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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
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.
高速TCP [RFC3649]のリードに続いて、別の輻輳制御アルゴリズムは、コミュニティがより良い解空間を理解できるような時間まで、「実験」のRFCとして公開されることが期待されます。伝統的に、「実験」のステータスの意味は、その使用および解釈に変化しました。この文書の一部として、我々は「実験」の状態で公開することができ、輻輳制御の提案の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への輻輳制御機構を持参する準備ができていない別の輻輳制御方式の作者のために、一つの可能性はのための代替輻輳制御機構を文書化するインターネットドラフトを提出するだろう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.
注：我々は、非IETFのRFC公開プロセスは、ドキュメントを生成した変更されない（例えば、RFC-エディタを介しIRTF又は独立提出からのもの）。しかし、我々は、彼らがそのような文書にメモを追加するかどうかを検討として、この文書のガイドラインは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].
(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.
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から一例として、標準のTCPとの公平性は、[RFC3649]（高速TCP）のセクション4及び6に記載されていると予備容量を使用することはセクション6、11.1で説明され、そして[RFC3649]の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.
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からの例として、困難な環境で性能がセクション6、9.2で説明され、そして[RFC4782]（クイックスタート）の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.
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.
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からの例として、不正動作するノードと外部の攻撃者のパフォーマンスは、セクション9.4、9.5で説明され、そして[RFC4782]（クイックスタート）の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].
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.
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からの例として、配備問題がセクション10.3 [RFC4782]（クイックスタート）の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].
ラースエッゲルトとアーロンフォークとの議論は、この文書を播種しました。ボブ・ブリスコー、Gorry Fairhurst、ダグリース、Jitendra Padhye、コリンパーキンス、ペッカSavola、TSVWGのメンバー、およびフィードバックと貢献のために、Microsoft ResearchのTCPワークショップの参加者に感謝します。この文書はまた、[メトリクス]から描画します。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "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]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（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]フロイド、S.、およびヤコブソン、V.、ランダム早期検出ゲートウェイ輻輳回避のため、ネットワーキング、V.1 N.4、1993年8月にIEEE / ACM取引。
[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]オールマン、M.、グローバー、D.、およびL.サンチェス、BCP 28、RFC 2488、1999年1月、 "標準的なメカニズムを使用して強化TCP上の衛星テレビ"。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティング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]ドーキンス、S.、モンテネグロ、G.、古城、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]ドーキンス、S.、モンテネグロ、G.、古城、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]フロイド、S.、 "大混雑Windows用の高速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]フロイド、S.とJ.ケンプ、「インターネットでの音声トラフィックのための輻輳制御に関する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]カーン、P.、ボルマン、C.、Fairhurst、G.、グロスマン、D.、ルートヴィヒ、R.、Mahdavi、J.、モンテネグロ、G.、タッチ、J.、およびL.ウッド、「アドバイスインターネットサブネットワークデザイナー」、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.、レディ、A. N.、オールマン、M.、およびE.ブラントン、 "非輻輳イベントへの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]フロイド、S.、オールマン、M.、ジャイナ教、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.フロイドおよびE.コーラー、シミュレーションとテストベッドシナリオの評価、進捗状況、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/
サリーフロイドICIR（インターネットリサーチのためのICSIセンター）1947センターストリート、スイート600バークレー、CA 94704から1198電話：+1（510）666から2989 Eメール：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バークレー、CA 94704から1198電話：（440）235から1792 Eメール：mallman@icir.org URL：http://www.icir.org/mallman/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。