Re: [PATCH net-next] tcp: avoid negotitating ECN for BBR

On Fri, Jan 19, 2018 at 11:31 AM, David Miller [off-list ref] wrote:

From: Yuchung Cheng <redacted>
Date: Tue, 16 Jan 2018 17:57:26 -0800

quoted

This patch keeps BBR from negotiating ECN if sysctl ECN is
set. Prior to this patch, BBR negotiates ECN if enabled, sends
CWR upon receiving ECE ACKs but does not react to them. This can
cause confusion from the protocol perspective. Therefore this
patch prevents the connection from negotiating ECN if BBR is the
congestion control during the handshake.

Note that after the handshake, the user can still switch to a
different congestion control that supports or even requires ECN
(e.g. DCTCP).  In that case, the connection can not re-negotiate
ECN and has to go with the ECN-free mode in that congestion control.

There are other cases BBR would still respond to ECE ACKs with CWR
but does not react to it like the behavior before this patch. First,
when the user switches to BBR congestion control but the connection
has already negotiated ECN before. Second, the system has configured
the ip route and/or uses eBPF to enable ECN on the connection that
uses BBR congestion control.

Signed-off-by: Yuchung Cheng <redacted>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yousuk Seung <redacted>
Acked-by: Eric Dumazet <edumazet@google.com>

Well, this is a bit disappointing.  I'm having trouble justifying
applying this.

Why doesn't BBR react to ECN notifications?  Is it because BBR's
idea of congestion differs from the one ECN is likely indicating?

This is really unfortunate, because if BBR does become quite prominent
(that's what you want right? :-) then what little success there has
been deploying working ECN will be for almost nothing, and there
will be little incentive for further ECN deployment.

And the weird behavior you list in your last paragraph, about how if
the user switches to BBR then ECN will be active, is just a red flag
that shows perhaps this is a bad idea overall.

ECN behavior should not be so tightly bound to the congestion control
algorithm like this, it's a connection property independant of
congestion control algorithm.

I'm not applying this for now, sorry.  Maybe if you significantly
enhance the commit message and try to do something sane with the
algorithm switching case it is work a respin.

Thank you for your feedback. We have not yet find a good approach to
react to the standard ECN (RFC3168) coarse early loss model. The
new proposal of Accurate ECN may provide better and compatible
signals to BBR, which we're still exploring in an early stage.

Your feedback on the weird behavior makes sense. We'll respin the
patch to (hopefully) address that instead of bluntly not negotiating
ECN.

Thanks.