Subject: [AAA-WG]: ISSUE: Time in end-to-end identifier

From: Mark Eklund <[email-masked]>
Date: Tue, 13 Nov 2001 10:40:15 -0500 (EST)

Submitter name: Mark Eklund
Submitter email address: [email-masked]
Date first submitted: 13-Nov-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00200.html
Document: base
Comment type: T
Priority: 1
Section: 3.2
Rationale/Explanation of issue:

  Initializing the end-to-end identifier to contain 12 bits of time has
  some problems.

  1. If the diameter implementation can generate more than 1,048,575
     transactions, it is possible to get duplicate records.  Consider
     a NAS that generates 2,097,152 that started generating at time t,
     ran for 10 seconds, rebooted, and started generating again at t +
     20.  The last record would be t * 0x00100000 + 2,097,152 * 10 = t
     * 0x00100000 + 0x1400000.  The first record generated is (t + 20)
     * 0x00100000 + 0 = t * 0xFFF00000 + 0x1400000.  This is the same
     as the last end-to-end before reboot.  Note, I ignored the fact
     that the bottom bits are random.  This doesn't matter because
     in the next second at 2M transactions per second, that random
     number will be seen.

  2. The clock on some embedded systems is reset to zero after reboot.
     Thus, the time would always be the same.

  3. NTP can actually make time go backwards while syncing.

Requested Change:

  The 12 bit time initializer is good for most implementations.  But
  if another implementation needs to implement it differently (like
  checkpointing the identifier), it shouldn't have to violate the RFC
  to do it.  So add a SHOULD to the description.

    Upon reboot, the high order 12 bits SHOULD be initiated to contain
    the low order 12 bits of current time, while the low order 20 bits
    SHOULD be set to a random value.

-mark

---

From: David Frascone <[email-masked]>
Date: Tue, 13 Nov 2001 10:19:54 -0600

I thought the consensus was to *not* mandate how the identifiers were
generated, but to state that they must be unique for a given timeframe.

Am I mistaken?

-Dave

---

From: Mark Eklund <[email-masked]>
Date: Tue, 13 Nov 2001 12:01:17 -0500

> generated, but to state that they must be unique for a given timeframe.

I now remember something like that.  I'll support that equally.

Does everyone else agree?

If so, lets just make sure the sentence containing the time is not in
the next version of the drafts.

-mark

---

From: Barney Wolff <[email-masked]>
Date: Tue, 13 Nov 2001 14:43:51 -0500

I thought the wg had come to rough consensus that the requirement
would be reduced to saying there MUST NOT be a duplicate id within
N minutes where N is a reasonable number.  We might then keep the
description of the "old" algorithm as an example of how to meet the
requirement without NV storage, but not as itself a requirement.

Is anybody even contemplating a Diameter system that generates more
than 1e6 transactions per second?  I'd warn against the dangers of
overdesign, but that battle was lost long ago.

Barney

On Tue, Nov 13, 2001 at 10:40:15AM -0500, Mark Eklund wrote:
>  ...

-- 
Barney Wolff

"Nonetheless, ease and peace had left this people still curiously tough.
They were, if it came to it, difficult to daunt or to kill; and they were,
perhaps, so unwearyingly fond of good things not least because they could,
when put to it, do without them, and could survive rough handling by grief,
foe, or weather in a way that astonished those who did not know them well
and looked no further than their bellies and their well-fed faces." J.R.R.T.

---

From: Mark Eklund <[email-masked]>
Date: Tue, 13 Nov 2001 15:07:01 -0500

Barney,

Pat had sent me his current version of End-to-End Identifier yesterday
and I have included it below.  He did add the "unique for a time period"
part, but the initialization using time remained the same.  It may be
a simple case of "whoops, I forgot to remove that".  I made an issue
to make sure it got changed.  My suggestion was to change the sentence
about the time to be SHOULD.  Your suggestion of rewording it as an
example is another option.

   End-to-End Identifier
      The End-to-End Identifier is an Unsigned32 field and 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 messages 
      MUST insert a unique identifier on each message. The identifier MUST remain
      locally unique for a period of at least 4 minutes. The originator of an Answer 
      message MUST ensure that the End-to-End Identifier field contains the 
      same value that was found in the corresponding request. The End-to-End 
      Identifier MUST NOT be modified by relay agents. The combination of the 
      Origin-Host and this field is used to detect duplicates. Duplicate 
      requests SHOULD cause the same answer to be transmitted (modulo the 
      hop-by-hop Identifier field and any routing AVPs that may be present), 
      and MUST NOT affect any state that was set when the original request 
      was processed. Duplicate answer messages that are to be locally 
      consumed (see Section 6.2) SHOULD be silently discarded.

-mark

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 13 Nov 2001 20:14:58 -0800

I think Mark's characterization of the "whoops" is about right.

I'll have that fixed.

PatC