From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 30F253CB35; Sat, 24 Aug 2019 17:59:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1566683982; bh=H9cu0uzB9MaB6klORs12zljhTCcDXON4HidL/O3aX+s=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=ZZOYN5juXcV4PyOcYswO1imHN+Kte8qsYS/RO3yxL5/wyJxqNoH0EVR/AqoWEhBEI 8IPwtwL/T5pS3VCv3HJZKiPrCLXWrY6HRmjxfJWWdYKud+aBy5M0ROEVZKs+Bsqt3G hlvXPPv+jt+idnpx9tL8PYlGszeFiOhW4YU0YDr0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.12.241.96]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MY68T-1hihUJ1zhd-00YRDU; Sat, 24 Aug 2019 23:59:42 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: <201908241627.x7OGR0ia068613@gndrsh.dnsmgr.net> Date: Sat, 24 Aug 2019 23:59:40 +0200 Cc: Dave Taht , ECN-Sane , bloat@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <3534C5ED-2F1F-4785-AAE2-7FC1E7DFB02F@gmx.de> References: <201908241627.x7OGR0ia068613@gndrsh.dnsmgr.net> To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:hKTByjPEZs4ZiFeOxIm1nbKGgqNdeDESJ8Avw3OAFFff7QO2Dtr BBNoj3eoEaTAv5CZONWiJ+k6lTsyqfNslIj5PZE801pY2MsLRIEuXEdN6oaAZuKVEmZo47a x/I6lGsQxliPQgcb/gUXuRce/6dQl9uM7mQY5by5SeP2g3lF0U2dFS3Suzv03MWO5wIgcAe +0zB9jD745TuarryL6z+g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:oQJmcp0Kd9s=:1nD6SPs0hGyDZqX8husZ8Y 2VLOLQUZov/WU53YudyhG8nGUea9bwq88ILAv6Z5TVb4bHv8hpmo0DGdu5+q9DWSv8gB6xRX1 JEE9Rb5XACOb+T4JZdWd3R39k24hzDF3CdHkOO31814K+MY1NQ2EujyVD9ajNtoexwJwJw6Pa 2e1v/QEq5ZrZ4LHTmyk6ETLGs84KyVHTh7kzXNvGcxt3rM4CZZlDAl33RD/l3UA2LL85J7P48 nAZzn7w228HrTnBytcjEFprqCxNsohVGNiEt7Ib1Kq5zKHFkq06vCTLHk7111L3pbYysfASEA NAHUkyw/vif+eKk3MCr+znH15hfJj4+gRfNcD+K/Ti5RxccSCGJn163fw6+k7U7ayLH0KT6Il kCySlNVHOkG0FLBfTBEBLKyCK7NW9niRhE+DmeeQBNtp1i9xh2EmVbOWJ31yu9kzb86xLAH/N hJP8L/Ul+yFj2ljAbyx5x5esKQzMssLbg6zMbDmjsPHPbSly4SHKaSwiVu7JkFGurxnPxqBQ9 jDgZ3W9GO7z3S5OBQ1+e7j9jjrqSh/tts7oubp7GvzFTL8KcAypR929hd55tqopO4CdgqI4F2 K3PVGxUJUiGAiEUROSxpFiwykPXs0ugp2utggGv052Obua0zTx1ycXrRld99SwpTFy71axHnn oLvAf4rUQujxBHGUiOM2QTOkPKQxy62Lg+fHKmO+/SDZ8D02lFvpGkQ5+EAawKsdNIgjbJtKd 3g7IMxEc+JQ4opBoEQiKwHifx2VH5ItMjnn8MWwCUetMyQ7sGjUg20FUImcOrQugpECoaNeyr 3+Q02/ydjlar/N3o73tM8mGpAor02XDbVKleRMAZi1uSazg9B6Ai44tjIJT898TNaZeRkAvp0 qpFDMX6EKCbeCfj8lCL8Te9eWAd2pSUo8BmSUYWmMjwBHSLZPP+v7T5Z5tyWw578lVDibAB5m RjgZDWXmfFSdxFA6fTk8agwG8dbQPUwvOnJq+cJ0aHWyahEothJNkiRpsdav7H2nzfDITFjH9 qwHdDsTXh+3yiI4d09E0ZOPGjMTNJfHIJYeVMghDYOad8MVOuF9SDsEKsQVFxGKiLhbd7XVjM /SMYDW6QhfwdW/1enfdFTkoM3qaepJO8YbDCVQkVaLV6yHM+FWm4C3Hc6GhvVTfmj9BAqinRC WO/6Y= Subject: Re: [Bloat] [Ecn-sane] non queue building flows ietf draft review. X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 21:59:45 -0000 Well, now I wasted my evening by going through this once again, and I remember = why I forgot its content from last time around... I am with Dave, it is a bit wordy for effectively saying let's call 2A =3D= NBQ, and it comes with loads of tangential text that really seems to = belong to an actually substantial L4S RFC. I wrote way to much and I am way to remote of all of this but I will try = to just extract the most relevant part of my draft (the wifi = recommendation map NBQ to AC_VO is horrendously wrong IMHO). > On Aug 24, 2019, at 18:27, Rodney W. Grimes <4bone@gndrsh.dnsmgr.net> = wrote: >=20 >> Hi Dave, >>=20 >> fun fact, the draft is titled "Identifying and Handling Non Queue = Building Flows in a Bottleneck Link". >> To which the _only_ and obvious answer is one does this by by = observing flow-behavior on the element that egresses into the bottleneck = link. >> Case closed, Nothing to see folks, you can go home... ;) >=20 > As Dave points out, and probably his strongest point, > this is yet another attempt to have sources classify thier > traffic for HIGHER priority or LOWER latency and ignore or > hand wave away the security (DOS) implications that causes. It has other issues as well, like misunderstanding with equal = sharing under load is a rational strategy and believing that the queue = protection method as pseudo-coded on the docsis standard document are = anything but a poor man's fq system (and rather rich to point at = fq_codel's hash collision issue over (default) 1024 flows, while queue = protect seems to only use 32 queues, plus a catch all flow for all the = rest, tell me with a straight face that the fate sharing going on in = that bucket is going to be less severe than the hash collisions in a = 1024 flow system) >=20 > You can do that type of thing in a controlled situation, > even as large as a whole AS, but this can never succeed > at the scale of "Internet." I believe all of this is not really aimed for the internet = anyway. What I see are building blocks for a low latency highway from = the (DOCSIS)-ISP to directly connected data centers, and I am not sure I = want that. >=20 >> (I have started to read this thing ages ago and blissfully forgot all = about it, time to read it agian?) >=20 > Yes, please, everyone read it again and comment on it, > it is very far along in the process now. =46rom my perspective the 2A=3DNBQ part is fine it is all the = rest that seems superfluous. >=20 >> Best Regards >> Sebastian >=20 > Regards, [Some more comments inline below] > Rod >=20 >>=20 >>> On Aug 24, 2019, at 16:57, Dave Taht wrote: >>>=20 >>>=20 >>> I decided that perhaps it would be best if we tried harder >>> to live within the ietf's processes for calm, reasoned discussion >>>=20 >>> But in trying to review this internet draft... >>>=20 >>> https://tools.ietf.org/id/draft-white-tsvwg-nqb-02.html >>>=20 >>> I couldn't help myself, and my review is here: >>>=20 >>> = https://mailarchive.ietf.org/arch/msg/tsvwg/hZGjm899t87YZl9JJUOWQq4KBsk >>>=20 >>> If someone could make something constructive out of that, great. It >>> would be good to have a really clear definition of what we mean by >>> sparse, and good definition and defense on our website of the = properties >>> and benefits of fair queueing.=20 >=20 > I concur that a good, concise and complete definition of "sparse flow" = would be useful. > I would also like to see a good glossary of all the terms tossed = around so often, > FQ, CoDel (vs FQ_CoDel vs non FQ Codel which is often ambigous in = scope as to which > of the three are actually being referenced) >=20 > And from another thread calling things "Classic" needs to die, > it is about as good as calling things "New", it is not Classic ECN, > it is RFC3168 ECN, it is not Classic TCP, it is RFC793 TCP, etc al. >=20 >>>=20 >>> And I'm going to go off today and try to do something nice for a = small >>> animal, a widow, or an orphan. Maybe plant some flowers. >>>=20 >>> Some days it doesn't pay to read your accrued inbox messages. Today >>> was one of them. You needen't read mine either! >=20 > Regards Again, > --=20 > Rod Grimes = rgrimes@freebsd.org