Subject: [AAA-WG]: Issue 235 - Enabling efficient accounting record uniqueness checking

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Mon, 12 Nov 2001 09:26:23 -0600

Hello,

Before rejecting issue 235 I would request that the AAA WG have a 
serious look at it, since the question is really about
improving the Diameter accounting record uniqueness
checking to be clearly extremely efficient with very minor enhancements.

Below is an analysis of the efficiency achieved by enhancing
the protocol with a very small change with two possible alternatives
being suggested:

Solution alternative 1:
-----------------------
In short, the issue 235 proposal is to set a Diameter
header flag ('D') for those few (e.g. 5-10) yet
unacknowledged accounting records that are sent
by a Diameter node or proxy (again) after a
link/node failover case.

  This way these possibly duplicated accounting
records can each later be identified as the (only)
ones needing the detail comparison check in
the Diameter server (or related accounting engine)
against all the other accounting records received
XX hours before it or XX hours after it.
  So the proposal is to do mandatory detail
uniqueness comparison (with Session-Id AVP and
Accounting-Record-Number AVP pairs) only for such
Diameter accounting records that are potential
duplicates.
  The solution is easy to implement and this
checking method is described in just one sentence,
proposed to be added to end of 2nd paragraph
of section 9.4.

  (The XX hours could be e.g. 24 hours. Some kind of sliding
"time zone window" for accounting record uniqueness checking
is needed, no matter which one of the two uniqueness checking 
methods would be used.)

Solution alternative 2:
-----------------------
The older solution alternative is to perform
the accounting record uniqueness checking by
mechanically just comparing EVERY record received
against EVERY other (as in the current base08
alpha02 text, in the 2nd paragraph of the section
9.4), in detail (with the Session-Id AVP and
Accounting-Record-Number AVP pairs).

About the AVP pair checkings there was a comment
that by building (and maintaining) an indexed
database, the comparisons could be done somewhat
smoother than with direct comparison series
(octet by octet) for each of the AVP pairs of
the packets.
  Anyhow, the Session-Id format is:
DiameterIdentity ; high 32 bits ; low 32 bits [;optional value],
which is DiameterIdentity + 4 + 4 + optional N octets,
and the DiameterIdentity inside that is of the format
(after the possibly omitted parts are first included by
their default values):
aaa://host.abc.com:6666;transport=tcp;protocol=diameter;[email-masked]
8
  Therefore the whole Session-Id length is in e.g. the
above example 73 + 4 + 4 ( + optional N ) octets long,
i.e. 81 (+ optional N) octets. If an indexed database
or some advanced algorithms are tried to be taken
into use here, one must note that the Session-Id
AVP nature is not completely ideal for this, as
the starting part, before the 32-bit values is
variable what comes to its contents part lengths,
and requires parsing efforts and searches of the
';' characters from the AVP string first, to be
able to build the possibly missing default values
to the string and to determine the offset to the
start of the embedded 32-bit values.
  Finally, even if some machine cycles can be
saved over a direct octet-by-octet comparison way,
the building and maintenance of indexed databases
(for the sliding uniqueness checking time window)
is *equally* possible for *both* the Solutions 2
and 1, so their relative difference in processor
resource consumption is *anyway* still extremely high
and not realy required.

Analysis:
---------
Here are some rough computations:

Assumptions:
a. 10M subscribers
b. Of the 10M only 1/10th of these are connected at any given time. 
c. No real-time charging
d. Diameter clients send accounting records every 10secs

  That is 6 records per minute, 360 records per hour and
8640 record per day. Therefore 10M subscribers that
are in communication connection 10% of their time,
cause 8.640.000.000 accounting records per day.
Lets assume a 24-hour comparison window forward
for each record and a 24-hour comparison window
backwards (for the uniqueness checks).
In this example we assume that one Diameter
client crashes/becomes non-functional once every
30 days on an average in the network. It has then 5 unacknowledged
accounting packets in its non-volatile memory which
may be now duplicates when sent again via a secondary
peer node (or the primary peer if that is reasonably
quickly recovered).

For solution alternative 1 there would then be in this
example 5 'D' flagged accounting packets at a Diameter
client.
  They would be compared against 8.640.000.000
accounting records forward, and against 8.640.000.000
accounting records backward on the time axle.
Totally that would mean 5 x 2 x 8.640.000.000 =
86.400.000.000 detail uniqueness checks using
the AVP pairs (each consisting of e.g.
81 + 4 octets) PER MONTH. (In over one billion
cases over one, just checking the one 'D' bit of
the anyway inspected Diameter header flag octet
would suffice.)

The solution alternative 2 would on the other hand
require here 8.640.000.000 AVPs x 1 days time zone
x 8.640.000.000 AVPs / 2 (division by two since by
testing 2 pairs the test is done in both "directions")
= 37.324.800.000.000.000.000 detailed AVP pair
cross-checks PER EVERY DAY, using the AVP pairs
(each AVP pair consists of a) e.g. 81 octets,
whose detail manipulations would require e.g.
searches of the ';' delimiter characters
and parsing and analysis prior to comparison, plus
b) four octets having a fixed format).
(And, in future there can be many operator networks
that are even much bigger than the example 10M
subscribers.)

Since either solution can be implemented by using
multi-indexed database(s) or whatever additional
arrangements or algorithms, that is not changing
the relative performance ratio of the two solution
alternatives 1 and 2.

-----------------------------------------------------
Because of this huge efficiency achieved,  stemming from the number of
required AVP pair checkings (and the related processor resource
requirements) the solution 1 (=issue 235) is proposed
as an important and necessary fix to make the
current Diameter accounting record uniqueness
checking feasible enough and attractive for network
operators to use.
-----------------------------------------------------

-Basavaraj