Re: [Make-wifi-fast] [Bloat] [Cake] Fwd: [Galene] Dave on bufferbloat and jitter at 8pm CET Tuesday 23

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

Hi,

On 26.02.21 at 16:27 Nils Andreas Svee wrote:
> On 2/26/21 12:47 PM, Toke Høiland-Jørgensen wrote:
> 
>> Yeah, there would have to be some kind of probing to discover when the
>> bandwidth goes up (maybe something like what BBR does?). Working out the
>> details of this is still in the future, this is all just loose plans
>> that I'll try to get back to once we have the measurement tool working
>> reasonably well. Input and experiments welcome, of course!
> 
> I've kept to maintaining CAKE binaries for the EdgeRouters, so I have a 
> lot to read up on if I'm gonna take a stab at this, should be fun though :)
> 
> I'll have a look at how BBR does it, and see if I can't figure out how 
> that works at least.
BBR increases its sending rate and looks whether the delivery rate
increases. It assumes that the bottleneck limit hasn't been reached
in case the delivery rate still increases. This is certainly true when
it is the only flow at the bottleneck, but not true when multiple
flows are present (the probing flow may simply steal other flows'
shares adn thus get a higher delivery rate nevertheless).
BBRv2 at least checks for packet loss and ECN
signals and detects when it hits a hard limit. One could try to
detect a correlated increase in RTT when probing for more bandwidth
and then stop, because it seems that the queue is filled by the
increased probing rate. However, getting that reliably detected out of
the RTT measurement noise is sometimes difficult.

Regards,
  Roland