Subject: Locator Pool Reference ID

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Nov 2003 01:47:41 -0600

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>

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 15 Nov 2003 23:35:37 +0900

Dave;

> This is plenty of granularity.

and IP, here, is used as ID. So,

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

is the answer.

> will confuse any algorithm trying to analyze the situation.

As I already noted, path change without locator change also changes
congenstion characteristics that it is a problem of transport not
specific to multi6.

On the other hand, it is a protection agaist redirecting burst
attack to slow start at locator changes.

However, slow start costs performance.

						Masataka Ohta

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 15 Nov 2003 13:44:51 -0600

From: "Masataka Ohta" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, November 15, 2003 8:35 AM
Subject: Re: Locator Pool Reference ID

> congenstion characteristics that it is a problem of transport not

Yes - for example, when 802.17 rings "change directions" - the ring is
one IP hop, but with destination-stripping, your cross-traffic can
vary considerably when you go "the other way" around a ring.

> However, slow start costs performance.

This is consistent with the feedback I was getting from TSV maevens
about transport-level notifications for path changes/path
characteristics changes.

Slow-start would be safe (how could it not be?), but may be more than
what is needed. The logic seems to go something like

- if my path changes and I'm competing with a lot less traffic, I
shouldn't slow down

- if my path changes and I'm competing with a lot more traffic, I'll
lose something, and TCP-ish transport protocols will slow down
appropriately within a couple of RTTs, using Fast Retransmit/Fast
Recovery

- so I should either do nothing, or do what I would have done anyway
within an RTT or two, without additional transport
protocol/implementation complexity

Not a multi6 issue - the same issue comes up today when a routing
update changes part of a connection path between two single-homed
networks.

Spencer