From: Anoop Ghanwani
Date: Sunday, November 17, 2013 10:53 AM
To: Preethi Natarajan
Cc: Naeem Khademi , curtis
, Michael Welzl , "aqm@ietf.org"
Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
>
>
>
> On Thu, Nov 14, 2013 at 5:33 PM, Pree
On 11/18/13 4:44 AM, "Scheffenegger, Richard" wrote:
>[chair hat off]
>
>Hi Michael,
>
>>
>>--
>RP: Again, the tight delay control comes from narrow-band
>bang-bang control with hard drops. The scenarios >that
>throughputs are goo
On 18. nov. 2013, at 13:44, Scheffenegger, Richard wrote:
> [chair hat off]
>
> Hi Michael,
>
>>
>> --
> RP: Again, the tight delay control comes from narrow-band bang-bang
> control with hard drops. The scenarios >that throughputs are
paring this for various AQMs should be documented.
Richard Scheffenegger
From: aqm-boun...@ietf.org [mailto:aqm-boun...@ietf.org] On Behalf Of Michael
Welzl
Sent: Freitag, 15. November 2013 20:36
To: Rong Pan (ropan)
Cc: Naeem Khademi; Preethi Natarajan; aqm@ietf.org
Subject: Re: [aqm] AQM sc
On Sun, 17 Nov 2013, Anoop Ghanwani wrote:
This should give you an idea of the kind of buffering that is actually
available. As port-counts go up, the amount of buffering per port goes
down. http://people.ucsc.edu/~warner/buffer.html
Not only that, but some switches actually have shared buff
On Thu, Nov 14, 2013 at 5:33 PM, Preethi Natarajan wrote:
>
>
> Just pointing out the evidence here --
> http://www.ietf.org/proceedings/86/slides/slides-86-iccrg-5.pdf
>
> The slides contain preliminary results from DC scenarios, showing PIE's
> parameters and adaptability to DC scenarios. Thank g
Well, sounds like your opinion about that consensus; no doubt that analysis
makes a paper stronger, but also no point in speculating about the reasons
why she never got it published.
You might speak with your opinion. I spoke with my scarred experience. Our
original proposal of BCN
I have been doing my best to ignore this thread.
Gripe #1:
What I saw of the ARED presentation seemed to show that if you
sacrificed quite a bit of throughput you'd get vastly better latency,
on a very simple set of benchmarks. I can go through each slide to see
where there were results that were
Hi,
In line, but snipping some things away:
> [About evaluating against other-than-RED AQMs]
> --
> RP: RED is the only one out there that got wide adoptions. Compared
> with the state of the art in products (not in papers) is the idea.
"aqm@ietf.org<mailto:aqm@ietf.org>" mailto:aqm@ietf.org>>
Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
Hi,
Interesting discussion!
I would like to say that in my opinion the real value of what Naeem has
presented is not so much in pushing ARED, but in:
-
TCP as deployed can be pretty bursty; TSO often results in 44 packet bursts
(later in connections, once the window has opened wide enough), which is
one reason IW10 caused very little harm. I wouldn't say Google favours
that; as Yuchung's presentation in TCPM showed, the TCP team here is
working h
On Nov 13, 2013, at 2:43 PM, Anoop Ghanwani wrote:
> On Wed, Nov 13, 2013 at 12:14 PM, Naeem Khademi
> wrote:
>
> Agreed only in general terms -- but what would be considered as "packet
> burst" and how would it be defined? This will probably have a subjective
> answer e.g. one can argue th
Hi,
Interesting discussion!
I would like to say that in my opinion the real value of what Naeem has
presented is not so much in pushing ARED, but in:
- reminding people that there was AQM stuff done between RED and CoDel, and
some of this is worth looking at. Rong, we're aware of at least some
From: Naeem Khademi
Date: Thursday, November 14, 2013 1:06 PM
To: Preethi Natarajan
Cc: curtis , Michael Welzl ,
"aqm@ietf.org" , Anoop Ghanwani
Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
>
> This should have probably been brought in different thread.
Michael Welzl mailto:mich...@ifi.uio.no>>
Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
Hi Rong
comments follow inline
Thanks
Naeem
On Thu, Nov 14, 2013 at 8:59 PM, Rong Pan (ropan)
mailto:ro...@cisco.com>> wrote:
Please see inline…
Thanks,
Rong
From: Naeem Kha
t; 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 net
; 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
> t
On Thu, 14 Nov 2013, 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 th
;
> 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
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
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 clarif
ailto:mich...@ifi.uio.no>>
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
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 "targe
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.
>
>
> 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
From: Naeem Khademi
Date: Wednesday, November 13, 2013 12:14 PM
To: Preethi Natarajan
Cc: Michael Welzl , "aqm@ietf.org"
Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
>
> Very true, though that's what ARED *is* with very low thresholds (e.g.
>
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
da
On Wed, Nov 13, 2013 at 12:14 PM, Naeem Khademi wrote:
>
> Agreed only in general terms -- but what would be considered as "packet
> burst" and how would it be defined? This will probably have a subjective
> answer e.g. one can argue that a size of TCP sawtooth of data is a burst
> and therefore w
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 lengt
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-u
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
>
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
On 8. nov. 2013, at 12:34, Preethi Natarajan wrote:
> Hello Michael, all:
>
> Please see inline.
>
> From: Michael Welzl
> Date: Friday, November 8, 2013 2:11 PM
> To: Preethi Natarajan
> Cc: Naeem Khademi , "aqm@ietf.org"
> Subject: Re: [aqm] AQM
Hello Michael, all:
Please see inline.
From: Michael Welzl
Date: Friday, November 8, 2013 2:11 PM
To: Preethi Natarajan
Cc: Naeem Khademi , "aqm@ietf.org"
Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
>
> On 8. nov. 2013, at 11:00, Preethi Natarajan
On 8. nov. 2013, at 11:00, Preethi Natarajan wrote:
> Hi Naeem, all:
>
> Please see detailed responses inline.
>
> From: Naeem Khademi
> Date: Thursday, November 7, 2013 10:50 PM
> To: Preethi Natarajan
> Cc: "aqm@ietf.org"
> Subject: Re: [aqm] AQM
Hi Naeem, all:
Please see detailed responses inline.
From: Naeem Khademi
Date: Thursday, November 7, 2013 10:50 PM
To: Preethi Natarajan
Cc: "aqm@ietf.org"
Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
> I fully agree with the need to have AQMs that use "
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
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 va
38 matches
Mail list logo
