Subject: [aqm] draft-khademi-alternativebackoff - lightly loaded, high BDP paths

From: Simon Barber <[email-masked]>
Date: Mon, 12 Oct 2015 20:09:07 -0700

I was very interested to see this draft discusses a problem with AQMs

AQM schemes like CoDel and PIE use congestion notifications to
    constrain the queuing delays experienced by packets, rather than in
    response to impending or actual bottleneck buffer exhaustion.  With
    current default delay targets, CoDel and PIE both effectively emulate
    a shallow buffered bottleneck (section II, [ABE2015  <https://tools.ietf.org/html/draft-khademi-alternativebackoff-ecn-01#ref-ABE2015>]).  This
    interacts acceptably for TCP connections over low BDP paths, or
    highly multiplexed scenarios (lmany concurrent TCP connections).
    However, it interacts badly with lightly-multiplexed cases (few
    concurrent connections) over high BDP paths.  Conventional TCP
    backoff in such cases leads to gaps in packet transmission and
    underutilisation of the path.

I think it wold be good to add some discussion of this effect to the 
draft on evaluating AQM algorithms. In many access network scenarios the 
paths will be lightly loaded, and sometimes higher BDPs will be 
experienced. In these cases it's good to know that the AQM is not 
hurting your experience.

Simon

---

From: Naeem Khademi <[email-masked]>
Date: Wed, 14 Oct 2015 03:42:51 +0200

Hi Simon

Very good point -- I also think this falls into the scope
of draft-ietf-aqm-eval-guidelines aligned with my interpretation of your
words. I believe Section 8.2.2 of
https://tools.ietf.org/html/draft-ietf-aqm-eval-guidelines-08 somewhat
implicitly covers that.

Cheers,
Naeem

On Tue, Oct 13, 2015 at 5:09 AM, Simon Barber <[email-masked]> wrote:

> I think it wold be good to add some discussion of this effect to the draft
> on evaluating AQM algorithms. In many access network scenarios the paths
> will be lightly loaded, and sometimes higher BDPs will be experienced. In
> these cases it's good to know that the AQM is not hurting your experience.
>
> Simon
>
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>
>