> 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
