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

From: <[email-masked]>
Date: Tue, 26 Feb 2002 11:32:05 -0600

Barney Wolff [[email-masked]] wrote:

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

Agreed. The "D" bit will not necessarily cause every implementation to
do duplicate detection based on this bit. Duplicate detection can be
done via other means as has been discussed on the list. However with
the "D" bit it would allow searches to be done on a very small subset
of all records and thereby improve efficiency.

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

As I mentioned above, with the "D" bit you would not have to do an
insert/delete database op on every record.

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

-Basavaraj

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 26 Feb 2002 19:36:15 +0200

>In that case, the two searches are likely to take the same time.

I think one of the central question to answer is why the User-Name optimization
is not sufficient. Basavaraj, can you comment on that?

Jari

---

From: Barney Wolff <[email-masked]>
Date: Tue, 26 Feb 2002 13:52:12 -0500

When the D record arrives, all "recent" records must be searched to 
find the possible original.  Either this is a brute-force sequential
search, or some sort of indexing on all records must be maintained,
and records aged out when no longer recent.  Yes, the delete could
be effectively done in batches, by keeping hourly databases.

My problem with the D-bit is that it invites doing something in real
time that does not need to be done in real time, and puts a burden
on the sender while saving very little if anything for the receiver.
The biller is going to sort the records anyway, and finding adjacent
duplicates is trivial with or without the D-bit.

Barney Wolff

On Tue, Feb 26, 2002 at 11:32:05AM -0600, [email-masked] wrote:
> ... However with