[PATCH net-next] tcp: Accept ECT on SYN in the presence of RFC8311

[PATCH net-next] tcp: Accept ECT on SYN in the presence of RFC8311

[Tilmans, Olivier (Nokia - BE/Antwerp)]

Linux currently disable ECN for incoming connections when the SYN
requests ECN and the IP header has ECT(0)/ECT(1) set, as some
networks were reportedly mangling the ToS byte, hence could later
trigger false congestion notifications.

RFC8311 §4.3 relaxes RFC3168's requirements such that ECT can be set
one TCP control packets (including SYNs). The main benefit of this
is the decreased probability of losing a SYN in a congested
ECN-capable network (i.e., it avoids the initial 1s timeout).
Additionally, this allows the development of newer TCP extensions,
such as AccECN.

This patch relaxes the previous check, by enabling ECN on incoming
connections using SYN+ECT if at least one bit of the reserved flags
of the TCP header is set. Such bit would indicate that the sender of
the SYN is using a newer TCP feature than what the host implements,
such as AccECN, and is thus implementing RFC8311. This enables
end-hosts not supporting such extensions to still negociate ECN, and
to have some of the benefits of using ECN on control packets.

Signed-off-by: Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com>
Suggested-by: Bob Briscoe <research@bobbriscoe.net>
Cc: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com>
---
 net/ipv4/tcp_input.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 5dfbc333e79a..6660ce2a7333 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -6263,6 +6263,11 @@ static inline void pr_drop_req(struct request_sock *req, __u16 port, int family)
  * congestion control: Linux DCTCP asserts ECT on all packets,
  * including SYN, which is most optimal solution; however,
  * others, such as FreeBSD do not.
+ *
+ * Exception: At least one of the reserved bits of the TCP header (th->res1) is
+ * set, indicating the use of a future TCP extension (such as AccECN). See
+ * RFC8311 §4.3 which updates RFC3168 to allow the development of such
+ * extensions.
  */
 static void tcp_ecn_create_request(struct request_sock *req,
 				   const struct sk_buff *skb,
@@ -6282,7 +6287,7 @@ static void tcp_ecn_create_request(struct request_sock *req,
 	ecn_ok_dst = dst_feature(dst, DST_FEATURE_ECN_MASK);
 	ecn_ok = net->ipv4.sysctl_tcp_ecn || ecn_ok_dst;
 
-	if ((!ect && ecn_ok) || tcp_ca_needs_ecn(listen_sk) ||
+	if (((!ect || th->res1) && ecn_ok) || tcp_ca_needs_ecn(listen_sk) ||
 	    (ecn_ok_dst & DST_FEATURE_ECN_CA) ||
 	    tcp_bpf_ca_needs_ecn((struct sock *)req))
 		inet_rsk(req)->ecn_ok = 1;
-- 
2.21.0

Re: [PATCH net-next] tcp: Accept ECT on SYN in the presence of RFC8311

[Eric Dumazet]

On Wed, Apr 3, 2019 at 6:49 AM Tilmans, Olivier (Nokia - BE/Antwerp)
<olivier.tilmans@nokia-bell-labs.com> wrote:
>
> Linux currently disable ECN for incoming connections when the SYN
> requests ECN and the IP header has ECT(0)/ECT(1) set, as some
> networks were reportedly mangling the ToS byte, hence could later
> trigger false congestion notifications.
>
> RFC8311 §4.3 relaxes RFC3168's requirements such that ECT can be set
> one TCP control packets (including SYNs). The main benefit of this
> is the decreased probability of losing a SYN in a congested
> ECN-capable network (i.e., it avoids the initial 1s timeout).
> Additionally, this allows the development of newer TCP extensions,
> such as AccECN.
>
> This patch relaxes the previous check, by enabling ECN on incoming
> connections using SYN+ECT if at least one bit of the reserved flags
> of the TCP header is set. Such bit would indicate that the sender of
> the SYN is using a newer TCP feature than what the host implements,
> such as AccECN, and is thus implementing RFC8311. This enables
> end-hosts not supporting such extensions to still negociate ECN, and

nit : negotiate

> to have some of the benefits of using ECN on control packets.
>
> Signed-off-by: Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com>
> Suggested-by: Bob Briscoe <research@bobbriscoe.net>
> Cc: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com>
> ---


LGTM,  thank you.

Signed-off-by: Eric Dumazet <edumazet@google.com>

Re: [PATCH net-next] tcp: Accept ECT on SYN in the presence of RFC8311

[Neal Cardwell]

On Wed, Apr 3, 2019 at 9:50 AM Tilmans, Olivier (Nokia - BE/Antwerp)
<olivier.tilmans@nokia-bell-labs.com> wrote:
>
> Linux currently disable ECN for incoming connections when the SYN
> requests ECN and the IP header has ECT(0)/ECT(1) set, as some
> networks were reportedly mangling the ToS byte, hence could later
> trigger false congestion notifications.
>
> RFC8311 §4.3 relaxes RFC3168's requirements such that ECT can be set
> one TCP control packets (including SYNs). The main benefit of this
> is the decreased probability of losing a SYN in a congested
> ECN-capable network (i.e., it avoids the initial 1s timeout).
> Additionally, this allows the development of newer TCP extensions,
> such as AccECN.
>
> This patch relaxes the previous check, by enabling ECN on incoming
> connections using SYN+ECT if at least one bit of the reserved flags
> of the TCP header is set. Such bit would indicate that the sender of
> the SYN is using a newer TCP feature than what the host implements,
> such as AccECN, and is thus implementing RFC8311. This enables
> end-hosts not supporting such extensions to still negociate ECN, and
> to have some of the benefits of using ECN on control packets.
>
> Signed-off-by: Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com>
> Suggested-by: Bob Briscoe <research@bobbriscoe.net>
> Cc: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com>

Acked-by: Neal Cardwell <ncardwell@google.com>

Thank you for this patch, Olivier and Bob.

thanks,
neal

Re: [PATCH net-next] tcp: Accept ECT on SYN in the presence of RFC8311

[Yuchung Cheng]

On Wed, Apr 3, 2019 at 8:39 AM Neal Cardwell <ncardwell@google.com> wrote:
>
> On Wed, Apr 3, 2019 at 9:50 AM Tilmans, Olivier (Nokia - BE/Antwerp)
> <olivier.tilmans@nokia-bell-labs.com> wrote:
> >
> > Linux currently disable ECN for incoming connections when the SYN
> > requests ECN and the IP header has ECT(0)/ECT(1) set, as some
> > networks were reportedly mangling the ToS byte, hence could later
> > trigger false congestion notifications.
> >
> > RFC8311 §4.3 relaxes RFC3168's requirements such that ECT can be set
> > one TCP control packets (including SYNs). The main benefit of this
> > is the decreased probability of losing a SYN in a congested
> > ECN-capable network (i.e., it avoids the initial 1s timeout).
> > Additionally, this allows the development of newer TCP extensions,
> > such as AccECN.
> >
> > This patch relaxes the previous check, by enabling ECN on incoming
> > connections using SYN+ECT if at least one bit of the reserved flags
> > of the TCP header is set. Such bit would indicate that the sender of
> > the SYN is using a newer TCP feature than what the host implements,
> > such as AccECN, and is thus implementing RFC8311. This enables
> > end-hosts not supporting such extensions to still negociate ECN, and
> > to have some of the benefits of using ECN on control packets.
> >
> > Signed-off-by: Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com>
> > Suggested-by: Bob Briscoe <research@bobbriscoe.net>
> > Cc: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com>
>
> Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>

>
> Thank you for this patch, Olivier and Bob.
>
> thanks,
> neal

Re: [PATCH net-next] tcp: Accept ECT on SYN in the presence of RFC8311

[David Miller]

From: "Tilmans, Olivier (Nokia - BE/Antwerp)" <olivier.tilmans@nokia-bell-labs.com>
Date: Wed, 3 Apr 2019 13:49:42 +0000

> Linux currently disable ECN for incoming connections when the SYN
> requests ECN and the IP header has ECT(0)/ECT(1) set, as some
> networks were reportedly mangling the ToS byte, hence could later
> trigger false congestion notifications.
> 
> RFC8311 §4.3 relaxes RFC3168's requirements such that ECT can be set
> one TCP control packets (including SYNs). The main benefit of this
> is the decreased probability of losing a SYN in a congested
> ECN-capable network (i.e., it avoids the initial 1s timeout).
> Additionally, this allows the development of newer TCP extensions,
> such as AccECN.
> 
> This patch relaxes the previous check, by enabling ECN on incoming
> connections using SYN+ECT if at least one bit of the reserved flags
> of the TCP header is set. Such bit would indicate that the sender of
> the SYN is using a newer TCP feature than what the host implements,
> such as AccECN, and is thus implementing RFC8311. This enables
> end-hosts not supporting such extensions to still negociate ECN, and
> to have some of the benefits of using ECN on control packets.
> 
> Signed-off-by: Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com>
> Suggested-by: Bob Briscoe <research@bobbriscoe.net>

Applied, thanks.