ietf
[Top] [All Lists]

Re: where the indirection layer belongs

2003-09-03 10:28:58
Dear Keith Moore,

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










<Prev in Thread] Current Thread [Next in Thread>