rfc3150.txt

RFC 的详细文档！

Network Working Group                                         S. Dawkins
Request for Comments: 3150                                 G. Montenegro
BCP: 48                                                         M . Kojo
Category: Best Current Practice                                V. Magret
                                                               July 2001


           End-to-end Performance Implications of Slow Links

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

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

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
   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.











Dawkins, et al.          Best Current Practice                  [Page 1]

RFC 3150                   PILC - Slow Links                   July 2001


Table of Contents

   1.0 Introduction .................................................  2
   2.0 Description of Optimizations .................................  3
           2.1 Header Compression Alternatives ......................  3
           2.2 Payload Compression Alternatives .....................  5
           2.3 Choosing MTU sizes ...................................  5
           2.4 Interactions with TCP Congestion Control [RFC2581] ...  6
           2.5 TCP Buffer Auto-tuning ...............................  9
           2.6 Small Window Effects ................................. 10
   3.0 Summary of Recommended Optimizations ......................... 10
   4.0 Topics For Further Work ...................................... 12
   5.0 Security Considerations ...................................... 12
   6.0 IANA Considerations .......................................... 13
   7.0 Acknowledgements ............................................. 13
   8.0 References ................................................... 13
   Authors' Addresses ............................................... 16
   Full Copyright Statement ......................................... 17

1.0 Introduction

   The Internet protocol stack was designed to operate in 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 often "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





Dawkins, et al.          Best Current Practice                  [Page 2]

RFC 3150                   PILC - Slow Links                   July 2001


   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, RFC3095] provide the following benefits:

      -  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 to use 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).

   [RFC1144] header compression is 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, but these errors
   result in loss of data (up to a full TCP window), delay of a full
   RTO, and unnecessary slow-start.







Dawkins, et al.          Best Current Practice                  [Page 3]

RFC 3150                   PILC - Slow Links                   July 2001


   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.

   The above scheme ceases to perform well under conditions as extreme
   as those of many cellular links (error conditions of 1e-3 or 1e-2 and
   round trip times over 100 ms.).  For these cases, the 'Robust Header
   Compression' working group has developed ROHC [RFC3095].  Extensions
   of ROHC to support compression of TCP headers are also under
   development.

   [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 [AlPa99].

   Nevertheless, the ROHC working group is developing schemes to
   compress TCP headers, including options such as timestamps and
   selective acknowledgements.

   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].  Robust Header Compression [RFC3095] is recommended for
   extremely slow links with very high error rates (see above), but
   implementors should judge if its complexity is justified (perhaps by
   the cost of the radio frequency resources).

   [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 complicates header compression.  Even though
   the Robust Header Compression (ROHC) working group is developing
   specifications to remedy this, those mechanisms are not yet fully
   developed nor deployed, and may not be generally justifiable.
   Furthermore, connections traversing "slow" links do not require
   protection against TCP sequence-number wrapping.





Dawkins, et al.          Best Current Practice                  [Page 4]

RFC 3150                   PILC - Slow Links                   July 2001


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, if a full-length MTU occupies a link for longer than the
   delayed ACK timeout (typically 200 milliseconds, but may be up to 500
   milliseconds), this timeout will cause an ACK to be generated for
   every segment, rather than every second segment, as occurs with most
   implementations of the TCP delayed ACK algorithm.







Dawkins, et al.          Best Current Practice                  [Page 5]

RFC 3150                   PILC - Slow Links                   July 2001


   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
   choosing 296-byte MTUs (with header compression enabled) for dialup
   access is a compromise that limits the maximum link occupancy delay
   with full-length MTUs close to 200 milliseconds on 9.6 Kb/second
   links.

   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 (and a
   smaller MSS).  However, with a smaller MTU size, and a smaller MSS
   size, the congestion window, when measured in segments, increases
   more quickly than it would with a larger MSS size.  Connections using
   smaller MSS sizes are more likely to be able to send enough segments
   to generate three duplicate acknowledgements, triggering fast
   retransmit/fast recovery when packet losses are encountered.  Hence,
   a smaller MTU size is useful for slow links with lossy
   characteristics.

   Fourth, using a smaller MTU size also decreases the queuing delay of
   a TCP flow (and thereby RTT) compared to use of larger MTU size with
   the same number of packets in a queue.  This means that a TCP flow
   using a smaller segment size and traversing a slow link is able to
   inflate the congestion window (in number of segments) to a larger
   value while experiencing the same queuing delay.

   Finally, some networks charge for traffic on a per-packet basis, not
   on a per-kilobyte basis.  In these cases, connections using a larger
   MTU may be charged less than connections transferring the same number
   of bytes using a smaller MTU.