[tsvwg] How an L4S network node should treat ECT(1) packets if L4S has been disabled

[Bob Briscoe <[e-mail]>]

Mirja,

On 17/08/2021 17:00, Bob Briscoe wrote:
> Mirja,
>
> Having said I would hold back replies, yours are fairly brief, so I'll 
> reply now...
>
> On 11/08/2021 14:57, Mirja Kuehlewind wrote:
[snip]
>> - Section 5.1 has this todo still:
See last para of: 
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-19#section-5.1 
starting:
>> "  In case unforeseen problems arise with the L4S experiment, it MUST be
>>     possible to configure an L4S implementation to disable the L4S
>>     treatment.  Once disabled, all packets of all ECN codepoints will
>>     receive Classic treatment and ECT(1) packets MUST be treated as if
>>     they were {ToDo: Not-ECT / ECT(0) ?}."
>
> [BB] Yeah, I noticed that after I had posted the drafts. This is 
> actually a technical point, so I'll start a separate thread on it, in 
> case some people don't read emails starting 'editorial'.

I propose we choose Not-ECT for the following reason:

·Redirecting ECT(1) to ECT(0) treatment would be foolish because the 
sender would still behave as L4S

·Redirecting ECT(1) to Not-ECT treatment would be effective, by inducing 
a drop response at the sender

I could also paste in a long treatise on what all the requirements might 
be, what circumstances might lead to disabling L4S, etc, etc. But 
ultimately, the above consideration trumped every other aspect of the 
discussion.

Another view has been expressed (off list) that we should not decide at 
this point, but instead wait until the problem needs a solution. I would 
argue that this 'MUST' needs to be implemented from the start, and 
asking implementers to include options for future flexibility needs to 
be tempered by whether ECT(0) treatment would ever be useful in any 
future scenario.


Bob


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