RFC 1110 (rfc1110) - Page 2 of 3

Problem with the TCP big window option

RFC 1110           Comments on TCP Big Window Option         August 1989


   is contained in a 32-bit field and therefore "wraps around" after the
   transmission of 2**32 bytes of data.  Two additional mechanisms are
   used to insure the effective uniqueness of sequence numbers; these
   are the TCP transmission window and bounds on packet lifetime within
   the Internet, including the IP Time-to-Live (TTL).  The transmission
   window specifies the maximum number of bytes which may be sent by the
   source in one source-destination roundtrip time.  Since the TCP
   transmission window is specified by 16 bits, which is 1/65536 of the
   sequence number space, a sequence number will not be reused (used to
   number another byte) for 65,536 roundtrip times.  So long as the
   combination of gateway action on the IP TTL and holding times within
   the individual networks which interconnect the gateways do not allow
   a packet's lifetime to exceed 65,536 roundtrip times, each sequence
   number is effectively unique.  It was believed by the TCP designers
   that the networks and gateways forming the internet would meet this
   constraint, and such has been the case.

   The proposed TCP Big Window option, as described in RFC 1106, expands
   the size of the window specification to 30 bits, while leaving the
   sequence number space unchanged.  Thus, a sequence number can be
   reused after 4 roundtrip times.  Further, the Nak option allows a
   packet to be retransmitted (i.e., potentially duplicated) by the
   source after only one roundtrip time.  Thus, if a packet becomes
   "lost" in the Internet for only about 5 roundtrip times it may be
   delivered when its sequence number again lies within the window,
   albeit a later cycle of the window.  In this case, TCP will not
   necessarily recreate at the destination an exact copy of the data
   stream generated at the source; it may replace some data with earlier
   data.

   Of course, the problem described above results from the storage of
   the "lost" packet within the net, and its subsequent out-of-order
   delivery.  RFC 1106 seems to describe use of the proposed options in
   an isolated satellite network.  We may hypothesize that this network
   is memoryless, and thus cannot deliver packets out of order; it
   either delivers a packet in order or loses it.  If this is the case,
   then there is no problem with the proposed options.  The Internet,
   however, can deliver packets out of order, and this will likely
   continue to be true even if gigabit links become part of the
   Internet.  Therefore, the approach described in RFC 1106 cannot be
   adopted for general Internet use.










McKenzie