Re: [aqm] Questioning each PIE heuristic

Wolfram,

Just to explain some context. The PIE algorithm determines a dropping 
probability at sample times (default 16ms), then continues to drop with 
that probability until the next sample. If the queue had been large then 
traffic ends, while the queue is draining towards zero it is still 
dropping at the last calculated probability. So the PIE code includes a 
heuristic that suppresses any drop if the queue is less than half the 
target. Nonetheless, the PIE algo continues to calculate what the drop 
probability /would/ be if a queue of more than half the target appeared 
again.

This is so that the drop probability reflects a longer running measure 
of the load as well as the instantaneous queue.

Bob

On 29/03/17 18:58, Rong Pan (ropan) wrote:
> We are not holding back queued packets when the link is idle. We stop 
> dropping packets when the queue is shallow in order to avoid 
> unnecessary drops that could cause TCP traffic to back off and stop 
> sending traffic that will cause link idle.
>
> Rong
>
> From: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" 
> <wolfram.lautenschlaeger@nokia-bell-labs.com 
> <mailto:wolfram.lautenschlaeger@nokia-bell-labs.com>>
> Date: Wednesday, March 29, 2017 at 2:30 AM
> To: Rong Pan <ropan@cisco.com <mailto:ropan@cisco.com>>, Luca 
> Muscariello <luca.muscariello@gmail.com 
> <mailto:luca.muscariello@gmail.com>>, "Bless, Roland (TM)" 
> <roland.bless@kit.edu <mailto:roland.bless@kit.edu>>
> Cc: tsvwg IETF list <tsvwg@ietf.org <mailto:tsvwg@ietf.org>>, Fred 
> Baker <fredbaker.ietf@gmail.com <mailto:fredbaker.ietf@gmail.com>>, 
> Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>>, "De 
> Schepper, Koen (Nokia - BE/Antwerp)" 
> <koen.de_schepper@nokia-bell-labs.com 
> <mailto:koen.de_schepper@nokia-bell-labs.com>>, Greg White 
> <g.white@cablelabs.com <mailto:g.white@cablelabs.com>>, Jonathan 
> Morton <chromatix99@gmail.com <mailto:chromatix99@gmail.com>>, AQM 
> IETF list <aqm@ietf.org <mailto:aqm@ietf.org>>, Preethi Natarajan 
> <prenatar@cisco.com <mailto:prenatar@cisco.com>>
> Subject: RE: [aqm] Questioning each PIE heuristic
>
> To my understanding a proper operating AQM _/is/_ work-conserving. 
> Packet drops occur, if any, when a reasonable queue is present. And as 
> long as packets are present in the queue, the link runs at 100%. I 
> cannot see any (AQM) mechanism that is holding back queued packets 
> while the link is idle.
>
> Wolfram
>
> *From:*aqm [mailto:aqm-bounces@ietf.org] *On Behalf Of *Rong Pan (ropan)
> *Sent:* Dienstag, 28. März 2017 16:17
> *To:* Luca Muscariello <luca.muscariello@gmail.com 
> <mailto:luca.muscariello@gmail.com>>; Bless, Roland (TM) 
> <roland.bless@kit.edu <mailto:roland.bless@kit.edu>>
> *Cc:* tsvwg IETF list <tsvwg@ietf.org <mailto:tsvwg@ietf.org>>; Fred 
> Baker <fredbaker.ietf@gmail.com <mailto:fredbaker.ietf@gmail.com>>; 
> Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>>; De 
> Schepper, Koen (Nokia - BE/Antwerp) 
> <koen.de_schepper@nokia-bell-labs.com 
> <mailto:koen.de_schepper@nokia-bell-labs.com>>; Greg White 
> <g.white@cablelabs.com <mailto:g.white@cablelabs.com>>; Jonathan 
> Morton <chromatix99@gmail.com <mailto:chromatix99@gmail.com>>; AQM 
> IETF list <aqm@ietf.org <mailto:aqm@ietf.org>>; Preethi Natarajan 
> <prenatar@cisco.com <mailto:prenatar@cisco.com>>
> *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 drops can cause TCP to back off too much and 
> under-utilize the link.
>
> Rong
>
> *From: *Luca Muscariello <luca.muscariello@gmail.com 
> <mailto:luca.muscariello@gmail.com>>
> *Date: *Tuesday, March 28, 2017 at 8:48 AM
> *To: *"Bless, Roland (TM)" <roland.bless@kit.edu 
> <mailto:roland.bless@kit.edu>>
> *Cc: *Fred Baker <fredbaker.ietf@gmail.com 
> <mailto:fredbaker.ietf@gmail.com>>, Jonathan Morton 
> <chromatix99@gmail.com <mailto:chromatix99@gmail.com>>, tsvwg IETF 
> list <tsvwg@ietf.org <mailto:tsvwg@ietf.org>>, Bob Briscoe 
> <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>>, "De Schepper, Koen 
> (Koen)" <koen.de_schepper@nokia.com 
> <mailto:koen.de_schepper@nokia.com>>, Rong Pan <ropan@cisco.com 
> <mailto:ropan@cisco.com>>, Greg White <g.white@cablelabs.com 
> <mailto:g.white@cablelabs.com>>, AQM IETF list <aqm@ietf.org 
> <mailto:aqm@ietf.org>>, Preethi Natarajan <prenatar@cisco.com 
> <mailto:prenatar@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 defined.
>
> I can understand that an AQM can produce under utilization of the 
> link, but that is
>
> different to work conservation. Or is it maybe more subtle than that?
>
> Luca
>
> On Tue, Mar 28, 2017 at 1:48 PM, Bless, Roland (TM) 
> <roland.bless@kit.edu <mailto:roland.bless@kit.edu>> wrote:
>
>     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-conserving algorithm reduces
>     > the effective rate of the interface by spacing packets out.
>
>     +1 (that's also the definition I use, so I'm lost here too)
>
>     Regards,
>      Roland
>
>
>     _______________________________________________
>     aqm mailing list
>     aqm@ietf.org <mailto:aqm@ietf.org>
>     https://www.ietf.org/mailman/listinfo/aqm
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/