From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 905DE3B2A4 for ; Sat, 22 Jun 2019 18:03:47 -0400 (EDT) Received: by mail-oi1-x22f.google.com with SMTP id a128so7138354oib.1 for ; Sat, 22 Jun 2019 15:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7sYBkFX0tccl8yOxPZ/wlbFNSlgahabWyNAcsyl8f60=; b=V9M+4VnGpp5FnapflcU43KQpqD4oHZHGlsUhb/NKVpEN0D/egTTkUYlFdBuAlvbPzk xVI8iO2cw0h10mH98WarDayQEfE0XDID5SKQbwkn/VV+kbuQBHGqgi9ES9J6eHw8nfeq m5AkfufJ+oio5wDQTL4MyEF/o5zSSqTmKW3lA141C8pOAKMLwFpgHnuhVfyOz1H6HcUB o2dM342Q5gxncwdrV3azUPFY9srFM8/lj0pHcFhap2RKJYpJ/c/UKk0BntI3RsbO+oTx Ez8J3GwP5gp8wRmFchcHRai8MljMpXc/3nI0/zCL1JV4pc93x8ZsV4jPYEJKfjOhmjnP FQzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7sYBkFX0tccl8yOxPZ/wlbFNSlgahabWyNAcsyl8f60=; b=D6KWktl7ASA5SyGbyCr//g02gT3xu/nhUH+MDVqNFCknRQ2iGRb6QG3FETVlr5isIg pRluzPx1qT16+KhXMLvLbbhzyMOV5EzHOXAHnAhMO1JaPZKEENlqpNUAc8aYNo5VZaWh atw380Vhi5RdbOUK462ZzLVccQA7mksvTgGopWfQGsiiF8TSeukLqi2WjICbdbg5oHWX cx1EvTLLhTJO+CJ7HAk9kOyb8eVgP517a75BtMDMxGta7S5vlo7+G38OKD+U5wJI3lTP oLV+4g0epH5SIVA5XZXb6IZK5QwlpvdsxgM+pv2pL1S3qnl46wbwpZbg1jTBCUzcDJDR Jaug== X-Gm-Message-State: APjAAAVZPTXNvn88aML+ys6my7vw4w/ZKSUuqnzrUlfHeQU1GCmg398j OrpP+xaesASk3C3Va8SKHM6aQOua+YEm4gVZ6Vs= X-Google-Smtp-Source: APXvYqyDmqzKGJdoE34N+SxyLdQvrYNpz8KB2ha8Ow1rHbM9IgUPN/MkW/RGXnj4kCx2znTw1ycSxDx3voUJ/1TkcfI= X-Received: by 2002:aca:e4c9:: with SMTP id b192mr6747320oih.82.1561241026746; Sat, 22 Jun 2019 15:03:46 -0700 (PDT) MIME-Version: 1.0 References: <350f8dd5-65d4-d2f3-4d65-784c0379f58c@bobbriscoe.net> <46D1ABD8-715D-44D2-B7A0-12FE2A9263FE@gmx.de> <835b1fb3-e8d5-c58c-e2f8-03d2b886af38@gmail.com> <1561233009.95886420@apps.rackspace.com> <71EF351D-AFBF-4C92-B6B9-7FD695B68815@gmail.com> In-Reply-To: <71EF351D-AFBF-4C92-B6B9-7FD695B68815@gmail.com> From: Luca Muscariello Date: Sun, 23 Jun 2019 00:03:35 +0200 Message-ID: To: Jonathan Morton Cc: Brian E Carpenter , "David P. Reed" , "ecn-sane@lists.bufferbloat.net" , tsvwg IETF list Content-Type: multipart/alternative; boundary="000000000000cedea3058bf0c037" Subject: Re: [Ecn-sane] [tsvwg] per-flow scheduling X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2019 22:03:47 -0000 --000000000000cedea3058bf0c037 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat 22 Jun 2019 at 22:48, Jonathan Morton wrote: > > On 22 Jun, 2019, at 10:50 pm, David P. Reed 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 regularl= y > 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 midsumme= r > weekend, that number is considerably inflated compared to normal, and my > available link bandwidth is substantially impacted as a result, indicatin= g > congestion. > > I did not see anything in your argument specifically about per-flow > scheduling for the simple purpose of fairly sharing capacity between flow= s > 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=E2=80=99t 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=E2=80=99t= 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=E2=80=99s paper, i.e. the Occam= =E2=80=99s 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. --000000000000cedea3058bf0c037 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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 choos= e to operate with shared links in a saturated state. That's known in th= e phone business as the Mother's Day problem. You want to have enough c= apacity for the rare near-overload to never result in congestion.

This is most likely true for core networks.=C2=A0 However, I know of severa= l real-world networks and individual links which, in practice, are regularl= y in a saturated and/or congested state.

Indeed, the average Internet consumer's ADSL or VDSL last-mile link bec= omes saturated for a noticeable interval, every time his operating system o= r game vendor releases an update.=C2=A0 In my case, I share a 3G/4G tower&#= 39;s airtime with whatever variable number of subscribers to the same netwo= rk happen to be in the area on any given day; today, during midsummer weeke= nd, that number is considerably inflated compared to normal, and my availab= le link bandwidth is substantially impacted as a result, indicating congest= ion.

I did not see anything in your argument specifically about per-flow schedul= ing for the simple purpose of fairly sharing capacity between flows and/or = between subscribers, and minimising the impact of elephants on mice.=C2=A0 = Empirical evidence suggests that it makes the network run more smoothly.=C2= =A0 Does anyone have a concrete refutation?

=C2=A0- Jonathan Morton


I don=E2=80=99t think you would be able = to find a refutation.=C2=A0
Going back for a second = to what David and also Brian have said about diffserv, QoS have proved to b= e an intractable =C2=A0problem and I won=E2=80=99t blame those who have tri= ed to propose solutions that currently work under very special =C2=A0circum= stances.=C2=A0 Things have not changed to make that problem simpler, quite = the opposite, mostly because the mix of applications is way more diverse to= day with less predictable patters.

If I apply the same mindset used in =C2=A0David=E2=80=99s paper,= i.e. the Occam=E2=80=99s razor, to get design principles to obtain a solut= ion that is simple=C2=A0
and tractable, =C2=A0flow-q= ueuing in your DSL link looks like a perfectly acceptable solution.
And I say that w/o religious positions.=C2=A0

The fact that flow-isolation generate= s 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.

<= br>

--000000000000cedea3058bf0c037--