Rong, Preethi, Greg, Fred, and others involved in PIE,
You may recall that when we wrote PI2 we didn't include any of PIE's
heuristics. Mostly because PI2 solved the issues they addressed
intrinsically. But we left some until we had checked their benefit,
which is what I'm doing now...
My fi
Bob,
Sorry for the late reply. I have been traveling. Please see inlineŠ
Rong
On 3/23/17, 5:01 PM, "aqm on behalf of Bob Briscoe" wrote:
>Rong, Preethi, Greg, Fred, and others involved in PIE,
>
>You may recall that when we wrote PI2 we didn't include any of PIE's
>heuristics. Mostly because P
> On 28 Mar, 2017, at 04:04, Rong Pan (ropan) wrote:
>
>> Q1. What were the reasons for introducing such a frequent suppression of
>> the PI algorithm (the RFC just says what this code does, not why)?
>
> To be work conserving and avoid any unnecessary drops are the main reasons
> behind it.
>
> On Mar 28, 2017, at 1:25 AM, Jonathan Morton wrote:
>
>
>> On 28 Mar, 2017, at 04:04, Rong Pan (ropan) wrote:
>>
>>> Q1. What were the reasons for introducing such a frequent suppression of
>>> the PI algorithm (the RFC just says what this code does, not why)?
>>
>> To be work conserving a
> On 28 Mar, 2017, at 14:39, Fred Baker wrote:
>
> I'm not convinced I understand the definitions of "work conserving" and "non
> work conserving" in this context. A "work conserving" scheduling algorithm
> keeps an interface transmitting as long as there is data in the queue, while
> a non-w
Hi,
Am 28.03.2017 um 13:39 schrieb Fred Baker:
> I'm not convinced I understand the definitions of "work conserving"
> and "non work conserving" in this context. A "work conserving"
> scheduling algorithm keeps an interface transmitting as long as there
> is data in the queue, while a non-work-co
Rong,
Some comments inline. And one remaining question at the end...
On 28/03/17 02:04, Rong Pan (ropan) wrote:
Bob,
Sorry for the late reply. I have been traveling. Please see inlineŠ
Rong
On 3/23/17, 5:01 PM, "aqm on behalf of Bob Briscoe" wrote:
Rong, Preethi, Greg, Fred, and others in
[BB]: So that begs just one remaining question:
Q: Do you have tests showing any benefit, specifically comparing with
and without this "< QDELAY_REF/2" heuristic?
If we set the QDELAY_REF too low, we have seen losing throughput. This is
related
to your question regarding qdelay_old_. You are usi
org>>, Preethi Natarajan
mailto:prena...@cisco.com>>
Subject: Re: [aqm] Questioning each PIE heuristic
Work conserving is supposed to be referring to the scheduler.
I'm not familiar with work-conservation when it refers to active queue
management.
I'm not sure it is actually d
Work conserving is supposed to be referring to the scheduler.
I'm not familiar with work-conservation when it refers to active queue
management.
I'm not sure it is actually defined.
I can understand that an AQM can produce under utilization of the link, but
that is
different to work conservation.
; Preethi
Natarajan
Subject: Re: [aqm] Questioning each PIE heuristic
Sorry for causing the confusion in choosing the word "work-conserving". If we
apply AQM and can not achieving 100% line rate, i.e. losing throughput, it is a
big No No. Since we are dealing with TCP traffic, excess
i...@bobbriscoe.net>>, "De
Schepper, Koen (Nokia - BE/Antwerp)"
<mailto:koen.de_schep...@nokia-bell-labs.com>>, Greg White
mailto:g.wh...@cablelabs.com>>, Jonathan
Morton mailto:chromati...@gmail.com>>, AQM
IETF list mailto:aqm@ietf.org>>, Preethi Nataraj
>>, Jonathan
Morton mailto:chromati...@gmail.com>>, AQM IETF list
mailto:aqm@ietf.org>>, Preethi Natarajan
mailto:prena...@cisco.com>>
Subject: RE: [aqm] Questioning each PIE heuristic
To my understanding a proper operating AQM _is_ work-conserving. Packet drops
occur, if an
Jonathan,
Picking up on an earlier point you made about avoiding heuristics by
ensuring the underlying algo is sound,... that's precisely why I'm going
through all the (9) PIE heuristics...
For PI2 we removed all but 2 and it worked the same or better than PIE
in all our tests. I have been a
> On 30 Mar, 2017, at 10:46, Bob Briscoe wrote:
>
> For PI2 we removed all but 2 and it worked the same or better than PIE in all
> our tests. I have been assessing each of the other 7 one by one for
> reinstatement. So far I've rejected 6. I think I can reject this last one by
> making the s
---
From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Bob Briscoe
Sent: Thursday, March 30, 2017 2:47 AM
To: Jonathan Morton; Rong Pan (ropan)
Cc: Greg White; tsvwg IETF list; AQM IETF list; fredbaker.i...@gmail.com
Subject: Re: [aqm] Questioning each PIE heuristic
Jonathan,
Picking up on an earlier
Hi all,
Am 30.03.2017 um 11:08 schrieb Jonathan Morton:
>
>> On 30 Mar, 2017, at 10:46, Bob Briscoe wrote:
>>
>> For PI2 we removed all but 2 and it worked the same or better than PIE in
>> all our tests. I have been assessing each of the other 7 one by one for
>> reinstatement. So far I've re
Michael,
I just started reading your paper. Two comments so far:
*1) PIE rate averaging is an unfortunate example**
*In related work, you mention PIE's measurement of the link rate as an
example of use of moving averages. This is an unfortunate example,
because the PIE code screws up the calcu
Hi Bob, hi Rong,
Am 25.05.2017 um 00:34 schrieb Bob Briscoe:
> Michael,
>
> I just started reading your paper. Two comments so far:
>
> *1) PIE rate averaging is an unfortunate example**
> *In related work, you mention PIE's measurement of the link rate as an
> example of use of moving averages.
Michael,
Yes, I should have said that the most useful aspect of your paper is the
model that ties all the different algos together allowing comparison.
Bob
On 25/05/17 08:55, Michael Menth wrote:
Hi Bob, hi Rong,
Am 25.05.2017 um 00:34 schrieb Bob Briscoe:
Michael,
I just started reading
Michael and Bob,
The depart_rate is inversed in calculation delay….
Delay = queue_length/depart_rate;
Hence, current_qdelay = queue_.byte_length() * PIE- >avg_dq_time_/DQ_THRESHOLD;
Basically the average dq_time for dequeueing DQ_THRESHOLD is PIE->dq_time; What
is the approximate time to deque
Additional consideration is that 1/t1 would involve divide, which will be hard
to implement in hardware…
Regards,
Rong
On 5/26/17, 11:29 AM, "aqm on behalf of Rong Pan (ropan)" wrote:
Michael and Bob,
The depart_rate is inversed in calculation delay….
Delay = queue_length/dep
Rong,
That's a good rationale.
I withdraw my criticism of PIE on this point.
The code is OK, it's just the explanation that is misleading. it
shouldn't say it is measuring the average dequeue rate, and there's no
need to. It should describe the calculation as a moving average of the
time to d
23 matches
Mail list logo
