TCP big window and NAK options
RFC 1106

Document Type RFC - Historic (June 1989; No errata)
Obsoleted by RFC 6247
Author Richard Fox 
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1106 (Historic)
Telechat date
Responsible AD (None)
Send notices to (None)
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.


   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

   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
Show full document text