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

From: <[email-masked]>
Date: Wed, 27 Feb 2002 13:31:26 +0200

> -----Original Message-----
> From: ext Barney Wolff [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 8:52 PM
> 
...
> 
> 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

But there are cases when billing actually takes place in real time, called prepaid charging. So the usage of the D-bit would make a significant performance improvement for the receiver in these cases.

- Anne

---

From: Jari Arkko <[email-masked]>
Date: Wed, 27 Feb 2002 16:55:42 +0200

[email-masked] wrote:

> But there are cases when billing actually takes place in
> real time, called prepaid charging. So the usage of the
> D-bit would make a significant performance improvement
> for the receiver in these cases.

The prepaid case is a valid one. So D-bit is useful when
the following condition is fulfilled:

RealTimeBilling AND PoolLookUpFasterThanSessionIdLookUp AND
PoolLookUpFasterThanUserNameLookUp

Since the D-bit method also requires SessionId look-ups in
certain cases, we always need a reasonably fast look-up
anyway i.e. linear list of all records is not acceptable for
D-bit either. So this really boils down to the question of
whether the pool lookup (small and likely in RAM) is faster
than a real record lookup (likely on disk but index likely
in RAM).

Jari

---

From: Barbara L Hall <[email-masked]>
Date: Wed, 27 Feb 2002 08:53:24 -0700

Real-time usage data is a requirement.

The customer wants current status of an account.  The high value provider
will quantify that usage in time, in counts and in dollars (or whatever
monetary translation applies). No one refutes that 'billing' will continue
to occur offline after considerable sifting.  But Nokia points out what this
standard must provide to be adopted:  measurable, identifiable, reliable
event creation.

Resolving duplicates is the issue.

We may be getting off the mark by settling for batch and post-processing as
an easy or natural resolve.  The market expectations are considerably
higher.  If the discussion here is expediancy then accept the D-bit and note
the intent to improve the solution in the next standard release.  That
prepares the coders to isolate the solution.  [J2EE version 1.3.1 is an
adjustment.  But an easy adjustment, compared to the invaluable standards
that never baseline, only get closer and closer to infinity.]

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 27, 2002 4:31 AM
Subject: RE: [AAA-WG]: Request for closure on issue 235

...
> duplicates is trivial with or without the D-bit.

But there are cases when billing actually takes place in real time, called
prepaid charging. So the usage of the D-bit would make a significant
performance improvement for the receiver in these cases.

- Anne