Subject: Re: SIP

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jan 1999 20:50:35 -0500

Douglas Clowes wrote:
> 
> >There are several issues here that are being roled into one. SIP does
> >not address network QoS. That is left to other mechanisms, such as RSVP
> >and/or diffserv. With RSVP, routers would reject reservations once the
> >capacity in a router is reached. With diffserv, border routers will have
> >policers to make sure that people abide by their SLA's; other mechanisms
> >might be put in place to deal with overloads. The problem you mention is
> >not SIP specific at all (which is why network QoS is not addressed in
> >SIP). What happens if everyone tries to send email? Or enter chat rooms?
> >Or make H.323 calls?
> 
> Well, H.323 bandwidth management in the H.323 gatekeeper will come into
> play. Of course, it will only limit H.323 calls and all the SIP, email and
> chat traffic will make it meaningless.
> 
> I expect similar controls, introduced into SIP to have a similar lack of
> intended effect.

Yup. Controls in a SIP server are good for localized policy decisions,
(Joe can't make video calls), but for decisions based on global network
state - well, thats really not feasible.

> Some sort of bandwidth management, and payload prioritization, is required
> to offer some level of control over QoS. That is, and ought to be, outside
> of SIP/H.323 and firmly within the underlying transport system which, at
> least for H.323 (and I suspect for SIP), can be something other than IP.
> 
> As I understand it, and Jonathan will correct me if I'm wrong, RSVP is
> supposed to "gurantee" bandwidth, while diffserv will prioritize the
> traffic. In the former case, the call should be good or fail while in the
> latter, if there is too much "high priority" traffic it will all be bad.

Actually, its not if there's too much high priority, its if the amount
of high priority traffic reaches link bandwidths. If you implement the
EF PHB using a priority queue, and you expect on average 10% of the
network bandwidth to be voice (which the ISP marks as EF), in an
absolute catastrophe there is still 90% of the bandwidth left that the
priority queue could usurp. If a priority queue isn't used it might be
less. So, in a network with lots more data traffic than voice, things
might work quite nicely - except for the poor folks trying to send email
:)

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jan 1999 21:02:59 -0500

Jim Toga wrote:
> Call admission by H.323 Gatekeepers can be used in this case to match
> provisioning with capacity.   The behaviour might exactly mimic the current
> PSTN.

SIP servers can also do "admission control", by rejecting requests (see
my previous message). So, whatever logic you have behind the admission
decisions in RAS, you could put in a SIP server too. However, its not
clear how either a SIP server or H.323 gatekeeper would be able to
actually make a decision which mimics the PSTN. In the PSTN, the
circuits flow through the switch which makes the admission decision, and
the switch sees every setup message for a circuit that goes through it.
In the Internet, media doesn't flow through gatekeepers or SIP servers,
and neither will have knowledge of network topologies or other
applications. So, if there is lots of web traffic on an intranet, I
don't really see how a single application specific box could know how
much bandwidth is actually available on all links between a caller and
callee. Only routers can do that, and thats why QoS control is done with
things like RSVP and diffserv.

> >What if there are no servers? What if users try and contact each other
> >directly? In that case, you will need to make use of network QoS
> >management techniques. This is also not SIP specific. If two H.323
> >terminals communicate directly, you'll have the same problem.
> 
> This is exactly why the standard stipulates that _if_ Gatekeepers are
> present, they must be utilized.

Question: besides the specification, what prevents a client from
ignoring them anyway? A big theme on another thread has been that
clients often disobey or misimplement portions of a spec. IP is IP, and
two hosts with globally routable IP addresses can always communicate.
Seems like a bullet item for a feature in fact: no call rejections - the
user's software just tries to call the other user directly, ignoring the
admission rejections.

-Jonathan R.

---

From: Douglas Clowes <[email-masked]>
Date: Fri, 22 Jan 1999 14:35:31 +1100

>user's software just tries to call the other user directly, ignoring the

Of course, if it doesn't implement the spec, it doesn't conform to the spec.

People could ignore the standards and implement their own protocol. I think
that's happened before. Once or twice.

Let's see now, a firewall with proxies that only let through known
protocols and check with the gatekeeper for H.323 admission. Scarey!

Regards,

Douglas

---

From: Scott Petrack <[email-masked]>
Date: Mon, 25 Jan 1999 12:44:32 -0500

>protocols and check with the gatekeeper for H.323 admission. Scarey!

In H.323 you would probably use "gatekeeper routed calls" - that is, the
gatekeeper itself is the signalling proxy that only lets though known and
permitted signalling, and tells the relevant RTP firewall what to let
through. (But this is just quibbling with the words you use).

And if the signalling is SIP then you replace "gatekeeper" with "SIP proxy
server."

Although you can do it this way, unfortunately you have created -- the
phone system! That is, the RTP firewall looks a lot like a switch, because
you have to make certain that all the RTP traffic goes through that box.
The originating endpoint will never see the RTP address of the remote
endpoint, but only the address of the RTP firewall. So all of end-to-end
routing has been thrown away -- just like in the phone system.

Of course, similarly, we will need, SMTP firewalls and special DNS servers
which can give out addresses of MX machines which can do QoS email, and
other special DNS servers and HTTP firewalls which can do QoS web-browsing,
etc. etc. etc. In the end we will have overlaid 1000 different parallel
Internets on top of the current Internet. I know many people who share this
"dream". 

A better, more scaleable, goal, is to separate out the QoS infrastructure
from the needs of any particular application, and instead of having H.323
Gatekeepers, HTTP Gatekeepers, SMTP gatekeepers, etc. etc. etc., just
having an infrastructure for QoS that allows applications to seize the
required Internet resources without any reference to any particular
application.

It may end up being impossible to do, but it's the only hope that we'll get
QoS for all the Internet applications that need it.

It may well be that there is still a need for the single-application
servers, in order to enable really dumb hard-coded appliances that will not
want to deal with the QoS signalling themselves. But these servers will
need to hand-off decision-making to the real QoS infrastructure. 

Scott

---

From: Jim Toga <[email-masked]>
Date: Tue, 26 Jan 1999 08:34:44 -0800

Scott,

A couple of quick comments...

1) The 'switch' does not live in the 'network'.  The reason for existence
(in this discussion,) I thought, was for security aspects.  The whole point
is that you _want_ to keep the addressing/direct access isolated (or at
least monitored).  If you have a completely armored protocol(s)/box then
you don't need it.  ('course try and convince any IT dept...)

2) You can certainly reserve/deliver QOS on a 'generic' IP level.  It would
seem that if you want to allocate the QOS on an application basis (so that
we get "QOS for all the applications that need it") -- somebody has to be
coordinating at this level.  If this maps into an abstraction like DIFSRV
that's fine, but it still can't be a free-for-all with reservations....
Otherwise you simply end up with WinSock2 calls to RSVP... ;-)

jiimt.