RE: [EME] EME charter

"Paul Francis" <> Tue, 14 November 2006 13:22 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GjyFc-0002Pg-Cw; Tue, 14 Nov 2006 08:22:56 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1GjyFb-0002PQ-Cz for; Tue, 14 Nov 2006 08:22:55 -0500
Received: from ([] by with esmtp (Exim 4.43) id 1GjyFa-0001Vy-5R for; Tue, 14 Nov 2006 08:22:55 -0500
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 08:22:52 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [EME] EME charter
Date: Tue, 14 Nov 2006 08:22:52 -0500
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [EME] EME charter
Thread-Index: AccHVpvD+5PsjbGBQY+Rcc5RQkskkgAluS0A
From: "Paul Francis" <>
To: "Joe Touch" <touch@ISI.EDU>, "Saikat Guha" <>
X-OriginalArrivalTime: 14 Nov 2006 13:22:52.0593 (UTC) FILETIME=[FCF65A10:01C707EF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
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: <>, <>

My take on recent threads:

1.  As Saikat said, EME different from midcom mainly in its involving both
endpoints as well as middleboxes.
2.  As Melinda said, EME different from NSIS in large part in that it deals
with higher level naming issues (in a sense, EME "off-path" signaling
mechanisms would occur before NSIS "on-path" mechanisms, though EME will
revisit on-path signaling in light of its off-path components).

3.  As for cooperating versus non-cooperating middleboxes...I'm very
reluctant to try to do something about non-cooperating middleboxes...I'm not
sure what we can do about them.  My hope is that many middleboxes don't want
to be transparent per se, but are so because there are no other deployment
options.  If the EME protocols are successful, the middleboxes would have a
way to become non-transparent, and I assume that many would do so.  Right
now, I'm thinking of middleboxes that refuse to cooperate as out of scope.



-----Original Message-----
From: Joe Touch [mailto:touch@ISI.EDU] 
Sent: Monday, November 13, 2006 2:04 PM
To: Saikat Guha
Subject: Re: [EME] EME charter

Saikat Guha wrote:
> On Mon, 2006-11-13 at 10:29 -0800, Joe Touch wrote:
>>> 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 is different from MIDCOM in that the MIDCOM model is of an 
> endpoint signaling *to the line of middle boxes* in front of it (i.e 
> E-M), while the the EME model is the endpoint signaling *to the other 
> endpoint* through the line of middle boxes in front of both of them (i.e.

That'd be useful to bring out in the charter.


EME mailing list