Subject: RE: AQM work in the IETF

From: <[email-masked]>
Date: Mon, 3 Dec 2012 13:31:51 +0000

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 : [email-masked] [mailto:[email-masked]] De la part de Wesley Eddy
Envoyé : lundi 26 novembre 2012 03:57
À : [email-masked]
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.

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 3 Dec 2012 18:24:58 +0000

Wes,

My 2 pennies worth inline

>- Should we have a working group looking at AQMs?

Yes. During the lead-up to the RMCAT workshop & BoF, a number of us 
said that there are three problems for r-t apps, which I would rank 
in this order of importance (highest first):
- AQM behaviour
- competing TCP congestion avoidance behaviour
- r-t app congestion avoidance behaviour

So it makes sense to tackle the most important one as well as the 
least important.

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

Well, I would have thought informational specs of various algos 
proven to work well
and a BCP saying what any algo should / should-not do.

>   hardware and software, and behaves well under load?

Yes

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

Yes and no.

No, in that the tests for an AQM should be tailored to find 
deficiencies in a specific AQM that may be suspected by understanding 
the design of each one. Certainly, after that, other AQMs should be 
subjected to similar tests. However, this implies that the test 
surface should continually expand. This extensibility could be 
described in an RFC, but it implies a living document is also required.

Yes, in that we can't expect everyone to think from first principles, 
so a process people can use that saves them thinking can be useful.

>   metrics like "sojourn time" rather than variations of

Yes. The advice in RFC3819 needs a serious update, for instance. 
Recently an industry consultant asked me where there is good advice 
on how to config existing switches and routers, and I realised the 
level of advice on the Web, let alone in the RFCs, is well out of date.

>   ICCRG versus TSV working groups?

Well, RED and particularly WRED is very widely deployed. So that 
implies at least guidelines about legacy should be in TSV not ICCRG.

We are really gunning for self-configuring AQMs. They are not yet 
widely deployed so one could say that is a research subject. However, 
static config AQMs have been researched to death already (and 
parameter sensitivity), so I think we can say the area in general is 
understood enough to go straight into the IETF, not ICCRG.

AQM for wireless interfaces has been less researched - probably 
better to have ICCRG activity in parallel, but allow anything 
sufficiently mature in the IETF too.

Joe Touch says INT or OPS. I don't agree - there isn't the expertise 
there. I admit the core competence in TSV is e2e protocols, but TSV 
is where nearly all the expertise in queuing sits too. We should 
present to INT & OPS, but not do the work there.

Thanks for raising this.

Bob

>Thanks for your thoughts :).

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Matthew Ford <[email-masked]>
Date: Tue, 4 Dec 2012 12:24:09 +0400

Hi Wes,

Informed by a recent ISOC-hosted roundtable meeting (report is here: http://www.internetsociety.org/doc/bandwidth-management-internet-society-technology-roundtable-series) I have responses to some of your timely questions (speaking personally, of course):

> - Should we have a working group looking at AQMs?

I believe there is a strong and growing need for AQM at bottleneck links and there is a need to document suitable algorithms and provide industry guidance (in the form of BCPs) regarding tuning, where that is a consideration, and applicability of particular mechanisms. But to get beyond wishful thinking we need enough interest to produce a draft charter, at least.

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

For promising and broadly supported algorithms, sure, why not?

>  hardware and software, and behaves well under load?

I hope so, otherwise I think we have a pretty serious problem looming.

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

I think this could be worth shooting for, although I can already imagine lengthy discussions about the validity and relative 'weight' of specific tests. 

>  ICCRG versus TSV working groups?

I tend to think this is valuable to the extent that it can be done in the IETF rather than the IRTF. And I agree with Bob - most of the relevant expertise is in TSV, although co-ordination with INT and OPS is certainly going to be important.

Mat

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 4 Dec 2012 10:07:51 +0100

Hi all. I am following the discussion about buffers and AQM, so here go my 2
cents:

In our research group in the University of Zaragoza, we have studied the
effect of different buffer policies on some services, mainly real-time ones
based on UDP (VoIP and networked games), when competing with other traffic.
We have also calculated the results in terms of subjective quality
estimators.

Although we have not used AQM, we have used different FIFO buffer
implementations:

- Buffer measured in bytes
- Buffer measured in number of packets
- Time-limited buffer

A summary of some of the conclusions:

- In general, big buffers are bad for real-time traffic (of course).
- If the buffer is measured in bytes, it is better for real-time services:
they use small packets, and the drop probability is higher for big packets.
- If the buffer is measured in packets, logically drop probability is the
same for every packet.
- Bufferbloat: Very big buffers make it impossible to use real-time
services, when there is congestion. The added delays become unacceptable.

Four papers about the question (you can find them in
http://diec.unizar.es/~jsaldana/personal/index.htm):

- "The Effect of Router Buffer Size on Subjective Gaming Quality Estimators
based on Delay and Jitter", IEEE CCNC 2012
- "Influence of Online Games Traffic Multiplexing and Router Buffer on
Subjective Quality", IEEE CCNC 2012
- "Evaluating the Influence of Multiplexing Schemes and Buffer
Implementation on Perceived VoIP Conversation Quality," Computer Networks
(Elsevier), 2012

If this work can be of any help, it would be perfect. As you see, we "like"
studying buffers, so we could perhaps do some research studies about
different AQM policies if necessary.

Best regards,

Jose

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]] En
> nombre de Matthew Ford
> Enviado el: martes, 04 de diciembre de 2012 9:24
> Para: Wesley Eddy
> CC: [email-masked]
> Asunto: Re: AQM work in the IETF
> 
> Hi Wes,
> 
> Informed by a recent ISOC-hosted roundtable meeting (report is here:
> http://www.internetsociety.org/doc/bandwidth-management-internet-
> society-technology-roundtable-series) I have responses to some of your
> timely questions (speaking personally, of course):
> 
> 
> I believe there is a strong and growing need for AQM at bottleneck links
and
> there is a need to document suitable algorithms and provide industry
> guidance (in the form of BCPs) regarding tuning, where that is a
> consideration, and applicability of particular mechanisms. But to get
beyond
> wishful thinking we need enough interest to produce a draft charter, at
least.
> > - 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?
> 
> I think this could be worth shooting for, although I can already imagine
> lengthy discussions about the validity and relative 'weight' of specific
tests.
> 
> > - If any of this is of value, how much belongs in the  ICCRG versus
> > TSV working groups?
> 
> I tend to think this is valuable to the extent that it can be done in the
IETF
> rather than the IRTF. And I agree with Bob - most of the relevant
expertise is
> in TSV, although co-ordination with INT and OPS is certainly going to be
> important.
> 
> Mat
>

---

From: Michael Welzl <[email-masked]>
Date: Tue, 4 Dec 2012 10:23:15 +0100

Hi,

Since you mention byte vs. packet based queues: the effect of using one or the other can indeed be quite interesting. I'd like to throw this paper into the mix:

Lawrence Stewart, David Hayes, Grenville Armitage, Michael Welzl, Andreas Petlund: "Multimedia-unfriendly TCP Congestion Control and Home Gateway Queue Management", ACM Multimedia Systems Conference (MMSys 2011), 23-25 February 2011, San Jose, California, USA.

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Tue, 04 Dec 2012 09:17:22 -0800

> they use small packets, and the drop probability is higher for big packets.

This depends on whether the resources are byte-based or packet-based.

Byte-based examples include bandwidth (when supporting variable-sized 
frames at L2), encryption/authentication of the entire packet, and 
memory (using variable-sized buffers).

Packet-based include header processing overheads, fixed-frame network 
capacity, and fixed-size buffers.

How different traffic reacts to limited resources depends on how these 
resources are implemented, and which resources are limited/constrained. 
There's no single answer based solely on traffic.

Joe

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 4 Dec 2012 19:28:52 +0100

Thanks, Joe.

Another limitation to take into account is the number of packets per second
that the buffer is able to send. Sometimes there is a gap between small
packets, since there is a minimum time between packets.

Best regards,

Jose

> De: Joe Touch [mailto:[email-masked]]
> Enviado el: martes, 04 de diciembre de 2012 18:17
> Para: [email-masked]
> CC: 'Matthew Ford'; 'Wesley Eddy'; [email-masked]
> > In our research group in the University of Zaragoza, we have studied
> > the effect of different buffer policies on some services, mainly
> > real-time ones based on UDP (VoIP and networked games), when
> competing with other traffic.
> frames at L2), encryption/authentication of the entire packet, and memory
> (using variable-sized buffers).
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 04 Dec 2012 10:33:03 -0800

> packets, since there is a minimum time between packets.

Such gaps are like per-packet overheads, which act like larger L2 
headers, and can be accounted for that way.

Joe

---

From: ken carlberg <[email-masked]>
Date: Tue, 4 Dec 2012 15:51:08 -0500

Bob,

> Well, RED and particularly WRED is very widely deployed. So that implies at least guidelines about legacy should be in TSV not ICCRG.
> 
> We are really gunning for self-configuring AQMs. They are not yet widely deployed so one could say that is a research subject. However, static config AQMs have been researched to death already (and parameter sensitivity), so I think we can say the area in general is understood enough to go straight into the IETF, not ICCRG.
> 
> AQM for wireless interfaces has been less researched - probably better to have ICCRG activity in parallel, but allow anything sufficiently mature in the IETF too.
> 
> Joe Touch says INT or OPS. I don't agree - there isn't the expertise there. I admit the core competence in TSV is e2e protocols, but TSV is where nearly all the expertise in queuing sits too. We should present to INT & OPS, but not do the work there.

I think the exception is a BCP or simply a common practice that discusses guidelines concerning deployed AQM.  Something like that would seem to be more in line with OPS.  I don't think it has to be all-or-nothing in terms where AQM work resides -- parts here and there could be distributed depending heavily on what is being proposed/done.  And I would agree that a considerable amount of the expertise (and energy) on the topic is in TSV.

A few years ago, the requirements for adding a resource priority header was initially done in IEPREP, and then when it was fleshed out (by the group most interested in the topic), it was turned over to SIP (where the expertise existed) and finalized there.  I'm not saying we would need to do the exact same thing, but we have options to consider.

-ken

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 05 Dec 2012 14:25:28 +0000

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