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)" <[email protected]> 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:[email protected]] >>>Sent: Thursday, August 13, 2015 9:56 PM >>>To: Francini, Andrea (Andrea); Roland Bless; Jonathan Morton >>>Cc: [email protected] >>>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)" >>><[email protected]> 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)" >>>><[email protected] on behalf of [email protected]> >>>>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:[email protected]] On Behalf Of Roland Bless >>>>>Sent: Thursday, August 13, 2015 6:39 PM >>>>>To: Jonathan Morton >>>>>Cc: [email protected] >>>>>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 >>>>>[email protected] >>>>>https://www.ietf.org/mailman/listinfo/aqm >>>>> >>>>>_______________________________________________ >>>>>aqm mailing list >>>>>[email protected] >>>>>https://www.ietf.org/mailman/listinfo/aqm >>>> >>> >> >>_______________________________________________ >>aqm mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/aqm > _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
