Re: Flow label versus Extension header - protocol itself

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Erik,

Erik Nordmark wrote:
> 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>.

Well, it could even be before failure, so long as it's on a
different path.

I agree though.

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

Fair enough.  The main value of retaining the flow label F1 though,
is for applications which are interested in flow identification.

In the distant future, if someone returns to a path they've not visited
there's not going to be any retained state in the routers.

It doesn't seriously harm things to retain the flow label for that
pair of <source,dest,flow> triples.

> 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.)

I was talking with Marcelo on this before, and he seemed less interested
in non-unique labels (comments Marcelo?).  I think was largely an issue
if the label could be moved to a new source address before signaling
started.

> 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.

The main thing I guess is that it doesn't break any existing flows while
the flow remains on the original path.

Greg