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 protected]> wrote:

> 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 protected]> 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
>> 
> 
> _______________________________________________
> aqm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/aqm

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

Reply via email to