If you are interested, here's our 2001 paper showing all the limitations of RED and explaining the rationale behind the PI controller. It explained how delay and drop/ECN-mark can be decoupled for AQMs.
http://dna-pubs.cs.columbia.edu/citation/paperfile/23/MisraInfocom01-AQM-Controller.pdf The control action of PIE is identical to the PI controller we proposed. -Vishal -- http://www.cs.columbia.edu/~misra/ > On Aug 14, 2015, at 4:45 AM, Rong Pan (ropan) <[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 > > > 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
