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

Re: Flow label - the problem

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

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?

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?

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.