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 15:58:22 +0300

Hi Jari,

I beleive it is not question of philosophical discussion at all, if we have an accounting
session the state machine must be open. Idle means that we don't have any ongoing 
accounting session. It is definitely question of convention, clarity and also
practicality.
I agree with your text, and this has to be written in the spec.:

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

And I'm fine with the original Pete proposal for the accounting session
state for the Server with minor addition, I still insist that the state
must be Open when an accounting session is ongoing:

                            SERVER, ACCOUNTING
       State     Event                          Action       New State 
 ----------------------------------------------------------------------

      Idle      Accounting start request        send          Open
                 received, and successfully     accounting
                 processed.                     start
                                                answer

      Idle      Accounting event request        send          Idle
                 received, and successfully     accounting
                 processed.                     event
                                                answer
	
	Idle      Accounting request received     send		  Idle
		    (Interim Record or Start req.)  answer
                no space left to store records  Result-code=
                                                out-of-space

	Idle	    Interim Record received     	send		  Open
		    and successfully processed      accounting
                                                answer 

	Open      Interim Record received         send          Open
                and successfully processed      accounting
                                                answer

      Open      Accounting stop request         send          Idle
                 received, and successfully     accounting
                 processed                      stop answer

	Open	    Accounting request received     send		  Idle
		    (Interim Record or Stop req.)   answer
                no space left to store records  Result-code=
                                                out-of-space

A little explanation of the addition I have done to the original Pete proposal.
When there is no space left to store the record and the accounting session is
Open the new state will be idle. If accounting request was "Interim", the client 
may not close the session when it receives the answer with Result-code=out-of-space
(depending on the realtime AVP and client's buffer status) thus the client
can still send subsequent interim record.
If the error condition is still active in the server when subsequent interim records 
are received the state will stay idle otherwise the session is open again.

In general the possibility to receive interim record in idle state is also useful
when the client need to send these records to an alternate peer (server) in case
of accounting server failure.

I hope everybody is happy with this simple state model that clearly show, without 
ambiguity, when the accounting session is open and when is not.   

BR
Marco

> -----Original Message-----
> From: ext Jari Arkko [mailto:[email-masked]]
> Sent: 04. April 2002 12:21
> To: Lialiamou Elena (NET-IMN/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State
> Machines into Client vs. Server
> 
> 
> 
> > 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: Johan Johansson <[email-masked]>
Date: Thu, 04 Apr 2002 15:03:11 +0200

And what if no stop record is ever received? How does the server know 
that it can get rid of the session?

j