> -----Original Message----- > From: Paolo Abeni <[email protected]> > Sent: Tuesday, November 18, 2025 2:59 PM > To: Chia-Yu Chang (Nokia) <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; Koen De Schepper (Nokia) > <[email protected]>; [email protected]; > [email protected]; [email protected]; cheshire > <[email protected]>; [email protected]; [email protected]; Vidhi Goel > <[email protected]> > 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, [email protected] wrote: > > From: Chia-Yu Chang <[email protected]> > > > > 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 <[email protected]> > > > > --- > > 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 > > > + 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
