TCP Extensions for High Performance
RFC 1323
Document | Type |
RFC - Proposed Standard
(May 1992; Errata)
Obsoleted by RFC 7323
|
|
---|---|---|---|
Authors | David Borman , Robert Braden , Van Jacobson | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1323 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group V. Jacobson Request for Comments: 1323 LBL Obsoletes: RFC 1072, RFC 1185 R. Braden ISI D. Borman Cray Research May 1992 TCP Extensions for High Performance Status of This Memo This RFC specifies an IAB standards track protocol 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. Abstract This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences). Selective acknowledgments are not included in this memo. This memo combines and supersedes RFC-1072 and RFC-1185, adding additional clarification and more detailed specification. Appendix C summarizes the changes from the earlier RFCs. TABLE OF CONTENTS 1. Introduction ................................................. 2 2. TCP Window Scale Option ...................................... 8 3. RTTM -- Round-Trip Time Measurement .......................... 11 4. PAWS -- Protect Against Wrapped Sequence Numbers ............. 17 5. Conclusions and Acknowledgments .............................. 25 6. References ................................................... 25 APPENDIX A: Implementation Suggestions ........................... 27 APPENDIX B: Duplicates from Earlier Connection Incarnations ...... 27 APPENDIX C: Changes from RFC-1072, RFC-1185 ...................... 30 APPENDIX D: Summary of Notation .................................. 31 APPENDIX E: Event Processing ..................................... 32 Security Considerations .......................................... 37 Jacobson, Braden, & Borman [Page 1] RFC 1323 TCP Extensions for High Performance May 1992 Authors' Addresses ............................................... 37 1. INTRODUCTION 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. Production 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. 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 [Jacobson88a]. 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 defines a set of modest extensions to TCP to extend the domain of its application to match this increasing network capability. It is based upon and obsoletes RFC-1072 [Jacobson88b] and RFC-1185 [Jacobson90b]. There is no one-line answer to the question: "How fast can TCP go?". There are two separate kinds of issues, performance and reliability, and each depends upon different parameters. We discuss each in turn. 1.1 TCP Performance 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, i.e., the amount of unacknowledged data that TCP must handle in order to keep the pipeline full. TCP performance problems arise when the bandwidth*delay product is large. We 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 DS1-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. TerrestrialShow full document text