TCP and are no longer used or easily available.
RFC 2398 I: "Some Testing Tools for TCP Implementors" (August 1998)
This document [RFC2398] describes a number of TCP packet
generation and analysis tools. Although some of these tools are
no longer readily available or widely used, for the most part they
are still relevant and usable.
6.6. Case Studies
RFC 1337 I: "TIME-WAIT Assassination Hazards in TCP" (May 1992)
This document [RFC1337] points out a problem with acting on
received reset segments while one is in the TIME-WAIT state. The
main recommendation is that hosts in TIME-WAIT ignore resets.
This recommendation might not currently be widely implemented.
RFC 2415 I: "Simulation Studies of Increased Initial TCP Window Size"
(September 1998)
This document [RFC2415] presents results of some simulations using
TCP initial windows greater than 1 segment. The analysis
indicates that user-perceived performance can be improved by
increasing the initial window to 3 segments.
RFC 2416 I: "When TCP Starts Up With Four Packets Into Only Three
Buffers" (September 1998)
This document [RFC2416] uses simulation results to clear up some
concerns about using an initial window of 4 segments when the
network path has less provisioning.
RFC 2884 I: "Performance Evaluation of Explicit Congestion
Notification (ECN) in IP Networks" (July 2000)
This document [RFC2884] describes experimental results that show
some improvements to the performance of both short- and long-lived
connections due to ECN.
7. Undocumented TCP Features
There are a few important implementation tactics for the TCP that
have not yet been described in any RFC. Although this roadmap is
primarily concerned with mapping the TCP RFCs, this section is
included because an implementer needs to be aware of these important
issues.
SYN Cookies
A mechanism known as "SYN cookies" is widely used to thwart TCP
SYN flooding attacks, in which an attacker sends a flood of SYNs
to a victim but fails to complete the 3-way handshake. The result
is exhaustion of resources at the server. The SYN cookie
mechanism allows the server to return a cleverly chosen initial
sequence number that has all the required state for the secure
completion of the handshake. Then the server can avoid saving
connection state during the 3-way handshake and thus survive a SYN
flooding attack.
A web search for "SYN cookies" will reveal a number of useful
descriptions of this mechanism, although there is currently no RFC
on the matter.
Header Prediction
Header prediction is a trick to speed up the processing of
segments. Van Jacobson and Mike Karels developed the technique in
the late 1980s. The basic idea is that some processing time can
be saved when most of a segment’s fields can be predicted from
previous segments. A good description of this was sent to the
TCP-IP mailing list by Van Jacobson on March 9, 1988:
Quite a bit of the speedup comes from an algorithm that we
(’we’ refers to collaborator Mike Karels and myself) are
calling "header prediction". The idea is that if you’re in the
middle of a bulk data transfer and have just seen a packet, you
know what the next packet is going to look like: It will look
just like the current packet with either the sequence number or
ack number updated (depending on whether you’re the sender or
receiver). Combining this with the "Use hints" epigram from
Butler Lampson’s classic "Epigrams for System Designers", you
start to think of the tcp state (rcv.nxt, snd.una, etc.) as
"hints" about what the next packet should look like.
If you arrange those "hints" so they match the layout of a tcp
packet header, it takes a single 14-byte compare to see if your
prediction is correct (3 longword compares to pick up the send
& ack sequence numbers, header length, flags and window, plus a
short compare on the length). If the prediction is correct,
there’s a single test on the length to see if you’re the sender
or receiver followed by the appropriate processing. E.g., if
the length is non-zero (you’re the receiver), checksum and
append the data to the socket buffer then wake any process
that’s sleeping on the buffer. Update rcv.nxt by the length of
this packet (this updates your "prediction" of the next
packet). Check if you can handle another packet the same size
as the current one. If not, set one of the unused flag bits in
your header prediction to guarantee that the prediction will
fail on the next packet and force you to go through full
protocol processing. Otherwise, you’re done with this packet.
So, the *total* tcp protocol processing, exclusive of
checksumming, is on the order of 6 compares and an add.
8. Security Considerations
This document introduces no new security considerations. Each RFC
listed in this document attempts to address the security
considerations of the specification it contains.
9. Acknowledgments
This document grew out of a discussion on the end2end-interest
mailing list, the public list of the End-to-End Research Group of the
IRTF, and continued development under the IETF’s TCP Maintenance and
Minor Extensions (TCPM) working group. We thank Joe Touch, Reiner
Ludwig, Pekka Savola, Gorry Fairhurst, and Sally Floyd for their
contributions, in particular. The chairs of the TCPM working group,
Mark Allman and Ted Faber, have been instrumental in the development
of this document. Keith McCloghrie provided some useful notes and
clarification on the various MIB-related RFCs.
10. Informative References
10.1. Basic Functionality
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999.
[RFC2873] Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP
Processing of the IPv4 Precedence Field", RFC 2873, June
2000.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP’s Retransmission
Timer", RFC 2988, November 2000.
10.2. Recommended Enhancements
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC 2883, July 2000.
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
TCP’s Loss Recovery Using Limited Transmit", RFC 3042,
January 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP’s
Initial Window", RFC 3390, October 2002.
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Conservative Selective Acknowledgment (SACK)-based Loss
Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
Modification to TCP’s Fast Recovery Algorithm", RFC 3782,
April 2004.
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm
for TCP", RFC 4015, February 2005.
[RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance
Regarding the TCP MD5 Signature Option (RFC 2385) and the
BGP-4 Specification", RFC 4278, January 2006.
10.3. Experimental Extensions
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140,
April 1997.
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
Window Validation", RFC 2861, June 2000.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, June 2001.
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte
Counting (ABC)", RFC 3465, February 2003.
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm
for TCP", RFC 3522, April 2003.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", RFC
3540, June 2003.
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
RFC 3649, December 2003.
[RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective
Acknowledgement (DSACKs) and Stream Control Transmission
Protocol (SCTP) Duplicate Transmission Sequence Numbers
(TSNs) to Detect Spurious Retransmissions", RFC 3708,
February 2004.
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large
Congestion Windows", RFC 3742, March 2004.
[RFC4138] Sarolahti, P. and M. Kojo, "Forward RTO-Recovery (F-RTO):
An Algorithm for Detecting Spurious Retransmission
Timeouts with TCP and the Stream Control Transmission
Protocol (SCTP)", RFC 4138, August 2005.
10.4. Historic Extensions
[RFC1106] Fox, R., "TCP big window and NAK options", RFC 1106, June
1989.
[RFC1110] McKenzie, A., "Problem with the TCP big window option",
RFC 1110, August 1989.
[RFC1146] Zweig, J. and C. Partridge, "TCP alternate checksum
options", RFC 1146, March 1990.
[RFC1263] O’Malley, S. and L. Peterson, "TCP Extensions Considered
Harmful", RFC 1263, October 1991.
[RFC1379] Braden, R., "Extending TCP for Transactions -- Concepts",
RFC 1379, November 1992.
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions
Functional Specification", RFC 1644, July 1994.
[RFC1693] Connolly, T., Amer, P., and P. Conrad, "An Extension to
TCP : Partial Order Service", RFC 1693, November 1994.
10.5. Support Documents
[RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP",
RFC 813, July 1982.
[RFC0814] Clark, D., "Name, addresses, ports, and routes", RFC 814,
July 1982.
[RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, July
1982.
[RFC0817] Clark, D., "Modularity and efficiency in protocol
implementation", RFC 817, July 1982.
[RFC0872] Padlipsky, M., "TCP-on-a-LAN", RFC 872, September 1982.
[RFC0879] Postel, J., "TCP maximum segment size and related topics",
RFC 879, November 1983.
[RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks",
RFC 896, January 1984.
[RFC0964] Sidhu, D. and T. Blumer, "Some problems with the
specification of the Military Standard Transmission
Control Protocol", RFC 964, November 1985.
[RFC1066] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets", RFC
1066, August 1988.
[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the
Internet checksum", RFC 1071, September 1988.
[RFC1072] Jacobson, V. and R. Braden, "TCP extensions for long-delay
paths", RFC 1072, October 1988.
[RFC1156] McCloghrie, K. and M. Rose, "Management Information Base
for network management of TCP/IP-based internets", RFC
1156, May 1990.
[RFC1180] Socolofsky, T. and C. Kale, "TCP/IP tutorial", RFC 1180,
January 1991.
[RFC1185] Jacobson, V., Braden, B., and L. Zhang, "TCP Extension for
High-Speed Paths", RFC 1185, October 1990.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, March 1991.
[RFC1337] Braden, R., "TIME-WAIT Assassination Hazards in TCP", RFC
1337, May 1992.
[RFC1470] Enger, R. and J. Reynolds, "FYI on a Network Management
Tool Catalog: Tools for Monitoring and Debugging TCP/IP
Internets and Interconnected Devices", FYI 2, RFC 1470,
June 1993.
[RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via
Incremental Update", RFC 1624, May 1994.
[RFC1936] Touch, J. and B. Parham, "Implementing the Internet
Checksum in Hardware", RFC 1936, April 1996.
[RFC2012] McCloghrie, K., "SNMPv2 Management Information Base for
the Transmission Control Protocol using SMIv2", RFC 2012,
November 1996.
[RFC2398] Parker, S. and C. Schmechel, "Some Testing Tools for TCP
Implementors", RFC 2398, August 1998.
[RFC2415] Poduri, K. and K. Nichols, "Simulation Studies of
Increased Initial TCP Window Size", RFC 2415, September
1998.
[RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With
Four Packets Into Only Three Buffers", RFC 2416, September
1998.
[RFC2452] Daniele, M., "IP Version 6 Management Information Base for
the Transmission Control Protocol", RFC 2452, December
1998.
[RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP
Over Satellite Channels using Standard Mechanisms", BCP
28, RFC 2488, January 1999.
[RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner,
J., Heavens, I., Lahey, K., Semke, J., and B. Volz, "Known
TCP Implementation Problems", RFC 2525, March 1999.
[RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N.
Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D.,
Henderson, T., Heidemann, J., Touch, J., Kruse, H.,
Ostermann, S., Scott, K., and J. Semke, "Ongoing TCP
Research Related to Satellites", RFC 2760, February 2000.
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
Explicit Congestion Notification (ECN) in IP Networks",
RFC 2884, July 2000.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135, June 2001.
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret,
"End-to-end Performance Implications of Slow Links", BCP
48, RFC 3150, July 2001.
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N.
Vaidya, "End-to-end Performance Implications of Links with
Errors", BCP 50, RFC 3155, August 2001.
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful",
BCP 60, RFC 3360, August 2002.
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on
link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366,
August 2002.
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
Sooriyabandara, "TCP Performance Implications of Network
Path Asymmetry", BCP 69, RFC 3449, December 2002.
[RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and
F. Khafizov, "TCP over Second (2.5G) and Third (3G)
Generation Wireless Networks", BCP 71, RFC 3481, February
2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC
3493, February 2003.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004.
[RFC4022] Raghunarayan, R., "Management Information Base for the
Transmission Control Protocol (TCP)", RFC 4022, March
2005.
10.6. Informative References Outside the RFC Series
[JK92] Jacobson, V. and M. Karels, "Congestion Avoidance and
Control", This paper is a revised version of [Jac88], that
includes an additional appendix. This paper has not been
traditionally published, but is currently available at
ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. 1992.
[Jac88] Jacobson, V., "Congestion Avoidance and Control", ACM
SIGCOMM 1988 Proceedings, in ACM Computer Communication
Review, 18 (4), pp. 314-329, August 1988.
[KP87] Karn, P. and C. Partridge, "Round Trip Time Estimation",
ACM SIGCOMM 1987 Proceedings, in ACM Computer
Communication Review, 17 (5), pp. 2-7, August 1987
[MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring the
Evolution of Transport Protocols in the Internet", ACM
Computer Communication Review, 35 (2), April 2005.
[MM96] Mathis, M. and J. Mahdavi, "Forward Acknowledgement:
Refining TCP Congestion Control", ACM SIGCOMM 1996
Proceedings, in ACM Computer Communication Review 26 (4),
pp. 281-292, October 1996.
[SCWA99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29 (5), pp. 71-78, October
1999.
Authors’ Addresses
Martin H. Duke
The Boeing Company
PO Box 3707, MC 7L-49
Seattle, WA 98124-2207
Phone: 425-373-2852
EMail: martin.duke@boeing.com
Robert Braden
USC Information Sciences Institute
Marina del Rey, CA 90292-6695
Phone: 310-448-9173
EMail: braden@isi.edu
Wesley M. Eddy
Verizon Federal Network Systems
21000 Brookpark Rd, MS 54-5
Cleveland, OH 44135
Phone: 216-433-6682
EMail: weddy@grc.nasa.gov
Ethan Blanton
Purdue University Computer Science
250 N. University St.
West Lafayette, IN 47907
EMail: eblanton@cs.purdue.edu
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at