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

From: "Kobylarz, Thaddeus" <[email-masked]>
Date: Tue, 17 Apr 2001 10:14:10 -0400

Jari,
	Thanks for your input, especially the idea of doing batching at the
transport level by conveying a priority flag.  This appears to be simpler
than the switching from Diameter to FTP or TFTP.  I will to take these
thoughts and caveats to the 3GPP Charging folks.
	I'll keep you informed of their responses and look forward to your
future comments.
Thad

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Tuesday, April 17, 2001 2:30 AM
To: Kobylarz, Thaddeus
Cc: 'Jari Arkko'; Barney Wolff; John Alayari; [email-masked]; Bob
Engelhart; Chuck Adams; Daly, Brian; [email-masked]; John
Molchan; Luisa Marchetto
Subject: Re: [AAA-WG]: RE: Accounting-status-Ind & interim data

>The proposal for a choice of FTP or TFTP for "batch" has not
>received objections by the SA5 Charging group.  Do you see
>any problems with
>this proposal?

Perhaps I should clarify a little bit the background of
the batch discussion. After extensive discussions, it
was earlier decided that it is not necessary to support batch
mode in Diameter at the _message level_. However, the
protocol still supports batching at the _transport level_,
i.e. from the network point of view you will still
get the same behaviour. Main issues in the decision
to handle batching in this manner were the observation
that the transport layer can do this, and the difficulties
in handling Diameter-level batches in a reasonable manner
through proxies. In other words, cryptographic operations
and protocol acknowledgements get complicated when parts
of the batch end up in one direction while the rest goes
to another.

The current discussion is about the use of batches to
send data from a dying Diameter client. My proposal for
handling this situation is specifying that the client
SHOULD send the data before the i'm-dying message if
it still can. This sending takes place through normal
diameter mechanisms, and is also batchable at the transport
level. 

In the latest IETF meeting, we discussed the prioritizing
of accounting records which was a 3GPP requirement. I
made the proposal that a priority attribute added
to the records would be sufficient for a node to decide
how fast a particular record should be treated; real-time
records would go directly to the processing and sent
further to the next transport from the proxy, and batch
records could wait until there is time and bandwidth available
for processing them.

Regarding the use FTP or TFTP, they are widely used
for batching. Issues that you may want to think about
include the following:

- Making sure there is some application or IP level
  security involved so that the transport is secured.

- The proxying of batches is an equivalently hard problem
  for FTP and TFTP as it is for Diameter. If the 3GPP
  architecture includes proxies, specify rules on how
  batches are handled in them.

- How the batching is iniated and controlled.

- I understand that real-time is also a main requirement
  in the 3GPP. In order to add batching, your basic choices
  are to use the real-time protocol (Diameter?) also
  for batching i.e. rely on the transport layer batching,
  or to use another batch protocol (e.g. ftp). You may
  want to have clear requirements on why to do one or the
  other. In fact I'm not even sure what the difference
  in characteristics would be on the two alternatives.

Jari