Subject: RE: [AAA-WG]: Request for closure on issue 235

From: "Pat R. Calhoun" <[email-masked]>
Date: Tue, 26 Feb 2002 07:19:38 -0800

a. 1) Non-D, 2) D: Here the arrival
      of the D record triggers search
      against all records. Duplicate is found.

   b. 1) D, 2) Non-D: First the D record
      arrives, an all record search is
      performed. The D record goes to a special
      pool, and the Non-D record, when it arrives,
      is checked against this pool and duplicate
      is found.

   c. 1) D: A search against all records is
      performed, but no result hence the record
      is accepted.

   d. 1) Non-D: A search against the pool is
      performed, but no result hence the record
      is accepted.

In conclusion, the method requires the following:
  1. Checking all D-marked records against *all*
     other records.
  2. Checking all regular records against those
     stored in the D-pool.
  3. The D-pool contents must have some expiration
     time after which the records are moved out of
     the pool.

<PRC> The conclusion that I came up with is that a search is required
regardless of whether the D bit was set or not, because you cannot
guarantee the order in which the packets are received.

So what is the gain here?

PatC

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 26 Feb 2002 18:11:28 +0200

RE: [AAA-WG]: Request for closure on issue 235
> So what is the gain here? 

In case (d) -- the normal case -- the search is performed not to the
whole set of records but to a potentially smaller set, the pool of records
with D bit set. This set might even be typically empty.

So, a search is always needed but not necessarily same type
of search. At the end of my e-mail I made some calculations on
whether this saves something or not. The conclusions depend on
whether you believe the pool search will be less costly than the
full record search.

Jari

---

From: Barney Wolff <[email-masked]>
Date: Tue, 26 Feb 2002 11:54:33 -0500

The D-bit is an optimization, so we are entitled to assume that another
optimization, namely using User-Name as a primary search key, is also
taken.  In that case, the two searches are likely to take the same time.
But I'd be very careful with the notion of keeping a database of "recent"
records - that implies an insert and delete operation on every record
in real time and is likely to be painful.

There is also the end-to-end argument:  the biller should certainly make
a check that the line items it is billing contain no duplicates.  Therefore
making such checks at earlier stages is only justified if the cost of
detection and correction is substantially greater at the billing stage.

On the other hand, Diameter already contains so many bells and whistles
that no argument for simplicity has any force.

Barney Wolff