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

[John Heasley <[e-mail]>]

Tue, Dec 15, 2020 at 04:43:31PM -0800, Tony Li:
> > On Dec 15, 2020, at 4:15 PM, john heasley <[e-mail]> wrote:
> > 
> > Could a sender test the liveliness of a peer by attempting to open a
> > new session?  would a successful 3-way and commencement of BGP OPEN be
> > an indication that it should be more patient, increase its "deadtimer"
> > (HOLDTIME < STUCKTIME < PATHETICTIME)?  Clearly the remote has been
> > sending bgp keepalives, so perhaps not for all implementations.
> > 
> > could an implementation more tightly coupled to its tcp use the urgent
> > pointer to test liveliness?
> 
> 
> Hi Heas,
> 
> In modern implementations that are multi-threaded or multi-process, the ability to open 
> a new connection only demonstrates liveness of the destination stack. The upper
> level thread may not be alive, either due to protocol implementation issues or
> OS issues.
> 
> Tony

Hey tli,
That is why I added "commencement of the BGP OPEN," but I suppose a
threaded implementation could use separate threads for various
operations, not just i/o vs other ops.

rfc721 is another thought, but rfc7805 likely kills that and Stevens IIRC
suggested the implementation was varied - some might separate it from the
normal send/recv buffers (ie: win=0 is irrelevant) and some might not
provide a way to retrieve the data in parrallel.  I haven't tinkered with
it since ~1989 on Encore Umax.