From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 ADAA63CB35 for ; Fri, 21 Jun 2019 05:33:12 -0400 (EDT) Received: by mail-oi1-x230.google.com with SMTP id m206so4181061oib.12 for ; 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=ag0/zYmBIrY/25hw/Bb6CvLT4DjvNa1S+8yWXz+8QaAxPdir3DA/v/zptIlWbJ3xNH cyLN8Aet69YwbjkUdi1J6xoeUtlQmn8sGKN0Fo8kkt9WH/G5X+gBnZwOncVN08/24GjA A/IDgebZultzNBYUupL9msq1BeUNjatQ0FMEPpsynFCFUPnB9uWAvWtfxsYjGA7J9bmR zXQUieZEze/pfn0RM5QAPXozibPXk0UJ47DII2xgb+i2LpJ5q8cxp/s0pPPCk5vngkV8 Dg8hK8J2zsmxzP0ds0Cu2Si9QlIlJaXo3zCL5vkaRYAoi0opZwXIfu+EvLZKz3MFX57N CptQ== X-Gm-Message-State: APjAAAVgHB0yYs/gre1cJKSWDA8QSMXMLu31qf1SEkL/oQd+rCI9yGZo wyHLIzzq2LmsyF7z44sUKN6UEJE4/7jxC2r/7AA= 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 Date: Fri, 21 Jun 2019 11:33:00 +0200 Message-ID: To: Sebastian Moeller , "David P. Reed" Cc: Bob Briscoe , "ecn-sane@lists.bufferbloat.net" , tsvwg IETF list Content-Type: multipart/alternative; boundary="000000000000afd2d1058bd2262d" Subject: Re: [Ecn-sane] 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: Fri, 21 Jun 2019 09:33:12 -0000 --000000000000afd2d1058bd2262d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable + 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=E2=80=9310, 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 wrote: > > > > On Jun 19, 2019, at 16:12, Bob Briscoe 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 futur= e. > 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 wi= ll > be conserved. For the simple reason that it seems generally impossible to > guarantee that inter-packet spacing is conserved (think "cross-traffic" a= t > the bottleneck hop along the path and general bunching up of packets in t= he > 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 neith= er > 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 se= nd > 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 y= ou > (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 schedulin= g. > 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 > --000000000000afd2d1058bd2262d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+ David Reed, as I'm not sure he's on the ecn= -sane list.

To me, it seems like a very religious p= osition against per-flow queueing.=C2=A0
BTW, I fail to see how this wo= uld violate (in a "profound" way ) the e2e principle.
<= br>
When I read it (the e2e principle)

Saltzer, J. H., D. P. Reed, an= d D. D. Clark (1981) "End-to-End Arguments in System Design".=C2= =A0
In: Proceedings of the Second International Conference on Distributed Com= puting Systems. Paris, France.=C2=A0
April 8=E2=80=9310, 1981. IEEE Computer = Society, pp. 509-512.
(available on line for free).

It seems very much like the application of the Occam&#= 39;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.

I= f that was the case, then all service differentiation techniques would viol= ate the e2e principle in a "profound" way too,
and dual= Q too. A policer? A shaper? A priority queue?

Luca=





=



=C2=A0

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 prof= ound way - the dynamic choice of the spacing between packets - that most pe= ople don't even associate it with the e2e principle.

Maybe because it is not a violation of the e2e principle at all? My point i= s that with shared resources between the endpoints, the endpoints simply sh= ould have no expectancy that their choice of spacing between packets will b= e conserved. For the simple reason that it seems generally impossible to gu= arantee that inter-packet spacing is conserved (think "cross-traffic&q= uot; at the bottleneck hop along the path and general bunching up of packet= s 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 bottl= eneck which in tirn means each sender has only a very small timewindow in w= hich to transmit a packet for it to hits its "slot" in the bottle= neck L4S scheduler, otherwise, L4S's low queueing delay guarantees will= not work. In other words the senders have basically no say in the "sp= acing between packets", I fail to see how L4S improves upon FQ in that= regard.


=C2=A0IMHO 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, b= ut neither is L4S as it has at best stochastic guarantees, as a single queu= e AQM (let's ignore the RFC3168 part of the AQM) there is the probabili= ty 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 min= d, and what is realistically achievable over the internet?


Best Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian




>
> I detected that you were talking about FQ in a way that might have ass= umed my concern with it was just about implementation complexity. If you (o= r 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 p= ossible to separate out reducing queuing delay from throughput scheduling. = When Koen and I started working together on this, we discovered we had iden= tical concerns on this.
>
>
>
> Bob
>
>
> --
> ________________________________________________________________
> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bobbriscoe.net/=
>
> _______________________________________________
> Ecn-sane mailing list
> Ec= n-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane<= /a>

_______________________________________________
Ecn-sane mailing list
Ecn-san= e@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/ecn-sane
--000000000000afd2d1058bd2262d--