Subject: [aqm] WG status

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 5 Feb 2014 21:01:04 +0000

Hi,

a new month, a new status report.

First of all, Wes and I as chairs would like to thank the editors who have stepped forward to work on the AQM Evaluation Guideline draft. We are really thankful for their burst of efforts in the last couple weeks!

We expect that that a document will be ready for submission into the I-D repository well before cutoff, as an individual draft, so that the WG can see what the state of thinking is currently. Also, once the document is published on datatracker we'd like to encourage active discussion on it.

If the submitted -00 draft is felt to have a fairly complete outline of what the current thinking in the WG is, we may be able to ask the WG for formal adoption during this IETF meeting, or shortly thereafter.

 - WG Milestones:
   - Submit AQM recommendations to IESG for publication, obsoleting RFC
 2309 (Goal: January 2014)
     - draft-ietf-aqm-recommendation is accepted towards this milestone
     - http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/
     - the draft has been updated per comments received
     - if the authors are comfortable, a WGLC might be made on the next
 revision
     - we would like to hear from other authors of RFC 2309 on this
 document, if anyone has contacts to them.

   - Submit AQM algorithm evaluation guidelines to IESG for publication as
 Informational (Goal: July 2014)
     - An editor team has come forth and is working on this
     - A draft should be available for discussion in the London IETF
     - We encourage discussion on the list and during the meeting, if this 
        draft should be adopted by the working group.

   - Submit first algorithm specification to IESG for publication as
 Proposed Standard (Goal: December 2014)
     - Since any Proposed Standard algorithm should be in line with the
 recommendations and be passable versus the evaluation guidelines, this
 milestone is dependend on the progress of the two work items above.
     - Currently the only algorithm spec with a complete and active
 individual-submission draft is PIE
 
 - Other items:
   - draft-pan-aqm-pie is under active work as a proposed algorithm:
     http://tools.ietf.org/id/draft-pan-aqm-pie-00.txt, however the draft
     has expired and should be refreshed.
   - draft-nichols-tsvwg-codel is expired; Dave Taht or others may revive it and/or
 describe pairing with FQ/SFQ algorithms:
     http://tools.ietf.org/id/draft-nichols-tsvwg-codel-01.txt
   - Other algorithm specifications are welcome!
     - Though, we are not planning on adopting algorithms until
 recommendations and evaluation guidelines are mostly stable

Richard Scheffenegger

---

From: Dave Taht <[email-masked]>
Date: Thu, 6 Feb 2014 16:20:51 -0500

>  recommendations and evaluation guidelines are mostly stable

We are working on codel, fq_codel, and best current practices documents.

Very, very, very drafty material is being kept in pandoc2rfc format in

https://github.com/dtaht/bufferbloat-rfcs

of these only the home_gateway_queue_management one is even halfway
presentable, and it is anyone's guess as to whether we'll have any of these
complete before ietf.

More eyeballs and help would be nice to have.

>
> Richard Scheffenegger
>
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Nicolas KUHN <[email-masked]>
Date: Fri, 7 Feb 2014 12:58:25 +0100

Dear all, 

On the behalf of the contributors to the AQM Evaluation Guidelines, I encourage active discussion on the draft that we have written. 
I just submitted the draft as an individual draft to the I-D Submission Tool [0].

Please let us know what you think of the current document. 

Kind regards, 

Nicolas KUHN

[0] http://datatracker.ietf.org/doc/draft-kuhn-aqm-eval-guidelines/

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 7 Feb 2014 12:47:23 +0000

Thank you Nicolas, and of course also all the other editors for preparing this document!

We will dedicate a significant fraction of the meeting time in London on discussing this document, so I would like to encourage you all to review this version!

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: Nicolas KUHN [mailto:[email-masked]]
> Sent: Freitag, 07. Februar 2014 12:58
> To: Scheffenegger, Richard
> Cc: [email-masked]
> Subject: [AQM Evaluation Guidelines]
> 
> Dear all,
> 
> On the behalf of the contributors to the AQM Evaluation Guidelines, I
> encourage active discussion on the draft that we have written.
> > First of all, Wes and I as chairs would like to thank the editors who
> have stepped forward to work on the AQM Evaluation Guideline draft. We are
> really thankful for their burst of efforts in the last couple weeks!
> >
> > We expect that that a document will be ready for submission into the I-D
> repository well before cutoff, as an individual draft, so that the WG can
> see what the state of thinking is currently. Also, once the document is
> published on datatracker we'd like to encourage active discussion on it.
> >
> > If the submitted -00 draft is felt to have a fairly complete outline of
> what the current thinking in the WG is, we may be able to ask the WG for
> formal adoption during this IETF meeting, or shortly thereafter.
> >
> >
> >
> >
> > - WG Milestones:
> >   - Submit AQM algorithm evaluation guidelines to IESG for publication
> > as Informational (Goal: July 2014)
> >   - draft-nichols-tsvwg-codel is expired; Dave Taht or others may
> > revive it and/or describe pairing with FQ/SFQ algorithms:

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 07 Feb 2014 18:58:35 +0100

> Please let us know what you think of the current document.

Hi Nicolas and others

Thank you for the draft; here are some comments, mostly of a more
general nature (as opposed to concrete proposals for rewording).

1. TESTING METHODOLOGY AND REPRODUCIBILITY
I think it is important to encourage good testing methodology in a
document like this; and from the current draft the actual proposed
testing method is not clear.

I realise it is also important to leave some room for people to do
things in the way that suits their work-flow, however I believe some
minimum standards for methodology would be appropriate. Reproducibility
is a part of this that is especially important, but other areas that
spring to mind are:

- A sufficiently detailed description of the test setup to allow others
  to replicate it. Including software and hardware versions etc.
- Availability of the data used for analysis to allow others to check
  the conclusions drawn.

Requiring a reference implementation to be available could also be
relevant to this general point; I would think it would be a reasonable
requirement to have.

2. COMPETING VS LOAD-INDUCING TRAFFIC CHARACTERISTICS 
Distinguishing between the effect an AQM has on the traffic that induces
the congestion and traffic that competes with it is worthwhile, in my
opinion. For some applications (e.g. background transfers), maximising
goodput for the "offending" stream is less important than ensuring that
other traffic is not experiencing added latency because of it, while for
others (e.g. an adaptive video conference stream), the latency of the
"offending" stream can be vital. Having this distinction in the
measurements (by measuring both) makes it possible to evaluate this
aspect of the AQM behaviour.

3. SOME COMMENTS ON THE SCENARIOS
I have various comments on the proposed testing scenarios:

- 10 Mbps is a fairly high bandwidth compared to the average connection
  to the internet. I believe it would be worthwhile to include lower
  bandwidth(s) in the "general" scenarios, and not just in the "optional"
  ones.
- I don't believe the scenario dubbed "Wi-Fi" is a realistic
  representation of the behaviour of a wifi link. A comprehensive wifi
  test would include the presence of multiple hosts, bandwidth varying
  on very short time scales, and packet aggregation behaviour. I would
  suggest keeping the existing scenario, but calling it something else,
  and then adding a more comprehensive wifi scenario (which would
  probably need some hashing out).
- I'm missing measurements of the behaviour of real-world traffic such
  as DNS lookups, HTTP requests, etc. Indeed, having bidirectional
  traffic included would be good.

4. SCHEDULING vs AQM
In the first section(s) mention AQM and scheduling as though they are
interchangeable, while a later section mentions AQM interaction with
scheduling mechanisms. I believe it is worthwhile to both (a)
distinguish clearly between what is mean by AQM resp scheduling, but
also (b) make the recommendations apply equally to a "pure" AQM
algorithm and to a combination scheme that includes both an AQM and a
scheduler (which may or may not be intricately linked in their
operation).

5. STABILITY ANALYSIS
While I agree that it is important for an algorithm proposal to argue
plausibly for its stability, I think it is wrong to *require* that
argument to be made in the form of a control theoretic analysis. Such a
requirement limits possible algorithms to those that can be described
using that particular paradigm (loosely, things expressible and solvable
by differential equations). For instance, the fluid dynamic TCP model
commonly used for control theory stability analysis, discards a lot of
the dynamics of TCP, most notably slow start and other transient
behaviour, and focuses on the steady state. Since it is by no means
clear that this is the only way to make the argument (and indeed
focusing too much on the steady state can be counter-productive), I
would suggest to at least reword the section to mention control theory
as *a* way to make the argument, rather than the *only* way.

Sorry if this got a bit long; I started with a much shorter list of
notes, I swear! :)

-Toke

---

From: Nicolas KUHN <[email-masked]>
Date: Thu, 13 Feb 2014 11:25:01 +0100

> testing method is not clear.

We tried to be the clearer the possible. 
If you have any comments or proposals, we would be glad to hear them. 

> minimum standards for methodology would be appropriate.

We mentioned in the draft that the metrics and scenarios can be used for any AQM and context (that is the main idea of the draft). 
The idea is to provide a metric section that can be exploited whatever the context is. 
Also, the first part of Evaluation section is dedicated to scenarios that are "context-free". 

I agree that methodology should be integrated in the draft. I will include a dedicated section in the next version of the draft. 

> Reproducibility

I think this is dealt with in section 3.3.1.5. 
The next version will be more specific with the expected output (measuring the metrics separately for each class of traffic). The next version will also detail that the TCp transfer can be operated with an LBE congestion control. 

>  bandwidth(s) in the "general" scenarios, and not just in the "optional"

ACK - next version will consider 1Mbps

>  traffic included would be good.

The idea behind the draft was to be quite generic. Wi-Fi is a use case for "Medium bandwidth, medium delay" scenario. We could go deeper into details, but I am afraid that the draft will lose some of its generically. This should be further discussed with the list. 

> scheduler (which may or may not be intricately linked in their

I am not sure the current draft mention that AQM and scheduling are interchangeable. 
I think the draft mentions that they may both reduce the latency and the distinction between the two is clear. 
If some sections lack of clarity, please point them out. 

> as *a* way to make the argument, rather than the *only* way.

The draft claims that the impact of every externally tuned parameter MUST be discussed. The tester SHOULD provide background material showing control theoretic analysis but COULD use other ways to discuss stability. 

Kind regards, 

Nicolas

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 13 Feb 2014 17:09:11 +0100

> If you have any comments or proposals, we would be glad to hear them.

Well, one thing I believe is worth addressing is the issue of simulation
vs experiments on real systems. I would not consider an algorithm that
has never been subjected to real-world testing to be sufficiently
evaluated.

Another issue is how to obtain the data: if the AQM itself is inspected
while running that might affect its performance, whereas if packet
traces or application level measurements at another point are inspected,
they might be showing behaviour that has very little to do with the
behaviour of the AQM algorithm. As an example of the latter, on Linux it
is very easy to end up measuring buffers in the network driver, unless
care is taken to avoid it.

I would like to see the draft address these issues and provide some
guidance on how the most obvious pitfalls can be avoided. I'll be happy
to draft some text on it, if it's not part of the planned methodology
section.

> I agree that methodology should be integrated in the draft. I will
> include a dedicated section in the next version of the draft.

Great (also, comments above)!

> I think this is dealt with in section 3.3.1.5.

(I'm assuming you mean 3.2.1.5 here).

I suppose that scenario could cover this; however, I was also alluding
to the methodological issue of distinguishing between the case where
latency is measured by a separate flow (such as a straight 'ping'
alongside the test) vs directly measuring the queueing delay of the
packets making up the traffic scenario; I believe both kinds of
measurements provide valuable data, but about different aspects of the
algorithm behaviour...

> The next version will be more specific with the expected output
> (measuring the metrics separately for each class of traffic). The next
> version will also detail that the TCp transfer can be operated with an
> LBE congestion control.

ACK. What about IW4 vs IW10?

> The idea behind the draft was to be quite generic. Wi-Fi is a use case
> for "Medium bandwidth, medium delay" scenario. We could go deeper into
> details, but I am afraid that the draft will lose some of its
> generically. This should be further discussed with the list.

I'm not saying "get rid of the scenario", I'm saying "Don't call it
wifi, because that mischaracterises the behaviour of wifi". And perhaps
also "add a scenario where bandwidth varies on very small time scales".

> I am not sure the current draft mention that AQM and scheduling are
> interchangeable. I think the draft mentions that they may both reduce
> the latency and the distinction between the two is clear. If some
> sections lack of clarity, please point them out.

I think it could be made clearer whether or not his document is meant as
only a way to evaluate AQM algorithms, or if hybrid AQM/scheduling
algorithms should also be in scope (I would argue for the latter).

In the first many sections, whenever scheduling is mentioned (sections 2,
2.2.3, 3.2.3), the wording suggests that indeed AQM and scheduling can
be complimentary and an algorithm might feasibly be a tightly coupled
hybrid. However, the section specifically dealing with scheduling (4.4),
discussing adding scheduling "on top of" the algorithm is mentioned as a
requirement, which might imply that an algorithm that already includes
(say) a tightly coupled scheduler would not be liable for consideration?

Also, this paragraph:

   Both schedulers and AQMs can be introduced when packet are either
   enqued or dequed.  If both schedulers and AQM are implemented when
   packet are enqued, their interaction should not be a major issue.
   However, if one is introduced when packets are enqued and the others
   when they are dequed, there may be destructive interactions.

seems a bit speculative to me. Has the fact that the algorithms'
activation time is a predictor of adverse side effects actually been
demonstrated?

> The draft claims that the impact of every externally tuned parameter
> MUST be discussed. The tester SHOULD provide background material
> showing control theoretic analysis but COULD use other ways to discuss
> stability.

That formulation would be fine with me. However, the last part of the
latter sentence (the COULD part) is missing from the draft... :)

-Toke

---

From: Nicolas KUHN <[email-masked]>
Date: Fri, 14 Feb 2014 10:55:04 +0100

Dear Toke, 

> has never been subjected to real-world testing to be sufficiently

I believe the draft must be the most generic the possible. These guidelines provide the tools and aspects that must be looked at, however the AQM is tested. Even-driven simulations (such as in NS-2,OMNET) enable to achieve an economical and fast protocol experimentation [http://arxiv.org/pdf/1002.2827.pdf]. These guidelines cannot reject a proposal because it has not been tested in the 'real' world. 

I will add in the "methodology" section something about that issue, saying that proposals SHOULD be evaluated in testbeds, and MAY be evaluated with event-driven simulations to better understand their internal behaviour. 

> care is taken to avoid it.

This is the kind of discussion that should be avoided in the draft. Indeed, I am afraid we may open a "pandora's box" as we do not want to list all the issues encountered by any evaluation tool set. We may end discussing why choosing emulation, vs simulation, vs mathematical model, vs real-workd experiment.   

> (I'm assuming you mean 3.2.1.5 here).

Yes, I integrated the "Methodology" section and 3.2.1.5 became 3.3.1.5. 
Sorry for that

> algorithm behaviour…

I think that this is more a metric linked to the evaluation tool set. 
If we want the guidelines to be "generic" and "evaluation tool set" free, this should not  be discussed.  

> ACK. What about IW4 vs IW10?

I am not sure that it makes sense here, that would be another pandora's box: the guidelines should not consider every possible TCP improvements. Otherwise, others would say "do you consider RENO? CUBIC? Delay based CC?" or "what about MultiPath?".  We must generic and speak generally about TCP and UDP - without much more details. 

> also "add a scenario where bandwidth varies on very small time scales".

Yes I updated the Section "Medium bandwidth, medium delay: Wi-Fi" so that the tester may include "small time scales varying bandwidth"

> algorithms should also be in scope (I would argue for the latter).

I agree as well - the draft would then need some rewording

I will add an entry in the glossary explaining that by AQM, the draft consider hybrid AQM+scheduling

> (say) a tightly coupled scheduler would not be liable for consideration?

I will update the Section (4.4) considering that scheduling is a feature of an AQM, and is not introduced "on top" of it.

> activation time is a predictor of adverse side effects actually been

The guidelines just mention that this MAY be destructive and this issue should be carefully discussed. 

> latter sentence (the COULD part) is missing from the draft... :)
ACK

Cheers, 

Nicolas

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 14 Feb 2014 12:55:13 +0100

Nicolas KUHN <[email-masked]> writes:

> I believe the draft must be the most generic the possible. These
> guidelines provide the tools and aspects that must be looked at,
> however the AQM is tested. Even-driven simulations (such as in
> NS-2,OMNET) enable to achieve an economical and fast protocol
> experimentation [http://arxiv.org/pdf/1002.2827.pdf]. These guidelines
> cannot reject a proposal because it has not been tested in the 'real'
> world.

Sure, I'm not saying simulation is not useful. I'm just saying it should
not be the only evaluation of an algorithm.

> I will add in the "methodology" section something about that issue,
> saying that proposals SHOULD be evaluated in testbeds, and MAY be
> evaluated with event-driven simulations to better understand their
> internal behaviour.

Great. Would add "reference implementation available" to that. :)

> This is the kind of discussion that should be avoided in the draft.
> Indeed, I am afraid we may open a "pandora's box" as we do not want to
> list all the issues encountered by any evaluation tool set.

Not all of them perhaps, but the most common, and those that apply
generally across tool sets.

> We may end discussing why choosing emulation, vs simulation, vs
> mathematical model, vs real-workd experiment.

A discussion that is sorely lacking, IMO :)

>> ...case where latency is measured by a separate flow (such as a straight
>> 'ping' alongside the test) vs directly measuring the queueing delay
>> of the packets making up the traffic scenario;
>

My interest here was more to avoid comparing apples to oranges: the two
different kinds of measurements can give widely varying results. As an
example, a strict priority queue would give very good latency for flows
alongside the main "elephant", but could completely starve the elephant
itself. Which may be desirable in some cases: but distinguishing between
different types of behaviour is important if we want to compare
different algorithms fairly. And I think it is worth specifying that in
the draft somewhere.

> I am not sure that it makes sense here, that would be another
> pandora's box: the guidelines should not consider every possible TCP
> improvements. Otherwise, others would say "do you consider RENO?
> CUBIC? Delay based CC?" or "what about MultiPath?". We must generic
> and speak generally about TCP and UDP - without much more details.

Well, the draft does mention CUBIC under "aggressive" senders. But if
you don't want to enumerate all the permutations, some generic language
(along the lines of "SHOULD be evaluated against the most commonly seen
TCP variants deployed on the internet (for example, CUBIC, IW4, IW10,
etc").

> Yes I updated the Section "Medium bandwidth, medium delay: Wi-Fi" so
> that the tester may include "small time scales varying bandwidth"

Right, better. Still not entirely sure that it is a good representation
of wifi, but I'm not going to argue the point vehemently... :)

> I will update the Section (4.4) considering that scheduling is a
> feature of an AQM, and is not introduced "on top" of it.

Great!

> issue should be carefully discussed.

Yeah, I was just puzzled by why specifically one configuration of
activation time interaction is mentioned as potentially problematic,
instead of just saying "potentially destructive interactions between AQM
and scheduling should be accounted for" or somesuch.

-Toke

---

From: "Akhtar, Shahid (Shahid)" <[email-masked]>
Date: Thu, 20 Feb 2014 05:48:10 +0000

Hi Nicholas and other authors,

Thank you for producing this document. I had some (long) comments where I have also suggested some solutions/text, hopefully you find them helpful. When quoting from the document, I have used quotes and I have listed my comments as 1-4.

1. The number of tests recommended per AQM scheme seems to be quite large as well as many tests that may be best done together are done independently.

For example, there are different tests for fairness between flows (section 3.2.3), level of traffic (mild, medium, heavy) (section 3.2.4), different types of bursty traffic (3.2.2) and different network environments (section 3.3). In order to obtain a realistic estimate of AQM comparison, many of these effects may need to be tested together. For example to increase level of traffic (in section 3.2.4) only long term TCP flows of 50s are proposed. It would be better to test the level of congestion with realistic traffic (and with realistic proportions) as proposed in section 3.2.4. Another example would be to test fairness between flows of same type - e.g. long term TCP flows when multiple types of TCP flows are present at a AQM controlled buffer or test fairness between flows of different types - e.g. long term TCP flows and web flows. 

I noticed that in section 3.3 different network environments are mentioned. I suggest that tests with appropriate realistic traffic be done on each of these enviroments with various levels of congestion. One could measure fairness from these tests without the need for additional tests. This may have the benefit of reducing overall number of tests as well.

2. There are four network enviroments mentioned in the document (section 3.3):
Wifi - in home network.
Data-Center communications.
BB wireless/satellite.
Low and high buffers

This is a good set, however, recommed to add:

Access networks - and further split access networks into DSL/FTTH networks and Cable access networks. Cable access networks may have much larger number of flows than DSL/FTTH since they are shared by a large number of customers

There is another type of network environment - narrowband wireless (mobile) networks where the AQM could be placed on the eNodeB, but perhaps this is a complicated scenario, and best left for later or in another document.

3. I noticed that the modeling of different types of realistic traffic could be made more accurate (section 3.2.2)

"Bulk TCP transfer: (continuous file transmission, or repeating 5MB file transmission);"
The largest type of traffic on the Internet that uses bulk TCP - or large files via TCP is progressive download. The average speed of a Youtube video is over 3Mbps and it is on average 4.5 minutes long - so the average file size is considerably larger than 5MB. We have used an average of 38MB assuming 480p video and 4.5 minutes for some of our experiments. The inter-arrival time of these files should have a realistic random distribution as well as size of the files. 

"Realistic HTTP web traffic (repeated download of 700kB);"
According to statistics that Google collected from 2010 about web traffic, the average GET file size for web traffic was only 7KB. It is very important to have the size of these files correct since AQMs can help transfers of small files when large file downloads are also occurring. The effect of AQM on a 7KB file would be very different than on a 700KB file. Web traffic also has a complex inter-arrival time relationship between the GET requests as well as the pages that produce these GET requests. However to make the testing simpler, a repeated download of a 7KB file with a Pareto distributed size and Pareto distributed inter-arrival time may be an OK compromise.

I noticed that adaptive streaming is not modelled as a type of realistic traffic. It is probably the most important and largest flow on the Internet today - if we look at a recent Sandvine report of Internet traffic, about 75% of Internet traffic is real-time entertainment of which the largest component is adaptive streaming based video traffic. In order to simulate adaptive streaming traffic, one would need a client that changes video quality rates. To keep testing simpler, an option may be to generate realistic chunk sized files at regular intervals. Average netflix speeds are around 2Mbps. Typical chunk sizes range from 2s to 10s, but 4s may be a good average. The chunk sizes should be varied with some random distribution as is typically observed from real codecs. 

4. In section 2.2.5, QoE metrics are mentioned. It may be valuable to spell out some standard models or expressions to derive QoE from network parameters so that these QoE can be compared between AQMs. In the literature there is work that derives closed form expressions for QoE. The following are examples and suggestions:

Video - the work by Johan de Vriendt et al , "Model for estimating QoE of Video delivered using HTTP Adaptive Streaming", IFIP/IEEE Workshop on QoE Centric Management, May 2013 may be useful here. The authors used over 500 samples to derive their a closed form expressions. The authors derive the MOS = alpha*(average bit rate) + beta*(standard deviation of bit rates) + sigma*(no of bit rate switches) + gamma and then produce good values for alpha, beta, sigma and gamma.

Voice - The work in "Voice quality prediction models and their application in VoIP networks" by L. Sun et al has closed form expressions for MOS scores for most commercial codes. They derive a long closed form expression with parameters a-j for key codecs (and then provide a-j for most commercial codecs) based on end-to-end and packet loss.  

Web - The delay for one average web GET file could be used as the representative for the page load time

Key metric for AQMs on access networks may be QoE since it provides and end-user view. We have seen that often the absolute goodput does not matter as much as the stability of the flow for Video (which tends to be the dominant traffic). Larger goodput may provide higher VQ levels for Video, but if higher volatility is also produced then that higher VQ level may not produce a higher QoE.

On the other hand, best metrics inter data center traffic may be goodput and delay since most of that traffic is likely to be inter machine traffic.

Best regards,

Shahid Akhtar.

-----Original Message-----
From: aqm [mailto:[email-masked]] On Behalf Of Nicolas KUHN
Sent: Friday, February 07, 2014 5:58 AM
To: Richard Scheffenegger
Cc: [email-masked]
Subject: [aqm] [AQM Evaluation Guidelines]

Dear all, 

Kind regards, 

Nicolas KUHN