Subject: Re: [sip-overload] consensus call: overload-design draft as wg item

From: "Sheshadri Shalya (svshesha)" <[email-masked]>
Date: Mon, 14 Jun 2010 16:03:29 +0530

Volker,
Thanks for the clarifications. See inline for my responses:

Thanks,
-Shesh

-----Original Message-----
From: Volker Hilt [mailto:[email-masked]]
Sent: Saturday, June 12, 2010 6:10 AM
To: Sheshadri Shalya (svshesha)
Cc: Salvatore Loreto; [email-masked]; Parthasarathi R (partr)
Subject: Re: [sip-overload] consensus call: overload-design draft as wg item

Shesh,

> I looked at the overload design draft and the overall the approach seems
> fine to me, but there are some points which needs more clarity as below:
>
> 1. In the Introduction section, it is mentioned that the lack of
> resources that could result in overload may include CPU, memory, n/w
> bandwidth, input/output or disk resources. I would like to also include
> other resources like DSP, DS0/trunk circuits as other resources which
> can potentially cause overload in the SIP server (eg., PSTN gateway,
> SBCs handling media etc).
>
RFC 4412 already defines an error code for no trunk circuits, which I
believe is the correct thing to use. 
 
[svshesha:] IMO, This RFC helps in prioritize the specific call and not intended for handling overload. Adding the authors of this RFC for their comments [\svshesha:]
 
Overload control aims at preventing signaling overload in a server. If a server can't serve a request for
another reason and there is an error code for this condition, the server
should use this error code.

[svshesha:] The call rejection error code could be different for various scenarios (like 503, 488 or 408 etc). From the overload perspective, the end result is same, ie., not able to service the SIP request. Since overload can occur for various reasons, I believe, we should not limit the idea/design to 503 overload alone. [\svshesha:]

> 2. There are couple of examples mentioned - PSTN GW which runs out of
> trunk circuit, but having enough CPU rejecting the INVITE with 488 and
> another example of SIP registrar rejecting REGISTER request with 500 on
> loosing connectivity to registration database. I am not able to
> understand why overload control mechanism do not apply to these
> scenarios
>
In these cases, the server can return the error code defined for this
case (also see my comment above).

[svshesha:] I agree that the error code returned could be different, but still, I believe overload control mechanism could be applicable for these scenarios as well. How will the receipient of this error code knows when such services are available again? [\svshesha:]

> In my opinion, lack of any resource could result in overload condition
> in the SIP server depending on the criticality of that particular
> resource in the network. For eg., for PSTN GW kind of scenario, trunk
> circuit may still be critical and any SIP request that needs trunk
> circuit needs to be gracefully handled using the overload control
> mechanism and avoid overloading the Server when the trunk resource
> utilization has reached its threshold.
>
Yes, there needs to be a graceful handling of these cases. However,
there are already treatments defined for these cases.

[svshesha:] Based on my understanding, returning the appropriate error code is just an indication of the reason for the call failure/rejection. But not all the error codes indicate when the system would be available to service further similar requests. For eg., 488 may just indicate the trunk circuits are not available, but there is no indication on when they will be available for further requests. I believe overload control mechanism will definitely play a role here with explicit and/or implicit mechanism of informing the upstream entity the current load/usage of trunk circuits which can help the upstream SIP entity take informed decision  on when to forward further SIP requests without getting rejection from the overloaded SIP server. [\svshesha:]

> 3. What will happen if SIP server has enough CPU, but runs out of other
> resources such as disk or input/output?
>
There are different resources that need to be considered by the
algorithm that determines whether a SIP server is in overload or not.
This may even be specific to a device. E.g., an algorithm may consider
queue length, CPU load, or request rate. If it is in danger of not being
able to process all incoming SIP requests (e.g., the input queue starts
building up) it needs to throttle traffic using overload control.

[svshesha:] RFC 4412 also talks about returning 408 for queueing. Does that mean, call rejections happening due to this error code are out of overload control mechanism. The above response indicates that these scenarios could be covered as part of overload control mechanism. Similarly, I believe the trunk circuits rejection (488) could very well fit it to overload control mechanism [\svshesha:]

> 4. In section 4, SIP processor: is it something which serves SIP
> messages alone or can this also perform other functions like media
> handling etc apart from processing SIP messages? In SBC kind of devices,
> both signaling and media might be handled in the same server and
> overload can occur while handling media, due to lack of resources like
> DSPs. Does the SIP processor include such devices as well?
>
A SIP processor is a (logical) entity that processes SIP requests. A
device that runs a SIP processor can perform other tasks as you point out.

[svshesha:] Thanks for the clarification. The overload algorithm should not depend upon the signaling message alone as other factors/tasks may leads to signaling overload.[\svshesha:]

Thanks,

Volker

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Salvatore Loreto
> Sent: Thursday, June 10, 2010 12:01 AM
> To: [email-masked]
> Subject: [sip-overload] consensus call: overload-design draft as wg item
>
> Hi,
>
> the "Design Considerations for Session Initiation Protocol (SIP)
> Overload Control" draft ( draft-hilt-soc-overload-design-00 )
> was already a wg item in the Sipping working group.
>
> At moment it is an individual submission for the SoC working group.
>
> So as chairs we want to check the consensus for adopt it as baseline for
>
> the "Design Considerations" wg item
> we have in the SoC charter.
>
> The consensus call will run until June 21st, 2010.
>
>
> ciao
> Salvatore and Volker
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jun 2010 09:39:11 -0400

> believe is the correct thing to use.

You are referring to 488 + 370 warning code?

Its not clear if 4412 suggests use of that in cases whe R-P is not used.
(Though I see nothing about it that would prevent its use in other cases.)

I had never noticed this recommendation before. Until now I have been 
under the impression that 488 (and 606) implied a persistent error 
rather than a transient one. Using it for a transient (load related) 
error disturbs me, though I'm far from certain my impression is 
justifiable. I would have expected the 488+370 to mean that the 
requested bandwidth would *never* be available.

> [svshesha:] IMO, This RFC helps in prioritize the specific call and not 
> intended for handling overload. Adding the authors of this RFC for their 
> comments [\svshesha:]
>  
> [svshesha:] The call rejection error code could be different for various 
> scenarios (like 503, 488 or 408 etc). >From the overload perspective, 
> the end result is same, ie., not able to service the SIP request. Since 
> overload can occur for various reasons, I believe, we should not limit 
> the idea/design to 503 overload alone. [\svshesha:]

I'd like to hear more discussion of this.

	Thanks,
	Paul

> [svshesha:] I agree that the error code returned could be different, but 
> still, I believe overload control mechanism could be applicable for 
> these scenarios as well. How will the receipient of this error code 
> knows when such services are available again? [\svshesha:]
> 
> [svshesha:] Based on my understanding, returning the appropriate error 
> code is just an indication of the reason for the call failure/rejection. 
> But not all the error codes indicate when the system would be available 
> to service further similar requests. For eg., 488 may just indicate the 
> trunk circuits are not available, but there is no indication on when 
> they will be available for further requests. I believe overload control 
> mechanism will definitely play a role here with explicit and/or implicit 
> mechanism of informing the upstream entity the current load/usage of 
> trunk circuits which can help the upstream SIP entity take informed 
> decision  on when to forward further SIP requests without getting 
> rejection from the overloaded SIP server. [\svshesha:]
> 
> [svshesha:] RFC 4412 also talks about returning 408 for queueing. Does 
> that mean, call rejections happening due to this error code are out of 
> overload control mechanism. The above response indicates that these 
> scenarios could be covered as part of overload control mechanism. 
> Similarly, I believe the trunk circuits rejection (488) could very well 
> fit it to overload control mechanism [\svshesha:]
> 
> [svshesha:] Thanks for the clarification. The overload algorithm should 
> not depend upon the signaling message alone as other factors/tasks may 
> leads to signaling overload.[\svshesha:]
> 
> Thanks,
> 
> Volker
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 14 Jun 2010 11:13:47 -0400

Responding below to the comments about RFC4412

[email-masked] wrote on 06/14/2010 06:33:29 AM:

> [image removed] 
> 
> Re: [sip-overload] consensus call: overload-design draft as wg item
> 
> Sheshadri Shalya (svshesha) 
> 
> to:
> 
> volker.hilt
> 
> 06/14/2010 06:34 AM
> 
> Sent by:
> 
> [email-masked]
> 
> Cc:
> 
> sip-overload, hgs
> 
> Volker,
> [svshesha:] IMO, This RFC helps in prioritize the specific call and 
> not intended for handling overload. Adding the authors of this RFC 
> for their comments [\svshesha:]
> 
While I am not an author of RFC4412, I was, so's to speak, "there at the 
birth".

RFC4412 does not, itself, "define an error code for  no trunk circuits", 
but rather provides a recommendation for how to apply the codes already 
defined in RFC3261.

   "If the request fails because the RP actor cannot handle the signaling
   load, the RP actor responds with 503 (Service Unavailable).

   If there is not enough bandwidth, or if there is an insufficient
   number of trunks, a 488 (Not Acceptable Here) response indicates that
   the RP actor is rejecting the request due to media path availability,
   such as insufficient gateway resources.  In that case, [RFC3261]
   advises that a 488 response SHOULD include a 'Warning' header field
   with a reason for the rejection; warning code 370 (Insufficient
   Bandwidth) is typical.

   For systems implementing queueing, if the request is queued, the UAS
   will return 408 (Request Timeout) if the request exceeds the maximum
   configured waiting time in the queue."

This short extract illustrates several points.

First, while RFC4412 is not intended for "handling overload" in the sense 
of reducing the received load at any particular server, it IS intended to 
deal with a system that IS overloaded, servers, links, or both.

Second, RFC4412 separates "server overload" from "insufficient bandwidth". 
 The only solution available, when RFC4412 was written, for "server 
overload" was "503", which has been shown to be inadequate.  THAT is the 
situation that the SIP-overload group is chartered to address. 

When RFC4412 was written, there were already mechanisms for providing 
feedback on bandwidth overload, as defined in RFC3261, and provided as an 
example in RFC4412. The reference to 488 with 370 is intended to be an 
illustration of how to deal with "insufficient bandwidth", whether of not 
RPH is involved.

It is my understanding that such mechanisms are already in use by some 
major carriers to address bandwidth overload.  I believe the deployed 
systems actually use both 488 ("Not Acceptable Here") and 486 ("Busy 
Here") with different warning codes (typically not 370), due to specific 
interactions when translated back into ISUP.

But the fact remains that there are ALREADY mechanisms, not just 
theoretical but deployed, for providing feedback on "insufficient 
bandwidth".

Third, in the  discussion of the ID that led to RFC 5390 it was very clear 
that the focus was on server resources ("CPU processing, memory, I/O, or 
disk resources"), and not on network bandwidth.

Finally, "server overload"  is quite a different problem from "bandwidth 
overload", and inherently requires different solutions

1- There are common traffic distributions that lead to bandwidth overload 
without causing significant load on the SIP servers (e.g., requests for 
moderate numbers of sessions- each of which uses large amounts of 
bandwidth, and has a long holding time) and there are traffic 
distributions  that lead to server overload  without causing significant 
load on the bandwidth (e.g., registration, authorization, various forms of 
messaging, requests for large numbers of sessions- each of which uses 
small amounts  of bandwidth, and has a short holding time)

2- The mechanisms for dealing with server overload are often quite 
different from the mechanisms for dealing with bandwidth overload.

Hope this clarifies the relation to RFC4412.

Janet

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 15 Jun 2010 00:10:29 +0530

Janet,
 
But the fact remains that there are ALREADY mechanisms, not just theoretical but deployed, for providing feedback on "insufficient bandwidth". 
 
<Partha> We are seeing number of issues in the Large enterprise and Call centre solution with number of PSTN-SIP GW's deployment scenarios. As the current negative response mechanism is not fully meeting requirements, we are looking for other solutions. </Partha>

Third, in the  discussion of the ID that led to RFC 5390 it was very clear that the focus was on server resources ("CPU processing, memory, I/O, or disk resources"), and not on network bandwidth. 
<Partha> Agreed...Network bandwidth is outside the scope </Partha>

Finally, "server overload"  is quite a different problem from "bandwidth overload", and inherently requires different solutions 

1- There are common traffic distributions that lead to bandwidth overload without causing significant load on the SIP servers (e.g., requests for moderate numbers of sessions- each of which uses large amounts of bandwidth, and has a long holding time)
<Partha> I'm seeing the Architecture assumption here. Say architecture wherein SIP and RTP packets are handled in the single processor, SIP processing will be accepted by the number of incoming RTP packets as well and bandwidth  may not be issue due to the high-end network interface of the system. </Partha>
 
 and there are traffic distributions  that lead to server overload  without causing significant load on the bandwidth (e.g., registration, authorization, various forms of messaging, requests for large numbers of sessions- each of which uses small amounts  of bandwidth, and has a short holding time) 

2- The mechanisms for dealing with server overload are often quite different from the mechanisms for dealing with bandwidth overload. 

Janet

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 14 Jun 2010 15:41:33 -0400

"Parthasarathi R (partr)" <[email-masked]> wrote on 06/14/2010 02:40:29 
PM:

> [image removed] 
> 
> RE: [sip-overload] consensus call: overload-design draft as wg item
> 
> Parthasarathi R (partr) 
> 
> to:
> 
> Janet P Gunn, Sheshadri Shalya (svshesha)
> 
> 06/14/2010 02:40 PM
> 
> Cc:
> 
> sip-overload-bounces, volker.hilt, sip-overload, hgs, "James Polk 
(jmpolk)"
bandwidth".
> 
> <Partha> We are seeing number of issues in the Large enterprise and 
> Call centre solution with number of PSTN-SIP GW's deployment 
> scenarios. As the current negative response mechanism is not fully 
> meeting requirements, we are looking for other solutions. </Partha>
> 
[JPG] AHA! this would seem to be the heart of your concern.

Is this a similar concern in legacy (circuit switched)  "Large enterprise 
and  Call centres", or is the problem efficiently solved in the circuit 
switched world?

Then the question is whether THIS PROBLEM is sufficiently similar to the 
"SIP Server Overload" problem that it belongs in the SIP-overload WG, or 
whether it is sufficiently different that it belongs somewhere else.

Janet

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 15 Jun 2010 08:40:22 +0530

Janet,

Is this a similar concern in legacy (circuit switched)  "Large enterprise and  Call centres", or is the problem efficiently solved in the circuit switched world? 
<Partha> PSTN-H.323 (legacy to IP) network is working fine but it is an open issue in PSTN-SIP network. Also the issue mentioned by me is not just restricted to PSTN GW, DSP resource is also exhaustively used by SBC and other SIP application servers for transcoding, transrating and other media interworking.  The load balancer knows resource information in advance provides the better SIP routing decision by which setup delay shall be reduced and better utilization of ther resources. </Partha>

Then the question is whether THIS PROBLEM is sufficiently similar to the "SIP Server Overload" problem that it belongs in the SIP-overload WG, or whether it is sufficiently different that it belongs somewhere else. 
<Patha> I suppose that SIP server should not assume that CPU and memory are the critical resource.  I'm not the expert in disk threshold handling but when it is mentioned that disk thrashing leads to system crash  looks like a bug rather than expected behaviour. I expect the system to be stable and not reboot at any cost. Also, Including disk resource in the WG but not DSP,DS0 looks weird for me. IIUC, SIP overload is the best fit to handle this requirment. </Partha>

Janet

---

From: "Sheshadri Shalya (svshesha)" <[email-masked]>
Date: Wed, 16 Jun 2010 15:12:44 +0530

Hi Janet,

Thanks for all the clarifications so far on the objectives of  RFC 4412
and SoC WG charter. There are couple of points for which, I would
solicit further clarifications from the overload design perspective:

1) In section 1 of the design draft, Network bandwidth is included in
the set of resources. Based on the discussion so far, network bandwidth
has to be removed from this draft as it is not addressed in this design.

2) If the overall idea is to address only  503  based  overload
scenarios, where server cannot service any incoming requests, how does
disk and I/O fit into these scenarios?  Since Disk and I/O form the
internal resources of a SIP server, I am not able to understand why
other internal resource like DSP would fall into "Network bandwidth" and
not fit into overload scenarios being addressed here. Also, the
classification of what resources fall into this and what does not, is
not very clear.

3. Based on the discussion so far,  and the type of resources included
like disk and I/O,  does the group  still  feels the scope of the
overload design  has to be limited to 503  only ?  

IMO, on the view of combining DS0/trunk circuit to Network bandwidth, it
is debatable as the term bandwidth is usually associated only  with the
packet switched network. Based on my understanding, on the circuit
switched network, it is more of on/off kind of mechanism where if the
circuit is available for the call, then, it is assured that the full
bandwidth is available and dedicated for the call, where as the same is
not true in the packet switched world. 

Thanks,

Shesh

________________________________

From: Parthasarathi R (partr) 
Sent: Tuesday, June 15, 2010 8:40 AM
To: Janet P Gunn
Cc: [email-masked]; James Polk (jmpolk); [email-masked];
[email-masked]; Sheshadri Shalya (svshesha);
[email-masked]
Subject: RE: [sip-overload] consensus call: overload-design draft as wg
item

Janet,

Is this a similar concern in legacy (circuit switched)  "Large
enterprise and  Call centres", or is the problem efficiently solved in
the circuit switched world? 
<Partha> PSTN-H.323 (legacy to IP) network is working fine but it is an
open issue in PSTN-SIP network. Also the issue mentioned by me is not
just restricted to PSTN GW, DSP resource is also exhaustively used by
SBC and other SIP application servers for transcoding, transrating and
other media interworking.  The load balancer knows resource information
in advance provides the better SIP routing decision by which setup delay
shall be reduced and better utilization of ther resources. </Partha>

<Patha> I suppose that SIP server should not assume that CPU and memory
are the critical resource.  I'm not the expert in disk threshold
handling but when it is mentioned that disk thrashing leads to system
crash  looks like a bug rather than expected behaviour. I expect the
system to be stable and not reboot at any cost. Also, Including disk
resource in the WG but not DSP,DS0 looks weird for me. IIUC, SIP
overload is the best fit to handle this requirment. </Partha>

Janet

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 16 Jun 2010 08:19:48 -0400

Sheesh,

I am confident in my understanding of the intent of 4412.

But when it comes to the SOC charter, it is just my own personal opinion, 
and I would like to hear the WG Chairs' interpretation.

Janet

"Sheshadri Shalya (svshesha)" <[email-masked]> wrote on 06/16/2010 
05:42:44 AM:

> Janet P Gunn, volker.hilt
> 
> 06/16/2010 05:42 AM
> 
> Cc:
> 
> hgs, "Parthasarathi R (partr)", "James Polk (jmpolk)", sip-overload,
> sip-overload-bounces
> 
> Hi Janet,
> 
> Thanks for all the clarifications so far on the objectives of  RFC 
> 4412 and SoC WG charter. There are couple of points for which, I 
> would solicit further clarifications from the overload design 
perspective:
> 
> 1) In section 1 of the design draft, Network bandwidth is included 
> in the set of resources. Based on the discussion so far, network 
> bandwidth has to be removed from this draft as it is not addressed 
> in this design.
> 
> scenarios, where server cannot service any incoming requests, how 
> does disk and I/O fit into these scenarios?  Since Disk and I/O form
> the internal resources of a SIP server, I am not able to understand 
> why other internal resource like DSP would fall into “Network 
> bandwidth” and not fit into overload scenarios being addressed here.
> Also, the classification of what resources fall into this and what 
> does not, is not very clear.
> 
> 3. Based on the discussion so far,  and the type of resources 
> included like disk and I/O,  does the group  still  feels the scope 
> of the overload design  has to be limited to 503  only ? 
> 
> IMO, on the view of combining DS0/trunk circuit to Network 
> bandwidth, it is debatable as the term bandwidth is usually 
> associated only  with the packet switched network. Based on my 
> understanding, on the circuit switched network, it is more of on/off
> kind of mechanism where if the circuit is available for the call, 
> then, it is assured that the full bandwidth is available and 
> dedicated for the call, where as the same is not true in the packet 
> switched world. 
> 
> Thanks,
> Shesh
> 
> 
> 
item
> enterprise and  Call centres", or is the problem efficiently solved 
> in the circuit switched world? 
> <Partha> PSTN-H.323 (legacy to IP) network is working fine but it is
> an open issue in PSTN-SIP network. Also the issue mentioned by me is
> not just restricted to PSTN GW, DSP resource is also exhaustively 
> used by SBC and other SIP application servers for transcoding, 
> transrating and other media interworking.  The load balancer knows 
> resource information in advance provides the better SIP routing 
> decision by which setup delay shall be reduced and better 
> utilization of ther resources. </Partha>
> 
> Then the question is whether THIS PROBLEM is sufficiently similar to
> the "SIP Server Overload" problem that it belongs in the SIP-
> overload WG, or whether it is sufficiently different that it belongs
> somewhere else. 
> <Patha> I suppose that SIP server should not assume that CPU and 
> memory are the critical resource.  I'm not the expert in disk 
> threshold handling but when it is mentioned that disk thrashing 
> leads to system crash  looks like a bug rather than expected 
> behaviour. I expect the system to be stable and not reboot at any 
> cost. Also, Including disk resource in the WG but not DSP,DS0 looks 
> weird for me. IIUC, SIP overload is the best fit to handle this 
> requirment. </Partha>
> 
> Janet

---

From: Volker Hilt <[email-masked]>
Date: Wed, 16 Jun 2010 09:09:37 -0400

Shesh, Janet, Partr,

the charter of SOC is focused on signaling overload of SIP servers, 
i.e., cases where a SIP server is unable to process all SIP messages it 
receives.

"Overload is said to occur when a SIP server does not have sufficient 
resources to complete the processing of all incoming SIP messages within 
the required time."

There are many reasons for overload in a SIP server and the specific 
resource bottlenecks will depend on the type of overload, 
implementation, type of SIP server, etc. etc. The network bandwidth 
example is maybe somewhat misleading. In this context it refers to 
problems transmitting SIP messages.

Thanks,

Volker

On 6/16/2010 5:42 AM, Sheshadri Shalya (svshesha) wrote:
> 2) If the overall idea is to address only 503 based overload scenarios,
> where server cannot service any incoming requests, how does disk and I/O
> fit into these scenarios? Since Disk and I/O form the internal resources
> of a SIP server, I am not able to understand why other internal resource
> like DSP would fall into “Network bandwidth” and not fit into overload
> scenarios being addressed here. Also, the classification of what
> resources fall into this and what does not, is not very clear.
>
> like disk and I/O, does the group still feels the scope of the overload
> design has to be limited to 503 only ?
>
> *From:* Parthasarathi R (partr)
> *Sent:* Tuesday, June 15, 2010 8:40 AM
> *To:* Janet P Gunn
> *Cc:* [email-masked]; James Polk (jmpolk); [email-masked];
> *Subject:* RE: [sip-overload] consensus call: overload-design draft as
> wg item
>
> Janet,
>
> are the critical resource. I'm not the expert in disk threshold handling
> but when it is mentioned that disk thrashing leads to system crash looks
> like a bug rather than expected behaviour. I expect the system to be
> stable and not reboot at any cost. Also, Including disk resource in the
> WG but not DSP,DS0 looks weird for me. IIUC, SIP overload is the best
> fit to handle this requirment. </Partha>
>
> Janet
>

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 16 Jun 2010 09:53:49 -0400

Thanks for the clarification

Janet

Volker Hilt <[email-masked]> wrote on 06/16/2010 09:09:37 
AM:

> Volker Hilt 
> 06/16/2010 09:10 AM
> Janet P Gunn, "[email-masked]" , "Parthasarathi R (partr)", 
> "James Polk (jmpolk)", "[email-masked]" 
> 
> Shesh, Janet, Partr,
> 

> > 2) If the overall idea is to address only 503 based overload 
scenarios,
> > like disk and I/O, does the group still feels the scope of the 
overload
> > Is this a similar concern in legacy (circuit switched) "Large 
enterprise
> > <Partha> PSTN-H.323 (legacy to IP) network is working fine but it is 
an
> > Then the question is whether THIS PROBLEM is sufficiently similar to 
the
> > <Patha> I suppose that SIP server should not assume that CPU and 
memory
> > are the critical resource. I'm not the expert in disk threshold 
handling

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 17 Jun 2010 00:14:10 +0530

Volker,

Thanks for your clarification about the scope of SoC charter. The current focus of this WG is to avoid the overload due to CPU and Memory resource only. In case of other resources like DSP (488) and disk(500), the appropriate error code shall be returned to the sending entity. I agree that by solving CPU and Memory related overload issue, the receiver will never reach the overload or reach the overload for the minimum period depend upon the overload mechanism used and topology. Please correct me in case I misunderstand something.

I think that there is another related overload problem in the sender side (Load balancer) w.r.t other resources handling like DSP, disk storage which is still an open item in SIP. Say, Receiving 488 or 500 response from receiver will not alone help the load balancer to reduce the load or redirect the forthcoming calls to another server till the specific resource overload is return to the normal. This behavior leads to the call setup delay and under-utilization of the resource in the overall SIP network. This is already a concern area in Large Enterprises and Call Centre SIP deployments. In case the entire group feel that it is an another interesting problem to solve in IETF SIP, we will discuss further how to solve this issue in SIP world.

Thanks

Partha 

From: Volker Hilt [mailto:[email-masked]]
Sent: Wed 6/16/2010 6:39 PM
To: Sheshadri Shalya (svshesha)
Cc: Janet P Gunn; [email-masked]; Parthasarathi R (partr); James Polk (jmpolk); [email-masked]
Subject: Re: [sip-overload] consensus call: overload-design draft as wg item

Shesh, Janet, Partr,

Thanks,

Volker

On 6/16/2010 5:42 AM, Sheshadri Shalya (svshesha) wrote:
> like DSP would fall into "Network bandwidth" and not fit into overload

---

From: Volker Hilt <[email-masked]>
Date: Wed, 16 Jun 2010 15:54:11 -0400

Partr,
>
> Thanks for your clarification about the scope of SoC charter. The
> current focus of this WG is to avoid the overload due to CPU and Memory
> resource only. In case of other resources like DSP (488) and disk(500),
> the appropriate error code shall be returned to the sending entity. I
> agree that by solving CPU and Memory related overload issue, the
> receiver will never reach the overload or reach the overload for the
> minimum period depend upon the overload mechanism used and topology.
> Please correct me in case I misunderstand something.
>
The key criteria is not the resource that caused the overload. The key 
point is that a SIP server is unable to completely process all the SIP 
messages it is receiving. As long as a server can fully process all the 
SIP messages it receives, it should not use overload control.

> I think that there is another related overload problem in the sender
> side (Load balancer) w.r.t other resources handling like DSP, disk
> storage which is still an open item in SIP. Say, Receiving 488 or 500
> response from receiver will not alone help the load balancer to reduce
> the load or redirect the forthcoming calls to another server till the
> specific resource overload is return to the normal. This behavior leads
> to the call setup delay and under-utilization of the resource in the
> overall SIP network. This is already a concern area in Large Enterprises
> and Call Centre SIP deployments. In case the entire group feel that it
> is an another interesting problem to solve in IETF SIP, we will discuss
> further how to solve this issue in SIP world.
>
This problem is out of scope for SOC at this point.

Thanks,

Volker

> *From:* Volker Hilt [mailto:[email-masked]]
> *Sent:* Wed 6/16/2010 6:39 PM
> *To:* Sheshadri Shalya (svshesha)
> *Cc:* Janet P Gunn; [email-masked]; Parthasarathi R (partr); James
> Polk (jmpolk); [email-masked]
> *Subject:* Re: [sip-overload] consensus call: overload-design draft as
> wg item
>
> Shesh, Janet, Partr,
>

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 16 Jun 2010 16:24:08 -0400

To clarify my opinion.

I think it is a very valid problem to address- just not part of SOC.

Janet

From:
"Parthasarathi R (partr)" <[email-masked]>
To:
"Volker Hilt" <[email-masked]>, "Sheshadri Shalya 
(svshesha)" <[email-masked]>
Cc:
Janet P Gunn/USA/CSC@CSC, <[email-masked]>, "James Polk (jmpolk)" 
<[email-masked]>, <[email-masked]>
Date:
06/16/2010 02:44 PM
Subject:
RE: [sip-overload] consensus call: overload-design draft as wg item

Volker,
Thanks for your clarification about the scope of SoC charter. The current 
focus of this WG is to avoid the overload due to CPU and Memory resource 
only. In case of other resources like DSP (488) and disk(500), the 
appropriate error code shall be returned to the sending entity. I agree 
that by solving CPU and Memory related overload issue, the receiver will 
never reach the overload or reach the overload for the minimum period 
depend upon the overload mechanism used and topology. Please correct me in 
case I misunderstand something.
I think that there is another related overload problem in the sender side 
(Load balancer) w.r.t other resources handling like DSP, disk storage 
which is still an open item in SIP. Say, Receiving 488 or 500 response 
from receiver will not alone help the load balancer to reduce the load or 
redirect the forthcoming calls to another server till the specific 
resource overload is return to the normal. This behavior leads to the call 
setup delay and under-utilization of the resource in the overall SIP 
network. This is already a concern area in Large Enterprises and Call 
Centre SIP deployments. In case the entire group feel that it is an 
another interesting problem to solve in IETF SIP, we will discuss further 
how to solve this issue in SIP world.
Thanks
Partha 

From: Volker Hilt [mailto:[email-masked]]
Sent: Wed 6/16/2010 6:39 PM
To: Sheshadri Shalya (svshesha)
Cc: Janet P Gunn; [email-masked]; Parthasarathi R (partr); James Polk 
(jmpolk); [email-masked]
Subject: Re: [sip-overload] consensus call: overload-design draft as wg 
item

Shesh, Janet, Partr,

Thanks,

Volker

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Jun 2010 18:33:39 -0400

> SIP messages it receives, it should not use overload control.

Whats not clear to me is what "completely process all the SIP messages" 
means. Have I satisfied that if I can manage to return a 488 to each 
one, but I can't process them all with a 200 response?

A simplistic case here is a stateless, or transaction-stateful proxy. It 
is just concerned with completing SIP transactions. If it can't 
successfully forward all the traffic arriving, because it is out of CPU 
cycles or memory to keep track of transactions, then it can simply tell 
the upstream node to reduce the traffic by X% and all will be good. It 
doesn't matter which traffic is eliminated - as long as less requests 
are coming in all is good.

Next, consider a slightly more complex case - a call-stateful proxy. 
Every time a call is established, some state is retained in memory until 
the call ends. This is just like the previous case as long as the 
requests coming in aren't calls that establish state. But with INVITEs 
it is limited by the number of sessions it has in progress. If it runs 
out of memory for call state the strategy of just reducing incoming 
requests by X% no longer works. It never wants BYE requests to be 
dropped, and it doesn't care about other in-dialog requests. What needs 
to be throttled is initial-INVITE requests.

Is the working assumption here that the proxy should then select the 
requests it doesn't want to handle (some of the initial INVITEs) and 
explicitly reject them? With what response? (Presumably not 503.) Is it 
clear what the upstream box is to do in that case? Should it just try an 
alternative destination for this request, without altering its selection 
algorithm for future requests?

	Thanks,
	Paul

---

From: Volker Hilt <[email-masked]>
Date: Wed, 16 Jun 2010 21:23:31 -0400

> one, but I can't process them all with a 200 response?
Yes.

> to be throttled is initial-INVITE requests.
Throttling initial INVITE requests is generally a reasonable strategy. I 
believe this is mentioned in one of the drafts.

> algorithm for future requests?
No. A proxy that runs out of capacity to process all incoming requests 
should use overload control.

What you are describing is local overload control. Local overload 
control can be used if overload feedback is not available (e.g., no 
neighbor supports it). Local overload control can't prevent overload in 
a SIP server - it can push out the point at which overload will happen.

Thanks,

Volker

---

From: Victor Pascual Avila <[email-masked]>
Date: Thu, 17 Jun 2010 13:15:01 +0200

On Thu, Jun 17, 2010 at 3:23 AM, Volker Hilt
<[email-masked]> wrote:
> What you are describing is local overload control. Local overload control
> can be used if overload feedback is not available (e.g., no neighbor
> supports it).

Both mechanisms are needed and are complementary. When load increases
beyond engineered limits, it is more efficient to throttle requests at
the source; however, one still needs to ensure element protection
(misbehaving nodes, DoS, etc.)

Cheers,
-- 
Victor Pascual Ávila

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jun 2010 10:59:32 -0400

inline

> believe this is mentioned in one of the drafts.

Selectively throttling initial INVITEs rather than other messages is an 
effective strategy in *this* case. But it wouldn't be an especially 
effective one in other cases, such as the former one. It would be an 
especially bad strategy if none of the candidate messages are initial 
INVITEs.

My point is that an effective throttling strategy depends upon what the 
problem is that leads to overload. Unless the upstream node is aware of 
the specific problem, and has a suitable algorithm for dealing with that 
problem, its throttling is likely not to be effective.

> a SIP server - it can push out the point at which overload will happen.

But in the case I described the proxy *didn't* run out of capacity to 
process *all* incoming requests - only initial INVITEs. So do you 
believe that a node that is being overloaded for certain types of 
traffic such as this, but not for all traffic, is indeed a candidate for 
overload control, in scope of the current effort?

Lets consider yet another case:

Instead of a proxy, we have a B2BUA. It is dialog stateful. In addition 
it may do media termination/processing for certain calls, but not all 
calls. To be specific, lets say that it is restricting media to certain 
codecs on one side, and does transcoding when other codecs are offered 
on the other side. For the transcoding it needs a DSP resource.

The effect of this is to partition calls into two categories: those that 
require DSP resources and those that do not, with the criterion for 
putting a call into one category or the other being the codecs offered.

As a result, DSPs become a consumable resource for the calls that need 
them. From an overload perspective, this is much like my prior case - 
in-dialog and lots of incidental messages can be handled without 
trouble. But like the prior case it can get into a state where it cannot 
handle more initial INVITEs because of lack of resources for dialog 
state. You said overload control was suitable for that case. It can also 
get into a state where initial INVITEs that don't require allocation of 
DSP resource are also ok, but initial INVITEs that require DSP resources 
cannot be serviced.

Potentially overload control could be used in this last situation as 
well. But if it simply rejects a percentage of all initial INVITEs 
regardless of whether they will need a DSP then it will be doing an 
ineffective job of throttling load.

ISTM that this case only differs from the former ones by the throttling 
algorithm:

	CASE                 ALGORITHM

	Transaction          Reduce rate of messages.
	Stateful Proxy       (no distinction among messages.)
	out of msg processing
	capacity

	Call Stateful        Reduce rate of messages
	Proxy out of         that establish new dialogs
	mem for xaction      (such as initial INVITEs)
	state

	B2BUA out of         Same as prior
	mem for xaction
	state

	B2BUA out of         Reduce rate of messages
	DSPs for             that will require transcoding
	transcoding

So ISTM the overload control signaling ought to somehow indicate the 
algorithm to be used to throttle the load. If it doesn't do that, or if 
it could but there is no suitable algorithm for the problem at hand, 
then I guess the overloaded server will be forced to use Local Overload 
Control.

IIUC, Partha's draft is implying that there is a parameterized 
throttling algorithm, with the parameters being the resource usage 
statistics delivered in its notifications. (But it lacks any 
specification for an algorithm uses those stats to make effective 
throttling decisions.)

	Thanks,
	Paul

---

From: Volker Hilt <[email-masked]>
Date: Thu, 17 Jun 2010 18:25:53 -0400

Paul,

> especially bad strategy if none of the candidate messages are initial
Are your suggesting there are cases in which you would prefer dropping 
mid call requests over new INVITES? This would lead to a poor user 
experience.

> problem, its throttling is likely not to be effective.
See above. I think there are good strategies to follow for throttling 
traffic (e.g., dropping new INVITEs before mid-call messages, using RPH, 
etc.). I'm not sure why the strategy would depend on whether the SIP 
server came under overload because it reached CPU or memory capacity. 
The main point is to reduce the number of SIP messages to a point that 
can be handled by the server.

> overload control, in scope of the current effort?
A proxy that can't process all the SIP messages it receives is out of 
capacity. Some of these messages may be initial INVITEs. The point is 
that it can't fully process the SIP messages it receives. Throttling 
initial INVITEs is a way of reducing the load on the proxy.

> state.

In this case, the server can respond to all SIP messages it receives and 
has no problem processing them. It may have to reject some of the calls 
because it has trouble processing media but that is out of scope for 
overload control. There are may reasons why a SIP server has to reject 
calls and they have to be dealt with through the appropriate response. 
Overload control helps if the server cannot process the SIP messages it 
receives.

> You said overload control was suitable for that case. It can also
The proxy can reject the INVITEs that require DSPs.

> specification for an algorithm uses those stats to make effective
The problem overload control is solving is to help servers that do not 
have sufficient resources to complete the processing of all incoming SIP 
messages within the required time.

I don't think a B2BUA that is out of DSPs for transcoding falls into 
this category.

Thanks,

Volker

---

From: <[email-masked]>
Date: Fri, 18 Jun 2010 18:03:29 +0100

Paul

Comments below on two of your points below.

Concerning your "simple" case of a proxy. If a stateless, or
transaction-stateful, proxy starts to throttle messages at random as you
propose, it will reduce its own load in the short term. However the
users of the whole system are trying to set up sessions end-to-end
through the proxy. If a message is discarded at random then usually an
attempt to set up a session will fail, and often the user will
re-attempt quite quickly. If non-INVITE messages are throttled by the
proxy, then the proxy has already expended more than the minimum amount
of work on a session which will not complete, *and* the user re-attempt
means that the proxy will still (eventually) have all the work of
setting up the session. So I believe that it's likely to be best for
overload control to throttle only INVITEs, but to continue to handle
other messages so that sessions for which INVITEs have been accepted are
processed to completion - even at a stateless proxy. This minimises
wasted work and hence the severity of the overload at the proxy, leaving
the maximum resource available for productive call processing on
sessions which succeed. I'm not sure how likely it is to get a scenario
where almost none of the messages are INVITEs - perhaps in a
registration storm? REGISTER could also be throttled. It's certainly a
long-standing principle of overload control for "legacy" call processing
systems based on SS7 signalling that only initial messages should be
rejected (for example IAM messages in ISUP, InitialDP messages in
INAP...) unless the system is in very severe overload. In the area of
call-processing overload I think the parallels between SIP systems and
old-style systems are very close.

Concerning your B2BUA which does transcoding and runs out of DSP
resource. There's the usual obvious distinction between those resources
which are used only for session setup and teardown (the call-processing,
signalling-related resources - usually CPU) and those resources which
are needed for the duration of the session, typically the ones used for
media. In your example these resources are separated. A processing slot
in the DSP sub-system is needed for the duration of the session -
exactly analogous to a timeslot in a T1 from a trunk media gateway. So a
lack of DSP resource doesn't mean that the call-processing CPU is
overloaded, and it should be able to return a "no channels/timeslots
available" type of response (488), just for the calls needing the DSP.
Use of 488 in this way will selectively prevent setup of those sessions
its DSP can't handle, without affecting those sessions which the B2BUA
can still handle. This is as recommended in Intro para 3 of
draft-hilt-soc-overload-design-00. The signalling CPU is not overloaded,
so it's not right to throttle any signalling messages in this case -
there's no reason why the signalling shouldn't do its job of conveying
the information needed by the endpoints. So it seems very clear that
overload control (of the kind soc is addressing,  which is specifically
to protect the resources needed to process signalling messages) should
not be used in this "DSP resource exhausted" scenario.

Geoff

Geoff Hunt
BT Design

Tel: 01473 651704
We monitor our email system, and may record your emails. 
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000 

>From: Paul Kyzivat [mailto:[email-masked]]
>Sent: 17 June 2010 16:00
>To: Volker Hilt
>Cc: [email-masked]; [email-masked]
>>>>> the appropriate error code shall be returned to the sending
entity.
>I
>>> A simplistic case here is a stateless, or transaction-stateful
proxy.
>It
>> Throttling initial INVITE requests is generally a reasonable
strategy.
>I
>>> clear what the upstream box is to do in that case? Should it just
try

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jun 2010 16:19:26 -0400

> old-style systems are very close.

You seem to be assuming that all in-dialog messages are used for the 
purpose of dialog establishment, which isn't so.

For instance, there can be reINVITEs and UPDATEs after the dialog has 
been established. There can be INFO messages, which are in-dialog.
And there is NOTIFY in subscribe dialogs.

If a server is overloaded, those can potentially all be rejected. They 
won't be redirected to some other server - the failure will go all the 
way back to the source. That might give some pain but it does relieve 
some of the problem.

Also there MESSAGE messages, which are supposed to be out of dialog. 
They present a different load profile on servers. They are potentially 
good candidates to throttle.

And of course there are SUBSCRIBE and REFER messages that are dialog 
establishing. They can result in capturing of long lived resources in 
some servers, but not in others.

ISTM that at the very least there should be clear guidance for the oc 
throttling algorithm about all message types - whether they are 
candidates for rejection or not. And, does the oc value specify the 
percentage reduction over just those messages that are candidates for 
throttling? Or to all messages?

(If I've been asked to reduce messages by 10% but only 1% of the 
messages I'm processing are eligible for throttling then I have a 
problem. So I think the percentage should be relative to messages 
eligible for throttling. And that then makes it important for all to 
agree on which ones are eligible.)

> not be used in this "DSP resource exhausted" scenario.

This would mean that all incoming calls that require these resources 
would be received, rejected, then the upstream node would potentially 
choose another destination and try again. I guess that's what you have 
in mind.

	Thanks,
	Paul

---

From: Volker Hilt <[email-masked]>
Date: Fri, 18 Jun 2010 18:26:52 -0400

Paul,

> throttling? Or to all messages?
I agree, the draft needs to provide guidance about throttling different 
message types and to which messages the feedback applies.

Volker

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Jun 2010 10:21:47 -0400

Volker Hilt wrote:
>>>> proxy. It

I'm not suggesting I *prefer* it. But it may be a useful thing to do in 
some cases, and even an essential one. For instance, there might not be 
enough initial invites to accomplish the required reduction. Maybe there 
is a need for a 10% reduction, but only 1% are initial INVITEs while 95% 
are MESSAGE messages.

> can be handled by the server.

I'm rethinking my position here.

I guess in effect you are saying that overload control by upstream 
neighbors provides a single generic algorithm. Then, whenever a server 
has a more specialized overload problem that applies only to a subset of 
requests different from what that oc algorithm can deal with, it should 
use local overload control for the specialized overload, and use the 
generic oc mechanism to get the load down to where it can perform its 
local oc.

I guess that can work, though it may be suboptimal. It has the merit of 
having what is hopefully a simple algorithm. But I still have two areas 
I don't understand:

- while the percentage reduction algorithm is simple when applied to
   all requests, its not so simple when you want to bias it towards
   certain types of messages. Unless you have reliable statistics about
   the distribution of message types, I don't see how to make this work.
   Does someone already have an algorithm to suggest here that will work
   for all kinds of message distributions?

- when local overload control is used for the more specialized sorts
   of overload, there had better be a high likelihood that the rejected
   requests are handled in the appropriate way. I haven't done a study
   of that. Presumably the subsequent behavior will be affected by the
   way the request is rejected. It may be necessary to add stronger
   guidance on what codes to use and what the recipients should do when
   receiving such codes.

	Thanks,
	Paul

>>>> try an