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

[Bob Briscoe <[e-mail]>]

David, Sebastian, Gorry, and adding Greg as author of l4sops for the 
last point inline below, see [BB]...

On 06/05/2021 22:25, Black, David wrote:
> 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.

[BB] Following you pointing this out, we were indeed going to add that 
the rule to classify ECT(1) as L4S was subject to policy exceptions (as 
in S.5.4.1.2).

For the l4sops draft point, see my response embedded below to Sebastian, 
plus some others while I'm at it...


>
> 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/ .
[BB] Possibly, but an operator is an it, and it can make decisions. 
'Its' seems better to my English ear than 'this'. I'll leave it.

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

[BB] Good point. Here's the new para I've added at the end of the section:

An operator that excludes traffic carrying the L4S identifier from L4S 
treatment MUST NOT treat such traffic as if it carries the ECT(0) 
codepoint, which could confuse the sender.

>> =================================================================
> [...]
>
> 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...

[BB] Thanks for pointing this out.

ecn-l4s-id is about what L4S nodes do, whereas l4sops is about what 
non-L4S nodes might do. So l4sops is not strictly contrary to 
ecn-l4s-id. However, that's splitting hairs, because l4sops is about 
trying to help 3168 and L4S nodes to be more compatible. So it is not 
particularly compatible to be inconsistent.

When I sent my review of l4sops to the list recently, I said I didn't 
like the mention of bleaching. Quoting:
     "For both 5.5. & 5.6., I think it's necessary to say why we are 
even mentioning these options, given they are not recommended."

An alternative to your a) b) c) would be
d) not to mention this in l4sops. I'd support that.

If 5.6 remains in l4sops, I'd support your c).


Bob



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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/