Subject: Re: [EME] First cut at eme requirements

From: Mark Baugher <[email-masked]>
Date: Fri, 1 Dec 2006 15:46:56 -0800

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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/eme

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

---

From: "Paul Francis" <[email-masked]>
Date: Mon, 4 Dec 2006 11:38:43 -0500

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?

PF

-----Original Message-----
From: Mark Baugher [mailto:[email-masked]] 
Sent: Friday, December 01, 2006 6:47 PM
To: Paul Francis
Cc: eme
Subject: Re: [EME] First cut at eme 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.
>

---

From: Mark Baugher <[email-masked]>
Date: Mon, 4 Dec 2006 15:24:22 -0800

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

Mark

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 5 Dec 2006 11:20:16 -0500

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.

PF

-----Original Message-----
From: Mark Baugher [mailto:[email-masked]] 
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:

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

Mark

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

---

From: Mark Baugher <[email-masked]>
Date: Tue, 5 Dec 2006 12:29:28 -0800

> My feeling is that we should make a good effort to achieve 1 and 2,  

I don't think we want 3, either.  In hindsight, "does not disrupt" is  
a poor choice of words.  Tolerance to path change probably  
distinguishes one EME protocol from another.  Some EME protocols may  
be able to support the operational needs of more types of EME  
applications than others.  This is starting to sound more like an  
observation than a requirement to me, but as an example, an EME  
protocol might enable a middlebox to participate in the end-to-end  
security association in some way.  In this case, it might be okay for  
the endpoint and a middlebox to do an authenticated Diffie-Hellman  
once per session but no more.  So long as the middlebox that is  
incident to the new path is in the same security domain as the  
previous one, redundant or hot-failover is easily done.  If they are  
not in the same security domain, then endpoint policy probably would  
require that the new middlebox be completely authenticated.  In this  
case, a protocol that accomplishes the original goal without a  
relatively-slow crypto operation in response to path change would be  
preferred.

Mark
> providing