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

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

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

On Sat 22 Jun 2019 at 22:48, Jonathan Morton <chromatix99@gmail.com> wrote:

> > On 22 Jun, 2019, at 10:50 pm, David P. Reed <dpreed@deepplum.com> wrote:
> >
> > 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.
>
> 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.
>
> 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.
>
> 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?
>
>  - Jonathan Morton



I don’t think you would be able to find a refutation.
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.

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
and tractable,  flow-queuing in your DSL link looks like a perfectly
acceptable solution.
And I say that w/o religious positions.

The fact that flow-isolation generates incentives in sources to well behave
is good evidence to me.
Also the fact that even in situations that may look like the law of the
jungle, flow-isolation brings me performance that is predictable.
That brings more evidence that the solution is a good one.
In this respect Fq_codel (RFC 8290) looks like a simple useful tool.

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