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

Hi Gyan,

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

But BFD is not going to help at all to the problem at hand.

BFD is in the vast majority of cases distributed (and that is feature not a
bug) and responses are handled by line cards.

Here we are dealing with RE/RP based subsystems bugs regardless if those
are in TCP or BGP layer.

Thx,
R.

On Sat, Dec 19, 2020 at 10:36 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> 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 <william.mccall@gmail.com>
> wrote:
>
>> 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
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> 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
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>