Internet Engineering Task Force Mark Allman INTERNET DRAFT NASA Lewis/Sterling Software File: draft-ietf-tcpsat-res-issues-00.txt Dan Glover NASA Lewis November 21, 1997 Expires: May 21, 1998 Ongoing TCP Research Related to Satellites Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). NOTE This document is not complete. The authors are aware of many more mitigation strategies that may help TCP over satellite channels. These will be outlined in future iterations of this document. Abstract This document outlines TCP mechanisms that may help better utilize the available bandwidth in TCP transfers over long-delay satellite channels. The work outlined in this document is preliminary and has not yet been judged to be safe for use in the shared Internet. 1. Introduction This document outlines mechanisms that may help the Transmission Control Protocol (TCP) [Pos81] better utilize the bandwidth provided by long-delay satellite environments. These mechanisms may also help in other environments. The proposals outlined in this document are currently being studied throughout the research community. Therefore, these mechanisms SHOULD NOT be used in the shared Internet. At the point these mechanisms are proved safe and appropriate for general use, the appropriate IETF documents will be written. Until that time, these mechanisms should be used for research and in private networks only. Expires: May 21, 1998 [Page 1]
draft-ietf-tcpsat-res-issues-00.txt November 1997 2. Satellite Characteristics The characteristic of satellite links that has the largest effect on TCP is the propagation delay. The magnitude and characteristics of this delay depends on the distance of the satellite and its velocity relative to the ground station. Satellites in geostationary orbits appear to hover over a point on the ground and so have a constant, but large, delay (roughly 500 ms). Satellites in lower orbits have a shorter path to the ground and so lower delay, but these satellites move across the sky. This means the propagation path will change and the delay will vary as the satellite flies from horizon to horizon and eventually out of view of a ground station. At higher altitudes than GSO (e.g., for deep space probes), the spacecraft will also lose contact with a particular ground station as the Earth turns. Generally speaking, satellite channels are noisier than fiber and have less bandwidth capacity. Satellites may not be the weakest link in a connection in these areas, however. Error correction coding can mitigate noise problems. Additional radio frequency bandwidth is being exploited with moves to higher frequencies. A more detailed discussion of satellite characteristics can be found in [AG97]. 2.1 Architectures 2.1.1 Asymmetric Satellite Networks Some satellite networks exhibit a bandwidth asymmetry, with a larger data rate in one direction than the other, because of limits on the transmission power and the antenna size at one end of the link. Meanwhile, other systems are one way only or use a different return path. For example, in some systems being used today, satellites are found at the edges of the Internet providing the end user with a connection to the shared Internet. Many end users share a relatively high data rate downlink from a satellite and use a non-shared, low speed dialup modem connection as the return channel. [Picture in next iteration of draft.] 2.1.2 Hybrid Satellite Networks In the more general case, satellites may be located at any point in the network topology. In this case, the satellite link carries real network traffic and acts as just another channel between two gateways. In this environment, a given connection may be sent over terrestrial channels, as well as satellite channels. On the other Expires: May 21, 1998 [Page 2]
draft-ietf-tcpsat-res-issues-00.txt November 1997 hand, a connection could also travel over only the terrestrial network or only over the satellite portion of the network. [Picture in next iteration of draft.] 3. Mitigations The following sections will discuss various techniques for mitigating the problems TCP faces in the satellite environment. Each of the following sections details mitigation techniques that apply to one portion of the TCP connection. Each of the following sections will be organized as follows. First, each mitigation will be briefly outlined. Next, research work involving the mechanism in question will be briefly discussed. Finally, the mechanism's benefits in each of the environments above will be outlined. 4. Connection Setup 4.1 Mitigation Description TCP uses a three-way handshake to setup a connection between two hosts. This connection setup requires 1 RTT or 1.5 RTTs, depending upon whether the data sender started the connection actively or passively. This startup time can be eliminated by using TCP extensions for transactions (T/TCP) [Bra94]. In most situations, T/TCP bypasses the three-way handshake. This allows the data sender to begin transmitting data in the first packet sent (along with the connection setup information). This is especially helpful for short request/response traffic. 4.2 Research T/TCP is outlined and analyzed in [Bra94] and [Bra92]. 4.3 Implementation Issues T/TCP required changes in the TCP stacks of both the data sender and the data receiver. 4.4 Topology Considerations It is expected that T/TCP will be equally beneficial in all environments outlined in section 2. 5. Slow Start The slow start algorithm is used to gradually increase the size of TCP's sliding window [JK88] [Ste97]. The algorithm is an important safe-guard against transmitting an inappropriate amount of data into the network when the connection starts up. The algorithm begins by sending a single data segment to the receiver. For each acknowledgment (ACK) returned, the size of the window is increased by 1 segment. This makes the window growth directly proportional to the round-trip time (RTT). In long-delay environments, such as some Expires: May 21, 1998 [Page 3]
draft-ietf-tcpsat-res-issues-00.txt November 1997 satellite channels, the large RTT increases the time needed to increase the size of the window to an appropriate level. This effectively wastes capacity [All97]. Delayed ACKs are another source of wasted capacity during the slow start phase. RFC 1122 [Bra89] allows data receivers to refrain from ACKing every incoming data segment. However, every second full-sized segment must be ACKed. If a second full-sized segment does not arrive within a given timeout, an ACK must be generated (this timeout cannot exceed 500 ms). Since the data sender increases the size of the window based on the number of arriving ACKs, reducing the number of ACKs slows the window's growth rate. In addition, when TCP starts sending, it sends 1 segment. When using delayed ACKs a second segment must arrive before an ACK is sent. Therefore, the receiver is always going to have to wait for the delayed ACK timer to expire before ACKing the first segment. This also increases the transfer time. Several proposals have suggested ways to make slow start less problematic in long-delay environments. These proposals are briefly outlined below and references to the research work given. 5.1 Larger Initial Window 5.1.1 Mitigation Description One method that will reduce the amount of time required by slow start (and therefore, the amount of wasted capacity) is to make the initial window be more than a single segment. Recently, this proposal has been outlined in an Internet-Draft [FAP97]. The suggested size of the initial window is given in equation 1. min (4*MSS, max (2*MSS, 4380 bytes)) (1) By increasing the initial window, more packets are sent immediately, which will trigger more ACKs, allowing the window to open more rapidly. In addition, by sending at least 2 segments into the network initially, the first segment does not need to wait for the delayed ACK timer to expire as is the case when the initial window is 1 segment (as discussed above). Therefore, the window size given in equation 1 saves up to 3 RTTs and a delayed ACK timeout when compared to an initial window of 1 segment. Using a larger initial window is likely to cause increased amount of loss in highly congested networks (where each connection's share of the router queue is less than the initial window size). Therefore, this change must be studied further to ensure that it is safe the shared Internet. 5.1.2 Research Several researchers have studied the use of a larger initial window in various environments. Nichols [Nic97] found that using a larger initial window reduced the time required to load WWW pages over Expires: May 21, 1998 [Page 4]
draft-ietf-tcpsat-res-issues-00.txt November 1997 hybrid fiber coax (HFC) channels. Furthermore, it has been found that using an initial window of 4 packets does not negatively impact overall performance over dialup modem channels [SP97]. 5.1.3 Implementation Issues The use of larger initial windows requires changes to the sender's TCP stack. 5.1.4 Topology Considerations It is expect that the use of a large initial window would be equally beneficial to all network architectures outlined in section 2. 5.2 Handling Acknowledgments During Slow Start 5.2.1 Mitigation Description As discussed above, the wide-spread use of delayed ACKs increases the time needed by a TCP sender to increase the size of its window during slow start. Several suggestions have been made to counteract the negative impact delayed ACKs have on bandwidth utilization. The first suggestion is that the window size should be increased based on the number of previously unacknowledged segments covered by each incoming ACK [All97]. This makes the increase relative to the amount of data transmitted, rather than the number of ACKs received (known as byte counting). Another idea that has been put forth is turning delayed ACKs off during the slow start phase of the TCP connection. This would provide an increase in the number of ACKs arriving at the sender and thus decrease the time required to increase window size. After slow start, when the number of ACKs is not as important, delayed ACKs could be implemented as specified in [Bra89]. 5.2.2 Research Using byte counting, as opposed to standard ACK counting, has been shown to reduce the amount of time needed to increase the window to an appropriate size in satellite networks [All97]. 5.2.3 Implementation Issues Changing from ACK counting to byte counting requires changes to the data sender's TCP stack. Turning delayed ACKs off during slow start requires changes to the data receiver's TCP stack. 5.2.4 Topology Considerations It has been suggested by some (and roundly criticized by others) that the first mechanism (byte counting, rather than ACK counting) Expires: May 21, 1998 [Page 5]
draft-ietf-tcpsat-res-issues-00.txt November 1997 will be exhibit the same properties regardless of the network topology (outlined in section 2) being used. Disabling delayed ACKs during slow start would increase the number of packets being sent in the reverse direction, which may negatively impact asymmetric channels, with a limited-bandwidth return channel. It is expected that this mechanism will work well in the other topologies outlined in section 2. 5.3 Terminating Slow Start 5.3.1 Mitigation Description The initial slow start phase is used by TCP to determine an appropriate window size [JK88]. Slow start is terminated when TCP detects congestion, or when the size of the window reaches the size of the receivers advertised window. The window size at which TCP ends slow start and begins using the congestion avoidance [JK88] algorithm is "ssthresh". The initial value for ssthresh is the receiver's advertised window. TCP doubles the size of the window every RTT and therefore can overwhelm the network with at most twice as many segments as the network can handle. By setting ssthresh to something less than the receiver's advertised window initially, the sender may avoid overwhelming the network with segments. Hoe [Hoe96] proposes using the packet-pair [Kes91] algorithm to determine a more appropriate value for ssthresh. The algorithm observes the spacing between the first few ACKs to determine the bandwidth of the bottleneck link. Together with the measured RTT, the delay*bandwidth product is determined and ssthresh is set to this value. When TCP's window reaches this reduced ssthresh, slow start is terminated and transmission continues with congestion avoidance, which is a much more conservative algorithm for increasing the size of the window. 5.3.2 Research It has been shown that estimating ssthresh can improve performance and decrease packet loss [Hoe96]. 5.3.3 Implementation Issues Estimating ssthresh requires changes to the data sender's TCP stack. 5.3.4 Topology Considerations It is expected that this mechanism will work well in all symmetric topologies outlined in section 2. However, asymmetric channels pose a special problem, as the rate of the returning ACKs may not be the bottleneck bandwidth in the forward direction. 6. Loss Recovery 6.1 Non-SACK Based Mechanisms Expires: May 21, 1998 [Page 6]
draft-ietf-tcpsat-res-issues-00.txt November 1997 6.2 SACK Based Mechanisms 6.3 Detecting Corruption Loss 6.4 Use of RED and ECN 7. Spoofing 8. Protocol Boosters 9. Multiple Data Connections 10. TCP Pacing 11. ACK Spacing 12. Header Compression 13. Sharing TCP State Among Multiple Similar Connections x. Conclusions References [AG97] Mark Allman, Dan Glover. Enhancing TCP Over Satellite Channels using Standard Mechanisms, November 1997. Internet-Draft draft-ietf-tcpsat-stand-mech-01.txt (work in progress). [All97] Mark Allman. Improving TCP Performance Over Satellite Channels. Master's thesis, Ohio University, June 1997. [Bra89] Robert Braden. Requirements for Internet Hosts -- Communication Layers, October 1989. RFC 1122. [Bra92] Robert Braden. Transaction TCP -- Concepts, September 1992. RFC 1379. [Bra94] Robert Braden. T/TCP -- TCP Extensions for Transactions: Functional Specification, July 1994. RFC 1644. [FAP97] Sally Floyd, Mark Allman, Craig Partridge. Increasing TCP's Initial Window, July 1997. Internet-Draft draft-floyd-incr-init-win-00.txt (work in progress). [Hoe96] Janey Hoe. Improving the Startup Behavior of a Congestion Control Scheme for TCP. In ACM SIGCOMM, August 1996. [JK88] Van Jacobson and Michael Karels. Congestion Avoidance and Control. In ACM SIGCOMM, 1988. [Kes91] Srinivasan Keshav. A Control Theoretic Approach to Flow Control. In ACM SIGCOMM, September 1991. Expires: May 21, 1998 [Page 7]
draft-ietf-tcpsat-res-issues-00.txt November 1997 [Nic97] Kathleen Nichols. Improving Network Simulation with Feedback. Submitted to InfoCom 97. [Pos81] Jon Postel. Transmission Control Protocol, September 1981. RFC 793. [SP97] Tim Shepard and Craig Partridge. When TCP Starts Up With Four Packets Into Only Three Buffers, July 1997. Internet-Draft draft-shepard-TCP-4-packets-3-buff-00.txt (work in progress). [Ste97] W. Richard Stevens. TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, January 1997. RFC 2001. Author's Addresses: Mark Allman NASA Lewis Research Center/Sterling Software 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135 mallman@lerc.nasa.gov http://gigahertz.lerc.nasa.gov/~mallman Dan Glover NASA Lewis Research Center 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135 Daniel.R.Glover@lerc.nasa.gov Expires: May 21, 1998 [Page 8]
