Re: [tsvwg] Review comments on a careful read of the L4S ID

["Black, David" <[e-mail]>]

Hi Sebastian,

Something does indeed need to be done about this, as there's an even bigger problem elsewhere in the L4S ID.

There are (at least) two different reasons for not applying L4S AQM treatment to ECT(1) marked traffic: 
	- Policy-based exclusion (e.g., Section 5.4.1.2 of the L4S ID draft).
	- Operational exclusion (e.g., L4S OPS draft).
The L4S ID needs to allow both reasons for excluding ECT(1)-marked traffic from L4S AQM treatment.

Unfortunately, the L4S ID currently prohibits both exclusions due to an unintended consequence of the first sentence of Section 5.1:

   A network node that implements the L4S service MUST classify arriving ECT(1) packets for L4S treatment ...

My understanding is that the L4S authors are going to rewrite that sentence to correct this oversight, and check for other places where this problem may occur.  That rewrite ought to cover both exclusion cases listed above.

Thanks, --David

-----Original Message-----
From: tsvwg <[e-mail]> On Behalf Of Sebastian Moeller
Sent: Thursday, May 6, 2021 7:48 AM
To: Gorry Fairhurst
Cc: [e-mail]
Subject: Re: [tsvwg] Review comments on a careful read of the L4S ID


[EXTERNAL EMAIL] 

Hi Gorry,

see [SM] below for a question.


> On May 6, 2021, at 08:52, Gorry Fairhurst <[e-mail]> wrote:
> 
> 
> Here are some review comments on a careful read of the L4S ID that I hope will help in preparation of a new revision of the draft. More details have been sent to the authors.
> 
> Best wishes,
> 
> Gorry
> [...]
> =================================================================
> 25. Missing drop-only requirement for excluded traffic
>  
> Section 5.4.1.2.  Exclusion of Traffic From L4S Treatment – this text:
>  
>    “The operator MUST NOT alter the end-to-end L4S ECN identifier from
>    L4S to Classic, because its decision to exclude certain traffic from
>    L4S treatment is local-only.”
>  
> ⁃           I think be the word /its/this/ .
> ⁃            Please add a requirement that ECT(1) traffic excluded from L4S treatment MUST be handled as non-ECN traffic (e.g., all congestion signalling is via drops), as Classic AQM treatment and ECN marking produce the wrong results for such traffic.
> =================================================================
[...]

We actually recommend doing exactly that as a measure of last resorts in https://urldefense.com/v3/__https://tools.ietf.org/html/draft-white-tsvwg-l4sops-02*page-11__;Iw!!LpKI!1yLUhTX-HOwh-wMGgmzGrZngRafqgEyTPQoamHkJO0n_ZR1k6R0cJ2RFGzexjN3L$ [tools[.]ietf[.]org]
We could:
a) simply accept that divergence
b) add text to the ECN-ID draft to explicitly allow that for extreme situations (or reduce the MUST to a SHOULD, pointing out the cost of doing so)
c) add text to the OPs draft why that violation of the ECN-ID draft is acceptable as a measure of last resort...

Given that this is the final back-stop in the (unlikely) case that the L4S experiment should cause the next congestion collapse I think it made sense to tackle this explicitly, no?


Best Regards
	Sebastian