[aqm] ECN support for PIE AQM in Linux

[Naeem Khademi]

Hi

The already-existing PIE Linux code maintained at
ftp://ftpeng.cisco.com/pie/ does not support ECN. Studying the interaction
of ECN and AQM algos is probably of interest of some of us. I have added
ECN support to PIE Linux code and have given it some basic sanity tests.

The modified code is available at
http://heim.ifi.uio.no/naeemk/research/PIE/

I would appreciate any feedback.

Regards,
Naeem
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] AQM deployment status?

[Naeem Khademi]

Hi

Sorry if I'm asking a redundant question here, but any citeable information
on AQM's deployment on the Internet? RED, ARED, BLUE, (FQ_)CoDel's
deployment either at the edge or core? I'm curious to know how much of it
has made it into real deployment.

Regards,
Naeem
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] [Bloat] [iccrg] AQM deployment status?

[Naeem Khademi]

Thanks Shahid

Although interesting to know that (W)RED has made it into some hardware (in
your RE to Lars' point), my question is more about "deployment" at the edge
or the core, whether it's being used or not?

Cheers,
Naeem


On Wed, Sep 25, 2013 at 8:51 PM, Akhtar, Shahid (Shahid) <
shahid.akh...@alcatel-lucent.com> wrote:

> Hi Steinar and Lars,
>
> Please see below examples of support for RED/WRED from switches (from ALU
> and Cisco websites, search for RED or WRED in document):
>
> ALU 7450:
>
>
> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&ved=0CDMQFjAC&url=http%3A%2F%2Fwww3.alcatel-lucent.com%2Fwps%2FDocumentStreamerServlet%3FLMSG_CABINET%3DDocs_and_Resource_Ctr%26LMSG_CONTENT_FILE%3DData_Sheets%2F7450ESS_HS_MDA_ds.pdf&ei=pS5DUrIZiI70BLyYgYgK&usg=AFQjCNGS8uB-0Ele3TpDIRqbL4p1_kd2DQ&sig2=v-AgGJMpcZjrpjP2oZIHrA&bvm=bv.53077864,d.eWU
>
> ALU Omniswitch:
>
>
> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=0CDkQFjAC&url=http%3A%2F%2Fwww3.alcatel-lucent.com%2Fwps%2FDocumentStreamerServlet%3FLMSG_CABINET%3DDocs_and_Resource_Ctr%26LMSG_CONTENT_FILE%3DData_Sheets%2Fent_OS6855_datasheet_en.pdf&ei=9i1DUsXlOo788QTU94HQAQ&usg=AFQjCNFSXSEpkFjSihK1a0pkSHhItU8sZQ&sig2=3fitEZLZZI7Dmf0H2T3QbQ&bvm=bv.53077864,d.eWU
>
> Cisco Catalyst 6000/6500:
>
>
> http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper09186a0080131086.html
>
> Cisco Catalyst 4500:
>
>
> http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps4324/white_paper_c11-539588.html
>
> Best regards,
>
> -Shahid.
>
> -Original Message-
> From: Steinar H. Gunderson [mailto:sgunder...@bigfoot.com]
> Sent: Wednesday, September 25, 2013 9:35 AM
> To: Eggert, Lars
> Cc: Akhtar, Shahid (Shahid); bloat; ic...@irtf.org; aqm@ietf.org
> Subject: Re: [Bloat] [iccrg] [aqm] AQM deployment status?
>
> On Wed, Sep 25, 2013 at 02:31:21PM +, Eggert, Lars wrote:
> >> Most routers/switches/access equipment support RFC 2309, which is a
> >> description of RED.
> > I've heard that statement from many different people. I wonder if it
> > is actually true. Is there any hard data on this?
>
> I don't have hard data, but my soft data is that generally, devices
> branded as switches (including L3 switches) do not support it. Routers
> might.
>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
> ___
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] New AQM Kids on the block -- experimental evaluation of CoDel and PIE (and ARED)

[Naeem Khademi]

Hi

This might be of interest of some of AQMers:

The slides of ICCRG talk at IETF88 comparing the performance of CoDel, PIE
and ARED is available at:
http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-4.pdf

A detailed technical report with more experimental results can be found at:
http://urn.nb.no/URN:NBN:no-38868

Please don't hesitate to provide feedback.

Regards,
Naeem
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] AQM schemes: Queue length vs. delay based

[Naeem Khademi]

I fully agree with the need to have AQMs that use "queuing delay" as metric
and not "queue length" and this is already a bonus for algorithms that use
this metric (e.g. PIE). However, I believe that one can possibly modify RED
or its derivatives (e.g. Adaptive RED) to set their thresholds based on
"queuing delay" as well (although such algorithms don't exists yet as of
now). Whether the outcome of these modifications to xRED algorithms would
make them better than PIE and/or CoDel is another subject and I'm not going
to speculate on that here.

One specific issue with PIE is that it tries to *estimate* the queuing
delay over a certain time interval (t_update) and still somehow uses the
"queue length" and departure rate (over the interval) to estimate the
queuing delay. So saying that PIE uses the queueing delay instead of queue
length may not be 100% accurate.

Moreover, in a varying bandwidth scenario, depending on how often the
bandwidth changes and at what granularity, the derived "estimated queuing
delay" by PIE might be an outdated information e.g. it shows how the
channel has been (in term of delay) in the last 30ms and now how it is now!
if I'm not mistaken that has been somehow resolved in DOCSIS 3.1 by
coupling PIE's departure rate to the actual link layer rate.

In overall, while there are of course significant improvements made in
PIE's (and (FQ)-CoDel's) design, there are probably still lessons to be
learned from xRED family (check http://urn.nb.no/URN:NBN:no-38868 to see
some examples). Throwing away all the knowledge and improvement gained from
RED-like AQMs, CHoKe, etc and coming up with brand-new AQMs without
(experimentally) comparing them to the gallery of existing ones wouldn't be
great!

Cheers,
Naeem



On Thu, Nov 7, 2013 at 5:46 PM, Preethi Natarajan wrote:

> Hello AQMers:
>
> Just wanted to bring up the following item for discussion either as part
> of the recommendations draft or the evaluation criteria during Friday's
> session/mailing list.
>
> In access, edge and core routers the draining rate of a queue is affected
> by traffic on other queues and thus can vary a lot (depending on the
> deployment and traffic conditions). A queue length based AQM scheme such as
> RED or derivatives tries to maintain the average queue size around a
> predictable value under these changing draining rates. However, this queue
> size translates to high queuing delay under low draining rates and
> vice-versa. The unpredictability in resulting queueing delay was one of the
> reasons why we opted PIE to be a latency-based scheme.
>
> A queue length based AQM scheme could be perfectly valid for certain
> deployments. For deployments where predictable queuing delay is expected
> under varying draining rates, a latency based AQM is critical. We believe
> this should be brought about in discussions somewhere at AQM — perhaps in
> the recommendations draft or w.r.t evaluation criteria.
>
> Thanks,
> Preethi (on behalf of PIE team)
>
>
>
> ___
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>
>
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] IETF88 Fri 08Nov13 - 12:30 Regency B

[Naeem Khademi]

Hi

Snipping other stuff, I would like to add some specific points inline:


On Thu, Nov 7, 2013 at 10:45 AM, Fred Baker (fred)  wrote:

>
> On Nov 7, 2013, at 8:59 AM, "Akhtar, Shahid (Shahid)" <
> shahid.akh...@alcatel-lucent.com> wrote:
>
> >> 4.  Conclusions and Recommendations
> >>   [snip]
> >>3.  The algorithms that the IETF recommends SHOULD NOT require
> >>operational (especially manual) configuration or tuning.
> >
> > Some tuning may be required or implicitly assumed for virtually all AQMs
> – please see my comment later.
>
> That's an opinion. One of the objectives of Van and Kathy's work, and
> separately of Rong Pan et al's work, is to design an algorithm that may
> have different initial conditions drawn from a table given the interface it
> finds itself on, but requires no manual tuning. The great failure of RED,
> recommended in RFC 2309, is not that it doesn't work when properly
> configured; it's that real humans don't have the time to properly tune it
> differently for each of the thousands of link endpoints in their networks.


and "Adaptive RED" was an attempt to address exactly that issue! but it
seems that it has likely to have remained un-noticed since 2001. The draft
on Sally's homepage still says "August 1, 2001, under submission" while
it's been in Linux for a while :-).


> There is no point in changing away from RED if that is also true of the
> replacement.


> >>7.  Research, engineering, and measurement efforts are needed
> >>regarding the design of mechanisms to deal with flows that are
> >>unresponsive to congestion notification or are responsive, but
> >>are more aggressive than present TCP.
> >
> >   Do we want to make a suggestion on how to configure buffer sizes
> with each type of AQM here (e.g. 2xBDP etc) or simply state that research
> should be conducted on the best buffer sizes to use with AQM.
>
> I'm not sure that buffer sizes are specific to AQM algorithms; I'd
> entertain evidence otherwise. Buffer *thresholds* ("at what point do we
> start dropping/marking traffic?") may differ between algorithms. Buffer
> size ("how many bytes/packets do we allow into the queue in the worst
> case?") is a matter of the characteristics of burst behavior in a given
> network and the applications it supports. If I have, say, a Map/Reduce
> application that simultaneously asks thousands of systems a question, the
> queues in the intervening switches will need to be able to briefly absorb
> thousands of response packets. The key word here is "briefly". When Van or
> Kathy talk about "good queue" and "bad queue", they are saying that burst
> behavior may call for deep queues, but we really want the steady state to
> achieve 100% utilization with a statistically empty queue if we can
> possibly achieve that.
>

The terms "good queue", "bad queue" or "briefly" are very subjective. How
"brief" is the key. We can possibly know that when we're talking about a
specific application in a specific environment (e.g. Map/Reduce in data
center). On the access link with a mixture of all sort of traffics, and
also RTTs , that's more controversial. A queue that gives a 100 ms burst a
pass, is a good queue from CoDel designer's point of view (!)

Cheers,
Naeem
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] AQM schemes: Queue length vs. delay based

[Naeem Khademi]

On Wed, Nov 13, 2013 at 12:56 AM, Preethi Natarajan
wrote:

>
>
> From: Michael Welzl 
> Date: Friday, November 8, 2013 5:30 PM
>
> To: Preethi Natarajan 
> Cc: Naeem Khademi , "aqm@ietf.org" 
> Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
>
>
> Thanks for the link. My point was just (along with Naeem) that it would be
> useful to compare PIE (or CoDel) against something else except CoDel and
> RED. When I just look at the graphs in the HPSR paper (sorry, didn't get to
> read it yet), again I see only PIE, CoDel, RED.
>
> We tried ARED and were surprised to see how good it works - which is not
> to say that it is the ideal - but it was surprisingly often better than
> these newer schemes, despite its age of 10+ years... as we all know, there
> are many schemes out there, quite often designed with the goal of removing
> RED's dependence on parameters.
>
>
>
Hi Preethi and Rong

replies follow inline


> Michael, Naeem:
>
> This is just a follow-up to better understand the ARED results presented
> at AQM WG (http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-4.pdf
> ).
>
> Could you please clarify whether the ARED parameters for the tests were
> set as specified in the 2001 paper? I.e., when average queueing delay
> target = 1ms, the min and max thresholds would translate to 0.5ms and
> 1.5ms, and for 5 ms target the min and max thresh will be 2.5ms and 7.5ms,
> respectively, right? Can you confirm?
>

Copy/pasting from Section 3.1.3 of http://urn.nb.no/URN:NBN:no-38868
<http://urn.nb.no/URN:NBN:no-38868>

*"In case of ARED, the parameters are calculated based on the
recommendations in [19]*
*except when target delay=1 ms where th_min and th_max are set to 1 MTU*
*and 2 MTUs accordingly."*

*[19] S. Floyd, R. Gummadi, and S. Shenker. Adaptive RED: An Algorithm for*
*Increasing the Robustness of RED’s Active Queue Management. Technical*
*report, 2001.*

This means "yes" for all values of target delay except for 1 ms cases where
the thresholds become smaller than a single MTU transmission time on the 10
Mbps bottleneck link used in this case.  The recommendations in Sally
Flyod' s ARED 2001  (th_max=3*th_min; target=(th_max+th_min)/2) are used in
all other cases.


> Assuming ARED logic is intact, ARED drops all packets when average queue
> size goes above max_thresh  (max_thresh = 1.5ms or 7.5ms etc.); this
> would be semantically similar to a drop tail queue with shallow buffer (can
> be confirmed by looking at cumulative packet drops by ARED).
>

Similar but not identical as ARED (and any other *RED) does averaging
instead of using instantaneous queue size (e.g. that being employed in
DCTCP AQM)


> This is probably why the delay values are tight for ARED, and why ARED
> translates to poor utilization, especially for the lower target delay
> values, as seen in your slides (#8, #11, #13).
>

True!


> Also,  wondering if bursty traffic was considered for evaluations, since
> semantics of drop tail with shallow buffering doesn't accommodate bursty
> traffic.
>

No, we did not consider bursty traffic (e.g. multimedia, etc) for this work
as this was our first (initial) fundamental step to understand in a
systematic way how AQMs work in real-life with long-lived TCP traffic
(which is the most common type of traffic that fills up any buffer and
consistently contributes to excessively long latencies experienced on the
Internet (a.k.a bufferbloat)).

The fact that AQMs *should* absorb sub-RTT bursts (due to rate mistmatch,
etc) does not diminish the basic requirement for AQMs that they should
control the latency induced by bulk (long-lived) TCP traffic in a well
manner. Any other type of traffic on the access links will most likely to
coexist with bulk TCP traffic when latency is observed to grow high. In
other words, if an AQM can't control the latency of (not so bursty as
others-) TCP traffic, it probably won't be able to do so for bursty traffic
as well.


> Thanks,
> Preethi & Rong
>
>
Cheers,
Naeem
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] AQM schemes: Queue length vs. delay based

[Naeem Khademi]

On Wed, Nov 13, 2013 at 7:25 PM, Preethi Natarajan wrote:

> Please see inline…
>
> From: Naeem Khademi 
> Date: Wednesday, November 13, 2013 5:01 AM
> To: Preethi Natarajan 
> Cc: Michael Welzl , "aqm@ietf.org" 
>
> Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
>
>
>
>> Michael, Naeem:
>>
>> This is just a follow-up to better understand the ARED results presented
>> at AQM WG (
>> http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-4.pdf).
>>
>> Could you please clarify whether the ARED parameters for the tests were
>> set as specified in the 2001 paper? I.e., when average queueing delay
>> target = 1ms, the min and max thresholds would translate to 0.5ms and
>> 1.5ms, and for 5 ms target the min and max thresh will be 2.5ms and 7.5ms,
>> respectively, right? Can you confirm?
>>
>
> Copy/pasting from Section 3.1.3 of http://urn.nb.no/URN:NBN:no-38868 
> <http://urn.nb.no/URN:NBN:no-38868>
>
> *"In case of ARED, the parameters are calculated based on the
> recommendations in [19]*
> *except when target delay=1 ms where th_min and th_max are set to 1 MTU*
> *and 2 MTUs accordingly."*
>
> *[19] S. Floyd, R. Gummadi, and S. Shenker. Adaptive RED: An Algorithm for*
> *Increasing the Robustness of RED’s Active Queue Management. Technical*
> *report, 2001.*
>
> This means "yes" for all values of target delay except for 1 ms cases
> where the thresholds become smaller than a single MTU transmission time on
> the 10 Mbps bottleneck link used in this case.  The recommendations in
> Sally Flyod' s ARED 2001  (th_max=3*th_min; target=(th_max+th_min)/2) are
> used in all other cases.
>
>
>> Assuming ARED logic is intact, ARED drops all packets when average queue
>> size goes above max_thresh  (max_thresh = 1.5ms or 7.5ms etc.); this
>> would be semantically similar to a drop tail queue with shallow buffer (can
>> be confirmed by looking at cumulative packet drops by ARED).
>>
>
> Similar but not identical as ARED (and any other *RED) does averaging
> instead of using instantaneous queue size (e.g. that being employed in
> DCTCP AQM)
>
>
>> This is probably why the delay values are tight for ARED, and why ARED
>> translates to poor utilization, especially for the lower target delay
>> values, as seen in your slides (#8, #11, #13).
>>
>
> True!
>
>
>
> Thanks for clarifying. That definitely clears the air about why ARED's
> delay values were so tight; trying to maintain the average queue delay
> between such a narrow band between min and max thresholds (0.5ms to 1.5ms
> or 2.5ms to 7.5ms) would naturally result in tighter delay values at the
> cost of utilization. Of course, ARED works on the average queue size, but
> when it comes to such a narrow band between min and max thresholds, we
> suspect there wouldn't be much difference between ARED and drop tail.
>

Very true, though that's what ARED *is* with very low thresholds (e.g.
resonate between 1 or 2 packets on the average in the queue). Indeed there
can possibly be some future work on ARED's (or any other similar AQM) burst
allowance but I don't think e.g. letting a 100 ms burst of packets to pass
through can be a good way of fixing it as this can lead to massive variance
in overall RTT distribution.


>
>
> Also,  wondering if bursty traffic was considered for evaluations, since
>> semantics of drop tail with shallow buffering doesn't accommodate bursty
>> traffic.
>>
>
> No, we did not consider bursty traffic (e.g. multimedia, etc) for this
> work as this was our first (initial) fundamental step to understand in a
> systematic way how AQMs work in real-life with long-lived TCP traffic
> (which is the most common type of traffic that fills up any buffer and
> consistently contributes to excessively long latencies experienced on the
> Internet (a.k.a bufferbloat)).
>
> The fact that AQMs *should* absorb sub-RTT bursts (due to rate mistmatch,
> etc) does not diminish the basic requirement for AQMs that they should
> control the latency induced by bulk (long-lived) TCP traffic in a well
> manner. Any other type of traffic on the access links will most likely to
> coexist with bulk TCP traffic when latency is observed to grow high. In
> other words, if an AQM can't control the latency of (not so bursty as
> others-) TCP traffic, it probably won't be able to do so for bursty traffic
> as well.
>
>
>
> I would not limit an AQM design to absorb just sub-RTT bursts.
>

Neither do I. What I said was that we don't necessarily need to have a very
long distribution tail for long-lived TCP traffic (as observe

Re: [aqm] AQM schemes: Queue length vs. delay based

[Naeem Khademi]

> Delay-based ARED behaves similar to tail drop at max threshold.
>>
>
I think I now understand what you mean by this sentence ;-) and therefore
please ignore the paragraph responding to this specific point in the
previous email (sorry about that, I got it mixed with max_target). Indeed
ARED drops every packet when the average queue length grows beyond th_max
as drop probability jumps to 1 (when it's not in gentle mode). For this to
happen, the "average queue length" has to grow beyond th_max and depending
on how the averaging is done, that can correspond to certain burst
allowance at AQM. Moreover, this is done over 500 ms interval which means
the average queue length has to stay above th_max for mostly few rounds of
RTTs (assuming the typical distribution of RTTs on the Internet to have a
mean/average somewhere below that value e.g. 100~200 ms). This allows burst
that don't take the average queue size to above th_max over 500 ms period
to pass and clear themselves up the queue.

 > This is unacceptable of an AQM even for max thresholds around 50ms.

 Whether this is a good thing or bad thing is a subjective matter in my
opinion, as most AQMs at some point will drop every packet whether it be
the maximum queue length or at some thresholds.

Cheers,
Naeem
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] AQM schemes: Queue length vs. delay based

[Naeem Khademi]

On Thu, Nov 14, 2013 at 12:33 AM, Anoop Ghanwani wrote:

>
>
>
> On Wed, Nov 13, 2013 at 3:23 PM, Curtis Villamizar 
> wrote:
>
>>
>> Including unrealistic scenarios, like going from near zero traffic to 10
>> interfaces feeding one at full speed until overflow occurs, is
>> counterproductive.
>
>
> It is actually a problem that keeps many people busy because a number of
> data center switches have very high port count with very small buffers.
>  Some people address these buy using switches with bigger buffers, but
> that's not a luxury that everyone indulges in.
>

Fair point about the incast problem and I personally think AQMs designed
for data centers should address that.


> That is why I specifically asked the question at the AQM meeting about
> applicability of AQM to all types of networks/switches.  I was told the
> answer is "yes" and so I would like to see this scenario addressed as well.
>
>

Below is my personal opinion, but hopefully Fred can clarify this better
based on the AQM recommendations draft:

"applicability of AQM to all types of networks/switches" => "yes"

"applicability of *any* AQM to all types of networks/switches" => "no"


> Perhaps AQM cannot help this, but hopefully it won't hurt.  Trying to do
> fancy things with small buffers is challenging.
>

AQM will most likely to help from data centers to the access links, and so
on. But we may possibly need different AQMs for different network
scenarios; The fact that an AQMs should be auto-tunable doesn't imply that
it can be applied everywhere and we may need different auto-tunable AQMs
specifically designed for different networks (ideally better if we could
use fewer of them and they could work everywhere). I hope I'm not wrong.


>
> Anoop
>

Naeem
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] AQM schemes: Queue length vs. delay based

[Naeem Khademi]

On Thu, Nov 14, 2013 at 8:46 PM, Preethi Natarajan wrote:

>
>
> From: Naeem Khademi 
> Date: Thursday, November 14, 2013 5:32 AM
>
> To: Preethi Natarajan 
> Cc: Michael Welzl , "aqm@ietf.org" 
> Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
>
>
> AFAIK all three studied AQMs (CoDel, PIE, ARED) have a parameter named
> "target delay" or "target queuing". Judging based on the (param) name, they
> supposedly try to maintain the queue delay/length around/at a certain value
> although "target delay/queuing" has different semantics in each AQM and the
> response to crossing that threshold/value is also different from one AQM to
> another. Moreover, It is favorable for an AQM that tries to fix bufferbloat
> problem to have a predictable delay distribution, most favorably around
> (e.g. mean, median, max) a certain value. PIE uses it, CoDel has it and
> ARED in fixed BW setups has it too. So, I'm not quite sure, why it
> shouldn't be possible to allow a certain size of burst in such
> threshold-based mechanisms (AFAIK (A)RED's Linux implementation already has
> a "burst" param that can be tuned, although its semantics may not be
> identical to the way CoDel or PIE handle bursts).
>
>
> Of course. The question is how effective is the mechanism. As you note,
> whatever "burst" mechanism exists in Linux's ARED wasn't effective as
> evident from the low throughput in the plots.
>
>
>
>
>> Clearly delay-based ARED needs significant and careful redesign. I
>> suppose one can argue this task is as laborious as designing a new AQM
>> scheme as opposed to previous notions that delay-based ARED would work
>> right out of the box.
>>
>
> it's probably not accurate to say "redesign" as delay-based ARED doesn't
> exist as of know. AFAIK given our latest results with ARED, we raised
> the possibility of modifying ARED to use delay-based thresholds instead of
> size-based thresholds during the ICCRG talk and in the TR, and declared it
> as future work. I'm not aware of any other implementation/proposal of
> delay-based ARED to exist as of now. We never claimed or speculated on how
> this future delay-based AQM might perform and left it to when the future
> work is done and the outcome is properly investigated and therefore we
> never said that "it would work right out of the box" :-).
>
>
>
> Great. Thanks for confirming this point that ARED as is does not work well
> for the scenarios considered. What is required is new AQM design, not just
> plugging delay into ARED.
>

Agreed with all your points though to complete it, developing new AQMs
without looking back at and learning from what we have had available leads
to inventing things that improve utilization instead of delay for instance
:-). Again to emphasis we never recommended that people should turn on RED
or ARED (or any future variant of ARED) on their edge devices, but rather
we experimentally demonstrated that it worked better than CoDel and PIE is
most of the scenarios we studied except in very few. We thought it was
important to have more basic understandable experimental results (with
long-lived TCP flows) available before we indulge in looking at more
complex traffic scenarios.

What I would probably choose to investigate e.g. why PIE performs with a
very long upper distribution tail of RTTs with common long-lived TCP
traffic more specifically for lower target delay values even though we know
TCP isn't a very bursty type of traffic? Could that be related to the way
it handles bursts?  or any other reason?  The technical report provides a
very first insight into such issues that need to be explored like this one
but then the story doesn't stop here and ARED was only a benchmark that was
close enough to IETF-documented RED and could work with a certain target
delay (in our scenarios).


> Preethi
>

Naeem
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] AQM schemes: Queue length vs. delay based

[Naeem Khademi]

Very sorry for double-posting as for some reasons "what I was answering to"
was missed from the rest of my previous email. So here again:


On Thu, Nov 14, 2013 at 8:46 PM, Preethi Natarajan wrote:

>
>
> From: Naeem Khademi 
> Date: Thursday, November 14, 2013 5:32 AM
>
> To: Preethi Natarajan 
> Cc: Michael Welzl , "aqm@ietf.org" 
> Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
>
>
> AFAIK all three studied AQMs (CoDel, PIE, ARED) have a parameter named
> "target delay" or "target queuing". Judging based on the (param) name, they
> supposedly try to maintain the queue delay/length around/at a certain value
> although "target delay/queuing" has different semantics in each AQM and the
> response to crossing that threshold/value is also different from one AQM to
> another. Moreover, It is favorable for an AQM that tries to fix bufferbloat
> problem to have a predictable delay distribution, most favorably around
> (e.g. mean, median, max) a certain value. PIE uses it, CoDel has it and
> ARED in fixed BW setups has it too. So, I'm not quite sure, why it
> shouldn't be possible to allow a certain size of burst in such
> threshold-based mechanisms (AFAIK (A)RED's Linux implementation already has
> a "burst" param that can be tuned, although its semantics may not be
> identical to the way CoDel or PIE handle bursts).
>
>
> Of course. The question is how effective is the mechanism. As you note,
> whatever "burst" mechanism exists in Linux's ARED wasn't effective as
> evident from the low throughput in the plots.
>
>
>
>
>> Clearly delay-based ARED needs significant and careful redesign. I
>> suppose one can argue this task is as laborious as designing a new AQM
>> scheme as opposed to previous notions that delay-based ARED would work
>> right out of the box.
>>
>
> it's probably not accurate to say "redesign" as delay-based ARED doesn't
> exist as of know. AFAIK given our latest results with ARED, we raised
> the possibility of modifying ARED to use delay-based thresholds instead of
> size-based thresholds during the ICCRG talk and in the TR, and declared it
> as future work. I'm not aware of any other implementation/proposal of
> delay-based ARED to exist as of now. We never claimed or speculated on how
> this future delay-based AQM might perform and left it to when the future
> work is done and the outcome is properly investigated and therefore we
> never said that "it would work right out of the box" :-).
>
>
>
> Great. Thanks for confirming this point that ARED as is does not work well
> for the scenarios considered. What is required is new AQM design, not just
> plugging delay into ARED.
> Preethi
>

Agreed with all your points though to complete it, developing new AQMs
without looking back at and learning from what we have had available leads
to inventing things that improve utilization instead of delay for instance
:-). Again to emphasis we never recommended that people should turn on RED
or ARED (or any future variant of ARED) on their edge devices, but rather
we experimentally demonstrated that it worked better than CoDel and PIE is
most of the scenarios we studied except in very few. We thought it was
important to have more basic understandable experimental results (with
long-lived TCP flows) available before we indulge in looking at more
complex traffic scenarios.

What I would probably choose to investigate e.g. why PIE performs with a
very long upper distribution tail of RTTs with common long-lived TCP
traffic more specifically for lower target delay values even though we know
TCP isn't a very bursty type of traffic? Could that be related to the way
it handles bursts?  or any other reason?  The technical report provides a
very first insight into such issues that need to be explored like this one
but then the story doesn't stop here and ARED was only a benchmark that was
close enough to IETF-documented RED and could work with a certain target
delay (in our scenarios).
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] AQM schemes: Queue length vs. delay based

[Naeem Khademi]

Hi Rong

comments follow inline

Thanks
Naeem

On Thu, Nov 14, 2013 at 8:59 PM, Rong Pan (ropan)  wrote:

>  Please see inline…
>
>  Thanks,
>
>  Rong
>
>
>
>   From: Naeem Khademi 
> Date: Thursday, November 14, 2013 8:43 AM
> To: Preethi Natarajan 
> Cc: "aqm@ietf.org" , Michael Welzl 
>
> Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
>
>
>
>> Delay-based ARED behaves similar to tail drop at max threshold.
>>>
>>
>  I think I now understand what you mean by this sentence ;-) and
> therefore please ignore the paragraph responding to this specific point in
> the previous email (sorry about that, I got it mixed with max_target).
> Indeed ARED drops every packet when the average queue length grows beyond
> th_max as drop probability jumps to 1 (when it's not in gentle mode). For
> this to happen, the "average queue length" has to grow beyond th_max and
> depending on how the averaging is done, that can correspond to certain
> burst allowance at AQM. Moreover, this is done over 500 ms interval which
> means the average queue length has to stay above th_max for mostly few
> rounds of RTTs (assuming the typical distribution of RTTs on the Internet
> to have a mean/average somewhere below that value e.g. 100~200 ms). This
> allows burst that don't take the average queue size to above th_max over
> 500 ms period to pass and clear themselves up the queue.
>
>   > This is unacceptable of an AQM even for max thresholds around 50ms.
>
>  -
>  >>>>>>>>>>>>>RP: Two issues here, first, averaging has a parameter. How
> to tune it to avoid tail drop behavior? What would be its relationship to
> max_th? Do we understand ?  Second, one single tcp's behavior is very
> bursty, if 500ms burst allowance is effective in ARED, how come is it not
> reflected in your throughput chart? The one single tcp throughput is very
> low for low latency numbers, which is a clear indication of not enough
> buffering.
> 
>


NAEEMK: As stated before, we're not advocating using ARED whatsoever.
Therefore trying to fix/address ARED's inherent issues that have been
stated on this thread repeatedly would not be an option nor it enhances the
argument to support PIE or CoDel for deployment. So, I'm not going to
speculate on how one can possibly fix ARED thresholds and its burst
allowance. On the other hand, based on the presented experimental results,
we would alternatively like to see why CoDel and PIE performed worse that
ARED (designed in 2001) while they were expected to achieve latencies far
better than *RED.


>
>
> Whether this is a good thing or bad thing is a subjective matter in
> my opinion, as most AQMs at some point will drop every packet whether it be
> the maximum queue length or at some thresholds.
>
>  
>  >>>>>>>>>>>>RP: I don’t think so. Neither PIE nor Codel has drop-all
> threshold as AQM part of it. Tail drop exists, but it is not part of AQM.
> Putting the latency-based  ARED aside, ARED in this current form has the
> issues that we mentioned in the previous emails. It needs significant and
> careful redesign.
>

NAEEMK: The same response as above.


> ---
>
>  There is also a comment about "Throwing away all the knowledge and
> improvement gained from RED-like AQMs, CHoKe, etc and coming up with
> brand-new AQMs …".
>
>  --
> >>>>>>>>>>RP: After I worked on CHOKe (now in Linux Kernel)  in 2000 as
> part of my Ph.D. thesis at Stanford, I have worked on AFD (implemented in
> many Cisco flagship products), QCN (now I standard for data center
> ethernet, 802.1Qau), all of which are AQM schemes. I also helped writing
> guidelines in tuning WRED at Cisco. New thinkings were brought into PIE
> after I learned precious lessons (both good and bad) from all of them.
> Discarding them as "coming up with brand-new AQMs" is ignorant.
>

NAEEMK: agreed! and we are on same side :-) though it will be nice to see
the connection points between above AQMs and PIE and lessons learned being
somehow documented.


>
>  Regards,
>
>  Rong
>  
>
>
>  Cheers,
>  Naeem
>
>  >>>>>>>>>>>>RP:
>
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] AQM schemes: Queue length vs. delay based

[Naeem Khademi]

This should have probably been brought in different thread...

comments follow inline

On Thu, Nov 14, 2013 at 9:00 PM, Preethi Natarajan wrote:

>
>
> From: Naeem Khademi 
> Date: Thursday, November 14, 2013 8:05 AM
> To: Anoop Ghanwani 
> Cc: , Michael Welzl , "
> aqm@ietf.org" , Preethi Natarajan 
>
> Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
>
>
>
> Below is my personal opinion, but hopefully Fred can clarify this better
> based on the AQM recommendations draft:
>
> "applicability of AQM to all types of networks/switches" => "yes"
>
> "applicability of *any* AQM to all types of networks/switches" => "no"
>
>
>> Perhaps AQM cannot help this, but hopefully it won't hurt.  Trying to do
>> fancy things with small buffers is challenging.
>>
>
> AQM will most likely to help from data centers to the access links, and so
> on. But we may possibly need different AQMs for different network
> scenarios; The fact that an AQMs should be auto-tunable doesn't imply that
> it can be applied everywhere and we may need different auto-tunable AQMs
> specifically designed for different networks (ideally better if we could
> use fewer of them and they could work everywhere). I hope I'm not wrong.
>
>
>
> Again, please hold on. Even if its personal opinion, I would state facts
> backed with evidence instead of "hopes", since the community's thought
> process is at stake here.
>
> From the preliminary results we've seen, PIE has been able to address data
> center issues quite well. There is no evidence thus far why PIE's control
> law with auto-tuned parameters cannot adapt to data center or other network
> environments.
>

Taking what is mentioned in above sentence granted, there is no evidence if
it cannot or if it can and this point is also orthogonal to my response to
Anoop which was about his question at IETF about AQM deployment in general.



>
> Given that, its too early to "hope" that different network scenarios 
> needdifferent AQM schemes. Of course, different network environments may 
> choose
> to deploy different AQM schemes for various other reasons, which is not the
> point of discussion here.
>

It should have been on another thread. Sorry :-)


>
> Preethi
>

Naeem
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] [iccrg] Clearing up misunderstandings about Linux versioning

[Naeem Khademi]

Hi Dave

Thanks for sharing this and great to know that you're working on
replicating the "AQM Kids..." work presented at ICCRG. jfyi we used Linux
3.10.4 on the AQM box for our real-life tests (also mentioned in Table 4,
page 8 of the TR) and it should contain most of the recent codes on the
latest AQMs judging from what you've written below.

Cheers,
Naeem

On Tue, Nov 26, 2013 at 2:49 AM, Dave Taht  wrote:

> I am in the process of trying to reproduce the recent rite papers on
> immediate congestion notification and the iccrg ARED work and need
> to explain something to researchers so that I don't have to work so hard.
>
> Linux kernel releases are numbered X.Y.Z-Q. All kernel versions
> contain bugs. Linux 3.2.0 was, IMHO, the nadir of the network stack in
> Linux.
>
> The "X" is the major version number. It's only changed 3 times. "Y",
> is the minor version number. These come out roughly quarterly and
> consist of new development of "features". "Z" is critical patches
> backported from newer releases. -Q is usually the vendor's kernel
> build number which often contains more patches.
>
> These numbers, clearly identified, in every academic paper on
> networking, and every presentation, ever published,  would make me a
> happier guy. A pointer to the git tree actually used would make me
> even happier, with all the patches (like DCTCP in this case) applied,
> would cause me to dance for joy, and sing hallelujah!
>
> Anyway, on the "Z" part of X.Y.Z:
>
> Periodically a "long term stable" release is picked and receives updates
> for as long as someone is funded to do it.
>
> *the only things that enter into a long term stable release* are fixes
> for security bugs, crash bugs, and truly egregious bugs that can be
> somewhat easily fixed.
>
> But the rest of the development goes into X.Y+1.
>
> Sane people never run a X.Y.0 release on hardware/data they care about.
>
> So... anyway... when I was told that the recent paper on DCTCP had
> been done against Linux 3.2.18, "which came out in july, 2013!" ...
>
> I was partially happy - pretty stable release - but
> my heart sank as I knew that very, very, very few of the relevant fixes
> for bufferbloat and the tcp stack had landed in anything prior to
> Linux 3.6. Those fixes had mostly qualified as "features". Several in
> fact have been in such continuous development that I'd not want to
> generalize from fq_codel in 3.5 vs what's in 3.8 now, as one example.
>
> So it's my hope that folk will try to follow more closely the X.Y series
> of kernels rather than the 3.2.Z series of kernels in the future. I'm
> very happy with what happened in the 3.12 series in particular and
> look forward to work against it in the near future. The 3.13 work is
> just beginning, too.
>
> In the hope that the showing the mechanics of researching what fixes
> did land in an old stable release would help on future papers,
> here's how to look:
>
> git clone git://
> git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> git clone linux-stable linux-3.2.18
> cd linux-3.2.18
> git checkout v3.2.18
> git checkout -b ritepaper
> git log net include/net # just the networking bits, not the driver
> bits for this example
>
> BQL, enhanced SFQ, SFQRED, codel, fq_codel, tcp small queues,
> retirement of some odd tcp logic, and hundreds of other changes were
> made to the the stack since 3.2.0, and were NOT backported to 3.2.Z.
>
> Some very relevant bugfixes did indeed land in 3.2.18 that were not in 3.2!
>
> If you have an experiment that used TCP that is against an even older
> release, perhaps some of these major bugs might explain your results.
> Here's a sampling:
>
> commit 4b9b05fd95c502521eaef111ba0f83c58b391587
> Author: Eric Dumazet 
> Date:   Wed May 2 02:28:41 2012 +
>
> tcp: change tcp_adv_win_scale and tcp_rmem[2]
>
> 
>
> This also means tcp advertises a too optimistic window for a given
> allocated rcvspace : When receiving frames, sk_rmem_alloc can hit
> sk_rcvbuf limit and we call tcp_prune_queue()/tcp_collapse() too often,
> especially when application is slow to drain its receive queue or in
> case of losses (netperf is fast, scp is slow). This is a major latency
> source.
>
> icommit b713f6c7d317c136f03c132203d0900f4a0de084
> Author: Yuchung Cheng 
> Date:   Mon Apr 30 06:00:18 2012 +
>
> tcp: fix infinite cwnd in tcp_complete_cwr()
>
> [ Upstream commit 1cebce36d660c83bd1353e41f3e66abd4686f215 ]
>
> When the cwnd reduction is done, ssthresh may be infinite
> if TCP enters CWR via ECN or F-RTO. If cwnd is not undone, i.e.,
> undo_marker is set, tcp_complete_cwr() falsely set cwnd to the
> infinite ssthresh value. The correct operation is to keep cwnd
> intact because it has been updated in ECN or F-RTO.
>
> commit 65355aea86b2a70cbc7cbe14466702bc5a4e2217
> Author: Neal Cardwell 
> Date:   Tue Apr 10 07:59:20 2012 +
>
> tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample
>
>

[aqm] What is a good burst? -- AQM evaluation guidelines

[Naeem Khademi]

Hi all

I'm not sure if this has already been covered in any of the other threads,
but looking at http://www.ietf.org/proceedings/88/slides/slides-88-aqm-5.pdfand
draft-ietf-aqm-recommendation-00, the question remains: "what is a
good
burst (size) that AQMs should allow?" and/or "how an AQM can have a notion
of the right burst size?".

and how "naturally-occuring bursts" mentioned in
draft-ietf-aqm-recommendation-00
can be defined?



Regards,
Naeem
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] [e2e] What is a good burst? -- AQM evaluation guidelines

[Naeem Khademi]

Bob, Fred and all

I'll copy/paste the question here again: "what is a good burst (size) that
AQMs should allow?" and/or "how an AQM can have a notion of the right burst
size?"

So, obviously, as Bob mentioned, I'm concerned about what AQMs should or
shouldn't do. The mission of dealing with packet bursts in addition to the
task of keeping the standing queue very low or minimal is part of an "AQM
evaluation criteria" I envision. While I do agree with all Fred's remarks,
I'm more concerned to have an answer for this, for where AQMs might get
deployed.

An example: when designing my AQM X should I care about 64K TSO-generated
bursts to safely pass without dropping or not?  Does the answer (whatever
it is) also apply to the burst sizes typical of multimedia traffic, etc.?
if the answer is "yes", should an AQM design be actively aware of what
application layer does in terms of sending bursty traffic or not? and to
what extent if yes?

Regards,
Naeem

On Mon, Dec 16, 2013 at 8:34 AM, Fred Baker (fred)  wrote:

>
> On Dec 15, 2013, at 2:57 PM, Bob Briscoe 
>  wrote:
>
> > Fred,
> >
> > Jonathan Morton, Michael Scharf & I took Naeem's question to mean "What
> should an AQM assume the size of a good burst is?" whereas I think you and
> David C-B took the question to mean "What should an end-system take the
> size of a good burst to be?".
>
> I can't comment on what he means. I took the question as "what should a
> system that is in receipt of what it might consider a 'burst', and more
> especially a 'good burst', to be?"
>
> I don't know that a sending transport (which is to be distinguished from
> the queueing arrangement in that same system) or a receiving system *has* a
> definition of a "good" or "bad" burst. The one is sending data, which in
> the context of y two examples might be a good or bad idea, and the other is
> receiving it. From the receiver's perspective, the data either arrived or
> it didn't; if it arrived, there is no real argument for not delivering it
> to its application...
>
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] [e2e] What is a good burst? -- AQM evaluation guidelines

[Naeem Khademi]

and to clarify more about what else was discussed, it seems to me some of
us tend to correspond and relate the notion of "good queue" vs. "bad queue"
used by KN+VJ ACM queue paper to my question on "good bursts". While they
likely to be correlated (I have no argument on this now), the notion of
"good burst" goes beyond the "good queue" defined in that paper. Based on
their definition a good queue is a queue that minimizes the standing queue
(or gets rid of it entirely) while allowing a certain amount of (sub-RTT?
typical 100 ms) bursts while avoiding the link to get under-utilized. That
notion (again, I have no argument on its correctness for now) is different
from my question on "good bursts" which means that: once we manage to get
rid of the standing queue, what types/sizes of bursts I should let the AQM
X to protect/handle?

Naeem


On Mon, Dec 16, 2013 at 2:47 PM, Naeem Khademi wrote:

> Bob, Fred and all
>
> I'll copy/paste the question here again: "what is a good burst (size)
> that AQMs should allow?" and/or "how an AQM can have a notion of the right
> burst size?"
>
> So, obviously, as Bob mentioned, I'm concerned about what AQMs should or
> shouldn't do. The mission of dealing with packet bursts in addition to the
> task of keeping the standing queue very low or minimal is part of an "AQM
> evaluation criteria" I envision. While I do agree with all Fred's remarks,
> I'm more concerned to have an answer for this, for where AQMs might get
> deployed.
>
> An example: when designing my AQM X should I care about 64K TSO-generated
> bursts to safely pass without dropping or not?  Does the answer (whatever
> it is) also apply to the burst sizes typical of multimedia traffic, etc.?
> if the answer is "yes", should an AQM design be actively aware of what
> application layer does in terms of sending bursty traffic or not? and to
> what extent if yes?
>
> Regards,
> Naeem
>
> On Mon, Dec 16, 2013 at 8:34 AM, Fred Baker (fred)  wrote:
>
>>
>> On Dec 15, 2013, at 2:57 PM, Bob Briscoe 
>>  wrote:
>>
>> > Fred,
>> >
>> > Jonathan Morton, Michael Scharf & I took Naeem's question to mean "What
>> should an AQM assume the size of a good burst is?" whereas I think you and
>> David C-B took the question to mean "What should an end-system take the
>> size of a good burst to be?".
>>
>> I can't comment on what he means. I took the question as "what should a
>> system that is in receipt of what it might consider a 'burst', and more
>> especially a 'good burst', to be?"
>>
>> I don't know that a sending transport (which is to be distinguished from
>> the queueing arrangement in that same system) or a receiving system *has* a
>> definition of a "good" or "bad" burst. The one is sending data, which in
>> the context of y two examples might be a good or bad idea, and the other is
>> receiving it. From the receiver's perspective, the data either arrived or
>> it didn't; if it arrived, there is no real argument for not delivering it
>> to its application...
>>
>
>
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] WG status

[Naeem Khademi]

I'm interested in contributing to the evaluation guidelines draft as writer
as expressed before, although I won't be able to actively work on this
earlier than the second week of Feb'14.

Regards,
Naeem




On Wed, Jan 8, 2014 at 8:45 PM, Wesley Eddy  wrote:

> Hi, as we've entered 2014 and have charter milestones that we're
> working towards, Richard and I thought it would be good to start
> periodically sending a "status report" to the WG mailing list so
> that we can all keep up with what's going on, and focus our efforts
> together on the things that need work.
>
> Towards that goal, here is a snapshot of where we think the AQM
> working group is at today, and what the next steps are that people
> can contribute to:
>
>
> - 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 needs to be updated per comments received, including
> feedback on the recommendations from the Vancouver meeting
> - 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)
> - We need an editor team to step forward and begin work on this;
> there was initial work presented in Vancouver, but no draft available or
> adopted by the working group yet.
> - It will be difficult to make this milestone, and will push other
> milestones back, if this work isn't accelerated.
> - Please express interest to the chairs or on-list
>
>   - 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 hard to start on without significant progress on the
> previous two.
> - 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
>   - CoDel draft 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
>
>
> --
> Wes Eddy
> MTI Systems
> ___
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] [NS-2 implementation of AQMs]

[Naeem Khademi]

Nicolas,

Good catch although I tend to think that the impact of this would be
more visible on FIFO/DropTail queues; with an AQM presumably set at a
low threshold this impact will probably be less profound (although
depending on too many other factors, such as the load, multiplexing
level, BDP, etc).

Naeem

On Fri, Feb 21, 2014 at 1:10 PM, Ilpo Järvinen
 wrote:
> On Fri, 21 Feb 2014, Nicolas KUHN wrote:
>
>> We have a question regarding the NS-2 implementations of RED, CoDel, PIE
>> and others AQMs. Especially, we believe that the way buffer-overflows
>> are managed is not the same for each AQM scheme.
>>
>> In "Multimedia-unfriendly TCP Congestion Control and Home Gateway Queue
>> Management" (L. Stewart et al.) details that :
>> "PS: The queue is packet (slot) based, and the maximum queue length is
>> specified as an integer number of packets:
>> if (NumPktsInQ ≥ PktQueueLength)
>>   drop incoming packet"
>>
>> However:
>> 1- In droptail.cc: if((q_->length() + 1) >= qlim_) buffer overflow is
>> detected
>> 2- In RED/PIE/CoDel/etc.: if((q_->length() >= qlim_) buffer overflow is
>> detected
>>
>> In the case of RED/PIE, when there are buffer overflows, the incoming
>> packet may not be dropped. As a result, the incoming packet needs to be
>> stored before the other packet is selected for drop: if((q_->length() >=
>> qlim_) should be avoided - and if((q_->length() + 1) >= qlim_) preferred.
>>
>> In the case of CoDel, when there are buffer overflows, the incoming
>> packets are dropped. if((q_->length() >= qlim_) is a good solution.
>>
>> Anyway, the authors of "Multimedia-unfriendly TCP Congestion Control and
>> Home Gateway Queue Management" (L. Stewart et al.) illustrate the impact
>> of this setting that should be carefully discussed. This point is of
>> interest while comparing the performance of various AQM schemes with
>> NS-2.
>>
>> We believe that AQMs that need information about incoming packets before
>> tail-dropping them MUST detect buffer over flow when if((q_->length() +
>> 1) >= qlim_).
>> Any thoughts?
>
> While doing some tests with RED using ns2 in the past, I noticed this same
> difference. I patched ns2 RED to get equal behavior (patch attached but it
> probably breaks some of the ns2 tests which is why I didn't consider
> trying to upstream it).
>
>
> --
>  i.
> ___
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] [Bloat] Draft on fq_codel submitted

[Naeem Khademi]

Great! We now finally have a common basis to discuss about FQ_CoDel.

Naeem


On Mon, Mar 3, 2014 at 12:50 PM, Toke Høiland-Jørgensen <
toke.hoiland-jorgen...@kau.se> wrote:

> Hi everyone
>
> This is to notify you of the availability of a draft explaining the
> fq_codel algorithm. It is available from here:
> http://datatracker.ietf.org/doc/draft-hoeiland-joergensen-aqm-fq-codel/
>
> Thanks,
> -Toke
> ___
> Bloat mailing list
> bl...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Notes

[Naeem Khademi]

Hi Richard

line 134: "???: does an AQM implementation must justify its cost. I don't
think you"

that's *probably* me trying to say that "it's up to the AQM designers to
justify the cost of their proposed AQM given a set of
scenarios/environments where their AQM is aimed to operate at. Q1: Is it
mandatory for them to design an AQM that is justified in cost for every
possible network scenario (e.g. w/ packet scheduling, etc.)? answer: no!
Q2: do we require them (or is it mandatory) to justify the cost of AQM
implementation in where they define their AQM to operate at? yes!"

The current draft actually have specifically covered that.

Cheers,
Naeem


On Tue, Mar 4, 2014 at 5:53 PM, Scheffenegger, Richard wrote:

>  First of all, thanks to the note takers.
>
> We've had quite some discussion around the AQM evaluation guideline draft,
> and I believe the notes capture many of the points brought up.
>
> If you have been up and made a comment on the Microphone, I would like you
> to check if the spirit of your comment has been properly captured in the
> notes:
> *http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-aqm*
>
>
>
> Richard Scheffenegger
>
> NetApp
> *r...@netapp.com* 
> +43 1 3676811 3146 Office (2143 3146 - internal)
> +43 676 654 3146 Mobile
> *www.netapp.com* 
>
> EURO PLAZA
> Gebäude G, Stiege 7, 3.OG
> Am Euro Platz 2
> A-1120 Wien
>
>
>
>
> ___
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>
>
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] Comments on draft-ietf-aqm-eval-guidelines-01?

[Naeem Khademi]

Hi all

Any comments on the newly submitted update as
draft-ietf-aqm-eval-guidelines-01 is welcomed. In the new version, we have
tried to address the issues brought up on the ML as well as the feedback we
received at the IETF-91 and have tried to incorporate them all. We have
also clarified several issues in the text making it more straightforward
and less ambiguous with regards to the "guidelines" and "scenarios". We
would like to have this document discussed on the ML preferably before the
9th March cut-off date as well as during the period prior to IETF-92.

Cheers,
Authors
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] draft-khademi-alternativebackoff - lightly loaded, high BDP paths

[Naeem Khademi]

Hi Simon

Very good point -- I also think this falls into the scope
of draft-ietf-aqm-eval-guidelines aligned with my interpretation of your
words. I believe Section 8.2.2 of
https://tools.ietf.org/html/draft-ietf-aqm-eval-guidelines-08 somewhat
implicitly covers that.

Cheers,
Naeem

On Tue, Oct 13, 2015 at 5:09 AM, Simon Barber  wrote:

> I was very interested to see this draft discusses a problem with AQMs
>
> AQM schemes like CoDel and PIE use congestion notifications to
>constrain the queuing delays experienced by packets, rather than in
>response to impending or actual bottleneck buffer exhaustion.  With
>current default delay targets, CoDel and PIE both effectively emulate
>a shallow buffered bottleneck (section II, [ABE2015 
> ]).
>   This
>interacts acceptably for TCP connections over low BDP paths, or
>highly multiplexed scenarios (lmany concurrent TCP connections).
>However, it interacts badly with lightly-multiplexed cases (few
>concurrent connections) over high BDP paths.  Conventional TCP
>backoff in such cases leads to gaps in packet transmission and
>underutilisation of the path.
>
>
> I think it wold be good to add some discussion of this effect to the draft
> on evaluating AQM algorithms. In many access network scenarios the paths
> will be lightly loaded, and sometimes higher BDPs will be experienced. In
> these cases it's good to know that the AQM is not hurting your experience.
>
> Simon
>
> ___
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>
>
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm