Subject: RE: [AAA-WG]: Issue: DCC: Credit pooling should be under server c ontrol

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

Hi Marco,

Comments on this one inline too. Again, happy to work offline to get a
revised proposal together.

Just for clarity, Issue 16 builds on and changes some of the things proposed
in this one (17). It is probably best if we focus on the text from Issue 16
since I think that basically addresses both problems - I submitted two just
because I saw two distinct problems. But that can have a common solution, I
hope.

Regards...Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 30 January 2004 16:36
> 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: Credit pooling should be 
> under server control
> 
> 
> Hi Mark,
> 
> >Therefore it's clear that it is the CC Client that controls the 
> >grouping of services or
> >rating-groups into a single session or sub-session and hence 
> into a single credit pool.
> 
> MSt: perhaps this is your interpretation. As stated many 
> times during our discussion the CC client doesn't control the 
> grouping of services in a single credit pool. But, this is 
> just clarification.
> 

MW: I guess the point was just that as presently drafted the credit is
pooled across all services in a sub-session & it is the client which decides
how to group services into sub-sessions. Or were you referring to the
funding of services from separate accounts, as described below ?

> >Finally, the current draft omits to describe how credit pooling is 
> >applied in the case of
> >services with multiple unit types (for example both time and volume).
> 
> I think the Flow X exactly depict this case, but ok we need 
> to rewrite it.
> 

MW: Ok. I meant the case where one service has both a time and a volume
quota, not where there is a time-based service together in a sub-session
with a different volume-based service. For example a service may be charged
per MB but has a time quota of 2 hours as well because the per MB rate is
only valid for the first 2 hours. The current draft is not clear about how
to interpret multiple unit types in a single G-S-U, but in one
interpretation, the passing of time for this service would reduce the
available quota for other services (it would be counted towards the current
%age of the reservation that has been used), whereas this is not the
intention.

> >In order to let the responsibility of grouping to the sever, 
> i.e, the 
> >server decides what
> >services can be shared with the credit allocated, we should 
> introduce a new AVP in the CCA >called "G-S-U-Pool-Reference" 
> AVP within the Granted-Service-Unit.
> >The G-S-U-Pool-Reference represents a reference from the 
> Granted-Service-Units to a 
> >'Granted Service Units Pool'. The Granted Service Units Pool 
> is identified by a unique 
> >identifier (new G-S-U-Pool-Identifier AVP). The reference is 
> specific to a particular kind >of unit (i.e. Time/Money/Volume).
> 
> MSt: Agree.
> 
> >Granted-Service-Units within a session which refer to the 
> same Granted 
> >Service Units Pool
> >are considered to draw from a single pool of credit. This 
> applies even when they are in
> >different sub-sessions.
> 
> MSt: I agree with the concept you propose except that CCR 
> sent in one (sub-)session MUST not include quotas given in 
> another (sub-)session even thoguh they draw from the same 
> account i.e. each (sub-)session is handled separately, no mixing.
> 

MW: Yes, agreed. That was the intention.

>  >  Note that this concept implies that one single credit reservation 
>    is kept and allocated to all the services/rating groups 
> within a credit 
>    pool. All the quotas associated with the credit pool are 
> derived from that 
>    entire credit reservation i.e. assuming each given 
> service/rating group 
>    consumes the whole amount. Therefore the quotas conveyed 
> to the Diameter 
>    Credit control client are not independent entities - that 
> is the client can 
>    completely consume only a single one of them, or partially 
> consume some 
>    combination. Where a single service or rating group has 
> multiple quotas of 
>    different types (e.g. time and volume), these are 
> considered as separate 
>    quotas within the credit pool. An example of this 
> mechanism is illustrated 
>    in Appendix A (Flow X). 
> 
> MSt: since each service/rating-group seems to have its own 
> reservation, the above text is now inaccurate. What about 
> removing or rewriting it?

MW: Yes, if we go forward with both Issues 16 and 17 then this text is
replaced by text from Issue 16. What we have above is a way to give the
client control of the pooling, but for the pools then to operate in the same
way as in the present draft (i.e. using the existing formula).

> 
> >8.16 Granted-Service-Unit AVP
>  
>    Re-authorisation must be sought when the credit pool is 
> exhausted. A credit 
>    pool is considered exhausted when the sum of the 
> fractional amounts of the 
>    granted credit for all the quotas associated with the same 
> credit pool 
>    reaches unity.
> 
> >8.X G-S-U-Pool-Identifier AVP
> 
>     Granted-Service-Units associated 
>     within a single Credit Pool are assumed to be drawn from 
> a common credit 
>     reservation. Therefore, re-authorisation MUST be sought 
> when the combined 
>     resource used by all the services or rating groups within 
> the credit pool 
>     reaches 100% of the amount granted. 
> 
> MSt: to me these sounds a bit inaccurate descriptions, it 
> doesn't reflect the equations defined in the other issue 
> (issue 16). I would perhaps consider rewriting.
> 

MW: Yes - Issue 16 changes this text too (or it should!)

> > 8.Y G-S-U-Pool-Reference AVP
>     The G-S-U-Pool-Reference AVP (AVP code tbd) is of type 
> Grouped and 
>     associates the Granted-Service-Units AVP within which it 
> appears with a 
>     credit pool within the session for a single unit type. 
> The CC-Unit-Type 
>     AVP specifies the type of units for which credit is 
> pooled. The Credit- 
>     Pool-Identifier AVP specifies the credit pool from which 
> credit is drawn 
>     for this unit type. 
>          G-S-U-Pool-Reference    ::= < AVP Header: tbd > 
>                                   ( G-S-U-Pool-Identifier ) 
>                                   ( CC-Unit-Type ) 
> 
> MSt: I think there is better description in issue 16. The 
> ABNF grammar should be:
> 
>             G-S-U-Pool-Reference ::= < AVP Header: tbd > 
>                                      { G-S-U-Pool-Identifier } 
>                                      [ CC-Unit-Type ]
>                                      [ Unit-Value ] 
>

MW: What would be the meaning of a G-S-U-Pool-Reference with no CC-Unit-Type
?
 
> Regards
> Marco