From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 lists.bufferbloat.net (Postfix) with ESMTPS id 01AFE3B29E for ; Fri, 21 Jun 2019 16:38:06 -0400 (EDT) Received: by mail-pf1-x444.google.com with SMTP id a186so4160257pfa.5 for ; 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=YY/bJF4EWmIn5ASnjYYnx/0EXkJLg3u1t7Jbej93kEK9nJ2jVj6YvI59rJ2WBkfR7Q PWILPuFK9anmQzODr58dfJHyCUHFHsvXF1tsd/M596U/fGU/oqbNkjntPIYwe+Jo9DfI qdnjappNtXNIPIyEoosig2PUHsda60OFTY89rdLQtp1+hHp56p4ToNIHSt24BJF8gIES yhrPDCdSrInRZOArq3/oPJEMumi8lt+pmZ8e8+lACn8fFgt7rxqlJ96ieSzPog8UUyrp 9v8S1W1KwqUr0rMrCHqa2HDLl5ZUVtAWvMlaJX05yscBXIAP5aI7+ikAaAXklU9jIrSL N26Q== X-Gm-Message-State: APjAAAUAOqZ1+oQ/+pZMNWpTeYmUu1kDVodrRMitnVIMw9xnPPuiHp30 UvH7Ca0khGLygxyw8tVznMc= 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 , Sebastian Moeller , "David P. Reed" Cc: "ecn-sane@lists.bufferbloat.net" , tsvwg IETF list References: <350f8dd5-65d4-d2f3-4d65-784c0379f58c@bobbriscoe.net> <46D1ABD8-715D-44D2-B7A0-12FE2A9263FE@gmx.de> From: Brian E Carpenter 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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 22 Jun 2019 11:02:00 -0400 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: Fri, 21 Jun 2019 20:38:06 -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. >=20 > To me, it seems like a very religious position against per-flow queuein= g.=C2=A0 > BTW, I fail to see how this would violate (in a "profound" way ) the e2= e principle. >=20 > When I read it (the e2e principle) >=20 > Saltzer, J. H., D. P. Reed, and D. D. Clark (1981) "End-to-End Argument= s in System Design".=C2=A0 > In: Proceedings of the Second International Conference on Distributed C= omputing Systems. Paris, France.=C2=A0 > April 8=E2=80=9310, 1981. IEEE Computer Society, pp. 509-512. > (available on line for free). >=20 > It seems very much like the application of the Occam's razor to functio= n placement in communication networks back in the 80s. > I see no conflict between what is written in that paper and per-flow qu= eueing today, even after almost 40 years. >=20 > 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? >=20 > 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 princ= iple, 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 ar= e 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 the= re probably isn't anything we can do about it by twiddling with algorithms. Brian >=20 >=20 >=20 >=20 >=20 >=20 > =C2=A0 >=20 > On Fri, Jun 21, 2019 at 9:00 AM Sebastian Moeller > wrote: >=20 >=20 >=20 > > 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 = future. I find per-flow scheduling a violation of the e2e principle in su= ch a profound way - the dynamic choice of the spacing between packets - t= hat most people don't even associate it with the e2e principle. >=20 > 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 pa= ckets will be conserved. For the simple reason that it seems generally im= possible to guarantee that inter-packet spacing is conserved (think "cros= s-traffic" at the bottleneck hop along the path and general bunching up o= f 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 t= imewindow 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 "s= pacing between packets", I fail to see how L4S improves upon FQ in that r= egard. >=20 >=20 > =C2=A0IMHO having per-flow fairness as the defaults seems quite rea= sonable, 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 probabi= lity to send a throtteling signal to a low bandwidth flow (fair enough, i= t 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? >=20 >=20 > Best Regards > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian >=20 >=20 >=20 >=20 > > > > I detected that you were talking about FQ in a way that might hav= e 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 sched= uling. When Koen and I started working together on this, we discovered we= had identical 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= =2Enet/ > > > > _______________________________________________ > > Ecn-sane mailing list > > Ecn-sane@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/ecn-sane >=20 > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane >=20