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.bl...@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
bl...@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
