Net Task Force Drafts TCP Upgrade For Satellite Links

Welcome Guest. | Log In| Register | Membership Benefits

March 22, 1998 (8:40 AM EST)

Net Task Force Drafts TCP Upgrade For Satellite Links

By Larry Lange,

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.

"I'm not saying TCPSAT is the best solution in every case; it's not. But IP Multicast isn't the best solution out there either."

-- Mark Allman
NASA Lewis Research Center

"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."