Subject: Re: [aqm] New Version Notification for draft-aqm-codel-00.txt

From: Jana Iyengar <[email-masked]>
Date: Thu, 16 Oct 2014 18:09:09 -0700

Dear all,

A new draft on CoDel  is now available in the drafts repository; see
below for details.

Thanks,
- jana

On Thu, Oct 16, 2014 at 5:55 PM,  <[email-masked]> wrote:
>
> A new version of I-D, draft-aqm-codel-00.txt
> has been successfully submitted by Jana Iyengar and posted to the
> IETF repository.
>
> Name:           draft-aqm-codel
> Revision:       00
> Title:          Controlled Delay Active Queue Management
> Document date:  2014-10-16
> Group:          Individual Submission
> Pages:          28
> URL:            http://www.ietf.org/internet-drafts/draft-aqm-codel-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-aqm-codel/
> Htmlized:       http://tools.ietf.org/html/draft-aqm-codel-00
>
>
> Abstract:
>    The "persistently full buffer" problem has been discussed in the IETF
>    community since the early 80's [RFC896].  The IRTF's End-to-End
>    Working Group called for the deployment of active queue management
>    (AQM) to solve the problem in 1998 [RFC2309].  Despite the awareness,
>    the problem has only gotten worse as Moore's Law growth in memory
>    density fueled an exponential increase in buffer pool size.  Efforts
>    to deploy AQM have been frustrated by difficult configuration and
>    negative impact on network utilization.  This problem, recently
>    christened "bufferbloat", [TSVBB2011] [BB2011] has become
>    increasingly important throughout the Internet but particularly at
>    the consumer edge.
>
>    This document describes a general framework called CoDel (Controlled
>    Delay) [CODEL2012] that controls bufferbloat-generated excess delay
>    in modern networking environments.  CoDel consists of an estimator, a
>    setpoint, and a control loop.  It requires no configuration in normal
>    Internet deployments.  CoDel comprises some major technical
>    innovations and has been made available as open source so that the
>    framework can be applied by the community to a range of problems.  It
>    has been implemented in Linux (and available in the Linux
>    distribution) and deployed in some networks at the consumer edge.  In
>    addition, the framework has been successfully applied in other ways.
>
>    Note: Code Components extracted from this document must include the
>    license as included with the code in Section 5.
>
>
>
>
> 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.
>
> The IETF Secretariat
>

---

From: Nicolas KUHN <[email-masked]>
Date: Fri, 17 Oct 2014 13:53:26 +0200

Dear all, 

I have some comments regarding the new version of draft-aqm-codel-00.txt.

Also, we would like to have some reviews of the draft-ietf-aqm-eval-guidelines-00.txt document [ https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/ ]: we have set up a github repository, if you want to have a access to it, please send us an email.

Comments on draft-aqm-codel-00.txt:
1- Introduction:
	- "Many approaches to active queue management (AQM) have been developed
   over the past two decades but none has been widely deployed due to
   performance problems."
	-> "performance problems" is not clear IMO and not accurately true - the problem is that AQM might be difficult to tweak, but we can not say that there are performance problems when correctly parameterised.
	-> AFAIK, RED  have also been widely implemented in some network devices, but RED is reported to be usually turned off. 

	- "The CoDel approach is designed to meet the following goals: is […]; treats […] " 
	-> The CoDel approach is designed to meet the following goals: be […]; treat […]

	- "With no changes to parameters, we have found CoDel to work across a wide range of conditions, with varying links and the full range of terrestrial round trip times."
	-> do you have any reference that justifies this point ? 

	- "CoDel has been implemented in Linux very efficiently"
	-> [non-native speaker alert] I would rephrase this sentence. 

4- Putting it together: queue management for the network edge
	- "The only setting CoDel requires is its interval value, and as 100ms satisfies that definition for normal internet usage, CoDel can be parameter-free for consumer use."
	-> IMO the target value can also be another setting parameter, as it triggers the maximum "allowed" queuing delay. I think that the "normal internet usage" should be clearly defined. I believe that the "That is, target SHOULD NOT be adjusted but interval MAY need to be adjusted." (in section 4.3) is enough to say that the target value could be adjusted, but is disadvised. Changing both the target and interval would enable to achieve different tradeoffs than the default one, as you say in Section 4.7. 

	- "CoDel was released to the open source community where it has been widely promulgated and adapted to many problems. "
	-> what 'many' problems was CoDel adapted to ?

4.1- Overview of CoDel AQM
	- "In the open Internet, in particular the consumer edge, we can use the "usual maximum" terrestrial RTT of 100 ms"
	-> I think that a reference is needed 

	- "Additional logic prevents re-entering the dropping state too soon after exiting it and resumes the dropping state at a recent control level, if one exists."
	-> what is this additional logic ? if this is explain later in the document, this sentence should point to that part of the draft.

4.3 Using the interval	
	- " A setting of 100ms works well across a range of RTTs from 10ms to 1 second (excellent performance is achieved in the range from 10 ms to 300ms). For devices intended for the normal terrestrial Internet interval SHOULD have the value of 100ms.  This will only cause overcropping where a long-lived TCP has an RTT longer than 100ms and there is little or no mixing with other connections through the link."
	-> what do you mean by "works well" ?
	-> what are the differences between "working well" and "excellent performance" 
	-> as you say, if the RTT is higher than 100ms, there will be "overcropping": IMO, this discussion is enough to say that CoDel is not "non-sensitive to RTT" - this statement should be alleviated (or numbered in terms of bottleneck utilisation / queuing delay) in the whole document.

4.6 Use of stochastic bins or sub-queues to improve performance
	- "Our code, intended for simulation experiments, is available at http://pollere.net/CoDel.html and being integrated into the ns-2 distribution."
	-> the link seems to be broken.

	- " Implementers SHOULD use the fq_codel multiple queue approach if possible as it deals with many problems beyond the reach of an AQM on a single queue."
	-> following F. Bakers talks at IETF 90 [ http://www.ietf.org/proceedings/90/slides/slides-90-aqm-5.pdf ], I am not sure if we can make such statement. Supplementary results should be pointed at in this section to legitimate the "SHOULD". 

4.7 Setting up CoDel AQM
	- "An interval of 100ms is used, target is set to 5% of interval"
	- "A CoDel configured for this environment (target and interval in the microsecond rather than millisecond range)"
	-> IMO, this is in contradiction with what is said in section 4 about "That is, target SHOULD NOT be adjusted but interval MAY need to be adjusted".
	In section 4.4, it is said that the target has been set to 5ms based on experiments that consider various RTT and link capacity - but this section says the target is set depending on the interval. IMO, there should be more consistency in the determination of the target or the interval.

6.2 CoDel in the datacenter
	- "a target of 5% of the RTT or CoDel interval was used here."
	-> I understand that the interval is set to RTT and target to 5% of the interval
	-> sometimes in the document, it is said that target is set to 5% of RTT - I think it should be said everywhere that target is 5% of interval and the interval depends on the RTT.

Kind regards, 

Nicolas KUHN

On Oct 17, 2014, at 3:09 AM, Jana Iyengar <[email-masked]> wrote:

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