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

Jonathan Morton chromatix99 at gmail.com
Tue Jul 9 20:10:15 EDT 2019


> On 8 Jul, 2019, at 11:55 pm, Holland, Jake <jholland at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20190710/ccb45713/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 134772 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20190710/ccb45713/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.png
Type: image/png
Size: 142683 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20190710/ccb45713/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-3.png
Type: image/png
Size: 165646 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20190710/ccb45713/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-4.png
Type: image/png
Size: 171245 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20190710/ccb45713/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-5.png
Type: image/png
Size: 171513 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20190710/ccb45713/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-6.png
Type: image/png
Size: 172226 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20190710/ccb45713/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-7.png
Type: image/png
Size: 187005 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20190710/ccb45713/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-8.png
Type: image/png
Size: 140303 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20190710/ccb45713/attachment-0015.png>


More information about the Ecn-sane mailing list