-----Original Message-----
From: Paolo Abeni <pabeni@redhat.com> 
Sent: Tuesday, November 18, 2025 2:59 PM
To: Chia-Yu Chang (Nokia) <redacted>; 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) <redacted>; g.white@cablelabs.com; ingemar.s.johansson@ericsson.com; mirja.kuehlewind@ericsson.com; cheshire <redacted>; rs.ietf@gmx.at; Jason_Livingood@comcast.com; Vidhi Goel <redacted>
Subject: Re: [PATCH v6 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 11/14/25 8:13 AM, chia-yu.chang@nokia-bell-labs.com wrote:

quoted

From: Chia-Yu Chang <redacted>

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 <redacted>

---
v6:
- Use new synack_type TCP_SYNACK_RETRANS and num_retrans.
---
 include/net/tcp_ecn.h | 20 ++++++++++++++------  
net/ipv4/tcp_output.c |  4 ++--
 2 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/include/net/tcp_ecn.h b/include/net/tcp_ecn.h index 

a709fb1756eb..57841dfa6705 100644

--- a/include/net/tcp_ecn.h
+++ b/include/net/tcp_ecn.h

@@ -649,12 +649,20 @@ 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;
+tcp_ecn_make_synack(const struct request_sock *req, struct tcphdr *th,
+                 enum tcp_synack_type synack_type) {
+     // num_retrans will be incresaed after tcp_ecn_make_synack()

Please use /* */ for comments

quoted

+     if (!req->num_retrans) {

It's unclear you this function receives a `synack_type` argument and don't use it. Should the above be

        if (synack_type != TCP_SYNACK_RETRANS) {

?

Or just remove such argument.

/P

Hi Paolo,

You are right, and I will use both "synack_type != TCP_SYNACK_RETRANS" || "!req->num_retrans".

Because this ACE field fallback will only happen from the 2nd retansmitted SYN/ACK.

Chia-Yu