Subject: RE: [Sip] SIP Congestion Control

From: [email-masked]
Date: Thu, 1 Aug 2002 12:02:24 -0400

I remember a discussion quite some time ago about congestion control in 
SIP. Just found its reference:

http://www1.ietf.org/mail-archive/working-groups/sip/current/msg00143.html

Personally, I think dropping messages should be only after you cant 
respond with 503 (so uacs can then use SRV to try alternate routes)

regds
arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301-212-7860        (M): 240-997-0066

"Mark Watson" <[email-masked]>
Sent by: [email-masked]
08/01/2002 11:05 AM

        To:     "[email-masked]'" <[email-masked]>, "Naidu, Venkata" 
<[email-masked]>
        cc:     [email-masked]
        Subject:        RE: [Sip] SIP Congestion Control

> [Amish] My question applies to the case where possibly a 
> large number of SIP 
> INVITEs are being sent to a proxy or media server. They are 
> is overload since 
> they are unable to process such a large number of requests 
> simultaneously. This 
> is analogous to the case in the PSTN where an exchange is 
> unable to process a 
> large number of calls. In the PSTN this is dealt with using 
> the ISUP ACC to get 
> the adjacent nodes to throttle back their traffic. 
> 
I think there is an important difference between ISUP ACC and SIP in this 
respect. The ISUP ACC mechanism is based on a model of a non-distributed 
system in which the exchange attempts to provide a valid response to every 
ISUP IAM coming in. Starting from a point at which the exchange can fully 
process all messages sucessfully, as the offered load increases, the 
exchange starts to reject some IAMs with release due to overload. As the 
offered load increases further, the processing time used to send these 
rejections increases and starts to reduce the processsing time available 
for completing sucessful calls.
Increasing the offered load further, you reach a point where all the 
processing time is used to reject IAMs, and there is no sucessful traffic. 
The solution is to request adjacent nodes to reduce the offered load, 
hopefully stabilising it at the point at which all messages are 
sucessfully processed.
In my view, this is not a very good design, because the exchange is 
relying on other elements in order to maintain its own integrity. If those 
other elements do not behave as expected, then the capacity of the 
congested element drops.
As I understand it, in SIP, messages can just be dropped if they cannot be 
processed. There is potentially no processor load associated with dropping 
the packet. This causes the sender to back-off on retransmits (the sender 
doesn't see any difference between network congestion and nodal overload).
I know this is a bit of a simplistic view, but I'm sure someone will 
correct me if it's completely wrong :-) 
...Mark 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 01 Aug 2002 12:17:31 -0400

Remember also that TCP offers flow control, so that the upstream proxy 
will be throttled automatically. No packets lost and standard backpressure.