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 informational document describes TCP Control Block Interdependence, i.e.
sharing of a part of TCP state among similar concurrent or consecutive
connections. Many TCP implementations use such sharing to help improve
convergence to steady-state operation. The memo documents known caching
mechanisms and provides guidance to TCP implementers.
2140bis updates and replaces RFC 2140's description of interdependent TCP
control blocks. The document describes local heuristics inside a TCP endpoint
that do not affect interoperability between different TCP implementations. As
described in the document, different TCP/IP stacks internally cache different
TCP parameters, and there is no known best approach. As a result, 2140bis is
submitted as informational document, like RFC 2140.
2. Review and Consensus
The document is an outcome of the TCPM working group and has been discussed in
TCPM for a long time. There is strong consensus in the TCPM working group that
an up-to-date description of TCP Control Block Interdependence is useful -
instead of the outdated content of RFC 2140. Section 11 describes the updates
compared to RFC 2140. Various TCP implementers provided feedback about actually
implemented mechanisms and contributed e.g. to the summary in Section 10.
Before adoption in TCPM there were discussions about the target status of this
document, most notably about the question whether to publish 2140bis as BCP.
However, many implementers pushed back against a BCP in this space, given that
there is no known "best" caching heuristic and different operating systems have
successfully used different strategies for a long time. As different choices by
implementers do not result in interoperability issues, there is no apparent
need for normative IETF guidance. As a result, the TCPM consensus is to update
and replace the informational RFC 2140 by an informational document.
A small number of TCPM contributors has performed comprehensive reviews of the
document, both before and during WGLC. Given the informational status, parts of
the working group may not care much about the content of the document.
Nonetheless, the shepherd believes that there is strong consensus in the TCPM
working group to publish the main body of the document as informational RFC, as
it contains valuable information on how to efficiently implement TCP.
A notable exception is appendix C, which is based on text from an expired
individual Internet-Draft (draft-touch-tcpm-automatic-iw), for which there is
no known implementation at the time of publication. During and after WGLC, some
TCPM contributors expressed concerns about appendix C and in particular about
its length. While everybody agrees that it makes sense to discuss sharing of
the TCP initial window in this document, small parts of the TCPM working group
believe that a link to the expired draft and some summary discussion would be
sufficient instead of a full specification of the algorithm. Some improvements
in the appendix were made to address these WGLC comments, but the authors
prefer to keep a full description of an algorithm in appendix C instead of a
summary only. All in all, this discussion was between a small number of TCPM
contributors only. The vast majority in the TCPM working group stays silent on
that question.
The TCPM consensus whether to include a full description of an example
algorithm in appendix C is rough, and, as a result, appendix C has no strong
backing inside the TCPM working group. Nonetheless, the example in appendix C
is only a minor part of the overall document.
3. Intellectual Property
Each author has stated that their direct, personal knowledge of any IPR related
to this document has already been disclosed, in conformance with BCPs 78 and 79.
4. Other Points
There are no significant id-nits problems. There are a couple of warnings about
obsolete informational references, but all these references are included
intentionally in order to provide historical context.
This 2140bis document had to consider no erratas, as there are no known erratas
for RFC 2140.