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