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

[Brian Dickson <[e-mail]>]

On Thu, Dec 17, 2020 at 11:49 AM Enke Chen <[e-mail]>
wrote:

> Hi, Robert:
>
> The receiver is broken for not closing the session after the holdtime
> expires, and that certainly needs attention.
>
> However, the rational for trying to do something on the sender seems to be
> the following: as the session is broken and should have been terminated by
> the other side, but it's not, the sender would like to have a way that
> provides an "upper bound" for the session to be terminated
> deterministically at the transport layer.
>
> The TCP_USER_TIMEOUT option seems to be a good fit in this case.
>

I think this thread is suffering from "impedance mismatch".

There is a known issue where the actual TCP stacks of some routers are
buggy in ways that breaks things.

This proposal (TCP_USER_TIMEOUT) assumes that the local speakers' TCP stack
isn't buggy, at least with regards to the handling of that option.

I'm not opposed to using that option, but I don't think relying on that
exclusively is sufficient.

There is a layer issue, involving BGP protocol and TCP transport, where
transport and/or protocol issues (or both) are causing (or at least have
caused) global problems.

Having the BGP implementation be cognizant of the state of the TCP
connections, and handle behavior violations or boundary condition problems
expeditiously, is probably a good idea.

(The common term is "belt and suspenders", or perhaps "trust but verify".)

I.e. if the session is "broken", use all the available mechanisms in
increasing order of effectiveness (or extreme-ness) until the connection
dies, possibly with some grace periods in the escalation steps.

Brian