rfc1106.txt

RFC 的详细文档！

Network Working Group                                             R. Fox
Request for Comments:  1106                                       Tandem
                                                               June 1989


                     TCP Big Window and Nak Options

Status of this Memo

   This memo discusses two extensions to the TCP protocol to provide a
   more efficient operation over a network with a high bandwidth*delay
   product.  The extensions described in this document have been
   implemented and shown to work using resources at NASA.  This memo
   describes an Experimental Protocol, these extensions are not proposed
   as an Internet standard, but as a starting point for further
   research.  Distribution of this memo is unlimited.

Abstract

   Two extensions to the TCP protocol are described in this RFC in order
   to provide a more efficient operation over a network with a high
   bandwidth*delay product.  The main issue that still needs to be
   solved is congestion versus noise.  This issue is touched on in this
   memo, but further research is still needed on the applicability of
   the extensions in the Internet as a whole infrastructure and not just
   high bandwidth*delay product networks.  Even with this outstanding
   issue, this document does describe the use of these options in the
   isolated satellite network environment to help facilitate more
   efficient use of this special medium to help off load bulk data
   transfers from links needed for interactive use.

1.  Introduction

   Recent work on TCP has shown great performance gains over a variety
   of network paths [1].  However, these changes still do not work well
   over network paths that have a large round trip delay (satellite with
   a 600 ms round trip delay) or a very large bandwidth
   (transcontinental DS3 line).  These two networks exhibit a higher
   bandwidth*delay product, over 10**6 bits, than the 10**5 bits that
   TCP is currently limited to.  This high bandwidth*delay product
   refers to the amount of data that may be unacknowledged so that all
   of the networks bandwidth is being utilized by TCP.  This may also be
   referred to as "filling the pipe" [2] so that the sender of data can
   always put data onto the network and the receiver will always have
   something to read, and neither end of the connection will be forced
   to wait for the other end.

   After the last batch of algorithm improvements to TCP, performance



Fox                                                             [Page 1]

RFC 1106             TCP Big Window and Nak Options            June 1989


   over high bandwidth*delay networks is still very poor.  It appears
   that no algorithm changes alone will make any significant
   improvements over high bandwidth*delay networks, but will require an
   extension to the protocol itself.  This RFC discusses two possible
   options to TCP for this purpose.

   The two options implemented and discussed in this RFC are:

   1.  NAKs

      This extension allows the receiver of data to inform the sender
      that a packet of data was not received and needs to be resent.
      This option proves to be useful over any network path (both high
      and low bandwidth*delay type networks) that experiences periodic
      errors such as lost packets, noisy links, or dropped packets due
      to congestion.  The information conveyed by this option is
      advisory and if ignored, does not have any effect on TCP what so
      ever.

   2.  Big Windows

      This option will give a method of expanding the current 16 bit (64
      Kbytes) TCP window to 32 bits of which 30 bits (over 1 gigabytes)
      are allowed for the receive window.  (The maximum window size
      allowed in TCP due to the requirement of TCP to detect old data
      versus new data.  For a good explanation please see [2].)  No
      changes are required to the standard TCP header [6]. The 16 bit
      field in the TCP header that is used to convey the receive window
      will remain unchanged.  The 32 bit receive window is achieved
      through the use of an option that contains the upper half of the
      window.  It is this option that is necessary to fill large data
      pipes such as a satellite link.

   This RFC is broken up into the following sections: section 2 will
   discuss the operation of the NAK option in greater detail, section 3
   will discuss the big window option in greater detail.  Section 4 will
   discuss other effects of the big windows and nak feature when used
   together.  Included in this section will be a brief discussion on the
   effects of congestion versus noise to TCP and possible options for
   satellite networks.  Section 5 will be a conclusion with some hints
   as to what future development may be done at NASA, and then an
   appendix containing some test results is included.

2.  NAK Option

   Any packet loss in a high bandwidth*delay network will have a
   catastrophic effect on throughput because of the simple
   acknowledgement of TCP.  TCP always acks the stream of data that has



Fox                                                             [Page 2]

RFC 1106             TCP Big Window and Nak Options            June 1989


   successfully been received and tells the sender the next byte of data
   of the stream that is expected.  If a packet is lost and succeeding
   packets arrive the current protocol has no way of telling the sender
   that it missed one packet but received following packets.  TCP
   currently resends all of the data over again, after a timeout or the
   sender suspects a lost packet due to a duplicate ack algorithm [1],
   until the receiver receives the lost packet and can then ack the lost
   packet as well as succeeding packets received.  On a normal low
   bandwidth*delay network this effect is minimal if the timeout period
   is set short enough.  However, on a long delay network such as a T1
   satellite channel this is catastrophic because by the time the lost
   packet can be sent and the ack returned the TCP window would have
   been exhausted and both the sender and receiver would be temporarily
   stalled waiting for the packet and ack to fully travel the data pipe.
   This causes the pipe to become empty and requires the sender to
   refill the pipe after the ack is received.  This will cause a minimum
   of 3*X bandwidth loss, where X is the one way delay of the medium and
   may be much higher depending on the size of the timeout period and
   bandwidth*delay product.  Its 1X for the packet to be resent, 1X for
   the ack to be received and 1X for the next packet being sent to reach
   the destination.  This calculation assumes that the window size is
   much smaller than the pipe size (window = 1/2 data pipe or 1X), which
   is the typical case with the current TCP window limitation over long
   delay networks such as a T1 satellite link.

   An attempt to reduce this wasted bandwidth from 3*X was introduced in
   [1] by having the sender resend a packet after it notices that a
   number of consecutively received acks completely acknowledges already
   acknowledged data.  On a typical network this will reduce the lost
   bandwidth to almost nil, since the packet will be resent before the
   TCP window is exhausted and with the data pipe being much smaller
   than the TCP window, the data pipe will not become empty and no
   bandwidth will be lost.  On a high delay network the reduction of
   lost bandwidth is minimal such that lost bandwidth is still
   significant.  On a very noisy satellite, for instance, the lost
   bandwidth is very high (see appendix for some performance figures)
   and performance is very poor.

   There are two methods of informing the sender of lost data.
   Selective acknowledgements and NAKS.  Selective acknowledgements have
   been the object of research in a number of experimental protocols
   including VMTP [3], NETBLT [4], and SatFTP [5].  The idea behind
   selective acks is that the receiver tells the sender which pieces it
   received so that the sender can resend the data not acked but already
   sent once.  NAKs on the other hand, tell the sender that a particular
   packet of data needs to be resent.

   There are a couple of disadvantages of selective acks.  Namely, in



Fox                                                             [Page 3]

RFC 1106             TCP Big Window and Nak Options            June 1989


   some of the protocols mentioned above, the receiver waits a certain
   time before sending the selective ack so that acks may be bundled up.
   This delay can cause some wasted bandwidth and requires more complex
   state information than the simple nak.  Even if the receiver doesn't
   bundle up the selective acks but sends them as it notices that
   packets have been lost, more complex state information is needed to
   determine which packets have been acked and which packets need to be
   resent.  With naks, only the immediate data needed to move the left
   edge of the window is naked, thus almost completely eliminating all
   state information.

   The selective ack has one advantage over naks.  If the link is very
   noisy and packets are being lost close together, then the sender will
   find out about all of the missing data at once and can send all of
   the missing data out immediately in an attempt to move the left
   window edge in the acknowledge number of the TCP header, thus keeping
   the data pipe flowing.  Whereas with naks, the sender will be
   notified of lost packets one at a time and this will cause the sender
   to process extra packets compared to selective acks.  However,
   empirical studies has shown that most lost packets occur far enough
   apart that the advantage of selective acks over naks is rarely seen.
   Also, if naks are sent out as soon as a packet has been determined
   lost, then the advantage of selective acks becomes no more than
   possibly a more aesthetic algorithm for handling lost data, but
   offers no gains over naks as described in this paper.  It is this
   reason that the simplicity of naks was chosen over selective acks for
   the current implementation.

2.1  Implementation details

   When the receiver of data notices a gap between the expected sequence
   number and the actual sequence number of the packet received, the
   receiver can assume that the data between the two sequence numbers is
   either going to arrive late or is lost forever.  Since the receiver
   can not distinguish between the two events a nak should be sent in
   the TCP option field.  Naking a packet still destined to arrive has
   the effect of causing the sender to resend the packet, wasting one
   packets worth of bandwidth.  Since this event is fairly rare, the
   lost bandwidth is insignificant as compared to that of not sending a
   nak when the packet is not going to arrive.  The option will take the
   form as follows:

      +========+=========+=========================+================+
      +option= + length= + sequence number of      + number of      +
      +   A    +    7    +  first byte being naked + segments naked +
      +========+=========+=========================+================+

   This option contains the first sequence number not received and a



Fox                                                             [Page 4]

RFC 1106             TCP Big Window and Nak Options            June 1989


   count of how many segments of bytes needed to be resent, where
   segments is the size of the current TCP MSS being used for the
   connection.  Since a nak is an advisory piece of information, the
   sending of a nak is unreliable and no means for retransmitting a nak
   is provided at this time.

   When the sender of data receives the option it may either choose to
   do nothing or it will resend the missing data immediately and then
   continue sending data where it left off before receiving the nak.
   The receiver will keep track of the last nak sent so that it will not
   repeat the same nak.  If it were to repeat the same nak the protocol
   could get into the mode where on every reception of data the receiver
   would nak the first missing data frame.  Since the data pipe may be
   very large by the time the first nak is read and responded to by the