[要約] RFC 7415は、SIPセッションのレート制御に関する標準仕様です。その目的は、SIPネットワークでのトラフィック制御を改善し、サービス品質を向上させることです。
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
セッション開始プロトコル（SIP）レート制御
Abstract
概要
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 http://www.rfc-editor.org/info/rfc7415.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7415で入手できます。
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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect 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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、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
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.
有望なSIPベースの過負荷制御ソリューションが[RFC7339]で提案されています。そのソリューションは、過負荷制御アルゴリズムの通信方式を提供します。また、デフォルトの損失ベースの過負荷制御アルゴリズムも含まれています。これにより、クライアントのセットは、過負荷のサーバーに対して提供される負荷を制限できます。ただし、このような損失制御アルゴリズムは負荷の変動に敏感であるため、負荷の増加は、過負荷のサーバーに提示される提供された負荷のクライアントによって直接反映されます。さらに重要なことに、損失ベースの制御スキームでは、クライアントから過負荷のサーバーへの負荷の上限を保証できず、安定性に影響する可能性のある頻繁な更新が必要です。
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.
[RFC7339]で定義されたフレームワークに従って、このドキュメントは、代替の過負荷制御方式、つまりレートベースの過負荷制御方式を提案します。レートベースの制御アルゴリズムは、クライアントが過負荷のサーバーに送信するリクエストの、サーバーの更新間で一定のレートの上限を保証します。過負荷状態のサーバーは、損失ベースのアプローチよりもクライアントごとに異なるターゲット（最大レート）を使用する可能性が高いため、トレードオフはアルゴリズムの複雑さに関するものです。
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].
提案されたレートベースの過負荷制御アルゴリズムは、[RFC7339]の過負荷シグナリングスキームに準拠し、[RFC7339]のデフォルトの損失ベースの制御スキームのオプションの代替としてレートベースの制御スキームを提示しながら、SIPネットワークの輻輳を緩和します。
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.
特に明記されていない限り、このドキュメントで説明されているすべてのSIPエンティティは、この仕様をサポートしていると見なされます。
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.
[RFC7339]で定義されている手順に従って、サーバーとクライアントは、レートベースの過負荷制御のサポートを互いに通知します。
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).
次に、サーバーは定期的に内部測定値（CPU使用率やキューイング遅延など）に依存してその過負荷状態を評価し、1秒あたりのリクエスト数でターゲット最大SIPリクエストレートを推定します（損失の場合のターゲットパーセント損失とは対照的）ベースの制御）。
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.
過負荷の場合、サーバーはSIP応答のViaヘッダーフィールド[RFC7339]の「oc」パラメーターを使用して、クライアントにその過負荷状態とそのクライアントの目標最大SIPリクエストレートを通知します。
Upon receiving the "oc" parameter with a target maximum SIP request rate, each client throttles new SIP requests towards the overloaded server.
ターゲットの最大SIPリクエストレートで「oc」パラメータを受信すると、各クライアントは、過負荷のサーバーに向けて新しいSIPリクエストを抑制します。
Four Via header parameters are defined in [RFC7339] and are summarized below:
[RFC7339]には4つのViaヘッダーパラメータが定義されており、以下に要約されています。
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.
Viaヘッダーフィールドでの「oc」パラメーターの使用例については、セクション4を参照してください。
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.
[RFC7339]に従い、新しいクライアントは、サーバー宛のSIPリクエストのViaヘッダーフィールドに、サポートされているアルゴリズムの名前とともに「oc」および「oc-algo」を挿入することにより、サポートされている過負荷制御アルゴリズムをサーバーに示します。クライアントによるトークン「レート」の包含は、クライアントがレートベースのアルゴリズムをサポートすることを示します。逆に、サーバーは、クライアントへのSIP応答のViaヘッダーフィールドの「oc-algo」パラメーターを介して、選択した過負荷制御アルゴリズムをクライアントに通知します。サーバーが「oc-algo」パラメーターにトークン「rate」を含めることは、レートベースのアルゴリズムがサーバーによって選択されたことを示します。
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".
レートベースの制御のサポートは、「oc-algo」リストにトークン「rate」を含めて、クライアントが示す必要があります。レートベースの制御の選択は、「oc-algo」をトークン「レート」に設定することにより、サーバーによって示される必要があります。
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.
サーバーが過負荷状態を判断し、ターゲットの最大SIPリクエストレートを推定するために使用する実際のアルゴリズムは、このドキュメントの範囲外です。
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.
ただし、サーバーは定期的にその過負荷状態を評価し、それを超えると過負荷になる目標SIP要求レートを推定する必要があります。サーバーは、クライアント間でターゲットSIPリクエストレートを割り当てる方法を決定する必要があります。サーバーは、すべてのクライアントに同じレートを設定することも、クライアントごとに異なるレートを設定することもできます。
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).
特定のクライアントの最大レートを設定する場合、サーバーは、そのクライアントからのメッセージタイプの分散のワークロード（リクエストごとのCPU負荷など）を考慮する必要がある場合があります。さらに、クライアントは過負荷制限下で送信する特定のタイプのメッセージに優先順位を付ける可能性があるため、このメッセージタイプの分布は、非過負荷状態でのそのクライアントのメッセージ分布とは異なる場合があります（たとえば、CPUがより高いまたは低い可能性があります）。負荷）。
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.
レートベースのアルゴリズムの「oc」パラメーターは、クライアントからサーバーに送信されるトラフィックの上限（1秒あたりのメッセージ数）であることに注意してください。クライアントは、さまざまな理由で上限より大幅に低い速度でトラフィックを送信する場合があります。
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.
つまり、過負荷のサーバーによって複数のクライアントが制御されている場合、常に、一部のクライアントはターゲット（最大）SIPリクエストレートよりも低いレートでリクエストを受信し、他のクライアントはそのターゲットレートよりも高いレートでリクエストを受信します。ただし、過負荷のサーバーに提示される結果の要求レートは、ターゲットSIP要求レートに向かって収束します。
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.
過負荷を検出し、過負荷制御を呼び出すと決定すると、サーバーは[RFC7339]の仕様に従って、割り当てられたターゲットSIPリクエストレートをクライアントに通知し、レートベースの制御が有効であることをクライアントに通知する必要があります。
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].
クライアントがレートベースのアルゴリズムではなくデフォルトの損失ベースのアルゴリズムをサポートしている場合、クライアントは[RFC7339]のセクション5.10.2と同じ方法で処理されます。
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.
どちらの場合も、調整はこのドキュメントの範囲外です。ここに提示されているデフォルトのアルゴリズム（1つはトラフィックの優先順位付けのプロビジョニングあり、もう1つはなし）は単なる例です。
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).
ここに示すデフォルトのリーキーバケットアルゴリズムは、[ITU-T-I.371]の付録A.2に基づいています。このアルゴリズムにより、クライアントは、許容パラメーターTAU（できれば構成可能）を使用して、「oc」パラメーターで指定された速度でSIP要求を配信できます。
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.
「oc」パラメータが0で「0以外の「oc-validity」」の場合、クライアントは過負荷サーバー宛てのSIPリクエストを100％拒否する必要があることに注意してください。ただし、「oc-validity」の値が0の場合、クライアントはスロットルを直ちに停止する必要があります。
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.
新しいSIPリクエストの到着時に、バケットのコンテンツが制限値TAU以下の場合、SIPリクエストはサーバーに転送されます。それ以外の場合、SIP要求は拒否されます。
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.
クライアントがサーバーに関するある程度の知識（オペレーターの事前プロビジョニングなど）で構成されている状況では、サーバーに要求を送信するクライアントの数に基づいてTAUの値を選択することが有益な場合があります。
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.
非常に多数のクライアントがあり、それぞれの到着率が比較的小さいサーバーでは、すべてのサーバーからの急激なトラフィックの急増にさらされたときに、サーバーでのキューイング（したがって応答時間）を制限するために、TAUの値を小さくすることが一般的にメリットになりますクライアント。逆に、クライアントの数が比較的少なく、それぞれに比例して到着率が高いサーバーは、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
コントロールがアクティブ化されると、k番目の新しいSIPリクエストの到着時にta（k）で、バケットのコンテンツが値に暫定的に更新されます。
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.
Xは、最後に転送されたSIP要求の到着後のリーキーバケットカウンターの値であり、LCTは最後のSIP要求が転送された時間です。
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は任意の正の実数値を想定でき、必ずしも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.
TAUの値の指定、およびサーバー間の通信や調整は、このドキュメントの範囲を超えていることに注意してください。
A reference algorithm is shown below.
参照アルゴリズムを以下に示します。
No priority case:
の ｐりおりｔｙ かせ：
// 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
}
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).
[RFC7339]の損失ベースのアルゴリズムと同様に、レートベースのアルゴリズムを実装するクライアントは、メッセージを2つ以上のカテゴリのリクエストに優先順位付けします。たとえば、削減の候補であるリクエストと削減の対象にならないリクエスト（最初のカテゴリに削減可能なメッセージがない状況の場合。
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.
TAU1とTAU2は正の実数の値をとることができ、必ずしもTによって制限されません。
Reasonable values for TAU0, TAU1, and TAU2 are:
TAU0、TAU1、およびTAU2の妥当な値は次のとおりです。
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.
TAU1とTAU2の値の指定、およびサーバー間の通信や調整は、このドキュメントの範囲を超えていることに注意してください。
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
}
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.
共振が発生する可能性があるネットワークトポロジの場合、共振を回避する簡単な方法は、以下に説明するように、2つの適切なポイント（制御のアクティブ化時とバケットが空になるとき）でバケット占有をランダム化することです。
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 高負荷のランダム化はめったに発生しないので、バケットのランダム化された「フェーズ」が残っていても、許容レートの精度が失われることはありません。
The example in this section adapts the example in Section 6 of [RFC7339], where client P1 sends requests to a downstream server P2:
このセクションの例は、[RFC7339]のセクション6の例を適用したもので、クライアントP1がダウンストリームサーバーP2にリクエストを送信します。
INVITE sips:user@example.com SIP/2.0
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;received=192.0.2.111;
oc;oc-algo="loss,rate"
oc; oc-algo = "loss、rate"
...
。。。
SIP/2.0 100 Trying
SIP / 2.0 100試行
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;received=192.0.2.111;
oc=0;oc-algo="rate";oc-validity=0;
oc-seq=1282321615.781
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 p1.example.net;
branch=z9hG4bK2d4790.1;received=192.0.2.111;
oc=150;oc-algo="rate";oc-validity=1000;
oc-seq=1282321615.782
oc-seq = 1282321615.782
...
。。。
This specification extends the existing definition of the Via header field parameters of [RFC7339] as follows:
この仕様は、[RFC7339]のViaヘッダーフィールドパラメータの既存の定義を次のように拡張します。
algo-list =/ "rate"
何かリスト= / "レート"
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.
セクション3.5.3で説明されている共振の問題は別として、このメカニズムは、[RFC7339]で説明されている一般的な過負荷制御のセキュリティ問題以外のセキュリティの問題を引き起こしません。共振のリスクを軽減する方法については、セクション3.5.3で説明します。
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]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[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, <http://www.rfc-editor.org/info/rfc3261>.
[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月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", RFC 5390, December 2008, <http://www.rfc-editor.org/info/rfc5390>.
[RFC5390] Rosenberg、J。、「Session Initiation Protocolにおける過負荷の管理の要件」、RFC 5390、2008年12月、<http://www.rfc-editor.org/info/rfc5390>。
[RFC7339] Gurbani, V., Ed., Hilt, V., and H. Schulzrinne, "Session Initiation Protocol (SIP) Overload Control", RFC 7339, September 2014, <http://www.rfc-editor.org/info/rfc7339>.
[RFC7339] Gurbani、V.、Ed。、Hilt、V。、およびH. Schulzrinne、「Session Initiation Protocol（SIP）Overload Control」、RFC 7339、2014年9月、<http://www.rfc-editor.org / info / rfc7339>。
[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。
Acknowledgments
謝辞
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に感謝します。
Contributors
貢献者
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アメリカ
EMail: eric.noel@att.com
Philip M. Williams BT Innovate & Design Ipswich, IP5 3RE United Kingdom
フィリップM.ウィリアムズBTイノベーション＆デザインイプスウィッチ、IP5 3REイギリス
EMail: phil.m.williams@bt.com