From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 AC1483B260 for ; Mon, 28 Nov 2016 10:35:12 -0500 (EST) Received: by mail-qt0-x232.google.com with SMTP id w33so125351285qtc.3 for ; Mon, 28 Nov 2016 07:35:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eV7KRJnnoNrXeDL8d//5f7n9JDbdymBv3UA9EVjAn7c=; b=dnQ3cWHXcMkGQj8ISLkqAEeXgeNWj7P62JS3/l82H/dUt0GxOohjoRscHF9CPZKLGN PHVFltNlhwwAxurccLC/ml2cuWjq0LUFkliPKsUq4fg+kEk0hjsCpfsmlUBZk+QeM7/X cGisogs6pHtWlT9MqkNbbiyUyBHqfIp8zXBl9vKxWMygs10Pj92VzxTjTM8Sa2dE23zm uZ+6DKJOkCY9Q0xV0dINoc5xkOzQsn4MqeuyohgvsNbIyNybFnLu730ycvF0QNZ3CNqt UDpcdrg1VLrzqWGw3YvY662bNidHQpoY8vCQWPft7XBEuQJ5oV2xboSmTCZ64xc8dDtg CuOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eV7KRJnnoNrXeDL8d//5f7n9JDbdymBv3UA9EVjAn7c=; b=QWl419/+y39fynQ+owq8Kk3Iyy/s8XQQNaskLt9Gti2eIq2nj3TG3blb8j+Upve+1/ 962WvyoVwhvLCZ1k9z1baqrTO0cytp4adS/o2Ii9k9e4+euhUalOUp55k64G9WYv91pr 9ButogNgKKquToS/EORxO9RZTuta2i7RG67jjIoE6wowrzwHCS4Z59Qe/Mxjub72Af3h lgbZr7+Q9RMwmTxk4mGkX/1muM5iyHxkqcQYDVoMoEeGBDNGS5fOOvmEoTxwlSzpvzVv zHKHSzO/OssqhNpdzfyO4bKwOdUariY7hfm73fgposcaNhRnYW+eDqnf+DyoVw7M2R1G Ammw== X-Gm-Message-State: AKaTC02ztB13v4nRYFOl0OHAGu/7GrC/Nv9u7WGw/UaRYA9lcD6Zvr8wes4qkLT07JBz5keBocDUhISf4zkRGA== X-Received: by 10.237.41.129 with SMTP id o1mr19024371qtd.10.1480347312293; Mon, 28 Nov 2016 07:35:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.137.198 with HTTP; Mon, 28 Nov 2016 07:35:11 -0800 (PST) In-Reply-To: <229474f1-841f-60f9-0c7a-e613adac12fc@mti-systems.com> References: <548F6875-8670-4784-8A4D-9D4E6F0F20BD@gmail.com> <65cde0ee-4cc8-22c8-5274-a4eafe9cf338@pollere.com> <229474f1-841f-60f9-0c7a-e613adac12fc@mti-systems.com> From: Dave Taht Date: Mon, 28 Nov 2016 07:35:11 -0800 Message-ID: To: Wesley Eddy Cc: bloat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] Fixing bufferbloat in 2017 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, 28 Nov 2016 15:35:12 -0000 On Mon, Nov 28, 2016 at 7:23 AM, Wesley Eddy wrote: > On 11/28/2016 10:12 AM, Dave Taht wrote: >> >> On Mon, Nov 28, 2016 at 4:48 AM, David Collier-Brown >> wrote: >>> >>> A short RFC with a clear summary would change the ground on which we >>> stand. >>> Include me in if you're planning one. >> >> Call me grumpy. Call me disaffected. But it's been 4 years into the >> IETF RFC process with codel and fq_codel with still no end in sight. >> > > > Hi Dave, while it's been undeniably slow, "no end in sight" is not really > accurate. Here is the correct status, since I am document shepherd for > both: > > - The fq-codel draft is completely and totally done in terms of IETF > process, and has been in the RFC Editor's queue simply awaiting the codel > draft to arrive. This is what the "MISSREF" state indicates in that IETF > datatracker tool. It completed the IETF last call and IESG balloting in > March/April earlier this year. > > - The codel document completed AQM working group last call, and I believe= is > awaiting the authors to make changes requested by the Area Director in or= der > to go for IETF Last Call and IESG balloting. > > The end is most definitely within sight! Thank you for the update! I will, however, believe it when I see it (and heave a great sigh of relief). I see from looking over this preliminary draft, http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices= -00.html that since I wrote it, we have made a serious dent in dealing with nat and in per host fq with the cake project, as well as dealing well with rate shaping (and diffserv classification to the best of our understandings) current man page for cake: http://static.lochnair.net/bufferbloat/tc-cake.8= .html Some tech detail (does not include the new de-natting code or per host fq (triple-isolate)): https://www.bufferbloat.net/projects/codel/wiki/CakeTechnical/ There is *no way* I want to submit cake to the RFC process (the code is dual licensed), but an updated form of this attempt at a best practices document might be worthwhile, if not as a wg submission, then as an individual submission. > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org