Re: [tsvwg] L4S vs SCE

[Greg White <[e-mail]>]

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