Subject: Re: [Ieprep] Preemption

From: Fred Baker <[email-masked]>
Date: Fri, 22 Mar 2002 14:08:30 -0600

At 06:29 PM 3/18/2002, Beard, Cory wrote:
>How does this translate to packet-level dropping policies in IP?  It seems 
>to me that RED could be seen as a form of preemption.  Should we be on 
>record as not supporting RED, or should a distinction be made between 
>call-level preemption and packet-level preemption?

It's pre-emption, yes, but pre-emption of something other than what gets 
pre-empted in telco implementations. MLPP pre-emption, if implemented, is 
pre-emption of a call, which is an entire traffic stream. RED, from a VoIP 
perspective, is a random noise generator inserted in the circuit, whose 
effect is determined primarily by the competing traffic and the random 
number generator.

Personally, if I were someone trying to specify the behavior of a network 
for VoIP, I would want to know that I was implementing something that the 
best minds in the business agreed would provide good service for me. EF is 
that recommendation. I would want to have this working group specify its 
use. RFC 3246 talks about loss, and fundamentally says "it should not be 
the normal practice, apart from senders whose traffic doesn't conform to 
the service specification; a service which regularly loses conformant EF 
traffic does not conform to the EF specification." Specifying a change to 
it without a comparable level of modeling and testing to what was done to 
develop RFC 3246 seems unwise at best. You have no idea what effect your 
changes will have.

>IMHO we just should take no position about preemption in the framework 
>document.

I personally agree, if you're talking about call pre-emption. The framework 
should indicate that there will be policies applied in various networks, 
and that the exact structure of the policy is a matter of service offering 
and contract between the network provider and its customers. Pre-emption or 
lack of it is a policy which would be applied in a specific network, and on 
this list there has been discussion both of a network that does use it and 
a network that doesn't use it.

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

---

From: Ken Carlberg <[email-masked]>
Date: Sun, 24 Mar 2002 14:45:27 +0000

> a network that doesn't use it.

as it is written now, the Framework document takes the position that
non-preemptive service is the default service or mode of operation.  

there were a couple of thoughts behind this approach.  the current
deployed effort in IP telephony does not support pre-emption.  hence,
using this installed base as the default model would seem to be a nice
starting point -- much in the way that the inclusion of new service
models in IP still led the IETF to take the position that best effort
is the default service model for IP.

it also seemed that pre-emptive service in non-private networks involves
a combination of local law/regulation as well as additional mechanisms
that go beyond just labeling.  so, if we state that if for some reason a
lack of policy exists in a network for the received label, then the
default action taken should be non-preemptive.  thereby further
reinforcing the distinction between label and the action taken upon it.

i believe the framework document already articulates what Fred says
above about policies, but i'll double check to make sure.

-ken

---

From: "Stuart (Stu) Goldman" <[email-masked]>
Date: Sun, 24 Mar 2002 20:40:53 -0700

Ken,

If I correctly understand what you have written, you are suggesting non
pre-emption is the default, but are not preventing pre-emption (but not as the
default) in those networks where it might be desired.

This sounds like an approach that everybody should be able to live with.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 25 Mar 2002 12:18:19 -0600

>This sounds like an approach that everybody should be able to live with.

I like this approach

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com