[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: identity persistence and comparison issues


El 24/06/2004, a las 1:28, Erik Nordmark escribió:

Now, the initiator may not need to have such a stable identifier, since
the initiator does not receive communications. what the initiator needs
is an identifier that is stable during the communication lifetime so,
if the locator change, the identifier is maintained so it is the
communication. 

I agree in principle, but I'm concerned this is a theoretical
observation because I don't think we can build systems that
know what the lifetime of the communication is.

It is true that in many cases "communication lifetime" = "TCP connection
lifetime", but if we build solutions assuming this then they will
fail for the cases when the equality doesn't hold; whether the
communication consists of UDP traffic, referrals, callbacks, or just
multiple TCP connections between the same nodes.


I agree


However, i wonder if this issue is not more general and it is not limited to only ephemeral ids proposals

(not considering the refferral and call back cases here)

I mean, in any proposal that manages bindings between multiple locators that can be used to reach a single endpoint, you need some state in the endpoints about the binding. This state has to be preserved as long as the communication exists, and some garbage collection mechanism is needed to delete this state after it is used.
As you mention, the wedge layer does not have knowledge about the apps still need the binding state, so how do you know when to delete it?

For example, how does this work in the hip case?
a node A starts a communication with node B, so the node A obtains through the DNS the HITB and the locators of node B
Node A then generates a state that maps HITB with the set of locators associated with the node B
Now how long this state is preserved in node A? and how does the node A knows when to delete it?
I mean, perhaps there is an app that has been quiet for a long time and wants to continue the communication afterwards, what happens if the binding information between the HITB and the locators have been deleted? in HIP this is even more difficult because there is no way to obtain the set of locators from a HIT...

I guess that the solution would be to use very long garbage collection times, but as you have mentioned sometime before, this approach may introduce some additional danger and it clearly does not guarantee that all apps will be satisfied

am i missing something? Any ideas?

regards, marcelo

One could argue that the application should inform the "stack" about
the lifetime of the communication, perhaps by defining some new "open"
and "close" APIs, i.e. getting close to defining a session layer.
But my gut feel is that this requires more changes to the applications
than is warranted.

Erik