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

Dave,

On 02/06/16 17:54, Dave Täht wrote:
>
> 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)
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.

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

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

>
> 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.
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).
>
>
>> - 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.
+1.
See earlier re possible adoption activities.

Bob
>> _______________________________________________
>> aqm mailing list
>> aqm@ietf.org
>> https://www.ietf.org/mailman/listinfo/aqm
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>

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