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

On 6/1/16 7:10 AM, 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.  

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

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.

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

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.

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

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
> documented?

What form could that take?

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

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.
> 
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm