Subject: [Ieprep] Summary of IEPREP work and VoIP

From: "King, Kimberly S." <[email-masked]>
Date: Thu, 12 Dec 2002 18:09:32 -0500

>Thanks.  You read more carefully than Fred, and its appreciated.

To be fair, Fred may not have read all the thousands of emails that have
been written in ieprep lately.  ;-)

Mike's scenario has been discussed, in various forms, many times. The below
cases represent our main findings in my own words.  We assume an ETS
location is connected via an access link to the Internet.

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

·	The second thing that is possible is some kind of CoS on the access
link.  
o	In all cases, the customer may use filters, QoS appliances, etc. to
prioritize voice over data at the CPE (as Ran suggested).  In some cases,
the ISP will also perform this service at the network end of that link
(e.g., Sprint CoS service).

Case 2:  The ISP provides a CoS service but any SIP services come from a
provider whose service is distributed in other places in the Internet.
Basically, here the ISP provides transport with some CoS but isn't coupled
with a SIP service.
o	The resource priority mechanism would still be useful if gateways or
end systems support such a mechanism.  
o	However, since the SIP provider has no information about how the
user is obtaining access, it doesn't really make sense to do "call admission
control".  (For example, 10 users at the same location could rely on 10
different SIP service providers - none of the service provider can determine
what is flowing over the access link they happen to all be using.)  
o	Note that users may still retain control over which connections get
setup by local control (several QoS appliances or SIP proxy firewalls could
be modified to support this).

o	The second thing that is possible is some kind of CoS on the access
link.  Again, the customer may use filters, QoS appliances, etc. to
prioritize voice over data at the CPE (as Ran suggested).  In this case, the
ISP will also perform this service at the network end of that link (e.g.,
Sprint CoS service).

Case 3:  The ISP provides a best effort service and any SIP services come
from a provider whose service is distributed in many places in the Internet.

This is just like case 2 above except we don't expect a CoS treatment at the
network end of the access link.

In terms of what needs to be done for SIP protocol changes, I think we have
achieved our objectives.  I haven't shared this with the group yet, but I
believe Megaco is okay as is.  I'll save my research there for another
email. Now, Rohan had a nice idea that could also supplement the above from
say an Internet Café but no one has expressed an interest.  I think all the
pieces, at least surrounding preferential treatment and SIP can be glued
together to form preferential call service.  But, the working group remains
open to new ideas.

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

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 13 Dec 2002 08:45:00 -0500

On Thursday, Dec 12, 2002, at 18:09 America/Montreal, King, Kimberly S. 
wrote:
> proxy firewalls)

or SIP proxy firewalls or IP routers that are configured to enable 
CBQ/CoS
or link-layer QoS mechanisms)

>  that are enhanced to only setup the highest priority calls

That phrasing is awkward and ambiguous since the IP-layer still does not
have the concept of a "call".  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.

> o	In all cases, the customer may use filters, QoS appliances, etc. to

s/filters,/router filters, router CoS, switch filters, link-specific 
AoS,/

> prioritize voice over data at the CPE (as Ran suggested).

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

> In some cases,

At least some existing switches and routers can be configured to do 
this,
within various implementation-specific constraints.

> link.  Again, the customer may use filters, QoS appliances, etc. to

s/filters,/filters, routers, switches,/

> ISP will also perform this service at the network end of that link 

s/ISP will also/ISP might also/

> network end of the access link.

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

A valid and productive response to a pair of VoIP end systems becoming
aware of congestion someplace along the path between them would be to
switch to a lower-data-rate-codec.  This kind of behaviour is needed
regarless of IEprep, as part of normal Internet congestion avoidance
and control.   And there is certainly room to use codecs other than 
G.711,
as others have discussed here.  And either of those changes could well
lead to a reduction in the congestion on the link causing the two humans
to still be able to understand each other clearly (which is the 
functional
need), even though one might not be able to hear a pin drop at the 
remote
end.

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

But overall, a helpful draft summary.

Ran
[email-masked]