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

From: Shahram Davari <[email-masked]>
Date: Wed, 20 Sep 2006 06:34:31 -0700

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

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 20 Sep 2006 11:54:28 -0400

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

---

From: "GOLDMAN, STUART O \(STUART\)" <[email-masked]>
Date: Wed, 20 Sep 2006 12:37:48 -0500

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 question becomes:

Regards.
-- Kwok --

---

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

Stuart:
Preemption is just one of possibly multiple decisions the End Node function
can take.
Hence you are right that there may be other decisions that is of value to the
system as a whole, possibly depending on the deployment evironment.

These discussions we have so far indicates that we may not want to call
the network information the Interior Nodes are providing as "Preemption Mark"
indication.

Hence these discussions are very helpful for our BOF/WG.

Thanks!
-- Kwok --

---

From: "GOLDMAN, STUART O \(STUART\)" <[email-masked]>
Date: Sun, 24 Sep 2006 18:34:35 -0500

Kwok,

Sorry to have taken so long to respond, but my day job got in the way. 

As I understood the topic, we are addressing pre-congestion. In that
light, I assumed that congestion has not yet occurred, but that we are
approaching congestion. So, I further assumed that there was still some
capacity available, although this remaining capacity needs to be
conserved as best as possible.

Am I am the right wavelength?

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

-----Original Message-----
From: Kwok-Ho Chan [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 10:58 AM
To: GOLDMAN, STUART O (STUART)
Cc: Kwok-Ho Chan; Shahram Davari; [email-masked]; ken carlberg
Subject: RE: ProblemStatement Issue B.9:Call Preemption Not

Stuart:
Preemption is just one of possibly multiple decisions the End Node
function
can take.
Hence you are right that there may be other decisions that is of value
to the
system as a whole, possibly depending on the deployment evironment.

These discussions we have so far indicates that we may not want to call
the network information the Interior Nodes are providing as "Preemption
Mark"
indication.

Thanks!
-- Kwok --

At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote:
> > > >used by the general public -- this definitely applies for a
number
>of
> > > >used by the general public -- this definitely applies for a
number
>of

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Mon, 25 Sep 2006 11:29:35 -0400

Stuart:
No problem.
By "Pre-Congestion", we mean:
"if additional IP packet traffic is admitted (into the traffic class 
handling this traffic),
then already admitted traffic (of the same traffic class) will 
experience degraded QoS.
This degraded QoS happens at specific nodes (or diffserv hops) of the 
end-to-end path
because we are working with IP packet network.  This degraded QoS may 
affect the
end-to-end service required of the network by the Using Application."

Of course there are many factors that defines what is (and what is 
not) acceptable
"degraded QoS" and how much additional traffic will cause the degraded QoS to
be not acceptable, for example:
- the Using Application and the requirements it have on the network.
--- hence we are looking at inelastic, interactive, Real-Time use of 
the network (first).
- the ratio of the total shared (by the traffic class) network 
resource at specific network
   nodes with respect to each admitted traffic flow and each 
to-be-admitted traffic flow.
   This indicates how each additional traffic flow over some limit 
will impact already
   admitted traffic flows.  In both space and time dimensions.
--- hence we are looking into amount of network resource, e.g. size 
of network pipes.
     We first look at the easier one (we think), large network 
pipes.  Then the harder ones
     of smaller and smaller network pipes.
- the characteristic of the traffic flows, for example are they 
constant bit rate?  Or close
   to constant bit rate?, etc.
- the promised service to the Using Application.
   On this Issue B.9, we are talking about promised service of NO PREEMPTION
    (but may be with some condition).

As you indicated, the network resource we are discussing allows 
provisioning of
detection before congestion, before the packet forwarding queues gets 
backed up.
And we want to have some capacity still available (this may be view 
as one of the
ways on HOW we can do this).  But you are right that we may need to conserve
this head-room capacity, but again depending on for what reasons.
Is it because we can not preempt any admitted flows?
Is it because we need to handle emergency services?
Is it because we need to handle none-constant bit rate traffic?
Some other reasons or combinations of them?

These are still topics of discussions and additional work we hope we 
can do together
in this WG (hopeful result of the PCN BOF).

Sorry for such a long reply, just want to indicate some of the 
thinkings I have and
working toward/down the path of agreements.
Thanks!
-- Kwok --

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 26 Sep 2006 09:28:46 +0200

Kwok, Stuart,

my take may be a slightly different one. PCN allows to mark packets once
a settable load level has been reached on a particular link and prior to
any of these packets being discarded due to the traffic rate crossing a
second settable rate. 

The former of both rates is the admissible link rate or
configured-admission-rate. The latter is the supportable link rate or
configured-preemption-rate. My understanding is that PCN doesn't specify
"service" to more detail then demanding CL like performance for admitted
traffic. To reach this aim, the preemption-rate must be chosen
sufficiently bigger than the admission-rate. How the rates are set
exactly is left to operators and depends on the network planning
philosophy applied by each of them and the characteristics of the
traffic being forwarded by PCN. A second condition is that PCN traffic
should consist of a large number of multiplexed flows whose individual
peak rate is small as compared to the admission-rate. What PCN should do
is provide simulation results and measurements prooving that the
mechanism works under todays "common" load and network conditions.
Giving guidance on operational settings for a variety of networks and
traffic mixes to me is a research topic, which is out of scope of the
PCN WG. A BCP may be published, once sufficient "P" is available. 

Regards,

Rudiger

|-----Original Message-----
|From: Kwok-Ho Chan [mailto:[email-masked]]
|Sent: Monday, September 25, 2006 5:30 PM
|To: GOLDMAN, STUART O (STUART)
|Cc: [email-masked]; Shahram Davari; ken carlberg
|Subject: RE: ProblemStatement Issue B.9:Call Preemption Not
|AllowedIssue. Used to be Re: [PCN]
|draft-chan-pcn-problem-statement-00.txt
|
|
|Stuart:
|No problem.
|By "Pre-Congestion", we mean:
|"if additional IP packet traffic is admitted (into the traffic class 
|handling this traffic),
|then already admitted traffic (of the same traffic class) will 
|experience degraded QoS.
|This degraded QoS happens at specific nodes (or diffserv hops) of the 
|end-to-end path
|because we are working with IP packet network.  This degraded QoS may 
|affect the
|end-to-end service required of the network by the Using Application."
|
|Of course there are many factors that defines what is (and what is 
|not) acceptable
|"degraded QoS" and how much additional traffic will cause the 
|degraded QoS to
|be not acceptable, for example:
|- the Using Application and the requirements it have on the network.
|--- hence we are looking at inelastic, interactive, Real-Time use of 
|the network (first).
|- the ratio of the total shared (by the traffic class) network 
|resource at specific network
|   nodes with respect to each admitted traffic flow and each 
|to-be-admitted traffic flow.
|   This indicates how each additional traffic flow over some limit 
|will impact already
|   admitted traffic flows.  In both space and time dimensions.
|--- hence we are looking into amount of network resource, e.g. size 
|of network pipes.
|     We first look at the easier one (we think), large network 
|pipes.  Then the harder ones
|     of smaller and smaller network pipes.
|- the characteristic of the traffic flows, for example are they 
|constant bit rate?  Or close
|   to constant bit rate?, etc.
|- the promised service to the Using Application.
|   On this Issue B.9, we are talking about promised service of 
|NO PREEMPTION
|    (but may be with some condition).
|
|As you indicated, the network resource we are discussing allows 
|provisioning of
|detection before congestion, before the packet forwarding queues gets 
|backed up.
|And we want to have some capacity still available (this may be view 
|as one of the
|ways on HOW we can do this).  But you are right that we may 
|need to conserve
|this head-room capacity, but again depending on for what reasons.
|Is it because we can not preempt any admitted flows?
|Is it because we need to handle emergency services?
|Is it because we need to handle none-constant bit rate traffic?
|Some other reasons or combinations of them?
|
|These are still topics of discussions and additional work we hope we 
|can do together
|in this WG (hopeful result of the PCN BOF).
|
|Sorry for such a long reply, just want to indicate some of the 
|thinkings I have and
|working toward/down the path of agreements.
|Thanks!
|-- Kwok --
|
|
|At 07:34 PM 9/24/2006, GOLDMAN, STUART O \(STUART\) wrote:
|>Kwok,
|>
|>Sorry to have taken so long to respond, but my day job got in the way.
|>
|>As I understood the topic, we are addressing pre-congestion. In that
|>light, I assumed that congestion has not yet occurred, but that we are
|>approaching congestion. So, I further assumed that there was 
|still some
|>capacity available, although this remaining capacity needs to be
|>conserved as best as possible.
|>
|>Am I am the right wavelength?
|>
|>Stuart Goldman
|>Lucent Technologies
|>[email-masked]
|>602 493 8438
|>
|>-----Original Message-----
|>From: Kwok-Ho Chan [mailto:[email-masked]]
|>Sent: Wednesday, September 20, 2006 10:58 AM
|>To: GOLDMAN, STUART O (STUART)
|>Cc: Kwok-Ho Chan; Shahram Davari; [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
|>
|>Stuart:
|>Preemption is just one of possibly multiple decisions the End Node
|>function
|>can take.
|>Hence you are right that there may be other decisions that is of value
|>to the
|>system as a whole, possibly depending on the deployment evironment.
|>
|>These discussions we have so far indicates that we may not 
|want to call
|>the network information the Interior Nodes are providing as 
|"Preemption
|>Mark"
|>indication.
|>
|>Hence these discussions are very helpful for our BOF/WG.
|>
|>Thanks!
|>-- Kwok --
|>
|>
|>At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote:
|> >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
|

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 26 Sep 2006 11:31:33 -0400

Ruediger:
I think we agree on most points, please see inline below for details.
Regards.
-- Kwok --

>any of these packets being discarded due to the traffic rate crossing a

You may want to think of the level/condition at which packets start to be
discarded a third/another load level, for example the policy+drop rate for EF
or the tail drop of a queue or link.  But this is not the same as the second
set-able PCN load level we have been thinking about.

>configured-preemption-rate.

Agree.

>My understanding is that PCN doesn't specify
>traffic being forwarded by PCN.

We are actually working on and have some results on these details.
I have been refraining from diving into details of the HOWs.
We were just focusing on the WHATs and WHYs for the BOF.
May be we should start talking about some details on the mailing list 
before the BOF?

>A second condition is that PCN traffic
>peak rate is small as compared to the admission-rate.

I agree that this is one possibility we should start with wrt 
simulation traffic sources.

>What PCN should do

Agree.  But we are also targeting specific type of traffic flows, 
real-time flows to start.
Hence, we may think of "common real-time flow" load and network conditions.

>PCN WG. A BCP may be published, once sufficient "P" is available.

We don't have such BCP on our proposed WG work item list currently.
So I think we agree.

---

From: "GOLDMAN, STUART O \(STUART\)" <[email-masked]>
Date: Tue, 26 Sep 2006 11:36:27 -0500

Ruediqer,

I think my mental picture is close to your view of having the two level
settings. I would hope that the pre-congestion level while relatively
high still leaves enough excess capacity so that the actions taken are
more likely to prevent the second level from actually being crossed.

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

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: Tuesday, September 26, 2006 12:29 AM
To: [email-masked]; GOLDMAN, STUART O (STUART)
Cc: [email-masked]
Subject: RE: ProblemStatement Issue B.9:Call Preemption Not

Kwok, Stuart,

Regards,

Rudiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 27 Sep 2006 08:20:08 +0200

Stuart,

if "pre-congestion level" is the configured-admission-rate, 
then "leaving enough excess capacity" is, at least from my 
point of view, a planning task. PCN should make sure 
that vendors have sufficient guidance to implement the 
knobs allowing network operators to fulfill this task. 

As I mentioned, what a "relatively high (CL load) level" 
on a particular PCN link is, should for his network 
entirely be the decision of a carrier. As long as the 
SLA's defining the CL service commercially are kept, 
it is nobody else' matter how it is produced.

Regards, 

Rudiger

|-----Original Message-----
|From: GOLDMAN, STUART O (STUART) [mailto:[email-masked]]
|Sent: Tuesday, September 26, 2006 6:36 PM
|To: Geib, Rudiger; [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
|
|
|Ruediqer,
|
|I think my mental picture is close to your view of having the two level
|settings. I would hope that the pre-congestion level while relatively
|high still leaves enough excess capacity so that the actions taken are
|more likely to prevent the second level from actually being crossed.
|
|Stuart Goldman
|Lucent Technologies
[email-masked]
|602 493 8438
|
|
|-----Original Message-----
|From: Geib, Ruediger [mailto:[email-masked]] 
|Sent: Tuesday, September 26, 2006 12:29 AM
|To: [email-masked]; GOLDMAN, STUART O (STUART)
|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
|
|Kwok, Stuart,
|
|my take may be a slightly different one. PCN allows to mark 
|packets once
|a settable load level has been reached on a particular link 
|and prior to
|any of these packets being discarded due to the traffic rate crossing a
|second settable rate. 
|
|The former of both rates is the admissible link rate or
|configured-admission-rate. The latter is the supportable link rate or
|configured-preemption-rate. My understanding is that PCN 
|doesn't specify
|"service" to more detail then demanding CL like performance 
|for admitted
|traffic. To reach this aim, the preemption-rate must be chosen
|sufficiently bigger than the admission-rate. How the rates are set
|exactly is left to operators and depends on the network planning
|philosophy applied by each of them and the characteristics of the
|traffic being forwarded by PCN. A second condition is that PCN traffic
|should consist of a large number of multiplexed flows whose individual
|peak rate is small as compared to the admission-rate. What PCN 
|should do
|is provide simulation results and measurements prooving that the
|mechanism works under todays "common" load and network conditions.
|Giving guidance on operational settings for a variety of networks and
|traffic mixes to me is a research topic, which is out of scope of the
|PCN WG. A BCP may be published, once sufficient "P" is available. 
|
|Regards,
|
|Rudiger
|
||-----Original Message-----
||From: Kwok-Ho Chan [mailto:[email-masked]]
||Sent: Monday, September 25, 2006 5:30 PM
||To: GOLDMAN, STUART O (STUART)
||Cc: [email-masked]; Shahram Davari; ken carlberg
||Subject: RE: ProblemStatement Issue B.9:Call Preemption Not
||AllowedIssue. Used to be Re: [PCN]
||draft-chan-pcn-problem-statement-00.txt
||
||
||Stuart:
||No problem.
||By "Pre-Congestion", we mean:
||"if additional IP packet traffic is admitted (into the traffic class 
||handling this traffic),
||then already admitted traffic (of the same traffic class) will 
||experience degraded QoS.
||This degraded QoS happens at specific nodes (or diffserv hops) of the 
||end-to-end path
||because we are working with IP packet network.  This degraded QoS may 
||affect the
||end-to-end service required of the network by the Using Application."
||
||Of course there are many factors that defines what is (and what is 
||not) acceptable
||"degraded QoS" and how much additional traffic will cause the 
||degraded QoS to
||be not acceptable, for example:
||- the Using Application and the requirements it have on the network.
||--- hence we are looking at inelastic, interactive, Real-Time use of 
||the network (first).
||- the ratio of the total shared (by the traffic class) network 
||resource at specific network
||   nodes with respect to each admitted traffic flow and each 
||to-be-admitted traffic flow.
||   This indicates how each additional traffic flow over some limit 
||will impact already
||   admitted traffic flows.  In both space and time dimensions.
||--- hence we are looking into amount of network resource, e.g. size 
||of network pipes.
||     We first look at the easier one (we think), large network 
||pipes.  Then the harder ones
||     of smaller and smaller network pipes.
||- the characteristic of the traffic flows, for example are they 
||constant bit rate?  Or close
||   to constant bit rate?, etc.
||- the promised service to the Using Application.
||   On this Issue B.9, we are talking about promised service of 
||NO PREEMPTION
||    (but may be with some condition).
||
||As you indicated, the network resource we are discussing allows 
||provisioning of
||detection before congestion, before the packet forwarding queues gets 
||backed up.
||And we want to have some capacity still available (this may be view 
||as one of the
||ways on HOW we can do this).  But you are right that we may 
||need to conserve
||this head-room capacity, but again depending on for what reasons.
||Is it because we can not preempt any admitted flows?
||Is it because we need to handle emergency services?
||Is it because we need to handle none-constant bit rate traffic?
||Some other reasons or combinations of them?
||
||These are still topics of discussions and additional work we hope we 
||can do together
||in this WG (hopeful result of the PCN BOF).
||
||Sorry for such a long reply, just want to indicate some of the 
||thinkings I have and
||working toward/down the path of agreements.
||Thanks!
||-- Kwok --
||
||
||At 07:34 PM 9/24/2006, GOLDMAN, STUART O \(STUART\) wrote:
||>Kwok,
||>
||>Sorry to have taken so long to respond, but my day job got 
|in the way.
||>
||>As I understood the topic, we are addressing pre-congestion. In that
||>light, I assumed that congestion has not yet occurred, but 
|that we are
||>approaching congestion. So, I further assumed that there was 
||still some
||>capacity available, although this remaining capacity needs to be
||>conserved as best as possible.
||>
||>Am I am the right wavelength?
||>
||>Stuart Goldman
||>Lucent Technologies
||>[email-masked]
||>602 493 8438
||>
||>-----Original Message-----
||>From: Kwok-Ho Chan [mailto:[email-masked]]
||>Sent: Wednesday, September 20, 2006 10:58 AM
||>To: GOLDMAN, STUART O (STUART)
||>Cc: Kwok-Ho Chan; Shahram Davari; [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
||>
||>Stuart:
||>Preemption is just one of possibly multiple decisions the End Node
||>function
||>can take.
||>Hence you are right that there may be other decisions that 
|is of value
||>to the
||>system as a whole, possibly depending on the deployment evironment.
||>
||>These discussions we have so far indicates that we may not 
||want to call
||>the network information the Interior Nodes are providing as 
||"Preemption
||>Mark"
||>indication.
||>
||>Hence these discussions are very helpful for our BOF/WG.
||>
||>Thanks!
||>-- Kwok --
||>
||>
||>At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote:
||> >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
|

---

From: Michael Menth <[email-masked]>
Date: Wed, 27 Sep 2006 08:35:50 +0200

Hi Ruediger, Stuart,

I think that the question is the following: How large should the 
admissible and supportable link rates be that QoS can be maintained in 
spite of
(1) bursty traffic
(2) admission errors due to the measurement-based nature of the AC 
(flash crowds)
(3) redirected traffic due to likely network outages like single link 
failures
The answer depends on the traffic model and the link capacity. I think 
this defines plenty of work for academic parametric studies to give 
guidelines for operators. This is a feasible thing to do. We addressed 
issue (3) in previous work for a different NAC approach. If the network 
is configured to copy with (1)-(3), QoS is quite well protected.  And if 
all the assumptions for (1)-(3) fail that were made for the 
configuration, then preemption kicks in, but only then.

Best wishes,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 27 Sep 2006 10:24:52 +0200

Hi Michael

I think that you are right, we need to somehow provide some quantification 
of the overprovisioning, which depends on:
1)  the time until the calls are admtted: If the response time is long, the
overprovisioning is substantial.
2)  the statistics of the aggregated traffic. It will work well with traffic
that have a nice average behaviour.
3)  mass-call events that usually happends in telefony networks.  If the
number of calls suddenly increases, the PCN will not have time to block the
calls.
4) response time for the measurement function.

Best Regards,
Georgios

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: woensdag 27 september 2006 8:36
To: Geib, Ruediger
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

Hi Ruediger, Stuart,

I think that the question is the following: How large should the admissible
and supportable link rates be that QoS can be maintained in spite of
(1) bursty traffic
(2) admission errors due to the measurement-based nature of the AC (flash
crowds)
(3) redirected traffic due to likely network outages like single link
failures The answer depends on the traffic model and the link capacity. I
think this defines plenty of work for academic parametric studies to give
guidelines for operators. This is a feasible thing to do. We addressed issue
(3) in previous work for a different NAC approach. If the network is
configured to copy with (1)-(3), QoS is quite well protected.  And if all
the assumptions for (1)-(3) fail that were made for the configuration, then
preemption kicks in, but only then.

Best wishes,

    Michael

Geib, Ruediger wrote:
> Stuart,
>
> if "pre-congestion level" is the configured-admission-rate, then 
> "leaving enough excess capacity" is, at least from my point of view, a 
> planning task. PCN should make sure that vendors have sufficient 
> guidance to implement the knobs allowing network operators to fulfill 
> this task.
>
> on a particular PCN link is, should for his network entirely be the 
> decision of a carrier. As long as the SLA's defining the CL service 
> commercially are kept, it is nobody else' matter how it is produced.
>
> Regards,
>
> Rudiger
>
> |I think my mental picture is close to your view of having the two 
> |level settings. I would hope that the pre-congestion level while 
> |relatively high still leaves enough excess capacity so that the 
> |actions taken are more likely to prevent the second level from actually
being crossed.
> |my take may be a slightly different one. PCN allows to mark packets 
> |once a settable load level has been reached on a particular link and 
> |prior to any of these packets being discarded due to the traffic rate 
> |crossing a second settable rate.
> |
> |configured-preemption-rate. My understanding is that PCN doesn't 
> |specify "service" to more detail then demanding CL like performance 
> |for admitted traffic. To reach this aim, the preemption-rate must be 
> |chosen sufficiently bigger than the admission-rate. How the rates are 
> |set exactly is left to operators and depends on the network planning 
> |traffic being forwarded by PCN. A second condition is that PCN 
> |traffic should consist of a large number of multiplexed flows whose 
> |individual peak rate is small as compared to the admission-rate. What 
> |PCN should do is provide simulation results and measurements prooving 
> |that the mechanism works under todays "common" load and network 
> |conditions.
> ||handling this traffic), then already admitted traffic (of the same 
> ||traffic class) will experience degraded QoS.
> ||This degraded QoS happens at specific nodes (or diffserv hops) of 
> ||the end-to-end path because we are working with IP packet network.  
> ||This degraded QoS may affect the end-to-end service required of the 
> ||network by the Using Application."
> ||
> ||degraded QoS to be not acceptable, for example:
> ||   On this Issue B.9, we are talking about promised service of NO 
> ||PREEMPTION
> ||provisioning of detection before congestion, before the packet 
> ||forwarding queues gets backed up.
> ||as one of the ways on HOW we can do this).  But you are right that 
> ||we may need to conserve this head-room capacity, but again depending 
> ||on for what reasons.
> ||can do together in this WG (hopeful result of the PCN BOF).
> ||
> ||thinkings I have and working toward/down the path of agreements.
> ||Thanks!
> ||-- Kwok --
> ||
> ||
> ||>As I understood the topic, we are addressing pre-congestion. In 
> ||>that light, I assumed that congestion has not yet occurred, but
> |that we are
> ||>function can take.
> ||> >Police and Firemen to use this resource to help the general 
> ||> >public at large.
> ||> >
> ||> >- Does the Emergency Services want to use the same physical 
> ||> >network as the general public?
> ||> >     Also if the different jurisdictions even wants to use the 
> ||> >same network infrastructure for both
> ||> > >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.
> ||> > >
> ||> > > > >VoIP.  Hence, I would recommend that the group consider 
> ||> > > > >other
> ||>(re)
> ||> > > > initial version of what we are thinking, as this is still 
> ||> > > > work in progress, there
> ||>definitely
> ||> > > > are area we
> ||> > > > indicated.  There may be more than one solution as there may 
> ||> > > > be more than one
> |Deployment
> ||> >Model.
> ||> > > >
> ||> > > > VoIP calls/sessions be a good Problem Statement that we can 
> ||> > > > add to our Problem Statement draft?
> ||> > > >
> ||> > > > for now because we want to get the Problem Statement cleared 
> ||> > > > away first for the BOF purpose.
> ||> > > >
> ||> > > > Thanks!
> ||> > > > -- Kwok --
> ||> > > >
> ||> > > > >>The degree of how far apart preemption and admission 
> ||> > > > >>thresholds are is of course a mater of
> ||> > > > >>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
> ||> > > > >>>In the US and some other countries, this is not allowed 
> ||> > > > >>>in the PSTN.
> ||> > > > >>
> ||> > > > >treated with the same level of precedence.  the exception 
> ||> > > > >are
> ||> >systems
> ||> > > > >VoIP.  Hence, I would recommend that the group consider 
> ||> > > > >other
> ||>(re)

--
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074
Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn