Subject: Re: where the indirection layer belongs

From: Robert Honore <[email-masked]>
Date: Thu, 04 Sep 2003 15:14:51 -0400

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.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 6 Sep 2003 09:25:25 +0859 ()

Robert Honore;

> 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.

> from being able to find other addresses to try.

Read the draft and say TCP.

> implement such a thing, then you will have to prove it.

Read the draft and say TCP.

> 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 

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.

> useless to have such a layer", nor do I believe that the presence of 

See above.

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 8 Sep 2003 05:15:23 +0859 ()

Robert Honore;

> libraries or implementations of those protocols, lest we break something.

It is a wrong requirement wrong in various ways.

First of all, we must change something, which means we must change
some code.

Though the changes should better be simple, whether the changes can
be inserted as a module or not is irrelevant,

To make the changes simpler, the modification MUST be confined in
libraries or kernel. So, we should try to change libraries or kernel
to avoid changes on application code.

It, of course, is necessary to change application code for UDP
cases for address selection that it is necessary to an API
to control address selection in IP headers from applications
that IP and transport layer code MUST be modified .

Secondly, preservation of code is less important to preservation
of protocol and protocol is defined on the wire.

If you put some code below transport layer to modify packet content
visible from the transport layer, which is the case with MAST, you
change the transport layer protocol.

But, again, we must change something of the protocol.

So, the requirements are:

	to modify existing code

	to modify existing protocol

and any attempt, including but not limited to MAST, to avoid them
is not constructive only to constraing the solution space to
result in less capable and less efficient solutions.

Of course, it is desirable

	to preserve existing application code

whenever possible. But, we must be aware that it is NOT always
possible.

In addition, it is desirable

	to preserve interoperability with existing protocols

which automatically means "to preserve interoperability with existing
code of the peer". In this case, it is doable. Of course, all the
freedom to use multiple addresses is lost when the peer is a
leagacy one.

							Masataka Ohta

---

From: Robert Honore <[email-masked]>
Date: Mon, 08 Sep 2003 14:28:48 -0400

Dear Masataka Ohta,

  I was a bit impetuous in saying that I would prefer not to modify 
libraries or implementations etc.  However, my aim so far is more to 
obtain for myself a clear understanding of the problem we are trying to 
solve, rather than trying to state requirements of the possible 
solutions to that problem.  My apologies for such a stupid statement.

I do believe that there are issues to be resolved and they are being 
currently reflected in threads like the one about deprecating site-local 
addresses and the need for provider independent addresses that is 
currently active, as well as the thread "solving the real problem" 
started by Tony Hain.  I believe the issues being discussed there are 
real.  You might not agree that they are.

If the issues are real, then we need to specify or formulate them in a 
way that is amenable to deriving solutions for them.  If the issues are 
not real, then they are likely the artifacts of wrong perceptions or 
ideas that users and engineers in the IPv6 community have.  In that 
case, we need to replace those wrong perceptions or ideas with correct 
ones.  It seems to me though, that nobody has stated clearly what those 
wrong perceptions and ideas are, much less to say what is wrong with 
them and thus replace them with correct perceptions and ideas.

Yours sincerely,
Robert Honore.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 9 Sep 2003 06:58:45 +0859 ()

Robert Honore;

> It seems to me though, that nobody has stated clearly what those 

A draft ID

                    Simple Internet Protocol, Again

on the real problems can be found at

	ftp://ftp.hpcl.titech.ac.jp/draft-ohta-sipa--1.txt

	Abstract

	   IPv6 has failed to be deployed partly because of its complexity.

	   IPv6 mostly is a descendant of SIP (Simple Internet Protocol) but has
	   fatally bloated merging with other proposals and trying to make IPv6
	   has better functionality than IPv4, which makes IPv6 unnecessarily
	   complex and, thus, worse than IPv4.

	   SIPA (Simple Internet Protocol, Again) is a proposal attempting to
	   restore simplicity to IPv6 sticking to the real world operational
	   requirements for the IPv4 Internet to make IPv6 more acceptable to
	   ISPs and end users.

						Masataka Ohta