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