> -----Original Message----- > From: Paolo Abeni <[email protected]> > Sent: Thursday, November 6, 2025 1:07 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 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, [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]> > > --- > > 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
