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

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Wed, 20 Sep 2006 15:47:00 -0400

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: "Geib, Ruediger" <[email-masked]>
Date: Thu, 21 Sep 2006 08:58:37 +0200

Hi Anna,

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

[Rudi] I'd expect that the quality after "expectable" failures could be 
maintained by provisioning and planning. But I agree, during
catastrophic 
failures, quality degradations will occur. As a result, some folks will 
end their calls. After a short time (on the order of minutes, I'd 
assume) standard operation should resume, meaning that the transport 
quality is ensured again by PCN.

Regards, 

Rudiger