Re: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback requested

[William McCall <[e-mail]>]

On Fri, Apr 23, 2021 at 12:43 PM Job Snijders
<job=[e-mail]> wrote:
>
> Hi Jakob, group,
>
> Thanks for the feedback, a -02 has been submitted.
>
> On Fri, Apr 23, 2021 at 12:56:40AM +0000, Jakob Heitz (jheitz) wrote:
> > I propose to add this text:
> >
> > It is possible that a BGP speaker presents a TCP zero receive window
> > after receiving a large batch of updates. Resetting the session to
> > such a speaker may just repeat the large batch, whereas waiting a little
> > longer may have given it a chance to recover. The possibility of this
> > occurrence makes it difficult to determine a good value for the
> > timer. The default value of the timer is therefore recommended
> > to be 15 minutes.
>
> In this email John Scudder appears to suggest using a separate new
> timer, and populate the timer with the default HoldTimer value (and the
> -02 draft attempts to describe exactly that).
> https://mailarchive.ietf.org/arch/msg/idr/E5pqxIObPS7e9A2IqIApTHVSfig/
>
> you propose 15 minutes; so it seems there is some convergent thinking in
> the group the proposed timers at hand is in the order of 'multiple
> minutes'.
>
> How long should a BGP speaker be willing to buffer on behalf of another
> BGP speaker's inability to progress message processing?
>
> If the oldest message in the queue is a KEEPALIVE message, and its been
> stuck there for more than HoldTimer, wouldn't we have expected the
> remote side to have killed the BGP session anyway?
>
> Would you mind sharing your thinking on why a default of 15 minutes is
> better than for example 180 seconds? What do others think?
>

15 min seems a safe default, if somewhat arbitrary.

The default has to be safe enough to survive slowness, especially
during initial convergence, across a wide variety of deployments.

What is "slow" is going to depend on the profile of the deployment. So
tunability in implementation is probably going to be more critical (at
least in my thoughts) than the default in practice.

I think this is only a piece of what BGP really ought to measure and
act against in these cases. BGP should have some understanding of
far-side message processing latency. Because if my queue is
progressing at 1 update/10 min, it is going to be really behind even
when there is progress.  I'm a big fan of a ping + nonce capability to
estimate this latency in addition to watching update outQ time. They
handle for complimentary conditions.

-- 
William McCall