Browse Prior Art Database

Problem with the TCP big window option (RFC1110)

IP.com Disclosure Number: IPCOM000001920D
Original Publication Date: 1989-Aug-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 2 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A.M. McKenzie: AUTHOR

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 57% of the total text.

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

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 b...