Subject: [AAA-WG]: Diameter/SCTP and watchdogs

From: Jonathan Wood <[email-masked]>
Date: Mon, 30 Apr 2001 12:44:35 -0700 (PDT)

Section 7 of the base protocol draft describes watchdogs
to detect peer failure.

SCTP already has this functionality built in, so when
using SCTP, diameter doesn't need to do it too. To this
end I suggest that we add some text stating section
7 is needed only when transporting diamter over TCP.

Jonathan

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 1 May 2001 07:48:01 -0700

On Mon, Apr 30, 2001 at 01:30:29PM -0700, Jonathan Wood wrote:
> This is one possibility. But there is more than just redundancy
> on the network at stake here. Incorporated with the watchdog
> functionality is the whole bundle of RTT measurement and RTO
> calculation, which can be pretty subtle (how many papers have
> been written on this subject? :) and is, I believe, something
> best left to the transport layer. It would be nice to not
> have to do this at all in Diameter (another argument for moving
> to SCTP exculsively).

But the reality is that the application must have access to some
measurement information in order to make a more intelligent
failover decision. The watchdog messages are intended to be used
for that purpose, since it is the only message that doesn't get
proxies, and can therefore provide the actual application RTT (meaning
both transport and application processing) measurements.

Also, can one "configure" how SCTP keepalives will be sent?
> 
> Now that I think about it, could we rely on TCP keepalives
> for analagous functionality in TCP and get rid of this
> altogether?

See above, and with TCP, there is no way for the application to
specify the frequency of the keepalives, which is necessary for
quick failover.

PatC

---

From: Jonathan Wood <[email-masked]>
Date: Tue, 1 May 2001 10:24:38 -0700 (PDT)

Just in case people are getting confused about terminology:

In Diameter they are called watchdogs
In SCTP they are called heartbeats
in TCP they are called keepalives

>failover decision.

Remember that this is the whole point of RTO calculation by the
transport layer: when can we reasonably decide that a peer is
down? SCTP is flexible enough that the application layer should
be able to tune some parameters, and leave the rest up to SCTP.

>The watchdog messages are intended to be used

Perhaps I am way off base here, but I would be surprised if,
in practice, the the cost of application processing for
watchdogs actually became significant for RTT measurements.
Furthermore (and now I may be heading too much into
implementation-detail land), for resource efficiency reasons
you often don't want an otherwise idle application periodically
waking up. Ultimately transports like SCTP will be in the
kernel, so they won't cause app wakeups for heartbeats.

>Also, can one "configure" how SCTP keepalives will be sent?

Yes.

>specify the frequency of the keepalives, which is necessary for

Actually some platforms do allow you to configure keepalive frequency.
However, it is non-standard, so there would be code-portability
issues.

So for TCP I see a case for leaving in watchdogs, but for SCTP I
still think it makes sense to turn them off and make use of
SCTP heartbeats.