From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1110.txt | 171 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 doc/rfc/rfc1110.txt (limited to 'doc/rfc/rfc1110.txt') diff --git a/doc/rfc/rfc1110.txt b/doc/rfc/rfc1110.txt new file mode 100644 index 0000000..29a33e3 --- /dev/null +++ b/doc/rfc/rfc1110.txt @@ -0,0 +1,171 @@ + + + + + + +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] + \ No newline at end of file -- cgit v1.2.3