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

[Yumei Huang <yuhuang@redhat.com>]

Thank you both for the comments!

On Tue, Sep 30, 2025 at 9:06 AM David Gibson
<david@gibson.dropbear.id.au> wrote:
>
> On Tue, Sep 30, 2025 at 12:23:35AM +0200, Stefano Brivio wrote:
> > 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. :(
>
> Right, it discusses RTO, and never explicitly talks about SYN resends,
> kind of implying that SYN resends should use the same RTO calculations
> as data retransmits.
>
> > 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.

I found this through Google,
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.rst.
Having a repo at hand would be great too!

> >
> > > 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).
>
> I think taking tcp_syn_retries from the host makes sense.  I'm a bit
> less sure about tcp_syn_linear_timeouts, since that requires
> implementing the more complex and specific linear backoff behaviour.
>
> > 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.
>
> Well, probably the least surprising we can achieve.  It's not possible
> for us to match the peer's SYN retry behaviour if it's not Linux or
> has different settings to the host.
>
> > 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]
>
> 1 << conn->retries, or 1 << (conn->retries - syn_linear_timeouts) ?

I think it should be the latter.

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

I'm afraid I won't be able to finish it today. Will work on this after
I come back from holiday.

> >
> > --
> > Stefano
> >
>
> --
> David Gibson (he or they)       | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au  | minimalist, thank you, not the other way
>                                 | around.
> http://www.ozlabs.org/~dgibson


-- 
Thanks,

Yumei Huang