SOC Working Group V. Gurbani, Ed.
Internet-Draft Bell Laboratories, Alcatel-Lucent
Intended status: Standards Track V. Hilt
Expires: July 24, 2011 Bell Labs/Alcatel-Lucent
H. Schulzrinne
Columbia University
January 20, 2011
Session Initiation Protocol (SIP) Overload Control
draft-ietf-soc-overload-control-01
Abstract
Overload occurs in Session Initiation Protocol (SIP) networks when
SIP servers have insufficient resources to handle all SIP messages
they receive. Even though the SIP protocol provides a limited
overload control mechanism through its 503 (Service Unavailable)
response code, SIP servers are still vulnerable to overload. This
document defines an overload control mechanism for SIP.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 24, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Gurbani, et al. Expires July 24, 2011 [Page 1]
Internet-Draft Overload Control January 2011
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of operations . . . . . . . . . . . . . . . . . . . . 4
4. Via Header Parameters for Overload Control . . . . . . . . . . 5
4.1. The oc paramater . . . . . . . . . . . . . . . . . . . . . 5
4.2. The oc-algo parameter . . . . . . . . . . . . . . . . . . 6
4.3. The oc-validity parameter . . . . . . . . . . . . . . . . 7
4.4. The oc-seq parameter . . . . . . . . . . . . . . . . . . . 7
5. Creating and updating the overload control parameters . . . . 8
6. Determining the 'oc' Parameter Value . . . . . . . . . . . . . 9
7. Processing the Overload Control Parameters . . . . . . . . . . 10
8. Using the Overload Control Parameter Values . . . . . . . . . 10
9. Forwarding the overload control parameters . . . . . . . . . . 11
10. Self-Limiting . . . . . . . . . . . . . . . . . . . . . . . . 11
11. Responding to an Overload Indication . . . . . . . . . . . . . 12
11.1. Message prioritization at the hop before the
overloaded server . . . . . . . . . . . . . . . . . . . . 12
11.2. Rejecting requests at an overloaded server . . . . . . . . 13
12. 100-Trying provisional response and overload control
parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 13
13. Relationship with other IETF SIP load control efforts . . . . 14
14. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
15. Design Considerations . . . . . . . . . . . . . . . . . . . . 14
15.1. SIP Mechanism . . . . . . . . . . . . . . . . . . . . . . 15
15.1.1. SIP Response Header . . . . . . . . . . . . . . . . . 15
15.1.2. SIP Event Package . . . . . . . . . . . . . . . . . . 15
15.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 16
16. Security Considerations . . . . . . . . . . . . . . . . . . . 17
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
18.1. Normative References . . . . . . . . . . . . . . . . . . . 18
18.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19
Appendix B. RFC5390 requirements . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Gurbani, et al. Expires July 24, 2011 [Page 2]
Internet-Draft Overload Control January 2011
1. Introduction
As with any network element, a Session Initiation Protocol (SIP)
[RFC3261] server can suffer from overload when the number of SIP
messages it receives exceeds the number of messages it can process.
Overload can pose a serious problem for a network of SIP servers.
During periods of overload, the throughput of a network of SIP
servers can be significantly degraded. In fact, overload may lead to
a situation in which the throughput drops down to a small fraction of
the original processing capacity. This is often called congestion
collapse.
Overload is said to occur if a SIP server does not have sufficient
resources to process all incoming SIP messages. These resources may
include CPU processing capacity, memory, network bandwidth, input/
output, or disk resources.
For overload control, we only consider failure cases where SIP
servers are unable to process all SIP requests due to resource
constraints. There are other cases where a SIP server can
successfully process incoming requests but has to reject them due to
failure conditions unrelated to the SIP server being overloaded. For
example, a PSTN gateway that runs out of trunks but still has plenty
of capacity to process SIP messages should reject incoming INVITEs
using a 488 (Not Acceptable Here) response [RFC4412]. Similarly, a
SIP registrar that has lost connectivity to its registration database
but is still capable of processing SIP requests should reject
REGISTER requests with a 500 (Server Error) response [RFC3261].
Overload control does not apply to these cases and SIP provides
appropriate response codes for them.
The SIP protocol provides a limited mechanism for overload control
through its 503 (Service Unavailable) response code. However, this
mechanism cannot prevent overload of a SIP server and it cannot
prevent congestion collapse. In fact, the use of the 503 (Service
Unavailable) response code may cause traffic to oscillate and to
shift between SIP servers and thereby worsen an overload condition.
A detailed discussion of the SIP overload problem, the problems with
the 503 (Service Unavailable) response code and the requirements for
a SIP overload control mechanism can be found in [RFC5390].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Gurbani, et al. Expires July 24, 2011 [Page 3]
Internet-Draft Overload Control January 2011
The normative statements in this specification as they apply to SIP
clients and SIP servers assume that both the SIP clients and SIP
servers support this specification. If, for instance, only a SIP
client supports this specification and not the SIP server, then
follows that the normative statements in this specification pertinent
to the behavior of a SIP server do not apply to the server that does
not support this specification.
3. Overview of operations
We now explain the overview of how the overload control mechanism
operates by introducing the overload control parameters. Section 4
provides more details and normative behavior on the parameters listed
below.
Because overload control is best performed hop-by-hop, the Via
parameter is attractive since it allows two adjacent SIP entities to
indicate support for, and exchange information associated with
overload control. Additional advantages of this choice are discussed
in Section 15.1.1. An alternative mechanism using SIP event packages
was also considered, and the characteristics of that choice are
further outlined in Section 15.1.2.
This document defines four new parameters for the SIP Via header for
overload control. These parameters provide a SIP mechanism for
conveying overload control information between adjacent SIP
entities.) These parameters are:
1. oc: This parameter serves a dual purpose; when inserted by a SIP
client in a request going downstream, the parameter indicates
that the SIP client supports overload control. When the
downstream SIP server sends a response, the downstream SIP server
will add a value to the parameter that indicates a loss rate (in
percentage) by which the requests arriving at the downstream SIP
server should be reduced.
2. oc-algo: This parameter serves a dual purpose: when inserted by a
SIP client in a request going downstream, the parameter contains
a comma-separated list of the class of overload control algorithm
supported by the SIP client. When the downstream SIP server
sends a response, the downstream SIP server will pick one
overload control algorithm from the list and will pare the list
down to include the one chosen algorithm. In this manner, the
upstream SIP client and the downstream SIP server can negotiate
the specific class of algorithm that is utilized for overload
control.
Gurbani, et al. Expires July 24, 2011 [Page 4]
Internet-Draft Overload Control January 2011
3. oc-validity: Inserted by the SIP server sending a response
upstream. This parameter contains a value that indicates the
time (in millisecond resolution) that the load reduction
specified by the "oc" parameter should be in effect.
4. oc-seq: Inserted by the SIP server sending a response upstream.
This parameter contains a value that indicates the sequence
number associated with the "oc" parameter defined above.
Consider a SIP client, P1, which is sending requests to another
downstream SIP server, P2. The following snippets of SIP messages
demonstrate how the overload control parameters work.
INVITE sips:user@example.com SIP/2.0
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;received=192.0.2.111;oc;
oc-algo="loss,rate"
...
SIP/2.0 100 Trying
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;received=192.0.2.111;
oc=20;oc-algo="loss";oc-validity=500;
oc-seq=1282321615.781
...
In the messages above, the first line is sent by P1 to P2. This line
is a SIP request; because P1 supports overload control, it inserts
the "oc" parameter in the topmost Via header that it created.
The second line --- a SIP response --- shows the topmost Via header
amended by P2 according to this specification and sent to P1.
Because P2 also supports overload control, it sends back further
overload control parameters towards P1 requesting that P1 reduce the
incoming traffic by 20% for 500ms. P2 updates the "oc" parameter to
add a value and inserts the remaining two parameters, "oc-validity"
and "oc-seq".
4. Via Header Parameters for Overload Control
4.1. The oc paramater
This parameter is inserted by the SIP client and updated by the SIP
server.
A SIP client MUST add an "oc" parameter to the topmost Via header it
inserts into the SIP request. This provides an indication to
downstream neighbors that this server supports overload control.
Gurbani, et al. Expires July 24, 2011 [Page 5]
Internet-Draft Overload Control January 2011
When inserted into a request by a SIP client to indicate support for
overload control, there MUST NOT be a value associated with the
parameter.
The downstream server MUST add a value to the "oc" parameter in the
response going upstream; this value indicates a loss rate (in
percentage) by which the requests arriving at the downstream server
should be reduced.
When adding a value to the "oc" parameter, the downstream server MUST
restrain that value to a number between 0 and 100. This value
describes the percentage by which the traffic (SIP requests) destined
to the SIP server should be reduced. The default value for this
parameter is 0.
When a SIP client receives a response with the value in the "oc"
parameter filled in, it SHOULD reduce, in terms of a percentage, the
number of requests going downstream to the SIP server from which it
received the response (see Section 11 for pertinent discussion on
traffic reduction).
4.2. The oc-algo parameter
This parameter is inserted by the SIP client and updated by the SIP
server.
A SIP client MAY add an "oc-algo" parameter to the topmost Via header
it inserts into the SIP request. This parameter contains a comma-
separated list of a class of overload control algorithms. Currently,
three classes of overload control algorithms are known: loss-based,
rate-based, and window-based. This document supports overload
control through a loss-based mechanism, therefore the single
mandatory to implement class of overload control algorithm is loss-
based. All implementations that support overload control MUST
implement a loss-based overload control mechanism.
If a SIP client only supports the loss-based overload control
mechanism, then the "oc-algo" parameter can be omitted. When a SIP
server receives a request without an "oc-algo" parameter, it MUST NOT
add the parameter in the response going upstream as the absence of
the parameter in the request implied that the upstream SIP client
only supported a loss-based overload control mechanism.
If a SIP client supports multiple class of overload control
algorithms, then it will insert a comma-separated list in the "oc-
algo" parameter value. Each element in the comma-separated list
corresponds to the class of overload control algorithms supported by
the SIP client. Currently, three classes of overload control
Gurbani, et al. Expires July 24, 2011 [Page 6]
Internet-Draft Overload Control January 2011
algorithms are known: loss-based, rate-based, and window-based. When
a downstream SIP server receives a request with a choice of overload
control algorithms specified in the "oc-algo" parameter value, it
MUST choose one algorithm from the list and MUST pare the list down
to include the one chosen algorithm. The pared down list consisting
of the chosen algorithm MUST be returned to the upstream SIP client
in the response.
It is RECOMMENDED that once an upstream SIP client and a downstream
SIP server have converged to a mutually agreeable class of overload
control algorithm, the agreed upon class stays in effect for a non-
trivial duration of time. That is, the adjacent peers MUST NOT
renegotiate the overload control algorithm class per transaction, or
per request- response message exchange. A rapid renegotiation of the
overload control algorithm will not benefit the client or the server
as such flapping does not allow the chosen algorithm to measure and
fine tune its behavior over a period of time.
Exigent realities of deployments of SIP clients and servers
necessitate that the overload control algorithm be renegotiated upon
a system reboot or a software upgrade, however, frequent
renegotiations of the overload control algorithm MUST be avoided.
Renegotiation, when desired, is simply accomplished by the SIP client
sending a fresh "oc-algo" parameter in a request going downstream.
The downstream server, as before, MUST choose one algorithm from the
list and MUST pare the list down to include the one chosen algorithm.
The pared down list consisting of the chosen algorithm MUST be
returned to the upstream SIP client in the response and stays in
effect until the next renegotiation.
4.3. The oc-validity parameter
This parameter is inserted by the SIP server.
This parameter contains a value that indicates an interval of time
(measured in milliseconds) that the load reduction specified value of
the "oc" parameter should be in effect. The default value of the
"oc_validity" parameter is 500 (millisecond).
The "oc_validity" parameter can only be present in a Via header in
conjunction with an "oc" parameter.
4.4. The oc-seq parameter
This parameter is inserted by the SIP server.
This parameter contains a value that indicates the sequence number
associated with the "oc" parameter. Some implementations may be
Gurbani, et al. Expires July 24, 2011 [Page 7]
Internet-Draft Overload Control January 2011
capable of updating the overload control information before the
validity period specified by the "oc-validity" parameter expires.
Such implementations MUST have an increasing value in the "oc-seq"
parameter for each response sent to the upstream SIP client. This is
to allow the upstream SIP client to properly collate out-of-order
responses.
5. Creating and updating the overload control parameters
A SIP server can provide overload control feedback to its upstream
neighbors by providing a value for the "oc" parameter to the topmost
Via header field of a SIP response. The topmost Via header is
determined after the SIP server has removed its own Via header; i.e.,
it is the Via header that was generated by the upstream neighbor.
Since the topmost Via header of a response will be removed by an
upstream neighbor after processing it, overload control feedback
contained in the "oc" parameter will not travel beyond the upstream
SIP client. A Via header parameter therefore provides hop-by-hop
semantics for overload control feedback (see
[I-D.ietf-soc-overload-design]) even if the next hop neighbor does
not support this specification.
The "oc: parameter can be used in all response types, including
provisional, success and failure responses (please see Section 12 for
special consideration on transporting overload control parameters in
a 100-Trying response). A SIP server MAY update the "oc" parameter
in all responses it is sending. A SIP server MUST update the "oc"
parameter to responses when the transmission of overload control
feedback is required by the overload control algorithm to limit the
traffic received by the server. I.e., a SIP server MUST update the
"oc" parameter when the overload control algorithm sets the value of
an "oc" parameter to a value different than the default value.
A SIP server that has updated the "oc" parameter to Via header SHOULD
also add a "oc_validity" parameter to the same Via header. The
"oc_validity" parameter defines the time in milliseconds during which
the content (i.e., the overload control feedback) of the "oc"
parameter is valid. The default value of the "oc_validity" parameter
is 500 (millisecond). A SIP server SHOULD use a shorter
"oc_validity" time if its overload status varies quickly and MAY use
a longer "oc_validity" time if this status is more stable. If the
"oc_validity" parameter is not present, its default value is used.
The "oc_validity" parameter MUST NOT be used in a Via header that did
not originally contain an "oc" parameter when received. Furthermore,
when a SIP server receives a request with the topmost Via header
containing only an "oc-validity" parameter without the accompanying
Gurbani, et al. Expires July 24, 2011 [Page 8]
Internet-Draft Overload Control January 2011
"oc" parameter. it MUST ignore the "oc-validity" parameter.
When a SIP server retransmits a response, it SHOULD use the "oc"
parameter value and "oc-validity" parameter value consistent with the
overload state at the time the retransmitted response is sent. This
implies that the values in the "oc" and "oc-validity" parameters may
be different then the ones used in previous retransmissions of the
response. Due to the fact that responses sent over UDP may be
subject to delays in the network and arrive out of order, the "oc-
seq" parameter aids in detecting a stale "oc" parameter value.
Implementations that are capable of updating the "oc" and "oc-
validity" parameter values for retransmissions MUST insert the "oc-
seq" parameter. The value of this parameter MUST be a set of numbers
drawn from an increasing sequence.
Implementations that are not capable of updating the "oc" and "oc-
validity" parameter values for retransmissions --- or implementations
that do not want to do so because they will have to regenerate the
message to be retransmitted --- MUST still insert a "oc-seq"
parameter in the first response associated with a transaction;
however, they do not have to update the value in subsequent
retransmissions.
The "oc_validity" and "oc-seq" Via header parameters are only defined
in SIP responses and MUST NOT be used in SIP requests. These
parameters are only useful to the upstream neighbor of a SIP server
(i.e., the entity that is sending requests to the SIP server) since
this is the entity that can offload traffic by redirecting/rejecting
new requests. If requests are forwarded in both directions between
two SIP servers (i.e., the roles of upstream/downstream neighbors
change), there are also responses flowing in both directions. Thus,
both SIP servers can exchange overload information.
Since overload control protects a SIP server from overload, it is
RECOMMENDED that a SIP server use the mechanisms described in this
specification. However, if a SIP server wanted to limit its overload
control capability for privacy reasons, it MAY decide to perform
overload control only for requests that are received on a secure
transport channel, such as TLS. This enables a SIP server to protect
overload control information and ensure that it is only visible to
trusted parties.
6. Determining the 'oc' Parameter Value
The value of the "oc" parameter is determined by an overload control
algorithm (see [I-D.ietf-soc-overload-design]). This specification
Gurbani, et al. Expires July 24, 2011 [Page 9]
Internet-Draft Overload Control January 2011
does not mandate the use of a specific overload control algorithm.
However, the output of an overload control algorithm MUST be
compliant to the semantics of this Via header parameter.
The "oc" parameter value specifies the percentage by which the load
forwarded to this SIP server should be reduced. Possible values
range from 0 (the traffic forwarded is reduced by 0%, i.e., all
traffic is forwarded) to 100 (the traffic forwarded is reduced by
100%, i.e., no traffic forwarded). The default value of this
parameter is 0.
7. Processing the Overload Control Parameters
A SIP client compliant to this specification SHOULD remove "oc",
"oc_validity" and "oc-seq" parameters from all Via headers of a
response received, except for the topmost Via header. This prevents
overload control parameters that were accidentally or maliciously
inserted into Via headers by a downstream SIP server from traveling
upstream.
A SIP client maintains the "oc" parameter values received along with
the address and port number of the SIP servers from which they were
received for the duration specified in the "oc_validity" parameter or
the default duration. Each time a SIP client receives a response
with an "oc" parameter from a downstream SIP server, it overwrites
the "oc" value it has currently stored for this server with the new
value received. The SIP client restarts the validity period of an
"oc" parameter each time a response with an "oc" parameter is
received from this server. A stored "oc" parameter value MUST be
discarded once it has reached the end of its validity.
8. Using the Overload Control Parameter Values
A SIP client compliant to this specification MUST honor overload
control values it receives from downstream neighbors. The SIP client
MUST NOT forward more requests to a SIP server than allowed by the
current "oc" parameter value from a particular downstream server.
When forwarding a SIP request, a SIP client uses the SIP procedures
of [RFC3263] to determine the next hop SIP server. The procedures of
[RFC3263] take as input a SIP URI, extract the domain portion of that
URI for use as a lookup key, and query the Domain Name Service (DNS)
to obtain an ordered set of one or more IP addresses with a port
number and transport corresponding to each IP address in this set
(the "Expected Output").
Gurbani, et al. Expires July 24, 2011 [Page 10]
Internet-Draft Overload Control January 2011
After selecting a specific SIP server from the Expected Output, the
SIP client MUST determine if it already has overload control
parameter values for the server chosen from the Expected Output. If
the SIP client has a non-expired "oc" parameter value for the server
chosen from the Expected Output, and this chosen server is operating
in overload control mode. Thus, the SIP client MUST determine if it
can or cannot forward the current request to the SIP server depending
on the nature of the request and the prevailing overload conditions.
The particular algorithm used to determine whether or not to forward
a particular SIP request is a matter of local policy, and may take
into account a variety of prioritization factors. However, this
local policy SHOULD generate the same number and rate of SIP requests
as the default algorithm (to be determined), which treats all
requests as equal.
In the absence of a different local policy, the SIP client SHOULD use
the following default algorithm to determine if it can forward the
request downstream (TODO: Need to devise an algorithm. The original
simple algorithm based on random number generation does not suffice
for all cases.)
9. Forwarding the overload control parameters
A SIP client MAY forward the content of an "oc" parameter it has
received from a downstream neighbor on to its upstream neighbor.
However, forwarding the content of the "oc" parameter is generally
NOT RECOMMENDED and should only be performed if permitted by the
configuration of SIP servers. For example, a SIP server that only
relays messages between exactly two SIP servers may forward an "oc"
parameter. The "oc" parameter is forwarded by copying it from the
Via in which it was received into the next Via header (i.e., the Via
header that will be on top after processing the response). If an
"oc_validity" parameter is present, MUST be copied along with the
"oc" parameter.
10. Self-Limiting
In some cases, a SIP client may not receive a response from a
downstream server after sending a request. RFC3261 [RFC3261] defines
that when a timeout error is received from the transaction layer, it
MUST be treated as if a 408 (Request Timeout) status code has been
received. If a fatal transport error is reported by the transport
layer, it MUST be treated as a 503 (Service Unavailable) status code.
In the event of repeated timeouts or fatal transport errors, the SIP
Gurbani, et al. Expires July 24, 2011 [Page 11]
Internet-Draft Overload Control January 2011
client MUST stop sending requests to this server. The SIP client
SHOULD occasionally forward a single request to probe if the
downstream server is alive. Once a SIP client has successfully
transmitted a request to the downstream server, the SIP client can
resume normal traffic rates. It should, of course, honor any "oc"
parameters it may receive subsequent to resuming normal traffic
rates.
OPEN ISSUE: If a downstream neighbor does not respond to a request
at all, the upstream SIP client will stop sending requests to the
downstream neighbor. The upstream SIP client will periodically
forward a single request to probe the health of its downstream
neighbor. It has been suggested --- see http://www.ietf.org/
mail-archive/web/sip-overload/current/msg00229.html --- that we
have a notification mechanism in place for the downstream neighbor
to signal to the upstream SIP client that it is ready to receive
requests. This notification scheme has advantages, but comes with
obvious disadvantages as well. Need some more discussion around
this.
11. Responding to an Overload Indication
A SIP client can receive overload control feedback indicating that it
needs to reduce the traffic it sends to its downstream server. The
client can accomplish this task by sending some of the requests that
would have gone to the overloaded element to a different destination.
It needs to ensure, however, that this destination is not in overload
and capable of processing the extra load. An client can also buffer
requests in the hope that the overload condition will resolve quickly
and the requests still can be forwarded in time. In many cases,
however, it will need to reject these requests.
11.1. Message prioritization at the hop before the overloaded server
During an overload condition, a SIP client needs to prioritize
requests and select those requests that need to be rejected or
redirected. While this selection is largely a matter of local
policy, certain heuristics can be suggested. One, during overload
control, the SIP client should preserve existing dialogs as much as
possible. This suggests that mid-dialog requests MAY be given
preferential treatment. Similarly, requests that result in releasing
resources (such as a BYE) MAY also be given preferential treatment.
A SIP client SHOULD honor the local policy for prioritizing SIP
requests such as policies based on the content of the Resource-
Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value)
RPH contents may indicate high priority requests that should be
Gurbani, et al. Expires July 24, 2011 [Page 12]
Internet-Draft Overload Control January 2011
preserved as much as possible during overload. The RPH contents can
also indicate a low-priority request that is eligible to be dropped
during times of overload. Other indicators, such as the SOS URN
[RFC5031] indicating an emergency request, may also be used for
prioritization.
Local policy could also include giving precedence to mid- dialog SIP
requests (re-INVITEs, UPDATEs, BYEs etc.) in times of overload. A
local policy can be expected to combine both the SIP request type and
the prioritization markings, and SHOULD be honored when overload
conditions prevail.
A SIP client SHOULD honor user-level load control filters installed
by signaling neighbors [I-D.ietf-soc-load-control-event-package] by
sending the SIP messages that matched the filter downstream.
11.2. Rejecting requests at an overloaded server
If the upstream SIP client to the overloaded server does not support
overload control, it will continue to direct requests to the
overloaded server. Thus, the overloaded server must bear the cost of
rejecting some session requests as well as the cost of processing
other requests to completion. It would be fair to devote the same
amount of processing at the overloaded server to the combination of
rejection and processing as the overloaded server would devote to
processing requests from an upstream SIP client that supported
overload control. This is to ensure that SIP servers that do not
support this specification don't receive an unfair advantage over
those that do.
A SIP server that is under overload and has started to throttle
incoming traffic MUST reject this request with a "503 (Service
Unavailable)" response without Retry-After header to reject a
fraction of requests from upstream neighbors that do not support
overload control.
12. 100-Trying provisional response and overload control parameters
The overload control information sent from a SIP server to a client
is transported in the responses. While implementations can insert
overload control information in any response, special attention
should be accorded to overload control information transported in a
100-Trying response.
Traditionally, the 100-Trying response has been used in SIP to quench
retransmissions. In some implementations, the 100-Trying message may
not be generated by the transaction user (TU) nor consumed by the TU.
Gurbani, et al. Expires July 24, 2011 [Page 13]
Internet-Draft Overload Control January 2011
In these implementations, the 100-Trying response is generated at the
transaction layer and sent to the upstream SIP client. At the
receiving SIP client, the 100-Trying is consumed at the transaction
layer by inhibiting the retransmission of the corresponding request.
Consequently, implementations that insert overload control
information in the 100-Trying cannot assume that the upstream SIP
client passed the overload control information in the 100-Trying to
their corresponding TU. For this reason, implementations that insert
overload control information in the 100-Trying MUST re-insert the
same (or updated) overload control information in the first non-100
response being sent to the upstream SIP client.
13. Relationship with other IETF SIP load control efforts
The overload control mechanism described in this document is reactive
in nature and apart from message prioritization directives listed in
Section 11.1 the mechanisms described in this draft will not
discriminate requests based on user identity, filtering action and
arrival time. SIP networks that require pro-active overload control
mechanisms can upload user-level load control filters as described in
[I-D.ietf-soc-load-control-event-package].
14. Syntax
This specification extends the existing definition of the Via header
field parameters of [RFC3261] as follows:
via-params = via-ttl / via-maddr
/ via-received / via-branch
/ oc / oc-validity
/ oc-seq / oc-algo / via-extension
oc = "oc" [EQUAL 0-100]
oc-validity = "oc_validity" [EQUAL delta-ms]
oc-seq = (1*12DIGIT "." 1*5DIGIT)
oc-algo = DQUOTE algo-list *(COMMA algo-list) DQUOTE
algo-list = "loss" / *(other-algo)
other-algo = %x41-5A / %x61-7A / %x30-39
15. Design Considerations
This section discusses specific design considerations for the
mechanism described in this document. General design considerations
for SIP overload control can be found in
[I-D.ietf-soc-overload-design].
Gurbani, et al. Expires July 24, 2011 [Page 14]
Internet-Draft Overload Control January 2011
15.1. SIP Mechanism
A SIP mechanism is needed to convey overload feedback from the
receiving to the sending SIP entity. A number of different
alternatives exist to implement such a mechanism.
15.1.1. SIP Response Header
Overload control information can be transmitted using a new Via
header field parameter for overload control. A SIP server can add
this header parameter to the responses it is sending upstream to
provide overload control feedback to its upstream neighbors. This
approach has the following characteristics:
o A Via header parameter is light-weight and creates very little
overhead. It does not require the transmission of additional
messages for overload control and does not increase traffic or
processing burdens in an overload situation.
o Overload control status can frequently be reported to upstream
neighbors since it is a part of a SIP response. This enables the
use of this mechanism in scenarios where the overload status needs
to be adjusted frequently. It also enables the use of overload
control mechanisms that use regular feedback such as window-based
overload control.
o With a Via header parameter, overload control status is inherent
in SIP signaling and is automatically conveyed to all relevant
upstream neighbors, i.e., neighbors that are currently
contributing traffic. There is no need for a SIP server to
specifically track and manage the set of current upstream or
downstream neighbors with which it should exchange overload
feedback.
o Overload status is not conveyed to inactive senders. This avoids
the transmission of overload feedback to inactive senders, which
do not contribute traffic. If an inactive sender starts to
transmit while the receiver is in overload it will receive
overload feedback in the first response and can adjust the amount
of traffic forwarded accordingly.
o A SIP server can limit the distribution of overload control
information by only inserting it into responses to known upstream
neighbors. A SIP server can use transport level authentication
(e.g., via TLS) with its upstream neighbors.
15.1.2. SIP Event Package
Overload control information can also be conveyed from a receiver to
a sender using a new event package. Such an event package enables a
sending entity to subscribe to the overload status of its downstream
neighbors and receive notifications of overload control status
Gurbani, et al. Expires July 24, 2011 [Page 15]
Internet-Draft Overload Control January 2011
changes in NOTIFY requests. This approach has the following
characteristics:
o Overload control information is conveyed decoupled from SIP
signaling. It enables an overload control manager, which is a
separate entity, to monitor the load on other servers and provide
overload control feedback to all SIP servers that have set up
subscriptions with the controller.
o With an event package, a receiver can send updates to senders that
are currently inactive. Inactive senders will receive a
notification about the overload and can refrain from sending
traffic to this neighbor until the overload condition is resolved.
The receiver can also notify all potential senders once they are
permitted to send traffic again. However, these notifications do
generate additional traffic, which adds to the overall load.
o A SIP entity needs to set up and maintain overload control
subscriptions with all upstream and downstream neighbors. A new
subscription needs to be set up before/while a request is
transmitted to a new downstream neighbor. Servers can be
configured to subscribe at boot time. However, this would require
additional protection to avoid the avalanche restart problem for
overload control. Subscriptions need to be terminated when they
are not needed any more, which can be done, for example, using a
timeout mechanism.
o A receiver needs to send NOTIFY messages to all subscribed
upstream neighbors in a timely manner when the control algorithm
requires a change in the control variable (e.g., when a SIP server
is in an overload condition). This includes active as well as
inactive neighbors. These NOTIFYs add to the amount of traffic
that needs to be processed. To ensure that these requests will
not be dropped due to overload, a priority mechanism needs to be
implemented in all servers these request will pass through.
o As overload feedback is sent to all senders in separate messages,
this mechanism is not suitable when frequent overload control
feedback is needed.
o A SIP server can limit the set of senders that can receive
overload control information by authenticating subscriptions to
this event package.
o This approach requires each proxy to implement user agent
functionality (UAS and UAC) to manage the subscriptions.
15.2. Backwards Compatibility
An new overload control mechanism needs to be backwards compatible so
that it can be gradually introduced into a network and functions
properly if only a fraction of the servers support it.
Hop-by-hop overload control (see [I-D.ietf-soc-overload-design]) has
Gurbani, et al. Expires July 24, 2011 [Page 16]
Internet-Draft Overload Control January 2011
the advantage that it does not require that all SIP entities in a
network support it. It can be used effectively between two adjacent
SIP servers if both servers support overload control and does not
depend on the support from any other server or user agent. The more
SIP servers in a network support hop-by-hop overload control, the
better protected the network is against occurrences of overload.
A SIP server may have multiple upstream neighbors from which only
some may support overload control. If a server would simply use this
overload control mechanism, only those that support it would reduce
traffic. Others would keep sending at the full rate and benefit from
the throttling by the servers that support overload control. In
other words, upstream neighbors that do not support overload control
would be better off than those that do.
A SIP server should therefore use 5xx responses towards upstream
neighbors that do not support overload control. The server should
reject the same amount of requests with 5xx responses that would be
otherwise be rejected/redirected by the upstream neighbor if it would
support overload control. If the load condition on the server does
not permit the creation of 5xx responses, the server should drop all
requests from servers that do not support overload control.
16. Security Considerations
Overload control mechanisms can be used by an attacker to conduct a
denial-of-service attack on a SIP entity if the attacker can pretend
that the SIP entity is overloaded. When such a forged overload
indication is received by an upstream SIP client, it will stop
sending traffic to the victim. Thus, the victim is subject to a
denial-of-service attack.
An attacker can create forged overload feedback by inserting itself
into the communication between the victim and its upstream neighbors.
The attacker would need to add overload feedback indicating a high
load to the responses passed from the victim to its upstream
neighbor. Proxies can prevent this attack by communicating via TLS.
Since overload feedback has no meaning beyond the next hop, there is
no need to secure the communication over multiple hops.
Another way to conduct an attack is to send a message containing a
high overload feedback value through a proxy that does not support
this extension. If this feedback is added to the second Via headers
(or all Via headers), it will reach the next upstream proxy. If the
attacker can make the recipient believe that the overload status was
created by its direct downstream neighbor (and not by the attacker
further downstream) the recipient stops sending traffic to the
Gurbani, et al. Expires July 24, 2011 [Page 17]
Internet-Draft Overload Control January 2011
victim. A precondition for this attack is that the victim proxy does
not support this extension since it would not pass through overload
control feedback otherwise.
A malicious SIP entity could gain an advantage by pretending to
support this specification but never reducing the amount of traffic
it forwards to the downstream neighbor. If its downstream neighbor
receives traffic from multiple sources which correctly implement
overload control, the malicious SIP entity would benefit since all
other sources to its downstream neighbor would reduce load.
The solution to this problem depends on the overload control
method. For rate-based and window-based overload control, it is
very easy for a downstream entity to monitor if the upstream
neighbor throttles traffic forwarded as directed. For percentage
throttling this is not always obvious since the load forwarded
depends on the load received by the upstream neighbor.
17. IANA Considerations
[TBD.]
18. References
18.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006.
18.2. Informative References
[I-D.ietf-soc-load-control-event-package]
Shen, C., Schulzrinne, H., and A. Koike, "A Session
Gurbani, et al. Expires July 24, 2011 [Page 18]
Internet-Draft Overload Control January 2011
Initiation Protocol (SIP) Load Control Event Package",
draft-ietf-soc-load-control-event-package-00 (work in
progress), January 2011.
[I-D.ietf-soc-overload-design]
Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design
Considerations for Session Initiation Protocol (SIP)
Overload Control", draft-ietf-soc-overload-design-04 (work
in progress), December 2010.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031,
January 2008.
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in
the Session Initiation Protocol", RFC 5390, December 2008.
Appendix A. Acknowledgements
Many thanks to Keith Drage, Janet Gunn, Rich Terpstra, Daryl Malas,
R. Parthasarathi, Jonathan Rosenberg, Charles Shen, Rahul Srivastava,
Padma Valluri, Shaun Bharrat, and Paul Kyzivat for their
contributions to this specification.
Appendix B. RFC5390 requirements
Table 1 provides a summary how this specification fulfills the
requirements of [RFC5390]. A more detailed view on how each
requirements is fulfilled is provided after the table.
Gurbani, et al. Expires July 24, 2011 [Page 19]
Internet-Draft Overload Control January 2011
+-------------+-------------------+
| Requirement | Meets requirement |
+-------------+-------------------+
| REQ 1 | Yes |
| REQ 2 | Yes |
| REQ 3 | Partially |
| REQ 4 | Partially |
| REQ 5 | Partially |
| REQ 6 | Not applicable |
| REQ 7 | Yes |
| REQ 8 | Partially |
| REQ 9 | Yes |
| REQ 10 | Yes |
| REQ 11 | Yes |
| REQ 12 | Yes |
| REQ 13 | Yes |
| REQ 14 | Yes |
| REQ 15 | Yes |
| REQ 16 | Yes |
| REQ 17 | Partially |
| REQ 18 | Yes |
| REQ 19 | Yes |
| REQ 20 | Yes |
| REQ 21 | Yes |
| REQ 22 | Yes |
| REQ 23 | Yes |
+-------------+-------------------+
Summary of meeting requirements in RFC5390
Table 1
REQ 1: The overload mechanism shall strive to maintain the overall
useful throughput (taking into consideration the quality-of- service
needs of the using applications) of a SIP server at reasonable
levels, even when the incoming load on the network is far in excess
of its capacity. The overall throughput under load is the ultimate
measure of the value of an overload control mechanism.
Meeting REQ 1: Yes, the overload control mechanism allows an
overloaded SIP server to maintain a reasonable level of throughput as
it enters into congestion mode by requesting the upstream clients to
reduce traffic destined downstream.
REQ 2: When a single network element fails, goes into overload, or
suffers from reduced processing capacity, the mechanism should strive
to limit the impact of this on other elements in the network. This
helps to prevent a small-scale failure from becoming a widespread
Gurbani, et al. Expires July 24, 2011 [Page 20]
Internet-Draft Overload Control January 2011
outage.
Meeting REQ 2: Yes. When a SIP server enters overload mode, it will
request the upstream clients to throttle the traffic destined to it.
As a consequence of this, the overloaded SIP server will itself
generate proportionally less downstream traffic, thereby limiting the
impact on other elements in the network.
REQ 3: The mechanism should seek to minimize the amount of
configuration required in order to work. For example, it is better
to avoid needing to configure a server with its SIP message
throughput, as these kinds of quantities are hard to determine.
Meeting REQ 3: Partially. On the server side, the overload condition
is determined monitoring S (c.f., Section 4 of
[I-D.ietf-soc-overload-design]) and reporting a load feedback F as a
value to the "oc" parameter. On the client side, a throttle T is
applied to requests going downstream based on F. This specification
does not prescribe any value for S, nor a particular value for F. The
"oc-algo" parameter allows for automatic convergence to a particular
class of overload control algorithm. There are suggested default
values for the "oc-validity" parameter.
REQ 4: The mechanism must be capable of dealing with elements that do
not support it, so that a network can consist of a mix of elements
that do and don't support it. In other words, the mechanism should
not work only in environments where all elements support it. It is
reasonable to assume that it works better in such environments, of
course. Ideally, there should be incremental improvements in overall
network throughput as increasing numbers of elements in the network
support the mechanism.
Meeting REQ 4: Partially. The mechanism is designed to reduce
congestion when a pair of communicating entities support it. If a
downstream overloaded SIP server does not respond to a request in
time, a SIP client conformant to this specification will attempt to
reduce traffic destined towards the non-responsive server as outlined
in Section 10.
REQ 5: The mechanism should not assume that it will only be deployed
in environments with completely trusted elements. It should seek to
operate as effectively as possible in environments where other
elements are malicious; this includes preventing malicious elements
from obtaining more than a fair share of service.
Meeting REQ 5: Partially. Since overload control information is
shared between a pair of communicating entities, a confidential and
authenticated channel can be used for this communication. However,
Gurbani, et al. Expires July 24, 2011 [Page 21]
Internet-Draft Overload Control January 2011
if such a channel is not available, then the security ramifications
outlined in Section 16 apply.
REQ 6: When overload is signaled by means of a specific message, the
message must clearly indicate that it is being sent because of
overload, as opposed to other, non overload-based failure conditions.
This requirement is meant to avoid some of the problems that have
arisen from the reuse of the 503 response code for multiple purposes.
Of course, overload is also signaled by lack of response to requests.
This requirement applies only to explicit overload signals.
Meeting REQ 6: Not applicable. Overload control information is
signaled as part of the Via header and not in a new header.
REQ 7: The mechanism shall provide a way for an element to throttle
the amount of traffic it receives from an upstream element. This
throttling shall be graded so that it is not all- or-nothing as with
the current 503 mechanism. This recognizes the fact that "overload"
is not a binary state and that there are degrees of overload.
Meeting REQ 7: Yes, please see Section 8 and Section 11.
REQ 8: The mechanism shall ensure that, when a request was not
processed successfully due to overload (or failure) of a downstream
element, the request will not be retried on another element that is
also overloaded or whose status is unknown. This requirement derives
from REQ 1.
Meeting REQ 8: Partially. A SIP client that has overload information
from multiple downstream servers will not retry the request on
another element. However, if a SIP client does not know the overload
status of a downstream server, it may send the request to that
server.
REQ 9: That a request has been rejected from an overloaded element
shall not unduly restrict the ability of that request to be submitted
to and processed by an element that is not overloaded. This
requirement derives from REQ 1.
Meeting REQ 9: Yes, a SIP client conformant to this specification
will send the request to a different element.
REQ 10: The mechanism should support servers that receive requests
from a large number of different upstream elements, where the set of
upstream elements is not enumerable.
Meeting REQ 10: Yes, there are no constraints on the number of
upstream clients.
Gurbani, et al. Expires July 24, 2011 [Page 22]
Internet-Draft Overload Control January 2011
REQ 11: The mechanism should support servers that receive requests
from a finite set of upstream elements, where the set of upstream
elements is enumerable.
Meeting REQ 11: Yes, there are no constraints on the number of
upstream clients.
REQ 12: The mechanism should work between servers in different
domains.
Meeting REQ 12: Yes, there are no inherent limitations on using
overload control between domains.
REQ 13: The mechanism must not dictate a specific algorithm for
prioritizing the processing of work within a proxy during times of
overload. It must permit a proxy to prioritize requests based on any
local policy, so that certain ones (such as a call for emergency
services or a call with a specific value of the Resource-Priority
header field [RFC4412]) are given preferential treatment, such as not
being dropped, being given additional retransmission, or being
processed ahead of others.
Meeting REQ 13: Yes, please see Section 11.
REQ 14: REQ 14: The mechanism should provide unambiguous directions
to clients on when they should retry a request and when they should
not. This especially applies to TCP connection establishment and SIP
registrations, in order to mitigate against avalanche restart.
Meeting REQ 14: Yes, Section 10 provides normative behavior on when
to retry a request after repeated timeouts and fatal transport errors
resulting from communications with a non-responsive downstream SIP
server.
REQ 15: In cases where a network element fails, is so overloaded that
it cannot process messages, or cannot communicate due to a network
failure or network partition, it will not be able to provide explicit
indications of the nature of the failure or its levels of congestion.
The mechanism must properly function in these cases.
Meeting REQ 15: Yes, Section 10 provides normative behavior on when
to retry a request after repeated timeouts and fatal transport errors
resulting from communications with a non-responsive downstream SIP
server.
REQ 16: The mechanism should attempt to minimize the overhead of the
overload control messaging.
Gurbani, et al. Expires July 24, 2011 [Page 23]
Internet-Draft Overload Control January 2011
Meeting REQ 16: Yes, overload control messages are sent in the
topmost Via header, which is always processed by the SIP elements.
REQ 17: The overload mechanism must not provide an avenue for
malicious attack, including DoS and DDoS attacks.
Meeting REQ 17: Partially. Since overload control information is
shared between a pair of communicating entities, a confidential and
authenticated channel can be used for this communication. However,
if such a channel is not available, then the security ramifications
outlined in Section 16 apply.
REQ 18: The overload mechanism should be unambiguous about whether a
load indication applies to a specific IP address, host, or URI, so
that an upstream element can determine the load of the entity to
which a request is to be sent.
Meeting REQ 18: Yes, please see discussion in Section 8.
REQ 19: The specification for the overload mechanism should give
guidance on which message types might be desirable to process over
others during times of overload, based on SIP-specific
considerations. For example, it may be more beneficial to process a
SUBSCRIBE refresh with Expires of zero than a SUBSCRIBE refresh with
a non-zero expiration (since the former reduces the overall amount of
load on the element), or to process re-INVITEs over new INVITEs.
Meeting REQ 19: Yes, please see Section 11.
REQ 20: In a mixed environment of elements that do and do not
implement the overload mechanism, no disproportionate benefit shall
accrue to the users or operators of the elements that do not
implement the mechanism.
Meeting REQ 20: Yes, an element that does not implement overload
control does not receive any measure of extra benefit.
REQ 21: The overload mechanism should ensure that the system remains
stable. When the offered load drops from above the overall capacity
of the network to below the overall capacity, the throughput should
stabilize and become equal to the offered load.
Meeting REQ 21: Yes, the overload control mechanism described in this
draft ensures the stability of the system.
REQ 22: It must be possible to disable the reporting of load
information towards upstream targets based on the identity of those
targets. This allows a domain administrator who considers the load
Gurbani, et al. Expires July 24, 2011 [Page 24]
Internet-Draft Overload Control January 2011
of their elements to be sensitive information, to restrict access to
that information. Of course, in such cases, there is no expectation
that the overload mechanism itself will help prevent overload from
that upstream target.
Meeting REQ 22: Yes, an operator of a SIP server can configure the
SIP server to only report overload control information for requests
received over a confidential channel, for example. However, note
that this requirement is in conflict with REQ 3, as it introduces a
modicum of extra configuration.
REQ 23: It must be possible for the overload mechanism to work in
cases where there is a load balancer in front of a farm of proxies.
Meeting REQ 23: Yes; depending on the type of load balancer, this
requirement is automatically met. More information on a load
balancer in the context of SIP overload is in Section 6 of
[I-D.ietf-soc-overload-design].
Authors' Addresses
Vijay K. Gurbani (editor)
Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm 9C-533
Naperville, IL 60563
USA
Email: vkg@bell-labs.com
Volker Hilt
Bell Labs/Alcatel-Lucent
791 Holmdel-Keyport Rd
Holmdel, NJ 07733
USA
Email: volkerh@bell-labs.com
Gurbani, et al. Expires July 24, 2011 [Page 25]
Internet-Draft Overload Control January 2011
Henning Schulzrinne
Columbia University/Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Gurbani, et al. Expires July 24, 2011 [Page 26]
