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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 21 June 2019 20:38 UTC

Return-Path: <brian.e.carpenter@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 E0E32120130 for <tsvwg@ietfa.amsl.com>; Fri, 21 Jun 2019 13:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 la7T-8_093ya for <tsvwg@ietfa.amsl.com>; Fri, 21 Jun 2019 13:38:05 -0700 (PDT)
Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (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 DF07112012B for <tsvwg@ietf.org>; Fri, 21 Jun 2019 13:38:05 -0700 (PDT)
Received: by mail-pf1-x444.google.com with SMTP id 81so4139654pfy.13 for <tsvwg@ietf.org>; Fri, 21 Jun 2019 13:38:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3+CDpEvQOu+lSx7jwlmRQ5GIjLu0vxE1ZA7is563EaU=; b=eeEYXi+FzDOBOQ4w6fd6pMoukf7s5T6yUzkFRrku3KXS+LT0aCpYNTqhrNZW7o5cRb U/BD0PkILswShTSlfp+aK0Pbme+F/ktKtAF289a9eRGd3vqbHfniXyIKMwwB/jye7ULU mzaTTjIena038XB3+LZ4tie/HeisfcGJ1mdBPB8ys3BfPQj7gVh2zWH229P3TqPbiK5G hd1F0qjiDtyCWRZD/eHtJ4lxL/vgmGh1eTHMVR+eLfMwgWdIZKVhRfOZHnvvHmikNvyQ 4femmTYZqTSBVC6IKiPlOsc/a8B0ZB8DBN+USWh2TLcHaZ5Rw1z9gn/OWWaVLV5yBTE9 8uBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3+CDpEvQOu+lSx7jwlmRQ5GIjLu0vxE1ZA7is563EaU=; b=JRKd5OHdS92bWLcxY4vceSH2eKVEbYerj9wK42wgNPpw67SpBvS8k3j126qTp0UTAm XfwNlJyfJwOyCm1N/E6jm3ZmpxOjSKCZdnjjLxsnP3QOM1xStvX4B4YhS/RNSFtrTvMz Wc37T0delD7eqRcN27yAojTLzIVXSwWm3GbEAHw9Vrl6w0lRxWHNr8oBY81sGjBT7EIt +KzLDtRFIvLaZqmLtA23k0qs/c5RFPyrmOKdARIm5s8es0jaqJLYo++fy0da2kwrrMr8 3UvSM9pIMlNltbvcsVKcd1+7ekFx5fbuAB4mtQ61oNMI8bkUiooBaNfIVa1z87Leo2mX fWIQ==
X-Gm-Message-State: APjAAAU3P3Rme19AsME877irIdb3u8ZaLyHCyrffopePEBHPwMaVQMqr IdxoABffjzeWpQz1PtMAz4dtgJ8E
X-Google-Smtp-Source: APXvYqyJrtlfEyKgeJJfBEZxB/MrrZnOD146PuLj8TfhruMg6hd6KzLpP71JM1Prk93fq9zfTl7K+A==
X-Received: by 2002:a17:90a:28e4:: with SMTP id f91mr8736673pjd.99.1561149484983; Fri, 21 Jun 2019 13:38:04 -0700 (PDT)
Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id 23sm3968493pfn.176.2019.06.21.13.38.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jun 2019 13:38:04 -0700 (PDT)
To: Luca Muscariello <luca.muscariello@gmail.com>, Sebastian Moeller <moeller0@gmx.de>, "David P. Reed" <dpreed@deepplum.com>
Cc: "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, tsvwg IETF list <tsvwg@ietf.org>
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <835b1fb3-e8d5-c58c-e2f8-03d2b886af38@gmail.com>
Date: Sat, 22 Jun 2019 08:37:59 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <CAHx=1M4+sJBEe-wqCyuVyy=oDz7A+SG_ZxBbu_ZZDZiCHrX2uw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/w7bHJuWtbrjYAFMBD0K0eHWdlAs>
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: Fri, 21 Jun 2019 20:38:08 -0000

Below...
On 21-Jun-19 21:33, Luca Muscariello wrote:
> + David Reed, as I'm not sure he's on the ecn-sane list.
> 
> To me, it seems like a very religious position against per-flow queueing. 
> BTW, I fail to see how this would violate (in a "profound" way ) the e2e principle.
> 
> When I read it (the e2e principle)
> 
> Saltzer, J. H., D. P. Reed, and D. D. Clark (1981) "End-to-End Arguments in System Design". 
> In: Proceedings of the Second International Conference on Distributed Computing Systems. Paris, France. 
> April 8–10, 1981. IEEE Computer Society, pp. 509-512.
> (available on line for free).
> 
> It seems very much like the application of the Occam's razor to function placement in communication networks back in the 80s.
> I see no conflict between what is written in that paper and per-flow queueing today, even after almost 40 years.
> 
> If that was the case, then all service differentiation techniques would violate the e2e principle in a "profound" way too,
> and dualQ too. A policer? A shaper? A priority queue?
> 
> Luca

Quoting RFC2638 (the "two-bit" RFC):

>>>    Both these
>>>    proposals seek to define a single common mechanism that is used by
>>>    interior network routers, pushing most of the complexity and state of
>>>    differentiated services to the network edges.

I can't help thinking that if DDC had felt this was against the E2E principle,
he would have kicked up a fuss when it was written.

Bob's right, however, that there might be a tussle here. If end-points are
attempting to pace their packets to suit their own needs, and the network is
policing packets to support both service differentiation and fairness,
these may well be competing rather than collaborating behaviours. And there
probably isn't anything we can do about it by twiddling with algorithms.

    Brian







> 
> 
> 
> 
> 
> 
>  
> 
> On Fri, Jun 21, 2019 at 9:00 AM Sebastian Moeller <moeller0@gmx.de <mailto:moeller0@gmx.de>> wrote:
> 
> 
> 
>     > On Jun 19, 2019, at 16:12, Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>> wrote:
>     >
>     > Jake, all,
>     >
>     > 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.
> 
>     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.
> 
> 
>      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).
>     But enough about my opinion, what is the ideal fairness measure in your mind, and what is realistically achievable over the internet?
> 
> 
>     Best Regards
>             Sebastian
> 
> 
> 
> 
>     >
>     > 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.
>     >
>     > 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.
>     >
>     >
>     >
>     > Bob
>     >
>     >
>     > --
>     > ________________________________________________________________
>     > Bob Briscoe                               http://bobbriscoe.net/
>     >
>     > _______________________________________________
>     > Ecn-sane mailing list
>     > Ecn-sane@lists.bufferbloat.net <mailto:Ecn-sane@lists.bufferbloat.net>
>     > https://lists.bufferbloat.net/listinfo/ecn-sane
> 
>     _______________________________________________
>     Ecn-sane mailing list
>     Ecn-sane@lists.bufferbloat.net <mailto:Ecn-sane@lists.bufferbloat.net>
>     https://lists.bufferbloat.net/listinfo/ecn-sane
>