Re: [aqm] PIE vs. RED

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

>
>
>This is an omission in the paper, which we should specify. This simulation
>is done with 10Mbps link with 200KB of buffer. We did size our buffers
>according to the BDP. As Jonathan rightly pointed out, "the queue size is
>tuned for the maximum capability of the device and a pessimistic value for
>RTT². Figure 7 is intended to show that in reality link speed may not get
>to the max capacity, and hence well-intended BDP buffer sizing may cause
>extreme delays, the time between 50-100s in the plot.
>

Just to make it clear, Figure 8 is run using 10Mbps link with 200KB
buffer. 
We should clearly specify in the paper, sorry for that.

Figure 7 is run using 100Mbps with 2MB of buffer and in the middle of the
simulation,
the link speed is reduced to 20Mbps to illustrate the case where
well-intended 
buffer sizing might cause delay bloat.






>
>
>>
>>Thank you,
>>
>>Andrea
>>
>>-----Original Message-----
>>From: Rong Pan (ropan) [mailto:[e-mail]]
>>Sent: Thursday, August 13, 2015 9:56 PM
>>To: Francini, Andrea (Andrea); Roland Bless; Jonathan Morton
>>Cc: [e-mail]
>>Subject: Re: [aqm] PIE vs. RED
>>
>>>>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
>>>
>>
>
>_______________________________________________
>aqm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm