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

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

Hi Ken,

You say that  

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

Thanks,
Anna 

-----Original Message-----
From: ken carlberg [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 9:58 AM
To: Jozef Babiarz
Cc: [email-masked]
Subject: Re: [PCN] draft-chan-pcn-problem-statement-00.txt

Joe,

> 1./ The routers can signal pre-congestion level(s) via ECN bits in IP 
> header to egress hosts and egress hosts really this information to 
> ingress hosts to reduce their sending rate if they can (use a lower 
> rate codec). However, this does not totally solve the problem.
> 2./ The network is engineered so that there are sufficed spare 
> resources available that should a router or link fail, that traffic is

> rerouted on to the spare resources. Again this does not totally solve 
> the problem because there maybe multiple failures, etc.

understood.  perhaps in the next iteration of the architecture document
these can be more prominently placed/discussed so that it is seen as the
same "level" as preemption.

> Pre-emption is the last resort mechanism that removes real-time 
> inelastic flows to bring that service class back into non-congested 
> state.  It will be interesting what guidelines/rules the FCC and other

> regulatory bodies will provide/use should an operator be forced to 
> preempt m number of voice flows in the IP network? My take is that it 
> would be similar to what is done in TDM networks today when a TDM 
> switch or trunk fails and calls are lost.

well, within the context of the US PSTN, when such a condition exists
and calls are lost, other existing calls on other switches are not
preempted when the system tries to re-establish lost calls.  When
capacity has reached its limit, additional call attempts are blocked.

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.  In the US and some other countries, this is not
allowed in the PSTN.  I also don't claim to be an expert on the FCC, but
recent rulings regarding 911 service for certain VoIP providers would
seem that they intend to extend existing regulations from PSTN to
certain VoIP providers.

-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

---

From: ken carlberg <[email-masked]>
Date: Tue, 19 Sep 2006 12:13:59 -0400

Anna,

> 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

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

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 19 Sep 2006 17:26:22 -0400

Ken:
Thank you for handling so many of our replies at the same time. :)

>original note, seems will be done.

We are using the Problem-Statement draft to put out an initial version of what
we are thinking, as this is still work in progress, there definitely 
are area we
may have missed.

Thank you for pointing out at least one of them.

I will write some additional text for -01 version of the Problem 
Statement draft to try
and describe the problem you have indicated (but I will try NOT to 
indicate any solution
in the Problem Statement draft).

And we will try to have some text in at least some of our Deployment 
Model drafts
to see if there are good solutions to the problem you indicated.  There may be
more than one solution as there may be more than one Deployment Model.

Please Notice I have changed the subject of the E-Mail thread for 
issue tracking purpose.
Please use this E-Mail Subject for continuing this discussion.

Now I have additional questions concerning the use of Preemption for 
handling Emergency
Services.  Will Preemption be allowed for Emergency Services?  Does some of the
jurisdiction you have indicated want to use a separate network for 
Emergency Services
purpose?  Will combining Emergency Services with the normal VoIP calls/sessions
be a good Problem Statement that we can add to our Problem Statement draft?

I am concentrating on Problem Statement instead of Solutions for now because we
want to get the Problem Statement cleared away first for the BOF purpose.

Thanks!
-- Kwok --

---

From: ken carlberg <[email-masked]>
Date: Wed, 20 Sep 2006 10:09:32 -0400

Kwok,

> Now I have additional questions concerning the use of Preemption  
> for handling Emergency
> Services.  Will Preemption be allowed for Emergency Services?

My understanding is that Japan provides a measure of preemption for  
its 911-type service. However, I don't know the specifics and can't  
offer any more insight.  One thing to keep in mind is that the 911- 
type system is inherently an any-to-one (any user to PSAP/911- 
operator) model.

As mentioned earlier, the US (and some other countries) have a system  
called GETS that focuses on increasing the probability of call  
completion over their PSTN.  This represents an an-to-any model.   
There is also the Wireless Priority System (WPS) in the US that  
allows "displacement" of other users *during* call setup, versus a  
call that has been established.  People can google GETS and WPS for  
more info.

> Does some of the
> purpose?

Yes, AUTOVON is one example.  Other examples are Land Mobile Radio  
(LMR) systems used by first responders.  From the IP perspective, the  
bulk of the LMR infrastructure is at Layer 2, but IP providers and  
vendors are starting to infuse IP into those systems.  The key thing  
to keep in mind is that these are systems that are under a single  
administrative authority (ie, a single domain).

> Will combining Emergency Services with the normal VoIP calls/sessions

Well, I would view Emergency Services as mostly one motivation for  
what you are trying to accomplish.  Aspects like rapid recovery,  
prioritization/labeling/coloring of flows, etc. would seem to be of  
interest to those dealing with emergencies or some other condition.

-ken

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 20 Sep 2006 12:06:49 -0400

Ken:
I think you brought up couple of points below.
My interpretation is:
1. There is a need for 911 type (999 in UK?) of calls to get through 
in a public network.
     Hence 911 type of calls may be allowed to be admitted while 
normal calls get preempt
     as a start of a problem statement.
2. There is a need for dedicated emergency service networks to allow 
flow/session preemptions.
3. There is a need to allow flow/session preemptions when Emergency 
Service Networks and
     General Public Networks share network resources.

Each may have a different affect to the mechanism and solution space 
we want to work on
in the PCN BOF/WG.

Please correct me if I mis-understand or missed your points.

Thank you very much for your insights.
-- Kwok --

At 10:09 AM 9/20/2006, ken carlberg wrote:
>type system is inherently an any-to-one (any user to PSAP/911- operator) model.
>

---

From: <[email-masked]>
Date: Wed, 20 Sep 2006 17:40:44 +0100

I'm not sure, but I think maybe the scope is drifting outside what I
envisaged the scope of the PCN flow pre-emption mechanism.

I don't think it's about: when an emergency call arrives, pre-empting a
normal call because the new call would overload the network.
This is something that might be done, of course - just I don't think
it's in the scope of PCN.

My view is that PCN is about "the network" realising that it's
overloaded, and by how much, and providing this info [typically] to the
relevant ingress node of the PCN-region. this node can then take action
based on this info, ie decide which flows to pre-empt. My view is that
the scope is really about how to provide the information, rather than
detailing the action that should be taken.

Agree?

phil

-----Original Message-----
From: Kwok-Ho Chan [mailto:[email-masked]] 
Sent: 20 September 2006 17:07
To: ken carlberg
Cc: [email-masked]
Subject: Re: ProblemStatement Issue B.9:Call Preemption Not
AllowedIssue. Used to be Re: [PCN]
draft-chan-pcn-problem-statement-00.txt

Ken:

operator) model.

---

From: ken carlberg <[email-masked]>
Date: Wed, 20 Sep 2006 12:51:02 -0400

> 1. There is a need for 911 type (999 in UK?) of calls to get  
> through in a public network.
> 2. There is a need for dedicated emergency service networks to  
> allow flow/session preemptions.

no, I'm not saying the above at all.  and in fact given the snapshot  
of today, quite the opposite.  the fact that only one country has a  
form of preemption for 911-type calls and most other countries do not  
implies there is no (or very little) current need for preemption in  
support of 911-type communications.

the fact that there are some deployments of GETS-like service that  
focus on increasing probability of call completion *without* the use  
of preemption of existing calls implies that there is a need for a  
solution space other than preemption.  this is of course under the  
context of infrastructure being shared by the general public and  
first responders (emergency related personnel).

In private networks like AUTOVON, LMR, etc, there is a need/desire  
for the option of preemptive action.  but these are systems that are  
closed and usually under a single administrative authority, which  
seems out of scope (or outside) the default inter-domain model of the  
Briscoe architecture draft.

-ken

---

From: ken carlberg <[email-masked]>
Date: Wed, 20 Sep 2006 12:54:16 -0400

> detailing the action that should be taken.

I feel comfortable with this characterization, though I would change  
the term "ie" with "eg" :-)

-ken

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 20 Sep 2006 13:10:30 -0400

Phil:
I am not addressing the specific mechanism or the solution that we 
may be able to do.

But the ability of the mechanism we are working on should be able
to satisfy/address the problem indicated (and I think it can, as you 
pointed out)
wrt emergency service usage.

Hence then why is this out of scope for the Problem Statement draft
(I am not (I am refraining myself from) talking about solutions)?
We are not working on providing the exact way to solve the emergency usage.
But we want to make sure the network mechanism we come up with can be
used by emergency service for emergency service deployment usage.

Do you think that is the right thing to do in the Problem Statement draft?
(Again, I am just talking only about the Problem Statement draft.)

Should we take these discussions as inputs to help us formulate the WG?
And hopefully get more support for the BOF to become a WG?

Thanks!
-- Kwok --

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 20 Sep 2006 13:51:47 -0400

Ken:
Thanks for the clarification!

On your last point.
The Inter-Domain Model of the Briscoe CL Architecture draft is one of a couple
of "Deployment Model"/"Framework"/"Architecture" drafts we are proposing to
work on in the PCN WG.
Please see http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt that we
are indicating we will work on at least 2 deployment models in item 2 under
Informational drafts the PCN WG plans to produce.

We are not ruling out that other Framework/Architecture can or can not handle
the problem you are indicating.

Hence the network Interior Node (switches or router) function/mechanism we are
standardizing can be used to provide network information for the End Nodes
(edge routers or proxies or end systems) to make the appropriate decisions
(may they be admission control or preemption decisions).

And I hope you will support us in creating this WG and further hope 
you can invest
some sweat equity in this WG.

Thanks!
-- Kwok --

---

From: Bruce Davie <[email-masked]>
Date: Wed, 20 Sep 2006 14:48:50 -0400

> detailing the action that should be taken.

yes, I agree.

I think the main take-away from this discussion is that if you have  
an architecture that *mandates* pre-emption, it may not be possible  
to deploy it in some regulatory environments. Thus it would seem wise  
if PCN tries to produce an architecture in which pre-emption is  
possible but not mandatory. Beyond that, I'm not sure how much we  
need to discuss all the different flavors of emergency calls etc,  
which seems more well-suited to the IEPREP WG.

Bruce

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 20 Sep 2006 15:01:50 -0400

Phil:
>detailing the action that should be taken.

I totally agree on the point of the network providing the information as the
scope of the PCN WG (this is what we want to standardize).
And that the decision + action can be separate.
And we may not specifically solve the emergency service deployment
solution here in PCN WG.

But the discussion we have so far is of value to how we put together
the Problem Statement draft.
For example, our work in PCN WG does (should) not stop the emergency
services community to use the network mechanism we standardize to
provide an emergency service solution.
We should try to help if we can (and I think we can without deviating from
our other goals).

Thanks!
-- Kwok --

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 20 Sep 2006 14:05:10 -0500

>detailing the action that should be taken.

Philip (and all)

there are several aspects of this that need to be brought up, if any 
are.  Consider this:

if "the network" is to "tell" the ingress node it is overloading the core 
by admitting additional packets, is this with a WFQ, or RED or FIFD 
(first-in, first-dropped) type of mechanism - until there is no more 
overload caused by this node?

If packets are to be dropped:

- are some more important than others?

- are some to be considered part of a flow, where others are to be 
considered part of another flow?

- are pacekts to be considered part of a flow (i.e. a call) at all, or is 
it first-in, first-dealt--with?

If flows (meaning the packets associated with the call between Alice and 
Bob are different than the packets associated between Carol and Dave) are 
to be treated differently (i.e. packets from one flow are dropped and 
packets from a parallel flow are not), how is this indicated and loarned by 
the ingress node?

MLEF certainly isn't the answer I hope.

Next aspect is wrt emergency calling, what's the indication that Alice's 
call is to an emergency response center, and Bob's is not (at the ingress 
node)?

Without the ability to identify emergency calls from non-emergency calls, 
talking about emergency calling getting any preferential treatment is 
pointless.

Next aspect, how is the layer 3 mechanism of packet drops bubbled up to the 
signaling layer? Or does the affected user(s) just realize their quality is 
getting poorer?

Since the ingress node is not the endpoint within any flow, does this 
ingress node provide any feedback to the originator of the packet(s)? Or is 
this merely expected to be learned through the normal course of dropped 
packets within any network?

Final aspect, if how to differentiate one flow from another flow is 
possible, how does this BoF's effort solve for how this is not hacked and 
misused for a game of Doom 3 or Quake 4 between users?

IMO, anything from this BoF should address (at least in requirements) these 
"aspects" to be addressed in any solution from those requirements.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 21 Sep 2006 08:41:39 +0200

Hi Phil,

I too agree. 

Regards, 

Rudiger

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]]
|Sent: Wednesday, September 20, 2006 6:41 PM
|To: [email-masked]; [email-masked]
|Cc: [email-masked]
|Subject: RE: ProblemStatement Issue B.9:Call Preemption Not
|AllowedIssue. Used to be Re: [PCN]
|draft-chan-pcn-problem-statement-00.txt
|
|
|I'm not sure, but I think maybe the scope is drifting outside what I
|envisaged the scope of the PCN flow pre-emption mechanism.
|
|I don't think it's about: when an emergency call arrives, pre-empting a
|normal call because the new call would overload the network.
|This is something that might be done, of course - just I don't think
|it's in the scope of PCN.
|
|My view is that PCN is about "the network" realising that it's
|overloaded, and by how much, and providing this info [typically] to the
|relevant ingress node of the PCN-region. this node can then take action
|based on this info, ie decide which flows to pre-empt. My view is that
|the scope is really about how to provide the information, rather than
|detailing the action that should be taken.
|
|Agree?
|
|phil
|
|-----Original Message-----
|From: Kwok-Ho Chan [mailto:[email-masked]] 
|Sent: 20 September 2006 17:07
|To: ken carlberg
|Cc: [email-masked]
|Subject: Re: ProblemStatement Issue B.9:Call Preemption Not
|AllowedIssue. Used to be Re: [PCN]
|draft-chan-pcn-problem-statement-00.txt
|
|Ken:
|I think you brought up couple of points below.
|My interpretation is:
|1. There is a need for 911 type (999 in UK?) of calls to get through 
|in a public network.
|     Hence 911 type of calls may be allowed to be admitted while 
|normal calls get preempt
|     as a start of a problem statement.
|2. There is a need for dedicated emergency service networks to allow 
|flow/session preemptions.
|3. There is a need to allow flow/session preemptions when Emergency 
|Service Networks and
|     General Public Networks share network resources.
|
|Each may have a different affect to the mechanism and solution space 
|we want to work on
|in the PCN BOF/WG.
|
|Please correct me if I mis-understand or missed your points.
|
|Thank you very much for your insights.
|-- Kwok --
|
|
|At 10:09 AM 9/20/2006, ken carlberg wrote:
|>Kwok,
|>
|>>Now I have additional questions concerning the use of Preemption
|>>for handling Emergency
|>>Services.  Will Preemption be allowed for Emergency Services?
|>
|>My understanding is that Japan provides a measure of preemption for
|>its 911-type service. However, I don't know the specifics and can't
|>offer any more insight.  One thing to keep in mind is that the 911- 
|>type system is inherently an any-to-one (any user to PSAP/911-
|operator) model.
|>
|>As mentioned earlier, the US (and some other countries) have a system
|>called GETS that focuses on increasing the probability of call
|>completion over their PSTN.  This represents an an-to-any model.
|>There is also the Wireless Priority System (WPS) in the US that
|>allows "displacement" of other users *during* call setup, versus a
|>call that has been established.  People can google GETS and WPS for
|>more info.
|>
|>>Does some of the
|>>jurisdiction you have indicated want to use a separate network for
|>>Emergency Services
|>>purpose?
|>
|>Yes, AUTOVON is one example.  Other examples are Land Mobile Radio
|>(LMR) systems used by first responders.  From the IP perspective, the
|>bulk of the LMR infrastructure is at Layer 2, but IP providers and
|>vendors are starting to infuse IP into those systems.  The key thing
|>to keep in mind is that these are systems that are under a single
|>administrative authority (ie, a single domain).
|>
|>>Will combining Emergency Services with the normal VoIP calls/sessions
|>>be a good Problem Statement that we can add to our Problem
|>>Statement draft?
|>
|>Well, I would view Emergency Services as mostly one motivation for
|>what you are trying to accomplish.  Aspects like rapid recovery,
|>prioritization/labeling/coloring of flows, etc. would seem to be of
|>interest to those dealing with emergencies or some other condition.
|>
|>-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
|