Re: [Ecn-sane] [tsvwg] Comments on L4S drafts

[Jonathan Morton <chromatix99@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2866 bytes --]

> On 8 Jul, 2019, at 11:55 pm, Holland, Jake <jholland@akamai.com> wrote:
> 
> Also, I think if the SCE position is "low latency can only be
> achieved with FQ", that's different from "forcing only FQ on the
> internet", provided the fairness claims hold up, right?  (Classic
> single queue AQMs may still have a useful place in getting
> pretty-good latency in the cheapest hardware, like maybe PIE with
> marking.)

In support of this viewpoint, here are some illustrative time-series graphs showing SCE behaviour in a variety of contexts.  These are all simple two-flow tests plus a sparse latency probe flow, conducted using Flent, over a 50Mbps, 80ms RTT path under lab conditions.

First let's get the FQ case out of the way, with Reno-SCE competing against plain old Reno.  Here you can see Reno's classic sawtooth, while FQ keeps the latency of sparse flows sharing the link low; the novelty is that Reno-SCE is successfully using almost all of the capacity left on the table by plain Reno's sawtooth.  This is basically ideal behaviour, enabled by FQ.



If we then disable FQ and run the same test, we find that Reno-SCE yields very politely to plain Reno, again using only leftover capacity.  From earlier comments, I gather that a similar graph was seen by the L4S team at some point in their development.  Here we can see some small delay spikes, just before AQM activates to cut the plain Reno flow down.



Conversely, if we begin the SCE marking ramp only when CE marking also begins, we get good fairness between the two flows, in the same manner as with a conventional AQM - because both flows are mostly receiving only conventional AQM signals.  The delay spikes also reflect that fact, and a significant amount of capacity goes unused.  I gather that this scenario was also approximately seen during L4S development.



Our solution - which required only a few days' thought and calculation to define - is to make the SCE ramp straddle the AQM activation threshold, for single-queue situations only.  The precise extent of straddling is configurable to suit different network situations; here is the one that works best for this scenario.  Fairness between the two flows remains good; mostly the CE marks are going to the plain Reno flow, while the SCE flow is using the remaining capacity fairly effectively.  Notice however that the delay plateaus due to the weakened SCE signalling:



Compare this to single-queue SCE vs SCE performance in a single queue, using the basic SCE ramp which lies entirely below the AQM threshold:



And with the straddling ramp:



And with the SCE ramp entirely above the threshold:



And, finally, the *real* ideal situation - SCE vs SCE with FQ:



I hope this reassures various people that we do, in fact, know what we're doing over here.

 - Jonathan Morton


[-- Attachment #2.1: Type: text/html, Size: 5164 bytes --]

[-- Attachment #2.2: PastedGraphic-1.png --]
[-- Type: image/png, Size: 134772 bytes --]

[-- Attachment #2.3: PastedGraphic-2.png --]
[-- Type: image/png, Size: 142683 bytes --]

[-- Attachment #2.4: PastedGraphic-3.png --]
[-- Type: image/png, Size: 165646 bytes --]

[-- Attachment #2.5: PastedGraphic-4.png --]
[-- Type: image/png, Size: 171245 bytes --]

[-- Attachment #2.6: PastedGraphic-5.png --]
[-- Type: image/png, Size: 171513 bytes --]

[-- Attachment #2.7: PastedGraphic-6.png --]
[-- Type: image/png, Size: 172226 bytes --]

[-- Attachment #2.8: PastedGraphic-7.png --]
[-- Type: image/png, Size: 187005 bytes --]

[-- Attachment #2.9: PastedGraphic-8.png --]
[-- Type: image/png, Size: 140303 bytes --]