tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 2760


Ongoing TCP Research Related to Satellites

Part 3 of 3, p. 29 to 46
Prev RFC Part


prevText      Top      Up      ToC       Page 29 
3.8 Sharing TCP State Among Similar Connections

Top      Up      ToC       Page 30 
3.8.1 Mitigation Description

   Persistent TCP state information can be used to overcome limitations
   in the configuration of the initial state, and to automatically tune
   TCP to environments using satellite links and to coordinate multiple
   TCP connections sharing a satellite link.

   TCP includes a variety of parameters, many of which are set to
   initial values which can severely affect the performance of TCP
   connections traversing satellite links, even though most TCP
   parameters are adjusted later after the connection is established.
   These parameters include initial size of cwnd and initial MSS size.
   Various suggestions have been made to change these initial
   conditions, to more effectively support satellite links.  However, it
   is difficult to select any single set of parameters which is
   effective for all environments.

   An alternative to attempting to select these parameters a-priori is
   sharing state across TCP connections and using this state when
   initializing a new connection.  For example, if all connections to a
   subnet result in extended congestion windows of 1 megabyte, it is
   probably more efficient to start new connections with this value,
   than to rediscover it by requiring the cwnd to increase using slow
   start over a period of dozens of round-trip times.

3.8.2 Research

   Sharing state among connections brings up a number of questions such
   as what information to share, with whom to share, how to share it,
   and how to age shared information.  First, what information is to be
   shared must be determined.  Some information may be appropriate to
   share among TCP connections, while some information sharing may be
   inappropriate or not useful.  Next, we need to determine with whom to
   share information.  Sharing may be appropriate for TCP connections
   sharing a common path to a given host.  Information may be shared
   among connections within a host, or even among connections between
   different hosts, such as hosts on the same LAN.  However, sharing
   information between connections not traversing the same network may
   not be appropriate.  Given the state to share and the parties that
   share it, a mechanism for the sharing is required.  Simple state,
   like MSS and RTT, is easy to share, but congestion window information
   can be shared a variety of ways. The sharing mechanism determines
   priorities among the sharing connections, and a variety of fairness
   criteria need to be considered.  Also, the mechanisms by which
   information is aged require further study.  See RFC 2140 for a
   discussion of the security issues in both sharing state within a
   single host and sharing state among hosts on a subnet.  Finally, the
   security concerns associated with sharing a piece of information need

Top      Up      ToC       Page 31 
   to be carefully considered before introducing such a mechanism.  Many
   of these open research questions must be answered before state
   sharing can be widely deployed.

   The opportunity for such sharing, both among a sequence of
   connections, as well as among concurrent connections, is described in
   more detail in [Tou97].  The state management itself is largely an
   implementation issue, however what information should be shared and
   the specific ways in which the information should be shared is an
   open question.

   Sharing parts of the TCB state was originally documented in T/TCP
   [Bra92], and is used there to aggregate RTT values across connection
   instances, to provide meaningful average RTTs, even though most
   connections are expected to persist for only one RTT.  T/TCP also
   shares a connection identifier, a sequence number separate from the
   window number and address/port pairs by which TCP connections are
   typically distinguished. As a result of this shared state, T/TCP
   allows a receiver to pass data in the SYN segment to the receiving
   application, prior to the completion of the three-way handshake,
   without compromising the integrity of the connection. In effect, this
   shared state caches a partial handshake from the previous connection,
   which is a variant of the more general issue of TCB sharing.

   Sharing state among connections (including transfers using non-TCP
   protocols) is further investigated in [BRS99].

3.8.3 Implementation Issues

   Sharing TCP state across connections requires changes to the sender's
   TCP stack, and possibly the receiver's TCP stack (as in the case of
   T/TCP, for example).  Sharing TCP state may make a particular TCP
   connection more aggressive.  However, the aggregate traffic should be
   more conservative than a group of independent TCP connections.
   Therefore, sharing TCP state should be safe for use in shared
   networks.  Note that state sharing does not present any new security
   problems within multiuser hosts.  In such a situation, users can
   steal network resources from one another with or without state

3.8.4 Topology Considerations

   It is expected that sharing state across TCP connections may be
   useful in all network environments presented in section 2.

Top      Up      ToC       Page 32 
3.8.5 Possible Interaction and Relationships with Other Research

   The state sharing outlined above is very similar to the Congestion
   Manager proposal [BRS99] that attempts to share congestion control
   information among both TCP and UDP flows between a pair of hosts.

3.9 ACK Congestion Control

   In highly asymmetric networks, a low-speed return link can restrict
   the performance of the data flow on a high-speed forward link by
   limiting the flow of acknowledgments returned to the data sender.
   For example, if the data sender uses 1500 byte segments, and the
   receiver generates 40 byte acknowledgments (IPv4, TCP without
   options), the reverse link will congest with ACKs for asymmetries of
   more than 75:1 if delayed ACKs are used, and 37:1 if every segment is
   acknowledged.  For a 1.5 Mb/second data link, ACK congestion will
   occur for reverse link speeds below 20 kilobits/sec.  These levels of
   asymmetry will readily occur if the reverse link is shared among
   multiple satellite receivers, as is common in many VSAT satellite
   networks.  If a terrestrial modem link is used as a reverse link, ACK
   congestion is also likely, especially as the speed of the forward
   link is increased.  Current congestion control mechanisms are aimed
   at controlling the flow of data segments, but do not affect the flow
   of ACKs.

   In [KVR98] the authors point out that the flow of acknowledgments can
   be restricted on the low-speed link not only by the bandwidth of the
   link, but also by the queue length of the router.  The router may
   limit its queue length by counting packets, not bytes, and therefore
   begin discarding ACKs even if there is enough bandwidth to forward

3.9.1 Mitigation Description

   ACK Congestion Control extends the concept of flow control for data
   segments to acknowledgment segments.  In the method described in
   [BPK97], any intermediate router can mark an acknowledgment with an
   Explicit Congestion Notification (ECN) bit once the queue occupancy
   in the router exceeds a given threshold.  The data sender (which
   receives the acknowledgment) must "echo" the ECN bit back to the data
   receiver (see section 3.3.3 for a more detailed discussion of ECN).
   The proposed algorithm for marking ACK segments with an ECN bit is
   Random Early Detection (RED) [FJ93].  In response to the receipt of
   ECN marked data segments, the receiver will dynamically reduce the
   rate of acknowledgments using a multiplicative backoff.  Once
   segments without ECN are received, the data receiver speeds up
   acknowledgments using a linear increase, up to a rate of either 1 (no

Top      Up      ToC       Page 33 
   delayed ACKs) or 2 (normal delayed ACKs) data segments per ACK.  The
   authors suggest that an ACK be generated at least once per window,
   and ideally a few times per window.

   As in the RED congestion control mechanism for data flow, the
   bottleneck gateway can randomly discard acknowledgments, rather than
   marking them with an ECN bit, once the queue fills beyond a given

3.9.2 Research

   [BPK97] analyze the effect of ACK Congestion Control (ACC) on the
   performance of an asymmetric network.  They note that the use of ACC,
   and indeed the use of any scheme which reduces the frequency of
   acknowledgments, has potential unwanted side effects.  Since each ACK
   will acknowledge more than the usual one or two data segments, the
   likelihood of segment bursts from the data sender is increased.  In
   addition, congestion window growth may be impeded if the receiver
   grows the window by counting received ACKs, as mandated by
   [Ste97,APS99].  The authors therefore combine ACC with a series of
   modifications to the data sender, referred to as TCP Sender
   Adaptation (SA).  SA combines a limit on the number of segments sent
   in a burst, regardless of window size.  In addition, byte counting
   (as opposed to ACK counting) is employed for window growth.  Note
   that byte counting has been studied elsewhere and can introduce
   side-effects, as well [All98].

   The results presented in [BPK97] indicate that using ACC and SA will
   reduce the bursts produced by ACK losses in unmodified (Reno) TCP.
   In cases where these bursts would lead to data loss at an
   intermediate router, the ACC and SA modification significantly
   improve the throughput for a single data transfer.  The results
   further suggest that the use of ACC and SA significantly improve
   fairness between two simultaneous transfers.

   ACC is further reported to prevent the increase in round trip time
   (RTT) that occurs when an unmodified TCP fills the reverse router
   queue with acknowledgments.

   In networks where the forward direction is expected to suffer losses
   in one of the gateways, due to queue limitations, the authors report
   at best a very slight improvement in performance for ACC and SA,
   compared to unmodified Reno TCP.

Top      Up      ToC       Page 34 
3.9.3 Implementation Issues

   Both ACC and SA require modification of the sending and receiving
   hosts, as well as the bottleneck gateway.  The current research
   suggests that implementing ACC without the SA modifications results
   in a data sender which generates potentially disruptive segment
   bursts.  It should be noted that ACC does require host modifications
   if it is implemented in the way proposed in [BPK97].  The authors
   note that ACC can be implemented by discarding ACKs (which requires
   only a gateway modification, but no changes in the hosts), as opposed
   to marking them with ECN.  Such an implementation may, however,
   produce bursty data senders if it is not combined with a burst
   mitigation technique.  ACC requires changes to the standard ACKing
   behavior of a receiving TCP and therefore is not recommended for use
   in shared networks.

3.9.4 Topology Considerations

   Neither ACC nor SA require the storage of state in the gateway.
   These schemes should therefore be applicable for all topologies,
   provided that the hosts using the satellite or hybrid network can be
   modified.  However, these changes are expected to be especially
   beneficial to networks containing asymmetric satellite links.

3.9.5 Possible Interaction and Relationships with Other Research

   Note that ECN is a pre-condition for using ACK congestion control.
   Additionally, the ACK Filtering algorithm discussed in the next
   section attempts to solve the same problem as ACC.  Choosing between
   the two algorithms (or another mechanism) is currently an open
   research question.

3.10 ACK Filtering

   ACK Filtering (AF) is designed to address the same ACK congestion
   effects described in 3.9.  Contrary to ACC, however, AF is designed
   to operate without host modifications.

3.10.1 Mitigation Description

   AF takes advantage of the cumulative acknowledgment structure of TCP.
   The bottleneck router in the reverse direction (the low speed link)
   must be modified to implement AF.  Upon receipt of a segment which
   represents a TCP acknowledgment, the router scans the queue for
   redundant ACKs for the same connection, i.e. ACKs which acknowledge
   portions of the window which are included in the most recent ACK.
   All of these "earlier" ACKs are removed from the queue and discarded.

Top      Up      ToC       Page 35 
   The router does not store state information, but does need to
   implement the additional processing required to find and remove
   segments from the queue upon receipt of an ACK.

3.10.2  Research

   [BPK97] analyzes the effects of AF.  As is the case in ACC, the use
   of ACK filtering alone would produce significant sender bursts, since
   the ACKs will be acknowledging more previously-unacknowledged data.
   The SA modifications described in 3.9.2 could be used to prevent
   those bursts, at the cost of requiring host modifications.  To
   prevent the need for modifications in the TCP stack, AF is more
   likely to be paired with the ACK Reconstruction (AR) technique, which
   can be implemented at the router where segments exit the slow reverse

   AR inspects ACKs exiting the link, and if it detects large "gaps" in
   the ACK sequence, it generates additional ACKs to reconstruct an
   acknowledgment flow which more closely resembles what the data sender
   would have seen had ACK Filtering not been introduced.  AR requires
   two parameters; one parameter is the desired ACK frequency, while the
   second controls the spacing, in time, between the release of
   consecutive reconstructed ACKs.

   In [BPK97], the authors show the combination of AF and AR to increase
   throughput, in the networks studied, over both unmodified TCP and the
   ACC/SA modifications.  Their results also strongly suggest that the
   use of AF alone, in networks where congestion losses are expected,
   decreases performance (even below the level of unmodified TCP Reno)
   due to sender bursting.

   AF delays acknowledgments from arriving at the receiver by dropping
   earlier ACKs in favor of later ACKs.  This process can cause a slight
   hiccup in the transmission of new data by the TCP sender.

3.10.3 Implementation Issues

   Both ACK Filtering and ACK Reconstruction require only router
   modification.  However, the implementation of AR requires some
   storage of state information in the exit router.  While AF does not
   require storage of state information, its use without AR (or SA)
   could produce undesired side effects.  Furthermore, more research is
   required regarding appropriate ranges for the parameters needed in

Top      Up      ToC       Page 36 
3.10.4 Topology Considerations

   AF and AR appear applicable to all topologies, assuming that the
   storage of state information in AR does not prove to be prohibitive
   for routers which handle large numbers of flows.  The fact that TCP
   stack modifications are not required for AF/AR makes this approach
   attractive for hybrid networks and networks with diverse types of
   hosts.  These modifications, however, are expected to be most
   beneficial in asymmetric network paths.

   On the other hand, the implementation of AF/AR requires the routers
   to examine the TCP header, which prohibits their use in secure
   networks where IPSEC is deployed.  In such networks, AF/AR can be
   effective only inside the security perimeter of a private, or virtual
   private network, or in private networks where the satellite link is
   protected only by link-layer encryption (as opposed to IPSEC).  ACK
   Filtering is safe to use in shared networks (from a congestion
   control point-of-view), as the number of ACKs can only be reduced,
   which makes TCP less aggressive.  However, note that while TCP is
   less aggressive, the delays that AF induces (outlined above) can lead
   to larger bursts than would otherwise occur.

3.10.5 Possible Interaction and Relationships with Other Research

   ACK Filtering attempts to solve the same problem as ACK Congestion
   Control (as outlined in section 3.9).  Which of the two algorithms is
   more appropriate is currently an open research question.

4   Conclusions

   This document outlines TCP items that may be able to mitigate the
   performance problems associated with using TCP in networks containing
   satellite links.  These mitigations are not IETF standards track
   mechanisms and require more study before being recommended by the
   IETF.  The research community is encouraged to examine the above
   mitigations in an effort to determine which are safe for use in
   shared networks such as the Internet.

5   Security Considerations

   Several of the above sections noted specific security concerns which
   a given mitigation aggravates.

   Additionally, any form of wireless communication link is more
   susceptible to eavesdropping security attacks than standard wire-
   based links due to the relative ease with which an attacker can watch
   the network and the difficultly in finding attackers monitoring the

Top      Up      ToC       Page 37 
6   Acknowledgments

   Our thanks to Aaron Falk and Sally Floyd, who provided very helpful
   comments on drafts of this document.

7   References

   [AFP98]   Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
             Initial Window", RFC 2414, September 1998.

   [AGS99]   Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over
             Satellite Channels using Standard Mechanisms", BCP 28, RFC
             2488, January 1999.

   [AHKO97]  Mark Allman, Chris Hayes, Hans Kruse, Shawn Ostermann.  TCP
             Performance Over Satellite Links.  In Proceedings of the
             5th International Conference on Telecommunication Systems,
             March 1997.

   [AHO98]   Mark Allman, Chris Hayes, Shawn Ostermann.  An Evaluation
             of TCP with Larger Initial Windows.  Computer Communication
             Review, 28(3), July 1998.

   [AKO96]   Mark Allman, Hans Kruse, Shawn Ostermann.  An Application-
             Level Solution to TCP's Satellite Inefficiencies.  In
             Proceedings of the First International Workshop on
             Satellite-based Information Services (WOSBIS), November

   [All97a]  Mark Allman.  Improving TCP Performance Over Satellite
             Channels.  Master's thesis, Ohio University, June 1997.

   [All97b]  Mark Allman.  Fixing Two BSD TCP Bugs.  Technical Report
             CR-204151, NASA Lewis Research Center, October 1997.

   [All98]   Mark Allman. On the Generation and Use of TCP
             Acknowledgments.  ACM Computer Communication Review, 28(5),
             October 1998.

   [AOK95]   Mark Allman, Shawn Ostermann, Hans Kruse.  Data Transfer
             Efficiency Over Satellite Circuits Using a Multi-Socket
             Extension to the File Transfer Protocol (FTP).  In
             Proceedings of the ACTS Results Conference, NASA Lewis
             Research Center, September 1995.

   [AP99]    Mark Allman, Vern Paxson.  On Estimating End-to-End Network
             Path Properties. ACM SIGCOMM, September 1999.

Top      Up      ToC       Page 38 
   [APS99]   Allman, M., Paxson, V. and W. Richard Stevens, "TCP
             Congestion Control", RFC 2581, April 1999.

   [BCC+98]  Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
             S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
             Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S.,
             Wroclawski, J. and L. Zhang, "Recommendations on Queue
             Management and Congestion Avoidance in the Internet", RFC
             2309, April 1998.

   [BKVP97]  B. Bakshi and P. Krishna and N. Vaidya and D. Pradham,
             "Improving Performance of TCP over Wireless Networks", 17th
             International Conference on Distributed Computing Systems
             (ICDCS), May 1997.

   [BPK97]   Hari Balakrishnan, Venkata N. Padmanabhan, and Randy H.
             Katz.  The Effects of Asymmetry on TCP Performance.  In
             Proceedings of the ACM/IEEE Mobicom, Budapest, Hungary,
             ACM.  September, 1997.

   [BPK98]   Hari Balakrishnan, Venkata Padmanabhan, Randy H. Katz.  The
             Effects of Asymmetry on TCP Performance.  ACM Mobile
             Networks and Applications (MONET), 1998 (to appear).

   [BPSK96]  H. Balakrishnan and V. Padmanabhan and S. Sechan and R.
             Katz, "A Comparison of Mechanisms for Improving TCP
             Performance over Wireless Links", ACM SIGCOMM, August 1996.

   [Bra89]   Braden, R., "Requirements for Internet Hosts --
             Communication Layers", STD 3, RFC 1122, October 1989.

   [Bra92]   Braden, R., "Transaction TCP -- Concepts", RFC 1379,
             September 1992.

   [Bra94]   Braden, R., "T/TCP -- TCP Extensions for Transactions:
             Functional Specification", RFC 1644, July 1994.

   [BRS99]   Hari Balakrishnan, Hariharan Rahul, and Srinivasan Seshan.
             An Integrated Congestion Management Architecture for
             Internet Hosts.  ACM SIGCOMM, September 1999.

   [ddKI99]  M. deVivo, G.O. deVivo, R. Koeneke, G. Isern.  Internet
             Vulnerabilities Related to TCP/IP and T/TCP.  Computer
             Communication Review, 29(1), January 1999.

Top      Up      ToC       Page 39 
   [DENP97]  Mikael Degermark, Mathias Engan, Bjorn Nordgren, Stephen
             Pink.  Low-Loss TCP/IP Header Compression for Wireless
             Networks.  ACM/Baltzer Journal on Wireless Networks, vol.3,
             no.5, p. 375-87.

   [DMT96]   R. C. Durst and G. J. Miller and E. J. Travis, "TCP
             Extensions for Space Communications", Mobicom 96, ACM, USA,

   [DNP99]   Degermark, M., Nordgren, B. and S. Pink, "IP Header
             Compression", RFC 2507, February 1999.

   [FF96]    Kevin Fall, Sally Floyd.  Simulation-based Comparisons of
             Tahoe, Reno, and SACK TCP.  Computer Communication Review,
             V. 26 N. 3, July 1996, pp. 5-21.

   [FF99]    Sally Floyd, Kevin Fall.  Promoting the Use of End-to-End
             Congestion Control in the Internet, IEEE/ACM Transactions
             on Networking, August 1999.

   [FH99]    Floyd, S. and T. Henderson, "The NewReno Modification to
             TCP's Fast Recovery Algorithm", RFC 2582, April 1999.

   [FJ93]    Sally Floyd and Van Jacobson.  Random Early Detection
             Gateways for Congestion Avoidance, IEEE/ACM Transactions on
             Networking, V. 1 N. 4, August 1993.

   [Flo91]   Sally Floyd.  Connections with Multiple Congested Gateways
             in Packet-Switched Networks, Part 1: One-way Traffic.  ACM
             Computer Communications Review, V. 21, N. 5, October 1991.

   [Flo94]   Sally Floyd.  TCP and Explicit Congestion Notification, ACM
             Computer Communication Review, V. 24 N. 5, October 1994.

   [Flo99]   Sally Floyd.  "Re: TCP and out-of-order delivery", email to
             end2end-interest mailing list, February, 1999.

   [Hah94]   Jonathan Hahn.  MFTP: Recent Enhancements and Performance
             Measurements.  Technical Report RND-94-006, NASA Ames
             Research Center, June 1994.

   [Hay97]   Chris Hayes.  Analyzing the Performance of New TCP
             Extensions Over Satellite Links.  Master's Thesis, Ohio
             University, August 1997.

   [HK98]    Tom Henderson, Randy Katz.  On Improving the Fairness of
             TCP Congestion Avoidance.  Proceedings of IEEE Globecom `98
             Conference, 1998.

Top      Up      ToC       Page 40 
   [HK99]    Tim Henderson, Randy Katz.  Transport Protocols for
             Internet-Compatible Satellite Networks, IEEE Journal on
             Selected Areas of Communications, February, 1999.

   [Hoe95]   J. Hoe, Startup Dynamics of TCP's Congestion Control and
             Avoidance Schemes. Master's Thesis, MIT, 1995.

   [Hoe96]   Janey Hoe.  Improving the Startup Behavior of a Congestion
             Control Scheme for TCP.  In ACM SIGCOMM, August 1996.

   [IL92]    David Iannucci and John Lakashman.  MFTP: Virtual TCP
             Window Scaling Using Multiple Connections.  Technical
             Report RND-92-002, NASA Ames Research Center, January 1992.

   [Jac88]   Van Jacobson.  Congestion Avoidance and Control.  In
             Proceedings of the SIGCOMM '88, ACM.  August, 1988.

   [Jac90]   Jacobson, V., "Compressing TCP/IP Headers", RFC 1144,
             February 1990.

   [JBB92]   Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for
             High Performance", RFC 1323, May 1992.

   [JK92]    Van Jacobson and Mike Karels.  Congestion Avoidance and
             Control.  Originally appearing in the proceedings of
             SIGCOMM '88 by Jacobson only, this revised version includes
             an additional appendix.  The revised version is available
             at  1992.

   [Joh95]   Stacy Johnson.  Increasing TCP Throughput by Using an
             Extended Acknowledgment Interval.  Master's Thesis, Ohio
             University, June 1995.

   [KAGT98]  Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran.  HTTP
             Page Transfer Rates Over Geo-Stationary Satellite Links.
             March 1998. Proceedings of the Sixth International
             Conference on Telecommunication Systems.

   [Kes91]   Srinivasan Keshav.  A Control Theoretic Approach to Flow
             Control.  In ACM SIGCOMM, September 1991.

   [KM97]    S. Keshav, S. Morgan. SMART Retransmission: Performance
             with Overload and Random Losses. Proceeding of Infocom.

Top      Up      ToC       Page 41 
   [KVR98]   Lampros Kalampoukas, Anujan Varma, and K. K.Ramakrishnan.
             Improving TCP Throughput Over Two-Way Asymmetric Links:
             Analysis and Solutions.  Measurement and Modeling of
             Computer Systems, 1998, Pages 78-89.

   [MM96a]   M. Mathis, J. Mahdavi, "Forward Acknowledgment: Refining
             TCP Congestion Control," Proceedings of SIGCOMM'96, August,
             1996, Stanford, CA.  Available from

   [MM96b]   M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding
             Parameters" Available from

   [MMFR96]  Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
             Selective Acknowledgment Options", RFC 2018, October 1996.

   [MSMO97]  M. Mathis, J. Semke, J. Mahdavi, T. Ott, "The Macroscopic
             Behavior of the TCP Congestion Avoidance
             Algorithm",Computer Communication Review, volume 27,
             number3, July 1997.  Available from

   [MV98]    Miten N. Mehta and Nitin H. Vaidya.  Delayed Duplicate-
             Acknowledgments: A Proposal to Improve Performance of TCP
             on Wireless Links.  Technical Report 98-006, Department of
             Computer Science, Texas A&M University, February 1998.

   [Nic97]   Kathleen Nichols.  Improving Network Simulation with
             Feedback.  Com21, Inc. Technical Report.  Available from

   [PADHV99] Paxson, V., Allman, M., Dawson, S., Heavens, I. and B.
             Volz, "Known TCP Implementation Problems", RFC 2525, March

   [Pax97]   Vern Paxson.  Automated Packet Trace Analysis of TCP
             Implementations.  In Proceedings of ACM SIGCOMM, September

   [PN98]    Poduri, K. and K. Nichols, "Simulation Studies of Increased
             Initial TCP Window Size", RFC 2415, September 1998.

   [Pos81]   Postel, J., "Transmission Control Protocol", STD 7, RFC
             793, September 1981.

Top      Up      ToC       Page 42 
   [RF99]    Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
             Congestion Notification (ECN) to IP", RFC 2481, January

   [SF98]    Nihal K. G. Samaraweera and Godred Fairhurst,
             "Reinforcement of TCP error Recovery for Wireless
             Communication", Computer Communication Review, volume 28,
             number 2, April 1998.

   [SP98]    Shepard, T. and C. Partridge, "When TCP Starts Up With Four
             Packets Into Only Three Buffers", RFC 2416, September 1998.

   [Ste97]   Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
             Retransmit, and Fast Recovery Algorithms", RFC 2001,
             January 1997.

   [Sut98]   B. Suter, T. Lakshman, D. Stiliadis, and A. Choudhury.
             Design Considerations for Supporting TCP with Per-flow
             Queueing.  Proceedings of IEEE Infocom `98 Conference,

   [Tou97]   Touch, J., "TCP Control Block Interdependence", RFC 2140,
             April 1997.

   [VH97a]   Vikram Visweswaraiah and John Heidemann.  Improving Restart
             of Idle TCP Connections.  Technical Report 97-661,
             University of Southern California, 1997.

   [VH97b]   Vikram Visweswaraiah and John Heidemann.  Rate-based pacing
             Source Code Distribution, Web page:
             November, 1997.

   [VH98]    Vikram Visweswaraiah and John Heidemann.  Improving Restart
             of Idle TCP Connections (revised).  Submitted for

Top      Up      ToC       Page 43 
8   Authors' Addresses

   Mark Allman
   NASA Glenn Research Center/BBN Technologies
   Lewis Field
   21000 Brookpark Rd.  MS 54-2
   Cleveland, OH  44135


   Spencer Dawkins
   P.O.Box 833805
   Richardson, TX 75083-3805


   Dan Glover
   NASA Glenn Research Center
   Lewis Field
   21000 Brookpark Rd.  MS 3-6
   Cleveland, OH  44135


   Jim Griner
   NASA Glenn Research Center
   Lewis Field
   21000 Brookpark Rd.  MS 54-2
   Cleveland, OH  44135


   Diepchi Tran
   NASA Glenn Research Center
   Lewis Field
   21000 Brookpark Rd.  MS 54-2
   Cleveland, OH  44135


Top      Up      ToC       Page 44 
   Tom Henderson
   University of California at Berkeley
   Phone: +1 (510) 642-8919


   John Heidemann
   University of Southern California/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695


   Joe Touch
   University of Southern California/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292-6601

   Phone: +1 310-448-9151
   Fax:   +1 310-823-6714

   Hans Kruse
   J. Warren McClure School of Communication Systems Management
   Ohio University
   9 S. College Street
   Athens, OH 45701

   Phone: 740-593-4891
   Fax: 740-593-4889

   Shawn Ostermann
   School of Electrical Engineering and Computer Science
   Ohio University
   416 Morton Hall
   Athens, OH  45701

   Phone: (740) 593-1234

Top      Up      ToC       Page 45 
   Keith Scott
   The MITRE Corporation
   M/S W650
   1820 Dolley Madison Blvd.
   McLean VA 22102-3481


   Jeffrey Semke
   Pittsburgh Supercomputing Center
   4400 Fifth Ave.
   Pittsburgh, PA  15213


Top      Up      ToC       Page 46 
9  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an


   Funding for the RFC Editor function is currently provided by the
   Internet Society.