Re: [aqm] PIE vs. RED

[Vishal Misra <[e-mail]>]

If you are interested, here's our 2001 paper showing all the limitations of RED and explaining the rationale behind the PI controller. It explained how delay and drop/ECN-mark can be decoupled for AQMs. 

http://dna-pubs.cs.columbia.edu/citation/paperfile/23/MisraInfocom01-AQM-Controller.pdf

The control action of PIE is identical to the PI controller we proposed. 

-Vishal
--
http://www.cs.columbia.edu/~misra/

> On Aug 14, 2015, at 4:45 AM, Rong Pan (ropan) <[e-mail]> wrote:
> 
> Delayed-based RED still would associate latency with drop probability:
> drop probability will only go up when queueing latency goes up. A higher
> drop probability can only be achieved via higher queueing latency.  As we
> proved in PIE, the two can be made independent. We can maintain low
> latency regardless of traffic intensity.
> 
> Rong
> 
> 
> On 8/13/15, 4:07 PM, "aqm on behalf of Francini, Andrea (Andrea)"
> <[e-mail] on behalf of [e-mail]>
> wrote:
> 
>> To second Roland's point, the advantage of PIE over RED should not be
>> entirely in the use of delay-based thresholds instead of queue-length
>> ones, otherwise it could be argued that a version of RED with delay-based
>> thresholds is not too hard to design (Wolfram easily did it for his GSP
>> scheme). 
>> 
>> With such a RED version in place, hopefully PIE would still show better
>> performance, so the same superiority should also emerge when the
>> queue-length thresholds of conventional RED are reasonably tuned around
>> the traffic scenario of each experiment.
>> 
>> Andrea
>> 
>> -----Original Message-----
>> From: aqm [mailto:[e-mail]] On Behalf Of Roland Bless
>> Sent: Thursday, August 13, 2015 6:39 PM
>> To: Jonathan Morton
>> Cc: [e-mail]
>> Subject: Re: [aqm] PIE vs. RED
>> 
>> Hi Jonathan,
>> 
>>> Am 13.08.2015 um 19:35 schrieb Jonathan Morton:
>>> In the real world, the hardware buffer size is rarely matched to the
>>> real BDP.  There are several reasons for this, but a couple of
>>> fundamental ones are:
>>> 
>>> - BDP varies with RTT, which is in general different for flows
>>> simultaneously using the same link/queue to reach different remote
>>> hosts, and therefore cannot be accurately predicted by a hardware
>>> vendor.
>> 
>> Yep, sure. My point was not to promote setting the buffers according to
>> "the BDP", but rather arguing that one should use comparable target
>> settings when comparing AQMs, see below...
>> 
>>> - Frequently, the queue size is tuned for the maximum capability of the
>>> device and a pessimistic value for RTT, but the same hardware is more
>>> often used (at least initially) at lower link speeds and thebqueue size
>>> is not adjusted to compensate.  Eg. DOCSIS 2 cable but DOCSIS 3 modem,
>>> Ethernet NIC or switch capable of 1000Mbps but operating at 100 or even
>>> 10, 802.11ac wifi struggling with a marginal 802.11g link...
>>> 
>>> Thus substantially oversized raw buffers are quite normal.  It is AQM's
>>> job to keep the *actual* queue occupancy low; with a properly
>>> functioning AQM, the effects of an oversized raw queue are nil.
>> 
>> That's correct. However, IMHO if one compares AQMs one should set/tune
>> the individual parameters of the AQMs so that they achieve a similar
>> target value (and not more than an order of magnitude apart).
>> This is probably relevant for the aqm eval guidelines, but
>> I'll come up with a detailed review for the draft within the next days...
>> 
>> Regards,
>> Roland
>> 
>> _______________________________________________
>> aqm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/aqm
>> 
>> _______________________________________________
>> aqm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/aqm
> 
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm