Re: flow label demultiplexing

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

Iljitsch van Beijnum wrote:

> > Well, there could packets with the same src and dst address, that 
> > belong to different communications with different ULIDs, right? the 
> > flow label is to determine the proper demux context.
>
>
> Under what circumstances would having different associations between the 
> same source and destination locator sets be necessary and/or useful?

Presumably we can't assume that the shim will control which ULIDs are 
selected; some upper layer like the application or transport protocol 
will in many cases select the destination ULID, and perhaps also the 
source ULID.

Hence the shim needs to be able to deal with the fact that between host 
A and host B, one or both of them having multiple ULIDs, there might be 
communication which uses different ULID combinations.

When the communication is established, we don't know the equivalence 
sets for the remote hosts.
For instance, host A might establish communication with www.foo.example 
and www.bar.example, each having different IP addresses in the DNS (B 
and C in this example), but the IP addresses might be handled by the 
same peer host.
In such a case there is no choice but to (initially) have different 
associations for the different ULID combinations. Once A realizes that 
the locator sets are common (or at least partially overlapping) for B 
and C, it could potentially merge those into the same context to save on 
the "test" traffic, but it would still need to retain the separate flow 
labels so that the receiver knows which packets need to have which ULIDs 
when they are delivered to the upper layer protocol.
So I don't think such merging makes the demultiplexing any easier.

   Erik