Subject: Re: Call for Papers: IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)

From: Masataka Ohta <[email-masked]>
Date: Wed, 03 Dec 2014 22:49:51 +0900

This time to IETF list;

As I wrote:

> The problem, however, is that the review comment are so
> surprising that the result of SEMI workshop is very simply
> proven (see below) to be "incorrect and incomplete".

are there anyone who argue against the proof?

To explain it less formally without the end to end argument,

According to RFC3424 written by IAB:

    o  Shipping NATs often contain Application Layer Gateways (ALGs)
       which attempt to be context-sensitive, depending on the source or
       destination port number.  The behavior of the ALGs can be hard to
       anticipate and these behaviors have not always been documented.

but, CFP of SEMI2015 says:

   Can common transport functionality and standardization help
   application developers to implement and deploy such approaches
   in today’s Internet?

which means SEMI2015 has, quite seemingly, a prejudice to focus
only on "common" and/or standardized, thus, well known, functionality
of ALGs, ignoring undocumented ones.

As such, it is obvious that such approach won't work for ALGs with
undocumented functionality.

Then, there is no point to have SEMI2015 only to harm the Internet
community by having an IAB authorized workshop report containing
wrong approaches.

Still, one might argue that, with incremental approach by making the
mechanisms more and more complicated, at some point, we might finally
be able to make it complete and correct.

Those who can enjoy the formalism of the end to end argument can
recognize that the argument is the simple and straight forward
proof that it is impossible.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 03 Dec 2014 23:02:14 +0900

Phillip Hallam-Baker wrote:

> The only end points that can be fixed end to end on a network are
> cryptographic keys and data bound to cryptographic keys.

I think you understand that introduction of cryptographic keys for
communications between servers and clients through middleboxes
requires upgrading of all of them (servers, clients and middleboxes).

Or, are you assuming some more magical approach?

						Masataka Ohta

---

From: Eliot Lear <[email-masked]>
Date: Wed, 03 Dec 2014 19:43:13 +0100

Ohta-san:

> are there anyone who argue against the proof?

Yes, because it's not proof.

> of ALGs, ignoring undocumented ones.

That clearly wasn't our intent.  Rather, you will note that the text you
quote from the CFP is in the form of a question.  That is a good basis
for discussion, not a conclusion, as you assert.  Clearly the end to end
argument comes into play in that discussion.  It is not, however, the
beginning or end of the matter.

Eliot

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Dec 2014 08:33:14 +0900

> Yes, because it's not proof.

Why? Please argue, not just state.

> for discussion, not a conclusion, as you assert.

The problem is that, as I gave a proof, only two possibilities to
keep the end to end transparency is rejected in advance and the
wrong approach, proven to be incorrect and incomplete, is raised
as a question.

That is, it is the worst basis for meaningful discussion.

> Clearly the end to end argument comes into play in that discussion.

It is a waste of time and too late to let the end to end argument
comes into play so lately.

> It is not, however, the beginning or end of the matter.

No, of course. With proper approaches rejected and remaining
wrong questions, no constructive discussion can begin.

All you can do is to repeat simplistic statements such as
"Yes, because it's not proof." without any reasoning.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Dec 2014 21:09:21 +0900

> Why? Please argue, not just state.

Let me elaborate a little more.

It is not productive to declare something not a proof, because it
dose not make the problem address the proof disappear.

And the problem is that, with the following situation:

	a) there are a client behind a middlebox and a server
	 communicating over the Internet

	b) the middlebox has ALG function with some protocol
	at some port

	c) the function somehow harms communication between the server
	and the client

	d) some part of the harmful ALG function is unknown to the
	client

the communication between the server and the client is harmed.

Then, the only possible approaches to completely remove the harm is:

	1) to avoid the port used by the ALG, which requires cooperation
	between the server and the client sides

	2) to replace/upgrade the middlebox and the client so that the
	 harm by the middlebox is known and reacted against by the
	client

and another approach of:

	3) to make the client react against the harm of the function
	as much as possible even though the client is at a loss against
	the unknown part of the function

is, obviously, an incomplete solution.

As such, declaring the content of my previous mails "not proof" do not
make the problem disappear.

A possible productive counter argument is to show an approach 4) or
more which could completely remove the harm.

I do welcome it.

If you can't to do so, you should just accept that the problem is
real, even though it might deny the originally intended purpose of
SEMI2015.

Can you argue against the problem? Or?

						Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Dec 2014 16:06:23 -0800

On 11/26/2014 8:22 AM, Phillip Hallam-Baker wrote:
> On Wed, Nov 26, 2014 at 4:43 AM, Masataka Ohta
> <[email-masked]> wrote:
>> Dear IAB (CC to IETF list);
>>
>> I wrote a position paper for SEMI workshop and it was rejected
>> with a surprising review comment, all of the point of which
>> is wrong.
> 
> That is because it is a workshop on how the Internet can evolve to
> realize the architecture of the stack, not a workshop on how the
> architecture of the stack can evolve to address the way people use it.

I had thought that part of the meeting would be to address the tension
between these two issues, but I have also since learned it has become
"how do we evolve the Internet to accept whatever middleboxes want to
do" - i.e., precisely the latter of your examples.

> cryptographic keys and data bound to cryptographic keys. Ports and IP
> addresses are ephemera.

Not according to the current Internet architecture, but that's back to
my point above.

An architecture is defined as much by what it is not as what it is. If
everything is on the table as changeable, then there is NO architecture
anymore.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Dec 2014 22:10:44 -0500

> everything is on the table as changeable, then there is NO architecture

If you believe in 'permissionless innovation' then everything is always on
the table. The Internet architecture to date has been what survived a
Darwinian process.

I don't believe in in ancestor worship. Grace Hopper was a visionary
pioneer but I am really glad we stopped using COBOL and FORTRAN even if
many of those ideas made it into later languages.

The statement I made was not about Internet architecture. It is a basic
fact about a network. The only thing that you can rely on being constant
end-to-end is what you protect with cryptography.

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 Dec 2014 17:26:08 -0800

On 12/8/2014 7:10 PM, Phillip Hallam-Baker wrote:
> 
> 
> On Mon, Dec 8, 2014 at 7:06 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> If you believe in 'permissionless innovation' then everything is always
> on the table. 

That's called "anarchy", and the results only serve to increase entropy.

> The Internet architecture to date has been what survived a
> Darwinian process.

First, it's not Darwinian so much as mutation caused by high-energy
radiation, and no, it's not clear to me that "architecture" is
surviving. Sometimes the result is just glowing goo.

> I don't believe in in ancestor worship.

Nor do I; I do believe in deliberate, thoughtful changes to
architecture. That's not the same as the anarchist view, or post-facto
"let's figure out how to change the architecture to accommodate the
anarchy".

In good design, sometimes the answer has to be "NO". If that's not the
case, then you have no architecture.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Dec 2014 09:03:47 -0500

> That's called "anarchy", and the results only serve to increase entropy.

My statement is descriptive, not normative.

If you don't want the Internet to be an anarchy then you have an awful lot
of toothpaste to put back into a very small tube.

> surviving. Sometimes the result is just glowing goo.

What is surprising is that it is possible to describe what has survived in
a remarkably clean fashion with almost no recourse to special casing except
on the issue of syntax.

The glowing goo rarely survives long. My problem is that things get
described as glowing goo for no other reason than that we didn't think of
them.

Are we really taking the high ground in the architecture discussion here or
have we merely staked a position in an editors war?

The argument seems to be that we define the architecture, therefore
anything that isn't the architecture is wrong is an abomination and since
the only things that don't fit the architecture are abominations, this
proves we don't need to reconsider the architecture.

It is a hermetically sealed system of thought.

The real heart of the Internet isn't the narrow waist or even the
end-to-end principle. It is that the Internet is designed to support novel
functionality. The narrow waist is probably an essential consequence of
that goal.

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 Dec 2014 07:25:18 -0800

On 12/11/2014 6:03 AM, Phillip Hallam-Baker wrote:
> On Wed, Dec 10, 2014 at 8:26 PM, Joe Touch <[email-masked]
...
> What is surprising is that it is possible to describe what has survived
> in a remarkably clean fashion with almost no recourse to special casing
> except on the issue of syntax.

If that were true, we would have such a description in hand, and the IAB
wouldn't need to run a workshop to figure out how middleboxes fit into it.

> described as glowing goo for no other reason than that we didn't think
> of them.
> 
> Are we really taking the high ground in the architecture discussion here
> or have we merely staked a position in an editors war?
> 
> anything that isn't the architecture is wrong is an abomination and
> since the only things that don't fit the architecture are abominations,
> this proves we don't need to reconsider the architecture.
> 

Let me clarify.

An architecture describes a system of components and their interactions
in an internally consistent way, which can be used to reason about behavior.

Architectures aren't fixed things; they can evolve, e.g., you can go
from one stable architecture to another, more capable one by deliberate
extension.

It's much harder to just allow unrestricted "innovation" (i.e., anarchy)
and then try to back-calculate a valid architecture that includes those
innovations. Sometimes it's possible, but most of the time the
innovation as deployed wasn't designed to be consistent with a new
architecture. That doesn't mean you can't do the extension - it just
means you can't do an unrestricted extension.

If we had an IAB, they'd be dealing with this evolution as we go, rather
than trying to back-fit it after extensions are widely deployed without
constraint.

> end-to-end principle. It is that the Internet is designed to support
> novel functionality. The narrow waist is probably an essential
> consequence of that goal. 

The real heart of the Internet is an architecture. The E2E principle and
narrow waist are consequences of that architecture. If you put either
one ahead of that, you just have a bumper sticker with no utility.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 15 Dec 2014 16:26:28 +0900

Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 15 Dec 2014 17:11:02 +0900

> from one stable architecture to another, more capable one by deliberate

Surely, something you call architectures might evolve. So what?

> The real heart of the Internet is an architecture.

Depending on what you call "architecture", may be or may be not.

> The E2E principle and
> narrow waist are consequences of that architecture.

Completely wrong.

Apparently, you haven't read the paper, which does not depend
on specific structure/architecture of the Internet with a
very old example of CTSS, reference to which was written in 1963,
and another old example of telephone networking, reference to
which was written in 1964.

As the paper is titled

	END-TO-END ARGUMENTS IN SYSTEM DESIGN

and its abstract begins with the following statement:

	This paper presents a design principle that helps guide
	placement of functions among the modules of a distributed
	computer system.

the argument is applicable to system design in general and,
especially, all the distributed computer systems including
preliminary and *EVOLVED* ones.

Moreover, the paper does not say anything about architecture
of networking (though the paper briefly mentions CPU architecture
of RISC).

So, while you can call something an end to end architecture and
say it can evolve, it has nothing to do with the applicability
of the principle, the end to end argument, to system designs
with or without the evolved architecture.

With the argument, it can be concluded that approaches presumed by
SEMI2015 is incomplete and incorrect.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 15 Dec 2014 17:13:49 +0900

> That's called "anarchy", and the results only serve to increase entropy.

Or, are you assuming some formal way to describe behavior of
middle boxes, with which end systems can cooperate with the
middle boxes?

							Masataka Ohta