Re: [PATCH 2/2] tcp: Resend SYN for inbound connections

[Stefano Brivio <sbrivio@redhat.com>]

On Mon, 29 Sep 2025 16:25:39 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Sun, Sep 28, 2025 at 03:29:46PM +0800, Yumei Huang wrote:
> > If a client connects while guest is not connected or ready yet,
> > resend SYN instead of just resetting connection after SYN_TIMEOUT.
> > 
> > Signed-off-by: Yumei Huang <yuhuang@redhat.com>  
> 
> Simpler than I thought.  Nice.
> 
> However, I think now that we're retrying we probably want to adjust
> SYN_TIMEOUT.  I suspect the 10s was a generous amount to mitigate the
> fact we didn't retry.

That was the idea, yes.

> However, AFAICT most OSes resend SYNs faster than that (after 1-3s
> initially).

Right. Remember all the examples from Linux with one-second retries
I wanted to show? :)

> They also typically slow down the
> resents on subsequent retries.  I'm not sure if that last is important
> in our case - since we're talking directly to a guest, we're unlikely
> to flood the link this way.

Exponential back-off (or whatever is used by other implementations)
doesn't only serve the purpose of avoiding to flood the link. It's also
about functionality itself.

That is, if you waited one second, and you didn't get any reply, that's
a good indication that you might not get a reply in one second from
now, because the peer might need a little bit longer.

> In fact, I haven't read closely enough to be sure, but there was some
> language in RFC 6298 and RFC 1122 that suggested to me maybe we should
> be using the same backoff calculation for SYN retries as for regular
> retransmits.  Which as a bonus might simplify our logic a little bit.

Somewhat surprisingly, RFC 9293 doesn't say anything about this. :(

And while I'm fairly sure that RFC 2988 was intended to only cover
*data* retransmissions, RFC 6298 (which updates it) seems to simply
assume, in section 5., that it's also about SYN segments:

   (5.7) If the timer expires awaiting the ACK of a SYN segment and the
         TCP implementation is using an RTO less than 3 seconds, the RTO
         MUST be re-initialized to 3 seconds when data transmission
         begins (i.e., after the three-way handshake completes).

so, yes, I tend to agree with this. Let's just use the same logic.

Just note that it's an approximation of RFC 6298, in any case, because
we don't implement RTT measurements.

It's a rather complicated implementation that I originally decided to
skip because there's no actual data transmission between us and
guest/container, so there isn't much that can go wrong. Maybe we could
even assume that the RTT is zero.

As a result of that, we can't implement RFC 2988 / RFC 6298 exactly as
it is. But we can get quite close to it.

> Documentation/networking/ip-sysctl.rst

...in the unlikely case it's not clear: David means a Linux kernel tree
here. Yumei, it might be a good idea to have a kernel tree (maybe
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git) at
hand to check this kind of stuff.

> has some information on how
> Linux handles this (tcp_syn_retries and tcp_syn_linear_timeouts in
> particular).  I guess we could configure ourselves to match the host's
> settings - we do something similar to determine what we consider
> ephemeral ports.
> 
> Stefano, thoughts?

Yes, I think reading those values from the host makes sense because the
same thing that would happen if the host connects to the guest or
container with another implementation (veth, or tap).

It's also the least surprising behaviour for any kind of application
that was previously running outside guest or containers and now it's
moved there.

We have just 3 bits here, so we can only try 9 times (retry 8 times),
but other than that we can use tcp_syn_retries and
tcp_syn_linear_timeouts as they are.

Summing up, I would propose that we do something like this:

1. (optional, and might be in another series, but keeping it together
   with the rest might be more convenient): read tcp_syn_retries, limit
   to 8, and also read tcp_syn_linear_timeouts

2. always use one second as initial RTO (retransmission timeout). That's
   what the kernel does (even though rto_initial should be 3 seconds by
   default...? I'm not sure)

3. for SYN, implement the tcp_syn_linear_timeouts thing. That is,
   in tcp_timer_ctl(), use this timeout:

	if (conn->retries < c->tcp_ctx.syn_linear_timeouts)
		[one second]
	else
		[1 << conn->retries]

4. do the same for data retransmissions, but without the
   tcp_syn_linear_timeouts thing, start from one second (see Appendix A
   in RFC 6298)... and maybe limit it to 60 seconds as allowed by the
   same RFC:

   (2.5) A maximum value MAY be placed on RTO provided it is at least 60
         seconds.

   ? Retransmitting data after 256 seconds doesn't make a lot of sense
   to me.

It shouldn't be much more complicated than the current patch, it just
involves some extra changes in tcp_timer_ctl(), I guess.

-- 
Stefano