From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 AF7A13CB35; Sat, 24 Aug 2019 19:32:21 -0400 (EDT) Received: by mail-io1-xd44.google.com with SMTP id t3so28616819ioj.12; Sat, 24 Aug 2019 16:32:21 -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:content-transfer-encoding; bh=1YJk4tzBcn5k+oOjo8C/HC33r9ivBwjKPCJzvPm8gCk=; b=CJdYeT0T6m/XW4Ytgj0B+sE7vX0y/N/NAb0pHBMjHrRol65ePB3v0l2W0Clr+oziK3 8L5K+oyZGbJYLSpEMGgUPHCnrAHed+NAAnVAXah1B1ZcDkgA0rt+4JmNNR2edfkMcAVq LlCuUyMlLblt5zOF/MY1LtUUtvbRhh9S2B2M9OK5lGe4A3Rt81i8aCP1KGhaUhmQTw39 OFBem0KxKm4Kztb70YNMS1/2tg3GYm6y8mXHLRa90m/B3b7c6OjGzLbSVeMPx8PMFKD5 rEnaCljJZkPBdOqBUcLBKRYS0eQVRZQY9pv8Onzs37x+R/eXzP/0hN5zoGpIJCPTYGQP zekQ== 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:content-transfer-encoding; bh=1YJk4tzBcn5k+oOjo8C/HC33r9ivBwjKPCJzvPm8gCk=; b=mIlHytPGXh7bDwuL0xv/uYeD03pzRjQXTOLJjAzYt1O++8wf5wnKXg8G/fGhg10HgI 3xXz8wsBsN9ATHoNUUlYzGtZ/xX+1orKlAgpS5BLdnETgoKBppGYyTQa0CSCHvY+YC3x U9QK6vHRE23Vp8F8iymg2yZ9lM04uGClIRrvLbPSC3kx4kr3uRXWlk4b5279wonQcOdY E8nn5idLw1DW8KRSf/diyFGVYGJvFKuPRJplM1Cc409OXGZqIHRfdGx1KI3akgv8QJSc fuwx8W4u/ma9v/fEEhDjyfyXCC3JgTK7EXG46J5uDWts7Z4a2CCwKgtQpLceLrxomA2r nJFQ== X-Gm-Message-State: APjAAAWRgoxeDyWunvgqkKm6BDQ7OR97taaWp/DZFWlEj+ZuWW85Yl/U xG7Gf59Cmn0VMQEcLHSaZfVdqJaZ1YoQyGXF19I= X-Google-Smtp-Source: APXvYqyaqxzve4PO0lGPVxhe3/w3Cak1bU+U8mbqU7cjw98BbNOoWn5k7FVGcmp6q0G7nS4MCW/OXjb0/RKOYXh+x1w= X-Received: by 2002:a5e:8a48:: with SMTP id o8mr16215821iom.287.1566689540981; Sat, 24 Aug 2019 16:32:20 -0700 (PDT) MIME-Version: 1.0 References: <201908241627.x7OGR0ia068613@gndrsh.dnsmgr.net> <3534C5ED-2F1F-4785-AAE2-7FC1E7DFB02F@gmx.de> In-Reply-To: <3534C5ED-2F1F-4785-AAE2-7FC1E7DFB02F@gmx.de> From: Dave Taht Date: Sat, 24 Aug 2019 16:32:08 -0700 Message-ID: To: Sebastian Moeller Cc: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, ECN-Sane , Dave Taht , bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecn-sane] non queue building flows ietf draft review. 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: Sat, 24 Aug 2019 23:32:21 -0000 Just for the record, the reason why I did not cross post my comments to ecn-sane as well as tsvwg, was in the hope that by putting the commentary on the draft there, and the venting, here, was that it might cut down on the noise and pain level this time around as we ramp up for another tense debate in singapore. Certainly it's helpful to co-ordinate a good open discussion here and official responses, there. And maybe the cc thing between lists is the right idea? I don't know to what extent the whole bloat list really cares about these issues? - btw: there's 440+ people (or bots?) on bloat and 50 or so on ecn-sane), and since g+ died, don't know of a way to give a short "heads up" on anything. So it's my hope now that anybody caring about the whole L4S debate has subscribed to ecn-sane and can take the noise? To some extent I personally of have a goal of "one post to each list" per week of something interesting latency or edge or wifi, related (and I do wish more popped up with interesting finds, also - I hadn't seen the wonderful animation of the congestion avoidance either) just to keep us conversing around the virtual water cooler. This is considerably less traffic than the Interesting People list... There was a time I was on irc a lot.... For example, instead of gardening today, I just finished reading "eccentric orbits" - which is the story of Iridium's (and to some extent teledesic) bankruptcy and recovery - GREAT BOOK. Utterly fascinating if you are trying to reverse engineer how spacex starlink or amazon oneweb are going to work, or puzzled at the machinations of big corps, high finance, and international governments. Get it. :) Anybody else got a space related communications book recommendation? Something highly technical? ... I incidentally had totally missed the AC_VO thing as a place to stick NQB packets. AC_VO also has the CS6 problem. And on wireless-n cannot aggregate (ac and later can). Thx for pointing that out. It's looking potentially like much less a problem on 802.11ax gear... once it ships on both clients and aps. The VI class (CS4 or CS5) however, is seemingly a good place to stick some intended L4S-ish flows - at least from an IPTV or interactive video (VR) perspective it's a decent place, I think - a bounded txop, mild extra priority. For bigbuckbunny & netflix, though, no so much, and of course, if everybody marked packets CS4 or CS5 nobody would win. (actually if universal, they might - bandwidth would go down, but txop size would be more limited so we'd multiplex between stations better - I'd really like us in the wifi work to limit txop size both on the ap and in the beacon, under load) I incidentally :cough: mark all my ssh/mosh packets CS4 when in a horrible wifi environment. It's evil of me, I suppose, but it lowers my jitter related stress level in multiple coffee shops I frequent (and haven't helped fix yet) On Sat, Aug 24, 2019 at 2:59 PM Sebastian Moeller wrote: > > Well, > > > now I wasted my evening by going through this once again, and I remember = why I forgot its content from last time around... thx for taking the time! Got a good book to read yourself to sleep with? > > 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 be= long 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> w= rote: > > > >> Hi Dave, > >> > >> fun fact, the draft is titled "Identifying and Handling Non Queue Buil= ding Flows in a Bottleneck Link". > >> To which the _only_ and obvious answer is one does this by by observin= g flow-behavior on the element that egresses into the bottleneck link. > >> Case closed, Nothing to see folks, you can go home... ;) > > > > 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 sha= ring under load is a rational strategy and believing that the queue protect= ion 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 collis= ion 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 seve= re than the hash collisions in a 1024 flow system) > > > > > 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. > > > > >> (I have started to read this thing ages ago and blissfully forgot all = about it, time to read it agian?) > > > > Yes, please, everyone read it again and comment on it, > > it is very far along in the process now. > > From my perspective the 2A=3DNBQ part is fine it is all the rest = that seems superfluous. > > > > >> Best Regards > >> Sebastian > > > > Regards, [Some more comments inline below] > > Rod > > > >> > >>> On Aug 24, 2019, at 16:57, Dave Taht wrote: > >>> > >>> > >>> I decided that perhaps it would be best if we tried harder > >>> to live within the ietf's processes for calm, reasoned discussion > >>> > >>> But in trying to review this internet draft... > >>> > >>> https://tools.ietf.org/id/draft-white-tsvwg-nqb-02.html > >>> > >>> I couldn't help myself, and my review is here: > >>> > >>> https://mailarchive.ietf.org/arch/msg/tsvwg/hZGjm899t87YZl9JJUOWQq4KB= sk > >>> > >>> 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 propert= ies > >>> and benefits of fair queueing. > > > > 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) Yes. Really need to combat the FUD. > > > > 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. I'm very, very happy to have seen multiple other IETF members demand this clear distinction in the documents instead of the marketing driven phrasology. I plan to adopt this clearer terminology instead of what I'd been using. > >>> > >>> And I'm going to go off today and try to do something nice for a smal= l > >>> animal, a widow, or an orphan. Maybe plant some flowers. > >>> > >>> Some days it doesn't pay to read your accrued inbox messages. Today > >>> was one of them. You needen't read mine either! > > > > Regards Again, > > -- > > Rod Grimes rgrimes@free= bsd.org > > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane -- Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740