Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

["Bless, Roland (TM)" <roland.bless@kit.edu>]

Hi Michael,

Am 27.11.18 um 12:04 schrieb Michael Welzl:
> I'm lost in this conversation: I thought it started with a statement saying that the queue length must be at least a BDP such that full utilization is attained because the queue never drains.

I think it helps to distinguish between bottleneck buffer size (i.e.,
its capacity) and bottleneck buffer occupancy (i.e., queue length).
My point was that full bottleneck utilization doesn't require any buffer
occupancy at all. I think one should also distinguish precisely between
different viewpoints: at the sender or at the bottleneck (aggregate of
many flows from different sources with different RTTs).

> To this, I'd want to add that, in addition to the links from Roland, the point of ABE is to address exactly that: https://tools.ietf.org/html/draft-ietf-tcpm-alternativebackoff-ecn-12
> (in the RFC Editor queue)

Yep, because then the backoff is less drastic so the utilization is kept
at a higher level even if the queue is much smaller than a BDP (that is
concluded from the fact that when ECN is present an AQM will try to keep
the queue much smaller). Our complementary approach was the AQM Steering
approach that let's the AQM adapt.

> But now I think you're discussing a BDP worth of data *in flight*, which is something else.

Yes, maybe because I think it was confused, but it's anyhow related:
having a BDP in flight will allow you fully utilize the link capacity,
having BDP+x in flight will lead to having x queued up in the bottleneck
buffer. So having 2BDP inflight will lead to 1 BDP on the wire and 1 BDP
in the buffer. That's what loss based CC variants usually have and what
BBRv1 set as limit.

Regards,
 Roland