Re: [tsvwg] L4S vs SCE (Evolvability)

[Sebastian Moeller <[e-mail]>]

Hi Greg,

please note that I am not a member of the SCE development team, but I have looked at the L4S/SCE comparisons in detail and hence believe I can add (other people's) data to this discussion thread.

More below in-line.

> On Jan 7, 2020, at 01:09, Greg White <[e-mail]> wrote:
> 
> David,
> See [GW] below.
> Greg
> 
> On 1/1/20, 4:33 PM, "tsvwg on behalf of Black, David" <[e-mail] on behalf of [e-mail]> wrote:
> 
>    Bob,
>    (posting as an individual)
> 
>    The assertion that SCE traffic will "starve" is just plain wrong in the following ...
> 
>>> The SCE markings can be used independently whether you have multiple
>>> queues or just a single queue.
>> [BB] This seems to be the opposite of reality. Perhaps you've used the
>> word 'can' because you think it might be possible. But there's good
>> reason to doubt that. As follows...
>> 
>> Packets from non-SCE and from SCE senders are indistinguishable by just
>> looking at them. So, if there's a single queue, they have to be mixed
>> together in it {Note 1}. But a single queue can only have one length.
>> Any transports that don't understand SCE drive the single queue to a
>> deeper operating point (defined by CE or drop).
> 
>    The reasoning appears to be sound up to this point, but the next sentence does not follow from the above:
> 
>> This overruns the SCE
>> operating point, and causes SCE marking to approach 100% {Note 2}. Then
>> those transports that do understand SCE will starve.
> 
>    Actually, it causes both SCE and non-SCE senders to operate at that "deeper operating point (defined by CE or drop)" because SCE traffic has an RFC-3168-like response to CE marks, and the usual reaction to drops.  The result is a deeper queue than would have resulted in the absence of non-SCE traffic, but the result is definitely *not* starvation.
> 
> [GW] Is that true?  Setting aside Bob's "Note 2" implementation, it seems your statement would only be true if the SCE sender had /no/ cwnd response to SCE-marks (i.e. ECT(1)) at all (which I guess would make it a non-SCE sender). I know the SCE congestion controller is still under development, but I seem to remember Jonathan indicating that it would aim to reduce its congestion window until the SCE-mark rate was 50% (don't quote me on that being the precise behavior currently).   If the non-SCE senders continue to drive the SCE-mark rate to 100% in order to experience occasional CE-marks, then the SCE senders would continue to reduce their congestion window on every RTT.   I suppose one way to (somewhat) get the behavior you are describing would be for an SCE sender to, upon receiving a single CE-mark, revert to an RFC3168 compliant mode and stop responding to SCE-marks.  I don’t believe that is the behavior today.

	[SM] I believe we could just look at the data collected for scenario 1 at https://github.com/heistp/sce-l4s-bakeoff/blob/master/README.md#scenario-1, especially https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/sce-s1-2/batch-sce-s1-2-cubic-vs-reno-sce-50Mbit-80ms_fixed.png, https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/sce-s1-2/batch-sce-s1-2-cubic-vs-reno-sce-50Mbit-10ms_fixed.png, and https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/sce-s1-2/batch-sce-s1-2-cubic-vs-reno-sce-50Mbit-0ms_fixed.png, which show the "degenerate" single queue SCE-AQM case. 

	And your intuition seems to be right, the tested naive SCE AQM will, in single queue configuration, unduly slow down SCE-enabled flows (just like a single queue L4S AQM would unduly slow down flows with a 1/sqrt(p) response).
IMHO this seems to indicate that for single queue operation (or operation at similar computational cost to a single queue?) the SCE AQM needs refinements, and it is not clear yet how well this can be made to work but there is work on-going in that regard. It certainly seems safe behavior from the perspective of throughput of the standard non-SCE traffic though, and it also seems relatively easy to simply avoid instantiating single queue SCE AQMs until this issue is remedied.

	This issue is also explicitly acknowledged by SCE's developers at https://github.com/heistp/sce-l4s-bakeoff/blob/master/README.md#list-of-sce-issues:

"SCE Single Queue Non-SCE Unfairness

Because SCE is marked at lower queue depths than CE, non-SCE flows will outcompete SCE flows in a single queue without a change to the SCE marking ramp, as presented at IETF 105. This is effective, however it trades off some of the benefits of SCE, and requires tuning, which may be dependent on the link or traffic conditions.

Another solution is fair queueing. One of the arguments against this is the resource requirements for fair queueing, which led to the proposed Lightweight Fair Queueing and Cheap Nasty Queueing. Another argument is the perception that FQ can do harm to periodic bursty flows, however we have not yet shown this to be the case with hard evidence, and the SCE team is in general in favor of FQ.

We continue to explore alternative solutions to this challenge, and will seek to quantify any potential side effects of FQ, however this is a decades old debate that may not be resolved any time soon."


https://datatracker.ietf.org/meeting/105/materials/slides-105-tsvwg-sessa-61-some-congestion-experienced-00 (slide 13) shows that e.g. modification to the marking ramp-function can help ameliorate that issue.




> 
> 
>    Thanks, --David