Subject: [AAA-WG]: multiple services in a user session, tech. discussion

From: <[email-masked]>
Date: Fri, 23 Jan 2004 16:17:34 +0200

Hi Mark,

I have renamed the discussion to make it more easy to track, I hope you are 
comfortable with this.
I really hope we can together find if there is any problem and fix it.

>Question 1:
>a) a user establishes a Secondary PDP Context - this causes a new DCC
>session to be established

Yes.

>b) the user sends packets matching 2 separate charging rules at the client
>with different charging keys/rating groups (i.e. that need to be rated
>differently)
>c) the client establishes a new DCC sub-session within the existing session
>and asks for Service Units for both rating groups (rg1 and rg2)

Not necessarily, sub-sessions may be used only in case you want independent
quotas (Chris requirement). Otherwise, the client sends a CCR(UPD) to request 
service units for both the rating groups (rg1 and rg2) within the same
DCC session.

>d) server returns 10mb for rg1 and 10 minutes for rg2. This is within one
>sub-session, so I understand that this means that the user can have 10mb of
>rg1 traffic OR 10 minutes of rg2 traffic OR some combination (e.g. 5MB +
>5minutes - I will omit to mention combinations below for brevity). (btw -
>the fact that this is OR and not AND is far from clear in the draft and is
>rather important!).

Assuming the server maintains a single credit reservation and derives the 
service units from it considering that each rating group consumes the whole 
amount, this would be an OR. In other words, server reserves credit M and 
then determines rating R1 for rg1 and rating R2 for rg2. The two service 
units are M/R1=5MB and M/R2=5min.
For instance the reservation is $10, R1 is $2/MB and R2 is $2/min.

If the client keeps track of the fraction of reserved credit M that is 
consumed by each of the rating groups and report when the sum of the 
fractions >= 1 (i.e. 100% of the reserved credit is consumed), the reserved 
credit is always being used no matter what rg uses it and what portion 
a rg uses. There is no credit fragmentation at all.

>e) the user sends packets matching a 3rd charging rule for a 3rd rating
>group (rg3).
>
>Question: is the client *required* to establish a new sub-session for this
>flow ? If so, I understand the quota returned will be completely 
>independent
>from that provided in (d) above. So, the if the server returns 20mb then 
>the
>user is now entitled to 10MB of rg1 OR 10 min of rg2) AND (20mb of rg3) and
>we have credit fragmentation.
>

The client would send a CCR(UPD) reporting the units used by each of the 
rating groups and request units for rg1, rg2 and rg3. 
For example, let assume that 10% of the reservation of (d) was consumed by
rg1 and 30% was consumed by rg2 when the request is sent. The client reports
0.5MB of used units by rg1 and 1.5min used units by rg2.
 
The server may:

1- debit used units and make new reservation, or

2- work on the existing reservation if there is enough money left

Anyway, the result is that there will be some credit M from which service 
units are derived as in (d) (M/R1, M/R2 and M/R3).

In this example the server determines that rg1 consumed $1.5 (0.5MB*$2)
and rg2 consumed $3 (1.5min*$2), for a total of $4.5. The server decides
to work on the existing reservation and re-allocate the credit left that
is $5.5. The server also determines that R3 is $1/MB. The three service
units are then 2.75MB for rg1, 2.75min for rg2 and 5.5MB for rg3.

Here is the flow for the above scenario. I didn't use total-octets and 
seconds for simplicity.

                Service Element
 End-User           (CC client)                              CC Server
 |(1)PDP Act. Req.   |                                         |
 |------------------>|(2)CCR(initial)                          |  
 |                   |---------------------------------------->|
 |                   |                      (3)CCA(Success)    |
 |  (4)PDP Act. Res. |<----------------------------------------|
 |<------------------|                                         |
 :                   :                                         :
 |(5)Service-Requests (match RG1 and RG2)                      |
 |------------------>|(6)CCR(update,                           |
 |                   |       Requested-Units(Rating-Group 1),  |
 |                   |       Requested-Units(Rating-Group 2))  |
 |                   |---------------------------------------->|
 |                   |(7)CCA(Granted-Units(RG1, 5MB),          |
 |                   |       Granted-Units(RG2, 5min))         |
 |                   |<----------------------------------------|
 :                   :                                         :
 |(8)Service-Request (match RG3)                               |
 |------------------>|                                         |
 |                   |(9)CCR(update, Used-Units(RG1, 0.5MB),   |
 |                   |          Used-Units(RG2, 1.5min),       |
 |                   |       Requested-Units(Rating-Group 1),  |
 |                   |       Requested-Units(Rating-Group 2),  |
 |                   |       Requested-Units(Rating-Group 3))  | 
 |                   |---------------------------------------->|
 |                   |(10)CCA(Granted-Units(RG1, 2.75MB),      |
 |                   |       Granted-Units(RG2, 2.75min),      |
 |                   |       Granted-Units(RG3, 5.5MB))        |
 |                   |<----------------------------------------|

>If not, then the client must send a new request for the existing 
>subsession.
>Does it include all three rating groups and receive one quota covering all
>three (in an OR fashion) ? or does it send a request just for rg3, in which
>case how is the returned quota interpreted ?
>
>Question 2:
>(a) to (c) as Question 1:
>(d) the server determines that it cannot allocate a pool across rg1 and rg2
>because they are to be funded out of different accounts.
>
>Question: How does the server indicate this to the client ? Is this to do
>with the 'Credit-Pool-ID' AVP I saw mentioned in one of the emails. I 
>didn't
>find this in the draft - is it defined somewhere else ?
>

The Credit-Pool-ID AVP I think was proposed by Harri in http://www.merit.edu/mail.archives/aaa-wg/2004-01/msg00021.html, 
it is not defined in the draft at all. In the current draft the 
Credit-Pool-Id is not used, the server would reserve the same amount 
from account #1 and account #2, the amount to be reserved would be 
determined based on the account with smaller amount of credit. 
We have now two reservations M1 and M2 with the same amount of credit M. 
The server derives the service units as if there was only one credit 
reservation M (it can do it because M1==M2), so M/R1 and M/R2 are 
returned to the client.
However, if you feel that credit-pool information is better option I 
guess Harri could clarify how it is supposed to work.

For instance, account #1 hold $10 and account #2 hold $5.5. The server
reserves $5 from account #1 and $5 from account #2, it calculates then
the service units for rg1 and rg2 as if there was only single reservation.
The server then grants 2.5MB to rg1 and 2.5min to rg2.

The client keeps track of the fraction of reserved credit M that is consumed 
by each of the rating groups and report when the sum of the fractions >= 1 as 
in (d). The client reports back the used units by each of the rating groups, the 
server then debits on the appropriate account (units used by rg1 to account #1 
and units used by rg2 to account #2).

Continuing the numeric example, let assume that 10% of the reservation was 
consumed by rg1 and 90% was consumed by rg2 when the request is sent. 
The client reports 0.25MB of used units by rg1 and 2.25min of used units by 
rg2. The server determines that rg1 consumed $0.5 (0.25MB*$2)
and rg2 consumed $4.5 (2.25min*$2), it then deducts $0.5 from account #1 and
$4.5 from account #2. Now there is $9.5 letf in account #1 and $1 in account #2.
Let assume the credit left on account #2 is below the threshold limit, the
server will then only reserve money from account #1 and will deny traffic for
rg2. Credit reserved is now $5 from account #1 only, thus units granted to rg1 are
2.5MB.

Here is the flow for the above scenario. I didn't use total-octets and 
seconds for simplicity.

                Service Element
 End-User           (CC client)                              CC Server
 |(1)PDP Act. Req.   |                                         |
 |------------------>|(2)CCR(initial)                          |  
 |                   |---------------------------------------->|
 |                   |                      (3)CCA(Success)    |
 |  (4)PDP Act. Res. |<----------------------------------------|
 |<------------------|                                         |
 :                   :                                         :
 |(5)Service-Requests (match RG1 and RG2)                      |
 |------------------>|(6)CCR(update,                           |
 |                   |       Requested-Units(Rating-Group 1),  |
 |                   |       Requested-Units(Rating-Group 2))  |
 |                   |---------------------------------------->|
 |                   |(7)CCA(Granted-Units(RG1,2.5MB),         |
 |                   |       Granted-Units(RG2,2.5min))        |
 |                   |<----------------------------------------|
 :                   :                                         :
 |       (8) whole reservation used                            |
 |                   |(9)CCR(update, Used-Units(RG1, 0.25MB),  |
 |                   |          Used-Units(RG2, 2.25min),      |
 |                   |       Requested-Units(Rating-Group 1),  |
 |                   |       Requested-Units(Rating-Group 2))  | 
 |                   |---------------------------------------->|
 |                   |(10)CCA(Granted-Units(RG1, 2.5MB),       |
 |                   |       Granted-Units(RG2, 0min(i.e. deny))),
 |                   |<----------------------------------------|

>Question 3:
>(a) to (d) as Question 1:
>The server wants to indicate that the quota provided for rg1 is only valid
>for 1 hour, after which re-authorisation must be sought. I guess the server
>includes the Validity-Time AVP to indicate this.
>
>Question: The Validity-Time seems to be associated with the whole 
>CC-Answer,
>not with one of the rating groups - so am I correct in assuming that all 
>the
>rating groups within this sub-session need to be re-authorised at once ?

Yes, the Validity-Time is per CC session.
We thought that what really matter is the burning time of the credit 
reservation M. If the client keeps track of the fraction of M consumed by 
each of the rating groups and report when the sum of the fractions >= 1, the 
reserved credit is always being used no matter who use it. Then the reservation
is not staying in the client in vain.
The server would set the Validity-Time to 1 hour. If it expires is because 
no rg1 nor rg2 consumed the allotted credit. In case both rg1 and rg2 have a 
validity time, the Validity-Time AVP would be set to the lowest value.

When Validity-Time expires the client reports the units used by rg 1 and rg2 
and requests units for rg1 and rg2.

Since we assume that the server derives service units from a single credit 
reservation as explained in (d), even though you would associate the timer 
to rg1 you would need to report both rg1 and rg2 in the CCR(UPD). This is 
because you cannot leave service units running in the client while the 
server is doing operations on the credit reservation from which these
units are derived.

Regards
Marco

---

From: <[email-masked]>
Date: Fri, 23 Jan 2004 17:07:36 +0200

Hi again,

> units are then 2.75MB for rg1, 2.75min for rg2 and 5.5MB for rg3.

Ouch...I just notice there was a small mistake in the numeric
example. Of course it should be:

In this example the server determines that rg1 consumed $1 (0.5MB*$2)
and rg2 consumed $3 (1.5min*$2), for a total of $4. The server decides
to work on the existing reservation and re-allocate the credit left that
is $6. The server also determines that R3 is $1/MB. The three service
units are then 3MB for rg1, 3min for rg2 and 6MB for rg3.

                Service Element
 |                   |(10)CCA(Granted-Units(RG1, 3MB),         |
 |                   |       Granted-Units(RG2, 3min),         |
 |                   |       Granted-Units(RG3, 6MB))          |

Regards
Marco

---

From: <[email-masked]>
Date: Mon, 26 Jan 2004 16:03:56 +0200

Hi Mark,

>Thanks for these explanations - I think I understand how the mechanism is
>supposed to work now, but just to check, assuming a single sub-session
>within a session:
>
>When the client needs authorisation for a new flow, or re-authorisation of
>an existing one (Validity-time timeout etc.) it must always return a
>CCR(UPD) containing the units used for all ongoing flows. Then the server
>will re-authorise all of these, potentially making a new credit 
>reservation.
>Right ?
>
>"This is because you cannot leave service units running in the client while
>the
>server is doing operations on the credit reservation from which these units
>are derived."

Yes, within a DCC session/sub-session when the client need to authorize a 
new service flow or re-authorize an existing one it must return CCR(UPD) 
containing the units used for all ongoing service flows.
Note that re-authorization of already authorized service flows doesn't imply 
service interruption since the new received service units apply from the point 
when the CCR(UPD) was sent, as stated in section 5.2:

   "When the used units are reported to the credit-control server the
   credit-control client will not have any units in its possession before
   new granted units are received from the credit-control server. When
   the new granted units are received from the credit-control server
   these units apply from the point where the measurement of the reported
   used units stopped."

>Secondly, parameters such as Validity-Time are associated with the whole
>sub-session, so if different flows have different Validity-Times then 
>server
>uses the lowest one.

Correct. This is equivalent to set Validity-Time associated to each of the 
service flows, since the first that expires will cause all the others to be 
reported.

>Thirdly, when flows within a sub-session are funded from separate accounts,
>the server must make reservations 'of equivalent value' from each accounts.
>The client will request re-authorisation when a total of one times this
>value have been used by the user.

Correct. Of course the client may also request re-authorization upon other
events as well e.g. Validity-Time expires etc.

>Finally, the client has a choice of requesting a single reservation shared
>across multiple flows, or a separate reservation for each flow. It does 
>this
>by establishing a single subsession  in the former case of separate
>sub-sessions for each flow in the latter case.

Correct. In the former case the client can even not use a sub-session at all 
as in the example I sent. The client would establish one DCC session per each 
of the PDP context a subscriber open to a given APN, no need of sub-sessions.
Alternatively secondary PDP context may cause DCC sub-session, this 
sub-session controls all the service flows carried in that PDP context.

In the latter case the client establishes a single sub-session for each flow 
by requesting authorization/re-authorization only for a single rating-group or 
service-identifier within the sub-session.

Question to you Mark: we thought that would be enough to integrate some
text in existing sections to address the multiple services in a user's
session feature, but apparently it is not clear how things are supposed
to work. Do you think this feature should have its own sub-section 
under e.g. section 5 where all the aspects we discussed would be
somehow included?

Regards
Marco

---

From: <[email-masked]>
Date: Mon, 26 Jan 2004 16:45:19 +0200

>However, if I were you I'd hold off on drafting anything until you have seen our promised detailed last call issues/proposals.
 
Yes of course.
 
Marco

-----Original Message-----
From: ext Mark Watson [mailto:[email-masked]]
Sent: 26 January, 2004 16:25
To: Stura Marco (Nokia-NET/Helsinki)
Cc: Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka (Nokia-NET/Tampere); [email-masked]'; [email-masked]'; [email-masked]'; Alexander Benni (Nokia-NET/Espoo); [email-masked]'; Koskinen Juha-Pekka (Nokia-NET/Tampere); Christopher Richards; Javier Gonzalez Gallego; [email-masked]'
Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussion

Hi Marco, 

Thanks. 

To answer your question, then yes, I think a clearer description in its own section would probably be useful. 

However, if I were you I'd hold off on drafting anything until you have seen our promised detailed last call issues/proposals.

Regards, 

Mark 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: 26 January 2004 14:04 
To: Watson, Mark [MOP:EP10:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Richards, Christopher [RICH2:2Q40:EXCH]; Gonzalez Gallego, Javier [MOP:UNKN:EXCH]; [email-masked]

Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussion 

Hi Mark, 

>Thanks for these explanations - I think I understand how the mechanism 
>is supposed to work now, but just to check, assuming a single 
>sub-session within a session: 
> 
>When the client needs authorisation for a new flow, or re-authorisation 
>of an existing one (Validity-time timeout etc.) it must always return a 
>CCR(UPD) containing the units used for all ongoing flows. Then the 
>server will re-authorise all of these, potentially making a new credit 
>reservation. Right ? 
> 
>"This is because you cannot leave service units running in the client 
>while the server is doing operations on the credit reservation from 
>which these units are derived." 

>Secondly, parameters such as Validity-Time are associated with the 
>whole sub-session, so if different flows have different Validity-Times 
>then server uses the lowest one. 

>Thirdly, when flows within a sub-session are funded from separate 
>accounts, the server must make reservations 'of equivalent value' from 
>each accounts. The client will request re-authorisation when a total of 
>one times this value have been used by the user. 

Correct. Of course the client may also request re-authorization upon other events as well e.g. Validity-Time expires etc.

>Finally, the client has a choice of requesting a single reservation 
>shared across multiple flows, or a separate reservation for each flow. 
>It does this by establishing a single subsession  in the former case of 
>separate sub-sessions for each flow in the latter case. 

Correct. In the former case the client can even not use a sub-session at all 
as in the example I sent. The client would establish one DCC session per each 
of the PDP context a subscriber open to a given APN, no need of sub-sessions. Alternatively secondary PDP context may cause DCC sub-session, this 

Question to you Mark: we thought that would be enough to integrate some text in existing sections to address the multiple services in a user's session feature, but apparently it is not clear how things are supposed to work. Do you think this feature should have its own sub-section 

under e.g. section 5 where all the aspects we discussed would be somehow included? 

Regards 
Marco