Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier

From: Jacques Caron <[email-masked]>
Date: Thu, 28 Jun 2001 18:34:42 +0200

At 18:31 28/06/01, Fredrik Johansson wrote:
>Also, add some text describing what a server should do when the e-2-e
>identifier has been seen before. e.g. discard it or reply with the same
>answer as last time.

Should reply with the same answer, not discard it. The only issue is that 
it should not do the same processing again, if that has "consequences" on 
anything (e.g. not store an accounting record a second time).

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Mark Eklund <[email-masked]>
Date: Thu, 28 Jun 2001 13:29:50 -0400 (EDT)

> anything (e.g. not store an accounting record a second time).

So, am I interpreting this right?  A server that serves 100
clients and has a window of 128 will have to remember how it
replied for 12800 packets?

What if it receives something below the window?  Do you just
drop the packet, or make up a best guess for the reply?

-mark

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 29 Jun 2001 09:19:15 +0200

>replied for 12800 packets?

Sound like alot of answers to save, I'm not sure (probably don't understand,
so someone please enlighten me) why you have to reply with the same answer.
If it's an request you already answered to why just not drop it?

>drop the packet, or make up a best guess for the reply?

I guess you have to try to figure out if it can be a wrap around in the e2e
identifier or if it's an old one. No matter how you define the e2e
identifier (monotonically increased or just increased) you will have to take
care of the wrap around. With a monotonically increased identifier you'll
encounter the problem less often.

/Fredrik

---

From: Jacques Caron <[email-masked]>
Date: Fri, 29 Jun 2001 11:54:41 +0200

>If it's an request you already answered to why just not drop it?

In your previous mail, you said "since we have reliable transport we should 
be able to assume that it reaches
the Origin-host of the request". That is not true: we have reliable 
hop-by-hop transport, not reliable end-to-end transport (the end-to-end 
reliability is provided by Diameter's Request/Answer mechanism, not the 
transport). If a link/host goes down between the request and the answer 
(not very plausible given the times we're talking about, but it might 
happen), then the answer is lost. At some point, somebody will send the 
request on an alternate path, and the server will receive it again. It 
should know that it's a request it already got, and act accordingly.

Actually, it is important that any actions it takes that do have an effect 
(e.g. storing accounting) are not taken again, and it seems obvious it 
needs to answer the same thing, but this could be "reconstructed" rather 
than cached.

BTW, all of this really raises having a "Diameter transport" part that 
would really be like TCP over multiple TCP hops :-)

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 29 Jun 2001 06:03:39 -0700

> If it's an request you already answered to why just not drop it?

because if you've received the request again, chances are the answer got
lost (perhaps a proxy or relay became unreachable). So, you need to send the
answer again, and have two choices:

1. process the request, but make sure that the dup request doesn't cause 
   the user to be allocated additional resources (e.g. two concurrent sessions)
2. queue all answers for n seconds. Simply return answers when a dup request is
   received.

> encounter the problem less often.

the e2e I-D still has 2^128 possible values, so that alot of requests. If we
want a windowing system, then monotonically increasing is the only way, but
random (and unique within the last 128 requests) works too. Seems that the
former may be simpler to implement.

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 29 Jun 2001 16:32:22 +0200

>-----Original Message-----
>From: Pat Calhoun [mailto:[email-masked]]
>Sent: den 29 juni 2001 15:04
>To: Fredrik Johansson
>Cc: Mark Eklund; Jacques Caron; AAA Listan
>Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier
>
>

Ok, I'm convinced :-)

>former may be simpler to implement.

Ok, so can we agree on a monotonically increased identifier, then it is up
to the implementor if you want to use the windowing technique or not.

/Fredrik

---

From: Paul Funk <[email-masked]>
Date: Fri, 29 Jun 2001 12:01:35 -0400

The problem with a window for End-To-End Identifier is that any individual 
server will not get sequential requests from a client. The client talks to 
many servers, and a home server may receive two sequential requests from 
the same client with End-To-End Identifiers that are not sequential, not by a 
long shot, because that client was talking to other servers in between. So a 
window can't possibly work.

Paul

>to the implementor if you want to use the windowing technique or not.

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 29 Jun 2001 09:22:06 -0700

> window can't possibly work.

you are correct.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Sat, 30 Jun 2001 16:44:47 -0700

so is the only solution to make this value pseudo-random, and make sure that no
two packets can be sent with the same id within a period of time, or just make it
monotonically increasing, and not worry about windowing?

PatC

---

From: Paul Funk <[email-masked]>
Date: Sat, 30 Jun 2001 21:40:16 -0400

Pat, 

I think the text that describes how to generate Hop-By-Hop Identifier and 
End-To-End Identifier should be the same -- that is, an identifier should be 
locally unique for the long enough past the lifetime of a transaction to 
prevent any ambiguity. How this is done is up to the sender, and there is 
no requirement that the numbers be increasing, though the obvious way to 
achieve this is to initialize the value in an intelligent way on reboot and 
increment from then on.

The identifier can be initialized randomly at reboot, but there is always the 
risk that identifiers from before and after reboots could clash. That's okay 
for Hop-By-Hop Identifiers, because when the connection goes down all 
the pending transactions are dropped anyway. With End-To-End Identifier, 
it's more problematic; the only way the server can disambiguate two 
equal identifiers is by consulting Origin-State-Id, but that is not a required 
attribute.

Here's an algorithm for generating an initial value for an identifier that 
guarantees uniqueness across reboot:

Initialize the high order 12 bits of the identifier to the low order 12
bits of the 
current time, and initialize the low order 20 bits of the identifier to 0.
This is 
guaranteed to produce unique identifiers across reboots provided that:

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).

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]