Re: [EME] EME charter

Joe Touch <touch@ISI.EDU> Mon, 13 November 2006 18:29 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GjgYq-0001yy-4k; Mon, 13 Nov 2006 13:29:36 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1GjgYo-0001yq-WD for; Mon, 13 Nov 2006 13:29:35 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1GjgYn-0001na-Kn for; Mon, 13 Nov 2006 13:29:34 -0500
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id kADITFx8023282; Mon, 13 Nov 2006 10:29:17 -0800 (PST)
Message-ID: <>
Date: Mon, 13 Nov 2006 10:29:13 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20061025)
MIME-Version: 1.0
To: Saikat Guha <>
Subject: Re: [EME] EME charter
References: <> <> <1163441212.4894.34.camel@localhost.localdomain>
In-Reply-To: <1163441212.4894.34.camel@localhost.localdomain>
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: end-middle-end research group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0387284376=="

Saikat Guha wrote:
> On Sun, 2006-11-12 at 21:52 -0800, Joe Touch wrote:
>> Problem-causing middleboxes don't *want* to be found; they want to be
>> "transparent".
>> Resolving - or prohibiting - that transparency should be included and
>> addressed.
> Middleboxes that are _truly transparent_ are not problematic (by
> definition almost). Translucent middleboxes, on the other hand, should
> indeed be addressed.

Transparent = router or link.

Non-transparent - in some way - is the definition of a middlebox. The
trouble is that middlebox designers use "transparent" when they mean "I
*think* the endpoint won't know", rather than "then endpoint cannot
know, and the difference cannot matter".

> One reason such translucent middleboxes exist is that there is no way
> for the middle to inform the end of policy much less require the end to
> enforce it (the corporate firewall case). Another reason is that the end
> cannot effectively direct the middle (the NAT case); perhaps NATs would
> have been less problematic if source route was a first class citizen in
> the Internet or DNS names carried end-to-end in packets. 

The real reason is that some middlebox designer somewhere thought they
knew better than the person at the endpoint about what an E2E
communication was supposed to do.

Although there are some designers who want to communicate with the
endpoint (if they only could), some (IMO most) *want* to be transparent
even in that case.

> To the extent that the lack of middle-to-end and end-to-middle
> communication prevents middleboxes from being truly transparent (to the
> app layer) or fully visible (to the network layer), EME resolves to
> address the problem IMHO.

That was (is) the goal of MIDCOM, as Melinda pointed out. What will this
WG do beyond that?


EME mailing list