Subject: RE: [PCN] Problem of differentiating packets by flows (i.e. calls)

From: "James M. Polk" <[email-masked]>
Date: Wed, 20 Sep 2006 15:06:38 -0500

Said below:

  "The edge, on the other hand does have the per-flow info, and can then 
make a per-flow based decision on who to preempt/accept based on this info.  "

How will the ingress node have all the necessary information in it to make 
a decision that Alice's call is more important than Bob's?

Will the edge node have access to SIP signaling (for example)? Without this 
(or the like) or without there being a reservation to the ingress dge node 
from the packet originator, what is/are the indicator(s) distinguishing one 
packet from another (meaning one call from another)?

Without this, any discussion of prioritizing one packet over another is 
pointless (which I said in my original email), and probably out of scope of 
PCN.

At 12:47 PM 9/20/2006 -0700, Anna Charny \(acharny\) wrote:
>Hi James,
>
>A few comments/answers below:
>
>-----Original Message-----
>From: James Polk (jmpolk)
>Sent: Wednesday, September 20, 2006 3:05 PM
>To: [email-masked]; [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: [PCN] Problem of differentiating packets by flows (i.e. calls)
>
>At 05:40 PM 9/20/2006 +0100, [email-masked] wrote:
> >I'm not sure, but I think maybe the scope is drifting outside what I
> >envisaged the scope of the PCN flow pre-emption mechanism.
> >
> >I don't think it's about: when an emergency call arrives, pre-empting a
>
> >normal call because the new call would overload the network.
> >This is something that might be done, of course - just I don't think
> >it's in the scope of PCN.
> >
> >My view is that PCN is about "the network" realising that it's
> >overloaded, and by how much, and providing this info [typically] to the
>
> >relevant ingress node of the PCN-region. this node can then take action
>
> >based on this info, ie decide which flows to pre-empt. My view is that
> >the scope is really about how to provide the information, rather than
> >detailing the action that should be taken.
>
>Philip (and all)
>
>there are several aspects of this that need to be brought up, if any
>are.  Consider this:
>
>if "the network" is to "tell" the ingress node it is overloading the
>core by admitting additional packets, is this with a WFQ, or RED or FIFD
>(first-in, first-dropped) type of mechanism - until there is no more
>overload caused by this node?
>
>[Anna]  There is actually no explicit assumptions of the underlying
>queueing that (I think) is necessary.  The overload is defined based on
>the "desired" capacity - e.g. the same capacity that would be
>"provisioned" in, say DiffServ EF context.  The simplest assumption then
>is that the PCN traffic has a queue for itself (could be a priority
>queue or a queue in a WFQ).  A particular solution may use different
>means of implementing the measurement of overload wrt that "desired"
>capacity. E.g. draft-brisco-cl-architecture  offers to do that based on
>the virtual queue.  But that virtual queue is largely independent of the
>underlying queueing/scheduling.
>
>If packets are to be dropped:
>
>- are some more important than others?
>
>- are some to be considered part of a flow, where others are to be
>considered part of another flow?
>
>- are pacekts to be considered part of a flow (i.e. a call) at all, or
>is it first-in, first-dealt--with?
>
>[Anna] There are no assumption that "importance" of packets is known,
>and there are no assumptions that it is known at the core which packets
>belong to which flows.
>
>If flows (meaning the packets associated with the call between Alice and
>Bob are different than the packets associated between Carol and Dave)
>are to be treated differently (i.e. packets from one flow are dropped
>and packets from a parallel flow are not), how is this indicated and
>loarned by the ingress node?
>
>MLEF certainly isn't the answer I hope.
>
>[Anna]  Again, there is explicitly no assumptions that there is info
>available at the core to tell which packets are from Alice and which are
>from Bob, not which of those are more important than others.  The
>assumption is that the core only deals with figuring out whether the
>total (PCN) traffic is above or below the desired level, and
>communicates that info to the edge.  The edge, on the other hand does
>have the per-flow info, and can then make a per-flow based decision on
>who to preempt/accept based on this info.  However, IF
>importance/precedence info is available at the core, then of course
>additional mechanisms ae available.   It seems to me that from the
>BoF/WG standpoint,  discussion of this boils down to work on deployment
>models.  The assumptions relevant to the particular deployment models
>definely have to work with PCN assumptions and mechanism for PCn to be
>viable in those models.
>
>
>Next aspect is wrt emergency calling, what's the indication that Alice's
>call is to an emergency response center, and Bob's is not (at the
>ingress node)?
>
>[Anna]  Some discussion of that is already in the
>draft-briscoe-cl-architecture.  A short answer is repeating the above:
>the ingress node has the flexibility to decide *which* calls to prefer,
>based on the call/flow info available to it.  The core is assumeed to
>not be able to tell Alice from Bob anyway.
>
>Without the ability to identify emergency calls from non-emergency
>calls, talking about emergency calling getting any preferential
>treatment is pointless.
>
>[Anna]  As the ingress has the necessary info to distinguish emergency
>vs non-emergency calls, it can then make the decisions based on that.
>
>Next aspect, how is the layer 3 mechanism of packet drops bubbled up to
>the signaling layer? Or does the affected user(s) just realize their
>quality is getting poorer?
>
>[Anna]  The goal of PCN is to avoid packet drops under normal
>circumstances by limiting the number of admitted calls to be below the
>load that can be supported without loss or performance degradation.  In
>the case of failures or other unexpected events, the goal of pcn is to
>preempt enough flows to make sure the remaining ones do no get QoS
>degradation.  If preemption is not used (or in the short period of time
>until preemption takes effect), then yes, the quality is just getting
>poorer for all flows involved.
>
>Since the ingress node is not the endpoint within any flow, does this
>ingress node provide any feedback to the originator of the packet(s)? Or
>is this merely expected to be learned through the normal course of
>dropped packets within any network?
>
>[Anna] The answer depends on the deployment model.  The model assumed in
>draft-briscoe-cl-architecture (but not the only one possible) is the one
>where the core is for example an rsvp hop, and so the edges use RSVP to
>admit or bring down a call end-to-end.
>
>
>Final aspect, if how to differentiate one flow from another flow is
>possible, how does this BoF's effort solve for how this is not hacked
>and misused for a game of Doom 3 or Quake 4 between users?
>
>[Anna] Well, the problem statement needs to scope the problem that is
>being dealt with.  My answers above correspond to the scope that is
>currently being proposed (or at least I believe so :-).  Feedback on
>whether it should be broadened (or narrowed) is exactly what we are
>asking for.  I guess I am not entirely sure whether you are arguing
>whether the "aspects" you are bringing up should or should not be within
>the scope?
>
>Thank you,
>Anna
>
>
>
>IMO, anything from this BoF should address (at least in requirements)
>these "aspects" to be addressed in any solution from those requirements.
>
>
> >Agree?
> >
> >phil
> >
> >-----Original Message-----
> >From: Kwok-Ho Chan [mailto:[email-masked]]
> >Sent: 20 September 2006 17:07
> >To: ken carlberg
> >Cc: [email-masked]
> >Subject: Re: ProblemStatement Issue B.9:Call Preemption Not
> >AllowedIssue. Used to be Re: [PCN]
> >draft-chan-pcn-problem-statement-00.txt
> >
> >Ken:
> >I think you brought up couple of points below.
> >My interpretation is:
> >1. There is a need for 911 type (999 in UK?) of calls to get through
> >in a public network.
> >      Hence 911 type of calls may be allowed to be admitted while
> >normal calls get preempt
> >      as a start of a problem statement.
> >2. There is a need for dedicated emergency service networks to allow
> >flow/session preemptions.
> >3. There is a need to allow flow/session preemptions when Emergency
> >Service Networks and
> >      General Public Networks share network resources.
> >
> >Each may have a different affect to the mechanism and solution space
> >we want to work on
> >in the PCN BOF/WG.
> >
> >Please correct me if I mis-understand or missed your points.
> >
> >Thank you very much for your insights.
> >-- Kwok --
> >
> >
> >At 10:09 AM 9/20/2006, ken carlberg wrote:
> > >Kwok,
> > >
> > >>Now I have additional questions concerning the use of Preemption
> > >>for handling Emergency
> > >>Services.  Will Preemption be allowed for Emergency Services?
> > >
> > >My understanding is that Japan provides a measure of preemption for
> > >its 911-type service. However, I don't know the specifics and can't
> > >offer any more insight.  One thing to keep in mind is that the 911-
> > >type system is inherently an any-to-one (any user to PSAP/911-
> >operator) model.
> > >
> > >As mentioned earlier, the US (and some other countries) have a system
> > >called GETS that focuses on increasing the probability of call
> > >completion over their PSTN.  This represents an an-to-any model.
> > >There is also the Wireless Priority System (WPS) in the US that
> > >allows "displacement" of other users *during* call setup, versus a
> > >call that has been established.  People can google GETS and WPS for
> > >more info.
> > >
> > >>Does some of the
> > >>jurisdiction you have indicated want to use a separate network for
> > >>Emergency Services
> > >>purpose?
> > >
> > >Yes, AUTOVON is one example.  Other examples are Land Mobile Radio
> > >(LMR) systems used by first responders.  From the IP perspective, the
> > >bulk of the LMR infrastructure is at Layer 2, but IP providers and
> > >vendors are starting to infuse IP into those systems.  The key thing
> > >to keep in mind is that these are systems that are under a single
> > >administrative authority (ie, a single domain).
> > >
> > >>Will combining Emergency Services with the normal VoIP
>calls/sessions
> > >>be a good Problem Statement that we can add to our Problem
> > >>Statement draft?
> > >
> > >Well, I would view Emergency Services as mostly one motivation for
> > >what you are trying to accomplish.  Aspects like rapid recovery,
> > >prioritization/labeling/coloring of flows, etc. would seem to be of
> > >interest to those dealing with emergencies or some other condition.
> > >
> > >-ken
> > >
> >
> >
> >_______________________________________________
> >PCN mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pcn
> >
> >_______________________________________________
> >PCN mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pcn
>
>_______________________________________________
>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: "Jozef Babiarz" <[email-masked]>
Date: Wed, 20 Sep 2006 17:41:03 -0400

James, in one of the deployment models, the pre-congestion information
from the network is passed to the SIP endpoints. The SIP endpoint based
on its service policy take the appropriate action. Currently, I'm
writing the deployment model that explains how this would work. In the
deployment model that I'm using the pre-congestion information is passed
via the ECN bits in the IP header of packets received by the SIP
endpoint. SIP signalling is used to close the control loop with the SIP
traffic originating endpoint for admission and flow termination
(preemption). 

Regards, Joe
QoS & Network Architecture
Telephone: 613-763-6098 (ESN 393-6098)
Email: [email-masked]

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 4:07 PM
To: Anna Charny (acharny); [email-masked]; Chan, Kwok-Ho
(BL60:470); [email-masked]
Cc: [email-masked]
Subject: RE: [PCN] Problem of differentiating packets by flows (i.e.
calls)

Said below:

make a per-flow based decision on who to preempt/accept based on this
info.  "

How will the ingress node have all the necessary information in it to
make 
a decision that Alice's call is more important than Bob's?

Will the edge node have access to SIP signaling (for example)? Without
this 
(or the like) or without there being a reservation to the ingress dge
node 
from the packet originator, what is/are the indicator(s) distinguishing
one 
packet from another (meaning one call from another)?

Without this, any discussion of prioritizing one packet over another is 
pointless (which I said in my original email), and probably out of scope
of 
PCN.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 20 Sep 2006 21:19:27 -0500

>traffic originating endpoint for admission and flow termination

cool

I just wanted to know/understand how traffic was being differentiated, if 
it was, especially under emergency situations (which was the topic of this 
original thread).