Re: [aqm] PIE vs. RED

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

Yes, with 10Mbps output rate the results in Figure 8 realign with the expectations. 

Because of the statement at the beginning of IV.A I had first thought that the 10Mbps setup should apply to Figure 8, but then the placement of the paragraph that describes the 100Mbps setup, titled "Performance Evaluation and Comparison", made me conclude that both of the remaining experiments in that section, not just the one in IV.A.5, used that same configuration. 

Thank you for clarifying,

Andrea

-----Original Message-----
From: Rong Pan (ropan) [mailto:[e-mail]] 
Sent: Friday, August 14, 2015 2:41 PM
To: Francini, Andrea (Andrea); Roland Bless; Jonathan Morton
Cc: [e-mail]
Subject: Re: [aqm] PIE vs. RED

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
>