Internet Engineering Task Force (IETF) V. Hilt
Request for Comments: 6357 Bell Labs/Alcatel-Lucent
Category: Informational E. Noel
ISSN: 2070-1721 AT&T Labs
C. Shen
Columbia University
A. Abdelal
Sonus Networks
August 2011
Design Considerations for
Session Initiation Protocol (SIP) Overload Control
Abstract
抽象
Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism.
SIPサーバは、彼らが受信するすべてのSIPメッセージを処理するのに十分なリソースを持っている時に過負荷がセッション開始プロトコル（SIP）ネットワークで発生します。 SIPプロトコルは、その503（サービス利用不可）応答コードを介して制限された過負荷制御機構を提供するにもかかわらず、SIPサーバは、依然として過負荷に対して脆弱です。この文書では、SIPの過負荷制御機構のモデルと設計上の考慮事項について説明します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6357.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6357で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SIP Overload Problem . . . . . . . . . . . . . . . . . . . . . 4
3. Explicit vs. Implicit Overload Control . . . . . . . . . . . . 5
4. System Model . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Degree of Cooperation . . . . . . . . . . . . . . . . . . . . 8
5.1. Hop-by-Hop . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. End-to-End . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Local Overload Control . . . . . . . . . . . . . . . . . . 11
6. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 14
9. Explicit Overload Control Feedback . . . . . . . . . . . . . . 15
9.1. Rate-Based Overload Control . . . . . . . . . . . . . . . 15
9.2. Loss-Based Overload Control . . . . . . . . . . . . . . . 17
9.3. Window-Based Overload Control . . . . . . . . . . . . . . 18
9.4. Overload Signal-Based Overload Control . . . . . . . . . . 19
9.5. On-/Off Overload Control . . . . . . . . . . . . . . . . . 19
10. Implicit Overload Control . . . . . . . . . . . . . . . . . . 20
11. Overload Control Algorithms . . . . . . . . . . . . . . . . . 20
12. Message Prioritization . . . . . . . . . . . . . . . . . . . . 21
13. Operational Considerations . . . . . . . . . . . . . . . . . . 21
14. Security Considerations . . . . . . . . . . . . . . . . . . . 22
15. Informative References . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 25
As with any network element, a Session Initiation Protocol (SIP) [RFC3261] server can suffer from overload when the number of SIP messages it receives exceeds the number of messages it can process. Overload occurs if a SIP server does not have sufficient resources to process all incoming SIP messages. These resources may include CPU, memory, input/output, or disk resources.
それは受信SIPメッセージの数は、それが処理できるメッセージの数を超えた場合に、任意のネットワーク構成要素と同様に、セッション開始プロトコル（SIP）[RFC3261]サーバーが過負荷に苦しむことができます。 SIPサーバは、すべての着信SIPメッセージを処理するのに十分なリソースを持っていない場合、過負荷が発生します。これらのリソースは、CPU、メモリ、入力/出力、またはディスクリソースを含むことができます。
Overload can pose a serious problem for a network of SIP servers. During periods of overload, the throughput of SIP messages in a network of SIP servers can be significantly degraded. In fact, overload in a SIP server may lead to a situation in which the overload is amplified by retransmissions of SIP messages causing the throughput to drop down to a very small fraction of the original processing capacity. This is often called congestion collapse.
過負荷は、SIPサーバのネットワークのための深刻な問題を提起することができます。過負荷の期間中、SIPサーバのネットワークにおけるSIPメッセージのスループットが大幅に低下する可能性があります。実際には、SIPサーバに過負荷が過負荷がスループットが元の処理能力の非常に小さな画分に落下させるSIPメッセージの再送によって増幅されている状況につながる可能性があります。これは、多くの場合、輻輳崩壊と呼ばれています。
An overload control mechanism enables a SIP server to process SIP messages close to its capacity limit during times of overload. Overload control is used by a SIP server if it is unable to process all SIP requests due to resource constraints. There are other failure cases in which a SIP server can successfully process incoming requests but has to reject them for other reasons. For example, a Public Switched Telephone Network (PSTN) gateway that runs out of trunk lines but still has plenty of capacity to process SIP messages should reject incoming INVITEs using a response such as 488 (Not Acceptable Here), as described in [RFC4412]. Similarly, a SIP registrar that has lost connectivity to its registration database but is still capable of processing SIP messages should reject REGISTER requests with a 500 (Server Error) response [RFC3261]. Overload control mechanisms do not apply in these cases and SIP provides appropriate response codes for them.
過負荷制御機構は、過負荷の時間中にその容量限界に近いSIPメッセージを処理するSIPサーバーを可能にします。リソースの制約のために、すべてのSIPリクエストを処理できない場合は、過負荷制御は、SIPサーバで使用されています。 SIPサーバが正常に着信要求を処理するが、他の理由のためにそれらを拒否しなければならないことが可能な他の障害のケースがあります。 [RFC4412]に記載されているように、例えば、公衆交換電話ネットワーク幹線の不足が、それでもSIPメッセージは、（ここではない可）488として応答を使用して、着信のINVITEを拒否すべきである処理能力を十分に有している（PSTN）ゲートウェイスイッチ。同様に、その登録データベースへの接続を失ったが、それでも500（サーバーエラー）応答[RFC3261]に登録要求を拒否すべきであるSIPメッセージを処理することができるしているSIPレジストラ。過負荷制御機構は、これらの場合には適用されませんし、SIPは、彼らのために適切な応答コードを提供します。
There are cases in which a SIP server runs other services that do not involve the processing of SIP messages (e.g., processing of RTP packets, database queries, software updates, and event handling). These services may, or may not, be correlated with the SIP message volume. These services can use up a substantial share of resources available on the server (e.g., CPU cycles) and leave the server in a condition where it is unable to process all incoming SIP requests. In these cases, the SIP server applies SIP overload control mechanisms to avoid congestion collapse on the SIP signaling plane. However, controlling the number of SIP requests may not significantly reduce the load on the server if the resource shortage was created by another service. In these cases, it is to be expected that the server uses appropriate methods of controlling the resource usage of other services. The specifics of controlling the resource usage of other services and their coordination is out of scope for this document.
SIPサーバは、SIPメッセージ（例えば、RTPパケット、データベースクエリ、ソフトウェアのアップデート、およびイベント処理の処理）の処理を伴わない他のサービスを実行している場合があります。これらのサービスは、あるいはないかもしれないが、SIPメッセージの体積と相関させることができます。これらのサービスは、サーバ（例えば、CPUサイクル）で利用可能なリソースのかなりのシェアを使用して、すべての着信SIP要求を処理することができない状態でサーバーを残すことができます。これらの場合、SIPサーバは、SIPシグナリング・プレーン上の輻輳崩壊を回避するために、SIP過負荷制御メカニズムを適用します。リソース不足が別のサービスによって作成された場合は、SIP要求の数を制御することが大幅にサーバーの負荷を軽減しない場合があります。これらのケースでは、サーバーは他のサービスのリソース使用量を制御するための適切なメソッドを使用していることが予想されます。他のサービスのリソース使用量を制御し、その調整の詳細はこの文書の範囲外です。
The SIP protocol provides a limited mechanism for overload control through its 503 (Service Unavailable) response code and the Retry-After header. However, this mechanism cannot prevent overload of a SIP server and it cannot prevent congestion collapse. In fact, it 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 Retry-After header, and the requirements for a SIP overload control mechanism can be found in [RFC5390]. In addition, 503 is used for other situations, not just SIP server overload. A SIP overload control process based on 503 would have to specify exactly which cause values trigger the overload control.
SIPプロトコルは、503（サービス利用不可）応答コードと再試行後にヘッダを介して過負荷制御のための限られたメカニズムを提供します。しかし、このメカニズムは、SIPサーバの過負荷を防ぐことはできないし、それが輻輳崩壊を防ぐことはできません。実際には、トラフィックが振動すると、SIPサーバ間でシフトすることにより、過負荷状態を悪化させる恐れがあります。 SIP過負荷の問題の詳細な説明、503（サービス利用不可）応答コードと再試行後ヘッダの問題、およびSIP過負荷制御機構のための要件は、[RFC5390]に見出すことができます。また、503は他の状況だけでなく、SIPサーバーの過負荷のために使用されています。 503に基づくSIP過負荷制御プロセスは、値が過負荷制御を誘発する原因となる正確に指定する必要があります。
This document discusses the models, assumptions, and design considerations for a SIP overload control mechanism. The document originated in the SIP overload control design team and has been further developed by the SIP Overload Control (SOC) working group.
この文書では、SIPの過負荷制御機構のモデル、仮定、および設計上の考慮事項について説明します。文書は、SIP過負荷制御の設計チームに由来し、さらにSIP過負荷制御（SOC）ワーキンググループによって開発されました。
A key contributor to SIP congestion collapse [RFC5390] is the regenerative behavior of overload in the SIP protocol. When SIP is running over the UDP protocol, it will retransmit messages that were dropped or excessively delayed by a SIP server due to overload and thereby increase the offered load for the already overloaded server. This increase in load worsens the severity of the overload condition and, in turn, causes more messages to be dropped. A congestion collapse can occur [Hilt] [Noel] [Shen] [Abdelal].
SIP輻輳崩壊[RFC5390]への主要な貢献者は、SIPプロトコルにおける過負荷の回生動作です。 SIPは、UDPプロトコル上で動作している場合、それは廃棄又は過度にオーバーロードすることにより、既に過負荷サーバに対して提供された負荷を増大させることにより、SIPサーバによって遅延されたメッセージを再送します。負荷の増加は、過負荷状態の重症度を悪化させると、今度は、より多くのメッセージが廃棄されます。輻輳崩壊は[柄] [ノエル] [シェン] [Abdelal]起こり得ます。
Regenerative behavior under overload should ideally be avoided by any protocol as this would lead to unstable operation under overload. However, this is often difficult to achieve in practice. For example, changing the SIP retransmission timer mechanisms can reduce the degree of regeneration during overload but will impact the ability of SIP to recover from message losses. Without any retransmission, each message that is dropped due to SIP server overload will eventually lead to a failed transaction.
これは、過負荷の下で不安定な動作につながるような過負荷の下の回生動作は、理想的には、任意のプロトコルによって避けるべきです。しかし、これは実際に達成することが困難な場合が多いです。例えば、SIP再送タイマメカニズムを変更する、過負荷時に再生の程度を低減することができるが、メッセージ損失から回復するSIPの能力に影響を与えます。任意の再送信せずに、SIPサーバの過負荷が原因でドロップされた各メッセージは、最終的に失敗したトランザクションにつながります。
For a SIP INVITE transaction to be successful, a minimum of three messages need to be forwarded by a SIP server. Often an INVITE transaction consists of five or more SIP messages. If a SIP server under overload randomly discards messages without evaluating them, the chances that all messages belonging to a transaction are successfully forwarded will decrease as the load increases. Thus, the number of transactions that complete successfully will decrease even if the message throughput of a server remains up and assuming the overload behavior is fully non-regenerative. A SIP server might (partially) parse incoming messages to determine if it is a new request or a message belonging to an existing transaction. Discarding a SIP message after spending the resources to parse it is expensive. The number of successful transactions will therefore decline with an increase in load as fewer resources can be spent on forwarding messages and more resources are consumed by inspecting messages that will eventually be dropped. The rate of the decline depends on the amount of resources spent to inspect each message.
成功するためにトランザクションを、SIP INVITEのために、3つのメッセージの最小は、SIPサーバによって転送される必要があります。多くの場合、INVITEトランザクションが5つ以上のSIPメッセージで構成されています。過負荷の下でSIPサーバがランダムにそれらを評価せず、メッセージを破棄した場合、すべてのメッセージが正常に転送されたトランザクションに属する可能性は、負荷の増加に伴って減少します。サーバーのメッセージスループットは最大のままで、過負荷の挙動をと仮定すると、完全に非再生の場合でもこのように、正常に完了したトランザクションの数が減少します。 SIPサーバは、（部分的に）それは新しい要求または既存のトランザクションに属するメッセージであるかどうかを判断するために、着信メッセージを解析することがあります。それは高価で解析するためのリソースを費やした後、SIPメッセージを破棄。最終的にドロップされるメッセージを検査することで、より少ないリソースがメッセージの転送に費やすことができ、より多くのリソースが消費されているとして成功したトランザクションの数は、したがって、負荷の増加に伴って低下します。下落率は、各メッセージを検査するために費やした資源の量に依存します。
Another challenge for SIP overload control is controlling the rate of the true traffic source. Overload is often caused by a large number of user agents (UAs), each of which creates only a single message. However, the sum of their traffic can overload a SIP server. The overload mechanisms suitable for controlling a SIP server (e.g., rate control) may not be effective for individual UAs. In some cases, there are other non-SIP mechanisms for limiting the load from the UAs. These may operate independently from, or in conjunction with, the SIP overload mechanisms described here. In either case, they are out of scope for this document.
SIP過負荷制御のためのもう一つの課題は、真のトラフィックソースの量を制御しています。過負荷は、しばしば、単一のメッセージを作成それぞれがユーザエージェント（UAS）の多数によって引き起こされます。しかし、彼らのトラフィックの合計は、SIPサーバをオーバーロードすることができます。 SIPサーバ（例えば、レート制御）を制御するのに適した過負荷機構は、個々のUAのために有効ではないかもしれません。いくつかのケースでは、ユーザエージェントからの荷重を制限するための他の非SIPメカニズムが存在します。これらは独立して、または本明細書に記載SIP過負荷機構と連動して動作することができます。いずれの場合も、彼らはこの文書の範囲外です。
The main difference between explicit and implicit overload control is the way overload is signaled from a SIP server that is reaching overload condition to its upstream neighbors.
明示的および暗黙的な過負荷制御の主な違いは、過負荷がその上流近隣に過負荷状態に達しているSIPサーバからシグナリングされる方法です。
In an explicit overload control mechanism, a SIP server uses an explicit overload signal to indicate that it is reaching its capacity limit. Upstream neighbors receiving this signal can adjust their transmission rate according to the overload signal to a level that is acceptable to the downstream server. The overload signal enables a SIP server to steer the load it is receiving to a rate at which it can perform at maximum capacity.
明示的な過負荷制御機構において、SIPサーバは、その容量限界に達していることを示すために、明示的な過負荷信号を使用します。この信号を受信し、上流の隣人は、下流サーバに受け入れられるレベルまで過負荷信号に応じてそれらの送信レートを調整することができます。過負荷信号は、それが最大容量で行うことができる速度に受信された負荷を操縦するSIPサーバを可能にします。
Implicit overload control uses the absence of responses and packet loss as an indication of overload. A SIP server that is sensing such a condition reduces the load it is forwarding to a downstream neighbor. Since there is no explicit overload signal, this mechanism is robust, as it does not depend on actions taken by the SIP server running into overload.
暗黙的な過負荷制御は、過負荷の指標として応答パケットロスが存在しないことを利用します。そのような状態を感知しているSIPサーバは、それが下流の近隣に転送された負荷を減少させます。明示的な過負荷信号がないので、このメカニズムは、それが過負荷に実行しているSIPサーバが実行するアクションに依存しないよう、堅牢です。
The ideas of explicit and implicit overload control are in fact complementary. By considering implicit overload indications, a server can avoid overloading an unresponsive downstream neighbor. An explicit overload signal enables a SIP server to actively steer the incoming load to a desired level.
明示的および暗黙的過負荷制御のアイデアは、実際に相補的です。暗黙の過負荷兆候を考慮することにより、サーバが応答しない下流の隣人の過負荷を避けることができます。明示的な過負荷信号を積極的に所望のレベルに入ってくる荷重を操縦するSIPサーバを可能にします。
The model shown in Figure 1 identifies fundamental components of an explicit SIP overload control mechanism:
図1に示すモデルは、明示的なSIPの過負荷制御機構の基本的な構成要素を識別する。
SIP Processor: The SIP Processor processes SIP messages and is the component that is protected by overload control.
SIPプロセッサ：SIPプロセッサは、SIPメッセージを処理し、過負荷制御によって保護されている成分です。
Monitor: The Monitor measures the current load of the SIP Processor on the receiving entity. It implements the mechanisms needed to determine the current usage of resources relevant for the SIP Processor and reports load samples (S) to the Control Function.
モニタ：モニタの措置受信エンティティのSIPプロセッサの現在の負荷。これは、SIPプロセッサに関連するリソースの現在の使用状況を判断するために必要なメカニズムとの報告が制御機能にサンプル（S）をロード実装しています。
Control Function: The Control Function implements the overload control algorithm. The Control Function uses the load samples (S) and determines if overload has occurred and a throttle (T) needs to be set to adjust the load sent to the SIP Processor on the receiving entity. The Control Function on the receiving entity sends load feedback (F) to the sending entity.
制御機能：制御機能は、過負荷制御アルゴリズムを実装しています。制御機能は、負荷サンプル（S）を使用し、過負荷が発生し、スロットル（T）は、受信エンティティにSIPプロセッサに送信負荷を調整するように設定する必要があるかどうかを決定します。受信エンティティの制御機能は、送信エンティティへの負荷フィードバック（F）を送信します。
Actuator: The Actuator implements the algorithms needed to act on the throttles (T) and ensures that the amount of traffic forwarded to the receiving entity meets the criteria of the throttle. For example, a throttle may instruct the Actuator to not forward more than 100 INVITE messages per second. The Actuator implements the algorithms to achieve this objective, e.g., using message gapping. It also implements algorithms to select the messages that will be affected and determine whether they are rejected or redirected.
アクチュエータ：アクチュエータは、スロットル（T）に作用するために必要なアルゴリズムを実装し、受信エンティティへ転送されたトラフィックの量は、スロットルの基準を満たすことを保証します。例えば、スロットルがない前方以上100が毎秒メッセージをINVITEアクチュエータを指示してもよいです。アクチュエータは、メッセージギャッピングを使用して、例えば、この目的を達成するためのアルゴリズムを実装します。また、影響を受けることになるメッセージを選択し、それらが拒否またはリダイレクトされているかどうかを判断するためのアルゴリズムを実装しています。
The type of feedback (F) conveyed from the receiving to the sending entity depends on the overload control method used (i.e., loss-based, rate-based, window-based, or signal-based overload control; see Section 9), the overload control algorithm (see Section 11), as well as other design parameters. The feedback (F) enables the sending entity to adjust the amount of traffic forwarded to the receiving entity to a level that is acceptable to the receiving entity without causing overload.
送信エンティティが使用する過負荷制御方法に依存するために、フィードバックのタイプ（F）は、受信から搬送（すなわち、損失ベース、レートベースのウィンドウベース、または信号に基づく過負荷制御、参照セクション9）、過負荷制御アルゴリズム（セクション11を参照）と同様に、他の設計パラメータ。フィードバック（F）は、過負荷を引き起こすことなく、受信エンティティに受け入れられるレベルまで受信エンティティへ転送されたトラフィックの量を調整するために送信側エンティティを可能にします。
Figure 1 depicts a general system model for overload control. In this diagram, one instance of the control function is on the sending entity (i.e., associated with the actuator) and one is on the receiving entity (i.e., associated with the Monitor). However, a specific mechanism may not require both elements. In this case, one of two control function elements can be empty and simply passes along feedback. For example, if (F) is defined as a loss-rate (e.g., reduce traffic by 10%), there is no need for a control function on the sending entity as the content of (F) can be copied directly into (T).
図1は、過負荷制御のための一般的なシステムモデルを示します。この図では、制御機能の1つのインスタンスは、送信側エンティティである（すなわち、アクチュエータに関連する）、1つは受信エンティティである（すなわち、モニタに関連付けられています）。しかし、特定の機構は、両方の要素を必要としないかもしれません。この場合、2つの制御機能要素の一つは空であってもよく、単にフィードバックに沿って通過します。 （F）は（例えば、10％のトラフィックを減らす）損失率として定義されている場合（F）の含有量は、（Tに直接コピーすることができるように、例えば、送信側エンティティ上の制御機能は不要です）。
The model in Figure 1 shows a scenario with one sending and one receiving entity. In a more realistic scenario, a receiving entity will receive traffic from multiple sending entities and vice versa (see Section 6). The feedback generated by a Monitor will therefore often be distributed across multiple Actuators. A Monitor needs to be able to split the load it can process across multiple sending entities and generate feedback that correctly adjusts the load each sending entity is allowed to send. Similarly, an Actuator needs to be prepared to receive different levels of feedback from different receiving entities and throttle traffic to these entities accordingly.
図1のモデルは、1つの送信と1つの受信エンティティとのシナリオを示しています。より現実的なシナリオでは、受信エンティティは、複数の送信エンティティとその逆（セクション6を参照）からのトラフィックを受信します。モニターによって生成されたフィードバックは、それゆえ、多くの場合、複数のアクチュエータに分散されます。モニタは、複数の送信エンティティ間で処理できる負荷を分割し、正しく各送信エンティティが送信することが許可された負荷を調整フィードバックを生成できるようにする必要があります。同様に、アクチュエータは、それに応じて、これらのエンティティに異なる受信エンティティからのフィードバックとスロットルトラフィックの異なるレベルを受け取るように準備される必要があります。
In a realistic deployment, SIP messages will flow in both directions, from server B to server A as well as server A to server B. The overload control mechanisms in each direction can be considered independently. For messages flowing from server A to server B, the sending entity is server A and the receiving entity is server B, and vice versa. The control loops in both directions operate independently.
現実的な展開では、各方向のSIPメッセージは、サーバBからサーバAと同様に、サーバAにサーバBに、両方向に流れる過負荷制御機構は、独立して考えることができます。サーバAからサーバBに流れるメッセージの場合、送信エンティティは、サーバAであり、受信エンティティはサーバB、およびその逆です。両方向の制御ループは独立して動作します。
Sending Receiving
Entity Entity
+----------------+ +----------------+
| Server A | | Server B |
| +----------+ | | +----------+ | -+
| | Control | | F | | Control | | |
| | Function |<-+------+--| Function | | |
| +----------+ | | +----------+ | |
| T | | | ^ | | Overload
| v | | | S | | Control
| +----------+ | | +----------+ | |
| | Actuator | | | | Monitor | | |
| +----------+ | | +----------+ | |
| | | | ^ | -+
| v | | | | -+
| +----------+ | | +----------+ | |
<-+--| SIP | | | | SIP | | | SIP
--+->|Processor |--+------+->|Processor |--+-> | System
| +----------+ | | +----------+ | |
+----------------+ +----------------+ -+
Figure 1: System Model for Explicit Overload Control
図1：明示的な過負荷制御のためのシステムモデル
A SIP request is usually processed by more than one SIP server on its path to the destination. Thus, a design choice for an explicit overload control mechanism is where to place the components of overload control along the path of a request and, in particular, where to place the Monitor and Actuator. This design choice determines the degree of cooperation between the SIP servers on the path. Overload control can be implemented hop-by-hop with the Monitor on one server and the Actuator on its direct upstream neighbor. Overload control can be implemented end-to-end with Monitors on all SIP servers along the path of a request and an Actuator on the sender. In this case, the Control Functions associated with each Monitor have to cooperate to jointly determine the overall feedback for this path. Finally, overload control can be implemented locally on a SIP server if the Monitor and Actuator reside on the same server. In this case, the sending entity and receiving entity are the same SIP server, and the Actuator and Monitor operate on the same SIP Processor (although, the Actuator typically operates on a pre-processing stage in local overload control). Local overload control is an internal overload control mechanism, as the control loop is implemented internally on one server. Hop-by-hop and end-to-end are external overload control mechanisms. All three configurations are shown in Figure 2.
SIP要求は、通常、宛先へのパス上に複数のSIPサーバによって処理されます。このように、明示的な過負荷制御機構の設計選択は、モニタやアクチュエータを配置する場合、特に、要求の経路に沿って過負荷制御のコンポーネントを配置しする場所です。この設計上の選択は、パス上のSIPサーバ間の協力の度合いを決定します。過負荷制御は、1台のサーバー上にモニターし、その直接の上流隣接のアクチュエータとホップバイホップを実装することができます。過負荷制御は、要求送信者にアクチュエータの経路に沿った全てのSIPサーバ上のモニタでエンドツーエンドを実現することができます。この場合、各モニタに関連付けられた制御機能は共同でこのパスの全体的なフィードバックを決定するために協力しなければなりません。モニターおよびアクチュエータが同じサーバー上に存在する場合は最後に、過負荷制御は、SIPサーバ上でローカルに実装することができます。この場合、エンティティを送信し、受信エンティティは、同一のSIPサーバであり、（アクチュエータは、典型的には、ローカル過負荷制御における前処理ステージ上で動作するが）アクチュエータとモニタは、同じSIPプロセッサ上で動作します。ローカル過負荷制御の制御ループは、1台のサーバ上で内部的に実装されているように、内部過負荷制御機構です。ホップバイホップとエンド・ツー・エンドは、外部過負荷制御機構です。すべての3つの構成は、図2に示されています。
+---------+ +------(+)---------+
+------+ | | | ^ |
| | | +---+ | | +---+
v | v //=>| C | v | //=>| C |
+---+ +---+ // +---+ +---+ +---+ // +---+
| A |===>| B | | A |===>| B |
+---+ +---+ \\ +---+ +---+ +---+ \\ +---+
^ \\=>| D | ^ | \\=>| D |
| +---+ | | +---+
| | | v |
+---------+ +------(+)---------+
(a) hop-by-hop (b) end-to-end
（a）は、ホップバイホップ（b）は、エンド・ツー・エンド
+-+
v |
+-+ +-+ +---+
v | v | //=>| C |
+---+ +---+ // +---+
| A |===>| B |
+---+ +---+ \\ +---+
\\=>| D |
+---+
^ |
+-+
(c) local
（C）ローカル
==> SIP request flow <-- Overload feedback loop
==> SIPリクエストフロー< - 過負荷フィードバックループ
Figure 2: Degree of Cooperation between Servers
図2：サーバー間の協力の度合い
The idea of hop-by-hop overload control is to instantiate a separate control loop between all neighboring SIP servers that directly exchange traffic. That is, the Actuator is located on the SIP server that is the direct upstream neighbor of the SIP server that has the corresponding Monitor. Each control loop between two servers is completely independent of the control loop between other servers further up- or downstream. In the example in Figure 2(a), three independent overload control loops are instantiated: A - B, B - C, and B - D. Each loop only controls a single hop. Overload feedback received from a downstream neighbor is not forwarded further upstream. Instead, a SIP server acts on this feedback, for example, by rejecting SIP messages if needed. If the upstream neighbor of a server also becomes overloaded, it will report this problem to its upstream neighbors, which again take action based on the reported feedback. Thus, in hop-by-hop overload control, overload is always resolved by the direct upstream neighbors of the overloaded server without the need to involve entities that are located multiple SIP hops away.
ホップバイホップ過負荷制御の考え方は、直接トラフィックを交換すべての隣接SIPサーバとの間の別個の制御ループをインスタンス化することです。これは、アクチュエータは、対応するモニターを持っているSIPサーバの直接の上流隣接であるSIPサーバ上に配置されています。 2つのサーバー間の各制御ループはさらに上方または下流の他のサーバとの間の制御ループの完全に独立しています。図2（A）の例では、三つの独立した過負荷制御ループがインスタンス化される：A - B、B - C、およびBは - D.各ループは、単一のホップを制御します。下流ネイバーから受信した過負荷フィードバックがさらに上流転送されません。代わりに、SIPサーバは、必要に応じて、SIPメッセージを拒否することによって、例えば、このフィードバックに作用します。サーバーの上流の隣人も過負荷になった場合は、再度報告されたフィードバックに基づいて行動を取るその上流ネイバー、この問題を報告します。このように、ホップバイホップ過負荷制御では、過負荷は、常に複数のSIPは、ホップ離れ置かれたエンティティが関与することなく、過負荷状態のサーバの直接上流の隣人によって解決されます。
Hop-by-hop overload control reduces the impact of overload on a SIP network and can avoid congestion collapse. It is simple and scales well to networks with many SIP entities. An advantage is that it does not require feedback to be transmitted across multiple-hops, possibly crossing multiple trust domains. Feedback is sent to the next hop only. Furthermore, it does not require a SIP entity to aggregate a large number of overload status values or keep track of the overload status of SIP servers it is not communicating with.
ホップバイホップ過負荷制御は、SIPネットワーク上の過負荷の影響を低減し、輻輳崩壊を回避することができます。それは簡単で、多くのSIPエンティティとのネットワークにも拡張できます。利点は、それが複数のホップを介して送信されるようにフィードバックを必要としないことである可能性が複数の信頼ドメインを横切ります。フィードバックは唯一の次のホップに送信されます。また、過負荷状態値が多数凝集またはそれと通信していないSIPサーバの過負荷状態を追跡するためにSIPエンティティを必要としません。
End-to-end overload control implements an overload control loop along the entire path of a SIP request, from user agent client (UAC) to user agent server (UAS). An end-to-end overload control mechanism consolidates overload information from all SIP servers on the way (including all proxies and the UAS) and uses this information to throttle traffic as far upstream as possible. An end-to-end overload control mechanism has to be able to frequently collect the overload status of all servers on the potential path(s) to a destination and combine this data into meaningful overload feedback.
エンドツーエンド過負荷制御は、ユーザエージェントクライアント（UAC）からユーザエージェントサーバ（UAS）に、SIP要求の経路全体に沿って過負荷制御ループを実装します。エンドツーエンド過負荷制御機構は、（すべてのプロキシとUASを含む）途中ですべてのSIPサーバからの過負荷情報を統合し限り上流できるだけトラフィックを絞るために、この情報を使用します。エンドツーエンド過負荷制御機構は、頻繁に目的地までの潜在的経路（S）上のすべてのサーバの過負荷状態を収集し、意味のある過負荷フィードバックにこのデータを結合することができなければなりません。
A UA or SIP server only throttles requests if it knows that these requests will eventually be forwarded to an overloaded server. For example, if D is overloaded in Figure 2(b), A should only throttle requests it forwards to B when it knows that they will be forwarded to D. It should not throttle requests that will eventually be forwarded to C, since server C is not overloaded. In many cases, it is difficult for A to determine which requests will be routed to C and D, since this depends on the local routing decision made by B. These routing decisions can be highly variable and, for example, depend on call-routing policies configured by the user, services invoked on a call, load-balancing policies, etc. A previous message to a target that has been routed through an overloaded server does not necessarily mean that the next message to this target will also be routed through the same server.
それはこれらの要求は、最終的に過負荷のサーバに転送されることを知っている場合はUAまたはSIPサーバーは要求を絞ります。 Dは、図2（B）にオーバーロードされる場合、例えば、Aは、スロットルは、それが彼らはそれが最終的にサーバCので、Cに転送されるスロットル要求いけないDに転送されることを知っている場合Bに転送要求すべきですオーバーロードされていません。多くの場合、これはB.製ローカルルーティング決定これらのルーティングの決定は、例えば、高度に可変であるとすることができるに依存するため、C及びDにルーティングされる要求を決定するのは困難であり、コールルーティングに依存ユーザーによって設定されたポリシー、コールに呼び出されるサービス、負荷分散ポリシーなど過負荷のサーバーを経由してルーティングされたターゲットへ前のメッセージは、必ずしもこのターゲットに次のメッセージも経由でルーティングされることを意味するものではありません同じサーバー。
The main problem of end-to-end overload control is its inherent complexity, since UAC or SIP servers need to monitor all potential paths to a destination in order to determine which requests should be throttled and which requests may be sent. Even if this information is available, it is not clear which path a specific request will take.
UAC又はSIPサーバは要求が絞られるべきであり、その要求が送信されてもよいかを決定するために、先にすべての潜在的な経路を監視する必要があるため、エンドツーエンド過負荷制御の主な問題は、その固有の複雑さです。この情報が入手可能であっても、特定の要求がかかりますどのパス明確ではありません。
A variant of end-to-end overload control is to implement a control loop between a set of well-known SIP servers along the path of a SIP request. For example, an overload control loop can be instantiated between a server that only has one downstream neighbor or a set of closely coupled SIP servers. A control loop spanning multiple hops can be used if the sending entity has full knowledge about the SIP servers on the path of a SIP message.
エンドツーエンド過負荷制御の変異体は、SIP要求の経路に沿って、周知のSIPサーバのセット間の制御ループを実装することです。例えば、過負荷制御ループは、ただ1つの下流の隣接または密接に結合されたSIPサーバのセットを有するサーバとの間でインスタンス化することができます。送信エンティティは、SIPメッセージの経路上のSIPサーバに関する完全な知識を持っている場合は、複数のホップに及ぶ制御ループを使用することができます。
Overload control for SIP servers is different from end-to-end congestion control used by transport protocols such as TCP. The traffic exchanged between SIP servers consists of many individual SIP messages. Each SIP message is created by a SIP UA to achieve a specific goal (e.g., to start setting up a call). All messages have their own source and destination addresses. Even SIP messages containing identical SIP URIs (e.g., a SUBSCRIBE and an INVITE message to the same SIP URI) can be routed to different destinations. This is different from TCP, where the traffic exchanged between routers consists of packets belonging to a usually longer flow of messages exchanged between a source and a destination (e.g., to transmit a file). If congestion occurs, the sources can detect this condition and adjust the rate at which the next packets are transmitted.
SIPサーバの過負荷制御は、TCPなどのトランスポートプロトコルによって使用されるエンドツーエンドの輻輳制御と異なっています。 SIPサーバ間で交換トラフィックは、多くの個々のSIPメッセージで構成されています。各SIPメッセージは、特定の目標（例えば、コールのセットアップを開始するために）を達成するためにSIP UAによって作成されます。すべてのメッセージは、自分の送信元アドレスと宛先アドレスを持っています。同じSIP URIを含むSIPメッセージであっても（例えば、SUBSCRIBEと同じSIP URIにINVITEメッセージ）異なる宛先にルーティングすることができます。これは、（例えば、ファイルを送信する）送信元と宛先の間で交換されるトラフィックは、メッセージの通常より長いフローに属するパケットから構成ルータ間で交換されるTCP、異なっています。輻輳が発生した場合、ソースは、この状態を検出し、次のパケットが送信されるレートを調整することができます。
The idea of local overload control (see Figure 2(c)) is to run the Monitor and Actuator on the same server. This enables the server to monitor the current resource usage and to reject messages that can't be processed without overusing local resources. The fundamental assumption behind local overload control is that it is less resource consuming for a server to reject messages than to process them. A server can therefore reject the excess messages it cannot process to stop all retransmissions of these messages. Since rejecting messages does consume resources on a SIP server, local overload control alone cannot prevent a congestion collapse.
地元の過負荷制御の考え方は、（図2（c）参照）と同じサーバー上でモニターし、アクチュエータを実行することです。これは、現在のリソース使用状況を監視するために、地域の資源を乱用することなく処理できないメッセージを拒絶するようにサーバを可能にします。地元の過負荷制御の背後にある基本的な前提は、それがそれらを処理するよりも、メッセージを拒否するようにサーバー用に低消費資源であるということです。サーバーは、したがって、それは、これらのメッセージのすべての再送を停止するために処理できない余分なメッセージを拒否することができます。メッセージを拒否すると、SIPサーバ上のリソースを消費しないので、地元の過負荷制御だけでは、輻輳崩壊を防ぐことはできません。
Local overload control can be used in conjunction with other overload control mechanisms and provides an additional layer of protection against overload. It is fully implemented within a SIP server and does not require cooperation between servers. In general, SIP servers should apply other overload control techniques to control load before a local overload control mechanism is activated as a mechanism of last resort.
ローカル過負荷制御は、他の過負荷制御機構と組み合わせて使用され、過負荷に対する保護の追加の層を提供することができます。それは完全にSIPサーバ内に実装されるとサーバ間の協力を必要としません。一般的には、SIPサーバは、ローカルの過負荷制御機構は、最後の手段として活性化される前に、負荷を制御するために、他の過負荷制御技術を適用する必要があります。
The following topologies describe four generic SIP server configurations. These topologies illustrate specific challenges for an overload control mechanism. An actual SIP server topology is likely to consist of combinations of these generic scenarios.
次のトポロジは、4つの、一般的なSIPサーバの構成を説明します。これらのトポロジは、過負荷制御機構のための具体的な課題を説明します。実際のSIPサーバのトポロジは、これらの一般的なシナリオの組み合わせで構成されそうです。
In the "load balancer" configuration shown in Figure 3(a), a set of SIP servers (D, E, and F) receives traffic from a single source A. A load balancer is a typical example for such a configuration. In this configuration, overload control needs to prevent server A (i.e., the load balancer) from sending too much traffic to any of its downstream neighbors D, E, and F. If one of the downstream neighbors becomes overloaded, A can direct traffic to the servers that still have capacity. If one of the servers acts as a backup, it can be activated once one of the primary servers reaches overload.
図3に示す「ロードバランサ」構成（a）において、SIPサーバ（D、E、及びF）のセットは、ロードバランサは、このような構成のための典型的な例である単一のソースAからトラフィックを受信します。この構成では、過負荷制御は、その下流の隣人D、E、およびFの下流の隣人の1が過負荷になった場合、Aはにトラフィックを誘導することができるのいずれかにあまりにも多くのトラフィックを送信してからサーバA（すなわち、ロードバランサ）を防止する必要がありますまだ能力を持つサーバー。いずれかのサーバがバックアップとして機能している場合、プライマリサーバの1が過負荷に達すると、それが起動することができます。
If A can reliably determine that D, E, and F are its only downstream neighbors and all of them are in overload, it may choose to report overload upstream on behalf of D, E, and F. However, if the set of downstream neighbors is not fixed or only some of them are in overload, then A should not activate an overload control since A can still forward the requests destined to non-overloaded downstream neighbors. These requests would be throttled as well if A would use overload control towards its upstream neighbors.
Aは確実D、E、およびFは、その唯一の下流の隣国であり、それらのすべてが過負荷である、それは下流の隣人のセットならば、しかしD、E、およびFの代わりに、上流の過負荷を報告することを選択することが確認できた場合Aは、まだ非過負荷の下流の隣人宛て要求を転送することができるので、固定またはその一部のみが過負荷であるされていない場合、過負荷制御をアクティブにはなりません。 Aは、その上流の隣人への過負荷制御を使用する場合は、これらの要求は、同様に絞ることになります。
In some cases, the servers D, E, and F are in a server farm and are configured to appear as a single server to their upstream neighbors. In this case, server A can report overload on behalf of the server farm. If the load balancer is not a SIP entity, servers D, E, and F can report the overall load of the server farm (i.e., the load of the virtual server) in their messages. As an alternative, one of the servers (e.g., server E) can report overload on behalf of the server farm. In this case, not all messages contain overload control information, and all upstream neighbors need to be served by server E periodically to ensure that updated information is received.
いくつかのケースでは、サーバD、E、およびFは、サーバーファームであり、その上流の隣人への単一のサーバとして見えるように構成されています。この場合、サーバーAは、サーバーファームに代わって過負荷を報告することができます。ロードバランサは、SIPエンティティでない場合、サーバD、E、およびFは、それらのメッセージ内のサーバファーム（仮想サーバのすなわち、負荷）の全体的な負荷を報告することができます。別の方法として、サーバ（例えば、サーバE）の一つは、サーバーファームに代わって過負荷を報告することができます。この場合、いないすべてのメッセージは、過負荷制御情報が含まれており、すべての上流の隣人が更新された情報が受信されることを保証するために、定期的にサーバEによって提供される必要があります。
In the "multiple sources" configuration shown in Figure 3(b), a SIP server D receives traffic from multiple upstream sources A, B, and C. Each of these sources can contribute a different amount of traffic, which can vary over time. The set of active upstream neighbors of D can change as servers may become inactive, and previously inactive servers may start contributing traffic to D.
図3（B）に示す「複数のソース」構成では、SIPサーバDは、B、およびCは、これらのソースのそれぞれは、時間の経過とともに変化することができるトラフィックの異なる量を、貢献することができる複数のアップストリームのソースからのトラフィックを受信します。サーバが非アクティブになることとして、Dのアクティブな上流の隣人のセットを変更することができ、そして以前に非アクティブのサーバーはD.へのトラフィックを貢献し始めることができます
If D becomes overloaded, it needs to generate feedback to reduce the amount of traffic it receives from its upstream neighbors. D needs to decide by how much each upstream neighbor should reduce traffic. This decision can require the consideration of the amount of traffic sent by each upstream neighbor and it may need to be re-adjusted as the traffic contributed by each upstream neighbor varies over time. Server D can use a local fairness policy to determine how much traffic it accepts from each upstream neighbor.
Dが過負荷になった場合、それはその上流ネイバーから受信したトラフィックの量を減らすために、フィードバックを生成する必要があります。 Dはそれぞれ上流の隣人がトラフィックを減らす必要がありますどのくらいで決定する必要があります。この決定は、各上流隣接によって送信されたトラフィック量を考慮することを必要とすることができ、各上流隣接によって寄与トラフィックが時間とともに変化するように再調整する必要があるかもしれません。サーバDは、各上流の隣人から受け入れてどのくらいのトラフィックを決定するために、ローカル公平性ポリシーを使用することができます。
In many configurations, SIP servers form a "mesh" as shown in Figure 3(c). Here, multiple upstream servers A, B, and C forward traffic to multiple alternative servers D and E. This configuration is a combination of the "load balancer" and "multiple sources" scenario.
図3（c）に示すように、多くの構成では、SIPサーバは、「メッシュ」を形成します。ここで、複数の代替サーバD及びEに複数のアップストリームサーバA、B、及びCの順方向トラフィックがこの構成は、「ロード・バランサ」および「複数のソース」シナリオの組み合わせです。
+---+ +---+
/->| D | | A |-\
/ +---+ +---+ \
/ \ +---+
+---+-/ +---+ +---+ \->| |
| A |------>| E | | B |------>| D |
+---+-\ +---+ +---+ /->| |
\ / +---+
\ +---+ +---+ /
\->| F | | C |-/
+---+ +---+
(a) load balancer (b) multiple sources
（a）は、ロードバランサ（b）は、複数のソース
+---+
| A |---\ a--\
+---+-\ \---->+---+ \
\/----->| D | b--\ \--->+---+
+---+--/\ /-->+---+ \---->| |
| B | \/ c-------->| D |
+---+---\/\--->+---+ | |
/\---->| E | ... /--->+---+
+---+--/ /-->+---+ /
| C |-----/ z--/
+---+
(c) mesh (d) edge proxy
（c）はメッシュ（d）のエッジプロキシ
Figure 3: Topologies
図3：トポロジ
Overload control that is based on reducing the number of messages a sender is allowed to send is not suited for servers that receive requests from a very large population of senders, each of which only sends a very small number of requests. This scenario is shown in Figure 3(d). An edge proxy that is connected to many UAs is a typical example for such a configuration. Since each UA typically infrequently sends requests, which are often related to the same session, it can't decrease its message rate to resolve the overload.
送信者が送信を許可されたメッセージの数を減らすことに基づいて過負荷制御が要求だけの非常に小さな数を送るそれぞれの送信者の非常に大きな母集団からの要求を受信サーバに適していません。このシナリオは、図3（d）に示されています。多くのUAに接続されたエッジプロキシは、このような構成のための典型的な例です。各UAは、一般的に、まれに、多くの場合、同じセッションに関連するリクエストを送信するので、過負荷を解決するために、そのメッセージの速度を減少させることはできません。
A SIP server that receives traffic from many sources, which each contribute only a small number of requests, can resort to local overload control by rejecting a percentage of the requests it receives with 503 (Service Unavailable) responses. Since it has many upstream neighbors, it can send 503 (Service Unavailable) to a fraction of them to gradually reduce load without entirely stopping all incoming traffic. The Retry-After header can be used in 503 (Service Unavailable) responses to ask upstream neighbors to wait a given number of seconds before trying the request again. Using 503 (Service Unavailable) can, however, not prevent overload if a large number of sources create requests (e.g., to place calls) at the same time.
各要求のごく少数の貢献多くのソースからのトラフィックを受信するSIPサーバは、それは503（サービス利用不可）応答を受け取る要求の割合を拒否することにより、ローカル過負荷制御に頼ることができます。それは多くの上流の隣人を持っているので、それは徐々に完全にすべての着信トラフィックを停止することなく、負荷を軽減するためにそれらの画分に503（サービス使用不可）を送信することができます。リトライ-Afterヘッダには、要求を再試行する前に、与えられた秒数を待つために上流の隣人を依頼する503（サービス使用不可）応答で使用することができます。多数のソースが同時に要求（例えば、電話をかけるために）を作成した場合、503（サービス使用不可）を使用すると、しかし、過負荷を防ぐことはできません。
Note: The requirements of the "edge proxy" topology are different from the ones of the other topologies, which may require a different method for overload control.
注：「エッジプロキシ」トポロジーの要件は、過負荷制御のための別の方法を必要とし得る他のトポロジーのうち、異なっています。
There are many different ways to define fairness between multiple upstream neighbors of a SIP server. In the context of SIP server overload, it is helpful to describe two categories of fairness: basic fairness and customized fairness. With basic fairness, a SIP server treats all requests equally and ensures that each request has the same chance of succeeding. With customized fairness, the server allocates resources according to different priorities. An example application of the basic fairness criteria is the "Third caller receives free tickets" scenario, where each call attempt should have an equal success probability in connecting through an overloaded SIP server, irrespective of the service provider in which the call was initiated. An example of customized fairness would be a server that assigns different resource allocations to its upstream neighbors (e.g., service providers) as defined in a service level agreement (SLA).
SIPサーバの複数の上流ネイバー間の公平性を定義するためのさまざまな方法があります。基本的な公平性とカスタマイズされた公正：SIPサーバの過負荷の状況では、公正の二つのカテゴリーを記述するために有用です。基本的な公平さと、SIPサーバは、同様にすべての要求を扱い、各要求は、後続の同じチャンスを持っていることを保証します。カスタマイズされた公正では、サーバーは異なる優先順位に応じてリソースを割り当てます。基本的な公平性基準の適用例は、通話が開始されたサービスプロバイダにかかわらず、各コールの試みが過負荷にSIPサーバを経由して接続が等しい成功確率を持つべきシナリオ、「第三の呼び出し側は無料チケットを受け取る」です。カスタマイズされた公平性の例は、サービスレベルアグリーメント（SLA）で定義されるように、その上流近隣（例えば、サービスプロバイダ）に異なるリソース割り当てを割り当てるサーバーであろう。
The performance of an overload control mechanism can be measured using different metrics.
過負荷制御機構の性能は、異なるメトリックを使用して測定することができます。
A key performance indicator is the goodput of a SIP server under overload. Ideally, a SIP server will be enabled to perform at its maximum capacity during periods of overload. For example, if a SIP server has a processing capacity of 140 INVITE transactions per second, then an overload control mechanism should enable it to process 140 INVITEs per second even if the offered load is much higher. The delay introduced by a SIP server is another important indicator. An overload control mechanism should ensure that the delay encountered by a SIP message is not increased significantly during periods of overload. Significantly increased delay can lead to time-outs and retransmission of SIP messages, making the overload worse.
主要なパフォーマンス指標は、過負荷の下でSIPサーバのグッドプットです。理想的には、SIPサーバは、過負荷の期間中、その最大能力で実行することが可能であろう。 SIPサーバ140の処理能力を有する場合、例えば、その過負荷制御機構が提供される負荷が非常に高い場合であっても、毎秒140件のINVITEを処理することを可能にする必要があり、秒あたりのトランザクションをINVITE。 SIPサーバによって導入される遅延は、もう一つの重要な指標です。過負荷制御機構は、SIPメッセージが遭遇する遅延は、過負荷の期間中に有意に増加していないことを確認すべきです。大幅に増加した遅延は、過負荷が悪化させる、タイムアウトおよびSIPメッセージの再送信につながることができます。
Responsiveness and stability are other important performance indicators. An overload control mechanism should quickly react to an overload occurrence and ensure that a SIP server does not become overloaded, even during sudden peaks of load. Similarly, an overload control mechanism should quickly stop rejecting requests if the overload disappears. Stability is another important criteria. An overload control mechanism should not cause significant oscillations of load on a SIP server. The performance of SIP overload control mechanisms is discussed in [Noel], [Shen], [Hilt], and [Abdelal].
応答性と安定性は、他の重要な性能指標です。過負荷制御機構は、素早く過負荷の発生に反応し、SIPサーバがあっても、負荷の突然のピーク時、過負荷にならないことを確実にすべきです。同様に、過負荷制御機構はすぐに過負荷が消えた場合に要求を拒否停止する必要があります。安定性は、他の重要な基準です。過負荷制御機構は、SIPサーバの負荷の大きな振動が発生することはありません。 SIP過負荷制御機構の性能は[ノエル]で議論されている、[シェン]、[柄]、および[Abdelal]。
In addition to the above metrics, there are other indicators that are relevant for the evaluation of an overload control mechanism:
上記指標に加えて、過負荷制御機構の評価に関連する他の指標があります。
Fairness: Which type of fairness does the overload control mechanism implement?
フェアネス：過負荷制御機構は、公平性の種類を実装していますか？
Self-limiting: Is the overload control self-limiting if a SIP server becomes unresponsive?
自己制限は：SIPサーバが応答しなくなった場合に過負荷制御は、自己制限されていますか？
Changes in neighbor set: How does the mechanism adapt to a changing set of sending entities?
隣人の変更は設定：どのメカニズムは、エンティティを送るの変更セットに適応するのでしょうか？
Data points to monitor: Which and how many data points does an overload control mechanism need to monitor?
監視するデータポイント：どのおよび過負荷制御機構を監視するために、どのように多くのデータポイントを必要とするのか？
Computational load: What is the (CPU) load created by the overload "Monitor" and "Actuator"?
計算負荷：過負荷「モニター」と「アクチュエータ」により作成された（CPU）負荷とは何ですか？
Explicit overload control feedback enables a receiver to indicate how much traffic it wants to receive. Explicit overload control mechanisms can be differentiated based on the type of information conveyed in the overload control feedback and whether the control function is in the receiving or sending entity (receiver- vs. sender-based overload control), or both.
明示的な過負荷制御のフィードバックは、それが受信したいどのくらいのトラフィックを示すために受信機を可能にします。明示的な過負荷制御機構は、過負荷制御フィードバックおよび制御機能は、（センダベースの過負荷制御対receiver-）受信または送信側エンティティであるか、またはその両方かどうかを伝えられる情報のタイプに基づいて区別することができます。
The key idea of rate-based overload control is to limit the request rate at which an upstream element is allowed to forward traffic to the downstream neighbor. If overload occurs, a SIP server instructs each upstream neighbor to send, at most, X requests per second. Each upstream neighbor can be assigned a different rate cap.
レートベースの過負荷制御の重要なアイデアは、上流要素を下流隣接ノードへのトラフィックの転送を許可された要求レートを制限することです。過負荷が発生した場合、SIPサーバは、最大で送信するために、各上流の隣人、毎秒X要求を指示します。各アップストリームネイバーは異なるレートキャップを割り当てることができます。
An example algorithm for an Actuator in the sending entity is request gapping. After transmitting a request to a downstream neighbor, a server waits for 1/X seconds before it transmits the next request to the same neighbor. Requests that arrive during the waiting period are not forwarded and are either redirected, rejected, or buffered. Request gapping only affects requests that are targeted by overload control (e.g., requests that initiate a transaction and not retransmissions in an ongoing transaction).
送信エンティティにおけるアクチュエータの例アルゴリズムが要求ギャッピングです。それは同じネイバーに次の要求を送信する前に、下流の隣接に要求を送信した後、サーバは、1 / X秒間待機します。待機期間中に到着した要求が転送されないとのいずれか、リダイレクト拒否、またはバッファリングされています。唯一ギャッピング要求は、過負荷制御（トランザクションを開始し、現在進行中のトランザクションで再送信ではない、例えば、要求）の標的とされる要求に影響を与えます。
The rate cap ensures that the number of requests received by a SIP server never increases beyond the sum of all rate caps granted to upstream neighbors. Rate-based overload control protects a SIP server against overload, even during load spikes assuming there are no new upstream neighbors that start sending traffic. New upstream neighbors need to be considered in the rate caps assigned to all upstream neighbors. The rate assigned to upstream neighbors needs to be adjusted when new neighbors join. During periods when new neighbors are joining, overload can occur in extreme cases until the rate caps of all servers are adjusted to again match the overall rate cap of the server. The overall rate cap of a SIP server is determined by an overload control algorithm, e.g., based on system load.
レート上限は、SIPサーバが受信した要求の数が決して上流の隣人に付与されたすべてのレートキャップの合計を超えて増加しないことを保証します。レートベースの過負荷制御も、トラフィックの送信を開始新しい上流ネイバーが存在しないと仮定すると、負荷の急増時に、過負荷に対してSIPサーバを保護します。新しい上流の隣人は、すべての上流の隣人に割り当てられたレートの上限に検討する必要があります。新しい隣人が参加したときに、上流の隣人に割り当てられた率を調整する必要があります。すべてのサーバの割合キャップが再びサーバーの全体的な速度の上限と一致するように調整されるまで、新しい隣人が参加している期間中、過負荷が極端な場合に発生する可能性があります。 SIPサーバの全体的なレートキャップはシステム負荷に基づいて、例えば、過負荷制御アルゴリズムによって決定されます。
Rate-based overload control requires a SIP server to assign a rate cap to each of its upstream neighbors while it is activated. Effectively, a server needs to assign a share of its overall capacity to each upstream neighbor. A server needs to ensure that the sum of all rate caps assigned to upstream neighbors does not substantially oversubscribe its actual processing capacity. This requires a SIP server to keep track of the set of upstream neighbors and to adjust the rate cap if a new upstream neighbor appears or an existing neighbor stops transmitting. For example, if the capacity of the server is X and this server is receiving traffic from two upstream neighbors, it can assign a rate of X/2 to each of them. If a third sender appears, the rate for each sender is lowered to X/3. If the overall rate cap is too high, a server may experience overload. If the cap is too low, the upstream neighbors will reject requests even though they could be processed by the server.
レートベースの過負荷制御は、それが活性化されている間、その上流の近隣の各々にレート上限を割り当てるSIPサーバを必要とします。効果的に、サーバは、各上流の隣人にその全体の容量のシェアを割り当てる必要があります。サーバーは、上流の隣人に割り当てられたすべてのレートキャップの合計は実質的にその実際の処理能力をオーバーサブスクライブしないことを保証する必要があります。これは、上流の隣人のセットを追跡するために、新たな上流の隣人が表示されたり、既存の隣人が送信を停止した場合にレート上限を調整するためにSIPサーバが必要です。サーバの容量がXであり、このサーバは、2つの上流の近隣からのトラフィックを受信している場合、例えば、それはそれらのそれぞれにX / 2のレートを割り当てることができます。第三の送信者が表示された場合、各送信者の割合は、X / 3に低下させます。全体的な速度の上限が高すぎると、サーバが過負荷が発生することがあります。キャップが低すぎる場合には、上流の隣人は、彼らがサーバーで処理することができていても要求を拒否します。
An approach for estimating a rate cap for each upstream neighbor is using a fixed proportion of a control variable, X, where X is initially equal to the capacity of the SIP server. The server then increases or decreases X until the workload arrival rate matches the actual server capacity. Usually, this will mean that the sum of the rate caps sent out by the server (=X) exceeds its actual capacity, but enables upstream neighbors who are not generating more than their fair share of the work to be effectively unrestricted. In this approach, the server only has to measure the aggregate arrival rate. However, since the overall rate cap is usually higher than the actual capacity, brief periods of overload may occur.
各上流隣接のレートキャップを推定するための手法は、Xは、SIPサーバの能力に最初に等しい制御変数、X、一定の割合を使用しています。ワークロードの到着率は、実際のサーバの能力と一致するまで、サーバは、次に、Xを増加または減少させます。通常、これは、サーバが送信レートキャップの合計が（= X）はその実際の容量を超えているが、仕事の公正な取り分より多くを生成していない上流の隣人が効果的に制限のないことを可能にすることを意味します。このアプローチでは、サーバは、集約到着率を測定することがあります。全体的なレートキャップは実際の容量よりも通常高いので、過負荷の短い期間が発生する可能性があります。
A loss percentage enables a SIP server to ask an upstream neighbor to reduce the number of requests it would normally forward to this server by X%. 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 that is destined for this server.
損失の割合がX％で、このサーバに正常に楽しみ、それは希望のリクエストの数を減らすために、上流の隣人を依頼するSIPサーバを可能にします。例えば、SIPサーバは、この隣人は通常10％で送信した要求の数を減らすために、上流の隣人を求めることができます。上流の隣人は、このサーバ宛のトラフィックの10％をリダイレクトまたは拒否する。
To implement a loss percentage, the sending entity may employ an algorithm to draw a random number between 1 and 100 for each request to be forwarded. The request is not forwarded to the server if the random number is less than or equal to X.
損失率を実現するために、送信エンティティは、各要求を転送するための1と100との間で乱数を描画するためのアルゴリズムを採用してもよいです。乱数がより小さいかXに等しい場合、要求がサーバに転送されていません
An advantage of loss-based overload control is that the receiving entity does not need to track the set of upstream neighbors or the request rate it receives from each upstream neighbor. It is sufficient to monitor the overall system utilization. To reduce load, a server can ask its upstream neighbors to lower the traffic forwarded by a certain percentage. The server calculates this percentage by combining the loss percentage that is currently in use (i.e., the loss percentage the upstream neighbors are currently using when forwarding traffic), the current system utilization, and the desired system utilization. For example, if the server load approaches 90% and the current loss percentage is set to a 50% traffic reduction, then the server can decide to increase the loss percentage to 55% in order to get to a system utilization of 80%. Similarly, the server can lower the loss percentage if permitted by the system utilization.
損失ベースの過負荷制御の利点は、受信エンティティは、上流の近隣のセットまたは各上流ネイバーから受信した要求レートを追跡する必要がないことです。システム全体の使用率を監視するのに十分です。負荷を軽減するために、サーバーが一定の割合で転送されたトラフィックを下げるために、その上流の隣人に尋ねることができます。サーバは、現在使用中の損失率（すなわち、トラフィックを転送するとき、上流ネイバーが現在使用している損失率）、現在のシステム使用率、および所望のシステムの利用を組み合わせることにより、この割合を算出します。サーバーの負荷が90％に近づくと、現在の損失率が50％のトラフィックの低減に設定されている場合、サーバは80％のシステム利用率を取得するためには55％に損失率を向上させることを決定することができます。システムの利用によって許可された場合も、サーバは損失率を下げることができます。
Loss-based overload control requires that the throttle percentage be adjusted to the current overall number of requests received by the server. This is particularly important if the number of requests received fluctuates quickly. For example, if a SIP server sets a throttle value of 10% at time t1 and the number of requests increases by 20% between time t1 and t2 (t1<t2), then the server will see an increase in traffic by 10% between time t1 and t2. This is even though all upstream neighbors have reduced traffic by 10%. Thus, percentage throttling requires an adjustment of the throttling percentage in response to the traffic received and may not always be able to prevent a server from encountering brief periods of overload in extreme cases.
損失ベースの過負荷制御スロットルの割合は、サーバーが受信した要求の現在の全体的な数に調整されている必要があります。受け取った要求の数が急速に変動した場合、これは特に重要です。例えば、SIPサーバは、時刻t1において10％のスロットル値を設定する場合に要求の数が時間T1およびT2（T1 <T2）との間に20％増加し、その後、サーバは、間に10％のトラフィックの増加が表示されます時間t1とt2。これは、すべての上流の隣人が10％で、トラフィックが減少しているにもかかわらずです。このように、割合の調整は、受信したトラフィックに応じて、スロットリング比率の調整を必要とし、常に極端な場合には、過負荷の短い期間に遭遇からサーバーを防ぐことができない場合があります。
The key idea of window-based overload control is to allow an entity to transmit a certain number of messages before it needs to receive a confirmation for the messages in transit. Each sender maintains an overload window that limits the number of messages that can be in transit without being confirmed. Window-based overload control is inspired by TCP [RFC0793].
ウィンドウベースの過負荷制御のキーアイデアは、それは輸送中のメッセージの確認を受信する必要がある前に、エンティティは、メッセージの一定数を送信できるようにすることです。各送信者は確認されずに輸送中にできるメッセージの数を制限し、過負荷ウィンドウを維持しています。ウィンドウベースの過負荷制御は、TCP [RFC0793]に触発されています。
Each sender maintains an unconfirmed message counter for each downstream neighbor it is communicating with. For each message sent to the downstream neighbor, the counter is increased. For each confirmation received, the counter is decreased. The sender stops transmitting messages to the downstream neighbor when the unconfirmed message counter has reached the current window size.
各送信者は、それが通信している各ダウンストリームネイバの未確認メッセージカウンタを維持します。下流隣人に送られた各メッセージに対して、カウンタが増加されます。各受信確認のために、カウンタが減少します。送信者は、未確認のメッセージカウンタは、現在のウィンドウサイズに達した場合、下流の隣人へのメッセージの送信を停止します。
A crucial parameter for the performance of window-based overload control is the window size. Each sender has an initial window size it uses when first sending a request. This window size can be changed based on the feedback it receives from the receiver.
ウィンドウベースの過負荷制御の性能のための重要なパラメータは、ウィンドウ・サイズです。各送信者は、最初の要求を送信するときに、それが使用する初期ウィンドウサイズを持っています。このウィンドウのサイズは、それが受信機から受信したフィードバックに基づいて変更することができます。
The sender adjusts its window size as soon as it receives the corresponding feedback from the receiver. If the new window size is smaller than the current unconfirmed message counter, the sender stops transmitting messages until more messages are confirmed and the current unconfirmed message counter is less than the window size.
送信者は、すぐにそれが受信機から対応するフィードバックを受信すると、そのウィンドウサイズを調整します。新しいウィンドウサイズは現在未確認のメッセージカウンタよりも小さい場合にはより多くのメッセージが確認されており、現在未確認のメッセージカウンタがウィンドウサイズよりも小さくなるまで、送信者はメッセージの送信を停止します。
Note that the reception of a 100 (Trying) response does not provide a confirmation for the successful processing of a message. 100 (Trying) responses are often created by a SIP server very early in processing and do not indicate that a message has been successfully processed and cleared from the input buffer. If the downstream neighbor is a stateless proxy, it will not create 100 (Trying) responses at all and will instead pass through 100 (Trying) responses created by the next stateful server. Also, 100 (Trying) responses are typically only created for INVITE requests. Explicit message confirmations do not have these problems.
100（試行）応答の受信は、メッセージを正常に処理するための確認を提供しないことに留意されたいです。 100（しよう）の応答は、多くの場合、非常に早い処理におけるSIPサーバによって作成され、メッセージが正常に処理され、入力バッファからクリアされていることを示すものではありません。下流の隣人がステートレスプロキシである場合は、それがすべてで100（しよう）の応答を作成しません、代わりに次のステートフルサーバによって作成された100（しよう）応答を通過します。また、100（しよう）応答は、一般的にのみ、INVITEリクエストのために作成されます。明示的なメッセージの確認は、これらの問題を持っていません。
Window-based overload control is similar to rate-based overload control in that the total available receiver buffer space needs to be divided among all upstream neighbors. However, unlike rate-based overload control, window-based overload control is self-limiting and can ensure that the receiver buffer does not overflow under normal conditions. The transmission of messages by senders is clocked by message confirmations received from the receiver. A buffer overflow can occur in extreme cases when a large number of new upstream neighbors arrives at the same time. However, senders will eventually stop transmitting new requests once their initial sending window is closed.
ウィンドウベースの過負荷制御利用可能な全受信バッファ空間は、すべての上流の近隣の間で分割する必要があることで過負荷制御系を評価する類似しています。しかし、レートベースの過負荷制御とは異なり、ウィンドウベースの過負荷制御は、自己制限的であり、受信バッファが通常の条件下でオーバーフローがないことを保証することができます。送信者によるメッセージの送信は、受信機から受信したメッセージの確認によってクロックされます。新しい上流近傍の多数が同時に到着したとき、バッファオーバーフローが極端な場合に起こり得ます。ただし、送信者は最終的に彼らの最初の送信ウィンドウが閉じられた後、新しい要求の送信を停止します。
In window-based overload control, the number of messages a sender is allowed to send can frequently be set to zero. In this state, the sender needs to be informed when it is allowed to send again and when the receiver window has opened up. However, since the sender is not allowed to transmit messages, the receiver cannot convey the new window size by piggybacking it in a response to another message. Instead, it needs to inform the sender through another mechanism, e.g., by sending a message that contains the new window size.
ウィンドウベースの過負荷制御では、送信者が送信することが許可されたメッセージの数は頻繁にゼロに設定することができます。この状態では、送信側は受信側のウィンドウが開かれているとき、再び送信することが許可されたときに通知する必要があります。送信者がメッセージを送信するために許可されていないので、受信機は、別のメッセージに応答して、それをピギーバックすることにより、新しいウィンドウサイズを伝えることはできません。代わりに、新しいウィンドウサイズを含むメッセージを送信することにより、例えば、別のメカニズムを介して送信者に通知する必要があります。
The key idea of overload signal-based overload control is to use the transmission of a 503 (Service Unavailable) response as a signal for overload in the downstream neighbor. After receiving a 503 (Service Unavailable) response, the sender reduces the load forwarded to the downstream neighbor to avoid triggering more 503 (Service Unavailable) responses. The sender keeps reducing the load if more 503 (Service Unavailable) responses are received. Note that this scheme is based on the use of 503 (Service Unavailable) responses without the Retry-After header, as the Retry-After header would require a sender to entirely stop forwarding requests. It should also be noted that 503 responses can be generated for reasons other than overload (e.g., server maintenance).
過負荷信号に基づく過負荷制御の重要なアイデアは、下流の近隣に過負荷用の信号として503（サービス利用不可）応答の送信を使用することです。 503（サービス使用不可）レスポンスを受信した後、送信者はより503（サービス使用不可）応答をトリガーする避けるために、下流の隣人に転送負荷を軽減します。送信者はより503（サービス使用不可）応答が受信された場合の負荷を軽減し続けます。再試行後、ヘッダが完全転送要求を停止するために送信者を必要とするであろうように、この方式は、リトライ後ヘッダ無し503（サービス利用不可）応答の使用に基づいていることに留意されたいです。また、503個の応答が過負荷（例えば、サーバのメンテナンス）以外の理由で発生することができることに留意すべきです。
A sender that has not received 503 (Service Unavailable) responses for a while but is still throttling traffic can start to increase the offered load. By slowly increasing the traffic forwarded, a sender can detect that overload in the downstream neighbor has been resolved and more load can be forwarded. The load is increased until the sender receives another 503 (Service Unavailable) response or is forwarding all requests it has. A possible algorithm for adjusting traffic is additive increase/multiplicative decrease (AIMD).
しばらくの間、503（サービス使用不可）レスポンスを受信していないが、それでもトラフィックを絞るされ、送信者は、提供された負荷を高めるために開始することができます。ゆっくりと転送されたトラフィックを増やすことで、送信者は、川下の隣人でその過負荷が解消されていて、より多くの負荷を転送することができます検出することができます。負荷は送信者が、別の503（サービス使用不可）レスポンスを受信するまで増加させたり、それが持っているすべての要求を転送しています。トラフィックを調整するための可能なアルゴリズムは、添加物の増加/減少乗法（AIMD）です。
Overload signal-based overload control is a sender-based overload control mechanism.
過負荷信号に基づく過負荷制御センダベースの過負荷制御機構です。
On-/off overload control feedback enables a SIP server to turn the traffic it is receiving either on or off. The 503 (Service Unavailable) response with a Retry-After header implements on-/off overload control. On-/off overload control is less effective in controlling load than the fine grained control methods above. All of the above methods can realize on-/off overload control, e.g., by setting the allowed rate to either zero or unlimited.
オン/オフの過負荷制御のフィードバックは、それがオンまたはオフ受信されたトラフィックを有効にするSIPサーバを可能にします。 503（サービス利用不可）応答再試行後、ヘッダは、過負荷制御をオン/オフオン実装で。オン/オフ過負荷制御は、上記のファイングレイン制御方法よりも負荷の制御にあまり効果的です。上記の方法の全ては、ゼロまたは無限のいずれかに許容レートを設定することにより、例えば、オフ/オン過負荷制御を実現することができます。
Implicit overload control ensures that the transmission of a SIP server is self-limiting. It slows down the transmission rate of a sender when there is an indication that the receiving entity is experiencing overload. Such an indication can be that the receiving entity is not responding within the expected timeframe or is not responding at all. The idea of implicit overload control is that senders should try to sense overload of a downstream neighbor even if there is no explicit overload control feedback. It avoids an overloaded server, which has become unable to generate overload control feedback, from being overwhelmed with requests.
暗黙の過負荷制御は、SIPサーバの送信は自己限定的であることを保証します。受信エンティティは、過負荷が発生しているという兆候がある場合には、送信側の伝送速度を遅くします。そのような指示は、受信エンティティが予測期間内に応答しないか、または全く応答しないこととすることができます。暗黙の過負荷制御の考え方は、送信者が明示的な過負荷制御のフィードバックが存在しない場合でも、下流の隣人の過負荷を検知するように試みるべきであるということです。これは、要求に圧倒されることから、過負荷制御フィードバックを生成できなくなったオーバーロードされたサーバーを、避けることができます。
Window-based overload control is inherently self-limiting since a sender cannot continue to pass messages without receiving confirmations. All other explicit overload control schemes described above do not have this property and require additional implicit controls to limit transmissions in case an overloaded downstream neighbor does not generate explicit feedback.
ウィンドウベースの過負荷制御、送信者が確認を受信せずにメッセージを渡すために続けることができないので、本質的に自己制限です。上記の他のすべての明示的な過負荷制御方式は、この性質を持っており、オーバーロードされ、下流の隣人は、明示的なフィードバックを生成しない場合には送信を制限するために追加の暗黙的な制御を必要としません。
An important aspect of the design of an overload control mechanism is the overload control algorithm. The control algorithm determines when the amount of traffic to a SIP server needs to be decreased and when it can be increased. In terms of the model described in Section 4, the control algorithm takes (S) as an input value and generates (T) as a result.
過負荷制御機構の設計の重要な側面は、過負荷制御アルゴリズムです。 SIPサーバへのトラフィックの量が減少する必要がある場合、それを増加させることができるとき、制御アルゴリズムが決定されます。セクション4で説明したモデルの観点から、制御アルゴリズムは、入力値として（S）を取り、結果として（T）を生成します。
Overload control algorithms have been studied to a large extent and many different overload control algorithms exist. With many different overload control algorithms available, it seems reasonable to suggest a baseline algorithm in a specification for a SIP overload control mechanism and allow the use of other algorithms if they provide the same protocol semantics. This will also allow the development of future algorithms, which may lead to better performance. Conversely, the overload control mechanism should allow the use of different algorithms if they adhere to the defined protocol semantics.
過負荷制御アルゴリズムは、大幅に研究されており、多くの異なった過負荷制御アルゴリズムが存在します。多くの異なった過負荷制御アルゴリズムが利用可能で、SIP過負荷制御機構のための仕様で、ベースラインアルゴリズムを提案し、それらが同じプロトコルのセマンティクスを提供する場合、他のアルゴリズムを使用することができるように合理的なようです。これはまた、より良いパフォーマンスにつながる可能性があり、将来のアルゴリズムの開発を可能にします。それらは定義されたプロトコルのセマンティクスに準拠している場合、逆に、過負荷制御機構は、異なるアルゴリズムを使用することを可能にすべきです。
Overload control can require a SIP server to prioritize requests and select requests to be rejected or redirected. The selection is largely a matter of local policy of the SIP server, the overall network, and the services the SIP server provides.
過負荷制御は、要求に優先順位を付け、拒否またはリダイレクトする要求を選択するために、SIPサーバを必要とすることができます。選択は、主にSIPサーバ、ネットワーク全体、およびSIPサーバが提供するサービスのローカルポリシーの問題です。
While there are many factors that can affect the prioritization of SIP requests, the Resource-Priority Header (RPH) field [RFC4412] is a prime candidate for marking the prioritization of SIP requests. Depending on the particular network and the services it offers, a particular namespace and priority value in the RPH could indicate i) a high priority request, which should be preserved if possible during overload, ii) a low priority request, which should be dropped during overload, or iii) a label, which has no impact on message prioritization in this network.
SIPリクエストの優先順位付けに影響を与えることができる多くの要因がありますが、リソース優先ヘッダー（RPH）フィールド[RFC4412]はSIP要求の優先順位付けをマーキングするための最有力候補です。特定のネットワークとそれが提供するサービスに応じて、RPHで特定の名前空間と優先順位値は、Iを示している可能性があり）、可能であれば中に削除する必要があり、過負荷、ⅱ）優先順位の低い要求、中に保存されるべき優先度の高い要求、過負荷、またはこのネットワークにおけるメッセージの優先順位付けに影響を及ぼさないIII）ラベル。
For a number of reasons, responses should not be targeted in order to reduce SIP server load. Responses cannot be rejected and would have to be dropped. This triggers the retransmission of the request plus the response, leading to even more load. In addition, the request associated with a response has already been processed and dropping the response will waste the efforts that have been spent on the request. Most importantly, rejecting a request effectively also removes the request and the response. If no requests are passed along, there will be no responses coming back in return.
多くの理由により、応答がSIPサーバの負荷を軽減するために、対象とすべきではありません。回答は拒否することができないと落下しなければならないであろう。これは、さらに多くの負荷につながる、リクエストプラス応答の再送信をトリガします。また、応答に関連付けられたリクエストはすでに処理されたとの応答をドロップする要求に費やしてきた努力を無駄にします。最も重要なのは、要求を拒否することも効果的要求と応答を削除します。何の要求が一緒に渡されない場合は、リターンに戻って来て何の応答もないでしょう。
Overload control does not change the retransmission behavior of SIP. Retransmissions are triggered using procedures defined in RFC 3261 [RFC3261] and are not subject to throttling.
過負荷制御は、SIPの再送動作を変更しません。再送は、RFC 3261 [RFC3261]で定義された手順を使用して調整を受けないトリガされます。
In addition to the design considerations discussed above, implementations of a SIP overload control mechanism need to take the following operational aspects into consideration. These aspects, while important, are out of scope for this document and are left for further discussion in other documents.
上述の設計上の考慮事項に加えて、SIP過負荷制御機構の実装を考慮に以下の動作態様を取る必要があります。これらの態様は、重要ながら、この文書の範囲外であると、他の文書のさらなる議論のために残されています。
Selection of feedback type: A SIP overload control mechanism can support one or multiple types of explicit overload control feedback. Using a single type of feedback (e.g., loss-based feedback) has the advantage of simplifying the protocol and implementations. Supporting multiple types of feedback (e.g., loss- and rate-based feedback) provides more flexibility; however, it requires a way to select the feedback type used between two servers.
フィードバック方式の選択：SIP過負荷制御機構は、明示的な過負荷制御フィードバックの一つまたは複数のタイプをサポートすることができます。フィードバックの単一のタイプ（例えば、損失ベースのフィードバック）を使用するプロトコル及び実装を単純化するという利点を有します。フィードバック複数のタイプをサポートする（例えば、loss-がレートベースのフィードバック）は、より多くの柔軟性を提供します。しかし、それは2つのサーバー間で使用されるフィードバックの種類を選択するための方法が必要です。
Event reporting: Overload is a serious condition for any network of SIP servers, even if it is handled properly by an overload control mechanism. Overload events should therefore be reported by a SIP server, e.g., through a logging or management interface.
イベント報告：過負荷は、それが過負荷制御機構により、適切に処理されている場合でも、SIPサーバの任意のネットワークのための深刻な状態です。過負荷イベントは、したがって、ロギングまたは管理インターフェースを介して、例えば、SIPサーバによって報告されるべきです。
This document presents an overview of several overload control feedback mechanisms. These mechanisms and design consideration are presented as input to other documents that will specify a particular feedback mechanism. Specific security measures pertinent to a particular overload feedback mechanism will be discussed in the context of a document specifying that security mechanism. However, there are common security considerations that must be taken into account regardless of the choice of a final mechanism.
この文書では、いくつかの過負荷制御フィードバック機構の概要を説明します。これらのメカニズムと設計上の考慮事項は、特定のフィードバック機構を指定します他の文書への入力として提示されています。特定の過負荷フィードバック機構に関連する特定のセキュリティ対策は、セキュリティ・メカニズムを指定する文書の文脈で説明します。しかし、最終的メカニズムの選択にかかわらず、考慮に入れなければならない共通のセキュリティ上の考慮事項があります。
First, the rate-based mechanism surveyed in Section 9.1 allocates a fixed portion of the total inbound traffic of a server to each of its upstream neighbors. Consequently, an attacker can introduce a new upstream server for a short duration, causing the overloaded server to lower the proportional traffic rate to all other existing servers. Introducing many such short-lived servers will cause the aggregate rate arriving at the overloaded server to decrease substantially, thereby affecting a reduction in the service offered by the server under attack and leading to a denial-of-service attack [RFC4732].
まず、セクション9.1で調査レートベースのメカニズムは、その上流の近隣のそれぞれへのサーバの総インバウンドトラフィックの固定部分を割り当てます。その結果、攻撃者は、他のすべての既存のサーバーに比例したトラフィックレートを下げるためにオーバーロードされたサーバーを引き起こし、短い期間のための新しいアップストリームサーバーを導入することができます。このような多くの短命のサーバを導入することにより、攻撃を受けて、サーバが提供するサービスの減少に影響を与えるとDoS攻撃[RFC4732]につながる、過負荷のサーバーに到着集約レートを実質的に低下します。
The same problem exists in the windows-based mechanism discussed in Section 9.3; however, because of the window acknowledgments sent by the overloaded server, the effect is not as drastic (an attacker will have to expend resources by constantly sending traffic to keep the receiver window full).
同じ問題は、9.3項で述べたWindowsベースのメカニズムに存在します。しかし、過負荷のサーバーから送信されたウィンドウの確認応答の、効果は（攻撃者が完全な受信ウィンドウを維持するために常にトラフィックを送信することにより、リソースを消費する必要があります）など抜本的なではありません。
All mechanisms assume that the upstream neighbors of an overloaded server follow the feedback received. In the rate- and window-based mechanisms, a server can directly verify if upstream neighbors follow the requested policies. As the loss-based mechanism described in Section 9.2 requires upstream neighbors to reduce traffic by a fraction and the current offered load in the upstream neighbor is unknown, a server cannot directly verify the compliance of upstream neighbors, except when traffic reduction is set to 100%. In this case, a server has to rely on heuristics to identify upstream neighbors that try to gain an advantage by not reducing load or not reducing it at the requested loss-rate. A policing mechanism can be used to throttle or block traffic from unfair or malicious upstream neighbors. Barring such a widespread policing mechanism, the communication link between the upstream neighbors and the overloaded server should be such that the identity of both the servers at the end of each link can be established and logged. The use of Transport
すべてのメカニズムは、オーバーロード、サーバーの上流ネイバーが受け取ったフィードバックに従うことを前提としています。上流の隣人が要求されたポリシーに従っている場合すべり速度とウィンドウベースのメカニズムでは、サーバが直接確認することができます。 9.2節で説明した損失ベースのメカニズムは、分数でトラフィックを削減するために、上流の隣人を必要とし、上流の隣人で、現在提供され、負荷が不明であるため、サーバが直接トラフィックの減少が100に設定されている場合を除き、上流の隣人の適合性を検証することはできません％。この場合、サーバは負荷を軽減しないか、または要求された損失率でそれを削減しないことで優位性を獲得しようとする上流の隣人を識別するために、経験則に頼らなければなりません。ポリシング機構は、スロットル又は不当または悪意のある上流の隣人からのトラフィックをブロックするために使用することができます。このような広範囲ポリシング機構がなければ、上流の隣人と過負荷サーバとの間の通信リンクは、各リンクの端部におけるサーバの両方のアイデンティティを確立し、ログに記録することができるようなものであるべきです。交通機関の利用
Layer Security (TLS) and mutual authentication of upstream neighbors [RFC3261] [RFC5922] can be used for this purpose.
層セキュリティ（TLS）と上流の隣人[RFC 3261]、[RFC 5922]の相互認証は、この目的のために使用することができます。
If an attacker controls a server, he or she may maliciously advertise overload feedback to all of the neighbors of the server, even if the server is not experiencing overload. This will have the effect of forcing all of the upstream neighbors to reject or queue messages arriving to them and destined for the apparently overloaded server (this, in essence, is diminishing the serving capacity of the upstream neighbors since they now have to deal with their normal traffic in addition to rejecting or quarantining the traffic destined to the overloaded server). All mechanisms allow the attacker to advertise a capacity of 0, effectively disabling all traffic destined to the server pretending to be in overload and forcing all the upstream neighbors to expend resources dealing with this condition.
攻撃者は、サーバーを制御している場合、彼または彼女は悪意を持って、サーバが過負荷を経験していない場合でも、サーバーの隣人のすべてに過負荷フィードバックを広告します。これは、彼らが今、彼らに対処する必要があるため（これは、本質的には、上流の隣人のサービス提供能力を減少さ棄却する上流の隣人のすべてを強制的にまたはキューのメッセージは彼らに到着し、明らかにオーバーロードされたサーバー宛ての効果があります過負荷状態のサーバ宛てのトラフィックを）拒否または隔離に加えて、通常のトラフィック。すべてのメカニズムが効果的に過負荷であることをふりをして、この状況に対処するリソースを消費するために、すべての上流の隣人を強制的にサーバー宛てのすべてのトラフィックを無効にすることを、攻撃者が0の能力を宣伝することができます。
As before, a remedy for this is to use a communication link such that the identity of the servers at both ends of the link is established and logged. The use of TLS and mutual authentication of neighbors [RFC3261] [RFC5922] can be used for this purpose.
前述のように、この治療薬は、リンクの両端でのサーバのアイデンティティが確立され、ログに記録されるように、通信リンクを使用することです。 TLSや近所の相互認証[RFC3261] [RFC5922]の使用は、この目的のために使用することができます。
If an attacker controls several servers of a load-balanced cluster, he or she may maliciously advertise overload feedback from these servers to all senders. Senders with the policy to redirect traffic that cannot be processed by an overloaded server will start to redirect this traffic to the servers that have not reported overload. This attack can be used to create a denial-of-service attack on these servers. If these servers are compromised, the attack can be used to increase the amount of traffic that is passed through the compromised servers. This attack is ineffective if servers reject traffic based on overload feedback instead of redirecting it.
攻撃者は、負荷分散クラスタの複数のサーバを制御している場合、彼または彼女は悪意を持って、すべての送信者にこれらのサーバーから過負荷フィードバックを広告します。オーバーロードされたサーバーで処理できないトラフィックをリダイレクトするためのポリシーを持つ送信者は、過負荷を報告していないサーバにこのトラフィックをリダイレクトするために開始します。この攻撃は、これらのサーバー上のサービス拒否攻撃を作成するために使用することができます。これらのサーバーが侵害された場合、攻撃は危険にさらさサーバを通過するトラフィックの量を増加させることができます。サーバが代わりにそれをリダイレクトの過負荷フィードバックに基づいてトラフィックを拒否した場合、この攻撃は効果がありません。
[Abdelal] Abdelal, A. and W. Matragi, "Signal-Based Overload Control for SIP Servers", 7th Annual IEEE Consumer Communications and Networking Conference (CCNC-10), Las Vegas, Nevada, USA, January 2010.
[Abdelal] Abdelal、A.とW. Matragi、 "SIPサーバー用の信号に基づく過負荷制御"、第7回IEEE消費者コミュニケーションとネットワーキング会議（CCNC-10）、ラスベガス、ネバダ州、アメリカ、2010年1月。
[Hilt] Hilt, V. and I. Widjaja, "Controlling overload in networks of SIP servers", IEEE International Conference on Network Protocols (ICNP'08), Orlando, Florida, October 2008.
[柄]柄、V.およびI. Widjaja、 "SIPサーバのネットワークの制御、過負荷"、ネットワークプロトコル（ICNP'08）、オーランド、フロリダ州、2008年10月にIEEE国際会議。
[Noel] Noel, E. and C. Johnson, "Novel Overload Controls for SIP Networks", International Teletraffic Congress (ITC 21), Paris, France, September 2009.
[ノエル]ノエル、E.およびC.ジョンソンは、 "小説過負荷がSIPネットワークのためのコントロール"、国際トラヒック会議（ITC 21）、パリ、フランス、2009年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[RFC4412] Schulzrinneと、H.とJ.ポーク、 "セッション開始プロトコル（SIP）のための通信リソースプライオリティ"、RFC 4412、2006年2月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]ハンドリー、M.、レスコラ、E.、およびIAB、 "インターネットサービス拒否の注意事項"、RFC 4732、2006年12月。
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", RFC 5390, December 2008.
[RFC5390]ローゼンバーグ、J.、「セッション開始プロトコルにおける過負荷の管理のための要件」、RFC 5390、2008年12月。
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
[RFC5922] Gurbani、V.、ローレンス、S.、およびA.ジェフリー、 "セッション開始プロトコル（SIP）にドメイン証明書"、RFC 5922、2010年6月。
[Shen] Shen, C., Schulzrinne, H., and E. Nahum, "Session Initiation Protocol (SIP) Server Overload Control: Design and Evaluation, Principles", Systems and Applications of IP Telecommunications (IPTComm'08), Heidelberg, Germany, July 2008.
[シェン]シェン、C.、Schulzrinneと、H.、およびE.ナホム、 "セッション開始プロトコル（SIP）サーバー過負荷制御：設計と評価、原則"、システムおよびIP通信（IPTComm'08）、ハイデルベルクの応用、ドイツ、2008年7月。
Appendix A. Contributors
付録A.協力者
Many thanks for the contributions, comments, and feedback on this document to: Mary Barnes (Nortel), Janet Gunn (CSC), Carolyn Johnson (AT&T Labs), Paul Kyzivat (Cisco), Daryl Malas (CableLabs), Tom Phelan (Sonus Networks), Jonathan Rosenberg (Cisco), Henning Schulzrinne (Columbia University), Robert Sparks (Tekelec), Nick Stewart (British Telecommunications plc), Rich Terpstra (Level 3), Fangzhe Chang (Bell Labs/Alcatel-Lucent).
この文書に貢献、コメント、およびフィードバックに感謝：メアリー・バーンズ（ノーテル）、ジャネット・ガン（CSC）、キャロリン・ジョンソン（AT＆T Labs社）、ポール・Kyzivat（シスコ）、ダリル・マラス（CableLabsに）、トム・フェラン（ソナスネットワーク）、ジョナサン・ローゼンバーグ（シスコ）、ヘニングSchulzrinneと（コロンビア大学）、ロバート・スパークス（Tekelec）、ニック・スチュワート（英国電気通信ピーエルシー）、リッチテルプストラ（レベル3）、Fangzheチャン（ベル研究所/アルカテル・ルーセント）。
Authors' Addresses
著者のアドレス
Volker Hilt Bell Labs/Alcatel-Lucent 791 Holmdel-Keyport Rd Holmdel, NJ 07733 USA
フォルカー柄ベル研究所/アルカテル・ルーセント791ホルムデル-KeyportのRdのホルムデル、NJ 07733 USA
EMail: volker.hilt@alcatel-lucent.com
メールアドレス：volker.hilt@alcatel-lucent.com
Eric Noel AT&T Labs
エリック・ノエルAT＆T Labs社
EMail: eric.noel@att.com
メールアドレス：eric.noel@att.com
Charles Shen Columbia University
チャールズ・シェンコロンビア大学
EMail: charles@cs.columbia.edu
メールアドレス：charles@cs.columbia.edu
Ahmed Abdelal Sonus Networks
アーメドAbdall Snousネットワーク
EMail: aabdelal@sonusnet.com
メールアドレス：aabdelal@sonusnet.com