Re: Thoughts about layering multi-addressing

[Jari Arkko <jari.arkko@piuha.net>]

This seems like a very useful thread. Some comments:

> So, it looks to me that we are facing something like the following steps:
>
> 1. Minimally intelligent shim, one primary locator, unchanged
> transports
>
> 2. Shim as in #1, richer interface between shim and ULPs,
> shim-aware transports being able to use multiple locators
> at the same time
>
> 3. Further research on the proper new location(s) of traditional
> transport functions in the stack
>
> #2 and #3 are clearly research at this point of time, and outside the 
> scope of the WG charter. As I wrote in my first message in this 
> thread, I would very much see running code or simulations in that 
> space; without that we'd be driving in the dark.

I am very much in favor of the minimal shim. I realize finer grain
control is possible, but at least for now I remain unconvinced
of the real need -- particularly when we will still have to allow
for transports and applications that can do some of these things
themselves. A number of examples about various interfaces
and applications were listed earlier on this thread, but I
fear that its hard to find out the information on which you
can base the decision on, and automating everything would
require a TCP-like measurement process, information about
applications' needs, and perhaps even pricing information.

On the other hand I'm not sure if you classification above
is exact. Primary locators are used in SCTP, but do
we need them in shim? Or did you mean "one current locator"?
Also, some extensions in the interface appear unavoidable,
like telling transport that it needs a slow start, or the ability
of multihoming aware transports and applications to bypass
the shim if they want to.

--Jari