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

[John Scudder <[e-mail]>]

On Dec 18, 2020, at 1:09 PM, Enke Chen <[e-mail]> 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