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

[Robert Raszuk <[e-mail]>]

Hi Jeff,

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

Please note that this is almost exactly what we did in the draft. We
recommended
30 min or EOR.

   We also recommend that the TCP "User Timeout" parameter be set only
   after the End-of-RIB marker [RFC4724], if expected, is received from
   each of the (AFI, SAFI) being exchanged over the BGP session, or
   otherwise thirty minutes after the BGP session is established.


We did not suggest lowering that after drop-dead time just yet ... or we
did not
include some AI bits into this simply as we think this is marginal
enough so we
should not make it too complex.



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


If the sender is not following negotiated HOLDTIME I am not sure if this is
useful to signal it apriori.

As we see there can be some constants but the timeout may be subject to
change
during runtime. So what we signalled on session up may not apply in all
cases. If we
look at TCP there can be a number of TCP level factors in dropping the
session or not.




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

There is a significant difference in what do we call "stuff" here.

Current BGP Send_Hold_Timer implementation detects TCP local buffer as
full. I
think this is way too coarse to what we are dealing with here.

And to solve this in a decent manner and not make BGP code way too complex,
TCP
level detection comes almost for free here. Hence our proposal :)

Kind regards,
Robert