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.
著作権（C）2008 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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:
そのようなSIPユーザエージェントまたはプロキシとして要素は、正常それが受信されるトラフィックのすべてを処理するのに十分なリソースを有している場合、過負荷が発生します。リソースはCPU処理、メモリ、I / O、またはディスクリソースを含む要求を処理するために使用される要素のすべての機能を、含まれています。それはまた、これらのサーバーのCPU、処理、メモリ、I / O、およびディスクリソースが効率的に要求を処理する論理要素の一部である場合には、データベースやDNSサーバなどの外部リソースを含むことができます。過負荷は、多くの理由を含むが発生する可能性があります。
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ネットワークは、彼らがなることが期待されている加入者のニーズを満たすために、その上のサーバー、ハードウェア、ディスク、および十分な数で設計する必要があります。キャパシティプランニングは、これらのニーズを決定するプロセスです。これは、予想される加入者の数とそれらが使用することを期待されているフローの種類に基づいています。この作業が適切に行われていない場合、ネットワークは、通常の用法と（例えば母の日にボリュームを呼び出して高い声など）予想通り高いものも含めて、予測可能な用途を処理するための十分な能力を有することができます。
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素子が過負荷になることができます。これらのケースでは、さえも最小限のトラフィックは、サーバが過負荷に入る可能性があります。このような依存過負荷の例としては、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登録してネットワークに接続しようとしたときに発生します。雪崩の再起動は、いくつかのイベントによって引き起こされる場合があります。一つは、マンハッタンのような大都市圏で停電があり、「マンハッタンの再起動」のシナリオです。電源が回復すると、SIP電話機のすべて、PCやスタンドアロンデバイスを問わず、同時に電源オンとは、ブートを開始します。彼らはすべて、ネットワークに接続し、登録し、SIP REGISTERメッセージの洪水を引き起こします。雪崩再起動のもう一つの原因は、例えば大規模なネットワーク接続の失敗、企業向けアクセスルータです。それが失敗した場合、SIPクライアントは、[OUTBOUND]にメカニズムを使用して迅速に故障を検出します。接続が復元されると、これが検出され、クライアントが再登録を、すべての短い時間内に。雪崩再起動のもう1つの原因は、プロキシサーバの障害です。クライアントは、すべてのTCPでサーバに接続していた場合、その故障は、検出された別のサーバーへの再接続および再登録が続きます。 [OUTBOUND]は、この場合には、いくつかの救済を提供しないことに注意してください。
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.
フラッシュ群衆：フラッシュ群衆が発生したときに、ユーザーの非常に大きな数の同時呼び出しを行うために、すべての試み。これが起こることができるかの一例は、無料ギフトを受け取るためにコールする番号を広告するテレビコマーシャルです。贈り物は説得力があると多くの人が広告を見た場合、多くのコールが同時に同じ番号にすることができます。これは、過負荷にシステムを送ることができます。
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の場合は、タイムアウトする前にINVITEリクエストの多くは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.
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）は、代替サーバに要求を転送しようとすべきです。存在する場合には、再試行-Afterヘッダフィールドで指定された期間のためにそのサーバーに他の要求を転送すべきではありません。
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の応答を転送しないようにプロキシを指示します。これは実際には、問題は、要素はさらに下流たとき、プロキシが過負荷であると結論mistakinglyの上流のサーバーを避けるためです。
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.
プロキシP1は、多くのソースからSIPリクエストを受信し、処理するためのサーバS1、S2、及びS3への要求をプロキシ、単にロードバランサとして機能します。入力負荷は、3台のすべてのサーバーが過負荷になる点まで増加します。それはその次の要求を受けたサーバS1、しかし、503を生成し、サーバーがロードされているため、SIPは、UDP上で実行されている場合は、503を生成するためにいくつかの時間がかかることがあり、これは要求の再送信をもたらすことができる、更なる増加S1での作業。サーバがロードされ、カーネルが十分に速くTCPの確認応答を送信できない場合でも、TCPの場合、TCPの再送が発生することがあります。 503は、P1によって受信されると、それは、S2上の要求を再試行します。 S2はまた、オーバーロードし、最終的に503を生成するが、その間にも再送信で打撃することができるされています。 P1は再び別のサーバー、また最終的には503でそれを拒否し、この時間S3を、しようとします。
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の。このように、無負荷条件の下で、クライアントからの単一の要求（クライアントにS1からP1へ、次いでP1）（S1、S2、またはS3）に一つのリクエストと2つの応答を生成します。ネットワークが過負荷になるとUDPが使用されている場合、クライアントからの単一の要求は、タイムアウト前に、できるだけ多くのように18回の要求と応答など、多くを生成することがありました！状況は、TCP（または一般に任意の信頼性の高いトランスポート）とのより良いですが、再送TCPセグメントが存在しなかった場合でも、クライアントからの単一の要求は、3つの要求と4つの応答を生成することができます。各サーバは、これらのメッセージを処理するためのリソースを消費しなければなりませんでした。このように、より多くのメッセージとより多くの仕事は、要素が過負荷になった時点でネットワークに送られました。単一の要素がオーバーロードされたときに503メカニズムがうまく機能します。問題は、全体的なネットワーク負荷があるときには、503のメカニズムは、実際には最終的にはとにかく要求の拒否で、その結果、より多くのメッセージとすべてのサーバーのためのより多くの仕事を生成します。
The problem becomes amplified further if one considers proxies upstream from P1, as shown in Figure 2.
一つはP1の上流プロキシを考慮した場合、図2に示すような問題は、さらに増幅されてしまいます。
+------+
> | | <
/ | 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間の負荷バランスの両方。すべてのオーバーロードされS3を介して再びS1と仮定すると、要求は最初P1を試みるPA、に到達します。 P1はS1、S2、次いでS3を試み、そしてUDPが使用される場合、多くの要求内の各トランザクションの結果が再送します。 P1が最終的に要求を処理することができないので、それを拒否する。その下流のすべての依存関係がビジー状態であるため、しかし、それはこれが503度以上で、その結果、再びS3を通してS1をしようとP2をしようとPA、に伝播503を送信することを決定します。したがって、この場合には、我々は、以前の場合と比較して、ネットワーク内のSIPトランザクションの数と全体的な作業を倍増しています。ここでの問題は、S1からS3がオーバーロードされたという事実は、P1に知られていたが、P2は再びS3を通してS1を再試行するように、この情報は、P2にPAへと貫通戻されなかったことです。
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.
興味深いことに、ネットワーク容量を大幅に過負荷機構の結果として減少した展開の例もあります。もう一度考えてみて、それがP1によって受信されるとRFC 3261が503の範囲に明確ではない、残念ながら、図1を、そのIPアドレスに要求を送信するプロキシ中止していますか？ホスト名に？ URIに？いくつかの実装では、スコープとしてホスト名を選択しました。 URIのホスト名は、順番に、なります、（例ではS1、S2、およびS3）下流サーバのクラスタへの単一のものから503応答をマッピングし、DNSでのSRVレコード、を指すときプロキシは、クラスタ全体が過負荷になっていることを信じています。その結果、プロキシ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.
リトライ後のメカニズムは、サーバーが一定の期間トラフィックの送信を停止するために、上流の要素を伝えることができます。そうでない場合は、そのサーバーに送信されていたであろう作品ではなく、別のサーバーに送信されます。メカニズムは、全か無かの技術です。サーバーは、またはnoneに向けて、すべてのトラフィックをオフにすることができます。間では何もありません。これはさえ穏やかな過負荷の高い振動挙動を引き起こす傾向があります。二つのサーバS1とS2間の要求のバランスをとるれるプロキシP1を考えてみましょう。入力負荷がちょうどS1とS2の両方が100％の容量である点に達します。要求がP1に到達するとS1に送られます。 S1は503でこの要求を拒否し、そのバックログをクリアするには、リトライした後を使用することを決定しました。 P1は、S1へのすべてのトラフィックの送信を停止します。さて、S2は、トラフィックを取得しますが、それは真剣に過負荷になっている - 200％の容量で！それは今S1の再試行-後タイマーが切れるまで、すべてのトラフィックを拒否するようにP1を強制的に503とリトライの後で要求を拒否することを決定します。その時点で、すべての荷重がバック過負荷に到達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を生成することです。ゲートウェイは、下流のスイッチから特定のISUP原因コードを受信した場合、例えば、ISDNユーザ部（ISUP）にSIPのインターワーキングを指定RFC 3398 [RFC3398]は、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.
これには二つの問題が発生します。まず、過負荷の期間中に、それは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：メカニズムは、過負荷の時間中に、プロキシ内の作業の処理を優先するために特定のアルゴリズムを規定してはなりません。 （例えば緊急サービスのための呼またはリソース優先ヘッダフィールドの特定の値を持つコール[RFC4412]のような）特定のものを優遇が与えられるように、そのような、任意のローカルポリシーに基づいて要求を優先順位付けするためにプロキシを許可する必要がありますドロップされていないと、追加の再送を与えられている、または先に他人の処理されています。
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：彼らはいけないメカニズムは、彼らが要求を再試行する必要があるときに、クライアントに明確な方向性を提供しなければなりません。これは特に、雪崩の再起動を軽減するためには、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固有の考慮事項に基づいて、過負荷の時間中に他のものよりも処理することが望ましいかもしれないれたガイダンスを与えるべきです。例えば、ゼロより有効期限と更新SUBSCRIBE処理するより有益であってもよい（前者は要素の負荷の全体量を減少させるため）非ゼロの有効期限と更新SUBSCRIBE、または新しいオーバー再招待処理します誘います。
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：それは、これらのターゲットのIDに基づいて、上流のターゲットに向けた負荷情報の報告を無効にすることが可能でなければなりません。これは、その情報へのアクセスを制限するために、その要素の負荷は機密情報であると考えて、ドメイン管理者を可能にします。もちろん、このような場合には、過負荷メカニズム自体は、その上流のターゲットからの過負荷を防ぐことができますという期待がありません。
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.
作者はこのドキュメントへの貢献のためにスティーブ・メイヤー、Mouli Chandramouli、ロバートWhent、マーク・パーキンス、ジョー・ストーン、ビジェイGurbani、スティーブNorreys、フォルカー柄、スペンサードーキンスマット・マシス、ユルゲンSchoenwaelder、とデールウォーリーを感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.
[OUTBOUND]ジェニングス、C.とR.マーイ、進歩、2008年10月に作品「セッション開始プロトコル（SIP）でのクライアント開始された接続の管理」を参照してください。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[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]キャマリロ、G.、ローチ、A.、ピーターソン、J.、およびL.オング、 "セッション開始プロトコル（SIP）へのマッピング総合デジタル通信網（ISDN）ユーザ部（ISUP）"、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.ポーク、 "セッション開始プロトコル（SIP）のための通信リソースプライオリティ"、RFC 4412、2006年2月。
Author's Address
著者のアドレス
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサン・ローゼンバーグシスコエジソン、NJ US
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電子メール：jdrosen@cisco.com URI：http://www.jdrosen.net