Re: [aqm] working group status and rechartering vs. closing

Bob Briscoe <research@bobbriscoe.net> Wed, 01 June 2016 19:01 UTC

Return-Path: <research@bobbriscoe.net>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A9B12D0D1 for <aqm@ietfa.amsl.com>; Wed, 1 Jun 2016 12:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnDkXOAldRre for <aqm@ietfa.amsl.com>; Wed, 1 Jun 2016 12:01:35 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56F312D105 for <aqm@ietf.org>; Wed, 1 Jun 2016 12:01:34 -0700 (PDT)
Received: from [31.185.187.76] (port=46624 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <research@bobbriscoe.net>) id 1b8BOW-0000t8-MH; Wed, 01 Jun 2016 20:01:33 +0100
To: Wesley Eddy <wes@mti-systems.com>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>
References: <74081931-bbc2-a3e1-4aac-5633306eecb0@mti-systems.com>
From: Bob Briscoe <research@bobbriscoe.net>
Message-ID: <574F310B.6040400@bobbriscoe.net>
Date: Wed, 01 Jun 2016 20:01:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <74081931-bbc2-a3e1-4aac-5633306eecb0@mti-systems.com>
Content-Type: multipart/alternative; boundary="------------080406020800070808000600"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/8HvtRapfmWlkkaTyoJWXoI5c8No>
Cc: "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] working group status and rechartering vs. closing
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2016 19:01:37 -0000

Wes,

Thanks for raising this.

*PI2**
*The work Koen presented in ICCRG in Buenos Aires on making PIE scale 
better comes under your category of 'improvements to current algos' that 
could be documented.
https://www.ietf.org/proceedings/95/slides/slides-95-iccrg-3.pdf
There's currently not a draft written up, but we have prepared a draft 
paper that could form the basis of an I-D too.

Even tho you could look at PI2 short-sightedly as just an implementation 
improvement, it ensures the PIE algorithm scales indefinitely and it has 
other interesting implications (e.g. as one side of the DualQ).

Also, as part of the experimental evaluation, there are other aspects of 
PIE that we might be able to 'nuance'. E.g. the authors said that the 
burst allowance might be redundant, given the whole point of a PI algo 
is to control how fast it responds to bursts. We believe that suitable 
choices of alpha & beta allow the burst allowance to be removed.

We may be able to prove that some other bells and whistles in PIE can be 
done more simply, but that's ongoing work.

*DualQ**
*The DualQ work could only be 'conditionally' chartered, dependent on 
whether draft-briscoe-tsvwg-ecn-l4s-id is chartered, which we are hoping 
to discuss in Berlin too (currently proposed for tsvwg) [see current 
discussions on tcpprague@ietf.org ]. But I guess the IESG formally 
approves new charter items in all WGs, so a cross-WG dependency wouldn't 
be a problem.

Whatever, we would very much like to put forward DualQ for re-chartering 
discussions.


Bob

On 01/06/16 15:10, Wesley Eddy wrote:
> Hello; the AQM list has been mostly quiet recently, other than 
> discussion around the IESG comments on our drafts as they progress 
> through the IESG review, so I thought it would be a good time to send 
> a status snapshot and start more discussion about rechartering.
>
> The datatracker page tells the story well, I believe: 
> https://datatracker.ietf.org/wg/aqm/documents/
>
> The main thing we need to work on before closing/rechartering is 
> getting the CoDel draft finished.  I believe the editors have the 
> working group last call comments and are planning an update to address 
> them.  The goal should be to close the loop on these with the 
> reviewers and get this into the IESG's queue before the next meeting 
> in July.
>
> We are planning for a 1-hour meeting at the next IETF meeting in July, 
> in order to discuss next-steps for the working group, which could be 
> either shutting down or rechartering.
>
> We succeeded early on in getting RFC 7567 published and it looks like 
> we'll soon have Experimental RFCs for 2 of the algorithms most people 
> have worked with to-date.  Both specs became more clear and were 
> improved through the WG reviews.  Additionally, we also have RFC 7806, 
> the ECN benefits document, the characterization guidelines, FQ-CoDel, 
> and DOCSIS-PIE descriptions that were completed.
>
> We should think about what would be needed going forward.  Some 
> questions for rechartering might be:
>
> -  What would the group expect to advance algorithms from Experimental 
> to Standards Track?  (e.g. more data from real deployments, more 
> analysis of edge cases, etc) ... and are there people with time and 
> support to meet whatever those expectations are?
>
> - Are the current couple of algorithms all that's needed for the 
> Internet, or are there other algorithms building on these, learning 
> from experience with them, or making other improvements which we 
> should work on?  (e.g. we have the DualQ draft, and recently the GSP 
> draft has been updated)
>
> - Are there ongoing field deployments, research projects, and other 
> efforts that it will be good to discuss together in the working group, 
> towards improving or advancing the current algorithms, or towards new 
> algorithms?
>
> - Is there other operations experience or considerations that should 
> be documented?
>
> Of course, this is not a complete list, but I thought formulating a 
> few questions like this could help in determining if a recharter is 
> justified rather than simply closing.  Your thoughts on these and any 
> other relevant topics will be useful to hear on the mailing list and 
> in Berlin.
>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/