Subject: AQM work in the IETF

From: Wesley Eddy <[email-masked]>
Date: Sun, 25 Nov 2012 21:56:30 -0500

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

-- 
Wes Eddy
MTI Systems

---

From: ken carlberg <[email-masked]>
Date: Mon, 26 Nov 2012 07:12:20 -0500

I, for one, would be very interested to see work done in this area, so count me as one of the infamous "+1".  I think a good place to start is a BCP (or multiple, depending on what is to be accomplished), and then from that point consider subsequent related topics.  And certainly, we'd want the Ops folks involved, though that brings up the question of whether such an effort should start in Ops first.

Perhaps other questions to bring to the table would be:
- would there be a need for a requirements and/or framework document?  
- does one anticipate signaling (predominantly, intra-domain) to configure AQM nodes to reflect an administrative policy?

the downside of the above questions is that they can slow the entire process down and perhaps get us in a situation of lost in introspective thought.  On the other hand, they could help provide direction of any potential working group and help bound the problem space.  I think the problems still exist in finding the "sweet spot" in determining the right configurations for AQM, and dissiminating this information on a domain-wide basis.

-ken

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Nov 2012 10:00:42 -0800

Hi, all,

Although I would expect TSV-AREA and others (APPS, even SEC) to have 
strong interest and participatio, perhaps this should be raised as a 
plenary issue and then handled within either INT or OPS where IMO it 
belongs.

Joe

---

From: John Leslie <[email-masked]>
Date: Mon, 26 Nov 2012 14:54:40 -0500

> AQMs, but the IETF is currently not doing a whole lot to

   This issue tends to fall in the cracks between areas. :^(

   TSV is the area best adapted to standardize AQM algorithms; but
there is no mechanism to request a particular algorithm be used, or
to report which algorithm was in use.

   It's not entirely clear where those mechanisms might fit; and
of course passing parameters would be desirable...

>... Particularly, I have wondered:

   I have great difficulty imaging a charter.

> - If so, does it make sense to shoot for Standards Track

   Probably not yet.

>   hardware and software, and behaves well under load?

   That's the easy part.

>   similar to what ICCRG was doing for high-rate TCP?

   Not clear.

>   metrics like "sojourn time" rather than variations of

   At the current state-of-the-art, No (IMHO).

>   ICCRG versus TSV working groups?

   Clearly, anything can be chartered to ICCRG: but this doesn't
typically lead to fast progress.

   I would suggest discussion in <tsv-area> of how to communicate
algorithms and parameters.

--
John Leslie <[email-masked]>

---

From: Michael Welzl <[email-masked]>
Date: Tue, 27 Nov 2012 10:29:25 +0100

Hi,

> typically lead to fast progress.

I think we can mention draft-fairhurst-tcpm-newcwv as a counter-example, that one was dealt with quite swiftly.
In fact, the notorical "slow progress" cases (Compound TCP, CUBIC, HTCP, even my own MulTFRC) are slow because of the authors not following up, so ICCRG itself isn't the reason.

Cheers,
Michael

---

From: David Ros <[email-masked]>
Date: Tue, 27 Nov 2012 16:20:40 +0100

Hi,

Some thoughts from Michael & I, with ICCRG chair hats on. I'm cc'ing the ICCRG list, just in case.

>  similar to what ICCRG was doing for high-rate TCP?

An AQM test suite is in the purview of ICCRG, IOHO. And it'd certainly be valuable to have such a test suite.

>  ICCRG versus TSV working groups?

Metrics-related stuff (as in, e.g., what metric should an arbitrary AQM algorithm base its decisions upon) looks to us as ICCRG material. Other stuff seems more fit to TSV. ICCRG has served as an "intermediate" forum for experimental things that are not ready for a WG yet, so we can take that role again w.r.t. AQMs and TSVWG, just like the RG did for high-speed-TCPs and TCPM -- and, as Michael said, things getting stuck in the ICCRG-to-TCPM path wasn't the fault of the RG, actually. Or, the RG can be the home of Experimental RFCs for AQMs, that would move later to TSVWG when (if) moving to Standards-track.

Our take is, AQMs in general fit in ICCRG, and for some AQM-related things Informational or Experimental RFCs are possible outputs from the RG; in particular, we would very much like to see the new PIE proposal published through ICCRG.

Thanks,

David.

> Thanks for your thoughts :).

=================================================================
David ROS
http://www.rennes.enst-bretagne.fr/~dros/

Deadlines really start to press a week or two after they pass. -- John Perry