Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Mon, 2 Feb 2004 13:10:04 +0100

Hi Chris,

the way it is proposed in the draft-02 is similar as currently
implemented in the IN/CAMEL systems and we are not aware of any problem associated
with it, it just works nicely. Concerning the proposed mechanism it seems
the server would need to allocate credit both before and after the tariff
change. If the server wants to minimize the likelihood of higher 
re-authorization traffic load, it would have to allocate bigger credit
in both categories since it doesn't know whether more units will be consumed
before or after. If the server wants to minimize the credit fragmentation
would need to allocate smaller credit, at the expences of higher re-autht
traffic load. So, I fully agree with John P. in that the proposed mechanism
defeats both the objectives of trying to reduce credit fragmentation and
trying to minimize the re-auth traffic load.

John Loughney wrote:
>I am quite worried about additional optional mechanisms.  Already
>the specification is quite complicated and I worry that additional
>optional mechansisms will create extremely complicated mechanisms.
>
>I favor simplication at this point, so I'd hope we could discuss
>the options and focus on a single mechansim.
>
I agree with this, we shouldn't introduce more optionality. We should
support only one way of doing tariff switch (tsw itself is optional
already, optionality within one option is not desirable).

BR,
Leena

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: 30. tammikuuta 2004 19:08
To: Christopher Richards
Cc: [email-masked]'; [email-masked]
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris, 

I've no objection myself in principle to your mechanism of allocating quotas together for both units before and units after the tariff change.  As long as it is all optional. 

The question is: how likely is the client to run out of the before units before the time of the tariff change.  This would trigger an re-authorisation even though the units after are unused.  To avoid this, the server would have to allocated a higher quota in that category.  Alternatively, if the user did little before the tariff change and lots after they would be likely to consume the units after much more quickly. 
  
Therefore, I suspect that this mechanism won't reduce the volume of authorisation traffic in practice unless larger quotas are allocated, which I think defeats your objective of trying to reduce credit fragmentation. 

Regards, 

John. 

"Christopher Richards" <[email-masked]> 
30/01/2004 16:27 
        
        To:        "[email-masked]'" <[email-masked]> 
        cc:        "[email-masked]'" <[email-masked]>, [email-masked] 
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Thanks for the reply John, 
  
Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP. 
However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above? 
  
Best Regards,
Chris. 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]'; [email-masked]
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Hi Chris, 

The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this. 

There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services). 

For time-based services there is no need to report the Tariff-Time-Change AVP to the client.  It doesn't even need to know that the tariff has changed.  When the server knows that there is tariff change due it can take this into account when rating the granted units.  There is no need for any additional Diameter traffic for time-based services when there is a tariff change. 

Regards, 

John. 

"Christopher Richards" <[email-masked]> 
Sent by: [email-masked] 
30/01/2004 16:09         
       To:        "[email-masked]'" <[email-masked]> 
       cc:         
       Subject:        [AAA-WG]: DCC: Issue: Tariff Change mechanism.

All, 
Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft. 
Best Regards, 
Chris Richards. 
Description of issue: Tariff Change 
Submitter name: Chris Richards, Tim Roberts 
Date first submitted: 29.01.2004 
Reference: 
Document: draft-ietf-aaa-diameter-cc-02.txt 
Comment type: T 
Priority: ['S' Must fix | '1' Should fix | '2' May fix ] 
Sections: 8.16, 8.41 and 8.42 
Rationale/Explanation of issues: 
The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 
1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. 
2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values. 
3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit. 
Requested changes: 
- Section 5, last paragraph: 
FROM: 
 The Diameter credit-control server and client may optionally support a 
 tariff change mechanism. The Diameter credit-control server may 
 include a Tariff-Time-Change AVP in the answer message. Note that the 
 granted units should be allocated based on the worst-case scenario in 
 case of forthcoming tariff change, so that the overall reported used 
 units would never exceed the credit reservation.  
 When the Diameter credit-control client reports the used units and a 
 tariff change has occurred during the reporting period then the 
 Diameter credit-control client SHOULD itemize the units used before 
 and after the tariff change. In case some units straddled the tariff 
 change, the credit-control client SHOULD itemize those units as well. 
TO: 
 The Diameter credit-control server and client may optionally support a 
 tariff change mechanism. The Diameter credit-control server may 
 include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in 
 two quota allocations in the answer message. One of the granted units is 
 allocated to be used before the potential tariff change while the 
 second granted units are used after a tariff change. Both granted unit 
 quotas MUST contain the same Service-Identifier and Rating-Group values. 
 This dual quota mechanism ensures that the overall reported used 
 units would never exceed the credit reservation.  
 The Diameter credit-control client reports both the used units before 
 and after the tariff change. 
- Section 8.16, new paragraphs: 
NEW: 
 The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is 
 present. It instructs the client when the resources in the Granted-Service- 
 Unit AVP should be used. 
   When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, 
 the server MUST include two separate Granted-Service-Unit AVPs (for the 
 same Service-Identifier and/or Rating-Group when either the Service- 
 Identifier or Rating-Group AVP is included). One of the Granted-Service- 
 Units resources are used before a tariff change occurs, while the other 
 is to be used after the tariff change has occurred. 
- Section 8.16, last paragraph: 
FROM: 
 The Granted-Service-Unit AVP has the following ABNF grammar:   
           
       Granted-Service-Unit ::= < AVP Header: 431 > 
                                [ Tariff-Time-Change ]   
                                [ CC-Time ] 
                                [ CC-Money ]   
                                [ CC-Total-Octets ] 
                                [ CC-Input-Octets ] 
                                [ CC-Output-Octets ] 
                                [ CC-Service-Specific-Units ] 
                               *[ Service-Identifier ] 
                                [ Rating-Group ] 
TO: 
 The Granted-Service-Unit AVP has the following ABNF grammar:   
           
       Granted-Service-Unit ::= < AVP Header: 431 > 
                                [ Tariff-Time-Change ]   
                                [Tariff-Change-Usage ] 
                                [ CC-Time ] 
                                [ CC-Money ]   
                                [ CC-Total-Octets ] 
                                [ CC-Input-Octets ] 
                                [ CC-Output-Octets ] 
                                [ CC-Service-Specific-Units ] 
                               *[ Service-Identifier ] 
                                [ Rating-Group ] 
- Section 8.41, first and second paragraphs: 
FROM: 
 The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 
 includes the time in seconds since January 1, 1900 00:00 UTC when the 
 tariff of the service will be changed. 
  
 The tariff change mechanism is optional for client and server and it 
 is not used for unit type time, since the server has full control of 
 the time.  
  
TO: 
 The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 
 includes the time in seconds since January 1, 1900 00:00 UTC when the 
 tariff of the service will be changed. 
   The tariff change mechanism is optionally enabled by the server for a 
 Diameter credit control session or sub-session. 
- Section 8.42: 
FROM: 
 The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and 
 defines whether units are used before, after or straddled tariff 
 change when a tariff change has occurred during the reporting period. 
 Omission of this AVP means that no tariff change has been occurred. 
  
 Tariff-Change-Usage can be one of the following. 
  
  UNIT_BEFORE_TARIFF_CHANGE                                  0 
  
   The used units contains the amount of the units before tariff 
   change, that is units measured from the point when the previous 
   measurement ended to the point when tariff change occurred. 
  
  UNIT_AFTER_TARIFF_CHANGE                                   1 

   The used units contains the amount of the units after tariff change 
   has been occurred. 
  
  UNIT_INDETERMINATE                                         2 
  
   The used units contains the amount of units that straddle the 
   tariff change (e.g. the metering process reports to the credit- 
   control client in blocks of n octets and one block straddled the 
   tariff change). 
TO:    
 The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated. 
   When present in the Granted-Service-Units AVP, this AVP defines whether 
 units are allocated to be used before or after a tariff change event. 
   When present in the Used-Service-Units AVP, this AVP identified what 
 resources where used before or after a tariff change during the reporting 
 period. 
   Omission of this AVP means that no tariff change is to be reported and/or 
 none has occurred. 
  
 Tariff-Change-Usage can be one of the following. 
  
  UNIT_BEFORE_TARIFF_CHANGE                                  0 
  
   When present in the Granted-Service-Units AVP, this value indicates 
   the amount of the units allocated for use before a tariff change 
   occurs. 
     When present in the Reported-Service-Units AVP, this value indicates 
   the amount of resource units used before a tariff change had occurred. 
  
  UNIT_AFTER_TARIFF_CHANGE                                   1 
  
   When present in the Granted-Service-Units AVP, this value indicates 
   the amount of the units allocated for use after a tariff change 
   occurs. 
     When present in the Reported-Service-Units AVP, this value indicates 
   the amount of resource units used after tariff change had occurred. 
    
- end of changes 
Best Regards, 
Chris Richards. 

******************************************************************************

The content of this e-mail may be privileged and/or confidential.
If you are not the addressee indicated in this message 
(or responsible for delivery of the message to such person), 
you may not copy or deliver this message to anyone. In such 
case, you should destroy this message and kindly notify the 
sender and [email-masked] by reply email. Please
note that in such circumstances any review, dissemination, 
disclosure, alteration, printing, copying or further transmission
of this e-mail and/or any file transmitted with it is prohibited 
and may be unlawful. Please advise us immediately if you or
your employer do not consent to Internet email for messages 
of this kind. The opinions, conclusions and other information 
in this message are of the author and shall be understood as 
neither given nor endorsed by Vodafone Ireland Limited 
unless it is otherwise indicated by an authorised representative 
independent of this message. Internet e-mail is
transmitted over the public internet over which Vodafone 
Ireland Limited has no control. As such, there is no guarantee that 
(i) this e-mail will be delivered within a reasonable time or at all
(ii) this e-mail comes from the purported sender 
(iii) this e-mail has not been intercepted by a third party 
(iv) the contents of this e-mail are unaltered from the time of
transmission. The presence of this footnote indicates that this 
message (including its attachments) has been processed by an 
automated anti-virus system; however it is the responsibility of 
the recipient to ensure that the message (and attachments) 
are safe and authorised for use in their environment. 
Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), 
Pauline Best (UK), Paul Donovan Chief Executive (UK), 
Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK).
Registered in Ireland at MountainView, Leopardstown, Dublin 18. 
Number 326967 VAT Reg No. IE6346967G

****************************************************************************** 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: "Christopher Richards" <[email-masked]>
Date: Mon, 2 Feb 2004 10:06:45 -0600

Hi Leena,

Thanks for the reply. I have added some comments below.

Best Regards,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281

-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 6:10 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]'; [email-masked]';
[email-masked]'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris,

the way it is proposed in the draft-02 is similar as currently implemented
in the IN/CAMEL systems and we are not aware of any problem associated with
it, it just works nicely. 

   [CR] That's OK for voice traffic. I guess we need the
   input from some of some data OCS vendors. Interestingly,
   3GPP went with the new proposal for IMS in Release 5 -
   this was a Diameter protocol.

Concerning the proposed mechanism it seems the server would need to allocate
credit both before and after the tariff change.

   [CR] Yes. But this is effectively the same for the
   existing mechanism. Except that in the existing mechanism,
   since only one allocation can actually be given, the OCS
   must make the allocation based upon the worst case scenario
   and provide quota in small enough amounts so that the usage
   at a potentially higher cost can be covered by the users 
   account. In other words the OCS has to make decisions up 
   front that it can then only really reconcile after the usage.

 If the server wants to minimize the likelihood of higher 
re-authorization traffic load, it would have to allocate bigger credit in
both categories since it doesn't know whether more units will be consumed
before or after. 

   [CR] Not at all. It can make a decision about how much "after" 
   quota to allocate because it knows how much is available in the 
   users account because it has already allocated the "before" 
   quota. It now has the power to allocate as much or as little 
   "after" quota as it sees fit - smaller chunks to avoid credit 
   fragmentation - but this is also a function of how long before 
   a tariff change that the quota is requested. I.e. 30 seconds 
   before a TC, it can allocate more to the "after" quota. However, 
   if the request is being made 30 minutes before a TC, then it 
   would allocate less to the "after" quota.

If the server wants to minimize the credit fragmentation would need to
allocate smaller credit, at the expences of higher re-autht traffic load.
So, I fully agree with John P. in that the proposed mechanism defeats both
the objectives of trying to reduce credit fragmentation and trying to
minimize the re-auth traffic load.

   [CR] The intention of my proposal was not to make it optional: 
   it was to replace the existing scheme. I think we all agree 
   that 2 parallel mechanisms would be best to avoid. It will 
   make it more difficult for OCS vendors to implement.

John Loughney wrote:
>I am quite worried about additional optional mechanisms.  Already the 
>specification is quite complicated and I worry that additional optional 
>mechansisms will create extremely complicated mechanisms.
>
>I favor simplication at this point, so I'd hope we could discuss the 
>options and focus on a single mechansim.
>
I agree with this, we shouldn't introduce more optionality. We should
support only one way of doing tariff switch (tsw itself is optional already,
optionality within one option is not desirable).

BR,
Leena

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: 30. tammikuuta 2004 19:08
To: Christopher Richards
Cc: [email-masked]'; [email-masked]
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris, 

I've no objection myself in principle to your mechanism of allocating quotas
together for both units before and units after the tariff change.  As long
as it is all optional. 

The question is: how likely is the client to run out of the before units
before the time of the tariff change.  This would trigger an
re-authorisation even though the units after are unused.  To avoid this, the
server would have to allocated a higher quota in that category.
Alternatively, if the user did little before the tariff change and lots
after they would be likely to consume the units after much more quickly. 
  
Therefore, I suspect that this mechanism won't reduce the volume of
authorisation traffic in practice unless larger quotas are allocated, which
I think defeats your objective of trying to reduce credit fragmentation. 

Regards, 

John. 

        cc:        "[email-masked]'" <[email-masked]>,
[email-masked] 
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Since there are implementations that can generate straddling usage counts
today, I don't have a problem leaving this value in the Tariff-Change-Usage
AVP. 
However, I still think that the current proposed mechanism in the draft
should address it's shortcomings as I described in the Issue email I sent.
Will the change proposal be accepted as an issue to discuss? If so, should I
resubmit the issue with the change described above? 
  
Best Regards,
Chris. 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]'; [email-masked]
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Hi Chris, 

The option to specify units straddlling a tariff time change was suggested
by us as we have an implemented system that behaves like this. 

There is a fundamental difference between tariffs changing for a service
that is consumed at a regular rate (i.e. time based such as circuit-switched
calls) and one that is consumed at an irregular rate (such as GPRS or 3G
data services). 

For time-based services there is no need to report the Tariff-Time-Change
AVP to the client.  It doesn't even need to know that the tariff has
changed.  When the server knows that there is tariff change due it can take
this into account when rating the granted units.  There is no need for any
additional Diameter traffic for time-based services when there is a tariff
change. 

Regards, 

John. 

All, 
Please find enclosed issue regarding the current tariff change mechanism
specified in the DCC draft. 
Best Regards, 
Chris Richards. 
Description of issue: Tariff Change 
Submitter name: Chris Richards, Tim Roberts 
Date first submitted: 29.01.2004 
Reference: 
Document: draft-ietf-aaa-diameter-cc-02.txt 
Comment type: T 
Priority: ['S' Must fix | '1' Should fix | '2' May fix ] 
Sections: 8.16, 8.41 and 8.42 
Rationale/Explanation of issues: 
The current draft implements a tariff time change capability by allowing the
Used-Service-Units to report back the used resources before and after a
tariff change. However, the resources supplied by the DCC server are given
in a single Granted-Service-Units AVP. However, using this mechanism has a
number of drawbacks and practical issues: 
1. It is complex for the DCC server since it must reserve credit on the
basis of which will be more expensive before or after consumption (As
acknowledged in section 5 of the draft). This is particularly inconvenient
when the model changes e.g. some bundled minutes after the duration, or
rates change to a minimum of x or any other model. As a result, either the
server will have to allocate smaller quotas resulting in increased quota
activity or it will have to reserve a larger amount of credit exacerbating
credit fragmentation concerns. 
2. The draft document states that the mechanism is not used when the
resource unit is time. However, in order to perform tariff time changes, the
client will have to re-authorise all quotas for all sessions that react to
the same tariff time change - this will lead to a flood of messaging and
processing on the client and server which will result in delayed responses
and inaccurate time change values. 
3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism
has been introduced for the Diameter IMS charging application which avoids
the problems stated above - there are no longer used resources that straddle
a tariff change thus removing this indeterminate charging scenario. It would
seem highly desirable to align with this mechanism so all applications can
benefit. 
Requested changes: 
- Section 5, last paragraph: 
FROM: 
 The Diameter credit-control server and client may optionally support a 
 tariff change mechanism. The Diameter credit-control server may 
 include a Tariff-Time-Change AVP in the answer message. Note that the 
 granted units should be allocated based on the worst-case scenario in 
 case of forthcoming tariff change, so that the overall reported used 
 units would never exceed the credit reservation.  
 When the Diameter credit-control client reports the used units and a 
 tariff change has occurred during the reporting period then the 
 Diameter credit-control client SHOULD itemize the units used before 
 and after the tariff change. In case some units straddled the tariff 
 change, the credit-control client SHOULD itemize those units as well. 
TO: 
 The Diameter credit-control server and client may optionally support a 
 tariff change mechanism. The Diameter credit-control server may 
 include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in 
 two quota allocations in the answer message. One of the granted units is 
 allocated to be used before the potential tariff change while the 
 second granted units are used after a tariff change. Both granted unit 
 quotas MUST contain the same Service-Identifier and Rating-Group values. 
 This dual quota mechanism ensures that the overall reported used 
 units would never exceed the credit reservation.  
 The Diameter credit-control client reports both the used units before 
 and after the tariff change. 
- Section 8.16, new paragraphs: 
NEW: 
 The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is 
 present. It instructs the client when the resources in the Granted-Service-

 Unit AVP should be used. 
   When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are
present, 

  
  
TO: 

  

  
  UNIT_INDETERMINATE                                         2 

 none has occurred. 

  

    
- end of changes 
Best Regards, 
Chris Richards. 

****************************************************************************
**

The content of this e-mail may be privileged and/or confidential. If you are
not the addressee indicated in this message 
(or responsible for delivery of the message to such person), 
you may not copy or deliver this message to anyone. In such 
case, you should destroy this message and kindly notify the 
sender and [email-masked] by reply email. Please
note that in such circumstances any review, dissemination, 
disclosure, alteration, printing, copying or further transmission of this
e-mail and/or any file transmitted with it is prohibited 
and may be unlawful. Please advise us immediately if you or your employer do
not consent to Internet email for messages 
of this kind. The opinions, conclusions and other information 
in this message are of the author and shall be understood as 
neither given nor endorsed by Vodafone Ireland Limited 
unless it is otherwise indicated by an authorised representative 
independent of this message. Internet e-mail is
transmitted over the public internet over which Vodafone 
Ireland Limited has no control. As such, there is no guarantee that 
(i) this e-mail will be delivered within a reasonable time or at all
(ii) this e-mail comes from the purported sender 
(iii) this e-mail has not been intercepted by a third party 
(iv) the contents of this e-mail are unaltered from the time of
transmission. The presence of this footnote indicates that this 
message (including its attachments) has been processed by an 
automated anti-virus system; however it is the responsibility of 
the recipient to ensure that the message (and attachments) 
are safe and authorised for use in their environment. 
Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), 
Pauline Best (UK), Paul Donovan Chief Executive (UK), 
Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered
in Ireland at MountainView, Leopardstown, Dublin 18. 
Number 326967 VAT Reg No. IE6346967G

****************************************************************************
** 

This communication is confidential and intended solely for the addressee(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If
you believe this message has been sent to you in error, please notify the
sender by replying to this transmission and delete the message without
disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

---

From: <[email-masked]>
Date: Mon, 2 Feb 2004 18:49:47 +0200

3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225), the mechanism
of allocating quotas before and after was proposed there for time based services sometime ago. 
But for time based services there is no need for any interaction between server and client as 
also stated by John P.  Interestingly, there are couple of pending Change Requests against the 
concerned IMS Release 5 TS to remove the mechanism, so apparently not all in the 3GPP community
are of the same opinion. So the statement that "3GPP went  with the new proposal etc." is rather
inaccurate.
 
However, I think the AAA mailing list is not the appropriate place to discuss 3GPP specific
issues.
 
Thank you
Marco

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 02 February, 2004 18:07
To: 'Leena Mattila (TU/LMF)'
Cc: [email-masked]'; [email-masked]'; Loughney John (Nokia-NRC/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Leena, 

Best Regards, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message----- 
From: Leena Mattila (TU/LMF) [ mailto:[email-masked]] 
Sent: Monday, February 02, 2004 6:10 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked]'; [email-masked]' 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

Hi Chris, 

the way it is proposed in the draft-02 is similar as currently implemented in the IN/CAMEL systems and we are not aware of any problem associated with it, it just works nicely. 

Concerning the proposed mechanism it seems the server would need to allocate credit both before and after the tariff change.

 If the server wants to minimize the likelihood of higher 
re-authorization traffic load, it would have to allocate bigger credit in both categories since it doesn't know whether more units will be consumed before or after. 

If the server wants to minimize the credit fragmentation would need to allocate smaller credit, at the expences of higher re-autht traffic load. So, I fully agree with John P. in that the proposed mechanism defeats both the objectives of trying to reduce credit fragmentation and trying to minimize the re-auth traffic load.

>options and focus on a single mechansim. 
I agree with this, we shouldn't introduce more optionality. We should support only one way of doing tariff switch (tsw itself is optional already, optionality within one option is not desirable).

BR, 
Leena 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]]On Behalf Of [email-masked] 
Sent: 30. tammikuuta 2004 19:08 
To: Christopher Richards 
Cc: [email-masked]'; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

Hi Chris, 

Regards, 

John. 

  

Best Regards, 
Chris. 
-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: Friday, January 30, 2004 10:18 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked] 
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. 

Hi Chris, 

Regards, 

John. 

All, 

Requested changes: 

  
  
TO: 

  

  
  UNIT_INDETERMINATE                                         2 

  

  
    
- end of changes 
Best Regards, 
Chris Richards. 

The content of this e-mail may be privileged and/or confidential. If you are not the addressee indicated in this message 

disclosure, alteration, printing, copying or further transmission of this e-mail and/or any file transmitted with it is prohibited 

and may be unlawful. Please advise us immediately if you or your employer do not consent to Internet email for messages 

(iv) the contents of this e-mail are unaltered from the time of transmission. The presence of this footnote indicates that this 

Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK). Registered in Ireland at MountainView, Leopardstown, Dublin 18.

---

From: "Christopher Richards" <[email-masked]>
Date: Mon, 2 Feb 2004 11:11:06 -0600

Hi Marco, All,
 
Agreed, no need to talk 3GPP or any specific standards organisation other
than IETF here.
 
I'm interested in your statement that time based quotas have no interaction
between the client/server:

But for time based services there is no need for any interaction between
server and client as 
also stated by John P .

Could you explain your reasoning?

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 10:50 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

3GPP uses Diameter DCC in the context of IMS online charging (TS 32.225),
the mechanism
of allocating quotas before and after was proposed there for time based
services sometime ago. 
But for time based services there is no need for any interaction between
server and client as 
also stated by John P.  Interestingly, there are couple of pending Change
Requests against the 
concerned IMS Release 5 TS to remove the mechanism, so apparently not all in
the 3GPP community
are of the same opinion. So the statement that "3GPP went  with the new
proposal etc." is rather
inaccurate.
 
However, I think the AAA mailing list is not the appropriate place to
discuss 3GPP specific
issues.
 
Thank you
Marco

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
Christopher Richards
Sent: 02 February, 2004 18:07
To: 'Leena Mattila (TU/LMF)'
Cc: [email-masked]'; [email-masked]'; Loughney John
(Nokia-NRC/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Leena, 

Best Regards, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message----- 
From: Leena Mattila (TU/LMF) [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, February 02, 2004 6:10 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked]';
[email-masked]' 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

Hi Chris, 

BR, 
Leena 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of [email-masked] 
Sent: 30. tammikuuta 2004 19:08 
To: Christopher Richards 
Cc: [email-masked]'; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

Hi Chris, 

Regards, 

John. 

  

Best Regards, 
Chris. 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Friday, January 30, 2004 10:18 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked] 
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. 

Hi Chris, 

Regards, 

John. 

All, 

Requested changes: 

 Unit AVP should be used. 

  
  
TO: 

  

  
  UNIT_INDETERMINATE                                         2 

 none has occurred. 

  

    
- end of changes 
Best Regards, 
Chris Richards.

---

From: <[email-masked]>
Date: Mon, 2 Feb 2004 19:19:49 +0200

Hi Chris,

Chris Richards wrote:
>I'm interested in your statement that time based quotas have no interaction between the 
>client/server:
>But for time based services there is no need for any interaction between server and client >as also stated by John P .

The reasoning was clearly explained already. Here is an extract of the mail
with the explanation, I'm of the same opinion.

Regards
Marco

John Prudhoe wrote:

>For time-based services there is no need to report the Tariff-Time-Change AVP to the 
>client.  It doesn't even need to know that the tariff has changed.  When the server knows 
>that there is tariff change due it can take this into account when rating the granted 
>units.  There is no need for any additional Diameter traffic for time-based services when 
>there is a tariff change.

---

From: [email-masked]
Date: Mon, 2 Feb 2004 17:23:46 +0000

Hi Chris,

My reasoning behind this is that time based quotas are consumed at a 
regular rate (60 seconds per minute to be exact).  So imagine that the 
rating engine allocates 300 seconds at a time 130 seconds before the 
tariff time change.  At that point it already knows that 130seconds will 
be consumed at the before rate and 170 seconds will be consumed at the 
rate afterwards.

The client only knows it has been given 300s not how much it costs and it 
need never know about the tariff time change.  If the session continues, 
the client will come back at the end of the 300s and not at the time of 
the tariff change.

If the session ends after, say, 90s the rating engine knows that has all 
been consumed at the before rate.  If it ends after 140seconds, the rating 
engine knows it can be split into 130s at the before rate and 10s at the 
after rate.  In neither of these circumstances does the client need to 
know about the tariff time change nor does it need to return to the server 
at the time of the tariff change.

I hope this explains it.

Regards,

John. 

02/02/2004 17:11

        To:     "[email-masked]'" <[email-masked]>
        cc:     [email-masked], [email-masked], [email-masked]
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Marco, All,

I'm interested in your statement that time based quotas have no 
interaction between the client/server:
But for time based services there is no need for any interaction between 
server and client as 
also stated by John P .
Could you explain your reasoning?
Cheers, 
Chris. 
Shasta Wireless Development 
Nortel Networks 
Telephone: 
+1 972 684 3281 
ESN 444 3281 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 10:50 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

concerned IMS Release 5 TS to remove the mechanism, so apparently not all 
in the 3GPP community

Thank you
Marco

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 02 February, 2004 18:07
To: 'Leena Mattila (TU/LMF)'
Cc: [email-masked]'; [email-masked]'; Loughney John 
(Nokia-NRC/Helsinki)

Hi Leena, 

-----Original Message----- 
From: Leena Mattila (TU/LMF) [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 6:10 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked]'; 

Hi Chris, 
in the IN/CAMEL systems and we are not aware of any problem associated 
with it, it just works nicely. 
Concerning the proposed mechanism it seems the server would need to 
allocate credit both before and after the tariff change.
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked] 
Sent: 30. tammikuuta 2004 19:08 
To: Christopher Richards 
Cc: [email-masked]'; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 
Hi Chris, 
I've no objection myself in principle to your mechanism of allocating 
quotas together for both units before and units after the tariff change. 
As long as it is all optional. 

The question is: how likely is the client to run out of the before units 
before the time of the tariff change.  This would trigger an 
re-authorisation even though the units after are unused.  To avoid this, 
the server would have to allocated a higher quota in that category. 
Alternatively, if the user did little before the tariff change and lots 
after they would be likely to consume the units after much more quickly. 
 
Therefore, I suspect that this mechanism won't reduce the volume of 
authorisation traffic in practice unless larger quotas are allocated, 
which I think defeats your objective of trying to reduce credit 
fragmentation. 
Regards, 
John. 

        To:        "[email-masked]'" 
<[email-masked]> 
        cc:        "[email-masked]'" <[email-masked]>, 
[email-masked] 
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism. 

Since there are implementations that can generate straddling usage counts 
today, I don't have a problem leaving this value in the 
Tariff-Change-Usage AVP. 
However, I still think that the current proposed mechanism in the draft 
should address it's shortcomings as I described in the Issue email I sent. 
Will the change proposal be accepted as an issue to discuss? If so, should 
I resubmit the issue with the change described above? 
 
Best Regards, 
Chris. 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 30, 2004 10:18 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked] 
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. 

Hi Chris, 
The option to specify units straddlling a tariff time change was suggested 
by us as we have an implemented system that behaves like this. 
There is a fundamental difference between tariffs changing for a service 
that is consumed at a regular rate (i.e. time based such as 
circuit-switched calls) and one that is consumed at an irregular rate 
(such as GPRS or 3G data services). 
For time-based services there is no need to report the Tariff-Time-Change 
AVP to the client.  It doesn't even need to know that the tariff has 
changed.  When the server knows that there is tariff change due it can 
take this into account when rating the granted units.  There is no need 
for any additional Diameter traffic for time-based services when there is 
a tariff change. 
Regards, 
John. 

All, 
Please find enclosed issue regarding the current tariff change mechanism 
specified in the DCC draft. 
Best Regards, 
Chris Richards. 
Description of issue: Tariff Change 
Submitter name: Chris Richards, Tim Roberts 
Date first submitted: 29.01.2004 
Reference: 
Document: draft-ietf-aaa-diameter-cc-02.txt 
Comment type: T 
Priority: ['S' Must fix | '1' Should fix | '2' May fix ] 
Sections: 8.16, 8.41 and 8.42 
Rationale/Explanation of issues: 
The current draft implements a tariff time change capability by allowing 
the Used-Service-Units to report back the used resources before and after 
a tariff change. However, the resources supplied by the DCC server are 
given in a single Granted-Service-Units AVP. However, using this mechanism 
has a number of drawbacks and practical issues: 
1. It is complex for the DCC server since it must reserve credit on the 
basis of which will be more expensive before or after consumption (As 
acknowledged in section 5 of the draft). This is particularly inconvenient 
when the model changes e.g. some bundled minutes after the duration, or 
rates change to a minimum of x or any other model. As a result, either the 
server will have to allocate smaller quotas resulting in increased quota 
activity or it will have to reserve a larger amount of credit exacerbating 
credit fragmentation concerns. 
2. The draft document states that the mechanism is not used when the 
resource unit is time. However, in order to perform tariff time changes, 
the client will have to re-authorise all quotas for all sessions that 
react to the same tariff time change - this will lead to a flood of 
messaging and processing on the client and server which will result in 
delayed responses and inaccurate time change values. 
3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism 
has been introduced for the Diameter IMS charging application which avoids 
the problems stated above - there are no longer used resources that 
straddle a tariff change thus removing this indeterminate charging 
scenario. It would seem highly desirable to align with this mechanism so 
all applications can benefit. 
Requested changes: 
- Section 5, last paragraph: 
FROM: 
 The Diameter credit-control server and client may optionally support a 
 tariff change mechanism. The Diameter credit-control server may 
 include a Tariff-Time-Change AVP in the answer message. Note that the 
 granted units should be allocated based on the worst-case scenario in 
 case of forthcoming tariff change, so that the overall reported used 
 units would never exceed the credit reservation. 
 When the Diameter credit-control client reports the used units and a 
 tariff change has occurred during the reporting period then the 
 Diameter credit-control client SHOULD itemize the units used before 
 and after the tariff change. In case some units straddled the tariff 
 change, the credit-control client SHOULD itemize those units as well. 
TO: 
 The Diameter credit-control server and client may optionally support a 
 tariff change mechanism. The Diameter credit-control server may 
 include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in 
 two quota allocations in the answer message. One of the granted units is 
 allocated to be used before the potential tariff change while the 
 second granted units are used after a tariff change. Both granted unit 
 quotas MUST contain the same Service-Identifier and Rating-Group values. 
 This dual quota mechanism ensures that the overall reported used 
 units would never exceed the credit reservation. 
 The Diameter credit-control client reports both the used units before 
 and after the tariff change. 
- Section 8.16, new paragraphs: 
NEW: 
 The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP 
is 
 present. It instructs the client when the resources in the 
Granted-Service- 
 Unit AVP should be used. 
   When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are 
present, 
 the server MUST include two separate Granted-Service-Unit AVPs (for the 
 same Service-Identifier and/or Rating-Group when either the Service- 
 Identifier or Rating-Group AVP is included). One of the Granted-Service- 
 Units resources are used before a tariff change occurs, while the other 
 is to be used after the tariff change has occurred. 
- Section 8.16, last paragraph: 
FROM: 
 The Granted-Service-Unit AVP has the following ABNF grammar: 

 
 
TO: 

 

  UNIT_INDETERMINATE                                         2 

 period. 
   Omission of this AVP means that no tariff change is to be reported 
and/or 
 none has occurred. 

 

 
- end of changes 
Best Regards, 
Chris Richards. 

The content of this e-mail may be privileged and/or confidential. If you 
are not the addressee indicated in this message 
and may be unlawful. Please advise us immediately if you or your employer 
do not consent to Internet email for messages 

This communication is confidential and intended solely for the 
addressee(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you believe this message has been sent to you in error, 
please notify the sender by replying to this transmission and delete the 
message without disclosing it. Thank you.
E-mail including attachments is susceptible to data corruption, 
interruption, unauthorized amendment, tampering and viruses, and we only 
send and receive e-mails on the basis that we are not liable for any such 
corruption, interception, amendment, tampering or viruses or any 
consequences thereof.

---

From: "Christopher Richards" <[email-masked]>
Date: Mon, 2 Feb 2004 12:32:06 -0600

Hi John,

Thanks for the explanation.

Time units then are not such a big issue for TC - the only limitation being
that when allocating quotas in time, there is no way to tell what events or
bytes were used when during the quota usage. E.g. the user pays the operator
based upon time, but a third party content provider pays the operator based
upon bytes/events used by the user at a particular time. Perhaps that's not
a big deal and there are ways around it (Allocate quota in bytes/events
always).

It also appears that resource usage straddling a TC is not an issue either
(Although, as an operator, I'd have to disagree!) - it is a limitation due
to implementation rather than due to the specification.

With that in mind, here is the updated proposal:-

Sections: 5.0, 8.16

1. It is complex for the DCC server since it must reserve credit on the
basis of which will be more expensive before or after consumption (As
acknowledged in section 5 of the draft). This is particularly inconvenient
when the model changes e.g. some bundled minutes after the duration, or
rates change to a minimum of x or any other model. As a result, either the
server will have to allocate smaller quotas resulting in increased quota
activity and possibly impacted subscriber experience, or it will have to
reserve a larger amount of credit exacerbating credit fragmentation
concerns.

Requested changes:

FROM:

TO:

NEW:

FROM:

- end of changes

Best Regards, 
Chris. 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 11:24 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]'

Hi Chris, 

My reasoning behind this is that time based quotas are consumed at a regular
rate (60 seconds per minute to be exact).  So imagine that the rating engine
allocates 300 seconds at a time 130 seconds before the tariff time change.
At that point it already knows that 130seconds will be consumed at the
before rate and 170 seconds will be consumed at the rate afterwards. 

The client only knows it has been given 300s not how much it costs and it
need never know about the tariff time change.  If the session continues, the
client will come back at the end of the 300s and not at the time of the
tariff change. 

If the session ends after, say, 90s the rating engine knows that has all
been consumed at the before rate.  If it ends after 140seconds, the rating
engine knows it can be split into 130s at the before rate and 10s at the
after rate.  In neither of these circumstances does the client need to know
about the tariff time change nor does it need to return to the server at the
time of the tariff change. 

I hope this explains it. 

Regards, 

John. 

        To:        "[email-masked]'" <[email-masked]> 
        cc:        [email-masked], [email-masked],
[email-masked] 
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Marco, All, 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 10:50 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

  
  
Thank you 
Marco 

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

Hi Leena, 
-----Original Message----- 

       

 
Best Regards, 
Chris. 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 30, 2004 10:18 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked] 
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. 
Hi Chris, 

All, 

          

TO: 

 

 UNIT_INDETERMINATE                                         2 

 

 
   
- end of changes 
Best Regards, 
Chris Richards.

---

From: [email-masked]
Date: Mon, 2 Feb 2004 19:08:07 +0000

Hi Chris,

I'd like to work through a couple of examples to illustrate the respective 
merits of your proposal and the existing mechanism.  I'm making up these 
examples entirely at random to compare the cases.

Example 1: old mechanism.

A client wants a quota to send data over GPRS.  It is 15 minutes before 
the tariff change.  The tariff is higher before the change.  The server 
allocates 50K with a validity time of 30 minutes, say.

The user uses 40K (which at the end of the validity time is reported as 
30K before the change and 10K afterwards).  This is rated at that time and 
some of the monetary reservation is returned to the subscribers balance. 
This means there are three rating events in the billing system - one for 
the original quota at the worst case rate and one at each of the two rates 
when the used quota is reported.

Example 2: new mechanism.

The client still wants a quota to send data over GPRS.  The server 
allocates 25K at the expensive rate and 25K at the cheap rate.  (That's 
already two rating events in the billing system).  Validity time again 30 
minutes.

I disagree with your earlier point that the cheap rate can be a large 
quota because the goal is to minimise the amount reserved for any one 
service so that funds are available for other activity (such as voice or 
SMS).

Anyway, as before, the user tries to use 30K before the tariff time 
change, but only has a quota of 25K so has to return after that has been 
exhausted.  Whether the billing engine re-rates the used quota isn this 
case is implementation dependent, but it will definitely have to rate 
twice for the new quota, which will be again of 25K + 25K.  When the 
client next returns it will reports the usage in these categories, which 
will again have to be rated.

So in example one, there are three rating events and the exchange of two 
Diameter command pairs.  In example two there are between six and eight 
rating events and the exchange of three Diameter command pairs.  Even in 
the best case with your method I believe there will be four rating events.

I'm afraid I'm still of the opinion that the proposed change is less than 
efficient than the mechanism that you want to replace, so unless anyone 
can point out clear advantages with it that I haven't spotted my vote 
remains against it.

Regards,

John

02/02/2004 18:32

        To:     "[email-masked]'" <[email-masked]>
        cc:     [email-masked], [email-masked], "[email-masked]'" 
<[email-masked]>
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi John, 
Time units then are not such a big issue for TC - the only limitation 
being that when allocating quotas in time, there is no way to tell what 
events or bytes were used when during the quota usage. E.g. the user pays 
the operator based upon time, but a third party content provider pays the 
operator based upon bytes/events used by the user at a particular time. 
Perhaps that's not a big deal and there are ways around it (Allocate quota 
in bytes/events always).

Requested changes: 
   two quota allocations in the answer message. One of the granted units 
   quotas MUST contain the same Service-Identifier and Rating-Group 
values. 
   Identifier or Rating-Group AVP is included). One of the 

- end of changes 

Best Regards, 
Chris. 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 11:24 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]' 

Hi Chris, 

Hi Marco, All, 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 10:50 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 
   [CR] That's OK for voice traffic. I guess we need the 
  input from some of some data OCS vendors. Interestingly, 
  3GPP went with the new proposal for IMS in Release 5 - 
  this was a Diameter protocol. 

 
Thank you 
Marco 

 -----Original Message----- 
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards 
Sent: 02 February, 2004 18:07 
To: 'Leena Mattila (TU/LMF)' 
Cc: [email-masked]'; [email-masked]'; Loughney John 
(Nokia-NRC/Helsinki) 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked] 
Sent: 30. tammikuuta 2004 19:08 
To: Christopher Richards 
Cc: [email-masked]'; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 
Hi Chris, 

 

  
Best Regards, 
Chris. 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 30, 2004 10:18 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked] 
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. 
Hi Chris, 

All, 

 

TO: 

  

 UNIT_INDETERMINATE                                         2 

  

  
 
- end of changes 
Best Regards, 
Chris Richards.

---

From: "Christopher Richards" <[email-masked]>
Date: Mon, 2 Feb 2004 13:58:58 -0600

Hi John,
 
Thanks again, that's very constructive. But it highlights the problems of
using examples though. There's never one definitive answer as highlighted by
this example:-
 
Old mechanism:
 
A client wants a quota to send data over GPRS.  It is 5 minutes before the
tariff change. The tariff is lower before the change: 20 cents per K before
the TC, $1 per K at the higher.  The user only has $5 in his account. So the
server allocates for the worst case scenario: 5K usage (Rated at $5) is
provided! After a few seconds the 5K is used, the client makes another
request for quota. Server takes the 5K @ 20c/K from the user account making
it $4 and allocates another worst case scenario - this time for 4K. And so
it continues - at some point the user is denied usage even though there is
some funds in his account that could be used at the lower rate of 20 cents/K
but cannot be allocated using the higher rate because the allocation would
be too small. 

New mechanism:
 
A client wants a quota to send data over GPRS.  It is 5 minutes before the
tariff change. The tariff is lower before the change: 20 cents per K before
the TC, $1 per K at the higher.  The user only has $5 in his account. So the
server allocates 20K at 20 cents/K and a further 1K at $1/K. User can use
20K before having to request new quota - even if it is used before the TC.
If it is not used before the TC, user has 1K of use at the expensive rate.
 
In the old mechanism user funds cannot be used for the lower rate even
though funds are available because allocation must use the worst case rating
scenario. Also, since initial allocations used the worst case rating
scenario, the quotas provided are relatively small - requiring more
re-authorisation requests.
 
In the new mechanism the full balance in the account can be provided for
use. And since the cheaper rated quotas are larger, less re-authorisations
are needed. Essentially, the server does not have to make usage reservations
based upon what cost the usage might be. It provides allocations based upon
what is being used at the current rate.

Cheers, 
Chris. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 1:08 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris, 

A client wants a quota to send data over GPRS.  It is 15 minutes before the
tariff change.  The tariff is higher before the change.  The server
allocates 50K with a validity time of 30 minutes, say. 

The user uses 40K (which at the end of the validity time is reported as 30K
before the change and 10K afterwards).  This is rated at that time and some
of the monetary reservation is returned to the subscribers balance.  This
means there are three rating events in the billing system - one for the
original quota at the worst case rate and one at each of the two rates when
the used quota is reported. 

The client still wants a quota to send data over GPRS.  The server allocates
25K at the expensive rate and 25K at the cheap rate.  (That's already two
rating events in the billing system).  Validity time again 30 minutes. 

I disagree with your earlier point that the cheap rate can be a large quota
because the goal is to minimise the amount reserved for any one service so
that funds are available for other activity (such as voice or SMS). 

Anyway, as before, the user tries to use 30K before the tariff time change,
but only has a quota of 25K so has to return after that has been exhausted.
Whether the billing engine re-rates the used quota isn this case is
implementation dependent, but it will definitely have to rate twice for the
new quota, which will be again of 25K + 25K.  When the client next returns
it will reports the usage in these categories, which will again have to be
rated. 

So in example one, there are three rating events and the exchange of two
Diameter command pairs.  In example two there are between six and eight
rating events and the exchange of three Diameter command pairs.  Even in the
best case with your method I believe there will be four rating events. 

I'm afraid I'm still of the opinion that the proposed change is less than
efficient than the mechanism that you want to replace, so unless anyone can
point out clear advantages with it that I haven't spotted my vote remains
against it. 

Regards, 

John 

02/02/2004 18:32 

        cc:        [email-masked], [email-masked],
"[email-masked]'" <[email-masked]> 
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi John, 

Requested changes: 

FROM: 

TO: 

NEW: 

FROM: 

- end of changes 

Best Regards, 
Chris. 
-----Original Message----- 
From: [email-masked] [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Monday, February 02, 2004 11:24 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]' 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

Hi Chris, 

I hope this explains it. 

Regards, 

John. 

Hi Marco, All, 

-----Original Message----- 
From: [email-masked] [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Monday, February 02, 2004 10:50 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

 
 
Thank you 
Marco 

-----Original Message----- 
From: [email-masked] [ <mailto:[email-masked]>
mailto:[email-masked]]On Behalf Of ext Christopher Richards 
Sent: 02 February, 2004 18:07 
To: 'Leena Mattila (TU/LMF)' 
Cc: [email-masked]'; [email-masked]'; Loughney John
(Nokia-NRC/Helsinki) 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

Hi Leena, 
-----Original Message----- 
From: Leena Mattila (TU/LMF) [ <mailto:[email-masked]>
mailto:[email-masked]] 

BR, 
Leena 
-----Original Message----- 
From: [email-masked] [ <mailto:[email-masked]>
mailto:[email-masked]]On Behalf Of [email-masked] 
Sent: 30. tammikuuta 2004 19:08 
To: Christopher Richards 
Cc: [email-masked]'; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 
Hi Chris, 
I've no objection myself in principle to your mechanism of allocating quotas
together for both units before and units after the tariff change.  As long
as it is all optional. 

  

Regards, 
John. 

 

  
Best Regards, 
Chris. 
-----Original Message----- 
From: [email-masked] [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Friday, January 30, 2004 10:18 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked] 
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. 
Hi Chris, 
The option to specify units straddlling a tariff time change was suggested
by us as we have an implemented system that behaves like this. 

Regards, 
John. 

All, 

Requested changes: 

 
 
TO: 

 

UNIT_INDETERMINATE                                         2 

 

 
  
- end of changes 
Best Regards, 
Chris Richards.

---

From: <[email-masked]>
Date: Tue, 3 Feb 2004 07:21:53 +0200

I updated issue 18 accordingly.
 
John

-----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: 02 February, 2004 20:32
To: [email-masked]'
Cc: [email-masked]; Loughney John (Nokia-NRC/Helsinki); Stura Marco (Nokia-NET/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi John, 

Time units then are not such a big issue for TC - the only limitation being that when allocating quotas in time, there is no way to tell what events or bytes were used when during the quota usage. E.g. the user pays the operator based upon time, but a third party content provider pays the operator based upon bytes/events used by the user at a particular time. Perhaps that's not a big deal and there are ways around it (Allocate quota in bytes/events always).

It also appears that resource usage straddling a TC is not an issue either (Although, as an operator, I'd have to disagree!) - it is a limitation due to implementation rather than due to the specification.

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity and possibly impacted subscriber experience, or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns.

Requested changes: 

FROM: 

TO: 

NEW: 

FROM: 

- end of changes 

Best Regards, 
Chris. 
-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: Monday, February 02, 2004 11:24 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]' 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

Hi Chris, 

My reasoning behind this is that time based quotas are consumed at a regular rate (60 seconds per minute to be exact).  So imagine that the rating engine allocates 300 seconds at a time 130 seconds before the tariff time change.  At that point it already knows that 130seconds will be consumed at the before rate and 170 seconds will be consumed at the rate afterwards. 

The client only knows it has been given 300s not how much it costs and it need never know about the tariff time change.  If the session continues, the client will come back at the end of the 300s and not at the time of the tariff change. 

If the session ends after, say, 90s the rating engine knows that has all been consumed at the before rate.  If it ends after 140seconds, the rating engine knows it can be split into 130s at the before rate and 10s at the after rate.  In neither of these circumstances does the client need to know about the tariff time change nor does it need to return to the server at the time of the tariff change. 

I hope this explains it. 

Regards, 

John. 

Hi Marco, All, 
  
Agreed, no need to talk 3GPP or any specific standards organisation other than IETF here. 
  
I'm interested in your statement that time based quotas have no interaction between the client/server: 
But for time based services there is no need for any interaction between server and client as 
also stated by John P . 
Could you explain your reasoning? 
Cheers, 
Chris. 
Shasta Wireless Development 
Nortel Networks 
Telephone: 
+1 972 684 3281 
ESN 444 3281 
-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: Monday, February 02, 2004 10:50 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

  
  
Thank you 
Marco 

 -----Original Message----- 
From: [email-masked] [ mailto:[email-masked]]On Behalf Of ext Christopher Richards 
Sent: 02 February, 2004 18:07 
To: 'Leena Mattila (TU/LMF)' 
Cc: [email-masked]'; [email-masked]'; Loughney John (Nokia-NRC/Helsinki) 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

Hi Leena, 
-----Original Message----- 
From: Leena Mattila (TU/LMF) [ mailto:[email-masked]] 
Sent: Monday, February 02, 2004 6:10 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked]'; [email-masked]' 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 
Hi Chris, 

BR, 
Leena 
-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]]On Behalf Of [email-masked] 
Sent: 30. tammikuuta 2004 19:08 
To: Christopher Richards 
Cc: [email-masked]'; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 
Hi Chris, 

Regards, 
John. 

  

Best Regards, 
Chris. 
-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: Friday, January 30, 2004 10:18 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked] 
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. 
Hi Chris, 

Regards, 
John. 

All, 

Requested changes: 

  
  
TO: 

  

 UNIT_INDETERMINATE                                         2 

  

  
   
- end of changes 
Best Regards, 
Chris Richards.

---

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Tue, 3 Feb 2004 09:05:45 +0100

Hi Chris,
 
we still seem to have some quite big differences in our reasonings.
Who said I was talking about voice traffic only? CAMEL is used for data charging, and the method described in the current
draft is fully backwards compatible with that. Besides, implementations for that mechanism exist and haven't heard
of any problems with that.
 
I strongly disagree with your arguments about better efficiency of this new proposal. Yes, it may cause less signaling in some exeptional cases (as you have illustrated in other mails) but as John P. very well pointed out, your proposal actually increases signaling in most of the cases and involves much more rating rounds. We should not design a protocol to optimize the behavior in some extreme cases with the expense of more complexity and most likely poorer performance in normal cases. So, my vote remains against this (even updated) issue.
 
I do agree with you with that that we should only support one mechanism. But I think that mechanism should be the one described currently in the draft. And as far as I understand that is the opinion of the others involved as well.
 
BR,
Leena

-----Original Message-----
From: Christopher Richards [mailto:[email-masked]]
Sent: 2. helmikuuta 2004 18:07
To: Leena Mattila (TU/LMF)
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Leena, 

Best Regards, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message----- 
From: Leena Mattila (TU/LMF) [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Monday, February 02, 2004 6:10 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked]'; [email-masked]' 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

Hi Chris, 

BR, 
Leena 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ]On Behalf Of [email-masked] 
Sent: 30. tammikuuta 2004 19:08 
To: Christopher Richards 
Cc: [email-masked]'; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

Hi Chris, 

Regards, 

John. 

  

Best Regards, 
Chris. 
-----Original Message----- 
From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, January 30, 2004 10:18 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked] 
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. 

Hi Chris, 

Regards, 

John. 

All, 

Requested changes: 

  
  
TO: 

  

  
  UNIT_INDETERMINATE                                         2 

  

  
    
- end of changes 
Best Regards, 
Chris Richards.

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Tue, 3 Feb 2004 09:32:53 +0100

Hi Chris,

Our point is that the mechanism defined in the draft-02 is similar as currently
implemented in several systems and existing standardized protocol (CAP v.3) works 
similar way as well. As you know CAP v.3 is not used only for voice traffic, it is
valid also for GPRS data, i.e. there exists own GPRS charging procedures.

As Leena said we are not aware of any problem associated with this mechanisms so 
why we should change something which works very well in existing implementations?
 
I think also that this principle is fully in line with the backwards compatibility 
requirements with existing systems. If the tariff switch for data charging works
in this way for one node (access) I don't understand why we should have a different
TSw mechanism for the other node (gateway), when the charging of these nodes are 
under same server's control.

Regards.........Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Christopher Richards
Sent: 2. helmikuuta 2004 20:32
To: [email-masked]'
Cc: [email-masked]; [email-masked]; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi John, 

Requested changes: 

- end of changes 

Best Regards, 
Chris.

---

From: [email-masked]
Date: Tue, 3 Feb 2004 09:50:57 +0000

Hi Chris,

Thanks for the reply.  It's a good example, but I'd argue it is a rare 
case.

My thinking at the moment is that as the subscribers balance gets very low 
we would have to reduce the validity time of any quota anyway so there is 
at least adequate co-ordination between the expiry of, say, parallel voice 
& data sessions.

The unfortunate subscriber who is running out of balance just as the rate 
is about to increase five-fold shouldn't cause as much of a problem as you 
envisage.  Because the validity time is being reduced anyway there is a 
much smaller time window that could include the tariff change.

Regards,

John.

02/02/2004 19:58

Hi John,
 
Thanks again, that's very constructive. But it highlights the problems of 
using examples though. There's never one definitive answer as highlighted 
by this example:-
 
Old mechanism:
 
A client wants a quota to send data over GPRS.  It is 5 minutes before the 
tariff change. The tariff is lower before the change: 20 cents per K 
before the TC, $1 per K at the higher.  The user only has $5 in his 
account. So the server allocates for the worst case scenario: 5K usage 
(Rated at $5) is provided! After a few seconds the 5K is used, the client 
makes another request for quota. Server takes the 5K @ 20c/K from the user 
account making it $4 and allocates another worst case scenario - this time 
for 4K. And so it continues - at some point the user is denied usage even 
though there is some funds in his account that could be used at the lower 
rate of 20 cents/K but cannot be allocated using the higher rate because 
the allocation would be too small. 
New mechanism:
 
A client wants a quota to send data over GPRS.  It is 5 minutes before the 
tariff change. The tariff is lower before the change: 20 cents per K 
before the TC, $1 per K at the higher.  The user only has $5 in his 
account. So the server allocates 20K at 20 cents/K and a further 1K at 
$1/K. User can use 20K before having to request new quota - even if it is 
used before the TC. If it is not used before the TC, user has 1K of use at 
the expensive rate.
 
In the old mechanism user funds cannot be used for the lower rate even 
though funds are available because allocation must use the worst case 
rating scenario. Also, since initial allocations used the worst case 
rating scenario, the quotas provided are relatively small - requiring more 
re-authorisation requests.
 
In the new mechanism the full balance in the account can be provided for 
use. And since the cheaper rated quotas are larger, less re-authorisations 
are needed. Essentially, the server does not have to make usage 
reservations based upon what cost the usage might be. It provides 
allocations based upon what is being used at the current rate.
Cheers, 
Chris. 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 1:08 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris, 

Regards, 

John 

Hi John, 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 11:24 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]' 

Hi Chris, 

Hi Marco, All, 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 10:50 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 
   [CR] That's OK for voice traffic. I guess we need the 
 input from some of some data OCS vendors. Interestingly, 
 3GPP went with the new proposal for IMS in Release 5 - 
 this was a Diameter protocol. 

 
Thank you 
Marco 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards 
Sent: 02 February, 2004 18:07 
To: 'Leena Mattila (TU/LMF)' 
Cc: [email-masked]'; [email-masked]'; Loughney John 
(Nokia-NRC/Helsinki) 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked] 
Sent: 30. tammikuuta 2004 19:08 
To: Christopher Richards 
Cc: [email-masked]'; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 
Hi Chris, 

 

  
Best Regards, 
Chris. 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 30, 2004 10:18 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked] 
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. 
Hi Chris, 

All, 

 

TO: 

 

UNIT_INDETERMINATE                                         2 

none has occurred. 

 

 
- end of changes 
Best Regards, 
Chris Richards.

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 6 Feb 2004 15:00:21 -0000

John, all,
 
I guess the issue we see with the single-quota mechanism for tariff change
is that it requires "over-reservation" - there is credit reserved that the
user cannot access before the tariff change. The amount of this credit is
related to the size of the quota granted. If the authorisation is being
given some time before the tariff change, then this could be quite
significant and result in unnecessary early re-authorisation/credit
fragmentation.
 
A five-fold increase in rate is not so likely, I agree, but more likely is
an increase from zero-rated to per-MB, which is worse! For example as a user
moves from a period where MB/hours bundled with the subscription are valid
into a period where they are not. You are forcing credit reservation and
re-auths based on the per-MB price throughout the 'bundled' period - exactly
when the user might be using the service most!
 
Dual-quotas (before & after) also have the property that some credit is
always reserved for after the tariff change, but there are two important
differences:
- this quantity can be chosen by the operator independent of the quota given
for before the time change
- credit pooling will allow this reserved credit to be accessed before the
time change
 
I also don't see much difference in the workload at the OCS - it has to
calculate the rates before and after the tariff change in all cases (to see
which is higher in the single quota case) and that is most of the work -
actually calculating the size of the quota is just a multiplication
operation.
 
In practice the 'after' quota might be fairly small - it's purpose being
largely to spread re-auths over some period (e.g. 30 mins) after the actual
tariff change. This also would avoid some of the problems raised below.
 
Regards,
 
Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 03 February 2004 09:51
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked]';
[email-masked]'

Hi Chris, 

Thanks for the reply.  It's a good example, but I'd argue it is a rare case.

My thinking at the moment is that as the subscribers balance gets very low
we would have to reduce the validity time of any quota anyway so there is at
least adequate co-ordination between the expiry of, say, parallel voice &
data sessions. 

The unfortunate subscriber who is running out of balance just as the rate is
about to increase five-fold shouldn't cause as much of a problem as you
envisage.  Because the validity time is being reduced anyway there is a much
smaller time window that could include the tariff change. 

Regards, 

John. 

02/02/2004 19:58 

Hi John, 

Old mechanism: 

  

Cheers, 
Chris. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 1:08 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris, 

Regards, 

John 

02/02/2004 18:32 

Hi John, 

Requested changes: 

FROM: 

TO: 

NEW: 

 Unit AVP should be used. 

FROM: 

- end of changes 

Best Regards, 
Chris. 
-----Original Message----- 

Hi Chris, 

I hope this explains it. 

Regards, 

John. 

Hi Marco, All, 

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

Thank you 
Marco 

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

Hi Leena, 
-----Original Message----- 

BR, 
Leena 
-----Original Message----- 

  

Regards, 
John. 

  
Best Regards, 
Chris. 
-----Original Message----- 

Regards, 
John. 

All, 

Requested changes: 

TO: 

UNIT_INDETERMINATE                                         2 

 
- end of changes 
Best Regards, 
Chris Richards.

---

From: [email-masked]
Date: Fri, 6 Feb 2004 15:39:02 +0000

Hi Mark,

I think it's understood by all that the single-quota will cause some 'over 
reservation'.  That is simply a consequence of combining a tariff change 
with irregular consumption of units.  However, I think all those who have 
responded have agreed that the proposed change would exacerbate the 
problem.

The change from zero-rated to charged is something that has not been 
mentioned before (that I've noticed) but it is an interesting case.  It is 
certainly the first realistic example where the proposed mechanism would 
be better than the existing mechanism.

At an early stage of the discussion on this subject it was concluded that 
there shouldn't be two options, so I was concerned about the adverse 
impact on the existing mechanism. My opinion is that it is unacceptable 
that a solution for this zero-rated-to-charged transition makes things 
worse for the general case, but I feel that it is reasonable that we 
identify a mechanism to support your requirements that does not adversely 
impact everybody else.

And because I still believe the proposed changes will make the general 
case worse, I still think that the proposed changes should be rejected. 
What we need are new ideas on the subject.

Regards,

John.

PS So far I've only had one idea, and I'll be the first to admit it is not 
perfect.  Perhaps if we pass two extra optional AVPs (haven't considered 
in detail where yet)...  One is the amount of any free quota and the 
second identifies when it expires.  Usage of this quota is not to be 
reported - alternatively a new value of FREE could be added to 
Tariff-Change-Usage.

I'd appreciate comments from all interested parties to help improve this 
idea or to come up with a better idea.

"Mark Watson" <[email-masked]>
Sent by: [email-masked]
06/02/2004 15:00

        To:     "[email-masked]'" <[email-masked]>, "Christopher 
Richards" <[email-masked]>
        cc:     "[email-masked]'" <[email-masked]>, "[email-masked]'" 
<[email-masked]>, "[email-masked]'" 
<[email-masked]>
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

John, all,

A five-fold increase in rate is not so likely, I agree, but more likely is 
an increase from zero-rated to per-MB, which is worse! For example as a 
user moves from a period where MB/hours bundled with the subscription are 
valid into a period where they are not. You are forcing credit reservation 
and re-auths based on the per-MB price throughout the 'bundled' period - 
exactly when the user might be using the service most!
 
Dual-quotas (before & after) also have the property that some credit is 
always reserved for after the tariff change, but there are two important 
differences:
- this quantity can be chosen by the operator independent of the quota 
given for before the time change
- credit pooling will allow this reserved credit to be accessed before the 
time change
 
I also don't see much difference in the workload at the OCS - it has to 
calculate the rates before and after the tariff change in all cases (to 
see which is higher in the single quota case) and that is most of the work 
- actually calculating the size of the quota is just a multiplication 
operation.
 
In practice the 'after' quota might be fairly small - it's purpose being 
largely to spread re-auths over some period (e.g. 30 mins) after the 
actual tariff change. This also would avoid some of the problems raised 
below.
 
Regards,
 
Mark
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 03 February 2004 09:51
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked]'; 
[email-masked]'

Hi Chris, 

Regards, 

John. 

Hi John, 

Old mechanism: 

  
  
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 1:08 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Chris, 

Regards, 

John 

Hi John, 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 11:24 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]' 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 10:50 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 
   [CR] That's OK for voice traffic. I guess we need the 

Thank you 
Marco 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards 
Sent: 02 February, 2004 18:07 
To: 'Leena Mattila (TU/LMF)' 
Cc: [email-masked]'; [email-masked]'; Loughney John 
(Nokia-NRC/Helsinki) 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked] 
Sent: 30. tammikuuta 2004 19:08 
To: Christopher Richards 
Cc: [email-masked]'; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 
Hi Chris, 

 

Best Regards, 
Chris. 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 30, 2004 10:18 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]'; [email-masked] 
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism. 
Hi Chris, 

 

TO: 

UNIT_INDETERMINATE                                         2 

 
- end of changes 
Best Regards, 
Chris Richards.

---

From: <[email-masked]>
Date: Mon, 9 Feb 2004 13:47:55 +0200

Hi Mark, John

Mark Watson wrote:

>Also, we have not thought before about the interaction of tariff time changes with credit pooling - dual quotas interact well with 
>credit sharing because the multipliers allow the 'after tariff change' quota to be shared with the 'before tariff change one' - this 
>is the only mechanism which eliminates the over-reservation effect and so is the best possible from the point of view of 
>reducing early re-authorisations.

Yes Mark, I guess credit pooling may eliminate the over-reservation effect but I think we cannot force a simple client to support credit pooling because it supports the tariff time changes, I think the two mechanisms should not be coupled by any means. However, the tariff time change mechanism should work same way also in the event that credit pooling (or in other words independent credit control of multiple services in a DCC (sub-)session)  is supported.

>Having said that, I appreciate the need to keep things simple for clients which don't support pooling etc.

This is exactly the point. Building on the John's inputs one possible solution that I guess meet your requirements and doesn't adversely impact everybody else could be to make the tariff change AVP a grouped  AVP as follow:

        Tariff-Change-Info :: < AVP Header: TBD >
                                    { Tariff-Time-Change }
                                    [ Unlimited-Use-Indication ]

The presence of the Unlimited-Use-Indication AVP would mean that the granted-units MUST be consumed only after the tariff change, before tariff change the end-user have rights to unlimited use of resources (i.e. zero-rated). However, the DCC client 
MUST meter the units used before the tariff change and report those units to the server associated to the Tariff-Change-Usage with value UNIT_BEFORE_TARIFF_CHANGE as usual (of course also the units used after tariff change are reported). This way there is only a single small credit reservation to cover the "per MB" case, the main purpose being to spread the credit re-authorization messages across some time period.

There is always the drawback that a small amount of credit need to be allocated even though the is no certainty that the end-user will consume after tariff change, but I guess this cannot be avoided whatever mechanism we select.

Do you think would be useful to indicate also the other case, moving from per MB to zero rate?
In this case the Unlimited-Use-Indication would have two values to indicate whether the unlimited use applies before or after tariff change. When after tariff change applies, the client MUST stop using the granted units but MUST continue to meter the traffic.
Credit re-authorization will occur upon Validity-Time expires and the DCC client MUST report the units used after the tariff change associated to the Tariff-Change-Usage with value UNIT_AFTER_TARIFF_CHANGE as usual  (of course also the units used before tariff change are reported).

This way there would be one single mechanism and we could optimally support the extreme case of moves from zero-rate to per MB cost with the single quota. What do you think?

Regards
Marco

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 9 Feb 2004 12:24:04 -0000

Hi Marco.

Completely unlimited usage is a rather rare tariff. I was thinking more of
the case where a certain volume is bundled with the users subscription - so
there is still a quota of X MB, but this does not require any reservation to
be made from the users account (they've already paid as part of their
monthly fee).

I wasn't suggesting that we should link the tariff change and credit pooling
mechansism, but just pointing out that with a dual quota approach then it is
at least *possible* (but not mandatory) to develop a system which is optimal
in terms of avoiding over-reservations and consequent additional
re-authorisations. With a single quota approach this is not possible.

I'm afraid I can't think of an easy way of adding a dual quota approach as
an optional extension above the existing single quota approach. I think we
need to choose one or the other based on which is technically better.

I am not sure that handling separate 'before' and 'after' quotas is any more
complex for a 'simple client' than the single quota mechanism - both keep
separate before/after counts, single quota compares before+after with quota
value, dual quota compares before with before-quota and after with
after-auota - do you really think it is more complex ?

Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 09 February 2004 11:48
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]
Cc: [email-masked]; Richards, Christopher [RICH2:2Q40:EXCH];
[email-masked]

Hi Mark, John

Mark Watson wrote:

>Also, we have not thought before about the interaction of tariff time 
>changes with credit pooling - dual quotas interact well with
>credit sharing because the multipliers allow the 'after tariff change'
quota to be shared with the 'before tariff change one' - this 
>is the only mechanism which eliminates the over-reservation effect and so
is the best possible from the point of view of 
>reducing early re-authorisations.

Yes Mark, I guess credit pooling may eliminate the over-reservation effect
but I think we cannot force a simple client to support credit pooling
because it supports the tariff time changes, I think the two mechanisms
should not be coupled by any means. However, the tariff time change
mechanism should work same way also in the event that credit pooling (or in
other words independent credit control of multiple services in a DCC
(sub-)session)  is supported.

>clients which don't support pooling etc.

This is exactly the point. Building on the John's inputs one possible
solution that I guess meet your requirements and doesn't adversely impact
everybody else could be to make the tariff change AVP a grouped  AVP as
follow:

The presence of the Unlimited-Use-Indication AVP would mean that the
granted-units MUST be consumed only after the tariff change, before tariff
change the end-user have rights to unlimited use of resources (i.e.
zero-rated). However, the DCC client 
MUST meter the units used before the tariff change and report those units to
the server associated to the Tariff-Change-Usage with value
UNIT_BEFORE_TARIFF_CHANGE as usual (of course also the units used after
tariff change are reported). This way there is only a single small credit
reservation to cover the "per MB" case, the main purpose being to spread the
credit re-authorization messages across some time period.

There is always the drawback that a small amount of credit need to be
allocated even though the is no certainty that the end-user will consume
after tariff change, but I guess this cannot be avoided whatever mechanism
we select.

Do you think would be useful to indicate also the other case, moving from
per MB to zero rate? In this case the Unlimited-Use-Indication would have
two values to indicate whether the unlimited use applies before or after
tariff change. When after tariff change applies, the client MUST stop using
the granted units but MUST continue to meter the traffic. Credit
re-authorization will occur upon Validity-Time expires and the DCC client
MUST report the units used after the tariff change associated to the
Tariff-Change-Usage with value UNIT_AFTER_TARIFF_CHANGE as usual  (of course
also the units used before tariff change are reported).

This way there would be one single mechanism and we could optimally support
the extreme case of moves from zero-rate to per MB cost with the single
quota. What do you think?

Regards
Marco

---

From: <[email-masked]>
Date: Mon, 9 Feb 2004 15:04:32 +0200

Hi Mark,
 
Mark Watson wrote:
 
>Completely unlimited usage is a rather rare tariff. I was thinking more of the case where a certain volume is bundled with the users 
>subscription - so there is still a quota of X MB, but this does not require any reservation to be made from the users account (they've 
>already paid as part of their monthly fee).
 
If  you are thinking of a case where a user paid X MB as part of the monthly fee I would expect that these are always X MB regardless the applicable tariff at a given time of the day, no? 
Because these X MB are paid as part of the monthly fee the server would grant a quota of X MB, when these units have been consumed by the end-user the client report back, those are not affected by tariff changes. Or do I have totally missunderstood  your case?
 
>I'm afraid I can't think of an easy way of adding a dual quota approach as an optional extension above the existing single quota 
>approach. I think we need to choose one or the other based on which is technically better.
 
I have the same feeling, but I think also backword compatibility with existing system need to be considered when making the choice see next point. 
 
> I am not sure that handling separate 'before' and 'after' quotas is any more complex for a 'simple client' than the single quota 
>mechanism - both keep separate before/after counts, single quota compares before+after with quota value, dual quota compares 
>before with before-quota and after with after-auota - do you really think it is more complex ?
 
Well, I'm not thinking it is far more complex. However, I'm somewhat in agreement with John's arguments.
With the dual quota there is also another small problem that is backword compatibility with existing systems (not sure we already consider this aspect and I apologize if already did). Unfortunately we have existing deployments in which the DCC may have to fit
e.g. existing 2.5G and 3G networks. The DCC server may need to connect to existing IN systems where the tariff change is implemented according the current draft 02. The unfortunate DCC server that receive one quota associated to the Tariff switch cannot convert this into two quotas, or if it does it will not get the wanted result. I'm not sure we can design the solution as if such systems wouldn't exist.
 
Regards
Marco

-----Original Message-----
From: ext Mark Watson [mailto:[email-masked]]
Sent: 09 February, 2004 14:24
To: Stura Marco (Nokia-NET/Helsinki); [email-masked]'
Cc: [email-masked]'; Christopher Richards; Loughney John (Nokia-NRC/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Marco. 

Completely unlimited usage is a rather rare tariff. I was thinking more of the case where a certain volume is bundled with the users subscription - so there is still a quota of X MB, but this does not require any reservation to be made from the users account (they've already paid as part of their monthly fee).

I wasn't suggesting that we should link the tariff change and credit pooling mechansism, but just pointing out that with a dual quota approach then it is at least *possible* (but not mandatory) to develop a system which is optimal in terms of avoiding over-reservations and consequent additional re-authorisations. With a single quota approach this is not possible.

I'm afraid I can't think of an easy way of adding a dual quota approach as an optional extension above the existing single quota approach. I think we need to choose one or the other based on which is technically better.

I am not sure that handling separate 'before' and 'after' quotas is any more complex for a 'simple client' than the single quota mechanism - both keep separate before/after counts, single quota compares before+after with quota value, dual quota compares before with before-quota and after with after-auota - do you really think it is more complex ?

Regards...Mark 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: 09 February 2004 11:48 
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked] 
Cc: [email-masked]; Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

Hi Mark, John 

Do you think would be useful to indicate also the other case, moving from per MB to zero rate? In this case the Unlimited-Use-Indication would have two values to indicate whether the unlimited use applies before or after tariff change. When after tariff change applies, the client MUST stop using the granted units but MUST continue to meter the traffic. Credit re-authorization will occur upon Validity-Time expires and the DCC client MUST report the units used after the tariff change associated to the Tariff-Change-Usage with value UNIT_AFTER_TARIFF_CHANGE as usual  (of course also the units used before tariff change are reported).

Regards 
Marco

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 9 Feb 2004 14:48:38 -0000

Hi Marco,
 
You can imagine a tarrif where X MB of *off-peak* traffic is bundled into
the monthly subscription. It's very common with voice tariffs to have X
minutes of off-peak calls. When peak hours start, then you switch to €/mb.
 
As for backwards compatibility, I think it's fine to consider backwards
compatibility with existing *standards*, but where there are existing
proprietary deployments then unless you can accomodate all of them I am not
sure it is a valid consideration for what to standardise. Is it a particular
standard you are looking for backwards compatibility with ?
 
If I receive a single quota from a legacy system I can easily split it into
two with some simple rules which will work reasonably well most of the time.
 
Conversely, if I receive a dual quota from a legacy system it is not
possible for me to combine it into a single one - just adding them doesn't
work.

So, it would seem that if you want to accomodate both kinds of legacy system
you should adopt the dual quota approach ;-)
 
Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 09 February 2004 13:05
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]
Cc: [email-masked]; Richards, Christopher [RICH2:2Q40:EXCH];
[email-masked]

Hi Mark,

>Completely unlimited usage is a rather rare tariff. I was thinking more of
the case where a certain volume is bundled with the users 
>subscription - so there is still a quota of X MB, but this does not require
any reservation to be made from the users account (they've 
>already paid as part of their monthly fee).
 
If  you are thinking of a case where a user paid X MB as part of the monthly
fee I would expect that these are always X MB regardless the applicable
tariff at a given time of the day, no? 
Because these X MB are paid as part of the monthly fee the server would
grant a quota of X MB, when these units have been consumed by the end-user
the client report back, those are not affected by tariff changes. Or do I
have totally missunderstood  your case?
 
>I'm afraid I can't think of an easy way of adding a dual quota approach as
an optional extension above the existing single quota 
>approach. I think we need to choose one or the other based on which is
technically better.
 
I have the same feeling, but I think also backword compatibility with
existing system need to be considered when making the choice see next point.

> I am not sure that handling separate 'before' and 'after' quotas is any
more complex for a 'simple client' than the single quota 
>mechanism - both keep separate before/after counts, single quota compares
before+after with quota value, dual quota compares 
>before with before-quota and after with after-auota - do you really think
it is more complex ?
 
Well, I'm not thinking it is far more complex. However, I'm somewhat in
agreement with John's arguments.
With the dual quota there is also another small problem that is backword
compatibility with existing systems (not sure we already consider this
aspect and I apologize if already did). Unfortunately we have existing
deployments in which the DCC may have to fit
e.g. existing 2.5G and 3G networks. The DCC server may need to connect to
existing IN systems where the tariff change is implemented according the
current draft 02. The unfortunate DCC server that receive one quota
associated to the Tariff switch cannot convert this into two quotas, or if
it does it will not get the wanted result. I'm not sure we can design the
solution as if such systems wouldn't exist.
 
Regards
Marco

-----Original Message-----
From: ext Mark Watson [mailto:[email-masked]]
Sent: 09 February, 2004 14:24
To: Stura Marco (Nokia-NET/Helsinki); [email-masked]'
Cc: [email-masked]'; Christopher Richards; Loughney John
(Nokia-NRC/Helsinki)

Hi Marco. 

Regards...Mark 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: 09 February 2004 11:48 
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked] 
Cc: [email-masked]; Richards, Christopher [RICH2:2Q40:EXCH];
[email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

Hi Mark, John 

Regards 
Marco

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Mon, 9 Feb 2004 16:01:00 +0100

Hi Mark,
 
Is it a particular standard you are looking for backwards compatibility with ?
For instance in case of 3GPP, the OCS (i.e. CC server) supports CAP v.3 towards SGSN and I think
that it is not good to force one server to support two different TSw mechanisms,
one mechanism for access node and another mechanism for gateway node. 
 
regards...........Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark Watson
Sent: 9. helmikuuta 2004 16:49
To: [email-masked]'; [email-masked]'
Cc: [email-masked]'; Christopher Richards; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Marco,
 
You can imagine a tarrif where X MB of *off-peak* traffic is bundled into the monthly subscription. It's very common with voice tariffs to have X minutes of off-peak calls. When peak hours start, then you switch to €/mb.
 
As for backwards compatibility, I think it's fine to consider backwards compatibility with existing *standards*, but where there are existing proprietary deployments then unless you can accomodate all of them I am not sure it is a valid consideration for what to standardise. Is it a particular standard you are looking for backwards compatibility with ?
 
If I receive a single quota from a legacy system I can easily split it into two with some simple rules which will work reasonably well most of the time.
 
Conversely, if I receive a dual quota from a legacy system it is not possible for me to combine it into a single one - just adding them doesn't work.

So, it would seem that if you want to accomodate both kinds of legacy system you should adopt the dual quota approach ;-)
 
Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 09 February 2004 13:05
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]
Cc: [email-masked]; Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Mark,

 

 

Regards
Marco

-----Original Message-----
From: ext Mark Watson [mailto:[email-masked]]
Sent: 09 February, 2004 14:24
To: Stura Marco (Nokia-NET/Helsinki); [email-masked]'
Cc: [email-masked]'; Christopher Richards; Loughney John (Nokia-NRC/Helsinki)
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Marco. 

Regards...Mark 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: 09 February 2004 11:48 
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked] 
Cc: [email-masked]; Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked] 
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism 

Hi Mark, John 

Regards 
Marco

---

From: <[email-masked]>
Date: Mon, 9 Feb 2004 17:32:49 +0200

Hi Mark,

>You can imagine a tarrif where X MB of *off-peak* traffic is bundled into the monthly subscription. It's very common with voice 
>tariffs to have X minutes of off-peak calls. When peak hours start, then you switch to €/mb.

OK, now your case is more clear and yes I misunderstood it. But I still think that a good co-ordination with the validity time can solve this, of course not the way you want and still with over-reservation effect. However, it seems that all those involved in this discussion have agreed that your proposal may optimize this extreme cases but will make the general case worse.

The only benefit I can see with the dual quota mechanism is when it is used in conjunction with credit pooling. Is that what you want to achieve? I mean you want to be able to use the dual quota mechanism when credit pooling feature is supported?

>As for backwards compatibility, I think it's fine to consider backwards compatibility with existing *standards*, but where there 
>are existing proprietary deployments then unless you can accomodate all of them I am not sure it is a valid consideration for 
>what to standardise. Is it a particular standard you are looking for backwards compatibility with ?

I thought it was clear from my answer, I was talking about IN systems that are not proprietary deployments. I never mentioned about proprietary deployments Mark.

>If I receive a single quota from a legacy system I can easily split it into two with some simple rules which will work reasonably 

Yes, but if you receive a single quota associated with the tariff switch (i.e. according to the CAMEL mechanism) from an IN legacy system the credit have been reserved according to the worst case. So, you can split the quota according to whatever rule but you will defeat your objective of avoiding over-reservation. Not only, but you will exacerbate the problem of early credit re-authorization.

>Conversely, if I receive a dual quota from a legacy system it is not possible for me to combine it into a single one - just adding 

What standard are you now looking for?

Regards
Marco

---

From: [email-masked]
Date: Mon, 9 Feb 2004 15:40:32 +0000

Hi Marco,

I've also come to the opinion that the best solution to this particular 
case is to make clever use of validity time.

Regards,

John.

<[email-masked]>
09/02/2004 15:32

        To:     <[email-masked]>, <[email-masked]>
        cc:     <[email-masked]>, <[email-masked]>, <[email-masked]>
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism

Hi Mark,

>tariffs to have X minutes of off-peak calls. When peak hours start, then you switch to €/mb.

OK, now your case is more clear and yes I misunderstood it. But I still 
think that a good co-ordination with the validity time can solve this, of course not the way you want and still with over-reservation effect. 
However, it seems that all those involved in this discussion have agreed 
that your proposal may optimize this extreme cases but will make the 
general case worse.

The only benefit I can see with the dual quota mechanism is when it is 
used in conjunction with credit pooling. Is that what you want to achieve? I mean you want to be able to use the dual quota mechanism when credit 
pooling feature is supported?

>As for backwards compatibility, I think it's fine to consider backwards 
compatibility with existing *standards*, but where there 
>are existing proprietary deployments then unless you can accomodate all 
of them I am not sure it is a valid consideration for 
>what to standardise. Is it a particular standard you are looking for 
backwards compatibility with ?

I thought it was clear from my answer, I was talking about IN systems that are not proprietary deployments. I never mentioned about proprietary 
deployments Mark.

>If I receive a single quota from a legacy system I can easily split it 
into two with some simple rules which will work reasonably 
>well most of the time.

Yes, but if you receive a single quota associated with the tariff switch 
(i.e. according to the CAMEL mechanism) from an IN legacy system the 
credit have been reserved according to the worst case. So, you can split 
the quota according to whatever rule but you will defeat your objective of avoiding over-reservation. Not only, but you will exacerbate the problem of early credit re-authorization.

>Conversely, if I receive a dual quota from a legacy system it is not 
possible for me to combine it into a single one - just adding 
>them doesn't work.

Regards
Marco

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 9 Feb 2004 15:49:01 -0000

Hi Marco,

Ok, so we are talking about backwards compatibility with existing standards
- that's fine.

>The only benefit I can see with the dual quota mechanism is when it is used
in conjunction with credit pooling.

There is also a benefit without credit pooling which is that the server has
complete control over the size of the 'over-reservation' (and so on the
extent of the early re-authorisation effect). By contrast, with a single
quota the size of the over-reservation is dependent on the rate differential
and the size of the reservation itself and the amount the client actually
uses before the tariff change.

>I mean you want to be able to use the dual quota mechanism when credit

That seems to be the only way to avoid over-reservations, so I would like
this to be possible in the standard, but not mandatory.

>Yes, but if you receive a single quota associated with the tariff switch
(i.e. according to the CAMEL mechanism) from an
> IN legacy system the credit have been reserved according to the worst
case. So, you can split the quota according to 
> whatever rule but you will defeat your objective of avoiding
over-reservation. Not only, but you will exacerbate the problem 
> of early credit re-authorization.

The over-reservation exists anyway because of the single quota mechanism.
Its size depends on the three factors mentioned above. Splitting it does
indeed place a lower bound on the size of the over-reservation i.e. things
may be worse, but they will not be better. But I am comparing with the
converse case where it is just *not possible* to combine a dual quota into a
single one.

>What standard are you now looking for?

3GPP Release 5 IMS online charging, for example.

Regards,

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 09 February 2004 15:33
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]
Cc: [email-masked]; Richards, Christopher [RICH2:2Q40:EXCH];
[email-masked]

Hi Mark,

>You can imagine a tarrif where X MB of *off-peak* traffic is bundled 
>into the monthly subscription. It's very common with voice

OK, now your case is more clear and yes I misunderstood it. But I still
think that a good co-ordination with the validity time can solve this, of
course not the way you want and still with over-reservation effect. However,
it seems that all those involved in this discussion have agreed that your
proposal may optimize this extreme cases but will make the general case
worse.

The only benefit I can see with the dual quota mechanism is when it is used
in conjunction with credit pooling. Is that what you want to achieve? I mean
you want to be able to use the dual quota mechanism when credit pooling
feature is supported?

>are existing proprietary deployments then unless you can accomodate all of
them I am not sure it is a valid consideration for 
>what to standardise. Is it a particular standard you are looking for
backwards compatibility with ?

I thought it was clear from my answer, I was talking about IN systems that
are not proprietary deployments. I never mentioned about proprietary
deployments Mark.

Yes, but if you receive a single quota associated with the tariff switch
(i.e. according to the CAMEL mechanism) from an IN legacy system the credit
have been reserved according to the worst case. So, you can split the quota
according to whatever rule but you will defeat your objective of avoiding
over-reservation. Not only, but you will exacerbate the problem of early
credit re-authorization.

Regards
Marco

---

From: <[email-masked]>
Date: Mon, 9 Feb 2004 20:15:21 +0200

Hi Mark, John, all
 
John P. wrote:
 
> I've also come to the opinion that the best solution to this particular case is to make clever use of validity time. 
 
I agree, the mechanism for the basic DCC functionality of single service (or single quota support) should then be kept
as it is.  
 
Mark Watson wrote:
>>I mean you want to be able to use the dual quota mechanism when credit pooling feature is supported? 

>That seems to be the only way to avoid over-reservations, so I would like this to be possible in the standard, but not mandatory.

Fine. So, why not to define the dual quota in the context of the independent credit control for multiple services feature? I mean, client/server that implement support for the independent credit control for multiple services should support the dual quota mechanism. In other words, the dual quota for tariff changes would be a  functionality within the independent credit control of multiple services feature, the server may use it if so wanted. 

So, the only mechanism to support with the basic functionality in case of single service (or single quota) support is the one described in draft 02 i.e. single quota. Where independent credit control of multiple services feature is supported, then the dual quota should be supported as well because it can leverage the credit pooling capabilities to avoid over-reservation etc. (i.e. let use the mechanism where it makes more sense to use it). The tariff switch mechanism is of course not used for time based services in any case as already agreed.

Basically, what I propose is to enhance the structure of the Multiple-Services-Credit-Control AVP of the updated proposal to issue 16 (the one we are working offline as announced, I apologize for those who didn't see the update yet) with the Tariff-Change-Usage AVP that would be used only in CCA messages and indicates whether the quota is for consumption before tariff change or after tariff change. The presence of the Tariff-Change-Usage implies the presence of the Tariff-Time-Change AVP in the G-S-U AVP.  The structure would looks 

 Multiple-Services-Credit-Control ::= < AVP Header: tbd > 

                                         [ Granted-Service-Unit ]   

                                         [ Requested-Service-Units ] 

                                        *[ Used-Service-Units ] 

                                        *[ Service-Identifier ] 

                                         [ Rating-Group ] 

                                         [ Tariff-Change-Usage ]

                                        *[ G-S-U-Pool-Reference ] 

                                         [ Validity-Time ] 

                                         [ Result-Code ] 

                               [ Final-Unit-Indication ] 

This is my proposa, let see what other people think about the proposal.  If there is agreement,  I guess we could include this in our update of  the issue 16 that I hope will be able to publish  in the few coming days.

>3GPP Release 5 IMS online charging, for example.

That is defined for IMS that is actually doing, and can only do, time based credit control and it only requires the basic DCC application functionalities for the single service/quota. However, we already agreed that there is no need for any tariff switch mechanism for the time based services since the server is in full power to control the tariff changes, in fact there are pending CRs for the removal of the mechanism. So, I feel the alignment should happen this way, not the other way round.
 
Regards
Marco

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 9 Feb 2004 20:07:08 -0000

Hi Marco, all,
 
This seems to work - 2 quotas is still multiple quotas so it makes sense
that this is only supported where multiple quotas are supported.
 
Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 09 February 2004 18:15
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]
Cc: [email-masked]; Richards, Christopher [RICH2:2Q40:EXCH];
[email-masked]

Hi Mark, John, all

 
I agree, the mechanism for the basic DCC functionality of single service (or
single quota support) should then be kept
as it is.  

Fine. So, why not to define the dual quota in the context of the independent
credit control for multiple services feature? I mean, client/server that
implement support for the independent credit control for multiple services
should support the dual quota mechanism. In other words, the dual quota for
tariff changes would be a  functionality within the independent credit
control of multiple services feature, the server may use it if so wanted. 

So, the only mechanism to support with the basic functionality in case of
single service (or single quota) support is the one described in draft 02
i.e. single quota. Where independent credit control of multiple services
feature is supported, then the dual quota should be supported as well
because it can leverage the credit pooling capabilities to avoid
over-reservation etc. (i.e. let use the mechanism where it makes more sense
to use it). The tariff switch mechanism is of course not used for time based
services in any case as already agreed.

Basically, what I propose is to enhance the structure of the
Multiple-Services-Credit-Control AVP of the updated proposal to issue 16
(the one we are working offline as announced, I apologize for those who
didn't see the update yet) with the Tariff-Change-Usage AVP that would be
used only in CCA messages and indicates whether the quota is for consumption
before tariff change or after tariff change. The presence of the
Tariff-Change-Usage implies the presence of the Tariff-Time-Change AVP in
the G-S-U AVP.  The structure would looks 

                                         [ Granted-Service-Unit ]   

                                        *[ Used-Service-Units ] 

                                        *[ Service-Identifier ] 

                                         [ Rating-Group ] 

                                         [ Tariff-Change-Usage ]

                                         [ Validity-Time ] 

                                         [ Result-Code ] 

This is my proposa, let see what other people think about the proposal.  If
there is agreement,  I guess we could include this in our update of  the
issue 16 that I hope will be able to publish  in the few coming days.

>3GPP Release 5 IMS online charging, for example.

That is defined for IMS that is actually doing, and can only do, time based
credit control and it only requires the basic DCC application
functionalities for the single service/quota. However, we already agreed
that there is no need for any tariff switch mechanism for the time based
services since the server is in full power to control the tariff changes, in
fact there are pending CRs for the removal of the mechanism. So, I feel the
alignment should happen this way, not the other way round.
 
Regards
Marco