[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
- 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=22.214.171.124, srcport=1, dstport=2, dst=126.96.36.199
src=188.8.131.52, srcport=1, dstport=2, dst=184.108.40.206
.. 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