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

[john heasley <[e-mail]>]

Sat, Dec 12, 2020 at 03:29:02AM +0000, Jakob Heitz (jheitz):
> Good point Keyur.
> A receiver may be overwhelmed for a long time and not open its TCP window to avoid
> silly window syndrome or some other reason. The receiver may still be functional
> and able to clear its backlog, albeit in a long time. Resetting such a session
> will only make the situation worse. Telling the difference between this case
> and a receiver stuck in a bug is difficult.

It seems that closing after HOLDTIME would be fragile at boot-time of the
receiver or recovery of an IxP interface, when there is high demand -
which I think is keyur's comment.  Maybe this should not be enforced until
an EoR marker, allowing a receiver to retard new, GR, or RtRefresh peers?

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?