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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20180119.143148.953873341015988293.davem@davemloft.net>
Date:   Fri, 19 Jan 2018 14:31:48 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     ycheng@...gle.com
Cc:     netdev@...r.kernel.org, edumazet@...gle.com, ysseung@...gle.com,
        ncardwell@...gle.com
Subject: Re: [PATCH net-next] tcp: avoid negotitating ECN for BBR

From: Yuchung Cheng <ycheng@...gle.com>
Date: Tue, 16 Jan 2018 17:57:26 -0800

> 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 <ycheng@...gle.com>
> Signed-off-by: Neal Cardwell <ncardwell@...gle.com>
> Acked-by: Yousuk Seung <ysseung@...gle.com>
> Acked-by: Eric Dumazet <edumazet@...gle.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.

Thanks.