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

[Sebastian Moeller <[e-mail]>]

Hi Jonathan, hi Pete

right you are. I had ignored the "transient spike" (even though at multiple seconds duration it can wreck havoc on any latency sensitive traffic on that AQM). I really only wanted to conceed that my intuition that L4S flows will completely incapacitate a post-bottleneck FQ-AQM. And obviously did not look closely enough at the ICMP traces. Thanks both of you for the great data source and the support in interpretation!

Best Regards & many thanks
	Sebastian


> On Sep 16, 2019, at 10:06, Jonathan Morton <[e-mail]> wrote:
> 
>> 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.

	+1; this backwards compatibility helps SCE flows ot behave like good neicens should do instead of simply bulldozing over everything. ;)


> 
>  - Jonathan Morton
>