[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Flow label versus Extension header
marcelo bagnulo braun wrote:
I mean, do you think that if context tag values are repeated across
different context, based on the fact that locator set of the peer are
disjoint, receiver based context tag allocation can guarantee proper demux?
I mean, as i see it, when we are handling dynamic locator sets, the only
option to guarantee proper demuxing is to solely rely in the context tag
i.e. not include the addresses in the demux operation.
This isn't the only option. With receiver-based tag allocation, then the
receiver can choose which locators it advertises for which contexts.
For instance, a receiver can have multiple locators in each prefix and
keep them separate. So {P1:X, P2:Y} can use tag=1 and be associated with
one context, and {P1:Z, P2:W} can use tag=1 and be associated with a
different context.
Of course, if the host doesn't do this, then it can assign the tags to
that it never needs to look at the locators in order to lookup the context.
Because if we
inlcude the addresses in the demux, and we have repeated context tags,
it always may occur that we end up with two contexts that have the same
context tag (because we are using repeated context tags) and with the
same locators (because they were added after we assigned the context
tag, allowing to assign the same context tags initially, because
initially the context tags were disjoints)
So, as i see it, the easier mechanisms to guarantee proper demux is to
assign unique context tags and demux only based in context tags (not
consider the addresses). Moreover, in order to guarantee this
uniqueness, the simplest way is probably to use different context tags
for each direction and to perform receiver based context tag allocation.
and finally because of the expected number of sessions, probably we need
a bigger field than the flow label in order to guarantee uniqueness of
the context tag.
I would say that this is the simpler approach. I may not be the most
efficient though.
I agree it is simpler.
One could augment it with the receiver ability, when the peer wants to
add locators to the set, to be able to refuse the addition (due to a
potential conflict).
If that mechanism is present then the receiver can ensure that a tuple
<src locator, dst locator, tag> always uniquely identifies one shim
context. It is't clear to me what tag allocation algorithm the host
would use to maximize the utility of such a scheme. When the allocation
is done, the host has been told the (initial) set of locators for the
peer, so it could at least verify that there isn't overlap between
those. So we can handle overlap in the initial sets that the peers send
in the context establishment, and we can handle dynamic locators, but
the host would have to refuse when a the overlap is due to the dynamic
addition locators by the peer.
I don't know if this provides good enough benefits.
Erik