TCP extensions for long-delay paths
RFC 1072
|
Document |
Type |
|
RFC - Historic
(October 1988; No errata)
|
|
Authors |
|
|
|
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 1072 (Historic)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group V. Jacobson
Request for Comments: 1072 LBL
R. Braden
ISI
October 1988
TCP Extensions for Long-Delay Paths
Status of This Memo
This memo proposes a set of extensions to the TCP protocol to provide
efficient operation over a path with a high bandwidth*delay product.
These extensions are not proposed as an Internet standard at this
time. Instead, they are intended as a basis for further
experimentation and research on transport protocol performance.
Distribution of this memo is unlimited.
1. INTRODUCTION
Recent work on TCP performance has shown that TCP can work well over
a variety of Internet paths, ranging from 800 Mbit/sec I/O channels
to 300 bit/sec dial-up modems [Jacobson88]. However, there is still
a fundamental TCP performance bottleneck for one transmission regime:
paths with high bandwidth and long round-trip delays. The
significant parameter is the product of bandwidth (bits per second)
and round-trip delay (RTT in seconds); this product is the number of
bits it takes to "fill the pipe", i.e., the amount of unacknowledged
data that TCP must handle in order to keep the pipeline full. TCP
performance problems arise when this product is large, e.g.,
significantly exceeds 10**5 bits. We will refer to an Internet path
operating in this region as a "long, fat pipe", and a network
containing this path as an "LFN" (pronounced "elephan(t)").
High-capacity packet satellite channels (e.g., DARPA's Wideband Net)
are LFN's. For example, a T1-speed satellite channel has a
bandwidth*delay product of 10**6 bits or more; this corresponds to
100 outstanding TCP segments of 1200 bytes each! Proposed future
terrestrial fiber-optical paths will also fall into the LFN class;
for example, a cross-country delay of 30 ms at a DS3 bandwidth
(45Mbps) also exceeds 10**6 bits.
Clever algorithms alone will not give us good TCP performance over
LFN's; it will be necessary to actually extend the protocol. This
RFC proposes a set of TCP extensions for this purpose.
There are three fundamental problems with the current TCP over LFN
Jacobson & Braden [Page 1]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
paths:
(1) Window Size Limitation
The TCP header uses a 16 bit field to report the receive window
size to the sender. Therefore, the largest window that can be
used is 2**16 = 65K bytes. (In practice, some TCP
implementations will "break" for windows exceeding 2**15,
because of their failure to do unsigned arithmetic).
To circumvent this problem, we propose a new TCP option to allow
windows larger than 2**16. This option will define an implicit
scale factor, to be used to multiply the window size value found
in a TCP header to obtain the true window size.
(2) Cumulative Acknowledgments
Any packet losses in an LFN can have a catastrophic effect on
throughput. This effect is exaggerated by the simple cumulative
acknowledgment of TCP. Whenever a segment is lost, the
transmitting TCP will (eventually) time out and retransmit the
missing segment. However, the sending TCP has no information
about segments that may have reached the receiver and been
queued because they were not at the left window edge, so it may
be forced to retransmit these segments unnecessarily.
We propose a TCP extension to implement selective
acknowledgements. By sending selective acknowledgments, the
receiver of data can inform the sender about all segments that
have arrived successfully, so the sender need retransmit only
the segments that have actually been lost.
Selective acknowledgments have been included in a number of
experimental Internet protocols -- VMTP [Cheriton88], NETBLT
[Clark87], and RDP [Velten84]. There is some empirical evidence
in favor of selective acknowledgments -- simple experiments with
RDP have shown that disabling the selective acknowlegment
facility greatly increases the number of retransmitted segments
over a lossy, high-delay Internet path [Partridge87]. A
simulation study of a simple form of selective acknowledgments
added to the ISO transport protocol TP4 also showed promise of
performance improvement [NBS85].
Jacobson & Braden [Page 2]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
(3) Round Trip Timing
Show full document text