Re: [EME] First cut at eme requirements

Rémi Després <remi.despres@wanadoo.fr> Tue, 05 December 2006 17:20 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdyS-0005P0-Gi; Tue, 05 Dec 2006 12:20:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdyR-0005Oh-5E for eme@irtf.org; Tue, 05 Dec 2006 12:20:55 -0500
Received: from smtp20.orange.fr ([80.12.242.26] helo=smtp-msa-out20.orange.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrdyO-0003me-JN for eme@irtf.org; Tue, 05 Dec 2006 12:20:55 -0500
Received: from [127.0.0.1] (APuteaux-152-1-57-191.w82-120.abo.wanadoo.fr [82.120.173.191]) by mwinf2028.orange.fr (SMTP Server) with ESMTP id 8F29B1C000B8; Tue, 5 Dec 2006 18:20:50 +0100 (CET)
X-ME-UUID: 20061205172050586.8F29B1C000B8@mwinf2028.orange.fr
Message-ID: <4575AA70.1070909@wanadoo.fr>
Date: Tue, 05 Dec 2006 18:20:48 +0100
From: Rémi Després <remi.despres@wanadoo.fr>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Paul Francis <francis@cs.cornell.edu>
Subject: Re: [EME] First cut at eme requirements
References: <E6F7A586E0A3F94D921755964F6BE00672E365@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <E6F7A586E0A3F94D921755964F6BE00672E365@EXCHANGE2.cs.cornell.edu>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff
Cc: eme <eme@irtf.org>
X-BeenThere: eme@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: end-middle-end research group <eme.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/eme>
List-Post: <mailto:eme@irtf.org>
List-Help: <mailto:eme-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1345348760=="
Errors-To: eme-bounces@irtf.org

Good question!
Scott's definition in my view has two parts.
- The first sentence is the definition per se
- The two others are comments.

My point is only about the first sentence (the comments are OK).

the current wording, "Functions apart from standard functions of an IP 
router" is somewhat involved, and IMO ambiguous (if a router has more 
functions than a "standard" router, as defined by IETF, does it become 
an EME middlebox?).
Now, a question remains: is it intended by some in the group that a box 
could be an EME middlebox although it would never modify any E2E IP packets?
(A router that encapsulates a packet is seen as NOT modifying the "E2E 
packet".)
It don't se the need for that, but it should be a conscious collective 
decision.

The following definition would take my point:
A middlebox refers to a network element which involves itself in
communication between endpoints and modifies end-to-end IP packets more 
than by updating their TTL.
A middlebox may keep per-flow state or may be
stateless.
Like endpoints, middleboxes may also have local policy governing
which endpoints may communicate over the particular network.

RD


Paul Francis a écrit :
>  Do you find Scott's definition to be insufficient or too involved?
>  (Repeated here for convenience)
>
>
>
>
>  PF
>
>  ________________________________
>
>  From: Rémi Després [mailto:remi.despres@wanadoo.fr] Sent: Tuesday,
>  December 05, 2006 5:05 AM To: Paul Francis Cc: Scott W Brim; eme
>  Subject: Re: [EME] First cut at eme requirements
>
>
>  I wonder whether an easy characterization of EME middleboxes couldn't
>  be that they may modify IP packets. ("IP Packets" are no longer E2E.
>  Only part of their semantics is.)
>
>  RD
>
>  Paul Francis wrote :
>
>  These are all reasonable comments...happy to incorporate them in the
>  next revision.  PF    -----Original Message----- From: Scott W Brim
>  [mailto:swb@employees.org] Sent: Tuesday, November 28, 2006 2:39 PM
>  To: Paul Francis Cc: eme Subject: Re: [EME] First cut at eme
>  requirements  On 11/28/2006 10:30 AM, Paul Francis wrote:
>
>  Middlebox:  A middlebox refers to a network element assisting
>  endpoints to communicate through that network.  A middlebox may keep
>  per-flow state or may be stateless.  Like endpoints, middleboxes may
>  also have local policy governing which endpoints may communicate over
>  the particular network.
>
>  This isn't an easy definition.  Not all middleboxes "assist"
>  communication -- some either restrict it or allow it.  Also I believe
>  we want to exclude routers from the definition.  Finally, some
>  middleboxes are pure control, some are pure data plane, some are
>  mixed.  What about pure policy boxes?  
>
>
>

_______________________________________________
EME mailing list
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme