rfc2525.txt

RFC 的详细文档！

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
      positions below the earlier transmission, all 26 positions of the
      earlier transmission, and two additional sequence positions.

      The retransmission disagrees starting just after sequence
      90048447, annotated above with a leading '*'.  These two bytes
      were originally transmitted as hex 2c34 but retransmitted as hex
      2c31.  Subsequent positions disagree as well.

      This behavior has been observed in other traces involving
      different hosts.  It is unknown how to repeat it.

      In this instance, no corruption would occur, since B has already
      indicated it will not accept further packets from A.

      A second example illustrates a slightly different instance of the
      problem.  The tracing again was made with tcpdump at the receiving
      TCP (D).

   22:23:58.645829 C > D: P 185:212(27) ack 565 win 4096
                                        4500 0043 90a3 0000
                    3306 0734 cbf1 9eef 83f3 010a 0525 0015
                    a3a2 faba 578c 70a4 5018 1000 9a53 0000
   data starts here>504f 5254 2032 3033 2c32 3431 2c31 3538
                    2c32 3339 2c35 2c34 330d 0a
   22:23:58.646805 D > C: . ack 184 win 8192
                                        4500 0028 beeb 0000
                    3e06 ce06 83f3 010a cbf1 9eef 0015 0525
                    578c 70a4 a3a2 fab9 5010 2000 342f 0000
   22:31:36.532244 C > D: FP 186:213(27) ack 565 win 4096
                                        4500 0043 9435 0000
                    3306 03a2 cbf1 9eef 83f3 010a 0525 0015
                    a3a2 fabb 578c 70a4 5019 1000 9a51 0000
   data starts here>504f 5254 2032 3033 2c32 3431 2c31 3538
                    2c32 3339 2c35 2c34 330d 0a







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


      In this trace, sequence numbers are relative.  C sends 185:212,
      but D only sends an ACK for 184 (so sequence number 184 is
      missing).  C then sends 186:213.  The packet payload is identical
      to the previous payload, but the base sequence number is one
      higher, resulting in an inconsistent retransmission.

      Neither trace exhibits checksum errors.

   Trace file demonstrating correct behavior
      (Omitted, as presumably correct behavior is obvious.)

   References
      None known.

   How to detect
      This problem unfortunately can be very difficult to detect, since
      available experience indicates it is quite rare that it is
      manifested.  No "trigger" has been identified that can be used to
      reproduce the problem.

   How to fix
      In the absence of a known "trigger", we cannot always assess how
      to fix the problem.

      In one implementation (not the one illustrated above), the problem
      manifested itself when (1) the sender received a zero window and
      stalled; (2) eventually an ACK arrived that offered a window
      larger than that in effect at the time of the stall; (3) the
      sender transmitted out of the buffer of data it held at the time
      of the stall, but (4) failed to limit this transfer to the buffer
      length, instead using the newly advertised (and larger) offered
      window.  Consequently, in addition to the valid buffer contents,
      it sent whatever garbage values followed the end of the buffer.
      If it then retransmitted the corresponding sequence numbers, at
      that point it sent the correct data, resulting in an inconsistent
      retransmission.  Note that this instance of the problem reflects a
      more general problem, that of initially transmitting incorrect
      data.

2.5.

   Name of Problem
      Failure to retain above-sequence data

   Classification
      Congestion control, performance





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


   Description
      When a TCP receives an "above sequence" segment, meaning one with
      a sequence number exceeding RCV.NXT but below RCV.NXT+RCV.WND, it
      SHOULD queue the segment for later delivery (RFC 1122, 4.2.2.20).
      (See RFC 793 for the definition of RCV.NXT and RCV.WND.)  A TCP
      that fails to do so is said to exhibit "Failure to retain above-
      sequence data".

      It may sometimes be appropriate for a TCP to discard above-
      sequence data to reclaim memory.  If they do so only rarely, then
      we would not consider them to exhibit this problem.  Instead, the
      particular concern is with TCPs that always discard above-sequence
      data.

   Significance
      In environments prone to packet loss, detrimental to the
      performance of both other connections and the connection itself.

   Implications
      In times of congestion, a failure to retain above-sequence data
      will lead to numerous otherwise-unnecessary retransmissions,
      aggravating the congestion and potentially reducing performance by
      a large factor.

   Relevant RFCs
      RFC 1122 revises RFC 793 by upgrading the latter's MAY to a SHOULD
      on this issue.

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

      B is the TCP sender, A the receiver.  A exhibits failure to retain
      above sequence-data:

   10:38:10.164860 B > A: . 221078:221614(536) ack 1 win 33232 [tos 0x8]
   10:38:10.170809 B > A: . 221614:222150(536) ack 1 win 33232 [tos 0x8]
   10:38:10.177183 B > A: . 222150:222686(536) ack 1 win 33232 [tos 0x8]
   10:38:10.225039 A > B: . ack 222686 win 25800

      Here B has sent up to (relative) sequence 222686 in-sequence, and
      A accordingly acknowledges.

   10:38:10.268131 B > A: . 223222:223758(536) ack 1 win 33232 [tos 0x8]
   10:38:10.337995 B > A: . 223758:224294(536) ack 1 win 33232 [tos 0x8]
   10:38:10.344065 B > A: . 224294:224830(536) ack 1 win 33232 [tos 0x8]
   10:38:10.350169 B > A: . 224830:225366(536) ack 1 win 33232 [tos 0x8]
   10:38:10.356362 B > A: . 225366:225902(536) ack 1 win 33232 [tos 0x8]



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


   10:38:10.362445 B > A: . 225902:226438(536) ack 1 win 33232 [tos 0x8]
   10:38:10.368579 B > A: . 226438:226974(536) ack 1 win 33232 [tos 0x8]
   10:38:10.374732 B > A: . 226974:227510(536) ack 1 win 33232 [tos 0x8]
   10:38:10.380825 B > A: . 227510:228046(536) ack 1 win 33232 [tos 0x8]
   10:38:10.387027 B > A: . 228046:228582(536) ack 1 win 33232 [tos 0x8]
   10:38:10.393053 B > A: . 228582:229118(536) ack 1 win 33232 [tos 0x8]
   10:38:10.399193 B > A: . 229118:229654(536) ack 1 win 33232 [tos 0x8]
   10:38:10.405356 B > A: . 229654:230190(536) ack 1 win 33232 [tos 0x8]

      A now receives 13 additional packets from B.  These are above-
      sequence because 222686:223222 was dropped.  The packets do
      however fit within the offered window of 25800.  A does not
      generate any duplicate ACKs for them.

      The trace contributor (V. Paxson) verified that these 13 packets
      had valid IP and TCP checksums.

   10:38:11.917728 B > A: . 222686:223222(536) ack 1 win 33232 [tos 0x8]
   10:38:11.930925 A > B: . ack 223222 win 32232

      B times out for 222686:223222 and retransmits it.  Upon receiving
      it, A only acknowledges 223222.  Had it retained the valid above-
      sequence packets, it would instead have ack'd 230190.

   10:38:12.048438 B > A: . 223222:223758(536) ack 1 win 33232 [tos 0x8]
   10:38:12.054397 B > A: . 223758:224294(536) ack 1 win 33232 [tos 0x8]
   10:38:12.068029 A > B: . ack 224294 win 31696

      B retransmits two more packets, and A only acknowledges them.
      This pattern continues as B retransmits the entire set of
      previously-received packets.

      A second trace confirmed that the problem is repeatable.

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

   09:11:25.790417 D > C: . 33793:34305(512) ack 1 win 61440
   09:11:25.791393 D > C: . 34305:34817(512) ack 1 win 61440
   09:11:25.792369 D > C: . 34817:35329(512) ack 1 win 61440
   09:11:25.792369 D > C: . 35329:35841(512) ack 1 win 61440
   09:11:25.793345 D > C: . 36353:36865(512) ack 1 win 61440
   09:11:25.794321 C > D: . ack 35841 win 59904

      A sequence hole occurs because 35841:36353 has been dropped.





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


   09:11:25.794321 D > C: . 36865:37377(512) ack 1 win 61440
   09:11:25.794321 C > D: . ack 35841 win 59904
   09:11:25.795297 D > C: . 37377:37889(512) ack 1 win 61440
   09:11:25.795297 C > D: . ack 35841 win 59904
   09:11:25.796273 C > D: . ack 35841 win 61440
   09:11:25.798225 D > C: . 37889:38401(512) ack 1 win 61440
   09:11:25.799201 C > D: . ack 35841 win 61440
   09:11:25.807009 D > C: . 38401:38913(512) ack 1 win 61440
   09:11:25.807009 C > D: . ack 35841 win 61440
   (many additional lines omitted)
   09:11:25.884113 D > C: . 52737:53249(512) ack 1 win 61440
   09:11:25.884113 C > D: . ack 35841 win 61440

      Each additional, above-sequence packet C receives from D elicits a
      duplicate ACK for 35841.

      09:11:25.887041 D > C: . 35841:36353(512) ack 1 win 61440
      09:11:25.887041 C > D: . ack 53249 win 44032

      D retransmits 35841:36353 and C acknowledges receipt of data all
      the way up to 53249.

   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 result in some
      above-sequence packets arriving.  A TCP that exhibits "Failure to
      retain ..." may not generate duplicate ACKs for these packets.
      However, some TCPs that do retain above-sequence data also do not
      generate duplicate ACKs, so failure to do so does not definitively
      identify the problem.  Instead, the key observation is whether
      upon retransmission of the dropped packet, data that was
      previously above-sequence is acknowledged.

      Two considerations in detecting this problem using a packet trace
      are that it is easiest to do so with a trace made at the TCP
      receiver, in order to unambiguously determine which packets
      arrived successfully, and that such packets may still be correctly
      discarded if they arrive with checksum errors.  The latter can be
      tested by capturing the entire packet contents and performing the
      IP and TCP checksum algorithms to verify their integrity; or by
      confirming that the packets arrive with the same checksum and
      contents as that with which they were sent, with a presumption
      that the sending TCP correctly calculates checksums for the
      packets it transmits.




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


      It is considerably easier to verify that an implementation does
      NOT exhibit this problem.  This can be done by recording a trace
      at the data sender, and observing that sometimes after a
      retransmission the receiver acknowledges a higher sequence number
      than just that which was retransmitted.

   How to fix
      If the root problem is that the implementation lacks buffer, then
      then unfortunately this requires significant work to fix.
      However, doing so is important, for reasons outlined above.

2.6.

   Name of Problem
      Extra additive constant in congestion avoidance

   Classification
      Congestion control / performance