Subject: RE: Shared Locator Address Pool (SLAP) protocol proposal

From: "Christian Huitema" <[email-masked]>
Date: Sat, 15 Nov 2003 11:44:20 -0800

> 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

---

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Nov 2003 12:08:01 -0800

Christian,

CH> This is very true. In fact, there are other advantages to transport
CH> approaches. The transport layer naturally obtains information on the
CH> quality of different paths.

In fact, I am suspecting that it will prove useful to distinguish -- and
modularize, and possibly even share -- the "quality assessment" function
in transport, from the other things such a protocol does.

>> 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
CH> In short, this would make the "wedge" a local concept in the host,

Not really. Each of these needs to exist in both the endpoints (or in
one endpoint and a proxy agent that is working on behalf of the other
endpoint.)

So each approach really is an end-to-end, cooperative service, rather
than being only a local to a single end, the way a typical NAT is.

>> Anyone from the various camps interested in discussing such an effort?
CH> We should not think in terms of "camps"... But, yes, I am interested.

Great!

As IETF proposal wars go, this one is -- so far -- pretty amicable. In
fact, I think it is proving extremely productive for getting a better
understanding of underlying issues.

But quite a few folks do have their favorite specification and are
lobbying for it. (Not just me. Not just the HIP folks.) On the average,
an IETF effort that seeks to "merge" competing proposals does not turn
out very well, but the current situation looks at least technically
reasonable to consider.

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