Re: [Ecn-sane] tsvwg preso for sce is up

[Jonathan Morton <chromatix99@gmail.com>]

> On 30 Jul, 2019, at 5:38 pm, Dave Taht <dave.taht@gmail.com> wrote:
> 
> at 1:25:20 - mirja had asked what the sce marking threshold was, not
> the codel parameters (I think). I think she wanted to know the
> sce_threshold?

We used Cake, not fq_codel, so there is no sce threshold function, rather the ramp function carefully illustrated on two of the slides.  I'm pretty sure she was asking about the Codel parameters, which were the defaults, and she seemed satisfied with that answer.

> 1:27:49 Gorry said "This looks like FQ", and no, it's the real
> convergence of two SCE AQMed flows at 50mbit, 80ms rtt as Jonathan
> pointed out, which
> takes 45 seconds. And that brought to mind, what is your intuition?
> What would you expect for convergence using fq? And what is it?

FQ converges a whole lot quicker than that - basically as fast as the second flow can ramp up, which you can eyeball by looking at the first flow.  It also converges more precisely, and the ping flow would show a lower and more consistent reading.  Gorry's reaction is one of unfamiliarity with Flent plots showing FQ'd paths.

> 1:31:18 One thing long since vanished from the l4s debate is that
> codel achieves a ~5ms queue depth, where pie only gets 16ms. The need
> for "ultra-low-latency" is less when you get that kind of result in
> most cases from your aqm.

This is true, although PIE is specifically adjusted by default to accommodate a 30ms MAC grant delay on standard DOCSIS, which means about 15ms average is the best it *can* aim for without killing throughput on TCP.  I assume that PI2 is instead adjusted for the 1ms MAC grant delay of Low Latency DOCSIS.

When asked, the L4S team admitted they weren't familiar with Codel at all - and by inference, had done no testing with it.  We subsequently made the point that Codel is probably the most widely deployed AQM today, being part of the default qdisc on both Linux and OSX, and also available on BSD.  They have made no visible effort to ensure compatibility.

> Flent has a default sample rate of 200ms, which means that it can miss
> some details. You can sample instead at rates as low as 20ms, although
> this is murder on your local cpu and can heisenbug the tests. It's
> generally a good idea to be sampling at double the rate you care about
> (nyquist theorim), so a 40ms sample rate here would have shown more detail.
> 
> If you really, really want more detail than that, packet captures are
> a way to go. Got any?

We do use packet captures for debugging purposes, including exploring the detail of the cwnd evolution.  The graphs on the slides were produced for illustration more than anything else, though it's possible to infer much from them as-is.  I'll ask Pete if increasing the sample rate works on the hardware we use.

 - Jonathan Morton