Enterprising NASA searches for faster hailing
Whenever Capt. James T. Kirk of the Starship Enterprise told Lt. Uhura to open a channel, he could hold an intergalactic conference over a two-way, real-time video channel. NASA hasn't quite gotten to that point, even for pushing data packets through space. The space agency has been testing a combination of asynchronous transfer mode switching with its Advanced Communications Technology Satellite. In one experiment, NASA wanted to deliver the power of a Cray Research Inc.
Whenever Capt. James T. Kirk of the Starship Enterprise told Lt. Uhura to open a
channel, he could hold an intergalactic conference over a two-way, real-time video
channel.
NASA hasn't quite gotten to that point, even for pushing data packets through space.
The space agency has been testing a combination of asynchronous transfer mode switching
with its Advanced Communications Technology Satellite. In one experiment, NASA wanted to
deliver the power of a Cray Research Inc. supercomputer at Cleveland's Lewis Research
Center to a high-end Silicon Graphics Inc. workstation at Boeing Co.'s Seattle facility
for some design work on a next-generation aircraft.
The effort succeeded, but with a surprise: Although the Cleveland-Seattle ATM link ran
at the fast synchronous optical network rate of 155 megabits/sec, NASA got only
10-megabit/sec, Ethernet-like performance.
A big part of the problem was the Transmission Control Protocol portion of the TCP/IP
protocol stack. This transport-layer protocol, which ensures that data is delivered
properly, chewed up most of the bandwidth and left just a fraction available for real
work.
That's why NASA now wants to spend a modest $500,000 to hand out a few contracts to
study TCP/IP in satellite communications.
The problem is especially acute with a geostationary orbiting satellite such as ACTS,
which flies in sync with the earth's rotation and hangs high enough up there to look down
on half the earth's surface.
The time it takes a radio signal to go from a ground station up to the satellite and
down to another ground station--and back--is interpreted by TCP as network congestion.
Things slow down. If the ground stations are at opposite edges of the satellite's view,
the signal takes even longer to travel.
""TCP works very well for what it was designed for. Terrestrial networks
don't get the delays you see in satellite networks,'' commented Daniel R. Glover, an
electronics engineer in the Lewis center's Space Electronics Division.
""Satellites are such a small part of the market that it's not worth most
people's time to worry about this. You could say we're a worst-case scenario.''
What bugs NASA today, however, could become everybody's long wait in the
not-too-distant future. Motorola Inc.'s Iridium project calls for putting up several dozen
communications satellites, and Microsoft Corp. chairman Bill Gates' Teledesic system plans
several hundred satellites.
These are low-earth-orbit satellites, or LEOS, so the delays aren't going to be
anything like what NASA found in the ACTS/ATM experiment. ACTS' position in space, about
25,000 miles up, measures about the same as the circumference of the earth. The altitude
of the LEOS, in contrast, would be only a few hundred miles. But there's also talk in some
quarters of throwing up a constellation of medium-earth-orbit satellites, or MEOS, which
would fly quite a bit farther up.
So, some day when the global information infrastructure comes into being and we're
communicating across different satellite networks, will we still be using TCP? We could
turn to the companion User Datagram Protocol, but then there'd be no guarantee our packets
would ever get delivered.
Can this TCP dilemma possibly result from a giant conspiracy in the Open Systems
Interconnection protocol camp? I say it's time NASA turned to Mr. Spock.
Masud is GCN's senior editor for communications.
NEXT STORY: Air Force buy will be first to include COE