<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat 22 Jun 2019 at 22:48, Jonathan Morton <<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On 22 Jun, 2019, at 10:50 pm, David P. Reed <<a href="mailto:dpreed@deepplum.com" target="_blank">dpreed@deepplum.com</a>> wrote:<br>
> <br>
> Pragmatic networks (those that operate in the real world) do not choose to operate with shared links in a saturated state. That's known in the phone business as the Mother's Day problem. You want to have enough capacity for the rare near-overload to never result in congestion.<br>
<br>
This is most likely true for core networks.  However, I know of several real-world networks and individual links which, in practice, are regularly in a saturated and/or congested state.<br>
<br>
Indeed, the average Internet consumer's ADSL or VDSL last-mile link becomes saturated for a noticeable interval, every time his operating system or game vendor releases an update.  In my case, I share a 3G/4G tower's airtime with whatever variable number of subscribers to the same network happen to be in the area on any given day; today, during midsummer weekend, that number is considerably inflated compared to normal, and my available link bandwidth is substantially impacted as a result, indicating congestion.<br>
<br>
I did not see anything in your argument specifically about per-flow scheduling for the simple purpose of fairly sharing capacity between flows and/or between subscribers, and minimising the impact of elephants on mice.  Empirical evidence suggests that it makes the network run more smoothly.  Does anyone have a concrete refutation?<br>
<br>
 - Jonathan Morton</blockquote><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I don’t think you would be able to find a refutation. </div><div dir="auto">Going back for a second to what David and also Brian have said about diffserv, QoS have proved to be an intractable  problem and I won’t blame those who have tried to propose solutions that currently work under very special  circumstances.  Things have not changed to make that problem simpler, quite the opposite, mostly because the mix of applications is way more diverse today with less predictable patters.</div><div dir="auto"><br></div><div dir="auto">If I apply the same mindset used in  David’s paper, i.e. the Occam’s razor, to get design principles to obtain a solution that is simple </div><div dir="auto">and tractable,  flow-queuing in your DSL link looks like a perfectly acceptable solution.</div><div dir="auto">And I say that w/o religious positions. </div><div dir="auto"><br></div><div dir="auto">The fact that flow-isolation generates incentives in sources to well behave is good evidence to me.</div><div dir="auto">Also the fact that even in situations that may look like the law of the jungle, flow-isolation brings me performance that is predictable.</div><div dir="auto">That brings more evidence that the solution is a good one.</div><div dir="auto">In this respect Fq_codel (RFC 8290) looks like a simple useful tool.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div></div>