Internet Engineering Task Force S. Dawkins INTERNET DRAFT G. Montenegro M. Kojo V. Magret November 24, 2000 End-to-end Performance Implications of Slow Links draft-ietf-pilc-slow-05.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Comments should be submitted to the PILC mailing list at pilc@grc.nasa.gov. Distribution of this memo is unlimited. 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.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document makes performance-related recommendations for users of network paths that traverse "very low bit-rate" links. "Very low bit-rate" implies "slower than we would like". This recommendation may be useful in any network where hosts can saturate available bandwidth, but the design space for this recommendation explicitly includes connections that traverse 56 Kb/second modem Expires May 24, 2001 [Page 1] INTERNET DRAFT PILC - Slow Links November 2000 links or 4.8 Kb/second wireless access links - both of which are widely deployed. This document discusses general-purpose mechanisms. Where application-specific mechanisms can outperform the relevant general-purpose mechanism, we point this out and explain why. This document has some recommendations in common with RFC 2689, "Providing integrated services over low-bitrate links", especially in areas like header compression. This document focuses more on traditional data applications for which "best-effort delivery" is appropriate. Changes since last draft: Slightly restructured the document in part. Editorial changes and corrections and added some new text. Expires May 24, 2001 [Page 2] INTERNET DRAFT PILC - Slow Links November 2000 1.0 Introduction The Internet protocol stack was designed to span a wide range of link speeds, and has met this design goal with only a limited number of enhancements (for example, the use of TCP window scaling as described in "TCP Extensions for High Performance" [RFC1323] for very-high-bandwidth connections). Pre-World Wide Web application protocols tended to be either interactive applications sending very little data (e.g., Telnet) or bulk transfer applications that did not require interactive response (e.g., File Transfer Protocol, Network News). The World Wide Web has given us traffic that is both interactive and at times "bulky", including images, sound, and video. The World Wide Web has also popularized the Internet, so that there is significant interest in accessing the Internet over link speeds that are much "slower" than typical office network speeds. In fact, a significant proportion of the current Internet users is connected to the Internet over a relatively slow last-hop link. In future, the number of such users is likely to increase rapidly as various mobile devices are foreseen to to be attached to the Internet over slow wireless links. In order to provide the best interactive response for these "bulky" transfers, implementors may wish to minimize the number of bits actually transmitted over these "slow" connections. There are two areas that can be considered - compressing the bits that make up the overhead associated with the connection, and compressing the bits that make up the payload being transported over the connection. In addition, implementors may wish to consider TCP receive window settings and queuing mechanisms as techniques to improve performance over low-speed links. While these techniques do not involve protocol changes, they are included in this document for completeness. 2.0 Description of Optimizations This section describes optimizations which have been suggested for use in situations where hosts can saturate their links. The next section summarizes recommendations about the use of these optimizations. 2.1 Header Compression Alternatives Mechanisms for TCP and IP header compression defined in [RFC1144, RFC2507, RFC2508, RFC2509] provide the following benefits: Expires May 24, 2001 [Page 4] INTERNET DRAFT PILC - Slow Links November 2000 - Improve interactive response time - Decrease header overhead (for a typical dialup MTU of 296 bytes, the overhead of TCP/IP headers can decrease from about 13 percent with typical 40-byte headers to 1-1.5 percent with with 3-5 byte compressed headers, for most packets). This enables use of small packets for delay sensitive low data-rate traffic and good line efficiency for bulk data even with small segment sizes (for reasons using a small MTU on slow links, see section 2.3) - Many slow links today are wireless and tend to be significantly lossy. Header compression reduces packet loss rate over lossy links (simply because shorter transmission times expose packets to fewer events that cause loss). Van Jacobson (VJ) header compression [RFC1144] describes a Proposed Standard for TCP Header compression that is widely deployed. Unfortunately it is vulnerable on lossy links, because even a single bit error results in loss of synchronization between the compressor and decompressor. It uses TCP timeouts to detect a loss of such synchronization. This may, however, result in dropping a full TCP window, waiting for a full RTO, and performing slow-start unnecessarily. In addition, VJ header compression does work in presence of IPsec [RFC2401]. A more recent header compression proposal [RFC2507] includes an explicit request for retransmission of an uncompressed packet to allow resynchronization without waiting for a TCP timeout (and executing congestion avoidance procedures). This works much better on links with lossy characteristics. [RFC1323] defines a "TCP Timestamp" option, used to prevent "wrapping" of the TCP sequence number space on high-speed links, and to improve TCP RTT estimates by providing unambiguous TCP roundtrip timings. Use of TCP timestamps prevents header compression, because the timestamps are sent as TCP options. This means that each timestamped header has TCP options that differ from the previous header, and headers with changed TCP options are always sent uncompressed. In addition, timestamps do not seem to have much of an impact on RTO estimation either [AlPa99]. Recommendation: Implement [RFC2507], in particular as it relates to IPv4 tunnels and Minimal Encapsulation for Mobile IP, as well as TCP header compression for lossy links and links that reorder packets. PPP capable devices should implement "IP Header Compression over PPP" [RFC2509]. Expires May 24, 2001 [Page 5] INTERNET DRAFT PILC - Slow Links November 2000 [RFC1144] header compression should only be enabled when operating over reliable "slow" links. Use of TCP Timestamps [RFC1323] is not recommended with these connections, because it prevents header compression and because connections traversing "slow" links do not require protection against TCP sequence-number wrapping. 2.2 Payload Compression Alternatives Compression of IP payloads is also desirable on "slow" network links. "IP Payload Compression Protocol (IPComp)" [RFC2393] defines a framework where common compression algorithms can be applied to arbitrary IP segment payloads. IP payload compression is something of a niche optimization. It is necessary because IP-level security converts IP payloads to random bitstreams, defeating commonly-deployed link-layer compression mechanisms which are faced with payloads that have no redundant "information" that can be more compactly represented. However, many IP payloads are already compressed (images, audio, video, "zipped" files being transferred), or are already encrypted above the IP layer (e.g., SSL [SSL]/TLS [RFC2246]). These payloads will not "compress" further, limiting the benefit of this optimization. For uncompressed HTTP payload types, HTTP/1.1 [RFC2616] also includes Content-Encoding and Accept-Encoding headers, supporting a variety of compression algorithms for common compressible MIME types like text/plain. This leaves only the HTTP headers themselves uncompressed. In general, application-level compression can often outperform IPComp, because of the opportunity to use compression dictionaries based on knowledge of the specific data being compressed. Extensive use of application-level compression techniques will reduce the need for IPComp, especially for WWW users. Recommendation: IPComp may optionally be implemented. 2.3 Choosing MTU Sizes There are several points to keep in mind when choosing an MTU for low-speed links. First, using a link MTU that takes more than delayed ACK timeout Expires May 24, 2001 [Page 6] INTERNET DRAFT PILC - Slow Links November 2000 (typically 200 milliseconds) to transmit will cause an ACK to be generated for every segment, rather than one per two segments as is normal with most implementations of the TCP delayed ACK algorithm. Second, "relatively large" MTUs, which take human-perceptible amounts of time to be transmitted into the network, create human-perceptible delays in other flows using the same link. [RFC1144] considers 100-200 millisecond delays as human-perceptible. The convention of 296-byte MTUs for dialup access was chosen to limit the impact of a single MTU size to be not significantly longer than 100-200 milliseconds on 9.6 Kb/second links [RFC1144]. Third, on last-hop links using a larger link MTU size, and therefore larger MSS, would allow a TCP sender to increase its congestion window faster in bytes than when using a smaller MTU size. However, with a larger MTU size the congestion window increases slower in segments than with a smaller MTU size. This, in turn, means that with larger MTU sizes the congestion window size would stay in only a few segments for much longer time and the sender is more likely to be unable to send enough segments to generate three duplicate acknowledgements and thus triggering fast retransmit/fast recovery, when a packet loss is encountered. Therefore, a smaller MTU size is better choice, especially with slow links with lossy characteristics. Finally, using a smaller MTU size also decreases the queuing delay of a TCP flow compared to use of larger MTU size with the same number of packets in a queue. This means that a TCP flow using smaller segment size and traversing a slow link is more likely to be able to inflate the congestion window (in number of segments) while experiencing the same queuing delay. If it is possible to do so, MTUs should be chosen that do not monopolize network interfaces for human-perceptible amounts of time, and implementors should not chose MTUs that will occupy a network interface for significantly more than 100-200 milliseconds. 2.4 Interactions with TCP Congestion Control [RFC2581] In many cases, TCP connections that traverse slow links have the slow link as an "access" link, with higher-speed links in use for most of the connection path. One common configuration might be a laptop computer using dialup access to a terminal server (a last-hop router), with an HTTP server on a high-speed LAN "behind" the terminal server. The HTTP server may be able to place packets on a directly-attached high-speed LAN at a higher rate than the last-hop router can forward them on the low-speed link. The consequence of this action is that Expires May 24, 2001 [Page 7] INTERNET DRAFT PILC - Slow Links November 2000 the last-hop router will be unable to buffer unlimited traffic intended for the low-speed link, and will become a point of congestion and thus begin to "drop" the excess packets. The self-clocking nature of TCP's slow start and congestion avoidance algorithms prevent this buffer overrun from continuing, but these algorithms also allow senders to "probe" for available bandwidth - cycling through an increasing rate of transmission until loss occurs, followed by a dramatic (50-percent) drop in transmission rate. This happens when a host directly connected to a low-speed link offers an advertised window that is unrealistically large for the low-speed link. The peer host continues to probe for available bandwidth, trying to fill the advertised window, until packet loss occurs. The same problem also exists when a sending host is directly connected to a slow link as most slow links have some local buffer in the link interface. This link interface buffer is subject to overflow exactly in the same way. Smaller the number of buffers in the last-hop router is, earlier it becomes congested even with a single TCP flow. In addition, the most important responsibility of the router buffers is to absorb data bursts. Too small number of buffers, like only three buffers per outbound link as described in [RFC2416], become full very easily and are unlikely to absorb even very a small burst. On the other hand, a larger number of router buffers leads to longer queuing delays but the buffers are still likely to become (almost) full due to nature of TCP behavior. Therefore, it is essential to have normally-small queues in routers. In order to achieve this it is recommended [RFC2309] that an active queue management mechanism, like Random Early Detection (RED) [RED93], should be implemented in all Internet routers, including the last-hop routers in front of a slow link. It should also be noted that RED requires a reasonable number of router buffers to work properly. (In addition, on a last-hop router towards a slow link the appropriate parameters of RED are likely to deviate from the defaults recommended. Active queue management mechanism do not eliminate packet drops but, instead, drop packets at earlier stage to solve the full-queues problem for flows that are responsive to packet drops as congestion signal. Hosts that are directly connected to low-speed links may limit the receive windows they advertise in order to lower or eliminate the number of packet drops in a last-hop router. This recommendation takes two forms: - Modern operating systems use relatively large default TCP receive buffers, in order to maximize throughput on high-speed links. Users should be able to choose the default receive window size in use - typically a system-wide parameter. (This "choice" may be as simple as "dial-up access/LAN access" on a dialog box - this would Expires May 24, 2001 [Page 8] INTERNET DRAFT PILC - Slow Links November 2000 accomodate many environments without requiring hand-tuning by experienced network engineers). - Application developers should not attempt to manually manage network bandwidth using socket buffer sizes. Only in very rare circumstances will an application actually know both the bandwidth and delay of a path and be able to choose a suitably low (or high) value for the socket buffer size to obtain good network performance. This recommendation is not a general solution for any network path that might involve a slow link. Instead, this recommendation is applicable in environments where the host "knows" it is always connected to other hosts via "slow links". For hosts that may connect to other host over a variety of links (e.g., dial-up laptop computers with LAN-connected docking stations), buffer auto-tuning for the receive buffer is a more reasonable recommendation, and is discussed below. 2.5 TCP Buffer Auto-tuning [SMM98] recognizes a tension between the desire to allocate "large" TCP buffers, so that network paths are fully utilized, and a desire to limit the amount of memory dedicated to TCP buffers, in order to efficiently support large numbers of connections to hosts over network paths that may vary by six orders of magnitude. The technique proposed is to dynamically allocate TCP buffers, based on the current congestion window, rather than attempting to preallocate TCP buffers without any knowledge of the network path. This proposal results in receive buffers that are appropriate for the window sizes in use, and send buffers large enough to contain two windows of segments, so that SACK and fast recovery can can recover losses without "stalling" the connection. While most of the motivation for this proposal is given from a server's perspective, hosts that connect using multiple interfaces with markedly-different link speeds may also find this kind of technique useful. This is true in particular with slow links, which are likely to dominate the end-to-end RTT. If the host is connected only via a single slow link interface at a time, it is fairly easy to (dynamically) adjust the receive window (and thus the advertised window) to a value appropriate for the slow last-hop link with known bandwidth and delay characteristics. Expires May 24, 2001 [Page 9] INTERNET DRAFT PILC - Slow Links November 2000 3.0 Summary of Recommended Optimizations This section summarizes our recommendations regarding the previous standards-track mechanisms, for end nodes that are capable of saturating available bandwidth. Header compression should be implemented. [RFC1144] header compression can be enabled over robust network connections. [RFC2507] should be used over network connections that are expected to experience loss due to corruption as well as loss due to congestion. [RFC1323] TCP timestamps must be turned off to allow header compression. IP Payload Compression [RFC2393] should be implemented, although compression at higher layers of the protocol stack (examples: [RFC 2616, HTTP-NG]) may make this mechanism less useful. For HTTP/1.1 environments, [RFC2616] payload compression should be implemented and should be used for payloads that are not already compressed. Implementors should choose MTUs that don't monopolize network interfaces for more than 100-200 milliseconds, in order to limit the impact of a single connection on all other connections sharing the network interface. Use of active queuue management is recommended on last-hop routers that provode Internet access to host behind a slow link. In addition, number of router buffers per slow link should be large enough. Implementors should consider the possibility that a host will be directly connected to a low-speed link when choosing default TCP receive window sizes. Application developers should consider the possibility that an application will be used on a host that is directly connected to a low-speed link, before increasing the TCP receive window size beyond the default for TCP connections used by this application. All of the mechanisms described above are stable standards-track RFCs (at Proposed Standard status, as of this writing). In addition, implementors may wish to consider TCP buffer auto-tuning, especially when the host system is likely to be used with a wide variety of access link speeds. This is not a standards- track TCP mechanism but, as it is an operating system implementation isssue, it does not need to be standardized. Expires May 24, 2001 [Page 10] INTERNET DRAFT PILC - Slow Links November 2000 In addition, researchers may wish to experiment with injecting new traffic into the network when duplicate acknowledgements are being received to stimulate fast retransmit when not enough segments are in the pipe, as described in [TCPB98] and [TCPF98]. This is not a standards-track TCP mechanism. Of the above mechanisms, only Header Compression (for IP and TCP) ceases to work in the presence of end-to-end IPSEC. 4.0 Topics For Further Work In addition to the standards-track mechanisms discussed above, there are still opportunities to improve performance over low-speed links. "Sending fewer bits" is an obvious response to slow link speeds. The now-defunct HTTP-NG proposal [HTTP-NG] replaced the text-based HTTP header representation with a binary representation for compactness. Since HTTP-NG isn't moving forward and HTTP/1.1 isn't being enhanced to include a more compact HTTP header representation, the Wireless Application Protocol (WAP) Forum has proposed mechanisms like the Wireless Session Prococol [WSP], which does a binary encoding of HTTP/1.1 functionality. It would be nice to agree on a more compact HTTP header representation that will be used by all WWW communities, not only the wireless WAN community. Very slow link speeds usually mean that TCP connections are likely to have small congestion windows, interacting badly with Fast Retransmit/Fast Recovery. TCPs recover without full RTO timeouts when connections experience losses, as long as the window is large enough to generate three duplicate acknowledgements. More aggressive introduction of new segments when duplicate acknowledgements are being received may provide faster recovery when the congestion window sizes are small. (See Appendix A for details on existing proposals like [TCPB98] and [TCPF98].) We note that TCP options which change from segment to segment effectively disable header compression schemes deployed today, because there's no way to indicate that some fields in the header are unchanged from the previous segment, while other fields are not. It would be nice to be able to use timestamps with header compression. 5.0 Acknowledgements This recommendation has grown out of "Long Thin Networks" [RFC2757], which in turn benefitted from work done in the IETF TCPSAT working group. Expires May 24, 2001 [Page 11] INTERNET DRAFT PILC - Slow Links November 2000 6.0 References [AlPa99] Mark Allman and Vern Paxson, "On Estimating End-to-End Network Path Properties", in ACM SIGCOMM 99 Proceedings, 1999. [SMM98] Jeffrey Semke, Matthew Mathis, and Jamshid Mahdavi, "Automatic TCP Buffer Tuning", 1998. Available from http://www.acm.org/sigcomm/sigcomm98/tp/abs_26.html. [HTTP-NG] H. Frystyk Nielsen, Mike Spreitzer, Bill Janssen, Jim Gettys, "HTTP-NG Overview", draft-frystyk-httpng-overview-00.txt, November 17, 1998, expired, but also available from http://www.w3.org/Protocols/HTTP-NG/1998/11/. [PAX97] Paxson, V., "End-to-End Internet Packet Dynamics", 1997, in SIGCOMM 97 Proceedings, available as http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-97.html [RED93] Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, pp. 397-413. Also available from http://ftp.ee.lbl.gov/floyd/red.html. [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links," RFC 1144, February 1990. (Proposed Standard) [RFC1323] Jacobson, V., Braden, R., Borman, D., "TCP Extensions for High Performance", RFC 1323, May 1992. (Proposed Standard) [RFC2246] T. Dierks, C. Allen, "The TLS Protocol: Version 1.0", RFC 2246, January 1999. (Proposed Standard) [RFC2309] B. Braden et. al., "Recommendations on Queue Management and Congestion Avoidance in the Internet," RFC 2309, April 1998. (Informational) [RFC2393] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload Compression Protocol (IPComp)," RFC 2393, December 1998. (Proposed Standard) [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol," RFC 2401, November 1998. [RFC2416] T. Shepard, C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998. [RFC2507] Mikael Degermark, Bjorn Nordgren, Stephen Pink. "IP Expires May 24, 2001 [Page 12] INTERNET DRAFT PILC - Slow Links November 2000 Header Compression," RFC 2507, February 1999. (Proposed Standard) [RFC2508] S. Casner, V. Jacobson. "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links," RFC 2508, February 1999. (Proposed Standard) [RFC2509] Mathias Engan, S. Casner, C. Bormann. "IP Header Compression over PPP," RFC 2509, February 1999. (Proposed Standard) [RFC2581] M. Allman, V. Paxson, W. Stevens, "TCP Congestion Control, RFC 2581, April 1999. (Proposed Standard) [RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, Masinter, P. Leach, T. Berners-Lee. "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. (Draft Standard) [RFC2757] G. Montenegro, S. Dawkins, M. Kojo, V. Magret, N. Vaidya, "Long Thin Networks", RFC 2757, January 2000. (Informational) [SACK-EXT] Sally Floyd, Jamshid Mahdavi, Matt Mathis, Matthew Podolsky, Allyn Romanow, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", August 1999. Work in progress, available at http://www.ietf.org/internet-drafts/draft-floyd-sack-00.txt [SSL] Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol: Version 3.0, March 1996 (Expired Internet-Draft, available from http://home.netscape.com/eng/ssl3/ssl-toc.html) [TCPB98] Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan Seshan, Mark Stemm, Randy H. Katz, "TCP Behavior of a Busy Internet Server: Analysis and Improvements", IEEE Infocom, March 1998. Available from: http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.gz [TCPF98] Dong Lin and H.T. Kung, "TCP Fast Recovery Strategies: Analysis and Improvements", IEEE Infocom, March 1998. Available from: http://www.eecs.harvard.edu/networking/papers/ infocom-tcp-final-198.pdf [WSP] Wireless Application Protocol Forum, "Wireless Session Protocol Specification", Version 5, November 1999. Available from Expires May 24, 2001 [Page 13] INTERNET DRAFT PILC - Slow Links November 2000 http://www1.wapforum.org/tech/documents/SPEC-WSP-19991105.pdf Authors' addresses Questions about this document may be directed to: Spencer Dawkins Fujitsu Network Communications 2801 Telecom Parkway Richardson, Texas 75082 Voice: +1-972-479-3782 E-Mail: spencer.dawkins@fnc.fujitsu.com Gabriel E. Montenegro Sun Labs Networking and Security Group Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View, California 94303 Voice: +1-650-786-6288 Fax: +1-650-786-6445 E-Mail: gab@sun.com Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland Voice: +358-9-1914-4179 Fax: +358-9-1914-4441 E-Mail: kojo@cs.helsinki.fi Expires May 24, 2001 [Page 14] INTERNET DRAFT PILC - Slow Links November 2000 Vincent Magret Corporate Research Center Alcatel Network Systems, Inc 1201 Campbell Mail stop 446-310 Richardson Texas 75081 USA M/S 446-310 Voice: +1-972-996-2625 Fax: +1-972-996-5902 E-mail: vincent.magret@aud.alcatel.com Appendix A Small Window Effects (Experimental) If a TCP connection stabilizes with a congestion window of only a few segments (as would be expected on a "slow" link), the sender isn't sending enough segments to generate three duplicate acknowledgements, triggering fast retransmit/fast recovery. This means that a retranmission timeout is required to repair the loss - dropping the TCP connection to a congestion window with only one segment. [TCPB98] and [TCPF98] observe that (in studies of network trace datasets) it is relatively common for TCP retransmission timeouts to occur even when some duplicate acknowledgements are being sent. The challenge is to use these duplicate acknowledgements to trigger fast retransmit/fast recovery without injecting traffic into the network unnecessarily - and especially not injecting traffic in ways that will result in instability. In these situations, it may be desireable to trigger fast retransmit/fast recovery more aggressively. [TCPB98] and [TCPF98] suggest sending a new segment when the first and second duplicate acknowledgements are received, so that the receiver will continue to generate duplicate acknowledgements until the TCP retransmit threshhold is reached, triggering fast retransmit/fast recovery. We note that a maximum of two additional new segments will be sent before the receiver sends either an acknowledgement advancing the window or two additional duplicate acknowledgements, triggering fast retransmit/fast recovery, and that these new segments will be acknowledgement-clocked, not back-to-back. The alternative, lowering the fast retransmit/fast recovery threshold, is more likely to inject unnecessary retransmissions when the duplicate acknowledgements are the result of out-of-order Expires May 24, 2001 [Page 15] INTERNET DRAFT PILC - Slow Links November 2000 delivery to the far-end TCP [PAX97]. Expires May 24, 2001 [Page 16] INTERNET DRAFT PILC - Slow Links November 2000 Table of Contents 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.0 Description of Optimizations . . . . . . . . . . . . . . . . . . 3 2.1 Header Compression Alternatives . . . . . . . . . . . . . . 3 2.2 Payload Compression Alternatives . . . . . . . . . . . . . 6 2.3 Choosing MTU sizes . . . . . . . . . . . . . . . . . . . . 6 2.4 Interactions with TCP Congestion Control [RFC2581] . . . . 7 2.5 TCP Buffer Auto-tuning . . . . . . . . . . . . . . . . . . 9 3.0 Summary of Recommended Optimizations . . . . . . . . . . . . . . 10 4.0 Topics For Further Work . . . . . . . . . . . . . . . . . . . . 11 5.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 6.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' addresses . . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A Small Window Effects (Experimental) . . . . . . . . . . . 15 Expires May 24, 2001 [Page 3]