Re: [tsvwg] draft-ietf-tsvwg-l4sops: recommend ABE as "Classic" ?

[Michael Welzl <[e-mail]>]

[ NOTE to everyone: below Greg’s asking for the group consensus on whether the l4sops draft should recommend falling back to ABE (RFC 8511).  Please don’t miss this - please speak up ! ]

Hi Greg!


> On Mar 22, 2023, at 10:14 PM, Greg White <[e-mail]> wrote:
> 
> Hi Michael,
> 
> Sorry for the long delay in responding to this.

No worries - much appreciated in any case!


>  You are right, the L4Sops draft doesn't currently provide any specific recommendations around the details of falling back to Classic behavior.  In fact it refers to that operation with language like "make decisions whether or not to use L4S congestion control" or  "discontinuing the use of L4S" and in one case "fall-back to Classic behavior".  So, we rely instead on the detailed requirements and discussion in RFC9331 Section 4.3 and A.1.5 (which also points to the Briscoe/Ahmed paper that used ABE when falling back to Classic behavior).   But it seems that we've neglected to directly refer to those sections.  As a first step, I'll add a reference to those RFC9331 sections.

Ok…  I have no opinion on that.


> It seems to me that those sections in RFC9331 (or the eventual Stds track version) would be the best place to include additional requirements and recommendations on Classic fall-back, rather than L4Sops.  But, since RFC9331 is done, and the Stds track version hasn't been started, I can see that L4Sops might be a convenient place to do it.

I’m surprised - it seemed obvious to me that L4Sops would be the right place. Given this description on the abstract, it’s hard for me to see that any other document could be a better fit?
"Other L4S documents provide guidance for running an L4S experiment, but this document is focused solely on potential interactions between L4S flows and flows using the original ('Classic') ECN over a Classic ECN bottleneck link. The document discusses the potential outcomes of these interactions, describes mechanisms to detect the presence of Classic ECN bottlenecks, and identifies opportunities to prevent and/or detect and resolve fairness problems in such networks.”

My suggestion is exclusively about this - L4S flows that would interact with ‘Classic’ ECN over a Classic ECN bottleneck link.


> I don't personally have a strong opinion on the value of recommending ABE for L4S senders falling back to classic behavior.  I actually fall more into the camp of those who would be happy to see Classic ECN be deprecated rather than encourage implementations of it.

… but instead of a document that says “Classic ECN is herewith deprecated”, you wrote a long document on interactions with Classic ECN.
It seems to me that “can we deprecate Classic ECN” is therefore not the discussion on the table.


>  But, if it is the WG consensus that ABE should be recommended here, I won't object.   So, I'd like to get some other opinions on this from the WG.

+1.  People, please speak up !

ABE pointers:
===========
* Why Classic ECN isn’t “good enough”: it may seem to “just be a win”, as a packet doesn’t get dropped but marked instead. However, since this packet also enters the queue, it affects queue dynamics As a result, it’s sometimes a benefit and sometimes not. For details, please see figs. 13 /14 here: https://www.duo.uio.no/handle/10852/37381
* ABE: RFC 8511 and for some results: https://folk.universitetetioslo.no/michawe/research/publications/Networking2017ABE.pdf <https://folk.universitetetioslo.no/michawe/research/publications/Networking2017ABE.pdf>
* Code: to play with it, you can try the FreeBSD socket option: https://www.freebsd.org/cgi/man.cgi?query=cc_newreno <https://www.freebsd.org/cgi/man.cgi?query=cc_newreno>    The Linux kernel Linux kernel patch is here:  https://folk.universitetetioslo.no/michawe/research/projects/abe/index.html <https://folk.universitetetioslo.no/michawe/research/projects/abe/index.html> 


> If we do take this on, I think I agree with you that section 5 would be the right place.  We'd need to create a new discussion of the topic, pointing to RFC9331 for the requirements and most of the recommendations, and then introducing the new recommendations etc.   If you'd like to propose some specific text for that, it might help others in the WG form an opinion as to whether they agree that it should be included.

Given the above, I think they now have all they need; I’m happy to offer text later if folks agree that this should be the recommendation in the L4Sops draft.

Cheers,
Michael