[tcpm] Lars Eggert's Discuss on draft-ietf-tcpm-2140bis-10: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-tcpm-2140bis-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/



----------------------------------------------------------------------
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?


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