Subject: RE: [AAA-WG]: Diam CC Quota Triggers

From: "Christopher Richards" <[email-masked]>
Date: Thu, 30 Oct 2003 18:38:41 -0600

Hi Marco,
 
Thanks for your reply. I decided to address the different questions I raised
in separate emails to make it simpler.
 
I think that there is real value in having per-quota level triggers, actions
and "reason/cause" codes now that we have multiple quotas per message and
per session.
 
I've added some clarifications below.

Cheers, 
Chris. 

Shasta Wireless Development 
Nortel Networks 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 27, 2003 6:37 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Diam CC questions

Hi Christopher,
 
thank you for your valuable comments.  
 
Harri already gave some answer to some of your questions, I try to address
the others. 
 
I think you have some good point here,  my comments in line.
 
Regards
Marco 
 
P.S.: In general I would suggest you review the draft 01, that should soon
appear in the IETF database, and continue the discussion based on this new
version of the credit control application. Let me know if you want the draft
01 immediately, in that case I 'll send the document directly to you. Hope
this is fine with you.

>On a different subject: Multi-quotas and Used-Service-Units &
Granted-Service-Unit structure. 
 
 [MSt]: I guess you refer to  enhancing  the issue I posted last week,
right?  Or at least to the multiple quotas in general. 
[Chris Richards ] Yes. I am very much in favour of the multiple quotas.
However, with this change comes some re-arrangement of information that is
associated to a quota - and not to a session. Therefore some information
needs to be specific to the Service-Unit AVP (Granted, requested & reported)
- and not at the scope of the entire message (session). 

>The inclusion of trigger/action/trigger-value and cause fields within the
Granted-Service-Unit structure. 

>A Granted-Service-Unit is really the permission to use a resource until
some limit is reached or
> some other session  properties change. The permission may be granted only
for the consumption of a particular resource 
>or category of resource.

[MSt]: The CC server grant permission to use resources according to the
funds available in the user account. If the server determines that usage of
certain resource or category of resource need not to be granted it won't
return quota associated to it.
[Chris Richards ] It may deny a previously granted quota - and do so for
many different reasons. It may also deny an initial request for a quota for
the same reasons. For example, the client requests for 3 different quotas on
behalf of the subscriber at session start. However, the server may decline
to provide Granted-Service-Units to one or more of them while allowing the
others (Providing Granted-Service-Units).

Now that we have multiple quota, we need to be able to treat each one
independently of the others. 

>The current draft has most of these attributes already defined for the
Granted-Service-Unit. However, it seems to be missing 
>the ability to instruct the CC client what actions to take in the event of
certain session events. I propose the addition of 
>Triggers, trigger-actions and trigger-values for the Granted-Service-Unit
AVP.
 
>Triggers are such things as: Time changes or changes to the QoS
characteristics of a session or a change in user location
> (for 3GPP) or quota usage threshold or quota idle time.
 
>Associated with these triggers are actions that should be taken upon the
trigger. Examples of actions could include: re-
>authorise quota, return quota and block further traffic.
 
>Some trigger/actions require a trigger value. For example, the "Idle quota"
trigger, may have an action of "return quota" 
>and  a trigger value of "600 seconds". In other words, if this quota has
not been used for 600 seconds, return it to the 
>Diameter CC server.
 
Trigger ::= < AVP Header: TBD > 
                     { Trigger-Id } 
                     { Trigger-Action } 
                     [ Trigger-Value ] 

         Granted-Service-Unit ::= < AVP Header: TBD > 
                                  { Cause-Id } 
                                  [ CC-Time ] 
                                  [ CC-Money ] 
                                  [ CC-Total-Octets ] 
                                  [ CC-Input-Octets ] 
                                  [ CC-Output-Octets ] 
                                  [ CC-Service-Specific-Units ] 
                                 *[ Service-Identifier ] 
                                  [ Rating-Group ] 
                                 *[ Trigger ] 

[MSt]: this feature concerning the QoS changes or other mid-session events
is already supported. The assumption is that, if mid-session events occur,
the granted quota(s) is(are) not valid anymore and the credit control client
need to perform credit re-authorization to the CC server, this is visible in
the state machine as well as in section 4. I would not introduce any
separate action: the client should send a CCR (update) when such events
occur. 
[Chris Richards ] The problem with the current definition is that it forces
all events to all quotas for all subscribers to be the same. However, for
some subscribers using some quotas, only some events need to be acted upon.
E.g. Not all QoS changes for all quotas should need to trigger a mid call
re-auth of the quota - it should be on a subscriber, quota and event -
basis.

 Concerning the quota idle time we have defined the Validity-time that is
used exactly for that purpose (i.e. return quota if not consumed within
Validity-Time). Validity-time applies to the whole credit reservation, that
is the asset to control. When thinking to multi-quotas, a single credit
reservation is kept for the credit control session and rating for all the
requested Rating-Groups and Service-Identifiers is performed against the
reserved credit (of course according to the cost of a given service or
rating group). Many of the issues you listed are already covered in the
current draft.
[Chris Richards ] The Validity-time has a different usage to the "Idle-Time"
trigger I gave as an example. The Validity-time seems to apply to the entire
session. However, the quota Idle-time is per-quota. It is a means of
ensuring that a subscribers account balance is not all allocated to a
session in many quotas when some of the quotas may no longer be needed and
the quota can be returned to the subscribers account for use elsewhere.
Again, Idle-time is just one example of the many quota-specific triggers --
events that are specific to a particular quota (Granted-Service-Unit).

BTW, We have stated that 'a change in rating condition' may trigger a
spontaneous update but this has been left totally for the client
implementation to decide what kind of change should be regarded important
from rating point of view. So, guidance from the CC server should be allowed
as well and you have a point here.  Why not to defne the Trigger AVP (maybe
in somewhat simpler format) in the CCA message level instead of embedding
that in the GSU AVP?
[Chris Richards ] Because it is specific to each quota
(Granted-Service-Unit). 

 Also, I agree with you that at least one of the things you listed is not
well covered yet , and you have another good point here as well . I'm
thinking to the time changes. While QoS changes and location changes occur
according to some sort of statistic model, thus a huge storm of CCR messages
due to such events is not likely to happen, the time change case may occur
for all the active subscribers at the same time. But I'm not sure the
Trigger AVP you propose cover my concern related to time changes, it seems
the CC client would potentially generate a huge storm of CCR. I think tariff
changes can be handled by including tariff-change time in the CCA (but would
not treat this as 'trigger') and by reporting used units twice (before and
after t-ch, for that we would need a new avp in the USU).  
[Chris Richards ] Excellent. 

>Cause fields are used in each Used-Service-Unit and Granted-Service-Unit
AVP response. E.g. When a client returns 
>quota to the server, the cause field is used to indicate why the quota is
being returned. In a Granted-Service-Unit AVP
> response, the server indicates if the Granted-Service-Unit is successfully
requested and if not, why.

         Cause-Id ::= < AVP Header: TBD > 
                      { Cause-Value } 

[MSt]: I think diameter result codes should be used instead of tailored
cause-id avp. There are few  cases  why the client would perform credit
re-authorization, but the reason is always "credit re-authorization":
 
1- The credit reservation has been consumed. This is determined by the fact
that no units are in possession of the CC client anymore (example for
multiple  quotas can be found in my issue at Flow xxx).
 
2- Mid-session event has occured. The CCR message would include the
mid-session event to be rated, the non-consumed reservation will be returned
to the user's account. The CC server can determine  the mid-session event
from the rating AVPs.
 
3- Validity-Time expires. The CC server is in control of this parameter, it
can determine whether the Validity-Time has expired and what to do next.
 
>For example, in the Used-Service-Units AVP, the cause may be set to "return
of idle quota". The Diameter CC server, 
>would then know not to return any more Granted-Service-Unit AVP for this
Service-Identifier. 
[Chris Richards ] The intention was to define a per-quota cause value. Since
each quota (Granted-Service-Unit) is an independent entity, each needs to be
able to inform the client why it was or was not successful. Having a single
cause at the message (session) level is not fine enough granularity. 
 
>In the Granted-Service-Unit, the cause may indicate that the request was
denied due to "too many Granted-Service-Units in
> use". The client could then take action to return idle
Granted-Service-Unit quotas. 
 
 [MSt]:  If the client terminates the end-user service and the CC session,
it would include the Termination-Cause AVP indicating the  reason. If the CC
server determines some error in the CCR message, it would return an
appropriate Result-Code AVP value.   In the multi-quota case, I don't see
needs to determine credit re-authorization upon a single G-S-U since the
asset to control is always the whole credit reservation.
[Chris Richards ] For example, subscriber wishes to use some service for
which he currently has no Granted-Service-unit. CC Client requests a quota
for this use from the server using the Requested-Service-Unit AVP. If the
users account is barred from using that service, the server can return a
cause indicating "quota declined for session duration" saving the CC client
from requesting the same quota again.
Also when a Reported-Service-Unit is returned to the CC server, it can
indicate what action the server should take based on the cause for return
value - "returning idle quota" will instruct the server not to re-authorise
this quota. Since more than one quota can now exist in a single CC message,
each needs to indicate independently why it is there.

>Please let me know your thoughts and suggestions regarding these proposals.
If you agree I will prepare a formal change. 

 [MSt]: I think it would be nice to address the following issues: tariff-
time  changes in both the single quota and  the multiple quotas cases;
guidance from the CC server concerning the mid-session events.
 
As I say, I'm not sure your current proposal is perfectly tailored to solve
these issues. I would see those as separate issues to be  addressed with
different AVPs. Perhaps you could define an AVP for the CC-ReAuth-Trigger
and some other mechanism for the tariff-time-change?  It would be great if
you can help find a solution to these issues.

---

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Fri, 31 Oct 2003 09:22:53 +0100

Hi Chris,

I agree with you, there are still some things missing in the DCC.
However, I think we have different views on the usage of the quota
in some places. See more comments inline.

Cheers,
Leena

>Some trigger/actions require a trigger value. For example, the
>"Idle quota" trigger, may have an action of "return quota" 
>and  a trigger value of "600 seconds". In other words, if this quota
>has not been used for 600 seconds, return it to the 
>Diameter CC server.
>

[MSt]: this feature concerning the QoS changes or other mid-session
events is already supported. The assumption is that, if mid-session
events occur, the granted quota(s) is(are) not valid anymore and the
credit control client need to perform credit re-authorization to the
CC server, this is visible in the state machine as well as in
section 4. I would not introduce any separate action: the client
should send a CCR (update) when such events occur.

[Chris Richards ] The problem with the current definition is that it
forces all events to all quotas for all subscribers to be the same.
However, for some subscribers using some quotas, only some events need
to be acted upon. E.g. Not all QoS changes for all quotas should need
to trigger a mid call re-auth of the quota - it should be on a subscriber,
quota and event - basis.

[Leena Mattila] I agree with both of you to some extent. I think we
need to define a Trigger to allow the server to control what events
are significant from credit control point of view but I would not go
further than that. That is, the only action for each Trigger would
be 'send CCR(update) to CC server'. The CC Server can then decide what
action to take, continue as normal, terminate service, redirect etc.
Those mechanisms exist already in the DCC, I would not mix the action
with the Trigger and complicate things too much.

[Leena Mattila] I would also keep the principle that when a CCR(update)
is sent then _all_ quotas are reported to the CC server, not only a few
of them while keeping the others running in the client, otherwise we
create kind of hidden sub-sessions with different quotas in one CC session.
If one necessarily wants to report different quotas asynchoronously
then sub-sessions should be used for this purpose. 

[Chris Richards ] The Validity-time has a different usage to the "Idle-Time"
trigger I gave as an example. The Validity-time seems to apply to the 
entire session. However, the quota Idle-time is per-quota. It is a means
of ensuring that a subscribers account balance is not all allocated to a
session in many quotas when some of the quotas may no longer be needed
and the quota can be returned to the subscribers account for use elsewhere.
Again, Idle-time is just one example of the many quota-specific triggers
-- events that are specific to a particular quota (Granted-Service-Unit).

[Leena Mattila] I'd define a basic set of events in the DCC as the Triggers
e.g. change of location, QoS change, and leave the rest to be service
specific. 

[MSt] Why not to defne the Trigger AVP (maybe
in somewhat simpler format) in the CCA message level instead of embedding
that in the GSU AVP?
[Chris Richards ] Because it is specific to each quota (Granted-Service-Unit).

[Leena Mattila] OK, but as mentioned earlier I'd keep the rule that all
quotas should be reported in the CCR(update) whatever and where ever the trigger is.

[MSt]: I think diameter result codes should be used instead of tailored
cause-id avp. There are few  cases  why the client would perform credit
re-authorization, but the reason is always "credit re-authorization"
<snip>
[Chris Richards ] The intention was to define a per-quota cause value.
Since each quota (Granted-Service-Unit) is an independent entity, each
needs to be able to inform the client why it was or was not successful.
Having a single cause at the message (session) level is not fine enough
granularity.

[Leena Mattila] Why is this granularity needed in the client?

[MSt]:  If the client terminates the end-user service and the CC session,
it would include the Termination-Cause AVP indicating the  reason. If the
CC server determines some error in the CCR message, it would return an
appropriate Result-Code AVP value.   In the multi-quota case, I don't
see needs to determine credit re-authorization upon a single G-S-U
since the asset to control is always the whole credit reservation.
[Chris Richards ] For example, subscriber wishes to use some service
for which he currently has no Granted-Service-unit. CC Client
requests a quota for this use from the server using the
Requested-Service-Unit AVP. If the users account is barred from
using that service, the server can return a cause indicating "quota
declined for session duration" saving the CC client from requesting
the same quota again.
[Leena Mattila] If one wants to ask separate quota for separate
services, still having one credit control session then I think
the sub-session mechanism should be used. I don't see big difference
between the sub-sessions and the mechanism you propose here.
If different quotas should be reported and treated asynchronously
then sub-sessions should be used. 

[Chris Richards ] Also when a Reported-Service-Unit is returned to the CC server,
it can indicate what action the server should take based on the
cause for return value - "returning idle quota" will instruct the 
server not to re-authorise this quota. Since more than one quota can
now exist in a single CC message, each needs to indicate independently
why it is there.
[Leena Mattila] I don't see a need for any modifications due to that.
The client can report the used units that the service has consumed
and if it does not need any more units of this type any more it can
request 0 units as Requested-Service-Units.

---

From: <[email-masked]>
Date: Fri, 31 Oct 2003 11:47:15 +0200

Hi,

in my mind all this discussion is tightly coupled with the credit reservation,
that is what the CCA need to control.
One single credit reservation maps one-to-one to a credit control session, what Chris
describes seems to assume that you have different credit reservations per each
quotas hiding a sub-session within a session. If quotas are computed from different
reservations, and thus need to be treated independently, then CC sub-sessions
SHOULD be used. And CC sub-sessions are supported in the current draft.

More comments in line.

Regards
Marco

> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Leena Mattila (TU/LMF)
> Sent: 31 October, 2003 10:23
> To: 'Christopher Richards'
> Cc: Harri Hakala (TU/LMF); Koskinen Juha-Pekka (NET/Tampere); Loughney
> John (NRC/Helsinki); Alexander Benni (NET/Helsinki); Patrik Teppo
> (KA/EAB); [email-masked]
> Subject: FW: [AAA-WG]: Diam CC Quota Triggers
> 
> 
> Hi Chris,
> 

[MSt]: to define a server controllable triggers is what I meant. The triggers
action is always "credit re-authorization" means that CCR[Update] to the CC
server is to be sent.

> then sub-sessions should be used for this purpose. 

[MSt]: Agree.

> where ever the trigger is.

[MSt]: OK Leena, but the trigger should be then at the command level.
Keeping the rule that a credit re-authorization is performed (i.e.
all quotas are reported), it doesn't require for triggers at the
G-S-U level.

> Having a single cause at the message (session) level is not 

[MSt]: if the one single credit reservation is done for the CC session, each
quota is not an independent entity as such. If you see quotas as independent
entities, then you need one credit reservation for each quota and you should
use sub-sessions.

> declined for session duration" saving the CC client from requesting

[MSt]: the assumption is that the services a user is allowed for are provisioned
by another entity than the CC server. If a given service is barred for a given
user, the Service-Identifier pointing to that service won't be provisioned 
to the Service Element. The CC client won't send any request for that service,
simply would deny the user's service request.

> request 0 units as Requested-Service-Units.
[MSt]: I don't see need for modification either. What you, Leena, describe
is one of the supported option (client driven). Another option is to report
0 used-units for a service that didn't consume any and let the server 
decide what to do (server driven). Both are supported.