-----Original Message----- From: Paolo Abeni pabeni@redhat.com Sent: Thursday, October 16, 2025 11:14 AM To: Chia-Yu Chang (Nokia) chia-yu.chang@nokia-bell-labs.com; edumazet@google.com; linux-doc@vger.kernel.org; corbet@lwn.net; horms@kernel.org; dsahern@kernel.org; kuniyu@amazon.com; bpf@vger.kernel.org; netdev@vger.kernel.org; dave.taht@gmail.com; jhs@mojatatu.com; kuba@kernel.org; stephen@networkplumber.org; xiyou.wangcong@gmail.com; jiri@resnulli.us; davem@davemloft.net; andrew+netdev@lunn.ch; donald.hunter@gmail.com; ast@fiberby.net; liuhangbin@gmail.com; shuah@kernel.org; linux-kselftest@vger.kernel.org; ij@kernel.org; ncardwell@google.com; Koen De Schepper (Nokia) koen.de_schepper@nokia-bell-labs.com; g.white@cablelabs.com; ingemar.s.johansson@ericsson.com; mirja.kuehlewind@ericsson.com; cheshire cheshire@apple.com; rs.ietf@gmx.at; Jason_Livingood@comcast.com; Vidhi Goel vidhi_goel@apple.com Subject: Re: [PATCH v4 net-next 08/13] tcp: accecn: retransmit SYN/ACK without AccECN option or non-AccECN SYN/ACK
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
On 10/13/25 7:03 PM, chia-yu.chang@nokia-bell-labs.com wrote:
From: Chia-Yu Chang chia-yu.chang@nokia-bell-labs.com
If the TCP Server has not received an ACK to acknowledge its SYN/ACK after the normal TCP timeout or it receives a second SYN with a request for AccECN support, then either the SYN/ACK might just have been lost, e.g. due to congestion, or a middlebox might be blocking AccECN Options. To expedite connection setup in deployment scenarios where AccECN path traversal might be problematic, the TCP Server SHOULD retransmit the SYN/ACK, but with no AccECN Option.
If this retransmission times out, to expedite connection setup, the TCP Server SHOULD retransmit the SYN/ACK with (AE,CWR,ECE) = (0,0,0) and no AccECN Option, but it remains in AccECN feedback mode.
This follows Section 3.2.3.2.2 of AccECN spec (RFC9768).
Signed-off-by: Chia-Yu Chang chia-yu.chang@nokia-bell-labs.com
include/net/tcp_ecn.h | 14 ++++++++++---- net/ipv4/tcp_output.c | 2 +- 2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/net/tcp_ecn.h b/include/net/tcp_ecn.h index c66f0d944e1c..97a3a7f36aff 100644 --- a/include/net/tcp_ecn.h +++ b/include/net/tcp_ecn.h @@ -651,10 +651,16 @@ static inline void tcp_ecn_clear_syn(struct sock *sk, struct sk_buff *skb) static inline void tcp_ecn_make_synack(const struct request_sock *req, struct tcphdr *th) {
if (tcp_rsk(req)->accecn_ok)tcp_accecn_echo_syn_ect(th, tcp_rsk(req)->syn_ect_rcv);else if (inet_rsk(req)->ecn_ok)th->ece = 1;
if (req->num_retrans < 1 || req->num_timeout < 1) {I think the above condition does not match the commit message. Should be: if (!req->num_retrans && !req->num_timeout) {
/P
Hi Paolo,
This patch includes two differetn SYN/ACK retransmissions: In the first retransmited SYN/ACK, the retransmitted SYN/ACK will not include AccECN option. This uses the condition of "req->num_retrans >1" in tcp_synack_options().
In the second retransmitted SYN/ACK, the retransmitted SYN/ACK will further set ACE=0. This uses the condition of "req->num_retrans>1 && req->num_timeout>1" in tcp_ecn_make_synack().
I was thinking, in the next version, I could update the commit message to clarify it.
Chia-Yu