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

From: "Mark Watson" <[email-masked]>
Date: Fri, 23 Jan 2004 16:14:28 -0000

HI Marco,

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.

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.

Let me know if I've got it right!

Harri,

I'd be interested learning more about the Credit-Pool-ID that you referred
to in your earlier mail.

Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 23 January 2004 14:18
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: [AAA-WG]: multiple services in a user session, tech. discussion

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: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Mon, 26 Jan 2004 14:59:06 +0100

Hi Mark,

>I'd be interested learning more about the Credit-Pool-ID that
>you referred to in your earlier mail. 

Marco illustrated in previous mail how multiple accounts are supported
in draft 02 in a way transparently to the client. 

Another option may be to let the server indicate to the client what are the flows 
that are funded from different accounts in the answer to the first CCR(initial)
request. This can be seen as enhancement to the "Multiple services in a user's
session, independent quotas" issue which we sent:
http://www.merit.edu/mail.archives/aaa-wg/2004-01/msg00003.html 

It is stated in the draft that all the services subject to the same rate are 
part of the same rating group. On the other hand, user can have several accounts
for different services and in which case reservation should be done from the right
account based on Service-Id. So it can be happen, that the server can notice that
two services belonging same rating group should funded out of different accounts 
and thus own sub-session would be needed for both services, if independent control
of allocated quotas are required.

To avoid this happen, The Credit-Pool-Id AVP might help. In CCA[initial] Credit-Pool-Id
AVP can be included in the G-S-U to point out which Rating-Group/Services requires
own sub-sessions. The client would then open a sub-session for each of these pools 
whenever a service request matching the relevant filter is met.
An example of this method is shown in figure below:

End-User           (CC client)                              CC Server
 |(1)User logon      |                                         |
 |------------------>|(2)CCR(initial, Service-Id(access))      |
 |                   |---------------------------------------->|
 |                   |(3)CCA(Granted-Units(Time),              |
 |                   |       Granted-Units(Rating-Group 1,     |
 |                   |                     Service-Id 1,       |
 |                   |                     Service-Id 2,       |
 |                   |                     Credit-Pool 1),     |
 |                   |       Granted-Units(Rating-Group 1,     |
 |                   |                     Service-Id 3,       |
 |                   |                     Credit-Pool 2),     |
 |                   |       Granted-Units(Rating-Group 2,     |
 |                   |                     Service-Id 4,       |
 |                   |                     Service-Id 5,       |
 |                   |                     Credit-Pool 3))     |
 |                   |<----------------------------------------|
 :                   :                                         :
 |(4)Service-Request (Service 1)                               |
 |------------------>|(5)CCR(initial,sub-session 1,            |
 |                   |       Requested-Units(Rating-Group 1,   |
 |                   |                       Service-Id 1))    |
 |                   |---------------------------------------->|
 |                   |(6)CCA(Granted-Units(Rating-Group 1,     |
 |                   |                     Service-Id 1,       |
 |                   |                     Total-Octets))      |
 |                   |<----------------------------------------|
 :                   :                                         :
 |(7)Service-Request (Service 3)                               |
 |------------------>|(8)CCR(initial,sub-session 2,            |
 |                   |       Requested-Units(Rating-Group 1,   |
 |                   |                       Service-Id 3))    |
 |                   |---------------------------------------->|
 |                   |(9)CCA(Granted-Units(Rating-Group 1,     |
 |                   |                     Service-Id 3,       |
 |                   |                     Total-Octets))      |
 |                   |<----------------------------------------|
:                   :                                         :

Regards........Harri

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 26 Jan 2004 14:23:00 -0000

Harri,

Yes, something like this would address one of our concerns. Any reason why
the client needs to establish new sub-sessions for the separate pools ? Why
can't they be managed as separate pools within a single (sub-)session ?

Regards...Mark

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: 26 January 2004 13:59
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]'
Cc: [email-masked]'; [email-masked]'; Leena
Mattila (TU/LMF); [email-masked]'; [email-masked]';
[email-masked]'; Patrik Teppo (KA/EAB);
[email-masked]'; Richards, Christopher [RICH2:2Q40:EXCH];
Gonzalez Gallego, Javier [MOP:UNKN:EXCH]
Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi
on

Hi Mark,

>I'd be interested learning more about the Credit-Pool-ID that you 
>referred to in your earlier mail.

Marco illustrated in previous mail how multiple accounts are supported in
draft 02 in a way transparently to the client. 

Another option may be to let the server indicate to the client what are the
flows 
that are funded from different accounts in the answer to the first
CCR(initial) request. This can be seen as enhancement to the "Multiple
services in a user's session, independent quotas" issue which we sent:
http://www.merit.edu/mail.archives/aaa-wg/2004-01/msg00003.html 

part of the same rating group. On the other hand, user can have several
accounts for different services and in which case reservation should be done
from the right account based on Service-Id. So it can be happen, that the
server can notice that two services belonging same rating group should
funded out of different accounts 
and thus own sub-session would be needed for both services, if independent
control of allocated quotas are required.

To avoid this happen, The Credit-Pool-Id AVP might help. In CCA[initial]
Credit-Pool-Id AVP can be included in the G-S-U to point out which
Rating-Group/Services requires own sub-sessions. The client would then open
a sub-session for each of these pools 
whenever a service request matching the relevant filter is met. An example
of this method is shown in figure below:

Regards........Harri

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 26 Jan 2004 14:25:07 -0000

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

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: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Tue, 27 Jan 2004 15:32:53 +0100

Hi Mark,

>Any reason why the client needs to establish new sub-sessions for the separate pools ?
>Why can't they be managed as separate pools within a single (sub-)session ?

To manage separate pools within a single (sub-)session it would require it's own 
CCR/CCA pair and it's own instance of the DCC state machine as well as it's own Tx 
timer. This way we have created sort of implicit sub-sessions multiplexed within a
(sub-)session, but it makes more complex the failure handling, setting correct 
combination of failure handling AVPs and handle functionalities such as the GST.

What we would eventually save as compared to explicit sub-session are couple of 
messages to close the sub-session when the user logoff (or the PDP context is closed).
However, it is always possible to send only the CCR(termination) for the main session
including multiple instances of the U-S-U. This would implicitly close all the sub-
sessions, the server is always able to deduct used credit from the right account because
we have associated service-id to the U-S-U. There is no difference in signaling load,
but much cleaner failure handling etc. if we explicitly signal sub-sessions.

The sequence below shows that same signalling load is needed both implicit and explicit
sub-session handling cases, but having explicit sub-session simplify the failure handling 
etc.

Flow example with implicit sub-sessions:
End-User           (CC client)                              CC Server
 |(1)User logon      |                                         |
 |------------------>|(2)CCR(initial, Service-Id(access))      |
 |                   |---------------------------------------->|
 |                   |(3)CCA(Granted-Units(Time),              |
 |                   |       Granted-Units(Rating-Group 1,     |
 |                   |                     Service-Id 1,       |
 |                   |                     Service-Id 2,       |
 |                   |                     Credit-Pool 1),     |
 |                   |       Granted-Units(Rating-Group 1,     |
 |                   |                     Service-Id 3,       |
 |                   |                     Credit-Pool 2),     |
 |                   |       Granted-Units(Rating-Group 2,     |
 |                   |                     Service-Id 4,       |
 |                   |                     Service-Id 5,       |
 |                   |                     Credit-Pool 3))     |
 |                   |<----------------------------------------|
 :                   :                                         :
 |(4)Service-Request (Service 1)                               |
 |------------------>|(5)CCR(update,                           |
 |                   |       Requested-Units(Rating-Group 1,   |
 |                   |                       Service-Id 1))    |
 |                   |---------------------------------------->|
 |                   |(6)CCA(Granted-Units(Rating-Group 1,     |
 |                   |                     Service-Id 1,       |
 |                   |                     Total-Octets))      |
 |                   |<----------------------------------------|
 :                   :                                         :
 |(7)Service-Request (Service 3)                               |
 |------------------>|(8)CCR(update,                           |
 |                   |       Requested-Units(Rating-Group 1,   |
 |                   |                       Service-Id 3))    |
 |                   |---------------------------------------->|
 |                   |(9)CCA(Granted-Units(Rating-Group 1,     |
 |                   |                     Service-Id 3,       |
 |                   |                     Total-Octets))      |
 |                   |<----------------------------------------|
 :                   :                                         :
 |(10)User logoff    |                                         |
 |------------------>|(11)CCR(termination, U-S-U(Service-Id(access)),
 |                   |               U-S-U(RG1, Service-Id 3), |
 |                   |               U-S-U(RG1, Service-Id 1), |
 |                   |---------------------------------------->|

Flow example with explicit sub-sessions:
End-User           (CC client)                              CC Server
 |(1)User logon      |                                         |
 |------------------>|(2)CCR(initial, Service-Id(access))      |
 |                   |---------------------------------------->|
 |                   |(3)CCA(Granted-Units(Time),              |
 |                   |       Granted-Units(Rating-Group 1,     |
 |                   |                     Service-Id 1,       |
 |                   |                     Service-Id 2,       |
 |                   |                     Credit-Pool 1),     |
 |                   |       Granted-Units(Rating-Group 1,     |
 |                   |                     Service-Id 3,       |
 |                   |                     Credit-Pool 2),     |
 |                   |       Granted-Units(Rating-Group 2,     |
 |                   |                     Service-Id 4,       |
 |                   |                     Service-Id 5,       |
 |                   |                     Credit-Pool 3))     |
 |                   |<----------------------------------------|
 :                   :                                         :
 |(4)Service-Request (Service 1)                               |
 |------------------>|(5)CCR(initial,sub-session 1,            |
 |                   |       Requested-Units(Rating-Group 1,   |
 |                   |                       Service-Id 1))    |
 |                   |---------------------------------------->|
 |                   |(6)CCA(Granted-Units(Rating-Group 1,     |
 |                   |                     Service-Id 1,       |
 |                   |                     Total-Octets))      |
 |                   |<----------------------------------------|
 :                   :                                         :
 |(7)Service-Request (Service 3)                               |
 |------------------>|(8)CCR(initial,sub-session 2,            |
 |                   |       Requested-Units(Rating-Group 1,   |
 |                   |                       Service-Id 3))    |
 |                   |---------------------------------------->|
 |                   |(9)CCA(Granted-Units(Rating-Group 1,     |
 |                   |                     Service-Id 3,       |
 |                   |                     Total-Octets))      |
 |                   |<----------------------------------------|
 :                   :                                         :
 |(10)User logoff    |                                         |
 |------------------>|(11)CCR(termination, U-S-U(Service-Id(access)),
 |                   |               U-S-U(RG1, Service-Id 3), |
 |                   |               U-S-U(RG1, Service-Id 1)) |
 |                   |---------------------------------------->|

---

From: "Mark Watson" <[email-masked]>
Date: Tue, 27 Jan 2004 16:13:52 -0000

HI Harri,

Ok, so you flows show no actual units being provided to the client in the
answer to the initial request. So the client is just learning the
Service/Rating-Group <> Credit Pool mapping at this stage. Then it handles
each Credit Pool in a separate sub-session.

Would it also be possible to return actual Service Units in this initial
response ? How are those then 'transferred' into the new per Credit Pool
sub-sessions ?

I'm thinking of the case where the client does not indicate the required
Service/Rating-Groups to the server until they are actually used. And it has
no information about Service/Rating <> Credit Pool mapping when it requests
the units.

I wasn't sure why you would need a separate CC state machine for each credit
pool - presumably we can shut off/redirect traffic within one credit pool
without closing the (sub-)session by returning zero units and attaching the
appropriate redirect AVPs etc. to the G-S-U, right ?

Regards...Mark

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: 27 January 2004 14:33
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]'
Cc: [email-masked]'; [email-masked]'; Leena

Hi Mark,

>Any reason why the client needs to establish new sub-sessions for the 
>separate pools ? Why can't they be managed as separate pools within a 
>single (sub-)session ?

To manage separate pools within a single (sub-)session it would require it's
own 
CCR/CCA pair and it's own instance of the DCC state machine as well as it's
own Tx 
timer. This way we have created sort of implicit sub-sessions multiplexed
within a (sub-)session, but it makes more complex the failure handling,
setting correct 
combination of failure handling AVPs and handle functionalities such as the
GST.

What we would eventually save as compared to explicit sub-session are couple
of 
messages to close the sub-session when the user logoff (or the PDP context
is closed). However, it is always possible to send only the CCR(termination)
for the main session including multiple instances of the U-S-U. This would
implicitly close all the sub- sessions, the server is always able to deduct
used credit from the right account because we have associated service-id to
the U-S-U. There is no difference in signaling load, but much cleaner
failure handling etc. if we explicitly signal sub-sessions.

The sequence below shows that same signalling load is needed both implicit
and explicit sub-session handling cases, but having explicit sub-session
simplify the failure handling 
etc.

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Wed, 28 Jan 2004 09:07:03 +0100

Hi Mark,

To answer right things, I would like to ask first from you
a few questions to be sure that I have read your scenario 
in right way. 

I assume that you would like to have solution, where:

CCR[intial] is used to open and reserve units for main 
session as well as for sub-session(s). Then the CCA[intial]
carries G-S-U for main session and sub-session(s). 
CCR[terminate] closes and reports units related both the
main session and sub-session(s), right? 

I've understood that one credit pool would correspond to one 
independent quota. i.e. with one CCR one would report used 
units for one credit pool.
Do you mean that there could be several credit pools within one
sub-session? I.e. what's your definition for 'independent quota',
one service, one pool(account) or one (sub)-session, or something 
else?

Regards............Harri

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: 27. tammikuuta 2004 18:14
To: Harri Hakala (TU/LMF); [email-masked]'
Cc: [email-masked]'; [email-masked]'; Leena Mattila (TU/LMF); [email-masked]'; [email-masked]'; [email-masked]'; Patrik Teppo (KA/EAB); [email-masked]'; Christopher Richards; Javier Gonzalez Gallego
Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on

HI Harri, 
Ok, so you flows show no actual units being provided to the client in the answer to the initial request. So the client is just learning the Service/Rating-Group <> Credit Pool mapping at this stage. Then it handles each Credit Pool in a separate sub-session.
Would it also be possible to return actual Service Units in this initial response ? How are those then 'transferred' into the new per Credit Pool sub-sessions ?
I'm thinking of the case where the client does not indicate the required Service/Rating-Groups to the server until they are actually used. And it has no information about Service/Rating <> Credit Pool mapping when it requests the units.
I wasn't sure why you would need a separate CC state machine for each credit pool - presumably we can shut off/redirect traffic within one credit pool without closing the (sub-)session by returning zero units and attaching the appropriate redirect AVPs etc. to the G-S-U, right ?
Regards...Mark

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 28 Jan 2004 12:07:22 -0000

Hi Harri,

I am thinking of the case where the client requests units for several
Rating-Groups in a single CCR[initial] for the session and the server
determines that these groups cannot share a single pool of credit.

You show this in your flow, but you do not show any actual *units* being
returns in the CCA[initial] - just the information about which Rating-Group
goes with which Credit-Pool.

So, then it is necessary for the client to make a new sub-session for each
Credit-Pool.

The question is whether units for all these Rating-Groups can be returned in
the CCA[initial] ? And if these units are returned, do they continue to be
managed within the main session, or are they 'transferred' to separate
sub-sessions for each credit pool.

In my understanding a 'quota' is a unit of granularity corresponding to a
bundle of identially metered and rated services (i.e. a Rating-Group).
Clearly it is desirable that the credit used by multiple such bundles of
services is pooled to avoid credit fragmentation.

Equally clearly, the separate bundles of services need to be handled
independently in terms of termination/redirect action etc.

As a preference, I would have these handled independently in terms of
re-authorisation and addition of new services. Although the draft allows for
re-authorisation without service interruption, some of our customers see
this as a fraud window and would like to drop/buffer packets during
re-authorisation.

Finally, the association of Rating-Groups into credit pools needs to be
under control of the server, not the client.

Now, how this maps to sessions, sub-sessions and any new 'Credit-Pool'
AVP(s) is what we need to work out - I don't have a strong opinion about
that as long as it works, but we will make a concrete proposal as promised.

Regards...Mark

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: 28 January 2004 08:07
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]'
Cc: [email-masked]'; [email-masked]'; Leena

Hi Mark,

CCR[intial] is used to open and reserve units for main 
session as well as for sub-session(s). Then the CCA[intial] carries G-S-U
for main session and sub-session(s). 
CCR[terminate] closes and reports units related both the
main session and sub-session(s), right? 

I've understood that one credit pool would correspond to one 
independent quota. i.e. with one CCR one would report used 
units for one credit pool.
Do you mean that there could be several credit pools within one sub-session?
I.e. what's your definition for 'independent quota', one service, one
pool(account) or one (sub)-session, or something 
else?

Regards............Harri

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: 27. tammikuuta 2004 18:14
To: Harri Hakala (TU/LMF); [email-masked]'
Cc: [email-masked]'; [email-masked]'; Leena
Mattila (TU/LMF); [email-masked]'; [email-masked]';
[email-masked]'; Patrik Teppo (KA/EAB);
[email-masked]'; Christopher Richards; Javier Gonzalez
Gallego
Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi
on

HI Harri, 
Ok, so you flows show no actual units being provided to the client in the
answer to the initial request. So the client is just learning the
Service/Rating-Group <> Credit Pool mapping at this stage. Then it handles
each Credit Pool in a separate sub-session. Would it also be possible to
return actual Service Units in this initial response ? How are those then
'transferred' into the new per Credit Pool sub-sessions ? I'm thinking of
the case where the client does not indicate the required
Service/Rating-Groups to the server until they are actually used. And it has
no information about Service/Rating <> Credit Pool mapping when it requests
the units. I wasn't sure why you would need a separate CC state machine for
each credit pool - presumably we can shut off/redirect traffic within one
credit pool without closing the (sub-)session by returning zero units and
attaching the appropriate redirect AVPs etc. to the G-S-U, right ?
Regards...Mark

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Wed, 28 Jan 2004 15:04:10 +0100

Hi Mark,

>The question is whether units for all these Rating-Groups can be returned in the CCA[initial] ?
>And if these units are returned, do they continue to be managed within the main session, or are
>they 'transferred' to separate sub-sessions for each credit pool.
The challenge may be how to 'transfer' each credit pool to sub-session.
Basically sub-sessions are initiated and sub-session Ids are created by client, but
in this case the server would implicitly open sub-sessions with Answer message.
But It would be rather difficult also handle several credit pools within one session.

>pool - presumably we can shut off/redirect traffic within one credit pool without
>closing the (sub-)session by returning zero units and attaching the appropriate 
>redirect AVPs etc. to the G-S-U, right ?
If there is a need to report used units per credit pool within one (sub)-session, and
there are several credit pools in the (sub)-session, then on reason is the failure handling,
another reason is that when in the session you are in pending state waiting for an answer
you cannot send a new CCR[update]) until the session move to open state (i.e. until the answer
is received). This means that if a credit-pool need to be re-authorized while 
another credit-pool re-authorization is ongoing, you cannot do it in real-time
and you need to queue the request. What happen if the answer is delayed for some
reason? If you really want to treat the pools independently, than you need
an instance of the DCC state machine for each credit pool.

>Now, how this maps to sessions, sub-sessions and any new 'Credit-Pool' AVP(s) is 
>what we need to work out - I don't have a strong opinion about that as long as it
>works, but we will make a concrete proposal as promised.
I think it will be easier to discuss this and provide comments once we have seen
your proposal.

Regards........Harri

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: 28. tammikuuta 2004 14:07
To: Harri Hakala (TU/LMF); [email-masked]'
Cc: [email-masked]'; [email-masked]'; Leena Mattila (TU/LMF); [email-masked]'; [email-masked]'; [email-masked]'; Patrik Teppo (KA/EAB); [email-masked]'; Christopher Richards; Javier Gonzalez Gallego
Subject: RE: [AAA-WG]: multiple services in a user session, tech. discussi on

Hi Harri, 
I am thinking of the case where the client requests units for several Rating-Groups in a single CCR[initial] for the session and the server determines that these groups cannot share a single pool of credit.
You show this in your flow, but you do not show any actual *units* being returns in the CCA[initial] - just the information about which Rating-Group goes with which Credit-Pool.
So, then it is necessary for the client to make a new sub-session for each Credit-Pool. 
The question is whether units for all these Rating-Groups can be returned in the CCA[initial] ? And if these units are returned, do they continue to be managed within the main session, or are they 'transferred' to separate sub-sessions for each credit pool.
In my understanding a 'quota' is a unit of granularity corresponding to a bundle of identially metered and rated services (i.e. a Rating-Group). Clearly it is desirable that the credit used by multiple such bundles of services is pooled to avoid credit fragmentation.
Equally clearly, the separate bundles of services need to be handled independently in terms of termination/redirect action etc.
As a preference, I would have these handled independently in terms of re-authorisation and addition of new services. Although the draft allows for re-authorisation without service interruption, some of our customers see this as a fraud window and would like to drop/buffer packets during re-authorisation.
Finally, the association of Rating-Groups into credit pools needs to be under control of the server, not the client. 
Now, how this maps to sessions, sub-sessions and any new 'Credit-Pool' AVP(s) is what we need to work out - I don't have a strong opinion about that as long as it works, but we will make a concrete proposal as promised.
Regards...Mark

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 28 Jan 2004 14:52:43 -0000

Hi Harri,

Thanks for the continued clarifications...

You wrote:
>I think it will be easier to discuss this and provide comments once we have
seen your proposal.

However, I am trying to modify our proposal to accommodate the opinions
expressed in this discussion, so if I may, I will ask one further question:

Is to your opinion that in order to handle re-authorisation for separate
Rating-Groups independently then separate sub-sessions/state machines are
needed (either client or server initiated) ?

Is the same true if I want to provide different handling on credit
exhaustion - for example one Rating-Group is terminated, another redirected
and a further one allowed to continue 'into the red'.

Both the above are assuming that the separate Rating-Groups all draw from
the same credit pool.

Regards...Mark

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: 28 January 2004 14:04
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]'
Cc: [email-masked]'; [email-masked]'; Leena

Hi Mark,

>The question is whether units for all these Rating-Groups can be 
>returned in the CCA[initial] ? And if these units are returned, do they 
>continue to be managed within the main session, or are they 
>'transferred' to separate sub-sessions for each credit pool.
The challenge may be how to 'transfer' each credit pool to sub-session.
Basically sub-sessions are initiated and sub-session Ids are created by
client, but in this case the server would implicitly open sub-sessions with
Answer message. But It would be rather difficult also handle several credit
pools within one session.

>I wasn't sure why you would need a separate CC state machine for each 
>credit pool - presumably we can shut off/redirect traffic within one 
>credit pool without closing the (sub-)session by returning zero units 
>and attaching the appropriate redirect AVPs etc. to the G-S-U, right ?
If there is a need to report used units per credit pool within one
(sub)-session, and there are several credit pools in the (sub)-session, then
on reason is the failure handling, another reason is that when in the
session you are in pending state waiting for an answer you cannot send a new
CCR[update]) until the session move to open state (i.e. until the answer is
received). This means that if a credit-pool need to be re-authorized while 
another credit-pool re-authorization is ongoing, you cannot do it in
real-time and you need to queue the request. What happen if the answer is
delayed for some reason? If you really want to treat the pools
independently, than you need an instance of the DCC state machine for each
credit pool.

>AVP(s) is
I think it will be easier to discuss this and provide comments once we have
seen your proposal.

Regards........Harri

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: 28. tammikuuta 2004 14:07
To: Harri Hakala (TU/LMF); [email-masked]'
Cc: [email-masked]'; [email-masked]'; Leena

Hi Harri, 
I am thinking of the case where the client requests units for several
Rating-Groups in a single CCR[initial] for the session and the server
determines that these groups cannot share a single pool of credit. You show
this in your flow, but you do not show any actual *units* being returns in
the CCA[initial] - just the information about which Rating-Group goes with
which Credit-Pool. So, then it is necessary for the client to make a new
sub-session for each Credit-Pool. 
The question is whether units for all these Rating-Groups can be returned in
the CCA[initial] ? And if these units are returned, do they continue to be
managed within the main session, or are they 'transferred' to separate
sub-sessions for each credit pool. In my understanding a 'quota' is a unit
of granularity corresponding to a bundle of identially metered and rated
services (i.e. a Rating-Group). Clearly it is desirable that the credit used
by multiple such bundles of services is pooled to avoid credit
fragmentation. Equally clearly, the separate bundles of services need to be
handled independently in terms of termination/redirect action etc. As a
preference, I would have these handled independently in terms of
re-authorisation and addition of new services. Although the draft allows for
re-authorisation without service interruption, some of our customers see
this as a fraud window and would like to drop/buffer packets during
re-authorisation. Finally, the association of Rating-Groups into credit
pools needs to be under control of the server, not the client. 
Now, how this maps to sessions, sub-sessions and any new 'Credit-Pool'
AVP(s) is what we need to work out - I don't have a strong opinion about
that as long as it works, but we will make a concrete proposal as promised.
Regards...Mark

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Thu, 29 Jan 2004 13:02:11 +0100

Hi Mark,

>needed (either client or server initiated) ?
If there is a common credit pool for Rating-Groups/services, why RGs need
to be reported independently? In other words isn't it enough to have one
re-authorization request, where used units are reported and new units are 
required per RGs (compare flow X) and to have one re-authorization answer 
where the common quota associated with the RGs is returned? 

Anyhow, I think that if there is need for own re-authorization per RG within the 
(sub)-session, then separate state machines are needed per RG.

>Is the same true if I want to provide different handling on credit exhaustion
>- for example one Rating-Group is terminated, another redirected and a further
>one allowed to continue 'into the red'.
>Both the above are assuming that the separate Rating-Groups all draw from the 
>same credit pool. 
In my opinion, as long as there is no such situation where a credit
re-authorization request is sent to allocate more quota for one service
while indicating e.g. a redirect to refill server for another service then I don't
see a big problem. If one CCR would contain different credit allocation requests
for the same pool then this would require separate state machines. 

regards........harri

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 29 Jan 2004 13:38:28 -0000

Hi Harri,

Thanks - this makes things clearer.

To answer your questions, it should not be necessary to re-authorise all
quotas associated with a pool when a new one is to be added. The draft
allows for packet flow to continue during re-auth, but this is an issue of
service provider policy. If SP policy implies service interruption during
re-auth, we need to minimise the re-auths.

It's not the CCR which might contain different requests for different RGs,
but the CCA. This might indicate that one RG should be terminated or
redirected whilst another can continue. Clearer, service providers will have
different policies for different services with respect to handling on credit
exhaustion - e.g. some services can continue for a limited time.

...Mark

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: 29 January 2004 12:02
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]'
Cc: [email-masked]'; [email-masked]'; Leena

Hi Mark,

>Is to your opinion that in order to handle re-authorisation for 
>separate Rating-Groups independently then separate sub-sessions/state 
>machines are needed (either client or server initiated) ?
If there is a common credit pool for Rating-Groups/services, why RGs need to
be reported independently? In other words isn't it enough to have one
re-authorization request, where used units are reported and new units are 
required per RGs (compare flow X) and to have one re-authorization answer 
where the common quota associated with the RGs is returned? 

Anyhow, I think that if there is need for own re-authorization per RG within
the 
(sub)-session, then separate state machines are needed per RG.

>exhaustion
the 
In my opinion, as long as there is no such situation where a credit
re-authorization request is sent to allocate more quota for one service
while indicating e.g. a redirect to refill server for another service then I
don't see a big problem. If one CCR would contain different credit
allocation requests for the same pool then this would require separate state
machines. 

regards........harri

---

From: <[email-masked]>
Date: Thu, 29 Jan 2004 16:31:51 +0200

Hi Mark,
 
>To answer your questions, it should not be necessary to re-authorise all quotas associated with a pool when a new one is to be 
>added. 
 
What you say implies a new credit reservation to the same pool (i.e. account). Since the client doesn't report back the
units used from the current reservation, these quotas are running in the client and we cannot operate on the existing credit reservation. This may lead to situations where all the available credit resources have been allocated to the client, but not
actually used (ok, you can control with an idle timer but its not deterministic), when the server receives a request for a new
service/rg.  Also, high number of credit reservations may become a burden for the server etc. Is that what we want?
 
>The draft allows for packet flow to continue during re-auth, but this is an issue of service provider policy. If SP policy implies service
> interruption during re-auth, we need to minimise the re-auths.
 
I guess you are thinking to the fraud window during the re-authorization round-trip, right?
In the DCC we can get the fraud window to zero, that's why we have the final-unit-indication. If the client didn't receive the
final-unit-indication it is because there still credit in that pool and there is no risk of running out, otherwise it would have received the final-units with the action to be taken in the last CCA. 
 
>It's not the CCR which might contain different requests for different RGs, but the CCA. This might indicate that one RG should be 
>terminated or redirected whilst another can continue. Clearer, service providers will have different policies for different services with 
>respect to handling on credit exhaustion - e.g. some services can continue for a limited time.
 
I don't fully get your first statement "It's not the CCR which might contain different requets...". We have been discussing that the client may request quota only when the service/rg is actually used, how the server would know this if not indicated by the client? So, what do you exactly mean with that statement?
Concerning the different policies for different services/rg, perhaps  we need to have finer granularity for the actions and we need to find a solution for that.
 
Regards
Marco

---

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

Hi Marco,
 
Some comments below...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 29 January 2004 14:32
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]
Cc: [email-masked]; [email-masked];

Hi Mark,
 
>To answer your questions, it should not be necessary to re-authorise all
quotas associated with a pool when a new one is to be 
>added. 
 
What you say implies a new credit reservation to the same pool (i.e.
account). Since the client doesn't report back the
units used from the current reservation, these quotas are running in the
client and we cannot operate on the existing credit reservation. 

MW> Why not ? The server could instruct the client that the new service
should draw from the same pool as the existing ones, or it could supply an
additional credit reservation to be 'added' to the pool already running in
the client. Ok, so the *existing* mechanism in the draft cannot do this -
that is one of our points!

 This may lead to situations where all the available credit resources have
been allocated to the client, but not
actually used (ok, you can control with an idle timer but its not
deterministic), when the server receives a request for a new
service/rg.  Also, high number of credit reservations may become a burden
for the server etc. Is that what we want? 

MW> No, the burden on the server is higher if all existing quotas need to be
reported and re-authed/re-rated when a new service is added. We would prefer
that the server could just auth & rate the one new service which is to be
added.

>The draft allows for packet flow to continue during re-auth, but this is an
issue of service provider policy. If SP policy implies service
> interruption during re-auth, we need to minimise the re-auths.
 
I guess you are thinking to the fraud window during the re-authorization
round-trip, right?
In the DCC we can get the fraud window to zero, that's why we have the
final-unit-indication. If the client didn't receive the
final-unit-indication it is because there still credit in that pool and
there is no risk of running out, otherwise it would have received the
final-units with the action to be taken in the last CCA.  

MW> You are making an assumption that there are no other drains on the
credit in the server. Certainly the server can refuse to re-authorise a
service even if it didn't return the Final-Units-Indication. 

>It's not the CCR which might contain different requests for different RGs,
but the CCA. This might indicate that one RG should be 
>terminated or redirected whilst another can continue. Clearer, service
providers will have different policies for different services with 
>respect to handling on credit exhaustion - e.g. some services can continue
for a limited time.
 
I don't fully get your first statement "It's not the CCR which might contain
different requets...". We have been discussing that the client may request
quota only when the service/rg is actually used, how the server would know
this if not indicated by the client? So, what do you exactly mean with that
statement? 

MW> Sorry if it wasn't clear - this point was addressing a different
question in Harri's email. The point is just that the server may want to
indicate different handling for different Services/Rating-Groups. Some may
be terminated, some re-directed and others allowed to continue (still under
credit control).

Concerning the different policies for different services/rg, perhaps  we
need to have finer granularity for the actions and we need to find a
solution for that. 

MW> Yes, I think that is one point exactly. But from Harri's comments it
seemed not possible to do that unless a separate state machine was
associated with each quota, rather than with each (sub-)session.  
 
Anyway, proposals to address these points to follow by eod - we are not
stuck on any single solution & I'm hopeful we can work out some agreeable
soution between us.
 
...Mark

Regards
Marco