Background news analysis

Morphing TCP Technology For Space Travel The End-to-End Research draft being edited by Baker will include a wide-ranging list of implementation recommendations for TCP stack vendors. The suggestions--which apply to both terrestrial and satellite links--follow a December IETF report on some dramatic problems with existing (although anonymously referenced) TCP stacks. The recommendations, which are already implemented in the BSD Tahoe and Reno TCP releases, include slow start, a fast retransmit heuristic, selective acknowledgments and large windows. Top-Down Perspective Satellite advocates would like stack vendors to pay attention to a number of RFCs that could curb satellite delay. HTTP 1.1, for example, creates a single persistent connection that can perform multiple transactions. For many earthbound and satellite users, its implementation can't happen soon enough. Existi ng standards provide flexible window sizes, but most vendors (excluding a few Unix stack providers) implement a maximum window size of about 32 KB. Satellite providers say they need windows five times that size or greater for large data transfers. Space in this window is freed only when data is acknowledged as having arrived at its destination. The acknowledgments also "advertise" to the window any buffer limitations on the other end that would require the window to constrict. Daniel R. Glover, a NASA project engineer, notes that until vendors decide to deploy error-correction coding, some satellite links will be noisier than terrestrial fiber. When error-producing noise is confused by TCP with congestion, it can initiate a dramatic downsizing of the TCP window, followed by a retransmission process that is even slower than slow start. Another issue on the agenda is whether the actual TCP spec should be changed. Barajas would like to see a less-reliable TCP, or at least one in which the reliability overh ead is bumped up to the application layer. IETF's Baker says such an unreliable protocol could be used alongside TCP, but actual changes in the TCP protocol aren't going to happen on his watch. How quickly are changes needed? Hughes already has launched its DirecPC commercial Internet service (with terrestrial user access, followed by satellite download), and plans to join some competitors in targeting the millennium for providing full bidirectional Internet links. Helping these companies to sort out TCP issues are a handful of scientists commissioned by NASA. Among them are researchers at Ohio University who are conducting promising work to improve slow start for FTP applications. Craig Partridge, a co-inventor of the round-trip time-estimation algorithm used in slow start, says the university work involves an algorithm that is faster than slow start--a rough difference of, say, one-hundredth of the bandwidth, versus one-fourth. Partridge, a division scientist for BBN Systems and Technology, also is work ing for NASA to evaluate and create test environments for the TCP research. He's examining whether channel bandwidth estimation techniques developed by Bell Communications Research (Bellcore) and Bell Labs can be applied to TCP. Partridge says there's a sense of urgency about this TCP work, since many issues facing satellite use today will confront higher-speed terrestrial networks in the near future. The issues, he says, need to be solved within the next two years or so.

The H-Report News, Trends and Analysis by Kelly Jackson Higgins Internet Online products, resources and tips by Christy Hudgins-Bonafield Updated February 7, 1997