Subject: [AAA-WG]: Use of the D-Bit clarification

From: <[email-masked]>
Date: Wed, 16 Oct 2002 14:50:08 +0300

Hi again,

here the mail that try better explanation of the D-bit.

For real-time accounting applications, such as the Diameter Credit Control
draft, it is important to immediately process the original request (D=0)
since action by the client (action to the user) will be 
taken if the answer doesn't come within a certain time. As the user
cannot wait for the service to be granted for 20 or 30 seconds, usually
a real-time accounting application defines a "waiting timer" after which
expiration the service is granted or not granted to the end user. A 
value of the timer is about 10sec. 

The client behavior is usually controlled by some "failure handling"
parameter. For example the failure handling for "one time event"
direct debiting in case "waiting timer" expires could be "grant the
service and store the request" or "grant the service and forget the
request", this is configurable by the service provider.

Storing the request is a sort of back-up to give a chance to the 
service provider that the used service may be debited to the
user's account later and revenue is not lost.

If a duplicate happens to reach the server, the "waiting timer" is normally 
expired and proper action to the end user already been taken.

This "one time event" direct debiting could be applicable to messaging
services, for example. For session based services e.g. VoIP or data services the one
time event approach is likely not applicable since online monitoring of the ongoing
session is needed. In this cases start/interim/stop approach where money 
is reserved first and debited only when consumed by the service is the best solution. 
A stateful server would be used and also in this case is important to immediately 
process the original request (D=0). Sice stateful server would be used, moving the
accounting data stream to alternate server shouldn't be possible. 
However duplicate may happen also in this case.

In all cases when duplicate happen to reach the server, the client application
"waiting timer" is normally expired and proper action to the end user already been taken.

Conclusion of the above is:

1- original request (D=0) must be processed immediately.
2- no hurry to process the duplicate (D=1)

When D=0, no checking is needed in the Server and the record is immediately
processed.

Only when a D=1 accounting record is encountered, then the checkings are done 
(its AVP pair against the other Session-ID & Accounting-record-Number AVP pairs
 of the +/- time window). When D=1, its Session-ID & Accounting-Record-Number AVP pair
is buffered for a possible future check, but no check is needed in normal case. 
A link failover procedure (causing the D-bit to be used for the last few yet 
unacknowledged accounting records, the amount being in maximum the protocol 
window size of records only) occurs e.g. during 2-3 days per year, so the rareness 
of the D=1 case causes that
     1- most of the time there are no extra checkings at all
        (when using the D-bit).
     2- when there are checkings the search is done just for the few D=1
        and only within the configurable time window to the future & past. 
       (Of course, the checks can be Session-ID based).   
     3- only limited amount of resourses for duplicate detection are required
	  in the Server.

Out of order records shouldn't be an issue because of the +/- time window. 

The key is that once a record arriving from Diameter client to
a Diameter server and is marked with D=1, then ***if the original is not found 
in the +- time window (e.g. TIME_WAIT),then the D=1 mark is not removed*** 
from the accounting record when sending it further towards the end system. 
The network's accounting end system can be understood and implemented as 
a _central logical entity_(no matter if it would physically consist of several servers).
It could then be left to the end system to compare the possible
still existing (very, very few!) D=1 marked records against others
in a configurable +- time window.

I hope the above clarify some of the discussed topics.

Br
Marco

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 16 Oct 2002 11:33:22 -0400

Marco,

I come to think that the D-bit scheme would be useful for duplication
detection not only for real-time accounting applications but also for
other applications, and having D-bit in Diameter header would make
sense (but with additional consideration, please see my comments
inline).

> When D=0, no checking is needed in the Server and the record is immediately

I think checking is needed if the current time is within + time window
started from the last reception of D=1.

>  of the +/- time window). 

For a class of retransmisstion that happened due to normal
failover/failback, it is not necessary to look Session-ID &
Accounting-record-Number AVP pairs.  Instead, looking End-to-End
Identifier and Origin-Host AVP in the Diameter server engine (without
bringing up to the application) is enough for such a class of
retransmission and if doing this way, the detection scheme 
can be generic to be applicable to other applications also.

On the other hand, there is other class of retransmission that
happened at a Diameter client due to rebooting.  For this class,
Session-ID & Accounting-record-Number AVP pairs should be used for
detecting duplication in the application, since different E-E ID 
will be used for the same accounting record in this case.

So, I would suggest treating the two classes of retransmission
separatedly.

> When D=1, its Session-ID & Accounting-Record-Number AVP pair

Regards,
Yoshihiro Ohba