RE: AQM work in the IETF

[<[e-mail]>]

Hi all,

I have a basic question about this proposal, for my own understanding: what would more precisely be the problem statement? Would this activity only aim at providing solutions to the "buffer bloat" issue, or would it also address other topics related to queue management? Which use cases are targeted?

As an example, could this activity include the notion of "wireless congestion" (which might be related to other activities, inside or outside IETF: e.g. ConEx, UPCON, ...), and could it lead to study and to document new suitable AQM mechanisms for this?

As far as I can see, I think the main interest and usage would be for "wireless congestion" in such context.

Thanks for the clarification.

Cheers,

Sébastien

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Wesley Eddy
Envoyé : lundi 26 novembre 2012 03:57
À : [e-mail]
Objet : AQM work in the IETF

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.