[要約] RFC 5033は、新しい輻輳制御アルゴリズムの仕様を定義するためのものであり、インターネットのトラフィック制御の改善を目的としています。
Network Working Group S. Floyd
Request for Comments: 5033 M. Allman
BCP: 133 ICIR / ICSI
Category: Best Current Practice August 2007
Specifying New Congestion Control Algorithms
新しい混雑制御アルゴリズムの指定
Status of This Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Abstract
概要
The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF.
IETFの標準的な混雑制御スキームは、さまざまな環境（高速ネットワークなど）には不十分であることが広く示されています。最近の研究により、IETFの輻輳制御原則とは大きく異なる多くの代替輻輳制御スキームが得られました。グローバルなインターネットでこれらの新しい輻輳制御スキームを使用すると、新しい渋滞制御を使用したトラフィックと、現在標準化されている混雑制御を使用したトラフィックの両方に影響を与える可能性があります。したがって、IETFは、別の混雑制御提案を扱う際には注意して進める必要があります。このドキュメントの目標は、IETF内の代替輻輳制御アルゴリズムを検討するためのガイダンスを提供することです。
This document provides guidelines for the IETF to use when evaluating suggested congestion control algorithms that significantly differ from the general congestion control principles outlined in [RFC2914]. The guidance is intended to be useful to authors proposing alternate congestion control and for the IETF community when evaluating whether a proposal is appropriate for publication in the RFC series.
このドキュメントは、[RFC2914]で概説されている一般的な輻輳制御原則とは大幅に異なる提案された混雑制御アルゴリズムを評価するときに使用するIETFのガイドラインを提供します。このガイダンスは、提案がRFCシリーズでの公開に適しているかどうかを評価する際に、代替の混雑制御を提案する著者やIETFコミュニティにとって有用であることを目的としています。
The guidelines in this document are intended to be consistent with the congestion control principles from [RFC2914] of preventing congestion collapse, considering fairness, and optimizing the flow's own performance in terms of throughput, delay, and loss. [RFC2914] also discusses the goal of avoiding a congestion control "arms race" among competing transport protocols.
このドキュメントのガイドラインは、渋滞の崩壊を防ぎ、公平性を考慮し、スループット、遅延、および損失の観点からフローのパフォーマンスを最適化するという[RFC2914]の輻輳制御原則と一致することを目的としています。[RFC2914]は、競合する輸送プロトコルの間での混雑制御「武器競争」を回避するという目標についても説明しています。
This document does not give hard-and-fast requirements for an appropriate congestion control scheme. Rather, the document provides a set of criteria that should be considered and weighed by the IETF in the context of each proposal. The high-order criteria for any new proposal is that a serious scientific study of the pros and cons of the proposal needs to have been done such that the IETF has a well-rounded set of information to consider.
このドキュメントでは、適切な渋滞制御スキームの厳しい要件を提供しません。むしろ、このドキュメントは、各提案のコンテキストでIETFによって考慮され、計量する必要がある一連の基準を提供します。新しい提案の高次基準は、提案の長所と短所に関する深刻な科学的研究が行われる必要があるため、IETFが考慮すべきバランスのとれた情報セットがあることです。
After initial studies, we encourage authors to write a specification of their proposals for publication in the RFC series to allow others to concretely understand and investigate the wealth of proposals in this space.
最初の研究の後、著者がRFCシリーズに掲載する提案の仕様を書くことを奨励し、他の人がこの分野での豊富な提案を具体的に理解し調査できるようにします。
Following the lead of HighSpeed TCP [RFC3649], alternate congestion control algorithms are expected to be published as "Experimental" RFCs until such time that the community better understands the solution space. Traditionally, the meaning of "Experimental" status has varied in its use and interpretation. As part of this document we define two classes of congestion control proposals that can be published with the "Experimental" status. The first class includes algorithms that are judged to be safe to deploy for best-effort traffic in the global Internet and further investigated in that environment. The second class includes algorithms that, while promising, are not deemed safe enough for widespread deployment as best-effort traffic on the Internet, but are being specified to facilitate investigations in simulation, testbeds, or controlled environments. The second class can also include algorithms where the IETF does not yet have sufficient understanding to decide if the algorithm is or is not safe for deployment on the Internet.
Highspeed TCP [RFC3649]のリードに続いて、コミュニティがソリューションスペースをよりよく理解するまで、「実験的な」RFCとして代替の混雑制御アルゴリズムが公開されると予想されます。伝統的に、「実験的」ステータスの意味は、その使用と解釈が異なりました。このドキュメントの一部として、「実験的」ステータスで公開できる2つのクラスの混雑制御提案を定義します。ファーストクラスには、グローバルなインターネットで最高のエフォルトトラフィックのために展開し、その環境でさらに調査したと判断されたアルゴリズムが含まれています。2番目のクラスには、有望ではありますが、インターネット上の最高のエフォルトトラフィックとして広範囲にわたる展開に十分な安全とは見なされないが、シミュレーション、テストベッド、または制御環境の調査を容易にするために指定されているアルゴリズムが含まれています。2番目のクラスには、IETFがインターネット上の展開に安全であるか安全でないかを決定するのに十分な理解がまだ十分でないアルゴリズムを含めることもできます。
Each alternate congestion control algorithm published is required to include a statement in the abstract indicating whether or not the proposal is considered safe for use on the Internet. Each alternate congestion control algorithm published is also required to include a statement in the abstract describing environments where the protocol is not recommended for deployment. There may be environments where the protocol is deemed *safe* for use, but still is not *recommended* for use because it does not perform well for the user.
公開されている各代替渋滞制御アルゴリズムは、提案がインターネットでの使用に安全であると見なされるかどうかを示す抽象にステートメントを含める必要があります。公開されている各代替の輻輳制御アルゴリズムは、展開にプロトコルが推奨されない環境を説明する抽象的なステートメントを含める必要があります。プロトコルが使用するために *安全 *とみなされる環境がありますが、ユーザーにとってはうまく機能しないため、使用するために *推奨されません *。
As examples of such statements, [RFC3649] specifying HighSpeed TCP includes a statement in the abstract stating that the proposal is Experimental, but may be deployed in the current Internet. In contrast, the Quick-Start document [RFC4782] includes a paragraph in the abstract stating the mechanism is only being proposed for controlled environments. The abstract specifies environments where the Quick-Start request could give false positives (and therefore would be unsafe to deploy). The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment would still not be recommended because it could cause unnecessary delays for the connections attempting to use Quick-Start.
このようなステートメントの例として、[RFC3649]が高速TCPを指定することには、提案が実験的であるが現在のインターネットに展開される可能性があることを示す抽象的な声明が含まれています。対照的に、クイックスタートドキュメント[RFC4782]には、メカニズムが制御された環境に対してのみ提案されていることを示す抽象的な段落が含まれています。要約は、クイックスタート要求が誤検知を与える可能性がある環境を指定します（したがって、展開するのは安全ではありません）。要約は、クイックスタートリクエストを含むパケットをネットワークで削除できる環境も指定しています。このような環境では、クイックスタートは展開するのに安全ではありませんが、クイックスタートを使用しようとする接続に不必要な遅延を引き起こす可能性があるため、展開はまだ推奨されません。
For authors of alternate congestion control schemes who are not ready to bring their congestion control mechanisms to the IETF for standardization (either as Experimental or as Proposed Standard), one possibility would be to submit an internet-draft that documents the alternate congestion control mechanism for the benefit of the IETF and IRTF communities. This is particularly encouraged in order to get algorithm specifications widely disseminated to facilitate further research. Such an internet-draft could be submitted to be considered as an Informational RFC, as a first step in the process towards standardization. Such a document would also be expected to carry an explicit warning against using the scheme in the global Internet.
混雑制御メカニズムを標準化のためにIETFに持ち込む準備ができていない代替渋滞制御スキームの著者（実験的または提案された標準として）の著者にとって、1つの可能性は、代替の混雑制御メカニズムを文書化するインターネットドラフトを提出することです。IETFおよびIRTFコミュニティの利点。これは、さらなる研究を促進するために広く普及しているアルゴリズムの仕様を取得するために特に奨励されています。このようなインターネットドラフトは、標準化に向けたプロセスの最初のステップとして、情報RFCと見なされるように提出することができます。このようなドキュメントは、グローバルなインターネットでスキームを使用することに対して明示的な警告を伝えることも期待されます。
Note: we are not changing the RFC publication process for non-IETF produced documents (e.g., those from the IRTF or Independent Submissions via the RFC-Editor). However, we would hope the guidelines in this document inform the IESG as they consider whether to add a note to such documents.
注：非ITETFが作成したドキュメント（例：IRTFまたはRFC-Editorを介した独立した提出物からのRFC出版プロセス）は変更していません。ただし、このドキュメントのガイドラインが、そのようなドキュメントにメモを追加するかどうかを検討するIESGに通知することを願っています。
As noted above, authors are expected to do a well-rounded evaluation of the pros and cons of proposals brought to the IETF. The following are guidelines to help authors and the IETF community. Concerns that fall outside the scope of these guidelines are certainly possible; these guidelines should not be considered as an all-encompassing check-list.
上記のように、著者は、IETFに提案された提案の長所と短所のバランスのとれた評価を行うことが期待されています。以下は、著者とIETFコミュニティを支援するためのガイドラインです。これらのガイドラインの範囲外にある懸念は確かに可能です。これらのガイドラインは、包括的なチェックリストと見なされるべきではありません。
(0) Differences with Congestion Control Principles [RFC2914]
(0) 混雑制御原則との違い[RFC2914]
Proposed congestion control mechanisms should include a clear explanation of the deviations from [RFC2914].
提案された輻輳制御メカニズムには、[RFC2914]からの逸脱の明確な説明を含める必要があります。
(1) Impact on Standard TCP, SCTP [RFC2960], and DCCP [RFC4340].
(1) 標準のTCP、SCTP [RFC2960]、およびDCCP [RFC4340]への影響。
Proposed congestion control mechanisms should be evaluated when competing with standard IETF congestion control [RFC2581, RFC2960, RFC4340]. Alternate congestion controllers that have a significantly negative impact on traffic using standard congestion control may be suspect and this aspect should be part of the community's decision making with regards to the suitability of the alternate congestion control mechanism.
標準のIETF混雑制御[RFC2581、RFC2960、RFC4340]と競合する場合、提案された混雑制御メカニズムを評価する必要があります。標準的な輻輳制御を使用してトラフィックに大きな影響を与える代替の混雑コントローラーが疑われる可能性があり、この側面は、代替の輻輳制御メカニズムの適合性に関してコミュニティの意思決定の一部でなければなりません。
We note that this bullet is not a requirement for strict TCP-friendliness as a prerequisite for an alternate congestion control mechanism to advance to Experimental. As an example, HighSpeed TCP is a congestion control mechanism that is Experimental, but that is not TCP-friendly in all environments. We also note that this guideline does not constrain the fairness offered for non-best-effort traffic.
この弾丸は、実験的に進むための代替渋滞制御メカニズムの前提条件として、厳密なTCPフレンドリーの要件ではないことに注意してください。例として、高速TCPは実験的な混雑制御メカニズムですが、すべての環境でTCPに優しいものではありません。また、このガイドラインは、非ベストエフォルトトラフィックに提供される公平性を制約しないことにも注意してください。
As an example from an Experimental RFC, fairness with standard TCP is discussed in Sections 4 and 6 of [RFC3649] (HighSpeed TCP) and using spare capacity is discussed in Sections 6, 11.1, and 12 of [RFC3649].
実験RFCの例として、[RFC3649]のセクション4および6（高速度TCP）のセクション4および6で標準的なTCPの公平性について説明し、予備容量を使用して、[RFC3649]のセクション6、11.1、および12で説明します。
(2) Difficult Environments.
(2) 難しい環境。
The proposed algorithms should be assessed in difficult environments such as paths containing wireless links. Characteristics of wireless environments are discussed in [RFC3819] and in Section 16 of [Tools]. Other difficult environments can include those with multipath routing within a connection. We note that there is still much to be desired in terms of the performance of TCP in some of these difficult environments. For congestion control mechanisms with explicit feedback from routers, difficult environments can include paths with non-IP queues at layer-two, IP tunnels, and the like. A minimum goal for experimental mechanisms proposed for widespread deployment in the Internet should be that they do not perform significantly worse than TCP in these environments.
提案されたアルゴリズムは、ワイヤレスリンクを含むパスなどの困難な環境で評価する必要があります。ワイヤレス環境の特性は、[RFC3819]および[ツール]のセクション16で説明されています。他の困難な環境には、接続内でマルチパスルーティングがある環境が含まれます。これらの困難な環境のいくつかでTCPのパフォーマンスに関しては、まだ多くのことが望まれることに注意してください。ルーターからの明示的なフィードバックを備えた混雑制御メカニズムの場合、困難な環境には、レイヤーツー、IPトンネルなどの非IPキューを持つパスを含めることができます。インターネットでの広範な展開のために提案された実験メカニズムの最小目標は、これらの環境でTCPよりも著しく悪化していないことです。
While it is impossible to enumerate all the possible "difficult environments", we note that the IETF has previously grappled with paths with long delays [RFC2488], high delay bandwidth products [RFC3649], high packet corruption rates [RFC3155], packet reordering [RFC4653], and significantly slow links [RFC3150]. Aspects of alternate congestion control that impact networks with these characteristics should be detailed.
考えられるすべての「困難な環境」を列挙することは不可能ですが、IETFは以前に長い遅延[RFC2488]、高い遅延帯域幅製品[RFC3649]、高いパケット破損率[RFC3155]、パケット再秩序化のあるパスに取り組んでいたことに注意してください。RFC4653]、およびリンクが大幅に遅くなる[RFC3150]。これらの特性を備えたネットワークに影響を与える代替渋滞制御の側面を詳細にする必要があります。
As an example from an Experimental RFC, performance in difficult environments is discussed in Sections 6, 9.2, and 10.2 of [RFC4782] (Quick-Start).
実験RFCの例として、[RFC4782]（クイックスタート）のセクション6、9.2、および10.2で困難な環境でのパフォーマンスについて説明します。
(3) Investigating a Range of Environments.
(3) さまざまな環境の調査。
Similar to the last criteria, proposed alternate congestion controllers should be assessed in a range of environments. For instance, proposals should be investigated across a range of bandwidths, round-trip times, levels of traffic on the reverse path, and levels of statistical multiplexing at the congested link. Similarly, proposals should be investigated for robust performance with different queueing mechanisms in the routers, especially Random Early Detection (RED) [FJ03] and Drop-Tail. This evaluation is often not included in the internet-draft itself, but in related papers cited in the draft.
最後の基準と同様に、提案された代替輻輳コントローラーは、さまざまな環境で評価する必要があります。たとえば、提案は、さまざまな帯域幅、往復時間、逆パス上のトラフィックのレベル、および混雑したリンクでの統計的多重化のレベルで調査する必要があります。同様に、ルーター内のさまざまなキューイングメカニズム、特にランダム早期検出（RED）[FJ03]およびドロップテールを使用した堅牢なパフォーマンスについては、提案を調査する必要があります。この評価は、多くの場合、インターネットドラフト自体ではなく、ドラフトで引用されている関連書類に含まれています。
A particularly important aspect of evaluating a proposal for standardization is in understanding where the algorithm breaks down. Therefore, particular attention should be paid to characterizing the areas where the proposed mechanism does not perform well.
標準化の提案を評価することの特に重要な側面は、アルゴリズムが崩壊する場所を理解することです。したがって、提案されたメカニズムがうまく機能しない領域を特徴付けることには、特に注意が払われるべきです。
As an example from an Experimental RFC, performance in a range of environments is discussed in Section 12 of [RFC3649] (HighSpeed TCP) and Section 9.7 of [RFC4782] (Quick-Start).
実験RFCの例として、さまざまな環境のパフォーマンスについては、[RFC3649]（高速TCP）のセクション12および[RFC4782]（クイックスタート）のセクション9.7で説明します。
(4) Protection Against Congestion Collapse.
(4) 混雑崩壊に対する保護。
The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold [RFC3714], or should include some notion of "full backoff". For "full backoff", at some point the algorithm would reduce the sending rate to one packet per round-trip time and then exponentially backoff the time between single packet transmissions if congestion persists. Exactly when either "full backoff" or a pause in sending comes into play will be algorithm-specific. However, as discussed in [RFC2914], this requirement is crucial to protect the network in times of extreme congestion.
代替の輻輳制御メカニズムは、パケットドロップレートがある程度のしきい値を超えた場合に送信を停止する必要があります[RFC3714]、または「フルバックオフ」の概念を含める必要があります。「フルバックオフ」の場合、ある時点で、アルゴリズムは往復時間ごとに送信率を1つのパケットに引き下げ、混雑が続く場合の単一パケット送信間の時間を指数関数的にバックオフします。正確に「フルバックオフ」または送信中の一時停止が登場する場合、アルゴリズム固有のものになります。ただし、[RFC2914]で説明したように、この要件は、極端なうっ血の時にネットワークを保護するために重要です。
If "full backoff" is used, this bullet does not require that the full backoff mechanism must be identical to that of TCP [RFC2988]. As an example, this bullet does not preclude full backoff mechanisms that would give flows with different round-trip times comparable bandwidth during backoff.
「フルバックオフ」が使用されている場合、この弾丸は、完全なバックオフメカニズムがTCP [RFC2988]と同一でなければならないことを必要としません。例として、この弾丸は、バックオフ中に異なる往復時間と同等の帯域幅でフローを与える完全なバックオフメカニズムを排除しません。
(5) Fairness within the Alternate Congestion Control Algorithm.
(5) 代替輻輳制御アルゴリズム内の公平性。
In environments with multiple competing flows all using the same alternate congestion control algorithm, the proposal should explore how bandwidth is shared among the competing flows.
複数の競合するフローを備えた環境では、すべて同じ代替渋滞制御アルゴリズムを使用して、提案は競合するフローの間で帯域幅がどのように共有されるかを調査する必要があります。
(6) Performance with Misbehaving Nodes and Outside Attackers.
(6) 誤動作ノードと外部攻撃者によるパフォーマンス。
The proposal should explore how the alternate congestion control mechanism performs with misbehaving senders, receivers, or routers. In addition, the proposal should explore how the alternate congestion control mechanism performs with outside attackers. This can be particularly important for congestion control mechanisms that involve explicit feedback from routers along the path.
提案は、誤動作の送信者、受信機、またはルーターで代替の輻輳制御メカニズムがどのように機能するかを探る必要があります。さらに、この提案は、代替の混雑制御メカニズムが外部の攻撃者とどのように機能するかを探る必要があります。これは、パスに沿ったルーターからの明示的なフィードバックを含む混雑制御メカニズムにとって特に重要です。
As an example from an Experimental RFC, performance with misbehaving nodes and outside attackers is discussed in Sections 9.4, 9.5, and 9.6 of [RFC4782] (Quick-Start). This includes discussion of misbehaving senders and receivers; collusion between misbehaving routers; misbehaving middleboxes; and the potential use of Quick-Start to attack routers or to tie up available Quick-Start bandwidth.
実験RFCの例として、[RFC4782]（Quick-start）のセクション9.4、9.5、および9.6で、誤動作ノードと外部攻撃者のパフォーマンスについて説明します。これには、誤動作の送信者と受信者の議論が含まれます。不正行為ルーター間の共謀;ミドルボックスを誤動作します。クイックスタートの潜在的な使用は、ルーターを攻撃したり、利用可能なクイックスタート帯域幅を拘束したりします。
(7) Responses to Sudden or Transient Events.
(7) 突然または一時的なイベントへの応答。
The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as sudden congestion, a routing change, or a mobility event. Routing changes, link disconnections, intermittent link connectivity, and mobility are discussed in more detail in Section 17 of [Tools].
この提案は、突然の輻輳、ルーティングの変更、モビリティイベントなどの一時的なイベントの存在下で、代替の輻輳制御メカニズムがどのように機能するかを考慮する必要があります。ルーティングの変更、リンク切断、断続的なリンク接続、およびモビリティについては、[ツール]のセクション17で詳しく説明します。
As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of [RFC4782] (Quick-Start).
実験RFCの例として、一時的なイベントへの応答については、[RFC4782]（クイックスタート）のセクション9.2で説明します。
(8) Incremental Deployment.
(8) 増分展開。
The proposal should discuss whether the alternate congestion control mechanism allows for incremental deployment in the targeted environment. For a mechanism targeted for deployment in the current Internet, it would be helpful for the proposal to discuss what is known (if anything) about the correct operation of the mechanism with some of the equipment installed in the current Internet, e.g., routers, transparent proxies, WAN optimizers, intrusion detection systems, home routers, and the like.
提案は、代替の混雑制御メカニズムがターゲット環境での増分展開を可能にするかどうかを議論する必要があります。現在のインターネットでの展開を目的としたメカニズムの場合、現在のインターネットに設置されている機器の一部を使用して、メカニズムの正しい操作について（もしあれば）既知のことを議論することが提案が役立つでしょう。プロキシ、WANオプティマイザー、侵入検知システム、ホームルーターなど。
As a similar concern, if the alternate congestion control mechanism is intended only for specific environments (and not the global Internet), the proposal should consider how this intention is to be carried out. The community will have to address the question of whether the scope can be enforced by simply stating the restrictions or whether additional protocol mechanisms are required to enforce the scoping. The answer will necessarily depend on the change being proposed.
同様の懸念事項として、代替の輻輳制御メカニズムが特定の環境（グローバルインターネットではなく）のみで意図されている場合、提案はこの意図をどのように実行するかを検討する必要があります。コミュニティは、制限を単純に述べることで範囲を実施できるかどうか、またはスコーピングを実施するために追加のプロトコルメカニズムが必要かどうかの問題に対処する必要があります。答えは、提案されている変更に必然的に依存します。
As an example from an Experimental RFC, deployment issues are discussed in Sections 10.3 and 10.4 of [RFC4782] (Quick-Start).
実験RFCの例として、[RFC4782]（クイックスタート）のセクション10.3および10.4で展開の問題について説明します。
This section suggests minimum requirements for a document to be approved as Experimental with approval for widespread deployment in the global Internet.
このセクションでは、グローバルインターネットでの広範な展開の承認を得て、実験として承認されるドキュメントの最小要件を示唆しています。
The minimum requirements for approval for widespread deployment in the global Internet include the following guidelines on: (1) assessing the impact on standard congestion control, (3) investigation of the proposed mechanism in a range of environments, (4) protection against congestion collapse, and (8) discussing whether the mechanism allows for incremental deployment.
グローバルインターネットでの広範な展開の承認の最小要件には、次のガイドラインが含まれます。（1）標準的な混雑制御への影響の評価（3）さまざまな環境で提案されたメカニズムの調査、（4）渋滞崩壊に対する保護、および（8）メカニズムが増分展開を可能にするかどうかを議論する。
For other guidelines, i.e., (2), (5), (6), and (7), the author must perform the suggested evaluations and provide recommended analysis. Evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet.
他のガイドライン、つまり（2）、（5）、（6）、および（7）については、著者は提案された評価を実行し、推奨分析を提供する必要があります。提案されたメカニズムには、TCPのメカニズムよりもかなり多くの問題があるという証拠は、グローバルなインターネットでの広範な展開の承認の懸念の原因となるはずです。
This document does not represent a change to any aspect of the TCP/IP protocol suite and therefore does not directly impact Internet security. The implementation of various facets of the Internet's current congestion control algorithms do have security implications (e.g., as outlined in [RFC2581]). Alternate congestion control schemes should be mindful of such pitfalls, as well, and should examine any potential security issues that may arise.
このドキュメントは、TCP/IPプロトコルスイートのいかなる側面への変更を表していないため、インターネットセキュリティに直接影響を与えません。インターネットの現在の混雑制御アルゴリズムのさまざまなファセットの実装には、セキュリティの意味があります（例：[RFC2581]で概説されているように）。代替の混雑制御スキームは、そのような落とし穴にも注意する必要があり、発生する可能性のある潜在的なセキュリティの問題を調べる必要があります。
Discussions with Lars Eggert and Aaron Falk seeded this document. Thanks to Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye, Colin Perkins, Pekka Savola, members of TSVWG, and participants at the TCP Workshop at Microsoft Research for feedback and contributions. This document also draws from [Metrics].
Lars EggertとAaron Falkとの話し合いは、この文書をシードしました。ボブ・ブリスコー、ゴリー・フェアハースト、ダグ・リース、ジテンドラ・パディエ、コリン・パーキンス、ペッカ・サヴォラ、TSVWGのメンバー、およびフィードバックと貢献についてMicrosoft ResearchのTCPワークショップの参加者に感謝します。このドキュメントは、[メトリック]からも描画されています。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。、およびW. Stevens、「TCP渋滞制御」、RFC 2581、1999年4月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S。、「混雑制御原則」、BCP 41、RFC 2914、2000年9月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagramうっ血制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[FJ03] Floyd, S., and Jacobson, V., Random Early Detection Gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, V.1 N.4, August 1993.
[FJ03] Floyd、S。、およびJacobson、V.、渋滞回避のためのランダムな早期検出ゲートウェイ、IEEE/ACMトランザクション、v.1 N.4、1993年8月。
[Metrics] S. Floyd, Metrics for the Evaluation of Congestion Control Mechanisms, Work in Progress, July 2007.
[メトリック] S.フロイド、輻輳制御メカニズムの評価のためのメトリック、2007年7月、進行中の作業。
[RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[RFC2488] Allman、M.、Glover、D。、およびL. Sanchez、「標準メカニズムを使用した衛星チャネル上のTCPの強化」、BCP 28、RFC 2488、1999年1月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[RFC3150] Dawkins、S.、Montenegro、G.、Kojo、M。、およびV. Magret、「スローリンクのエンドツーエンドのパフォーマンスへの影響」、BCP 48、RFC 3150、2001年7月。
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N. Vaidya, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3155, August 2001.
[RFC3155] Dawkins、S.、Montenegro、G.、Kojo、M.、Magret、V。、およびN. Vaidya、「エラーとリンクのエンドツーエンドのパフォーマンスの意味」、BCP 50、RFC 3155、2001年8月。
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, December 2003.
[RFC3649] Floyd、S。、「大渋滞窓用の高速TCP」、RFC 3649、2003年12月。
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[RFC3714] Floyd、S。およびJ. Kempf、「IABは、インターネットでの音声トラフィックの混雑制御に関する懸念」、RFC 3714、2004年3月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819] Karn、P.、Bormann、C.、Fairhurst、G.、Grossman、D.、Ludwig、R.、Mahdavi、J.、Montenegro、G.、Touch、J.、およびL. Wood、「アドバイス」アドバイスインターネットサブネットワークデザイナー向け」、BCP 89、RFC 3819、2004年7月。
[RFC4653] Bhandarkar, S., Reddy, A. N., Allman, M., and E. Blanton, "Improving the Robustness of TCP to Non-Congestion Events", RFC 4653, August 2006.
[RFC4653] Bhandarkar、S.、Reddy、A。N.、Allman、M。、およびE. Blanton、「非合成イベントに対するTCPの堅牢性の改善」、RFC 4653、2006年8月。
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, January 2007.
[RFC4782] Floyd、S.、Allman、M.、Jain、A。、およびP. Sarolahti、「TCPとIPのクイックスタート」、RFC 4782、2007年1月。
[Tools] S. Floyd and E. Kohler, Tools for the Evaluation of Simulation and Testbed Scenarios, Work in Progress, July 2007.
[ツール] S. FloydとE. Kohler、シミュレーションおよびテストベッドシナリオの評価のためのツール、2007年7月、進行中の作業。
Authors' Addresses
著者のアドレス
Sally Floyd ICIR (ICSI Center for Internet Research) 1947 Center Street, Suite 600 Berkeley, CA 94704-1198 Phone: +1 (510) 666-2989 EMail: floyd@icir.org URL: http://www.icir.org/floyd/
Sally Floyd ICIR（ICSIセンターフォーインターネット研究センター）1947センターストリート、スイート600バークレー、CA 94704-1198電話：1（510）666-2989メール：floyd@icir.org url：http://www.icir.org/フロイド/
Mark Allman ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704-1198 Phone: (440) 235-1792 EMail: mallman@icir.org URL: http://www.icir.org/mallman/
マークオールマンICSIインターネットリサーチセンター1947センターストリート、スイート600バークレー、カリフォルニア州94704-1198電話：（440）235-1792メール：mallman@icir.org url：http：//www.icir.org/mallman/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。