Re: [tsvwg] L4S vs SCE

[Pete Heist <[e-mail]>]

Yes, we look forward to providing more results later, in the form of flent tests. If there's is anything more detailed that needs testing, we’ll enhance flent as a first option.

The CNQ implementation is only a week or so old, and LFQ is not implemented yet. The crude discrete time simulations for both are referenced in the respective drafts.

A clarification for my earlier statement regarding CNQ is below.

> On Nov 22, 2019, at 12:02 PM, Greg White <[e-mail]> wrote:
> 
> Pete,
> 
> I've seen several statements being made to the effect that SCE can possibly work in a single queue or dual queue bottleneck, but I've not seen any data to suggest that it is true.
> 
> If the SCE team can come up with such an approach, and provide test results (preferably to a similar extent to those provided by the L4S team, not just the simple flent scenarios), it would be interesting to see.
> 
> -Greg
> 
> 
> On 11/21/19, 8:58 PM, "Pete Heist" <[e-mail]> wrote:
> 
>> On Nov 21, 2019, at 7:14 AM, Greg White <[e-mail]> wrote:
>> 
>> Where I think SCE fails is that it is not available to any link that doesn't implement FQ, whether that is by choice or by necessity.  I don't believe that the IETF should use the last IP codepoint for a signaling mechanism that can *only* work in FQ.
> 
>    The thoughts are appreciated. What I think needs to be clarified is that SCE doesn’t necessarily require full FQ using the traditional many queues approach. It only requires some level of help from the network, when fairness between SCE and non-SCE flows is required. Options include:
> 
>    - Changing the SCE marking ramp, trading off some of the advantages of SCE for improved fairness. This was first described at IETF 105 in Montreal.
>    - Using CNQ, which is implemented but we didn’t have time to present today. That provides a minimal level of improved fairness that can actually favor SCE flows early in their lifetime.

It should more accurately say:

"That provides a minimal level of improved fairness that prevents SCE flows from being starved to minimum cwnd.  It also priorities sparse flows including initial handshakes & request-response transactions.”

Experimentally, we have seen SCE flows outcompete non-SCE flows early in their lifetime with CNQ, but that isn’t directly due to help from CNQ, but to the new marking strategy using Codel, which was prototyped in CNQ.  We’ll port this development to Cake in due course.

>    - Using LFQ, which like CNQ, is in draft form with a crude discrete time simulation, but doesn’t yet have an implementation. This provides closer to full FQ but with a lighter weight implementation.
> 
>    This is still an active area of research with many options available to us, and we feel it’s a tractable problem. We just want to make clear that “SCE requires FQ” isn’t very accurate, and needs more clarification as to the current and future options available.