[Battlemesh] lossless low latency congestion control with "SCE" (vs cablelabs l4s)

Wed Jul 10 11:04:24 CEST 2019

I'd hoped to get to where we could test this over wifi this week, but I
think too many kernel patches are required as yet (
https://github.com/chromi/sce/commits/sce ) , and most of the work is in
the tcps and sch_cake.

That said basic ecn support is universally enabled in fq_codel, you can
enable it in your tcp stack with a sysctl.

It's not all good news - I've generally found an excess of ecn flows tends
to hurt routing protocols lacking ecn (as well as other forms of non-ecn
traffic) - batman, not being IP based, is unfixable, babel needs a 1 line
patch (and to evolve a notion of CC in the first place, and have a good rtt
based metric) - it is generally my hope that we see more rtt based cc's
like bbr evolve to replace reno and cubic, also, instead of tons of
marks....

The last graph here is to die for, though.

---------- Forwarded message ---------
From: Jonathan Morton <chromatix99 at gmail.com>
Date: Tue, Jul 9, 2019 at 5:10 PM
Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts
To: Holland, Jake <jholland at akamai.com>
Cc: ecn-sane at lists.bufferbloat.net <ecn-sane at lists.bufferbloat.net>,
tsvwg at ietf.org <tsvwg at ietf.org>, De Schepper, Koen (Nokia - BE/Antwerp) <
koen.de_schepper at nokia-bell-labs.com>

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

_______________________________________________
Ecn-sane mailing list
Ecn-sane at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/ecn-sane

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ml.ninux.org/pipermail/battlemesh/attachments/20190710/44712e54/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://ml.ninux.org/pipermail/battlemesh/attachments/20190710/44712e54/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://ml.ninux.org/pipermail/battlemesh/attachments/20190710/44712e54/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://ml.ninux.org/pipermail/battlemesh/attachments/20190710/44712e54/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://ml.ninux.org/pipermail/battlemesh/attachments/20190710/44712e54/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://ml.ninux.org/pipermail/battlemesh/attachments/20190710/44712e54/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://ml.ninux.org/pipermail/battlemesh/attachments/20190710/44712e54/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://ml.ninux.org/pipermail/battlemesh/attachments/20190710/44712e54/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://ml.ninux.org/pipermail/battlemesh/attachments/20190710/44712e54/attachment-0015.png>