On Tue, Dec 15, 2020 at 05:02:19PM +0100, Claudio Jeker wrote:
> On Mon, Dec 14, 2020 at 06:22:09PM +0000, Job Snijders wrote:
> > This patch appears to be a very elegant solution to a thorny subtle
> > problem: what to do when a peer is not accepting new routing
> > information from you?
>
> One thing I'm unsure about is the value of the SendHold timer. I reused
> the hold timer value with the assumption that for dead connections the
> regular hold timer expires before the SendHold timer (the send buffer
> needs to be full before send starts blocking).
Let's be conservative while being progressive! :-)
If the 'Send Hold Timer' value is moved from 'infinite' to 90 seconds
("The suggested default value for the HoldTime", RFC 4271), I think
we'll be able to see benefits.
> People should look out for cases where the SendHold timer triggered before
> either a NOTIFICATION form the peer arrived or where the SendHold timer
> triggered before the HoldTimer. Now that may be tricky since both SendHold
> and Hold timer trigger the same EVNT_TIMER_HOLDTIME event so they can not
> be distinguished easily.
Separation of the cases might be helpful.
> I think that the SendHold timer will almost never trigger and if it does
> only for the case where a session only works in one direction.
If it is rare, maybe it should be logged as a unique message:
"SendHoldTimer Expired".
Kind regards,
Job
