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

From: Wesley Eddy <[email-masked]>
Date: Wed, 1 Jun 2016 10:10:52 -0400

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.

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 1 Jun 2016 20:01:31 +0100

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 [email-masked] ]. 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:
> 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 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.
>
> 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)
>
> - 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 
> other relevant topics will be useful to hear on the mailing list and 
> in Berlin.
>
>
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

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

---

From: David Lang <[email-masked]>
Date: Wed, 1 Jun 2016 17:42:48 -0700 (PDT)

On Wed, 1 Jun 2016, Wesley Eddy wrote:

> - 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)

People are always working on better ideas :-)

right now, there is work being done on 'cake' [email-masked] 
(started off as 'convert sqm scripts to C code for speed' that is working on 
being able to handle rate limiting and enhance from fq_codel)

This has been ongoing and is available in some OpenWRT builds. Unfortunantly it 
keeps growing new special-case features, so it may never settle down.

also on that list there was the suggestion to look at combining BLUE and Codel 
(working name COBALT) letting each cover the weak points of the other, and 
simplifying the code in the process (by eliminating a lot of special case code 
by letting the other algorithm handle it)

This is a recent suggestion and the first cut of the code is in the process of 
being nailed down, so there isn't any real-world experience with it yet.

Info on both of these can be found in the list archives 
https://lists.bufferbloat.net/listinfo/codel

David Lang

---

From: grenville armitage <[email-masked]>
Date: Thu, 2 Jun 2016 11:21:50 +1000

On 06/02/2016 00:10, Wesley Eddy wrote:
     [...]
>
> - 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)

We recently implemented a hybrid FQ-PIE in FreeBSD's ipfw/dummynet context, which might be something to evaluate/document more fully in the future?

(Our version boils down to gluing the FlowQueue hashing+newflow queue assignment logic from FQ-CoDel with per-queue instances of PIE.  Code went into FreeBSD-CURRENT a few days ago, https://svnweb.freebsd.org/base?view=revision&revision=300779. All being well, the code will be in FreeBSD 11.0-RELEASE later this year.)

I know there was a Linux FQ-PIE proof-of-concept discussed here many moons ago, but I don't know its current disposition.

cheers,
gja

---

From: Dave Täht <[email-masked]>
Date: Thu, 2 Jun 2016 09:54:31 -0700

On 6/1/16 7:10 AM, Wesley Eddy wrote:
> the CoDel draft finished.  

What remains to be done? (I've lost track). Can we focus on it and
finish the darn thing?

It is sad that the algorithm that essentially spawned the formation of
this working group remains un-rfc'd.

It's had influence elsewhere, also - outside of networking. The thinking
behind it has just had a rather nice patch set arrive for
making background disk writeback more invisible to foreground applications:

https://lwn.net/Articles/685894/

> I believe the editors have the working group

My own desire is to see more link layers - wifi, 5g, 6lowpan, homeplug,
especially, explored with more implementations. There is also new stuff
like threads, wifi direct/p2p, and this new ieee effort,
http://standards.ieee.org/develop/corpchan/sfocus/index.html#std1c

These are the growth nodes of the internet today, with special problems
(non-duplex shared media with exponential backoff, handoff issues for
mobility, packet aggregation (wifi, 5g), offloads (ethernet), that are
only partially addressed by the aqm/fq technologies developed to date.

To me this also requires tighter interfacing with the IEEE especially on
new stuff like 802.11ad0, as well as 3gpp (5g)

Other stuff - hardware multiqueue for multicore cpus, bql-like answers
at lower levels, and exactly how much should/must be pushed into
hardware logic rather than handled in software needs to start getting
resolved.

Ways for isps and vendors to more easily push out proper configs
(tr-069) for their link layers (dsl's variety of such is particularly
problematic)...

So my most important issues for future work tend to cross layers and wgs
and standards orgs.

> on?  (e.g. we have the DualQ draft, and recently the GSP draft has been

I note that the dualq stuff does much better with the second queue
fq_codeled than it does with the default algo, in my limited tests.

I have not re-read the gsp draft, but I thought the prior one was of
trivial actual use.

extensions to reuse ECT(1) for a dctcp-like solution are being
discussed. I have no idea where that will go.

real world experiences with the ecn deployments so far (apple chickened
ut and is only enabling it on 5% of all) will start to arrive.

we will also start seeing the first attacks against ecn enabled systems
start to arrive and this will feed back into future work. A "cure" for
udp floods just arrived in mainline fq_codel, notably. I would certainly
like to see more attacks against ecn enabled systems demonstrated and
mitigated.

> towards improving or advancing the current algorithms, or towards new

Some have already been mentioned on this thread. In particular making
tcps (or quic, or utp) work better with aqm at low rates is of great
interest to me, whether it be with sub-packet windows or with reducing
the mss size, propigating a smaller IW from slow gateways (somehow) or
whatever.

Additionally work to apply saner scheduling and aqm to wifi is
progressing nicely, but I don't expect the work to be in an ietf
presentable state for quite some time yet.

(preliminary results start here, which also points at a need for tcp's
to be more gentle at lower rates:
http://blog.cerowrt.org/post/rtt_fair_on_wifi/
 )
> - Is there other operations experience or considerations that should be

What form could that take?

> other relevant topics will be useful to hear on the mailing list and in

I would prefer to see the working products of the aqm working group
spread farther and wider. 3 billion wifi devices shipped last year, as
one example that keeps me up nights. There has been nearly no movement
towards less delay on core edge technologies in the publicly available
user tests like

http://www.dslreports.com/speedtest/results/bufferbloat?up=1

That I can discern.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 2 Jun 2016 23:14:12 +0000

> On Jun 1, 2016, at 6:21 PM, grenville armitage <[email-masked]> wrote:
> 

If you're referring to our versions (2 of them), they were uploaded to github but not submitted to Linux. If you want to do the latter, be my guest.

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 13 Jun 2016 11:21:56 +0100

Dave,

> new stuff like 802.11ad0, as well as 3gpp (5g)
Strongly agree.
I've been dealing with liaison correspondence with IEEE and 3GPP on 
behalf of the IETF (tsvwg) about misunderstandings in the implementation 
of ECN (which obviously requires an AQM). The general summary is:
* IEEE: no activity on this at all at the moment.
* 3GPP: 21 3GPP specs recommend ECN and therefore AQM (initially for 
voice over LTE). See slide 5 of my update to tsvwg 
<https://www.ietf.org/proceedings/95/slides/slides-95-tsvwg-11.pdf> at 
the April'16 IETF. Two of these 3GPP docs specify the radio access 
network part. In them, the IETF's specs have been misunderstood, because 
the word "congestion" has been misunderstood as something that is 
binary, so when there is radio "congestion", it is assumed you have to 
do 100% marking and 0% when there is no "congestion".

However, the upside is that implementations are rare or non-existent :(
We need to somehow impress on implementers of radio network equipment 
how significant the improvements are from AQM, and explain AQM as 
something that is for all applications, not just one. Interactions with 
power control and radio resource control are hard - a group of us have 
started working on this, because it's very hard for RAN equipment 
designers to translate current AQM designs to address their scenario.

> So my most important issues for future work tend to cross layers and wgs
Agree. In order to make this possible, we are going to need to work out 
the factors that are common to many L2 technologies, and which ones are 
specific. Otherwise we will just burn our time for ever trying to design 
and implement for each different technology.

Should we ensure that a significant part of the AQM's charter/agenda is 
about explanation/liaison/socialisation?
I'm not sure how to do that - it's not a common thing for an IETF WG to do.

The IAB has an activity on protocol adoption: e.g. 
https://tools.ietf.org/html/rfc7305
ISOC might have a role here? (I've added Mat Ford to the distr).

I think each one of us could collectively make a lot of difference by 
{visiting | mailing | interacting with} just one fora outside our usual 
"tribe" - even just once.

> fq_codeled than it does with the default algo, in my limited tests.
The idea of dualq is to be able to focus on the far lower queuing delay 
and loss that you can get by addressing the root cause of the problem: TCP.
What I learned from the results of all those experiments was that 
proponents of different solutions have been arguing around which part of 
the balloon they can squeeze to make one factor look a bit better at the 
expense of the balloon bulging out for other factors (utilization, loss, 
deployability, implementation cost, configuration complexity, unintended 
side-effects, etc).

> like to see more attacks against ecn enabled systems demonstrated and
Yes. There's a lot of useful work on this already done in the past that 
the AQM WG could start from (see earlier comment about adding policing 
to the charter).
> http://www.dslreports.com/speedtest/results/bufferbloat?up=1
+1.
See earlier re possible adoption activities.

Bob

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 20 Jun 2016 21:46:40 +0200

Hi Dave, hi all,

> Am 02.06.2016 um 18:54 schrieb Dave Täht <[email-masked]>:
> 

For me aqm that focuses on wireless networks is also an interesting topic where a lot of work is going on. The question is are people interested to bring this work to the IETF (writing drafts) and is there enough energy in this group to finalize the work?

Mirja

---

From: Dave Täht <[email-masked]>
Date: Mon, 20 Jun 2016 18:35:43 -0700

On 6/20/16 12:46 PM, Mirja Kühlewind wrote:
> For me aqm that focuses on wireless networks is also an interesting topic where a lot of work is going on. 

Where?

>The question is are people interested to bring this work to the IETF (writing drafts) 

I think my points were more that the existing ietf work needed to be
successfully exported. Somehow.

>and is there enough energy in this group to finalize the work?

Not me. I long ago ran out of funding to work on standards.

Even if I had funding levels equal to the commitment, my energy and
enthusiasm for any new paperwork is at a low ebb. I would much rather
rejoin the vibrant dynamics of the open source world where the time
difference between an idea and an implementation is merely a long
sleepless weekend.

If ever again I stumble across a techno-logic advance worth bringing
in front of the ietf, I will do my best to sucker someone else into
doing so. ;)