Skip to main content

Shepherd writeup
draft-ietf-tcpm-rfc793bis

1. Summary

The document shepherd is Michael Scharf <michael.scharf@hs-esslingen.de>.

The responsible Area Director is Martin Duke <martin.h.duke@gmail.com>.

This document specifies the Transmission Control Protocol (TCP) as "bis"
document to RFC 793. It obsoletes RFC 793 as well as a several other RFCs that
specified additions to RFC 793. It also updates RFC 1122, and it should be
considered as a replacement for the portions of that document dealing with TCP
requirements.

The purpose of this document is to bring together all the IETF Standards Track
changes that have been made to the base TCP functional specification and unify
them into an update of RFC 793. The document focuses on the common basis all
TCP implementations must support to interoperate. With one exception, protocol
modifications compared to RFC 793 are limited to standards-track RFCs or
verified erratas, i.e., changes of TCP standards that already have IETF
consensus.

RFC 793 and RFC 1122 are ubiquitously implemented Internet Standards. The same
applies to 793bis. The TCPM working group requests publication of 793bis on
Standards Track. If approved, the document should replace RFC 793 as "STD 7".

2. Review and Consensus

The TCPM working group has worked on this document for more than 6 years, and
many TCPM contributors have reviewed the specification during that time. In
particular, many TCP implementers have provided detailed comments based on
operational experience. The document was relatively stable in the latest
versions. During and after WGLC, several comprehensive reviews flagged some
open issues that all got resolved.

793bis improves the specification of TCP but it does not modify the TCP
protocol. TCP is a complex protocol and even minor wording details in the
protocol specification can matter. Given the restriction to TCP changes that
already have IETF consensus, there has never been any major controversy about
the main content.

Nonetheless, several questions were non-trivial and triggered longer
discussions in TCPM. These issues can roughly be subdivided in three categories:

1/ Being published in 1981, RFC 793 defines several protocol mechanisms that
have become outdated and may not be implemented at all in a modern TCP/IP
stack. However, in some cases the corresponding specification in RFC 793 never
got updated or obsoleted and is still formally valid. Appendix A.1 summarizes
some of these issues. The TCPM consensus for those cases is to document the
issues in 793bis, but not to change the TCP standards. The required changes to
the TCP standards should be handled by dedicated, narrow-focused RFCs that
would have to reach IETF consensus first. This de-risk strategy ensures that
each TCP protocol change can be properly and comprehensively reviewed.

2/ There are some known issues in the standards-track specification of TCP that
exist but only matter in corner cases. An example is documented in Appendix
A.2. In Internet usage of TCP, these conditions are rarely occurring. Common
operating systems include different alternative mitigations, and the standard
has not been updated yet to codify one of them. Also, there is no known best
approach. Given the lack of practical relevance, the TCPM consensus is to
describe these known problems, but not to change the TCP standards in 793bis.
Again, these problems could be solved by future, dedicated, narrow-focused RFCs
that would have to reach IETF consensus first.

3/ There are known deviations between mandatory-to-implement requirements in
the TCP standard and some widely deployed implementations. An example are some
details in Section 3.8.3, such as the numerical value in MUST-23. Those cases
typically do not affect interoperability with other implementations. The TCPM
working group has discussed whether to change the standard in such cases (e.g.,
downgrade MUST-23 to a SHOULD), but finally refrained from going down that road
in 793bis, given the huge installed base with a very large variety of TCP
implementations. Similar like in the previous cases, 793bis may get updated by
narrow-focused RFCs.

There is one important exception to the decision not to include new guidance in
793bis. The exception is Section 3.8.2 "TCP Congestion Control". TCP congestion
control was developed after publication of RFC 793 and the state-of-the-art has
evolved a lot as compared to RFC 1122. While there are numerous RFCs that
specify TCP congestion control, there is no clear normative guidance on the
required minimum in all TCP implementations that would be appropriate for
793bis. However, 793bis cannot just stay silent on congestion control. Given
the lack of other applicable wording in existing standards, Section 3.8.2
includes new text and is therefore different to the rest of the document.
Section 3.8.2 was comprehensively reviewed by the TCPM working group and in
particular by TCP implementers. The section is short and straightforward, and
the wording was chosen very carefully to reflect existing TCP standards and
operational experience in the Internet. Also, given ongoing research, TCP
congestion control will most likely further evolve in future. Section 3.8.2
enables such a further evolution while defining important base requirements.

Running code exists - in billions of devices across numerous TCP/IP stacks.
Given the very limited scope of modifications in the 793bis document, all TCP
implementations that are already compliant to the TCP standards before
publication of 793bis should be compliant to 793bis as well.

The shepherd believes that the 793bis document has unanimous support from the
entire TCPM working group.

3. Intellectual Property

The editor has stated that his direct, personal knowledge of any IPR related to
this document has already been disclosed, in conformance with BCPs 78 and 79.
The editor is not aware of any IPR relevant for the base TCP protocol. Since
793bis does not change the TCP protocol, relevant IPR would have to be
disclosed already for the existing RFCs included in 793bis.

There is a Cisco IPR disclosure from year 2004 related to the Internet-Draft
that resulted in RFC 5961 (https://datatracker.ietf.org/ipr/421/). RFC 5961 is
one source of changes included in 793bis. In all places in 793bis where the
recommendations from RFC 5961 are mentioned, 5961 is prominently referenced.
RFC 5961 mostly affects MAY-12 in 793bis, i.e., the changes described in RFC
5961 are optional and not mandatory-to-implement.

It has been suggested that the owner of the IPR disclosed in
https://datatracker.ietf.org/ipr/421/ updates the IPR disclosure to make clear
whether it applies to 793bis, or not.

The TCPM working group is aware of the IPR disclosure related to RFC 5961,
which is known already for a long time. The document shepherd has verified on
the TCPM mailing list that the TCPM working group is fine with the proposed
text in 793bis related to RFC 5961. In the TCPM working group there are no
known concerns regarding this IPR disclosure related to an optional mechanism.

4. Other Points

The intended status listed in the document is "Standards Track". As all main
TCP implementations are supposed to comply with 793bis, the document may
fulfill the requirements of an "Internet Standard" according to RFC 2026 and
RFC 7127.

idnits reports some warnings, such as obsolete references. These are all false
positives. The document refers to some obsolete documents to provide historical
context.

The IANA section includes many actions:
(1) Update the structure of the TCP flags registry to include a new column
called "Assignment Notes" (2) Rename "Bit" column of the TCP flags registry to
"Bit Offset" (3) Update the TCP flags registry to include all assigned TCP
flags, not only those initially assigned in RFC 3168. 10-15 values are
assigned. (4) Move the existing TCP flags registry to be as sub-registry of the
TCP registry. There was unanimous consensus in TCPM with these changes. The
modifications neither change any allocation nor any policy in the IANA registry.

All errata to RFC 793 and related RFCs have been considered in this "bis"
document.

When Wes started working on a 793bis document in 2013, the document shepherd,
as well as many other TCPM contributors, were pretty convinced that writing a
793bis document is an impossible endeavor. Well, after many years, we are
proven wrong. Many thanks to Wes as editor!
Back