Re: [tsvwg] L4S vs SCE

["Scheffenegger, Richard" <[e-mail]>]

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