Maybe I read your paper on project SNIPE too quickly, but it was not immediately clear that the problems you mentioned were a specific result of an attempt to make the application resilient against (sudden) changes in IP address. More specifically, it was not clear from that report that the additional complexity did come from the attempt to provide the kind of resilience we are seeking, or from the rather ambitious goals of project SNIPE. I will re-read more slowly and carefully this time.
Yours sincerely, Robert Honore.
Keith Moore wrote:
(regarding the complexity of putting a general-purpose layer to survive address changes between L4 and L7)
But why do you assert that it will take lots of complexity and overhead? Can you point to some code where they tried this? As far
as I know, nobody has really given this an earnest try as yet. At
least not with any IP protocols.
I tried this in connection with a project called SNIPE that I worked on
several years ago. SNIPE was an attempt to build a very
reliable distributed computing environment that supported, among other
things, the ability to access a computing resource via multiple
addresses (mostly in order to exploit high-bandwidth local networks
not necessarily using IP), and the ability of both hosts and processes
to migrate to other addresses. It used a DNS-like service similar to
RESCAP (for those who remember that) to register the addresses at which
a process was accessible, and it attempted to provide TCP-like streams
on top of TCP and this registry that would survive changes in those
addresses. Basically I found that you can get such a service to work
reasonably well and reasonably efficiently if endpoints don't move
without adequate notice. OTOH if hosts or processes do move without
adequate notice then you end up needing to implement the mechanisms I
mentioned earlier, and that involves extra copies and extra overhead.
The reason I am preposing that the two problems (changing addresses with adequate notice and changing addresses without adequate notice) be treated separately is that by trying to make a single mechanism serve both purposes you end up with a lot of inefficiency and/or cost that aren't needed in most cases. And that's true (for different reasons) regardless of whether you insert that single layer between L3 and L4 or between L4 and L7.
What specific glue do you believe it requires for the L4 to L7
approach?
Thought I'd said this already: buffering of data until acknowledged by the peer, generation and processing of acknowledgements, retransmission of lost messages due to broken connections, windowing (so you don't degrade to stop-and-wait), duplicate suppression. You also need to multiplex control and data information over the same stream and to probe for other addresses when you get a failure on the one you were using.
How does that compare to what is needed in an L3 solution?
If you work on the problem at (or just above) L3, transport protocols already have the code needed to recover from lost messages, so you don't have to reimplement that. You basically need a mechanism by which the layer can realize it needs to start routing packets differently, and do so. You probably need multiple ways that the layer can get that information because the remote address can change for a variety of reasons and in lots of different places in the network. (That's equally true for the L4-L7 layer as for the L3-L4 layer, but the L4-L7 layer isn't in a position to get some of that information. The L3-L4 layer can potentially recover from address changes more quickly but to do that safely it has to be able to authenticate and establish a basis for trust in a wider variety of information sources.)
Yes you can do that but it presumes that the host knows a priori whether or not it needs the stabilization layer. I would make the mechanism used to provide stable addresses a property of the network- either the network provides "reasonably" stable addresses (i.e. plenty of prior notice before changing them) or it provides a stabilization layer. That way, networks that don't need it don't pay the overhead.
But I would argue that the host or at least the application's designer
knows whether it will need the stabilisation layer.
It can't know that reliably unless the network without the stabilization layer has well-defined properties - e.g. the network won't change addresses of a network without advertising those changes with a minimum amount of advance notice. If addresses can potentially change at arbitrary times with no assurance of stability then every app needs the stabilization layer (or provide its own means of recovery).
Making the mechanism that provides the stable network addresses a property of the
network leaves the question of how. Even if that were achieved
though, that still does not completely or effectively address the
problem of one application process identifying its peer across the
network.
Well, there's no way I can supply all of the details in a few email messages. I've been trying to find time to write them up. In the meantime I want to discourage too much momentum behind trying to solve all of the address changing problems in any one place - particularly between L4 and L7, because I already know that that won't work well.
Keith
