RE: Shared Locator Address Pool (SLAP) protocol proposal

["Christian Huitema" <huitema@windows.microsoft.com>]

> A fundamental advantage that transport-based locator-pool schemes
> (SCTP, DCCP, TCP-MH) have over wedge-layer approaches (HIP, LIN6,
> MAST, MIP) is that they can multiplex the control exchange in with
> data traffic, potentially saving on number of packets. Wedge-layer
> approaches are forced to have an explicit, separate exchange. MAST
> makes this asynchronous from the data exchange that uses the locator
> pool; this avoid startup delay. However the basic cost of the exchange
> remains. If a host must do this exchange with every other host it
> talks to, the aggregate overhead is high.

This is very true. In fact, there are other advantages to transport
approaches. The transport layer naturally obtains information on the
quality of different paths. SCTP can perform measurements across several
paths simultaneously, and can then map flows on one or another path.
TCP-MH can detect that the current path has stopped working well, e.g.
if the frequency of repetition becomes too high, and can decide to try
another path. 

> 1. An endpoint runs Locator Pools (LP) as a resource shared among
> different
> consumer services at the endpoint -- eg, a wedge layer service and an
> enhanced
> transport service -- potentially with multiple maintainers. (Yes, the
> latter
> raises a concern about synchronization, but let's ignore that minor
> detail,
> for now.) LPs might vary in their granularity.  Bigger grains makes it
> more likely that the pool will be shared.  A pool that is the finest
> grain (Connection) can't be shared, of course.

In short, this would make the "wedge" a local concept in the host,
rather than an explicit layer in the protocol. This looks to me like a
generalization of the NOID proposal.

> 2. A common Shared Locator Address Pool (SLAP) protocol is used by the
> different maintenance services, over different communication channels
> (eg, multiplexed on the transport channel, versus over an independent
> control channel). The maintenance services also might use different
> "configurations", such as peer-to-peer exchange, versus third-party
> agent mediation.

Yes. The maintenance information comes from several sources. TCP can
observe timers and congestion windows. Neighbor discovery can provide
information about preferred and deprecated addresses. Routing protocols
can obtain information based on their idea of the network topology, and
can pass it to the host through options in the router announcements. The
maintenance service should combine all these informations.

> 3. Enhanced transport services access the pool directly. Legacy
> transport services access the pool via the much-vaunted IP wedge layer
> service. If an enhanced transport is one of the participants, then
> there really is no need for a wedge-layer service to conduct an
> exchange. This saves packets.

Yes. In fact, it is relatively easy to enhance TCP along the line of
TCP-MH and take advantage of this service.

> The obvious direction this idea leads is towards an effort to produce
> a common protocol.  Clearly it should include the locator
> "characterization" attribute-signalling capability that Erik
suggested.
> 
> Anyone from the various camps interested in discussing such an effort?

We should not think in terms of "camps"... But, yes, I am interested.

-- Christian Huitema