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

From: <[email-masked]>
Date: Wed, 3 Apr 2002 16:47:31 +0300

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

Regards
Elena

> -----Original Message-----
> From: ext Jari Arkko [mailto:[email-masked]]
> Sent: 03. April 2002 15:57
> To: Lialiamou Elena (NET-IMN/Helsinki)
> Cc: Loughney John (NRC/Helsinki); [email-masked]
> Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State
> Machines into Client vs. Server
> 
> 
> Thanks Elena for your comments. Some responses below:
> 
> > All the states proposed for Server Accounting are Idle 
> (check the diamstates.txt).How is that possible?
> > Shouldn't at least Open and Idle be required/ needed for 
> the server side ?
> 
> Well, the original splitted table sent by Pete did
> have Open and Idle. However, I wasn't sure if this
> added any useful value to the state machine. Are we
> supposed to reject an Interim record if we didn't
> receive a Start earlier? In some ways that would make
> sense, but on the other hand, I would think we would
> like to get even some records if for some reason the
> earlier records have been lost, e.g. due to network
> partiotion and lack of memory. Secondly, what if
> there is some reordering between accounting records
> under some strange network condition and the Start
> arrives later than the interim? We aren't supposed to
> be doing that on the client side, but again I wonder
> if we should really drop the records on the floor
> if we do receive them in the wrong order.
> 
> So, unless we are going to do something different
> in the Open/Idle states, we aren't going to need
> states.
> 
> > Also, in previous email with regard to the same topic
> > some additional state-event transitions in particular
> > Interim Record was presented which is not included in the 
> diamstates.txt .
> 
> I'm not sure what you are missing, can you clarify?
> The state machine does have Open-> PendingI and then
> 5 different actions on what to do there.
> 
> Jari
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Apr 2002 17:17:10 +0300

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

> 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)?

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

- 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*?

My opinion is that we should focus Diameter accounting on the data collection part, and
allow but not require keeping state. 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: Johan Johansson <[email-masked]>
Date: Wed, 03 Apr 2002 17:19:16 +0200

>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"
Yes. But everything that is needed to recreate that state is contained 
in the ACR that the server receives.

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

>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.
>
It matters when doing the billing.

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

j