Browse Prior Art Database

TCP extensions for long-delay paths (RFC1072)

IP.com Disclosure Number: IPCOM000001881D
Original Publication Date: 1988-Oct-01
Included in the Prior Art Database: 2019-Feb-15
Document File: 16 page(s) / 22K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

V. Jacobson: AUTHOR [+1]

Related Documents

10.17487/RFC1072: DOI

Abstract

This RFC 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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 10% of the total text.

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

Processing...
Loading...