<div dir="ltr"><div>+ David Reed, as I'm not sure he's on the ecn-sane list.<br></div><div><br></div>To me, it seems like a very religious position against per-flow queueing. <div>BTW, I fail to see how this would violate (in a "profound" way ) the e2e principle.</div><div><br></div><div>When I read it (the e2e principle)</div><div><span style="font-family:sans-serif;font-size:12.6px"><br></span></div><div><span style="font-family:sans-serif;font-size:12.6px">Saltzer, J. H., D. P. Reed, and D. D. Clark (1981) "End-to-End Arguments in System Design". </span></div><div><span style="font-family:sans-serif;font-size:12.6px">In: Proceedings of the Second International Conference on Distributed Computing Systems. Paris, France. </span></div><div><span style="font-family:sans-serif;font-size:12.6px">April 8–10, 1981. IEEE Computer Society, pp. 509-512.</span><br></div><div><font face="sans-serif"><span style="font-size:12.6px">(available on line for free).</span></font></div><div><br></div><div>It seems very much like the application of the Occam's razor to function placement in communication networks back in the 80s.</div><div>I see no conflict between what is written in that paper and per-flow queueing today, even after almost 40 years.</div><div><br></div><div>If that was the case, then all service differentiation techniques would violate the e2e principle in a "profound" way too,</div><div>and dualQ too. A policer? A shaper? A priority queue?</div><div><br></div><div>Luca</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 21, 2019 at 9:00 AM Sebastian Moeller <<a href="mailto:moeller0@gmx.de" target="_blank">moeller0@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Jun 19, 2019, at 16:12, Bob Briscoe <<a href="mailto:ietf@bobbriscoe.net" target="_blank">ietf@bobbriscoe.net</a>> wrote:<br>
> <br>
> Jake, all,<br>
> <br>
> 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.<br>
<br>
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.<br>
<br>
<br>
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).<br>
But enough about my opinion, what is the ideal fairness measure in your mind, and what is realistically achievable over the internet?<br>
<br>
<br>
Best Regards<br>
Sebastian<br>
<br>
<br>
<br>
<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> <br>
> <br>
> Bob<br>
> <br>
> <br>
> -- <br>
> ________________________________________________________________<br>
> Bob Briscoe <a href="http://bobbriscoe.net/" rel="noreferrer" target="_blank">http://bobbriscoe.net/</a><br>
> <br>
> _______________________________________________<br>
> Ecn-sane mailing list<br>
> <a href="mailto:Ecn-sane@lists.bufferbloat.net" target="_blank">Ecn-sane@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/ecn-sane" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/ecn-sane</a><br>
<br>
_______________________________________________<br>
Ecn-sane mailing list<br>
<a href="mailto:Ecn-sane@lists.bufferbloat.net" target="_blank">Ecn-sane@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/ecn-sane" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/ecn-sane</a><br>
</blockquote></div>