Dear Masataka Ohta,
Masataka Ohta wrote:
Keith;
(regarding the complexity of putting a general-purpose layer to survive
address changes between L4 and L7)
It is not merely complex but also useless to have such a layer.
Right now I am not fully aware of all of the specifics of the issues in
trying to implement such a layer, but the statement you make in the
paragraph just below does not seem to support your statement that "It is
not merely complex but also useless to have such a layer." I will
explain my position below.
The basic problem of the approach to have such a layer is that
only the application layer has proper knowledge on proper
timeout value to try other addresses.
If such a layer is useless as you say, then the application could see no
benefit to being able to parametrise the transport or network layers
with such information as the proper timeout values to try other
addresses. It would also be impossible for the application to benefit
from being able to find other addresses to try.
Another objection I have to your statement: If the application layer is
the one that has the proper knowledge of things like timeouts (I suppose
there are things), then it should be possible to implement something on
the stack that is close to the application wherein it can collect that
information and parametrise the behaviour of the rest of the lower
layers. If by your statement you are saying that it is impossible to
implement such a thing, then you will have to prove it.
So, the issue can be solved only involving application layer, though
most applications over TCP can be satisfied by a default timeout of
TCP. In either case, there is no room to have an additional layer.
I agree completely with your first sentence in this paragraph. The
problem we have right now is that, save for the application specifying
to the transport which peer port it wants to connect with, it has no
further control over the behaviour of the transport or the network
layers other than to possibly drop the connection.
I cannot as yet agree or disagree with your second sentence. I don't
know as yet what needs to be built. I will say that I would prefer to
minimise or avoid altogether any modifications to the transport or the
network protocols. I would also prefer not to modify any of the
libraries or implementations of those protocols, lest we break something.
I documented it long ago (April 2000) in draft-ohta-e2e-multihoming-*.txt
The Architecture of End to End Multihoming
(current most version is 05) that:
To support the end to end multihoming, no change is necessary on
routing protocols. Instead, APIs and applications must be modified to
detect and react against the loss of connection. In case of TCP
where there is a network wide defact agreement on the semantics
(timeout period) of the loss of connectivity, most of the work can be
done by the kernel code at the transport layer, though some timing
may be adjusted for some application. However, in general, the
condition of "loss of connectivity" varies application by application
that the multihoming must directly be controlled by application
programs.
Masataka Ohta
Having looked at draft-ohta-e2e-multihoming-05.txt, I am not convinced
that it supports your statement that "It is not merely complex but
useless to have such a layer", nor do I believe that the presence of
such a layer would necessarily violate the end-to-end principle you
advocate in draft-ohta-e2e-multihoming-05.txt. In fact, the way I see
it, the presence of such a layer could make it easier to achieve the
aims of draft-ohta-e2e-multihoming-05.txt even without needing to
designate any special kind of IPv6 address, provided we can solve the
problem of specifying end-point identifiers and clarifying exactly what
they should identify.
PS
Layering is abstraction and not indirection at all.
Agreed. We should use the correct terminology.
Yours sincerely,
Robert Honore.