Subject: [PCN] New Deployment Model

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 17 Oct 2006 20:31:19 -0400

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt

	Title		: SIP Controlled Admission and Preemption
	Author(s)	: J. Babiarz, et al.
	Filename	: draft-babiarz-pcn-sip-cap-00.txt
	Pages		: 20
	Date		: 2006-10-16
	
   This framework defines a method of providing Explicit Congestion
   Control to real-time inelastic traffic like voice and video through
   the use of session admission control and preemption mechanisms.  This
   approach uses the Pre-Congestion Notification Marking (PCN) [1]
   mechanism.  PCN marking is deployed in routers to measure and convey
   two levels of onset of congestion with the SIP controlled endpoints
   responding to the marking.  This approach is different from what is
   defined in An edge-to-edge Deployment Model for Pre-Congestion
   Notification [3], as here the admission and preemption control
   function resides in the application (either in the endpoint or the
   application server that controls the endpoint.  This framework is
   focused on using Session Initiated Protocol (SIP) as the application
   signaling protocol but other application signaling protocols could be
   extended for this purpose.

Looking forward to having a discussion of this approach on the list. 

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

_______________________________________________
PCN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn

---

From: Michael Menth <[email-masked]>
Date: Thu, 19 Oct 2006 08:39:34 +0200

Dear Jozef,

I read your draft. Here are my comments.

4.1 If the admissible rate is exceeded, ALL packets running over this 
element must be marked. If the supportable rate is exceeded, only a 
fraction of the packets is marked accordingly, to allow the end systems 
to determine the strength of the overload.

General comments:
* As SIP is an end-to-end solution, this application requires all PCN 
clouds to have the same semantic for the encoding. I can imagine other 
admission control support, e.g., using RSVP based on traffic 
descriptors. If the SIP control is agnostic to that and admits new calls 
only based on PCN-feedback, this might become a problem.
* Another problem might be that only SIP controlled applications react 
to overload while other applications using the same service class are 
not responsive.

Best wishes,

    Michael

Jozef Babiarz wrote:
> _http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt_
>
> ///Regards, Joe/
> ------------------------------------------------------------------------
>

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Thu, 19 Oct 2006 06:33:40 -0400

Hi Michael:
Please see in-line below.
-- Kwok --

At 02:39 AM 10/19/2006, Michael Menth wrote:
>4.1 If the admissible rate is exceeded, ALL packets running over 
>this element must be marked. If the supportable rate is exceeded, 
>only a fraction of the packets is marked accordingly, to allow the 
>end systems to determine the strength of the overload.
>
>General comments:
>* As SIP is an end-to-end solution, this application requires all 
>PCN clouds to have the same semantic for the encoding. I can imagine 
>other admission control support, e.g., using RSVP based on traffic 
>descriptors. If the SIP control is agnostic to that and admits new 
>calls only based on PCN-feedback, this might become a problem.

SIP proxy can also be used.  Hence this is not just an end-to-end solution.

The PCN encoding will need to use the agreed on meaning when it reach the PENs.
But if some domain in the middle does not support PCN, and instead 
use some other
admission method, that domain will need to indicate the PCN condition 
(think of this
domain be represented as one hop of PCN).  This view may help the interfacing
between different methods.
Also, the use of PCN will allow the network to change routes, etc in 
the middle (PINs).
Hence the SIP control will be agnostic to the exact packet route used 
and the route's
exact method.  For example if QoS routing is employed in the 
middle.  That QoS routing
capable region may not cause PCN Marking by reacting and solving any 
QoS problem
before indicating using PCN Marking is needed.

>* Another problem might be that only SIP controlled applications 
>react to overload while other applications using the same service 
>class are not responsive.

Yes.  The PCN capable traffic will need to be separated from the other traffic.
This is also true with ECN (RFC 3168) with TCP.  What happens if some 
end points are not
good citizens?
This becomes a fairness issue.

Hope this helps.

---

From: "Jozef Babiarz" <[email-masked]>
Date: Fri, 20 Oct 2006 00:15:29 -0400

Michael, see my explanation below, I hope they help.

Regards, Joe
QoS & Network Architecture
Telephone: 613-763-6098 (ESN 393-6098)
Email: [email-masked]
-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: Thursday, October 19, 2006 2:40 AM
To: Babiarz, Jozef (CAR:0S03); [email-masked]
Subject: Re: [PCN] New Deployment Model

Dear Jozef,

[Joe] To block admission of new sessions, it is desirable that all
packets in that service calls are marked by the element that is
experience that bandwidth utilization above admissible level. The main
reason being that during session setup SIP controlled endpoints are
sending probe packets to test the path and if the network element in
questions did not mark all packets belonging to the service class, the
endpoint most like would not see any marking and would admit new
session. 
Now if the supportable rate is exceeded, one packet every n bytes of
excess traffic is marked. What I'm suggestion is that the network
element that experience traffic above the supportable rate selects the
flow to be removed by marking a packet similar to what ECN does for TCP
flows to reduce sending rate. In this deployment model normal there is
only one flow per endpoint so trying to measure the level of overload is
not that practical. For deployments scenarios where edge node has many
flows excess rate may be measured by counting the number of market
packets and multiplying by n bytes over counting time.  

General comments:

[Joe] Yes both endpoints need to use the same semantics or be aware that
semantic are different. This approach allows other admission control
methods to be used in different network segments. Should RSVP be used,
in one network segment the reservation would need to be completed before
SIP session would be allowed to continue or if a different approach was
used the probe packets would need to be received by the other endpoint
before session setup could be completed. Can you explain a situation
which would cause a problem?

 [Joe] Yes, this is an issue. One approach is to use the Not-ECT "00"
codepoint to represent flows that are not control by this mechanize or
to use a different DS codepoint. This is an issue that needs to be
discussed on how best it can be resolved.  

Best wishes,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Fri, 20 Oct 2006 15:32:51 +0200

Dear Jozef,

see inline!

> which would cause a problem?
I don't know how this should work. Does the probe packet trigger a 
reservation request through the RSVP-controlled cloud? Probably, we are 
here already right in the middle of a discussion how to achieve 
end-to-end QoS while PCN is a local solution for a PCN domain. I can 
imagine that different domains have different QoS protocols/mechanisms 
and that there must be another protocol talking with these domains to 
find out whether a flow can be admitted end-to-end. From my perspective, 
SIP should be based on such an end-to-end protocol, otherwise the 
solution can be safely applied only within a PCN-domain, e.g., within a 
comany, or SIP proxies must be used as workaround as Kwok mentioned in 
his last email.

Best wishes,

    Michael
>>    the use of session admission control and preemption mechanisms.
>>     
> This
>   
>>    mechanism.  PCN marking is deployed in routers to measure and
>>     
> convey
>   
>>    focused on using Session Initiated Protocol (SIP) as the
>>     
> application
>   
>>    signaling protocol but other application signaling protocols could
>>     
> be
>

---

From: "Jozef Babiarz" <[email-masked]>
Date: Fri, 20 Oct 2006 10:11:32 -0400

Michael wrote:
I don't know how this should work. Does the probe packet trigger a
reservation request through the RSVP-controlled cloud? 
[Joe] No. SIP triggers reservation request in RSVP-controlled cloud. The
assumption is SIP precondition (RFC 3312) is used in both RSVP and this
approach. Alerting of the called party (admission) is delayed until all
conditions are met. 

Probably, we are here already right in the middle of a discussion how to
achieve end-to-end QoS while PCN is a local solution for a PCN domain. 
[Joe] I do not view PCN being only a local solution. Yes for simplicity,
our initial trust is to focus on a single domain and delay all the trust
issues between different domains, but PCN like ECN can be end-to-end.

I can imagine that different domains have different QoS
protocols/mechanisms and that there must be another protocol talking
with these domains to find out whether a flow can be admitted
end-to-end. From my perspective, SIP should be based on such an
end-to-end protocol, otherwise the solution can be safely applied only
within a PCN-domain, e.g., within a company, or SIP proxies must be used
as workaround as Kwok mentioned in his last email.
[Joe] I think we are in agreement. If a domain use other than the PCN
method for admission control, that domain needs a method to inform SIP
that it can or can not support that new session.

Regards, Joe
-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: Friday, October 20, 2006 9:33 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]
Subject: Re: [PCN] New Deployment Model

Dear Jozef,

see inline!

> descriptors. If the SIP control is agnostic to that and admits new
calls

Best wishes,

    Michael