This site has been archived. For information on the GN Project’s eduPERT initiative please visit https://archive.geant.org/projects/gn3/geant/services/edupert/Pages/Home.html

The Transmission Control Protocol (TCP) is the prevalent transport protocol used on the Internet today. It uses window-based transmission to provide the service of a reliable byte stream, and adapts the rate of transfer to the state (of congestion) of the network and the receiver. Basic mechanisms include:

  • Segments that fit into IP packets, into which the byte-stream is split by the sender,
  • a checksum for each segment,
  • a Window, which bounds the amount of data "in flight" between the sender and the receiver,
  • Acknowledgements, by which the receiver tells the sender about segments that were received successfully,
  • a flow-control mechanism, which regulates data rate as a function of network and receiver conditions.

Originally specified in September 1981 RFC793 TCP was clarified, refined and extended in many documents. Perhaps most importantly, congestion control  was introduced in "TCP Tahoe" in 1988, described in Van Jacobson's 1988 SIGCOMM article on "Congestion Avoidance and Control". It can be said that TCP's congestion control is what keeps the Internet working when links are overloaded. In today's Internet, the enhanced "Reno" variant of congestion control is probably the most widespread.

RFC 7323 (formerly RFC 1323) specifies a set of "TCP Extensions for High Performance", namely the Window Scaling Option, which provides for much larger windows than the original 64K, the Timestamp Option and the PAWS (Protection Against Wrapped Sequence numbers) mechanism. These extensions are supported by most contemporary TCP stacks, although they frequently must be activated explicitly (or implicitly by configuring large TCP windows).

Another widely implemented performance enhancement to TCP are selective acknowledgements (SACK, RFC2018). In TCP as originally specified, the acknowledgements ("ACKs") sent by a receiver were always "cumulative", that is, they specified the last byte of the part of the stream that was completely received. This is advantageous with LargeTcpWindows, in particular where chances are high that multiple segments within a single window are lost. RFC2883 describes an extension to SACK which makes TCP more robust in the presence of PacketReordering in the network.

In addition, RFC 3449 - TCP Performance Implications of Network Path Asymmetry provides excellent information since a vast majority of Internet connections are asymmetrical.

Further Reading

References

  • RFC 7414, A Roadmap for Transmission Control Protocol (TCP) Specification DocumentsUWC_TOKEN_CL, M. Duke, R. Braden, W. Eddy, E. Blanton, A. Zimmermann, February 2015
  • RFC 793, Transmission Control Protocol, J. Postel, September 1981
  • draft-ietf-tcpm-rfc793bis-12, Transmission Control Protocol Specification, Wesley M. Eddy, October 2018
  • RFC 7323, TCP Extensions for High Performance, D. Borman, B. Braden, V. Jacobson, B. Scheffenegger, September 2014 (obsoletes RFC 1323 from May 1993)
  • RFC 2018, TCP Selective Acknowledgement Options, M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, October 1996
  • RFC 5681, TCP Congestion Control]], M. Allman, V. Paxson, E. Blanton, September 2009
  • RFC 3449, TCP Performance Implications of Network Path Asymmetry, H. Balakrishnan, V. Padmanabhan, G. Fairhurst, M. Sooriyabandara, December 2002

There is ample literature on TCP, in particular research literature on its performance and large-scale behaviour.

Juniper has a nice white paper, Supporting Differentiated Service Classes: TCP Congestion Control Mechanisms (PDF format) explaining TCP's congestion control as well as many of the enhancements proposed over the years.

– SimonLeinen - 2004-10-27 - 2018-12-09
– UlrichSchmid - 2005-05-31

  • No labels