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

[Greg White <[e-mail]>]

Hi Michael,

Sorry for the long delay in responding to this.  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.

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

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.

-Greg


On 12/13/22, 4:38 AM, "tsvwg on behalf of Michael Welzl" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> wrote:


Hi everyone,


I have just read (most of) draft-ietf-tsvwg-l4sops-04. A strange document, I must say! Structurally (the headings, the way it’s laid out) it seems good to me, but the text has such long-winded musings about what is likely and what isn't, what we may think of per-flow-fairness, what the point of caring about congestion control as a way to realize fairness may be, etc etc … to me, much of it reads like one of the many long emails this list has seen rather than a spec.


But, okay, these are style matters, and they may be a matter of taste. My reason to write this email is that I would like to propose that this document should recommend that servers fall back to ABE (RFC 8511) upon detection of a classic ECN bottleneck. This should be beneficial for L4S, because its users, including ones having little knowledge of the underlying technical intricacies, should generally see some kind of benefit from it.


Without ABE, the benefits of using ECN are questionable (one may believe that it’s just a net gain, because a packet doesn’t get dropped but is marked instead - yet, because said packet is enqueued, the dynamics may play our favourably or not. See fig. 14 in this old paper for more: https://www.duo.uio.no/handle/10852/37381 <https://www.duo.uio.no/handle/10852/37381&nbsp;&nbsp;>). That’s why we designed ABE - with ABE, hosts are more likely to see a benefit, if only small, from having RFC 3168 style ECN marking.


I note that ABE is already recommended as a fall-back in section 6 of this document, which the l4sops draft points at, in various places:
[Briscoe] Briscoe, B. and A.S. Ahmed, "TCP Prague Fall-back on Detection of a Classic ECN AQM", ArXiv , February 2021, <https://arxiv.org/abs/1911.00710> <https://arxiv.org/abs/1911.00710&gt;>.
… but I think that this behaviour should be explicitly spelled out in the draft, not just in this reference.


In fact, now, nothing seems to be explicitly spelled out regarding the behavior upon detection of an RFC 3168 style bottleneck. I’d expect this to be in section 5 - which begins with general text on what deployers should do and shouldn’t do, how harmful false positives are (is all this text really needed?), and then goes on to discuss specific types of servers. E.g., section 5.1.1 has four bullets; the first two explain how testing could be performed, the third explains a case where “taking action may not be needed”, and the fourth mentions that, for long flows, " it may be possible to fall-back to Classic behavior (..)”.


This is again just strange style, in my opinion. What “fall-back to Classic” means should be spelled out - i.e., if you want RFC 3168, this should reference RFC 3168, and probably state an exception to this rule from RFC 3168: "Senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis.”. Again, however, I would suggest to explicitly recommend ABE (RFC 8511).


Oh, and then, the draft should probably make a recommendation about the “classic" congestion control mechanism to use. I agree with [Briscoe] that ABE-Reno would seem easiest, though [Briscoe] also says: “(though falling back to a less lame congestion control such as Cubic or BBRv2 would be preferable)”. Either which way, I think that draft-ietf-tsvwg-l4sops needs to make some clear recommendations here.


Cheers,
Michael