Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 10 Jul 2004 09:25:41 -0400

Hi Marco,
 
The more I think about this issue the more I believe that it needs to be
addressed properly in the draft before it becomes a standard.
Let us assume that SLA covers the Tariff change functionality.
 
Since Tariff change is not a mandatory functionality on the DCC client, it
is quite very possible that the support of this functionality is being
CONFIGURABLE on the access side. This means that there is a room for human
error of not enabling Tariff Change functionality while it is REQUIRED. In
this case, I believe a service provider will never be alerted to what
happens to their customers until issue is escalated and produced many
unsatisfied customers.
 
My other point is, that every protocol SHALL provide a reliable mechanism
for error handling which I believe DCC is lacking with respect to this
issue.
 
Now: I am not sure why it is so difficult to include a new error code to
resolve this issue and make this DCC protocol more robust.?
I am sure it is not the lack of space for a new error code.

Regards, 
Ahmad 

-----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH] 
Sent: Wednesday, June 09, 2004 7:58 AM
To: [email-masked]'; Maddireddi, Satheesh [RICH2:2Q40:EXCH];
[email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi Marco,
comments inline..

Regards, 
Ahmad 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 09, 2004 7:43 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; Maddireddi, Satheesh
[RICH2:2Q40:EXCH]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi Ahmad,
 
it seems you didn't get my point.  What is indicated in the draft is that
SLA is expected to cover bla bla bla...., and this should be enough
other options are not needed.
 
Finally, the only changes allowed at this point are major bug fixing and
your proposal doesn't fall within this category. So, new termination
causes will not be added in this DCC version unless explicitely requested by
IESG. 
 
[A.M.]
I still believe a new cause value is a much better choice and needed. 
But, if it is too late at this point, let us hope that IESG request that
otherwise, we can forget about it.
 
Regards
Marco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
Ahmad Muhanna
Sent: 09 June, 2004 15:10
To: Stura Marco (Nokia-NET/Helsinki); Satheesh Maddireddi;
[email-masked]
Cc: [email-masked]; [email-masked]; Koskinen
Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki);
[email-masked]; [email-masked]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
Please see comments inline.

Regards, 
Ahmad 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 09, 2004 5:26 AM
To: Maddireddi, Satheesh [RICH2:2Q40:EXCH]; Muhanna, Ahmad
[RICH2:2Q30:EXCH]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
 
I think what really happen is that the user signs a contract with a service
provider, often referred as subscription. 
The contract typically states the pricing structure for the services,
including tariff time changes, when and where 
certain conditions are  applicable etc. Therefore, whether tariff time
changes are applicable when roaming to a 
given visited network, should be known as well since this may have legal
implications (i.e. you cannot sell to
a user that the access costs $1/MB from 6am to 6 pm and $0.5/MB from 6pm to
6 am if not sure that
tariff change is supported. Presumably you cannot sell that the effective
cost of the service has dependencies
on whether tariff change is supported in the visited network either. So, you
have to know it beforehand.). Introducing
additional protocol functionalities such as new termination cause etc. won't
help in that respect, since in most
cases the server won't accept to change the billing model agreed beforehand
with the user, the service will most 
likely be denied in any case.
 
[A.M.]
I agree.
Please see comments below.
 
We have a paragraph in section 4.1 that is supposed to cover this
interoperability issues, basically the option 2
listed by Ahmad.
 
Clip

   It is reasonable to expect that there will exist a service level 
   agreement between providers of the credit control client and the 
   credit control server covering the charging, services offered, 
   roaming agreements, agreed rating input, etc. 
     
[A.M.]
I think this probably enough to cover the static configuration portion of
it.
 
"covering the charging" basically refers to the charging model, therefore
includes such things as the tariff changes and
charging type (e.g. volume, time etc.) too. We thought that it was better
choice to group all this interoperability stuff in 
one section rather than repeating the same text for all the optional
features along the document, there is nothing left to 
individual interpretation or assumptions as Ahmad appears to believe.
 
That said, the draft passed couple of WG last calls, the AD review and is
now in the IESG review. So, IESG officially frowns 
upon changes except in extreme cases (i.e. major bugs). What you are
pointing out, as discussed above, I don't believe 
is a bug at all and that is reasonable to expect SLA is mentioned in section
4.1. 
 
[A.M.]
Agreed.
I believe the cause value should be changed to a specific one and not so
generic. 
I do not think it is too late to propose a new cause value as "tariff change
not supported". 
It is more descriptive and much more helpful for collecting proper OM at
both ends; the server and client. 
 
Mark Grayson wrote
 
>well at least there seems to be some inconsistency with optional MSCC which
then has support explicitly indicated by the client.
 
The MSCC is a bit different case. Who decide at the origin to multiplex
services in the same credit control session is actually
the client, while the tariff-change is server driven. The reason of
indicating MSCC support in the initial CCR, is to indicate to
the server "I want to multiplex services that may be subject to different
cost in the same session". The server may reject the
request because it doesn't support the feature (Failed AVP included in the
response), in such a case the client still have the
option to open a credit control session for each of the requested services.
As discussed above this won't be effective in case
of tariff-changes, all would happen is that the server would reject the
request if the client indicates "tariff change not supported"
since you cannot change the beforehand agreed charging model with the user. 
 
[A.M.]
please see comments above. 
 
Regards
Marco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
Satheesh Maddireddi
Sent: 09 June, 2004 05:40
To: Ahmad Muhanna; Stura Marco (Nokia-NET/Helsinki);
[email-masked]
Cc: [email-masked]; [email-masked]; Koskinen
Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki);
[email-masked]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
 
I agree with Ahmad we should have a specific reason for the failing the MSCC
in case if the client doesn't support the Tariff-Time-Change AVP
as the the server will not be able to interpret the failure as it may be
because of  the GSU unit types OR the tariff change AVP will have to retry
at most 2 times to understand the meaning of failure reason. (Need a new
failure cause). Regarding mandating the Tariff-Time-Change AVP
server always has an option to include a mandatory AVP Validity-Time for the
client to trigger reauth as the server wants.
 
Regards,
Satheesh 

 -----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH] 
Sent: Tuesday, June 08, 2004 9:08 AM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
please see comments inline.

Regards, 
Ahmad 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, June 08, 2004 8:35 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
 
I think the Peter answer indicated that this is not a problem. 
 
[A.M.]
Apparently and based on my comment to Peter, I disagree. 
 
Indeed, who decide the billing model is the server in the home network and
not the client in the
visited network, this was already discussed in the mailing list a while ago.
If the server sent a tariff-time-change in the answer is because it requires
this model, perhaps 
it has also contractual implications with the user if the model is broken,
and therefore it is correct for 
the client to reject the answer if it doesn't support the tariff-time-change
mechanism.
 
It is up to the server to eventually track that the origin-host X rejected
an answer with Tariff-Time-Change AVP
and at the next attempt change the billing model if possible. However,
typically an agreement between
DCC-Client and server exist and the server can control whether to send the
tariff-time-change or not. 
 
[A.M.] 
I think we are drafting a standard that needs not to leave anything for
individual interpretation or assumptions. Also, to avoid any IOT problem, we
need to make this clear in the standard.
I see you just proposed a couple of options:
1. Some sort of dynamic configuration based on DCC Server tracking DCC
clients support for Tariff-Time-Change. 

The only problem I see here is how the server would know that the client
does not support Tariff-Time-Change while the cause value in the
Temination-Cause AVP is set to a generic one "DIAMETER_BAD_ANSWER"

2. Static configuration at the DCC Server based on "agreement between
DCC-Client and DCC Server"
 
I may also add another straight forward one, 
3. Mandate the support for the Tariff-Time-Change mechanism on the DCC
server and DCC Client.
 
Is there any other options that the group may think applicable to this
issue?
 
Ahmad
 
Marco

-----Original Message-----
From: ext Ahmad Muhanna [mailto:[email-masked]]
Sent: 08 June, 2004 15:51
To: 'Peter Zackrisson (KA/EAB)'; [email-masked]
Cc: [email-masked]'; [email-masked]'; Koskinen
Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); Loughney
John (Nokia-NRC/Helsinki); Ahmad Muhanna
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

So far the only comment received is from Peter. 
Does this mean that every one agrees that this is a problem that needs to be
fixed.
If so, what do you think the solution should be?

Regards, 
Ahmad 

-----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH] 
Sent: Friday, June 04, 2004 8:59 AM
To: 'Peter Zackrisson (KA/EAB)'; [email-masked]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Thanks Peter,
 
Is it fair to say that your argument is based on the assumption that all DCC
Servers are always aware of all DCC clients capabilities with respect to
Tariff-Time-Change mechanism support.
 
Thanks again.

Regards, 
Ahmad 

-----Original Message-----
From: Peter Zackrisson (KA/EAB) [mailto:[email-masked]] 
Sent: Friday, June 04, 2004 8:48 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; [email-masked]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

I think the DCC specification is correct regarding the tariff change
mechanism.
 
If a DCC client does not support the tariff change mechanism the DCC server
must use a charging model towards that client that is not based on time,
which means that Tariff-Time-Change is not to be sent.
This means that it is up to the DCC server to be able to control if
Tariff-Time-Change should be sent or not.
If you have a charging model saying that the price for e.g. volume will be
different between 8 and 18 o'clock the clients will have to support
tariff change mechanism.
It is a very bad idea if some clients are allowed to break the charging
model (instead the charging model should be changed).
 
/ Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Ahmad Muhanna
Sent: den 4 juni 2004 15:15
To: [email-masked]
Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF);
[email-masked]'; [email-masked]';
[email-masked]'
Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi all, 

According to the DCC draft under section 5.1, support of Tariff-Time-Change
is optional by the DCC client and Server. 

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

On the other hand and under the same section, it mandates the DCC client
which does not support this functionality to terminate the DCC session if it
receives a CCA with Tariff-Time-Change AVP included.

Under section 5.1, it reads: 
" 
   If a client does not support the tariff change mechanism, and it 
   receives a CCA message carrying the Tariff-Time-Change AVP, it MUST 
   terminate the credit control session, giving a reason of 
   DIAMETER_BAD_ANSWER in the Termination-Cause AVP. 
" 

The problem I see is the following: 
There is a very good possibility that a DCC server supports
Tariff-Time-Change and DCC Client does not. 
This may cause a denial of service for an end-user which home Diameter CC
server supports Tariff-Time-Change mechanism while it is at an access where
DCC client does not.

Am I making sense here? 
Your thoughts please. 

Thanks, 
Ahmad