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

From: <[email-masked]>
Date: Wed, 16 Oct 2002 19:26:13 +0300

Hi Ohba,

> 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).

I agree with you that D-bit scheme is very usefull also for other applications.

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

Actually checking for D=0 is never needed, probably you are thinking to the case
when D=1 is received before D=0, out of order. Am I right?
D=1 is stored for later processing but doesn't need to be processed immediately, no
harry. Checking of the last received D=1 can safely be postponed (e.g. according to the current
available resources in the server etc.) and  should, however,  always start with sufficient
delay to be sure that possibly out of order record have been received.
For example, if checking is delayed >= 2 * TIME_WAIT (e.g. 5 min.) you are sure that TIME_WAIT is
over and possibly out of order record should have been received. When checking, a forward (+)
time window of  e.g. 2 * TIME_WAIT  can be used to be sure that you catch the
possible out of order record. Usually backward and forward time windows are configurable
in the server.

> 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.

I'm just wondering that the server doesn't know the reason of the re-transmission, failover/failback
or application re-transmission. I guess a better approach would be a generic scheme applicable to 
all the cases.
My feeling is that Session-Id and Accounting-Record-Number is a good generic scheme
applicable in any case.

Br
Marco

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 16 Oct 2002 12:45:14 -0400

> when D=1 is received before D=0, out of order. Am I right?

Yes.

> possible out of order record. Usually backward and forward time windows are configurable

OK.  I unstadant that there are several implementation design choices 
on the scheme.

> or application re-transmission. 

It does not have to know actually.  Duplicated messages that are not
detected based on End-to-End ID and Origin Host will be automatically
passed to the application, and the application can do another
detection (application-specific duplication detection) based on
Session-ID and Acct-Record-Number.

> I guess a better approach would be a generic scheme applicable to 
> all the cases.

I meant to be generic to all authentication and accounting
applications, not only to all accounting applications.
Authentication applications do not have Accounting-Record-Number.

> Marco

Yoshihiro Ohba