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
