Re: [aqm] PIE vs. RED

["Rong Pan (ropan)" <[e-mail]>]

>>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.


In our PIE paper (attached), Figure 8 shows the max latency of RED is
around 100ms (which is very reasonable). PIE controls latency regardless
of traffic intensity. It is the plot that you want.

Thanks,

Rong

On 8/13/15, 5:25 PM, "Francini, Andrea (Andrea)"
<[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
>
>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
>