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

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

Hi,

Am 27.11.18 um 12:58 schrieb Luca Muscariello:
> A buffer in a router is sized once. RTT varies.
> So BDP varies. That’s as simple as that.
> So you just cannot be always at optimum because you don’t know what RTT
> you have at any time.

The endpoints can measure the RTT. Yes, it's probably a bit noisy and
there are several practical problems such as congestion on the reverse
path and multiple bottlenecks, but in general it's not impossible.

> Lola si not solving that. No protocol could BTW.

LoLa is exactly solving that. It measures RTTmin and effective RTT
(and there are lots of other delay-based CC proposals doing that)
and tries to control the overall queuing delay, even achieving
RTT-independent flow rate fairness.

> BTW I don’t see  any formal proof about queue occupancy in the paper.

It's not in the LoLa paper, it was in a different paper, but reviewers
thought it was already common knowledge.

Regards,
 Roland

> On Tue 27 Nov 2018 at 12:53, Bless, Roland (TM) <roland.bless@kit.edu
> <mailto:roland.bless@kit.edu>> wrote:
> 
>     Hi Luca,
> 
>     Am 27.11.18 um 12:01 schrieb Luca Muscariello:
>     > A BDP is not a large buffer. I'm not unveiling a secret.
> 
>     That depends on speed and RTT (note that typically there are
>     several flows with different RTTs sharing the same buffer).
>     The essential point is not how much buffer capacity is available,
>     but how much is actually used, because that adds queueing delay.
> 
>     > And it is just a rule of thumb to have an idea at which working point
>     > the protocol is working.
> 
>     No, one can actually prove that this is the best size for
>     loss-based CC with backoff factor of 0.5 (assuming a single flow).
> 
>     > In practice the protocol is usually working below or above that value.
> 
>     That depends on the protocol.
> 
>     > This is where AQM and ECN help also. So most of the time the
>     protocol is
>     > working at way 
>     > below 100% efficiency.
> 
>     > My point was that FQ_codel helps to get very close to the optimum w/o
>     > adding useless queueing and latency.
>     > With a single queue that's almost impossible. No, sorry. Just
>     impossible.
> 
>     No, it's possible. Please read the TCP LoLa paper.
> 
>     Regards,
>      Roland
>