Subject: [Dime] Diameter state synchronization - PART 2

From: "Ulf Bodin" <[email-masked]>
Date: Wed, 26 Sep 2007 17:50:52 +0200

All, 
 
Continuing the work on Diameter state synchronization I've looked
through sections 5.2.3 and 5.2.4 of
http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-01
.txt
<http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-0
1.txt>  [SR]. Sections 5.2.1 and 5.2.2 were discussed in June (see PART
1 below). Going through section 5.2.3 and 5.2.4 (PART 1) of [SR] and
matching against
http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-03
.txt
<http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-0
3.txt>  [RM-ext] I noted the following: 
 
1) Active instance guided backup server selection means to inform peer
Diameter peers about the identity of backup server, or servers in case
loadsharing is to be applied, in which states need to be rebuilt after
failover (see section 5.2.3 of [SR]). Active instance guided selection
could be achieved through AVP(s) returned in regular application
signalling. This approach could work also for backup instance guided
backup server selection case as I see it. 
 
Alternatively, in case loadsharing is to be applied the information on
how the load should be distributed among multiple backup servers could
be provided already in a notification message message from the
backup/standby about active/primary server failure (i.e. the message
identified in section 5.2.1 - Notificaiton from Standby Instance). 
 
In my view the approach of using a separate notificaiton message can be
beneficial also for active instance guided backup server selection since
the loadsharing information will then be available before reqular
application signalling occurs. That is, sudden increases in signalling
load will then be distributed correctly immediately instead of after
information in the first returning application message answers has been
received and processed. At high load scenarios that may cause overload
situation that server(s) may handle more or less well depending on
implementation. Would be good avoiding relying on that servers implement
proper overload control IMHO and I therefore prefer the separate message
approach (i.e. using the same separate message that needs to be defined
to solve the section 5.2.1 - Notificaiton from Standby Instance
problem). 
 
2) The timing of state reconstruction after failure (covered in section
5.2.4 of [SR]) can be challenging due to the potentially large amount of
states that need to be synchronized. Therefore a mechnism to perform
bulk transfers of state information is needed. Such mechanism is defined
in [RM-ext]. That is, a Resource-Bag AVP can be included in an
Session-Resource-Reply (SSR) message. The actual information (AVP(S))
that needs to be provided should if possible be restricted to what's
needed by the server to take over the work of the active/primary server.
The information to be synchronized shold in my view be clearly defined
by Diameter applications aiming at using a generic Diameter state
synchronization mechanism (i.e. the subset of information that must be
synchronized should be identified by the appliocation). 
 
For state reconstruction upon reception of a request (second part of
section 5.2.4 of [SR], the same need for identifying the subset of
information that must be synchronized in application specification
appears. Also, a backup server without complete resynchronized state
must be capable of separating request messages that update soft-state
and/or are issued for synchronization purposes from request messages
that are sent to create a new state/session. E.g. 3GPP Gq and ETSI
TSIAPN Gq' relies on that the server recognizes the session ID of an AAR
as a new ID or an ID that belongs to an existing session. This precludes
the backup server from treating update/synchronization messages
different from requests for new sessions, which may be desired e.g. to
handle overload situations properly. Therefore I beleive it would be
beneficial to define an boolean AVP for new session/not new session as
part of a Diameter state synchrinization mechnism together with rules
for when this AVP shall/should be used by applications in request
messages. 
 
Comments?
 
BR Ulf  

	All, 

	I've been looking in whether the original work on Diameter
resource management extensions now captured in
http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-reqs-02.tx
t
<http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-reqs-02.t
xt>  [RM-ext] would meet the demands identified in
http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-01
.txt
<http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-0
1.txt>  [SR] on Diameter state recovery considerations. Comments on this
analyze are very wellcome. 

	Going through section 5.2.1 and 5.2.2 (PART 1) of [SR] and
matching against [RM-ext] I noted the following (remaing sections/PARTs
in following mail): 

	1) Having a standby node informing remote peers of the failure
of an active instance (i.e. 5.2.1 in [SR]) is not covered by [RM-ext],
not in any other spec (as far as I know). I'm not sure what kind of
message would be appropriate for this purpose (i.e. a new mesage or an
existing one such as CER). Any views on this? 
	[Lionel Morand] CER/CEA are used to initiate a transport
connection between diameter peers. In this specific case, we may assume
that the Standby node may actually also indicate the active instance
failure by sending a CER to the remote peers. The transport connection
establishment would be a hint for the remote peers to detect that the
Standby node is now active and that therefore the previous active node
is down. The only problem is that CER/CAA messages can not be proxied,
redirected or relayed i.e. it would be not possible to use this
mechanism if a proxy/redirect/relay agent is present in the Diameter
path between remote peers and Stanby/active node. This can not be
therefore defined as a generic mechanism.  

	[Ulf1] You're right of course. Informing remote peers of the
failure of an active instance would henece require a new message I
guess. that is, a message the be sent immediately after the CER/CAA
message exchange directly following the detection of that an Active
instance has become permanetly inavailable. 

	2) Synchronizing state (i.e. 5.2.2, first paragraph in [SR]) is
not natively supported by [RM-ext], but could be suppored with a small
change/addition I beleive. E.g. through a flag in the SRQ saying whether
all session information is requested for all active sessions (all
information on all sessions is requested when no Session-Id is provided
in the SRQ), or just the session-Id of all active sesisons (i.e. an SRR
without any Resource-bag AVPs). 
	[Lionel Morand] if needed, I think that this could be easily
fulfilled with an optional AVP in SQR e.g. "State Synchronization AVP"
of Enumarated type, that would clearly indicate the granularity of
requested information about active sessions. 

	[Ulf1] Yes. I agree. I forsee a potential value in having a set
of predefined values for different granularities. For example, (a) all
information on all active sessions, (b) session ids only for all active
sessions, (c) all information or session ids only for all sessions
that'll time out with x seconds, (d) all information or session ids only
for all sessions with application property x (related to one or more
application specific AVPs), etc. While I see a clear need for
differentiating between (a) and (b), I think (c) and (d) type of values
would be interesting to discuss to found out whether that can be useful
or just makes the solution more complex.  

	3) Reconstructing session state using application messages (i.e.
5.2.2, Using Application Messages in [SR]) is generally not supported by
Diameter nor in [RM-ext]. As I understand the protocol a AAR updating an
existing session is identified by that the Session-Id is known by the
server (i.e. is active), while an AAR establishing a new session
provides a new Session-Id not currently being used for any active
session. Hence, a flag indicating that the message is for an existing
sesison (or a separate message) would be needed to facilitate state
reconstruction using mid-session messages.  

	4) Reconstructing session state using generic messages (i.e.
5.2.2, Using a Generic Message in [SR]) is indeed supported by [RM-ext]
(i.e. through SRQ and SRR in which state information for several
sessions can be requested and provided respectively). 

	Best regards,
	Ulf 

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime