Subject: [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-05.txt

From: [email-masked]
Date: Mon, 29 Jun 2015 05:03:48 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Active Queue Management and Packet Scheduling Working Group of the IETF.

        Title           : AQM Characterization Guidelines
        Authors         : Nicolas Kuhn
                          Preethi Natarajan
                          Naeem Khademi
                          David Ros
	Filename        : draft-ietf-aqm-eval-guidelines-05.txt
	Pages           : 35
	Date            : 2015-06-29

Abstract:
   Unmanaged large buffers in today's networks have given rise to a slew
   of performance issues.  These performance issues can be addressed by
   some form of Active Queue Management (AQM) mechanism, optionally in
   combination with a packet scheduling scheme such as fair queuing.
   The IETF Active Queue Management and Packet Scheduling working group
   was formed to standardize AQM schemes that are robust, easily
   implementable, and successfully deployable in today's networks.  This
   document describes various criteria for performing precautionary
   characterizations of AQM proposals.  This document also helps in
   ascertaining whether any given AQM proposal should be taken up for
   standardization by the AQM WG.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-aqm-eval-guidelines-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-eval-guidelines-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Simon Barber <[email-masked]>
Date: Mon, 29 Jun 2015 16:31:41 -0700

Section 7.2 does not discuss testing of a very common scenario for 
network edge devices - no congestion, and single flow. There are issues 
with some AQMs reducing goodput in these scenarios, and there is a trade 
off between the achievable latency and maximizing goodput here. The 
recommendation should include testing of these common and potential 
problem regimes, In particular long RTT and very low numbers of flows 
are of concern.

The current definition of mild congestion results in enough flows to 
not test the problem areas.

Simon

On 2015-06-29 05:03, [email-masked] wrote:
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

---

From: Nicolas Kuhn <[email-masked]>
Date: Tue, 30 Jun 2015 10:02:10 +0200

Dear Simon, 

> On 30 Jun 2015, at 01:31, Simon Barber <[email-masked]> wrote:
> 
> Section 7.2 does not discuss testing of a very common scenario for network edge devices - no congestion, and single flow. There are issues with some AQMs reducing goodput in these scenarios, and there is a trade off between the achievable latency and maximizing goodput here. The recommendation should include testing of these common and potential problem regimes, In particular long RTT and very low numbers of flows are of concern.
> 

In section 5.2, we have the following test: 

"
5.2.  Recommended tests

[ … ]

   o  To evaluate the impact of the RTT value on the AQM performance and
      the intra-protocol fairness (the fairness for the flows using the
      same paths/congestion control), for each run, two flows (Flow1 and
      Flow2) should be introduced.  For each experiment, the set of RTT
      SHOULD be the same for the two flows and in [5ms;560ms].
“

We have 2 flows to have the same load as in the “inter-RTT fairness” scenario
that is presented in the same section and this is not a “MUST” requirement. 
 
This scenario is somehow "very common” - no congestion - scenario.

We may reduce the number of flow to 1 for that specific scenario, but I am not quite
sure to understand the rationale of such change if the objective is to evaluate 
not debug an AQM.

> The current definition of mild congestion results in enough flows to not test the problem areas.
> 

Indeed, this is why, in section 5.2, we propose a lower level of congestion 
than in the mild congestion scenario.

Kind regards,

Nicolas