Re: : Failover mechanism in DCCA

> These, I understand are more of BASE protocol functionalities and should
> be transparent to DCCA client. (Assuming DCCA would be layered on BASE)

The BASE failover facilities described in RFC 3539 operate only on
the first hop, and assume that state is not being kept, and therefore that
one AAA server is as good as another.

This is not necessarily true for the DCCA application, which builds state
on the Diameter client and server that may or may not be replicated to an
alternative server.  The result is that pure BASE failover functionality
can result in failover to a DCCA server without the required state.  This
is why DCCA needs to be able to control the failover behavior via the
CC-Session-Failover AVP.  My understanding is that if this AVP is not set
to FAILOVER_SUPPORTED then Diameter Base failover is turned off.

> In scenarios where DCCA client talking to Agents, and an Agent could be
> serving the requests for a particular realm 3 hops away, do we need to
> start all over again to try the alternate secondary server which could
> have been reached from the same Agent ? Further, how would the DCCA
> client know which is the alternate server that needs to be tried ?

Diameter clients utilize the Watchdog functionality defined in RFC 3539 to
diagnose failures in the first hop.  Unless a Diameter client receives an
error message, it may be quite difficult for it to diagnose the cause of
a failure beyond the first hop.  In general, receipt of error messages is
not guaranteed for all potential failure scenarios.

> As far as I see, DCCA should include Dest-Host AVP for the subsequent
> requests after initial CCA received *IF* failover_is_not_supported else
> it shouldn't include this AVP so that the BASE/Agents can do a failover
> to other servers in a given realm.

In general, RFC 3539 tries to avoid failover while segments are still in
flight since this violates the law of "conservation of packets".  That
is why Diameter DCCA can terminate service early (prior to expiration of
the minimum Tw timer) but does not initiate a new request unless a
protocol error has been received, indicating that segments are no longer
in flight.  This enables DCCA to maintain conservative behavior.

> But, with the above approach it is not guaranteed that we always try the
> server which replied with initial CCA before failing over to the other
> alternate servers.

I'm also not sure how this approach can avoid multiple failovers and
violation of "conservation of packets".