One document matched: draft-ietf-soc-overload-control-14.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY rfc3263 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml'>
<!ENTITY rfc4412 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4412.xml'>
<!ENTITY rfc5390 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5390.xml'>
<!ENTITY rfc5031 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5031.xml'>
<!ENTITY rfc3968 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3968.xml'>
<!ENTITY rfc2827 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml'>
<!ENTITY rfc6455 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6455.xml'>
<!ENTITY rfc6357 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6357.xml'>
<!ENTITY rfc6357 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6357.xml'>
<!ENTITY i-d.ietf-soc-load-control-event-package PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-soc-load-control-event-package.xml'>
<!ENTITY i-d.ietf-soc-overload-rate-control PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-soc-overload-rate-control.xml'>]>
<rfc ipr='trust200902' category='std' docName="draft-ietf-soc-overload-control-14">
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc sortrefs='yes'?>
<?rfc symrefs="yes"?>
<front>
<title abbrev='Overload Control'>Session Initiation Protocol (SIP)
Overload Control</title>
<author initials="V.K." surname="Gurbani" fullname="Vijay K. Gurbani" role="editor">
<organization>Bell Laboratories, Alcatel-Lucent</organization>
<address>
<postal>
<street>1960 Lucent Lane, Rm 9C-533</street>
<city>Naperville</city> <region>IL</region>
<code>60563</code>
<country>USA</country>
</postal>
<email>vkg@bell-labs.com</email>
</address>
</author>
<author initials='V.H.' surname='Hilt' fullname='Volker Hilt'>
<organization>Bell Laboratories, Alcatel-Lucent</organization>
<address>
<postal>
<street>791 Holmdel-Keyport Rd</street>
<city>Holmdel</city> <region>NJ</region>
<code>07733</code>
<country>USA</country>
</postal>
<email>volkerh@bell-labs.com</email>
</address>
</author>
<author initials='H.S.' surname='Schulzrinne' fullname='Henning Schulzrinne'>
<organization abbrev='Columbia University'>Columbia University/Department
of Computer Science</organization>
<address>
<postal>
<street>450 Computer Science Building</street>
<city>New York</city> <region>NY</region>
<code>10027</code>
<country>USA</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<date year='2013' />
<area>RAI</area>
<workgroup>SOC Working Group</workgroup>
<keyword>SIP</keyword>
<keyword>Overload Control</keyword>
<abstract>
<t>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 the behaviour of SIP servers involved in overload
control, and in addition, it specifies a loss-based overload scheme
for SIP.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>As with any network element, a Session Initiation Protocol
(SIP) <xref target="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.</t>
<t>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.</t>
<t>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 <xref target="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 <xref
target="RFC3261" />. Overload control does not apply to these
cases and SIP provides appropriate response codes for them.</t>
<t>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 <xref target="RFC5390" />.</t>
<t>This document defines the protocol for communicating overload
information between SIP servers and clients, so that clients can
reduce the volume of traffic sent to overloaded servers, avoiding
congestion collapse and increasing useful throughput. <xref target
="sec:header"/> describes the Via header parameters used for
this communication. The general behaviour of SIP servers and clients
involved in overload control is described in
<xref target="sec:gen-behaviour"/>. In addition,
<xref target="sec:loss-based"/> specifies a loss-based overload control
scheme. SIP clients and servers conformant to this specification MUST
implement the loss-based overload control scheme. They MAY implement
other overload control schemes as well.</t>
</section>
<section title="Terminology">
<t>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
<xref target="RFC2119">RFC 2119</xref>.</t>
<t>In this document, the terms "SIP client" and "SIP server" are used
in their generic forms. Thus, a "SIP client" could refer to
the client transaction state machine in a SIP proxy or it
could refer to a user agent client. Similarly, a "SIP server"
could be a user agent server or the server transaction state
machine in a proxy. Various permutations of this are also
possible, for instance, SIP clients and servers could also be
part of back-to-back user agents (B2BUAs).</t>
<t>However, irrespective of the context (i.e., proxy, B2BUA, UAS,
UAC) these terms are used in, "SIP client" applies to any SIP
entity that provides overload control to traffic destined
downstream. Similarly, "SIP server" applies to any SIP entity
that is experiencing overload and would like its upstream
neighbour to throttle incoming traffic.</t>
<t>Unless otherwise specified, all SIP entities described in this
document are assumed to support this specification.</t>
<t>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.</t>
</section>
<section title="Overview of operations" anchor="sec:overview">
<t>We now explain the overview of how the overload control
mechanism operates by introducing the overload control parameters.
<xref target="sec:header"/> provides more details and
normative behavior on the parameters listed below.</t>
<t>Because overload control is 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 <xref target="RFC6357"/>. Additional advantages of
this choice are discussed in <xref target="sec:dc:sm:response"/>. An
alternative mechanism using SIP event packages was also considered, and the
characteristics of that choice are further outlined in <xref target=
"sec:dc:sm:event"/>.</t>
<t>This document defines four new parameters for the SIP Via header
for overload control. These parameters provide a mechanism for
conveying overload control information between adjacent SIP
entities. The "oc" parameter is used by a SIP server to indicate
a reduction in the amount of requests arriving at the server. The
"oc-algo" parameter contains a token or a list of tokens corresponding
to the class of overload control algorithms supported by the client.
The server chooses one algorithm from this list. The "oc-validity"
parameter establishes a time limit for which overload control is
in effect, and the "oc-seq" parameter aids in sequencing the
responses at the client. These parameters are discussed in detail
in the next section.</t>
</section> <!-- sec:overview -->
<section title="Via header parameters for overload control"
anchor="sec:header">
<t>The four Via header parameters are introduced below.
Further context about how to interpret these under various
conditions is provided in <xref target="sec:gen-behaviour"/>.</t>
<section title="The oc parameter" anchor="oc-param">
<t>This parameter is inserted by the SIP client and updated by the
SIP server.</t>
<t>A SIP client MUST add
an "oc" parameter to the topmost Via header it inserts into every
SIP request. This provides an indication to downstream neighbors
that the client supports overload control. There MUST NOT be
a value associated with the parameter (the value will be added
by the server).</t>
<t>The downstream server MUST add a value to the "oc" parameter
in the response going upstream to a client that included the
"oc" parameter in the request. Inclusion of a value to the
parameter represents two things: one, upon the first contact (see
<xref target="oc-support"/>), addition of a value by the server
to this parameter
indicates (to the client) that the downstream server supports
overload control as defined in this document. Second, if
overload control is active, then it indicates the level of
control to be applied.</t>
<t>When a SIP client receives a response with the value in
the "oc" parameter filled in, it MUST reduce, as indicated
by the "oc" and "oc-algo" parameters, the number of requests
going downstream to the SIP server from which it received
the response (see
<xref target="sec:respond-overload"/> for pertinent discussion
on traffic reduction).</t>
</section> <!-- oc-param -->
<section title="The oc-algo parameter" anchor="oc-algo">
<t>This parameter is inserted by the SIP client and updated by the
SIP server.</t>
<t>A SIP client MUST add an "oc-algo" parameter to the topmost
Via header it inserts into every SIP request, with a default value
of "loss".</t>
<t>This parameter contains names of one or more classes of overload
control algorithms.
A SIP client MUST support the loss-based overload control scheme
and MUST insert at least the token "loss" as one of the "oc-algo"
parameter values.
In addition, the SIP client MAY insert other tokens, separated by a
comma, in the "oc-algo" parameter if it supports other overload
control schemes such as a rate-based scheme
(<xref target="I-D.ietf-soc-overload-rate-control"/>).
Each element in the comma-separated list corresponds to the
class of overload control algorithms supported by the SIP client.
When more than one class of overload control algorithms is
present in the "oc-algo" parameter, the client may indicate
algorithm preference by ordering the list in a decreasing order
of preference. However, the client must not assume that the
server will pick the most preferred algorithm.</t>
<t>When a downstream SIP server receives a request with multiple
overload control algorithms specified in the "oc-algo" parameter
(optionally sorted by decreasing order of preference), it MUST
choose one algorithm from the list and return the single selected
algorithm in the response to the upstream SIP client.</t>
<t>Once the SIP server has chosen, and communicated to the client,
a mutually agreeable class of overload control algorithm, the
selection stays in effect until such time that the algorithm is
changed by the server. Furthermore, the client MUST continue
to include all the supported algorithms in subsequent requests;
the server MUST respond with the agreed to algorithm until such
time that the algorithm is changed by the server.
The selection SHOULD stay the same for a non-trivial duration of
time to allow the overload control algorithm to stabilize its
behaviour (see <xref target="sec:stabilize"/>).</t>
<!-- For the text after "Furthermore ..." in the above paragraph, see
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00669.html
for a discussion on this. -->
<t>The "oc-algo" parameter does not define the exact algorithm to be
used for traffic reduction, rather, the intent is to use any
algorithm from a specific class of algorithms that affect traffic
reduction similarly. For example, the reference algorithm in
<xref target="sec:default-loss-algo"/> can be used as a
loss-based algorithm, or it can be substituted by any other loss-based
algorithm that results in equivalent traffic reduction.</t>
<!-- c.f.
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00935.html
-->
</section> <!-- oc-algo -->
<section title="The oc-validity parameter" anchor="oc-validity">
<t>This parameter MAY be inserted by the SIP server in a response;
it MUST NOT be inserted by the SIP client in a request.</t>
<t>This parameter contains a value that indicates an interval of time
(measured in milliseconds) that the load reduction specified in the
value of the "oc" parameter should be in effect. The default
value of the "oc-validity" parameter is 500 (millisecond). If the
client receives a response with the "oc" and "oc-algo" parameters
suitably filled in, but no "oc-validity" parameter, the SIP client
should behave as if it had received "oc-validity=500".</t>
<t>A value of 0 in the "oc-validity" parameter is reserved
to denote the event that the server wishes to stop overload
control, or to indicate that it supports overload control, but is
not currently requesting any reduction in traffic
(see <xref target="sec:terminate"/>).</t>
<t>A non-zero value for the "oc-validity" parameter MUST only be
present in conjunction with an "oc" parameter. A SIP client
MUST discard a non-zero value of the "oc-validity" parameter
if the client receives it in a response without the corresponding
"oc" parameter being present as well.</t>
<t>After the value specified in the "oc-validity" parameter expires
and until the SIP client receives an updated set of overload control
parameters from the SIP server, the client MUST behave as if
overload control is not in effect between it and the downstream
SIP server.</t>
</section> <!-- oc-validity -->
<section title="The oc-seq parameter" anchor="oc-seq">
<t>This parameter MUST be inserted by the SIP server in a response;
it MUST NOT be inserted by the SIP client in a request.</t>
<t>This parameter contains an unsigned integer value that indicates
the sequence number associated with the "oc" parameter. This
sequence number is used to differentiate two "oc" parameter values
generated by an overload control algorithm at two different instants
in time. "oc" parameter values generated by an overload control
algorithm at time t and t+1 MUST have an increasing value in the
"oc-seq" parameter. This allows the upstream SIP client to properly
collate out-of-order responses.</t>
<t><list style="empty">
<t>A timestamp can be used as a value of the "oc-seq" parameter.</t>
</list></t>
<!-- Decision to go with a timestamp like mechanism reached at
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00307.html
-->
<t>If the value contained in "oc-seq" parameter overflows during
the period in which the load reduction is in effect, then
the "oc-seq" parameter MUST be reset to the current timestamp or
an appropriate base value.</t>
<t><list style="empty">
<t>A client implementation can recognize that an overflow has
occurred when it receives an "oc-seq" parameter whose value
is significantly less than several previous values. (Note that
an "oc-seq" parameter whose value does not deviate significantly
from the last several previous values is symptomatic of a tardy
packet. However, overflow will cause "oc-seq" an "oc-seq"
parameter value to be significantly less than the last several
values.) If an overflow is detected, then the client should
use the overload parameters in the new message, even though the
sequence number is lower. The client should also reset any
internal state to reflect the overflow so that future messages
(following the overflow) will be accepted.</t>
<!-- Above inserted instead of below based on AD review.
Source:
http://www.ietf.org/mail-archive/web/sip-overload/current/msg01030.html
-->
<!-- Due to an overflow, client implementations should be
prepared to receive an "oc-seq" parameter whose value is less
than the previous value. Client implementations can handle
this by continuing to perform overload control until the
"oc-validity" related to the previous value of "oc-seq" parameter
expires.
Source: http://www.ietf.org/mail-archive/web/sip-overload/current/
msg00928.html -->
</list></t>
</section> <!-- oc-seq -->
<!--
<t><list>
<t>OPEN ISSUE: To throttle upstream neighbors in a fair way,
it is important that a SIP server can estimate the load each
upstream neighbor receives for this server before it is
throttled. This enables the server to throttle each upstream
neighbor in the same way and thus provides each request the
same chance of succeeding. In rate- and window-based overload
control systems, a SIP server does not know how many messages
each upstream neighbor had received for the server before
throttling took place. A solution to this problem is to allow
servers to report the unthrottled load for a downstream neighbor
in the 'oc_accept' parameter.</t>
</list></t>
-->
</section> <!-- sec:header -->
<section title="General behaviour" anchor="sec:gen-behaviour">
<t>When forwarding a SIP request, a SIP client uses the SIP
procedures of <xref target="RFC3263"/> to determine the next
hop SIP server. The procedures of <xref target="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").</t>
<t>After selecting a specific SIP server from the Expected Output,
a SIP client MUST determine whether overload controls are
currently active with that server. If overload controls are
currently active (and oc-validity period has not yet expired),
the client applies the relevant algorithm to determine whether
or not to send the SIP request to the server. If overload
controls are not currently active with this server (which will
be the case if this is the initial contact with the server,
or the last response from this server had "oc-validity=0",
or the time period indicated by the "oc-validity" parameter has
expired), the SIP client sends the SIP message to the server
without invoking any overload control algorithm.</t>
<section title="Determining support for
overload control" anchor="oc-support">
<t>If a client determines that this is the first contact
with a server, the client MUST insert the "oc" parameter without
any value, and MUST insert the "oc-algo" parameter with a
list of algorithms it supports. This list MUST include
"loss" and MAY include other algorithm names approved by IANA
and described in corresponding documents. The client transmits
the request to the chosen server.</t>
<!--
NOTE: It is important to retain the above since this states
uneqivocally that the list of algorithms must include loss!
-->
<t>If a server receives a SIP request containing the "oc"
and "oc-algo" parameters, the server MUST determine if it
has already selected the overload control algorithm class
with this client. If it has, the server SHOULD use the
previously selected algorithm class in its response to the
message. If the server determines that the message is from
a new client, or a client the server has not heard from in
a long time, the server MUST choose one algorithm
from the list of algorithms in the "oc-algo" parameter. It
MUST put the chosen algorithm as the sole parameter value in
the "oc-algo" parameter of the response it sends to the client.
In addition, if the server is currently not in an overload condition,
it MUST set the value of the "oc" parameter to be 0 and MAY insert
an "oc-validity=0" parameter in the response to further qualify
the value in the "oc" parameter. If the server is currently
overloaded, it MUST follow the procedures of <xref target="oc-create"/>.
</t>
<t>
<list style="empty">
<t>A client that supports the rate-based overload control scheme
<xref target="I-D.ietf-soc-overload-rate-control"/>
will consider "oc=0" as an indication not to send any
requests downstream at all. Thus, when the server inserts
"oc-validity=0" as well, it is indicating that it does support
overload control, but it is not under overload mode right now
(see <xref target="sec:terminate"/>).</t></list>
</t>
</section> <!-- oc-support -->
<section title="Creating and updating the overload control parameters"
anchor="oc-create">
<t>A SIP server provides overload control feedback to its
upstream clients by providing a value for the "oc" parameter
to the topmost Via header field of a SIP response, that is,
the Via header added by the client before it sent the request
to the server.</t>
<t>Since the topmost Via header of a response will be removed by
an upstream client 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
<xref target="RFC6357"/>) even if the
next hop neighbor does not support this specification.</t>
<t>The "oc" parameter can be used in all response types,
including provisional, success and failure responses (please see
<xref target="sec:100"/> for special consideration on
transporting overload control parameters in a 100-Trying response). A
SIP server MAY update the "oc" parameter a response, asking the
client to increase or decrease the number of requests destined
to the server, or to stop performing overload control altogether.</t>
<!--
<t>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 specify an oc-validity time that is responsive
to changing client originated traffic rates, but not too short as
to introduce instability. This is a complex subject and outside
the scope of this specification. (Last two sentences added in -07
by feedback from Phil Williams, see
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00699.html)
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.</t>
REPLACED WITH TEXT BELOW from Volker's email to the list.
See
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00764.html
-->
<t>A SIP server that has updated the "oc" parameter SHOULD also
add a "oc-validity" parameter. The "oc-validity" parameter defines
the time in milliseconds during
which the the overload control feedback specified in the "oc"
parameter is valid. The default value of the "oc-validity" parameter
is 500 (millisecond).</t>
<t>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 than 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.</t>
<t>Implementations that are capable of updating the "oc"
and "oc-validity" parameter values during retransmissions MUST
insert the "oc-seq" parameter. The value of this parameter
MUST be a set of numbers drawn from an increasing sequence.</t>
<t>Implementations that are not capable of updating the "oc"
and "oc-validity" parameter values during 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.</t>
<!-- Ed. note: The discussion that lead to the above is
captured in
http://www.ietf.org/mail-archive/web/sip-overload/
current/msg00250.html
-->
<t>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 the client is the entity
that can offload traffic by redirecting or 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.</t>
<!--
Not sure the paragraph below adds anything useful to the
discussion. I will comment it out right now and see if
someone notices its disappearance. vkg Nov-19-2010.
<t>While adding "oc" and "oc-validity" parameters to
requests may increase the frequency with which overload
information is exchanged in these scenarios, this increase will
rarely provide benefits and does not justify the added overhead
and complexity needed.</t>
-->
<t>Since overload control protects a SIP server from overload,
it is RECOMMENDED that a SIP server uses 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. </t>
</section>
<section title="Determining the 'oc' Parameter Value"
anchor="oc-determine">
<!-- The below paragraph taken out in -07 as agreed upon
in the following list exchange:
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00707.html
The value of the "oc" parameter is determined by the
overloaded server using any pertinent information at its
disposal. The process by which an overloaded server
determines the value of the "oc" parameter is considered
out of scope for this document.
It has been replaced by what you see below.
-->
<t> The value of the "oc" parameter is determined by the overloaded
server using any pertinent information at its disposal. The only
constraint imposed by this document is that the server control
algorithm MUST produce a value for the "oc" parameter
that it expects the receiving SIP clients to apply to all downstream
SIP requests (dialogue forming as well as in-dialogue) to this SIP
server. Beyond this stipulation, the process by which an overloaded
server determines the value of the "oc" parameter is considered out
of scope for this document.</t>
<t>
<list style="empty">
<t>Note that this stipulation is required so that both the client
and server have an common view of which messages the overload
control applies to. With this stipulation
in place, the client can prioritize messages as discussed
in <xref target="msg-priority"/>.</t>
</list>
</t>
<t>As an example, a value of "oc=10" when the loss-based algorithm
is used implies that 10% of the total number of SIP requests (dialog
forming as well as in-dialogue) are subject to reduction at the client.
Analogously, a value of "oc=10" when the rate-based algorithm
<xref target="I-D.ietf-soc-overload-rate-control"/> is used indicates
that the client should send SIP requests at a rate of 10 SIP requests
or fewer per second.</t>
</section>
<section title="Processing the Overload Control Parameters"
anchor="oc-process">
<t>A SIP client 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.</t>
<t>The scope of overload control applies to unique combinations of
IP and port values. A SIP client maintains the overload control
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 overload control parameter
from a downstream SIP server, it compares the "oc-seq" value extracted
from the Via header with the "oc-seq" value stored for this server.
If these values match, the response does not update the overload
control parameters related to this server and the client continues
to provide overload control as previously negotiated. If the
"oc-seq" value extracted from the Via header is larger than the
stored value, the client updates the stored values by
copying the new values of "oc", "oc-algo" and "oc-seq" parameters
from the Via header to the stored values. Upon such an update
of the overload control parameters, the client restarts the
validity period of the new overload control parameters. The
overload control parameters now remain in effect until the
validity period expires or the parameters are updated in a new
response. Stored overload control parameters MUST be reset to
default values once the validity period has expired (see
<xref target="sec:terminate"/> for the detailed steps on terminating
overload control).</t>
</section>
<section title="Using the Overload Control Parameter Values"
anchor="oc-use">
<t>A SIP client 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" and "oc-algo" parameter values from
that particular downstream server.</t>
<t>When forwarding a SIP request, a SIP client uses the SIP
procedures of <xref target="RFC3263"/> to determine the next
hop SIP server. The procedures of <xref target="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").</t>
<t>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, then 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 based on the "oc" and "oc-algo" parameters and any
relevant local policy.</t>
<t>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 transmit the same number of
SIP requests as the sample algorithm defined by the overload
control scheme being used. (See <xref target="sec:default-loss-algo"/>
for the default loss-based overload control algorithm.)</t>
<!--
<t>The SIP client SHOULD use the following algorithm to determine
if it can forward the request. The SIP client draws a random
number between 1 and 100 for the current request. If the random
number is less than or equal to the 'oc' parameter value, the
request is not forwarded. Otherwise, the request is
forwarded (note that this algorithm does not prioritize the
requests it is dropping --- c.f. OPEN ISSUE 3 in <xref target=
"msg-priority"/>.) Any other algorithms that
approximate the random number algorithm may be used as well.</t>
-->
<!--
<t><list>
<t>OPEN ISSUE: the specific mechanisms to throttle traffic
depend on the type of feedback conveyed in the 'oc' parameter
value. It needs to be defined depending on whether a
loss-based, rate-based or window-based feedback is used.</t>
</list></t>
<t>The treatment of SIP requests that cannot be forwarded to the
selected SIP Server is a matter of local policy. A SIP client
MAY try to find an alternative target or it MAY reject the
request (see <xref target="sec:5xx" />).</t>
-->
</section>
<section title="Forwarding the overload control parameters"
anchor="sec:forward">
<t>Overload control is defined in a hop-by-hop manner. Therefore,
forwarding the contents of the overload control parameters
is generally NOT RECOMMENDED and should only be performed if
permitted by the configuration of SIP servers. This means that a
SIP proxy SHOULD strip the overload control parameters
inserted by the client before proxying the request further
downstream.</t>
</section> <!-- sec:forward -->
<section title="Terminating overload control"
anchor="sec:terminate">
<t>A SIP client removes overload control if one of the following
events occur:</t>
<t>
<list style="numbers">
<!-- <t>The "oc" parameter is set to a value that allows the
client to forward all traffic;</t> -->
<t>The "oc-validity" period previously received by the client
from this server (or the default value of 500ms if the server
did not previously specify an "oc-validity" parameter) expires;</t>
<t>The client is explicitly told by the server to
stop performing overload control using the "oc-validity=0"
parameter.</t>
</list>
</t>
<t>A SIP server can decide to terminate overload control by explicitly
signaling the client. To do so, the SIP server MUST set the value
of the "oc-validity" parameter to 0. The SIP server MUST increment
the value of "oc-seq", and SHOULD set the value of the "oc" parameter
to 0.
<list>
<t></t>
<t>Note that the loss-based overload control scheme
(<xref target="sec:loss-based"/>) can
effectively stop overload control by setting the value of the
"oc" parameter to 0. However, the rate-based scheme
(<xref target="I-D.ietf-soc-overload-rate-control"/>) needs an
additional piece of information in the form of "oc-validity=0".</t>
</list>
</t>
<t>When the client receives a response with a higher "oc-seq"
number than the one it most recently processed, it checks
the "oc-validity" parameter. If the value of the "oc-validity"
parameter is 0, the client MUST stop performing overload control of
messages destined to the server and the traffic should flow without
any reduction. Furthermore, when the value of the "oc-validity"
parameter is 0, the client SHOULD disregard the value in the
"oc" parameter.</t>
</section> <!-- sec:terminate -->
<section title="Stabilizing overload algorithm selection"
anchor="sec:stabilize">
<t>Realities of deployments of SIP necessitate that the
overload control algorithm may be changed upon a system reboot
or a software upgrade. However, frequent changes of the
overload control algorithm must be avoided. Frequent changes
of the overload control algorithm will not benefit the client or
the server as such flapping does not allow the chosen algorithm
to stabilize. An algorithm change, when desired, is simply
accomplished by the SIP server choosing a new algorithm from the list
in the client's "oc-algo" parameter and sending it back to the
client in a response.</t>
<t>The client associates a specific algorithm with each server it
sends traffic to and when the server changes the algorithm,
the client must change its behaviour accordingly.</t>
<t>Once the server selects a specific overload control algorithm
for a given client, the algorithm SHOULD NOT change the algorithm
associated with that client for at least 3600 seconds (1 hour).
This period may involve one or more cycles of overload control being
in effect and then being stopped depending on the traffic and
resources at the server.
<list>
<t></t>
<t>One way to accomplish this involves the server
saving the time of the last algorithm change in a lookup
table, indexed by the client's network identifiers.
The server only changes the "oc-algo" parameter when the time
since the last change has surpassed 3600 seconds.</t>
</list>
</t>
</section> <!-- sec:stabilize -->
<section title="Self-Limiting" anchor="sec:self-limiting">
<t>In some cases, a SIP client may not receive a response from a
server after sending a request. <xref
target="RFC3261">RFC3261</xref> 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.</t>
<t>In the event of repeated timeouts or fatal transport errors,
the SIP client MUST stop sending requests to this server. The
SIP client SHOULD periodically probe if the downstream server is
alive using any mechanism at its disposal. Clients should be
conservative in their probing (e.g., using an exponential back-off) so
that their liveness probes do not exacerbate an overload situation.
<!-- Commented and updated above by AD review.
SIP client SHOULD periodically probe if the downstream server
is alive using any mechanism at its disposal.
The above sentence added in -07 at the request of Sal. See
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00697.html,
towards the end of the post. -->
Once a SIP client has successfully received a normal response for a
request sent to the downstream server, the SIP client can resume
sending SIP requests. It should, of course, honor any overload
control parameters it may receive in the initial, or later,
responses.</t>
<!--
<t><list>
<t>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.</t>
</list></t>
<t><list>
<t>OPEN ISSUE: waiting for a timeout to occur seems a long time
before starting to throttle back. It could make sense to
throttle back earlier if no response is received for requests
transmitted.</t>
</list></t>
-->
</section>
<section title="Responding to an Overload Indication"
anchor="sec:respond-overload">
<t>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. A 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 with a "503 (Service Unavailable)"
response without the Retry-After header.</t>
<section title="Message prioritization at the hop before the
overloaded server" anchor="msg-priority">
<t>During an overload condition, a SIP client needs to
prioritize requests and select those requests that need to be rejected
or redirected. This selection is largely a matter of local
policy. It is expected that a SIP client will follow
local policy as long as the result in reduction of traffic is
consistent with the overload algorithm in effect at that node.
Accordingly, the normative behaviour in the next three paragraphs
should be interpreted with the understanding that the SIP client
will aim to preserve local policy to the fullest extent possible.</t>
<t>A SIP client SHOULD honor the local policy for prioritizing
SIP requests such as policies based on message type, e.g., INVITEs
versus requests associated with existing sessions.</t>
<t>A SIP client SHOULD honor the local policy for prioritizing
SIP requests based on the content of the
Resource-Priority header (RPH, <xref target="RFC4412">RFC4412</xref>).
Specific (namespace.value) RPH contents may indicate high priority
requests that should be 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.</t>
<t>A SIP client SHOULD honor the local policy for prioritizing SIP
requests relating to emergency calls as identified by the SOS URN
<xref target="RFC5031"/> indicating an emergency request.</t>
<t>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.</t>
<!-- Took this out as per the review of Janet Gunn. She feels that
this is out of scope for this document. However, Keith points out
that service providers need this specified. So going with the
text that currently appears in S7.
<t>A SIP client SHOULD honor user-level load control filters
installed by signaling neighbors
<xref target="I-D.ietf-soc-load-control-event-package"/> by sending
the SIP messages that matched the filter downstream.</t>
-->
<!--
<t><list>
<t>OPEN ISSUE 3: The process by which the upstream server
selects messages to be rejected to reduce load needs to be
discussed further. Clearly, SIP messages that contain the
Resource-Priority header should not be rejected. Also, mid-
dialog requests (re-INVITEs, UPDATEs, BYEs etc.) should be
honored, if possible. This can be left as a policy decision
with guidelines provided --- example, if a request has both
the To tag and From tag, do not drop it since it is a mid-
dialog request; do not drop requests with the Resource-Priority
header, etc. Some discussion on this is captured in
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00272.html.
</t>
<t></t>
<t>This issue also has a bearing on the default algorithm to be
outlined in Section <xref target="oc-use"/>.</t>
</list></t>
-->
</section>
<section title="Rejecting requests at an overloaded server"
anchor="sec:5xx">
<t>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, for the non-participating
client, the overloaded server must bear the cost of rejecting
some requests from the client as well as the cost of processing the
non-rejected 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 from a non-participating client
as the overloaded server would devote to processing requests from a
participating client. This is to ensure that SIP clients that do
not support this specification don't receive an unfair advantage over
those that do. </t>
<t>A SIP server that is under overload and has started to
throttle incoming traffic MUST reject some requests from
non-participating clients with a "503 (Service Unavailable)" response
without the Retry-After header.</t>
</section>
</section>
<section title="100-Trying provisional response and overload control
parameters" anchor="sec:100">
<t>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.</t>
<t>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.
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.</t>
<!-- c.f. http://www.ietf.org/mail-archive/web/sip-overload/
current/msg00452.html -->
</section> <!-- sec:100 -->
</section> <!-- sec:gen-behaviour -->
<section title="Example" anchor="sec:example">
<t>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.</t>
<figure><artwork><![CDATA[
INVITE sips:user@example.com SIP/2.0
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;oc;oc-algo="loss,A"
...
SIP/2.0 100 Trying
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;received=192.0.2.111;
oc=0;oc-algo="loss";oc-validity=0
...
]]></artwork></figure>
<t>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. P1 supports two overload control algorithms: loss and
some algorithm called "A".</t>
<t>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, and because it
chooses the "loss" based scheme, it sends "loss" back to P1 in
the "oc-algo" parameter. It also sets the value of "oc" and
"oc-validity" parameters to 0 because it is not currently
requesting overload control activation.</t>
<t>Had P2 not supported overload control, it would have left
the "oc" and "oc-algo" parameters unchanged, thus allowing the
client to know that it did not support overload control.</t>
<t>At some later time, P2 starts to experience overload. It
sends the following SIP message indicating that P1 should
decrease the messages arriving to P2 by 20% for 0.5s.</t>
<figure><artwork><![CDATA[
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.3;received=192.0.2.111;
oc=20;oc-algo="loss";oc-validity=500;
oc-seq=1282321615.782
...
]]></artwork></figure>
<t>After some time, the overload condition at P2 subsides. It then
changes the parameter values in the response it sends to P1 to allow
P1 to send all messages destined to P2.</t>
<figure><artwork><![CDATA[
SIP/2.0 183 Queued
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.4;received=192.0.2.111;
oc=0;oc-algo="loss";oc-validity=0;oc-seq=1282321892.439
...
]]></artwork></figure>
</section> <!-- sec:example -->
<section title="The loss-based overload control scheme"
anchor="sec:loss-based">
<t>Under a loss-based approach, a SIP server asks an upstream neighbor to
reduce the number of requests it would normally forward to this
server by a certain percentage. For example, a SIP server can ask
an upstream neighbor to reduce the number of requests this neighbor
would normally send by 10%. The upstream neighbor then redirects
or rejects 10% of the traffic originally destined for that server.</t>
<t>This section specifies the semantics of the overload control
parameters associated with the loss-based overload control scheme.
The general behaviour of SIP clients and servers is specified in
<xref target="sec:gen-behaviour"/> and is applicable to SIP clients
and servers that implement loss-based overload control.</t>
<section title="Special parameter values for loss-based overload
control" anchor="sec:loss-based-params">
<t>The loss-based overload control scheme is identified using the
token "loss". This token MUST appear in the "oc-algo" parameter
list sent by the SIP client.</t>
<t>A SIP server that has selected the loss-based algorithm, upon
entering the overload state, will assign a value to the "oc" parameter.
This value MUST be in the range of [0, 100], inclusive. This
value MUST be interpreted by the client as a percentage, and the
SIP client MUST reduce the number of
requests being forwarded to the overloaded server by that percent.
The SIP client may use any algorithm that reduces the traffic
it sends to the overloaded server by the amount indicated. Such
an algorithm SHOULD honor the message prioritization discussion
of <xref target="msg-priority"/>. While a particular algorithm
is not subject to standardization, for completeness a default
algorithm for loss-based overload control is provided in
<xref target="sec:default-loss-algo"/>.</t>
<!-- Commented as per AD review; please see
http://www.ietf.org/mail-archive/web/sip-overload/current/msg01014.html
<t>When a SIP server using the loss-based algorithm receives a
request from a client with an "oc" parameter but the SIP server is
not experiencing overload, it MUST assign a value of 0 to the
"oc" parameter in the response. Assigning such a value lets
the client know that the server supports overload control but
is not currently requesting any reduction in traffic.</t>
<t>When the "oc-validity" parameter is used to signify overload
control termination (<xref target="sec:terminate"/>), the server
MUST insert a value of 0 in the "oc-validity" parameter. The
server MUST insert a value of 0 in the "oc" parameter as well.
When a client receives a response whose "oc-validity" parameter
contains a 0, it MUST treat any non-zero value in the "oc"
parameter as if it had received a value of 0 in that parameter.</t>
-->
</section> <!-- sec:loss-based-params -->
<!-- Moved to its own section as per AD review, see
http://www.ietf.org/mail-archive/web/sip-overload/current/msg01014.html
<section title="Example" anchor="sec:example">
<t>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.</t>
<figure><artwork><![CDATA[
INVITE sips:user@example.com SIP/2.0
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;oc;oc-algo="loss,A"
...
SIP/2.0 100 Trying
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;received=192.0.2.111;
oc=0;oc-algo="loss";oc-validity=0
...
]]></artwork></figure>
<t>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. P1 supports two overload control algorithms: loss and
some algorithm called "A".</t>
<t>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, and because it
chooses the "loss" based scheme, it sends "loss" back to P1 in
the "oc-algo" parameter. It also sets the value of "oc" and
"oc-validity" parameters to 0 because it is not currently
requesting overload control activation.</t>
<t>Had P2 not supported overload control, it would have left
the "oc" and "oc-algo" parameters unchanged, thus allowing the
client to know that it did not support overload control.</t>
<t>At some later time, P2 starts to experience overload. It
sends the following SIP message indicating that P1 should
decrease the messages arriving to P2 by 20% for 0.5s.</t>
<figure><artwork><![CDATA[
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.3;received=192.0.2.111;
oc=20;oc-algo="loss";oc-validity=500;
oc-seq=1282321615.782
...
]]></artwork></figure>
<t>After some time, the overload condition at P2 subsides. It then
changes the parameter values in the response it sends to P1 to allow
P1 to send all messages destined to P2.</t>
<figure><artwork><![CDATA[
SIP/2.0 183 Queued
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.4;received=192.0.2.111;
oc=0;oc-algo="loss";oc-validity=0;oc-seq=1282321892.439
...
]]></artwork></figure>
</section>
-->
<section title="Default algorithm for loss-based overload control"
anchor="sec:default-loss-algo">
<t>This section describes a default algorithm that a SIP client can
use to throttle SIP traffic going downstream by the percentage loss
value specified in the "oc" parameter.</t>
<t>The client maintains two categories of requests; the first
category will include requests that are candidates for reduction,
and the second category will include requests that are not subject
to reduction except when all messages in the first category have
been rejected, and further reduction is still needed.
Section <xref target="msg-priority"/> contains directives on
identifying messages for inclusion in the second category.
The remaining messages are allocated to the first category.</t>
<t>Under overload condition, the client converts the value of the
"oc" parameter to a value that it applies to requests in the first
category. As a simple example, if "oc=10" and 40% of the requests
should be included in the first category, then:
<list style="empty"><t></t><t>10 / 40 * 100 = 25</t><t></t></list>
Or, 25% of the requests in the first category can be reduced to get
an overall reduction of 10%. The client uses random discard to
achieve the 25% reduction of messages in the first category.
Messages in the second category proceed downstream unscathed.
To affect the 25% reduction rate from the first category, the
client draws a random number between 1 and 100 for the request
picked from the first category. If the random number is less than
or equal to converted value of the "oc" parameter, the request is
not forwarded; otherwise the request is forwarded.</t>
<t>A reference algorithm is shown below.</t>
<figure><artwork><![CDATA[
cat1 := 80.0 // Category 1 --- subject to reduction
cat2 := 100.0 - cat1 // Category 2 --- Under normal operations
// only subject to reduction after category 1 is exhausted.
// Note that the above ratio is simply a reasonable default.
// The actual values will change through periodic sampling
// as the traffic mix changes over time.
while (true) {
// We're modeling message processing as a single work queue
// that contains both incoming and outgoing messages.
sip_msg := get_next_message_from_work_queue()
update_mix(cat1, cat2) // See Note below
switch (sip_msg.type) {
case outbound request:
destination := get_next_hop(sip_msg)
oc_context := get_oc_context(destination)
if (oc_context == null) {
send_to_network(sip_msg) // Process it normally by sending the
// request to the next hop since this particular destination
// is not subject to overload
}
else {
// Determine if server wants to enter in overload or is in
// overload
in_oc := extract_in_oc(oc_context)
oc_value := extract_oc(oc_context)
oc_validity := extract_oc_validity(oc_context)
if (in_oc == false or oc_validity is not in effect) {
send_to_network(sip_msg) // Process it normally by sending
// the request to the next hop since this particular
// destination is not subject to overload. Optionally,
// clear the oc context for this server (not shown).
}
else { // Begin perform overload control
r := random()
drop_msg := false
category := assign_msg_to_category(sip_msg)
pct_to_reduce_cat1 = oc_value / cat1 * 100
if (oc_value <= cat1) { // Reduce all msgs from category 1
if (r <= pct_to_reduce_cat1 && category == cat1) {
drop_msg := true
}
}
else { // oc_value > category 1. Reduce 100% of msgs from
// category 1 and remaining from category 2.
pct_to_reduce_cat2 = (oc_value - cat1) / cat2 * 100
if (category == cat1) {
drop_msg := true
}
else {
if (r <= pct_to_reduce_cat2) {
drop_msg := true;
}
}
}
if (drop_msg == false) {
send_to_network(sip_msg) // Process it normally by
// sending the request to the next hop
}
else {
// Do not send request downstream, handle locally by
// generating response (if a proxy) or treating as
// an error (if a user agent).
}
} // End perform overload control
}
end case // outbound request
case outbound response:
if (we are in overload) {
add_overload_parameters(sip_msg)
}
send_to_network(sip_msg)
end case // outbound response
case inbound response:
if (sip_msg has oc parameter values) {
create_or_update_oc_context() // For the specific server
// that sent the response, create or update the oc context;
// i.e., extract the values of the oc-related parameters
// and store them for later use.
}
process_msg(sip_msg)
end case // inbound response
case inbound request:
if (we are not in overload) {
process_msg(sip_msg)
}
else { // We are in overload
if (sip_msg has oc parameters) { // Upstream client supports
process_msg(sip_msg) // oc; only sends important requests
}
else { // Upstream client does not support oc
if (local_policy(sip_msg) says process message) {
process_msg(sip_msg)
}
else {
send_response(sip_msg, 503)
}
}
}
end case // inbound request
}
}
Note: A simple way to sample the traffic mix for category 1 and
category 2 is to associate a counter with each category of message.
Periodically (every 5-10s) get the value of the counters and calculate
the ratio of category 1 messages to category 2 messages since the
last calculation.
Example: In the last 5 seconds, a total of 500 requests arrived
at the queue. 450 out of the 500 were messages subject
to reduction and 50 out of 500 were classified as requests not
subject to reduction. Based on this ratio, cat1 := 90 and
cat2 := 10, so a 90/10 mix will be used in overload calculations.
]]></artwork></figure>
<!--
Above algorithm based on:
1. www.ietf.org/mail-archive/web/sip-overload/current/msg00318.html
refined by the thread
http://www.ietf.org/mail-archive/web/sip-overload/current/threads.html#00734
2. Last paragraph of Section 4.5 in
http://tools.ietf.org/html/draft-gurbani-soc-overload-control-01
-->
</section> <!-- sec:default-loss-based-algo -->
</section> <!-- sec:loss-based -->
<section title="Relationship with other IETF SIP load control efforts"
anchor="sec:relationship">
<t>The overload control mechanism described in this document is reactive
in nature and apart from message prioritization directives listed in
<xref target="msg-priority"/> 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
<xref target="I-D.ietf-soc-load-control-event-package"/>. Local
policy will also dictate the precedence of different overload
control mechanisms applied to the traffic. Specifically, in a
scenario where load control filters are installed by signaling
neighbours [I-D.ietf-soc-load-control-event-package] and the same
traffic can also be throttled using the overload control mechanism,
local policy will dictate which of these schemes shall be given
precedence. Interactions between the two schemes are out of scope
for this document.</t>
</section> <!-- sec:relationship -->
<section title="Syntax" anchor="sec:syntax">
<!--
<t><list>
<t>OPEN ISSUE: the syntax of the 'oc' Via header parameter
depends on the overload control method (i.e., loss-based,
rate-based or window-based) in use. The following syntax
definition defines a rate-based 'oc' header. This syntax needs
to be adjusted if rate-based or window-based overload control is
used.</t>
</list></t>
-->
<t>This specification extends the existing definition of the Via
header field parameters of <xref target="RFC3261"/> as follows:</t>
<figure>
<artwork><![CDATA[
via-params = via-ttl / via-maddr
/ via-received / via-branch
/ oc / oc-validity
/ oc-seq / oc-algo / via-extension
oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT
oc-validity = "oc-validity" [EQUAL delta-ms]
oc-seq = "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT
oc-algo = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list)
DQUOTE
algo-list = "loss" / *(other-algo)
other-algo = %x41-5A / %x61-7A / %x30-39
delta-ms = 1*DIGIT
]]></artwork>
</figure>
</section>
<section title="Design Considerations" anchor="sec:dc">
<t>This section discusses specific design considerations for the
mechanism described in this document. General design
considerations for SIP overload control can be found in
<xref target="RFC6357" />.</t>
<section title="SIP Mechanism" anchor="sec:dc:sm">
<t>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.</t>
<section title="SIP Response Header" anchor="sec:dc:sm:response">
<t>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:</t>
<t><list style='symbols'>
<t>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. </t>
<t>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.</t>
<t>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.</t>
<t>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. </t>
<t>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.</t>
</list></t>
</section>
<section title="SIP Event Package" anchor="sec:dc:sm:event">
<t>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 changes in NOTIFY requests. This
approach has the following characteristics:</t>
<t><list style='symbols'>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>As overload feedback is sent to all senders in separate
messages, this mechanism is not suitable when frequent
overload control feedback is needed.</t>
<t>A SIP server can limit the set of senders that can
receive overload control information by authenticating
subscriptions to this event package.</t>
<t>This approach requires each proxy to implement user agent
functionality (UAS and UAC) to manage the subscriptions.</t>
</list></t>
</section>
</section>
<section title="Backwards Compatibility">
<t>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.</t>
<t>Hop-by-hop overload control (see
<xref target="RFC6357" />) has 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.</t>
<t>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.</t>
<t>A SIP server should therefore follow the behaviour outlined
in <xref target="sec:5xx"/> to handle clients that do not
support overload control.</t>
</section>
</section>
<section anchor="sec:security" title="Security Considerations">
<t>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.</t>
<t>To better understand the threat model, consider the following
diagram:</t>
<figure><artwork><![CDATA[
Pa ------- ------ Pb
\ /
: ------ +-------- P1 ------+------ :
/ L1 L2 \
: ------- ------ :
-----> Downstream (requests)
<----- Upstream (responses)
]]></artwork></figure>
<t>Here, requests travel downstream from the left-hand side, through Proxy
P1, towards the right-hand side, and responses travel upstream from the
right-hand side, through P1, towards the left hand side. Proxies Pa, Pb
and P1 support overload control. L1 and L2 are labels for the links
connecting P1 to the upstream clients and downstream servers.</t>
<t>If an attacker is able to modify traffic between Pa and P1 on link L1,
it can cause denial of service attack on P1 by having Pa not send
any traffic to P1. Such an attack can proceed by the attacker modifying
the response from P1 to Pa such that Pa's Via header is changed to
indicate that all requests destined towards P1 should be dropped.
Conversely, the attacker can simply remove any "oc", "oc-validity" and
"oc-seq" markings added by P1 in a response to Pa. In such a case, the
attacker will force P1 into overload control by denying request
quenching at Pa even though Pa is capable of performing overload
control.</t>
<t>Similarly, if an attacker is able to modify traffic between P1 and Pb
on link L2, it can change the Via header associated with P1 in
a response from Pb to P1 such that all subsequent requests destined
towards Pb from P1 are dropped. In essence, the attacker mounts a
denial of service attack on Pb by indicating false overload control.
Note that it is immaterial whether Pb supports overload control or not,
the attack will succeed as long as the attacker is able to control L2.
Conversely, an attacker can suppress a genuine overload condition at
Pb by simply remove any "oc", "oc-validity" and "oc-seq" markings added
by Pb in a response to P1. In such a case, the attacker will force
P1 into sending requests to Pb even under overload conditions
because P1 would not be aware aware that Pb supports overload control.</t>
<t>Attacks that indicate false overload control can be mitigated by using
TCP or Websockets <xref target="RFC6455"/>, or better yet, TLS in
conjunction with applying BCP 38 <xref target="RFC2827"/>. Attacks that
are mounted to suppress genuine overload conditions can be avoided by
using TLS on the connection.</t>
<t>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 header
(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
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.</t>
<t>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.</t>
<t><list>
<t>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.</t>
</list></t>
<t>To prevent such attacks, servers should monitor client behavior to
determine whether they are complying with overload control policies.
If a client is not conforming to such policies, then the server should
treat it as a non-supporting client
(see <xref target="sec:5xx"/>).</t>
<!-- Commented original as per AD comments and substituted current text.
See http://www.ietf.org/mail-archive/web/sip-overload/current/msg01024.html
<t>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.</t>
<t>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.</t>
<t>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 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.</t>
<t>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. </t>
<t><list>
<t>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.</t>
</list></t>
-->
</section> <!-- sec:security -->
<section anchor="sec:iana" title="IANA Considerations">
<t>This specification defines four new Via header parameters as
detailed below in the "Header Field Parameter and Parameter
Values" sub-registry as per the registry created by
<xref target="RFC3968"/>. The required information is:</t>
<figure><artwork>
Header Field Parameter Name Predefined Values Reference
__________________________________________________________
Via oc Yes RFCXXXX
Via oc-validity Yes RFCXXXX
Via oc-seq Yes RFCXXXX
Via oc-algo Yes RFCXXXX
RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC
number of this specification.]
</artwork></figure>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc3261;
&rfc3263;
&rfc3968;
&rfc4412;
</references>
<references title='Informative References'>
&rfc5390;
&rfc5031;
&rfc6357;
&rfc2827;
&rfc6455;
&i-d.ietf-soc-load-control-event-package;
&i-d.ietf-soc-overload-rate-control;
</references>
<section title="Acknowledgements">
<t>The authors acknowledge the contributions of Bruno Chatras, Keith Drage,
Janet Gunn, Rich Terpstra, Daryl Malas, Eric Noel, R. Parthasarathi,
Antoine Roly, Jonathan Rosenberg, Charles Shen, Rahul Srivastava, Padma
Valluri, Shaun Bharrat, Paul Kyzivat and Jeroen Van Bemmel to
this document.</t>
<t>Adam Roach and Eric McMurry helped flesh out the different
cases for handling SIP messages described in the algorithm of
<xref target="sec:default-loss-algo"/>. Janet Gunn reviewed the
algorithm and suggested changes that lead to simpler processing for
the case where "oc_value > cat1".</t>
<t>Richard Barnes provided invaluable comments as part of area
director review of the draft.</t>
</section>
<section title="RFC5390 requirements" anchor="rfc5390-reqs">
<t><xref target="table-rfc5390"/> provides a summary how this
specification fulfills the requirements of <xref target="RFC5390"/>.
A more detailed view on how each requirements is fulfilled is
provided after the table.</t>
<texttable anchor="table-rfc5390">
<ttcol align="left">Requirement</ttcol>
<ttcol align="left">Meets requirement</ttcol>
<c>REQ 1</c> <c>Yes</c>
<c>REQ 2</c> <c>Yes</c>
<c>REQ 3</c> <c>Partially</c>
<c>REQ 4</c> <c>Partially</c>
<c>REQ 5</c> <c>Partially</c>
<c>REQ 6</c> <c>Not applicable</c>
<c>REQ 7</c> <c>Yes</c>
<c>REQ 8</c> <c>Partially</c>
<c>REQ 9</c> <c>Yes</c>
<c>REQ 10</c> <c>Yes</c>
<c>REQ 11</c> <c>Yes</c>
<c>REQ 12</c> <c>Yes</c>
<c>REQ 13</c> <c>Yes</c>
<c>REQ 14</c> <c>Yes</c>
<c>REQ 15</c> <c>Yes</c>
<c>REQ 16</c> <c>Yes</c>
<c>REQ 17</c> <c>Partially</c>
<c>REQ 18</c> <c>Yes</c>
<c>REQ 19</c> <c>Yes</c>
<c>REQ 20</c> <c>Yes</c>
<c>REQ 21</c> <c>Yes</c>
<c>REQ 22</c> <c>Yes</c>
<c>REQ 23</c> <c>Yes</c>
<postamble>Summary of meeting requirements in RFC5390</postamble>
</texttable>
<t>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.</t>
<t>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.</t>
<t>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 outage.</t>
<t>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.</t>
<t>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.</t>
<t>Meeting REQ 3: Partially. On the server side, the overload
condition is determined monitoring S (c.f., Section 4 of
<xref target="RFC6357"/>) 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.</t>
<t>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.</t>
<t>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 will attempt to reduce traffic
destined towards the non-responsive server as outlined in
<xref target="sec:self-limiting"/>.</t>
<t>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.</t>
<t>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,
if such a channel is not available, then the security ramifications
outlined in <xref target="sec:security"/> apply.</t>
<t>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.</t>
<t>Meeting REQ 6: Not applicable. Overload control information is
signaled as part of the Via header and not in a new header.</t>
<t>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.</t>
<t>Meeting REQ 7: Yes, please see <xref target="oc-use"/> and
<xref target="sec:respond-overload"/>.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>Meeting REQ 9: Yes, a SIP client conformant to this specification
will send the request to a different element.</t>
<t>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.</t>
<t>Meeting REQ 10: Yes, there are no constraints on the number of
upstream clients.</t>
<t>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.</t>
<t>Meeting REQ 11: Yes, there are no constraints on the number of
upstream clients.</t>
<t>REQ 12: The mechanism should work between servers in different domains.</t>
<t>Meeting REQ 12: Yes, there are no inherent limitations on using
overload control between domains.</t>
<t>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 <xref target="RFC4412"/>) are given
preferential treatment, such as not being dropped, being given
additional retransmission, or being processed ahead of others.</t>
<t>Meeting REQ 13: Yes, please see <xref target="sec:respond-overload"/>.
</t>
<t>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.</t>
<t>Meeting REQ 14: Yes, <xref target="sec:self-limiting"/>
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.</t>
<t>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.</t>
<t>Meeting REQ 15: Yes, <xref target="sec:self-limiting"/>
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.</t>
<t>REQ 16: The mechanism should attempt to minimize the overhead of
the overload control messaging.</t>
<t>Meeting REQ 16: Yes, overload control messages are sent in the
topmost Via header, which is always processed by the SIP elements.</t>
<t>REQ 17: The overload mechanism must not provide an avenue for
malicious attack, including DoS and DDoS attacks.</t>
<t>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 <xref target="sec:security"/> apply.</t>
<t>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.</t>
<t>Meeting REQ 18: Yes, please see discussion in <xref target="oc-use"/>.</t>
<t>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.</t>
<t>Meeting REQ 19: Yes, please see <xref target="sec:respond-overload"/>.</t>
<t>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.</t>
<t>Meeting REQ 20: Yes, an element that does not implement overload
control does not receive any measure of extra benefit.</t>
<t>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.</t>
<t>Meeting REQ 21: Yes, the overload control mechanism described in
this draft ensures the stability of the system.</t>
<t>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 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.</t>
<t>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.</t>
<t>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.</t>
<t>Meeting REQ 23: Yes. Depending on the type of load balancer,
this requirement is met. A load balancer fronting
a farm of SIP proxies could be a SIP-aware load balancer or one that
is not SIP-aware. If the load balancer is SIP-aware, it can make
conscious decisions on throttling outgoing traffic towards the
individual server in the farm based on the overload control parameters
returned by the server. On the other hand, if the load balancer is
not SIP-aware, then there are other strategies to perform overload
control. Section 6 of <xref target="RFC6357"/>
documents some of these strategies in more detail (see discussion related
to Figure 3(a) in Section 6).</t>
<!--
For list discussion on this, see
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00531.html
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00533.html
-->
</section> <!-- rfc5390-reqs -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:18:26 |