From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DCAFC3B29E for ; Mon, 29 Oct 2018 10:15:15 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1540822514; bh=o48sW7Zy5M05uxFfZgzVp71fZoVy3rrctBngqcfnAoc=; h=From:To:Subject:In-Reply-To:References:Date:From; b=GWVu343h4l6QY+pBxtZlWUms3zTejL/L3x+gXFTMcg/MxvpI6XBwPI0aq8rc7WrjL iStJEoxXwfNcGohrIa2oR9oDCabqMtzeg56NL7pdKXZmCQRejkf+S8Pa1enhJmWJ8m NHlb/xnCBsoWTwtv7bjP30k4D+J19dirAw4Gq/FeTw4EBCuNsKvINdHC+Y8LT4ia2t XErzsjLdJWceiXTwVjxo1pRZy9RDVMVJB+F73uzq06i04AcpTJwTiDUY9xQva6tKOX rsY2d/rvw3iBPteuVIIbHWTcV5ijZQg3/SYzphMduypd6Xh9t6l9XhkN1yB/dSGqm5 edKuxvgVaHT5Q== To: Dave Taht , tsvwg@ietf.org, g.white@cablelabs.com, bloat@lists.bufferbloat.net In-Reply-To: <878t2h1jtm.fsf@taht.net> References: <878t2h1jtm.fsf@taht.net> Date: Mon, 29 Oct 2018 15:15:13 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <877ei096vi.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Bloat] quick review and rant of "Identifying and Handling Non Queue Building Flows in a Bottleneck Link" 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: Mon, 29 Oct 2018 14:15:16 -0000 Hi Greg Since Dave's email prompted me to read your draft, I thought I'd chime in with this comment: Section 3.2 of the draft reads: > 3.2. Queuing behavior analysis > > Similar to the queue protection function outlined in the previous > section, it may be feasible to devise a real time flow analyzer for a > node that would identify flows that are causing queue build up, and > redirect those flows to the QB queue, leaving the remaining flows in > the NQB queue. To me, this sounds exactly like a description of what the sparse flow optimisation of FQ-CoDel, so I'm puzzled why you don't believe this to be the case? Sure, FQ-CoDel uses its per-flow queueing system as a mechanism to achieve this, but if you really can't do per-flow queueing, it is conceivable that the mechanism could be implemented without it. The high-level logic is basically (in your terms) "on enqueue, does this flow already have a packet queued? if yes, it's a QB flow, if no, it's an NQB flow". It is simple, but quite effective. I've recently analysed the behaviours that fall out of this simple mechanism in some detail, which may be relevant to your efforts. See this publication in IEEE Communication Letters: https://doi.org/10.1109/LCOMM.2018.2871457 -Toke