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 17:34:20 +0300

Diameter is running on TCP or SCTP (chapter 2.1), so there is TCP or
SCTP reliable transport connection between client and server.

And the case you describe is very very very improbable to happen.
The client sends ACR (interim record) and goes to PendingI state.
Now the user terminate the service then the client store the stop
record (it does not send the stop record!)and stays in PendingI
state untill it receives the ACA (interim record).
When the ACA(interim record) has been successfully received the
client goes to Open state then the client finally sends the
ACA (stop record).
So, ACA (stop record) is never sent by the client before the
answer to the ACR (interim record) has not been received by the
server, but this means that the server already received the
request.
 
I really don't see any problem, or better, the problem does not
exist.

BR
Marco

> -----Original Message-----
> From: ext Johan Johansson [mailto:[email-masked]]
> Sent: 04. April 2002 16:38
> To: [email-masked]
> Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State
> Machines into Client vs. Server
> 
> 
> You have no transport layer connection between the client and the
> accounting server. As for software bugs: assuming that they 
> don't happen
> at a machine you don't control over is a good way to find trouble. You
> also forgot the case where a stop record due to reordering 
> along the way
> arrives before and interim record. When the interim record arrives you
> will create a new session that will never receive a stop record.
> 
> j
> 
> [email-masked] wrote:
> 
>  >what are the cases when stop record is not received?
>  >I would say:
>  >
>  >1- network failure
>  >2- Client error (e.g. spontaneous restart of the client,
>  >Diameter process failure...)
>  >
>  >A network failure should be detected at the transport layer.
>  >In general the accounting session will be closed if the 
> transport layer
>  >detect a connection failure (it is an implementation issue 
> how transport
>  >layer will instruct the Diameter layer).
>  >
>  >In case of client error sooner or later the transport layer 
> connection
>  >will be closed and we go back to the previous case.
>  >
>  >If the message is lost due to temporary network overload/failure
>  >Diameter is running on reliable transport then the message will be
>  >re-transmitted at transport layer.
>  >
>  >In case of software bug in the client the problem is not in the
>  >server state model.
>  >
>  >Are these examples enough or you need more examples?
>  >
>  >BR
>  >Marco
>  >
>  >>-----Original Message-----
>  >>From: ext Johan Johansson [mailto:[email-masked]]
>  >>Sent: 04. April 2002 16:03
>  >>To: Stura Marco (NET/Helsinki)
>  >>Cc: [email-masked]; Lialiamou Elena (NET-IMN/Helsinki);
>  >>[email-masked]; [email-masked]
>  >>Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + 
> Split State
>  >>Machines into Client vs. Server
>  >>
>  >>
>  >>And what if no stop record is ever received? How does the 
> server know
>  >>that it can get rid of the session?
>  >>
>  >>j
>  >>
>  >>[email-masked] wrote:
>  >>
>  >>>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 16:53:54 +0200

>SCTP reliable transport connection between client and server.
No. There is one between each node in the network but rarely directly 
between the client and the server. This means that the server must be 
able to handle the case where no stop record is ever sent and therefore 
not received without involving transport layer events (which is why they 
are not in the state machine).

>server, but this means that the server already received the
So when you are sending accounting records on startup that have been 
saved in persistant storage as a part of fault recovery you replay the 
session's lifetime in fast-forward? If you do that, wouldn't you need to 
store the client side session state along with every accounting record?

j

---

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

> SCTP reliable transport connection between client and server.

Only if the client and the server are adjacent to each other.
If there's a proxy in between there's no way to know for sure what's
happeningv at the other end.

Jari