draft-ietf-tcpm-tcp-roadmap-02.txt   draft-ietf-tcpm-tcp-roadmap-03.txt 
Network Working Group M. Duke Network Working Group M. Duke
Internet-Draft Boeing Phantom Works Internet-Draft Boeing Phantom Works
Expires: October 7, 2005 R. Braden Expires: October 28, 2005 R. Braden
USC Information Sciences Institute USC Information Sciences Institute
W. Eddy W. Eddy
NASA GRC/Verizon FNS NASA GRC/Verizon FNS
E. Blanton E. Blanton
Purdue University Purdue University
April 5, 2005 April 26, 2005
A Roadmap for TCP Specification Documents A Roadmap for TCP Specification Documents
draft-ietf-tcpm-tcp-roadmap-02 draft-ietf-tcpm-tcp-roadmap-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 7, 2005. This Internet-Draft will expire on October 28, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document contains a "roadmap" to the Requests for Comments (RFC) This document contains a "roadmap" to the Requests for Comments (RFC)
documents relating to the Internet's Transmission Control Protocol documents relating to the Internet's Transmission Control Protocol
(TCP). This roadmap provides a brief summary of the documents (TCP). This roadmap provides a brief summary of the documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
3.2 SACK-based Loss Recovery and Congestion Control . . . . . 10 3.2 SACK-based Loss Recovery and Congestion Control . . . . . 10
3.3 Dealing with Forged Segments . . . . . . . . . . . . . . . 10 3.3 Dealing with Forged Segments . . . . . . . . . . . . . . . 10
4. Experimental Extensions . . . . . . . . . . . . . . . . . . 12 4. Experimental Extensions . . . . . . . . . . . . . . . . . . 12
5. Historic Extensions . . . . . . . . . . . . . . . . . . . . 15 5. Historic Extensions . . . . . . . . . . . . . . . . . . . . 15
6. Support Documents . . . . . . . . . . . . . . . . . . . . . 17 6. Support Documents . . . . . . . . . . . . . . . . . . . . . 17
6.1 Foundational Works . . . . . . . . . . . . . . . . . . . . 17 6.1 Foundational Works . . . . . . . . . . . . . . . . . . . . 17
6.2 Difficult Network Environments . . . . . . . . . . . . . . 18 6.2 Difficult Network Environments . . . . . . . . . . . . . . 18
6.3 Implementation Advice . . . . . . . . . . . . . . . . . . 20 6.3 Implementation Advice . . . . . . . . . . . . . . . . . . 20
6.4 Management Information Bases . . . . . . . . . . . . . . . 22 6.4 Management Information Bases . . . . . . . . . . . . . . . 22
6.5 Tools and Tutorials . . . . . . . . . . . . . . . . . . . 23 6.5 Tools and Tutorials . . . . . . . . . . . . . . . . . . . 23
6.6 Case Studies . . . . . . . . . . . . . . . . . . . . . . . 23 6.6 Case Studies . . . . . . . . . . . . . . . . . . . . . . . 24
7. Undocumented TCP Features . . . . . . . . . . . . . . . . . 25 7. Undocumented TCP Features . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . 27
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1 Basic Functionality . . . . . . . . . . . . . . . . . . 29 10.1 Basic Functionality . . . . . . . . . . . . . . . . . . 29
10.2 Standard Enhancements . . . . . . . . . . . . . . . . . 29 10.2 Standard Enhancements . . . . . . . . . . . . . . . . . 29
10.3 Experimental Extensions . . . . . . . . . . . . . . . . 30 10.3 Experimental Extensions . . . . . . . . . . . . . . . . 30
10.4 Historic Extensions . . . . . . . . . . . . . . . . . . 31 10.4 Historic Extensions . . . . . . . . . . . . . . . . . . 31
10.5 Support Documents . . . . . . . . . . . . . . . . . . . 31 10.5 Support Documents . . . . . . . . . . . . . . . . . . . 31
10.6 Informative References Outside the RFC Series . . . . . 34 10.6 Informative References Outside the RFC Series . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . 36
1. Introduction 1. Introduction
A correct and efficient implementation of the Transmission Control A correct and efficient implementation of the Transmission Control
Protocol (TCP) is a critical part of the software of most Internet Protocol (TCP) is a critical part of the software of most Internet
hosts. As TCP has evolved over the years, many distinct documents hosts. As TCP has evolved over the years, many distinct documents
have become part of the accepted standard for TCP. At the same time, have become part of the accepted standard for TCP. At the same time,
a large number of more experimental modifications to TCP have also a large number of more experimental modifications to TCP have also
been published in the RFC series, along with informational notes, been published in the RFC series, along with informational notes,
skipping to change at page 5, line 38 skipping to change at page 5, line 38
series of developmental TCP specifications, starting in the series of developmental TCP specifications, starting in the
Internet Experimental Notes (IENs) and continuing in the RFC Internet Experimental Notes (IENs) and continuing in the RFC
series. series.
RFC 1122 S: "Requirements for Internet Hosts - Communication Layers" RFC 1122 S: "Requirements for Internet Hosts - Communication Layers"
(October 1989) (October 1989)
This document [RFC1122] updates and clarifies RFC 793, fixing some This document [RFC1122] updates and clarifies RFC 793, fixing some
specification bugs and oversights. It also explains some features specification bugs and oversights. It also explains some features
such as keep-alives and Karn's and Jacobson's RTO estimation such as keep-alives and Karn's and Jacobson's RTO estimation
algorithms [KP87][Jac88]. ICMP interactions are mentioned and algorithms [KP87][Jac88][JK92]. ICMP interactions are mentioned
some tips are given for efficient implementation. RFC 1122 is an and some tips are given for efficient implementation. RFC 1122 is
Applicability Statement, listing the various features that MUST, an Applicability Statement, listing the various features that
SHOULD, MAY, SHOULD NOT, and MUST NOT be present in MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT be present in
standards-conforming TCP implementations. Unlike a purely standards-conforming TCP implementations. Unlike a purely
informational "roadmap", this Applicability Statement is a informational "roadmap", this Applicability Statement is a
standards document, and gives formal rules for implementation. standards document, and gives formal rules for implementation.
RFC 2460 S: "Internet Protocol, Version 6 (IPv6) Specification RFC 2460 S: "Internet Protocol, Version 6 (IPv6) Specification
(December 1998) (December 1998)
This document [RFC2460] is of relevance to TCP because it defines This document [RFC2460] is of relevance to TCP because it defines
how the pseudo-header for TCP's checksum computation is derived, how the pseudo-header for TCP's checksum computation is derived,
when 128-bit IPv6 addresses are used instead of 32-bit IPv4 when 128-bit IPv6 addresses are used instead of 32-bit IPv4
skipping to change at page 6, line 39 skipping to change at page 6, line 39
fairness among competing flows. fairness among competing flows.
RFC 2675 S: "IPv6 Jumbograms" (August 1999) RFC 2675 S: "IPv6 Jumbograms" (August 1999)
IPv6's support for longer datagrams than were allowed in IPv4, IPv6's support for longer datagrams than were allowed in IPv4,
necessitated some changes to the way that TCP's MSS and Urgent necessitated some changes to the way that TCP's MSS and Urgent
fields (both 16 bits) are treated. This document [RFC2675] fields (both 16 bits) are treated. This document [RFC2675]
explains those changes. While it describes changes to basic explains those changes. While it describes changes to basic
header semantics, these changes should only affect the use of very header semantics, these changes should only affect the use of very
large segments, such as IPv6 jumbograms, which are rarely used. large segments, such as IPv6 jumbograms, which are rarely used.
Supporting this document does not affect interoperability with
TCPs when using IPv4 or non-jumbogram IPv6.
RFC 2873 S: "TCP Processing of the IPv4 Precendence Field" (June RFC 2873 S: "TCP Processing of the IPv4 Precendence Field" (June
2000) 2000)
This document [RFC2873] removes from the TCP specification all This document [RFC2873] removes from the TCP specification all
processing of the precedence bits of the TOS byte of the IP processing of the precedence bits of the TOS byte of the IP
header. This resolves a conflict over the use of these bits header. This resolves a conflict over the use of these bits
between RFC 793 and Differentiated Services. between RFC 793 and Differentiated Services [RFC2474].
RFC 2988 S: "Computing TCP's Retransmission Timer" (November 2000) RFC 2988 S: "Computing TCP's Retransmission Timer" (November 2000)
Abstract: "This document defines the standard algorithm that Abstract: "This document defines the standard algorithm that
Transmission Control Protocol (TCP) senders are required to use to Transmission Control Protocol (TCP) senders are required to use to
compute and manage their retransmission timer. It expands on the compute and manage their retransmission timer. It expands on the
discussion in section 4.2.3.1 of RFC 1122 and upgrades the discussion in section 4.2.3.1 of RFC 1122 and upgrades the
requirement of supporting the algorithm from a SHOULD to a MUST." requirement of supporting the algorithm from a SHOULD to a MUST."
[RFC2988] [RFC2988]
skipping to change at page 11, line 7 skipping to change at page 11, line 7
3.3 Dealing with Forged Segments 3.3 Dealing with Forged Segments
By default, TCP lacks any cryptographic structures to differentiate By default, TCP lacks any cryptographic structures to differentiate
legitimate segments and those spoofed from malicious hosts. Spoofing legitimate segments and those spoofed from malicious hosts. Spoofing
valid segments requires correctly guessing a number of fields. The valid segments requires correctly guessing a number of fields. The
documents in this sub-section describe ways to make that guessing documents in this sub-section describe ways to make that guessing
harder, or prevent it from being able to negatively impact a harder, or prevent it from being able to negatively impact a
connection. connection.
The TCPM working group is currently in progress towards fully
understanding and defining mechanisms for preventing spoofing attacks
(including both spoofed TCP segments and ICMP datagrams). Some of
the solutions being considered rely on TCP modifications, while
others rely on security at lower layers (like IPsec) for protection.
RFC 1948 I: "Defending Against Sequence Number Attacks" (May 1996) RFC 1948 I: "Defending Against Sequence Number Attacks" (May 1996)
This document [RFC1948] describes the TCP vulnerability based upon This document [RFC1948] describes the TCP vulnerability based upon
guessing sequence numbers, as well as defenses against guessing sequence numbers, as well as defenses against
exploitation. Some variation is implemented in most exploitation. Some variation is implemented in most
currently-used operating systems. currently-used operating systems.
RFC 2385 S: "Protection of BGP Sessions via the TCP MD5 Signature RFC 2385 S: "Protection of BGP Sessions via the TCP MD5 Signature
Option" (August 1998) Option" (August 1998)
skipping to change at page 11, line 34 skipping to change at page 11, line 40
segment, incorporating information known only to the connection segment, incorporating information known only to the connection
end points. Since BGP uses TCP as its transport, using this end points. Since BGP uses TCP as its transport, using this
option in the way described in this paper significantly reduces option in the way described in this paper significantly reduces
the danger from certain security attacks on BGP." [RFC2385] the danger from certain security attacks on BGP." [RFC2385]
TCP MD5 options are currently only used in very limited contexts, TCP MD5 options are currently only used in very limited contexts,
primarily for defending BGP exchanges between routers. Some primarily for defending BGP exchanges between routers. Some
deployment notes for those using TCP MD5 are found in the later deployment notes for those using TCP MD5 are found in the later
RFC 3562, "Key Management Considerations for the TCP MD5 Signature RFC 3562, "Key Management Considerations for the TCP MD5 Signature
Option" [RFC3562]. A draft that is currently in the RFC Editor's Option" [RFC3562]. A draft that is currently in the RFC Editor's
queue for publication (draft-iesg-tcpmd5app-01) deprecates TCP MD5 queue for publication (draft-iesg-tcpmd5app) deprecates TCP MD5
for use outside BGP. for use outside BGP.
The TCPM working group is currently in progress towards fully
understanding and defining mechanisms for preventing spoofing
attacks (including both spoofed TCP segments and ICMP datagrams).
Some of the solutions being considered rely on TCP modifications,
while others rely on security at lower layers (like IPsec) for
protection.
4. Experimental Extensions 4. Experimental Extensions
The RFCs in this section are still experimental, but may become The RFCs in this section are still experimental, but may become
proposed standards in the future. At least part of the reason that proposed standards in the future. At least part of the reason that
they are still experimental is to gain more wide-scale experience they are still experimental is to gain more wide-scale experience
with them before making a standards track decision. By their with them before making a standards track decision. By their
publication as experimental RFCs, it is hoped that the community of publication as experimental RFCs, it is hoped that the community of
TCP researchers will analyze and test the contents of these RFCs. TCP researchers will analyze and test the contents of these RFCs.
Although encouraged for experimentation, there is not yet formal Although encouraged for experimentation, there is not yet formal
consensus that these are fully logical and safe behaviors. consensus that these are fully logical and safe behaviors.
Wide-scale deployment of implementations that use these features Wide-scale deployment of implementations that use these features
should be well thought-out in terms of consequences. should be well thought-out in terms of consequences.
RFC 2140 I: "TCP Control Block Interdependence" (April 1997) RFC 2140 I: "TCP Control Block Interdependence" (April 1997)
This document [RFC2140] suggests how TCP connections between the This document [RFC2140] suggests how TCP connections between the
same endpoints might share information, such as their congestion same endpoints might share information, such as their congestion
control state. To some degree, this is done in practice by a few control state. To some degree, this is done in practice by a few
operating systems; for example, Linux currently has a destination operating systems; for example, Linux currently has a destination
cache. cache. Although this RFC is technically informational, the
concepts it describes are in experimental use, so we include it in
this section.
A related proposal, the Congestion Manager, is specified in RFC A related proposal, the Congestion Manager, is specified in RFC
3124 [RFC3124]. The idea behind the Congestion Manager, moving 3124 [RFC3124]. The idea behind the Congestion Manager, moving
congestion control outside of individual TCP connections, congestion control outside of individual TCP connections,
represents a modification to the core of TCP, which supports represents a modification to the core of TCP, which supports
sharing information among TCP connections as well. Although a sharing information among TCP connections as well. Although a
Proposed Standard, some pieces of the Congestion Manager support Proposed Standard, some pieces of the Congestion Manager support
architecture have not been specified yet, and it has not achieved architecture have not been specified yet, and it has not achieved
use or implementation beyond experimental stacks, so it is not use or implementation beyond experimental stacks, so it is not
listed among the standard TCP enhancements in this roadmap. listed among the standard TCP enhancements in this roadmap.
skipping to change at page 19, line 36 skipping to change at page 19, line 36
to use in the global Internet. to use in the global Internet.
RFC 2760 I: "Ongoing TCP Research Related to Satellites" (February RFC 2760 I: "Ongoing TCP Research Related to Satellites" (February
2000) 2000)
This document [RFC2760] discusses the advantages and disadvantages This document [RFC2760] discusses the advantages and disadvantages
of several different experimental means of improving TCP of several different experimental means of improving TCP
performance over long-delay or error-prone paths. These include: performance over long-delay or error-prone paths. These include:
T/TCP, larger initial windows, byte counting, delayed T/TCP, larger initial windows, byte counting, delayed
acknowledgements, slow start thresholds, NewReno and SACK-based acknowledgements, slow start thresholds, NewReno and SACK-based
loss recovery, FACK [FACK], ECN, various corruption-detection loss recovery, FACK [MM96], ECN, various corruption-detection
mechanisms, congestion avoidance changes for fairness, use of mechanisms, congestion avoidance changes for fairness, use of
multiple parallel flows, pacing, header compression, state multiple parallel flows, pacing, header compression, state
sharing, and ACK congestion control, filtering, and sharing, and ACK congestion control, filtering, and
reconstruction. While RFC 2488 looks at standard extensions, this reconstruction. While RFC 2488 looks at standard extensions, this
document focuses on more experimental means of performance document focuses on more experimental means of performance
enhancement. enhancement.
RFC 3135 I: "Performance Enhancing Proxies Intended to Mitigate RFC 3135 I: "Performance Enhancing Proxies Intended to Mitigate
Link-Related Degradations" (June 2001) Link-Related Degradations" (June 2001)
skipping to change at page 21, line 44 skipping to change at page 21, line 44
long-standing black hole problem, stretch acknowlegements (ACKs) long-standing black hole problem, stretch acknowlegements (ACKs)
due to confusion between Maximum Segment Size (MSS) and segment due to confusion between Maximum Segment Size (MSS) and segment
size, and MSS advertisement based on PMTU." [RFC2923] size, and MSS advertisement based on PMTU." [RFC2923]
RFC 3360 B: "Inappropriate TCP Resets Considered Harmful" (August RFC 3360 B: "Inappropriate TCP Resets Considered Harmful" (August
2002) 2002)
This document [RFC3360] is a plea that firewall vendors not send This document [RFC3360] is a plea that firewall vendors not send
gratuitous TCP RST (Reset) packets when unassigned TCP header bits gratuitous TCP RST (Reset) packets when unassigned TCP header bits
are used. This practice prevents desirable extension and are used. This practice prevents desirable extension and
evolution of the protocol and hence is inimical to the future of evolution of the protocol and hence is potentially harmful to the
the Internet. future of the Internet.
RFC 3493 I: "Basic Socket Interface Extensions for IPv6" (February RFC 3493 I: "Basic Socket Interface Extensions for IPv6" (February
2003) 2003)
This document [RFC3493] describes the de facto standard sockets This document [RFC3493] describes the de facto standard sockets
API for programming with TCP. This API is implemented nearly API for programming with TCP. This API is implemented nearly
ubiquitously in modern operating systems and programming ubiquitously in modern operating systems and programming
languages. languages.
6.4 Management Information Bases 6.4 Management Information Bases
skipping to change at page 22, line 19 skipping to change at page 22, line 19
The first MIB module defined for use with SNMP (in RFC 1066 and its The first MIB module defined for use with SNMP (in RFC 1066 and its
update, RFC 1156) was a single monolithic MIB module, called MIB-I. update, RFC 1156) was a single monolithic MIB module, called MIB-I.
This evolved over time to be MIB-II (RFC 1213). It then became This evolved over time to be MIB-II (RFC 1213). It then became
apparent that having a single monolithic MIB module was not scalable, apparent that having a single monolithic MIB module was not scalable,
given the number and breadth of MIB data definitions that needed to given the number and breadth of MIB data definitions that needed to
be included. Thus, additional MIB modules were defined, and those be included. Thus, additional MIB modules were defined, and those
parts of MIB-II which needed to evolve were split off. Eventually, parts of MIB-II which needed to evolve were split off. Eventually,
the remaining parts of MIB-II were also split off, with the the remaining parts of MIB-II were also split off, with the
TCP-specific part being documented in RFC 2012. TCP-specific part being documented in RFC 2012.
RFC 2012 is the primary document for MIB-II. MIB-I, defined in RFC RFC 2012 was obsoleted by RFC 4022, which is the primary TCP MIB
1156, has been obsoleted by the MIB-II specification in RFC 1213 document today. MIB-I, defined in RFC 1156, has been obsoleted by
(updated by 2012). Work is in progress, at the time of this writing, the MIB-II specification in RFC 1213. For current TCP implementers,
on a document that incorporates IPv6 and updates and obsoletes RFC RFC 4022 should be supported.
2012 (currently in the form of draft-ietf-ipv6-rfc2012-update, edited
by Rajiv Raghunarayan, under submission to the IESG as a Proposed
Standard).
RFC 1066: "Management Information Base for Network Management of RFC 1066: "Management Information Base for Network Management of
TCP/IP-based Internets" (August 1988) TCP/IP-based Internets" (August 1988)
This document [RFC1066] was the description of the TCP MIB. It This document [RFC1066] was the description of the TCP MIB. It
was obsoleted by RFC 1156. was obsoleted by RFC 1156.
RFC 1156 S: "Management Information Base for Network Management of RFC 1156 S: "Management Information Base for Network Management of
TCP/IP-based Internets" (May 1990) TCP/IP-based Internets" (May 1990)
skipping to change at page 23, line 7 skipping to change at page 22, line 47
RFC 1213 S: "Management Information Base for Network Management of RFC 1213 S: "Management Information Base for Network Management of
TCP/IP-based Internets: MIB-II" (March 1991) TCP/IP-based Internets: MIB-II" (March 1991)
This document [RFC1213] describes the second version of the MIB in This document [RFC1213] describes the second version of the MIB in
a monolithic form. RFC 2012 updates this document by splitting a monolithic form. RFC 2012 updates this document by splitting
out the TCP-specific portions. out the TCP-specific portions.
RFC 2012 S: "SNMPv2 Management Information Base for the Transmission RFC 2012 S: "SNMPv2 Management Information Base for the Transmission
Control Protocol using SMIv2" (November 1996) Control Protocol using SMIv2" (November 1996)
This document [RFC2012] defined the TCP MIB, in an update to RFC
This document [RFC2012] defines the TCP MIB, updating RFC 1213. 1213. It is now obsoleted by RFC 4022.
RFC 2452 S: "IP Version 6 Management Information Base for the RFC 2452 S: "IP Version 6 Management Information Base for the
Transmission Control Protocol" (December 1998) Transmission Control Protocol" (December 1998)
This document [RFC2452] augments RFC 2012 by adding an This document [RFC2452] augments RFC 2012 by adding an
IPv6-specific connection table. The rest of 2012 holds for any IP IPv6-specific connection table. The rest of 2012 holds for any IP
version. version.
Although it is a standards track document, RFC 2452 is considered Although it is a standards track document, RFC 2452 is considered
a historic mistake by the MIB community, as it is based on the a historic mistake by the MIB community, as it is based on the
idea of parallel IPv4 and IPv6 structures. Although IPv6 requires idea of parallel IPv4 and IPv6 structures. Although IPv6 requires
new structures, the community has decided to define a single new structures, the community has decided to define a single
generic structure for both IPv4 and IPv6. This will aid in generic structure for both IPv4 and IPv6. This will aid in
definition, implementation, and transition between IPv4 and IPv6. definition, implementation, and transition between IPv4 and IPv6.
RFC 4022 S: "Management Information Base for the Transmission Control
Protocol (TCP)" (March 2005)
This document [RFC4022] obsoletes RFC 2012 and RFC 2452, and
specifies the current standard for the TCP MIB that should be
deployed.
6.5 Tools and Tutorials 6.5 Tools and Tutorials
RFC 1180 I: "TCP/IP Tutorial" (January 1991) RFC 1180 I: "TCP/IP Tutorial" (January 1991)
This document [RFC1180] is an extremely brief overview of the This document [RFC1180] is an extremely brief overview of the
TCP/IP protocol suite as a whole. It gives some explanation as to TCP/IP protocol suite as a whole. It gives some explanation as to
how and where TCP fits in. how and where TCP fits in.
RFC 1470 I: "FYI on a Network Management Tool Catalog: Tools for RFC 1470 I: "FYI on a Network Management Tool Catalog: Tools for
Monitoring and Debugging TCP/IP Internets and Interconnected Devices" Monitoring and Debugging TCP/IP Internets and Interconnected Devices"
skipping to change at page 29, line 18 skipping to change at page 29, line 18
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (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 [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999. Control", RFC 2581, April 1999.
[RFC2675] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms", [RFC2675] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999. RFC 2675, August 1999.
[RFC2873] Xiao, X., Hannan, A., Paxson, V. and E. Crabbe, "TCP [RFC2873] Xiao, X., Hannan, A., Paxson, V. and E. Crabbe, "TCP
Processing of the IPv4 Precedence Field", RFC 2873, June Processing of the IPv4 Precedence Field", RFC 2873, June
2000. 2000.
skipping to change at page 34, line 23 skipping to change at page 34, line 26
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, February 2003. RFC 3493, February 2003.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004. 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 10.6 Informative References Outside the RFC Series
[FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgement: [JK92] Jacobson, V. and M. Karels, "Congestion Avoidance and
Refining TCP Congestion Control", ACM SIGCOMM, August 1996. 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 [Jac88] Jacobson, V., "Congestion Avoidance and Control", ACM
SIGCOMM, August 1988. 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", [KP87] Karn, P. and C. Partridge, "Round Trip Time Estimation",
ACM SIGCOMM, August 1987. 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 [MAF04] Medina, A., Allman, M. and S. Floyd, "Measuring the
Evolution of Transport Protocols in the Internet", (under Evolution of Transport Protocols in the Internet", ACM
submission - URL http://www.icir.org/tbit/), December 2004. 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, [SCWA99] Savage, S., Cardwell, N., Wetherall, D. and T. Anderson,
"TCP Congestion Control with a Misbehaving Receiver", ACM "TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review 29 (5), October 1999. Computer Communication Review, 29 (5), pp. 71-78, October
1999.
Authors' Addresses Authors' Addresses
Martin Duke Martin Duke
Boeing Phantom Works Boeing Phantom Works
PO Box 3707, MC 3W-51 PO Box 3707, MC 3W-51
Seattle, WA 98124-2207 Seattle, WA 98124-2207
Phone: 253-657-8203 Phone: 253-657-8203
Email: mduke26@comcast.net Email: mduke26@comcast.net
skipping to change at page 35, line 4 skipping to change at page 35, line 20
Authors' Addresses Authors' Addresses
Martin Duke Martin Duke
Boeing Phantom Works Boeing Phantom Works
PO Box 3707, MC 3W-51 PO Box 3707, MC 3W-51
Seattle, WA 98124-2207 Seattle, WA 98124-2207
Phone: 253-657-8203 Phone: 253-657-8203
Email: mduke26@comcast.net Email: mduke26@comcast.net
Robert Braden Robert Braden
USC Information Sciences Institute USC Information Sciences Institute
Marina del Rey, CA 90292-6695 Marina del Rey, CA 90292-6695
Phone: 310-448-9173 Phone: 310-448-9173
Email: braden@isi.edu Email: braden@isi.edu
Wesley M. Eddy Wesley M. Eddy
NASA GRC/Verizon FNS NASA GRC/Verizon FNS
21000 Brookpark Rd, MS 54-5
Cleveland, OH 44135
Phone: 216-433-6682
Email: weddy@grc.nasa.gov Email: weddy@grc.nasa.gov
Ethan Blanton Ethan Blanton
Purdue University Purdue University
Email: eblanton@cs.purdue.edu Email: eblanton@cs.purdue.edu
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/