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

[Gyan Mishra <[e-mail]>]

Here is the RFC 5482 TCP User timeout options from TCPM WG.

https://tools.ietf.org/html/rfc5482

TCPM has a bis draft update to 793 that has more info then the original.

https://datatracker.ietf.org/wg/tcpm/documents/

https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-19#page-42


>From quick read there are caveats with devices supporting or not supporting
the option.

Also I guess setting the value is tricky as well not too low or too high
that either could make matters worse with instability.

Going down this path of does seem a lot more complicated and risker then
using BFD.


Kind Regards

Gyan


On Sat, Dec 19, 2020 at 5:38 AM William McCall <[e-mail]>
wrote:

> On Fri, Dec 18, 2020 at 10:33 PM John Scudder
> <jgs=[e-mail]> wrote:
> >
> > 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
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > 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
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD