Internet Engineering Task Force (IETF)                           E. Noel
Request for Comments: 7415                                     AT&T Labs
Category: Standards Track                                    P. Williams
ISSN: 2070-1721                                     BT Innovate & Design
                                                           February 2015

Session Initiation Protocol (SIP) Rate Control




The prevalent use of the Session Initiation Protocol (SIP) in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. A loss-based solution to remedy known vulnerabilities of the SIP 503 (Service Unavailable) overload control mechanism has already been proposed. Using the same signaling, this document proposes a rate-based control scheme to complement the loss-based control scheme.

次世代ネットワークでのセッション開始プロトコル(SIP)の普及には、SIPネットワークが適切な制御メカニズムを提供し、トラフィックの過負荷時の輻輳の崩壊を防ぐことでトランザクションのスループットを維持する必要があります。 SIP 503(Service Unavailable)過負荷制御メカニズムの既知の脆弱性を改善するための損失ベースのソリューションは、すでに提案されています。同じシグナリングを使用して、このドキュメントは損失ベースの制御方式を補足するためにレートベースの制御方式を提案します。

Status of This Memo


This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect 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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents


   1. Introduction ....................................................2
   2. Terminology .....................................................3
   3. Rate-Based Algorithm Scheme .....................................3
      3.1. Overview ...................................................3
      3.2. Via Header Field Parameters for Overload Control ...........4
      3.3. Client and Server Rate-Based Control Algorithm Selection ...4
      3.4. Server Operation ...........................................5
      3.5. Client Operation ...........................................6
           3.5.1. Default Algorithm ...................................6
           3.5.2. Priority Treatment ..................................9
           3.5.3. Optional Enhancement: Avoidance of Resonance .......10
   4. Example ........................................................12
   5. Syntax .........................................................13
   6. Security Considerations ........................................13
   7. IANA Considerations ............................................13
   8. References .....................................................14
      8.1. Normative References ......................................14
      8.2. Informative References ....................................14
   Acknowledgments ...................................................14
   Contributors ......................................................14
   Authors' Addresses ................................................15
1. Introduction
1. はじめに

The use of SIP [RFC3261] in large-scale Next Generation Networks requires that SIP-based networks provide adequate control mechanisms for handling traffic growth. In particular, SIP networks must be able to handle traffic overloads gracefully, maintaining transaction throughput by preventing congestion collapse.

大規模な次世代ネットワークでSIP [RFC3261]を使用するには、SIPベースのネットワークがトラフィックの増加を処理するための適切な制御メカニズムを提供する必要があります。特に、SIPネットワークは、輻輳の崩壊を防ぐことでトランザクションのスループットを維持しながら、トラフィックの過負荷を適切に処理できる必要があります。

A promising SIP-based overload control solution has been proposed in [RFC7339]. That solution provides a communication scheme for overload control algorithms. It also includes a default loss-based overload control algorithm that makes it possible for a set of clients to limit offered load towards an overloaded server. However, such a loss control algorithm is sensitive to variations in load so that any increase in load would be directly reflected by the clients in the offered load presented to the overloaded servers. More importantly, a loss-based control scheme cannot guarantee an upper bound on the load from the clients towards an overloaded server and requires frequent updates that may have implications for stability.


In accordance with the framework defined in [RFC7339], this document proposes an alternate overload control scheme: the rate-based overload control scheme. The rate-based control algorithm guarantees an upper bound on the rate, constant between server updates, of requests sent by clients towards an overloaded server. The trade-off is in terms of algorithmic complexity, since the overloaded server is more likely to use a different target (maximum rate) for each client than the loss-based approach.


The proposed rate-based overload control algorithm mitigates congestion in SIP networks while adhering to the overload signaling scheme in [RFC7339] and presenting a rate-based control scheme as an optional alternative to the default loss-based control scheme in [RFC7339].


2. Terminology
2. 用語

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 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

Unless otherwise specified, all SIP entities described in this document are assumed to support this specification.


3. Rate-Based Algorithm Scheme
3. レートベースのアルゴリズムスキーム
3.1. Overview
3.1. 概観

The server is the one protected by the overload control algorithm defined here, and the client is the one that throttles traffic towards the server.


Following the procedures defined in [RFC7339], the server and clients signal one another support for rate-based overload control.


Then, periodically, the server relies on internal measurements (e.g., CPU utilization or queueing delay) to evaluate its overload state and estimate a target maximum SIP request rate in number of requests per second (as opposed to target percent loss in the case of loss-based control).


When in overload, the server uses the "oc" parameter in the Via header field [RFC7339] of SIP responses in order to inform clients of its overload state and of the target maximum SIP request rate for that client.


Upon receiving the "oc" parameter with a target maximum SIP request rate, each client throttles new SIP requests towards the overloaded server.


3.2. Via Header Field Parameters for Overload Control
3.2. オーバーロード制御のヘッダーフィールドパラメーターを介して

Four Via header parameters are defined in [RFC7339] and are summarized below:


o oc: Used by clients in SIP requests to indicate support for overload control per [RFC7339] and by servers to indicate the load reduction amount in the loss-based algorithm and the maximum rate, in messages per second, for the rate-based algorithm described here.

o oc:SIPリクエストでクライアントが[RFC7339]による過負荷制御のサポートを示すために使用し、サーバーが損失ベースのアルゴリズムでの負荷削減量と1秒あたりのメッセージ数で説明したレートベースのアルゴリズムの最大レートを示すために使用ここに。

o oc-algo: Used by clients in SIP requests to advertise supported overload control algorithms and by servers to notify clients of the algorithm in effect. Supported values are loss (default) and rate (optional).

o oc-algo:サポートされている過負荷制御アルゴリズムをアドバタイズするためにSIP要求でクライアントによって使用され、有効なアルゴリズムをクライアントに通知するためにサーバーによって使用されます。サポートされる値は、損失(デフォルト)とレート(オプション)です。

o oc-validity: Used by servers in SIP responses to indicate an interval of time (in milliseconds) that the load reduction should be in effect. A value of 0 is reserved for the server to stop overload control. A non-zero value is required in all other cases.

o oc-validity:サーバーがSIP応答で使用して、負荷削減を有効にする時間間隔(ミリ秒単位)を示します。値0は、サーバーが過負荷制御を停止するために予約されています。他のすべての場合には、ゼロ以外の値が必要です。

o oc-seq: A sequence number associated with the "oc" parameter.

o oc-seq:「oc」パラメーターに関連付けられたシーケンス番号。

Consult Section 4 for an illustration of the usage of the "oc" parameter in the Via header field.


3.3. Client and Server Rate-Based Control Algorithm Selection
3.3. クライアントとサーバーのレートベースの制御アルゴリズムの選択

Per [RFC7339], new clients indicate supported overload control algorithms to servers by inserting "oc" and "oc-algo", with the names of the supported algorithms, in the Via header field of SIP requests destined to servers. The inclusion by the client of the token "rate" indicates that the client supports a rate-based algorithm. Conversely, servers notify clients of the selected overload control algorithm through the "oc-algo" parameter in the Via header field of SIP responses to clients. The inclusion by the server of the token "rate" in the "oc-algo" parameter indicates that the rate-based algorithm has been selected by the server.


Support of rate-based control MUST be indicated by clients including the token "rate" in the "oc-algo" list. Selection of rate-based control MUST be indicated by servers by setting "oc-algo" to the token "rate".


3.4. Server Operation
3.4. サーバー操作

The actual algorithm used by the server to determine its overload state and estimate a target maximum SIP request rate is beyond the scope of this document.


However, the server MUST periodically evaluate its overload state and estimate a target SIP request rate beyond which it would become overloaded. The server must determine how it will allocate the target SIP request rate among its client. The server may set the same rate for every client or may set different rates for different clients.


The maximum rate determined by the server for a client applies to the entire stream of SIP requests, even though throttling may only affect a particular subset of the requests, since as per [RFC7339] and REQ 13 of [RFC5390], request prioritization is a client's responsibility.

[RFC7339]と[RFC5390]のREQ 13によると、要求の優先順位付けはaであるため、スロットリングは要求の特定のサブセットにのみ影響を与える可能性がありますクライアントの責任。

When setting the maximum rate for a particular client, the server may need to take into account the workload (e.g., CPU load per request) of the distribution of message types from that client. Furthermore, because the client may prioritize the specific types of messages it sends while under overload restriction, this distribution of message types may be different from the message distribution for that client under non-overload conditions (e.g., it could have either higher or lower CPU load).


Note that the "oc" parameter for the rate-based algorithm is an upper bound (in messages per second) on the traffic sent by the client to the server. The client may send traffic at a rate significantly lower than the upper bound for a variety of reasons.


In other words, when multiple clients are being controlled by an overloaded server, at any given time, some clients may receive requests at a rate below their target (maximum) SIP request rate while others above that target rate. But the resulting request rate presented to the overloaded server will converge towards the target SIP request rate.


Upon detection of overload and the determination to invoke overload controls, the server MUST follow the specifications in [RFC7339] to notify its clients of the allocated target SIP request rate and to notify them that rate-based control is in effect.


The server MUST use the "oc" parameter defined in [RFC7339] to send a target SIP request rate to each of its clients.

サーバーは、[RFC7339]で定義されている "oc"パラメータを使用して、ターゲットのSIPリクエストレートを各クライアントに送信する必要があります。

When a client supports the default loss-based algorithm and not the rate-based algorithm, the client would be handled in the same way as in Section 5.10.2 of [RFC7339].


3.5. Client Operation
3.5. クライアントの操作
3.5.1. Default Algorithm
3.5.1. デフォルトのアルゴリズム

In determining whether or not to transmit a specific message, the client may use any algorithm that limits the message rate to the "oc" parameter in units of messages per second. For ease of discussion, we define T = 1/["oc" parameter] as the target inter-SIP request interval. The algorithm may be strictly deterministic, or it may be probabilistic. It may, or may not, have a tolerance factor to allow for short bursts, as long as the long-term rate remains below 1/T.

特定のメッセージを送信するかどうかを決定する際に、クライアントは、メッセージレートを「oc」パラメータに制限する任意のアルゴリズムを1秒あたりのメッセージ数の単位で使用できます。説明を簡単にするために、T = 1 / ["oc"パラメータ]をターゲットのSIPリクエスト間隔として定義します。アルゴリズムは厳密に決定論的でも、確率論的でもかまいません。長期的なレートが1 / T未満である限り、短いバーストを許容する許容係数がある場合とない場合があります。

The algorithm may have provisions for prioritizing traffic in accordance with REQ 13 of [RFC5390].

アルゴリズムは、[RFC5390]のREQ 13に従ってトラフィックに優先順位を付けるための規定を持っているかもしれません。

If the algorithm requires other parameters (in addition to "T", which is 1/["oc" parameter]), they may be set autonomously by the client, or they may be negotiated between client and server independently of the SIP-based overload control solution.

アルゴリズムが他のパラメーターを必要とする場合(1 / ["oc"パラメーター]である "T"に加えて)、それらはクライアントによって自律的に設定されるか、またはSIPベースのクライアントとは独立してクライアントとサーバー間でネゴシエートされます。過負荷制御ソリューション。

In either case, the coordination is out of the scope of this document. The default algorithms presented here (one with and one without provisions for prioritizing traffic) are only examples.


To throttle new SIP requests at the rate specified by the "oc" parameter sent by the server to its clients, the client MAY use the proposed default algorithm for rate-based control or any other equivalent algorithm that forward messages in conformance with the upper bound of 1/T messages per second.

サーバーがクライアントに送信する「oc」パラメータで指定されたレートで新しいSIPリクエストを抑制するために、クライアントは、レートベースの制御用に提案されたデフォルトアルゴリズム、または上限に準拠してメッセージを転送するその他の同等のアルゴリズムを使用してもよい(MAY) 1 / Tメッセージ/秒。

The default leaky bucket algorithm presented here is based on [ITU-T-I.371], Appendix A.2. The algorithm makes it possible for clients to deliver SIP requests at a rate specified by the "oc" parameter with the tolerance parameter TAU (preferably configurable).


Conceptually, the leaky bucket algorithm can be viewed as a finite capacity bucket whose real-valued content drains out at a continuous rate of 1 unit of content per time unit and whose content increases by the increment T for each forwarded SIP request. T is computed as the inverse of the rate specified by the "oc" parameter, namely T = 1 / ["oc" parameter].

概念的には、リーキーバケットアルゴリズムは、実数値のコンテンツが時間単位あたり1ユニットのコンテンツの連続レートで排出され、転送されるSIPリクエストごとにTの増分でコンテンツが増加する有限容量バケットと見なすことができます。 Tは、「oc」パラメーターで指定されたレートの逆数、つまりT = 1 / [「oc」パラメーター]として計算されます。

Note that when the "oc" parameter is 0 with a non-zero "oc-validity", then the client should reject 100% of SIP requests destined to the overload server. However, when the "oc-validity" value is 0, the client should immediately stop throttling.


If, at a new SIP request arrival, the content of the bucket is less than or equal to the limit value TAU, then the SIP request is forwarded to the server; otherwise, the SIP request is rejected.


Note that the capacity of the bucket (the upper bound of the counter) is (T + TAU).

バケットの容量(カウンターの上限)は(T + TAU)であることに注意してください。

The tolerance parameter TAU determines how close the long-term admitted rate is to an ideal control that would admit all SIP requests for arrival rates less than 1/T and then admit SIP requests precisely at the rate of 1/T for arrival rates above 1/T. In particular, at mean arrival rates close to 1/T, it determines the tolerance to deviation of the inter-arrival time from T (the larger TAU, the more tolerance to deviations from the inter-departure interval T).

許容パラメータTAUは、長期許可レートが、1 / T未満の到着レートのすべてのSIPリクエストを許可し、1を超える到着レートの場合、1 / TのレートでSIPリクエストを正確に許可する理想的な制御にどれだけ近いかを決定します/ T。特に、1 / Tに近い平均到着率では、Tからの到着間時間の偏差に対する許容範囲が決定されます(TAUが大きいほど、出発間隔Tからの偏差に対する許容範囲が大きくなります)。

This deviation from the inter-departure interval influences the admitted rate burstiness or the number of consecutive SIP requests forwarded to the server (burst size proportional to TAU over the difference between 1/T and the arrival rate).

出発間隔からのこの逸脱は、許容レートのバースト性またはサーバーに転送される連続したSIP要求の数(1 / Tと到着レートの差のTAUに比例するバーストサイズ)に影響します。

In situations where clients are configured with some knowledge about the server (e.g., operator pre-provisioning), it can be beneficial to choose a value of TAU based on how many clients will be sending requests to the server.


Servers with a very large number of clients, each with a relatively small arrival rate, will generally benefit from a smaller value for TAU in order to limit queuing (and hence response times) at the server when subjected to a sudden surge of traffic from all clients. Conversely, a server with a relatively small number of clients, each with a proportionally larger arrival rate, will benefit from a larger value of TAU.


Once the control has been activated, at the arrival time of the k-th new SIP request, ta(k), the content of the bucket is provisionally updated to the value


   X' = X - (ta(k) - LCT)

where X is the value of the leaky bucket counter after arrival of the last forwarded SIP request, and LCT is the time at which the last SIP request was forwarded.


If X' is less than or equal to the limit value TAU, then the new SIP request is forwarded, the leaky bucket counter X is set to X' (or to 0 if X' is negative) plus the increment T, and LCT is set to the current time ta(k). If X' is greater than the limit value TAU, then the new SIP request is rejected, and the values of X and LCT are unchanged.

X 'が制限値TAU以下の場合、新しいSIP要求が転送され、リーキーバケットカウンターXはX'(またはX 'が負の場合は0)に増分Tを加えた値に設定され、LCTは現在時刻ta(k)に設定します。 X 'が制限値TAUより大きい場合、新しいSIP要求は拒否され、XとLCTの値は変更されません。

When the first response from the server has been received indicating control activation (oc-validity>0), LCT is set to the time of activation, and the leaky bucket counter is initialized to the parameter TAU0 (preferably configurable), which is 0 or larger but less than or equal to TAU.

サーバーからの最初の応答が受信され、制御のアクティブ化が示されると(oc-validity> 0)、LCTはアクティブ化の時間に設定され、リーキーバケットカウンターは0またはTAUより大きいがTAU以下。

TAU can assume any positive real number value and is not necessarily bounded by T.


TAU=4*T is a reasonable compromise between burst size and throttled rate adaptation at low offered rates.

TAU = 4 * Tは、バーストサイズと、低オファーレートでのスロットルレートアダプテーション間の妥当な妥協点です。

Note that specification of a value for TAU and any communication or coordination between servers are beyond the scope of this document.


A reference algorithm is shown below.


No priority case:

の pりおりty かせ:

   // T: inter-transmission interval, set to 1 / ["oc" parameter]
   // TAU: tolerance parameter
   // ta: arrival time of the most recent arrival received by the
   //     client
   // LCT: arrival time of last SIP request that was sent to the server
   //      (initialized to the first arrival time)
   // X: current value of the leaky bucket counter (initialized to
   //    TAU0)
   // After most recent arrival, calculate auxiliary variable Xp
   Xp = X - (ta - LCT);
   if (Xp <= TAU) {
     // Transmit SIP request
     // Update X and LCT
     X = max (0, Xp) + T;
     LCT = ta;
   } else {
     // Reject SIP request
     // Do not update X and LCT
3.5.2. Priority Treatment
3.5.2. 優先治療

As with the loss-based algorithm in [RFC7339], a client implementing the rate-based algorithm also prioritizes messages into two or more categories of requests, for example, requests that are candidates for reduction and requests that are not subject to reduction (except under extenuating circumstances when there aren't any messages in the first category that can be reduced).


Accordingly, the proposed leaky bucket implementation is modified to support priority using two thresholds for SIP requests that are candidates for reduction. With two priorities, the proposed leaky bucket requires two thresholds: TAU1 and TAU2 (where TAU1 < TAU2):

したがって、提案されたリーキーバケットの実装は、削減の候補であるSIP要求の2つのしきい値を使用して優先度をサポートするように変更されます。 2つの優先度で、提案されたリーキーバケットには2つのしきい値が必要です。TAU1およびTAU2(TAU1 <TAU2):

o All new requests would be admitted when the leaky bucket counter is at or below TAU1.

o すべての新しい要求は、リーキーバケットカウンタがTAU1以下になると許可されます。

o Only higher-priority requests would be admitted when the leaky bucket counter is between TAU1 and TAU2.

o リーキーバケットカウンタがTAU1とTAU2の間にある場合、優先度の高い要求のみが許可されます。

o All requests would be rejected when the bucket counter is at or above TAU2.

o バケットカウンターがTAU2以上になると、すべての要求が拒否されます。

This can be generalized to n priorities using n thresholds for n>2 in the obvious way.

これは、明らかな方法でn> 2のn個のしきい値を使用して、n個の優先度に一般化できます。

With a priority scheme that relies on two tolerance parameters (TAU2 influences the priority traffic, and TAU1 influences the non-priority traffic), always set TAU1 < TAU2 (TAU is replaced by TAU1 and TAU2). Setting both tolerance parameters to the same value is equivalent to having no priority. TAU1 influences the admitted rate the same way as TAU does when no priority is set. The larger the difference between TAU1 and TAU2, the closer the control is to strict priority queueing.

2つの許容パラメータに依存する優先順位スキーム(TAU2は優先トラフィックに影響を及ぼし、TAU1は非優先トラフィックに影響を与える)では、常にTAU1 <TAU2に設定します(TAUはTAU1とTAU2に置き換えられます)。両方の許容パラメータを同じ値に設定することは、優先度がないことと同じです。 TAU1は、優先度が設定されていない場合のTAUと同じ方法で許容レートに影響します。 TAU1とTAU2の差が大きいほど、厳密な優先キューイングに制御が近づきます。

TAU1 and TAU2 can assume any positive real number value and are not necessarily bounded by T.


Reasonable values for TAU0, TAU1, and TAU2 are:


o TAU0 = 0,

o TAU0 = 0、

o TAU1 = 1/2 * TAU2, and

o TAU1 = 1/2 * TAU2、および

o TAU2 = 10 * T.

o TAU2 = 10 *T。

Note that specification of a value for TAU1 and TAU2 and any communication or coordination between servers are beyond the scope of this document.


A reference algorithm is shown below.


Priority case:


   // T: inter-transmission interval, set to 1 / ["oc" parameter]
   // TAU1: tolerance parameter of no-priority SIP requests
   // TAU2: tolerance parameter of priority SIP requests
   // ta: arrival time of the most recent arrival received by the
   //     client
   // LCT: arrival time of last SIP request that was sent to the server
   //      (initialized to the first arrival time)
   // X: current value of the leaky bucket counter (initialized to
   //    TAU0)
   // After most recent arrival, calculate auxiliary variable Xp
   Xp = X - (ta - LCT);
   if (AnyRequestReceived && Xp <= TAU1) || (PriorityRequestReceived &&
   Xp <= TAU2 && Xp > TAU1) {
     // Transmit SIP request
     // Update X and LCT
     X = max (0, Xp) + T;
     LCT = ta;
   } else {
     // Reject SIP request
     // Do not update X and LCT
3.5.3. Optional Enhancement: Avoidance of Resonance
3.5.3. オプションの拡張:共振の回避

As the number of client sources of traffic increases or the throughput of the server decreases, the maximum rate admitted by each client needs to decrease; therefore, the value of T becomes larger. Under some circumstances (e.g., if the traffic arises very quickly simultaneously at many sources), the occupancies of each bucket can become synchronized, resulting in the admissions from each source being close in time and batched or having very 'peaky' arrivals at the server, which gives rise not only to control instability but also to very poor delays and even lost messages. An appropriate term for this is 'resonance' [Erramilli].

クライアントのトラフィックソースの数が増えるか、サーバーのスループットが低下するにつれて、各クライアントが許可する最大レートを下げる必要があります。したがって、Tの値は大きくなります。状況によっては(たとえば、トラフィックが多くのソースで同時に非常に速く発生する場合)、各バケットの占有率が同期され、各ソースからのアドミッションが時間的に近くなり、バッチ処理されるか、サーバーに非常に「ピーク」の到着が発生します。 、これは不安定性を制御するだけでなく、非常に貧弱な遅延やメッセージの損失さえも引き起こします。これに適切な用語は「共鳴」です[エラミリ]。

If the network topology is such that resonance can occur, then a simple way to avoid resonance is to randomize the bucket occupancy at two appropriate points -- at the activation of control and whenever the bucket empties -- as described below.


After updating the value of the leaky bucket to X', generate a value u as follows:

リーキーバケットの値をX 'に更新した後、次のように値uを生成します。

if X' > 0, then u = 0

X '> 0の場合、u = 0

     else if X' <= 0, then let u be set to a random value uniformly
                      distributed between -1/2 and +1/2

Then, only if the arrival is admitted, increase the bucket by an amount T + uT, which will therefore be just T if the bucket hadn't emptied or lie between T/2 and 3T/2 if it had.

次に、到着が許可された場合にのみ、バケットをT + uTだけ増やします。したがって、バケットが空でなかった場合、またはT / 2と3T / 2の間にあった場合は、Tになります。

This randomization should also be done when control is activated, i.e., instead of simply initializing the leaky bucket counter to TAU0, initialize it to TAU0 + uT, where u is uniformly distributed as above. Since activation would have been a result of response to a request sent by the client, the second term in this expression can be interpreted as being the bucket increment following that admission.

このランダム化は、制御がアクティブになったときにも実行する必要があります。つまり、単にリーキーバケットカウンターをTAU0に初期化する代わりに、TAU0 + uTに初期化します。ここで、uは上記のように均一に分散されます。アクティブ化はクライアントから送信されたリクエストへの応答の結果であったため、この式の2番目の用語は、そのアドミッションに続くバケットの増分であると解釈できます。

This method has the following characteristics:


o If TAU0 is chosen to be equal to TAU and all sources activate control at the same time due to an extremely high request rate, then the time until the first request admitted by each client would be uniformly distributed over [0,T].

o TAU0がTAUと等しくなるように選択され、要求レートが非常に高いためにすべてのソースが同時に制御をアクティブ化する場合、各クライアントによって許可された最初の要求までの時間は[0、T]に均一に分散されます。

o The maximum occupancy is TAU + (3/2)T, rather than TAU + T without randomization.

o 最大占有率は、ランダム化なしのTAU + Tではなく、TAU +(3/2)Tです。

o For the special case of 'classic gapping' where TAU=0, then the minimum time between admissions is uniformly distributed over [T/2, 3T/2], and the mean time between admissions is the same, i.e., T+1/R where R is the request arrival rate.

o 「クラシックギャッピング」の特別なケースで、TAU = 0の場合、入院間の最小時間は[T / 2、3T / 2]に均一に分散され、入院間の平均時間は同じ、つまりT + 1 / R Rは要求到着率です。

o As high load randomization rarely occurs, there is no loss of precision of the admitted rate, even though the randomized 'phasing' of the buckets remains.

o 高負荷のランダム化はめったに発生しないので、バケットのランダム化された「フェーズ」が残っていても、許容レートの精度が失われることはありません。

4. Example
4. 例

The example in this section adapts the example in Section 6 of [RFC7339], where client P1 sends requests to a downstream server P2:


            INVITE SIP/2.0
            Via: SIP/2.0/TLS;


oc; oc-algo = "loss、rate"



SIP/2.0 100 Trying

SIP / 2.0 100試行

            Via: SIP/2.0/TLS;


oc-seq = 1282321615.781



The first message above is sent by P1 to P2. This message is a SIP request; because P1 supports overload control, it inserts the "oc" parameter in the topmost Via header field that it created. P1 supports two overload control algorithms: loss and rate.

上記の最初のメッセージは、P1からP2に送信されます。このメッセージはSIP要求です。 P1はオーバーロード制御をサポートしているため、作成した最上位のViaヘッダーフィールドに「oc」パラメーターを挿入します。 P1は、損失とレートの2つの過負荷制御アルゴリズムをサポートしています。

The second message, a SIP response, shows the topmost Via header field amended by P2 according to this specification and sent to P1. Because P2 also supports overload control, it chooses the rate-based scheme and sends that back to P1 in the "oc-algo" parameter. It uses oc-validity=0 to indicate no overload control. In this example, "oc=0", but "oc" could be any value as "oc" is ignored when "oc-validity=0".

2番目のメッセージであるSIP応答は、この仕様に従ってP2によって修正され、P1に送信された最上位のViaヘッダーフィールドを示しています。 P2は過負荷制御もサポートしているため、レートベースのスキームを選択し、それを「oc-algo」パラメーターでP1に送り返します。 oc-validity = 0を使用して、過負荷制御がないことを示します。この例では、「oc = 0」ですが、「oc-validity = 0」の場合、「oc」は無視されるため、「oc」は任意の値にすることができます。

At some later time, P2 starts to experience overload. It sends the following SIP message indicating P1 should send SIP requests at a rate no greater than or equal to 150 SIP requests per second and for a duration of 1,000 milliseconds.

しばらくすると、P2に過負荷が発生し始めます。次のSIPメッセージを送信して、P1が1秒あたり150 SIPリクエスト以下のレートで、1,000ミリ秒の間SIPリクエストを送信する必要があることを示します。

SIP/2.0 180 Ringing

SIP / 2.0 180リンギング

            Via: SIP/2.0/TLS;


oc-seq = 1282321615.782



5. Syntax
5. 構文

This specification extends the existing definition of the Via header field parameters of [RFC7339] as follows:


algo-list =/ "rate"

何かリスト= / "レート"

6. Security Considerations
6. セキュリティに関する考慮事項

Aside from the resonance concerns discussed in Section 3.5.3, this mechanism does not introduce any security concerns beyond the general overload control security issues discussed in [RFC7339]. Methods to mitigate the risk of resonance are discussed in Section 3.5.3.


7. IANA Considerations
7. IANAに関する考慮事項

IANA has registered the "oc-algo" parameter of the Via header field in the "Header Field Parameters and Parameter Values" subregistry of the "Session Initiation Protocol (SIP) Parameters" registry. The entry appears as follows:

IANAは、「Session Initiation Protocol(SIP)Parameters」レジストリの「Header Field Parameters and Parameter Values」サブレジストリに、Viaヘッダーフィールドの「oc-algo」パラメーターを登録しました。エントリは次のように表示されます。

   Header     Parameter     Predefined     References
   Field      Name          Values

Via oc-algo Yes [RFC7339] [RFC7415]

oc-algo経由[はい] [RFC7339] [RFC7415]

8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<>。

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

[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP:Session Initiation Protocol」 、RFC 3261、2002年6月、<>。

[RFC5390] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", RFC 5390, December 2008, <>.

[RFC5390] Rosenberg、J。、「Session Initiation Protocolにおける過負荷の管理の要件」、RFC 5390、2008年12月、<>。

[RFC7339] Gurbani, V., Ed., Hilt, V., and H. Schulzrinne, "Session Initiation Protocol (SIP) Overload Control", RFC 7339, September 2014, <>.

[RFC7339] Gurbani、V.、Ed。、Hilt、V。、およびH. Schulzrinne、「Session Initiation Protocol(SIP)Overload Control」、RFC 7339、2014年9月、< / info / rfc7339>。

8.2. Informative References
8.2. 参考引用

[ITU-T-I.371] ITU-T, "Traffic control and congestion control in B-ISDN", ITU-T Recommendation I.371, March 2004.

[ITU-T-I.371] ITU-T、「B-ISDNのトラフィック制御と輻輳制御」、ITU-T勧告I.371、2004年3月。

[Erramilli] Erramilli, A., and L. Forys, "Traffic Synchronization Effects In Teletraffic Systems", ITC-13, 1991.

[Erramilli] Erramilli、A。、およびL. Forys、「テレトラフィックシステムにおけるトラフィック同期効果」、ITC-13、1991。



Many thanks to the following individuals for comments and feedback on this document: Richard Barnes, Keith Drage, Vijay Gurbany, Volker Hilt, Christer Holmberg, Winston Hong, Peter Yee, and James Yu.

このドキュメントに関するコメントとフィードバックを提供してくれたRichard Barnes、Keith Drage、Vijay Gurbany、Volker Hilt、Christer Holmberg、Winston Hong、Peter Yee、James Yuに感謝します。



Significant contributions to this document were made by Janet Gunn.


Authors' Addresses


Eric Noel AT&T Labs 200 S Laurel Avenue Middletown, NJ 07747 United States

Eric Noel AT&T Labs 200 S Laurel Avenue Middletown、NJ 07747アメリカ


Philip M. Williams BT Innovate & Design Ipswich, IP5 3RE United Kingdom

フィリップM.ウィリアムズBTイノベーション&デザインイプスウィッチ、IP5 3REイギリス