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

[Enke Chen <[e-mail]>]

Hi, Jeff:

Thank you for your comments. Please see my replies inline.

On Fri, Aug 19, 2022 at 9:24 AM Jeffrey Haas <[e-mail]> wrote:
>
> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-chen-idr-tcp-user-timeout/__;!!Mt_FR42WkD9csi9Y!Y42MYIGWjyExkrGXFCRWmilyyAOF-OGmR3HhTqCFjbbeHMVlDFNhrFCkBdNW9FxBv_0MJzduyRYnh0PvRA$
> >
> > 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. :-)

Yes, there needs to be a default value, and it should be configurable.
That's what we recommend in the draft.

>
> 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.
>

For such a corner case, IMO we should keep the solution simple.
It seems that the key is to make the timeout value large (and
configurable) so we don't generate false positives.

> 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.

The signaling mechanism for TCP user-timeout is already specified in
RFC5482. It's optional.

>
> 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".
>

The TCP user-timer applies to "un-delivered data", including both
"unacked data" and "buffered but untransmitted data".

> 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?
>

BGP only knows when the local TCP write-buffer is full, and that is
only one specific case. There are several other cases where the TCP
write-buffer is not full, but can also result in stale routes:

    - BGP messages are not delivered for a long time, either due to
zero-window or lost ack.

It can take a long time for the TCP buffer to be filled up when
routing is relatively stable.

That's why I believe a solution at the BGP level would be incomplete
and perhaps even more complex. On the other hand, TCP user-timeout is
specifically designed to handle these cases. It's more complete and
simpler.

-- Enke