Shepherd writeup
draft-ietf-tcpm-2140bis-11

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.
Back