[Ecn-sane] BBRv3 ecn_low per-route feature and the CE confusion

[Pete Heist]

Regarding the per-route ecn_low feature in BBRv3:
https://github.com/google/bbr/blob/v3/README.md#introducing-the-ecn_low-per-route-feature

When set, any incoming CE marks from an ecn_low flagged route will be
treated as an L4S/RFC9331 CE, while CE marks from routes without that
flag will be treated as a regular RFC3168 CE. Obviously this is
problematic, as the two CE marks mean very different things, and
outside of closed environments, there's no reliable way to know which
type of CE you're receiving. The consequences of confusing them range
from massive self-induced bloat, to driving competing traffic in the
same queue down to minimum cwnd. The solution here is to just punt, so
at least tests and demos can be made to work.

This isn't a problem with BBR. The problem is, we've started an
experiment [RFC9331] that redefines the meaning of CE in a way that's
incompatible with existing RFC3168 middleboxes. This feature in BBR is
just a reflection of that. CCA developers are now tasked with somehow
deciding which type of CE they're seeing.

Speaking of ecn "sane", does anyone else see this as not? :) and as a
problem that needs solving?

Pete

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20231128/2a33286e/attachment-0001.sig>