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