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

From: <[email-masked]>
Date: Wed, 16 Oct 2002 20:06:39 +0300

Hi Ohba,

> 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

the focus was only to accounting applications.
Do you think the D-flag would be useful for authentication application too? 

However, is It not better approach to leave the detailed solution specification
to the application definition?

Br
Marco

> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 16. October 2002 19:45
> To: Stura Marco (NET/Helsinki)
> Cc: [email-masked]; [email-masked]; 
> [email-masked];
> Loughney John (NRC/Helsinki); [email-masked];
> [email-masked]
> Subject: Re: [AAA-WG]: Use of the D-Bit clarification
> 
> 
> On Wed, Oct 16, 2002 at 07:26:13PM +0300, [email-masked] wrote:
> > 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?
> 
> Yes.
> 
> > 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.
> 
> OK.  I unstadant that there are several implementation design choices 
> on the scheme.
> 
> > 
> > > 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. 
> 
> 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.
> > My feeling is that Session-Id and Accounting-Record-Number 
> is a good generic scheme
> > applicable in any case.
> 
> 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.
> 
> > 
> > Br
> > Marco
> > 
> 
> Yoshihiro Ohba
>

---

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

Marco,

> Do you think the D-flag would be useful for authentication application too? 

Based on my analysis, yes.  I just thought that it can also enhance
the performance of duplication detection performed in the Diameter
base engine by using the E-E ID and Origin-Host AVP regardless of
application types, in that servers do not have to check 
for every received request message, right? (But the D-bit indication
might be informative, as Jari mentioned.)

> to the application definition?

That's why I'm suggesting the separation of the duplication detection
schemes into two.  D-bit scheme based on E-E ID+Origin-Host AVP, which
would be common to all applications, could be described in the base
spec.  D-bit scheme specific to realtime accounting application based
on Session-ID+Acct-Record-Number can be described in either the base
spec (if the realtime accounting application is supported as base
accounting application) or separated document (if the realtime
accounting application is supported as a new accounting application).

Those two schemes are essentially identical except for which header
field and/or AVP are used as the search key for duplication detection.

Yoshihiro Ohba

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 16 Oct 2002 13:54:55 -0700

> might be informative, as Jari mentioned.)

But duplicate detection is not required (in general) in Diameter, right?
Even for accounting, duplicate detection/removal can very often be left to a
back-end processor.

> field and/or AVP are used as the search key for duplication detection.

Right, and since neither of these schemes are actually necessary for the
correct operation of the protocol (as opposed to the correct processing of
the _data_ carried _by_ the protocol, and that only in certain special
situatons), I would prefer to leave any description of any processing out of
the base protocol document.  I suggest that the 'D' bit be renamed the 'T'
for reTransmission bit, to be set on any retransmission of a Diameter
message.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 16 Oct 2002 21:10:44 -0400

Yes. 

> for reTransmission bit, to be set on any retransmission of a Diameter

Agreed, as long as it does not preclude the generic usage I suggested 
as well as the original usage for realtime accounting application.

Yoshihiro Ohba

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 16 Oct 2002 19:02:35 -0700

> as well as the original usage for realtime accounting application.

I think that the bit could be used in (non protocol-related) processing in
whatever way one might wish.

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Oct 2002 21:42:40 -0700

>> Even for accounting, duplicate detection/removal can very often be left
>> to a back-end processor.
> Yes. 

so, please remind me why we need to make things more complicated?

randy

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Oct 2002 10:24:07 +0300

> for reTransmission bit, to be set on any retransmission of a Diameter

Agree. I also don't want to see a mandated treatment at the server side,
except maybe in a specific accounting extension spec.

Jari