Subject: [Ieprep] RE: Summary of IEPREP work and VoIP

From: "King, Kimberly S." <[email-masked]>
Date: Fri, 13 Dec 2002 09:44:00 -0500

> On Thursday, Dec 12, 2002, at 18:09 America/Montreal, King, 
> Kimberly S. 
> wrote:
> > Case 1:  There is a predefined relationship between SIP 
> provider and 
> > ISP
> > providing access to the ETS location and this is known in 
> advance of an
> > emergency.  (The model might be like an enhanced GETS-like 
> WorldCom SIP
> > service).  In this case, there are two main things that can be done.
> >
> > o	Call signaling where some new resource priority mechanism (this
> > mechanism will hopefully to be created in SIPPING as a result of 
> > Henning's
> > requirements document) is in SIP that can be used to 
> identify calls for
> > preferential access to ports on PSTN gateways or other end systems.
> > o	If the provider runs stateful SIP proxies, the new 
> resource priority
> > mechanism could also allow preferential treatment of proxy 
> resources.
> > o	Depending upon how this provider engineers their 
> service (suppose
> > they want to be very stateful and track how many calls are coming 
> > to/from
> > which locations), a traditional call admission control 
> could possibly 
> > be
> > supported giving preferential treatment to emergency calls 
> by allowing 
> > them
> > a greater probably of call setup than regular calls.
> > o	We take the assumption (largely substantiated for many 
> U.S. regions)
> > that network congestion, if it exists, is on the access 
> link.  Hence, 
> > to
> > increase the likelihood of good sounding calls over an 
> access link, the
> > number of calls can be controlled locally at the customer 
> location.  
> > This
> > can be achieved through the use of devices (e.g., QoS 
> appliances or SIP
> > proxy firewalls)
> 
> or SIP proxy firewalls or IP routers that are configured to enable 
> CBQ/CoS
> or link-layer QoS mechanisms)

Actually, I'm talking purely SIP signaling at this point.  Only after that
do I consider the CBQ/CoS etc. for IP layer mechanisms.  What I mean above
is that there are literally SIP proxy-firewalls and QoS devises available
that can block the call signaling based upon a variety of factors including
the current number of active calls over the access link.  I've talked with
some of these vendors about the ability to modify their products to support
a preferential treatment whereby some users have a higher priority to setup
calls during congestion (as defined by the number of calls occurring over
the access link) and pre-emption of existing calls if desired.  They
indicate this functionality could be supported if the market calls for it.
I can provide more details if you think that would be constructive.
Remember this is done locally so this scales fine and doesn't involve the
service provider.

> 
> >  that are enhanced to only setup the highest priority calls
> > over the access link, up to a predetermined maximum 
> influenced by the 
> > speed
> > of the access link, possibly even supporting preemption.
> 
> That phrasing is awkward and ambiguous since the IP-layer 
> still does not
> have the concept of a "call".  

You don't get my phrasing here because I guess it wasn't clear enough that I
am only talking signaling at this point.  I'm not worried about the IP-layer
not understanding "calls", I am using devises that do.  Here's an example
firewall http://www.ingate.com/siparators.php that includes knowledge about
calls.

>Presumably what one meant is something
> more like:
> 
> ...that are enhanced to provide preferred forwarding over the access 
> link
> to IP datagrams that are associated with specific authorised 
> emergency-related
> flows, up to some predetermined maximim influenced by the speed of the
> access link.  This preferred forwarding might involve CBQ in routers,
> lower-drop probability for authorised emergency-related IP packets,
> or other mechanisms.  Some such mechanisms might be inside the 
> link-layer,
> rather than in the IP-layer or above.

No.  I'm hoping it's clear from the above but what I mean is put something
between the customer LAN and the access link that understands SIP signaling
and the maximum number of calls supported at any given time (this is exactly
what WorldCom SIP service is doing).  Now, modify this thing to track
priority of the given calls.  Either allow a greater probably of call setup
to priority calls when the number of calls approaches the limit or pre-empt
existing lower priority calls.  If the link supports 10 quality calls, then
all ten always sound good.  However, the 10 using the link are the highest
priority ones simply by virtue of call admission control (done locally).

It's actually an easy modification.  By using such a devise, one can
essentially make the link act somewhat like the PSTN.  Who gets to talk is
determined only by signaling, you admit the most important players and
everyone admitted gets quality sounding calls (because you predetermined how
much voice can be supported over the link and possibly use CoS to help that
quality even more).  Is this clear?

> Or, if a policy and deployment is agreed upon *by the 
> operators of that 
> link*,
> one might be able to prioritise selected IP flows (of any application 
> protocol).

Yes.

> What is missing in each scenario above is discussion of codec 
> selection.

This is an important topic and it would be nice to have discussions.
However, my summary doesn't include it because we really haven't reached any
conclusions on it yet.  It's a good topic.

> 
> Also missing is discussion of the desirability of using link-layer QoS
> mechanisms (e.g. IEEE 802.1p) where they exist.

One could add that.

> 
> But overall, a helpful draft summary.

Good.

Kimberly
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 13 Dec 2002 10:01:59 -0500

On Friday, Dec 13, 2002, at 09:44 America/Montreal, King, Kimberly S. 
wrote:
> the current number of active calls over the access link.

Ahh.  Could you please edit the phrase "QoS devices" to make it clear
that you are thinking about "SIP-layer-only QoS devices" ?  Not sure 
what
the right words would be, but the current ones are confusing.

> I've talked with

Seems plausible enough, with the understanding that it is a matter of
application-layer blocking for SIP signalling, rather than blocking
IP packets of any sort.

> not understanding "calls", I am using devises that do.

Could you please try to devise alternate, more clear, wording ?

 From the URL below, it appears that the widget you are thinking of 
operates
basically as an "application-layer gateway (ALG)" or "SIP proxy server".
Maybe you could work one or both of those phrases (whichever you think
is accurate) into the new text ?

> Here's an example

The URL definitely helps understand what you mean.

> quality even more).  Is this clear?

The two paragraphs above increase clarity a whole lot.  Please maybe 
take
some of that text into your next revision of the "VoIP summary" in an
effort to make things clear all around.

Now, what happens if the same access link is being used concurrently
for non-SIP/non-VoIP traffic (e.g. a real-time game that is UDP-based
and lacks congestion avoidance and control) ?

Is that not still a problem...

> conclusions on it yet.  It's a good topic.

Maybe add a place holder ?
	"Open Issues:
		- Initial codec selection
		- Codec changes due to congestion

>> mechanisms (e.g. IEEE 802.1p) where they exist.

Unless one is trying to rule that out, maybe that could be added.  
Proposed
text (edit to taste) might be:

	"Link-layer QoS mechanisms should be considered for deployment as part
	of an overall system, when such mechanisms exist and can be applied
	to a particular IEprep scenario."

Ran
[email-masked]