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

From: Lars Eggert via Datatracker <[email-masked]>
Date: Thu, 25 Mar 2021 02:23:52 -0700

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

---

From: "Scharf, Michael" <[email-masked]>
Date: Thu, 25 Mar 2021 09:30:27 +0000

For what it is worth, the shepherd write-up contains a summary of the TCPM discussions regarding inclusion of Appendix C.

Michael

---

From: Joseph Touch <[email-masked]>
Date: Thu, 25 Mar 2021 14:21:43 -0700

Hi, Lars,

Thanks for the comments. 

Most will be included in the update, but I want to address two below briefly:

> On Mar 25, 2021, at 2:23 AM, Lars Eggert via Datatracker <[email-masked]> wrote:
> 
> ...

Appendix C is TCB temporal sharing aggregated over long timescales and many endpoints to overcome the repeated need to statically update TCP’s IW. The intro there will be updated to make this much more explicit.

> RFC2140 to the IETF Trust?

I have been asked this before and declined. My position has not changed, so the boilerplate needs to remain.

> In that case, we don't need to keep the special
> pre-RFC5378 boilerplate.
> 

Can you clarify? All modern browsers are configured to allow 8-10 parallel connections, which is actually higher than when 2140 was written (it was half that).

> RTT information at the network later" - which is it?

The latter; the former should say “is better informed by the transport layer but aggregated across connections. The latter is typically performed a the network layer but there are problems...”. 
(I’ll clean that up to be more clear).

It’s just a typo.

(The rest of the diffs will be incorporated)

Joe

---

From: Lars Eggert <[email-masked]>
Date: Mon, 29 Mar 2021 09:23:30 +0300

Hi,

> I have been asked this before and declined. My position has not changed, so the boilerplate needs to remain.

sure. I just thought I'd ask.

> Can you clarify? All modern browsers are configured to allow 8-10 parallel connections, which is actually higher than when 2140 was written (it was half that).

With H2 and H3, all all Chrome-based browsers and Firefox use a default of one connection per server. With H1, the default of those browsers seems to be six. But H2/H3 are 3/4 of all traffic by some measures (e.g., https://radar.cloudflare.com/). So I stand by my argument.

Thanks,
Lars

---

From: Joseph Touch <[email-masked]>
Date: Mon, 29 Mar 2021 13:15:08 -0700

> On Mar 28, 2021, at 11:23 PM, Lars Eggert <[email-masked]> wrote:
> 
> With H2 and H3, all all Chrome-based browsers and Firefox use a default of one connection per server. With H1, the default of those browsers seems to be six. But H2/H3 are 3/4 of all traffic by some measures (e.g., https://radar.cloudflare.com/ <https://radar.cloudflare.com/>). So I stand by my argument.

Agreed, but I would note that:

	- the compartmentalization of the Internet means that we don’t know if we’re seeing an accurate representation
		CDNs hide traffic from many network taps
	- although chrome and Firefox may do this, they’re not the only browsers and web traffic isn’t the only TCP traffic
		Netflix and Amazon Prime both use TCP too; I’d bet they are a LOT more traffic (and Netflix uses multiple connections for a single stream)

I’ll update this to address both points.

Joe