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

[Naeem Khademi <[e-mail]>]

Hi Rong

comments follow inline

Thanks
Naeem

On Thu, Nov 14, 2013 at 8:59 PM, Rong Pan (ropan) <[e-mail]> wrote:

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


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.


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


>
>  Regards,
>
>  Rong
>  --------------------------------
>
>
>  Cheers,
>  Naeem
>
>  >>>>>>>>>>>>RP:
>