My thoughts....
(1) TSVWG is about to submit a draft on Byte and Packet Congestion
Notification - My understanding was that this was already about AQM, so
yes this does fall within the IETF's area of interest. TSV may not be a
bad area to do this (although it seems unusual), because the
implications of AQM are directly linked to transport behaviours (AQM is
not really to protect the forwarding or control plane or linked to
routing, more to throttle resources for a flow).
(2) It may be hard to set a charter. There are certainly problems here:
- are there tools to easily see what is happening in deployed networks?
this could perhaps be suited to ICCRG?
- is there a common reference model we could use to compare? Is there
wisdom on what may be bad, good, etc... It would be nice to have
standard terminology, and guidelines...
- are there specific algorithms, or combinations of techniques (like
CoDel) that should be described ... could be tricky without a common
framework?
In sumamry, I think if we ignore this, then we are in danger of ignoring
the existence of growing use of AQM, we've ignored other technologies in
the past, and that can be bad when they become popular or turn in
strange ways. To me it seems like transport - but if it is, then people
from other areas MUST be engaged.
Gorry
On 26/11/2012 02:56, Wesley Eddy wrote:
As TSV ADs, Martin and I have been wondering lately about
AQM work.
At this point, thanks largely to Jim Gettys, we all know
about large buffers, and we know what bulk-transfer with
loss-based congestion control can do to interactive traffic
when large queues exist.
We know one thing that can be done to help is the use of
AQMs, but the IETF is currently not doing a whole lot to
help in this regard.
There is the CoDel I-D that was discussed in the TSVAREA
meeting in Vancouver:
http://tools.ietf.org/html/draft-nichols-tsvwg-codel-00
But this is an individual submission that Martin and I
would be happy to sponsor, and not a working group
activity.
At the last IETF meeting, we had a request to talk about
PIE, which we didn't have time for in TSVAREA, but ICCRG
did:
http://www.ietf.org/proceedings/85/slides/slides-85-iccrg-2.ppt
This was really interesting, and we wonder if the
community is interested in continuing to hear about
AQMs in this space, and what the IETF should be doing.
If people have thoughts about this, we'd like to hear
about them on this list, and/or during the TSVAREA
meeting in Orlando at the next IETF meeting. We want
to know what the level of interest in AQMs is, and
might make this a focus of the TSVAREA meeting, if a
lot of people seem to think it's a good idea.
Particularly, I have wondered:
- Should we have a working group looking at AQMs?
- If so, does it make sense to shoot for Standards Track
specifications?
- Would we be able to come up with actual requirements
on an AQM so that it's implementable for cheap in
hardware and software, and behaves well under load?
- Would it be valuable to have a test suite for AQMs
similar to what ICCRG was doing for high-rate TCP?
- Would it be valuable to have a BCP (or multiple) on
configuring "legacy AQM" like RED, or the use of AQM
metrics like "sojourn time" rather than variations of
the queue length?
- If any of this is of value, how much belongs in the
ICCRG versus TSV working groups?
Thanks for your thoughts :).
