In a previous message (http://ops.ietf.org/lists/radiusext/2008/msg00857.html) Alan DeKok
pointed out:
"With TCP, there is a connection between client and server. The
watchdog timer algorithm in RFC 3539 is defined per *connection*. So an
ID has to be reserved, because the client can't open a new connection to
test if an existing connection is still alive."
While it's true that the watchdog timer algorithm is defined per connection,
it seems like Status-Server is about determining whether a server is up
or not. The only way to determine whether a connection is down
is to wait for it to close (either via a RESET or timeout). RFC 3539
attempts to detect a failure at the application layer prior to connection failure.
I'm wondering what the implications would be of using two separate connections,
one for Status-Server/Access-Accept and the other
one for Access-Request/Access-Accept transactions.
The failover logic would change, to be sure. For example,
a connection failure on the Request/Accept connection would probably trigger
failover, regardless of the state of the Status-Server/Accept connection.
Also, the state of the two connections could get out of
sync; for example, if the Request/Accept connection was quite busy,
then the Status/Accept connection might send little or no traffic,
which might cause middleboxes (e.g. a NAT) to lose connection state
on the Status/Accept connection. In such a situation, you might just
be able to bring up another Status/Accept connection rather than
triggering failover.
|