netdev - Re: [PATCH v9 net-next 09/15] tcp: accecn: retransmit SYN/ACK without AccECN option or non-AccECN SYN/ACK

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: <CANn89iJPE=rCExzfFw-eKe5PiukTnmUogaLJSXgo6JfDeZiezQ@mail.gmail.com>
Date: Tue, 20 Jan 2026 11:40:48 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: chia-yu.chang@...ia-bell-labs.com
Cc: pabeni@...hat.com, parav@...dia.com, linux-doc@...r.kernel.org, 
	corbet@....net, horms@...nel.org, dsahern@...nel.org, kuniyu@...gle.com, 
	bpf@...r.kernel.org, netdev@...r.kernel.org, dave.taht@...il.com, 
	jhs@...atatu.com, kuba@...nel.org, stephen@...workplumber.org, 
	xiyou.wangcong@...il.com, jiri@...nulli.us, davem@...emloft.net, 
	andrew+netdev@...n.ch, donald.hunter@...il.com, ast@...erby.net, 
	liuhangbin@...il.com, shuah@...nel.org, linux-kselftest@...r.kernel.org, 
	ij@...nel.org, ncardwell@...gle.com, koen.de_schepper@...ia-bell-labs.com, 
	g.white@...lelabs.com, ingemar.s.johansson@...csson.com, 
	mirja.kuehlewind@...csson.com, cheshire@...le.com, rs.ietf@....at, 
	Jason_Livingood@...cast.com, vidhi_goel@...le.com
Subject: Re: [PATCH v9 net-next 09/15] tcp: accecn: retransmit SYN/ACK without
 AccECN option or non-AccECN SYN/ACK

On Mon, Jan 19, 2026 at 7:59 PM <chia-yu.chang@...ia-bell-labs.com> wrote:
>
> From: Chia-Yu Chang <chia-yu.chang@...ia-bell-labs.com>
>
> For Accurate ECN, the first SYN/ACK sent by the TCP server shall set the
> ACE flag (see Table 1 of RFC9768) and the AccECN option to complete the
> capability negotiation. However, if the TCP server needs to retransmit such
> a SYN/ACK (for example, because it did not receive an ACK acknowledging its
> SYN/ACK, or received a second SYN requesting AccECN support), the TCP server
> retransmits the SYN/ACK without the AccECN option. This is because the
> SYN/ACK may be lost due to congestion, or a middlebox may block the AccECN
> option. Furthermore, if this retransmission also times out, to expedite
> connection establishment, the TCP server should retransmit the SYN/ACK with
> (AE,CWR,ECE) = (0,0,0) and without the AccECN option, while maintaining
> AccECN feedback mode.
>

Reviewed-by: Eric Dumazet <edumazet@...gle.com>