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

From: "Garcia, Nuno" <[email-masked]>
Date: Wed, 27 Sep 2006 09:58:01 +0100

Hi all:

I'm sorry to jump in, I've been waiting for some free time to read all the materials with due attention, but since you're bringing this on, IMHO we should consider using self-similarity measurement statistics, e.g. the Hurst parameter, since it is well known that self-similar bursty traffic does not behave well for statistics such average or variance.

Cheers,

Nuno Garcia
SIEMENS S.A.
INFORMATION and COMMUNICATIONS * RESEARCH and DEVELOPMENT 1 * RESEARCH 

Rua Irmãos Siemens, 1
Ed. 1, Piso 0
Alfragide
2720-093 Amadora
Portugal 

Phone: +351-21 416 7159
Fax: +351-21 424 2082 
e-mail: [email-masked] 

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: quarta-feira, 27 de Setembro de 2006 9:25
To: [email-masked]
Cc: [email-masked]
Subject: RE: ProblemStatement Issue B.9:Call Preemption NotAllowedIssue.Used to be Re: [PCN]draft-chan-pcn-problem-statement-00.txt

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.
>
> 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
> |
>
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pcn
>   

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

_______________________________________________
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