Re: [Ecn-sane] per-flow scheduling

[Sebastian Moeller <moeller0@gmx.de>]

> On Jun 19, 2019, at 16:12, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> Jake, all,
> 
> You may not be aware of my long history of concern about how per-flow scheduling within endpoints and networks will limit the Internet in future. I find per-flow scheduling a violation of the e2e principle in such a profound way - the dynamic choice of the spacing between packets - that most people don't even associate it with the e2e principle.

Maybe because it is not a violation of the e2e principle at all? My point is that with shared resources between the endpoints, the endpoints simply should have no expectancy that their choice of spacing between packets will be conserved. For the simple reason that it seems generally impossible to guarantee that inter-packet spacing is conserved (think "cross-traffic" at the bottleneck hop along the path and general bunching up of packets in the queue of a fast to slow transition*). I also would claim that the way L4S works (if it works) is to synchronize all active flows at the bottleneck which in tirn means each sender has only a very small timewindow in which to transmit a packet for it to hits its "slot" in the bottleneck L4S scheduler, otherwise, L4S's low queueing delay guarantees will not work. In other words the senders have basically no say in the "spacing between packets", I fail to see how L4S improves upon FQ in that regard.


 IMHO having per-flow fairness as the defaults seems quite reasonable, endpoints can still throttle flows to their liking. Now per-flow fairness still can be "abused", so by itself it might not be sufficient, but neither is L4S as it has at best stochastic guarantees, as a single queue AQM (let's ignore the RFC3168 part of the AQM) there is the probability to send a throtteling signal to a low bandwidth flow (fair enough, it is only a mild throtteling signal, but still).
But enough about my opinion, what is the ideal fairness measure in your mind, and what is realistically achievable over the internet?


Best Regards
	Sebastian




> 
> I detected that you were talking about FQ in a way that might have assumed my concern with it was just about implementation complexity. If you (or anyone watching) is not aware of the architectural concerns with per-flow scheduling, I can enumerate them.
> 
> I originally started working on what became L4S to prove that it was possible to separate out reducing queuing delay from throughput scheduling. When Koen and I started working together on this, we discovered we had identical concerns on this.
> 
> 
> 
> Bob
> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane