Re: [tsvwg] L4S vs SCE

[Greg White <[e-mail]>]

It seems that a component of this debate revolves around whether FQ is a good solution or not.

In my view, FQ provides a very nice benefit (flow isolation) which, if it were to be implemented in *every* bottleneck in the Internet, would allow for unfettered innovation around congestion control.   It also enforces fairness, which could be a blessing, or it could be a "don’t care" or it could be a curse, depending on the situation (and it has been argued that it weakens the end-to-end principle).  Finally, it introduces complexity concerns that likely prevent it from actually being implemented in *every* bottleneck in the Internet.

The question around the SCE signal vs the L4S signal, in my view, is mainly around the question:  Does the IETF want to select a signal that forces all bottlenecks to implement FQ (if they want to participate in high-fidelity congestion signaling), or does it want to select a signal that allows the bottleneck implementer to choose between TWO options (FQ or DualQ).   

I assume that FQ will nearly always give better per-flow-fairness than DualQ (just like it has always done better in that regard as compared to single queue systems).  With L4S, anyone can use FQ to get near-perfect fairness if that is what they think is most important (and they can participate in high-fidelity congestion signaling).  So, the argument that L4S is broken because DualQ doesn't provide the same precise fairness as FQ is not a convincing one.  

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.

-Greg



On 11/21/19, 5:36 AM, "tsvwg on behalf of Scheffenegger, Richard" <[e-mail] on behalf of [e-mail]> wrote:

    
    
    Am 20.11.2019 um 21:53 schrieb Pete Heist:
    >
    >> On Nov 21, 2019, at 4:28 AM, Scheffenegger, Richard <[e-mail]> wrote:
    >>
    >> Hi Pete,
    >>
    >> Am 20.11.2019 um 21:20 schrieb Pete Heist:
    >>> allowing alternatives to be explored without a risk-benefit analysis.
    >>
    >> A basic risk-benefit analysis should always be done. Even benign
    >> optimizations can change the dynamics of a CC.
    >
    > Good point, but the additional risks that a second congestion signal adds should only be reduced performance that doesn’t impact other flows.
    >
    > :)
    >
    
    There have been proposals over the years, to utilize the absence of a
    congestion signal as another signal, to speed up with session-start.
    
    I know that Bob has also been looking into this as a thought, to use the
    absence (or lower than expected steady-state) feedback of a low-impact
    congestion signal as a new mechanism to speed up slow-start or adjust
    maximum burst sizes. and there are similar approaches in the literature
    (but most were never brought in front of the IETF).
    
    The addition of a secondary congestion signal also introduces the signal
    "absence of secondary congestion signal" (provided you can affirm
    yourself, that this secondary mechanism is actually working on the
    bottleneck). Misuse of such a "1-x" signal could impact other flows.
    
    But don't get me wrong - I am very much in favor to a new signal; in my
    opinion, there are valid point in favor and against both of the two
    current proposals, which can not be easily combined.
    
    However, perhaps a more in-depth analysis would show, that linking SCE
    and L4S queues behind each other (in any order, and any number of
    queues, only some of which become the bottleneck at a time), is not
    catastrophically problematic. I haven't run any numbers on this though.
    
    
     From a 20km view, the marking strategies between both - broken down on
    an individual flow - seem to be fairly similar. Both appear to be using
    instantaneous queue depth (sojorn time) without any smoothing of that
    signal at the bottleneck. One stated of with a step function profile,
    while the other with a slope. Form my understanding, both marking
    strategies have found that some aspects of the other are beneficial
    (deadband when the queue is fairly empty, and a more or less steep
    slope, ramping up to 1 well ahead of a full Q). One crucial difference
    is that one does lend itself to easily cope with 100G+ link speeds and
    very tight time and memory budget on silicon, while the other one lends
    itself ideally more towards the edge of the current internet.
    
    The main contention - from my observation - is the question if a DualQ
    can be implemented without infringing certain IPR, and if it actually
    meets the cited design goals. Or if classification and bandwidth
    allocation need to be an orthogonal means to prevent starvation of one
    or the other type of flow. Similar questions remain on the other side -
    is it possible to build an AQM that can be put on 200G / 400G switching
    chipsets and maintain the properties of (FQ_)Cake - especially when the
    Q never holds more than one packet of a flow at any time.
    
    The L4 feedback signal should be the least concern when designing a new
    CC mechanism (and AccECN would in principle support all the use cases of
    SCE - not necessarily particularly efficient per the latest draft where
    the TCP options need to be used; but we have had designs over the years
    to match up with SCE needs much better, and could still tweak things
    there. Remember that when we started, we did think that ECT1 may become
    an additional congestion signal in its own right - but that design fell
    through in the WG. But there is nothing stopping the WG to revisit this
    decision now, in light of new data.
    
    Remains the CC reaction, where I believe the base CC mechanism in L4S
    has had more in-depth reviews (dctcp) than SCE over the last ~9 years.
    
    Best regards,
        Richard