Re: [tsvwg] L4S vs SCE

[Sebastian Moeller <[e-mail]>]

Hi Greg,

More below.

On November 21, 2019 12:14:11 AM GMT+01:00, Greg White <[e-mail]> wrote:
>It seems that a component of this debate revolves around whether FQ is
>a good solution or not

         [SM] The only party that keeps bringing up fq consistently seems to be the L4S proponents. In the context of the dual queue coupled AQM this is just a sreawman argument IMHO that distracts from the core of the issue. Tht being that implicitly everyone reading the L4S drafts will expect equitable sharing between the two traffic classes L4S divides the world into. In a sense a two class fair sharing system is one solution for the issue, as would be a strict priority scheduler that limits L4S traffic to 50% of the bandwidth (look, no fq). I even had a look at dualq's pseudocode and identified two toggles that most likely would allow to improve the worst case sharing behavior, potentially into a range that seems acceptable at least for the experiential roll-out. Not even exploring these options does not strike me as productive.


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

         [SM] I guess we agree that the most likely bottleneck for most users, is going to be the internet access link, so fixing those for users interested in low latency seems to be a more modest, but reachable goal.


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


         [SM] Well to recap the L4S approach of anything goes suffers from the issue that without an oracle scheduler divining the relative importance of active flows will not do the optimal thing either, but at the cost of allowing way more "catastrophic" sharing behavior, as evidenced in the results of sharing over DualQ at short RTTs. And to add insult to injury, opening multiple parallel flows to "trick" an fq aqm will also glresult in a higher bandwidth share in L4S, the only difference being that L4S did not try to make any guarantees in the first place....

Finally, it
>introduces complexity concerns that likely prevent it from actually
>being implemented in *every* bottleneck in the Internet.

[SM] How about we start with good enough and aim for the most relevant bottlenecks first instead of constructing an argument of the kind that shows that perfection seems unachievable and hence rejects the idea of even trying.


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

        [SM] It seems clear that the actual marking strategy of SCE and L4S are similar enough, that a unified method should exist to satisfy both camps, the goal in the end is a 1/p Control Loop. The issue about mutual exclusiveness of the two solutions really only comes from the side-effects of trying to change the semantics of the ECN codepoints', either subtly (SCE) or massively (L4S).
IMHO it seems worth revisiting the ECT(1) as classifier decision, but I fear that I do not represent the majority view in this.



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

         [SM] I agree, based on actually testing vodel versus fq_codel and cake on my Home-Link. I repeat though, that that issue really only isxrelevant for the sharing in each of L4S two queues. The sharing between these queues should be equitable independent on the guarantees inside each queue. IMHO that inter-queue sharing behavior is the sticking point.

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

[SM] Under the assumption that person is in control of the actual bottleneck, sure, but e.g. DOCSIS seems to plan to roll out L4S on the CMTS and I severely doubt all ISPs will give the user control over it's activation...


So, the
>argument that L4S is broken because DualQ doesn't provide the same
>precise fairness as FQ is not a convincing one.  

         [SM] I agree, the reason why it is broken is not that it is not FQ, but that it does not achieve the engineering goal of strictly separating the two traffic types. And in all fairness the "coupled" in dual queue coupled AQM and the L4S' team philosophical objections against fairness indicate to me that we are talking about a conscious design decision and notvsimplyvtge inability to come up with a strict and equitable sharing system.


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

         [SM] SCE is a marking strategy pure and simple. I see no insurmountable obstacle in combining the backward compatible SCE marking strategy with a better classifier to give L4S queueing to selected traffic.


I
>don't believe that the IETF should use the last IP codepoint for a
>signaling mechanism that can *only* work in FQ.

        [SM] Again I agree, but luckily that is simply not true, tack on a better identifier for L4S style senders and you are off to the races....

Sebastian


P.S.: If it appears that I am repeating my arguments than I admit that to be true, but so are Greg's.



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