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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 22 Jan 2018 17:33:54 -0800
From:   Yuchung Cheng <ycheng@...gle.com>
To:     David Miller <davem@...emloft.net>
Cc:     netdev <netdev@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Yousuk Seung <ysseung@...gle.com>,
        Neal Cardwell <ncardwell@...gle.com>
Subject: Re: [PATCH net-next] tcp: avoid negotitating ECN for BBR

On Fri, Jan 19, 2018 at 11:31 AM, David Miller <davem@...emloft.net> wrote:
>
> 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.
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.