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

[William McCall <[e-mail]>]

On Sat, Dec 12, 2020 at 3:29 AM Jakob Heitz (jheitz)
<jheitz=[e-mail]> wrote:
>
> 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.
>
> Regards,
> Jakob.

Byzantine Generals again.

We ran into this problem recently. The update group behavior made a
single session's
slowness cascade to all of the others, so there was much screaming.

At a certain point, a slow neighbor is a pointless neighbor. If we saw a number,
say 2 days backlog, it would be an obvious problem that requires
reset. Lower numbers
get trickier.

It seems to me that we're looking at 3 categories:

1) Normal sessions - don't kill
2) Slow sessions - don't kill yet, do the slow session things.
3) Too slow - goodbye session.

Maybe a "minimum update rate" algo that would kick off #2 and #3 is a
possibility. A bit
more flexible than just looking at queue depth or getting too deep
into other layers by
looking at buffer characteristics. I know some implementations implement #2, but
I never bothered to dig into how it works. #3 just seems like a
logical extension.

When we ran into this problem recently, the only discussion of window
size was as an affirmation
that the broken box was, in fact, the broken box. But the problem
description is always
something like "stale routes" or "routing loops" (undoubtedly because
they are stale).