Locator Pool Reference ID

[Dave Crocker <dhc@dcrocker.net>]

Private, Ephemeral ID Granularity
---------------------------------

If we assume that a context between two endpoints can be labeled
privately by them, as several proposals now do, there is a question
about the desired granularity of the ID.

For MAST, I've been having one pool per peer host context. This is
clearly inadequate for the long term. There are circumstances needing
more than one pool, such as to differentiate preferred locator use
according to type of service, but be able to use alternate locators
when the primary fails. In that scenario, each available path has a
primary use for one service and then serves as a back for other
services.

The question is how to 'name' these pools?  My own, continuing bias is
against any sort of new public namespace.  Worse, my own continuing
bias is against adding any bits to a data packet's header.  Hence, I
want to find a way for the real context naming to be done in the
endpoints, rather than adding a context label to the data packets.

I finally realized that we already have such a construct readily
available, and we have many years of experience using it:

     Connection ID:
     (Protocol, Remote IP, Remote Port, Local IP, Local Port).

This is plenty of granularity.

Best of all is that using this as the model for naming pools does not
require implementing more than one pool right away. So, we can
have the model contain a fine-grained labeling scheme, but initially
use it in a more coarse fashion.

I should also note that a using an address pool in any manner that is
interesting -- that is, beyond its serving as a supply of fallback
locators to be used only when the current one fails -- will likely
break congestion control mechanisms. Each locator will demonstrate
different congestion characteristics and the blind aggregation of them
will confuse any algorithm trying to analyze the situation. So, we
will have to make those mechanisms be aware of the different locators
that are being used simultaneously for the same endpoint.

Thoughts?

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>