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

Re: flow label demultiplexing -- worst cases

On Wed, 20 Apr 2005, Brian E Carpenter wrote: 
 - in step 3. above, an implementation could also perform two-tiered
   reservation: first reserve the flow label for any communication,
   but when in the danger of running out, start using it also for
   those destinations that don't belong to the locator set.  This way
   this would not be an issue (albeit difficult to debug) until the
   hosts are so loaded that they're running out of the flow label
   space for their sessions.


seems the reasonable choice if the flow id approach imho


Agree. In any case, I think the worst case result here is that
we trigger an unnecessary rehoming event because two flows
get overlaid somehow inside the shim6 state machine. Probably the
state machine description will need to cover this case, even though
it will be very rare.

It isn't clearly obvious to me that this is the worst case (and what the other cases are), so this needs to be analyzed.

Potential cases might be (all of them not applicable here, but in general with demultiplexing):

 - rehoming between the particular IP addresses [part of a past,
   present or future locator sets], possibly for a specific flow, does
   not work
 - the session is rehomed and re-mapped, but the packets are
   demultiplexed to an unrelated flow, causing data corruption,
   retransmissions or resetting of the session
 - unncessary rehoming event

....

Speaking of rehoming and remapping... it could also happen (unless there's something in the transport protocols that prevents this kind of reuse) that the source and destination would have two identical flows, just between different IP addresses (but with the same protocol and port numbers). That is,

 src=1.2.3.4, srcport=1, dstport=2, dst=4.5.6.7
 src=1.2.3.5, srcport=1, dstport=2, dst=4.5.6.8

.. now if one of the source addresses fails, and you end doing remapping, I wonder how different forms of demultiplexing deal with this case as well..

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