Re: [Dime] group signaling - limited success on group operations

["Bales, Mark [CTO]" <[e-mail]>]

Marco,

IMO


I think option B works, low risk to Diameter Peers getting out of Synch.  Additional signaling is the price we pay.

Mark

From: Marco Liebsch [mailto:[e-mail]]
Sent: Monday, February 27, 2017 10:52 AM
To: Bales, Mark [CTO] <[e-mail]>; [e-mail]
Subject: RE: group signaling - limited success on group operations

Hi Mark,

I agree with your view.

For the removal of failed sessions there are again different options:


Per specification, removal is controlled by Diameter peers utilizing (service-specific) re-authorization request
and having the SESSION_GROUP_ALLOCATION_ACTION flag of the included
Session-Group-Control-Vector cleared (Section 4.2.2).



During group operation, we have the result of a group operation that identifies failed sessions. Hence,
server and client should actually aware of failed sessions. I see the following options:



a.)      Since Diameter peers are aware of failed sessions, they MUST remove these session from
the group(s) to which the group command applied. This should keep the session groups
on both Diameter nodes synchronized.



b.)     To remove failed session from session groups, the Diameter client MUST initiate session removal procedure
per section 4.2.2 for each of the failed sessions. In addition, the Diameter client enters the procedure for
single-session fallback.



c.)      To remove failed sessions from session groups, the Diameter client includes the Session-Group-Control-Vector
with the SESSION_GROUP_ALLOCATION_ACTION flag cleared into the command used during the operation
of a single-session fallback.





Issue with a.) may be that the server has removed the failed session from the session groups when
sending the response of the group operation with limited success to the client. In case the response
does not arrive at the client for some reason, the client may re-send the group operation and  assumes
that the actually failed sessions are still assigned to the session groups.



b.) seems to be the safest approach but results in more signaling. Assuming N failed sessions, this will end up
in 1 x group operation response + N x re-authorization request for session removal, N x single-session operation.



c.) violates the specification per section 4.2.2 where a (service-specific) re-authorization request is to be
used to remove a session from a session group.

If we want to be as clean as possible in this base specification, I'd go for option b)
What do you think?

marco


From: Bales, Mark [CTO] [mailto:[e-mail]]
Sent: Freitag, 24. Februar 2017 20:03
To: Marco Liebsch; [e-mail]<mailto:[e-mail]>
Subject: RE: group signaling - limited success on group operations

Marco

IMO

Diameter peers need to fall back to single-session operation for failed session(s).  ---- keep as much efficiency as possible.
Remove sessions that failed from the session Group. --- we need to keep the session groups as accurate as possible.

Determining of re-addition of a Session to a Session Group would need to happen at some point but I see the as a recovery operations but an administrative function.



From: DiME [mailto:[e-mail]] On Behalf Of Marco Liebsch
Sent: Thursday, February 23, 2017 10:37 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [Dime] group signaling - limited success on group operations

There is an open item in the draft about how Diameter peers treat sessions, which belong to one or
multiple session groups, and a group command failed for some sessions associated with the session
groups to which the command applies. This is the current text in the draft:


When a Diameter node receives a request to process a command for one
or more session groups and the result of processing the command
succeeds for some sessions identified in one or multiple session
groups, but fails for one or more sessions, the Result-Code AVP in
the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per
Section 7.1.2 of [RFC6733].  In case of limited success, the
sessions, for which the processing of the group command failed, MUST
be identified using a Failed-AVP AVP as per Session 7.5 of [RFC6733].




Some more description is needed how these sessions, for which the group operation
failed, should be treated. Here is a proposal:

- Diameter peers need to fall back to single-session operation for these sessions
- Diameter node SHOULD re-try the command on a single-session basis
- If the single-session command succeeds, the Diameter peers MAY continue keeping the
session(s) in the session group(s)
- if the single-session command fails, the session MUST be removed from all session groups
to which the previous group command applied

This is kind of optimistic procedure.

Alternative: We may also mandate to fall back to single session operation and remove failed
sessions from all session groups to which the group command applied.

Please let me know your position w.r.t. the above operation, text and options.

marco








________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.