Subject: RE: [AAA-WG]: New Issue: End to end identifier

From: "Martin Julien (ECE)" <[email-masked]>
Date: Fri, 2 Nov 2001 12:20:53 +0100

I am also strongly in favor of letting the implementor decide
on how to manage the e-2-e Id. I actually do not see any reasons 
for forcing it incrementing by one, and so far, only good reasons 
for letting this e-2-e Id assignment question up to the implementors.

Martin

> -----Original Message-----
> From: Bob Kopacz [mailto:[email-masked]]
> Sent: Wednesday, October 31, 2001 3:43 PM
> To: Barney Wolff; [email-masked]
> Subject: RE: [AAA-WG]: New Issue: End to end identifier
> 
> 
> Hi Barney and Kevin,
> 
> I'd like to see this accepted, for the same reasons that 
> Kevin stated, 
> plus more.
> 
> This isn't actually a new issue.  Issue#93 is about the e-t-e
> identifier.  I re-opened this issue in an email on 10-12-2001,
> because I saw what I believe to be a flaw in the current draft
> regarding e-t-e identifier.  I also requested that the
> "increment by 1" requirement be removed.  There were a few
> emails exchanged among Pat, Barney, Mark, and myself, but 
> then the thread quietly died without resolution.
> 
> Here's a rehash of my thinking as to why the "increment by 1"
> is unuseful and unnecessary:
> 
> 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.
> 
> I was also thinking that the "increment by 1" might cause 
> complications
> for multi-process Diameter implementations.
> 
> For example, imagine a Diameter server implemented as three
> communicating processes: The NASREQ application is one process.  The
> Mobile-IP application is a second process.  And there is a third
> lower-level process which handles the Diameter base protocol and the
> TCP/SCTP connections.  When the NASREQ application or Mobile-IP
> application originate a message, they pass it to the lower-level
> process for transmission.
> 
> If there is an "increment by 1" rule, then the applications would
> need to access some common "end-to-end-identifier allocator".  Or
> the applications would have to let the lower-level transport process 
> assign the end-to-end-identifier, but then the lower-level transport
> process would have to return it to the application process.
> 
> If there wasn't an "increment by 1" rule, than each application
> could manage its own end-to-end-identifier allocation, as long as it
> didn't clash with the end-to-end-identifiers allocated by other
> processes.  To ensure a non-clash in this example, the NASREQ
> application could assign even-numbered end-to-end-identifiers, while
> the Mobile-IP application could assign odd-numbered
> end-to-end-identifiers.  In this case, then, each application would
> be incrementing by two rather than one.
> 
> Bob K.
> 
> 
> > From: [email-masked] on behalf of Barney Wolff
> > [[email-masked]]
> > Sent: Wednesday, October 31, 2001 1:47 AM
> > To: [email-masked]
> > Subject: Re: [AAA-WG]: New Issue: End to end identifier
> > 
> > I cannot imagine any implementation where a single 
> spinlock-protected
> > increment would even be measurable, so I'd urge rejection 
> of this issue.
> > Do all these processors share a single transport connection?  If so,
> > there are many more accesses that need protection.  If not, you're
> > making scalability problems for your peer.
> > 
> > If you don't have shared memory, do the id assignment and 
> increment in
> > the process that owns the transport.  Or allocate N id's 
> per invocation.
> > I don't see a requirement here to actually transmit the messages in
> > id order.
> > 
> > On Tue, Oct 30, 2001 at 04:29:02PM -0800, Kevin Purser wrote:
> > > Submitter name: Kevin Purser
> > > Submitter email address: [email-masked]
> > > Date first submitted: 10/30/01
> > > Reference: none
> > > Document: Base-08-alpha
> > > Comment type: 'T'echnical
> > > Priority: '1' Should fix
> > > Section: 3.0 Diameter Header
> > > Rationale/Explanation of issue:
> > > 
> > > On diameter servers which may utilize multiple (and 
> potentially many)
> > > processors, forcing the end-to-end identifier to be 
> monotonically increased
> > > by one for every message sent will probably cause 
> scalability issues.  This
> > > is due to the fact that this identifier would have to be 
> in shared memory,
> > > and would require mutually exclusive access amongst all 
> processors in order
> > > to update the value, thus slowing down all other diameter 
> processes waiting
> > > to send a message.
> > > 
> > > Requested change:
> > > In the sentence below, remove the phrase "by incrementing 
> the identifier by
> > > one (1)."  After all, the method of ensuring the 
> uniqueness of an identifer
> > > is probably more of an implementation issue anyway, right?
> > > 
> > > Senders of request or answer messages MUST
> > >       insert a unique identifier on each message, by 
> incrementing the
> > >       identifier by one (1).
> > > 
> > > 
> > 
> > -- 
> > Barney Wolff
> 
> Bob K.
>

---

From: Barney Wolff <[email-masked]>
Date: Fri, 2 Nov 2001 09:14:54 -0500

> for letting this e-2-e Id assignment question up to the implementors.

The motive is to get the maximum interval between duplicate ids.
If people can't figure out how to implement id++ efficiently,
fine, let the specification be changed to say the id MUST NOT be
duplicated within X minutes, and pick a reasonable X.  This is not
just a matter for the implementer, and the need for a safe id
algorithm is especially acute for the sort of high volume node that
would be implemented with multiple processors.
-- 
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.