Subject: [AAA-WG]: Issue 28: Watchdog Timer issue with no Max-Wait-Time

From: Pat Calhoun <[email-masked]>
Date: Fri, 13 Jul 2001 15:18:26 -0700

All,

Paul has identified a problem that exists with the current watchdog
algorithm since the Max-Wait-Time AVP has been removed. Please consider
the following proposed text. I will re-open Issue 28.

We have two options:
1. Leave the text as is, and let implementors deal with how to resolve
   this problem (it is not an interoperability issue, but more how to
   protect oneself against bad behavior), or
2. Accept the text

I would like to hear what the WG feels,

PatC
----

--=====================_133428019==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 08:15 AM 6/28/01 -0700, Pat Calhoun wrote:
>> 11. Issue 28 - Re-open Max-Wait-Time?
>When a response is received for requests, this is not an issue.
>Right now, how long a server wants to wait for a response is an
>implementation issue. Measures need to be taken against servers
>that do not respond. Paul will propose text to the list.
>Watchdogs will be removed from the state machine, and the
>definition would be expanded. A new section will discuss how
>to deal with requests that have been in the list for too long.

I'm not proposing that we reinstitute Max-Wait-Time. However, 
the absence of Max-Wait-Time does not alleviate the need to 
discard requests that are taking too long to complete. The 
client and each proxy must keep transaction state for each 
request. In theory, every request will be responded to, but for 
a variety of reasons it's possible that a request can get lost -- 
resource failures, malfunctions, etc. So every client and proxy 
needs to protect itself from slowly accumulating obsolete 
transaction state. 

My suggestion is simply that a client or proxy that has not 
received a response to a request within an appropriate (i.e., 
configurable) period of time simply discard it. If an answer 
comes in later, there is no transaction state so the answer 
will be ignored. I think a simple statement to this effect in 
the draft is all that's necessary.

The other related issue is how to handle watchdogs. The 
approach proposed by Randy at the interim meeting relied 
on an answer (possibly a timeout error) always being returned 
at least by the next-hop proxy at the conclusion of Max-Wait-
Time. That approach no longer works.

So here's my homework assignment - a new watchdog 
algorithm. I have to say that I'm not pleased with how it came 
out; it is certainly more complex than I'd like. 

Can we discuss this on Thursday? An alternative to specifying 
this algorithm in detail would be to simply state that a peer 
MAY issue DWR to confirm the status of a connection, at 
whatever frequency it chooses.

-----

Watchdog Algorithm

The algorithm that follows uses the following variables:

STATUS represents the level of confidence in the connection. 
It may take on one of the following values:

     OKAY indicates the connection is presumed working

     WAIT_DWA indicates that a DWR has been sent but a 
     DWA has not yet been received

     SUSPECT indicates the connection is possibly  
     congested or down

PENDING is a flag that is true when there are no outstanding 
unanswered requests.

T is the watchdog timer, measured in seconds. Every second, 
T is decremented. When it reaches 0, the OnTimerElapsed event 
(see below) is invoked.

The algorithm uses the following time constants, which have 
default values but may be configured differently in an 
implementation:

Ti, the idle time, represents the number of seconds that must 
elapse when there is no activity, before a DWR is sent. The 
default value of Ti is 30 seconds.

Tr, the request pending time, represents the number of seconds 
that must elapse when there are requests pending but no messages 
have been received, before a DWR is sent. Tr should be less than 
Ti. The default value of Tr is 10 seconds.

Tw, the watchdog pending time, represents the number of seconds 
that must elapse after a DWR is sent but no DWA has been 
received, before the STATUS of the connection is set to SUSPECT.
The default value of Tw is 5 seconds.

Tc, the close timer, the number of seconds that must elapse 
when the STATUS is SUSPECT and no DWA has been received, before 
the connection is stopped. The default value of Tc is 5 seconds.

The algorithm processes the following events:

OnSendRequest is processed whenever a request is sent on the 
connection.

OnReceiveNonDWA is processed whenever a message other than 
DWA is received on the connection. This message may be a 
request or an answer.

OnReceiveDWA is processed whenever a DWA is received.

OnTimerElapsed is processed whenever timer T reaches 0.

Pseudo-code for the algorithm is as follows:

OnSendRequest
     if status = okay AND T > Tr
          T = Tr

OnReceiveNonDWA
     if status = okay
          if pending
               T = Tr
          else
               T = Ti

OnReceiveDWA
     if status = wait_DWA OR status = suspect
          if pending
               T = Tr
          else
               T = Ti

OnTimerElapsed
     if status = okay
          SendWatchdog
          status = wait_DWA

     else if status = wait_DWA
          status = suspect
          T = Tc

     else if status = suspect
          Stop Connection

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]