Subject: Re: [Sip] SIP Congestion Control

From: [email-masked]
Date: Thu, 1 Aug 2002 12:15:08 +0530

Taking an analogy from the ACC procedure defined for ISUP, as well as Tom's
comment below, it is the network management entity at the servers that will
have to detect, indicate(to other/adjacent  servers) and act when such
'overload condition' occurs on the SIP servers.

The support that would be required by the NM entities would be an ability
to communicate the overload condition(levels or whatever) to the servers it
is connected to.

The NM entities residing on the adjacent servers can then take suitable
actions.

So, as far as SIP is concerned it should be sufficient to have a mechanism
by which NM entities can exchange overload indications over SIP.
The INFO method may be used for this purpose to share such application
level information. This may not be exactly similar to ACC procedure  in
ISUP where the REL message is used to convey the overload congestion
levels, but the purpose would be served equally well.

regards
Harsh

[email-masked] on 07/31/2002 10:35:15 PM

To:   [email-masked]
cc:   [email-masked]

Subject:  Re: [Sip] SIP Congestion Control

 Wouldn't this sort of load shedding or load balancing issue be best dealt
with at the application and not the protocol layer.

[email-masked]@ietf.org on 07/31/2002 11:34:51 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  [Sip] SIP Congestion Control

Hi,

Does SIP support congestion/flow control methods during application level
processing overload? (e.g. something equivalent to ISUP's ACC)

This is typically for scenarios where there could be a burst of calls
(possibly
due to some media stimulated event) and hence a burst of SIP messages. The
target of these messages could either be a proxy server, voicemail server
or
some other media server.

I am assuming there are sufficient resources in the IP network and no
packets
will be dropped.

From going through RFC3261 SIP seems to rely on the congestion controls of
the
transport protocols.
draft-willis-sip-congestsafe-00.txt also seems to address the case where a
transport network protocols like TCP and SCTP provide feedback control.

Thanks,
Amish

***************************************************************************
****

Important.
Confidentiality: This communication is intended for the above-named person
and
may be confidential and/or legally privileged. Any opinions expressed in
this
communication are not necessarily those of the company. If it has come to
you
in error you must take no action based on it, nor must you copy or show it
to
anyone; please delete/destroy and inform the sender immediately.

Monitoring/Viruses
Orange may monitor all incoming and outgoing emails in line with current
legislation.  Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually virus
free.

Orange PCS Limited is a subsidiary of Orange SA and is registered in
England No
2178917, with its address at St James Court, Great Park Road, Almondsbury
Park,
Bradley Stoke, Bristol BS32 4QJ.
***************************************************************************
****

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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: [email-masked]
Date: Thu, 1 Aug 2002 09:40:41 +0100

Venkata,

See my responses below...

"Naidu, Venkata" <[email-masked]> on 31/07/2002 17:27:49

To:   Amish CHANA/EN/HTLUK@HTLUK
      [email-masked]
cc:

Subject:  RE: [Sip] SIP Congestion Control

Amish,

-> I am assuming there are sufficient resources in the IP
-> network and no packets will be dropped.

  Then where is the congestion in the network?

[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.
To get back to your  congestion. If by network we refer to the IP network
between the UAs, proxies, media servers, etc. Then there is no congestion in the
network. We have overloaded servers.

-> From going through RFC3261 SIP seems to rely on the
-> congestion controls of the
-> transport protocols.
-> draft-willis-sip-congestsafe-00.txt also seems to address
-> the case where a
-> transport network protocols like TCP and SCTP provide
-> feedback control.

  I don't think congestion control, flow control methods
  are required in session/application level protocols
  when they depend on well tested, extensively reserached
  transport protocols (like TCP and respective extensions).

[Amish] Yes. But how is application level processing overload addressed if the
transport level is working perfectly - i.e. no packet loss, delays, etc.?

-Amish.

  Looks like every higher layer protocols are trying to
  solve their own congetion/flow control. Yes! I agree
  that there must be some corner cases where you can
  optimize/improve protocols (like SIP, BGP etc) when there
  is much stress. But the problems you are trying to solve
  are very corner cases when you implement congestion/flow
  control in SIP, BGP etc

  I feel that this is duplicate work unless SIP is going
  achieve good preformance improvement with it's own
  congestion/flow control mechanisms when compared to
  best TCP extension(s).

--
Venkata.

*******************************************************************************
Important.
Confidentiality: This communication is intended for the above-named person and
may be confidential and/or legally privileged. Any opinions expressed in this
communication are not necessarily those of the company. If it has come to you
in error you must take no action based on it, nor must you copy or show it to
anyone; please delete/destroy and inform the sender immediately.

Monitoring/Viruses
Orange may monitor all incoming and outgoing emails in line with current
legislation.  Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually virus free.

Orange PCS Limited is a subsidiary of Orange SA and is registered in England No
2178917, with its address at St James Court, Great Park Road, Almondsbury Park,
Bradley Stoke, Bristol BS32 4QJ.
*******************************************************************************

---

From: [email-masked]
Date: Thu, 1 Aug 2002 10:14:18 +0100

Harsh,

See my response below.....

[email-masked] on 01/08/2002 07:45:08

To:   [email-masked]
cc:   Amish CHANA/EN/HTLUK@HTLUK
      [email-masked]

[Amish] I agree.

[Amish] I received two off-line emails after this post suggesting the use of 503
Service Unavailable. IMO using 503 seems to be a better approach.
I would say that a method of exchanging overload information (and possibly
actions at the receiving end - if it is a proxy) needs to be clearly specified
so that actions at the transmitting end are predictable.

-Amish

regards
Harsh

To:   [email-masked]
cc:

Hi,

Thanks,
Amish

Important.

Monitoring/Viruses

Monitoring/Viruses

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 1 Aug 2002 16:05:19 +0100

> 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

---

From: [email-masked]
Date: Thu, 1 Aug 2002 17:00:33 +0100

Mark,

See my response below .......

------------------------------------------

[Amish] Isn't this equivalent to the affected proxy or media server relying on
other elements (proxies and UAs) to back-off in order to maintain its own
integrity. What happens if those elements do not behave as expected?

the packet.

[Amish] I disagree with that point. It's an implementation issue and the message
may incur some processing load on the server. Furthermore it may not be
advisable to discard just any SIP message. INVITEs can be discarded but ACKs and
other messages should not be discarded. And in order to determine the message
type you have to process the message. :-)

This causes the sender to back-off on retransmits (the sender
doesn't see any difference between network congestion and nodal overload).

[Amish] But if there is a sufficiently large pool of UAs, this method may be of
little help. It would be better to get the the intermediate proxies to reduce
their INVITEs and not block messages from sessions already in progress.
 The 503 Service Unavailable may be an option as some have already commented.

--Amish

Monitoring/Viruses

---

From: [email-masked]
Date: Thu, 1 Aug 2002 12:20:32 EDT

> elements do not behave as expected, then the capacity of the congested 

It is impossible to operate a network without one element being able to rely 
on others to behave properly. Especially for overload control. Simply 
dropping packets when you can't handle all of them isn't a good design, since 
you don't know which ones to drop and it just causes the sender to try again. 
Deciding which to drop requires some processing. While this processing can be 
kept to the minimum (like by looking at a drop precedence in the header), it 
is always better long-term to rely on someone else to stop sending the 
overload. Dropping is always the last resort.

Mike Pierce
Artel

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 1 Aug 2002 17:34:36 +0100

Mike,
 
I agree that dropping is always a last resort. My point was just that the
overall system is more robust if individual nodes are integral in their own
right i.e. they can keep on working, and doing useful work, without having
to rely on other nodes performing certain functions.
 
I'm just saying that you should not rely on adjacent in order to prevent
your node failing altogether, especially when those nodes themselves may
also be subject to overload.
 
ACC is by no means universally used within the PSTN. It is a mechanism to
optimise throughput during overload, not a mechanism to ensure the basic
integrity of the exchanges.
 
Of course if you have more messages than capacity, it's good to have ways of
determining which messages most deserve your attention i.e. which will most
likely lead to completion of calls.
 
...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 01 August 2002 17:21
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Re: [Sip] SIP Congestion Control

It is impossible to operate a network without one element being able to rely
on others to behave properly. Especially for overload control. Simply
dropping packets when you can't handle all of them isn't a good design,
since you don't know which ones to drop and it just causes the sender to try
again. Deciding which to drop requires some processing. While this
processing can be kept to the minimum (like by looking at a drop precedence
in the header), it is always better long-term to rely on someone else to
stop sending the overload. Dropping is always the last resort. 

Mike Pierce 
Artel

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 5 Aug 2002 13:36:07 -0500

amish.chana asked:
> Does SIP support congestion/flow control methods during 
> application level processing overload? (e.g. something 
> equivalent to ISUP's ACC)
> 
> This is typically for scenarios where there could be a burst 
> of calls (possibly due to some media stimulated event) and 
> hence a burst of SIP messages. The target of these messages 
> could either be a proxy server, voicemail server or some 
> other media server.

Even if a reliable transport like TCP is used, it may be possible for
messages to be delivered to an element faster than that element can
process those message. This results in queueing-up incoming messages.
Generally queue space is not infinite, and there is a related issue with
retransmission timers.

I've seen implementations that manage to handle this very effectively by
having the overloaded element issue a 503 (Service Unavailable) response
to new requests that it will be unable to process effectively. This can
be combined with a Retry-After header to indicate a minimum delay that
the requester must apply before resubmitting the request. There are also
techniques whereby a proxy can  start "ducking" by doing things like
returning a 302 response redirecting the request to a load-balancing
element instead of queueing the request.

For example, assume a proxy server capable of processing 100 requests
per second receives 200 requests per second. After 5 seconds, it has
processed 500 requests accumulated a direct queue of 500 requests. Of
course, some of the requests will have timed out and been retransmitted,
increasing the queue further. Obviously, continuance in this kind of
overload condition results in total meltdown, so we have to DO
SOMETHING.

This leads to a couple of design principles:

1) Stateful proxy servers should send provisional responses quickly,
reducing retransmission.
2) When there are multiple identical requests in a queue, some sort of
discard algorithm is needed to prevent redundant procesing. There are
many design alternatives here, and management of this is a big factor I
would consider when doing an evaluation of commercial proxy servers.
3) The proxy needs an awareness of its queue depth and processing rate,
and needs to switch to 503 responses or some alternate mechanism (such
as invoking a load balancer) when it detects an overload condition.

All of these things are enabled by the protocol, but HOW to use them
effectively for scaling and reliability management is beyond the scope
of the SIP protocol specification, just as building large scale web
servers is beyond the scope of the HTTP specification. This is a major
differentiator between systems -- lots of people can implement the basic
specification, but there aren't many people out there who have really
thought through the usage of these elements in building large-scale
systems. There are really big differences between the "research grade"
free proxies or "workgroup" scale stuff you can get bundled with various
operating systems and commercial scale architectures capable of
supporting tens of millions of users. That's why the big stuff is
expensive. Of course, not everything expensive actually works right, so
ask questions carefully . . . And yes, this is the kind of thing that
keeps me up nights. It's quite an interesting problem space. Lots of
opportunity for graduate projects, I think. If you want to fund some
research work here, let me know -- I may know people interested in
pursuing it.

--
Dean