Re: [aqm] AQM schemes: Queue length vs. delay based

["Rong Pan (ropan)" <[e-mail]>]

Please see inline…

Thanks,

Rong



From: Naeem Khademi <[e-mail]<mailto:[e-mail]>>
Date: Thursday, November 14, 2013 8:43 AM
To: Preethi Natarajan <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Michael Welzl <[e-mail]<mailto:[e-mail]>>
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.
------------------------------------


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

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.

Regards,

Rong
--------------------------------


Cheers,
Naeem

>>>>>>>>>>>>RP: