(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