Subject: RE: [PCN] draft-chan-pcn-problem-statement-00.txt

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Tue, 19 Sep 2006 13:19:16 -0400

Hi Ken,

First,  thanks for the explanation.  I think that we are in agreement
that pre-emtion is not an obligatory mechanism, and hence if there are
circumstances when I should not be iused for regulatory reasons then one
should not use it in those cases.  So we should make sure we make this
clear, and we should definitely discuss and understand regulatory
limitations to the use of preemption.

On your quetsion on why one may wantto have preemption at a higher level
than admission and whether that means additional granularity at the
edges (the answer to the latter is no). One way to look at it is as
follows.  One could assume that in many (most?) cases,  voice traffic is
using scheduling priority at the router, and that the provisioned amount
of this kind of traffic is limited to some amount (e.g. 50% of the link
spped as was widely assumed in the DiffServ EF work). In case of a
failure or multiple failure, unless the network is fully provisioned to
accommodate it, the total amount of traffic on a some link where traffic
is rerouted may be over the link speed (this can easily happen in the
case of a node failure if indeed all links are 50% utilized under normal
conditions).  So the question then is whether one wants to limit the
traffic on the new link to the same 50% limit (which in the case of
preemption would mean prempting at least 50% of the flows on the new
link), or whether perhaps a milder reaction is appropriate.  One can
conceivably decide to not preempt any voice flows at all unless ther is
more than, say 80% voice calls on the link). Obviously this is a
configurable value.  This is consistent with the view that preemption
should only be used when things realy go bad, and in case of mild
overloads of configured/provisioned "normal" loads one may not want to
use preemption at all.  Note that the state needed at the edge does not
depend on the level of preemption/cac - it is just setting of the
cac/preemption threshold at the internal router.

Hope that makes it clearer?

Anna 
-----Original Message-----
From: ken carlberg [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 12:14 PM
To: [email-masked]
Subject: Re: [PCN] draft-chan-pcn-problem-statement-00.txt

Anna,

>> maybe we have a different perspective of preemption.  as I view it, 
>> preemption is removing *existing* state (circuit in the PSTN
>> world) in
>> favor of new state.
>
> I guess that may be one thing that needs clarification.  The way I 
> view it (and I think the way draft-chan-pcn-problem-statement-00.txt 
> and related docs view the issue) is that pre-emption should kick in 
> when for whatever reason provisioning mechanisms fail there simply is 
> not enough capacity to carry all calls.  Setting aside the issue of 
> precedence for the moment, the expectation is that the level of 
> traffic needed to trigger premption is typicaly higher (perhaps 
> substanially higher) than the level triggering to stop admission of 
> new flows.  That means that when preemption does get triggered, there 
> would actually not really be any new state admitted.

I'm sorry, but with that last sentence you lost me :-)...I kind of
understood some of the things you were saying, but there were too many
things you left out (why does one have an admission control at level X
and a preemption level at X+N?, are you implying that the edge is
keeping track of the flows it rejects?....that would seem quite granular
in keeping measurements).

I'm not sure its necessary to clarify the above.  Its probably just best
that we agree that future work should include a more detailed discussion
of what is preemption in the context of your architecture.

> The degree of how far apart preemption and admission thresholds are is

> of course a mater of configuration, but I would expect that they would

> be sufficiently apart to ensure that you do not just toggle preempted 
> and new flows. Of course if there are higher precedence calls, then 
> one might expect that a higher precedence call may be established 
> while lower precedence calls may need to be preempted?
>
> Perhaps this expectation should be made more transparent in the 
> drafts?
>
>> In the US and some other countries, this is not allowed in the PSTN.
>
> Just wanted to make sure I understand exactly what is not allowed.   
> Are
> you saying that PSTN is not allowed to preempt a lower precedence call

> in order to establish a high recedence call?  Or are you referring to 
> the same precedence levels?

as an example, in the US PSTN, all calls from the general public are
treated with the same level of precedence.  the exception are systems
like GETS, but they simply increase the probability of call completion
-- they do not use preemption.  private systems based on MLPP, like
Autovon in the DoD and NATO, do allow different levels of priority and
subsequent preemption if so needed.  rfc-4190 and
rfc-4542 provide background on these systems/services along with
discussion in the context of IP (since this is the IETF :-)

just to recap.  I just wanted to point out that there are jurisdictions
that do not allow preemption for voice communications used by the
general public -- this definitely applies for a number of PSTNs, and I'm
sure it will trickle down to certain deployments of VoIP.  Hence, I
would recommend that the group consider other (re) actions other than
preemption....which from the feedback of my original note, seems will be
done.

regards,

-ken

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

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