Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs

[Jonathan Morton <[e-mail]>]

> On 16 Sep, 2019, at 10:27 am, Sebastian Moeller <[e-mail]> wrote:
> 
> So it looks like my fear that L4S-flows would completely crowd out standard compliant flows in the post bottleneck FQ-AQM scenario was unfounded! The intra-L4S latency increases in that situation, however, look terrible, but since they seem restricted to all L4S flows I can certainly live with that.

Except that's not what the data shows.  In Scenarios 5 & 6, the purple traces indicate queuing in the dumb FIFO (which affects *all* traffic), and that is much more serious with L4S traffic in play than with only RFC-3168 compliant (including SCE) traffic.  For direct comparison:

https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-09-13T045427-r1/sce-s6-2/batch-sce-s6-2-cubic-vs-cubic-50Mbit-10ms_fixed.png


https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-09-13T045427-r1/l4s-s6-2/batch-l4s-s6-2-prague-vs-prague-50Mbit-10ms_fixed.png


Note particularly how long the purple latency spikes last.  These are measured by parallel ICMP probes, and represent what a competing, sparse, latency-sensitive flow would see.

CUBIC and Reno-SCE almost avoid latency spikes altogether.  When Reno-SCE starts up, there's a very brief spike that's definitely less than a second wide.  For each Prague startup, the spike is at least one second and up to 5 seconds wide at its base, and much taller (the first one literally disappears off the top of the graph, which is at 110ms).  Given the baseline RTT of 10ms, this is clearly unacceptable.

Note also that in the above comparison, Reno-SCE is running into a completely non-SCE network.  In particular the link FIFO and the FQ-AQM that form the actual bottlenecks are not providing SCE signals, only RFC-3168 CE marks from the FQ-AQM and not the FIFO.  This shows the advantage of maintaining full backwards compatibility.

 - Jonathan Morton