[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Flow label versus Extension header - protocol itself
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
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.