Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

On Fri, Dec 18, 2020 at 10:33 PM John Scudder
<jgs=40juniper.net@dmarc.ietf.org> wrote:
>
> On Dec 18, 2020, at 1:09 PM, Enke Chen <enchen@paloaltonetworks.com> wrote:
> >
> > No, I am not assuming that packets are getting somewhere. The TCP_USER_TIMEOUT would work as long as there is "pending data" (either unacked, or locally queued). The data can be from the local BGP Keepalives or the TCP_KEEPALIVE.
>
> Apart from the other objections to relying on TCP_USER_TIMEOUT, which I think are sufficient, it’s not clear to me that implementations will provide the desired semantics. RFC 793 seems like it specifies the right semantics (“get this data to the peer within N seconds or close”):
>
>         The timeout, if present, permits the caller to set up a timeout
>         for all data submitted to TCP.  If data is not successfully
>         delivered to the destination within the timeout period, the TCP
>         will abort the connection.  The present global default is five
>         minutes.
>
> However the Linux man page documents different semantics:
>
>        TCP_USER_TIMEOUT (since Linux 2.6.37)
>               This option takes an unsigned int as an argument.  When the
>               value is greater than 0, it specifies the maximum amount of
>               time in milliseconds that transmitted data may remain
>               unacknowledged before TCP will forcibly close the
>               corresponding connection and return ETIMEDOUT to the
>               application.  If the option value is specified as 0, TCP will
>               use the system default.
>
> The important difference being that whereas 793 implies data written to the socket, the Linux man page says “transmitted” data, which seems like it must mean data TCP has written to the network. These are two very different things! If Linux (or another stack) implements what the man page seems to say, it’s not useful for our purposes.
>
> —John
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

I was curious too. I read the manpage, relevant linux kernel code, the
RFC, and hacked up a test case (unicast me if you want the code).
Also, Cloudflare published a relevant blog entry[0]. For this specific
scenario, see under the sub-heading "Zero window ESTAB is...
forever?".

TCP_USER_TIMEOUT doesn't appear to kick in until there is unACKed
data, meaning that it has already been transmitted from TCP's
perspective. Stuff hanging around in the buffers due to persist state
doesn't seem to count, per the test results and the docs. Confirms
your thoughts from the reading I think.

[0] https://blog.cloudflare.com/when-tcp-sockets-refuse-to-die/

--
William McCall