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

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

All,

Please find the second of two issues for DCC WGLC based on the discussions
on credit pooling and quota independence. I attempted to separate the two
issues of credit pooling and quota independence - indeed the symptoms of
these two problems are distinct. However, there are linkages which lead to a
common solution, and as such the proposal below builds heavily on the
proposal of our other submission.

I would say again that we are not wedded to a particular solution, but we
were asked for a concrete proposal, so here it is!

Best regards,

Mark

Description of issue: Independent handling of services within a session
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: 

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
- termination actions, particularly, redirect apply to the whole
(sub-)session
- state machine handling applies to the whole (sub-)session

This has the following disadvantages:
- unnecessary load on the server to perform re-rating for all services and
rating groups, particularly when adding a new service will usually have no
effect on the rating decision for the other services
- unnecessary (though less than above) load on the client to process other
services just to add a new one
- not possible to leave some services under credit control when others are
terminated/redirected (the policy for how far 'into the red' a service can
run will depend on the service).
- when a service or rating group has quotas in multiple units, it is not
possible to have some of those handled independently and others 'pooled'
- 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

The above restriction stems from the manner in which the 'pooling' of quotas
for multiple services is framed within the protocol. The quotas provided for
different services are not semantically independent and therefore operations
on them must be carried out 'en-bloc'.

We propose to make the quotas provided semantically independent within the
protocol, whilst maintaining the concept of a 'credit pool' which can apply
to multiple services across the session. Additionally, as per our other
proposal, we propose to decouple the 'pooling' of credit from the
session/sub-session. Please see the other proposal for the rationale for
this.

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.

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

This is pretty much equivalent to the existing formula (with Mi = M/Qi),
with the following advantages:
(i) new services can be added/removed without reference to the existing ones
- M is simply modified by (Quota*Multiplier) for the added/removed service
(ii) all quotas returned in CC answers cleanly represent independent
authorizations to use the indicated resource
(iii) re-authorisation can be sought for an individual service/rating group
(for example if another quota associated with the same service/rating group
is exhausted)
(iv) flexibility, low signaling overhead and avoidance of credit
fragmentation are maintained

Note that where a Granted-Service-Unit contains more than one resource unit
(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.
Note that the draft at present does not include an explicit description of
the handling of services with more than one resource unit with respect to
credit pooling.

Finally, we propose to add the Final-Unit-Indication and Validity-Time AVPs
to the Granted-Service-Unit APV to express independent handling of the
different services in these respects.

Requested change:

Overview:

To implement the above mechanism, we extend the proposal made in Issue xxx
on server control of credit pooling by adding the multiplier to the
G-S-U-Pool-Reference AVP. The multiplier is expressed using the Unit-Value
AVP.

We therefore add the following AVPs:

    G-S-U-Pool-Reference AVP - contains a reference to a credit pool, a
unit-type and a multiplier (using the Unit-Value AVP). It is used within
Granted-Service-Units AVP to indicate that credit of a particular type is
pooled.

    CC-Unit-Type AVP - indicates the type of units (time, volume) that are
pooled.

    G-S-U-Identifier AVP - identifies the credit pool.

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

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.

- New section 5.X:

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. 

    If M is the total service units within the pool, M1, M2, ... , Mn are
the
    multipliers provided for services 1, 2, ..., n andC1, C2, ... ,Cn are
the
    used resources within the session, then the pool credit is exhausted and
    re-authorisation MUST be sought when:

        C1*M1 + C2*M2 + ... + Cn*Mn >= M

    The total credit in the pool, M, is calculated from the quotas which are
    currently allocated to the pool as follows:

        M = Q1*M1 + Q2*M2 + ... + Qn*Mn    

    If services or rating groups are added to or removed from the pool, then
    the total credit is adjusted appropriately.

    Re-authorisation for an individual service or rating group may be sought
    at any time, for example if a 'non-pooled' quota is used up or the
    Validity-Time expires.

    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.

    Where service units are provided within a Granted-Service-Units AVP
    without a corresponding G-S-U-Reference AVP then these are handled
    independently from any credit pool and from any other services or rating
    groups within the session.

- Section 8 - add to the 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.
    
   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.

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. The CC-Unit-Type AVP specifies the type
of
    units for which credit is pooled. The G-S-U-Pool-Identifier AVP
specifies
    the credit pool from which credit is drawn for this unit type. The Unit-
    Value AVP specifies the multiplier which converts between service units
of
    type CC-Unit-Type and abstract service units within the credit pool (and
    hence to service units of any other service or rating group associated
    with the same pool).

         G-S-U-Pool-Reference	 ::= < AVP Header: tbd > 
                                  ( G-S-U-Pool-Identifier )
                                  ( CC-Unit-Type )
                                  ( Unit-Value )

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

- remove Annex A section A.10 (Flow X) - new example tbd once mechanism is
agreed

- end of changes

---

From: <[email-masked]>
Date: Thu, 29 Jan 2004 21:25:38 +0200

Assigned Issue 16

John
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Mark Watson
Sent: 29 January, 2004 21:08
To: [email-masked]'
Subject: [AAA-WG]: Issue: DCC: Independent handling of services within a session

All, 
Please find the second of two issues for DCC WGLC based on the discussions on credit pooling and quota independence. I attempted to separate the two issues of credit pooling and quota independence - indeed the symptoms of these two problems are distinct. However, there are linkages which lead to a common solution, and as such the proposal below builds heavily on the proposal of our other submission.
I would say again that we are not wedded to a particular solution, but we were asked for a concrete proposal, so here it is!
Best regards, 
Mark 

Description of issue: Independent handling of services within a session 
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: 
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
- termination actions, particularly, redirect apply to the whole (sub-)session 
- state machine handling applies to the whole (sub-)session 
This has the following disadvantages: 
- unnecessary load on the server to perform re-rating for all services and rating groups, particularly when adding a new service will usually have no effect on the rating decision for the other services
- unnecessary (though less than above) load on the client to process other services just to add a new one 
- not possible to leave some services under credit control when others are terminated/redirected (the policy for how far 'into the red' a service can run will depend on the service).
- when a service or rating group has quotas in multiple units, it is not possible to have some of those handled independently and others 'pooled'
- 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
The above restriction stems from the manner in which the 'pooling' of quotas for multiple services is framed within the protocol. The quotas provided for different services are not semantically independent and therefore operations on them must be carried out 'en-bloc'.
We propose to make the quotas provided semantically independent within the protocol, whilst maintaining the concept of a 'credit pool' which can apply to multiple services across the session. Additionally, as per our other proposal, we propose to decouple the 'pooling' of credit from the session/sub-session. Please see the other proposal for the rationale for this.
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.
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 
This is pretty much equivalent to the existing formula (with Mi = M/Qi), with the following advantages: 
(i) new services can be added/removed without reference to the existing ones - M is simply modified by (Quota*Multiplier) for the added/removed service
(ii) all quotas returned in CC answers cleanly represent independent authorizations to use the indicated resource 
(iii) re-authorisation can be sought for an individual service/rating group (for example if another quota associated with the same service/rating group is exhausted)
(iv) flexibility, low signaling overhead and avoidance of credit fragmentation are maintained 
Note that where a Granted-Service-Unit contains more than one resource unit (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. Note that the draft at present does not include an explicit description of the handling of services with more than one resource unit with respect to credit pooling.
Finally, we propose to add the Final-Unit-Indication and Validity-Time AVPs to the Granted-Service-Unit APV to express independent handling of the different services in these respects.
Requested change: 
Overview: 
To implement the above mechanism, we extend the proposal made in Issue xxx on server control of credit pooling by adding the multiplier to the G-S-U-Pool-Reference AVP. The multiplier is expressed using the Unit-Value AVP.
We therefore add the following AVPs: 
    G-S-U-Pool-Reference AVP - contains a reference to a credit pool, a unit-type and a multiplier (using the Unit-Value AVP). It is used within Granted-Service-Units AVP to indicate that credit of a particular type is pooled.
    CC-Unit-Type AVP - indicates the type of units (time, volume) that are pooled. 
    G-S-U-Identifier AVP - identifies the credit pool. 
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.
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.

Detailed changes: 
   basis. Where quotas are allocated to a pool, the quotas remain independent 
    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 
    If M is the total service units within the pool, M1, M2, ... , Mn are the 
    multipliers provided for services 1, 2, ..., n andC1, C2, ... ,Cn are the 

        

             

    

- 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. 
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. The CC-Unit-Type AVP specifies the type of 
    units for which credit is pooled. The G-S-U-Pool-Identifier AVP specifies 
    the credit pool from which credit is drawn for this unit type. The Unit- 
    Value AVP specifies the multiplier which converts between service units of 
    type CC-Unit-Type and abstract service units within the credit pool (and 
    hence to service units of any other service or rating group associated 
    with the same pool). 
         G-S-U-Pool-Reference    ::= < AVP Header: tbd > 
                                  ( G-S-U-Pool-Identifier ) 
                                  ( CC-Unit-Type ) 
                                  ( Unit-Value ) 

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 

- remove Annex A section A.10 (Flow X) - new example tbd once mechanism is agreed 
- end of changes

---

From: <[email-masked]>
Date: Fri, 30 Jan 2004 17:51:02 +0200

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?

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

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

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

>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

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.

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

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

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

FROM: 

MSt: I think this is fine.

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

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. 

             

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.