rfc2883.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

             Transmitted    Received    ACK Sent
             Segment        Segment     (Including SACK Blocks)

             500-999        500-999     1000 (ACK dropped)
             1000-1499      1000-1499   1500 (ACK dropped)
             1500-1999      1500-1999   2000 (ACK dropped)
             2000-2499      2000-2499   2500 (ACK dropped)
             (timeout)
             500-999        500-999     2500, SACK=500-1000
                                                   --------

   In this case, all of the ACKs are dropped, resulting in a timeout.
   This condition can be identified because the first ACK received
   following the timeout carries a D-SACK block indicating duplicate
   data was received.

   WITHOUT D-SACK:

   Without the use of D-SACK, the sender in this case would be unable to
   decide that no data packets has been dropped.

   RESEARCH ISSUES:

   For a TCP that implements some form of ACK congestion control
   [BPK97], this ability to distinguish between dropped data packets and
   dropped ACK packets would be particularly useful.  In this case, the
   connection could implement congestion control for the return (ACK)
   path independently from the congestion control on the forward (data)
   path.





Floyd, et al.               Standards Track                    [Page 12]

RFC 2883                     SACK Extension                    July 2000


5.4.  Early Retransmit Timeout

   If the sender's RTO is too short, an early retransmission timeout can
   occur when no packets have in fact been dropped in the network.  An
   example of this is given below:

             Transmitted    Received    ACK Sent
             Segment        Segment     (Including SACK Blocks)

             500-999        (delayed)
             1000-1499      (delayed)
             1500-1999      (delayed)
             2000-2499      (delayed)
             (timeout)
             500-999        (delayed)
                            500-999     1000
             1000-1499      (delayed)
                            1000-1499   1500
             ...
                            1500-1999   2000
                            2000-2499   2500
                            500-999     2500, SACK=500-1000
                                                   --------
                            1000-1499   2500, SACK=1000-1500
                                                   ---------
                            ...

   In this case, the first packet is retransmitted following the
   timeout.  Subsequently, the original window of packets arrives at the
   receiver, resulting in ACKs for these segments.  Following this, the
   retransmissions of these segments arrive, resulting in ACKs carrying
   SACK blocks which identify the duplicate segments.

   This can be identified as an early retransmission timeout because the
   ACK for byte 1000 is received after the timeout with no SACK
   information, followed by an ACK which carries SACK information (500-
   999) indicating that the retransmitted segment had already been
   received.

   WITHOUT D-SACK:

   If D-SACK was not used and one of the duplicate ACKs was piggybacked
   on a data packet, the sender would not know how many duplicate
   packets had been received.  If D-SACK was not used and none of the
   duplicate ACKs were piggybacked on a data packet, then the sender
   would have sent N duplicate packets, for some N, and received N
   duplicate ACKs.  In this case, the sender could reasonably infer that




Floyd, et al.               Standards Track                    [Page 13]

RFC 2883                     SACK Extension                    July 2000


   some data or ACK packet had been replicated in the network, or that
   an early retransmission timeout had occurred (or that the receiver is
   lying).

   RESEARCH ISSUES:

   After the sender determines that an unnecessary (i.e., early)
   retransmit timeout has occurred, the sender could adjust parameters
   for setting the RTO, to prevent more unnecessary retransmit timeouts.
   Coupled with this, when the sender determines, after the fact, that
   it has made an unnecessary window reduction, the sender has the
   option of "undoing" that reduction in the congestion window.

6. Security Considerations

   This document neither strengthens nor weakens TCP's current security
   properties.

7. Acknowledgements

   We would like to thank Mark Handley, Reiner Ludwig, and Venkat
   Padmanabhan for conversations on these issues, and to thank Mark
   Allman for helpful feedback on this document.

8. References

   [AP99]    Mark Allman and Vern Paxson, On Estimating End-to-End
             Network Path Properties, SIGCOMM 99, August 1999.  URL
             "http://www.acm.org/sigcomm/sigcomm99/papers/session7-
             3.html".

   [BPS99]   J.C.R. Bennett, C. Partridge, and N. Shectman, Packet
             Reordering is Not Pathological Network Behavior, IEEE/ACM
             Transactions on Networking, Vol. 7, No. 6, December 1999,
             pp. 789-798.

   [BPK97]   Hari Balakrishnan, Venkata Padmanabhan, and Randy H. Katz,
             The Effects of Asymmetry on TCP Performance, Third ACM/IEEE
             Mobicom Conference, Budapest, Hungary, Sep 1997.  URL
             "http://www.cs.berkeley.edu/~padmanab/
             index.html#Publications".

   [F99]     Floyd, S., Re: TCP and out-of-order delivery, Message ID
             <[e-mail]> to the end-to-end-
             interest mailing list, February 1999.  URL
             "http://www.aciri.org/floyd/notes/TCP_Feb99.email".





Floyd, et al.               Standards Track                    [Page 14]

RFC 2883                     SACK Extension                    July 2000


   [ISO8073] ISO/IEC, Information-processing systems - Open Systems
             Interconnection - Connection Oriented Transport Protocol
             Specification, Internation Standard ISO/IEC 8073, December
             1988.

   [L99]     Reiner Ludwig, A Case for Flow Adaptive Wireless links,
             Technical Report UCB//CSD-99-1053, May 1999.  URL
             "http://iceberg.cs.berkeley.edu/papers/Ludwig-
             FlowAdaptive/".

   [LK00]    Reiner Ludwig and Randy H. Katz, The Eifel Algorithm:
             Making TCP Robust Against Spurious Retransmissions, SIGCOMM
             Computer Communication Review, V. 30, N. 1, January 2000.
             URL "http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-
             toc-2000.html".

   [RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for
             High Performance", RFC 1323, May 1992.

   [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and  A. Romanow, "TCP
             Selective Acknowledgement Options", RFC 2018, April 1996.

   [RFC2581] Allman, M., Paxson,V. and W. Stevens, "TCP Congestion
             Control", RFC 2581, April 1999.

   [SCWA99]  Stefan Savage, Neal Cardwell, David Wetherall, Tom
             Anderson, TCP Congestion Control with a Misbehaving
             Receiver, ACM Computer Communications Review, pp. 71-78, V.
             29, N. 5, October, 1999.  URL
             "http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-
             99.html".




















Floyd, et al.               Standards Track                    [Page 15]

RFC 2883                     SACK Extension                    July 2000


Authors' Addresses

   Sally Floyd
   AT&T Center for Internet Research at ICSI (ACIRI)

   Phone: [phone]
   EMail: [e-mail]
   URL:  http://www.aciri.org/floyd/


   Jamshid Mahdavi
   Novell

   Phone: [phone]
   EMail: [e-mail]


   Matt Mathis
   Pittsburgh Supercomputing Center

   Phone: [phone]
   EMail: [e-mail]
   URL: http://www.psc.edu/~mathis/


   Matthew Podolsky
   UC Berkeley Electrical Engineering & Computer Science Dept.

   Phone: [phone]
   EMail: [e-mail]
   URL: http://www.eecs.berkeley.edu/~podolsky




















Floyd, et al.               Standards Track                    [Page 16]

RFC 2883                     SACK Extension                    July 2000


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Floyd, et al.               Standards Track                    [Page 17]