Re: Flow label - the problem

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

El 21/04/2005, a las 13:33, Iljitsch van Beijnum escribió:

> On 21-apr-2005, at 13:11, marcelo bagnulo braun wrote:
>
> > > But it's not just the overhead. The problem is that adding bytes to 
> > > the packet increases the work that must be done per packet. This is 
> > > also very bad.
>
> > Ok, no arguing that extra overhead is bad, but keep in mind that the 
> > overhead is only cause when there is a rehoming event i.e. that the 
> > locator being carried is different from the ULID of the session.
>
> You still need to work your way through each packet to see if there is 
> a header, so it's still bad even if the header isn't there...

what Brian said...


> > > As I said before, the only thing needed to make the flow label 
> > > usable for this, and without taking away from its other uses, is 
> > > avoid reusing flow labels for sessions with an unknown shim6 status.
>
> > Not sure if a agree here.
> > I mean, are you cosnidering the case where new locators can be added 
> > after the context has been established?
>
> In general: yes. There may be some corner cases, though. Are you 
> thinking about the situation where a locator that first belongs to one 
> host later belongs to another host?

No, this is not what i was thinking about (even if this situation seems 
also to describe a valid situation that Brian depicts), but i was 
considering the situation where a locator initially belongs to one 
session and then the same locator is added to a different session. see 
details below...

> > I mean, the requirement is to verify that those context that have 
> > intersecting locator set use different flow id values.
>
> How can different associations have overlapping locator sets?

Ok. Consider this situation

We have a host A with 4 addresses: IPa1, IPa2, IPa3 and IPa4 and host b 
with 2 addresses (to keep it simple) IPb1 and IPb2
Now a communication between these two hosts. The shim context between 
host a and host b has IPa1 and IPb1 as ulid and, because whatever 
reason (policy, efficiency) host a decide only to include on 
alternative locator in the context, say, IPa2 and host b does not 
include any additional locators. At this point, the context 1 between 
host a and host b has: ulids: IPa1 and IPb1, locator set for a: IPa1 
and IPa2, locator set for b IPb1.

Next another communication is established between host a and host b. 
Because the application is the one that chooses the ulids to used, 
let's consider the case that the ulids used for this new context 2 are: 
IPa3 and IPb2. Again for policy reasons, host a decides to include only 
one additional locator in the context, IPa4 and host b does not include 
any additional one. At this point, context 2 has IPa3 and IPb2 as ulids 
and IPa3,IPa4 as locators for host A and IPb2 as locator for host b

This basically means that they could eventually use the same flow id, 
because there is no overlapping between the locator set of the 
different contexts.

Now what happen if host a decide to include IPa3  and host b decides to 
include IPb2 as an alternative locators in context 1? basically, the 
locator set of context 1 will overlap with the locator set of context 
2, and packets carrying addresses IPa3 and IPb2 cannot be demultiplexed 
right?

(note: i agree that this situation may not be very likely, but still i 
guess it is possible)

The harm here is that one of the locators will not be accepted i.e. 
node b won't try to include IPb2 in context 2, i guess.

> > so if you are assuming that we have an static set of locators, then 
> > this is easy, since you can verify it when the session is 
> > established.
>
> > However if you assume dynamic locator sets, then this is simply 
> > impossible, since you cannot possible verify what will happen in the 
> > future i.e. if some of the locators included in one context won't be 
> > later on added to another context that has the same flow id value 
> > associated.
>
> But the problem only exists when we have communication with the 
> locator in question beforehand. So what would have to happen is that 
> there is shim6 communication between two hosts, but there is also 
> communication from one host to a locator without shim6, and then that 
> locator is bound to the existing shim6 association. I agree that this 
> can happen, but only for a very limited time: either the 
> shim6-agnostic session will start up shim6 negotiations, or the 
> existing association will add the new locator.
>
> In other words: sessions move out of the state where their flow label 
> can't be reused for other sessions fairly quickly because either they 
> turn out shim-enabled and then we know the set of locators for which 
> the flow label must remain unique, or they turn out shim-incable and 
> the flow label can be reused for any other destination address.

see the example above, i don't think this is only related to the case 
where there are non shim communications...

regards, marcelo