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