Subject: [AAA-WG]: Issue 247

From: <[email-masked]>
Date: Mon, 11 Mar 2002 08:56:22 +0200

Hi Bernard,

I thought that I closed this for the base.  Specifically,

 Requested change: 

 I recommend that text specifying how to control sending watchdogs and 
 management of the watchdog timer be stricken from the base spec, and 
 that the base spec refer to the transport draft on this matter. 

This I did.  Also,

 Remove from section 5.6.2 Events: 
  ...

Events were removed.  Timers (except for Tc) were removed.

Is there anything else left open?

John

Issue 247: Inconsistencies between the base and transport drafts 
Submitter name: Jonathan Wood 
Submitter email address: [email-masked] 
Date first submitted: 21-Nov-01 
Reference: 
Document: base 
Comment type: E 
Priority: 1 
Section: Base (version 8 alpha2), sections 5.6, 5.6.2, and 12 
Rationale/Explanation of issue: 

The transport draft and the base spec are in conflict about 
sending watchdogs. The state machine in the base spec section 5.6 
requires that watchdogs be sent on each expiration of the watchdog 
timer. However, the transport draft requires that a watchdog be 
send once on the first expiration of the watchdog timer. On the 
next expiration of the watchdog timer, the connection is put in 
the suspect state, and the connection is failed over. 

Also, section 5.6 states 

When the state machine below requests a 
transport connection with the peer, the state machine in [52] is 
invoked. Once the connection has been established, the state machine 
in this section is followed. 

This is not completely accurate. The state machine in the transport 
draft should be followed throughout the life of the connection as 
well to manage the connection. 

There are also some leftover timer descriptions in section 12 that 
are no longer relevant. 

Requested change: 

I recommend that text specifying how to control sending watchdogs and 
management of the watchdog timer be stricken from the base spec, and 
that the base spec refer to the transport draft on this matter. 

Specifically: 

5.6 Peer State Machine 
(Modify 2nd paragraph) 

This state machine is closely coupled with the state machine 
described in [52], which is used to open, close, failover, probe, 
and reopen transport connections. Note in particular that [52] 
requires the use of watchdog messages to probe connections. For 
Diameter, DWR and DWA messages are to be used. 

Remove from R-Open: 

WatchDog-Timer R-Snd-DWR R-Open 

Remove from I-Open: 

WatchDog-Timer I-Snd-DWR I-Open 

Remove from section 5.6.2 Events: 

WatchDog-Timer The Watchdog timer expired, indicating that a DWR 
message is to be sent to the peer. 

Rcv-DWR A DWR message was received. 

Rcv-DWA A DWA message was received. 

Section 12.0 Diameter protocol related configurable parameters 

Recommend removing the following timers: 

Td timer 
The Td timer controls the termination of connections with peer 
in the SUSPECT state. The recommended value is 5 seconds. 

Ti timer 
The Ti timer controls the frequency the watchdog messages are 
to be sent to idle peers. The recommended value is 30 seconds. 

Tr timer 
The Tr timer controls the frequency the watchdog messages are 
to be sent to peers when there are pending requests, but not 
messages have been received from the peer. The recommended 
value is 10 seconds. 

Tw timer 
The Tw timer controls the changing of a peer to the SUSPECT 
state when no answer is received to a watchdog request. The 
recommended value is 5 seconds. 

What about the Tc timer?

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 11 Mar 2002 05:44:39 -0800 (PST)

OK. I will mark it as closed.