Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Fri, 16 Jan 2004 14:35:22 +0100

Hi Chris,

>[CR] 
>So the current proposal is to provision on each client node, which services WILL 
>use resources from the same  resource pool? 
>Therefore each client node must know in advance exactly what resource pools exist 
>for all potential users and service providers? 
>And, that this grouping is not dynamic or expected to change too often? 
>Sounds a bit unrealistic to me. Each time a new resource pool is created, it may 
>mean going to each client node and re-assigning existing groupings. 
>Imagine a tariff architecture where the resource pools available to users is constantly
>being modified (Special offers from operator or 3rd party service providers, etc) - 
>each time this happens, the operator must go into each client and modify the entire rating groups? 
>Sounds unworkable to me. I do not think that the DCC client should know in advance 
>what resource pool some rated service usage should come from - which is what the document
>currently suggests. That's the domain of the charging system (OCS, etc).
>[End CR] 
Due to some special offers why resource pools need to be changed? Rating groups yes, but why
resource pools as well? Assuming that resource pools are same as accounts, i.e. subscriber can 
have several accounts for different services, one account for calls, one for MMS, one for data, etc.

I agree that when these parameters are only locally configured it would be quite challenging task to 
manage all possible changes manually. But although parameters are manually configured, it is still 
possible to activate/de-activate these parameters dynamically. And in 3G case I think
that there is solution how to dynamically identify the service data flows that need to be charged
at different rates and the DCC-02 is aligned with the solutions proposed by IP Flow Based Bearer Level 
Charging.

But after all it may be better to let CC server to decide in real time which credit pool shall be used
and let server to reserve credit from the right end user's account. The Credit-Pool-Id AVP can be included
in the G-S-U so that indication of which Rating-Group/Service require sub-session can be given by the
server. The client can then initiate sub-sessions for these Rating-Groups/Services.

>I disagree that it is simpler and easier to treat quotas independently within the 
>same "sub"-session. This means that you should report/request quotas also independently,
>i.e. to handle these quotas by using independent CCR/CCA commands, and thus having sort
>of sub-session within sub-session and/or session. For instance in fault situations, e.g. 
>transport failure, to handle these independent quotas would make the procedures and state 
>machines very complicated. 
>>[CR] 
>>Do not think of different rated services as different sub-sessions. This is not correct. An operator 
>>may specify many thousands of rated services. Leave it up to the Charging system (OCS) to determine
>>where and how the resources for some traffic. It is not the job of the client to have this information.
>>[End CR] 
Yes, an operator may specify many thousands of rated services, but it doesn't mean that operator have to
have thousands of different rates. I believe that many of these service still use same rates and it 
is possible (and feasible) to define that all the service subject to the same rating type is part of the
same group (rating group) and thus same sub-session can be used to control services which belongs to
same rating group.

And once again, sub-sessions are a cleaner and easier way to handle fault cases and account re-fill
cases (re-direct) compared to the approach of having everything controlled within one session. Also
controlling everything within one session would require somehow an instance of the state machine for 
each of the running quotas, thus emulating explicit sub-sessions. 

>[CR] 
>But with the current scheme, a single PDP context may have multiple sub-sessions. Adding secondary 
>PDP contexts for the same session, we end up with many sub-sessions: some for the same PDP context 
>and some for the other PDP context. It will make trying to correlate all these sub-sessions with
>each other and with the user session a whole lot more complicated.
>[End CR]
It will be rather easy to have own application specific AVP (e.g. 3GPP AVP) to identify the 
PDP context. For instance two or more DCC sub-sessions with the same PDP contextId AVP would 
indicate that services are carried in the same secondary PDP context.

I also assume there is still the option to open a new DCC session for the secondary PDP Context
and sub-sessions for independent quotas, no?

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

---

From: "Christopher Richards" <[email-masked]>
Date: Mon, 19 Jan 2004 14:02:17 -0600

Hi Harri,

I guess we still disagree with the concept of sessions and sub-sessions and
the independence of quotas within a session. Some more examples and comments
below.

Also, to give you some background: I come from a 3GPP background. Currently,
3GPP have defined procedures for enabling the network to rate different
content based upon the usual 5 tuple identifiers (src/dst address and ports
& protocol) AS WELL AS WAP and HTTP (I.e. URI information).

I understand from your colleagues that you are tackling DCC from an IMS
development stance. That may explain why we have some disconnect.

Best Regards, 
Chris.

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Friday, January 16, 2004 7:35 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; Leena Mattila (TU/LMF)
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i
ndependent quotas

Hi Chris,

>currently suggests. That's the domain of the charging system (OCS, etc).
Due to some special offers why resource pools need to be changed? Rating
groups yes, but why resource pools as well? Assuming that resource pools are
same as accounts, i.e. subscriber can 
have several accounts for different services, one account for calls, one for
MMS, one for data, etc.

[CR2]	Imagine that a 3rd party content provider makes an agreement with 
	the network operator: "I'll pay the network operator for any bearer
	traffic used by it's subscribers to my web site - but only next
	Friday (Big promotion coming up)". The resources should be taken
	from the 3rd party content providers pool - which is only valid
	next Friday.

I agree that when these parameters are only locally configured it would be
quite challenging task to 
manage all possible changes manually. But although parameters are manually
configured, it is still 
possible to activate/de-activate these parameters dynamically. And in 3G
case I think that there is solution how to dynamically identify the service
data flows that need to be charged at different rates and the DCC-02 is
aligned with the solutions proposed by IP Flow Based Bearer Level 
Charging.

But after all it may be better to let CC server to decide in real time which
credit pool shall be used and let server to reserve credit from the right
end user's account. The Credit-Pool-Id AVP can be included in the G-S-U so
that indication of which Rating-Group/Service require sub-session can be
given by the server. The client can then initiate sub-sessions for these
Rating-Groups/Services.

[CR2]	Why make it even more complicated to solve this problem. Now the
	CC server needs to send back an indicator that the client needs
	to track so that it knows when to use a sub-session or not. It is
	simply side-stepping the issue by making it more complicated. 
	A session is a session - not a type of content or resource.
	Resources used by that session should use that session. The quotas
	on the client track resource usage. The CC server is the place to
	track service usage by these sessions and charge (Or not)
	appropriately. It should not be the responsibility of the CC client
	to start doing the work of the server.

>>where and how the resources for some traffic. It is not the job of the
client to have this information.
Yes, an operator may specify many thousands of rated services, but it
doesn't mean that operator have to have thousands of different rates. 

[CR2]	But it may (And at least in some major networks: certainly will).
	Don't forget, that a single HTML web page can contain many
	differently rated items. 
	I would think that you would want to avoid creating many sub-
	sessions just for downloading a single web page.
	Each sub-session in this case will be very short lived.

I believe that many of these service still use same rates and it 
is possible (and feasible) to define that all the service subject to the
same rating type is part of the same group (rating group) and thus same
sub-session can be used to control services which belongs to same rating
group.

And once again, sub-sessions are a cleaner and easier way to handle fault
cases and account re-fill cases (re-direct) compared to the approach of
having everything controlled within one session. Also controlling everything
within one session would require somehow an instance of the state machine
for 
each of the running quotas, thus emulating explicit sub-sessions. 

[CR2]	Correct each resource quota would require state -- but
	that's no different to each sub-session. Also note that
	resource quotas would (On average) have a much shorter
	expected lifetime than a session. 

>each other and with the user session a whole lot more complicated.
It will be rather easy to have own application specific AVP (e.g. 3GPP AVP)
to identify the 
PDP context. For instance two or more DCC sub-sessions with the same PDP
contextId AVP would 
indicate that services are carried in the same secondary PDP context.

[CR2]	Just more work to do to correlate them all.

I also assume there is still the option to open a new DCC session for the
secondary PDP Context and sub-sessions for independent quotas, no?

[CR2]	Yes. But again, more work is involved. We would want to avoid
	artificially splitting the contexts into different sessions when
	really they are all related to the same user session. Also, we
	want to avoid unnecessary signalling overhead. 

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

---

From: <[email-masked]>
Date: Tue, 20 Jan 2004 14:04:21 +0200

Hi Chris,
 
>Also, to give you some background: I come from a 3GPP background. Currently, 3GPP have defined procedures for enabling 
>the network to rate different content based upon the usual 5 tuple identifiers (src/dst address and ports & protocol) AS WELL AS
> WAP and HTTP (I.e. URI information).
 
>I understand from your colleagues that you are tackling DCC from an IMS development stance. That may explain why we have some 
>disconnect.
 
The DCC is designed to be a generic credit control application to properly support several services and environments as stated in the
draft 02. Among others it also enables to rate rate different content based upon the usual 5 tuple identifiers (src/dst address and ports & protocol) as well as WAP and HTTP (I.e. URI information). I would like to inform you that e.g. the mechanism described in Flow X is
implemented and fully working , enabling for what you want with optimal signaling load.
 
Moreover, 3GPP doesn't have any defined procedures but just high level stage 2 architecture with requirements, which are covered by
the current draft 02.
 
Conclusion, no disconnect at all between the DCC and the 3GPP requirements since we are following what 3GPP is doing and we are
in constant talk with our 3GPP delegates. Where we do have disconnect is in our views how to implement these functionalities.
 
This discussion is really getting fruitless and endless, totally missing the point. What we have are requirements from 3GPP and some
that you also brought. I copy here your requirements from http://www.merit.edu/mail.archives/aaa-wg/msg00064.html:
 
- Quotas (G-S-U's) allow an amount of resource usage for a particular Rating-Group. 
- Multiple G-S-U AVPs may be returned in a single CCA. 
- The G-S-U resources for each Rating-Group are allocated independently of any others. 
- G-S-U resources may be requested by the client and allocated by the server at any point in a session. 
- Each G-S-U resource size (& unit) allocation is independent of any others. It is a function of the server. 
- A user may (probably will) use each resource at a different speed to others. 
 
All the points of  the above list are supported in draft 02.  If you want optimal signaling and use of resources in client and server, then you can implement the mechanism of issue 436.  If you want to achieve quota independence, then you can implement sub-sessions.
 
But you are still not happy, you want to enable for quotas multiplexing in the same session/sub-session thus creating two options
to support the same thing.  Introducing options to support the same functionalities is definitely increasing the likelihood of interoperability issues when coming to real life.
Moreover, each of the multiplexed independent quotas would require its own instance of the DCC state machine as well as its own Tx timer etc. Whatever you say this is definitely equivalent to have DCC sub-sessions.
 
Having said that, I'm still open to consider proposal that seamlessly fits within all the currently defined DCC functionalities and mechanisms and add value to the application. The problem is that so far you just brought in the discussion very high level proposals that do not tell much about failure handling etc. and so far I perceive what you propose as a different option of doing the same things already supported in the draft not as added value. 
So, what it would be nice from your side is to exit this discussion loop and make a proposal that describes your solution including
a nice flow example, failure handling details, how to handle the server initiated credit re-authorization for a given service, GST etc. etc.
Of course everything MUST fit seamlessly within all the existing functionalities defined in the DCC without re-inventing the wheel and MUST NOT introduce potential for interoperability issues.
 
Looking forward for your technical proposal to consider its added value if any.
 
Br
Marco

---

From: "Christopher Richards" <[email-masked]>
Date: Tue, 20 Jan 2004 10:58:31 -0600

Hi Marco,
 
I understand that Nokia already has an implementation of the DCC draft and
that is perhaps why there is little negotiation regarding the draft
document.
 
I would suggest that 3GPP has stage 2 requirements that need to be addressed
that are not. I really want 3GPP to adopt the DCC application, but in order
for that to happen, the protocol must meet the requirements.
 
I have commented on some of your specific points below. It worries me that
you state that any comments or proposals "MUST fit seamlessly within all the
existing functionalities defined in the DCC ". To me that means that the
only proposals you are willing to consider make no changes!  

Best Regards, 
Chris. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, January 20, 2004 6:04 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i
ndependent quotas

Hi Chris,
 
>Also, to give you some background: I come from a 3GPP background.
Currently, 3GPP have defined procedures for enabling 
>the network to rate different content based upon the usual 5 tuple
identifiers (src/dst address and ports & protocol) AS WELL AS
 
>I understand from your colleagues that you are tackling DCC from an IMS
development stance. That may explain why we have some 
>disconnect.
 
The DCC is designed to be a generic credit control application to properly
support several services and environments as stated in the
draft 02. Among others it also enables to rate rate different content based
upon the usual 5 tuple identifiers (src/dst address and ports & protocol) as
well as WAP and HTTP (I.e. URI information). I would like to inform you that
e.g. the mechanism described in Flow X is
implemented and fully working , enabling for what you want with optimal
signaling load.
[Chris Richards ] I would have to disagree with the last part of that
statement. My earlier emails described the extra signalling required and was
acknowledged by a response to the group. 
 
Moreover, 3GPP doesn't have any defined procedures but just high level stage
2 architecture with requirements, which are covered by
the current draft 02.
 
Conclusion, no disconnect at all between the DCC and the 3GPP requirements
since we are following what 3GPP is doing and we are
in constant talk with our 3GPP delegates. Where we do have disconnect is in
our views how to implement these functionalities.
[Chris Richards ] Your 3GPP delegate proposed a document that was a cut and
paste of an IMS specification. Not a generic Diameter Credit Control
document. It only addressed IMS.
 
This discussion is really getting fruitless and endless, totally missing the
point. 
[Chris Richards ] It is only fruitless if there is no willingness to
consider the issues I have raised. Again, if Nokia has already implemented
it's version of the draft, then I can understand this.
 
 What we have are requirements from 3GPP and some
that you also brought. I copy here your requirements from
http://www.merit.edu/mail.archives/aaa-wg/msg00064.html
<http://www.merit.edu/mail.archives/aaa-wg/msg00064.html> :
 
- Quotas (G-S-U's) allow an amount of resource usage for a particular
Rating-Group. 
- Multiple G-S-U AVPs may be returned in a single CCA. 
- The G-S-U resources for each Rating-Group are allocated independently of
any others. 
- G-S-U resources may be requested by the client and allocated by the server
at any point in a session. 
- Each G-S-U resource size (& unit) allocation is independent of any others.
It is a function of the server. 
- A user may (probably will) use each resource at a different speed to
others. 
 
All the points of  the above list are supported in draft 02.  If you want
optimal signaling and use of resources in client and server, then you can
implement the mechanism of issue 436.  If you want to achieve quota
independence, then you can implement sub-sessions.
[Chris Richards ] Again, apart from having the server tell the client what
resources are bound together and what resources are independent, how can a
client know that a request for one rate quota comes from what resource pool
and thus how to know in advance if it needs to create a new sub-session?  
 
But you are still not happy, 
[Chris Richards ] Mainly because as discussed earlier: it will not work in
practice.
 you want to enable for quotas multiplexing in the same session/sub-session
thus creating two options
to support the same thing. 
[Chris Richards ] No. Just one option: sub-sessions are used for sub
sessions and quotas are used for service delivery. Since when did one rate
suddenly become a sub-session. Following that logic, a single web page may
contain and require many different sub-sessions. Kind of makes a mockery out
of the term "sub-session".
 
  Introducing options to support the same functionalities is definitely
increasing the likelihood of interoperability issues when coming to real
life.

[Chris Richards ] Just about every Technical specification I have every seen
is full of options.
 
 Moreover, each of the multiplexed independent quotas would require its own
instance of the DCC state machine as well as its own Tx timer etc. Whatever
you say this is definitely equivalent to have DCC sub-sessions.
[Chris Richards ] Yes: each quota will need state (It already does - but
will need more) - just as sub-sessions do. However, the philosophy is
shifted. Sessions are sessions controlled by a user - not by the content of
traffic used by the user. The client only needs to know about how to rate
traffic (Rules filters) and be able to track the usage. The server needs to
manage the resource pools, resource reservation and accounts, etc. NOT the
client. The client should never care what resource pool any quota comes
from. I think that is fundamentally our disagreement: In the current DCC
draft, the client takes on a good deal of responsibility of resource pool
knowledge, provisioning, management, etc. In my view (And I think 3GPP
requirements): this is the domain of the Online server (DCC server, OCS).
 
Having said that, I'm still open to consider proposal that seamlessly fits
within all the currently defined DCC functionalities and mechanisms and add
value to the application. 
[Chris Richards ] So, basically as long as any proposals do not change in
any way the current draft, it's OK?! What sort of statement is that? If
that's the stance, then why even bother having a draft.
 
 The problem is that so far you just brought in the discussion very high
level proposals that do not tell much about failure handling etc. and so far
I perceive what you propose as a different option of doing the same things
already supported in the draft not as added value. 
So, what it would be nice from your side is to exit this discussion loop and
make a proposal that describes your solution including
a nice flow example, failure handling details, how to handle the server
initiated credit re-authorization for a given service, GST etc. etc.
Of course everything MUST fit seamlessly within all the existing
functionalities defined in the DCC without re-inventing the wheel and MUST
NOT introduce potential for interoperability issues.
 
Looking forward for your technical proposal to consider its added value if
any.
 
Br
Marco

---

From: "Stura Marco" <[email-masked]>
Date: Tue, 20 Jan 2004 20:15:00 +0200

Hi Chris,

>that is perhaps why there is little negotiation regarding the draft

Did I mention Nokia??? ..... and by the way, there is always room for 
protocol
improvements if those make sense and are not *yet another option*.

>only proposals you are willing to consider make no changes!

Rather than providing political answer, turn around things and speculate on 
my statements without any concrete proposal please concentrate on technical 
fact and provide what we requested, thank you.  i.e.

>initiated credit re-authorization for a given service, GST etc. etc.

I guess you should be familiar how to create an issue that includes all the 
impact to
the protocol etc., no?

Be sure that if your proposal is of any added value and valuable at the 
purpose of enhancing the application (i.e. not introducing options to do the 
same things already supported), I'm certainly not the one neglecting a good 
proposal.

>for that to happen, the protocol must meet the requirements.

All 3GPP requirements are addressed and met as repeated many many time since 
this discussion started. However, if the main 3GPP requirement is the DCC to 
accommodate for your view and implement the solution accordingly, I agree 
that this is not fully met.

Regards
Marco

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

---

From: "Christopher Richards" <[email-masked]>
Date: Tue, 20 Jan 2004 13:50:59 -0600

Hi Marco,

Well, let's go back to two of my original questions:-

How does a client know when to use a sub-session for a quota request or not?

I see 3 possibilities:-
(1) Always use sub-sessions for every quota.
(2) Provision on the client, exactly what resource pools each rate belongs
to.
(3) Have some other device to provide a table of rates <-> resource pool
mappings. Table is per user or per...?
(4) ?

Here is my opinion:-

(a) Personally, I don't think that the resource usage tracker (client)
should need to know what or how resource pools are managed. That's an
architectural issue and a job for the charging system. However, it has
direct bearing on the DCC protocol use of sessions sub-sessions.

(b) Rate-to-resource pool mapping may be very dynamic; changing depending on
many factors, including the time of the day. That makes any mapping table or
static provisioning unworkable.

Let me know your answer.

So, that brings me to the logical next question: What is a session as
defined in DCC? From RFC3588 I got these definitions:-

      Session
      A session is a related progression of events devoted to a
      particular activity.  Each application SHOULD provide guidelines
      as to when a session begins and ends.  All Diameter packets with
      the same Session-Identifier are considered to be part of the same
      session.

      Sub-session
      A sub-session represents a distinct service (e.g., QoS or data
      characteristics) provided to a given session.  These services may
      happen concurrently (e.g., simultaneous voice and data transfer
      during the same session) or serially.  These changes in sessions
      are tracked with the Accounting-Sub-Session-Id.
  
Are data characteristics or QoS represented by different rating of content?
Surely the QoS or data characteristics are attributes of the session not of
the rating of the content. The paragraph above is very similar to the 3GPP
definition of secondary context. 

Again, let me know your answer.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281

-----Original Message-----
From: Stura Marco [mailto:[email-masked]] 
Sent: Tuesday, January 20, 2004 12:15 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i
ndependent quotas

Hi Chris,

>I understand that Nokia already has an implementation of the DCC draft 
>and that is perhaps why there is little negotiation regarding the draft 
>document.

>I have commented on some of your specific points below. It worries me 
>that you state that any comments or proposals "MUST fit seamlessly 
>within all the existing functionalities defined in the DCC ". To me 
>that means that the only proposals you are willing to consider make no 
>changes!

>So, what it would be nice from your side is to exit this discussion 
>loop
>and

Regards
Marco

---

From: <[email-masked]>
Date: Wed, 21 Jan 2004 09:23:22 +0200

Hi Chris!
 
I've been following your vivid discussion for awhile. As this discussion has been going on so long I suggest that you make formal issue where you summarize (chapter x.x FROM - chapter x.x TO) the changes needed to DCCA draft 02. Could you do this, please?
 
I'm sure that detailed and formal proposal will solve this problem as also others can clearly see what should be changed and where and why. 
 
Thanks in advance!!
 
BR,
JP Koskinen

 -----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: 20 January, 2004 21:51
To: 'Stura Marco'
Cc: Stura Marco (Nokia-NET/Helsinki); Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka (Nokia-NET/Tampere); [email-masked]; [email-masked]; [email-masked]; [email-masked]; Alexander Benni (Nokia-NET/Espoo); [email-masked]
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas

Hi Marco, 

I see 3 possibilities:- 
(1) Always use sub-sessions for every quota. 
(2) Provision on the client, exactly what resource pools each rate belongs to. 
(3) Have some other device to provide a table of rates <-> resource pool mappings. Table is per user or per...? 
(4) ? 

Here is my opinion:- 

(a) Personally, I don't think that the resource usage tracker (client) should need to know what or how resource pools are managed. That's an architectural issue and a job for the charging system. However, it has direct bearing on the DCC protocol use of sessions sub-sessions.

(b) Rate-to-resource pool mapping may be very dynamic; changing depending on many factors, including the time of the day. That makes any mapping table or static provisioning unworkable.

Let me know your answer. 

So, that brings me to the logical next question: What is a session as defined in DCC? From RFC3588 I got these definitions:-

      Session 

      Sub-session 
  
Are data characteristics or QoS represented by different rating of content? Surely the QoS or data characteristics are attributes of the session not of the rating of the content. The paragraph above is very similar to the 3GPP definition of secondary context. 

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message----- 
From: Stura Marco [ mailto:[email-masked]] 
Sent: Tuesday, January 20, 2004 12:15 PM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]

Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas 

Hi Chris, 

Regards 
Marco

---

From: <[email-masked]>
Date: Wed, 21 Jan 2004 10:06:27 +0200

Hi Chris,

> Table is per user or per...? 

As you know, the draft is WGLC.  Could you please send your comments
in the format requested?  It gives us a way to track the issue and
try to resolve the issue.

As you know, the draft has existed for quite some time, and there are concerns
from 3GPP about completing this work, so we would really like to get issues
submitted and resolved as soon as possible.

thanks,
John

---

From: <[email-masked]>
Date: Wed, 21 Jan 2004 14:14:03 +0200

>How does a client know when to use a sub-session for a quota request or not? 
 
If we talk 3GPP, in SA2 they have defined the CRF (Charging Rule Function) that is supposed to
provision the Service Element (e.g. GGSN) with all the service data flows information including 
IP filters, URI, Service-Id and/or Rating-Group etc. The service data flow information may be 
static or dynamic (e.g. derived from SIP/SDP).
If your client does implement the independent quotas approach it will request for credit control
authorization by opening a DCC sub-session every time a non-authorized service data flow is met.
Please note that most of those sub-sessions are short lasting sub-sessions.
Since the user most likely will pay the services, also note that there will not be many sub-sessions
in average per user.
The client doesn't need to know what or how the server manage credit resources pools at all.
A flow example is provided in Issue 8.

 
>Are data characteristics or QoS represented by different rating of content? Surely the QoS or data characteristics are attributes of the >session not of the rating of the content. The paragraph above is very similar to the 3GPP definition of secondary context. 
 
Right. The QoS and all the bearer characteristics are attributes of the DCC session.
Note that the RFC 3588 gives QoS or data characteristics as an example of a distinct service, it doesn't say that distinct
service means only QoS or data characteristics. A distinct service may be something else as well e.g. a service data flow or a Rating-Group.
 
A PDP Context (primary or secondary) can map to a DCC session that carries the bearer characteristics (i.e. QoS, APN, PDP-Identifier etc.). Whenever a non-authorized service data flow is met, the service element (e.g. GGSN) opens a DCC sub-session to perform credit control and get independent quota. Note that all the service data flows subject to the same rate can be grouped into Rating-Groups, thus the client just need to authorize the Rating-Group and share the granted units among all the used services within the Rating-Group. It doesn't necessarily means that you need to open a sub-session for each of the service data flows.
The result of the above is that you get a DCC session for each PDP Context and associated temporary sub-sessions for different rating of content. If you multiplex quotas within the same session it is equivalent to this, since you would need an instance of the DCC state machine and Tx timer for each of the independent quotas the resources you save as compared to explicit sub-session are irrelevant and there is the cost of added system/implementation complexity and added potential for interoperability issues since there would be two options to do the same thing.
 
If you want to save signaling and resources then the DCC also support for another mechanism, an example of which is given in Flow X. As suggested in issue 8 the server need to support both mechanisms while the client implementation may support either one or the other or both. 
 
Personally, I regard this thread as closed. Should you have more questions/doubts that I didn't answer, please provide a formal issue with all the technical details, what should be changed where and why as also suggested by other people.
 
Regards
Marco

---

From: "Christopher Richards" <[email-masked]>
Date: Wed, 21 Jan 2004 09:49:29 -0600

Hi Marco,
 
I will  put together a formal proposal as suggested. In the meantime, I
quickly responded to your email.

Best Regards, 
Chris. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, January 21, 2004 6:14 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked];

>How does a client know when to use a sub-session for a quota request or
not? 
 
If we talk 3GPP, in SA2 they have defined the CRF (Charging Rule Function)
that is supposed to
provision the Service Element (e.g. GGSN) with all the service data flows
information including 
IP filters, URI, Service-Id and/or Rating-Group etc. The service data flow
information may be 
static or dynamic (e.g. derived from SIP/SDP).
If your client does implement the independent quotas approach it will
request for credit control
authorization by opening a DCC sub-session every time a non-authorized
service data flow is met.
[Chris Richards ] Ouch! Effectively returning to a single-quota mechanism. 
Please note that most of those sub-sessions are short lasting sub-sessions.
[Chris Richards ] Exactly. 
Since the user most likely will pay the services, also note that there will
not be many sub-sessions
in average per user.
[Chris Richards ] That's not for us to say - and it's very difficult to
speculate. I prefer to leave this up to the marketing departments of the
operators. 
The client doesn't need to know what or how the server manage credit
resources pools at all.
[Chris Richards ] As long as a sub-session (single quota mechanism) is used
every time as you described above. 
A flow example is provided in Issue 8.

 
>Are data characteristics or QoS represented by different rating of content?
Surely the QoS or data characteristics are attributes of the >session not of
the rating of the content. The paragraph above is very similar to the 3GPP
definition of secondary context. 
 
Right. The QoS and all the bearer characteristics are attributes of the DCC
session.
Note that the RFC 3588 gives QoS or data characteristics as an example of a
distinct service, it doesn't say that distinct
service means only QoS or data characteristics. A distinct service may be
something else as well e.g. a service data flow or a Rating-Group.
[Chris Richards ] I would have thought that the DCC idea of a session would
be somewhat similar to the examples in 3588. A Diameter session is
characterized by the attributes of a session, yet a session in DCC is
characterized by the user data being sent by the session at a particular
time.  
 
A PDP Context (primary or secondary) can map to a DCC session that carries
the bearer characteristics (i.e. QoS, APN, PDP-Identifier etc.). Whenever a
non-authorized service data flow is met, the service element (e.g. GGSN)
opens a DCC sub-session to perform credit control and get independent quota.
Note that all the service data flows subject to the same rate can be grouped
into Rating-Groups, thus the client just need to authorize the Rating-Group
and share the granted units among all the used services within the
Rating-Group. It doesn't necessarily means that you need to open a
sub-session for each of the service data flows.
[Chris Richards ] So, are you saying a sub-session is defined by how the
bearer traffic being sent at that time is charged? In other words: for any
traffic that the client does not have a quota for, it needs to open a
sub-session.
The other effect of course is that this puts the application back to single
quota mechanism. 
The result of the above is that you get a DCC session for each PDP Context
and associated temporary sub-sessions for different rating of content. If
you multiplex quotas within the same session it is equivalent to this, since
you would need an instance of the DCC state machine and Tx timer for each of
the independent quotas the resources you save as compared to explicit
sub-session are irrelevant and there is the cost of added
system/implementation complexity and added potential for interoperability
issues since there would be two options to do the same thing.
[Chris Richards ] I agree that both require state. That the complexity saved
by one method over the other. You're missing my point though: what is a
session and how much should the client know about the charging system in
order to define a sub-session.  
 
If you want to save signaling and resources then the DCC also support for
another mechanism, an example of which is given in Flow X. As suggested in
issue 8 the server need to support both mechanisms while the client
implementation may support either one or the other or both. 
[Chris Richards ] This only works if the client knows what rates belong to
what groups. If it does not (And it should not), then we're back to the
single quota mechanism and flow X is irrelevant/not applicable. 
 
Personally, I regard this thread as closed. Should you have more
questions/doubts that I didn't answer, please provide a formal issue with
all the technical details, what should be changed where and why as also
suggested by other people.
[Chris Richards ] It's on it's way. 
 
Regards
Marco

---

From: <[email-masked]>
Date: Wed, 21 Jan 2004 18:29:07 +0200

Hi Chris,
 
I'm more and more convinced that you need a training session on how the DCC application works in
general and especially for multiple services in a user session.
All your comments and claims are totally irrelevant to the DCC application and disconnected from
how the DCC application works.
 
THE CLIENT DOESN'T NEED TO KNOW WHAT OR HOW THE SERVER MANAGE CREDIT
RESOURCES POOLS AT ALL AND IN ANY CASE.
 
Regards
Marco

-----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: 21 January, 2004 17:49
To: Stura Marco (Nokia-NET/Helsinki)
Cc: Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka (Nokia-NET/Tampere); [email-masked]; [email-masked]; [email-masked]; [email-masked]; Alexander Benni (Nokia-NET/Espoo); [email-masked]; Koskinen Juha-Pekka (Nokia-NET/Tampere)
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas

Hi Marco,
 
I will  put together a formal proposal as suggested. In the meantime, I quickly responded to your email.

Best Regards, 
Chris. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, January 21, 2004 6:14 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas

[Chris Richards ] That's not for us to say - and it's very difficult to speculate. I prefer to leave this up to the marketing departments of the operators. 
[Chris Richards ] As long as a sub-session (single quota mechanism) is used every time as you described above. 

 
 
Right. The QoS and all the bearer characteristics are attributes of the DCC session.
Note that the RFC 3588 gives QoS or data characteristics as an example of a distinct service, it doesn't say that distinct
service means only QoS or data characteristics. A distinct service may be something else as well e.g. a service data flow or a Rating-Group.
[Chris Richards ] I would have thought that the DCC idea of a session would be somewhat similar to the examples in 3588. A Diameter session is characterized by the attributes of a session, yet a session in DCC is characterized by the user data being sent by the session at a particular time.  
 
A PDP Context (primary or secondary) can map to a DCC session that carries the bearer characteristics (i.e. QoS, APN, PDP-Identifier etc.). Whenever a non-authorized service data flow is met, the service element (e.g. GGSN) opens a DCC sub-session to perform credit control and get independent quota. Note that all the service data flows subject to the same rate can be grouped into Rating-Groups, thus the client just need to authorize the Rating-Group and share the granted units among all the used services within the Rating-Group. It doesn't necessarily means that you need to open a sub-session for each of the service data flows.
[Chris Richards ] So, are you saying a sub-session is defined by how the bearer traffic being sent at that time is charged? In other words: for any traffic that the client does not have a quota for, it needs to open a sub-session.
The other effect of course is that this puts the application back to single quota mechanism. 
The result of the above is that you get a DCC session for each PDP Context and associated temporary sub-sessions for different rating of content. If you multiplex quotas within the same session it is equivalent to this, since you would need an instance of the DCC state machine and Tx timer for each of the independent quotas the resources you save as compared to explicit sub-session are irrelevant and there is the cost of added system/implementation complexity and added potential for interoperability issues since there would be two options to do the same thing.
[Chris Richards ] I agree that both require state. That the complexity saved by one method over the other. You're missing my point though: what is a session and how much should the client know about the charging system in order to define a sub-session.  
 
If you want to save signaling and resources then the DCC also support for another mechanism, an example of which is given in Flow X. As suggested in issue 8 the server need to support both mechanisms while the client implementation may support either one or the other or both. 
[Chris Richards ] This only works if the client knows what rates belong to what groups. If it does not (And it should not), then we're back to the single quota mechanism and flow X is irrelevant/not applicable. 

Regards
Marco

---

From: <[email-masked]>
Date: Wed, 21 Jan 2004 19:16:35 +0200

Hi Chris,
 
apologize for saying things a bit to strong,  you know is getting very late here in Finland and I'm
getting tired. I wanted just to emphasize that in the current DCC the client does not need to know or 
manage the server resources in any case, even in the example of Flow X.
 
Looking forward for your formal issue
Marco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext 
Sent: 21 January, 2004 18:29
To: [email-masked]
Cc: Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka (Nokia-NET/Tampere); [email-masked]; [email-masked]; [email-masked]; [email-masked]; Alexander Benni (Nokia-NET/Espoo); [email-masked]; Koskinen Juha-Pekka (Nokia-NET/Tampere)
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas

Hi Chris,

 
Regards
Marco

-----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: 21 January, 2004 17:49
To: Stura Marco (Nokia-NET/Helsinki)
Cc: Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka (Nokia-NET/Tampere); [email-masked]; [email-masked]; [email-masked]; [email-masked]; Alexander Benni (Nokia-NET/Espoo); [email-masked]; Koskinen Juha-Pekka (Nokia-NET/Tampere)
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas

Hi Marco,

Best Regards, 
Chris. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, January 21, 2004 6:14 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i ndependent quotas

 

 

Regards
Marco

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 22 Jan 2004 18:44:58 -0000

Marco, all,
 
I'm afraid I can't see either how the proposed mechanism meets the
requirements for IP Flow Charging in 3GPP. We would like to make sure we can
find a mechanism which everyone is happy with and which meets those
requirements.
 
On a procedural note, I don't agree we are restricted to proposals which
"fit seamlessly within all the existing functionalities defined in the DCC"
- this is too strong. Of course proposals must result in a clean and
sensible overall protocol, but the draft is not yet approved. We expect to
be entitled to submit any proposal - including changes to the "existing
functionalities" - and have it judged on technical merits.
 
As Chris said we will submit a formal issue when we have a detailed proposal
together, hopefully early next week.
 
In the meantime, I wonder if I could pose a couple of questions which might
help clear up mis-understanding on both sides. Please correct me if I have
mis-understood anything and apologies to the non-3GPP crowd on the list for
the 3GPP language below:
 
Question 1:
a) a user establishes a Secondary PDP Context - this causes a new DCC
session to be established
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)
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!).
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.
 
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 ?
 
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 ?
 
Best regards,
 
Mark Watson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 21 January 2004 17:17
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i
ndependent quotas

Hi Chris,
 
apologize for saying things a bit to strong,  you know is getting very late
here in Finland and I'm
getting tired. I wanted just to emphasize that in the current DCC the client
does not need to know or 
manage the server resources in any case, even in the example of Flow X.

-----Original Message-----

Sent: 21 January, 2004 18:29
To: [email-masked]
Cc: Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka
(Nokia-NET/Tampere); [email-masked]; [email-masked];
[email-masked]; [email-masked]; Alexander Benni
(Nokia-NET/Espoo); [email-masked]; Koskinen Juha-Pekka
(Nokia-NET/Tampere)
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i
ndependent quotas

Hi Chris,
 
I'm more and more convinced that you need a training session on how the DCC
application works in
general and especially for multiple services in a user session.
All your comments and claims are totally irrelevant to the DCC application
and disconnected from
how the DCC application works.

Regards
Marco

-----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: 21 January, 2004 17:49
To: Stura Marco (Nokia-NET/Helsinki)
Cc: Loughney John (Nokia-NRC/Helsinki); Koskinen Juha-Pekka
(Nokia-NET/Tampere); [email-masked]; [email-masked];
[email-masked]; [email-masked]; Alexander Benni
(Nokia-NET/Espoo); [email-masked]; Koskinen Juha-Pekka
(Nokia-NET/Tampere)
Subject: RE: [AAA-WG]: Issue: DCC Multiple services in a user's session, i
ndependent quotas

Hi Marco,

Best Regards, 
Chris. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, January 21, 2004 6:14 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked];

 

 

Regards
Marco

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Fri, 23 Jan 2004 09:17:36 +0100

Hi Mark,

>I'm afraid I can't see either how the proposed mechanism meets the requirements
>for IP Flow Charging in 3GPP. We would like to make sure we can find a mechanism
>which everyone is happy with and which meets those requirements.
I believe that we can find a mechanism which everyone is happy with.

>On a procedural note, I don't agree we are restricted to proposals which "fit 
>seamlessly within all the existing functionalities defined in the DCC" - this 
>is too strong. Of course proposals must result in a clean and sensible overall
>protocol, but the draft is not yet approved. We expect to be entitled to submit
>any proposal - including changes to the "existing functionalities" - and have it
>judged on technical merits.
Because the DCC is intended to be a generic credit control application to different kind
of services in different environments, it defines certain basic mechanism valid for all 
application/systems and optional features valid for certain services. The multiple
services in a single credit control session is optional feature (a bit 3GPP specific,
I guess) in credit control draft, that is all applications/systems are not forced to support
it. In other words the support of multiple services is not mandatory for all CC clients and 
CC servers. These optional features shall fit seamlessly within all the existing basic
mechanism, e.g. session based credit control, failure procedures, state machines, etc. 
Due to one specific service we should not change or add more complex logic for basic parts 
and thus add complexity for applications which do not use that service.

>As Chris said we will submit a formal issue when we have a detailed proposal together, 
>hopefully early next week.
It may take time so early next week is fine.

regards..........Harri

---

From: <[email-masked]>
Date: Fri, 23 Jan 2004 10:29:29 +0200

Hi Mark,

>find a mechanism which everyone is happy with and which meets those

Yes, I would like to find a mechanism which everyone is happy with as well.

>We expect to

Definitely you are entitled, I've never say that you are not.
I was even saying that I'm not the one neglecting a good proposal, so no 
problems at all to judge on technical merits. The problem is that so far 
I've seen very fragmented proposals suggesting to add AVPs here and there, 
it was extremely difficult to understand the reason of the proposals and 
impossible to get the whole picture. I even asked questions to which
I've never got answer. The only thing we have been able to catch from this 
long discussion was a requirement for independent quotas, that's why we are 
now discussing sub-sessions. We have requested sometime ago a structured
formal issue, it really help to understand the potential problem and it 
gives us a way to track the issue and try to resolve the issue.

>together, hopefully early next week.

Great! That is what we would have like to see since the beginning of 
this discussion.

>mis-understood anything and apologies to the non-3GPP crowd on the list for

I'll send separate mail addressing your technical questions, so that we may 
attempt to find out if there is a gap and fix it.

Regards
Marco

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 23 Jan 2004 09:35:10 -0000

Harri,

Yes, I agree - different customers for the Diameter CC specification have
different requirements, so I have no problem with some capabilities being
optional. Nor any problem with ensuring that those who do not need such
options are not impacted by their existence in the specification.

My point was just that to get an overall clean and consistent mechanism,
which meets the above criterion, may mean changes to the existing draft, not
just 'grafted on' additions. The existing draft is not approved and so
nothing is 'sacred' - Such changes should not be 'ruled out' a priori as
appeared the intention of Marco's mail.

Anyway, let's see where we get on the particular issue - probably there will
be a clean solution which does not mean changes to the basic mechanisms - it
was just a procedural point.

...Mark

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: 23 January 2004 08:18
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]: Issue: DCC Multiple services in a user's session, i
ndependent quotas

Hi Mark,

>requirements for IP Flow Charging in 3GPP. We would like to make sure 
>we can find a mechanism which everyone is happy with and which meets 
>those requirements.

>judged on technical merits.
Because the DCC is intended to be a generic credit control application to
different kind of services in different environments, it defines certain
basic mechanism valid for all 
application/systems and optional features valid for certain services. The
multiple services in a single credit control session is optional feature (a
bit 3GPP specific, I guess) in credit control draft, that is all
applications/systems are not forced to support it. In other words the
support of multiple services is not mandatory for all CC clients and 
CC servers. These optional features shall fit seamlessly within all the
existing basic mechanism, e.g. session based credit control, failure
procedures, state machines, etc. 
Due to one specific service we should not change or add more complex logic
for basic parts 
and thus add complexity for applications which do not use that service.

regards..........Harri