Subject: RE: [Sipping] new draft on overload control in SIP

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 27 Feb 2006 02:02:41 -0600

Hi,

Some comments 

1. REQ 8 is written with view of binary overload state. Once the request
is rejected by overloaded SIP Entity, It should not be attempted for the
Server Entity with same or greater % of overloaded SIP entity. It
applies to REQ 9 too. 

2. How does this work will be related to Event Throttling work ? 

3. It needs to captured calls which are accepted before the overload
condition how they will be treated when overload occurs, in terms of
reINVITE  etc ?

4. Draft has  been talking in terms REQUEST (Title also has reqs). How
it will be handling Response overload ? I think we need to be more
specific in this. E.g. Bad Guy might send INVITE to different SIP
entities giving the top via as the Server to be attacked. It will
generate 100 Trying flood to the server, which are no where related.
Responses are not authenticated and with TLS also, one can have trusted
bad SIP entity. 

   I view Avalanche restart as DDOS. There can be other DDOS scenarios
too. Special request such as ACK which don't have any response, needs to
be captured. One can launch unrelated ACK flood too. 
We should have a REQUIREMENT capturing "SIP REQ / RSP messages with or
without ...... "

5. In Section 5, Where REQUIREMENTS are listed, we don't see requirement
for the  server overload
 caused on the other Non SIP (DNS/DHCP) servers due to SIP ? SIP Servers
are okay  to handle load, 
 but other server fails. Whether mechanism will detect this ? Just to
clarify whether REQ 2 covers this. It will be better if we have DNS/DHCP
( or SIP / Non SIP) captured in that.

6. How does Server Overload relate to Network Congestion ? Server
Overload might be happening because of network congestion and in some
scenarios server overload might cause network congestion.
Whether mechanism to be proposed will do any help in narrowing it down
or reconfiguration ?

6. Nits, Figure 1 is mentioned at Page 5, but it is not there.
 
7. Overload data should be captured in MIB for performance management
applications, or is it left for properitary interfaces ?

Thx
Samir 

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Saturday, February 25, 2006 12:30 PM
To: IETF Sipping List
Subject: [Sipping] new draft on overload control in SIP

Folks,

I've just submitted an I-D on the topic of overload control in SIP. 
Until it appears in the archives, you can pick it up at:

http://www.jdrosen.net/papers/draft-rosenberg-sipping-overload-reqs-00.t
xt

The draft talks about the general problem of overload, and points out
some serious problems with the current 503 mechanism. In particular, the
current mechanism can amplify network load substantially during periods
of overload. The draft calls out requirements for a solution.

I believe this is an important topic. Comments are welcome.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Darshan Bildikar <[email-masked]>
Date: Mon, 27 Feb 2006 14:12:38 +0530

One question...

Are we trying to solve this problem through protocol (new headers / new
method?)...

If yes, why? 

Say proxy A knows that server S1 cannot handle more than 20 Invite
transactions per second then why should it attempt new calls to that server.
What I'm trying to say is that this problem can be solved through a
configuration mechanism i.e. a proxy already knows the rate at which servers
can handle calls and makes sure that calls are not forwarded at more than a
pre defined rate (also can be configured to say, drop one out of every 5
calls at 70% load). 

This kind of mechanism would be useful between proxy - proxy, proxy -
server, server - server interfaces, right? 

The basic point I am trying to make is that the problem is solvable through
static configuration instead of SIP entities exchanging overload information
in real time. 

Am I missing something basic here?

Darshan

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Saturday, February 25, 2006 12:30 PM
To: IETF Sipping List
Subject: [Sipping] new draft on overload control in SIP

Folks,

Thanks,
Jonathan R.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 27 Feb 2006 08:50:54 -0500

Your comments make sense if there is only one proxy feeding the server. 
But what if there are many? Configuring static limits in all the proxies 
will lead to statistical inefficiency. Mind, static limits are a good 
idea in any event, just to cover totally unreasonable flow volumes, but 
they should be set higher than the rate at which the proxy is normally 
expected to operate.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 27 Feb 2006 08:51:20 -0500

There are several reasons that this doesn't work:

1. a SIP entity doesn't know the full set of downstream elements it will 
EVER talk to, and worse yet, in cases like proxy-proxy where the servers 
cross administrative domains, there isn't a real way to pass 
configuration information.

2. The actual capacity of an element depends on request types, 
extensions used, and so on. Thus, capacity is not easily expressed as a 
single figure. In reality the element has a queue, and if the queue 
starts to fill, its getting congested. Feeding this information 
backwards requires protocol mechanisms.

3. Its extremely brittle. All it takes is one change of a server 
somewhere (upgrade from a big box to a smaller one), or change of an IP 
address on a host, and the configuration no longer matches the network 
topology.

4. Its extremely hard to manage; this is related to (3), but even 
assuming it was always correct, it requires a lot of management 
complexity to configure this everywhere.

There is a lot of precedent for overload control within signaling 
protocols. ss7 certainly does it (call gapping). Its also a fundamental 
part of transport protocols, such as tcp and sctp. I believe there are 
also packages for MGCP too. No doubt it exists in other places.

-Jonathan R.