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..