GEOs Turn Up The Speed Of Light
In the multi-billion dollar broadband satellite wager, many service providers are still betting their money on geostationary earth orbit satellites, or a combination of high-flying GEOs and lower-orbiting LEOs.
This is true even though GEOs must contend with a nasty little obstacle limiting the applications they effectively serve. The problem is that TCP packets can't travel faster than the speed of light. This means that the round-trip
delay already seen terrestrially as packets are sent, received and acknowledged, is further magnified in the journey TCP packets must make up and down from satellites orbiting at about 22,300 miles.
While considerable debate exists over LEO latency (See, SIDE2latency), no one comes even close to arguing latency away with GEOs-and that has implications for business.
Joel Halpern, director of internetworking architecture for Newbridge Networks, says one clear message is that voice isn't meant to run over GEOs. Voice, he says, "can not live with more than a quarter second delay and prefers under 100 millisecond." GEO round-trip latency can approach the half-second mark-about 10 times the latency of a New York to California fiber hop. So, GEOs are probably best suited for those applications for which latency isn't a big issue-like multicasting, E-mail, bulk data delivery, software distribution, regularly broadcast database updates, and non-interactive video downloads.
Russell Daggatt, pre
sident of LEO-based Teledesic, says he doesn't "see a big role for GEO satellites in real-time applications," and because the PBX and server are coming together in the same computer, the role of GEOs will be further restrained going into the future.
Of course, not all of the players investing billions of dollars in next generation GEO systems concur. GEO advocates urge that the high-orbiting satellites let them tap into an existing terminal base, that GEOs are able to cover larger areas at lower cost than LEOs, that GEO topology is less complex and more manageable than that of LEOs, and that satellite-to-satellite GEO communications present much less routing complexity and jitter than LEO constellations.
Many also vigorously defend the use of voice and even videoconferening over GEOs, arguing that a single-hop GEO path meets ITU telephone standards. Lower delay is better, says Daniel R. Glover, a project engineer for the Satellite Network and Architecture Branch of NASA Lewis Research Center,
but with proper echo cancellation GEOs can produce "surprisingly high quality voice transmission." Hughes VP Denis Conti, adds that even videoconferencing, is viable over existing DirecPC GEO services since the numbers of sites involved tends to be small and control tends to pass from site to site.
The primary problem, though, is human expectation--the propensity of people to interrupt each other and find resulting transmission delays disconcerting; the expectation that a mouse click or joy-stick will produce fodder for the eye in a specific time interval. And even GEO advocates acknowledge that certain applications-like highly interactive gaming and remote control and login-simply aren't meant for GEOs.
And, while GEO providers-and even some terrestrial providers--can't exactly wish away high bandwidth latency, they can tout existing and proposed mechanisms that at least minimize the compounding problems that can occur when latency interacts with specific protocols like TCP/IP and SNA. An IETF
TCP-Over-Satellite working group has, for example, published information about practices that are useful in optimizing TCP/IP over satellites (ftp:ietf.org/internet-drafts/draft-ietf-tcpsat-res-issues-00.txt and ýtcpsat-stand-mech-01.txt). Hughes Research Laboratories also provides options and alternatives (www.wins.hrl.com/people/ygz/papers/inet97/index.html).
In particular, high latency can artificially narrow satellite bandwidth and delay the time it takes for a TCP transmission to come up to full speed. One reason lies with an important algorithm used for TCP/IP congestion avoidance, known as "slow start." Slow start tests the network waters for congestion through a process that sends 50 percent more data with each round trip for which congestion isn't encountered. For terrestrial pipes with high bandwidth or satellite pipes with high latency this can mean that transmissions are completed before full bandwidth is made available (See NWC, Feb. 15, 1997). In other words, bandwidth becomes artificial
ly constricted. This problem is particularly evident over the World Wide Web, where pulling down a single page may involve many TCP connections, each of which goes through the slow start process [Some browsers try to get around this problem by using defaults that transfer up to four segments and HTTP 1.1 also offers some relief.].
A second problem is that the potential for loss tends to be greater in today's satellite systems and may still be a problem in the future. The current generation of satellites has more noise to contend with than planned next generation systems that rely on error correction systems. That noise as well as any loss can be interpreted by TCP as congestion and initiate a dramatic downsizing of TCP's window. This is followed by a retransmission process that is even slower than the original slow start. Craig Partridge, a BBN technologies principal scientist working with NASA says, in fact, that on a gigabit GEO link, it could take several hours to achieve full transmission rates a
fter such a loss. Similarly, following slow start, losses during a transmission will be interpreted as congestion and slow the transmission.
Historically, one of the most common TCP modifications to bring transmissions up to full speed is spoofing. Spoofing provides premature acknowledgment that a TCP segment has been received, with each round trip releasing one TCP window's worth of data. The spoofing box then collects any duplicate acknowledgments to prevent confusion and asks for a retransmittal when a packet is not acknowledged. This effectively puts more packets in the air and reduces protocol-based bandwidth constraints. Proponents of spoofing also argue that it's wrong to assume that spoofing must be implemented on every computer used in a communication. Hughes DirecPC Enterprise, for example, claims to achieve 2.5Mbps speeds for customers. The spoofing occurs in VSAT terminals and at groundstations. At the company's Germantown, Md., hub the spoofing traffic is subsequently massaged so that it
can move cleanly onto the Internet.
Baker sees it this way: "Fifteen years of experience on the Internet says spoofing works just fine, there are just some considerations you need to make."
Others, like Partridge see TCP spoofing as little more than a Band-Aide. Partridge says TCP spoofing presents synchronization problems and possible data loss for users who may need to change their paths-say from a satellite to a terrestrial link. It can also present buffer management issues with speed mismatches causing tremendous queues to build up. And as the need for secure networking evolves, most experts, Baker included, agree that TCP spoofing won't work alongside end-to-end security schemes like IPSEC (See article, SIDESEC).
Another TCP modification is large windows. NASA's Glover says T1 efficiency can be improved from 30 percent (for a single TCP connection) to a figure approaching full capacity with large windows. Without the large windows option, a single TCP connection can carry up to 5
24Kbps, so large windows are not needed until an end user exceeds that rate. Typically, multiple lower rate connections are trunked together on a T1 line.
Because in-flight data must be stored on a transmitting machine until it is acknowledged, the large windows standards option of TCP/IP means more data can enter the network so long as the end station also supports this extension. Partridge has found that at SONET OC-3 speeds (155 Mbps) it takes about 11 seconds to get up to speed on a GEO link with large windows, 4 seconds on a LEO, and 2 seconds on a LAN. This means that most network transmittals will end long before the network reaches full speed on a GEO transmission. For example, only about 20 megabytes of data will be sent during the 11 seconds it takes a 155 Mbps GEO link to come up to speed. If spoofing is added to the mix, Partridge speculates "optimistically" that GEOS might be able to come up to speed at about the same rate as LEOs.
Large windows have a further limitation in tha
t they can only go up to a maximum data rate of about 15 Gbps over GEOs, says Partridge. And, today, yet another issue around large windows lies with machine support. UNIX servers have supported large windows for some time. Most desktop systems, however, do not support large windows, although Windows 98 is expected to add this functionality. For the time being, this means that businesses using GEO services will primarily access these systems via the LAN. This can be done today with software offered by Ray Noorda startup Helius in conjunction with Hughes Network Systems (See, page SIDEHELIUS).
Finally, functionality known as selective acknowledgments (SACKs), aids in a speedier recovery in the event of packet loss or reordering for satellites and other transmission types. An IETF consensus now exists for SACKs to become a standard TCP option. But there is ongoing debate about whether Network Address Translation boxes being widely deployed on corporate networks will recognize SACKs. Partridge estimates t
hat it may be two to three years before large windows and selective acknowledgments are widely supported on the desktop and server.
So, if you assume TCP spoofing isn't the answer ,and instead rely on large windows and SACKs, can the effect of GEO latency ever be reduced to the point that it even resembles terrestrial transports?
Partridge says "yes." He expects that within a year and a half experimental deployments will occur in two promising area-that of acknowledgment pacing and alternatives to slow-start for estimating available bandwidth. Pacing relies on estimates that smooth the flow of traffic over a link, making it easier to figure out available bandwidth. The alternatives to slow start would allow the sender to recognize pipe size and immediately jump to those speeds. Both approaches could be accomplished after satellite launch, and only pacing would effect groundstations, says Partridge, who along with Van Jacobson at Lawrence Berkeley Labs is leading the research in these areas.
Partridge also emphasizes that the value of this work isn't just for satellites-it applies as delay grows, but also as bandwidth grows. As terrestrial pipes grow bigger, similar latency issues come into play. "It's just that we are seeing this in satellites first," he says. Already, though, he says, "you can't fill a T3 long-haul terrestrial line without large windows. I'm deeply interested in finding solutions that work for all links," says Partridge, "not just satellites."
If Partridge is correct, the TCP research being conducted today may begin to transform itself into marketplace reality just about the time most GEO constellations come into service.
Scott Clavena of Pioneer Consulting is also confident that the technical problems will be resolved, "especially with the money behind these systems."
|
REPORTS
ANALYTICS
Follow 
