171 lines
5.5 KiB
Plaintext
171 lines
5.5 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group A. McKenzie
|
||
Request for Comments: 1110 BBN STC
|
||
August 1989
|
||
|
||
|
||
A Problem with the TCP Big Window Option
|
||
|
||
Status of this Memo
|
||
|
||
This memo comments on the TCP Big Window option described in RFC
|
||
1106. Distribution of this memo is unlimited.
|
||
|
||
Abstract
|
||
|
||
The TCP Big Window option discussed in RFC 1106 will not work
|
||
properly in an Internet environment which has both a high bandwidth *
|
||
delay product and the possibility of disordering and duplicating
|
||
packets. In such networks, the window size must not be increased
|
||
without a similar increase in the sequence number space. Therefore,
|
||
a different approach to big windows should be taken in the Internet.
|
||
|
||
Discussion
|
||
|
||
TCP was designed to work in a packet store-and-forward environment
|
||
characterized by the possibility of packet loss, packet disordering,
|
||
and packet duplication. Packet loss can occur, for example, by a
|
||
congested network element discarding a packet. Packet disordering
|
||
can occur, for example, by packets of a TCP connection being
|
||
arbitrarily transmitted partially over a low bandwidth terrestrial
|
||
path and partially over a high bandwidth satellite path. Packet
|
||
duplication can occur, for example, when two directly-connected
|
||
network elements use a reliable link protocol and the link goes down
|
||
after the receiver correctly receives a packet but before the
|
||
transmitter receives an acknowledgement for the packet; the
|
||
transmitter and receiver now each take responsibility for attempting
|
||
to deliver the same packet to its ultimate destination.
|
||
|
||
TCP has the task of recreating at the destination an exact copy of
|
||
the data stream generated at the source, in the same order and with
|
||
no gaps or duplicates. The mechanism used to accomplish this task is
|
||
to assign a "unique" sequence number to each byte of data at its
|
||
source, and to sort the bytes at the destination according to the
|
||
sequence number. The sorting operation corrects any disordering. An
|
||
acknowledgement, timeout, and retransmission scheme corrects for data
|
||
loss. The uniqueness of the sequence number corrects for data
|
||
duplication.
|
||
|
||
As a practical matter, however, the sequence number is not unique; it
|
||
|
||
|
||
|
||
McKenzie [Page 1]
|
||
|
||
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 [Page 2]
|
||
|
||
RFC 1110 Comments on TCP Big Window Option August 1989
|
||
|
||
|
||
Author's Address
|
||
|
||
Alex McKenzie
|
||
Bolt Beranek and Newman Inc.
|
||
10 Moulton Street
|
||
Cambridge, MA 02238
|
||
|
||
Phone: (617) 873-2962
|
||
|
||
EMail: MCKENZIE@BBN.COM
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
McKenzie [Page 3]
|
||
|