Subject: [AAA-WG]: Issue: DCC: Credit pooling should be under server control

From: "Mark Watson" <[email-masked]>
Date: Thu, 29 Jan 2004 19:03:21 -0000

All,

Please find below the first of two issues for the DCC Working Group Last
Call based on the various discussions on credit pooling and quota
independence - I'd be grateful if someone could let me know if there is
anything I need to do to get an issue number/agree on the priority.

Regards...Mark

Description of issue: Credit pooling should be under server control
Submitter name: Mark Watson/Chris Richards
Date first submitted: 29.01.2004
Reference: 
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Section: Various

Rationale/Explanation of issues: 

The current draft allocates credit as a 'pool' associated with a session or
sub-session. All Services or Rating-Groups within the (sub-)session draw
from the single pool.

Mapping of Services and Rating-Groups to (sub-)sessions is under the control
of the client.

In particular: in Clause 5 of the draft we can read: 
  "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). "

The Requested-Service-Unit AVP is part of the CCR, and as said in 8.21:
"The Service-Identifier and the Rating-Group AVPs are used to request 
  units for a given service(s) or rating group when the service element 
  supports credit control for multiple services in one credit control 
  session.  "

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.

This is directly opposite to 3GPP requirements stated in TR23.825 v.1.4.0
section 4.3.2. These requires the mapping of Services/Rating-Groups to
credit pools to be under control of the server.

Since 3GPP intend to pull this specification into 3GPP, it would be
advisable to incorporate 3GPP requirements into the draft. So this work can
be used by other standard bodies facilitating its adoption by the industry.

Furthermore, the current draft identifies grouping for the purposes of
'credit pooling' with grouping for the purpose of state machine handling,
re-authorisation and failure handling. There is no rationale for such an
identification - just because credit can be pooled between two services does
not mean they should be handled in the same way on credit exhaustion, for
example.

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).

Server control of credit pooling is equivalent to considering different
services to be funded from different accounts. It can be approximated
according to the current draft as described in
http://www.merit.edu/mail.archives/aaa-wg/msg00117.html. In this proposal
the server makes equivalent reservations in all necessary accounts and
authorizes service units according to this amount.

This has a number of drawbacks:
(i) it assumes a notion of equivalence between the credit available in the
different accounts. This is easy to understand where accounts contain
monetary currency, but more difficult when they contain scrip or special
one-time vouchers with various rules/restrictions attached.
(ii) it restricts the value of the reservation for all flows based on the
reservations allowed for each individual flow. However, the size of credit
reservations may be related to the expected usage of different services or
may vary depending on the account from which the service is funded. For
example, credit may be reserved in large blocks from the users account in
order to reduce re-authorisation traffic. But for a service which is wholly
or partly funded by a 3rd party, the reservation may be a small amount.
(iii) it is counter-intuitive since the same granted units appear to be
funded multiple times from the different accounts.

We propose that the grouping of services into credit pools should be under
the control of the server and should be decoupled from state machine
handling. We further propose to indicate which types of unit
(time/volume/etc.) are considered 'pooled'. Others are to be metered
independently for each quota. We do not have a strong preference as to how
this is achieved. One proposal is given below.

Requested change: 

Overview:

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).

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.

The absence of a G-S-U-Pool-Reference for a particular unit type implies
that the (sub-)session is to be considered a single pool, as per the
existing draft. 

Detailed changes:

- Change fifth paragraph of Section 5:

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 credit pool is explicitly identified in the
Granted-Service-
   Units AVP. 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.

   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).

- Section 8, add to table:
                                            +---------------------+  
                                            |    AVP Flag rules   |  
                                            |----+-----+----+-----|----+  
                     AVP  Section           |    |     |SHLD| MUST|    |  
   Attribute Name    Code Defined Data Type |MUST| MAY | NOT|  NOT|Encr|  
   -----------------------------------------|----+-----+----+-----|----|  
   G-S-U-Pool-      tbd  8.X      Unsigned32| M  | P   |    |  V  |  Y |
      Identifier                            |    |     |    |     |    |
   G-S-U-Pool-      tbd  8.Y      Grouped   | M  | P   |    |  V  |  Y |
     Reference                              |    |     |    |     |    |
   CC-Unit-Type     tbd  8.Z      Enumerated|    |     |    |     |    |

- Section 8.16 - amend as follows:

FROM:

8.16 Granted-Service-Unit AVP  
        
   Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and 
   contains the amount of units that the Diameter credit-control client 
   can provide to the end user until the service must be released or the 
   new Credit-Control-Request must be sent. A client is not required to 
   implement all of the unit types, and must treat unknown or unsupported 
   unit types in the answer message as an incorrect CCA answer. In that 
   case the client shall terminate credit control session and indicate in 
   the Termination-Cause AVP reason DIAMETER_BAD_ANSWER. 
    
   The Service-Identifier and the Rating-Group AVPs are used to associate 
   the granted units to a given service or rating group. 
   In case both the Service-Identifier and the Rating-Group AVPs are 
   included, the target of the granted units is always the service(s) 
   indicated by the value of the Service-Identifier AVP. 
   A value of 0 (zero) granted service unit associated to a Service-
   entifier(s) or Rating-Group indicates that the corresponding traffic 
   MUST be denied. Note that in case the credit-control server want to 
   disconnect the user and close the credit-control session, it SHOULD 
   use the appropriate error code in the Credit-Control-Answer message 
   rather than including n times the Granted-Service-Units AVPs with the 
   value of  0 (zero).  
   In contrast, a value of max type granted service unit (e.g. max 
   Unsigned 32 is FFFFFFFF) associated to a Service-Identifier(s) or 
   Rating-Group indicates that the corresponding traffic is free-of-
   charge. With unit type money, the value of the Exponent AVP is set to 
   0 (zero) when free-of-charge is indicated. With unit type service 
   specific, the value of the CC-Service-Specific-Units AVP is set to 
   FFFFFFFF to indicate free-of-charge. 
    
   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 ] 
                                 *[ Service-Identifier ] 
                                  [ Rating-Group ]

TO:

8.16 Granted-Service-Unit AVP  
        
   Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and 
   contains the amount of units that the Diameter credit-control client 
   can provide to the end user until the service must be released or the 
   new Credit-Control-Request must be sent. A client is not required to 
   implement all of the unit types, and must treat unknown or unsupported 
   unit types in the answer message as an incorrect CCA answer. In that
   case the client shall terminate credit control session and indicate in 
   the Termination-Cause AVP reason DIAMETER_BAD_ANSWER. 
    
   The Service-Identifier and the Rating-Group AVPs are used to associate 
   the granted units to a given service or rating group. 
   In case both the Service-Identifier and the Rating-Group AVPs are 
   included, the target of the granted units is always the service(s) 
   indicated by the value of the Service-Identifier AVP. 
   A value of 0 (zero) granted service unit associated to a Service-
   entifier(s) or Rating-Group indicates that the corresponding traffic 
   MUST be denied. Note that in case the credit-control server want to 
   disconnect the user and close the credit-control session, it SHOULD 
   use the appropriate error code in the Credit-Control-Answer message 
   rather than including n times the Granted-Service-Units AVPs with the 
   value of  0 (zero).  
   In contrast, a value of max type granted service unit (e.g. max 
   Unsigned 32 is FFFFFFFF) associated to a Service-Identifier(s) or 
   Rating-Group indicates that the corresponding traffic is free-of-
   charge. With unit type money, the value of the Exponent AVP is set to 
   0 (zero) when free-of-charge is indicated. With unit type service 
   specific, the value of the CC-Service-Specific-Units AVP is set to 
   FFFFFFFF to indicate free-of-charge.

   The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U-Pool-
   Identifier identifying a credit pool within which the units of the
   specified type are considered to be pooled. If a G-S-U-Pool-Reference AVP
   is present then actual service units of the specified type MUST also be
   present. For example, if the G-S-U-Pool-Reference AVP specifies Unit-Type
   TIME, then the CC-Time AVP MUST be present.

   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.
    
   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 ]

- Add new Section 8.X:

8.X G-S-U-Pool-Identifier AVP

    The G-S-U-Pool-Identifier AVP (AVP code tbd) is of type Unsigned32 and
    identifies a 'credit pool' within the session with which the
    Granted-Service-Units AVP is associated. 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.

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 )

8.Z CC-Unit-Type AVP

    The CC-Unit-Type AVP (AVP code tbd) is of type enumerated and specifies
the type of units which are considered to be pooled into a credit pool.  The
following values are defined for the CC-Unit-Type AVP:

        TIME                    0
        MONEY                   1
        TOTAL-OCTETS            2
        INPUT-OCTETS            3
        OUTPUT-OCTETS           4
        SERVICE-SPECIFIC-UNITS  5

- end of changes

---

From: <[email-masked]>
Date: Thu, 29 Jan 2004 22:19:27 +0200

Assigned issue 17
 
John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Mark Watson
Sent: 29 January, 2004 21:03
To: [email-masked]'
Subject: [AAA-WG]: Issue: DCC: Credit pooling should be under server control

All, 

Please find below the first of two issues for the DCC Working Group Last Call based on the various discussions on credit pooling and quota independence - I'd be grateful if someone could let me know if there is anything I need to do to get an issue number/agree on the priority.

Regards...Mark 

The current draft allocates credit as a 'pool' associated with a session or sub-session. All Services or Rating-Groups within the (sub-)session draw from the single pool.

Mapping of Services and Rating-Groups to (sub-)sessions is under the control of the client. 

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.

This is directly opposite to 3GPP requirements stated in TR23.825 v.1.4.0 section 4.3.2. These requires the mapping of Services/Rating-Groups to credit pools to be under control of the server.

Since 3GPP intend to pull this specification into 3GPP, it would be advisable to incorporate 3GPP requirements into the draft. So this work can be used by other standard bodies facilitating its adoption by the industry.

Furthermore, the current draft identifies grouping for the purposes of 'credit pooling' with grouping for the purpose of state machine handling, re-authorisation and failure handling. There is no rationale for such an identification - just because credit can be pooled between two services does not mean they should be handled in the same way on credit exhaustion, for example.

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).

Server control of credit pooling is equivalent to considering different services to be funded from different accounts. It can be approximated according to the current draft as described in http://www.merit.edu/mail.archives/aaa-wg/msg00117.html. In this proposal the server makes equivalent reservations in all necessary accounts and authorizes service units according to this amount.

This has a number of drawbacks: 
(i) it assumes a notion of equivalence between the credit available in the different accounts. This is easy to understand where accounts contain monetary currency, but more difficult when they contain scrip or special one-time vouchers with various rules/restrictions attached.

(ii) it restricts the value of the reservation for all flows based on the reservations allowed for each individual flow. However, the size of credit reservations may be related to the expected usage of different services or may vary depending on the account from which the service is funded. For example, credit may be reserved in large blocks from the users account in order to reduce re-authorisation traffic. But for a service which is wholly or partly funded by a 3rd party, the reservation may be a small amount.

(iii) it is counter-intuitive since the same granted units appear to be funded multiple times from the different accounts.

We propose that the grouping of services into credit pools should be under the control of the server and should be decoupled from state machine handling. We further propose to indicate which types of unit (time/volume/etc.) are considered 'pooled'. Others are to be metered independently for each quota. We do not have a strong preference as to how this is achieved. One proposal is given below.

Requested change: 

Overview: 

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).

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.

The absence of a G-S-U-Pool-Reference for a particular unit type implies that the (sub-)session is to be considered a single pool, as per the existing draft. 

Detailed changes: 

FROM: 

TO: 

   services. The credit pool is explicitly identified in the Granted-Service- 

   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). 

FROM: 

    

TO: 

    

   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. 

- Add new Section 8.X: 

    The G-S-U-Pool-Identifier AVP (AVP code tbd) is of type Unsigned32 and 
    identifies a 'credit pool' within the session with which the 
    Granted-Service-Units AVP is associated. 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. 

8.Z CC-Unit-Type AVP 

    The CC-Unit-Type AVP (AVP code tbd) is of type enumerated and specifies the type of units which are considered to be pooled into a credit pool.  The following values are defined for the CC-Unit-Type AVP:

        TIME                    0 
        MONEY                   1 
        TOTAL-OCTETS            2 
        INPUT-OCTETS            3 
        OUTPUT-OCTETS           4 
        SERVICE-SPECIFIC-UNITS  5 

- end of changes

---

From: <[email-masked]>
Date: Fri, 30 Jan 2004 18:35:40 +0200

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.

>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.

>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.

MSt: since each service/rating-group seems to have its own reservation, the above text is
now inaccurate. What about removing or rewriting it?

>8.X G-S-U-Pool-Identifier AVP

    Granted-Service-Units associated 

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.

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 ] 

Regards
Marco