Discussion of explicit congestion notification's impact on the Internet
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Pete Heist <pete@heistp.net>
Cc: ECN-Sane <ecn-sane@lists.bufferbloat.net>
Subject: Re: [Ecn-sane] BBRv3 ecn_low per-route feature and the CE confusion
Date: Tue, 28 Nov 2023 16:21:21 +0100	[thread overview]
Message-ID: <35C94031-C0B0-428B-822B-68AC0AB4A540@gmx.de> (raw)
In-Reply-To: <d97399e7a486fac11c2c750d58017ebba8b37738.camel@heistp.net>

Hi Pete,


> On Nov 28, 2023, at 13:57, Pete Heist via Ecn-sane <ecn-sane@lists.bufferbloat.net> wrote:
> 
> 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.

	I am probably blind, but looking at https://github.com/google/bbr/blob/v3/net/ipv4/tcp_bbr.c
I do not see this fall back to a rfc3168 compliant response, as far as I read this this is DCTCP or nothing... 
Or did you just mean that BBRv3 will treat CE just like BBRv1 and silently ignore it?



> 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.

	The per-route feature looks like a desirable safety... as does the default 5ms rtt "low-pass", where IIUC ECN will only be evaluated if the RTT is below 5ms...


> 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?

	Yes, however I assume this will solve it self, as is this usage of CE is over-promising and under-delivering, so I do not see this "winning the internet" in spite of the amount of thrust is put behind it...

Regards
	Sebastian


> 
> Pete
> 
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane


  parent reply	other threads:[~2023-11-28 15:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-28 12:57 Pete Heist
2023-11-28 14:03 ` Jonathan Morton
2023-11-28 15:21 ` Sebastian Moeller [this message]
2023-11-28 16:28   ` Pete Heist

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/ecn-sane.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=35C94031-C0B0-428B-822B-68AC0AB4A540@gmx.de \
    --to=moeller0@gmx.de \
    --cc=ecn-sane@lists.bufferbloat.net \
    --cc=pete@heistp.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox