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

From: Paul Funk <[email-masked]>
Date: Thu, 28 Jun 2001 14:18:28 -0400

Fredrik,

I think there's some misunderstanding as to how the End-To-End Identifier 
is used.

The End-To-End Identifiers are, by definition, not hop-by-hop, so there's no 
guarantee that a server will receive them in any particular sequence. A server 
may get messages wildly out of order from the same client, because they are 
routed through different proxies.

My understanding of how it's supposed to be used is this: A server would 
keep a cache of answers by Origin-Host + End-To-End Identifier. If a 
new request arrives that's already in the cache, instead of processing the 
request normally, it just sends back the same answer. How to manage 
(or whether to even provide) such a cache would be implementation 
dependent.

The problem this solves is that if a proxy goes down, pending requests will 
be rerouted to another proxy. The home server will thus receive two identical 
requests in unknown order; that is, it can't tell which request came over the 
good path and which came over the bad. Therefore it should respond to both 
identically.

I do think that the language for End-To-End-Identifier should mirror more 
closely the language for Hop-By-Hop Identifier, to indicate that it is 
typically randomly initialized and incremented, etc. But it need not be 
monotonically increased and there can't be a window.

Paul

At 06:31 PM 6/28/01 +0200, Fredrik Johansson wrote:
>Submitter name: Fredrik Johansson
>Submitter email address: [email-masked]
>Date first submitted: 28-Jun-2001
>Reference:
>Document: base-06
>Comment type: T
>Priority: S
>Section: 3.0,
>Rationale/Explanation of issue:
>
>The end-to-end identifier is not monotonically increasing, thus it requires
>a server to save all identifers on a per host basis to be able to see if the
>message has been received before. Some describing text is also missing on
>how a server should treat a message that it has received before.
>
>Requested change:
>
>Make the e-2-e identifier monotonically increasing and suggest that the
>server stores the identifiers in the same manner as done in AH (section
>3.4.3 in RFC 2402) but with a suggested value of 128 as default window.
>
>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.
>
>/Fredrik

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

---

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

Paul,

see comments below
/Fredrik

>-----Original Message-----
>From: Paul Funk [mailto:[email-masked]]
>Sent: den 28 juni 2001 20:18
>To: Fredrik Johansson; Mark Eklund; Jacques Caron
>Cc: [email-masked]
>Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier
>
>
>Fredrik,
>

I'm aware that the e2e identifier is from the origin host and that it can
not be guaranteed to be received in order, that's why I believe that it
would be easier to keep a caching window of monotonically increased numbers
(you can even make the implementation smart and store sequences of received
e2e identifiers in the window). If the identifier is monotonically
increasing it makes it easier to maintain the window.

By keeping a window you limit the number of e2e identifiers that you need to
save, if you receive something the the left of the window you have to try to
figure out if it can be a new request (wrap around on the identifier) or if
it's a old request. A new one is ofcourse processed and a old is discarded.

>(or whether to even provide) such a cache would be implementation

By host I mean Origin-Host. Why do you have to send back the same answer, if
it something you already processed once you'll have sent an answer. And
since we have reliable transport we should be able to assume that it reaches
the Origin-host of the request. The windowing mechanism can be made
implementation specific, however a monotonically increased identifier makes
it easier to optimize such a solution.

Is it reasonable to save all answers for all clients for all e2e
identifiers?!? That'll take alot of memory

>monotonically increased and there can't be a window.

Ok, there doesn't have to be a window, but somehow you probably would like
to limit the amount of memory taken in your implementation and a window
would do that.