Browse Prior Art Database

TCP Extension for High-Speed Paths (RFC1185)

IP.com Disclosure Number: IPCOM000001998D
Original Publication Date: 1990-Oct-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 21 page(s) / 30K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

V. Jacobson: AUTHOR [+2]

Related Documents

10.17487/RFC1185: DOI

Abstract

This memo describes an Experimental Protocol extension to TCP for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

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

Network Working Group V. Jacobson Request for Comments: 1185 LBL R. Braden ISI L. Zhang PARC October 1990

TCP Extension for High-Speed Paths

Status of This Memo

This memo describes an Experimental Protocol extension to TCP for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Summary

This memo describes a small extension to TCP to support reliable operation over very high-speed paths, using sender timestamps transmitted using the TCP Echo option proposed in RFC-1072.

1. INTRODUCTION

TCP uses positive acknowledgments and retransmissions to provide reliable end-to-end delivery over a full-duplex virtual circuit called a connection [Postel81]. A connection is defined by its two end points; each end point is a "socket", i.e., a (host,port) pair. To protect against data corruption, TCP uses an end-to-end checksum. Duplication and reordering are handled using a fine-grained sequence number space, with each octet receiving a distinct sequence number.

The TCP protocol [Postel81] was designed to operate reliably over almost any transmission medium regardless of transmission rate, delay, corruption, duplication, or reordering of segments. In practice, proper TCP implementations have demonstrated remarkable robustness in adapting to a wide range of network characteristics. For example, TCP implementations currently adapt to transfer rates in the range of 100 bps to 10**7 bps and round-trip delays in the range 1 ms to 100 seconds.

However, the introduction of fiber optics is resulting in ever-higher transmission speeds, and the fastest paths are moving out of the domain for which TCP was originally engineered. This memo and RFC- 1072 [Jacobson88] propose modest extensions to TCP to extend the

Jacobson, Braden & Zhang [Page 1]

RFC 1185 TCP over High-Speed Paths October 1990

domain of its application to higher speeds.

There is no one-line answer to the question: "How fast can TCP go?". The issues are reliability and performance, and these depend upon the round-trip delay and the maximum time that segments may be queued in the Internet, as well as upon the transmission speed. We must think through these relationships very carefully if we are to successfully extend TCP’s domain.

TCP performance depends not upon the transfer rate itself, but rather upon the product of the transfer rate and the round-trip delay. This "bandwidth*delay product" measures the amount of data that would "fill the pipe"; it is the buffer space required at sender and receiver to obtain maximum throughput on the TCP connection over the path. RFC-1072 proposed a set of TCP extensions to improve TCP efficiency for "LFNs" (long fat networks), i.e., networks with large bandwidth*delay products.

On the other hand, high transfer rate can threaten TCP reliability by violating the assumpti...

Processing...
Loading...