Subject: Re: SIP

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 21 Jan 1999 16:05:34 -0500

"Paul E. Jones" wrote:
> 
> Hanlin,
> 
> This is one of the very issues that I have struggled with.  In the Internet
> environment, protocols consume bandwidth as they need.  Latency can be high,
> but it is tolerable.  The idea of introducing voice and video into the IP
> network means that there must be some control over the bandwidth, otherwise
> the quality of the call (if the call can be placed at all) will suffer.
> 
> Imagine this scenario:  an earthquake strikes California.  Everybody in the
> state and out of the state attempts to place calls in and out of the
> earthquake zone to check on friends and family.  Today's telephone equipment
> will allow a certain number of calls to succeed-- all other attempts will
> fail due to busy circuits.  With the use of SIP in an IP telephone device,
> there is nothing (that I can see) that would prevent everyone from
> attempting to place calls simultaneously.  The end result is that all of the
> calls would suffer to the point that nobody could understand anything said
> on the call.  Something must control the traffic.
> 
> Surely the SIP designers have planned for this scenario.  I would love to
> know how the situation would be handled in a SIP environment.

SIP does not control network resource usage; that's the role of RSVP,
diff-serv, etc. Indeed, it likely avoids the signaling overload problem
encountered by traditional PSTN services as it may bypass all but the
final end system. Since SIP can transmit limited out-of-band data, the
California earthquake situation would actually handled much more readily
by SIP:

INVITE [email-masked]
From: [email-masked]
Subject: I'm fine but all the china is in pieces

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 21 Jan 1999 15:45:13 -0500

Hanlin,

Best Regards,
Paul

-----Original Message-----
From: [email-masked] <[email-masked]>
To: Jonathan Rosenberg <[email-masked]>
Cc: Aishling <[email-masked]>; [email-masked]
<[email-masked]>
Date: Wednesday, January 20, 1999 12:34 AM
Subject: Re: SIP

>My question is that: if you don't use proxy server in SIP, how can you get
>control and management capability comparing with H.323 gatekeeper system?
>If you use proxy server model, is there any significant difference between
>H.323 and SIP?
>Thanks for any comments!
>
>Hanlin
>
>
>---------

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jan 1999 16:26:45 -0500

> know how the situation would be handled in a SIP environment.

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?

Given that, there are certainly mechanisms within SIP which allow you to
restrict call volumes, independent of whether there is sufficient
network capacity. A proxy can simply reject calls after the number of
calls through it exceed some maximum, or if the request rate exceeds
some peak. Any criteria, at the discretion of the implementor, can be
used to reject a call. In SIP, the call is rejected by having the server
send a 600 class response. Given that SIP INVITE's usually carry SDP
(which contains media parameters, like codec types and possibly
bandwidth usage), a server could also use this information to try to
restrict "total bandwidth usage" in some abstract, topology independent
definition of the term.

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. 

-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
---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Douglas Clowes <[email-masked]>
Date: Fri, 22 Jan 1999 10:52:29 +1100

>SIP). What happens if everyone tries to send email? Or enter chat rooms?

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.

>terminals communicate directly, you'll have the same problem. 

At least H.323 mandates the use of the gatekeeper, if present.

But Jonathan is absolutely correct. Well, at least relatively correct.

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.

Douglas

---------

---

From: Jim Toga <[email-masked]>
Date: Thu, 21 Jan 1999 16:42:01 -0800

A couple of comments - 

jimt.

At 1/21/99 -0500, Jonathan Rosenberg wrote:
[SNIP]

>SIP). What happens if everyone tries to send email? Or enter chat rooms?

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.

[SNIP]

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

>-Jonathan R.
+1-503-264-8816(voice)              Intel - Hillsboro, OR
 mailto:[email-masked]         mailto:[email-masked] 
 PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41 

---------

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 21 Jan 1999 19:51:05 -0500

Douglas Clowes wrote:

> least for H.323 (and I suspect for SIP), can be something other than IP.

Transport can be IP, IPX, X.25, PSTN (see the PINT work), ATM or
anything else that has an address of some sort. You may have to define
the address format for SDP carriage, however. Currently, PSTN and IP is
all we got there.

> latter, if there is too much "high priority" traffic it will all be bad.

With a somewhat more gradual degradation, since you can tolerate
anywhere between 1 and 10% packet loss (more with FEC, but then your
bandwidth goes up) while still being able to communicate.

---

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

> provisioning with capacity.   The behaviour might exactly mimic the current

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.

> 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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jan 1999 20:50:35 -0500

> I expect similar controls, introduced into SIP to have a similar lack of

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.

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

---

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: "James Verlare" <[email-masked]>
Date: Fri, 22 Jan 1999 07:17:18 -0700

It seems to me that the answer lies in GateKeepers that provide admission
control with the help of external network monitoring serives.  RSVP is
responsible for capacity from segment to segment, diffserv for prioritizing
up to the last 100 meters, end stations NIC drivers in comnination with
diffserv determine CoS for that end station.  An external load monitoring
service keeps the GateKeeper informed so it can respond intelligently to
admission requests.

JLV.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jonathan
Rosenberg
Sent: Thursday, January 21, 1999 7:03 PM
To: Jim Toga
Cc: Paul E. Jones; [email-masked]; Aishling;
[email-masked]; [email-masked]
Subject: Re: SIP

-Jonathan R.

---------

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 25 Jan 1999 11:47:09 -0500

> present, they must be utilized.
I just hide when the protocol police come knocking. Lucky I haven't been
caught yet. Whew.

---------

---

From: Jim Toga <[email-masked]>
Date: Mon, 25 Jan 1999 13:38:51 -0800

From within a PDU, no one can hear you scream.....

---------

---

From: Scott Petrack <[email-masked]>
Date: Mon, 25 Jan 1999 17:46:18 -0500

>provisioning with capacity.   The behaviour might exactly mimic the current

There is unfortunately a fundamental difference between the PSTN behavior
and what an H.323 network can do. When the PSTN decides that there isn't
enough capacity, the end user gets a Network Busy signal and there is
nothing else s/he can do to affect the telephone network. This is because
of the fundamental distinction made in the PSTN between "NNI"
(network-network interfaces) and "UNI" (user-network interfaces). The
signalling which tells the switch "No you may NOT make that call" stays
entirely inside the network, and the business contracts and regulation that
bind operators guarantee that when that happens, the end user will not get
anything but a busy signal. He will not be able to mess things up for
anyone else.

But H.323 signalling is not NNI -- it goes all the way out the endpoint. So
if a gatekeeper tells an endpoint (which might be a terminal) "No you may
NOT make that call", and the endpoint can get via other means (say email)
the RTP address of the remote endpoint. He can blast away. It may sound
bad, and not many packets might get through, but he can certainly inject
the packets into the network and still mess things up for everybody else.

There is no way within H.323 to connect the permission that a gatekeeper
might or might not give, with the opening and closing of IP connectivity to
the endpoint, and there is in the PSTN.

Note that even if such a connection existed, it would not really help,
because there are many different kinds of traffic which affect capacity,
not just H.323: even if the Gatekeeper really could stop me from sending
RTP traffic from being sent when it forbids an H.323 call to complete, it
won't be able to stop me from sending Email, ftp, etc. 

The bottom line is that Gatekeepers are not enough, unfortunately, although
the analogous mechanism is enough in the PSTN -- because the business
contracts and laws are there and because there is only one single
application running (voice).

>present, they must be utilized.

Yes, and _if_ seatbelts are present, they must be utilized. The law says
so. But as long as there are cars which go on the highways even if you
don't buckle up, then innocent people are not going to get their very
precious little packets trashed because of people who don't listen when the
red "gatekeeper" light flashes on their dashboards.

Scott

---------

---

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.

---------

---

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

Scott,

some more (with all due respect :-)  ) rebuttal....

(this could be start of some many long discussions.....)

jimt.

At 05:46 PM 1/25/99 -0500, Scott Petrack wrote:
>But H.323 signalling is not NNI -- it goes all the way out the endpoint. 

Not if it doesn't get the address resolved from the GK.

>So
>the RTP address of the remote endpoint. He can blast away. 

Only if the two are in colusion with the same 'illegal' protocols.  I can
do all sorts of things if I were sufficiently sophisticated and have access
to the shared medium. I'm not saying that every implementation is
'correctly' written or behaves well, simply that the protocol (even SIP)
doesn't disallow from creating a working, tight system.

>It may sound

YADOSA  (yet another denial-of-service attack)

>the endpoint, and there is in the PSTN.

In a re-programmable system - agreed.

>won't be able to stop me from sending Email, ftp, etc. 

Agreed.  Two different sides to the QOS coin.  

Make sure application X doesn't step on applications A, B, C....  
Make sure application X doesn't get stepped on by appications A, B, C....

>application running (voice).

I agree that GKs are not enough - by themselves.  I'm not sure that I agree
that this has anything to do with protocols or single media.  The PSTN
model works because the barrier to connections (physical) is pretty high.
I _have_ to have a wire (or cell site). If I climb the pole outside my
neighbors house or put alligator clips on his NID, I've 'hacked' the
network and done denial of service on his phone.  Obviously I can't get
'services' that aren't allocated to that line, but whatever resources
aren't strictly 'monitored' I can appropriate.

>red "gatekeeper" light flashes on their dashboards.

Entirely agree that there are no standards police.  This is why there is a
public key/checksum in cable boxes.  It may be that that is what is requred
by IP applications some day to authenticate tamper-proofing. 

Car analogy is kind of weak ;-) but, to carry it further;  I'll take a
head-on with a five-point harness against you with a flashing red light any
day... 
(This implies that routers etc... act as the laws of physics in this case)

---------