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

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Mon, 30 Apr 2001 15:06:45 -0500

Johnathan,

	While I do agree that it's wasteful to include redundant redundancy, wouldn't this require different peer state machines for TCP and SCTP?  Couldn't there be some other way to reduce the overhead for SCTP?  What about negotiating the frequency of the watchdog messages in a DRI or something similar?  That way, an entity could configure infrequent (perhaps the maximum value of some well-known time data structure) watchdog messages for their reliable (sctp) links and more frequent watchdog messages for their less-reliable (tcp) counterparts.

-Brian
> -----Original Message-----
> From: Jonathan Wood [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 2:45 PM
> To: [email-masked]
> Subject: [AAA-WG]: Diameter/SCTP and watchdogs
> 
> 
> 
> 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: Jonathan Wood <[email-masked]>
Date: Mon, 30 Apr 2001 13:30:29 -0700 (PDT)

>
>Johnathan,
>
>	While I do agree that it's wasteful to include redundant redundancy, 
wouldn't this require different peer state machines for TCP and SCTP?  Couldn't

Hmm would they? If you never turn on the watchdog timer, you never
get watchdog events, and the state-machine code can be the same.

> there be some other way to reduce the overhead for SCTP?  What about 
negotiating the frequency of the watchdog messages in a DRI or something 
similar?  That way, an entity could configure infrequent (perhaps the maximum 
value of some well-known time data structure) watchdog messages for their 
reliable (sctp) links and more frequent watchdog messages for their 
less-reliable (tcp) counterparts.

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

Now that I think about it, could we rely on TCP keepalives
for analagous functionality in TCP and get rid of this
altogether?

Jonathan