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