Subject: RE: [IPTEL] CPL Question About Priority

From: "David Oran" <[email-masked]>
Date: Fri, 1 Dec 2000 09:50:27 -0500

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Lakshmi 
> Krishnamurthy
> Sent: Wednesday, November 29, 2000 4:06 PM
> To: hammer michael
> Cc: [email-masked]
> Subject: Re: [IPTEL] CPL Question About Priority
> 
> 
> I agree with this observation. The application always knows best in 
> terms of the nature & type of resources it needs accommodated by the 
> network. There needs to be a way of communicating this requirement to 
> the IP layer.
>
I disagree with the original observation, but not with your restatement.  Luckily, we DO have at least two ways for the application to tell the IP cloud its requirements. One is via RSVP; the other is via DIFFSERV marking.

> This need not be an explicit list of QoS params, but 
> something that is a 
> user-friendly mapping could be in order.
>
The mapping is a local system issue and does not affect any protocols. For example, the QoS/Codec API on Win2K knows how to take things like coder specifications, and create the appropriate TSPEC to go into RSVP.

What I believe is the disconnect here is whether media transport should have any coupling at all to the call/session signaling, the servers the signaling  uses, the proxies it visits, or the path through the network the signaling messages traverse. Some folks thing the two ought to be coupled, as they are in today's PSTN. One of the fundamental benefits of the Internet approach to multimedia (including telephony) is that they are completely *decoupled*. Coupling them would be a serious mistake, in my view, for a number of reasons:
1) some signaled sessions may have no media at all (e.g. presence)
2) it confuses the resources and costs for media carriage from those for establishing sessions and providing non-media-related services.
3) it encourages media flows to visit places they otherwise would not have to, resulting in inefficiencies, extra points of failure, etc.
4) it makes the signaling elements too media sensitive (i.e. need to understand each new medium and its detailed requirements).

Dave.

> hammer michael wrote:
> 
> > I understand to an extent the distinction you are making, 
> that the IP
> > layer, given the end-point address can figure out how to route the
> > packets carrying the media along with resource 
> reservations.  However,
> > the existence of Via, Route, and Record-Route parameters 
> and the usage
> > for routes longer than two proxies would seem to undermine 
> the purity
> > of your position.  Ultimately the purpose of signaling is 
> to establish
> > the media path, so they are not so totally divorced.
> > 
> > I thought that one of the evolutionary goals of the IP telephony was
> > to put as much control in the hands of the end-user.  If 
> such control
> > is in the IP layer, how does the user control that?  Will that be a
> > Web-level interface or must he be an IP guru?  I was envisioning a
> > little more control in the Application layer via some more
> > user-friendly features.  In the current PSTN, there is some level of
> > stimulus signaling for customers to activate and deactivate features
> > and program-in network codes and user phone numbers for 
> forwarding.  I
> > would expect that the level of user control would be much 
> higher in IP
> > telephony.
> > 
> > Do you see the network cloud operating transparently and 
> what service
> > you get is what you get?
> > Or is there another media-specific protocol that allows the user to
> > explicitly control what network routes that his packets traverse?
> > 
> > Mike
> > 
> > 
> > At 12:22 PM 11/29/2000 -0500, Jonathan Lennox wrote:
> > 
> >> On Wednesday, November 29 2000, "hammer michael" wrote to "Jonathan
> >> Lennox, [email-masked], [email-masked],
> >> [email-masked]" saying:
> >> 
> >>  > You could potentially have a network selection based on dynamic
> >> network
> >>  > characteristics.
> >>  > Route through network A (the cheapest) unless it is congested or
> >> denies me
> >>  > service,
> >>  > otherwise route through network B while QoS > X, else 
> ...  >  > I 
> >> know that bandwidth is supposed to be free and plentiful, 
> but could 
> >> you  > foresee networks of the future dynamically changing their 
> >> rates based on  > demand and users selecting the better 
> alternatives 
> >> for routing?
> >> 
> >> Yes, absolutely, but this is way out of scope for the CPL. 
>  Remember,
> >> CPL
> >> controls *signalling*, and the network selection you're 
> talking about
> >> is for
> >> *media*.
> >> 
> >> If I place a call to sip:[email-masked], and the 200 
> response to the
> >> INVITE
> >> has 128.59.19.147 in its SDP, I'm going to send my packets to
> >> 128.59.19.147,
> >> regardless of what route my INVITE took.
> >> 
> >> If I'm using manyfolks, I'll also set up a resource reservation to
> >> that IP
> >> address.  That's the point at which the service provider should
> >> intervene to
> >> figure out what route they want my packets to take.
> >> 
> >> --
> >> Jonathan Lennox
> >> [email-masked]
> >> 
> >> _______________________________________________
> >> IPTEL mailing list
> >> [email-masked] 
> >> http://lists.bell-labs.com/mailman/listinfo/iptel
> > 
> > 
> > 
> > 
> > _______________________________________________
> > IPTEL mailing list
> > [email-masked] 
> > http://lists.bell-labs.com/mailman/listinfo/iptel
> 
> 
> 
> _______________________________________________
> IPTEL mailing list
> [email-masked] 
> http://lists.bell-> labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: [email-masked]
Date: Fri, 1 Dec 2000 10:51:14 -0500

From:  Tom Gray@MITEL on 12/01/2000 10:51 AM

It seems to me that there is a more fundamental issue here. This is a discussion
on the feature set  of CPL which should be subsumed by the question of just what
is CPL intended to provide. It is not a full blown call processing language.
There does not seem to be a consensus as to what it is beyond that.

Should CPL be used as a rule set that can determine the QoS required for an
outgoing call? So if it determines that this is an internal call the cheapest
connection is used while if this is an external call to a customer then a
request should be made to use a connection of a sufficient quality. Is there a
tacit consensus that CPL is a system which will contain such rules?

"David Oran" <[email-masked]> on 12/01/2000 09:50:27 AM

To:   "'Lakshmi Krishnamurthy'" <[email-masked]>, "'hammer michael'"
      <[email-masked]>
cc:   [email-masked] (bcc: Tom Gray/Kan/Mitel)

Subject:  RE: [IPTEL] CPL Question About Priority

> network. There needs to be a way of communicating this requirement to
I disagree with the original observation, but not with your restatement.
Luckily, we DO have at least two ways for the application to tell the IP cloud
its requirements. One is via RSVP; the other is via DIFFSERV marking.

> user-friendly mapping could be in order.
The mapping is a local system issue and does not affect any protocols. For
example, the QoS/Codec API on Win2K knows how to take things like coder
specifications, and create the appropriate TSPEC to go into RSVP.

What I believe is the disconnect here is whether media transport should have any
coupling at all to the call/session signaling, the servers the signaling  uses,
the proxies it visits, or the path through the network the signaling messages
traverse. Some folks thing the two ought to be coupled, as they are in today's
PSTN. One of the fundamental benefits of the Internet approach to multimedia
(including telephony) is that they are completely *decoupled*. Coupling them
would be a serious mistake, in my view, for a number of reasons:
1) some signaled sessions may have no media at all (e.g. presence)
2) it confuses the resources and costs for media carriage from those for
establishing sessions and providing non-media-related services.
3) it encourages media flows to visit places they otherwise would not have to,
resulting in inefficiencies, extra points of failure, etc.
4) it makes the signaling elements too media sensitive (i.e. need to understand
each new medium and its detailed requirements).

Dave.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 3 Dec 2000 13:16:17 -0500

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, December 01, 2000 10:51 AM
> To: David Oran
> Cc: 'Lakshmi Krishnamurthy'; 'hammer michael'; 
> [email-masked]

There is clear consensus that it is a processing language for creation of
call control and signaling features by end users, which are executed inside
of proxies and other devices within the network. The services span only
services related to call establishment - that is, routing, screening, and
logging types of services. 

Certainly it can be used other ways; but thats what it was designed for. If
we want to increase its scope significantly for the next rev, we should
define some requirements.

> tacit consensus that CPL is a system which will contain such rules?

I think both I and Dave Oran, amongst others, have elaborated on why a call
control platform, like a SIP server, controller by CPL or any other logic,
is ill suited to end to end resource reservation or QoS types of services.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Matt Holdrege <[email-masked]>
Date: Sun, 03 Dec 2000 10:26:16 -0800

>is ill suited to end to end resource reservation or QoS types of services.

Yes, but there is nothing wrong (and much to gain) with a SIP server or a 
Softswitch giving hints to a QoS control engine somewhere else in the network.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 3 Dec 2000 13:34:14 -0500

> From: Matt Holdrege [mailto:[email-masked]]
> Sent: Sunday, December 03, 2000 1:26 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'; David Oran; 'Lakshmi Krishnamurthy'; 'hammer
> michael'; [email-masked]

It has been proposed by the DCS folks, amongst others, to push authorization
for QoS reservation from a proxy server to a COPS server or other QoS policy
server somewhere on the network. Thats something different; the QoS
availability decisions are still made within the QoS protocols, not by SIP
call routing. I don't see a role for CPL in doing this. Furthermore, whether
this kind of push is a good idea or not is debatable; I'm personally not a
fan, but thats a whole other discussion I'd really rather not have here.

-Jonathan R.

---

---

From: Matt Holdrege <[email-masked]>
Date: Sun, 03 Dec 2000 12:14:34 -0800

>fan, but thats a whole other discussion I'd really rather not have here.

One more try and then I'll stop polluting the list with this.

IF there is a reason to signal a QoS hint somewhere on a call-by-call 
basis, then wouldn't CPL have a useful role in that? If not CPL, then what 
else? A random XML script?

---

From: "Mark Gibson" <[email-masked]>
Date: Mon, 4 Dec 2000 09:28:36 -0000

-----Original Message-----
From: 	David Oran [mailto:[email-masked]] 
Sent:	Friday, December 01, 2000 2:50 PM
To:	'Lakshmi Krishnamurthy'; 'hammer michael'
Cc:	iptel
Subject:	RE: [IPTEL] CPL Question About Priority

I disagree with the original observation, but not with your restatement.
Luckily, we DO have at least two ways for the application to tell the IP
cloud its requirements. One is via RSVP; the other is via DIFFSERV marking.

[Mark] However RSVP is typically enterprise only and DiffServ gives you no
latency guarantees and won't reject resource reservation in the face of
congestion. Neither seems, on their own, particularly suited to core voice
applications.

What I believe is the disconnect here is whether media transport should have
any coupling at all to the call/session signaling, the servers the signaling
uses, the proxies it visits, or the path through the network the signaling
messages traverse. Some folks thing the two ought to be coupled, as they are
in today's PSTN. One of the fundamental benefits of the Internet approach to
multimedia (including telephony) is that they are completely *decoupled*.
Coupling them would be a serious mistake, in my view, for a number of
reasons:
1) some signaled sessions may have no media at all (e.g. presence)

[Mark] So don't use a QoS indication in this case - whether it's included in
the application layer does not have to mandatory for all applications.

[Mark] This can be sidestepped by using media specific filters in the
affected routers that are supporting the negotiated streams. Other services
continue to be dealt with as before.

3) it encourages media flows to visit places they otherwise would not have
to, resulting in inefficiencies, extra points of failure, etc.

[Mark] If you decouple the signalling path from the media path with a
provisioning mechanism (COPS-PR, SNMP, ...), there need be no direct
correlation between the signalling and media path. Again, those application
boxes who do not need to heed the QoS parameters could simply ignore them.
e.g. proxies at the edge of a domain might want to do some admission control
based on the size of new session and, once the destination is known, might
want to map the session to a particular path (e.g. LSP in an MPLS case).

4) it makes the signaling elements too media sensitive (i.e. need to
understand each new medium and its detailed requirements).

[Mark] No more so that sdp is currently, and I believe there are those who
believe that sdp is too limited in the b=... parameter. Probably the user is
going to have a fixed service level in any case in the form of an SLA that
might not bear close relationship to the media.
Besides, if you want SIP to extend to mobile (say) the likelihood is that a
call to a 'fixed' SIP UA is going to pass through some form of transcoder
(e.g. G.723 --> G.711)  that will mandate the application signalling to be
aware of the media. 
Probably the answer is not to do this in SIP but in some encapsulated body,
thereby avoiding wholesale changes to the SIP protocol and allowing non-QoS
aware applications to ignore this information.
Mark
Dave.

<loads more on this thread, snipped>