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

From: Salvatore Loreto <[email-masked]>
Date: Wed, 09 Jun 2010 21:30:44 +0300

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

-- 
Salvatore Loreto
www.sloreto.com

---

From: Mary Barnes <[email-masked]>
Date: Wed, 9 Jun 2010 13:51:15 -0500

I agree the document should be a WG document for the deliverable.

Mary.

On Wed, Jun 9, 2010 at 1:30 PM, Salvatore Loreto
<[email-masked]> wrote:
> Hi,
>
> the "Design Considerations for Session Initiation Protocol (SIP) Overload
> Control" draft ( draft-hilt-soc-overload-design-00 )
> So as chairs we want to check the consensus for adopt it as baseline for the
> "Design Considerations" wg item
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 10 Jun 2010 11:12:35 +0200

I support the adoption of this baseline.

The document was extensively worked in SIPPING, and it would be a considerable break in the work to fail to use the working group level discussion and consensus that has already occurred.

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Salvatore Loreto
> Sent: Wednesday, June 09, 2010 7:31 PM
> 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.
> 
> 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.
>

---

From: Victor Pascual Avila <[email-masked]>
Date: Thu, 10 Jun 2010 12:11:54 +0200

Hi,

> we have in the SoC charter.

I support adopting this document as a WG item.

Quick comment: As per Section 12, message prioritization is a matter
of local policy. However, I'm wondering whether Resource-Priority
should be mentioned in that section.

Cheers,
-- 
Victor Pascual Ávila

---

From: Volker Hilt <[email-masked]>
Date: Thu, 10 Jun 2010 08:53:46 -0400

Victor,

I'll add the reference to RPH in the next revision.

Thanks,

Volker

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 10 Jun 2010 11:14:03 -0400

I agree with both comments

Janet

[email-masked] wrote on 06/10/2010 06:11:54 AM:

> [image removed] 
> 
> Re: [sip-overload] consensus call: overload-design draft as wg item
> 
> Victor Pascual Avila 
> 
> to:
> 
> Salvatore Loreto
> 
> 06/10/2010 06:12 AM
> 
> Sent by:
> 
> [email-masked]
> 
> Cc:
> 
> "[email-masked]"
> 
> Hi,
>

---

From: "Sheshadri Shalya (svshesha)" <[email-masked]>
Date: Thu, 10 Jun 2010 21:37:21 +0530

Volker and team,
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).

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

3. What will happen if SIP server has enough CPU, but runs out of other
resources such as disk or input/output? 

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?

Thanks,
Shesh

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

ciao
Salvatore and Volker

-- 
Salvatore Loreto
www.sloreto.com

---

From: Volker Hilt <[email-masked]>
Date: Fri, 11 Jun 2010 20:40:03 -0400

Shesh,

> SBCs handling media etc).
RFC 4412 already defines an error code for no trunk circuits, which I 
believe is the correct thing to use. 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.

> understand why overload control mechanism do not apply to these
In these cases, the server can return the error code defined for this 
case (also see my comment above).

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

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

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

Thanks,

Volker

---

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

In line.

[email-masked] wrote on 06/10/2010 12:07:21 PM:

> Sheshadri Shalya (svshesha) 
> 
> to:
> 
> Salvatore Loreto, sip-overload, volker.hilt
> 
> 06/10/2010 12:08 PM
> 
> Sent by:
> 

It is my understanding that there are already mechanisms in SIP for 
signalling overload of transmission resources, and that this is out of 
scope for the SIP-Overload WG.  Bandwidth overload could (and would 
probably)be a result of many different protocols/applications, not just 
SIP.
> scenarios.

There certainly need to be "overload mechanisms" for situations where the 
bandwidth is overloaded but the Server is not overloaded.  But my 
understanding is that this is not within the intended scope for 
SIP-overload. And in many cases, the mechanisms already exist.  The 
"feedback loop" for bandwidth overload is typically somewhat simpler than 
the one for server overload.

> resource in the network. For e.g., for PSTN GW kind of scenario, trunk

That is certainly true.  But when the server is not overloaded itself, it 
can quite easily handle the requests which can not be honored due to lack 
of bandwidth or "trunks". The problems that the SIP-overload WG is 
intended (AIUI) to address are the ones where the overload (cpu, disk, 
I/O) of the server itself prevent the server from effectively handling the 
 additional requests, and, in order to "stay alive", it needs assistance 
from other servers in managing the load.
> resources such as disk or input/output? 

Disk and I/O are explicitly included in both RFC5930 and in the SOC 
Charter.

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 14 Jun 2010 23:33:15 +0530

Janet,
 
I agree to your point that "network bandwidth" handling is outside the scope of SIP-overload WG. AFAIK, SIP+RSVP (RFC 3312 and its updates) mechanism will ensure "network bandwidth" in SIP network. The disagreement is in including DS0 and DSP resources as the network bandwidth issue. For example, System with Gigabit Ethernet interface, T3 interface with 16 DSP channels, the bottleneck resource will DSP channels and it is purely related to that system resource availability only and not related to network bandwidth.
 
The response code for trunk circuit availability may be different (488) but the response does not indicate when the request shall be forward to the same PSTN gateway again or reduce the load. 488 response code will have the limitation mentioned for 503 as well.  Please read inline for more comments.
 
Thanks
Partha

> SBCs handling media etc). 

It is my understanding that there are already mechanisms in SIP for signalling overload of transmission resources,
<partha> Please let me know the mechanism for transmission of resources. </Partha>
 
 and that this is out of scope for the SIP-Overload WG.   Bandwidth overload could (and would probably)be a result of many different protocols/applications, not just SIP.
<Partha> Agreed </Partha>
> understand why overload control mechanism do not apply to these

There certainly need to be "overload mechanisms" for situations where the bandwidth is overloaded but the Server is not overloaded.  But my understanding is that this is not within the intended scope for SIP-overload. And in many cases, the mechanisms already exist.  The "feedback loop" for bandwidth overload is typically somewhat simpler than the one for server overload.
<Partha> How is it simpler to server overload. Please explain the mechanism </Partha> 

> utilization has reached its threshold. 

That is certainly true.  But when the server is not overloaded itself, it can quite easily handle the requests which can not be honored due to lack of bandwidth or "trunks". 
<Partha> Even when system is overloaded due to CPU or memory, the system is responding with negative response only. Where is the difference </Partha>
 
The problems that the SIP-overload WG is intended (AIUI) to address are the ones where the overload (cpu, disk, I/O) of the server itself prevent the server from effectively handling the  additional requests,
 
<Partha> I'm not getting the difference between disk and DSP/DS0 in this scenario </partha>
 and, in order to "stay alive", it needs assistance from other servers in managing the load.
<Partha> For DS0/DSP resource overload as well, the routing towards another PSTN GW is the better solution. </Partha>
> resources such as disk or input/output? 

Disk and I/O are explicitly included in both RFC5930 and in the SOC Charter.
> [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Salvatore Loreto
> https://www.ietf.org/mailman/listinfo/sip-overload <https://www.ietf.org/mailman/listinfo/sip-overload> 
> https://www.ietf.org/mailman/listinfo/sip-overload <https://www.ietf.org/mailman/listinfo/sip-overload>

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 14 Jun 2010 14:44:04 -0400

"Parthasarathi R (partr)" <[email-masked]> wrote on 06/14/2010 02:03:15 
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:03 PM
> 
> Cc:
> 
> sip-overload-bounces, sip-overload, volker.hilt
> 
> Janet,
> 
> I agree to your point that "network bandwidth" handling is outside 
> the scope of SIP-overload WG. AFAIK, SIP+RSVP (RFC 3312 and its 
> updates) mechanism will ensure "network bandwidth" in SIP network. 
> The disagreement is in including DS0 and DSP resources as the 
> network bandwidth issue. For example, System with Gigabit Ethernet 
> interface, T3 interface with 16 DSP channels, the bottleneck 
> resource will DSP channels and it is purely related to that system 
> resource availability only and not related to network bandwidth.
> 
> The response code for trunk circuit availability may be different 
> (488) but the response does not indicate when the request shall be 
> forward to the same PSTN gateway again or reduce the load. 488 
> response code will have the limitation mentioned for 503 as well. 
> Please read inline for more comments.
> 
> Thanks
> Partha

[JPG] By "network bandwidth" I mean BOTH packet-switched and 
circuit-switched bandwidth, and associated resources such as DSPa. 

The 488 and 486 mechanisms are currently being used for signalling 
overload of circuit switched resources.  The specific warning codes 
(usually in the Q850 family), combined with the logic in the gateways and 
SIP servers (and other indicators such as RPH), indicate whether to try 
again to the same server, try again to a different server, or "progress to 
final treatment".  I believe most of this is documented in ATIS (PTSC) 
documents, though I am not sure of the specific document names/numbers.

"503" is limited because the only additional information is the "retry 
after" value.  488 (and 486) are much less limited because there is a very 
large set of potential warning codes which can, to a certain extent, be 
used in "custom" ways.

I should also mention that most of the US "carriers" are not using RSVP, 
so overload of IP bandwidth is not solved that way.  However 
"preconditions" is not restricted to RSVP, and could potentially be used 
for circuit switched resources, though this is not commonly done.

> signalling overload of transmission resources,
[JPG] See above.
> 
>  and that this is out of scope for the SIP-Overload WG.   Bandwidth 
> overload could (and would probably)be a result of many different 
> protocols/applications, not just SIP.
> There certainly need to be "overload mechanisms" for situations 
> where the bandwidth is overloaded but the Server is not overloaded. 
> But my understanding is that this is not within the intended scope 
> for SIP-overload. And in many cases, the mechanisms already exist. 
> The "feedback loop" for bandwidth overload is typically somewhat 
> simpler than the one for server overload.

[JPG] Bandwidth overload is simpler because the "decision making process" 
itself is not impaired, and you can expect that the message sequence will 
be valid.

When the server is overloaded, however, it lack "cycles" for deciding what 
to do about the overload.  Furthermore, messages may randomly be dropped, 
leading to retransmissions, in an inherently unstable process.
> That is certainly true.  But when the server is not overloaded 
> itself, it can quite easily handle the requests which can not be 
> honored due to lack of bandwidth or "trunks". 
> <Partha> Even when system is overloaded due to CPU or memory, the 
> system is responding with negative response only. Where is the 
> difference </Partha>

[JPG] Sorry, don't understand your comment.
> 
> The problems that the SIP-overload WG is intended (AIUI) to address 
> are the ones where the overload (cpu, disk, I/O) of the server 
> itself prevent the server from effectively handling the  additional 
requests,
> <Partha> I'm not getting the difference between disk and DSP/DS0 in 

[JPG] When disk is overloaded, the system starts "thrashing", leading to 
"crashing".  Running out of DS0/DSP isn't going to lead to system 
"thrashing" and "crashing".

> <Partha> For DS0/DSP resource overload as well, the routing towards 
> another PSTN GW is the better solution. </Partha>

[JPG] Absolutely, but the unimpaired server can handle that.
Charter.

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 22 Jun 2010 19:09:09 +0300

Hi,

we have reached a clear consensus to adopt the 
draft-hilt-soc-overload-design-00 as a baseline
for the "Design Consideration" wg item we have in the SoC charter.

So I would ask the authors to submit it as wg item before the deadline.

ciao
Salvatore

-- 
Salvatore Loreto
www.sloreto.com