Subject: Re: [Ieprep] Preemption

From: [email-masked]
Date: Mon, 25 Mar 2002 15:50:18 EST

In a message dated 3/24/02 10:44:27 PM Eastern Standard Time, 
[email-masked] writes:

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

I don't understand what "default" means in this case. I think we agree that 
the "normal" or "most common" approach would be to not preempt, but I 
wouldn't describe that as a "default". It depends on the policy of the 
network.

I think it's confusing to talk of a "default" for such a thing. To me, a 
"default" operation only needs to be stated when one needs to say what to do 
if an optional parameter is missing from a received message. For example, 
default to the "Routine" precedence level if the "Resource-priority" header 
is missing.

There still is a confusion over whether you are referring to call preemption 
or packet "preemption" (dropping). Discussion of these two issues needs to be 
kept separate. Yes, call preemption in non-private networks would be subject 
to laws/regulations and, at least in the US, is unlikely to ever be allowed. 
The absence of preemption of calls is probably the presumed operation in any 
IP network. But I can't image a law addressing how we handle packets. It 
would only be a question of maintaining a required QoS level, if "regulated" 
by a tarrif, for example.

My Assured Service draft in SIPPING was explicitly presuming that packet 
level "preemption", through the use of multiple levels of selective dopping 
when congestion occurs, is required as the way to achieve the service 
requirements for the Defense Dept network. Thus, "packet preemption" would be 
the norm in that network. However, I might agree that such packet level 
"preemption" is not required to provide the authorized emergency requirements 
in the public network. But I wouldn't use the term "default".

However, I don't see why this packet level "preemption" by selective dropping 
is considered so bad. Isn't it already the described operation for the AF 
classes (with 3 drop precedences each) which might be used for the signaling 
messages? If some of these packets are dropped, might that actually prevent a 
call from being set-up, that is, look like a failure? In some networks, this 
would be worse than preemption (with its notification).

Mike Pierce