[要約] RFC 5390は、Session Initiation Protocol（SIP）における過負荷の管理に関する要件を定義しています。その目的は、SIPネットワークでの過負荷状態を制御し、通信の品質と信頼性を向上させることです。
Network Working Group J. Rosenberg
Request for Comments: 5390 Cisco
Category: Informational December 2008
Requirements for Management of Overload in the Session Initiation Protocol
セッション開始プロトコルにおける過負荷の管理の要件
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2008 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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insufficient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This document summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution.
過負荷は、プロキシとユーザーエージェントがリクエストの処理を完了するためにリソースが不十分な場合、セッション開始プロトコル（SIP）ネットワークで発生します。SIPは、503の応答コードを介した過負荷処理の限定的なサポートを提供します。これにより、上流の要素が過負荷になっていることがわかります。ただし、このメカニズムでは多くの問題が特定されています。このドキュメントは、既存の503メカニズムの問題を要約し、ソリューションにいくつかの要件を提供します。
Table of Contents
目次
1. Introduction ....................................................2
2. Causes of Overload ..............................................2
3. Terminology .....................................................4
4. Current SIP Mechanisms ..........................................4
5. Problems with the Mechanism .....................................5
5.1. Load Amplification .........................................5
5.2. Underutilization ...........................................9
5.3. The Off/On Retry-After Problem .............................9
5.4. Ambiguous Usages ..........................................10
6. Solution Requirements ..........................................10
7. Security Considerations ........................................13
8. Acknowledgements ...............................................13
9. References .....................................................14
9.1. Normative Reference .......................................14
9.2. Informative References ....................................14
Overload occurs in Session Initiation Protocol (SIP) [RFC3261] networks when proxies and user agents have insufficient resources to complete the processing of a request or a response. SIP provides limited support for overload handling through its 503 response code. This code allows a server to tell an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism.
過負荷は、セッション開始プロトコル（SIP）[RFC3261]ネットワークで発生し、プロキシとユーザーエージェントがリクエストまたは応答の処理を完了するためにリソースが不十分な場合。SIPは、503の応答コードを介した過負荷処理のサポートが限られています。このコードにより、サーバーは上流の要素に過負荷になっていることを伝えることができます。ただし、このメカニズムでは多くの問題が特定されています。
This document describes the general problem of SIP overload and reviews the current SIP mechanisms for dealing with overload. It then explains some of the problems with these mechanisms. Finally, the document provides a set of requirements for fixing these problems.
このドキュメントでは、SIP過負荷の一般的な問題について説明し、過負荷に対処するための現在のSIPメカニズムを確認します。次に、これらのメカニズムの問題のいくつかを説明します。最後に、ドキュメントはこれらの問題を修正するための一連の要件を提供します。
Overload occurs when an element, such as a SIP user agent or proxy, has insufficient resources to successfully process all of the traffic it is receiving. Resources include all of the capabilities of the element used to process a request, including CPU processing, memory, I/O, or disk resources. It can also include external resources such as a database or DNS server, in which case the CPU, processing, memory, I/O, and disk resources of those servers are effectively part of the logical element processing the request. Overload can occur for many reasons, including: Poor Capacity Planning: SIP networks need to be designed with sufficient numbers of servers, hardware, disks, and so on, in order to meet the needs of the subscribers they are expected to serve. Capacity planning is the process of determining these needs. It is based on the number of expected subscribers and the types of flows they are expected to use. If this work is not done properly, the network may have insufficient capacity to handle predictable usages, including regular usages and predictably high ones (such as high voice calling volumes on Mother's Day).
過負荷は、SIPユーザーエージェントやプロキシなどの要素が、受信しているすべてのトラフィックを正常に処理するためのリソースが不十分な場合に発生します。リソースには、CPU処理、メモリ、I/O、またはディスクリソースなど、リクエストの処理に使用される要素のすべての機能が含まれます。また、データベースやDNSサーバーなどの外部リソースを含めることもできます。この場合、これらのサーバーのCPU、処理、メモリ、I/O、およびディスクリソースは、リクエストの論理要素の処理の一部です。容量の低い計画：SIPネットワークは、サービスを提供する予想される購読者のニーズを満たすために、十分な数のサーバー、ハードウェア、ディスクなどで設計する必要があります。容量計画は、これらのニーズを決定するプロセスです。これは、予想される加入者の数と、使用する予定のフローの種類に基づいています。この作業が適切に行われていない場合、ネットワークは、通常の使用法や予想上の高い使用法（母の日の高い音声通話量など）を含む予測可能な使用型を処理する能力が不十分な場合があります。
Dependency Failures: A SIP element can become overloaded because a resource on which it is dependent has failed or become overloaded, greatly reducing the logical capacity of the element. In these cases, even minimal traffic might cause the server to go into overload. Examples of such dependency overloads include DNS servers, databases, disks, and network interfaces.
依存関係の障害：SIP要素が依存しているリソースが失敗したり過負荷になったりして、要素の論理容量を大幅に減らすため、SIP要素が過負荷になる可能性があります。これらの場合、トラフィックを最小限に抑えても、サーバーが過負荷になる可能性があります。このような依存関係の過負荷の例には、DNSサーバー、データベース、ディスク、ネットワークインターフェイスが含まれます。
Component Failures: A SIP element can become overloaded when it is a member of a cluster of servers that each share the load of traffic, and one or more of the other members in the cluster fail. In this case, the remaining elements take over the work of the failed elements. Normally, capacity planning takes such failures into account, and servers are typically run with enough spare capacity to handle failure of another element. However, unusual failure conditions can cause many elements to fail at once. This is often the case with software failures, where a bad packet or bad database entry hits the same bug in a set of elements in a cluster.
コンポーネントの障害：SIP要素は、それぞれがトラフィックの負荷を共有するサーバーのクラスターのメンバーであり、クラスター内の他のメンバーの1つ以上が失敗すると、オーバーロードされる可能性があります。この場合、残りの要素は失敗した要素の作業を引き継ぎます。通常、容量計画はそのような障害を考慮し、通常、別の要素の故障を処理するのに十分な予備の容量でサーバーが実行されます。ただし、異常な障害条件により、多くの要素が一度に失敗する可能性があります。これは、多くの場合、ソフトウェアの障害にも当てはまります。このパケットまたは不良なデータベースエントリがクラスター内の一連の要素で同じバグにヒットします。
Avalanche Restart: One of the most troubling sources of overload is avalanche restart. This happens when a large number of clients all simultaneously attempt to connect to the network with a SIP registration. Avalanche restart can be caused by several events. One is the "Manhattan Reboots" scenario, where there is a power failure in a large metropolitan area, such as Manhattan. When power is restored, all of the SIP phones, whether in PCs or standalone devices, simultaneously power on and begin booting. They will all then connect to the network and register, causing a flood of SIP REGISTER messages. Another cause of avalanche restart is failure of a large network connection, for example, the access router for an enterprise. When it fails, SIP clients will detect the failure rapidly using the mechanisms in [OUTBOUND]. When connectivity is restored, this is detected, and clients re-REGISTER, all within a short time period. Another source of avalanche restart is failure of a proxy server. If clients had all connected to the server with TCP, its failure will be detected, followed by re-connection and re-registration to another server. Note that [OUTBOUND] does provide some remedies to this case.
雪崩の再起動：最も厄介な過負荷源の1つは、雪崩の再起動です。これは、多数のクライアントがすべて同時にSIP登録でネットワークに接続しようとしたときに起こります。雪崩の再起動は、いくつかのイベントによって引き起こされる可能性があります。1つは「マンハッタンの再起動」シナリオで、マンハッタンなどの大都市圏で停電が発生しています。電源が復元されると、すべてのSIP電話は、PCSであろうとスタンドアロンデバイスであろうと、同時に電源を入れて起動を開始します。その後、すべてネットワークに接続してレジスタが発生し、SIPレジスタメッセージの洪水が発生します。雪崩の再起動のもう1つの原因は、たとえばエンタープライズのアクセスルーターなど、大きなネットワーク接続の障害です。失敗すると、SIPクライアントは[アウトバウンド]のメカニズムを使用して障害を迅速に検出します。接続性が回復すると、これは検出され、クライアントはすべて短期間で再登録されます。雪崩の再起動のもう1つのソースは、プロキシサーバーの障害です。クライアントがすべてTCPを使用してサーバーに接続されていた場合、その障害が検出され、その後、再接続と別のサーバーへの再登録が行われます。[アウトバウンド]は、このケースにいくつかの救済策を提供していることに注意してください。
Flash Crowds: A flash crowd occurs when an extremely large number of users all attempt to simultaneously make a call. One example of how this can happen is a television commercial that advertises a number to call to receive a free gift. If the gift is compelling and many people see the ad, many calls can be simultaneously made to the same number. This can send the system into overload.
フラッシュクラウド：フラッシュクラウドは、非常に多くのユーザー全員が同時に電話をかけようとすると発生します。これがどのように起こるかの1つの例は、無料の贈り物を受け取るために電話する番号を宣伝するテレビコマーシャルです。贈り物が説得力があり、多くの人が広告を見る場合、多くの電話を同時に同じ番号に作成できます。これにより、システムが過負荷になる可能性があります。
Denial of Service (DoS) Attacks: An attacker, wishing to disrupt service in the network, can cause a large amount of traffic to be launched at a target server. This can be done from a central source of traffic or through a distributed DoS attack. In all cases, the volume of traffic well exceeds the capacity of the server, sending the system into overload.
サービス拒否（DOS）攻撃：ネットワークでのサービスを混乱させたい攻撃者は、ターゲットサーバーで大量のトラフィックを起動する可能性があります。これは、中央のトラフィックソースから、または分散型DOS攻撃を通じて行うことができます。すべての場合において、トラフィックの量はサーバーの容量を大きく超えて、システムを過負荷にします。
Unfortunately, the overload problem tends to compound itself. When a network goes into overload, this can frequently cause failures of the elements that are trying to process the traffic. This causes even more load on the remaining elements. Furthermore, during overload, the overall capacity of functional elements goes down, since much of their resources are spent just rejecting or treating load that they cannot actually process. In addition, overload tends to cause SIP messages to be delayed or lost, which causes retransmissions to be sent, further increasing the amount of work in the network. This compounding factor can produce substantial multipliers on the load in the system. Indeed, in the case of UDP, with as many as seven retransmits of an INVITE request prior to timeout, overload can multiply the already-heavy message volume by as much as seven!
残念ながら、過負荷の問題はそれ自体を悪化させる傾向があります。ネットワークが過負荷になると、これにより、トラフィックを処理しようとしている要素の故障が頻繁に発生する可能性があります。これにより、残りの要素にさらに負荷がかかります。さらに、過負荷中に、機能的要素の全体的な容量は低下します。なぜなら、リソースの多くは、実際に処理できない負荷を拒否または処理するだけで費やされるからです。さらに、過負荷はSIPメッセージを遅延または紛失する傾向があり、これにより再送信が送信され、ネットワーク内の作業量がさらに増加します。この複合因子は、システムの負荷にかなりの乗数を生成できます。確かに、UDPの場合、タイムアウトの前に招待リクエストの7つの再送信があるため、過負荷は既に重いメッセージボリュームに最大7つを掛けることができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
SIP provides very basic support for overload. It defines the 503 response code, which is sent by an element that is overloaded. RFC 3261 defines it thus:
SIPは、過負荷の非常に基本的なサポートを提供します。過負荷の要素によって送信される503応答コードを定義します。RFC 3261はそれを定義します：
The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server MAY indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response.
サーバーは、サーバーの一時的な過負荷またはメンテナンスにより、一時的にリクエストを処理できません。サーバーは、クライアントがいつ再試行ヘッダーフィールドでリクエストを再試行するかを示す場合があります。再試行後の場合、クライアントは500（サーバー内部エラー）応答を受け取ったかのように動作する必要があります。
A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present.
503（サービスが利用できない）を受信するクライアント（プロキシまたはUAC）は、リクエストを代替サーバーに転送しようとする必要があります。存在する場合、再試行後ヘッダーフィールドで指定された期間、そのサーバーに他のリクエストを転送しないでください。
Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable).
サーバーは、503で応答する代わりに、接続を拒否したり、リクエストをドロップしたりする場合があります（サービスは利用できません）。
The objective is to provide a mechanism to move the work of the overloaded server to another server so that the request can be processed. The Retry-After header field, when present, is meant to allow a server to tell an upstream element to back off for a period of time, so that the overloaded server can work through its backlog of work.
目的は、要求を処理できるように、過負荷サーバーの作業を別のサーバーに移動するメカニズムを提供することです。再試行後のヘッダーフィールドは、存在する場合、サーバーが上流の要素を一定期間バックオフするように指示できるようにするために、過負荷のサーバーが作業のバックログを通じて動作できるようにします。
RFC 3261 also instructs proxies to not forward 503 responses upstream, at SHOULD NOT strength. This is to avoid the upstream server of mistakingly concluding that the proxy is overloaded when, in fact, the problem was an element further downstream.
RFC 3261は、上流では503回の応答を転送しないようにプロキシに指示します。これは、実際に問題がさらに下流の要素であった場合、プロキシが過負荷になっていると誤って結論付ける上流サーバーを回避するためです。
At the surface, the 503 mechanism seems workable. Unfortunately, this mechanism has had numerous problems in actual deployment. These problems are described here.
表面では、503メカニズムは実行可能と思われます。残念ながら、このメカニズムは実際の展開に多くの問題を抱えています。これらの問題はここで説明されています。
The principal problem with the 503 mechanism is that it tends to substantially amplify the load in the network when the network is overloaded, causing further escalation of the problem and introducing the very real possibility of congestive collapse. Consider the topology in Figure 1.
503メカニズムの主な問題は、ネットワークが過負荷になったときにネットワークの負荷を大幅に増幅する傾向があり、問題のさらなるエスカレーションを引き起こし、うっ血性崩壊の非常に現実的な可能性を導入することです。図1のトポロジを考えてください。
+------+
> | |
/ | S1 |
/ | |
/ +------+
/
/
/
/
+------+ / +------+
--------> | |/ | |
| P1 |---------> | S2 |
--------> | |\ | |
+------+ \ +------+
\
\
\
\
\
\ +------+
\ | |
> | S3 |
| |
+------+
Figure 1
図1
Proxy P1 receives SIP requests from many sources and acts solely as a load balancer, proxying the requests to servers S1, S2, and S3 for processing. The input load increases to the point where all three servers become overloaded. Server S1, when it receives its next request, generates a 503. However, because the server is loaded, it might take some time to generate the 503. If SIP is being run over UDP, this may result in request retransmissions, which further increase the work on S1. Even in the case of TCP, if the server is loaded and the kernel cannot send TCP acknowledgements fast enough, TCP retransmits may occur. When the 503 is received by P1, it retries the request on S2. S2 is also overloaded and eventually generates a 503, but in the interim may also be hit with retransmits. P1 once again tries another server, this time S3, which also eventually rejects it with a 503.
Proxy P1は、多くのソースからSIPリクエストを受け取り、ロードバランサーとしてのみ機能し、処理のためにサーバーS1、S2、およびS3へのリクエストをプロキシングします。入力負荷は、3つのサーバーすべてが過負荷になるポイントに増加します。サーバーS1は、次のリクエストを受信すると503が生成されます。ただし、サーバーがロードされているため、503を生成するのに時間がかかる場合があります。SIPがUDPで実行されている場合、リクエストの再送信が発生する可能性があります。S1の作業。TCPの場合でも、サーバーが読み込まれ、カーネルがTCP謝辞を十分に速く送信できない場合、TCP再送信が発生する可能性があります。503がP1によって受信されると、S2のリクエストを取得します。S2も過負荷になり、最終的には503を生成しますが、暫定的には再送信に衝突する可能性があります。P1は再び別のサーバーを試します。今回はS3で、最終的には503で拒否します。
Thus, the processing of this request, which ultimately failed, involved four SIP transactions (client to P1, P1 to S1, P1 to S2, P1 to S3), each of which may have involved many retransmissions -- up to seven in the case of UDP. Thus, under unloaded conditions, a single request from a client would generate one request (to S1, S2, or S3) and two responses (from S1 to P1, then P1 to the client). When the network is overloaded, a single request from the client, before timing out, could generate as many as 18 requests and as many responses when UDP is used! The situation is better with TCP (or any reliable transport in general), but even if there was never a TCP segment retransmitted, a single request from the client can generate three requests and four responses. Each server had to expend resources to process these messages. Thus, more messages and more work were sent into the network at the point at which the elements became overloaded. The 503 mechanism works well when a single element is overloaded. But when the problem is overall network load, the 503 mechanism actually generates more messages and more work for all servers, ultimately resulting in the rejection of the request anyway.
したがって、最終的に失敗したこの要求の処理には、4つのSIPトランザクション（クライアントからP1、P1からS1、P1からS2、P1からS3）が含まれます。UDPの。したがって、アンロードされた条件下では、クライアントからの単一の要求が1つの要求（S1、S2、またはS3へ）と2つの応答（S1からP1へ、次にP1にクライアントに）を生成します。ネットワークがオーバーロードされると、タイミングを出す前にクライアントからの単一のリクエストが18回ものリクエストを生成し、UDPが使用されると同数の応答を生成できます。TCP（または一般的な信頼できる輸送）で状況はより良くなりますが、TCPセグメントが再送信されたことがない場合でも、クライアントからの単一の要求は3つの要求と4つの応答を生成できます。各サーバーは、これらのメッセージを処理するためにリソースを消費する必要がありました。したがって、要素が過負荷になった時点で、より多くのメッセージとより多くの作業がネットワークに送信されました。503メカニズムは、単一の要素が過負荷になっている場合にうまく機能します。しかし、問題が全体的なネットワークロードである場合、503メカニズムは実際にすべてのサーバーに対してより多くのメッセージとより多くの作業を生成し、最終的にはとにかくリクエストを拒否します。
The problem becomes amplified further if one considers proxies upstream from P1, as shown in Figure 2.
図2に示すように、P1から上流のプロキシを考慮すると、問題はさらに増幅されます。
+------+
> | | <
/ | S1 | \\
/ | | \\
/ +------+ \\
/ \
/ \\
/ \\
/ \
+------+ / +------+ +------+
| | / | | | |
| P1 | ---------> | S2 |<----------| P2 |
| | \ | | | |
+------+ \ +------+ +------+
^ \ / ^
\ \ // /
\ \ // /
\ \ // /
\ \ / /
\ \ +------+ // /
\ \ | | // /
\ > | S3 | < /
\ | | /
\ +------+ /
\ /
\ /
\ /
\ /
\ /
\ /
\ /
\ /
+------+
| |
| PA |
| |
+------+
^ ^
| |
| |
Figure 2
図2
Here, proxy PA receives requests and sends these to proxies P1 or P2. P1 and P2 both load balance across S1 through S3. Assuming again S1 through S3 are all overloaded, a request arrives at PA, which tries P1 first. P1 tries S1, S2, and then S3, and each transaction results in many request retransmits if UDP is used. Since P1 is unable to eventually process the request, it rejects it. However, since all of its downstream dependencies are busy, it decides to send a 503. This propagates to PA, which tries P2, which tries S1 through S3 again, resulting in a 503 once more. Thus, in this case, we have doubled the number of SIP transactions and overall work in the network compared to the previous case. The problem here is that the fact that S1 through S3 were overloaded was known to P1, but this information was not passed back to PA and through to P2, so that P2 retries S1 through S3 again.
ここで、プロキシPAはリクエストを受け取り、これらをプロキシP1またはP2に送信します。P1とP2は両方とも、S1からS3の負荷バランスです。S1からS3がすべて過負荷になっていると仮定すると、リクエストがPAに到着し、最初にP1を試みます。P1はS1、S2、およびS3を試み、各トランザクションはUDPを使用する場合、多くのリクエスト再送信をもたらします。P1は最終的にリクエストを処理できないため、拒否します。ただし、その下流の依存関係はすべてビジーであるため、503を送信することにしました。これはPAに伝播します。これにより、S1からS3を再び試み、503が再び503になります。したがって、この場合、以前のケースと比較して、ネットワークでのSIPトランザクションの数と全体的な作業を2倍にしました。ここでの問題は、S1からS3からS3が過負荷になったという事実がP1に知られているが、この情報はPAに戻さず、P2に渡されたため、P2はS1からS3を再び回収することです。
Interestingly, there are also examples of deployments where the network capacity was greatly reduced as a consequence of the overload mechanism. Consider again Figure 1. Unfortunately, RFC 3261 is unclear on the scope of a 503. When it is received by P1, does the proxy cease sending requests to that IP address? To the hostname? To the URI? Some implementations have chosen the hostname as the scope. When the hostname for a URI points to an SRV record in the DNS, which, in turn, maps to a cluster of downstream servers (S1, S2, and S3 in the example), a 503 response from a single one of them will make the proxy believe that the entire cluster is overloaded. Consequently, proxy P1 will cease sending any traffic to any element in the cluster, even though there are elements in the cluster that are underutilized.
興味深いことに、過負荷メカニズムの結果としてネットワーク容量が大幅に減少した展開の例もあります。もう一度図1.残念ながら、RFC 3261は503の範囲で不明です。P1が受信した場合、プロキシはそのIPアドレスへのリクエストの送信をやめますか？ホスト名に？URIに？いくつかの実装は、ホスト名をスコープとして選択しています。URIのホスト名がDNSのSRVレコードを指している場合、これにより、下流サーバーのクラスター（例のS1、S2、およびS3）のクラスターにマップすると、単一の1つから503の応答が作成されます。プロキシは、クラスター全体が過負荷になっていると考えています。その結果、プロキシP1は、クラスター内に十分に活用されている要素があるにもかかわらず、クラスター内の要素にトラフィックを送信するのをやめます。
The Retry-After mechanism allows a server to tell an upstream element to stop sending traffic for a period of time. The work that would have otherwise been sent to that server is instead sent to another server. The mechanism is an all-or-nothing technique. A server can turn off all traffic towards it, or none. There is nothing in between. This tends to cause highly oscillatory behavior under even mild overload. Consider a proxy P1 that is balancing requests between two servers S1 and S2. The input load just reaches the point where both S1 and S2 are at 100% capacity. A request arrives at P1 and is sent to S1. S1 rejects this request with a 503, and decides to use Retry-After to clear its backlog. P1 stops sending all traffic to S1. Now, S2 gets traffic, but it is seriously overloaded -- at 200% capacity! It decides to reject a request with a 503 and a Retry-After, which now forces P1 to reject all traffic until S1's Retry-After timer expires. At that point, all load is shunted back to S1, which reaches overload, and the cycle repeats.
再試行メカニズムにより、サーバーは上流の要素に一定期間トラフィックの送信を停止するように指示できます。そうでなければそのサーバーに送信されていた作業は、代わりに別のサーバーに送信されます。メカニズムは、オールオアナッシングテクニックです。サーバーは、すべてのトラフィックをオフにすることができます。その間に何もありません。これは、軽度の過負荷の下で高度に振動する挙動を引き起こす傾向があります。2つのサーバーS1とS2の間でリクエストのバランスをとっているプロキシP1を検討してください。入力負荷は、S1とS2の両方が100％の容量になるポイントに達するだけです。リクエストはP1に到着し、S1に送信されます。S1は503でこのリクエストを拒否し、retry-afterを使用してバックログをクリアすることにしました。P1はすべてのトラフィックをS1に送信するのを停止します。現在、S2はトラフィックを取得しますが、200％の容量で真剣に過負荷になっています！503と再試行後のリクエストを拒否することにしました。これにより、P1はS1の再試行後のタイマーが切れるまですべてのトラフィックを拒否するようになりました。その時点で、すべての負荷がS1に戻り、過負荷に達し、サイクルが繰り返されます。
It's important to observe that this problem is only observed for servers where there are a small number of upstream elements sending it traffic, as is the case in these examples. If a proxy is accessed by a large number of clients, each of which sends a small amount of traffic, the 503 mechanism with Retry-After is quite effective when utilized with a subset of the clients. This is because spreading the 503 out amongst the clients has the effect of providing the proxy more fine-grained controls on the amount of work it receives.
これらの例の場合のように、この問題は、トラフィックを送信する上流の要素が少ないサーバーでのみ観察されることを観察することが重要です。多数のクライアントがプロキシにアクセスすると、それぞれが少量のトラフィックを送信する場合、クライアントのサブセットを使用すると、再試行後の503メカニズムが非常に効果的です。これは、503をクライアントの間に広めることが、受け取る作業の量に対して、より微調整されたコントロールを提供する効果があるためです。
Unfortunately, the specific instances under which a server is to send a 503 are ambiguous. The result is that implementations generate 503 for many reasons, only some of which are related to actual overload. For example, RFC 3398 [RFC3398], which specifies interworking from SIP to ISDN User Part (ISUP), defines the usage of 503 when the gateway receives certain ISUP cause codes from downstream switches. In these cases, the gateway has ample capacity; it's just that this specific request could not be processed because of a downstream problem. All subsequent requests might succeed if they take a different route in the Public Switched Telephone Network (PSTN).
残念ながら、サーバーが503を送信するための特定のインスタンスは曖昧です。その結果、実装は多くの理由で503を生成し、その一部のみが実際の過負荷に関連しています。たとえば、SIPからISDNユーザーパーツ（ISUP）へのインターワーキングを指定するRFC 3398 [RFC3398]は、ゲートウェイがダウンストリームスイッチから特定のISUP原因コードを受信したときに503の使用を定義します。これらの場合、ゲートウェイには十分な容量があります。この特定のリクエストは、下流の問題のために処理できなかったというだけです。公共の切り替えた電話ネットワーク（PSTN）で別のルートをとると、その後のすべての要求が成功する可能性があります。
This causes two problems. First, during periods of overload, it exacerbates the problems above because it causes additional 503 to be fed into the system, causing further work to be generated in conditions of overload. Second, it becomes hard for an upstream element to know whether to retry when a 503 is received. There are classes of failures where trying on another server won't help, since the reason for the failure was that a common downstream resource is unavailable. For example, if servers S1 and S2 share a database and the database fails, a request sent to S1 will result in a 503, but retrying on S2 won't help since the same database is unavailable.
これにより、2つの問題が発生します。第一に、過負荷の期間中、それは追加の503がシステムに供給され、過負荷条件でさらなる作業を生成するため、上記の問題を悪化させます。第二に、上流の要素が503を受信したときに再試行するかどうかを知ることが難しくなります。障害の理由は、一般的なダウンストリームリソースが利用できないということであるため、別のサーバーを試すことが役に立たない場合、失敗のクラスがあります。たとえば、サーバーS1とS2がデータベースを共有し、データベースが失敗した場合、S1に送信された要求は503になりますが、同じデータベースが利用できないためS2で再試行することはできません。
In this section, we propose requirements for an overload control mechanism for SIP that addresses these problems.
このセクションでは、これらの問題に対処するSIPの過負荷制御メカニズムの要件を提案します。
REQ 1: The overload mechanism shall strive to maintain the overall useful throughput (taking into consideration the quality-of-service needs of the using applications) of a SIP server at reasonable levels, even when the incoming load on the network is far in excess of its capacity. The overall throughput under load is the ultimate measure of the value of an overload control mechanism.
Req 1：過負荷メカニズムは、ネットワーク上の着信負荷がはるかに超えている場合でも、合理的なレベルでSIPサーバーの全体的な有用なスループット（使用の質のニーズを考慮して）を維持するよう努めなければなりません。その能力の。負荷がかかっている全体的なスループットは、過負荷制御メカニズムの値の究極の尺度です。
REQ 2: When a single network element fails, goes into overload, or suffers from reduced processing capacity, the mechanism should strive to limit the impact of this on other elements in the network. This helps to prevent a small-scale failure from becoming a widespread outage.
Req 2：単一のネットワーク要素が失敗したり、過負荷になったり、処理能力の低下に苦しんだり、メカニズムはネットワーク内の他の要素に対するこの影響を制限するよう努力する必要があります。これは、小規模な障害が広範囲にわたる停止になるのを防ぐのに役立ちます。
REQ 3: The mechanism should seek to minimize the amount of configuration required in order to work. For example, it is better to avoid needing to configure a server with its SIP message throughput, as these kinds of quantities are hard to determine.
Req 3：メカニズムは、動作するために必要な構成の量を最小限に抑えるよう努める必要があります。たとえば、SIPメッセージスループットでサーバーを構成する必要がないことを避けることをお勧めします。これらの種類の数量は決定が困難であるためです。
REQ 4: The mechanism must be capable of dealing with elements that do not support it, so that a network can consist of a mix of elements that do and don't support it. In other words, the mechanism should not work only in environments where all elements support it. It is reasonable to assume that it works better in such environments, of course. Ideally, there should be incremental improvements in overall network throughput as increasing numbers of elements in the network support the mechanism.
Req 4：メカニズムは、それをサポートしない要素を扱うことができなければならないため、ネットワークはそれを行う要素の組み合わせで構成し、サポートしない要素で構成されます。言い換えれば、メカニズムは、すべての要素がそれをサポートする環境でのみ機能するべきではありません。もちろん、そのような環境ではより良い動作をすると想定するのは合理的です。理想的には、ネットワーク内の要素の数が増加するため、メカニズムをサポートするため、ネットワークスループット全体に漸進的な改善が必要です。
REQ 5: The mechanism should not assume that it will only be deployed in environments with completely trusted elements. It should seek to operate as effectively as possible in environments where other elements are malicious; this includes preventing malicious elements from obtaining more than a fair share of service.
Req 5：メカニズムは、完全に信頼できる要素を持つ環境でのみ展開されると仮定してはなりません。他の要素が悪意を持っている環境では、可能な限り効果的に動作するように求める必要があります。これには、悪意のある要素がサービスの公平なシェア以上のものを取得するのを防ぐことが含まれます。
REQ 6: When overload is signaled by means of a specific message, the message must clearly indicate that it is being sent because of overload, as opposed to other, non overload-based failure conditions. This requirement is meant to avoid some of the problems that have arisen from the reuse of the 503 response code for multiple purposes. Of course, overload is also signaled by lack of response to requests. This requirement applies only to explicit overload signals.
Req 6：特定のメッセージによって過負荷が信号を送信する場合、メッセージは、他の非負荷ベースの障害条件とは対照的に、過負荷のために送信されていることを明確に示す必要があります。この要件は、複数の目的で503応答コードの再利用から生じた問題のいくつかを回避することを目的としています。もちろん、過負荷はリクエストへの応答の欠如によっても知られています。この要件は、明示的な過負荷信号にのみ適用されます。
REQ 7: The mechanism shall provide a way for an element to throttle the amount of traffic it receives from an upstream element. This throttling shall be graded so that it is not all-or-nothing as with the current 503 mechanism. This recognizes the fact that "overload" is not a binary state and that there are degrees of overload.
Req 7：メカニズムは、上流の要素から受け取るトラフィックの量を要素をスロットルする方法を提供するものとします。このスロットリングは、現在の503メカニズムと同様に、まったくないか、まったくないように等級付けするものとします。これは、「過負荷」はバイナリ状態ではなく、過負荷の程度があるという事実を認識しています。
REQ 8: The mechanism shall ensure that, when a request was not processed successfully due to overload (or failure) of a downstream element, the request will not be retried on another element that is also overloaded or whose status is unknown. This requirement derives from REQ 1.
Req 8：メカニズムは、ダウンストリーム要素の過負荷（または障害）のために要求が正常に処理されなかった場合、要求が過負荷またはそのステータスが不明な別の要素で再試行されないことを保証するものとします。この要件は、Req 1から派生します。
REQ 9: That a request has been rejected from an overloaded element shall not unduly restrict the ability of that request to be submitted to and processed by an element that is not overloaded. This requirement derives from REQ 1.
Req 9：過負荷の要素から要求が拒否されたことは、過負荷にならない要素によって提出され、処理される要求の能力を不当に制限してはならない。この要件は、Req 1から派生します。
REQ 10: The mechanism should support servers that receive requests from a large number of different upstream elements, where the set of upstream elements is not enumerable.
Req 10：メカニズムは、上流要素のセットが列挙できない多数の異なるアップストリーム要素からリクエストを受信するサーバーをサポートする必要があります。
REQ 11: The mechanism should support servers that receive requests from a finite set of upstream elements, where the set of upstream elements is enumerable.
Req 11：メカニズムは、上流要素のセットが列挙可能な上流要素の有限セットからリクエストを受信するサーバーをサポートする必要があります。
REQ 12: The mechanism should work between servers in different domains.
Req 12：メカニズムは、異なるドメインのサーバー間で動作するはずです。
REQ 13: The mechanism must not dictate a specific algorithm for prioritizing the processing of work within a proxy during times of overload. It must permit a proxy to prioritize requests based on any local policy, so that certain ones (such as a call for emergency services or a call with a specific value of the Resource-Priority header field [RFC4412]) are given preferential treatment, such as not being dropped, being given additional retransmission, or being processed ahead of others.
Req 13：メカニズムは、過負荷時にプロキシ内で作業の処理を優先するための特定のアルゴリズムを指示してはなりません。特定のポリシー（緊急サービスへの呼びかけやリソース優先ヘッダーフィールドの特定の価値を持つ電話など）に優先処理が与えられるように、プロキシがローカルポリシーに基づいてリクエストに優先順位を付けることを許可する必要があります。ドロップされていない、追加の再送信が与えられたり、他の人よりも先に処理されたりする。
REQ 14: The mechanism should provide unambiguous directions to clients on when they should retry a request and when they should not. This especially applies to TCP connection establishment and SIP registrations, in order to mitigate against avalanche restart.
Req 14：メカニズムは、クライアントがリクエストを再試行する必要がある場合とそうすべきではないときに、クライアントに明確な方向を提供する必要があります。これは、Avalanche Restartに対して緩和するために、TCP接続の確立とSIP登録に特に適用されます。
REQ 15: In cases where a network element fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure or network partition, it will not be able to provide explicit indications of the nature of the failure or its levels of congestion. The mechanism must properly function in these cases.
Req 15：ネットワーク要素が失敗した場合、非常に過負荷になっているため、メッセージを処理できない、またはネットワークの障害やネットワークパーティションのために通信できない場合、障害またはそのレベルの性質の明示的な兆候を提供することはできません。混雑の。これらの場合、メカニズムは適切に機能する必要があります。
REQ 16: The mechanism should attempt to minimize the overhead of the overload control messaging.
Req 16：メカニズムは、過負荷制御メッセージングのオーバーヘッドを最小限に抑えようとする必要があります。
REQ 17: The overload mechanism must not provide an avenue for malicious attack, including DoS and DDoS attacks.
Req 17：オーバーロードメカニズムは、DOSやDDOS攻撃を含む悪意のある攻撃の手段を提供してはなりません。
REQ 18: The overload mechanism should be unambiguous about whether a load indication applies to a specific IP address, host, or URI, so that an upstream element can determine the load of the entity to which a request is to be sent.
Req 18：過負荷メカニズムは、荷重表示が特定のIPアドレス、ホスト、またはURIに適用されるかどうかについて明確である必要があります。これにより、アップストリーム要素は、リクエストが送信されるエンティティの負荷を決定できます。
REQ 19: The specification for the overload mechanism should give guidance on which message types might be desirable to process over others during times of overload, based on SIP-specific considerations. For example, it may be more beneficial to process a SUBSCRIBE refresh with Expires of zero than a SUBSCRIBE refresh with a non-zero expiration (since the former reduces the overall amount of load on the element), or to process re-INVITEs over new INVITEs.
Req 19：過負荷メカニズムの仕様は、SIP固有の考慮事項に基づいて、過負荷時に他の人よりも処理するためにメッセージタイプが望ましい場合があるガイダンスを提供する必要があります。たとえば、ゼロ以外の有効期限（前者は要素の全体の負荷を減らすため）でサブスクライブの更新よりもゼロの有効期限が切れているサブスクライブの更新を処理するか、新規よりも再インチバイトを処理する方が有益かもしれません。招待します。
REQ 20: In a mixed environment of elements that do and do not implement the overload mechanism, no disproportionate benefit shall accrue to the users or operators of the elements that do not implement the mechanism.
Req 20：過負荷メカニズムを実装し、実装しない要素の混合環境では、メカニズムを実装していない要素のユーザーまたは演算子に不均衡な利益が生じません。
REQ 21: The overload mechanism should ensure that the system remains stable. When the offered load drops from above the overall capacity of the network to below the overall capacity, the throughput should stabilize and become equal to the offered load.
Req 21：過負荷メカニズムは、システムが安定したままであることを確認する必要があります。提供された負荷がネットワークの全体的な容量から全体の容量を下回るまで低下する場合、スループットは安定して提供される負荷に等しくなります。
REQ 22: It must be possible to disable the reporting of load information towards upstream targets based on the identity of those targets. This allows a domain administrator who considers the load of their elements to be sensitive information, to restrict access to that information. Of course, in such cases, there is no expectation that the overload mechanism itself will help prevent overload from that upstream target.
Req 22：これらのターゲットの身元に基づいて、上流のターゲットに向けて負荷情報の報告を無効にすることが可能である必要があります。これにより、要素の負荷を機密情報であると考えるドメイン管理者が、その情報へのアクセスを制限することができます。もちろん、そのような場合、過負荷メカニズム自体がその上流のターゲットからの過負荷を防ぐのに役立つという期待はありません。
REQ 23: It must be possible for the overload mechanism to work in cases where there is a load balancer in front of a farm of proxies.
Req 23：過負荷メカニズムが、プロキシの農場の前にロードバランサーがいる場合に機能する可能性がある必要があります。
Like all protocol mechanisms, a solution for overload handling must prevent against malicious inside and outside attacks. This document includes requirements for such security functions.
すべてのプロトコルメカニズムと同様に、過負荷処理のソリューションは、内外の攻撃を悪意のある防止防止しなければなりません。このドキュメントには、このようなセキュリティ機能の要件が含まれています。
Any mechanism that improves the behavior of SIP elements under load will result in more predictable performance in the face of application-layer denial-of-service attacks.
負荷下でのSIP要素の動作を改善するメカニズムは、アプリケーション層の拒否攻撃に直面して、より予測可能なパフォーマンスをもたらします。
The author would like to thank Steve Mayer, Mouli Chandramouli, Robert Whent, Mark Perkins, Joe Stone, Vijay Gurbani, Steve Norreys, Volker Hilt, Spencer Dawkins, Matt Mathis, Juergen Schoenwaelder, and Dale Worley for their contributions to this document.
著者は、スティーブ・メイヤー、ムーリ・チャンドラムーリ、ロバート・ウェント、マーク・パーキンス、ジョー・ストーン、ヴィジェイ・グルベイニ、スティーブ・ノリーズ、ヴォルカー・ヒルト、スペンサー・ドーキンス、マット・マシス、ジュエルゲン・シェンワエルダー、デール・ウォーリーがこの文書に貢献してくれたことに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, October 2008.
[Autbound] Jennings、C。and R. Mahy、「マネージングクライアントはセッション開始プロトコル（SIP）で接続を開始しました」、2008年10月、進行中の作業。
[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 Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002.
[RFC3398] Camarillo、G.、Roach、A.、Peterson、J。、およびL. Ong、「Integrated Services Digital Network（ISDN）ユーザーパーツ（ISUP）セッション開始プロトコル（SIP）マッピング（SIP）マッピング」、RFC 3398、12月2002年。
[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月。
Author's Address
著者の連絡先
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサンローゼンバーグシスコエジソン、ニュージャージー州
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net