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

[ section C.1 ]

* "typical Internet connection"

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

I scanned for ART issue and haven't found any worth bringing up.

Francesca

In Section 10, to what does "(see 0)" refer?

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.

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.

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

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