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

[Michael Welzl <[e-mail]>]

Hi Bob,

I proposed ABE as a fall-back because I thought that, with the current state of things, ABE is no longer an L4S “competitor”. It was never meant to be one - I always saw it as orthogonal, but you started out by saying (sorry for paraphrasing, but this is now many, many years ago) that Classic ECN should be deprecated and hence ABE (which might make it seem better) shouldn’t exist.

Now, in the new world where L4S “wins”, and ECN-capable equipment (which uses an AQM algorithm and is hopefully also able to handle Classic ECN when receiving ECT(0)?) gets deployed, I thought that ABE might be an attractive option for L4S. After all, in the majority of cases, it will probably make things work somewhat better, and as a result, even when L4S would have to resort to falling back, the whole machinery that is called L4S might end up looking better.   Your reaction makes it clear that this combination is far from desirable - you call it “entering a bear pit”.

So, my whole proposal was: “you might *want* to do this”. Your reaction is “it’s orthogonal" (which I agree with), "why do it if we don’t have to" (since you prefer not to - then, I agree with you, no need to do it), followed by explanation of where it might go wrong and asking about experiments.

Well, I agree with much of what you say here. I thank you for your concrete suggestions on where ABE might play out badly (no, varying-capacity links were not part of our prior tests). It’s a case where all end-to-end controls tend to fail: see for example https://ieeexplore.ieee.org/document/9162881 <https://ieeexplore.ieee.org/document/9162881> , which even tests TCP Prague (which, AFAIK, will also not back off more than Reno does, going to 1/2 of cwnd, but maybe I missed some recent developments there?). Of course, the less one backs off, the worse it becomes in this situation, so it’s definitely an interesting case for us to investigate further.

Admittedly, not much has happened on the experiment front in recent years; I needed a prod to get back to it, so thanks for that.

Cheers,
Michael


> On Mar 30, 2023, at 3:58 PM, Bob Briscoe <[e-mail]> wrote:
> 
> Michael, Greg,
> 1) Is it our role to recommend a CCA on detection of a Classic ECN bottleneck? 
> 
> Why enter a bear pit when we don't have to? 
> Given we're not even recommending a particular scalable CCA in any L4S docs, why would we recommend a Classic CCA for fallback? 
> Indeed, why would the best choice of Classic CCA after fallback be any different from the best choice of Classic CCA at any time? 
> 
> So, shouldn't the efforts of those interested in finding the best Classic CCA be directed at conducting the ABE experiment as promised in RFC8511 so that the results can be folded into updates of the standards track Reno or CUBIC specs?
> 
> 2) Pros and Cons of ABE? 
> 
> But we could certainly discuss the pros and cons of the choices on this ML. So here goes.
> 
> If fallback from Prague to Reno has been implemented, I believe ABE-Reno is likely to be safe with beta_{ecn} parameter 0.7 and perform better than standard Reno. 
> 
> However, if fallback to CUBIC was implemented, I'm not so sure that ABE-CUBIC with beta_{ecn} parameter of 0.85 (as recommended in the ABE Experimental RFC) would be 'better'. I don't think we have sufficient experience of ABE-CUBIC_0.85 performance in environments with highly varying capacity like radio (I believe all the experiments in your ABE paper were over fixed). But you probably know better than me what ABE experiments have been conducted since the RFC was published.
> 
> ABE-CUBIC_0.85 would respond 4.3 times more slowly than Reno to the heavy congestion you can get when the capacity massively reduces, and 2.2 times more slowly than CUBIC. In comparison, CUBIC is 1.9 times slower than Reno. {Note 1}
> 
> So after more experimentation, the preference order of classic CCAs might be:
> #1 standard-to-be CUBIC, 
> #2 ABE-Reno_0.7.
> 
> BTW, the paper Asad & I wrote ([Briscoe] in l4sops) only used ABE-Reno for experiments because I figured it would be more appropriate than Reno and quick to alter in the implementation we had. The paper didn't /recommend/ ABE-Reno. It didn't not recommend it either. The purpose of the paper wasn't to compare classic CCAs, so we only tried one.
> 
> 3) Where to write something, when we have something to write? 
> 
> IIRC, the goal of l4sops was solely to /add/ to RFC9331, not repeat it. I assume that's why this whole subject isn't in there at the mo. 
> 
> Your email does highlight that l4sops silently assumes the reader knows that there's material about "Fallback on detection of Classic ECN" in RFC9331. So I think it would be worth adding a brief summary of what is already in RFC9331 about this (couple of sentences), and pointing to the various sections in RFC9331 that give more detail. I think 4.3 might be the best place to do that, before 5, rather than in 5.
> 
> If/when the IETF comes up with a more general recommendation on which Classic AQM it recommends, and whether ABE is part of that, then this would also be the place to point to that (if available before l4sops completes).
> 
> Cheers
> 
> 
> 
> Bob
> 
> {Note 1} The ratio between the exponential decay rates of two beta parameters is just log(beta1)/log(beta2).
> 
> 
> On 25/03/2023 20:56, Michael Welzl wrote:
>> [ 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] <mailto:[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 <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
>> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/ <http://bobbriscoe.net/>