Subject: [AAA-WG]: DCC: credit pooling in flow X

From: "Christopher Richards" <[email-masked]>
Date: Thu, 18 Dec 2003 12:08:55 -0600

Hi All,

In Appendix A, flow X of the DCC draft, there is a short description of a
mechanism to sum quota resources in order to determine when to re-authorize
the quotas. Here is the text:

A.10 Flow X 

...

   The calculated quotas are conveyed to the credit control client in the 
   CCA message, each quota associated with the appropriate Rating-Group 
   or Service-Identifier. At this point the credit control client just 
   need to track the fraction of reserved credit used by the 
   corresponding service or Rating-Group, when the sum of the fractions 
   reaches 100% the credit control client sends an intermediate 
   interrogation since the whole amount of reserved credit is consumed. 
    
   If the credit control client initializes a counter C for each of the 
   received quota Q (C1 for Q1, C2 for Q2 ... Cn for Qn), the 
   intermediate interrogation will be sent when (C1/Q1 + C1/Q2 + ... + 
   Cn/Qn)>= 1.  
    
   Continuing the example, the end user uses 10 Mbytes from Rating-Group 
   1 and 10minutes from Rating-Group 2. This means that Rating-Group 1 
   consumed 50% of the reservation and Rating-Group 2 consumed the 
   remaining 50%. 0.5 + 0.5 >=1, so the credit control client sends an 
   intermediate interrogation to report the used units and request new 
   ones. 

My concern is that this method of summing the quota use should be clearly
stated as an implementation choice and not a mechanism that is mandated by
the DCC client. 
The mechanism outlined has some pitfalls and there are other mechanisms of
implementing credit sharing.

With this in mind, I recommend making the following editorial change from
the text above to:

A.10 Flow X 

...

   The calculated quotas are conveyed to the credit control client in the 
   CCA message, each quota associated with the appropriate Rating-Group 
   or Service-Identifier. At this point the credit control client just 
   need to track the fraction of reserved credit used by the 
   corresponding service or Rating-Group. The credit-control client SHOULD
   provide a mechanism that avoids end user resource fragmentation, however,
   exact mechanism employed by the credit-control client is outside the
   scope of this document.

   One possible mechanism that may be used is to track the fraction of
   reserved credit, when the sum of the fractions reaches 100% the credit
   control client sends an intermediate interrogation since the whole
   amount of reserved credit is consumed. Support of this mechanism by the
   credit-control client is optional.
    
   For example, if the credit control client initializes a counter C for
   each of the received quota Q (C1 for Q1, C2 for Q2 ... Cn for Qn), the 
   intermediate interrogation will be sent when (C1/Q1 + C1/Q2 + ... + 
   Cn/Qn)>= 1.  
    
   Continuing the example, the end user uses 10 Mbytes from Rating-Group 
   1 and 10minutes from Rating-Group 2. This means that Rating-Group 1 
   consumed 50% of the reservation and Rating-Group 2 consumed the 
   remaining 50%. 0.5 + 0.5 >=1, so the credit control client sends an 
   intermediate interrogation to report the used units and request new 
   ones. 

Best Regards, 
Chris.

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Fri, 19 Dec 2003 14:05:33 +0100

Hi Chris,

Nothing wrong in the proposal as such, but the flow X is only one example of the usage, it 
does not outrule other implementation options. As Marco stated in his mail, it seems that 
we are back to discussion how to allocate quota for multiple services in one credit control 
session and we need probably provide some guidelines to quota allocation in the section 5 
(Session Based Credit-control). But we should be careful for not re-inventing the sub-sessions.

The mechanism outlined has some pitfalls and there are other mechanisms of implementing credit sharing. 
To be able to avoid those pitfalls, could you clarify what are those.

Regards.....Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Christopher Richards
Sent: 18. joulukuuta 2003 20:09
To: [email-masked]
Subject: [AAA-WG]: DCC: credit pooling in flow X

Hi All, 

In Appendix A, flow X of the DCC draft, there is a short description of a mechanism to sum quota resources in order to determine when to re-authorize the quotas. Here is the text:

A.10 Flow X 

... 

    

My concern is that this method of summing the quota use should be clearly stated as an implementation choice and not a mechanism that is mandated by the DCC client. 

The mechanism outlined has some pitfalls and there are other mechanisms of implementing credit sharing. 

With this in mind, I recommend making the following editorial change from the text above to: 

A.10 Flow X 

... 

    

Best Regards, 
Chris.

---

From: "Christopher Richards" <[email-masked]>
Date: Fri, 19 Dec 2003 10:37:59 -0600

Hi Harri,
 
Thanks for your reply. So, I assume that the text change I proposed will be
added? I just want to make sure that it is clearly described as one possible
implementation.
 
As for the pitfalls of the described mechanism, I see the following:-

*	If a number of quotas are currently in use, but not being actively
used (or only used a little or just one of them is being used), it will take
some time to trigger a re-authorisation.
*	All user service may be interrupted if all quotas are required to be
re-authorised - even though the quotas have resources remaining.
*	It is not very deterministic. If a quota is allocated for some
resource amount, re-authorisation (& service interruption) is performed
based on the use of all the allocated quotas. 

This is not to say that it is completely without use. But it may not always
solve the problem it was trying to (credit fragmentation).

Cheers, 
Chris. 

Shasta Wireless Development 
Nortel Networks 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Friday, December 19, 2003 7:06 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]
Subject: RE: [AAA-WG]: DCC: credit pooling in flow X

Hi Chris,

Nothing wrong in the proposal as such, but the flow X is only one example of
the usage, it 
does not outrule other implementation options. As Marco stated in his mail,
it seems that 
we are back to discussion how to allocate quota for multiple services in one
credit control 
session and we need probably provide some guidelines to quota allocation in
the section 5 
(Session Based Credit-control). But we should be careful for not
re-inventing the sub-sessions.

Regards.....Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Christopher Richards
Sent: 18. joulukuuta 2003 20:09
To: [email-masked]
Subject: [AAA-WG]: DCC: credit pooling in flow X

Hi All, 

A.10 Flow X 

... 

    

A.10 Flow X 

... 

    

Best Regards, 
Chris.

---

From: "Stura Marco" <[email-masked]>
Date: Sat, 20 Dec 2003 10:35:20 +0200

>implementing credit sharing.

My concern Chris is that you didn't understand how the mechanism outlined in
FlowX works since we are not summing the quotas. Also, if everybody does 
what
He wants in server (to allocate credit and calculate quotas) and client (to 
decide
when to report) a. we'll never achieve interoperability that is the main 
reason
why standards exist and b. the service provider will risk negative credit or 
the
user will not be charged as expected.

I would suggest you better analyse the approach and you will see that the 
client
report when C1*R1+C2*R2+...+Cn*Rn>=a*Money Reservation.
Where C1, C2,...,Cn are the counters for each of the services running for 
the users,
R1 etc. are the rating parameters and a is a security factor to ensure that 
the money
reservation is never exceeded.
And yes there is one pitfall, this approach assume linear rating and doesn't 
consider
e.g. models where some discount is applied upon some event, for instance you 
have
generated 10MB of traffic using service 1,2 and 3 then you get 30% discount 
on these
services. A solution to this pitfall could to be worked out during WGLC.

Br
Marco

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

---

From: "Stura Marco" <[email-masked]>
Date: Sat, 20 Dec 2003 11:03:34 +0200

>some time to trigger a re-authorisation.

There is one credit reservation and the server grant quotas allocating all
reserved money to all the services. If we reserve an amount of money M
the server grants quotas to the services the following way:

Q1=M/R1, Q2=M/R2,......, Qn=M/Rn (i.e. no credit fragmentation)

Where R1 etc are the rating parameters.

The client inizialize counters for each of the services and report when:

C1/Q1+C2/Q2+......+Cn/Qn>=1 (or a*1), where a is a security factor to ensure 
that
M is never exceeded.

This equation is running in the client, no matter what is the service that 
consume the
reserved credit M (i.e. no credit fragmentation).

The reasons why this is a good mechanism are:

1- the signalling load is optimized because the client report only when 
really needed.
2- the credit management is simplified because you don't need to guess what 
services
     the user is effectively using and how much (i.e. a user may have 
subscription to
     20 different services but may use only 3 of them during a user's 
session, which one?
      how the server slice the reserved credit among all the possible 
subscribed services?
      M/20 or...? )
3- there is absolutely no credit fragmentation.

>re-authorised - even though the quotas have resources remaining.

If you better look the the DCC mechanisms there is no service interruption
while credit re-authorization is executed. No pitfall here.

>based on the use of all the allocated quotas.

Again, there is no service interruption when credit re-authorization is 
performed.
It is deterministic because what you care of is that the reserved money is 
not exceeded,
and since you report when C1*R1+C2*R2+...+Cn*Rn>=a*M it is deterministic 
that
you never exceed the reservation. No pitfall here.

The real pitfall, if you understand the mechanism, but it appears you don't, 
is that this
mechanism assume linear rating. We need to work out a solution to this.

Br
Marco

P.S.: and if you are concerned about IPR issues I'm not aware of any IPR on 
this
approach.

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus

---

From: "Christopher Richards" <[email-masked]>
Date: Mon, 22 Dec 2003 10:08:49 -0600

Hi Marco,

Thanks for your reply. As I said, the mechanism outlined is summing the
quota *use*. I guess I should have clarified that by saying "summing the
fractional quota use". 

One scenario I was trying to explain  was:

Assume Q1 is heavily used and has a relatively large quota. So: C1/Q1 = 0.5.
And C2/Q2 + C3/Q3 + C4/Q4 + .... Cn/Qn = ~0.1 (Due to little active use),
the quotas will not be re-authorised, even though credit has been fragmented
between them until the single heavy user (Q1) is exhausted.

My third point ("It is not very deterministic"): I was trying to point out
that it is very difficult to determine when quota re-authorisation will
occur for a particular quota, since it depends on the quota size and quota
use of other unrelated quotas. 

Whether a DCC client vendor wants to implement this mechanism as opposed to
others is outside the scope of the DCC specification. But it should be
marked as that - implementation choice. And as such, there should be no
requirement (And there is no need) that a DCC server assumes that a DCC
client is following this choice. That is where inter-operability issues
arise. But since there is no reason why a DCC server should assume exactly
how a DCC client is tracking re-authorisation limits, using this or any
other mechanism will pose no inter-op issues.

I'm curious about your statement that:

> Also, if everybody does what
> He wants in server (to allocate credit and calculate quotas) and client
(to decide
reason
> why standards exist and b. the service provider will risk negative credit
or the
> user will not be charged as expected.
 
I'd have thought that not implicitly tying a server implementation to a
client implementation would make the solution more inter-operable. Not the
other way!

Best Regards,
Chris.

-----Original Message-----
From: Stura Marco [mailto:[email-masked]] 
Sent: Saturday, December 20, 2003 2:35 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]
Subject: RE: [AAA-WG]: DCC: credit pooling in flow X

>My concern is that this method of summing the quota use should be 
>clearly stated as an implementation choice and not a mechanism that is 
>mandated by the DCC client. The mechanism outlined has some pitfalls 
>and there are other mechanisms of implementing credit sharing.

the

consider

have

Br
Marco