Re: [tsvwg] [Ecn-sane] per-flow scheduling
Luca Muscariello <luca.muscariello@gmail.com> Fri, 21 June 2019 09:33 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 469CC1201D2 for <tsvwg@ietfa.amsl.com>; Fri, 21 Jun 2019 02:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 hO1bfMykZVi1 for <tsvwg@ietfa.amsl.com>; Fri, 21 Jun 2019 02:33:13 -0700 (PDT)
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 D2C831201D4 for <tsvwg@ietf.org>; Fri, 21 Jun 2019 02:33:12 -0700 (PDT)
Received: by mail-oi1-x22b.google.com with SMTP id v186so4210166oie.5 for <tsvwg@ietf.org>; Fri, 21 Jun 2019 02:33:12 -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=vTlp3s+GEDMJr1wswnIvcRsAduAIp2iuEVWpCiE4ZfM=; b=vGNhMOXz9Goi/+MjV6tEpvWdYpiTT2zgBWh3XfuRJRPmyph/Aoa6wj4jo/eDbR+fFQ PWUN6XIl25YtBRIY6WaHTbhKoJsFM13jJsbz5QtQq+vOWH3apIJZWxwyEoOoaKtaRzU/ 7ht6kDceAU84F96gZp+tz5A3lRLG7CyR+2OvqDOl/H3B2RN5ky/3iv49XuKANyOYmASR qAMGqjkOCXxYg/FlgMzWOXad5aKadr9CRecoBNvqYOuGXE1E50RBsVMJdE48TALKvVum YAFG9YAw604xZ/Gh9PGcqXFlRZSytLxPzSHpXaiE1a5xaEQDWrwkk1zuYJJJD/9PC/L7 NVBQ==
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=vTlp3s+GEDMJr1wswnIvcRsAduAIp2iuEVWpCiE4ZfM=; b=ctbkhGBTi7rmsujtPiU3ZQh0KcponwaArgncBnAJHrIEIO9mPvRi4W3oXhw4vkGs1q ABgsrXEJElBguRi2uuqEjk3gKsbEjQrpGdXlOknzgKoeecrWdJkq0y/yLSMgQ27M14ww m3kl1P1xoKiXT0LmZ9zwjWtHHlo/zDFkzY/83v4T7rBM89BhUYD9obiycFZzb8D6R85x bJw9hyUje6grAX4hi75dm2Jlwrs1aVG0NPYciacGROKHMMZRoprIPIYYzj3xOEFgJV99 xXgK1WoKmc31XIKXtYFDqygdarI9+cCWdSn+sdCwX2UP1MhJmdNay08mjAryN5GI0Jb3 7klA==
X-Gm-Message-State: APjAAAU16A/m/l+7S251PQLr/qDThSqVSAxq6pPS9OvXpLJ2bFEjkzUy ummEvPh32ikmuNkOziSnvbBrxQEE7gLuGvggRu4=
X-Google-Smtp-Source: APXvYqxm5crLfuTNqivNaeUcwuUYSC45uuidm/hZPh/cwskPmbUMbyb45KjMlOKCYEM7M4y+I3WAyPzz8bQ73hB3V2o=
X-Received: by 2002:aca:cdc8:: with SMTP id d191mr2000618oig.151.1561109592001; Fri, 21 Jun 2019 02:33:12 -0700 (PDT)
MIME-Version: 1.0
References: <350f8dd5-65d4-d2f3-4d65-784c0379f58c@bobbriscoe.net> <46D1ABD8-715D-44D2-B7A0-12FE2A9263FE@gmx.de>
In-Reply-To: <46D1ABD8-715D-44D2-B7A0-12FE2A9263FE@gmx.de>
From: Luca Muscariello <luca.muscariello@gmail.com>
Date: Fri, 21 Jun 2019 11:33:00 +0200
Message-ID: <CAHx=1M4+sJBEe-wqCyuVyy=oDz7A+SG_ZxBbu_ZZDZiCHrX2uw@mail.gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>, "David P. Reed" <dpreed@deepplum.com>
Cc: Bob Briscoe <ietf@bobbriscoe.net>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, tsvwg IETF list <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000afd2d1058bd2262d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/lRzzky89sEw6jJqSeSiMRl4fKTE>
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 09:33:15 -0000
+ 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 On Fri, Jun 21, 2019 at 9:00 AM Sebastian Moeller <moeller0@gmx.de> wrote: > > > > On Jun 19, 2019, at 16:12, Bob Briscoe <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 > > https://lists.bufferbloat.net/listinfo/ecn-sane > > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane >
- [tsvwg] per-flow scheduling Bob Briscoe
- Re: [tsvwg] per-flow scheduling Kyle Rose
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Luca Muscariello
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Brian E Carpenter
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Jonathan Morton
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Brian E Carpenter
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Luca Muscariello
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Luca Muscariello
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Jonathan Morton
- Re: [tsvwg] [Ecn-sane] per-flow scheduling David P. Reed
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Jonathan Morton
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Jonathan Morton
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Luca Muscariello
- Re: [tsvwg] [Ecn-sane] per-flow scheduling David P. Reed
- Re: [tsvwg] [Ecn-sane] per-flow scheduling David P. Reed
- Re: [tsvwg] [Ecn-sane] per-flow scheduling David P. Reed
- Re: [tsvwg] [Ecn-sane] per-flow scheduling David P. Reed
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] per-flow scheduling David P. Reed
- Re: [tsvwg] [Ecn-sane] per-flow scheduling David P. Reed
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Bless, Roland (TM)
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Gorry Fairhurst
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Brian E Carpenter
- Re: [tsvwg] [Ecn-sane] per-flow scheduling David P. Reed
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Toke Høiland-Jørgensen
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] per-flow scheduling David P. Reed
- Re: [tsvwg] [Ecn-sane] per-flow scheduling David P. Reed
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Dave Taht
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Dave Taht
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Jonathan Morton
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Jonathan Morton
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Jonathan Morton
- Re: [tsvwg] [Ecn-sane] per-flow scheduling David P. Reed
- Re: [tsvwg] [Ecn-sane] per-flow scheduling David P. Reed
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Dave Taht
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Dave Taht
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Bob Briscoe
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Jonathan Morton
- Re: [tsvwg] [Ecn-sane] CNQ cheap-nasty-queuing (w… Luca Muscariello
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Kyle Rose
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Bob Briscoe
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Jonathan Morton
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Holland, Jake
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Kyle Rose
- Re: [tsvwg] [Ecn-sane] per-flow scheduling Jonathan Morton