From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <4bone@gndrsh.dnsmgr.net> Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5AB003CB35; Sat, 24 Aug 2019 12:27:06 -0400 (EDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x7OGR0ND068614; Sat, 24 Aug 2019 09:27:00 -0700 (PDT) (envelope-from 4bone@gndrsh.dnsmgr.net) Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x7OGR0ia068613; Sat, 24 Aug 2019 09:27:00 -0700 (PDT) (envelope-from 4bone) From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Message-Id: <201908241627.x7OGR0ia068613@gndrsh.dnsmgr.net> In-Reply-To: To: Sebastian Moeller Date: Sat, 24 Aug 2019 09:27:00 -0700 (PDT) CC: Dave Taht , ECN-Sane , bloat@lists.bufferbloat.net X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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 16:27:06 -0000 > Hi Dave, > > 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... ;) 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. 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 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. > 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/hZGjm899t87YZl9JJUOWQq4KBsk > > > > 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. 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) 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. > > > > 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. > > > > 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@freebsd.org