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

[Sebastian Moeller <[e-mail]>]

Hi Bob,

I hope you had an enjoyable holiday.

> On Jul 21, 2019, at 13:53, Bob Briscoe <[e-mail]> wrote:
> 
> Sebastian,
> 
> On 19/07/2019 23:03, Sebastian Moeller wrote:
>> Hi Jonathan,
>> 
>> 
>> 
>>> On Jul 19, 2019, at 22:44, Jonathan Morton <[e-mail]> wrote:
>>> So I'm pleased to hear that the L4S team will be at the hackathon with a demo setup.  Hopefully we will be able to obtain comparative test results, using the same test scripts as we use on SCE, and also insert an RFC-3168 single queue AQM into their network to demonstrate what actually happens in that case.  I think that the results will be illuminating for all concerned.
>> 	What I really would like to see, how L4S endpoints will deal with post-bottleneck ingress shaping by an RFC3168 -compliant FQ-AQM. I know the experts here deems this not even a theoretical concern, but I really really want to see data, that L4S flows will not crowd out the more reactive RFC3168 flows in that situation. This is the set-up quite a number of latency sensitive end-users actually use to "debloat" the internet and it would be nice to have real data showing that this is not a concern.
> Both teams brought their testbeds, and as of yesterday evening, Koen and Pete Heist had put the two together and started the tests Jonathan proposed. Usual problems: latest Linux kernel being used has introduced a bug, so need to wind back. But progressing.

	Great!

> 
> Nonetheless, altho it's included in the tests, I don't see the particular concern with this 'Cake' scenario.

	This is not a "cake" scenario, but rather an sqm-scripts scenario; for a number of years we have directed latency sensitive users to use ingress and egress traffic shaping to keep latency under load increase in check. To make things easy we offer an exemplary set of scripts under the name sqm-scripts, see https://github.com/tohojo/sqm-scripts, that make it easy to create and test this approach (we also integrated it nicely into OpenWrt to make it eve simpler to get decent de-bufferblat configured for home networks). We implanted the general approach of an FQ-AQM as post-bottleneck shaper, with HFSC+fq_codel (since retired), HTB+fq_codel and also with cake, but the whole approach proceeds cake existence. Now, cake takes most of these ideas to a new level (e.g. operating as ingress shaper to actually shape the ingress rate instead of the shaper's egress rate), but it is not that this approach requires cake.


> How can "L4S flows crowd out more reactive RFC3168 flows" in "an RFC3168-compliant FQ-AQM". Whenever it would be happening, FQ would prevent it.

	I have heard this repeatedly, but I want to see hard data instead of theoretic considerations, please. Especially since nobody bothered to think about post-bottleneck ingress shaping before I brought it up, this certainly was not considered during the design of L4S; so if it is not a problem, just demonstrate this to shut me up ;).
	So to be clear the scenario I want tested is something like the following:

1) Internet: the test servers connected with say 10 times the true bottleneck rate

2) "true bottleneck": say 100 Mbps / 40 Mbps (using a relative dump over-buffered traffic shaper, like most ISPs seem to do, so at least buffering for >=300ms per direction)

3) post-bottleneck ingress&egress flow-fair shaping: say 90/36 Mbps.

What I want to see is that with that set-up bi-directional saturating traffic with both RFC3168 and L4S flows that each flow still sees roughly its fair share of the bandwidth. I fear that L4S with its linear CE-response will react slower to AQM signals and hence will successively eat a bit of the RFC3168-flow's bandwidth share that throttle back due to receiving a CE mark. I hope my fears are over blown, but at the current state it was not easy enough to actually test that myself.


> 
> To ensure we're not continually being blown into the weeds, I thought the /only/ concern was about RFC3168-compliant /single-queue/ AQMs.

	I believe I have been clear that my concern is the effect of under-responsive L4S-flows on the flow fairness with a post-bottleneck ingress FQ-AQM system. So no compatibility with a "RFC3168-compliant /single-queue/ AQM" is not the only concern. Especially since I know that there is a community out there using post-bottleneck ingress FQ-AQM to keep latency under load increase under control, who would be less than impressed if L4S would destroy the effectiveness of their "solution". Really, I wonder why the L4S project did not reach out to this community during the design phase, since there users could be your natural supporters assuming your solution scratches their itches sufficiently well.

Best Regards
	Sebastian

> 
> 
> 
> Bob
> 
>> 
>> Best Regards
>> 	Sebastian
>> 
>> 
>> 
>>> - Jonathan Morton
>>> _______________________________________________
>>> Ecn-sane mailing list
>>> [e-mail]
>>> https://lists.bufferbloat.net/listinfo/ecn-sane
>> _______________________________________________
>> Ecn-sane mailing list
>> [e-mail]
>> https://lists.bufferbloat.net/listinfo/ecn-sane
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>