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

Re: flow label demultiplexing

Pekka, just one comment on this:

1. allocate a new flow label for all new communications immediately 

If you read RFC 3697 closely, you will see that in effect the definition
of a flow is "all packets carrying the same {flow label, srce, dest}".
That is: a flow is whatever set of packets the sending host chooses to
label as a flow. So your statement quoted above is a bit wrong; it
should be

  1. allocate a new flow label at exactly the same time as would be
     done in the absence of shim6.

In fact what you are doing is extending the scope of uniqueness
of a flow label from {srce, dest} to {{srce locators},{dest locators}}.

   Brian


Pekka Savola wrote: 
Hi,

Now that the charter bashing has quieted down, some technical discussion... I've read through the drafts again, and I have some high-level comments; I'll send a couple of them this week or so.

The first is demultiplexing, especially based on Flow Label.

First, one specific comment:

   An added limitation imposed by this approach is that all the
   potential source and destination locators have to be known beforehand
   by the receiver in order to be recognized.

==> I don't understand why this is a limitation in practice (though it may be an architectural limitation). Isn't the assumption that all the potential locators must be exchanged somehow before the network connectivity failure, otherwise the shim6 solution might not be able to switch to working locators? Otherwise the rehoming could not be secured...

....

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?

   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?

   If this approach would be used, it would just mean that if you had
   communicated recently to host X, and host X would soon afterwards be
   added to a locator set, you could not use shim6 to do connection
   survivability to host X.  This doesn't seem too awful a tradeoff..

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

 - demultiplexing just using the flow label (and not also source
   locators) is a non-starter, because then anyone would be able to
   inject any kind of packet to a particular data stream just by being
   able to pick the right flow label (and not having to even spoof the
   source address).  Requiring that the source address is one of the
   previously communicated locators mitigates this greatly.