Re: [Ecn-sane] per-flow scheduling

[Luca Muscariello <luca.muscariello@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4302 bytes --]

+ 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










On Fri, Jun 21, 2019 at 9:00 AM Sebastian Moeller <moeller0@gmx.de> wrote:

>
>
> > 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
>
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane
>

[-- Attachment #2: Type: text/html, Size: 5879 bytes --]