Subject: FW: [AAA-WG]: Issue 227: End-to-End Identifier

From: "Bob Kopacz" <[email-masked]>
Date: Fri, 2 Nov 2001 13:50:30 -0500

Hi Pat,

If issue#93:End-to-End Identifier is closed and not to be re-opened, 
and Issue#227 is the new issue# for End-to-End Identifier, then I'm
here just re-sending my End-to-End Identifier issue under
the new issue#, so it doesn't get lost.  

There's also a thread of a few emails from you, Mark, myself, 
and Barney that followed this one.

Bob K.

-----Original Message-----
From: Bob Kopacz [mailto:[email-masked]]
Sent: Friday, October 12, 2001 3:42 PM
To: Pat Calhoun
Cc: aaa-wg
Subject: RE: [AAA-WG]: Issue 93: End-to-End Identifier

Hi Pat,

I'm sorry to dredge this up, but I think there is a flaw here, so would
like to re-open issue#93 and propose a solution.

Base-Draft-08-alpha01 says:

   End-to-End Identifier
      The End-to-End Identifier is used to detect duplicate messages.
      Upon reboot, the high order 12 bits are initiated to contain the
      low order 12 bits of current time, while the low order 20 bits is
      set to a random value.  Senders of request or answer messages MUST
      insert a unique identifier on each message, by incrementing the
      identifier by one (1).

I'm thinking that, if the goal of the 12 time bits is to guarantee
unique identifiers across reboots, then the end-to-end identifier's
high-order 12-bits would need to be set to the current time's low order
12 bits every time an end-to-end identifier is generated, not just upon
reboot.

Then you would be guaranteed to produce unique identifiers across
reboots provided that you meet the following criteria (which I lifted
from earlier emails discussing this issue):

1. the device takes longer than a second to reboot

2. no transaction is kicking around for longer than an hour or so 
   (2 ^ 12 seconds)

3. the transaction rate (the rate at which the identifier is incremented) 
   is no greater than a million per second (2 ^ 20).

The flaw: If the end-to-end identifier's 12 high-order bits are
initialized only upon reboot, then there is no guarantee that upon
reboot, a node wouldn't be sending the same end-to-end identifiers he
was sending just a few seconds before the reboot.  For example, suppose
a node initializes his end-to-end identifier's 12 high-order bits only
upon reboot.  Suppose this node is booted at time T, stays up for 4095
(=2^12-1) seconds, and is rebooted at time T+4096.  Then in each of
these incarnations, the node would be using the same value for the 12
high-order bits of the end-to-end identifier.  And the end-to-end
identifiers used in the last few seconds of its previous life might be
reused in the early transactions of its new life.

Of course, if the end-to-end identifier's 12 high-order bits are updated
every second, then the end-to-end identifier jumps by about 2^20 every
second.

I don't think there are any time bits that will help if you only want to
init the high-order End-to-End Identifier bits upon reboot, so either go
with updating the high-order bits every second, or get rid of it
altogether and just init the End-to-End Identifier to a 32-bit random
number upon reboot.

The other comment I have to make is about the sentence "Senders of
request messages MUST ... increment ... the identifier by one (1)".  The
"increment by 1" requirement seems to be an over-specification which
imposes restrictions on the message originator's implementation, is
undetectable by the message's recipient, and doesn't benefit the
message's recipient.  The previous thread concluded that a receiver
could not make use of the "increment by 1".  Chiefly, a recipient may
receive an unordered and vanishingly small percentage of a client's
Diameter messages.

An end-to-end identifier which jumps by about 2^20 every second makes
the unuseful "increment by 1" even less useful, so I propose getting rid
of it altogether.

Revise the End-to-End Identifier specification as follows:

   End-to-End Identifier

      The End-to-End Identifier is used to detect duplicate messages.
      Whenever an End-to-End Identifier is generated, the high order
      12 bits are set to contain the low order 12 bits of current
      time, while the low order 20 bits are set to a value that ensures
      a unique identifier on each message.

Bob K.