Re: [radext] Watchdog behaviour (was: Confirmation of discussions on RADIUS/(D)TLS at IETF117)

[Heikki Vatiainen <[e-mail]>]

On Fri, 4 Aug 2023 at 20:41, Alexander Clouter <[e-mail]>
wrote:

> On Fri, 4 Aug 2023, at 18:12, Heikki Vatiainen wrote:
>
> On Thu, 3 Aug 2023 at 10:15, Mark Grayson (mgrayson) <mgrayson=
> [e-mail]> wrote:
>
> > Radsecproxy offers two different ways of doing status server. Either
> >"on", which sends a packet each $timeinterval (I think it's 30 or 60
> > seconds, would need to confirm) or "minimal" which only sends status
> > server requests if replies to requests are outstanding.
>
> We don’t want to break idle_timeout mechanisms, especially for dynamically
> discovered routes.
>
>
> That's a good point. Do any of the current RFCs have guidance on closing
> dynamically opened connections? Should there be, or is this for the
> implementations to decide?
>
> Here's a hopefully useful idea on how to use watchdog (Status-Server) with
> dynamic connections:
> - when the dynamic connection has been established, do a watchdog request
> (Status-Server) over the connection
> - if there's an answer, the connection is likely good, otherwise there is
> likely a problem
>
>
> Why not just send the request that triggered the discovery for the initial
> test? Seems it would just needlessly add an RTT to the overall RTT of the
> request/response?
>

This request is sent before the watchdog request. The watchdog can follow
immediately the initial request. When this is done, there are two
outstanding requests and depending on what answers are received, or not,
the state of the connection starts to become known. With dynamic discovery,
I'd say it helps debugging when it's immediately seen that the remote ends
answers to at least Status-Server requests.

This also shaves one watchdog timeout from the time it takes to determine
if the peer is able to respond at all.

However, this idea is more of an implementation detail and may be useful in
some cases. That's why I didn't suggest to put it in a draft. What Margaret
wrote in a separate message some moments is fine with me.

> - when the connection is up, run watchdog (Status-Server) periodically but
> do not reset idle_timeout timer when watchdog response is received
>
> This allows the dynamic connection to be timed out while still allowing
> monitoring whether or not the peer is still responsive.
>
>
> This yak shaving is starting to make me wonder if we should just define
> BFD-over-RADIUS. :)
>

Had to lookup 'yak shaving'. I first thought it means I was spreading too
much burro on this bread, which seems to be close, but a different animal
[1].

[1] Fawlty Towers, season 1, episode 1

-- 
Heikki Vatiainen
[e-mail]