[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Flow label - the problem
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
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
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
(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
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
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...