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

From: "Pat R. Calhoun" <[email-masked]>
Date: Wed, 27 Feb 2002 08:33:18 -0800

>Not only is there a Session-Id, which is unique, but 
>there is also an accounting record number. Those two items are 
>guaranteed to be unique, and therefore are a great way of checking 
>for dups. I don't understand the mechanism by which records are put 
>in a "temporary" buffer, as opposed on written on disk. You need to 
>write ALL records in this "temporary" buffer (if it even exists) in 
>order to check for duplicates. 
>
>What really confuses me here is how the checks are done. Using a 
>single bit 'D' isn't really useful for a lookup. 

It is useful. Either you believe that every record is a potential
duplicate and hence do duplicate checks of every record against every
other record (records within a certain duration +/- 24 hrs for eg.)
or
you do the check for duplicates only on records that have the "D" bit
marked explicitly. So the "D" bit improves the performance by a
significant enough margin.

<PRC> But what about packets that are received out of order (D bit is
received
First)?

PatC

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 27 Feb 2002 18:50:51 +0200

RE: [AAA-WG]: Request for closure on issue 235> <PRC> But what about packets that are received out of order
> (D bit is received First)?

1. D bit record is first received, and you search all records, no
match. you also search the pool, no match. you put it to a pool.

2. non-D bit record is received after that, and you search the pool
(not all records)

So, using the current scheme you do 2 all-records searches
total. Using the d-bit method you do 1 all-records search and 2
pool searches. Worth it? If the pool searches are significantly faster.
(Basavaraj, you do have to make some full searches anyway!)

Jari