rfc2525.txt

RFC 的详细文档！

   Description
      RFC 1122 section 4.2.2.15 states that TCP MUST implement
      Jacobson's "congestion avoidance" algorithm [Jacobson88], which
      calls for increasing the congestion window, cwnd, by:

           MSS * MSS / cwnd

      for each ACK received for new data [RFC2001].  This has the effect
      of increasing cwnd by approximately one segment in each round trip
      time.

      Some TCP implementations add an additional fraction of a segment
      (typically MSS/8) to cwnd for each ACK received for new data
      [Stevens94, Wright95]:

           (MSS * MSS / cwnd) + MSS/8

      These implementations exhibit "Extra additive constant in
      congestion avoidance".

   Significance
      May be detrimental to performance even in completely uncongested
      environments (see Implications).

      In congested environments, may also be detrimental to the
      performance of other connections.






Paxson, et. al.              Informational                     [Page 17]

RFC 2525              TCP Implementation Problems             March 1999


   Implications
      The extra additive term allows a TCP to more aggressively open its
      congestion window (quadratic rather than linear increase).  For
      congested networks, this can increase the loss rate experienced by
      all connections sharing a bottleneck with the aggressive TCP.

      However, even for completely uncongested networks, the extra
      additive term can lead to diminished performance, as follows.  In
      congestion avoidance, a TCP sender probes the network path to
      determine its available capacity, which often equates to the
      number of buffers available at a bottleneck link.  With linear
      congestion avoidance, the TCP only probes for sufficient capacity
      (buffer) to hold one extra packet per RTT.

      Thus, when it exceeds the available capacity, generally only one
      packet will be lost (since on the previous RTT it already found
      that the path could sustain a window with one less packet in
      flight).  If the congestion window is sufficiently large, then the
      TCP will recover from this single loss using fast retransmission
      and avoid an expensive (in terms of performance) retransmission
      timeout.

      However, when the additional additive term is used, then cwnd can
      increase by more than one packet per RTT, in which case the TCP
      probes more aggressively.  If in the previous RTT it had reached
      the available capacity of the path, then the excess due to the
      extra increase will again be lost, but now this will result in
      multiple losses from the flight instead of a single loss.  TCPs
      that do not utilize SACK [RFC2018] generally will not recover from
      multiple losses without incurring a retransmission timeout
      [Fall96,Hoe96], significantly diminishing performance.

   Relevant RFCs
      RFC 1122 requires use of the "congestion avoidance" algorithm.
      RFC 2001 outlines the fast retransmit/fast recovery algorithms.
      RFC 2018 discusses the SACK option.

   Trace file demonstrating it
      Recorded using tcpdump running on the same FDDI LAN as host A.
      Host A is the sender and host B is the receiver.  The connection
      establishment specified an MSS of 4,312 bytes and a window scale
      factor of 4.  We omit the establishment and the first 2.5 MB of
      data transfer, as the problem is best demonstrated when the window
      has grown to a large value.  At the beginning of the trace
      excerpt, the congestion window is 31 packets.  The connection is
      never receiver-window limited, so we omit window advertisements
      from the trace for clarity.




Paxson, et. al.              Informational                     [Page 18]

RFC 2525              TCP Implementation Problems             March 1999


   11:42:07.697951 B > A: . ack 2383006
   11:42:07.699388 A > B: . 2508054:2512366(4312)
   11:42:07.699962 A > B: . 2512366:2516678(4312)
   11:42:07.700012 B > A: . ack 2391630
   11:42:07.701081 A > B: . 2516678:2520990(4312)
   11:42:07.701656 A > B: . 2520990:2525302(4312)
   11:42:07.701739 B > A: . ack 2400254
   11:42:07.702685 A > B: . 2525302:2529614(4312)
   11:42:07.703257 A > B: . 2529614:2533926(4312)
   11:42:07.703295 B > A: . ack 2408878
   11:42:07.704414 A > B: . 2533926:2538238(4312)
   11:42:07.704989 A > B: . 2538238:2542550(4312)
   11:42:07.705040 B > A: . ack 2417502
   11:42:07.705935 A > B: . 2542550:2546862(4312)
   11:42:07.706506 A > B: . 2546862:2551174(4312)
   11:42:07.706544 B > A: . ack 2426126
   11:42:07.707480 A > B: . 2551174:2555486(4312)
   11:42:07.708051 A > B: . 2555486:2559798(4312)
   11:42:07.708088 B > A: . ack 2434750
   11:42:07.709030 A > B: . 2559798:2564110(4312)
   11:42:07.709604 A > B: . 2564110:2568422(4312)
   11:42:07.710175 A > B: . 2568422:2572734(4312) *

   11:42:07.710215 B > A: . ack 2443374
   11:42:07.710799 A > B: . 2572734:2577046(4312)
   11:42:07.711368 A > B: . 2577046:2581358(4312)
   11:42:07.711405 B > A: . ack 2451998
   11:42:07.712323 A > B: . 2581358:2585670(4312)
   11:42:07.712898 A > B: . 2585670:2589982(4312)
   11:42:07.712938 B > A: . ack 2460622
   11:42:07.713926 A > B: . 2589982:2594294(4312)
   11:42:07.714501 A > B: . 2594294:2598606(4312)
   11:42:07.714547 B > A: . ack 2469246
   11:42:07.715747 A > B: . 2598606:2602918(4312)
   11:42:07.716287 A > B: . 2602918:2607230(4312)
   11:42:07.716328 B > A: . ack 2477870
   11:42:07.717146 A > B: . 2607230:2611542(4312)
   11:42:07.717717 A > B: . 2611542:2615854(4312)
   11:42:07.717762 B > A: . ack 2486494
   11:42:07.718754 A > B: . 2615854:2620166(4312)
   11:42:07.719331 A > B: . 2620166:2624478(4312)
   11:42:07.719906 A > B: . 2624478:2628790(4312) **

   11:42:07.719958 B > A: . ack 2495118
   11:42:07.720500 A > B: . 2628790:2633102(4312)
   11:42:07.721080 A > B: . 2633102:2637414(4312)
   11:42:07.721739 B > A: . ack 2503742
   11:42:07.722348 A > B: . 2637414:2641726(4312)



Paxson, et. al.              Informational                     [Page 19]

RFC 2525              TCP Implementation Problems             March 1999


   11:42:07.722918 A > B: . 2641726:2646038(4312)
   11:42:07.769248 B > A: . ack 2512366

      The receiver's acknowledgment policy is one ACK per two packets
      received.  Thus, for each ACK arriving at host A, two new packets
      are sent, except when cwnd increases due to congestion avoidance,
      in which case three new packets are sent.

      With an ack-every-two-packets policy, cwnd should only increase
      one MSS per 2 RTT.  However, at the point marked "*" the window
      increases after 7 ACKs have arrived, and then again at "**" after
      6 more ACKs.

      While we do not have space to show the effect, this trace suffered
      from repeated timeout retransmissions due to multiple packet
      losses during a single RTT.

   Trace file demonstrating correct behavior
      Made using the same host and tracing setup as above, except now
      A's TCP has been modified to remove the MSS/8 additive constant.
      Tcpdump reported 77 packet drops; the excerpt below is fully
      self-consistent so it is unlikely that any of these occurred
      during the excerpt.

      We again begin when cwnd is 31 packets (this occurs significantly
      later in the trace, because the congestion avoidance is now less
      aggressive with opening the window).

   14:22:21.236757 B > A: . ack 5194679
   14:22:21.238192 A > B: . 5319727:5324039(4312)
   14:22:21.238770 A > B: . 5324039:5328351(4312)
   14:22:21.238821 B > A: . ack 5203303
   14:22:21.240158 A > B: . 5328351:5332663(4312)
   14:22:21.240738 A > B: . 5332663:5336975(4312)
   14:22:21.270422 B > A: . ack 5211927
   14:22:21.271883 A > B: . 5336975:5341287(4312)
   14:22:21.272458 A > B: . 5341287:5345599(4312)
   14:22:21.279099 B > A: . ack 5220551
   14:22:21.280539 A > B: . 5345599:5349911(4312)
   14:22:21.281118 A > B: . 5349911:5354223(4312)
   14:22:21.281183 B > A: . ack 5229175
   14:22:21.282348 A > B: . 5354223:5358535(4312)
   14:22:21.283029 A > B: . 5358535:5362847(4312)
   14:22:21.283089 B > A: . ack 5237799
   14:22:21.284213 A > B: . 5362847:5367159(4312)
   14:22:21.284779 A > B: . 5367159:5371471(4312)
   14:22:21.285976 B > A: . ack 5246423
   14:22:21.287465 A > B: . 5371471:5375783(4312)



Paxson, et. al.              Informational                     [Page 20]

RFC 2525              TCP Implementation Problems             March 1999


   14:22:21.288036 A > B: . 5375783:5380095(4312)
   14:22:21.288073 B > A: . ack 5255047
   14:22:21.289155 A > B: . 5380095:5384407(4312)
   14:22:21.289725 A > B: . 5384407:5388719(4312)
   14:22:21.289762 B > A: . ack 5263671
   14:22:21.291090 A > B: . 5388719:5393031(4312)
   14:22:21.291662 A > B: . 5393031:5397343(4312)
   14:22:21.291701 B > A: . ack 5272295
   14:22:21.292870 A > B: . 5397343:5401655(4312)
   14:22:21.293441 A > B: . 5401655:5405967(4312)
   14:22:21.293481 B > A: . ack 5280919
   14:22:21.294476 A > B: . 5405967:5410279(4312)
   14:22:21.295053 A > B: . 5410279:5414591(4312)
   14:22:21.295106 B > A: . ack 5289543
   14:22:21.296306 A > B: . 5414591:5418903(4312)
   14:22:21.296878 A > B: . 5418903:5423215(4312)
   14:22:21.296917 B > A: . ack 5298167
   14:22:21.297716 A > B: . 5423215:5427527(4312)
   14:22:21.298285 A > B: . 5427527:5431839(4312)
   14:22:21.298324 B > A: . ack 5306791
   14:22:21.299413 A > B: . 5431839:5436151(4312)
   14:22:21.299986 A > B: . 5436151:5440463(4312)
   14:22:21.303696 B > A: . ack 5315415
   14:22:21.305177 A > B: . 5440463:5444775(4312)
   14:22:21.305755 A > B: . 5444775:5449087(4312)
   14:22:21.308032 B > A: . ack 5324039
   14:22:21.309525 A > B: . 5449087:5453399(4312)
   14:22:21.310101 A > B: . 5453399:5457711(4312)
   14:22:21.310144 B > A: . ack 5332663           ***

   14:22:21.311615 A > B: . 5457711:5462023(4312)
   14:22:21.312198 A > B: . 5462023:5466335(4312)
   14:22:21.341876 B > A: . ack 5341287
   14:22:21.343451 A > B: . 5466335:5470647(4312)
   14:22:21.343985 A > B: . 5470647:5474959(4312)
   14:22:21.350304 B > A: . ack 5349911
   14:22:21.351852 A > B: . 5474959:5479271(4312)
   14:22:21.352430 A > B: . 5479271:5483583(4312)
   14:22:21.352484 B > A: . ack 5358535
   14:22:21.353574 A > B: . 5483583:5487895(4312)
   14:22:21.354149 A > B: . 5487895:5492207(4312)
   14:22:21.354205 B > A: . ack 5367159
   14:22:21.355467 A > B: . 5492207:5496519(4312)
   14:22:21.356039 A > B: . 5496519:5500831(4312)
   14:22:21.357361 B > A: . ack 5375783
   14:22:21.358855 A > B: . 5500831:5505143(4312)
   14:22:21.359424 A > B: . 5505143:5509455(4312)
   14:22:21.359465 B > A: . ack 5384407



Paxson, et. al.              Informational                     [Page 21]

RFC 2525              TCP Implementation Problems             March 1999


   14:22:21.360605 A > B: . 5509455:5513767(4312)
   14:22:21.361181 A > B: . 5513767:5518079(4312)
   14:22:21.361225 B > A: . ack 5393031
   14:22:21.362485 A > B: . 5518079:5522391(4312)
   14:22:21.363057 A > B: . 5522391:5526703(4312)
   14:22:21.363096 B > A: . ack 5401655
   14:22:21.364236 A > B: . 5526703:5531015(4312)
   14:22:21.364810 A > B: . 5531015:5535327(4312)
   14:22:21.364867 B > A: . ack 5410279
   14:22:21.365819 A > B: . 5535327:5539639(4312)
   14:22:21.366386 A > B: . 5539639:5543951(4312)
   14:22:21.366427 B > A: . ack 5418903
   14:22:21.367586 A > B: . 5543951:5548263(4312)
   14:22:21.368158 A > B: . 5548263:5552575(4312)
   14:22:21.368199 B > A: . ack 5427527
   14:22:21.369189 A > B: . 5552575:5556887(4312)
   14:22:21.369758 A > B: . 5556887:5561199(4312)
   14:22:21.369803 B > A: . ack 5436151
   14:22:21.370814 A > B: . 5561199:5565511(4312)
   14:22:21.371398 A > B: . 5565511:5569823(4312)
   14:22:21.375159 B > A: . ack 5444775
   14:22:21.376658 A > B: . 5569823:5574135(4312)
   14:22:21.377235 A > B: . 5574135:5578447(4312)
   14:22:21.379303 B > A: . ack 5453399
   14:22:21.380802 A > B: . 5578447:5582759(4312)
   14:22:21.381377 A > B: . 5582759:5587071(4312)
   14:22:21.381947 A > B: . 5587071:5591383(4312) ****

      "***" marks the end of the first round trip.  Note that cwnd did
      not increase (as evidenced by each ACK eliciting two new data
      packets).  Only at "****", which comes near the end of the second
      round trip, does cwnd increase by one packet.

      This trace did not suffer any timeout retransmissions.  It
      transferred the same amount of data as the first trace in about
      half as much time.  This difference is repeatable between hosts A
      and B.

   References
      [Stevens94] and [Wright95] discuss this problem.  The problem of
      Reno TCP failing to recover from multiple losses except via a
      retransmission timeout is discussed in [Fall96,Hoe96].