Re: [aqm] PIE vs. RED

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

It has been a while since I last read the paper in detail :-).

In IV A, we specified that unless otherwise specified, the link speed is
10Mbps and buffer size is 200KB.

Thanks,

Rong

On 8/14/15, 11:32 AM, "Rong Pan (ropan)" <[e-mail]> wrote:

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