Subject: RE: [AAA-WG]: Issue: DCC: Independent handling of services within a session

From: "Mark Watson" <[email-masked]>
Date: Mon, 2 Feb 2004 18:02:27 -0000

Hi Marco,

Thanks for your response - comments/answers below...

I guess we can work on an updated proposal offline based on your comments
below.

Regards...Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 30 January 2004 15:51
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: [AAA-WG]: Issue: DCC: Independent handling of 
> services within a session
> 
> 
> Hi Mark,
> 
> I'm glad to see your proposal, I finally think to understand 
> what you exactly want. You mainly want to manage each 
> service/rating-group (re-)authorization in a way 
> independently and you want to be able to add/remove services 
> at any time, right?

MW: Yes, and to decouple from the pooling concept, so that pooling can still
take place across independently managed services/rating-groups in order to
avoid fragmentation.

> 
> One minor detail.....such a structured proposal would have 
> avoided months of loop discussion.
> 
> I think in principle we are fine with your proposal. We would 
> however prefere a more clear functional split in the protocol 
> for this feature, I mean more clear separation of say basic 
> features and complex 
> functionalities. For that reason we may perhaps consider to define a 
> new grouped AVP that would include G-S-U, R-S-U, U-S-U, F-U-I 
> etc. rather 
> than lifting everything at G-S-U level. But, let agree the 
> basic principles 
> first and then discuss this other details.
> 
> More comments in line.
> 
> Regards
> Marco
> 
> >Handling of services or rating groups within a single session or 
> >sub-session can only be
> >done 'en-bloc' according to the grouping of those services 
> of rating groups into (sub-)
> >sessions by the client. In particular:
> >- all services or rating groups must be re-authorised at the 
> same time 
> >- adding an additional service or rating group requires 
> re-authorisation of all other 
> >services/rating groups in the (sub-)session
> 
> MST: This is not exactly true, in particular it is true 
> relative to the flow example I provided in our discussion but 
> is not an absolute statement. Since the client knows how much 
> of the credit reservation it has been used for service 1 
> (C1/Q1), it can authorize only the new service request e.g. 
> service 2 (CCR (Service 2)) if so wanted and safe enough 
> (e.g. if the total amount of credit used by the acive 
> service(s) is below some configurable threshold). So, all the 
> listed disadvantages and 'en-bloc' consideration vanishes. 
> The disatvantage of not enabling adding/removing 
> "reservations" in the pool stays.
> 

MW: Ok, I understand. We can add/remove services from the 'pool' but the
amount of credit in the pool (the reservation) cannot be changed.

> >- the construction in which multiple quotas representing the *same* 
> >monetary allocation are
> >passed down from client to server is counter-intuitive and 
> liable to major mis-
> >interpretation
> 
> MSt: I may argue the same for your proposal, but as long as 
> we clearly define the semantic there shouldn't be any 
> problems with either proposals.
> 

MW: Well, I guess there is a sense in which whatever you are most familiar
with is 'intuitive' and the opposite is 'counter-intuitive'. But really,
every credit control system I have come across has a concept of delegating
the authorisation for a certain amount of a particular service. The idea
that the authorisation for a particular volume is not absolute, but
qualified by some other services does seem a little strange - 'baroque' was
the term which came up internally ;-) 

> >In order to handle quotas within a pool separately, it is 
> necessary to 
> >be more explicit
> >within the protocol about the relationship between quotas. 
> This is presently communicated 
> >implicitly based on the assumption that all quotas are 
> derived from the same credit 
> >reservation in the server.
> >For each service/rating group and unit, we provide a 
> 'Multiplier' value which is used to 
> >express the ratios between services in terms of resource usage.
> >If service 1 has multiplier M1 and service 2 has multiplier 
> M2 then resources from service >1 can be converted to those 
> of service 2 by multiplying by M1/M2.
> 
> MSt: If  service 1 cost $1/MB, service 2 cost $0.5/MB and 
> service 3 cost $0.1/MB, the multiplier indicates that 10MB of 
> service 1 correspond to 20MB of service 2 and 100MB of 
> service 3, that 20MB of service 2 correspond to 10MB of 
> service 1 and 100MB of service 2 etc. right? In other word, 
> the multiplier is the rating value associated to the 
> service/rating-group. In the above example M1=1, M2=0.5 and 
> M3=0.1. So why don't you say this more explicitly?
> 

MW: M1=10, M2=5 and M3=1 would do just as well. We have found a lot of
sensitivity about doing rating in the client. Of course that is not what is
proposed here - the server does the rating and communicates the *result* to
the client. But still, that is the reason for avoiding terminology such as
'rating value' for things handled at the client. We can work offline on
clearer wording.

> >The formula for determining the exhaustion of the credit for a given 
> >pool of quotas at the
> >client is modified as follows: the credit pool is exhausted when
> >    C1*M1 + C2*M2 + ... + Cn*Mn >= M 
> >Where M is the total credit for the credit-pool. M is 
> initially calculated from the granted 
> >quotas in the pool as follows:
> >    M = Q1*M1 + Q2*M2 + ... + Qn*Mn 
> 
> MSt: This mechanism seems to imply that one reservation is 
> kept for each of the services/rating-groups because you sum 
> up all the active credit reservations (i.e. Q1*M1=$ reserved 
> for service 1, Q2*M2=$ reserved for service 2 etc.). This 
> equation won't be valid if Q1, Q2,..., Qn were derived from 
> the same credit reservation. In principle I'm fine with this 
> even though we may end up in a huge amount of credit 
> reservations that the server need to handle.
> 

MW: Right - the server calculates how much it would reserve for each service
separately and makes all of these reservations against the account. Now,
whether the server remembers how much was associated with each service, or
whether it just remembers the total is probably internal to the server. 

> The equation C1*M1+C2*M2+...+Cn*Mn >= M allows each of the 
> services to draw resources from any of the reservations so 
> long as the total amount of reserved credit is not exceeded. 
> Then I have a question. Suppose the server reserved $2 for 
> service 1, $5 for service 2 and $2 for service 3. Service 1 
> consumed $6, Service 2 consumed $1 and Service 3 consumed 
> $0.5. The total amount of used credit is not exceeding M 
> (that is 9 in this case) and e.g Validity-time for Q1 expires 
> then CCR reporting the corresponding amount of $6 is sent to 
> the server. Would the server then commit $2 from reservation 
> 1 and $4 from reservation 2 and make two new reservation, one 
> of $5 as before (for service 2) and one to re-authorize 
> service 1 or...? 

MW: I am not sure we need to specify the internal behaviour of the server so
long as the protocol is well-defined. It's clear that at the client, the
value of M is reduced by 6 when it indicates the $6 for Service 1 to the
server. At the server, the total credit reserved is reduced by $6 and a real
$6 deducted from the account. Then the server decides what new reservation,
if any, to make. Whavever the client gets back in terms of new credit for
Service 1 is added to M (times the multiplier).

> 
> >Additional considerations:
> >This proposal raised some additional considerations which 
> require discussion. 1) Since we 
> >propose that quotas are handled independently, it MAY be 
> necessary to associate the 
> >DIAMETER CC state machine with each *quota* rather than with 
> a (sub-)session. Equivalently, 
> >the CCR/CCA messages could be extended to handle 
> requests/answers for multiple sub-sessions 
> >within a single message. Due to the need for further 
> discussion, the detailed changes for 
> >this are not included below yet.
> 
> MSt: The DCC state machine described in the draft it is 
> mandatory and common to all the DCC client. The state machine 
> descibes the DCC (sub-)session and controls the messages sent 
> in it, according to the Diameter concept of session. Since 
> this feature is optional I don't want to see modification to 
> the state machine because of it. Perhaps some text as follow 
> could be added e.g. to section 5.
> 
> " How the independent quota objects are handled in 
> conjunction with the state machine defined in section 7 is 
> regarded as an implementation issue. Implementations of 
> DIAMETER credit control client and server MUST, however, 
> ensure a failure handling behavior for each of the quota 
> objects fully consistent with the section 5.6 of this 
> specification and MUST enable for credit (re-)authorization 
> of a service/rating-group while a (re-)authorization for one 
> or more other services/rating-groups is ongoing. To achieve 
> this it may be necessary to instantiate one DCC state machine 
> for each of the quota objects active within a (sub-)session."  
> 
> ...or something to that effect.
> 

MW: Ok, well I included that text based on the list discussion which seemed
to suggest that it would not be possible to handle quotas separately without
associating the state machine with the quotas. So perhaps this is something
you & Harri could discuss. As long as it is well-defined and works I don't
have a strong opinion about the state machine stuff.

> >2) It MAY be necessary to perform actions on a credit pool 
> as a whole 
> >(for example, server- initiated re-auth, setting of a 
> Validity-Time). 
> >In this case a Granted-Service-Units-Pool AVP could be 
> defined within 
> >the CCA message which supports such actions. This is not shown below 
> >either.
> 
> Yes, we have to define how to do this. For server initiated 
> re-authorization one possibility  could be to add the 
> Granted-Service-Units-Pool, the service-identifier and the 
> rating-group AVPs to the RAR message.
>

MW: Ok, sounds good.
 
> >Detailed changes:
> >- Section 5, fifth paragraph, amend as follows: 
> FROM: 
>    When multiple services are used within one user session and each 
>    service or group of services are subject to different 
> cost, making use 
>    of credit control sub-sessions will result in increased 
> signaling load 
>    and resources usage in both the credit control client and 
> the credit 
>    control server. For instance, during one network access 
> session the 
>    end user may use several http-services subject to different access 
>    cost. To optimally support these scenarios, the credit control 
>    application enables for multiple services credit control 
> in a single 
>    credit control session. It is possible to request and allocate 
>    multiple quotas as a credit pool that is shared between multiple 
>    services. The services can be further grouped into rating 
> groups in 
>    order to achieve even further aggregation of credit 
> allocation. It is 
>    also possible to request and allocate multiple quotas on a 
> per service 
>    basis. The mechanism is illustrated in Appendix A (Flow X). 
> TO: 
>    When multiple services are used within one user session and each 
>    service or group of services are subject to different 
> cost, making use 
>    of credit control sub-sessions will result in increased 
> signaling load 
>    and resources usage in both the credit control client and 
> the credit 
>    control server. For instance, during one network access 
> session the 
>    end user may use several http-services subject to different access 
>    cost. To optimally support these scenarios, the credit control 
>    application enables for multiple services credit control 
> in a single 
>    credit control session or sub-session. It is possible to 
> request and 
>    allocate resource as a credit pool that is shared between multiple 
>    services. The services can be further grouped into rating 
> groups in 
>    order to achieve even further aggregation of credit 
> allocation. It is 
>    also possible to request and allocate multiple quotas on a 
> per service 
>    basis. Where quotas are allocated to a pool, the quotas 
> remain independent 
>    objects which can be re-authorised independently at any 
> time. Quotas can 
>    also be given independent validity times and 
> Final-Unit-Indications. The 
>    mechanism to share units across services and rating groups 
> is described 
>    further in Section 5.X.
> 
> MSt: I think this is fine.
> 
> > 5.X Sharing of units across services and rating groups
>     To avoid credit fragmentation and unnecessary load on the 
> credit control 
>     server, it is possible for service units to be provided 
> to multiple 
>     services or rating groups as a pool. 
>     This is achieved by providing the service units in the 
> form of a quota for 
>     a particular service or rating group in the usual way, 
> but also including 
>     a reference to a credit pool for that unit type. The 
> reference includes a 
>     multiplier which translates from service units of a 
> specific type to the 
>     abstract service units in the pool.
> 
> MSt: I think it should be clarified what is this 
> 'multiplier'. Why don't you refer more explicitely to the 
> rating value (i.e. if cost $1/MB the multiplier is 1 as far 
> as I understand).

MW: We can work on some text offline - I think you have a correct
understanding of the concept. As I mentioned we just wanted to avoid people
getting sensitive about 'rating' in the client.

> 
>       Where multiple G-S-U-Pool-Reference AVPs with the same 
> G-S-U-Pool 
>     Identifier are provided within a Granted-Service-Units 
> AVP then these 
>     MUST have different CC-Unit-Type values and they all draw 
> on the credit 
>     pool separately. 
> 
> MSt: perhaps it would be good to expalin this with an 
> example, similarly as you did in the introduction.
> >(e.g. Time and Volume) then multipliers can be provided for 
> one or more 
> >of them. Where two >multipliers are provided (e.g. M1t for 
> time and M1v 
> >for volume) then the used resource from >the pool is the sum 
> C1t*M1t + 
> >C1v*M1v.
> 

MW: Ok.

> 8.16 Granted-Service-Unit AVP  
>         
>       
>    The Granted-Service-Unit AVP has the following ABNF grammar:   
>              
>          Granted-Service-Unit ::= < AVP Header: 431 > 
>                                   [ Tariff-Time-Change ]   
>                                   [ CC-Time ] 
>                                   [ CC-Money ]   
>                                   [ CC-Total-Octets ] 
>                                   [ CC-Input-Octets ] 
>                                   [ CC-Output-Octets ] 
>                                   [ CC-Service-Specific-Units ] 
>                                  *[ G-S-U-Pool-Reference ] 
>                                  *[ Service-Identifier ] 
>                                   [ Rating-Group ] 
>                                   [ Validity-Time ] 
>                                   [ Final-Unit-Indication ] 
> 
> MSt: it may be that the server returns a failed Result-Code 
> in the CCA caused by only one service/rating-group. In that 
> case we would close the whole (sub-)session even though other 
> services can continue. Perhaps it is apropriate to also 
> include the Result-Code in the G-S-U.
> 

MW: Ok, makes sense - or it could be in this intermediate level grouped AVC
that you suggested, right ?

---

From: <[email-masked]>
Date: Tue, 3 Feb 2004 09:23:13 +0200

Hi Mark,
 
>I guess we can work on an updated proposal offline based on your comments below. 
 
Agreed. Once the proposal will be ready we need to update the issues 16 and 17.
 
Regards
Marco