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

[Bob Briscoe <[e-mail]>]

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]> 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
> * Code: to play with it, you can try the FreeBSD socket option: 
> 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 
>
>
>
>> 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 Briscoehttp://bobbriscoe.net/