Subject: [Ieprep] Summary of ieprep work and VoIP--Take 2

From: "King, Kimberly S." <[email-masked]>
Date: Tue, 17 Dec 2002 11:49:29 -0500

I have created a summary below organizing information into various
contextual 
situations and options that I hope will provide some clarity.
______________________

We assume an ETS location is connected via an access link to the Internet. 
We also take the assumption (largely substantiated for many U.S. regions)
that network congestion at layer 3, if it exists, is on the access link.  

We assume the access link carries both VoIP signaling and VoIP media
streams. 
If other non-VoIP traffic is also carried, then there is a tradeoff to make 
between the performance of voice and non-voice applications.  For 
example, enough VoIP on a congested link (e.g., 10-40% packet drop rates) 
can be sufficient to make the link essentially unusable for TCP traffic.  

Case A: Bundled Internet access and SIP service provider. 
In this case, there is a predefined relationship between SIP provider and
ISP
providing access to the ETS location (e.g., WorldCom SIP service) and this 
is known in advance of an emergency.  Both preferential signaling and CoS 
type techniques are potentially applicable.  

Case A Signaling Technique 1 
Assume there is a SIP resource priority mechanism available to
identify emergency calls.  (Henning's Requirements document on this
subject will be examined by the SIPPING working group and we hope
the outcome will be such a mechanism in SIP.)  
This mechanism could identify emergency calls thereby facilitating
preferential access to ports on PSTN gateways or other end systems.

Case A Signaling Technique 2
If the provider runs stateful SIP proxies, the new resource priority
mechanism could also allow preferential treatment of proxy resources.  

Case A Signaling Technique 3 
One highly stateful solution would be for the provider to track how 
many calls are coming to/from which locations' access link, and apply a 
traditional call admission control.  If the provider has multiple SIP
servers, then 
this will further require communication between those servers to track 
coordinate information.  Again, either higher probability of call setup 
or pre-emption could be supported.  The WG recognizes that one of the major
aspects of VoIP is the decoupling of signaling and the switching matrix 
and hence solutions like this will have to approximate congestion based upon
VoIP
call counts over predetermined access links and will have some interesting 
scaling properties.  

Case A. Signaling Technique 4
The number of calls traversing the access link can be controlled by placing
a middle box (e.g., stateful SIP-proxy firewall, SIP-aware QoS middlebox) on
the 
customer premise at the access link.  This middle box can be
provisioned to allow a predetermined number of concurrent VoIP calls over
the
access link and deny further call attempts when that maximum number is met,
analogous to a traditional PBX.  However, this middle box could be
enhanced to understand call priority and allow preferential treatment to 
emergency calls by either granting them a greater probability of call setup
during
times when the link is close to the predetermined maximum or by enabling 
preemption.  

Case A. CoS on the Access link Technique 1
The customer may apply CoS at the CPE (e.g., router filters, switch filters,
QoS middleboxes).  Also, Link-layer QoS mechanisms should be considered for 
deployment as part of an overall system, when such mechanisms exist.

Case A. CoS on the Access link Technique 2
The service provider may also apply CoS at the service provider end of
the access link(e.g., Sprint CoS service).  If a policy and deployment is
agreed 
upon by the operators of that link, it is also possible to prioritize
selected IP 
flows of nearly any application protocol.  Note that some protocols do not
use 
fixed ports, so one can't use normal filters to handle those application 
protocols such as the data streams for VoIP traffic.

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

Signaling Technique 1,2 and 4 are potentially applicable from Case A above.
Signaling Technique 3 is no longer appropriate 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.)  

CoS on the Access link Technique 1 and 2 also apply.

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

Signaling Technique 1,2 and 4 are applicable from Case A above.

CoS on the Access link Technique 1 also applies.

Open Issues:
- Initial codec selection
-Codec changes due to congestion
-Additional mechanisms

Kimberly

Disclaimer:  My statements represent my own thinking and do not necessarily 
reflect the position of anyone else in the world including my employer. 
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 17 Dec 2002 12:34:40 -0500

On Tuesday, Dec 17, 2002, at 11:49 America/Montreal, King, Kimberly S. 
wrote:
> For example, enough VoIP on a congested link (e.g., 10-40% packet drop 
> rates)

I think that overstates the case.  There is evidence (e.g. USN 
deployments
of IP to ships at sea) that TCP/IPv4 works fine over 2.4 Kbps WAN radio 
links.
Unless the non-congestion-avoiding traffic consumes *all* of the link 
bandwidth,
TCP/SCTP will still work.  The response times of interactive 
congestion-avoiding
traffic traffic (whether TCP, SCTP, or other) will be adversely 
impacted by the
reduction in offered load caused by the congestion avoidance 
mechanisms, but that
will not make the link "essentially unusuable" for such traffic.

In particular, I myself have used a shared 2.4 Kbps RF link for 
interactive
(Telnet/TCP/IPv4) traffic halfway around the world (~Asia to US East 
Coast)
to read email.  It works OK.  It would be more pleasant with more 
bandwidth,
but it is not the case that TCP didn't work adequately on a shared very
low bandwidth very high latency link.

We should also be careful to note the stated IAB concern from Sally 
Floyd that
congestion-avoidance needs to be added to VoIP application protocols 
(e.g. RTP)
if VJ-compatible congestion avoidance is not already present in those 
protocols.
It is my understanding that work is in-progress on this topic in 
various IETF
Working Groups, so it is likely that VoIP application protocols will be 
implementing
and deploying VJ-compatible congestion avoidance in future.  This, by 
the way,
implies that those application protocols will be doing some form of 
codec
changing based in part on the degree of congestion present end-to-end 
(if any
congestion is present).

> protocols such as the data streams for VoIP traffic.

Editing for clarity, I might edit the last sentence to read more like 
this:

	Note that some application-layer protocols (e.g. VoIP sessions) do not 
use
	fixed transport-layer ports, so one might not be able to use 
port-centric
	filters to cause those application protocols to be handled differently 
than
	other IP traffic.

Ran
[email-masked]