Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server

From: <[email-masked]>
Date: Thu, 4 Apr 2002 10:41:26 +0300

Hi,

Some comments below.

Thanks very much for the discussion.

Regards
Elena

> > Hi,
> > 
> > With regard to the need of having accounting states or not:
> > 
> > 1. According to the definition of the Idle state means " 
> When a session is moved to the Idle state, any resources that 
> were allocated for the particular session must be released"
> 
> 
> This may not be the right text in the accounting side. I'll
> take care of rewording this.
> 
Elena: Ok.
> 
> > 2.It should be so that messages arrive in certain order ; 
> otherwise should be rejected or at least processed 
> differently.I think that an Interim should be rejected if a 
> Start was not received before.Otherwise what is the purpose 
> of the Start anyway if not matter in which order they arrive 
> the result is exactly the same? So, we would not need start, 
> interim or stop not even any order in which those should arrive.
> > 
> > So, since there is start , interim and stop and those are 
> linked to one accounting session there should be session 
> states which are based on receiving those requests and 
> sending corresponding responses. 
> > 
> > Otherwise, I cannot really understand the purpose of those 
> different messages if in the end of the day there is only one 
> state and always the same end result.
> 
> I believe there's a few different issues at play here:
> 
> - Billing vs. just collecting data. At which stage do we make 
> all the sanity checks and so on?

>    Is it the task of the data collector (diameter accounting) 
> or the billing process (some
>    rather company specific mechanism and policies)?

Elena. The purpose should be to make proper data collection part of the diameter accounting off-loading thus the actual billing process. Otherwise, if diameter accounting does not offer proper data collection, needed sanity checks etc then in terms of accounting protocol would  not be offering advantages over other accounting /collection mechanisms which do offer some of the above. Shouldn't the purpose of diameter accounting be to offer as reliable data collection as possible already within the protocol layer? Otherwise, relaying on the billing process is something that can be done without Diameter accounting.
> 
> - State of the accounting server vs. real-world effects. 
> Pretty much the same thing
>    as above. The state of the diameter accounting server 
> might not change due to a message
>    being received, but there might still be a real-world 
> event, such as my bank account
>    balance getting (even) smaller because I used a service 
> and the billing process used
>    an accounting record from the diameter accounting server 
> to bill me for it.

> Elena: That is correct. There should be the basic state maching "maintained" as part of the accounting session ensuring proper collection, sanity etc. At the same time real-world effects involve several systems and several events which should not affect the basic accounting session state.Basically, the way accounting data is processed, which accounts are affected with monetary /non monetary impacts or what other actions are triggered should not affect the basic state machine(?).

> - State vs. records. Accounting service must at least keep 
> records in some sort of
>    storage. Sometimes we may want to keep state as well, even 
> do very complicated things
>    like fraud detection. But do we need to keep state *always*?

Elena: I agree with you that we may not always want to keep state. But when we do not want to keep state then we can easily use a single message e.g. after the service delivery simply to transfere the generated "accounting data". I still do not see the point of having three different messages for a session which never has a state. How is the server supposed to process differently those three different messages if their order does not make any sense? 

> 
> My opinion is that we should focus Diameter accounting on the 
> data collection part, and
> allow but not require keeping state. 
Elena: That should be stated in the doc so that "simple accounting" does not require state but "state related" accounting does require or in some better way ?

Otherwise, I cannot really understand the purpose of those different messages if in the end of the day there is only one state and always the same end result.
The difference is the value of one avp that describes which "state" the 
accounting session is in.

Elena: Of course there is difference in the avp but if the server does not maintain any state what is the purpose of the state in which the accounting session is in? How can the server process differently the messages received ?

2.It should be so that messages arrive in certain order ; otherwise should be rejected or at least processed differently.
But it is not possible to guarantee the order in which they arrive even 
if there is an order in which they are sent, especially not when sending 
stale records as the result of failure recovery.

Elena: I agree that nothing can be guaranteed with regard to the order messages arrive.But  should the way the server process the messages be different if they arrive in the correct order or in the wrong order ? If messages get send in any order then Billing process will be quite overloaded just to "short out" dublicate , incorrect data just because the protocol layer does not provide with any proper collection mechanismetc. So, either there is correct order and any messages arriving out of the correct order is marked "differently" or else there is no need to define the correct order at all (?). There is one saying:  "Exceptions confirm the rule".

But please comment if 
> you feel differently. In any
> case I continue to be happy that Pete's split is revealing 
> these discussion items!
> 
> Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Apr 2002 12:20:42 +0300

> The purpose should be to make proper data collection part of the diameter
> accounting off-loading thus the actual billing process. Otherwise, if
> diameter accounting does not offer proper data collection, needed sanity
> checks etc then in terms of accounting protocol would  not be offering
> advantages over other accounting /collection mechanisms which do offer
> some of the above. Shouldn't the purpose of diameter accounting be to
> offer as reliable data collection as possible already within the
> protocol layer? Otherwise, relaying on the billing process is something
> that can be done without Diameter accounting.

Well, certain functions need to be performed between a service
and the bill from the service, but exactly where those happen
is a design issue. As far as other protocols possibly offering
some of these functions I can only repeat what I said earlier
about reordering, reboots etc. These don't appear to be issues
limited just to the Diameter protocol, they would apply to
other solutions as well. To me, the tradeoffs are pretty clearly
such that we should allow even reboot-damaged record streams
to come in. But others may disagree and apparently you do.
However, I'd like to point out that your product *can* ensure
ordering if it wants to - there may be service providers
that want to reduce the tasks of the billing post processing
phase at the expense of losing some records.

In conclusion, you get what you want and I also get what I want.
However, if you want Diameter to *require* these checks then
you'll get what you want but I can't get what I want. So...

> How is the server supposed to process differently those three
> different messages if their order does not make any sense? 

I get the feeling that we are entering a philosophical discussion.
What is state anyway? Is the AVP value Acct-Output-Octets = 12031231
in a record state or not? It is stored in a file or data base
in the Diameter accounting server, so it should be considered
state. Similarly for the Accounting-Record-Type AVP, right?
All of this information is available for either immediate or
later processing.

The only question is if we will decline receiving records in
order.

> That should be stated in the doc so that "simple accounting"
> does not require state but "state related" accounting
> does require or in some better way ?

Perhaps this is our way to a compromise. Why don't we state
the situation about the potential immediate use or just
storage of the records in the document. For instance:

"Note that the server side state machines requires the
reception of accounting records and does not place any
standards requirement on the processing of these records.
Implementations of Diameter MAY perform checking, ordering,
correlation, fraud detection, and other tasks based on these records.
Both base Diameter AVPs as well as application specific
AVPs MAY be inspected as a part of these tasks.
The tasks can happen either immediately after record
reception or in a post-processing phase. However, as these
tasks are typically application or even policy dependent,
they are not standardized by the Diameter specifications."

Jari

---

From: Pete McCann <[email-masked]>
Date: Thu, 4 Apr 2002 10:39:04 -0600 (CST)

Hi,

 > they are not standardized by the Diameter specifications."

I think this text is quite reasonable, and I would even support
removing the state machine entirely and replacing it with this text
and a bit of explanation.  The only reason my original proposal had an
"Open" state was because it was a cut-and-paste of what was already
there.  However, after reading the discussion on the issue, I don't
think we should place any requirements on the order in which
accounting records arrive at the accounting server, which is what a
state machine would essentially do.  State machines define sets of
acceptable event strings, and by definition other strings are not
acceptable.  I think the discussion has shown that there is no
reasonable way to react differently to an "unacceptable" string of
events because there may not be any connection to the authorization
state machine.  The server might throw away the entire string, but
personally I think it's better to keep it so you can try to figure out 
what happened later.

-Pete