rfc2525.txt

中、英文RFC文档大全打包下载完全版 .

   Implications
      Entering slow start upon timeout forms one of the cornerstones of
      Internet congestion stability, as outlined in [Jacobson88].  If
      TCPs fail to do so, the network becomes at risk of suffering
      "congestion collapse" [RFC896].

   Relevant RFCs
      RFC 1122 requires use of slow start after loss.  RFC 2001 gives
      the specifics of how to implement slow start.  RFC 896 describes
      congestion collapse.

      The retransmission timeout discussed here should not be confused
      with the separate "fast recovery" retransmission mechanism
      discussed in RFC 2001.

   Trace file demonstrating it
      Made using tcpdump recording at the sending TCP (A).  No losses
      reported by the packet filter.



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


   10:40:59.090612 B > A: . ack 357125 win 33580 (DF) [tos 0x8]
   10:40:59.222025 A > B: . 357125:358585(1460) ack 1 win 32768
   10:40:59.868871 A > B: . 357125:358585(1460) ack 1 win 32768
   10:41:00.016641 B > A: . ack 364425 win 33580 (DF) [tos 0x8]
   10:41:00.036709 A > B: . 364425:365885(1460) ack 1 win 32768
   10:41:00.045231 A > B: . 365885:367345(1460) ack 1 win 32768
   10:41:00.053785 A > B: . 367345:368805(1460) ack 1 win 32768
   10:41:00.062426 A > B: . 368805:370265(1460) ack 1 win 32768
   10:41:00.071074 A > B: . 370265:371725(1460) ack 1 win 32768
   10:41:00.079794 A > B: . 371725:373185(1460) ack 1 win 32768
   10:41:00.089304 A > B: . 373185:374645(1460) ack 1 win 32768
   10:41:00.097738 A > B: . 374645:376105(1460) ack 1 win 32768
   10:41:00.106409 A > B: . 376105:377565(1460) ack 1 win 32768
   10:41:00.115024 A > B: . 377565:379025(1460) ack 1 win 32768
   10:41:00.123576 A > B: . 379025:380485(1460) ack 1 win 32768
   10:41:00.132016 A > B: . 380485:381945(1460) ack 1 win 32768
   10:41:00.141635 A > B: . 381945:383405(1460) ack 1 win 32768
   10:41:00.150094 A > B: . 383405:384865(1460) ack 1 win 32768
   10:41:00.158552 A > B: . 384865:386325(1460) ack 1 win 32768
   10:41:00.167053 A > B: . 386325:387785(1460) ack 1 win 32768
   10:41:00.175518 A > B: . 387785:389245(1460) ack 1 win 32768
   10:41:00.210835 A > B: . 389245:390705(1460) ack 1 win 32768
   10:41:00.226108 A > B: . 390705:392165(1460) ack 1 win 32768
   10:41:00.241524 B > A: . ack 389245 win 8760 (DF) [tos 0x8]

      The first packet indicates the ack point is 357125.  130 msec
      after receiving the ACK, A transmits the packet after the ACK
      point, 357125:358585.  640 msec after this transmission, it
      retransmits 357125:358585, in an apparent retransmission timeout.
      At this point, A's cwnd should be one MSS, or 1460 bytes, as A
      enters slow start.  The trace is consistent with this possibility.

      B replies with an ACK of 364425, indicating that A has filled a
      sequence hole.  At this point, A's cwnd should be 1460*2 = 2920
      bytes, since in slow start receiving an ACK advances cwnd by MSS.
      However, A then launches 19 consecutive packets, which is
      inconsistent with slow start.

      A second trace confirmed that the problem is repeatable.

   Trace file demonstrating correct behavior
      Made using tcpdump recording at the sending TCP (C).  No losses
      reported by the packet filter.

   12:35:48.442538 C > D: P 465409:465921(512) ack 1 win 4608
   12:35:48.544483 D > C: . ack 461825 win 4096
   12:35:48.703496 D > C: . ack 461825 win 4096
   12:35:49.044613 C > D: . 461825:462337(512) ack 1 win 4608



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


   12:35:49.192282 D > C: . ack 465921 win 2048
   12:35:49.192538 D > C: . ack 465921 win 4096
   12:35:49.193392 C > D: P 465921:466433(512) ack 1 win 4608
   12:35:49.194726 C > D: P 466433:466945(512) ack 1 win 4608
   12:35:49.350665 D > C: . ack 466945 win 4096
   12:35:49.351694 C > D: . 466945:467457(512) ack 1 win 4608
   12:35:49.352168 C > D: . 467457:467969(512) ack 1 win 4608
   12:35:49.352643 C > D: . 467969:468481(512) ack 1 win 4608
   12:35:49.506000 D > C: . ack 467969 win 3584

      After C transmits the first packet shown to D, it takes no action
      in response to D's ACKs for 461825, because the first packet
      already reached the advertised window limit of 4096 bytes above
      461825.  600 msec after transmitting the first packet, C
      retransmits 461825:462337, presumably due to a timeout.  Its
      congestion window is now MSS (512 bytes).

      D acks 465921, indicating that C's retransmission filled a
      sequence hole.  This ACK advances C's cwnd from 512 to 1024.  Very
      shortly after, D acks 465921 again in order to update the offered
      window from 2048 to 4096.  This ACK does not advance cwnd since it
      is not for new data.  Very shortly after, C responds to the newly
      enlarged window by transmitting two packets.  D acks both,
      advancing cwnd from 1024 to 1536.  C in turn transmits three
      packets.

   References
      This problem is documented in [Paxson97].

   How to detect
      Packet loss is common enough in the Internet that generally it is
      not difficult to find an Internet path that will force
      retransmission due to packet loss.

      If the effective window prior to loss is large enough, however,
      then the TCP may retransmit using the "fast recovery" mechanism
      described in RFC 2001.  In a packet trace, the signature of fast
      recovery is that the packet retransmission occurs in response to
      the receipt of three duplicate ACKs, and subsequent duplicate ACKs
      may lead to the transmission of new data, above both the ack point
      and the highest sequence transmitted so far.  An absence of three
      duplicate ACKs prior to retransmission suffices to distinguish
      between timeout and fast recovery retransmissions.  In the face of
      only observing fast recovery retransmissions, generally it is not
      difficult to repeat the data transfer until observing a timeout
      retransmission.





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


      Once armed with a trace exhibiting a timeout retransmission,
      determining whether the TCP follows slow start is done by
      computing the correct progression of cwnd and comparing it to the
      amount of data transmitted by the TCP subsequent to the timeout
      retransmission.

   How to fix
      If the root problem is that the implementation lacks a notion of a
      congestion window, then unfortunately this requires significant
      work to fix.  However, doing so is critical, for reasons outlined
      above.

2.3.

   Name of Problem
      Uninitialized CWND

   Classification
      Congestion control

   Description
      As described above for "No initial slow start", when a TCP
      connection begins cwnd is initialized to one segment (or perhaps a
      few segments, if experimenting with [RFC2414]).  One particular
      form of "No initial slow start", worth separate mention as the bug
      is fairly widely deployed, is "Uninitialized CWND".  That is,
      while the TCP implements the proper slow start mechanism, it fails
      to initialize cwnd properly, so slow start in fact fails to occur.

      One way the bug can occur is if, during the connection
      establishment handshake, the SYN ACK packet arrives without an MSS
      option.  The faulty implementation uses receipt of the MSS option
      to initialize cwnd to one segment; if the option fails to arrive,
      then cwnd is instead initialized to a very large value.

   Significance
      In congested environments, detrimental to the performance of other
      connections, and likely to the connection itself.  The burst can
      be so large (see below) that it has deleterious effects even in
      uncongested environments.

   Implications
      A TCP exhibiting this behavior is stressing the network with a
      large burst of packets, which can cause loss in the network.

   Relevant RFCs
      RFC 1122 requires use of slow start.  RFC 2001 gives the specifics
      of slow start.



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


   Trace file demonstrating it
      This trace was made using tcpdump running on host A.  Host A is
      the sender and host B is the receiver.  The advertised window and
      timestamp options have been omitted for clarity, except for the
      first segment sent by host A.  Note that A sends an MSS option in
      its initial SYN but B does not include one in its reply.

   16:56:02.226937 A > B: S 237585307:237585307(0) win 8192
         <mss 536,nop,wscale 0,nop,nop,timestamp[|tcp]>
   16:56:02.557135 B > A: S 1617216000:1617216000(0)
         ack 237585308 win 16384
   16:56:02.557788 A > B: . ack 1 win 8192
   16:56:02.566014 A > B: . 1:537(536) ack 1
   16:56:02.566557 A > B: . 537:1073(536) ack 1
   16:56:02.567120 A > B: . 1073:1609(536) ack 1
   16:56:02.567662 A > B: P 1609:2049(440) ack 1
   16:56:02.568349 A > B: . 2049:2585(536) ack 1
   16:56:02.568909 A > B: . 2585:3121(536) ack 1

      [54 additional burst segments deleted for brevity]

   16:56:02.936638 A > B: . 32065:32601(536) ack 1
   16:56:03.018685 B > A: . ack 1

      After the three-way handshake, host A bursts 61 segments into the
      network, before duplicate ACKs on the first segment cause a
      retransmission to occur.  Since host A did not wait for the ACK on
      the first segment before sending additional segments, it is
      exhibiting "Uninitialized CWND"

   Trace file demonstrating correct behavior

      See the example for "No initial slow start".

   References
      This problem is documented in [Paxson97].

   How to detect
      This problem can be detected by examining a packet trace recorded
      at either the sender or the receiver.  However, the bug can be
      difficult to induce because it requires finding a remote TCP peer
      that does not send an MSS option in its SYN ACK.

   How to fix
      This problem can be fixed by ensuring that cwnd is initialized
      upon receipt of a SYN ACK, even if the SYN ACK does not contain an
      MSS option.




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


2.4.

   Name of Problem
      Inconsistent retransmission

   Classification
      Reliability

   Description
      If, for a given sequence number, a sending TCP retransmits
      different data than previously sent for that sequence number, then
      a strong possibility arises that the receiving TCP will
      reconstruct a different byte stream than that sent by the sending
      application, depending on which instance of the sequence number it
      accepts.

      Such a sending TCP exhibits "Inconsistent retransmission".

   Significance
      Critical for all environments.

   Implications
      Reliable delivery of data is a fundamental property of TCP.

   Relevant RFCs
      RFC 793, section 1.5, discusses the central role of reliability in
      TCP operation.

   Trace file demonstrating it
      Made using tcpdump recording at the receiving TCP (B).  No losses
      reported by the packet filter.

   12:35:53.145503 A > B: FP 90048435:90048461(26)
                             ack 393464682 win 4096
                                        4500 0042 9644 0000
                    3006 e4c2 86b1 0401 83f3 010a b2a4 0015
                    055e 07b3 1773 cb6a 5019 1000 68a9 0000
   data starts here>504f 5254 2031 3334 2c31 3737*2c34 2c31
                    2c31 3738 2c31 3635 0d0a
   12:35:53.146479 B > A: R 393464682:393464682(0) win 8192
   12:35:53.851714 A > B: FP 90048429:90048463(34)
                          ack 393464682 win 4096
                                        4500 004a 965b 0000
                    3006 e4a3 86b1 0401 83f3 010a b2a4 0015
                    055e 07ad 1773 cb6a 5019 1000 8bd3 0000
   data starts here>5041 5356 0d0a 504f 5254 2031 3334 2c31
                    3737*2c31 3035 2c31 3431 2c34 2c31 3539
                    0d0a



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


      The sequence numbers shown in this trace are absolute and not
      adjusted to reflect the ISN.  The 4-digit hex values show a dump
      of the packet's IP and TCP headers, as well as payload.  A first
      sends to B data for 90048435:90048461.  The corresponding data
      begins with hex words 504f, 5254, etc.

      B responds with a RST.  Since the recording location was local to
      B, it is unknown whether A received the RST.

      A then sends 90048429:90048463, which includes six sequence