rfc2018.txt

<VC++网络游戏建摸与实现>源代码


RFC 2018         TCP Selective Acknowledgement Options      October 1996


5.1  Congestion Control Issues

   This document does not attempt to specify in detail the congestion
   control algorithms for implementations of TCP with SACK.  However,
   the congestion control algorithms present in the de facto standard
   TCP implementations MUST be preserved [Stevens94].  In particular, to
   preserve robustness in the presence of packets reordered by the
   network, recovery is not triggered by a single ACK reporting out-of-
   order packets at the receiver.  Further, during recovery the data
   sender limits the number of segments sent in response to each ACK.
   Existing implementations limit the data sender to sending one segment
   during Reno-style fast recovery, or to two segments during slow-start
   [Jacobson88].  Other aspects of congestion control, such as reducing
   the congestion window in response to congestion, must similarly be
   preserved.

   The use of time-outs as a fall-back mechanism for detecting dropped
   packets is unchanged by the SACK option.  Because the data receiver
   is allowed to discard SACKed data, when a retransmit timeout occurs
   the data sender MUST ignore prior SACK information in determining
   which data to retransmit.

   Future research into congestion control algorithms may take advantage
   of the additional information provided by SACK.  One such area for
   future research concerns modifications to TCP for a wireless or
   satellite environment where packet loss is not necessarily an
   indication of congestion.

6.  Efficiency and Worst Case Behavior

   If the return path carrying ACKs and SACK options were lossless, one
   block per SACK option packet would always be sufficient.  Every
   segment arriving while the data receiver holds discontinuous data
   would cause the data receiver to send an ACK with a SACK option
   containing the one altered block in the receiver's queue.  The data
   sender is thus able to construct a precise replica of the receiver's
   queue by taking the union of all the first SACK blocks.














Mathis, et. al.             Standards Track                     [Page 7]

RFC 2018         TCP Selective Acknowledgement Options      October 1996


   Since the return path is not lossless, the SACK option is defined to
   include more than one SACK block in a single packet.  The redundant
   blocks in the SACK option packet increase the robustness of SACK
   delivery in the presence of lost ACKs.  For a receiver that is also
   using the time stamp option [Jacobson92], the SACK option has room to
   include three SACK blocks.  Thus each SACK block will generally be
   repeated at least three times, if necessary, once in each of three
   successive ACK packets.  However, if all of the ACK packets reporting
   a particular SACK block are dropped, then the sender might assume
   that the data in that SACK block has not been received, and
   unnecessarily retransmit those segments.

   The deployment of other TCP options may reduce the number of
   available SACK blocks to 2 or even to 1.  This will reduce the
   redundancy of SACK delivery in the presence of lost ACKs.  Even so,
   the exposure of TCP SACK in regard to the unnecessary retransmission
   of packets is strictly less than the exposure of current
   implementations of TCP.  The worst-case conditions necessary for the
   sender to needlessly retransmit data is discussed in more detail in a
   separate document [Floyd96].

   Older TCP implementations which do not have the SACK option will not
   be unfairly disadvantaged when competing against SACK-capable TCPs.
   This issue is discussed in more detail in [Floyd96].

7.  Sack Option Examples

   The following examples attempt to demonstrate the proper behavior of
   SACK generation by the data receiver.

   Assume the left window edge is 5000 and that the data transmitter
   sends a burst of 8 segments, each containing 500 data bytes.

      Case 1: The first 4 segments are received but the last 4 are
      dropped.

      The data receiver will return a normal TCP ACK segment
      acknowledging sequence number 7000, with no SACK option.













Mathis, et. al.             Standards Track                     [Page 8]

RFC 2018         TCP Selective Acknowledgement Options      October 1996


      Case 2:  The first segment is dropped but the remaining 7 are
      received.

         Upon receiving each of the last seven packets, the data
         receiver will return a TCP ACK segment that acknowledges
         sequence number 5000 and contains a SACK option specifying
         one block of queued data:

             Triggering    ACK      Left Edge   Right Edge
             Segment

             5000         (lost)
             5500         5000     5500       6000
             6000         5000     5500       6500
             6500         5000     5500       7000
             7000         5000     5500       7500
             7500         5000     5500       8000
             8000         5000     5500       8500
             8500         5000     5500       9000


      Case 3:  The 2nd, 4th, 6th, and 8th (last) segments are
      dropped.

      The data receiver ACKs the first packet normally.  The
      third, fifth, and seventh packets trigger SACK options as
      follows:

          Triggering  ACK    First Block   2nd Block     3rd Block
          Segment            Left   Right  Left   Right  Left   Right
                             Edge   Edge   Edge   Edge   Edge   Edge

          5000       5500
          5500       (lost)
          6000       5500    6000   6500
          6500       (lost)
          7000       5500    7000   7500   6000   6500
          7500       (lost)
          8000       5500    8000   8500   7000   7500   6000   6500
          8500       (lost)











Mathis, et. al.             Standards Track                     [Page 9]

RFC 2018         TCP Selective Acknowledgement Options      October 1996


      Suppose at this point, the 4th packet is received out of order.
      (This could either be because the data was badly misordered in the
      network, or because the 2nd packet was retransmitted and lost, and
      then the 4th packet was retransmitted). At this point the data
      receiver has only two SACK blocks to report.  The data receiver
      replies with the following Selective Acknowledgment:

          Triggering  ACK    First Block   2nd Block     3rd Block
          Segment            Left   Right  Left   Right  Left   Right
                             Edge   Edge   Edge   Edge   Edge   Edge

          6500       5500    6000   7500   8000   8500

      Suppose at this point, the 2nd segment is received.  The data
      receiver then replies with the following Selective Acknowledgment:

          Triggering  ACK    First Block   2nd Block     3rd Block
          Segment            Left   Right  Left   Right  Left   Right
                             Edge   Edge   Edge   Edge   Edge   Edge

          5500       7500    8000   8500

8.  Data Receiver Reneging

   Note that the data receiver is permitted to discard data in its queue
   that has not been acknowledged to the data sender, even if the data
   has already been reported in a SACK option.  Such discarding of
   SACKed packets is discouraged, but may be used if the receiver runs
   out of buffer space.

   The data receiver MAY elect not to keep data which it has reported in
   a SACK option.  In this case, the receiver SACK generation is
   additionally qualified:

      * The first SACK block MUST reflect the newest segment.  Even if
      the newest segment is going to be discarded and the receiver has
      already discarded adjacent segments, the first SACK block MUST
      report, at a minimum, the left and right edges of the newest
      segment.

      * Except for the newest segment, all SACK blocks MUST NOT report
      any old data which is no longer actually held by the receiver.

   Since the data receiver may later discard data reported in a SACK
   option, the sender MUST NOT discard data before it is acknowledged by
   the Acknowledgment Number field in the TCP header.





Mathis, et. al.             Standards Track                    [Page 10]

RFC 2018         TCP Selective Acknowledgement Options      October 1996


9.  Security Considerations

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

10. References

   [Cheriton88]  Cheriton, D., "VMTP: Versatile Message Transaction
   Protocol", RFC 1045, Stanford University, February 1988.

   [Clark87] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk Data
   Transfer Protocol", RFC 998, MIT, March 1987.

   [Fall95]  Fall, K. and Floyd, S., "Comparisons of Tahoe, Reno, and
   Sack TCP", ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z, December 1995.

   [Floyd96]  Floyd, S.,  "Issues of TCP with SACK",
   ftp://ftp.ee.lbl.gov/papers/issues_sa.ps.Z, January 1996.

   [Huitema81] Huitema, C., and Valet, I., An Experiment on High Speed
   File Transfer using Satellite Links, 7th Data Communication
   Symposium, Mexico, October 1981.

   [Jacobson88] Jacobson, V., "Congestion Avoidance and Control",
   Proceedings of SIGCOMM '88, Stanford, CA., August 1988.

   [Jacobson88}, Jacobson, V. and R. Braden, "TCP Extensions for Long-
   Delay Paths", RFC 1072, October 1988.

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

   [Keshav94]  Keshav, presentation to the Internet End-to-End Research
   Group, November 1994.

   [Mathis95]  Mathis, M., and Mahdavi, J., TCP Forward Acknowledgment
   Option, presentation to the Internet End-to-End Research Group, June
   1995.

   [Partridge87]  Partridge, C., "Private Communication", February 1987.

   [Postel81]  Postel, J., "Transmission Control Protocol - DARPA
   Internet Program Protocol Specification", RFC 793, DARPA, September
   1981.

   [Stevens94] Stevens, W., TCP/IP Illustrated, Volume 1: The Protocols,
   Addison-Wesley, 1994.




Mathis, et. al.             Standards Track                    [Page 11]

RFC 2018         TCP Selective Acknowledgement Options      October 1996


   [Strayer92] Strayer, T., Dempsey, B., and Weaver, A., XTP -- the
   xpress transfer protocol. Addison-Wesley Publishing Company, 1992.

   [Velten84] Velten, D., Hinden, R., and J. Sax, "Reliable Data
   Protocol", RFC 908, BBN, July 1984.

11. Authors' Addresses

    Matt Mathis and Jamshid Mahdavi
    Pittsburgh Supercomputing Center
    4400 Fifth Ave
    Pittsburgh, PA 15213
    [e-mail]
    [e-mail]

    Sally Floyd
    Lawrence Berkeley National Laboratory
    One Cyclotron Road
    Berkeley, CA 94720
    [e-mail]

    Allyn Romanow
    Sun Microsystems, Inc.
    2550 Garcia Ave., MPK17-202
    Mountain View, CA 94043
    [e-mail]

























Mathis, et. al.             Standards Track                    [Page 12]