From: Naeem Khademi <[email protected]<mailto:[email protected]>> Date: Thursday, November 14, 2013 1:58 PM To: Cisco Employee <[email protected]<mailto:[email protected]>> Cc: Preethi Natarajan <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Michael Welzl <[email protected]<mailto:[email protected]>> Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
Hi Rong comments follow inline Thanks Naeem On Thu, Nov 14, 2013 at 8:59 PM, Rong Pan (ropan) <[email protected]<mailto:[email protected]>> wrote: Please see inline… Thanks, Rong From: Naeem Khademi <[email protected]<mailto:[email protected]>> Date: Thursday, November 14, 2013 8:43 AM To: Preethi Natarajan <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Michael Welzl <[email protected]<mailto:[email protected]>> Subject: Re: [aqm] AQM schemes: Queue length vs. delay based Delay-based ARED behaves similar to tail drop at max threshold. I think I now understand what you mean by this sentence ;-) and therefore please ignore the paragraph responding to this specific point in the previous email (sorry about that, I got it mixed with max_target). Indeed ARED drops every packet when the average queue length grows beyond th_max as drop probability jumps to 1 (when it's not in gentle mode). For this to happen, the "average queue length" has to grow beyond th_max and depending on how the averaging is done, that can correspond to certain burst allowance at AQM. Moreover, this is done over 500 ms interval which means the average queue length has to stay above th_max for mostly few rounds of RTTs (assuming the typical distribution of RTTs on the Internet to have a mean/average somewhere below that value e.g. 100~200 ms). This allows burst that don't take the average queue size to above th_max over 500 ms period to pass and clear themselves up the queue. > This is unacceptable of an AQM even for max thresholds around 50ms. ----------------------------- >>>>>>>>>>>>>RP: Two issues here, first, averaging has a parameter. How to tune >>>>>>>>>>>>>it to avoid tail drop behavior? What would be its relationship to >>>>>>>>>>>>>max_th? Do we understand ? Second, one single tcp's behavior is >>>>>>>>>>>>>very bursty, if 500ms burst allowance is effective in ARED, how >>>>>>>>>>>>>come is it not reflected in your throughput chart? The one single >>>>>>>>>>>>>tcp throughput is very low for low latency numbers, which is a >>>>>>>>>>>>>clear indication of not enough buffering. ------------------------------------ NAEEMK: As stated before, we're not advocating using ARED whatsoever. Therefore trying to fix/address ARED's inherent issues that have been stated on this thread repeatedly would not be an option nor it enhances the argument to support PIE or CoDel for deployment. So, I'm not going to speculate on how one can possibly fix ARED thresholds and its burst allowance. On the other hand, based on the presented experimental results, we would alternatively like to see why CoDel and PIE performed worse that ARED (designed in 2001) while they were expected to achieve latencies far better than *RED. RP: If low latencies are achieved at the cost of losing quite a bit of throughput, it is a no-starter for AQM design. Whether this is a good thing or bad thing is a subjective matter in my opinion, as most AQMs at some point will drop every packet whether it be the maximum queue length or at some thresholds. ---------------------------- >>>>>>>>>>>>RP: I don’t think so. Neither PIE nor Codel has drop-all threshold >>>>>>>>>>>>as AQM part of it. Tail drop exists, but it is not part of AQM. >>>>>>>>>>>>Putting the latency-based ARED aside, ARED in this current form >>>>>>>>>>>>has the issues that we mentioned in the previous emails. It needs >>>>>>>>>>>>significant and careful redesign. NAEEMK: The same response as above. --------------------------- There is also a comment about "Throwing away all the knowledge and improvement gained from RED-like AQMs, CHoKe, etc and coming up with brand-new AQMs …". ------------------------------------------ >>>>>>>>>>RP: After I worked on CHOKe (now in Linux Kernel) in 2000 as part of >>>>>>>>>>my Ph.D. thesis at Stanford, I have worked on AFD (implemented in >>>>>>>>>>many Cisco flagship products), QCN (now IEEEE standard for data >>>>>>>>>>center ethernet, 802.1Qau), all of which are AQM schemes. I also >>>>>>>>>>helped writing guidelines in tuning WRED at Cisco. New thinkings were >>>>>>>>>>brought into PIE after I learned precious lessons (both good and bad) >>>>>>>>>>from all of them. Discarding them as "coming up with brand-new AQMs" >>>>>>>>>>is ignorant. NAEEMK: agreed! and we are on same side :-) though it will be nice to see the connection points between above AQMs and PIE and lessons learned being somehow documented. >>>>>>RP: starting reading some of the papers about those designs, especially >>>>>>PIE on HPSR2013, would be a good start…. Regards, Rong Regards, Rong -------------------------------- Cheers, Naeem >>>>>>>>>>>>RP:
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
