[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: flow label demultiplexing

On Mon, 18 Apr 2005, Iljitsch van Beijnum wrote:
Now, multihoming context is exchanged.

After that, the host tries to establish a new flow from 2001::1 to 2002::B2; unless there is reservation, it could end up picking "1" as well, which could create issues when either 2002::B1 or 2002::B2 fails because the flow labels overlap.

Hm this isn't how current implementations work. They pick a more or less random flow label for each new session. This is encouraged because it makes for better hash bucket utilization in boxes that want to do something useful with the flow label.

Sure. But the spec allows incremental assignment of flow labels in addition to a random process; heck, even recommends it. It just recommends that the start of the counter is randomized at startup.

However, there's still a MUST requirement that the flow label must not clash with existing or recently used ones. So, you can't just randomize and hope it's OK. (I'm not sure if implementations check this.)

For multihoming, we would probably want to use the same flow label instead in order to reuse a previously established context. If having all sessions between two hosts use the same flow label is undesirable, it may be necessary to tie the multihoming state to ranges of flow labels rather than a single one...

My assumption definitely is that requiring all the communications between two shim6 hosts use the same flow label is a non-starter (if not otherwise, but that would eliminate all other use of flow label on those hosts). This isn't stated explicitly in the document, so maybe it should be.

However, what I was assuming is that if the flow label is used, it would be used to make sure sessions are uniquely identified across the locator sets, so that by knowing the locators, you'd know whether an incoming packet should be mapped to an existing context or whether it's a new session.

Of course, there is still a race condition between the communication is established and the multihoming context is set up -- there's no way to do the reservation for destination locators before you know which ones they are.

Ok so you're saying a user visits a website at www.ietf.org and the html links to an image on images.ietf.org, both have addresses 2001::1 and 2002::2 and due to DNS load balancing the session to www uses 2001::1 and the one to images 2002::2. Then, when the sessions are set up with the same flow label for each, the shim does its thing and...? The sessions will be merged into a single association so there isn't a problem, I'd think. Rather the opposite: normal behavior would 99.9999% (yes I counted the nines) sure result in two different flow labels but now there is one association with two flow labels... But that shouldn't be too problematic.

In any event, you wouldn't want to reuse the same flow label any time soon irrespective of the addresses.

No, I'm worried about the contrary -- that the demultiplexing host thinks a packet belongs to a context, and demultiplexes it there, but it actually doesn't, and results in the corrupted data (e.g., with UDP) or maybe a TCP reset.

So, AFAICS, you can't just "merge" different sessions between two different hosts.

However, I would be interested in hearing if you have ideas what the protocol should do after narrowing the flow label down to 3 or 4. How does it disambiguate further from those 3 or 4? Would you rely on the implementation taking a peek at (say) layer 4 headers or some other information? 

There are two obvious options:

1. The flow label is relevant regardless of the addresses: this can't work because of the possibility of clashes with flow labels in unrelated packets

2. The flow label is only relevant with certain source/dest address combinations: but what's the additional benefit of the flow label here, we can demultiplex on the addresses

I guess the only way the flow label could be useful is as a last resort to correlate packets with unknown addresses to existing sessions. But this is insecure, so we need to trigger some kind of negotiation to get to know the unknown addresses. This could still be somewhat useful because if we're 99% sure who we're talking to we can do a one RTT challenge/response rather than something more involved.

I don't think these help in narrowing the flow label down further. My assumption (as I tried to describe) is that option 1 is definitely out.

For 2, I have different assumption. I'd assume that in most cases you actually _do_ know the source/dest address combinations; i.e., every shim6 host, when the context has been exchanged, keeps track of all the locators of the peer. Flow label is just used to disambiguate between the separate sessions between these combinations.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings