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

[Keyur Patel <[e-mail]>]

Comments inlined #Keyur

On 12/15/20, 4:15 PM, "john heasley" <[e-mail]> wrote:

    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?

#Keyur: Or a normal route-refresh as well.

    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.

#Keyur: Please note that the problem here is mostly a slow/faulty receiver. Any session reset is less likely to solve issues unless the receiving side processing related issues are solved first. 

    could an implementation more tightly coupled to its tcp use the urgent
    pointer to test liveliness?