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

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Thu, 04 December 2014 12:09 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982911A0302 for <ietf@ietfa.amsl.com>; Thu, 4 Dec 2014 04:09:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.599
X-Spam-Level:
X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPdTTzpdoPQB for <ietf@ietfa.amsl.com>; Thu, 4 Dec 2014 04:09:25 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 71B831A0276 for <ietf@ietf.org>; Thu, 4 Dec 2014 04:09:25 -0800 (PST)
Received: (qmail 76661 invoked from network); 4 Dec 2014 11:56:39 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 4 Dec 2014 11:56:39 -0000
Message-ID: <54804EF1.4000104@necom830.hpcl.titech.ac.jp>
Date: Thu, 04 Dec 2014 21:09:21 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Call for Papers: IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)
References: <9D725DD0-7136-4D02-99E0-48E03C173C9E@iab.org> <BB616542-70E8-47F9-99E8-305AA63B45C9@iab.org> <5475A0A5.50105@necom830.hpcl.titech.ac.jp> <547F14FF.9090600@necom830.hpcl.titech.ac.jp> <547F59C1.1060107@cisco.com> <547F9DBA.9020705@necom830.hpcl.titech.ac.jp>
In-Reply-To: <547F9DBA.9020705@necom830.hpcl.titech.ac.jp>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/zb69xqcuqthkBYMuZNe5ctKiKlI
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Dec 2014 12:09:29 -0000

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?
>>
>> Yes, because it's not proof.
> 
> 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