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 Sebastian,

On 26.02.21 at 18:14 Sebastian Moeller wrote:
> are you sure that BBRv2 actually evaluates CE marks and responds to them? As far as I understood, BBR is simply not rfc3168 compliant, there was some talk about teaching BBRv2+ some still to be defined high frequency (low amplitude) ECN signaling.
AFAIK, BBRv2 reacts not in an RFC3168 compliant (classic) manner, but 
more in a DCTCP style manner.
> The thing I fail to understand is, why BBR with its cavalier approach to drops did not grow ECN support on day one. While a drop could have a lot of reasons, including transient/stray wifi losses, a CE mark is less ambiguous.
Yes, it is. But as I understand the motivation for BBR's design,
they do not want to sacrifice throughput in case of non-congestion losses.
If you read the original BBR paper, one of its motivations was its use 
in B4,
where Google operates shallow-buffered switches. Because of their small 
buffer size,
they will cause occasional packet losses due to occurring short-term 
traffic
aggregation effects, which are different from persistent congestion.

A traditional RED-based AQM may also generate CE marks in this
case and the "strong" backoff may cost too much utilization in the end
(esp. if you consider 100+Gbit/s links), so the DCTCP style is much more
scalable in this respect.

Regards,
  Roland

>> On Feb 26, 2021, at 17:59, Bless, Roland (TM) <roland.bless@kit.edu> wrote:
>>
>> 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
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat