Subject: [EME] EME charter

From: Tilman Wolf <[email-masked]>
Date: Sun, 12 Nov 2006 21:18:21 -0500

Now that the End-Middle-End Research Group has been formally chartered, 
I would like to introduce myself, Tilman Wolf, and my co-chair, Mark 
Williams, to those subscribed to the EME mailing list. Mark and I will 
handle the administrative duties of this research group and hope to 
engage in some of the technical discussions.

The EME charter can be found at 
http://irtf.org/charter?gtype=rg&group=eme . The goal of our research 
group is to explore issues related to "middleboxes," i.e., devices that 
are placed inside the network along the end-to-end communication path. 
Our next immediate milestones are to develop an applicability statement 
followed by a design choices document.

If you need to contact us, our email addresses are available on the 
above website. We are both looking forward to your active participation 
in this research group.

Regards,
Tilman Wolf
-- 
------------------------------------------------------------------------
Tilman Wolf, D.Sc.                                   Assistant Professor
Department of Electrical and Computer Engineering         (413) 545-0757
University of Massachusetts                           [email-masked]
Amherst, MA 01003-9284                 http://www.ecs.umass.edu/ece/wolf
------------------------------------------------------------------------

_______________________________________________
EME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/eme

---

From: Jefsey_Morfin <[email-masked]>
Date: Mon, 13 Nov 2006 05:31:40 +0100

At 03:18 13/11/2006, Tilman Wolf wrote:
>http://irtf.org/charter?gtype=rg&group=eme . The goal of our 
>research group is to explore issues related to "middleboxes," i.e., 
>devices that are placed inside the network along the end-to-end 
>communication path. Our next immediate milestones are to develop an 
>applicability statement followed by a design choices document.

Are OPES and OPES networks (which can be considered as virtual 
middleboxes and virtual distributed middlebox) part of the EME concerns?
Thank you.
jfc

---

From: Joe Touch <[email-masked]>
Date: Sun, 12 Nov 2006 21:52:13 -0800

Tilman Wolf wrote:
...
> followed by a design choices document.

Some feedback on the charter. It talks about middleboxes that endpoints
don't know about, as if the endpoint is the problem.

Problem-causing middleboxes don't *want* to be found; they want to be
"transparent".

Resolving - or prohibiting - that transparency should be included and
addressed.

Joe

---

From: Yangwoo Ko <[email-masked]>
Date: Mon, 13 Nov 2006 15:02:50 +0900

> Resolving - or prohibiting - that transparency should be included and

I agree with the argument that "transparency" is problematic.
By the way, if they are not transparent, why should we call
them as "middleboxes" ? Aren't they just end-points? It seems
to be necessary to differentiate middleboxes that are well
identified and explicitly exploited by end-points and that
are trying to be transparent.

Regards

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 13 Nov 2006 06:08:25 -0800

Welcome Tilman and success!

I suppose we will go be the spirit of "Reflections on Internet
Transparency"?  

http://www.ietf.org/internet-drafts/draft-iab-net-transparent-00.txt 

Can middleboxes abide by the above IAB document? If yes, the RG could
formulate the exact criteria and show some use cases with good and bad
middleboxes. 

In lieu of an introduction, I have gotten a lot of flak by stating the
Session Border Controllers (SBC) used for VoIP are evil...

Thanks, 

Henry Sinnreich

-----Original Message-----
From: Tilman Wolf [mailto:[email-masked]] 
Sent: Sunday, November 12, 2006 8:18 PM
To: [email-masked]
Subject: [EME] EME charter

Regards,
Tilman Wolf

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Nov 2006 06:46:34 -0800

Yangwoo Ko wrote:
> them as "middleboxes" ? Aren't they just end-points? 

I was hoping someone would get to that point ;-)

> It seems

If the former are endpoints (E2E RG focus), and the latter are
impossible to 'please', what's left for EME?

Joe

---

From: Saikat Guha <[email-masked]>
Date: Mon, 13 Nov 2006 13:06:52 -0500

> Resolving - or prohibiting - that transparency should be included and

Middleboxes that are _truly transparent_ are not problematic (by
definition almost). Translucent middleboxes, on the other hand, should
indeed be addressed.

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. 

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.

-- 
Saikat

---

From: Melinda Shore <[email-masked]>
Date: Mon, 13 Nov 2006 13:09:54 -0500

> address the problem IMHO.

That was certainly the intent behind midcom, but as long as the
endpoint needs to know the location of the middlebox in order to
transmit requests to it you haven't eliminated the lack of tranparency,
you've just moved it somewhere else.

Melinda

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Nov 2006 10:29:13 -0800

> definition almost). Translucent middleboxes, on the other hand, should

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

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

> address the problem IMHO.

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

Joe

---

From: Melinda Shore <[email-masked]>
Date: Mon, 13 Nov 2006 13:40:31 -0500

> communication was supposed to do.

I think a lot of what's driving this has more to do with 1) maladapted
business models, and 2) perceptions around security, actually.  This is
particularly true around voice where on the one hand there's a higher
level of comfort with control plane/data plane separation and on the
other a tendency to solve problems that crop up by dropping more stuff
into the network (and granted, it's a lot easier to add new things than
it is to remove or change existing ones).  The enterprise case is somewhat
more complicated since there's a different relationship with users (they
aren't customers in the traditional sense) and there's a different
relationship to the network's assets.  I think that a lot of what's going
wrong on networks today, at least around middleboxes, has economic
roots rather than technical ones.  I don't have a clue what to do about
that.

Melinda

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Nov 2006 10:47:47 -0800

The same could be said of NATs, with the same result. Substantial impact
on the Internet architecture that we then spend years trying to
circumnavigate and/or explicitly support.

In both cases, the onus shifts on us to do lots of work to support
others who are making money, IMO.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

---

From: Saikat Guha <[email-masked]>
Date: Mon, 13 Nov 2006 13:53:23 -0500

On Mon, 2006-11-13 at 10:29 -0800, Joe Touch wrote:
> 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. E-M-E).

On Mon, 2006-11-13 at 13:09 -0500, Melinda Shore wrote: 
> as long as the

Agreed. If the signaling destination is the other endpoint which in turn
requires an end-to-end signaling plane, then there is an opportunity to
discover the middleboxes that need to be signaled individually.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 13 Nov 2006 14:04:26 -0500

> discover the middleboxes that need to be signaled individually.

Arguably that's nsis (although the NAT problem remains).

I'm glad to see that this research group was chartered, myself, and
there are definitely areas that need attention and that do not overlap
with existing work.  Certainly the namespace issue needs attention -
there's some existing work but it tends to be application-specific and
if something can be done to make that coherent that would be a big
step forward.  Some of that involves lookup services.  Similarly,
there may be a need for rendez-vous services that are smarter than
application-specific SBCs and relays.  I think the tools that actually
do the communication with middleboxes are basically there, but some
problems remain unsolved (naming for NATted endpoints that have
established external reachability, for example) and there's a lack
of general coherence.  I'm optimistic that this group can provide
a forum for trying to develop some coherence.  Ad astra per aspera,
or something.

Melinda

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Nov 2006 11:04:04 -0800

> through the line of middle boxes in front of both of them (i.e. E-M-E).

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

Joe

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 14 Nov 2006 08:22:52 -0500

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.

PF

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Monday, November 13, 2006 2:04 PM
To: Saikat Guha
Cc: [email-masked]
Subject: Re: [EME] EME charter

Saikat Guha wrote:
> 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.
E-M-E).

Joe