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 12:45:24 +0300

Hi,

I may have missed some parts of the discussion so forgive me if my question is irrelevant..

If the server has only idle state, what will be the actions in cases where ACA has interim-interval and for some reason client ignores it (timer failure)? It crossed my mind that server might have timer of it's own and when it has expired and no ACR INTERIM_RECORD has been received, some actions will be taken. Or...?

br,
JPK 

-----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 12:05:50 +0200

Well, I'm not sure there are that many possible actions you *can* take. 
Any such action would have to take place through the authorization 
session which is the only one with the power to initiate a session 
termination. The communication between the accounting session and the 
authorization session, which may not reside on the same machine, is not 
specified by the protocol and probably wisely so.

j

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Apr 2002 13:14:16 +0300

> I may have missed some parts of the discussion so forgive me if my question is irrelevant..

Not at all. Your comments are very relevant.

> If the server has only idle state, what will be the actions in cases where ACA has interim-interval and for some reason client ignores it (timer failure)? It crossed my mind that server might have…

I sympathize with the desire to do that but the question is,
what *can* we do?

Answer A: Nothing. (current state machine)

Answer B: Close the session. But what if there was a network
partition and the records come in tomorrow when it is fixed?

Jari