Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Usedto be Re: [PCN] draft-chan-pcn-problem-statement-00.txt

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Wed, 20 Sep 2006 13:56:50 -0400

Hi Stuart,

I think you are referring to giving scheduling/dropping priority to
packets based on call precedence - right?

Of course that could be done and there is obviously a large body of work
on that (i.e. MLEF-related) - but one of the assumptions that has been
made in the PCN context is that precedence information may not be
available in the core.

There is also an issue that even if you could do that,  in the case
where we assuming the need of preemption in he PCN context (e.g. massive
failure) ther may exist a level of precedence that "does not fit" in the
bandwidth left over to it.  So in that case one has a choice of
affecting the QoS of *all* flows at that level of precedence, or
preempting some while guaranteeing the necessary QoS to those that
remain.

Anna

-----Original Message-----
From: GOLDMAN, STUART O (STUART) [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 1:38 PM
To: Kwok-Ho Chan; Shahram Davari
Cc: [email-masked]; ken carlberg
Subject: RE: ProblemStatement Issue B.9:Call Preemption Not
AllowedIssue. Usedto be Re: [PCN]
draft-chan-pcn-problem-statement-00.txt

Kwok-Ho,
While you seem to have only mentioned preemption, there should be ways
to recognize a call deserving higher than normal preference and giving
it that preference to the remaining network resources without having to
preempt a call in progress. Yes?

Stuart Goldman
Lucent Technologies
[email-masked]
602 493 8438

-----Original Message-----
From: Kwok-Ho Chan [mailto:[email-masked]]
Sent: Wednesday, September 20, 2006 8:54 AM
To: Shahram Davari
Cc: [email-masked]; ken carlberg
Subject: RE: ProblemStatement Issue B.9:Call Preemption Not
AllowedIssue. Used to be Re: [PCN]
draft-chan-pcn-problem-statement-00.txt

Shahram:
I totally agree.
The cell phone network was also jammed during 9/11.
I was trying to reach my brother who were stuck in the subway
~2 stops from WTC.
So I know exactly how this feels like.  But I prefer to let the Police
and Firemen to use this resource to help the general public at large.

The question becomes:
- Does the Emergency Services want to use the same physical network as
the general public?
-- If Yes.  Then should the problem statement becomes:
    "Some controlled preemption functionality is allowed for Emergency
purposes in the general
    public integrated (voice, video, data, etc) network.  This
controlled preemption functionality
    needs to be supported by the network mechanisms."
-- If Yes.  Then we will need some guidance and help wrt the regulations
of the different jurisdictions.
    Also if the different jurisdictions even wants to use the same
network infrastructure for both
    emergency and public usage purposes.  If it is technically possible.

By this I am not saying a good solution exist or that I am promoting a
specific solution.
I am just agreeing that this problem needs to be addressed.
We may end up saying we can not solve this problem as of yet.  But I
wish we can solve it.

Regards.
-- Kwok --

At 09:34 AM 9/20/2006, Shahram Davari wrote:
>Kwok,
>
>Indeed you raised a good subject. The requirements for emergency 
>services should be part of the problem statement, and be dealt with in 
>the proposed solution draft. ITU-T has quite extensive work on the 
>requirements for Emergency services.
>
>On a side note, one of the problems identified during a recent school 
>shooting in Canada was that the emergency and police couldn't use the 
>phone or cell phones to communicate because the network was jammed due 
>to high volume of calls between students and their families.
>
>Yours,
>Shahram
>
>
> > -----Original Message-----
> > From: Kwok-Ho Chan [mailto:[email-masked]]
> > Sent: Tuesday, September 19, 2006 5:26 PM
> > To: ken carlberg
> > Cc: [email-masked]
> > Subject: ProblemStatement Issue B.9:Call Preemption Not Allowed
Issue.
> > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt
> >
> >
> > Ken:
> > Thank you for handling so many of our replies at the same time. :)
> >
> > YES, on your point of:
> >
> > >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.
> >
> > 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 --
> >
> > At 12:13 PM 9/19/2006, ken carlberg wrote:
> > >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
> >

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

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

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