Re: Flow label versus Extension header

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi Erik,

El 24/04/2005, a las 5:19, Erik Nordmark escribió:

> marcelo bagnulo braun wrote:
>
> > Any additional considerations?
>
> I think there are some considerations related to when and by whom the 
> value is allocated.

good point

> The flow label value would be allocated by the sender before sending 
> the first packet to the peer.

i think i agree but i would like to confirm why is that so.

This would be so because once the communication is initiated, the flow 
label value cannot be changed. And this is so because other usages 
related to the flow label (i.e. not becuase the usage of the flow label 
by the shim) Is this correct? I mean, if the only consider the usage of 
the flow id in the shim context, the flow id label could be changed 
during the context establsihement so we would be in a similar situation 
than in the context tag, right?

> A context tag carried separately doesn't need to be allocated until 
> the context is established. This allows the receiver of the packet 
> (carrying the tag) to do the allocation (and pass it to the peer as 
> part of the context establishment).
> The receiver-based allocation has the benefit that the receiver can 
> make sure that the tag (either by itself or in combination with the 
> destination locator) will uniquely identify the context even if the 
> receivers set of locators change in the future.


Not sure why is that...
I mean, first of all, the receiver based allocation can allow the 
receiver to make sure that the tag by itself will uniquely identify the 
context _for the receiver_... i mean how the receiver can be sure that 
the context tag was not already in use by the initator in another 
context?

Second,  are you assuming that at this point the receiver know all the 
locator set of the initiator? are you assuming the the locator sets are 
static? Becuase if the locator sets are dynamic then i think that no 
one can be sure that the locator sets won't overlap in the future...

Actually, for me, the benefit of a context tag carried separately is 
that it will probably have more bits, and we won't ran out of them

> One additional thing we haven't discussed much yet is that there can 
> be a different flow label or context tag for each direction, and that 
> each end needs to be able to uniquely find the shim state based on 
> both the flow label/tag and locators the *peer sent* (for normal 
> reception), and the flow label and locators *it sent* itself (to be 
> able to demux an ICMP error to the right context).
> I haven't figured out how this can be handled, nor whether the flow 
> label (and sender-based allocation) or a context tag (with potential 
> for receiver or sender-based allocation) makes any difference.

Well, imho, the context tag is used to demux incoming packets. So, it 
must uniquely identify packets to the receiver. I guess that the 
context tag of outgoing packets can be set to any value by the 
transmitter i.e. it doesn't affect the transmitter.

So, i guess that the best option from this p.o.v. (and also probably 
the most complex one) is to perform receiver-based context tag 
allocation independet for each direction of the communication. This 
means that each side of the communication informs the other side which 
context tag must be used to send packets.
i.e. Host a informs host b the context tag that host b must use when 
sending packets to host a
and Host b informs host a the context tag that host a must use when 
sending packets to host b

There are then two context tags, one per direction and each one is sure 
that this context tag is not used for any other incoming communication. 
The problem occurs when we ran out of context tag values. This can be 
the case if using flow id, while i don't think this is an issue for an 
alternative context tag.

Regards, marcelo


>    Erik