Subject: Re: [AAA-WG]: Accounting questions

From: Jari Arkko <[email-masked]>
Date: Wed, 01 Aug 2001 16:12:10 +0300

Hi. This is a response to an old mail. (I don't
seem to find an answer from anybody yet from
archives. I apologize is this has already been
discussed at length...) Seems that some errors
still remain in the current draft on these issues.

The comments can be found near the end.

"Guillermo Guardia-Lozano (ECE)" wrote:

> After reading the base draft  I have several 
> question regarding "Accounting" and maybe
> somebody in the list can clarify them. First I
> have included the parts of the document that
> all together lead me to confusion and, at the end, my questions.
> Thanks in advance.
> 
> Chapter 10.0
> When a service only makes use of the Accounting portion of the
> Diameter protocol, even in combination with an application, the
> Session-Id is still used to identify user sessions. However, the
> session termination messages are not used, since a session is
> signaled as being terminated by issuing an accounting stop message.
> 
> Chapter 11.5
> A particular value of Accounting-Session-Id MUST appear only in one
> sequence of accounting records from a DIAMETER client, except for the
> purposes of retransmission. The one sequence that is sent MUST be
> either one record with Accounting-Record-Type AVP set to the value
> EVENT_RECORD, or several records starting with one having the value
> START_RECORD, followed by zero or more INTERIM_RECORD, and a single
> STOP_RECORD.
> 
> Chapter 11.6
> However, there are certain applications that require multiple
> accounting sub-sessions. Such applications would send messages with a
> constant Session-Id AVP, but a different Accounting-Session-Id AVP.
> 
> Chapter 13.3
> The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32
> and identifies this record within one session. As Session-Id AVPs are
> globally unique, the combination of Session-Id and Accounting-
> Record-Number AVPs is also globally unique, and can be used in
> matching accounting records with confirmations.  An easy way to
> produce unique numbers is to set the value to 0 for records of type
> EVENT_RECORD and START_RECORD, and set the value to 1 for the first
> INTERIM_RECORD, 2 for the second, and so on until the value for
> STOP_RECORD is one more than for the last INTERIM_RECORD.
> 
> Chapter 13.4
> The Accounting-Session-Id AVP (AVP Code 44) is of type UTF8String,
> following the format specified in section 10.7. The Accounting-
> Session-Id is not used by the Diameter protocol, since the Session-Id
> defined in [1] is used for both authentication/authorization and
> accounting purposes.
> 
> Q1-
> If the service only makes use of the Accounting portion, but besides,
> it requires multiple accounting sub-sessions ( constant Session-Id but
> a different Accounting-Session-Id ), how is this session signaled as
> being terminated ?

It seems that we can't do it in the current spec. Is this needed?
If you have some resources to release, you should propably be
using other Diameter portions as well. If you don't have resources
to release, you might just rely on the fact that since you didn't
receive an accounting information any more there are no further
sessions. The specific application that produces the sessions
and subsessions might also specify something about how to determine
the true end. Possibly separate termination cause values might
be used. In fact, the latter is perhaps what I would recommend.
If an application produces subsessions, it should have some
sort of an AVP that defines why the subsession ended, and that
could take on values such as

	1 - user moved from this base station to another
	2 - user terminated the whole call

Comments?

> Is still applicable the "Accounting Session State Machine" in chapter 10.2 ?
> 
> Q2-
> Are Accounting-Record-Numbers unique within the session ( Session-Id )
> or unique within the accounting sub-session (Accounting-Session-Id ) ?

The current text doesn't specify this clearly. I would propose that
the record numbers keep increasing, i.e. subsessions don't reuse record
numbers.

> Q3-
> In the message format of <Accounting-Request> and <Accounting-Answer>
> the Accounting-Session-Id AVP appears as mandatory, but the AVP description
> (chapter 13.4 ) says : "The Accounting-Session-Id is not used by the Diameter
>  protocol, since ...."
> Is it coherent ?

No! Section 9.8.4 states that Accounting-Session-Id is only used for
RADIUS compatibility. Section 9.6 reuses this also for sub-sessions.
Yet we mandate it in the acct-req and acct-ans commands. Furthermore,
we are skipping the Accounting-Multi-Session-Id from the ABNF.

Here's a suggested 'issue' submission for the above problems:

     Subsession accounting unclarities
     Submitter name: Guillermo Guardia-Lozano / Jari Arkko
     Submitter email address: [email-masked] 
     Date first submitted: July 6, 2001 
     Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-07/msg00010.html 
     Document: base
     Comment type: T 
     Priority: 1 
     Section: 9 
     Rationale/Explanation of issue: 

       1) Unclear about when the whole session ends for an application
          that uses only Diameter accounting, and has subsessions
       2) Unclear about when record numbers reset for subsessions
       3) Unclear about Accounting-Session-Id and Accounting-Multi-Session-Id
          mandatory/optional status in the ABNF

     Requested change: 

       1) Add the following text after the second paragraph of
          9.6: "All applications that use the subsession accounting
          in DIAMETER MUST specify how the accounting server knows
          when the whole session has ended. Typically, this can take
          place through the reception of a special value in an AVP
          that describes the termination cause of the subsession."
       2) Add the following text to the end of 9.8.3: "In case the
          session consists of several subsessions, the values is not
          reset for new subsessions."
       3) Make Accounting-Session-Id optional in the ABNF, add
          Accounting-Multi-Session-Id to the ABNF, and mention in
          9.8.4 the use of Accounting-Session-Id also for subsessions.

/Jari

---

From: "Martin Julien (ECE)" <[email-masked]>
Date: Fri, 3 Aug 2001 15:52:22 +0200

See comments.

Martin

> 	2 - user terminated the whole call

Each accounting message must contain a session-id.
Furthermore, it may contain an accounting-session-id,
which is used to identify subsessions within that
accounting session. Each subsession MUST be 
considered independent, which means that they each
have a termination condition, which is a STOP message
for each subsession. That means that each accounting 
subsession should remain active until it receives a 
STOP message. That's the normal case.

So, the following text should be added:

"Each accounting message must contain a session-id,
which basically identifies an accounting session
on the accounting server. Furthermore, it may 
contain an accounting-session-id, which would be 
used to identify a subsession within that accounting 
session. Each subsession MUST be considered 
independent of each other, within the same session-id.

An accounting message that would define only a 
session-id, without an Accounting-session-id AVP,
MUST be considered by the accounting server as being
an accounting-session-id of 0.

All applications that use the accounting subsessions 
in Diameter MUST communicate their termination conditions 
to the accounting server through the means of an 
accounting message, indicating either an EVENT_RECORD 
or a STOP_RECORD in the Accounting-Record-Type AVP."

The question that Guillermo
had was more related to the fact that once an
Accounting session is started, it seems impossible
to close the accounting session unless we receive an 
accounting stop, at least according to the Accounting 
session state-machine (section 8.2). 
What should we count on for closing the accounting 
session, in fact an accounting subsession, in the case 
that we never receive any more messages, and obviously
not a STOP?

> the record numbers keep increasing, i.e. subsessions don't 

I would appreciate if you could make very clear in 
the draft, that a client MUST send accounting messages
using an increasing Record-number. It must be
stated in the draft, that record-numbers
of subsequent accounting messages must be incremental.

That means that when a client sends an accounting
message to an accounting server, it MUST keep on 
incrementing the record number for each accounting
message sent for a particular accounting session.
That implies that an accounting server MUST consider
the accounting message for a particular accounting 
subsession as containing the latest valid accounting 
data, based on the highest Record-number received. 

For example, let's say an accounting server has
received accounting messages so that it has 2
accounting-session-id for the same session-id.
That would mean that 2 accounting subsessions
are active for that session-id. In that case,
the client MUST keep on increasing the record-number
between all messages sent to the accounting server
for that session-id. So, in the accounting server,
each subsession would hand up receiving several
accounting message, for which the only check that
is required in the accounting server would be that
the last accounting data stored has a record-number
lower than the latest received. Otherwise, it should
not be overwriting the existing data, since the
accounting data is made of cumulative data.

>      Reference: 
> http://www.merit.edu/mail.archives/aaa-wg/2001-07/msg00010.htm
l 
     Document: base
     Comment type: T 
     Priority: 1 
     Section: 9 

     Requested change: 

          9.6: 

"Each accounting message must contain a session-id,
which basically identifies an accounting session
on the accounting server. Furthermore, it may 
contain an accounting-session-id, which would be 
used to identify a subsession within that accounting 
session.

An accounting message that would define only a 
session-id, without an Accounting-session-id AVP,
MUST be considered by the accounting server as being
an accounting-session-id of 0.

All applications that use the accounting subsessions 
in Diameter MUST communicate their termination conditions 
to the accounting server through the means of an 
accounting message, indicating either an EVENT_RECORD 
or a STOP_RECORD in the Accounting-Record-Type AVP.

Each subsession MUST be considered independent of
each other, within the same session-id."

       2) Add the following text to the end of 9.8.3:

"Record-numbers of subsequent accounting messages must be 
incremental.

That means that when a client sends an accounting
message to an accounting server, it MUST keep on 
incrementing the record number for each accounting
message sent for a particular accounting session.
That implies that an accounting server MUST consider
the accounting message for a particular accounting 
subsession as containing the latest valid accounting 
data, based on the highest Record-number received."

For example, let's say an accounting server has
received accounting messages so that it has 2
accounting-session-id for the same session-id.
That would mean that 2 accounting subsessions
are active for that session-id. In that case,
the client MUST keep on increasing the record-number
between all messages sent to the accounting server
for that session-id. So, in the accounting server,
each subsession would hand up receiving several
accounting message, for which the only check that
is required in the accounting server would be that
the last accounting data stored has a record-number
lower than the latest received. Otherwise, it should
not be overwriting the existing data, since the
accounting data is made of cumulative data.

/Jari

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 6 Aug 2001 00:54:18 -0700

<prc> Well there is an inconsistency in the base specification since the
Accounting-Session-Id definition in 9.8.4 states that this AVP must only
be used for RADIUS backward compatibility, while section 9.6 clearly
defines what you state above. Therefore, if this is really the intended
use of the Accounting-Session-Id, then I would claim that we should
create a new AVP that clearly states that it is used for subsessions,
and fix up the state machine accordingly.
</prc>

If subsessions are used, then I would argue that each subsession MUST
have a START and STOP. Otherwise, I am not sure how a server could know
when a session has been relinquished.

<prc>The current spec in section 9.8.3 states:

"The Accounting-Record-Number AVP (AVP Code 485) is of type 
Unsigned32 and identifies this record within one session. As
Session-Id AVPs are globally unique, the combination of
Session-Id and Accounting-Record-Number AVPs is also globally
unique, and can be used in matching accounting records with
confirmations.  An easy way to produce unique numbers is
to set the value to 0 for records of type EVENT_RECORD
and START_RECORD, and set the value to 1 for the first
INTERIM_RECORD, 2 for the second, and so on until
the value for STOP_RECORD is one more than for the
last INTERIM_RECORD."

The above clearly states that an Accounting-Record-Number is unique
across the same Session-Id. So a specific record number cannot be used
across subsessions for a given Session-Id. </prc>
 
l 
     Document: base
     Comment type: T 
     Priority: 1 
     Section: 9 

       1) Unclear about when the whole session ends for an application
          that uses only Diameter accounting, and has subsessions
       2) Unclear about when record numbers reset for subsessions
       3) Unclear about Accounting-Session-Id and
Accounting-Multi-Session-Id
          mandatory/optional status in the ABNF

     Requested change: 

<prc> OK

<prc> not sure this is absolutely required, but if folks think it helps,
I'll add the text.
</prc>

<prc> as well as some text in the state machine. </prc>

PatC

---

From: "Martin Julien (ECE)" <[email-masked]>
Date: Mon, 6 Aug 2001 10:30:08 +0200

See comments.

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Monday, August 06, 2001 9:54 AM
> To: [email-masked]
> Subject: RE: [AAA-WG]: Accounting questions
> 
> 
> > > Q1-

I think it is needed as well. That would be great!

> across subsessions for a given Session-Id. </prc>

I would like to get a "MUST" for the increasing order of record-numbers.

The problem is that it seems difficult for the accounting server to 
identify the latest accounting information, unless there is some kind
of indication in the accounting message that brings it. So, by using
the Accounting-Record-Number, it is easy for the accounting server
to discard older Accounting-Record-Number received after a later
one for the same session-id, in case of retries on the network that
would make some accounting messages being delayed and received in
the wrong order in the accounting server. The thing is also that
accounting data is cumulative, and the accounting server is required
to keep only the latest data. 

> <prc> not sure this is absolutely required, but if folks 

I'd appreciate.