🚀 go-pugleaf

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