Re: [Idr] New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt

[Jeffrey Haas <[e-mail]>]

Enke,

On Thu, Aug 18, 2022 at 08:20:19AM -0700, Enke Chen wrote:
> We have spelled out several recommendations for applying the TCP User
> Timeout to BGP in the following draft:
> 
>        https://datatracker.ietf.org/doc/draft-chen-idr-tcp-user-timeout/
> 
> I hope your concerns with using the TCP parameter are adequately
> addressed. Please let us know if you have any comments.

Thanks for the pointer to this new submission.

With regard to the FSM interaction, your suggested procedure is clear: Use
End-of-Rib as a trigger.  It's a good start to a proposal.

Your draft also picks some values for the timers with a minimum value of 10
minutes.  Loosely quoting John Scudder, "constants are always wrong", but we
have to start somewhere. :-)

The detail I'd provide for Working Group and your consideration against when
do we want to start the timer is that initial sync can get stuck (perhaps
more so in some circumstances!) just as well as later timelines.  We know
that devices initially booting are having to consume a significant amount of
state and this both contributes toward per-peer slowness and also many
opportunities for zero-windowing due to inability to service a given socket
in a timely fashion.

My comment applies equally to your draft and the sendholdtimer draft:
Portions of the BGP FSM set timer values depending on what point we are at
in the FSM's execution.  It's therefore reasonable to pick a very high value
and always start the timer upon session startup and then potentially reduce
the timer after we've achieved end-of-rib.  If end-of-rib isn't going to be
received, that lower timer threshold may be reasonable to set after some
drop-dead time; alternatively just stick with the very high value.

Similarly applicable to both drafts, I'm wondering if there may be benefit
in signaling the peer what the sendholdtimer (or equivalent tcp-user timer)
values are.  It's effectively a warning, and a hint to the remote peer's
schedulers to make sure that some amount of data is drained in a timely
enough fashion.  The NOTIFICATION subcode we've started discussing for
signaling that the sender has torn things down is the other half of this
equation.

With regard to the TCP specific feature, I still have personal unease with
what the timer implies.  The general desire articulated by many in these
threads is "the peer makes progress and doesn't stay blocked forever".
Certainly the TCP user timeout would accomplish that.  However, the timer is
versus "unacknowledged data".  What this means is not "we've made no
progress", rather "stuff was enqueued X seconds ago and unacknowledged".

I think the above illustrates a key detail the Working Group will need
consensus on: Do we care if we're not making progress (perhaps at all), or
are we willing to put a timeliness requirement on the contents?

-- Jeff