[要約] RFC 6357は、SIPの過負荷制御の設計に関する考慮事項をまとめたものです。その目的は、SIPネットワークの過負荷状態を管理し、サービスの品質を維持するためのガイドラインを提供することです。
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
セッション開始プロトコル（SIP）過負荷制御のための設計上の考慮事項
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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）[RFC3261]サーバーは、受信するSIPメッセージの数が処理できるメッセージの数を超えると過負荷に苦しむ可能性があります。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]に記載されているように、488（ここでは受け入れられない）などの応答を使用して、SIPメッセージを処理する能力が十分にあるが、トランクラインが不足しているがまだ十分な能力を持っている公開された電話ネットワーク（PSTN）ゲートウェイは拒否されるはずです。。同様に、登録データベースへの接続性を失ったが、SIPメッセージを処理できるSIPレジストラは、500（サーバーエラー）応答[RFC3261]でレジスタリクエストを拒否する必要があります。過負荷制御メカニズムはこれらの場合には適用されず、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
SIPサーバーがSIPメッセージの処理を伴わない他のサービスを実行する場合があります（たとえば、RTPパケットの処理、データベースクエリ、ソフトウェアの更新、イベント処理）。これらのサービスは、SIPメッセージボリュームと相関する場合と相関する場合があります。これらのサービスは、サーバーで利用可能なリソースのかなりのシェア（CPUサイクルなど）を使い果たし、すべての着信SIPリクエストを処理できない状態にサーバーを残すことができます。これらの場合、SIPサーバーはSIP過負荷制御メカニズムを適用して、SIPシグナリングプレーンでの輻輳崩壊を回避します。ただし、SIPリクエストの数を制御すると、別のサービスによってリソース不足が作成された場合、サーバーの負荷を大幅に削減できない場合があります。これらの場合、サーバーはのリソース使用量を制御する適切な方法を使用することが予想されます
other services. The specifics of controlling the resource usage of other services and their coordination is out of scope for this document.
他のサービス。他のサービスのリソース使用とそれらの調整を制御する詳細は、このドキュメントの範囲外です。
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（サービスが利用できない）応答コードとRetry-Afterヘッダーを通じて、過負荷制御のための限られたメカニズムを提供します。ただし、このメカニズムはSIPサーバーの過負荷を防ぐことができず、うっ血崩壊を防ぐことはできません。実際、トラフィックが振動し、SIPサーバー間を移動し、それによって過負荷状態が悪化する可能性があります。SIP過負荷の問題、503（サービスなし）応答コードの問題と再試行後のヘッダー、およびSIP過負荷制御メカニズムの要件の詳細な議論は、[RFC5390]に記載されています。さらに、SIPサーバーの過負荷だけでなく、他の状況に503が使用されます。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サーバーによってドロップまたは過度に遅延したメッセージを再送信し、それにより、すでに過負荷のサーバーの提供された負荷を増加させます。この負荷の増加により、過負荷状態の重症度が悪化し、さらに多くのメッセージが削除されます。輻輳崩壊が発生する可能性があります[hilt] [noel] [shen] [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
SIPがトランザクションを成功させるには、SIPサーバーによって最低3つのメッセージを転送する必要があります。多くの場合、招待状のトランザクションは5つ以上のSIPメッセージで構成されています。過負荷のSIPサーバーが評価せずにメッセージをランダムに破棄した場合、トランザクションに属するすべてのメッセージが
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サーバーは、（部分的に）着信メッセージを解析して、既存のトランザクションに属する新しい要求かメッセージかを判断する場合があります。リソースを費やして解析した後に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過負荷制御のもう1つの課題は、真のトラフィックソースのレートを制御することです。多くの場合、過負荷は多数のユーザーエージェント（UAS）によって引き起こされ、それぞれが単一のメッセージのみを作成します。ただし、トラフィックの合計はSIPサーバーに過負荷になる可能性があります。SIPサーバー（レート制御など）の制御に適した過負荷メカニズムは、個々のUAに効果的ではない場合があります。場合によっては、UASから負荷を制限するための他の非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
明示的で暗黙の過負荷制御のアイデアは、実際には補完的です。暗黙の過負荷の表示を考慮することにより、サーバーは反応しないダウンストリーム隣人の過負荷を避けることができます。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プロセッサに関連するリソースの現在の使用を決定するために必要なメカニズムを実装し、制御機能にロードサンプルを報告します。
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.
制御関数：制御関数は、過負荷制御アルゴリズムを実装します。制御関数は負荷サンプルを使用し、過負荷が発生したかどうかを判断し、受信エンティティのSIPプロセッサに送信される負荷を調整するためにスロットル（T）を設定する必要があります。受信エンティティの制御関数は、送信エンティティに負荷フィードバック（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）、受信エンティティに転送されるトラフィックの量がスロットルの基準を満たすことを保証します。たとえば、スロットルは、1秒あたり100を超える招待メッセージを転送しないようにアクチュエーターに指示する場合があります。アクチュエータは、この目的を達成するためにアルゴリズムを実装します。たとえば、メッセージギャップを使用します。また、アルゴリズムを実装して、影響を受けるメッセージを選択し、拒否されるかリダイレクトされているかを決定します。
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.,
図1は、過負荷制御の一般的なシステムモデルを示しています。この図では、制御関数の1つの例は送信エンティティ（つまり、アクチュエーターに関連付けられている）にあり、1つは受信エンティティ（つまり、モニターに関連付けられています）にあります。ただし、特定のメカニズムは両方の要素を必要としない場合があります。この場合、2つの制御関数要素の1つは空になり、単純にフィードバックに沿って渡すことができます。たとえば、（f）が損失率として定義されている場合（例えば、
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).
トラフィックを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、サーバーAまでの両方向に流れます。各方向の過負荷制御メカニズムは、独立して考慮することができます。サーバー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
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
ホップバイホップの過負荷制御のアイデアは、トラフィックを直接交換する近隣のすべてのSIPサーバー間で個別の制御ループをインスタンス化することです。つまり、アクチュエータは、対応するモニターを備えたSIPサーバーの直接上流の隣人であるSIPサーバーにあります。2つのサーバー間の各コントロールループは、他のサーバー間のコントロールループから完全に独立しています。図2（a）の例では、3つの独立した過負荷制御ループがインスタンス化されています：a -b、b -c、およびb -D。各ループは単一のホップのみを制御します。下流の隣人から受け取った過負荷フィードバックは、さらに上流に転送されません。代わりに、SIPサーバーは、たとえば、必要に応じてSIPメッセージを拒否することにより、このフィードバックに基づいて動作します。サーバーの上流の隣人も過負荷になった場合、この問題をそのに報告します
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ホップを配置するエンティティを関与させる必要なく、オーバーロードサーバーの直接上流の近隣によって常に過負荷が解決されます。
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リクエストのパス全体に沿って過負荷制御ループを実装します。エンドツーエンドの過負荷制御メカニズムは、途中のすべてのSIPサーバーからの過負荷情報（すべてのプロキシとUASを含む）を統合し、この情報を使用して、可能な限り上流のトラフィックをスロットルするために使用します。エンドツーエンドの過負荷制御メカニズムは、潜在的なパス上のすべてのサーバーの過負荷ステータスを宛先に頻繁に収集し、このデータを意味のある過負荷フィードバックに結合できる必要があります。
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サーバーは、これらのリクエストが最終的に過負荷サーバーに転送されることを知っている場合、リクエストのみをスロットルします。たとえば、図2（b）でDが過負荷になっている場合、Aは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メッセージ（たとえば、サブスクライブと同じSIP URIへの招待メッセージ）を異なる宛先にルーティングできます。これは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からトラフィックを受信します。ロードバランサーは、このような構成の典型的な例です。この構成では、過負荷制御がサーバーA（つまり、ロードバランサー）が下流の隣人D、E、Fのいずれかにトラフィックを送信しすぎないようにする必要があります。まだ容量を持っているサーバー。サーバーのいずれかがバックアップとして機能する場合、プライマリサーバーの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に代わってオーバーロードをアップストリームに報告することを選択できます。固定されていないか、一部のみが過負荷になっている場合、オーバーロードコントロールをアクティブにしないでください。これらの要求は、上流の隣人に過負荷制御を使用する場合、同様にスロットされます。
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は、メッセージ内のサーバーファーム（つまり、仮想サーバーの負荷）の全体的な負荷を報告できます。別の方法として、サーバーの1つ（たとえば、サーバー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は、複数の上流のソースA、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
Dが過負荷になった場合、上流の隣人から受け取るトラフィックの量を減らすためにフィードバックを生成する必要があります。Dは、各上流の隣人がトラフィックをどれだけ削減するかを決定する必要があります。この決定には、トラフィックの量を考慮する必要があります
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は、ローカル公平性ポリシーを使用して、各上流の隣人から受け入れるトラフィックの量を判断できます。
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サーバーが「メッシュ」を形成します。ここでは、複数の上流サーバーA、B、およびCのトラフィックを複数の代替サーバーDおよびEに転送します。この構成は、「ロードバランサー」と「複数のソース」シナリオの組み合わせです。
+---+ +---+
/->| 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）に示します。多くのUASに接続されているエッジプロキシは、このような構成の典型的な例です。各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（サービスが利用できない）を徐々に減らすことができます。Retry-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.
注：「Edge Proxy」トポロジの要件は、他のトポロジの要件とは異なり、過負荷制御には異なる方法が必要になる場合があります。
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サーバーの過負荷のコンテキストでは、2つのカテゴリの公平性を説明することが役立ちます。基本的な公平性とカスタマイズされた公平性です。基本的な公平性により、SIPサーバーはすべてのリクエストを均等に扱い、各リクエストが同じ成功する可能性を確保します。カスタマイズされた公平性により、サーバーは異なる優先順位に応じてリソースを割り当てます。基本的な公平性基準の適用の例は、「3番目の発信者が無料のチケットを受信する」シナリオです。各コール試行は、通話が開始されたサービスプロバイダーに関係なく、過負荷の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
重要なパフォーマンスインジケーターは、過負荷中のSIPサーバーのグッドプットです。理想的には、SIPサーバーが過負荷の期間中に最大容量で実行できるようになります。たとえば、SIPサーバーに1秒あたり140の招待トランザクションの処理能力がある場合、オーバーロード制御メカニズムにより、提供された負荷がはるかに高い場合でも、1秒あたり140の招待状を処理できるようになります。SIPサーバーによって導入された遅延は、もう1つの重要な指標です。過負荷制御メカニズムは、次のことを確認する必要があります
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メッセージのタイムアウトや再送信につながる可能性があり、過負荷が悪化します。
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過負荷制御メカニズムのパフォーマンスは、[Noel]、[Shen]、[Hilt]、および[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.
明示的な過負荷制御フィードバックにより、受信者は受け取りたいトラフィックの量を示すことができます。明示的な過負荷制御メカニズムは、過負荷制御フィードバックで伝えられる情報の種類と、制御機能が受信または送信エンティティ（受信と送信者ベースの過負荷制御）、またはその両方に基づいて区別できます。
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
レートベースの過負荷制御の重要なアイデアは、上流の要素が下流の隣人にトラフィックを転送できる要求レートを制限することです。過負荷が発生した場合、SIPサーバーが指示します
each upstream neighbor to send, at most, X requests per second. Each upstream neighbor can be assigned a different rate cap.
上流の各隣人は、せいぜいxリクエストを1秒あたりに送信します。各上流の隣人には、異なるレートキャップを割り当てることができます。
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のレートを割り当てることができます。3番目の送信者が表示されると、各送信者のレートが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,
各上流の隣人のレートキャップを推定するためのアプローチは、コントロール変数Xの固定割合を使用しています。Xは最初はSIPサーバーの容量に等しくなります。その後、サーバーは、ワークロードの到着率が実際のサーバー容量と一致するまでXを増加または減少させます。通常、これは、サーバー（= x）から送信されるレートキャップの合計が実際の容量を超えることを意味します。
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.
しかし、作業の公平なシェアを生み出していない上流の隣人は、効果的に無制限になることを可能にします。このアプローチでは、サーバーは集計到着率を測定するだけで済みます。ただし、通常、レートキャップ全体は実際の容量よりも高いため、過負荷の短い期間が発生する可能性があります。
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.
損失率により、SIPサーバーは、上流の隣人に通常このサーバーに転送されるリクエストの数をx％削減するように依頼することができます。たとえば、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（試行）応答は通常、招待リクエストのためにのみ作成されます。明示的なメッセージ確認にはこれらの問題はありません。
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
オン/オフオーバーロード制御フィードバックにより、SIPサーバーがオンまたはオフになっているトラフィックを回すことができます。再試行後のヘッダーを使用した503（サービスは利用できない）応答は、オン/オフ過負荷制御を実装します。オン/オフ過負荷制御は、上記の細かい粒子制御方法よりも負荷の制御にあまり効果的ではありません。すべての
the above methods can realize on-/off overload control, e.g., by setting the allowed rate to either zero or unlimited.
上記の方法は、許容率をゼロまたは無制限に設定することにより、オン/オフ過負荷制御を実現できます。
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で説明されているモデルに関しては、コントロールアルゴリズムは入力値として使用し、結果として（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過負荷制御メカニズムは、1つまたは複数のタイプの明示的な過負荷制御フィードバックをサポートできます。単一のタイプのフィードバック（損失ベースのフィードバックなど）を使用すると、プロトコルと実装を簡素化するという利点があります。複数の種類のフィードバック（損失およびレートベースのフィードバックなど）をサポートすることで、柔軟性が向上します。ただし、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で調査されたレートベースのメカニズムは、サーバーの合計インバウンドトラフィックの固定部分を各上流の隣人に割り当てます。その結果、攻撃者は短時間新しいアップストリームサーバーを導入し、過負荷のサーバーが他のすべての既存のサーバーに比例交通率を下げることができます。このような短命のサーバーの多くを導入すると、過負荷に及ぶサーバーに到着する集計レートが大幅に減少し、それにより、攻撃下でサーバーが提供するサービスの減少に影響を与え、サービス拒否攻撃につながります[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に設定されている場合を除き、上流の隣接者のコンプライアンスを直接確認することはできません。 ％。この場合、サーバーはヒューリスティックに依存して、荷重を減らしないか、要求された損失率でそれを減らしないことで利点を獲得しようとする上流の隣人を特定する必要があります。ポリシングメカニズムを使用して、不公平または悪意のある上流の隣人からトラフィックをスロットルまたはブロックすることができます。このような広範なポリシングメカニズムを除けば、上流の近隣サーバーとオーバーロードされたサーバーの間の通信リンクは、各リンクの最後にある両方のサーバーのIDを確立して記録できるようにする必要があります。輸送の使用
Layer Security (TLS) and mutual authentication of upstream neighbors [RFC3261] [RFC5922] can be used for this purpose.
この目的には、上流の隣接者[RFC3261] [RFC5922]のレイヤーセキュリティ（TLS）と相互認証を使用できます。
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.
前と同様に、このための救済策は、リンクの両端にあるサーバーのIDが確立され、記録されるように通信リンクを使用することです。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.
[Hilt] Hilt、V。およびI. Widjaja、「SIPサーバーのネットワークの過負荷の制御」、IEEE Network Protocolsに関する国際会議（ICNP'08）、フロリダ州オーランド、2008年10月。
[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] Postel、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、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. Polk、「セッション開始プロトコル（SIP）の通信リソースの優先順位」、RFC 4412、2006年2月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732] Handley、M.、Rescorla、E。、およびIAB、「インターネット拒否権に関する考慮事項」、RFC 4732、2006年12月。
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", RFC 5390, December 2008.
[RFC5390] Rosenberg、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.、Lawrence、S。、およびA. Jeffrey、「セッション開始プロトコル（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.
[Shen] Shen、C.、Schulzrinne、H。、およびE. Nahum、「セッション開始プロトコル（SIP）サーバーの過負荷制御：設計と評価、原則」、IPテレコミュニケーションのシステムとアプリケーション（IPTCOMM'08）、Heidelberg、ドイツ、2008年7月。
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ラボ）、ポール・キジバット（シスコ）、ダリル・マラス（ケーブルラブ）、トム・フェラン（ソヌス（ソヌス）への貢献、コメント、フィードバックに感謝します。ネットワーク）、ジョナサン・ローゼンバーグ（シスコ）、ヘニング・シュルツリン（コロンビア大学）、ロバート・スパークス（テケレック）、ニック・スチュワート（イギリス・テレコミューナリPLC）、リッチ・テープストラ（レベル3）、ファンツェ・チャン（ベル・ラボ/アルカテル・ルーセント）。
Authors' Addresses
著者のアドレス
Volker Hilt Bell Labs/Alcatel-Lucent 791 Holmdel-Keyport Rd Holmdel, NJ 07733 USA
Volker Hilt Bell Labs/Alcatel-Lucent 791 Holmdel-Keyport Rd Holmdel、NJ 07733 USA
EMail: volker.hilt@alcatel-lucent.com
Eric Noel AT&T Labs
エリック・ノエルAT＆Tラボ
EMail: eric.noel@att.com
Charles Shen Columbia University
チャールズシェンコロンビア大学
EMail: charles@cs.columbia.edu
Ahmed Abdelal Sonus Networks
アーメドアブデラルソヌスネットワーク
EMail: aabdelal@sonusnet.com