Hi Pascal,
this is a great list of items.
I'll try to explain my current thinking.
> I think we need to define context and usage in the architecture
> document, not in HC.
Right. HC just needs to assume that there *is* a way the contexts are
established between sender and receiver of an L2 packet. HC doesn't
really care what the protocol is that establishes them (except, if
it's not there, contexts can't be used). Right now, my working
assumption is that the optimized ND will fill that gap.
We cannot, however, ignore the likely properties of that context
establishment protocol (let's call it CEP for now to avoid the
question whether this is done in ND or elsewhere); I'll say some more
about this below.
> Now, there's this recurrent question about how many contexts and what
> they are for:
> - It is very hard to know how many we need if we do not know what
they
> are for in the first place.
Right. In broken record mode: To go from gut feeling ("640K should be
enough for everyone") to a better (and common) understanding, we need
to agree on an example/a benchmark. See my message from Jul 31.
(Continuing out of order:)
> There could be a number of those babies, thus the number 16.
The specific number should be decided when we know the trade-offs.
In the original CBHC draft, I proposed 16 because I conflated the
prefix length with the context number. I haven't heard any support
for that idea. So maybe we need fewer than 16. See below.
So:
> - a context entry contains a prefix and a prefix length. Length can
be
> 128.
Yes.
It might also contain information about what is going to provide the
remaining bits: Are they going to be in the header or are they inferred
(e.g., from L2 addresses)? Of course, that information can also be in
the header itself as separate bits, but this may be less efficient.
Note that the same prefix can be used beneficially in both these modes.
(We also need to decide how padding works if the bits in the header
can be non-multiples of 8 in length.)
Now, what is the cost of having too many contexts?
-- Assuming that the prefix length is part of the context state, the
cost of a context is: up to 16 bytes for the actual value, one byte (7
bits) for the prefix length, and one or two bytes for state
management. Providing space for 16 contexts thus would mean that each
node would need to reserve up to ~300 bytes of context state, a value
high enough to merit some further discussion.
-- The context ID needs to be encoded in the context-referencing
header, once for each address. Since we probably also want to
minimize complexity from variable-length and/or arithmetic encoding,
supporting 16 contexts needs expending 2x4 = 8 bits.
-- Of course, there is also a cost in state management. 300 bytes
don't fit into one L2 MTU, for instance, possibly increasing the
number of L2 packets needed for CEP.
What is the cost of having too little contexts? Lost opportunities
for compression (or, possibly the need to go for less compression
where more would have been possible).
> - if a node can not support as many contexts as the edge router
> requires, we can hope that it does not need them.
>
> - nodes should advertise how many contexts they can support max as
they
> attach to a router (ND)
Hope is not a strategy, and not a protocol either :-)
If we allow heterogeneous context state within an area, we'll need to
establish state between sender and receiver, whether with an explicit
bilateral CEP or by storing per-peer state from error messages.
I don't think we want to do this, so I would propose to go for
homogeneous context state.
> - It is the edge router responsibility to maintain the contexts in
all
> nodes. The contexts are distributed by the edge routers through a
new ND
> option that the ND draft introduces, valid in RAs and Router
> Registration Confirmation.
As I said, I'll call that "CEP" for now (but I do expect this to be
part of optimized ND and to be controlled by a designated node such as
an edge router).
So:
> - which context and how many there are (up to 16) is under the
> responsibility of the edge router (config, radius, ...)
Yes ("designated node" for this message).
> - Another question that is not answered if the scope of a context.
> [...]
> - the scope of a context is the set of devices attached to an
interface
> of that edge router. That is, it is guaranteed that entry 7 will
means
> the same for all nodes attached to a same interface on a same edge
> router.
I'll skip the issue of what "attached to a same interface on a same
edge router" means and just call these scopes "areas" for now.
So, again, I'd agree and try to get homogeneous context state for an
area. The assumption is that a node knows when it enters an area and
can then use a CEP (i.e., ND) to establish the context state for this
area. I also assume there will be other state associated with an
area, so running a CEP is not going to dominate the cost of
e.g. mobility.
It also makes sense to assume some relationship between the area and
address configuration information (such as prefixes used for stateless
address configuration).
> What we have today:
> - The Current version of the HC WG doc uses contexts for anything
> stateful
> - The Current version of the HC WG doc enables up to 16 contexts.
>
> Following the current HC assumptions, a context can be used to
compress
> anything down to /128. As Carsten mentions down here that includes
> remote prefixes; and it also enables to fully compress a number of
much
> used addressed such as the application gateways and servers that the
> nodes publish to.
Yep, but see above for the remaining bits.
Finally, I don't really know what these of your points mean:
> - An edge router might use the same table on multiple interfaces.
>
> - For transparent mobility, it is allowed to have a common context
table
> across the subnet
Let me comment that "mobility" can be intra-area mobility (which is
nothing but a routing change, so can be ignored here) or inter-area
mobility (which requires reconfiguration anyway). Which one do you
mean?
> - entry 0 is the edge router global address
We can always decide specific meanings for specific contexts, but I
don't know what "the edge router global address" is and how a node
would know it.
> - the router should store that in it ND cache and expand any address
> that the node can not understand
In route-over, all nodes are routers, so I don't understand.
> - an new ICMP can be introduced to reject an unknown entry.
I explained above why I don't like relying on this for normal
operation, but it's certainly a good idea to provide some diagnostic
capability.
So, thanks again, Pascal, for creating a good outline for discussion!
Now, back to that number 16:
I'm assuming that CEP will be extremely lightweight (not two-phase
commit or some such :-). So whenever the context state for an area
changes (and my assumption is that there is a need to allow it to
change), there will be contexts for which some nodes in the area have
new state and some are still on the old state. The CEP, of course, is
designed to converge, so the assumption is there is a point in time
when the new state actually can be used. But way before that point,
nodes need to find out the new state while knowing they can't use it
yet, and they need to stop using the old state.
So, I think each context can have one of the following states:
00 unused (do not use, do not accept)
01 in introduction (do not actively use, but remember the state)
11 in use (i.e., nodes assume all other nodes know the state)
10 in deprecation (do not actively use, but remember the state)
(01 and 10 are very similar in the way a node should handle them, so
it may be possible to combine them in CEP's encoding). 00 does not
have a value associated; the other three need a value and each node
needs to allow receiving headers referencing the context: 01 in case
another node switches to 11 earlier and starts using the context, 10
in case another node hasn't got the memo and still thinks the context
is in 11 state. This is also the reason a context can't be in 01 and
10 at the same time (i.e., cannot simply get descructively updated
with a new value): a receiving node would not know whether to apply
the old or the new value to a compressed header. (This can be solved
with any number of methods like generation numbers etc., but this
creates complexity and needs even more bits.)
So if we assume a transition time Tt within which a designated node
can update an area to new values with a level of probability deemed
acceptable, each specific context can be useless for 2*Tt, requiring
the use of another context number if continued context-based
compression during a transition is desired. This is the reason why we
may need more potential context values than any static context state
configuration might suggest. How many, of course, depends on our
model of the dynamicity of the context state, which is (broken-record
mode) the reason we need benchmarks to finish this discussion.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
