TCP Control Block Interdependence
draft-ietf-tcpm-2140bis-11

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
Nothing critical, but, the abstract is mostly cut & paste of the introduction. Could it be made more concise ?

-- Section 1 --
"as often used in the World-Wide Web", references are really outdated and we may expect/hope that H3/QUIC will represent soon the majority of the connections.

"TCP segments having the same host-pair experience the same path properties" does this assumption stand in an ECMP world ? A reference to section 8.1 would be useful.

-- Section 8.1 --
"e.g., the connections could be given the same IPv6 flow label" suggest to add a reference to RFC 6437


== NITS ==

-- Section 2 --
I am always puzzled by the use of BCP 14 boilerplate for an informational document, but, no need to change/reply.

[Ballot comment]
Thanks for this document, I found it to be an interesting and pleasant read, and thank you for bringing RFC 2140 up to date.

[Ballot discuss]
"Appendix C", paragraph 1, discuss:
> Appendix C: Automating the Initial Window in TCP over Long Timescales

The content of this appendix seems to be unrelated to TCB sharing and reads like
a separate document - why is it included in this document?

[Ballot comment]
Paragraph 5, comment:
>    This document may contain material from IETF Documents or IETF
>    Contributions published or made publicly available before November
>    10, 2008. The person(s) controlling the copyright in some of this
>    material may not have granted the IETF Trust the right to allow
>    modifications of such material outside the IETF Standards Process.

Joe, you were the single author of RFC2140. Would you grant BCP78 rights in
RFC2140 to the IETF Trust? In that case, we don't need to keep the special
pre-RFC5378 boilerplate.

Section 1, paragraph 2, comment:
>    across connections to the same host [RFC2140]. Such sharing is
>    intended to lead to better overall transient performance, especially
>    for numerous short-lived and simultaneous connections, as often used
>    in the World-Wide Web [Be94][Br02]. This sharing of state is

The modern web is using a lot fewer parallel connections compared to the web at
the time RFC 2140 was written. So the example is slightly dated.

Section 9.1, paragraph 1, comment:
> 9.1. Layering

The first paragraph in this section says "RTT information is better handled at
the network layer", the second paragraph says "there are problems with handling
RTT information at the network later" - which is it?

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 4, paragraph 3, nit:
>                cong. window size (sendcwnd)*
>                cong. window size threshold (ssthresh)*

Expand "cong."? Abbreviation not used elsewhere in the document.

Section 7, paragraph 1, nit:
> 7. Ensemble Sharing

Might want to cite https://dl.acm.org/doi/10.1145/505688.505691 for Ensemble
TCP.

Section 7.1, paragraph 11, nit:
>                sum(old_sendcwnd)  f(sum(old_sendcwnd), N)
> _
>                old_option          (option specific)

Why is there a dash here?

Section 10, paragraph 3, nit:
>    caches in order to maintain TCB states (see 0).
>

Broken reference.

Section 10, paragraph 2, nit:
>    The table below describes the current implementation status for TCB
>    temporal sharing in Windows as of December 2020, Linux kernel
>    version 5.10.3, and FreeBSD 12. Ensemble sharing is not yet
>    implemented.

Table also talks about Apple and Windows stacks.

Section 1, paragraph 2, nit:
-    implementations can (and now do) share certain TCB information
-                  -----------------
+    implementations share certain TCB information

Section 4, paragraph 6, nit:
-    some TCP options are negotiated only upon application layer request,
-                                                        ^
+    some TCP options are negotiated only upon an application-layer request,
+                                              +++          ^

Section 7.2, paragraph 8, nit:
-      old_RTT      curr_RTT      update    rtt_update(old,curr)
+      old_RTT      curr_RTT      update    rtt_update(old, curr)
+                                                            +

Section 7.2, paragraph 9, nit:
-      old_RTTVAR  curr_RTTVAR  update    rtt_update(old,curr)
+      old_RTTVAR  curr_RTTVAR  update    rtt_update(old, curr)
+                                                            +

Section 7.3, paragraph 5, nit:
-    implementations initialize it to four segments as standard [rfc3390]
-                                                                ^^^
+    implementations initialize it to four segments as standard [RFC3390]
+                                                                ^^^

Section 9, paragraph 2, nit:
-    RTT, and congestion window values. By avoiding the so-called, "slow-
-                                                                -
-    start restart," performance can be optimized [Hu01]. TCB
-                  -
+    RTT, and congestion window values. By avoiding the so-called "slow-
+    start restart", performance can be optimized [Hu01]. TCB
+                +

Section 9, paragraph 3, nit:
-    connections begin or end. Other mechanisms have since been proposed
-                                                    ------
+    connections begin or end. Other mechanisms have been proposed

Section 9.1, paragraph 2, nit:
-    information could be more appropriately handled in a network-layer
-                                                    ^^ ^
-    fashion, aggregated among concurrent connections, and shared across
-  ---------
+    information could be more appropriately handled at the network-layer,
+                                                    ^^ ^^^              +
+    aggregated among concurrent connections, and shared across

[Ballot comment]
Thanks to the shepherd for the very helpful writeup!

Section 3

  +RTTVAR - variance of round-trip times of a TCP packet exchange
  [RFC6298]

nit: in RFC 6298 this is "round-trip time variation", which to me is a more
useful description, since it is not a standard statistical averaged
squared deviation.

Section 6.2

A forward reference to where the "merge()" operation is discussed would
be helpful.

  During the connection, the associated TCB can be updated based on
  particular events, as shown below:

nit(?): should we s/associated TCB/assoicated TCB cache/?  (Likewise for
§6.2.)

Section 9

  confirmation, etc.) [RFC3124]. By dealing exclusively with
  transients, TCB interdependence is more likely to exhibit the same
  behavior as unmodified, independent TCP connections.

Is this the "same behavior" in the steady-state?  There seem to be
obvious (intentional) differences in behavior at startup.

Section 10

  The observation that some TCB state is host-pair specific rather
  than application-pair dependent is not new and is a common
  engineering decision in layered protocol implementations. Although
  now deprecated, T/TCP [RFC1644] was the first to propose using
  caches in order to maintain TCB states (see 0).

"see 0" feels like a broken automation for referencing Appendix A.
(Also occurs in Section 11 for the same T/TCP topic.)

Section 11

(nit) this feels more like a "changes from RFC 2140" section than an
"updates to RFC 2140" section, to me.

Appendix B

A reference to the IANA registry might help the reader make sense of
some of these option names.

Appendix C

  Temporal sharing, as described earlier in this document, builds on
  the assumption that multiple consecutive connections between the
  same host pair are somewhat likely to be exposed to similar
  environment characteristics. The stored information can therefore
  become invalid over time, and suitable precautions should be taken

nit: I don't think the preceding sentence justifies the use of
"therefore" here.

Appendix C.2

  environment, can always use a different value. In specific,
  information from previous connections, or sets of connections with a
  similar path, can already be used as context for such decisions (as
  noted in the core of this document).

nit: it feels like there might be a missing word here, perhaps
"situations" after "specific"?  Or perhaps just s/specific/particular/?

Appendix C.3

  1. On boot:

      IW = MaxIW; # assume this is in bytes, and an even number of MSS

nit: is "even number" intended to mean "integral multiple"?

  A number of additional constraints need to be imposed if this
  mechanism is implemented to ensure that it defaults values that

nit: singular/plural mismatch (maybe "it defaults to values"?)

Appendix C.4

  reasons (e.g., the ISN is used in TCP-AO [RFC5925]). The mechanism
  also benefits from persistent state kept across reboots, as would be
  other state sharing mechanisms (e.g., TCP Control Block Sharing
  [RFC2140]). The mechanism is inspired by RFC 2140's use of
  information across connections.

It feels strange for some reason to reference RFC 2140 here when this
document obsoletes RFC 2140.

[Ballot comment]
[ section C.1 ]

* "typical Internet connection"

  The computation given (1460) is for a typical Internet IPv4 connection, or
  IPv4 Internet connection.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-tcpm-2140bis-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-02-22):

From: The IESG
To: IETF-Announce
CC: Michael Scharf , draft-ietf-tcpm-2140bis@ietf.org, martin.h.duke@gmail.com, michael.scharf@hs-esslingen.de, tcpm-chairs@ietf.org, tcpm@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (TCP Control Block Interdependence) to Informational RFC


The IESG has received a request from the TCP Maintenance and Minor Extensions
WG (tcpm) to consider the following document: - 'TCP Control Block
Interdependence'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-02-22. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This memo provides guidance to TCP implementers that are intended to
  help improve convergence to steady-state operation without affecting
  interoperability. It updates and replaces RFC 2140's description of
  interdependent TCP control blocks and the ways that part of TCP
  state can be shared among similar concurrent or consecutive
  connections. TCP state includes a combination of parameters, such as
  connection state, current round-trip time estimates, congestion
  control information, and process information. Most of this state is
  maintained on a per-connection basis in the TCP Control Block (TCB),
  but implementations can (and do) share certain TCB information
  across connections to the same host. Such sharing is intended to
  improve overall transient transport performance, while maintaining
  backward-compatibility with existing implementations. The sharing
  described herein is limited to only the TCB initialization and so
  has no effect on the long-term behavior of TCP after a connection
  has been established.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/



No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Michael Scharf .

The responsible Area Director is Martin Duke .

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.

1. Summary

The document shepherd is Michael Scharf .

The responsible Area Director is Martin Duke .

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.