Subject: [AAA-WG]: Clarifications on the "D" bit (Issue 235)

From: <[email-masked]>
Date: Wed, 27 Feb 2002 13:32:17 -0600

Some clarifications regarding the "D" bit (Issue 235) :

The "D" bit would be marked by the sender to indicate that it this is
a potential duplicate. Receiving nodes (such as accounting servers)
would use this information to check the duplicate marked records
against other records in the cache.

An advantage of the D-bit usage is that it is needed only in extremely
rare cases (eg. when link totally fails and normal retries do not help
within their timer expiry and retry counter ranges). In the absence of
the "D" bit the pool searches would require the checking of every
record against every other record all the time.

In the normal case (which is probably >90% or even more) with the
D-bit method the sender does absolutely no work in regards to the
duplicate checking support. 

Only in the very rare case of a total link/recipient node failure, the
failover procedures are invoked. And the sender does only the smallest
imaginable effort: 
Setting of the Diameter header bit 4 of octet 5, to the possibly few
yet unacknowledged messages that were sent just before link failure.
So the sender does minimal work and that too as a rare occurence.

On the receiving node it would also do minimal uniqueness support
work: 
The receiver would normally only check for duplicates if the Diameter
header bit 4 of octet 5 is set. In the very rare case a comparison
of the D-bit marked record's Session-ID & Accounting-Record-Number
AVP pair, against the recent/soon to be received accounting records
using the ordinary Session-ID & Accounting-Record-Number would be
performed.  
(And even that check could be made in an optimized way but that does not
change the relative efficiency advantage of using the D-bit as the
first-checked indicator.)

Processing 
==========

1) When ANY record is received, it is kept in a buffer for a
   configured amount of time (eg. 24h). 

Additionally:

2a) If the received record is D bit marked, it is compared to the
    previous near past (e.g. last 12h) received D-/non-D-marked
    records by the already defined 2 AVPs for uniqueness. Even if
    there is no match, the D-marked record is ALSO compared to all the
    future records (e.g. next 12h) which takes care of messages
    arriving out-of-order (or duplicates arriving after the node has
    received the D bit marked record).

or

2b) If the received record is non-D-marked, it is compared to the
    near past(e.g. last 12h) received D-marked records by the
    already defined 2 AVPs for uniqueness. Even if there is no match,
    the non-D-marked record is ALSO compared to the near future
    D-marked records (e.g. next 12h), to avoid the message reordering
    problem. 

3) If a match (duplicate) is found the _first_ received record of the
   duplicated pair is deleted, and the more recent one of the
   duplicated pair stays in the pool as long as the pool timer permits.

-Basavaraj