Re: Shared Locator Address Pool (SLAP) protocol proposal

["Spencer Dawkins" <spencer@mcsr-labs.org>]

Hi, Brian,


> Spencer, I think the point here is that there will be state
> to maintain, and each user of that state will need to access a
> common STorage Information bloCK, i.e. the SLAP STICK.
>
> The kind of shim that NOID suggests could also be a user
> and maintainer of the slapstick.
>
> I'd encourage people to think about this as a potential
> architectural component, in the spirit of the final part of
> the discussion last week.

This all works for me. The thing in the back of my mind was that we
didn't head in a parallel direction with ECM (Endpoint Congestion
Management) - we developed the base specs, and then everthing kind of
stopped. But we've clearly considered providing a common capability
for all transports in a situation that was architecturually similar,
and the ECM pictures had congestion management in a shim underneath
multiple transports (the same point in the stack, if I get the SLAP
vision).

I don't think there was any technical obstacle to ECM, just a lot of
stack developers who already had working TCPs and didn't want to dork
with them. ECM happened before DCCP and pretty early for SCTP, so
there weren't a lot of non-TCP transports that were trying to get
congestion control right. But I digress.

The rules for using the SLAP STICK, and especially for modifying it,
need to be pretty clear. We know how to write clear rules, we just
need to make sure we do it this time!

Thanks,

Spencer