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

Luca Muscariello <luca.muscariello@gmail.com> Sat, 22 June 2019 22:03 UTC

Return-Path: <luca.muscariello@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3CB120048 for <tsvwg@ietfa.amsl.com>; Sat, 22 Jun 2019 15:03:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pcPlQDhJbAn for <tsvwg@ietfa.amsl.com>; Sat, 22 Jun 2019 15:03:47 -0700 (PDT)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A6D12001A for <tsvwg@ietf.org>; Sat, 22 Jun 2019 15:03:47 -0700 (PDT)
Received: by mail-oi1-x231.google.com with SMTP id e189so7073854oib.11 for <tsvwg@ietf.org>; 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=ti8AeB4uISXyZBqIvnAQ1+jhAuUEgVBzV/bYtqYWY8uDEUJSwkz7gJTqX1znR/HxGC I1o89k4BvZw//B50VOxrxaLTTkeFHkZ6A58L02eT6ctFfYf84ztQqrU0n8d3gsRAfjpt n5pDHI1xNvFBQ8PhKYi5oeLP8RBoQTKInVTGfQwCCdsMzaJ6PCet31OOIpXAi/AfDNOd mk0idA2KywvLpu8ZnnbQNHBkT2DHPZxCTtxrFQ7LZinUTm1jhcl33unA+y1XW656KMNn sHfKVr96fctH4hzaAZfE8sOaNZP2dMxpMZTzTbutSQU7JPp7Eg07xjUhP/tM3p0ET9+F skCg==
X-Gm-Message-State: APjAAAVwUtPKLa7CtvWHZk9szWHMyF/bCClicOoajJLFUIgl+fRwToE3 I528txnD8DTD+Xs97r4DJh0zvlfT5DxAdqE0xKU=
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> <CAHx=1M4+sJBEe-wqCyuVyy=oDz7A+SG_ZxBbu_ZZDZiCHrX2uw@mail.gmail.com> <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 <luca.muscariello@gmail.com>
Date: Sun, 23 Jun 2019 00:03:35 +0200
Message-ID: <CAHx=1M68JBFhwETW5TE0s20tCHVayrw6j2x0kJh6PH18JDUSUA@mail.gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, "David P. Reed" <dpreed@deepplum.com>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, tsvwg IETF list <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cedea3058bf0c037"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/5qlyu5NIW06P34aYCfuGdWBO2xE>
Subject: Re: [tsvwg] [Ecn-sane] per-flow scheduling
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Jun 2019 22:03:50 -0000

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.