Subject: RE: [IPTEL] CPL Question About Priority

From: "Mark Gibson" <[email-masked]>
Date: Thu, 30 Nov 2000 13:18:06 -0000

I think that there's another angle on this debate that's being ignored. I
might be willing to buy the fact that RSVP is OK to get me a QoS pipe
providing my network policy layer is working efficiently and I can provision
my core. However I think this problem also encompasses resilience to mass
calling events and alternative operator selection.

In the former case, assuming the manyfolks operation (which I'm not
massively familiar so do forgive inaccuracy), there are still some 3-4
rounds trips of SIP signalling before the RSVP layer comes back and says
"sorry, not enough bits" and the session clears down. Under mass calling
event conditions this is a lot of signalling, probably enough to bring
servers down - lets face it, the current PSTN creaks when Ticketmaster has
hot tickets for sale. Especially when you consider that this signalling is
likely to be concentrated at border Proxies. Surely its better for that
Proxy to be pre-warned that it just can't accept new sessions and reject the
call there & then.

In the latter case, I might have a preferential billing arrangement with one
core provider but will accept a provider that will route my call according
to certain service level conditions. As things like price are likely to be
cumulative and depend on trading agreements between operators, its unlikely
that we can source define a single best route so I'd like to try a number to
find the optimal one. And I will want to choose before RSVP establishes a
connection that I don't want to pay for. So I either, 

a) sort this out using the SIP signalling round trips - perhaps define an
sdp equivalence that does costing of routes and availability discovery and
extend SIP to permit forking and recombining INVITE without generating a
loop-detect error to nip call attempts that can't be handled in the bud

b) develop extensions to RSVP for its POLICY_ELEMENT to allow source routing
to be indicated (loosely) and perhaps cumulative cost and use COPS to tell
the management layer and have it signal the billing layer as to the final
route.

Note that b) runs the risk of the call blocking when its requirements cannot
be met at a point after resource has been committed by the Resv but before
the end-to-end connection is established, causing possible future call
blocking.

I appreciate that this is reasonably off topic for most of this list but its
clearly important. If anyone wants to take this offline and explore this
signalling and reservation issue in more detail perhaps we could get
together with Mike and Lakshmi.

Cheers

Mark Gibson

 -----Original Message-----
From: 	Jonathan Rosenberg [mailto:[email-masked]] 
Sent:	Thursday, November 30, 2000 4:22 AM
To:	'Lakshmi Krishnamurthy'; hammer michael
Cc:	[email-masked]
Subject:	RE: [IPTEL] CPL Question About Priority

Correct, the application knows best what its QoS requirements are. And thats
why IETF has developed protocols like RSVP that allow the users to ask the
network for various levels of QoS. Whether it scales or not is a separate
discussion thats out of scope here.

As per senders of IP packets getting to determine the route through the IP
network; there is the possibility of such a thing using loose source IP
routing. But, in practice, this is never done and frought with problems.
There are serious topology discovery and other issues that need to be
resolved; a minor problem is that packets marked with loose source routes
are slow-path on routers, resulting in increased delay. I don't think anyone
uses loose source routing at all.

That aside, this is all completely out of scope for CPL. As Jonathan L. has
correctly observed, SIP signaling routing is completely orthogonal to media
routing, and for really, really good reasons (i.e., not re-inventing yet
another forwarding, switching, routing layer within the network just for
RTP; the IP network already knows how to deliver the RTP packets in the most
direct path from originator to recipient).

-Jonathan R.

> -----Original Message-----
> From: Lakshmi Krishnamurthy [mailto:[email-masked]]
> 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 accomodated by the 
> network. There needs to be a way of communicating this requirement to 
> the IP layer.
> 
> This need not be an explicit list of QoS params, but 
> something that is a 
> user-friendly mapping could be in order.
> 
> 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
> 
---
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

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

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 30 Nov 2000 08:22:58 -0600

Mark Gison writes:

>RSVP layer comes back and says "sorry, not enough bits" and the session
clears down
The new drafts
http://ietf.org/internet-drafts/draft-gross-sipaq-00.txt
http://ietf.org/internet-drafts/draft-gross-cops-sip-00.txt
clearly take the approach that if RSVP reservation fails, the caller is
given the option to continue the call without QoS.

>there are still some 3-4 rounds trips of SIP signalling
The amount of messaging has also been minimized, please see
http://ietf.org/internet-drafts/draft-johnston-sip-osp-token-01.txt

>use COPS to tell the management layer and have it signal the billing layer
Great minds think alike :-)
Please again, see the above.

The topic area around SIP-Resources-AAA is surfacing again and again  in
various drafts, so I look forward to a good discussion in the WG.

Henry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Mark Gibson
Sent: Thursday, November 30, 2000 7:18 AM
To: 'Jonathan Rosenberg'; 'Lakshmi Krishnamurthy'; hammer michael
Cc: [email-masked]
Subject: RE: [IPTEL] CPL Question About Priority

 -----Original Message-----
From:   Jonathan Rosenberg [mailto:[email-masked]]
Sent:   Thursday, November 30, 2000 4:22 AM
To:     'Lakshmi Krishnamurthy'; hammer michael
Cc:     [email-masked]
Subject:        RE: [IPTEL] CPL Question About Priority

---