-----Original Message----- From: Paolo Abeni pabeni@redhat.com Sent: Thursday, November 6, 2025 1:07 PM To: Chia-Yu Chang (Nokia) chia-yu.chang@nokia-bell-labs.com; edumazet@google.com; parav@nvidia.com; linux-doc@vger.kernel.org; corbet@lwn.net; horms@kernel.org; dsahern@kernel.org; kuniyu@google.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 v5 net-next 10/14] 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/30/25 3:34 PM, chia-yu.chang@nokia-bell-labs.com wrote:
From: Chia-Yu Chang chia-yu.chang@nokia-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.
This complies with Section 3.2.3.2.2 of the AccECN specification (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..99d095ed01b3 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 || !req->num_timeout) {Why `if (!req->num_timeout)` is not a sufficient condition here?
Simplifying the above condition will make the TCP_SYNACK_RETRANS alternative simpler, I think.
/P
Hi Paolo,
AFAIK, req->num_timeout will be increased after tcp_rtx_synack() is done due to timeout, abut it does not cover the case when 2nd SYN is received.
But so far the AccECN spec requests to do the same fallback in both cases (i.e., either timeout or receive 2nd SYN).
So, here I would still think to use either num_retrans (or like you suggested to use different SYN_ACK types?)
Chia-Yu