[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:
All the approaches listed in demultiplexing based on flow label appear to have issues. It was not clear to me which approaches were really put forward and which were clearly rejected.

When looking at different alternatives, this is what I had in mind which could work up to a certain degree: 

  1. allocate a new flow label for all new communications immediately
  2. when setting up the multihoming context, keep track of all the
     potential source and destination locators
  3. flow label used by the created (src,dst,flow) in 1. is reserved
     so it can't be used for any communication to any destination
     locator *in the set*
  4. when switching to new locators, use the same flow label
  5. when demuxing the packet, the demuxer knows which locators can be used
     as source or destination, and use the flow label for demuxing.


This has a couple of generic issues:
 - what if the same flow label is used for some other address, and that
   address later gets added to this locator set?

I'm not sure if I understand. Can you give an example?

Brian made a good clarification already, but let me try because the bullet point I wrote above is very confusing.

First off, let me try to describe the main idea:

Host A has locators 2001::1 and 2001::2. When it establishes communications to B, it uses 2001::1 as source and 2002::B1 as destination locator (and 2002::B2 is backup). That communication uses flow label = "1".

Now, Host A (and presumably, also B depending on how it allocates flow labels) marks flow label = 1 as reserved for ({2001::1,2001::2},{2002::B1,2002::B2}). Normally, the flow label implementation either doesn't do reservation at all or would just mark (2001::1,2002::B1,1) as reserved.

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.

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.

The problem I was referring to above is that caused either by that race condition.

[Note that for our purposes, the destination address is irrelevant as presumably, it can be any of our addresses and we already know who we are. The only thing we care about is source + flow label.]

   This is better than nothing; the alternative is to do flow
   label reservation ("*,*,flow"), but that results in running out of
   flow labels with a high number of flows.  Or would that be an
   acceptable tradeoff?

The question is whether we absolutely, positively need to be able to determine which association a packet belongs to based on addresses and the flow label, or that it's just a very good guess that may turn out wrong in later steps. I.e., the machine may have 1000 sessions open, and being able to narrow down which session a packet belongs to by looking at the flow label to two or three of those is probably good enough. If so, then having the source cycle throough the entire flow label space without even managing collisions with existing sessions would be enough. 

This is a good point, and I don't recall seeing it in the draft.

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?


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