[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thoughts about layering multi-addressing


El 20/08/2005, a las 9:18, Pekka Nikander escribió:

...

We have traditionally taken care of path properties at the transport. Now we are moving some of this functionality to the networking layer, which may be the right direction in the very long run. However, IMHO we should aim for a conservative approach where we try to keep the shim as simple as possible, and keep the path property discovery at the transport layer.

In some way we seem to have two contending goals here:

1. keep locator sets at the IP layer, as a locator set is a property of a host and not a connection, and

2. keep path property discovery at the transport layer, as it has traditionally been done, separated from IP



...but we are including failure detection and path availability exploration mechanisms in the shim, right?

I mean, current design of shim includes (within the shim) the capability of detecting that an address pair in no longer working and also the capability of exploring alternative working address pairs

So, somehow we are including some parts of the path property discovery in the shim. However, the path property that is being discovered by the shim is quiet basic, just working/not working address pair

I assume that what you mean above is that the discovery of more advanced path properties like latency jitter RTT should not be performed by the shim at this stage, is this correct?

However, I don't consider these to be that incompatible; anyway, we can have joint data structures that allows this distinction to be kept. Something like Dave's and Avri's CELP, or maybe what Brian alluded. The flip side of this is, of course, that this breaks the layering abstraction, somewhat. Consequently, I think that in the very long run we should reconsider where to place the traditional transport functionality; my gut feeling is that we may need to split it into path-dependent and connection-dependent parts, separated by a multi-addressing layer.

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.


imho #3 is out of the scope clearly but i don't have a strong position about #2, perhaps some work in this area would be interesting...

regards, marcelo



However, I am worried that we may be trying to jump directly to #3 and design too much functionality to the shim. KISS vs. over-engineering, if you will.

--Pekka Nikander