Subject: RE: [AAA-WG]: Re: Accounting-status-Ind & interim data

From: "John Alayari" <[email-masked]>
Date: Wed, 11 Apr 2001 14:08:37 -0700

In the case when the client is about to be disabled and the usage
information accumulated in the local interim data storage may be lost, the
server may get the latest accumulated data.

John.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Patrice Calhoun
Sent: Wednesday, April 11, 2001 3:48 PM
To: John Alayari
Cc: [email-masked]
Subject: [AAA-WG]: Re: Accounting-status-Ind & interim data

>can we add accounting-Interim-interval AVP to Accounting-Status-Ind command
>(in section 14.3 of base). So interim data can be sent as well?

I suppose, but I would have to ask why. The message you refer to is used to
inform the AAA server that accounting is enabled, or disabled. So I don't
see
why an interim interval could be used in that particular message.

Could you please share your thoughts on when this would be used?

Thanks,

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 11 Apr 2001 15:48:16 -0700

I suppose, but I would have to ask why. The message you refer to is used to
inform the AAA server that accounting is enabled, or disabled. So I don't see
why an interim interval could be used in that particular message.

Thanks,

PatC

---

From: "Jari Arkko" <[email-masked]>
Date: Thu, 12 Apr 2001 07:32:41 +0300

> server may get the latest accumulated data.

I still have trouble understanding how the accounting-Interim-interval
AVP will help in this situation. That particular AVP is just for the authorization
or the accounting server to inform the client about how often it should
generate the interim records. Are you suggesting to send this AVP
with information about the planned outage at the client side so that the
server can use it for something?

Or are you thinking of sending the actual latest records? In that
case much more may be needed than this single AVP... and maybe
not even just one message, several, one for each session towards
that particular realm.

If the latter issue was your intention, there may also be other ways
of doing this. We could state something about the desired behaviour
of a Diameter client wrt existing client records when it is about to
stop accounting. For instance, we could say that Diameter clients
SHOULD try to send the latest interim records just before sending
the ASI.

By the way, it seems that the specification on who the ASI command
is really sent to is somewhat unclear. The text in 14.3 talks about the
"peer" but the AVPs such as the Destination-Realm in the message
might indicate more an end-to-end message... I' m not really sure
which one we even should prefer, because the peer variant is
a quick single message but not so useful, and the e2e variant could
be many messages but is on the other hand more useful.

Jari

---

From: "John Alayari" <[email-masked]>
Date: Mon, 16 Apr 2001 09:49:51 -0700

Hi Jari,

I am concerned about the losing accounting interim data since the last
transfer in the client. I believe, they should be transferred to the server
just before the ASI command. I am proposing a solution in my next email.

John.

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Wednesday, April 11, 2001 9:33 PM
To: John Alayari; [email-masked]
Cc: [email-masked]
Subject: Re: [AAA-WG]: Re: Accounting-status-Ind & interim data

>of doing this. We could state something about the desired behavior
the ASI.

Jari

---

From: Barney Wolff <[email-masked]>
Date: Mon, 16 Apr 2001 15:03:02 -0400

Um, we decided to forgo batched accounting, after discussion.
I respectfully suggest that we not bring it back.

Real-world, accounting would only be turned off as part of a
controlled shutdown of the access server.  That should generate
stops for each session without requiring special handling on
either side.  In my experience, uncontrolled shutdowns or restarts
are rather more common than controlled ones, even on equipment
from highly-regarded vendors. :)  So the value of a We-Who-Are-
About-To-Die-Salute-You command is limited, and any effort to
optimize it misguided.

Barney Wolff

On Mon, Apr 16, 2001 at 11:30:52AM -0700, John Alayari wrote:
> The current draft of the Diameter base protocol has the following command:
> 
> "14.3  Accounting-Status-Ind (ASI) Command
> 
>    The Accounting-Status-Ind command, indicated by the Command-Code
>    field set to 279, is sent by a Diameter node in order to inform its
>    peer of whether Accounting messages will be sent in the future. A
>    Diameter node that is about to be taken out of service SHOULD issue
>    an Accounting-Status-Ind message, with the Accounting-State AVP set
>    to DISABLED. A Diameter node that detected that it is able to issue
>    Accounting messages MUST issue an Accounting-Status-Ind message, with
>    the Accounting-State AVP set to ENABLED."
> 
> The issues is that the accounting usage information accumulated since the
> last transfer interval for each session, will be LOST and never get sent to
> the server.
> 
> I am proposing a solution for this to AAA WAG for discussion and hopefully
> we come up a good solution for this.
> 
> A NEW command say, Multi-Accounting-Request can be introduced that
> carries the AVPs such as origin-FQDN after the command header followed by
> one or more NEW AVPs (say Multi-Session-Record) of type Grouped.  This AVP
> carries stop records for all active sessions in the NAS to the server.
> This command should be sent to the server before the ASI command.
> 
> Please let me know what you think.
> 
> Thanks.
> 
> John Alayari.
> 
>

---

From: "John Alayari" <[email-masked]>
Date: Mon, 16 Apr 2001 11:30:52 -0700

Thanks.

John Alayari.

---

From: "Jari Arkko" <[email-masked]>
Date: Mon, 16 Apr 2001 23:49:27 +0300

>Um, we decided to forgo batched accounting, after discussion.

Correct. Let's not go there, and let's not bring up the 
issues such as proxying the batches in this discussion...

> About-To-Die-Salute-You command is limited, and any effort to

One thing we could perhaps do is to add language to the
diameter spec stating that if one is having a controlled
shutdown, then one SHOULD send the latest interim (or stop?)
records before ASI and before shutting down. Note that this could only
be a SHOULD, we can never require this to be always happening,
the client could easily be having serious trouble such as a 
power failure which does not allow it to send all records.

I do not propose adding the records to the ASI itself, let's keep that
part simple.

Jari