RE: [EME] First cut at eme requirements

"Paul Francis" <> Tue, 05 December 2006 16:20 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1Grd1o-0002pl-Mc; Tue, 05 Dec 2006 11:20:20 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1Grd1m-0002pH-S1 for; Tue, 05 Dec 2006 11:20:18 -0500
Received: from ([] by with esmtp (Exim 4.43) id 1Grd1l-0002a3-IX for; Tue, 05 Dec 2006 11:20:18 -0500
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 11:20:16 -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] First cut at eme requirements
Date: Tue, 5 Dec 2006 11:20:16 -0500
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [EME] First cut at eme requirements
Thread-Index: AccX+86FpAZOSSNmRjSUp6Ebu9KCvgAhKBTw
From: "Paul Francis" <>
To: "Mark Baugher" <>
X-OriginalArrivalTime: 05 Dec 2006 16:20:16.0998 (UTC) FILETIME=[40326860:01C71889]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
Cc: eme <>
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: <>, <>

So I guess what is meant by "does not disrupt" is key here.  Clearly we want
a solution that doesn't completely disrupt communications when a middle box
crashes or paths change.  At a minimum, this means enough state at the end
systems that they can re-establish communications and, for instance, continue
a transport stream.  I took this minimum amount of robustness as a given, but
no harm in codifying it in the requirements doc.

But if by "does not disrupt" you really mean does not disrupt in any way
(i.e. a voice call continues with nary a glitch), then obviously more of a
challenge.  There are several levels at which we could try to achieve this:

1.  Design the protocols in such a way that we don't prevent the deployment
of redundant hot-failover, fast-reroute kinds of solutions in the
infrastructure, should one wish to deploy this way.
2.  Keep this kind of requirement in mind, and design for it to the extent
that it doesn't overly complicate the protocol, but otherwise be willing to
forgo strong non-disruption.
3.  Make strong non-disruption a hard requirement.

My feeling is that we should make a good effort to achieve 1 and 2, but stop
short of 3.


-----Original Message-----
From: Mark Baugher [] 
Sent: Monday, December 04, 2006 6:24 PM
To: Paul Francis
Cc: eme
Subject: Re: [EME] First cut at eme requirements

On Dec 4, 2006, at 8:38 AM, Paul Francis wrote:

> Good question.  Probably we should have a statement on scale (i.e.  
> global).
> As for the other two, I want to avoid "obvious" kinds of requirement 
> (i.e.
> "the system must be robust").  Having said that, I'm certainly aware 
> that one can construct quite specific robustness statements ("the 
> system must be able to tolerate the loss of up to three servers with 
> zero measureable performance
> degradation") that can have a major impact on system design.
> But am open to discussion on this.  Do you have any thoughts on how 
> such requirements would be crafted?

Here's what I had in mind: To the extent that the middle box is providing
services to endpoints and is incident to the path between (or among) the
endpoints, what happens to end-to-end connectivity when the path changes to
use other middle boxes?  I think that a robust solution would not disrupt the
end-to-end communication as needed state is established in different middle


> PF
> -----Original Message-----
> From: Mark Baugher []
> Sent: Friday, December 01, 2006 6:47 PM
> To: Paul Francis
> Cc: eme
> Subject: Re: [EME] First cut at eme requirements
> What are your thoughts on robustness, scalability and fault-recovery 
> requirements?
> Mark
> On Nov 28, 2006, at 7:30 AM, Paul Francis wrote:
>> Gang,
>> Attached is a rough draft of a requirements document for EME.   
>> This is
>> meant to be the union of the requirements that Handley and I 
>> presented at the BOF in Montreal.  The goal here is to be ambitious 
>> but realistic, and to try to limit ourselves to basic and important 
>> requirements.  This really is a rough draft, and is meant to motivate 
>> and focus discussion.
>> Mark W, could you post on the wiki when you get a chance?
>> Thanks,
>> PF (and Saikat)
>> <eme-requirements.txt>
>> _______________________________________________
>> EME mailing list

EME mailing list