Re: [tsvwg] start of WGLC on L4S drafts

[Bob Briscoe <[e-mail]>]

Jake, (and thank you, Wes, for forwarding this to the list),

On 21/09/2021 18:10, Wesley Eddy wrote:
>
> Finally, here is the remaining part of the offlist exchange that we 
> wanted to bring to the list.
>
>
> On 8/31/2021 12:39 PM, Holland, Jake wrote:
>>
>> Hi Bob,
>>
>> I agree there was a discrepancy in our phrasing about updating vs. 
>> obsoleting RFC 3168, but I don’t really see how these differ.
>>
>> In either case, what I’m looking for is for the active latest 
>> standards-track specs to say that ECT(0)->CE handling stays the same, 
>> but ECT(1) is to be treated as NECT or L4S’s ECT(1), and all due 
>> effort should be made to ensure deployed queues will never henceforth 
>> treat ECT(1) as ECT(0), and that this is a necessary prerequisite to 
>> approving a doc allowing for new incompatible handling as described 
>> in L4S.
>>

[BB] Before I address the main procedural aspect of your email, can I 
ask that everyone please stops suggesting it is necessary for RFC3168 
equipment to treat ECT(1) as Not-ECT (or NECT as you call it). There are 
much better ways to proceed.

draft-ietf-tsvwg-l4sops proposes a number of potential changes to 
RFC3168 AQMs to make them support L4S, either fully or at least 
partially. Treating ECT(1) as Not-ECT comes way down the list as a 
non-preferred option. Indeed the editor (Greg White) has said that, in 
the next revision, he wants to draw a clearer line to explain that 
solutions that treat ECT(1) as Not-ECT are definitely not recommended or 
desirable.

The text about modifying FQ-CoDel (and CAKE) implementations of RFC3168 
is a particular case in point. The L4S architecture describes a really 
simple modification to Linux FQ-CoDel that fully supports both RFC3168 
ECN and L4S ECN. This is what l4sops mean when it says "update RFC3168 
FQ bottlenecks to be L4S-aware", but it is not clear what it means.

The l4sops draft then describes other less preferred options starting 
with treating ECT(1) as Not-ECT.  But it needs to be made much clearer 
(in l4sops and on this list now) what the preferred option is, and how 
easy it is to implement. It means the following, quoting from l4s-arch:

        ... For instance within each queue of an FQ-CoDel
        system, as well as a CoDel AQM, there is typically also ECN
        marking at an immediate (unsmoothed) shallow threshold to support
        use in data centres (see Sec.5.2.7 of [RFC8290  <https://datatracker.ietf.org/doc/html/rfc8290>]).  This can be
        modified so that the shallow threshold is solely applied to
        ECT(1) packets.  Then if there is a flow of non-ECN or ECT(0)
        packets in the per-flow-queue, the Classic AQM (e.g.  CoDel) is
        applied; while if there is a flow of ECT(1) packets in the queue,
        the shallower (typically sub-millisecond) threshold is applied.

That threshold is already in both the FQ-CoDel RFC and the Linux 
implementation. We have implemented and tested this minor change and can 
confirm that it fully supports both RFC3168 and L4S, so that hosts can 
switch from one to the other at any time without any dilemma.

>> (And as a suggestion, it seems likely the most expedient to achieve 
>> this prerequisite in the same document at standards track, though if 
>> the proponents would prefer to park the L4S documents to wait for a 
>> new standards track spec that changes ECT(1) to NECT instead of 
>> ECT(0) and permits experimental use, that would also be acceptable to 
>> me.)
>>
>> If you’re saying that obsoleting RFC 3168 would do that job but 
>> updating it would not, then I’ll adjust my position to say we should 
>> obsolete RFC 3168, but as I said, I don’t see how these differ 
>> substantively.  In either case, my position is that we should not 
>> publish an experimental doc that is not compatible with the latest 
>> standards track docs, in the way that L4S is not presently compatible 
>> with RFC 3168 as updated by RFC 8311, and that this can be solved by 
>> updating the current standards track docs, since we evidently can’t 
>> achieve it more cleanly by change to the signaling to make it 
>> compatible in any timely manner.
>>

[BB] You are really highlighting that we need another status where an 
exp track document can put a stds track document "on hold" - to 
recommend new implementations and deployments are discouraged while 
experiments on how best to update the stds track proceed. IOW, to 
discourage or even stop future implementations, even though it cannot 
undo the past.

Actually, thinking about it, that is effectively what RFC8311 did. 
Someone approaching RFC3168 without having heard anything about L4S 
would discover it is updated by RFC8311. And, by reading RFC8311, they 
would find that it enables experiments with ECN and refers to L4S. And 
by reading L4S they would find how it is hoped to improve on RFC3168. 
That's pretty-close to putting RFC3168 "on hold" - probably as close as 
the IETF can get. Because to go any further (actively updating or 
obsoleting present and future RFC3168 implementations) would need 
evidence from deployment over the real public Internet that the 
contender is indeed a viable improvement.

You want the RFC series to be self-consistent, but what you are hoping 
for would just lead to a different sort of inconsistency within the stds 
track - an experiment with a fake "standards track" label on it. There 
is loads of content in the L4S docs about what needs to be tested in L4S 
experiments, none of which can be tested properly except over the real 
Internet, which in turn cannot be done without assigning a codepoint. 
The WG cannot pretend that there is no experiment to do by just writing 
"standards track" in the header block. There is no tidy consistent way 
through this.

As I said, the closest to what you want that would be feasible (IMO) 
would be to draft a stds track update to RFC3168 as soon as L4S 
deployment starts, which might possibly even be while the L4S drafts are 
in the RFC editor queue.

Cheers


Bob


>> HTH.
>>
>> Best,
>>
>> Jake
>>
>> *From: *Bob Briscoe <[e-mail]>
>> *Date: *Tue,2021-08-31 at 8:37 AM
>> *To: *"C. M. Heard" <[e-mail]>
>> *Cc: *"Holland, Jake" <[e-mail]>, Wesley Eddy 
>> <[e-mail]>, Greg White <[e-mail]>, "De 
>> Schepper, Koen (Koen)" <[e-mail]>, Steven BLAKE 
>> <[e-mail]>, "[e-mail]" <[e-mail]>
>> *Subject: *Re: [OFFLIST for now] ECT(1) on stds track? (was: start of 
>> WGLC on L4S drafts)
>>
>> Mike,
>>
>> The only misunderstanding I've seen is between whether we're talking 
>> here about updating RFC3168 (and RFC8311), or obsoleting / 
>> deprecating RFC3168 (and probably 8311). Jake used the former words, 
>> whereas I notice you use the latter.
>>
>> If the IETF were to obsolete RFC3168, then I think it would have the 
>> effect that you and Jake are hoping to achieve. But I don't see that 
>> the IETF would have any reason to obsolete RFC3168. It is in use, 
>> continuing to be deployed (we believe in FQ-CoDel but possibly 
>> otherwise too) and providing some benefit.
>>
>> In contrast, updating RFC3168 to interwork more cleanly with RFC8311 
>> experiments (specifically L4S) is something that I can imaging the 
>> IETF doing. But then my point was that (IMO) it hardly resolves the 
>> coexistence problem any more than an EXP RFC would.
>>
>>
>> Bob
>>
>> On 28/08/2021 19:34, C. M. Heard wrote:
>>
>>     On Sat, Aug 28, 2021 at 3:45 AM Bob Briscoe wrote:
>>
>>         I think the outcome Jake is trying to achieve would be more
>>         likely by continuing on the exp track while initiating work
>>         on a stds track RFC fairly quickly - as soon as Internet
>>         deployment of the L4S experiment gets going. I think Jake's
>>         arguments for stds track are no stronger whether L4S moves to
>>         stds track before the drafts progress or soon after.
>>
>>     **IF** RFC 3168 were declared obsolete first, **THEN** I would
>>     agree that starting L4S as experimental and then moving to
>>     standard later would be a reasonable course of action. And that
>>     could be done, of course. But it seems to me that it would be
>>     simpler to make the L4S document set standards track and mark it
>>     as obsoleting RFC 3168 -- and probably RFC 8311 as well. I think
>>     that Jake is correct when he argues that RFC 8311 was never
>>     intended to permit incompatible and uncontained experimentation.
>>     It would actually be good to hear from the editor of that
>>     document on what his take is (wearing his editor hat, not his WG
>>     co-chair hat, of course).
>>
>>     Thanks
>>
>>     Mike Heard
>>
>>
>>
>> -- 
>> ________________________________________________________________
>> Bob Briscoehttp://bobbriscoe.net/  <https://urldefense.com/v3/__http:/bobbriscoe.net/__;!!GjvTz_vk!B4mHJRqHlL17qfu6aBRa-hojLOZ290aq_E7aTeqn-zlp25C3FDhIhd0u1pCYRo8$>

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