Robert Honore;
(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 issue has been discussed and analyzed long ago.
Just making a complex proposal with new layers, which is know to
be useless, is not a construtive way of discussion and the proposal
should be ignored without much discussion.
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.
Read the draft and say TCP.
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.
Read the draft and say TCP.
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.
Wrong. Additional API to existing layers is just enough.
I would also prefer not to modify any of the
libraries or implementations of those protocols, lest we break something.
That is source of your misunderstanding.
Youre requirement is not only meaningless but also harmful. See
other mail on how MAST is not transparent for details.
In short, it is as complex, transparent, meaningless and harmful
as NAT.
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
See above.
Layering is abstraction and not indirection at all.
Agreed. We should use the correct terminology.
And a new layer, to which information in other layers are
hidden with the abstraction, is useless to implement
mechanisms using the information.
Masataka Ohta