rfc3155.txt

RFC 的详细文档！

Network Working Group                                         S. Dawkins
Request for Comments: 3155                                 G. Montenegro
BCP: 50                                                          M. Kojo
Category: Best Current Practice                                V. Magret
                                                               N. Vaidya
                                                             August 2001


        End-to-end Performance Implications of Links with Errors

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 discusses the specific TCP mechanisms that are
   problematic in environments with high uncorrected error rates, and
   discusses what can be done to mitigate the problems without
   introducing intermediate devices into the connection.

Table of Contents

   1.0 Introduction .............................................    2
      1.1 Should you be reading this recommendation?  ...........    3
      1.2 Relationship of this recommendation to PEPs ...........    4
      1.3 Relationship of this recommendation to Link Layer
          Mechanisms.............................................    4
   2.0 Errors and Interactions with TCP Mechanisms ..............    5
      2.1 Slow Start and Congestion Avoidance [RFC2581] .........    5
      2.2 Fast Retransmit and Fast Recovery [RFC2581] ...........    6
      2.3 Selective Acknowledgements [RFC2018, RFC2883] .........    7
   3.0 Summary of Recommendations ...............................    8
   4.0 Topics For Further Work ..................................    9
      4.1 Achieving, and maintaining, large windows .............   10
   5.0 Security Considerations ..................................   11
   6.0 IANA Considerations ......................................   11
   7.0 Acknowledgements .........................................   11
   References ...................................................   11
   Authors' Addresses ...........................................   14
   Full Copyright Statement .....................................   16




Dawkins, et al.          Best Current Practice                  [Page 1]

RFC 3155                PILC - Links with Errors             August 2001


1.0 Introduction

   The rapidly-growing Internet is being accessed by an increasingly
   wide range of devices over an increasingly wide variety of links.  At
   least some of these links do not provide the degree of reliability
   that hosts expect, and this expansion into unreliable links causes
   some Internet protocols, especially TCP [RFC793], to perform poorly.

   Specifically, TCP congestion control [RFC2581], while appropriate for
   connections that lose traffic primarily because of congestion and
   buffer exhaustion, interacts badly with uncorrected errors when TCP
   connections traverse links with high uncorrected error rates.  The
   result is that sending TCPs may spend an excessive amount of time
   waiting for acknowledgement that do not arrive, and then, although
   these losses are not due to congestion-related buffer exhaustion, the
   sending TCP transmits at substantially reduced traffic levels as it
   probes the network to determine "safe" traffic levels.

   This document does not address issues with other transport protocols,
   for example, UDP.

   Congestion avoidance in the Internet is based on an assumption that
   most packet losses are due to congestion.  TCP's congestion avoidance
   strategy treats the absence of acknowledgement as a congestion
   signal.  This has worked well since it was introduced in 1988 [VJ-
   DCAC], because most links and subnets have relatively low error rates
   in normal operation, and congestion is the primary cause of loss in
   these environments.  However, links and subnets that do not enjoy low
   uncorrected error rates are becoming more prevalent in parts of the
   Internet.  In particular, these include terrestrial and satellite
   wireless links.  Users relying on traffic traversing these links may
   see poor performance because their TCP connections are spending
   excessive time in congestion avoidance and/or slow start procedures
   triggered by packet losses due to transmission errors.

   The recommendations in this document aim at improving utilization of
   available path capacity over such high error-rate links in ways that
   do not threaten the stability of the Internet.

   Applications use TCP in very different ways, and these have
   interactions with TCP's behavior [RFC2861].  Nevertheless, it is
   possible to make some basic assumptions about TCP flows.
   Accordingly, the mechanisms discussed here are applicable to all uses
   of TCP, albeit in varying degrees according to different scenarios
   (as noted where appropriate).






Dawkins, et al.          Best Current Practice                  [Page 2]

RFC 3155                PILC - Links with Errors             August 2001


   This recommendation is based on the explicit assumption that major
   changes to the entire installed base of routers and hosts are not a
   practical possibility.  This constrains any changes to hosts that are
   directly affected by errored links.

1.1 Should you be reading this recommendation?

   All known subnetwork technologies provide an "imperfect" subnetwork
   service - the bit error rate is non-zero.  But there's no obvious way
   for end stations to tell the difference between packets discarded due
   to congestion and losses due to transmission errors.

   If a directly-attached subnetwork is reporting transmission errors to
   a host, these reports matter, but we can't rely on explicit
   transmission error reports to both hosts.

   Another way of deciding if a subnetwork should be considered to have
   a "high error rate" is by appealing to mathematics.

   An approximate formula for the TCP Reno response function is given in
   [PFTK98]:

                                s
   T = --------------------------------------------------
       RTT*sqrt(2p/3) + tRTO*(3*sqrt(3p/8))*p*(1 + 32p**2)

   where

       T = the sending rate in bytes per second
       s = the packet size in bytes
       RTT = round-trip time in seconds
       tRTO = TCP retransmit timeout value in seconds
       p = steady-state packet loss rate

   If one plugs in an observed packet loss rate, does the math and then
   sees predicted bandwidth utilization that is greater than the link
   speed, the connection will not benefit from recommendations in this
   document, because the level of packet losses being encountered won't
   affect the ability of TCP to utilize the link.  If, however, the
   predicted bandwidth is less than the link speed, packet losses are
   affecting the ability of TCP to utilize the link.

   If further investigation reveals a subnetwork with significant
   transmission error rates, the recommendations in this document will
   improve the ability of TCP to utilize the link.






Dawkins, et al.          Best Current Practice                  [Page 3]

RFC 3155                PILC - Links with Errors             August 2001


   A few caveats are in order, when doing this calculation:

   (1)   the RTT is the end-to-end RTT, not the link RTT.
   (2)   Max(1.0, 4*RTT) can be substituted as a simplification for
         tRTO.
   (3)   losses may be bursty - a loss rate measured over an interval
         that includes multiple bursty loss events may understate the
         impact of these loss events on the sending rate.

1.2 Relationship of this recommendation to PEPs

   This document discusses end-to-end mechanisms that do not require
   TCP-level awareness by intermediate nodes.  This places severe
   limitations on what the end nodes can know about the nature of losses
   that are occurring between the end nodes.  Attempts to apply
   heuristics to distinguish between congestion and transmission error
   have not been successful [BV97, BV98, BV98a].  This restriction is
   relaxed in an informational document on Performance Enhancing Proxies
   (PEPs) [RFC3135]. Because PEPs can be placed on boundaries where
   network characteristics change dramatically, PEPs have an additional
   opportunity to improve performance over links with uncorrected
   errors.

   However, generalized use of PEPs contravenes the end-to-end principle
   and is highly undesirable given their deleterious implications, which
   include the following: lack of fate sharing (a PEP adds a third point
   of failure besides the endpoints themselves), end-to-end reliability
   and diagnostics, preventing end-to-end security (particularly network
   layer security such as IPsec), mobility (handoffs are much more
   complex because state must be transferred), asymmetric routing (PEPs
   typically require being on both the forward and reverse paths of a
   connection), scalability (PEPs add more state to maintain), QoS
   transparency and guarantees.

   Not every type of PEP has all the drawbacks listed above.
   Nevertheless, the use of PEPs may have very serious consequences
   which must be weighed carefully.

1.3 Relationship of this recommendation to Link Layer Mechanisms

   This recommendation is for use with TCP over subnetwork technologies
   (link layers) that have already been deployed.  Subnetworks that are
   intended to carry Internet protocols, but have not been completely
   specified are the subject of a best common practices (BCP) document
   which has been developed or is under development by the Performance






Dawkins, et al.          Best Current Practice                  [Page 4]

RFC 3155                PILC - Links with Errors             August 2001


   Implications of Link Characteristics WG (PILC) [PILC-WEB].  This last
   document is aimed at designers who still have the opportunity to
   reduce the number of uncorrected errors TCP will encounter.

2.0 Errors and Interactions with TCP Mechanisms

   A TCP sender adapts its use of network path capacity based on
   feedback from the TCP receiver.  As TCP is not able to distinguish
   between losses due to congestion and losses due to uncorrected
   errors, it is not able to accurately determine available path
   capacity in the presence of significant uncorrected errors.

2.1 Slow Start and Congestion Avoidance [RFC2581]

   Slow Start and Congestion Avoidance [RFC2581] are essential to the
   current stability of the Internet.  These mechanisms were designed to
   accommodate networks that do not provide explicit congestion
   notification.  Although experimental mechanisms such as [RFC2481] are
   moving in the direction of explicit congestion notification, the
   effect of ECN on ECN-aware TCPs is essentially the same as the effect
   of implicit congestion notification through congestion-related loss,
   except that ECN provides this notification before packets are lost,
   and must then be retransmitted.

   TCP connections experiencing high error rates on their paths interact
   badly with Slow Start and with Congestion Avoidance, because high
   error rates make the interpretation of losses ambiguous - the sender
   cannot know whether detected losses are due to congestion or to data
   corruption.  TCP makes the "safe" choice and assumes that the losses
   are due to congestion.

      -  Whenever sending TCPs receive three out-of-order
         acknowledgement, they assume the network is mildly congested
         and invoke fast retransmit/fast recovery (described below).

      -  Whenever TCP's retransmission timer expires, the sender assumes
         that the network is congested and invokes slow start.

      -  Less-reliable link layers often use small link MTUs.  This
         slows the rate of increase in the sender's window size during
         slow start, because the sender's window is increased in units
         of segments.  Small link MTUs alone don't improve reliability.
         Path MTU discovery [RFC1191] must also be used to prevent
         fragmentation.  Path MTU discovery allows the most rapid
         opening of the sender's window size during slow start, but a
         number of round trips may still be required to open the window
         completely.




Dawkins, et al.          Best Current Practice                  [Page 5]

RFC 3155                PILC - Links with Errors             August 2001


   Recommendation: Any standards-conformant TCP will implement Slow
   Start and Congestion Avoidance, which are MUSTs in STD 3 [RFC1122].
   Recommendations in this document will not interfere with these
   mechanisms.

2.2 Fast Retransmit and Fast Recovery [RFC2581]

   TCP provides reliable delivery of data as a byte-stream to an
   application, so that when a segment is lost (whether due to either
   congestion or transmission loss), the receiver TCP implementation
   must wait to deliver data to the receiving application until the
   missing data is received.  The receiver TCP implementation detects
   missing segments by segments arriving with out-of-order sequence
   numbers.