Re: [aqm] PIE vs. RED

["Francini, Andrea (Andrea)" <[e-mail]>]

> 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

That's my point (and I believe also Roland's): In a direct experimental comparison, this good property of PIE would be better emphasized against a configuration of RED where the queue length thresholds are not grossly oversized.

By the way, Global Synchronization Protection (GSP) also drops/marks at a fixed delay level independently of the drop/mark rate that keeps the queue stable. The draft that describes it (https://tools.ietf.org/id/draft-lauten-aqm-gsp-02.txt) is still active. I have seen only marginal comments about GSP. Any specific reason why?

Andrea 


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