Subject: [tsvwg] L4S, the endless discussion

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 24 Mar 2021 07:49:31 +0000

Hi

In email threads I read about "Team L4S" and "somebody else's experiment"
like it is just a figment of the imagination in just a few peoples’ mind.
Note that L4S got wide support from the industry at the interim a year ago. 

Still, the whole process seems continue to stall and has done so the last ~2
years. How long can we continue with this ?. 

There are entire email threads started by a few opponents around all things
that can go in the shitter when the L4S experiment starts, but so far I have
seen nothing, nada, zero…. discussion by the opponents around “what can
_we_, the opponents do to remedy these potential issues on our side?”. 
Instead all I see is that the burden of proof is put on "Team L4S". I can
understand that this situation is the normal in the initial phase but now we
are soon into a 2 year long infected debate that does not seem to show any
evidence to end. 

To me all this just look like a very long filibuster. I mean, at some stage
we need to move on, or ?.  

/Ingemar

================================

Ingemar Johansson  M.Sc. 

Master Researcher

Ericsson Research

RESEARCHER

GFTL ER NAP NCM Netw Proto & E2E Perf

Labratoriegränd 11

977 53, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

[email-masked]

www.ericsson.com <http://www.ericsson.com/> 

=================================

---

From: Sebastian Moeller <[email-masked]>
Date: Wed, 24 Mar 2021 10:09:06 +0100

Hi Ingemar,

"figment of the imagination" is veering into personal insults territory, I do not think this is where this discussion should to go if the goal is to actually improve the drafts. 

> On Mar 24, 2021, at 08:49, Ingemar Johansson S <ingemar.s.johansson=[email-masked]> wrote:
> 
> Hi
>  
> In email threads I read about "Team L4S" and "somebody else's experiment" like it is just a figment of the imagination in just a few peoples’ mind. Note that L4S got wide support from the industry at the interim a year ago. 

	[SM] Sorry, wasn't the question back "ECT(1): input or output"? The question was not L4S or something else, so I consider it to be bad style to post-hoc interpret that decision as a "vote" pro L4S. 

>  
> Still, the whole process seems continue to stall and has done so the last ~2 years. How long can we continue with this ?. 

	[SM] Well, if team L4S continues to not make any fixes/changes to the design and implementation that have been shown by real data to be deficient, we hopefully will carry on not ratifying this until it is fixed? Just getting ratified for sheer persistence will set a bad precedence.

> There are entire email threads started by a few opponents around all things that can go in the shitter when the L4S experiment starts, but so far I have seen nothing, nada, zero…. discussion by the opponents around “what can _we_, the opponents do to remedy these potential issues on our side?”. 

	[SM] Sorry, there have been proposals how to make L4S less of a safety problem for the existing internet, as well as how ot fix the deficient core design and implementation, what has not been volunteered are fixed implementations, but that is hardly the job for someone showing that a design is unfit for purpose? Tyically the onus to fix, would e on those who want a technique/design/implementation to become a standard.

> Instead all I see is that the burden of proof is put on "Team L4S".

	[SM] And rightly so, you want something quie soecial and precious, the right to redefine an already deployed signaling mechanism with known and accepted negative side-effects, so asking you to make sure that these side-effects are minimized is not a "burden" or a request for different rocks...

> I can understand that this situation is the normal in the initial phase but now we are soon into a 2 year long infected debate that does not seem to show any evidence to end. 

	[SM] Because in these two years the L4S design and implementation has not been changes to make the objections pointless/invalid. This conscious inaction of tem L4S is hardly a reason for the WG to now rubber stamp the same designs and implementations that where identified as deficient years ago.

> To me all this just look like a very long filibuster. I mean, at some stage we need to move on, or ?.  

	[SM] If you had taken the objections in good faith and actually attempted to address them properly, you would be in much better shape. But calling objections based on real data "filibustering" indicates, that you never actually accepted these objections as real and hence never attempted to fix the underlaying problems, but only show enough activity to muster a "addressed objections" standard. Case in point the RTT-bias clown show, in which you a) mis characterize the root cause1) of RTT-bias, b) based in that flawed assumption designed a flawed "solution"20, and c) only implemented enough of that solution to tackle on of Pete's specific measurement points3)...

	In short, these drafts should move on when they are ready, and not simply because time has passed, as you seem to argue.

Best Regards
	Sebastian

1) RTT-bias is not caused by end-points alone, but is a result of the diifferent dynamics od different RTT flows inside the bottleneck's buffer
2) Since RTT-bias is not caused by end-points alone trying to fix it in the end-points/the protocols is a fools errand, it needs at least support from the bottleneck buffer management, but the L$S AQM makes the problem worsse instead of ameliorating it.
3) the magic number 20ms, in TCP Pragues RTT-independence mode, I believe comes from the faxt that 20ms is one of Pete's testing points, at least there was no rationale how this number was divined. But that kind of test-hacking reveals a desire to pass a test, and not a desire to actually solve the problem.

> www.ericsson.com

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 24 Mar 2021 13:21:31 +0200

> On 24 Mar, 2021, at 9:49 am, Ingemar Johansson S <ingemar.s.johansson=[email-masked]> wrote:
> 

Okay, Ingemar, let's remedy that straight away.  Here is a concrete proposal, from the SCE side of the aisle, for how L4S can:

1: Identify L4S traffic to the network in a fail-safe manner, without consuming the ECT(1) codepoint.

2: Contain traffic with L4S semantics to participating networks, which can be adequately prepared for it - thereby minimising the likelihood of affecting "innocent bystanders".

3: Provide a positive signal to L4S endpoints that the path is (at least partially) L4S-compliant, so can reasonably be presumed to lie wholly within a participating network.  This would satisfy the "fallback to Classic ECN" requirement in both RFC-4774 Option 2 and the so-called "Prague Requirements".

I think this might be sufficient to promote L4S to satisfying Option 2 within RFC-4774 - which was the original goal, was it not?  It has the side benefit of freeing up ECT(1) for other experiments, without impairing L4S' own performance.

The details:

0: Select two DSCPs from the experimental pool, X and Y, for use by L4S on a time-limited basis.  With kill dates embedded in experimental implementations, there is an obvious route to un-deployment in finite time at the end of the experiment.  If the experiment is deemed successful, permanent DSCPs can be allocated to replace them.

1: L4S sender sets DSCP X at origin on participating connections (both data and control segments).  This acts as positive identification to the network (but not the receiver) that the traffic expects L4S semantics in place of RFC-3168.

2: L4S middleboxes accept DSCPs X and Y as L4S traffic (regardless of ECN codepoint), and re-mark those carrying X with the Y DSCP.  This acts as positive identification to the receiver endpoint that at least one node on the path understands L4S semantics.

3: Gateways at the border of the participating network either blackhole or bleach both the X and Y DSCPs, in both directions.  This is the containment mechanism.  Bleaching permits connectivity across the boundary with conventional semantics, as below.

4: L4S receivers treat only traffic marked Y as having L4S semantics, all else as RFC-3168, and convey this distinction to the sender by setting a non-L4S DSCP (eg. CS0) on acknowledgement packets requiring RFC-3168 semantics, and the X DSCP on those requiring L4S semantics.  Since this is a path-specific rather than packet-specific distinction, it should be fairly stable over a connection's lifetime.

5: L4S senders respond to notifications of CE marks according to L4S semantics if and only if the notification arrived in a packet carrying the Y DSCP (so, it passed through an L4S middlebox on the return path as well).  Otherwise they respond according to RFC-8511.

6: L4S endpoints should, upon observing a path that doesn't generate Y marks in either direction, revert the affected connection permanently to a non-L4S mode and cease to emit the X DSCP at origin.  If this occurs during the 3-way handshake, they should negotiate an RFC-3168 feedback mode instead of AccECN if possible.  Otherwise, CE marks indicated by AccECN should be interpreted as requiring a Multiplicative Decrease.

The effects:

Receipt of packets carrying DSCP Y implies all of the following:

1: The sender emitted DSCP X and asserts L4S compliance.

2: Some middlebox on the path supports L4S and is presumably part of a participating network.

3: The path did not cross the border of a participating network.  Given 2 above, that implies the path did not cross any part of an "innocent bystander" network.

This means that packets carrying both DSCP Y and CE can safely be treated as indicating marks applied by an L4S AQM. Packets carrying DSCP Y but not CE can be treated as permitting the connection to remain in L4S mode.

By contrast, receipt of packets carrying DSCP X implies all of the following:

4: The sender emitted DSCP X and asserts L4S compliance.

5: There was *no* middlebox supporting L4S on the path.

6: The path did not cross the border of a participating network.  Given 5 above, that implies the path is *wholly* within an "innocent bystander" network.

This means that packets carrying both DSCP X and CE *must* receive a Multiplicative Decrease response, and the connection *should* switch to Classic mode.

And receipt of packets carrying any other DSCP implies at least one of the following:

7: The sender did not emit DSCP X, and does not assert L4S compliance, OR

8: The path crossed the border of a participating network, so lies at least partly in an "innocent bystander" context.

This means that, as with receiving DSCP X and CE, receiving any other DSCP and CE *must* provoke a Multiplicative Decrease response, and the connection *should* switch to Classic mode.

By sending DSCP X and expecting DSCP Y in both directions, we can ensure that both endpoints of the connection share knowledge of what mode the connection is in.  A receiver noticing that the path has changed to lose L4S support informs the sender of that fact by omitting DSCP X from its acks, and the sender responds by switching mode and omitting DSCP X henceforth.

This is a potential path forward for both experiments - that is, both L4S and SCE simultaneously.  Is that good enough?

 - Jonathan Morton

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 24 Mar 2021 13:06:59 +0000

Hi Jonathan. 

I believe that it is best that I refer to the L4S DSCP thread and Gorry's input before jumping to conclusions
https://mailarchive.ietf.org/arch/msg/tsvwg/U5CfgEVZKgLNnspPMwmaeKxd_Zs/
I have for instance completely forgotten draft-briscoe-tsvwg-l4s-diffserv-00

/Ingemar

> -----Original Message-----
> From: tsvwg <[email-masked]> On Behalf Of Jonathan Morton
> Sent: den 24 mars 2021 12:22
> To: [email-masked]
> Subject: [tsvwg] L4S, DSCP, and RFC-4774 Option 2
> 
> > On 24 Mar, 2021, at 9:49 am, Ingemar Johansson S
> <ingemar.s.johansson=[email-masked]> wrote:
> >
> > There are entire email threads started by a few opponents around all
> things that can go in the shitter when the L4S experiment starts, but so far I
> have seen nothing, nada, zero…. discussion by the opponents around “what
> can _we_, the opponents do to remedy these potential issues on our side?”.
> 
> Okay, Ingemar, let's remedy that straight away.  Here is a concrete proposal,
> from the SCE side of the aisle, for how L4S can:
> 
> 2: Contain traffic with L4S semantics to participating networks, which can be
> adequately prepared for it - thereby minimising the likelihood of affecting
> "innocent bystanders".
> 
> 3: Provide a positive signal to L4S endpoints that the path is (at least partially)
> L4S-compliant, so can reasonably be presumed to lie wholly within a
> participating network.  This would satisfy the "fallback to Classic ECN"
> requirement in both RFC-4774 Option 2 and the so-called "Prague
> Requirements".
> 
> I think this might be sufficient to promote L4S to satisfying Option 2 within
> RFC-4774 - which was the original goal, was it not?  It has the side benefit of
> freeing up ECT(1) for other experiments, without impairing L4S' own
> performance.
> 
> 
> The details:
> 
> 0: Select two DSCPs from the experimental pool, X and Y, for use by L4S on a
> time-limited basis.  With kill dates embedded in experimental
> implementations, there is an obvious route to un-deployment in finite time
> at the end of the experiment.  If the experiment is deemed successful,
> permanent DSCPs can be allocated to replace them.
> 
> 1: L4S sender sets DSCP X at origin on participating connections (both data
> and control segments).  This acts as positive identification to the network
> (but not the receiver) that the traffic expects L4S semantics in place of RFC-
> 3168.
> 
> 2: L4S middleboxes accept DSCPs X and Y as L4S traffic (regardless of ECN
> codepoint), and re-mark those carrying X with the Y DSCP.  This acts as
> positive identification to the receiver endpoint that at least one node on the
> path understands L4S semantics.
> 
> 3: Gateways at the border of the participating network either blackhole or
> bleach both the X and Y DSCPs, in both directions.  This is the containment
> mechanism.  Bleaching permits connectivity across the boundary with
> conventional semantics, as below.
> 
> 4: L4S receivers treat only traffic marked Y as having L4S semantics, all else as
> RFC-3168, and convey this distinction to the sender by setting a non-L4S DSCP
> (eg. CS0) on acknowledgement packets requiring RFC-3168 semantics, and
> the X DSCP on those requiring L4S semantics.  Since this is a path-specific
> rather than packet-specific distinction, it should be fairly stable over a
> connection's lifetime.
> 
> 5: L4S senders respond to notifications of CE marks according to L4S
> semantics if and only if the notification arrived in a packet carrying the Y DSCP
> (so, it passed through an L4S middlebox on the return path as well).
> Otherwise they respond according to RFC-8511.
> 
> 6: L4S endpoints should, upon observing a path that doesn't generate Y
> marks in either direction, revert the affected connection permanently to a
> non-L4S mode and cease to emit the X DSCP at origin.  If this occurs during
> the 3-way handshake, they should negotiate an RFC-3168 feedback mode
> instead of AccECN if possible.  Otherwise, CE marks indicated by AccECN
> should be interpreted as requiring a Multiplicative Decrease.
> 
> 
> The effects:
> 
> 3: The path did not cross the border of a participating network.  Given 2
> above, that implies the path did not cross any part of an "innocent
> bystander" network.
> 
> This means that packets carrying both DSCP Y and CE can safely be treated as
> indicating marks applied by an L4S AQM. Packets carrying DSCP Y but not CE
> can be treated as permitting the connection to remain in L4S mode.
> 
> 6: The path did not cross the border of a participating network.  Given 5
> above, that implies the path is *wholly* within an "innocent bystander"
> network.
> 
> This means that packets carrying both DSCP X and CE *must* receive a
> Multiplicative Decrease response, and the connection *should* switch to
> Classic mode.
> 
> 8: The path crossed the border of a participating network, so lies at least
> partly in an "innocent bystander" context.
> 
> This means that, as with receiving DSCP X and CE, receiving any other DSCP
> and CE *must* provoke a Multiplicative Decrease response, and the
> connection *should* switch to Classic mode.
> 
> By sending DSCP X and expecting DSCP Y in both directions, we can ensure
> that both endpoints of the connection share knowledge of what mode the
> connection is in.  A receiver noticing that the path has changed to lose L4S
> support informs the sender of that fact by omitting DSCP X from its acks, and
> the sender responds by switching mode and omitting DSCP X henceforth.
> 
>