http://www.techweb.com/wire/story/TWB19980322S0002
An interesting story. So, TCPSAT provides both transport and
network layers, subsuming TCP and IP, but presumably with
interoperability in mind - at least at the network layer (I hope)
This article talks about both the satellite community's problems
with it (and a good point - I think - about opening up the backpath
on an asymmetric link when building the routing tree) and even the
problems with implementing it on symmetric land-lines (Cerf's
comments about CPU and policy).
So, how general is TCPSAT? Is symmetric transport a special
case of asymmetric (hmmm...)? And you can forget *TP. If we
can't generalize the network layer, we're going to need *NP.
What's Teledesic doing about mcast anyhow?
===
Net Task Force Drafts TCP Upgrade For Satellite
Links
(03/22/98; 11:40 a.m. EST)
By Larry Lange, EE Times
Despite the hype surrounding IP Multicast and its
purported ability to deliver a more powerful and robust
Internet, serious doubts about its effectiveness are
emanating from the very organization touting it. A
working group of the Internet Engineering Task Force
(IETF) has posted a new version of a draft for
enhancing the TCP for Internet transmissions over
satellite, with an eye toward extending the method to
other transport mechanisms as well.
The team of engineers, working at the NASA Lewis
Research Center, has proposed TCP over satellite
(TCPSAT), which looks to fix inherent flaws in the
TCP protocol. The developers, who double as members
of the IETF's TCP over Satellite Working Group, said
TCPSAT could operate in tandem with IP Multicast or
even usurp it.
Unlike past methods, IP Multicast-enabled networks
send one transmission across a pipe that is then
disseminated to many usecalled unicast methods, IP
Multicast-enabled networks send one transmission
across a pipe that is then disseminated to many users at
the end points, thereby conserving bandwidth and
speeding the network for distribution of large audio and
video multimedia files. The technique is amassing
support; notably, RealNetworks, Microsoft, and Intel
are developing applications that incorporate the Internet
Group Multicast Protocol (IGMP).
But IP Multicast has its critics in the United States, and
a huge chunk of users in Europe, Asia, and the Middle
East has sidestepped the protocol, opting for an
alternative method over satellite for Internet
connectivity and television-quality Internet multimedia
reception.
As the transport layer of the TCP/IP Internet protocols,
TCP takes the information for packet transmission,
breaks it into pieces, then numbers each piece, so
receipt can be verified and the data put back in the
proper order. Because TCP requires an
acknowledgement -- unlike the "send and pray" Use
Datagram Protocol for packet transport -- it can
experience significant latencies in such long-haul links
as satellite-to-terminal connections. IP Multicast
regularly uses UDP, but some software developers
want better control over packet services.
Several updates for TCP have been adopted or
proposed. Developers regularly use Van Lewis'
slow-start algorithms, and such TCP variants as TCP
Reno, TCP Vegas, and TCP Boston add special bit
fields or procedures for better control of
acknowledgement operations. TCPSAT is the latest to
come down the pike.
"I'm not saying TCPSAT is the best solution in every
case; it's not," said Mark Allman, a computer scientist
with the Satellite Architecture Group of the NASA
Lewis Research Center, in Cleveland, Ohio. "But IP
Multicast isn't the best solution out there either."
At least one company acknowledges investigating
TCPSAT as a complete replacement for IP Multicast:
The Fantastic Corp. (TFC), in Zug, Switzerland, which
is making huge inroads across Europe, Asia, and the
Middle East with its broadcast-interface software for
PCs and TVs.
"TCPSAT would be a
replacement for IP Multicast,"
which is not conducive to
satellite configuration, said
Erik Groelsen, vice president
of system engineering at TFC.
"Multicast is mainly one-way;
it doesn't address the issues of
two-way communication via
satellite."
IP Multicast runs on top of
the IP. As the second half of
the TCP/IP duo, IP is the
network layer and takes care
of addressing. IP itself is so
widely used that fundamental changes are not being
proposed for TCP binding, though the new IPv6
enhances the IP header field to handle packet
prioritization, security, and other features.
Since TCPSAT enables more robust Internet
connectivity through the TCP protocol, however, TFC
"would be using TCPSAT instead of IP and IP
Multicast," Groelsen said. "You're either using IP or
you're using TCPSAT."
NASA's Allman said the TCPSAT Working Group is
addressing what he called "some fundamental flaws" in
the transport protocol. One problem is the window size,
which Allman described as "the amount of traffic that
can be 'thrown out' over a network at any one time."
The group is widening that window to accommodate
exponentially higher amounts of traffic.
That move may extend TCPSAT's advantages beyond
satellite transmission. "Even for terrestrial, it happens
that you need this larger window for new Internet
networks, such as the gigabit networks coming up,"
Allman said. Gigabit networks that will incorporate the
new specification include the nearly completed
Internet2, a government-sponsored high-speed network
for educational and research capabilities.
Dan Glover, a NASA engineer and TCPSAT
working-group member, similarly said the team is
"branching out beyond the TCP issues. We're entirely
separate from IP Multicast, and we're looking to
improve TCP over satellite to get better performance."
Not A Good Mix
Judy Estrin, who recently became chief technology
officer at Cisco after the San Jose, Calif., company
acquired her IP Multicast company, Precept Software,
agreed that, "ultimately, TCPSAT and IP Multicast
don't go together. Multicast works well over satellite,
but you don't want it over TCP."
The IETF's Glover said a number of commercial
broadband-satellite companies that offer Internet
connectivity are already implementing TCPSAT for
customers.
Among them is PanAmSat, in Greenwich, Conn., which
has a 17-satellite global system for domestic and
international transmission. The company services
carriers from Latin America, Africa, and Asia. The
largest single user of PanAmSat is the giant Hughes
Network Systems .
Another TCPSAT user is Orion Network Systems, in
Rockville, Md., which provides high-speed Internet
connectivity in North America and has a global satellite
system under construction that, when completed, will
support 85 percent of the world's markets.
Orion's first satellite has been in operation since 1995
and serves Europe, parts of the United States, Canada,
and Mexico. The company's Asia-Pacific satellite is
scheduled for launch next year. Another slated for 1999
will serve Latin America, Russia, and the Middle East.
"These are the real-world applications already in
progress for TCPSAT," Glover said of Orion and
PanAmSat.
Switzerland's TFC, meanwhile, has tapped into the
brewing dissatisfaction with IP Multicast to sign a
number of influential broadcast partners. They include
Deutsche Telekom, which says it is the world's
third-largest phone carrier and largest cable-TV
provider, with 17 million subscribers; Elsacom, which
operates in the Italian market; and ZakSat, a
Kuwait-based satellite-communications company. The
ZakSat deal alone will bring broadband multimedia
services to businesses and households in 63 countries,
from Australia to Turkey.
TFC has also crossed the Atlantic, with funding and
technology partnerships with such U.S. companies as
Intel and e-commerce provider Commerce One, in
Walnut Creek, Calif.
Groelsen of TFC cites the agreements as evidence that
"there's a definite need for TCPSAT at this point.
When you look at the Multicast environment, it's very
Internet-centric, but the Internet model [over phone
lines] is causing big problems, especially at the routing
end."
Like Fire And Water
Combining the two may not be a feasible option,
Groelsen said. "With Multicast figured in [for satellite
connectivity], there might even be new routing problems
to deal with." He added when you build up the routing
tree from Multicast, you pass information back by the
channel from which you want to receive the Multicast
signal by opening the router.
"But if you're doing that with an asymmetric link," he
said, "you're not opening up on a satellite link; you're
actually opening up for the back path, and with an
asymmetric link, you're not opening up on a satellite
link; you're actually opening up for the back path, and
that's not where you want the data."
During the recent IP Multicast Summit, in San Jose
Calif., keynote speaker Vint Cerf, a pioneer of TCP/IP
who is now vice president of data architecture at MCI,
in Washington, D.C., acknowledged that IP Multicast
technology is problematic at best.
"It's not a trivial matter to incorporate multicasting
capability into the Net; it consumes CPU [central
processing unit] resources," said Cerf. "And then
there's the problem of getting all the equipment in and
justifying it in the face of an uncertain market." For
MCI and other ISPs, he said, it's "a multimillion-dollar
proposition."
Cerf also addressed the nagging question of how ISPs
would charge for Multicast use and wondered aloud
about policy implementations. "Plainly, we have a lot of
work to do in monitoring and managing complex
multicasting schemes," he said. "These are in the very
early, nascent stages."