Re: [tsvwg] New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt

["[e-mail]" <[e-mail]>]

 Gorry, Jonathan, tsvwg

See below  [AB]

    On Tuesday, March 9, 2021, 4:18:23 PM GMT, Gorry Fairhurst <[e-mail]> wrote:  
 
 On 09/03/2021 15:44, Jonathan Morton wrote:
>> On 9 Mar, 2021, at 5:42 pm, Gorry Fairhurst <[e-mail]> wrote:
>>
>> I understand that to say: if a router wishes to be compatable with L4S, this is one way to do this. The recommendation(s) could be stronger, if the community thinks this is what is needed.
> As I tried to point out in my talk, the problem is that a great many people are already running RFC-3168 compliant AQMs with no knowledge of L4S and, therefore, no "wish to be compatible" with a new spec that explicitly violates the spec they built against.
>
> Myself included.
>
>  - Jonathan Morton

This is pecisely why we have a standards process to make this change. 
When the work on L4S was first brought to the IETF, I know many people 
weighed the prospects of replacing the RFC3168 behavior.

When the L4S specs are published, this will indeed be a disruptive 
change for some, and people deploying and implementing do need to 
consider this. The place to describe this might be in 
draft-white-tsvwg-l4sops within the tsvwg, if this is adopted (this 
adoption call is on-going currently on the tsvwg list).
[AB] Not sure it's a problem, but rfc8311 (sec 4.2) says variation of marking behavior between ECT(0) and ECT(1) must be specified in an experimental RFC. The ops call just made for draft-white-tsvwg-l4sops is to be an informational RFC. 

With hindsight, I'm not sure why rfc8311 (which is standards track) didn't deprecate marking ECT(1) the same way it deprecated endpoints using it, outside experiments.


Alex