Re: Flow label versus Extension header - protocol itself

[Erik Nordmark <erik.nordmark@sun.com>]

Greg Daley wrote:
> The original assumption was that flow labels (in general, rather than in
> shim) would be sender selected.  Marcelo has mentioned that there may
> therefore be pre-shim flow labels in existence at negotiation time.
>
> I think it will be possible to accomodate these pre-existing labels
> for the path between the original source and destination while still
> allowing receiver selected flow labels for all other paths (and maybe
> replace the original label on the home path after flow state timeout).

This is an interesting suggestion. I don't think there is anything which 
prevents using a different flow label for the communication between ULID 
A and ULID B, and the communication that is using a different locator 
pair, but is part of the same upper layer communication. Any devices on 
the paths would need to identify the flow based on <source locator, 
destination locator, flow label>, thus when the shim switches to a 
different locator pair, if an explicit flow signaling protocol is used, 
it would need to signal something along the new path.

So I think we can make it so that the hosts start communicating using 
the ULID pair A, B, and a flow label F1 (which could be zero; it isn't 
used by the shim, but the shim preserves it e2e).
Thus F1 is sender allocated as today. (And for the packets from B to A, 
B could have picked flow label F2.)

When the shim sets up the context, then each receiver allocates a 
separate flow label, and uses this to identify the shim state.
Thus B would allocate F3 and send it to A, and A would allocate F4 and 
send it to B.

When the ULP sends packets from A to B before a shim failover, the 
packets have
	source locator A1
	destination locator B1
	flow label F1

After a failure, the shim would send packets with replaced values
	source locator A2
	destination locator B2
	flow label F3
and the receiver would use this to find the context state, so that the 
packet is passes to the ULP has <A1, A2, F1>.

I don't think it makes sense switching from F1 to a different locator 
for the "main" path as you parenthetically suggest, though.

The benefits of this hybrid is that the flow label that is used to 
identify the shim state can be receiver allocated, which means that the 
receiver can easily ensure that the flow label uniquely identifies its 
context state (for all its current and future locators). Thus the 
receiver might only need to lookup <destination locator, flow label> to 
find the context state.
It might even be possible for the receiver to reuse flow labels for 
different senders, because the context state setup can exchange the 
unique ids that Iljitsch suggested recently. (But in such a case, the 
receiver needs to use the source in the lookup.)


The only difference between this and using the same flow label for the 
communication before and after the locator switch, is a slight change 
for explicit flow signaling protocols. In either case, initially the 
signaling protocol setups flow state for <A1, B1, F1> (and <B1, A1, F2> 
for the reverse path).
If we use the same flow label, then after a locator switch, the 
signaling protocol needs to signal <A2, B2, F1>.
If we use a different (receiver allocated label), it needs to signal 
<A2, B2, F3> instead.
Doesn't seem like a big difference to me.

   Erik