[Ecn-sane] [tsvwg] per-flow scheduling

[Brian E Carpenter]

Below...
On 21-Jun-19 21:33, Luca Muscariello wrote:
> + David Reed, as I'm not sure he's on the ecn-sane list.
> 
> To me, it seems like a very religious position against per-flow queueing. 
> BTW, I fail to see how this would violate (in a "profound" way ) the e2e principle.
> 
> When I read it (the e2e principle)
> 
> Saltzer, J. H., D. P. Reed, and D. D. Clark (1981) "End-to-End Arguments in System Design". 
> In: Proceedings of the Second International Conference on Distributed Computing Systems. Paris, France. 
> April 8–10, 1981. IEEE Computer Society, pp. 509-512.
> (available on line for free).
> 
> It seems very much like the application of the Occam's razor to function placement in communication networks back in the 80s.
> I see no conflict between what is written in that paper and per-flow queueing today, even after almost 40 years.
> 
> If that was the case, then all service differentiation techniques would violate the e2e principle in a "profound" way too,
> and dualQ too. A policer? A shaper? A priority queue?
> 
> Luca

Quoting RFC2638 (the "two-bit" RFC):

>>>    Both these
>>>    proposals seek to define a single common mechanism that is used by
>>>    interior network routers, pushing most of the complexity and state of
>>>    differentiated services to the network edges.

I can't help thinking that if DDC had felt this was against the E2E principle,
he would have kicked up a fuss when it was written.

Bob's right, however, that there might be a tussle here. If end-points are
attempting to pace their packets to suit their own needs, and the network is
policing packets to support both service differentiation and fairness,
these may well be competing rather than collaborating behaviours. And there
probably isn't anything we can do about it by twiddling with algorithms.

    Brian







> 
> 
> 
> 
> 
> 
>  
> 
> On Fri, Jun 21, 2019 at 9:00 AM Sebastian Moeller <moeller0 at gmx.de <mailto:moeller0 at gmx.de>> wrote:
> 
> 
> 
>     > On Jun 19, 2019, at 16:12, Bob Briscoe <ietf at bobbriscoe.net <mailto:ietf at 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 at lists.bufferbloat.net <mailto:Ecn-sane at lists.bufferbloat.net>
>     > https://lists.bufferbloat.net/listinfo/ecn-sane
> 
>     _______________________________________________
>     Ecn-sane mailing list
>     Ecn-sane at lists.bufferbloat.net <mailto:Ecn-sane at lists.bufferbloat.net>
>     https://lists.bufferbloat.net/listinfo/ecn-sane
>