home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1100s / rfc1110.txt < prev    next >
Text File  |  1989-08-02  |  6KB  |  171 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        A. McKenzie
  8. Request for Comments: 1110                                       BBN STC
  9.                                                              August 1989
  10.  
  11.  
  12.                 A Problem with the TCP Big Window Option
  13.  
  14. Status of this Memo
  15.  
  16.    This memo comments on the TCP Big Window option described in RFC
  17.    1106.  Distribution of this memo is unlimited.
  18.  
  19. Abstract
  20.  
  21.    The TCP Big Window option discussed in RFC 1106 will not work
  22.    properly in an Internet environment which has both a high bandwidth *
  23.    delay product and the possibility of disordering and duplicating
  24.    packets.  In such networks, the window size must not be increased
  25.    without a similar increase in the sequence number space.  Therefore,
  26.    a different approach to big windows should be taken in the Internet.
  27.  
  28. Discussion
  29.  
  30.    TCP was designed to work in a packet store-and-forward environment
  31.    characterized by the possibility of packet loss, packet disordering,
  32.    and packet duplication.  Packet loss can occur, for example, by a
  33.    congested network element discarding a packet.  Packet disordering
  34.    can occur, for example, by packets of a TCP connection being
  35.    arbitrarily transmitted partially over a low bandwidth terrestrial
  36.    path and partially over a high bandwidth satellite path.  Packet
  37.    duplication can occur, for example, when two directly-connected
  38.    network elements use a reliable link protocol and the link goes down
  39.    after the receiver correctly receives a packet but before the
  40.    transmitter receives an acknowledgement for the packet; the
  41.    transmitter and receiver now each take responsibility for attempting
  42.    to deliver the same packet to its ultimate destination.
  43.  
  44.    TCP has the task of recreating at the destination an exact copy of
  45.    the data stream generated at the source, in the same order and with
  46.    no gaps or duplicates.  The mechanism used to accomplish this task is
  47.    to assign a "unique" sequence number to each byte of data at its
  48.    source, and to sort the bytes at the destination according to the
  49.    sequence number.  The sorting operation corrects any disordering.  An
  50.    acknowledgement, timeout, and retransmission scheme corrects for data
  51.    loss.  The uniqueness of the sequence number corrects for data
  52.    duplication.
  53.  
  54.    As a practical matter, however, the sequence number is not unique; it
  55.  
  56.  
  57.  
  58. McKenzie                                                        [Page 1]
  59.  
  60. RFC 1110           Comments on TCP Big Window Option         August 1989
  61.  
  62.  
  63.    is contained in a 32-bit field and therefore "wraps around" after the
  64.    transmission of 2**32 bytes of data.  Two additional mechanisms are
  65.    used to insure the effective uniqueness of sequence numbers; these
  66.    are the TCP transmission window and bounds on packet lifetime within
  67.    the Internet, including the IP Time-to-Live (TTL).  The transmission
  68.    window specifies the maximum number of bytes which may be sent by the
  69.    source in one source-destination roundtrip time.  Since the TCP
  70.    transmission window is specified by 16 bits, which is 1/65536 of the
  71.    sequence number space, a sequence number will not be reused (used to
  72.    number another byte) for 65,536 roundtrip times.  So long as the
  73.    combination of gateway action on the IP TTL and holding times within
  74.    the individual networks which interconnect the gateways do not allow
  75.    a packet's lifetime to exceed 65,536 roundtrip times, each sequence
  76.    number is effectively unique.  It was believed by the TCP designers
  77.    that the networks and gateways forming the internet would meet this
  78.    constraint, and such has been the case.
  79.  
  80.    The proposed TCP Big Window option, as described in RFC 1106, expands
  81.    the size of the window specification to 30 bits, while leaving the
  82.    sequence number space unchanged.  Thus, a sequence number can be
  83.    reused after 4 roundtrip times.  Further, the Nak option allows a
  84.    packet to be retransmitted (i.e., potentially duplicated) by the
  85.    source after only one roundtrip time.  Thus, if a packet becomes
  86.    "lost" in the Internet for only about 5 roundtrip times it may be
  87.    delivered when its sequence number again lies within the window,
  88.    albeit a later cycle of the window.  In this case, TCP will not
  89.    necessarily recreate at the destination an exact copy of the data
  90.    stream generated at the source; it may replace some data with earlier
  91.    data.
  92.  
  93.    Of course, the problem described above results from the storage of
  94.    the "lost" packet within the net, and its subsequent out-of-order
  95.    delivery.  RFC 1106 seems to describe use of the proposed options in
  96.    an isolated satellite network.  We may hypothesize that this network
  97.    is memoryless, and thus cannot deliver packets out of order; it
  98.    either delivers a packet in order or loses it.  If this is the case,
  99.    then there is no problem with the proposed options.  The Internet,
  100.    however, can deliver packets out of order, and this will likely
  101.    continue to be true even if gigabit links become part of the
  102.    Internet.  Therefore, the approach described in RFC 1106 cannot be
  103.    adopted for general Internet use.
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. McKenzie                                                        [Page 2]
  115.  
  116. RFC 1110           Comments on TCP Big Window Option         August 1989
  117.  
  118.  
  119. Author's Address
  120.  
  121.    Alex McKenzie
  122.    Bolt Beranek and Newman Inc.
  123.    10 Moulton Street
  124.    Cambridge, MA 02238
  125.  
  126.    Phone: (617) 873-2962
  127.  
  128.    EMail: MCKENZIE@BBN.COM
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. McKenzie                                                        [Page 3]
  171.