Internet Research Task Force (IRTF) D. Papadimitriou, Ed.
Request for Comments: 6077 Alcatel-Lucent
Category: Informational M. Welzl
ISSN: 2070-1721 University of Oslo
M. Scharf
University of Stuttgart
B. Briscoe
BT & UCL
February 2011
Open Research Issues in Internet Congestion Control
Abstract
抽象
This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet-scale solutions can be confidently engineered and deployed.
この文書では、今日知られているインターネットの輻輳制御で開いている問題のいくつかを説明します。これは、いくつかの新しいネットワークの成長に合わせて重要になっている課題のほか、長年知られているいくつかの問題を含んでいます。これらの課題は、一般的に、インターネット規模のソリューションを自信を持って設計して展開することができる前に、より多くの研究や革新的な技術の適用を必要とするかもしれない、オープンな研究テーマであると考えられています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Internet Congestion Control Research Group (ICCRG) of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書はインターネットResearch Task Force（IRTF）の製品です。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。このRFCはインターネットResearch Task Force（IRTF）のインターネット輻輳制御研究グループ（ICCRG）のコンセンサスを表しています。 IRSGによって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6077.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6077で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 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/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Global Challenges ...............................................5
2.1. Heterogeneity ..............................................5
2.2. Stability ..................................................7
2.3. Fairness ...................................................8
3. Detailed Challenges ............................................10
3.1. Challenge 1: Network Support ..............................10
3.1.1. Performance and Robustness .........................14
3.1.2. Granularity of Network Component Functions .........15
3.1.3. Information Acquisition ............................16
3.1.4. Feedback Signaling .................................17
3.2. Challenge 2: Corruption Loss ..............................17
3.3. Challenge 3: Packet Size ..................................19
3.4. Challenge 4: Flow Startup .................................24
3.5. Challenge 5: Multi-Domain Congestion Control ..............26
3.5.1. Multi-Domain Transport of Explicit
Congestion Notification ............................26
3.5.2. Multi-Domain Exchange of Topology or
Explicit Rate Information ..........................27
3.5.3. Multi-Domain Pseudowires ...........................28
3.6. Challenge 6: Precedence for Elastic Traffic ...............30
3.7. Challenge 7: Misbehaving Senders and Receivers ............31
3.8. Other Challenges ..........................................33
3.8.1. RTT Estimation .....................................33
3.8.2. Malfunctioning Devices .............................35
3.8.3. Dependence on RTT ..................................36
3.8.4. Congestion Control in Multi-Layered Networks .......36
3.8.5. Multipath End-to-End Congestion Control and
Traffic Engineering ................................37
3.8.6. ALGs and Middleboxes ...............................37
4. Security Considerations ........................................38
5. References .....................................................39
5.1. Informative References ....................................39
6. Acknowledgments ................................................50
7. Contributors ...................................................50
This document, the result of the Internet Congestion Control Research Group (ICCRG), describes some of the open research topics in the domain of Internet congestion control that are known today. We begin by reviewing some proposed definitions of congestion and congestion control based on current understandings.
このドキュメント、インターネットの輻輳制御研究グループ（ICCRG）の結果は、今日知られているインターネットの輻輳制御のドメインで開い研究課題のいくつかを説明します。私たちは現在の理解に基づいて、渋滞や混雑制御のいくつかの提案の定義を見直すことから始めます。
Congestion can be defined as a state or condition that occurs when network resources are overloaded, resulting in impairments for network users as objectively measured by the probability of loss and/or delay. The overload results in the reduction of utility in networks that support both spatial and temporal multiplexing, but no reservation [Keshav07]. Congestion control is a (typically distributed) algorithm to share network resources among competing traffic sources.
輻輳は、ネットワーク・リソースが過負荷されたときのような客観的損失および/または遅延の確率によって測定されたネットワークユーザのための障害を生じる、発生または状態として定義することができます。過負荷の両方の空間的及び時間的多重化をサポートするネットワークにおける有用性の減少をもたらすが、無予約【Keshav07]。輻輳制御は、競合トラフィックソース間でネットワークリソースを共有する（典型的には分散）アルゴリズムです。
Two components of distributed congestion control have been defined in the context of primal-dual modeling [Kelly98]. Primal congestion control refers to the algorithm executed by the traffic sources for controlling their sending rates or window sizes. This is normally a closed-loop control, where this operation depends on feedback. TCP algorithms fall in this category. Dual congestion control is implemented by the routers through gathering information about the traffic traversing them. A dual congestion control algorithm updates, implicitly or explicitly, a congestion measure or congestion rate and sends it back, implicitly or explicitly, to the traffic sources that use that link. Queue management algorithms such as Random Early Detection (RED) [Floyd93] or Random Exponential Marking (REM) [Ath01] fall into the "dual" category.
分散型輻輳制御の2つの成分は[Kelly98】主双対モデリングの文脈で定義されています。プライマル輻輳制御は、その送信速度やウィンドウサイズを制御するためのトラフィックソースによって実行されるアルゴリズムを指します。これは、通常、この操作は、フィードバックに依存して閉ループ制御です。 TCPアルゴリズムは、このカテゴリーに入ります。デュアル輻輳制御は、それらを通過するトラフィックに関する情報を収集して、ルータによって実装されます。暗黙的または明示的に二重の輻輳制御アルゴリズムのアップデート、渋滞対策や混雑率とそのリンクを使用してトラフィックソースに、暗黙的または明示的に、それを送り返します。そのようなランダム早期検出（RED）[Floyd93]またはランダム指数マーキング（REM）[Ath01]としてキュー管理アルゴリズムは、「デュアル」カテゴリーに分類されます。
Congestion control provides for a fundamental set of mechanisms for maintaining the stability and efficiency of the Internet. Congestion control has been associated with TCP since Van Jacobson's work in 1988, but there is also congestion control outside of TCP (e.g., for real-time multimedia applications, multicast, and router-based mechanisms) [RFC5783]. The Van Jacobson end-to-end congestion control algorithms [Jacobson88] [RFC2581] [RFC5681] are used by the Internet transport protocol TCP [RFC4614]. They have been proven to be highly successful over many years but have begun to reach their limits, as the heterogeneity of the data link and physical layer on the one hand, and of applications on the other, are pulling TCP congestion control beyond its natural operating regime. This is because it performs poorly as the bandwidth or delay increases. A side effect of these deficiencies is that an increasing share of hosts use non-standardized congestion control enhancements (for instance, many Linux distributions have been shipped with "CUBIC" [Ha08] as the default TCP congestion control mechanism).
輻輳制御は、インターネットの安定性と効率性を維持するためのメカニズムの基本的なセットを提供します。輻輳制御は1988年バン・ジェイコブソンの仕事ためTCPに関連しているが、輻輳制御TCPの外部（例えば、リアルタイムマルチメディアアプリケーション、マルチキャスト、およびルータベースのメカニズムのため）[RFC5783]もあります。バン・ジェイコブソンエンドツーエンドの輻輳制御アルゴリズムは、[Jacobson88] [RFC2581]、[RFC5681]インターネットトランスポートプロトコルTCP [RFC4614]で使用されます。彼らは長年にわたり非常に成功であることが証明されているが、その限界に到達し始めている、一方では、データリンク層および物理層の不均一など、その他のアプリケーションの、その自然な動作を超えてTCPの輻輳制御を引いています政権。それは帯域幅や遅延が増加するにつれて不十分行うためです。これらの欠陥の副作用は、ホストの増加割合が非標準化された輻輳制御の機能強化は、（例えば、多くのLinuxディストリビューションは、デフォルトのTCP輻輳制御機構として[Ha08]「CUBIC」に同梱されている）を使用することです。
While the original Van Jacobson algorithm requires no congestion-related state in routers, more recent modifications have departed from the strict application of the end-to-end principle [Saltzer84] in order to avoid congestion collapse. Active Queue Management (AQM) in routers, e.g., RED and some of its variants such as Adaptive RED (ARED), improves performance by keeping queues small (implicit feedback via dropped packets), while Explicit Congestion Notification (ECN) [Floyd94] [RFC3168] passes one bit of congestion information back to senders when an AQM would normally drop a packet. It is to be noted that other variants of RED built on AQM, such as Weighted RED (WRED) and RED with In/Out (RIO) [Clark98] are for quality enforcement, whereas Stabilized RED (SRED), and CHOKe [Pan00] and its extensions such as XCHOKe [Chhabra02], are flow policers. In [Bonald00], authors analytically evaluated RED performance.
元ヴァンヤコブソンアルゴリズムはルータに輻輳関連状態を必要としないが、より最近の変形は、輻輳崩壊を回避するために、エンド・ツー・エンドの原則[Saltzer84]の厳しいアプリケーションから出発しました。アクティブキュー管理（AQM）ルータでは、例えば、REDと、このような適応RED（ARED）としてその変種のいくつかは、小さな（パケットのドロップを経由して、暗黙的なフィードバック）のキューを維持することにより、パフォーマンスを向上しますが、明示的輻輳通知（ECN）[Floyd94] [ AQMは、通常、パケットをドロップすることになる場合RFC3168]は送信者に戻って渋滞情報の1ビットを通過させます。これは、REDの他の変形は、イン/アウト（RIO）で重み付けRED（WRED）とREDとして、AQM上に構築されたことに留意すべきである[Clark98]、品質の執行のためのものである安定化RED（SRED）、チョーク[Pan00]に対しそのようなXCHOKe [Chhabra02]、としてその拡張は、フローポリサーです。 [Bonald00]では、著者は解析的にREDの性能を評価しました。
These measures do improve performance, but there is a limit to how much can be accomplished without more information from routers. The requirement of extreme scalability together with robustness has been a difficult hurdle for acceleration of this information flow. Primal-dual TCP/AQM distributed algorithm stability and equilibrium properties have been extensively studied (cf. [Low02], [Low03.1], [Low03.2], [Kelly98], and [Kelly05]).
これらの措置は、パフォーマンスを向上させるんが、ルータからのより多くの情報なしに達成することができますどのくらいには限界があります。堅牢とともに極端なスケーラビリティの要件は、この情報の流れを加速するための困難なハードルでした。主双対TCP / AQM分散アルゴリズムの安定性および平衡特性は、広範囲（参照[Low02]、[Low03.1]、[Low03.2]、[Kelly98]、および[Kelly05]）が検討されています。
Congestion control includes many new challenges that are becoming important as the network grows, in addition to the issues that have been known for many years. These are generally considered to be open research topics that may require more study or application of innovative techniques before Internet-scale solutions can be confidently engineered and deployed. In what follows, an overview of some of these challenges is given.
輻輳制御は、ネットワークの成長に合わせて長年知られている問題に加えて、重要になっている多くの新たな課題を含んでいます。これらは一般に、インターネット規模のソリューションを自信を持って設計して展開することができる前に、より多くの研究や革新的な技術の適用を必要とするかもしれない、オープンな研究テーマであると考えられています。以下では、これらの課題のいくつかの概要が与えられています。
This section describes the global challenges to be addressed in the domain of Internet congestion control.
このセクションでは、インターネットの輻輳制御のドメインに対処すべきグローバルな課題について説明します。
The Internet encompasses a large variety of heterogeneous IP networks that are realized by a multitude of technologies, which result in a tremendous variety of link and path characteristics: capacity can be either scarce in very-slow-speed radio links (several kbps), or there may be an abundant supply in high-speed optical links (several gigabit per second). Concerning latency, scenarios range from local interconnects (much less than a millisecond) to certain wireless and satellite links with very large latencies up to or over a second). Even higher latencies can occur in space communication. As a consequence, both the available bandwidth and the end-to-end delay in the Internet may vary over many orders of magnitude, and it is likely that the range of parameters will further increase in the future.
インターネットリンクとパス特性の膨大な多様をもたらす技術、多数によって実現される異種IPネットワークの多種多様を包含する：容量は、超低速無線リンク（数kbpsの）、またはで不足のいずれかであることができます高速光リンク（毎秒数ギガビット）で豊富な供給が存在してもよいです。レイテンシについては、シナリオは、最大又は）第二上、非常に大きな待ち時間を有する特定の無線及び衛星リンクに（ミリ秒よりはるかに少ない）ローカル相互接続の範囲です。さらに高いレイテンシが宇宙通信で発生する可能性があります。その結果、利用可能な帯域幅やインターネットでのエンドツーエンド遅延の両方が何桁にわたって変化し得る、パラメータの範囲は今後さらに増加する可能性があります。
Additionally, neither the available bandwidth nor the end-to-end delay is constant. At the IP layer, competing cross-traffic, traffic management in routers, and dynamic routing can result in sudden changes in the characteristics of an end-to-end path. Additional dynamics can be caused by link layer mechanisms, such as shared-media access (e.g., in wireless networks), changes to new links due to mobility (horizontal/vertical handovers), topology modifications (e.g., in ad hoc or meshed networks), link layer error correction, and dynamic bandwidth provisioning schemes. From this, it follows that path characteristics can be subject to substantial changes within short time frames.
また、利用可能な帯域幅やエンドツーエンド遅延もないが一定です。 IP層では、クロストラフィック、ルータにおけるトラフィック管理、および動的ルーティング競合するエンドツーエンドパスの特性の急激な変化をもたらすことができます。追加のダイナミクスは、共有メディアアクセスモビリティに起因する新たなリンク（例えば、無線ネットワークにおいて）、変更（水平/垂直ハンドオーバ）、（アドホックまたはメッシュネットワークにおいて、例えば、）トポロジ変更などのリンク層メカニズムによって引き起こされる可能性が、層の誤り訂正、及び動的帯域幅プロビジョニング方式をリンク。このことから、パス特性は、短い時間枠内に実質的な変化を受けることができることになります。
Congestion control algorithms have to deal with this variety in an efficient and stable way. The congestion control principles introduced by Van Jacobson assume a rather static scenario and implicitly target configurations where the bandwidth-delay product is of the order of some dozens of packets at most. While these principles have proved to work in the Internet for almost two decades, much larger bandwidth-delay products and increased dynamics challenge them more and more. There are many situations where today's congestion control algorithms react in a suboptimal way, resulting, among other things, in low resource utilization.
輻輳制御アルゴリズムは、効率的かつ安定的な方法でこの多様性に対処する必要があります。バン・ジェイコブソンによって導入された輻輳制御の原理はかなり静的なシナリオを想定し、暗黙的に帯域幅遅延積が最大でパケットの数十程度である構成を標的とします。これらの原則は、ほぼ二十年のためにインターネットで働くことを証明しているが、はるかに大きな帯域幅遅延製品と増加したダイナミクスは、より多くのそれらに挑戦します。今日の輻輳制御アルゴリズムは、低リソース使用率で、とりわけ、その結果、次善の方法で反応する多くの状況があります。
This has resulted in a multitude of new proposals for congestion control algorithms. For instance, since the Additive Increase Multiplicative Decrease (AIMD) behavior of TCP is too conservative in practical environments when the congestion window is large, several high-speed congestion control extensions have been developed. However, these new algorithms may be less robust or starve legacy flows in certain situations for which they have not been designed. At the time of writing, there is no common agreement in the IETF on which algorithm(s) and protocol(s) to choose.
これは、輻輳制御アルゴリズムのための新しい提案の多くをもたらしました。輻輳ウィンドウが大きい場合、例えば、TCPの添加剤は、乗算減少を増やすため（AIMD）現象が実用環境下においても保守的であり、いくつかの高速輻輳制御の拡張が開発されています。しかし、これらの新しいアルゴリズムはあまり強固であるか、または、彼らは設計されていないいるため、特定の状況では、従来のフローを飢えさせることがあります。執筆時点では、選択するアルゴリズム（複数可）とプロトコル（複数可）にIETFには一般的な合意はありません。
It is always possible to tune congestion control parameters based on some knowledge of the environment and the application scenario. However, the interaction between multiple congestion control techniques is not yet well understood. The fundamental challenge is whether it is possible to define one congestion control mechanism that operates reasonably well in a whole range of scenarios that exist in the Internet. Hence, important research questions are how new Internet congestion control mechanisms would have to be designed, which maximum degree of dynamics they can efficiently handle, and whether they can keep the generality of the existing end-to-end solutions.
これは、環境のいくつかの知識とアプリケーションのシナリオに基づいて調整する輻輳制御パラメータに常に可能です。しかし、複数の輻輳制御技術との間の相互作用はまだよく理解されていません。根本的な課題は、インターネットに存在するシナリオの全範囲に合理的に動作する1つの輻輳制御機構を定義することが可能であるかどうかです。したがって、重要な研究課題では、インターネットの輻輳制御機構は、彼らが効率的に扱うことができるダイナミクスの最大どの程度、設計しなければならないか新しい、そして、彼らは既存のエンド・ツー・エンドのソリューションの一般性を保つことができるかどうかです。
Some improvements to congestion control could be realized by simple changes to single functions in end-systems or optimizations of network components. However, new mechanism(s) might also require a fundamental redesign of the overall network architecture, and they may even affect the design of Internet applications. This can imply significant interoperability and backward compatibility challenges and/or create network accessibility obstacles. In particular, networks and/or applications that do not use or support a new congestion control mechanism could be penalized by a significantly worse performance compared to what they would get if everybody used the existing mechanisms (cf. the discussion on fairness in Section 2.3). [RFC5033] defines several criteria to evaluate the appropriateness of a new congestion control mechanism. However, a key issue is how much performance deterioration is acceptable for "legacy" applications. This tradeoff between performance and cost has to be very carefully examined for all new congestion control schemes.
輻輳制御にいくつかの改善は、エンドシステムまたはネットワークコンポーネントの最適化における単一機能への簡単な変更によって実現することができます。しかし、新しいメカニズム（複数可）も、全体的なネットワークアーキテクチャの基本的な再設計が必要になることがありますし、彼らも、インターネットアプリケーションの設計に影響を与える可能性があります。これは重要な相互運用性と下位互換性の問題を暗示および/またはネットワークのアクセシビリティ障害物を作成することができます。具体的には、ネットワークおよび/または新規の輻輳制御機構を使用するか、またはサポートしていないアプリケーションでは、誰もが（2.3節における公正性に関する議論を参照されたい）既存のメカニズムを使用した場合、彼らはなるだろう何に比べて大幅に悪化した性能により罰せられることができ。 [RFC5033]は、新たな輻輳制御機構の妥当性を評価するためにいくつかの基準を定義します。しかし、重要な問題は、非常に性能劣化が「レガシー」アプリケーションに受け入れられる方法です。性能とコストとの間のこのトレードオフは非常に慎重にすべての新しい輻輳制御方式について検討する必要があります。
Control theory is a mathematical tool for describing dynamic systems. It lends itself to modeling congestion control -- TCP is a perfect example of a typical "closed loop" system that can be described in control theoretic terms. However, control theory has had to be extended to model the interactions between multiple control loops in a network [Vinnic02]. In control theory, there is a mathematically defined notion of system stability. In a stable system, for any bounded input over any amount of time, the output will also be bounded. For congestion control, what is actually meant by global stability is typically asymptotic stability: a mechanism should converge to a certain state irrespective of the initial state of the network. Local stability means that if the system is perturbed from its stable state it will quickly return toward the locally stable state.
制御理論は、動的システムを記述するための数学的なツールです。これは、モデリングの輻輳制御に適しています - TCPは、制御理論の観点から説明することができ、典型的な「閉ループ」システムの完璧な例です。しかし、制御理論は、[Vinnic02】ネットワーク内の複数の制御ループ間の相互作用をモデル化するために拡張しなければなりませんでした。制御理論では、システムの安定性の数学的に定義された概念があります。安定したシステムでは、時間の任意の量を超える任意の有界入力に対して、出力も有界であろう。輻輳制御のために、どのような実際のグローバル安定性が意味するものは、典型的には漸近安定である：メカニズムは、ネットワークの初期状態にかかわらず、特定の状態に収束するべきです。地元の安定性は、システムがその安定状態から乱された場合、それはすぐに局部的に安定した状態に向かって戻ることを意味します。
Some fundamental facts known from control theory are useful as guidelines when designing a congestion control mechanism. For instance, a controller should only be fed a system state that reflects its output. A (low-pass) filter function should be used in order to pass to the controller only states that are expected to last long enough for its action to be meaningful [Jain88]. Action should be carried out whenever such feedback arrives, as it is a fundamental principle of control that the control frequency should ideally be equal to the feedback frequency. Reacting faster leads to oscillations and instability, while reacting more slowly makes the system tardy [Jain90].
輻輳制御機構を設計する際に制御理論から知られているいくつかの基本的な事実は指針として有用です。例えば、コントローラは、その出力を反映したシステム状態を与えなければなりません。 （ローパス）フィルタ機能コントローラへの作用は[Jain88]有意義であるために十分長く持続することが期待されているだけの状態を渡すために使用されるべきです。それは制御周波数は、理想的には、フィードバック周波数に等しくなければならないことを制御の基本的な原則であるようなフィードバックは、到着するたびアクションが実行されるべきです。もっとゆっくり反応しながら、振動や不安定性への高速リードを反応させて、システムの遅刻[Jain90]になります。
Control theoretic modeling of a realistic network can be quite difficult, especially when taking distinct packet sizes and heterogeneous round-trip times (RTTs) into account. It has therefore become common practice to model simpler cases and to leave the more complicated (realistic) situations for simulations. Clearly, if a mechanism is not stable in a simple scenario, it is generally useless; this method therefore helps to eliminate faulty congestion control candidates at an early stage. However, a mechanism that is found to be stable in simulations can still not be safely deployed in real networks, since simulation scenarios make simplifying assumptions.
アカウントに個別のパケットサイズと異種の往復時間（RTTの）を服用する場合は特に、非常に困難なことが現実的なネットワークの理論的モデリングを制御します。したがって、単純な例をモデル化し、シミュレーションのためのより複雑な（現実的）な状況を残すために一般的になってきています。機構は、単純なシナリオでは安定していない場合は、明らかに、それは一般的に無駄です。この方法は、したがって、早い段階で障害のある輻輳制御候補を排除することができます。シミュレーションシナリオが単純化仮定を行うので、シミュレーションで安定していることが発見されたメカニズムは、まだ安全に、実際のネットワークに配置することはできません。
TCP stability can be attributed to two key aspects that were introduced in [Jacobson88]: the AIMD control law during congestion avoidance, which is based on a simple, vector-based analysis of two controllers sharing one resource with synchronous RTTs [Chiu89]; and the "conservation of packets principle", which, once the control has reached "steady state", tries to maintain an equal amount of packets in flight at any time by only sending a packet into the network when a packet has left the network (as indicated by an ACK arriving at the sender). The latter aspect has guided many decisions regarding changes that were made to TCP over the years.
TCPの安定性は、[Jacobson88]で導入された2つの重要な側面に帰することができる。同期のRTT [Chiu89]とつのリソースを共有する二つのコントローラの単純なベクトルベースの分析に基づいて、輻輳回避、中AIMD制御則。そして制御は、「定常状態」に達した後、パケットがネットワークを離れた場合、（のみネットワークにパケットを送信することによって、いつでも飛行中のパケットの等しい量を維持しようと、「パケット原則の保全」、 ACKによって示されるように）送信者に到着。後者の側面は、長年にわたってTCPに加えられた変更に関する多くの決定を導きました。
The reasoning in [Jacobson88] assumes all senders to be acting at the same time. The stability of TCP under more realistic network conditions has been investigated in a large number of ensuing works, leading to no clear conclusion that TCP would also be asymptotically stable under arbitrary network conditions. On the other hand, research has concluded that stability can be assured with constraints on dynamics that are less stringent than the "conservation of packets principle". From control theory, only rate increase (not the target rate) needs to be inversely proportional to RTT (whereas window-based control converges on a target rate inversely proportional to RTT). A congestion control mechanism can therefore converge on a rate that is independent of RTT as long as its dynamics depend on RTT (e.g., FAST TCP [Jin04]).
[Jacobson88]における推論はすべての送信者が同時に動作することを前提としています。より現実的なネットワーク条件下でのTCPの安定性は、TCPはまた、任意のネットワーク条件の下で漸近安定になる明確な結論につながる、その後の作品の大多数に研究されてきました。一方、研究は、安定性は、「パケット原理の保全」よりも厳しくない力学上の制約を保証することができると結論づけました。制御理論からは、唯一の速度増加（ない目標レート）は、（ウィンドウベースの制御はRTTに反比例目標レートに収束するのに対し）RTTに反比例する必要があります。輻輳制御メカニズムは、したがって、限り、そのダイナミクスがRTT（例えば、FAST TCP [Jin04]）に依存するようにRTTとは独立している速度に収束させることができます。
In the stability analysis of TCP and of these more modern controls, the impact of slow-start on stability (which can be significant as short-lived HTTP flows often never leave this phase) is not entirely clear.
TCPのこれらのより近代的な制御の安定性解析では、安定性にスロースタートの影響は（短命HTTPは、多くの場合、このフェーズを離れることはない流れのように大きくなる可能性がある）完全には明らかではありません。
Recently, the way the Internet community reasons about fairness has been called deeply into question [Bri07]. Much of the community has taken fairness to mean approximate equality between the rates of flows (flow rate fairness) that experience equivalent path congestion as with TCP [RFC2581] [RFC5681] and TCP-Friendly Rate Control (TFRC) [RFC5348]. [RFC3714] depicts the resulting situation as "The Amorphous Problem of Fairness".
最近、公正についてのインターネットコミュニティの理由の方法は、[Bri07]疑問に深く呼ばれています。コミュニティの多くは、流れの速度間のおおよその平等（流量公平性）TCP [RFC2581] [RFC5681]とTCPフレンドリーレート制御（TFRC）[RFC5348]のようにその経験同等のパスの輻輳を意味する公平性をとっています。 [RFC3714]は「公平性のアモルファス問題」として得られた状況を示しています。
A parallel tradition has been built on [Kelly98] where, as long as each user is accountable for the cost their rate causes to others [MacK95], the set of rates that everyone chooses is deemed fair (cost fairness) -- because with any other set of choices people would lose more value than they gained overall.
なぜならいずれかと - パラレル伝統は、[Kelly98]限り、各ユーザーが他にコスト彼らの率の原因に対して責任があるとして、[MacK95]、みんなが選ぶレートのセットが（コスト公平性）公正があると認める場合には、上に構築されています彼らは、全体の獲得よりも、選択肢の他のセットは、人々がより多くの価値を失うことになります。
In comparison, the debate between max-min, proportional, and TCP fairness is about mere details. These three all share the assumption that equal flow rates are desirable; they merely differ in the second-order issue of how to share out excess capacity in a network of many bottlenecks. In contrast, cost fairness should lead to extremely unequal flow rates by design. Equivalently, equal flow rates would typically be considered extremely unfair.
比較して、最大 - 最小、比例、およびTCP公平性との議論は、単なる細部についてです。これら三つの全てが等しい流量が望まれているという前提を共有します。彼らは単に多くのボトルネックのネットワークに余剰能力を共有する方法の第二次発行が異なります。これとは対照的に、コストの公平性が設計によって非常に不均等な流量につながるはずです。等価的に、同等の流量は通常、非常に不公平であると考えられます。
The two traditional approaches are not protocol options that can each be followed in different parts of an internetwork. They lead to research agendas that are different in their respective objectives, resulting in a different set of open issues.
2つの伝統的なアプローチは、各々がインターネットワークの異なる部分に続くことができるプロトコル・オプションはありません。彼らは、未解決の問題の別のセットで、その結果、それぞれの目的が異なっている課題を検索するに至ります。
If we assume TCP-friendliness as a goal with flow rate as the metric, open issues would be:
我々はメトリックとして流量と目標としてTCPフレンドリーを前提とした場合は、未解決の問題は次のようになります。
- Should flow fairness depend on the packet rate or the bit rate?
- パケットレートやビットレートに依存して公平性を流れるべき？
- Should the target flow rate depend on RTT (as in TCP) or should only flow dynamics depend on RTT (e.g., as in FAST TCP [Jin04])?
- 目標流量は、（TCPのように）RTTに依存すべきのみ流体力学（例えば、FAST TCP [Jin04]のように）RTTに依存する必要がありますか？
- How should we estimate whether a particular flow start strategy is fair, or whether a particular fast recovery strategy after a reduction in rate due to congestion is fair?
- どのように我々は、特定のフロー開始ストラテジーが公正であるかどうか、あるいは、輻輳に起因する割合が減少した後、特定の速い回復戦略が公正であるかどうかを見積もる必要がありますか？
- Should we judge what is reasonably fair if an application needs, for example, even smoother flows than TFRC, or it needs to burst occasionally, or with any other application behavior?
- アプリケーションのニーズTFRCよりも、例えば、でもスムーズに流れた場合、我々は合理的に公平であるものを判断し、またはそれは、あるいは他のアプリケーションの動作で、時折破裂する必要がありますでしょうか？
- During brief congestion bursts (e.g., due to new flow arrivals), how should we judge at what point it becomes unfair for some flows to continue at a smooth rate while others reduce their rate?
- 簡単な混雑バースト（例えば、原因の新しい流れの到着まで）の間に、どのように我々は他の人が彼らの率を減らす一方で、いくつかの流れがスムーズな速度で継続することは不公平になりどの時点で判断する必要がありますか？
- Which mechanism(s) could be used to enforce approximate flow rate fairness?
- どのメカニズム（複数可）おおよその流量公平性を強制するために使用されるだろうか？
- Should we introduce some degree of fairness that takes into account different users' flow activity over time?
- 私たちは、時間をかけて、アカウント別のユーザーのフロー活動に取り、公平性をある程度導入すべき？
- How should we judge the fairness of applications using a large number of flows over separate paths (e.g., via an overlay)?
- どのように我々は（オーバーレイ経由例えば、）別々のパス上のフローを多数使用したアプリケーションの公正性を判断する必要がありますか？
If we assume cost fairness as a goal with congestion-volume as the metric, open issues would be:
我々はメトリックとして輻輳ボリュームとの目標としてコストの公平性を仮定した場合、未解決の問題は次のようになります。
- Can one application's sensitivity to instantaneous congestion really be protected by longer-term accountability of competing applications?
- 瞬時の混雑にあるアプリケーションの感度は本当に競合するアプリケーションの長期的な責任で保護することはできますか？
- Which protocol mechanism(s) are needed to give accountability for causing congestion?
- どのプロトコルメカニズム（S）は、輻輳の原因となるため、説明責任を与えるために必要とされていますか？
- How might we design one or two weighted transport protocols (such as TCP, UDP, etc.) with the addition of application policy control over the weight?
- どのように我々は重量を超えるアプリケーションのポリシー制御を加えて（などTCP、UDP、など）は、1つのまたは2つの重み付けのトランスポートプロトコルを設計するのでしょうか？
- Which policy enforcement might be used by networks, and what are the interactions between application policy and network policy enforcement?
- どのポリシーの施行は、ネットワークで使用されるかもしれない、とアプリケーションポリシーおよびネットワークポリシーの施行の間の相互作用は何ですか？
- How should we design a new policy enforcement framework that will appropriately compete with existing flows aiming for rate equality (e.g., TCP)?
- どのように我々は適切レート平等（例えば、TCP）を目指す既存のフローと競合する新たな政策執行の枠組みを設計する必要がありますか？
The question of how to reason about fairness is a prerequisite to agreeing on the research agenda. If the relevant metric is flow rate, it places constraints at protocol design time, whereas if the metric is congestion-volume, the constraints move to run-time while design-time constraints can be relaxed [Bri08]. However, that question does not require more research in itself; it is merely a debate that needs to be resolved by studying existing research and by assessing how bad fairness problems could become if they are not addressed rigorously, and whether we can rely on trust to maintain approximate fairness without requiring policing complexity [RFC5290]. The latter points may themselves lead to additional research. However, it is also accepted that more research will not necessarily lead to convincing either side to change their opinions. More debate would be needed. It seems also that if the architecture is built to support cost fairness, then equal instantaneous cost rates for flows sharing a bottleneck result in flow-rate fairness; that is, flow-rate fairness can be seen as a special case of cost fairness. One can be used to build the other, but not vice-versa.
公正性について推論する方法についての質問は、研究課題について合意するための前提条件です。関連するメトリックは流量である場合にはメトリックが混雑ボリュームであれば、制約が実行時にするために、設計時の制約が[Bri08]緩和することができる一方で移動するのに対し、それは、プロトコルの設計時に制約を課します。しかし、その質問自体がより多くの研究を必要としません。それは単に既存の研究を研究することによって、彼らは厳格に対処されていない場合になる可能性がどのように悪い、公平性の問題を評価することによって解決される必要があり、我々はポリシング複雑[RFC5290]を必要とせず、おおよその公平性を維持するために、信頼に頼ることができるかどうかの議論です。後者の点は、それ自体が、追加の研究につながる可能性があります。しかし、また、より多くの研究が、必ずしも自分の意見を変更するにはいずれかの側を説得するにはつながらないだろうことが認められています。より多くの議論が必要であろう。アーキテクチャは、コストの公平性をサポートするために構築されている場合は、フローのための同等の瞬間コスト率は、流量公平にボトルネックの結果を共有することもそうです。つまり、流量公平性は、コスト公平性の特別なケースとして見ることができます。一つは、その逆、他のではなくを構築するために使用することができます。
This challenge is perhaps the most critical to get right. Changes to the balance of functions between the endpoints and network equipment could require a change to the per-datagram data plane interface between the transport and network layers. Network equipment vendors need to be assured that any new interface is stable enough (on decade timescales) to build into firmware and hardware, and operating-system vendors will not use a new interface unless it is likely to be widely deployed.
この課題は、権利を取得するために、おそらく最も重要です。エンドポイントとネットワーク機器との間の機能のバランスの変更は、トランスポート層とネットワーク層との間毎のデータグラムデータプレーンインターフェースへの変更を必要とする可能性があります。ネットワーク機器ベンダーは、広く展開されそうでなければ、新しいインターフェイスを使用することはありません、ファームウェアおよびハードウェア、およびオペレーティング・システム・ベンダーに構築するために、新しいインターフェースが（十年の時間スケールで）十分に安定であることを保証する必要があります。
Network components can be involved in congestion control in two ways: first, they can implicitly optimize their functions, such as queue management and scheduling strategies, in order to support the operation of end-to-end congestion control. Second, network components can participate in congestion control via explicit signaling mechanisms. Explicit signaling mechanisms, whether in-band or out-of-band, require a communication between network components and end-systems. Signals realized within or over the IP layer are only meaningful to network components that process IP packets. This always includes routers and potentially also middleboxes, but not pure link layer devices. The following section distinguishes clearly between the term "network component" and the term "router"; the term "router" is used whenever the processing of IP packets is explicitly required. One fundamental challenge of network-supported congestion control is that typically not all network components along a path are routers (cf. Section 3.1.3).
ネットワークコンポーネントは、2つの方法で輻輳制御に関与することができます：最初、彼らは暗黙のうちに、エンドツーエンドの輻輳制御の動作をサポートするために、そのようなキュー管理とスケジューリングの戦略として、その機能を最適化することができます。第二に、ネットワーク構成要素は、明示的なシグナル伝達機構を介して輻輳制御に参加することができます。明示的なシグナリングメカニズム、バンドまたはアウトオブバンドかどうかは、ネットワーク構成要素とエンドシステム間の通信を必要とします。 IP層内または上に実現信号がIPパケットを処理するネットワークコンポーネントにのみ意味があります。これは、常にルータや潜在的にもミドルボックスではなく、純粋なリンク層デバイスが含まれています。以下のセクションでは、用語「ネットワークコンポーネント」および用語「ルータ」との間にはっきりと区別する。 IPパケットの処理が明示的に必要とされるたびに用語「ルータ」は使用されています。ネットワークがサポートする輻輳制御の1つの基本的な課題は、典型的には、パスに沿ってすべてのネットワークコンポーネントは、ルータ（参照セクション3.1.3）であるということです。
The first (optimizing) category of implicit mechanisms can be implemented in any network component that processes and stores packets. Various approaches have been proposed and also deployed, such as different AQM techniques. Even though these implicit techniques are known to improve network performance during congestion phases, they are still only partly deployed in the Internet. This may be due to the fact that finding optimal and robust parameterizations for these mechanisms is a non-trivial problem. Indeed, the problem with various AQM schemes is the difficulty in identifying correct values of the parameters that affect the performance of the queuing scheme (due to variation in the number of sources, the capacity, and the feedback delay) [Firoiu00] [Hollot01] [Zhang03]. Many AQM schemes (RED, REM, BLUE, and PI-Controller, but also Adaptive Virtual Queue (AVQ)) do not define a systematic rule for setting their parameters.
暗黙的なメカニズムの最初の（最適化）カテゴリは、パケットを処理し、格納する任意のネットワーク構成要素で実現することができます。様々なアプローチが提案され、また、異なるAQM技術として、配備されています。これらの暗黙的な技術は、輻輳段階で、ネットワークのパフォーマンスを改善することが知られているにもかかわらず、彼らはまだ部分的にしかインターネットに配備されています。これは、これらのメカニズムのための最適かつ堅牢なパラメータ化を見つけること非自明な問題であるという事実に起因する可能性があります。実際、様々なAQM方式の問題点は、（これはソースの数、容量、およびフィードバック遅延の変動）にキューイングスキーム[Firoiu00] [Hollot01]の性能に影響を与えるパラメータの正しい値を識別することが困難です【Zhang03]。多くのAQMスキーム（RED、REM、BLUE、およびPI-コントローラが、また、アダプティブ仮想キュー（AVQ））はそのパラメータを設定するための体系的なルールを定義していません。
The second class of approaches uses explicit signaling. By using explicit feedback from the network, connection endpoints can obtain more accurate information about the current network characteristics on the path. This allows endpoints to make more precise decisions that can better control congestion.
アプローチの第二のクラスは、明示的なシグナリングを使用します。ネットワークからの明示的なフィードバックを使用することにより、接続エンドポイントは、経路上の現在のネットワーク特性に関するより正確な情報を得ることができます。これは、エンドポイントが制御輻輳をより良くすることができ、より正確な意思決定を行うことができます。
Explicit feedback techniques fall into three broad categories:
明示的なフィードバック技術は、大きく3つのカテゴリに分類されます。
- Explicit congestion feedback: one-bit Explicit Congestion Notification (ECN) [RFC3168] or proposals for more than one bit [Xia05];
- 明示的輻輳フィードバック：1ビットの明示的輻輳通知（ECN）[RFC3168]または複数のビット[Xia05]の提案。
- Explicit per-datagram rate feedback: the eXplicit Control Protocol (XCP) [Katabi02] [Falk07], or the Rate Control Protocol (RCP) [Dukki05];
- 明示的毎グラムレートフィードバック：明示的に制御プロトコル（XCP）Katabi02] [Falk07]、またはレート制御プロトコル（RCP）Dukki05]。
- Explicit rate feedback: by means of in-band signaling, such as by Quick-Start [RFC4782], or by means of out-of-band signaling, e.g., Congestion Avoidance with Distributed Proportional Control/Performance Transparency Protocol (CADPC/PTP) [Welzl03].
- 明示的なレートフィードバック次のようなインバンドシグナリングの手段、クイックスタート[RFC4782]による、またはアウトオブバンドシグナリングを用いて、例えば、分散型比例制御/パフォーマンス透明性プロトコル（CADPC / PTPと輻輳回避により、 ）[Welzl03]。
Explicit router feedback can address some of the inherent shortcomings of TCP. For instance, XCP was developed to overcome the inefficiency and instability that TCP suffers from when the per-flow bandwidth-delay product increases. By decoupling resource utilization/congestion control from fairness control, XCP achieves equal bandwidth allocation, high utilization, a small standing queue size, and near-zero packet drops, with both steady and highly varying traffic. Importantly, XCP does not maintain any per-flow state in routers and requires few CPU cycles per packet, hence making it potentially applicable in high-speed routers. However, XCP is still subject to research: as [Andrew05] has pointed out, XCP is locally stable but globally unstable when the maximum RTT of a flow is much larger than the mean RTT. This instability can be removed by changing the update strategy for the estimation interval, but this makes the system vulnerable to erroneous RTT advertisements. The authors of [Pap02] have shown that when flows with different RTTs are applied, XCP sometimes discriminates among heterogeneous traffic flows, even if XCP generally equalizes rates among different flows. [Low05] provides for a complete characterization of the XCP equilibrium properties.
明示的なルータのフィードバックは、TCPの固有の欠点のいくつかに対処することができます。例えば、XCPは非効率とTCPときフロー毎の帯域幅遅延積が増加罹患していることが不安定性を克服するために開発されました。フェアネス制御からリソース利用/輻輳制御を切り離すことにより、XCPは、等しい帯域幅割り当て、高い利用率、小さな定在キュー・サイズを達成、および近ゼロパケットは、安定性の高い変化の両方のトラフィックと、低下します。重要なのは、XCPは、ルータ内の任意のフローごとの状態を維持し、パケットごとにいくつかのCPUサイクルを必要とし、したがって、高速ルータでは、それが潜在的に適用することはありません。ただし、XCPは、まだ研究の対象となります。フローの最大RTTは平均RTTよりはるかに大きいとき[Andrew05]指摘したように、XCPは、局所的に安定したが、世界的に不安定です。この不安定性は、推定区間の更新戦略を変更することによって除去することができるが、これは誤ったRTT広告にシステムが脆弱になります。 【Pap02]の著者らは、異なるのRTTを有するフローが適用される場合異種トラフィックフローのうち、XCPは時々XCPは、一般的に異なるフローの間で速度を等しくしても、判別することが示されています。 【Low05] XCP平衡特性の完全な特性を提供します。
Several other explicit router feedback schemes have been developed with different design objectives. For instance, RCP uses per-packet feedback similar to XCP. But unlike XCP, RCP focuses on the reduction of flow completion times [Dukki06], taking an optimistic approach to flows likely to arrive in the next RTT and tolerating larger instantaneous queue sizes [Dukki05]. XCP, on the other hand, gives very poor flow completion times for short flows.
他のいくつかの明示的なルータのフィードバック方式は、異なる設計目標に開発されています。例えば、RCPは、XCPに似たパケットごとのフィードバックを使用しています。しかし、XCPとは異なり、RCPは、次のRTTに到着する可能性が高いフローに楽観的なアプローチを取って、[Dukki05]サイズより大きな瞬間キューを許容、フロー完了時間[Dukki06]の削減に焦点を当てています。 XCPは、他の一方で、短期フローのために非常に悪い流れの完了時間を与えます。
Both implicit and explicit router support should be considered in the context of the end-to-end argument [Saltzer84], which is one of the key design principles of the Internet. It suggests that functions that can be realized both in the end-systems and in the network should be implemented in the end-systems. This principle ensures that the network provides a general service and that it remains as simple as possible (any additional complexity is placed above the IP layer, i.e., at the edges) so as to ensure evolvability, reliability, and robustness. Furthermore, the fate-sharing principle ([Clark88], "Design Philosophy of the DARPA Internet Protocols") mandates that an end-to-end Internet protocol design should not rely on the maintenance of any per-flow state (i.e., information about the state of the end-to-end communication) inside the network and that the network state (e.g., routing state) maintained by the Internet shall minimize its interaction with the states maintained at the endpoints/hosts [RFC1958].
暗黙的および明示的の両方のルータのサポートは、インターネットの主要な設計原則の一つであるエンド・ツー・エンドの引数[Saltzer84]、の文脈で考えるべきです。これは、エンド・システムおよびネットワークの両方を実現することができる機能がエンド・システムに実装されるべきであることを示唆しています。進化可能性、信頼性、堅牢性を保証するように、この原理は、（エッジで、すなわち、任意の追加の複雑さは、IP層の上に配置されている）ネットワークは、一般的なサービスを提供することを保証し、それが可能な限り単純なままです。さらに、運命共有、エンドツーエンドのインターネットプロトコルの設計は、任意のフローごとの状態の維持に頼るべきではありません原則（[Clark88]、「DARPAインターネットプロトコルの設計理念」）任務（約すなわち、情報ネットワークの状態、ネットワークの内部及びそのエンド・ツー・エンド通信の状態）（例えば、状態は、エンドポイント/ホスト[RFC1958]に維持との相互作用を最小限にしなければならないインターネットによって維持ルーティング状態）。
However, as discussed in [Moors02] for instance, congestion control cannot be realized as a pure end-to-end function only. Congestion is an inherent network phenomenon and can only be resolved efficiently by some cooperation of end-systems and the network. Congestion control in today's Internet protocols follows the end-to-end design principle insofar as only minimal feedback from the network is used, e.g., packet loss and delay. The end-systems only decide how to react and how to avoid congestion. The crux is that on the one hand, there would be substantial benefit by further assistance from the network, but, on the other hand, such network support could lead to duplication of functions, which might even harmfully interact with end-to-end protocol mechanisms. The different requirements of applications (cf. the fairness discussion in Section 2.3) call for a variety of different congestion control approaches, but putting such per-flow behavior inside the network should be avoided, as such a design would clearly be at odds with the end-to-end and fate-sharing design principles.
ただし、で説明したように[Moors02]例えば、輻輳制御は、純粋なエンドツーエンドの機能として実現することができません。輻輳は、固有のネットワーク現象であり、唯一のエンドシステムとネットワークのいくつかの協働により、効率的に解決することができます。今日のインターネット・プロトコルにおける輻輳制御は、などのネットワークからのみ、最小限のフィードバックが使用され、例えば、パケットロスや遅延限りエンド・ツー・エンドの設計原則に従っています。エンドシステムにのみ反応する方法と、輻輳を回避する方法を決定します。核心は、一方では、ネットワークからのさらなる支援により、実質的な利点があるだろう、しかし、一方で、そのようなネットワークのサポートにも悪影響をエンド・ツー・エンドのプロトコルと対話するかもしれない、機能の重複につながる可能性があるということですメカニズム。このような設計ははっきりと対立しなように（2.3節における公平性の議論を参照）アプリケーションの異なる要件異なる輻輳制御の様々なアプローチを求めるが、ネットワーク内で、このようなフローごとの動作を入れては、避けるべきですエンド・ツー・エンドと運命を共有する設計の原則。
The end-to-end and fate-sharing principles are generally regarded as the key ingredients for ensuring a scalable and survivable network design. In order to ensure that new congestion control mechanisms are scalable, violating these principles must therefore be avoided.
エンド・ツー・エンドと運命共有の原則は、一般的にスケーラブルで存続ネットワーク設計を確保するための重要な要素とみなされています。新しい輻輳制御機構がスケーラブルであることを確実にするためには、これらの原則に違反するため、避けなければなりません。
For instance, protocols like XCP and RCP seem not to require flow state in the network, but this is only the case if the network trusts i) the receiver not to lie when feeding back the network's delta to the requested rate; ii) the source not to lie when declaring its rate; and iii) the source not to cheat when setting its rate in response to the feedback [Katabi04].
たとえば、XCPおよびRCPなどのプロトコルは、ネットワーク内の流動状態を要求していないように見えるが、これは唯一のケースであるかのネットワーク・トラストI）要求されたレートにネットワークのデルタをフィードバックする際に嘘をつくではない受信機。そのレートを宣言するときに嘘をつくではないII）源;フィードバック[Katabi04]に応答してその速度を設定する場合と、iii）ソースはカンニングしません。
Solving these problems for non-cooperative environments like the public Internet requires flow state, at least on a sampled basis. However, because flows can create new identifiers whenever they want, sampling does not provide a deterrent -- a flow can simply cheat until it is discovered and then switch to a whitewashed identifier [Feldman04], and continue cheating until it is discovered again ([Bri09], S7.3).
公共のインターネットのような非協力的な環境のため、これらの問題を解決することは、少なくともサンプリング基づいて、状態を流し必要です。 [（フローは、それが発見されるまで、単にカンニングして、白塗りの識別子[Feldman04]に切り替えて、それが再び発見されるまで、不正行為を続けることができます - 彼らはいつでもフローが新しい識別子を作成することができますので、しかし、サンプリングが抑止力を提供していません。 Bri09]、S7.3）。
However, holding flow state in the network only seems to solve these policing problems in single autonomous system settings. A multi-domain system would seem to require a completely different protocol structure, as the information required for policing is only seen as packets leave the internetwork, but the networks where packets enter will also want to police compliance.
ただし、ネットワーク内の流動状態を保持することは、単一の自律システム設定でこれらのポリシングの問題を解決するようです。マルチドメイン・システムは、ポリシングに必要な情報のみのパケットがインターネットを離れると見られているように、完全に異なるプロトコル構造を必要とするように見えるだろうが、パケットが入力したネットワークも、コンプライアンスを取り締まることになるでしょう。
Even if a new protocol structure were found, it seems unlikely that network flow state could be avoided given the network's per-packet flow rate instructions would need to be compared against variations in the actual flow rate, which is inherently not a per-packet metric. These issues have been outstanding ever since integrated services (IntServ) was identified as unscalable in 1997 [RFC2208]. All subsequent attempts to involve network elements in limiting flow rates (XCP, RCP, etc.) will run up against the same open issue if anyone attempts to standardize them for use on the public Internet.
新しいプロトコル構造が発見された場合でも、命令は、本質的に、パケットごとのメトリックではない実際の流量のばらつきに対して比較される必要があるであろうネットワークのパケットごとの流量与えられたネットワークフロー状態を避けることができたとは考えにくいです。これらの問題がされている優れ以来の統合サービス（IntServの）は1997 [RFC2208]にスケーラブルであると同定されました。後続のすべての試みは、誰もが公共のインターネット上での使用のためにそれらを標準化しようとした場合、同じ未解決の問題にぶつかるだろう流量（XCP、RCPなど）を制限するネットワーク要素が関与します。
In general, network support of congestion control raises many issues that have not been completely solved yet.
一般的には、輻輳制御のネットワークサポートはまだ完全には解決されていない多くの問題を提起します。
Congestion control is subject to some tradeoffs: on the one hand, it must allow high link utilizations and fair resource sharing, but on the other hand, the algorithms must also be robust.
輻輳制御は、いくつかのトレードオフの対象となります。一方では、それが高いリンク利用率と公平リソースの共有を許可する必要がありますが、一方で、アルゴリズムも堅牢でなければなりません。
Router support can help to improve performance, but it can also result in additional complexity and more control loops. This requires a careful design of the algorithms in order to ensure stability and avoid, e.g., oscillations. A further challenge is the fact that feedback information may be imprecise. For instance, severe congestion can delay feedback signals. Also, in-network measurement of parameters such as RTTs or data rates may contain estimation errors. Even though there has been significant progress in providing fundamental theoretical models for such effects, research has not completely explored the whole problem space yet.
ルーターのサポートは、パフォーマンスを向上させるために助けることができるが、それはまた、追加の複雑さとそれ以上の制御ループが発生することができます。これは、例えば、発振を安定性を確保し、避けるために、アルゴリズムを慎重に設計する必要があります。さらに課題は、フィードバック情報は不正確かもしれないという事実です。例えば、深刻な渋滞は、フィードバック信号を遅延させることができます。また、このようなのRTTまたはデータレートなどのパラメータの中のネットワークの測定は、推定誤差を含んでいてもよいです。このような効果のための基本的な理論モデルを提供する上で重要な進展があったにもかかわらず、研究はまだ完全に全体の問題空間を探索していません。
Open questions are:
オープンな質問は以下のとおりです。
- How much can network elements theoretically improve performance in the complete range of communication scenarios that exist in the Internet without damaging or impacting end-to-end mechanisms already in place?
- どのくらいのCANネットワーク要素は、理論的には、すでに場所で損傷または影響を与えるエンドツーエンドのメカニズムなしでインターネットに存在する通信シナリオの完全な範囲でのパフォーマンスを向上させますか？
- Is it possible to design robust congestion control mechanisms that offer significant benefits with minimum additional risks, even if Internet traffic patterns will change in the future?
- それは、インターネットのトラフィックパターンは、将来的に変更された場合でも、最小限の追加的なリスクと有意な利点を提供する堅牢な輻輳制御機構を設計することは可能ですか？
- What is the minimum support that is needed from the network in order to achieve significantly better performance than with end-to-end mechanisms and the current IP header limitations that provide at most unary ECN signals?
- エンドツーエンドのメカニズムと最も単項ECN信号で提供し、現在のIPヘッダの制限よりも有意に優れた性能を達成するために、ネットワークから必要とされる最低限のサポートとは何ですか？
There are several degrees of freedom concerning the involvement of network entities, ranging from some few additional functions in network management procedures on the one end to additional per-packet processing on the other end of the solution space. Furthermore, different amounts of state can be kept in routers (no per-flow state, partial per-flow state, soft state, or hard state). The additional router processing is a challenge for Internet scalability and could also increase end-to-end latencies.
ネットワークエンティティの関与に関するいくつかの自由度は、解空間のもう一方の端に一端上のネットワーク管理手順では、いくつかのいくつかの追加機能から追加のパケットあたりの処理に至るまで、があります。また、状態の異なる量は、ルータ（NOフローごとの状態、部分的なフローごとの状態、柔らかい状態、または硬い状態）に保つことができます。追加ルータの処理は、インターネットのスケーラビリティのための挑戦であり、また、エンドツーエンドのレイテンシを増加させる可能性があります。
Although there are many research proposals that do not require per-flow state and thus do not cause a large processing overhead, there are no known full solutions (i.e., including anti-cheating) that do not require per-flow processing. Also, scalability issues could be caused, for instance, by synchronization mechanisms for state information among parallel processing entities, which are, e.g., used in high-speed router hardware designs.
フローごとの状態を必要としないため、大規模な処理のオーバーヘッドが発生することはありません。多くの研究提案がありますが、フローごとの処理を必要としない（すなわち、抗不正行為を含む）には、既知の完全な解決策はありません。また、スケーラビリティの問題は、高速ルータのハードウェア設計に使用される、例えば、ある並列処理エンティティの間で状態情報の同期メカニズムによって、例えば、発生する可能性があります。
Open questions are:
オープンな質問は以下のとおりです。
- What granularity of router processing can be realized without affecting Internet scalability?
- ルータの処理のどのような粒度は、インターネットの拡張性に影響を与えることなく実現することができますか？
- How can additional processing efforts be kept to a minimum?
- どのように追加の処理努力を最小限に抑えることができますか？
In order to support congestion control, network components have to obtain at least a subset of the following information. Obtaining that information may result in complex tasks.
輻輳制御をサポートするために、ネットワーク構成要素は、以下の情報の少なくともサブセットを取得しなければなりません。その情報を取得することは複雑なタスクになることがあります。
Link characteristics depend on the realization of lower protocol layers. Routers operating at the IP layer do not necessarily know the link layer network topology and link capacities, and these are not always constant (e.g., on shared wireless links or bandwidth-on-demand links). Depending on the network technology, there can be queues or bottlenecks that are not directly visible at the IP networking layer.
リンク特性は、下位プロトコル層の実現に依存しています。 IP層で動作するルータは必ずしもリンクレイヤネットワークトポロジとリンク容量を知らない、そしてこれらは、（共有無線リンクまたはオンデマンド帯域幅リンクで、例えば）は常に一定ではありません。ネットワーク技術に応じて、IPネットワーク層で直接表示されていないキューまたはボトルネックが存在することができます。
Difficulties also arise when using IP-in-IP tunnels [RFC2003], IPsec tunnels [RFC4301], IP encapsulated in the Layer Two Tunneling Protocol (L2TP) [RFC2661], Generic Routing Encapsulation (GRE) [RFC1701] [RFC2784], the Point-to-Point Tunneling Protocol (PPTP) [RFC2637], or Multiprotocol Label Switching (MPLS) [RFC3031] [RFC3032]. In these cases, link information could be determined by cross-layer information exchange, but this requires interfaces capable of processing link layer technology specific information. An alternative could be online measurements, but this can cause significant additional network overhead. It is an open research question as to how much, if any, online traffic measurement would be acceptable (at run-time). Encapsulation and decapsulation of explicit congestion information have been specified for IP-in-IP tunnelling [RFC6040] and for MPLS-in-MPLS or MPLS-in-IP [RFC5129].
IPインIPトンネル[RFC2003]、IPsecトンネル[RFC4301]を使用する際の困難も生じ、IPレイヤ2トンネリングプロトコル（L2TP）[RFC2661]、総称ルーティングカプセル化（GRE）[RFC1701]、[RFC2784]にカプセル化され、ポイントツーポイントトンネリングプロトコル（PPTP）[RFC2637]、またはマルチプロトコルラベルスイッチング（MPLS）[RFC3031] [RFC3032]。これらのケースでは、リンク情報は、クロスレイヤ情報交換により決定することができるが、これはリンク層技術固有の情報を処理することが可能なインターフェースを必要とします。代替は、オンライン測定することができ、これは重要な追加のネットワークのオーバーヘッドが発生する可能性があります。これは、もしあれば、どのくらい、オンライントラフィック測定は、（実行時に）許容可能であるとのようなオープンな研究の質問です。明示的輻輳情報のカプセル化及びデカプセル化は、IPインIPトンネル[RFC6040]およびインMPLS MPLS-またはMPLSインIP [RFC5129]に指定されています。
Accurate online measurement of data rates is challenging when traffic is bursty. For instance, measuring a "current link load" requires defining the right measurement interval / sampling interval. This is a challenge for proposals that require knowledge, e.g., about the current link utilization.
トラフィックがバースト性である場合に、データ・レートの正確なオンライン測定が困難です。例えば、「現在のリンク負荷」を測定すると、右側の測定間隔/サンプリング間隔を定義する必要があります。これは、現在のリンクの利用率についての知識を必要と提案、例えば、のための課題です。
Some proposals use buffer statistics such as a virtual queue length to trigger feedback. However, network components can include multiple distributed buffer stages that make it difficult to obtain such metrics.
いくつかの提案は、フィードバックをトリガするために、このような仮想キュー長としてバッファの統計情報を使用しています。しかし、ネットワーク構成要素は、それが難しいような指標を得ることを可能にする複数の分散バッファ段を含むことができます。
Open questions are:
オープンな質問は以下のとおりです。
- Can and should this information be made available, e.g., by additional interfaces or protocols?
- この情報は、追加のインターフェースまたはプロトコルによって、例えば、利用可能にすべきであることはできますか？
- Which information is so important to higher-layer controllers that machine architecture research should focus on designing to provide it?
- どのような情報は、マシンアーキテクチャの研究がそれを提供するために、設計に焦点を当てるべき上位層コントローラにとても重要なのですか？
Explicit notification mechanisms can be realized either by in-band signaling (notifications piggybacked along with the data traffic) or by out-of-band signaling [Sarola07]. The latter case requires additional protocols and a secure binding between the signals and the packets they refer to. Out-of-band signaling can be further subdivided into path-coupled and path-decoupled approaches.
明示的な通知メカニズムは、[Sarola07】シグナリング（通知は、データトラフィックと一緒にピギーバック）またはアウトオブバンドシグナリング帯域内のいずれかで実現することができます。後者の場合は、追加のプロトコルおよび信号及び彼らが参照パケットとの間の安全な結合を必要とします。アウトオブバンドシグナリングは、さらにパス結合およびパス切り離さアプローチに細分することができます。
Open questions concerning feedback signaling include:
フィードバックシグナリングに関するオープンな質問は次のとおりです。
- At which protocol layer should the feedback signaling occur (IP/network layer assisted, transport layer assisted, hybrid solutions, shim layer, intermediate sub-layer, etc.)? Should the feedback signaling be path-coupled or path-decoupled?
- どのプロトコル層でフィードバックシグナリングが（支援IP /ネットワーク層、トランスポート層支援、ハイブリッドソリューション、シム層、中間副層など）を発生する必要がありますか？フィードバックシグナリングはパス結合またはパス・デカップリングする必要がありますか？
- What is the optimal frequency of feedback (only in case of congestion events, per RTT, per packet, etc.)?
- フィードバックの最適な周波数は（のみ輻輳イベントの場合は、RTTごとに、パケットあたり、など）とは何ですか？
- What direction should feedback take (from network resource via receiver to sender, or directly back to sender)?
- どのような方向フィードバックが（直接送信者に送信者に受信機を介してネットワークリソースから、または）を取る必要がありますか？
It is common for congestion control mechanisms to interpret packet loss as a sign of congestion. This is appropriate when packets are dropped in routers because of a queue that overflows, but there are other possible reasons for packet drops. In particular, in wireless networks, packets can be dropped because of corruption loss, rendering the typical reaction of a congestion control mechanism inappropriate. As a result, non-congestive loss may be more prevalent in these networks due to corruption loss (when the wireless link cannot be conditioned to properly control its error rate or due to transient wireless link interruption in areas of poor coverage).
輻輳制御機構が輻輳の兆候として、パケットロスを解釈するのが一般的です。パケットが原因でオーバーフローするキューのルータでドロップされたとき、これは適切であるが、パケットドロップのための他の理由が考えられます。具体的には、無線ネットワークにおいて、パケットが不適切な輻輳制御機構の典型的な反応をレンダリングする、なぜなら破損損失をドロップすることができます。結果として、非うっ血性損失は、破損損失（無線リンクが適切にエラー率を制御するために、馴化もしくは乏しいカバレッジのエリアで一過無線リンクを中断することができない場合）に、これらのネットワークにおいてより一般的であってもよいです。
TCP over wireless and satellite is a topic that has been investigated for a long time [Krishnan04]. There are some proposals where the congestion control mechanism would react as if a packet had not been dropped in the presence of corruption (cf. TCP HACK [Balan01]), but
無線や衛星経由TCPは、長い時間[Krishnan04]のために研究されているトピックです。パケットは汚職の存在下では削除されていなかったかのように輻輳制御機構が反応するいくつかの提案があります（参照：TCP HACK [Balan01]）が、
discussions in the IETF have shown (see, for instance, the discussion that occurred in April 2003 on the Datagram Congestion Control Protocol (DCCP) working group list http://www.ietf.org/mail-archive/web/dccp/current/mail6.html) that there is no agreement that this type of reaction is appropriate. For instance, it has been said that congestion can manifest itself as corruption on shared wireless links, and it is questionable whether a source that sends packets that are continuously impaired by link noise should keep sending at a high rate because it has lost the integrity of the feedback loop.
IETFでの議論は、（例えば、http://www.ietf.org/mail-archive/web/dccp/currentデータグラム輻輳制御プロトコル（DCCP）ワーキンググループリストの上に2003年4月に発生した説明を参照してください示しています/mail6.html）このタイプの反応が適切であるという合意がないこと。例えば、輻輳が共有無線リンク上の腐敗として現れることができ、そしての完全性を失ったため、連続的リンクノイズによって損なわれたパケットを送信元が高レートで送信し続けるべきかどうかは疑問であると言われていますフィードバックループ。
Generally, two questions must be addressed when designing a congestion control mechanism that takes corruption loss into account:
アカウントに破損損失を取る輻輳制御機構を設計する場合、一般的に、二つの質問に対処する必要があります。
In addition to question 1 above, it may be useful to consider detecting the reason for corruption, but this has not yet been done to the best of our knowledge.
上記1の質問に加えて、腐敗の原因を検出考慮することが有用であるが、これはまだ我々の知る限りに行われていません。
Corruption detection can be done using an in-band or out-of-band signaling mechanism, much in the same way as described for Challenge 1. Additionally, implicit detection can be considered: link layers sometimes retransmit erroneous frames, which can cause the end-to-end delay to increase -- but, from the perspective of a sender at the transport layer, there are many other possible reasons for such an effect.
破損検出を使用して行うことができ、インバンドまたはアウトオブバンド暗黙の検出を考えることができ、さらに、チャレンジ1について記載したのと同じ方法で、多くの機構を、シグナル：終了を引き起こすことができ、リンク層が時々誤ったフレームを再送しかし、トランスポート層における送信者の観点から、そのような効果のための多くの他の可能な理由がある - 増加する-to-エンド遅延。
Header checksums provide another implicit detection possibility: if a checksum only covers all the necessary header fields and this checksum does not show an error, it is possible for errors to be found in the payload using a second checksum. Such error detection is possible with UDP-Lite and DCCP; it was found to work well over a General Packet Radio Service (GPRS) network in a study [Chester04] and poorly over a WiFi network in another study [Rossi06] [Welzl08]. Note that while UDP-Lite and DCCP enable the detection of corruption, the specifications of these protocols do not foresee any specific reaction to it for the time being.
ヘッダチェックサムは、別の暗黙の検出可能性を提供する：チェックサムのみ必要なすべてのヘッダ・フィールドをカバーし、このチェックサムは、エラーが表示されない場合、エラーが第二のチェックサムを使用して、ペイロードに見出すことがすることが可能です。このようなエラー検出は、UDP-LiteのとDCCPで可能です。それは、[Welzl08] [Rossi06]と不十分別の研究ではWiFiネットワーク上で[Chester04]この研究では汎用パケット無線サービス（GPRS）ネットワーク上でうまく動作することがわかりました。 UDP-LiteのとDCCPは、汚職の検出を可能にしながら、これらのプロトコルの仕様は、当分の間、それまでの任意の特定の反応を予測していないことに注意してください。
The idea of having a transport endpoint detecting and accordingly reacting (or not) to corruption poses a number of interesting questions regarding cross-layer interactions. As IP is designed to operate over arbitrary link layers, it is therefore difficult to design a congestion control mechanism on top of it that appropriately reacts to corruption -- especially as the specific data link layers that are in use along an end-to-end path are typically unknown to entities at the transport layer.
腐敗を検出し、それに応じて反応する（またはしない）トランスポートエンドポイントを有するのアイデアは、クロスレイヤ相互作用について興味深い問題の数を提起します。特に、エンド・ツー・エンドに沿って使用されている特定のデータリンク層として - IPは、任意のリンク層上で動作するように設計されているように、適切に破壊に反応するその上に輻輳制御機構を設計することは困難ですパスは通常、トランスポート層でのエンティティに不明です。
While the IETF has not yet specified how a congestion control mechanism should react to corruption, proposals exist in the literature, e.g., [Tickoo05]. For instance, TCP Westwood [Mascolo01] sets the congestion window equal to the measured bandwidth at the time of congestion in response to three DupACKs or a timeout. This measurement is obtained by counting and filtering the ACK rate. This setting provides a significant goodput improvement in noisy channels because the "blind" by half window reduction of standard TCP is avoided, i.e., the window is not reduced by too much.
IETFはまだ輻輳制御機構が破損に反応する方法を指定していないが、提案が[Tickoo05]、例えば、文献中に存在します。例えば、TCPウエストウッドは、[Mascolo01] 3 DupACKsまたはタイムアウトに応答して、混雑時に測定帯域幅に等しい輻輳ウィンドウを設定します。この測定は、計数及びACKレートをフィルタリングすることによって得られます。この設定は、すなわち、ウィンドウはあまり減少していない標準のTCPの半分の窓還元による「ブラインド」は回避されるため、ノイズの多いチャンネル、の大幅なグッドプットの向上を提供します。
Open questions concerning corruption loss include:
汚職損失に関するオープンな質問は次のとおりです。
- How should corruption loss be detected?
- どのように破損の損失が検出されなければなりませんか？
- How should a source react when it is known that corruption has occurred?
- どのようにソースは、破損が発生していることが知られているときに反応すべきか？
- Can an ECN-capable flow infer that loss must be due to corruption just from lack of explicit congestion notifications around a loss episode [Tickoo05]? Or could this inference be dangerous, given the transport does not know whether all queues on the path are ECN-capable or not?
- ECN対応の流れは、単に損失エピソード[Tickoo05]周りの明示的輻輳通知の不足から起因する破損にその損失がなければなりません推測することはできますか？それとも、この推論は、トランスポートは、パス上のすべてのキューがECN対応であるかどうかわからない与え、危険なことだろうか？
TCP does not take packet size into account when responding to losses or ECN. Over past years, the performance of TCP congestion avoidance algorithms has been extensively studied. The well-known "square root formula" provides an estimation of the performance of the TCP congestion avoidance algorithm for TCP Reno [RFC2581]. [Padhye98] enhances the model to account for timeouts, receiver window, and delayed ACKs.
損失またはECNに応答するときにTCPを考慮にパケットサイズを取ることはありません。過去数年にわたり、TCP輻輳回避アルゴリズムの性能は、広く研究されてきました。周知の「平方根式は」TCPリノ[RFC2581]のTCP輻輳回避アルゴリズムの性能の推定を提供します。 【Padhye98】タイムアウト、受信ウィンドウ、及び遅延ACKを考慮するためにモデルを強化します。
For the sake of the present discussion, we will assume that the TCP throughput is expressed using the simplified formula. Using this formula, the TCP throughput B is proportional to the segment size and inversely proportional to the RTT and the square root of the drop probability:
本議論のために、我々は、TCPスループットが簡略化された式を用いて表現されると仮定する。この式を用いて、TCPスループットBは、セグメントサイズに比例し、RTTと廃棄確率の平方根に反比例します。
S 1
B ~ C --- -------
RTT sqrt(p)
where
どこ
C is a constant
S is the TCP segment size (in bytes)
RTT is the end-to-end round-trip time of the TCP
connection (in seconds)
p is the packet drop probability
Neglecting the fact that the TCP rate linearly depends on it, choosing the ideal packet size is a tradeoff between high throughput (the larger a packet, the smaller the relative header overhead) and low packet latency (the smaller a packet, the shorter the time that is needed until it is filled with data). Observing that TCP is not optimal for applications with streaming media (since reliable in-order delivery and congestion control can cause arbitrarily long delays), this tradeoff has not usually been considered for TCP applications. Therefore, the influence of the packet size on the sending rate has not typically been seen as a significant issue, given there are still few paths through the Internet that support packets larger than the 1500 bytes common with Ethernet.
TCP速度が直線的に理想的なパケットサイズを選択することに依存するという事実を無視するハイスループット（相対ヘッダオーバヘッドパケット大きい、小さい）と低いパケットレイテンシ（小さいパケット、短い時間の間のトレードオフでありますそれがデータで満たされるまで、その）が必要とされています。 （信頼性の高い順序どおりの配信と輻輳制御が任意に長い遅延が発生する可能性がありますので）TCPは、ストリーミングメディアを使用するアプリケーションに最適でないことを観察し、このトレードオフは、通常のTCPアプリケーションのために考慮されていません。そのため、送信レートのパケットサイズの影響は、一般的に与えられた、重要な問題として見られていないイーサネットと共通の1500バイトを超えるパケットをサポートし、インターネットを介して、いくつかのパスが残っています。
The situation is already different for the Datagram Congestion Control Protocol (DCCP) [RFC4340], which has been designed to enable unreliable but congestion-controlled datagram transmission, avoiding the arbitrary delays associated with TCP. DCCP is intended for applications such as streaming media that can benefit from control over the tradeoffs between delay and reliable in-order delivery.
状況は、既にTCPに関連付けられた任意の遅延を回避し、信頼できないけれども輻輳制御データグラムの送信を可能にするように設計されたデータグラム輻輳制御プロトコル（DCCP）[RFC4340]のために異なっています。 DCCPは、遅延および信頼性における順序配信の間のトレードオフに対する制御から利益を得ることができるようなストリーミングメディアなどのアプリケーションのために意図されています。
DCCP provides for a choice of modular congestion control mechanisms. DCCP uses Congestion Control Identifiers (CCIDs) to specify the congestion control mechanism. Three profiles are currently specified:
DCCPは、モジュール式の輻輳制御機構の選択のために用意されています。 DCCPは輻輳制御機構を指定する輻輳制御識別子（のCCIDs）を使用します。 3つのプロファイルは、現在指定されています。
- DCCP Congestion Control ID 2 (CCID 2) [RFC4341]: TCP-like Congestion Control. CCID 2 sends data using a close approximation of TCP's congestion control as well as incorporating a variant of Selective Acknowledgment (SACK) [RFC2018] [RFC3517]. CCID 2 is suitable for senders that can adapt to the abrupt changes in the congestion window typical of TCP's AIMD congestion control, and particularly useful for senders that would like to take advantage of the available bandwidth in an environment with rapidly changing conditions.
- DCCP輻輳制御ID 2（CCID 2）[RFC4341]：TCPのような輻輳制御。 CCID 2は、[RFC2018]、[RFC3517]をTCPの輻輳制御の近似を用いて、ならびに選択的確認応答（SACK）の変異体を組み込んだデータを送信します。 CCID 2は、TCPのAIMD輻輳制御の典型的な、そして急速に変化する条件と環境で利用可能な帯域幅を利用したい送信者のために特に有用で輻輳ウィンドウの急激な変化に適応できる送信者に適しています。
- DCCP Congestion Control ID 3 (CCID 3) [RFC4342]: TCP-Friendly Rate Control (TFRC) [RFC5348] is a congestion control mechanism designed for unicast flows operating in a best-effort Internet environment. When competing for bandwidth, its window is similar to TCP flows but has a much lower variation of throughput over time than TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance. CCID 3 is appropriate for flows that would prefer to minimize abrupt changes in the sending rate, including streaming media applications with small or moderate receiver buffering before playback.
- DCCP輻輳制御ID 3（CCID 3）[RFC4342]：TCPフレンドリーレート制御（TFRC）[RFC5348]はベストエフォート型のインターネット環境で動作するユニキャストフローのために設計された輻輳制御機構です。帯域幅のために競合すると、そのウィンドウはTCPフローに似ていますが、このような比較的滑らかな送付レートが重要であるストリーミングメディアなどのアプリケーションのためにそれをより適切にする、TCPよりも時間をかけてスループットのはるかに低い変動を持っています。 CCID 3は、再生前に小さなまたは中程度の受信バッファリングストリーミングメディアアプリケーションなどの送信レートの急激な変化を、最小限に抑えることを好むだろうフローに適しています。
- DCCP Congestion Control ID 4 (CCID 4) [RFC5622]: TFRC Small Packets (TFRC-SP) [RFC4828], a variant of the TFRC mechanism, has been designed for applications that exchange small packets. The objective of TFRC-SP is to achieve the same bandwidth in bits per second as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently. CCID 4 has been designed to be used either by applications that use a small fixed segment size, or by applications that change their sending rate by varying the segment size. Because CCID 4 is intended for applications that use a fixed small segment size, or that vary their segment size in response to congestion, the transmit rate derived from the TCP throughput equation is reduced by a factor that accounts for the packet header size, as specified in [RFC4828].
- DCCP輻輳制御ID 4（CCID 4）[RFC5622]：TFRCスモールパケット（TFRC-SP）[RFC4828]、TFRC機構の変形、小さなパケットを交換するアプリケーションのために設計されています。 TFRC-SPの目的は、最大1500バイトのパケットを使用してTCPフローとして毎秒ビットで同じ帯域幅を達成することです。 TFRC-SPは、頻繁に任意の小さなパケットを送信することから、単一の流れを防止するために、データパケット間の10ミリ秒の最小間隔を強制します。 CCID 4は、小さな固定セグメントサイズを使用するアプリケーションによって、またはセグメントのサイズを変化させることによって、それらの送信レートを変更するアプリケーションのいずれかによって使用されるように設計されています。 CCID 4が固定された小セグメントサイズ、又はその輻輳に応答して、それらのセグメントサイズを変えるを使用するアプリケーションのために意図されているため、指定されたように、TCPスループット方程式に由来する送信レートは、パケットヘッダーサイズを考慮に低減されます[RFC4828]インチ
The resulting open questions are:
その結果、オープンな質問は以下のとおりです。
- How does TFRC-SP operate under various network conditions?
- どのようにTFRC-SPは、さまざまなネットワーク条件の下で動作しますか？
- How can congestion control be designed so as to scale with packet size (dependency of congestion algorithm on packet size)?
- パケットサイズ（パケットサイズの混雑アルゴリズムの依存性）をスケールするように輻輳制御はどのように設計することができますか？
Today, many network resources are designed so that packet processing cannot be overloaded even for incoming loads at the maximum bit rate of the line. If packet processing can handle sustained load r [packet per second] and the minimum packet size is h [bit] (i.e., frame, packet, and transport headers with no payload), then a line rate of x [bit per second] will never be able to overload packet processing as long as x =< r*h.
パケット処理は、ラインの最大ビットレートでも、入ってくる負荷のために、オーバーロードすることができないように、今日では、多くのネットワークリソースが設計されています。うパケット処理は、持続負荷R [秒あたりのパケットを】取り扱うことができ、最小パケットサイズは、次いでH [ビット]（すなわち、フレーム、パケット、及び無ペイロードと転送ヘッダ）、xの線速度である[毎秒ビット]場合限り、X = <R * hでのパケット処理をオーバーロードすることはできません。
However, realistic equipment is often designed to only cope with a near-worst-case workload with a few larger packets in the mix, rather than the worst-case scenario of all minimum-size packets. In this case, x = r*(h + e) for some small value of e. Therefore, packet congestion is not impossible for runs of small packets (e.g., TCP
しかし、現実的な機器は、多くの場合だけではなく、すべての最小サイズのパケットの最悪のシナリオよりも、ミックスにいくつかの大きなパケットとほぼ最悪の場合のワークロードに対応できるように設計されています。この場合、X = R×（H + E）Eのいくつかの小さな値について。したがって、パケットの輻輳が小さなパケットの実行のために不可能ではない（例えば、TCP
ACKs or denial-of-service (DoS) attacks with TCP SYNs or small UDP datagrams). But absent such anomalous workloads, equipment vendors at the 2008 ICCRG meeting believed that equipment could still be designed so that any congestion should be due to bit overload and not packet overload.
ACKのか、TCPのSYNまたは小さなUDPデータグラム）でサービス拒否（DoS）攻撃。しかし、2008 ICCRG会で不在な異常なワークロード、機器ベンダーは、任意の輻輳が原因ビット過負荷ではなく、パケットの過負荷にする必要がありますように、その装置がまだ設計することができると信じていました。
This observation raises additional open issues:
この観察は、追加の未解決の問題が発生します。
- Can bit congestion remain prevalent?
- ビットの輻輳が流行した状態のままにできますか？
Being able to assume that congestion is generally due to excess bits and not excess packets is a useful simplifying assumption in the design of congestion control protocols. Can we rely on this assumption for the future? An alternative view is that in-network processing will become commonplace, so that per-packet processing will as likely be the bottleneck as per-bit transmission [Shin08].
その輻輳が一般過剰ビットではなく、過剰なパケットによるものであると仮定することができるということは、輻輳制御プロトコルの設計に有用な単純化仮定です。我々は将来のために、この仮定に頼ることはできますか？代替ビューは、パケット単位の処理としておそらくビット毎の送信[Shin08]としてボトルネックになるように、ネットワーク処理は、一般的になるであろうということです。
Over the last three decades, performance gains have mainly been achieved through increased packet rates and not bigger packets. But if bigger maximum segment sizes do become more prevalent, tiny segments (e.g., ACKs) will not stop being widely used -- leading to a widening range of packet sizes.
過去30年間にわたり、パフォーマンスの向上は、主に増加したパケット料金ではなく、より大きなパケットによって達成されています。大きな最大セグメントサイズがより普及しない場合には、小さなセグメント（例えば、ACKが）が広く使用されて停止しません - パケットサイズの広がり範囲につながります。
The open question is thus whether or not packet processing rates (r) will keep up with growth in transmission rates (x). A superficial look at Moore's Law-type trends would suggest that processing (r) will continue to outstrip growth in transmission (x). But predictions based on actual knowledge of technology futures would be useful. Another open question is whether there are likely to be more small packets in the average packet mix. If the answers to either of these questions predict that packet congestion could become prevalent, congestion control protocols will have to be more complicated.
未解決の問題は、パケット処理率（r）は、伝送速度（X）の成長に追いつくかどうかことです。ムーアの法則型の傾向で表面的な外観は、その処理（r）は、送信（x）の中で成長を上回るし続けることをお勧め。しかし、技術先物の実際の知識に基づいて予測が有用であろう。もう一つの未解決の問題は、平均パケットミックスで、より小さなパケットである可能性が高いがあるかどうかです。これらの質問のいずれかに対する答えは、パケットの輻輳が普及しうることを予測した場合、輻輳制御プロトコルはより複雑にする必要があります。
- Confusable causes of loss
- 損失の混同しやすい原因
There is a considerable body of research on how to distinguish whether packet drops are due to transmission corruption or to congestion. But the full list of confusable causes of loss is longer and includes transmission corruption loss, congestion loss (bit congestion and packet congestion), and policing loss.
パケットドロップが伝送の破損または輻輳によるものであるかどうかを見分ける方法についての研究のかなりのボディがあります。しかし、損失の紛らわしい原因の完全なリストは長く、伝送汚職損失、輻輳損失（ビット渋滞やパケットの輻輳）、およびポリシングの損失が含まれています。
If congestion is due to excess bits, the bit rate should be reduced. If congestion is due to excess packets, the packet rate can be reduced without reducing the bit rate -- by using larger packets. However, if the transport cannot tell which of these causes led to a specific packet drop, its only safe response is to reduce the bit rate. This is why the Internet would be more complicated if packet congestion were prevalent, as reducing the bit rate normally also reduces the packet rate, while reducing the packet rate does not necessarily reduce the bit rate.
輻輳が過剰ビットによるものである場合、ビットレートは低減されるべきです。大きなパケットを使用して、 - 輻輳が過剰パケットによるものである場合、パケットレートは、ビットレートを低下させることなく低減することができます。トランスポートは、特定のパケットドロップにつながったこれらの原因のどの伝えることができない場合は、その唯一の安全な応答は、ビットレートを削減することです。パケット輻輳がパケットレートを低減することが必ずしもビットレートを低下させない一方で、ビットレートは、通常、また、パケットレートを還元する還元として、流行した場合、インターネットがより複雑になる理由です。
Given distinguishing between corruption loss and congestion is already an open issue (Section 3.2), if that problem is ever solved, a further open issue would be whether to standardize a solution that distinguishes all the above causes of loss, and not just two of them.
その問題がこれまでに解決された場合に破損の損失や輻輳を区別することは既に開いている問題（3.2節）で与えられ、さらに未解決の問題は、損失のすべての上記の原因を区別するソリューションを標準化するかどうかだろう、とだけでなく、2それらの。
Nonetheless, even if we find a way for network equipment to explicitly distinguish which sort of loss has occurred, we will never be able to assume that such a smart AQM solution is deployed at every congestible resource throughout the Internet -- at every higher-layer device like firewalls, proxies, and servers; and at every lower-layer device like low-end hubs, DSLAMs, Wireless LAN (WLAN) cards, cellular base-stations, and so on. Thus, transport protocols will always have to cope with packet drops due to unpredictable causes, so we should always treat AQM as an optimization, given it will never be ubiquitous throughout the public Internet.
それにもかかわらず、我々はネットワーク機器が明示的に発生した損失のどの種の区別するための方法を見つけた場合でも、当社は、このようなスマートAQMソリューションは、インターネットを通じて、すべてのcongestibleリソースで展開されていることを前提とすることはできません - すべての上位層でファイアウォール、プロキシ、およびサーバなどのデバイス。そしてようにローエンドのハブのDSLAM、無線LAN（WLAN）カード、携帯電話の基地局などあらゆる下位層デバイスで。このように、トランスポートプロトコルは、常にパケットに対処する必要がありますによる予測できない原因に低下するので、我々は常にそれが公共のインターネットを通じてユビキタスになることはありません与えられ、最適化としてAQMを扱う必要があります。
- What does a congestion notification on a packet of a certain size mean?
- 特定のサイズのパケットの輻輳通知は何を意味するのでしょうか？
The open issue here is whether a loss or explicit congestion mark should be interpreted as a single congestion event irrespective of the size of the packet lost or marked, or whether the strength of the congestion notification is weighted by the size of the packet. This issue is discussed at length in [Bri10], along with other aspects of packet size and congestion control.
ここでの未解決の問題は、損失または明示的輻輳マークが失われたり、マーク、またはかどうか輻輳通知の強度は、パケットのサイズによって重み付けされるパケットのサイズにかかわらず、単一の輻輳イベントとして解釈されるべきであるかどうかです。この問題は、パケットサイズ及び輻輳制御の他の態様とともに、[Bri10]の長さで議論されています。
[Bri10] makes the strong recommendation that network equipment should drop or mark packets with a probability independent of each specific packet's size, while congestion controls should respond to dropped or marked packets in proportion to the packet's size.
[Bri10]輻輳制御は、パケットのサイズに比例して低下したか、マークされたパケットに応答すべきながら、ネットワーク機器は、各特定のパケットのサイズの確率独立してパケットをドロップまたはマークする必要があることを強く推奨します。
- Packet size and congestion control protocol design
- パケットサイズと輻輳制御プロトコルの設計
If the above recommendation is correct -- that the packet size of a congestion notification should be taken into account when the transport reads, and not when the network writes, the notification -- it opens up a significant problem of protocol engineering and re-engineering. Indeed, TCP does not take packet size into account when responding to losses or ECN. At present, this is not a pressing problem because use of 1500 byte data segments is very prevalent for TCP, and the incidence of alternative maximum segment sizes is not large. However, we should design the Internet's protocols so they will scale with packet size. So, an open issue is whether we should evolve TCP to be sensitive to packet size, or expect new protocols to take over.
上記の勧告は正しい場合 - トランスポートは読み込み時に輻輳通知のパケットサイズが考慮されるべきである、とのネットワークは、通知を書き込んないときということ - それは、プロトコル工学、リエンジニアリングの重大な問題を切り開きます。損失またはECNに応答するときに実際に、TCPは、アカウントにパケットサイズを取ることはありません。 1500個のバイトのデータセグメントの使用は、TCPのために非常に普及しており、別の最大セグメントサイズの発生率が大きくないので、現在のところ、これが押圧問題ではありません。彼らは、パケットのサイズに合わせて拡張されますので、しかし、我々はインターネットのプロトコルを設計する必要があります。だから、未解決の問題は、我々は、パケットサイズに敏感であることがTCPを進化させ、または引き継ぐために新しいプロトコルを期待すべきかどうかです。
As we continue to standardize new congestion control protocols, we must then face the issue of how they should account for packet size. It is still an open research issue to establish whether TCP was correct in not taking packet size into account. If it is determined that TCP was wrong in this respect, we should discourage future protocol designs from following TCP's example. For example, as explained above, the small-packet variant of TCP-friendly rate control (TFRC-SP [RFC4828]) is an experimental protocol that aims to take packet size into account. Whatever packet size it uses, it ensures that its rate approximately equals that of a TCP using 1500 byte segments. This raises the further question of whether TCP with 1500 byte segments will be a suitable long-term gold standard, or whether we need a more thorough review of what it means for a congestion control mechanism to scale with packet size.
私たちは、新たな輻輳制御プロトコルを標準化し続けているため、我々は、彼らがパケットサイズを考慮する必要があるかの問題に直面しなければなりません。 TCPは、アカウントにパケットサイズを取っていない中で正しかったかどうかを確立するために、まだ開い研究課題です。それはTCPは、この点で間違っていたと判断された場合、我々は、TCPの例を次の中から将来のプロトコルの設計を阻止すべきです。上述したように、例えば、TCPフレンドリーレート制御（TFRC-SP [RFC4828]）の小パケットの変異体は、アカウントにパケットサイズを取ることを目的と実験プロトコールです。それが使用するどのようなパケットサイズ、それはその割合が約1500個のバイトのセグメントを使用してTCPのそれに等しいことを保証します。これは、1500個のバイトのセグメントを持つTCPは、適切な長期的なゴールドスタンダードになるかどうかのさらなる問題を提起、または私達はそれがパケットサイズを拡張する輻輳制御機構のために何を意味するのか、より徹底的な見直しが必要かどうか。
The beginning of data transmissions imposes some further, unique challenges: when a connection to a new destination is established, the end-systems have hardly any information about the characteristics of the path in between and the available bandwidth. In this flow startup situation, there is no obvious choice as to how to start to send. A similar problem also occurs after relatively long idle times, since the congestion control state then no longer reflects current information about the state of the network (flow restart problem).
データ伝送の始まりは、さらにいくつかの、ユニークな挑戦を課し：新しい宛先への接続が確立されると、エンドシステムは、間にパスおよび利用可能な帯域幅の特性についてほとんど情報を持っています。このフローの起動状況では、送信を開始する方法についての明白な選択肢はありません。輻輳制御状態がもはやネットワーク（フロー再開問題）の状態に関する現在の情報を反映しているので、同様の問題は、比較的長いアイドル時間後に発生しません。
Van Jacobson [Jacobson88] suggested using the slow-start mechanism both for the flow startup and the flow restart, and this is today's standard solution [RFC2581] [RFC5681]. Per [RFC5681], the slow-start algorithm is used when the congestion window (cwnd) < slow-start threshold (ssthresh), whose initial value is set arbitrarily high (e.g., to the size of the largest possible advertised window) and reduced in response to congestion. During slow-start, TCP increments the cwnd by at most Sender Maximum Segment Size (MSS) bytes for each ACK received that cumulatively acknowledges new data. Slow-start ends when cwnd exceeds ssthresh or when congestion is observed. However, the slow-start is not optimal in many situations. First, it can take quite a long time until a sender can fully utilize the available bandwidth on a path. Second, the exponential increase may be too aggressive and cause multiple packet loss if large congestion windows are reached (slow-start overshooting). Finally, the slow-start does not ensure that new flows converge quickly to a reasonable share of resources, particularly when the new flows compete with long-lived flows and come out of slow-start early (slow-start vs overshoot tradeoff). This convergence problem may even worsen if more aggressive congestion control variants are widely used.
ヴァンヤコブソンは、[Jacobson88]の両方の流れの起動と流れの再起動のためのスロースタートメカニズムを使用して提案し、これは今日の標準溶液[RFC2581] [RFC5681]です。 [RFC5681]、スロースタートアルゴリズムが使用されている初期値を任意に高く設定されている輻輳ウィンドウ（CWND）<スロースタート閾値（SSTHRESH）、（例えば、最大の可能な広告ウィンドウのサイズ）および還元混雑に応じてインチスロースタートの間、TCPは、各ACKが累積的に新しいデータを認めることを受けたため、ほとんどの送信者の最大セグメントサイズ（MSS）のことでcwndをバイトをインクリメントします。 CWNDがSSTHRESHを超えた場合又は輻輳が観察されたときにスロースタートを終了します。しかし、スロースタートは、多くの状況では最適ではありません。送信者が完全パスで利用可能な帯域幅を利用できるようになるまで第一に、それは非常に長い時間がかかることがあります。第二に、指数関数的な増加は、あまりにも積極的かつ大混雑窓が（オーバーシュートスロースタート）に達している場合は、複数のパケットロスが発生することがあります。最後に、スロースタートは、新しいフローが長命の流れと競合し、早期のスロースタート（オーバーシュートのトレードオフ対スロースタート）から出てくる場合は特に、新しいフローは、資源の合理的なシェアを急速に収束していることを確認していません。より積極的な輻輳制御変異体が広く使用されている場合は、この収束問題はさらに悪化することがあります。
The slow-start and its interaction with the congestion avoidance phase was largely designed by intuition [Jacobson88]. So far, little theory has been developed to understand the flow startup problem and its implication on congestion control stability and fairness. There is also no established methodology to evaluate whether new flow startup mechanisms are appropriate or not.
スロースタートと輻輳回避フェーズとの相互作用は、主に[Jacobson88】直感的に設計しました。これまでのところ、少し理論は、フロー起動時の問題と輻輳制御の安定性と公平性にその意味を理解するために開発されました。新しいフローの起動メカニズムが適切であるかどうかを評価するための確立された方法論もありません。
As a consequence, it is a non-trivial task to address the shortcomings of the slow-start algorithm. Several experimental enhancements have been proposed, such as congestion window validation [RFC2861] and limited slow-start [RFC3742]. There are also ongoing research activities, focusing, e.g., on bandwidth estimation techniques, delay-based congestion control, or rate-pacing mechanisms. However, any alternative end-to-end flow startup approach has to cope with the inherent problem that there is no or only little information about the path at the beginning of a data transfer. This uncertainty could be reduced by more expressive feedback signaling (cf. Section 3.1). For instance, a source could learn the path characteristics faster with the Quick-Start mechanism [RFC4782]. But even if the source knew exactly what rate it should aim for, it would still not necessarily be safe to jump straight to that rate. The end-system still does not know how a change in its own rate will affect the path, which also might become congested in less than one RTT. Further research would be useful to understand the effect of decreasing the uncertainty by explicit feedback separately from control theoretic stability questions. Furthermore, flow startup also raises fairness questions. For instance, it is unclear whether it could be reasonable to use a faster startup when an end-system detects that a path is currently not congested.
その結果、スロースタートアルゴリズムの欠点に対処するための非自明な課題です。いくつかの実験的な拡張は、輻輳ウィンドウの検証[RFC2861]及びスロースタート限定[RFC3742]として、提案されています。現在進行中の研究活動は、帯域幅推定技術、遅延ベースの輻輳制御、またはレートペーシングメカニズムに、例えば、焦点を当て、もあります。しかし、任意の代替エンド・ツー・エンドのフローの起動方法は、データ転送の開始時にパスについてのまたはわずかしか情報がないという固有の問題に対処する必要があります。この不確実性は、より表現力のフィードバックシグナリング（節参照3.1）によって減少させることができます。例えば、ソースは、クイック・スタート・メカニズム[RFC4782]で速いパス特性を学ぶことができました。しかし、ソースは、それがために目指すべきまさに率を知っていたとしても、まだ、必ずしもそのレートに直接ジャンプすることは安全ではありません。エンドシステムはまだ、独自率の変化はまた、以下の1 RTTで混雑になる可能性があるパスを、どのように影響するかを知りません。さらなる研究は、制御理論的安定性の問題とは別に明示的なフィードバックにより、不確実性を減少させる効果を理解することは有用であろう。さらに、フローの起動も、公平性の問題を提起します。例えば、エンド・システムはパスが現在混雑していないことを検出した場合、より高速な起動を使用するのが妥当かもしれないかどうかは不明です。
In summary, there are several topics for further research concerning flow startup:
要約すると、流れの起動に関するさらなる研究のためのいくつかのトピックがあります。
- Better theoretical understanding of the design and evaluation of flow startup mechanisms, concerning their impact on congestion risk, stability, and fairness.
- 輻輳危険性、安定性、および公正性への影響について、フロー・スタートアップ・メカニズムの設計と評価、のより良い理論的な理解。
- Evaluating whether it may be appropriate to allow alternative starting schemes, e.g., to allow higher initial rates under certain constraints [Chu10]; this also requires refining the definition of fairness for startup situations.
- 特定の制約[Chu10】下で高い初期速度を可能にするために、例えば、代替出発スキームを可能にするのに適切であるかもしれないかどうかを評価します。これはまた、起動時の状況のため、公平性の定義を精緻化が必要です。
- Better theoretical models for the effects of decreasing uncertainty by additional network feedback, particularly if the path characteristics are very dynamic.
- 追加のネットワーク・フィードバックによって不確実性を減少させる効果のためのより良い理論的なモデルは、パス特性が非常に動的である場合は特に。
Transport protocols such as TCP operate over the Internet, which is divided into autonomous systems. These systems are characterized by their heterogeneity as IP networks are realized by a multitude of technologies.
TCPのようなトランスポートプロトコルは、自律システムに分割して、インターネット上で動作します。 IPネットワークは技術の多数により実現されるように、これらのシステムは、その異質性によって特徴付けられます。
Different conditions and their variations lead to correlation effects between policers that regulate traffic against certain conformance criteria.
さまざまな条件およびそのバリエーションは、特定の適合基準に対してトラフィックを規制ポリサー間の相関効果につながります。
With the advent of techniques allowing for early detection of congestion, packet loss is no longer the sole metric of congestion. ECN (Explicit Congestion Notification) marks packets -- set by active queue management techniques -- to convey congestion information, trying to prevent packet losses (packet loss and the number of packets marked gives an indication of the level of congestion). Using TCP ACKs to feed back that information allows the hosts to realign their transmission rate and thus encourages them to efficiently use the network. In IP, ECN uses the two least significant bits of the (former) IPv4 Type of Service (TOS) octet or the (former) IPv6 Traffic Class octet [RFC2474] [RFC3260]. Further, ECN in TCP uses two bits in the TCP header that were previously defined as reserved [RFC793].
輻輳の早期発見を可能に技術の出現により、パケット損失がもはや混雑の唯一のメトリックではありません。パケット損失を（パケットロスやパケット数が混雑のレベルの指示を与えるマーク）を防止しようとすると、渋滞情報を伝えるために - アクティブキュー管理技術によって設定された - ECN（明示的輻輳通知）は、パケットをマークします。その情報をフィードバックするためにTCP ACKを使用すると、ホストが自分の伝送速度を再調整することができますので、効率的にネットワークを使用するように奨励しています。 IPにおいて、ECNは、サービスの（旧）のIPv4タイプ（TOS）オクテットまたは（前者）IPv6のトラフィッククラスオクテット[RFC2474]、[RFC3260]の2つの最下位ビットを使用します。さらに、TCPにおけるECNは、以前に予約[RFC793]として定義されたTCPヘッダーの2ビットを使用します。
ECN [RFC3168] is an example of a congestion feedback mechanism from the network toward hosts. The congestion-based feedback scheme, however, has limitations when applied on an inter-domain basis. Indeed, Sections 8 and 19 of [RFC3168] detail the implications of two possible attacks:
ECN [RFC3168]はホストに向けて、ネットワークから輻輳フィードバック機構の一例です。ドメイン間ベースで適用されたときに渋滞に基づくフィードバック方式は、しかし、制限があります。実際、セクション8と[RFC3168]細部の19二つの可能な攻撃の影響：
1. non-compliance: a network erasing a Congestion Experienced (CE) codepoint introduced earlier on the path, and
1.非準拠：経験輻輳を消去ネットワーク（CE）コードポイントは、以前の経路に導入し、そして
2. subversion: a network changing Not ECN-Capable Transport (Not-ECT) to ECT.
2.転覆：ネットワークがECTにECNに対応していないトランスポート（未-ECT）を変更します。
Both of these problems could allow an attacking network to cause excess congestion in an upstream network, even if the transports were behaving correctly. There are to date two possible solutions to the non-compliance problem (number 1 above): the ECN-nonce [RFC3540] and the [CONEX] work item inspired by the re-ECN incentive system
これらの問題の両方がトランスポートが正しく動作したとしても、攻撃のネットワークは、上流ネットワークに過剰混雑を引き起こす可能性があります。 ECN-ナンス[RFC3540]及び再ECNインセンティブシステムに触発[コーネックス】作業項目：非準拠の問題に対する2つの可能な解決策を（上記数1）日付することがあります
[Bri09]. Nevertheless, accidental rather than malicious erasure of ECN is an issue for IPv6 where the absence of an IPv6 header checksum implies that corruption of ECN could be more impacting than in the IPv4 case.
【Bri09]。それにもかかわらず、ECNの偶発的ではなく、悪意のある消去は、IPv6ヘッダチェックサムが存在しないことがECNの破損は、IPv4の場合よりも衝撃であり得ることを意味するIPv6の問題があります。
Fragmentation is another issue: the ECN-nonce cannot protect against misbehaving receivers that conceal marked fragments; thus, some protection is lost in situations where path MTU discovery is disabled. Note also that ECN-nonce wouldn't protect against the subversion issue (number 2 above) because, by definition, a Not-ECT packet comes from a source without ECN enabled, and therefore without the ECN-nonce enabled. So, there is still room for improvement on the ECN mechanism when operating in multi-domain networks.
断片化は別の問題である：ECN-nonceがマークされた断片を隠す誤動作受信機から保護することはできません。このように、ある程度の保護は、パスMTUディスカバリが無効になっている状況で失われています。定義により、未-ECTパケットがECNを有効にせずに、そしてECN-nonceが有効ゆえせずにソースから来て、そのためECN-nonceはsubversionの問題（上記数2）からの保護ではないでしょうにも注意してください。だから、まだマルチドメイン・ネットワークで動作ECNメカニズムに改善の余地があります。
Operational/deployment experience is nevertheless required to determine the extent of these problems. The second problem is mainly related to deployment and usage practices and does not seem to result in any specific research challenge.
運用/展開の経験にもかかわらず、これらの問題の程度を決定するために必要とされます。第二の問題は、展開と使用慣行に主に関連しており、任意の特定の研究課題が生じていないようです。
Another controversial solution in a multi-domain environment may be the TCP rate controller (TRC), a traffic conditioner that regulates the TCP flow at the ingress node in each domain by controlling packet drops and delays of the packets in a flow. The outgoing traffic from a TRC-controlled domain is shaped in such a way that no packets are dropped at the policer. However, the TRC interferes with the end-to-end TCP model, and thus it would interfere with past and future diversity of TCP implementations (violating the end-to-end principle). In particular, the TRC embeds the flow rate equality view of fairness in the network, and would prevent evolution to forms of fairness based on congestion-volume (Section 2.3).
マルチドメイン環境内の別の論争の解決策は、TCPレート制御（TRC）、フロー内のパケットのパケットドロップや遅延を制御することにより、各ドメインの入口ノードにおけるTCPの流れを調節するトラフィックコンディショナであってもよいです。 TRC制御ドメインからの発信トラフィックはパケットがポリサーでドロップされないような方法で成形されます。しかし、TRCは、エンドツーエンドのTCPのモデルと干渉し、したがって、それは（エンド・ツー・エンドの原則に違反する）TCP実装の過去と未来の多様性を妨害するであろう。具体的には、TRCは、ネットワーク内の公平性の流量等価ビューを埋め込み、輻輳ボリューム（セクション2.3）に基づく公平性の形態に進化を妨げます。
Security is a challenge for multi-domain exchange of explicit rate signals, whether in-band or out-of-band. At domain boundaries, authentication and authorization issues can arise whenever congestion control information is exchanged. From this perspective, the Internet does not so far have any security architecture for this problem.
セキュリティは、インバンドまたはアウトオブバンドかどうか、明示レート信号のマルチドメイン交換のための挑戦です。輻輳制御情報を交換するたびにドメインの境界では、認証と承認の問題が発生することができます。このような観点から、インターネットがこれまでにこの問題の任意のセキュリティアーキテクチャを持っていません。
The future evolution of Internet inter-domain operation has to show whether more multi-domain information exchange can be effectively realized. This is of particular importance for congestion control schemes that make use of explicit per-datagram rate feedback (e.g., RCP or XCP) or explicit rate feedback that uses in-band congestion signaling (e.g., Quick-Start) or out-of-band signaling (e.g., CADPC/PTP). Explicit signaling exchanges at the inter-domain level that result in local domain triggers are currently absent from the
インターネットドメイン間の操作の将来の進化は、より多くのマルチドメインの情報交換を効果的に実現することができるかどうかを示すことがあります。これは、帯域内の輻輳シグナリング（例えば、クイックスタート）を使用して明示的な単位のデータグラムレートフィードバック（例えば、RCPまたはXCP）または明示的なレートフィードバックを利用する輻輳制御方式のために特に重要であるか、アウトオブバンドシグナル（例えば、CADPC / PTP）。ローカル・ドメイン・トリガをもたらすドメイン間のレベルで明示的なシグナリング交換は、から現在存在しません
Internet. From this perspective, security issues resulting from limited trust between different administrative units result in policy enforcement that exacerbates the difficulty encountered when explicit feedback congestion control information is exchanged between domains. Note that even though authentication mechanisms could be extended for this purpose (by recognizing that explicit rate schemes such as RCP or XCP have the same inter-domain security requirements and structure as IntServ), they suffer from the same scalability problems as identified in [RFC2208]. Indeed, in-band rate signaling or out-of-band per-flow traffic specification signaling (like in the Resource Reservation Protocol (RSVP)) results in similar scalability issues (see Section 3.1).
インターネット。このような観点から、異なる行政単位間の限られた信頼関係から生じるセキュリティ上の問題は、明示的なフィードバック輻輳制御情報は、ドメイン間で交換されたときに遭遇する困難を悪化させるポリシーの施行につながります。 [RFC2208で識別される認証機構は、（例えばRCPまたはXCPとして明示レート制度がイントサーブと同じドメイン間のセキュリティ要件と構造を持っていることを認識することによって）、この目的のために拡張することができていても、それらが同じスケーラビリティの問題を抱えていることに注意してください]。実際、インバンドレートシグナリングまたは（3.1節を参照）と同様のスケーラビリティの問題における結果（リソース予約プロトコルで（RSVP）のような）シグナリングアウトオブバンドフローごとのトラフィック仕様。
Also, many autonomous systems only exchange some limited amount of information about their internal state (topology hiding principle), even though having more precise information could be highly beneficial for congestion control. Indeed, revealing the internal network structure is highly sensitive in multi-domain network operations and thus also a concern when it comes to the deployability of congestion control schemes. For instance, a network-assisted congestion control scheme with explicit signaling could reveal more information about the internal network dimensioning than TCP does today.
また、多くの自律システムは、より正確な情報を持つことが輻輳制御のために非常に有益であり得るにもかかわらず、彼らの内部状態（トポロジ隠蔽原理）についての情報の一部限られた量を交換します。確かに、内部ネットワーク構造を明らかにすることは、マルチドメインネットワークの運用に非常に敏感であり、したがって、また、それが輻輳制御方式の展開性に懸念が来るとき。例えば、明示的なシグナリングとネットワーク支援型の輻輳制御方式は、TCPが今日よりも、内部ネットワークの寸法に関する詳細な情報を開示する可能性があります。
Extending pseudowires across multiple domains poses specific issues. Pseudowires (PWs) [RFC3985] may carry non-TCP data flows (e.g., Time-Division Multiplexing (TDM) traffic or Constant Bit Rate (CBR) ATM traffic) over a multi-domain IP network. Structure-Agnostic TDM over Packet (SAToP) [RFC4553], Circuit Emulation Service over Packet Switched Network (CESoPSN) [RFC5086], and TDM over IP (TDMoIP) [RFC5087] are not responsive to congestion control as discussed in [RFC2914] (see also [RFC5033]). The same observation applies to ATM circuit emulating services (CESs) interconnecting CBR equipment (e.g., Private Branch Exchanges (PBX)) across a Packet Switched Network (PSN).
複数のドメイン間で疑似回線の拡張は、特定の問題を提起します。疑似回線（PWの）[RFC3985]は、マルチドメイン、IPネットワーク上で非TCPデータフロー（例えば、時分割多重（TDM）トラフィックまたは固定ビットレート（CBR）ATMトラフィック）を運ぶことができます。パケット（のSAToP）上の構造にとらわれないTDM [RFC4553]、パケットオーバー回線エミュレーションサービスは、ネットワーク（のCESoPSN）[RFC5086]をスイッチ、および[RFC2914]で説明したようにIP（のTDMoIP）上TDM [RFC5087]は、輻輳制御に応答しません（参照[RFC5033]）。同じ観察がネットワーク（PSN）交換パケットを横切ってATM回線サービス（CESS）をエミュレートする相互接続CBR機器（例えば、構内交換機（PBX））に適用されます。
Moreover, it is not possible to simply reduce the flow rate of a TDM PW or an ATM PW when facing packet loss. Providers can rate-control corresponding incoming traffic, but they may not be able to detect that PWs carry TDM or CBR ATM traffic (mechanisms for characterizing the traffic's temporal properties may not necessarily be supported).
また、パケット損失に直面したときに、単にTDM PW又はATM PWの流量を減少させることは不可能です。プロバイダは、着信トラフィックを対応する制御を評価することができ、それらはPWSは（トラフィックの一時的な性質を特徴付けるためのメカニズムは必ずしもサポートされなくてもよい）TDMまたはCBR ATMトラフィックを運ぶことを検出することができないかもしれません。
This can be illustrated with the following example.
これは、以下の例で説明することができます。
........... ............
. . .
S1 --- E1 --- . .
. | . .
. === E5 === E7 ---
. | . . |
S2 --- E2 --- . . |
. . . | |
........... . | v
. ----- R --->
........... . | ^
. . . | |
S3 --- E3 --- . . |
. | . . |
. === E6 === E8 ---
. | . .
S4 --- E4 --- . .
. . .
........... ............
\---- P1 ---/ \---------- P2 -----
Sources S1, S2, S3, and S4 are originating TDM over IP traffic. P1 provider edges E1, E2, E3, and E4 are rate-limiting such traffic. The Service Level Agreement (SLA) of provider P1 with transit provider P2 is such that the latter assumes a BE traffic pattern and that the distribution shows the typical properties of common BE traffic (elastic, non-real time, non-interactive).
ソースS1、S2、S3、およびS4は、IPトラフィックの上にTDMを発信するされています。 P1プロバイダはE1、E2、E3、及びE4が律速そのようなトラフィックであるエッジ。トランジットプロバイダP2とプロバイダP1のサービスレベル契約（SLA）後者はBEトラフィックパターンを想定し、分布が共通BEトラフィック（弾性、非リアルタイム、非対話型）の典型的な性質を示しているようなものです。
The problem arises for transit provider P2 because it is not able to detect that IP packets are carrying constant-bit-rate service traffic for which the only useful congestion control mechanism would rely on implicit or explicit admission control, meaning self-blocking or enforced blocking, respectively.
IPパケットは、唯一の有益な輻輳制御機構は、暗黙的または明示的な許可制御に頼ることになるため、一定ビットレートサービスのトラフィックを運ぶ自己ブロッキングを意味またはブロッキング施行されていることを検出することができないため、問題がトランジットプロバイダP2のために生じます、それぞれ。
Assuming P1 providers are rate-limiting BE traffic, a transit P2 provider router R may be subject to serious congestion as all TDM PWs cross the same router. TCP-friendly traffic (e.g., each flow within another PW) would follow TCP's AIMD algorithm of reducing the sending rate by half, in response to each packet drop. Nevertheless, the PWs carrying TDM traffic could take all the available capacity while other more TCP-friendly or generally congestion-responsive traffic reduced itself to nothing. Note here that the situation may simply occur because S4 suddenly turns on additional TDM channels.
すべてのTDM PWSは同じルータを横切るようにP1プロバイダが律速BEトラフィックであると仮定すると、トランジットP2プロバイダルータRは、深刻な混雑を受けることができます。 TCPフレンドリーなトラフィック（例えば、別のPW内の各フロー）各パケットのドロップに対応して、半分に送信レートを低下させるTCPのAIMDアルゴリズムをたどります。他のよりTCPフレンドリーまたは一般的に輻輳応答トラフィックが何に自分自身を低減しながらもかかわらず、TDMトラフィックを運ぶPWSがすべての利用可能な容量を取ることができます。 S4が突然追加のTDMチャネルをオンにするので、状況は単純に発生する可能性があること、ここで注意してください。
It is neither possible nor desirable to assume that edge routers will soon have the ability to detect the responsiveness of the carried traffic, but it is still important for transit providers to be able to police a fair, robust, responsive, and efficient congestion control technique in order to avoid impacting congestion-responsive Internet traffic. However, we must not require only certain specific responses to congestion to be embedded within the network, which would harm evolvability. So designing the corresponding mechanisms in the data and control planes still requires further investigation.
そのエッジルータはすぐに運ばトラフィックの応答性を検出する能力を持つことになりますと仮定することは可能でも望ましくもないですが、トランジットプロバイダーは、公正堅牢、応答、および効率的な輻輳制御技術を警察にできるようにするために、それはまだ重要です輻輳応答のインターネットトラフィックに影響を与えないようにするためです。しかし、我々は発展性を害することとなるネットワーク内に埋め込まれる混雑、にのみ特定の応答を要求してはなりません。そこで、データプレーンとコントロールプレーンに対応するメカニズムを設計することは、まださらなる調査が必要です。
Traffic initiated by so-called elastic applications adapts to the available bandwidth using feedback about the state of the network.
いわゆる弾性アプリケーションによって開始されたトラフィックは、ネットワークの状態についてのフィードバックを使用して利用可能な帯域幅に適応します。
For elastic applications, the transport dynamically adjusts the data traffic sending rate to different network conditions. Examples encompass short-lived elastic traffic including HTTP and instant-messaging traffic, as well as long file transfers with FTP and applications targeted by [LEDBAT]. In brief, elastic data applications can show extremely different requirements and traffic characteristics.
弾性のアプリケーションでは、輸送は、動的に異なるネットワーク条件に率を送信するデータトラフィックを調整します。例としては、HTTPおよびインスタントメッセージングトラフィックだけでなく、FTPや[LEDBAT]によってターゲットアプリケーションと、長いファイル転送などの短命弾性トラフィックを包含する。簡単に言うと、弾性データ・アプリケーションは、非常に異なる要件とトラフィック特性を示すことができます。
The idea to distinguish several classes of best-effort traffic types is rather old, since it would be beneficial to address the relative delay sensitivities of different elastic applications. The notion of traffic precedence was already introduced in [RFC791], and it was broadly defined as "An independent measure of the importance of this datagram". For instance, low-precedence traffic should experience lower average throughput than higher-precedence traffic. Several questions arise here: What is the meaning of "relative"? What is the role of the transport layer?
異なる弾性アプリケーションの相対的な遅延感度に対処することが有益であるので、ベストエフォート型トラフィックタイプのいくつかのクラスを区別するためのアイデアは、かなり古いです。トラフィックの優先順位の概念はすでに[RFC791]で導入された、それは広く、「このデータグラムの重要性とは無関係に測定」と定義しました。例えば、低優先順位のトラフィックは、より高い優先順位のトラフィックよりも低い平均スループットを経験する必要があります。いくつかの質問がここに生じ：「相対的」の意味は何ですか？トランスポート層の役割は何ですか？
The preferential treatment of higher-precedence traffic combined with appropriate congestion control mechanisms is still an open issue that may, depending on the proposed solution, impact both the host and the network precedence awareness, and thereby congestion control. [RFC2990] points out that the interactions between congestion control and DiffServ [RFC2475] remained unaddressed until recently.
適切な輻輳制御機構と組み合わせた高い優先順位のトラフィックの優先処理が提案された解決策、衝撃ホストとネットワークの優先認識、及びそれによって輻輳制御の両方に応じて、まだそのかもしれない未解決の問題です。 [RFC2990]は、輻輳制御とDiffserv [RFC2475]の間の相互作用は、最近まで取り組まれていないままであることを指摘しています。
Recently, a study and a potential solution have been proposed that introduce Guaranteed TFRC (gTFRC) [Lochin06]. gTFRC is an adaptation of TCP-Friendly Rate Control providing throughput guarantees for unicast flows over the DiffServ/Assured Forwarding (AF) class. The purpose of gTFRC is to distinguish the guaranteed part from the best-effort part of the traffic resulting from AF conditioning. The proposed congestion control has been specified and tested inside DCCP/CCID 3 for DiffServ/AF networks [Lochin07] [Jourjon08].
最近、研究および潜在的な解決策を保証TFRC（gTFRC）[Lochin06]を導入が提案されています。 gTFRCは、DiffServの/保証転送（AF）クラス上のユニキャストフローのスループット保証を提供するTCPフレンドリーレート制御の適応です。 gTFRCの目的は、AFのコンディショニングから生じるトラフィックのベストエフォート部からの保証部分を区別することです。提案された輻輳制御は[Lochin07] [Jourjon08]のDiffServ / AFネットワーク用に指定され、DCCP / CCID 3の内部にテストされています。
Nevertheless, there is still work to be performed regarding lower-precedence traffic -- data transfers that are useful, yet not important enough to warrant significantly impairing other traffic. Examples of applications that could make use of such traffic are web caches and web browsers (e.g., for pre-fetching) as well as peer-to-peer applications. There are proposals for achieving low precedence on a pure end-to-end basis (e.g., TCP Low Priority (TCP-LP) [Kuzmanovic03]), and there is a specification for achieving it via router mechanisms [RFC3662]. It seems, however, that network-based lower-precedence mechanisms are not yet a common service on the Internet. Since early 2010, end-to-end mechanisms for lower precedence, e.g., [Shal10], have become common -- at least when competing with other traffic as part of its own queues (e.g., in a home router). But it is less clear whether users will be willing to make their background traffic yield to other people's foreground traffic, unless the appropriate incentives are created.
他のトラフィックを損なう大幅に保証するために役立つデータ転送を、まだ十分では重要ではない - それにもかかわらず、優先順位の低いトラフィックについて実行することに努めてまだあります。そのようなトラフィックの使用を作ることができるアプリケーションの例は、同様にピア・ツー・ピア・アプリケーションとしてWebキャッシュ及びウェブブラウザである（例えば、プリフェッチのために）。純粋なエンド・ツー・エンドの基準（例えば、TCP低優先度（TCP-LP）Kuzmanovic03]）に低い優先順位を達成するための提案があり、ルータメカニズム[RFC3662]を介してそれを達成するための仕様が存在します。しかし、そのネットワークベースの優先順位の低いメカニズムはまだインターネット上で共通のサービスではありません、そうです。 2010年初頭以来、低い優先順位、例えば、[Shal10]のエンドツーエンドのメカニズムは、一般的になってきている - 少なくとも、自身のキュー（例えば、ホームルータにおける）の一部として、他のトラフィックと競合します。しかし、ユーザーが適切なインセンティブが作成されていない限り、他の人のフォアグラウンドトラフィックに自分のバックグラウンドトラフィックの歩留まりを作ることをいとわないだろうかあまり明確です。
There is an issue over how to reconcile two divergent views of the relation between traffic class precedence and congestion control. One view considers that congestion signals (losses or explicit notifications) in one traffic class are independent of those in another. The other relates marking of the classes together within the active queue management (AQM) mechanism [Gibbens02]. In the independent case, using a higher-precedence class of traffic gives a higher scheduling precedence and generally lower congestion level. In the linked case, using a higher-precedence class of traffic still gives higher scheduling precedence, but results in a higher level of congestion. This higher congestion level reflects the extra congestion higher-precedence traffic causes to both classes combined. The linked case separates scheduling precedence from rate control. The end-to-end congestion control algorithm can separately choose to take a higher rate by responding less to the higher level of congestion. This second approach could become prevalent if weighted congestion controls were common. However, it is an open issue how the two approaches might co-exist or how one might evolve into the other.
トラフィッククラスの優先順位と輻輳制御との関係の2人の多様な意見を調整する方法を超える問題があります。一つのビューには、1つのトラフィッククラスにおける輻輳信号（損失または明示的な通知は）別のものとは無関係であると考えています。他は、アクティブキュー管理（AQM）メカニズム[Gibbens02]内に一緒にクラスのマーキングに関する。独立した場合に、トラフィックの高い優先クラスを使用すると、より高いスケジューリング優先順位と一般に低い輻輳レベルを与えます。リンクされた場合には、トラフィックの優先度が高いクラスを使用すると、さらに高いスケジューリングの優先順位を与えるが、混雑のより高いレベルでの結果。この高い輻輳レベルは、より高い優先順位のトラフィックを組み合わせ、両方のクラスになり、余分な混雑を反映しています。リンクされた場合は、レート制御からのスケジューリングの優先順位を分離します。エンドツーエンドの輻輳制御アルゴリズムは、別途渋滞のより高いレベルに以下を応答することによって、高いレートを取ることを選択することができます。加重輻輳制御が一般的であった場合には、この第2のアプローチは、流行になる可能性があります。しかし、それは二つのアプローチが共存する方法をか一方が他方に進化する方法を開いて問題があります。
In the current Internet architecture, congestion control depends on parties acting against their own interests. It is not in a receiver's interest to honestly return feedback about congestion on the path, effectively requesting a slower transfer. It is not in the sender's interest to reduce its rate in response to congestion if it can rely on others to do so. Additionally, networks may have strategic reasons to make other networks appear congested.
現在のインターネットアーキテクチャでは、輻輳制御は、自分の利益に反する行為の当事者に依存します。それは正直に効果的に遅い転送を要求して、パス上の輻輳に関するフィードバックを返すために、受信者の関心ではありません。それはそうするように他人に頼ることができれば、混雑に応答して、その割合を減らすために、送信者の関心ではありません。さらに、ネットワークは、他のネットワークが混雑して表示させるための戦略的な理由を有することができます。
Numerous strategies to improve congestion control have already been identified. The IETF has particularly focused on misbehaving TCP receivers that could confuse a compliant sender into assigning excessive network and/or server resources to that receiver (e.g., [Savage99], [RFC3540]). But, although such strategies are worryingly powerful, they do not yet seem common (however, evidence of attack prevalence is itself a research requirement).
輻輳制御を改善するための多くの戦略がすでに確認されています。 IETFは、特に、その受信機（例えば、[Savage99]、[RFC3540]）に過剰なネットワークおよび/またはサーバリソースを割り当てるに準拠した送信者を混乱させる可能性がTCP受信機が誤動作に焦点を当ててきました。このような戦略は、困ったことに強力ですが、しかし、彼らはまだ（ただし、攻撃の有病率の証拠が自身の研究の要件です）一般的なようではありません。
A growing proportion of Internet traffic comes from applications designed not to use congestion control at all, or worse, applications that add more forward error correction as they experience more losses. Some believe the Internet was designed to allow such freedom, so it can hardly be called misbehavior. But others consider it misbehavior to abuse this freedom [RFC3714], given one person's freedom can constrain the freedom of others (congestion represents this conflict of interests). Indeed, leaving freedom unchecked might result in congestion collapse in parts of the Internet. Proportionately, large volumes of unresponsive voice traffic could represent such a threat, particularly for countries with less generous provisioning [RFC3714]. Also, Internet video on demand services that transfer much greater data rates without congestion control are becoming popular. In general, it is recommended that such UDP applications use some form of congestion control [RFC5405].
インターネットトラフィックの増加割合は全く輻輳制御を使用しないように設計されたアプリケーション、または悪いことに、彼らはより多くの損失を経験するように、より前方誤り訂正を追加するアプリケーションから来ています。いくつかは、インターネットが、このような自由を許可するように設計されていたので、それはほとんどの不正行為と呼ばれることはできないと考えています。しかし、他の人は、それは（輻輳が利益のこの競合を表します）[RFC3714]、一人の人間の自由を与えられたが、他人の自由を制約することができ、この自由を乱用して不正行為を検討してください。確かに、未チェックの自由を残して、インターネットの一部で混雑崩壊につながる可能性があります。比例、無応答、音声トラフィックの大ボリュームは特に少ない寛大なプロビジョニング[RFC3714]で国のために、このような脅威を表すことができます。また、輻輳制御なしではるかに高いデータ・レートを転送するオンデマンドサービスインターネットビデオが普及してきています。一般に、このようなUDPアプリケーションは、[RFC5405]の輻輳制御のいくつかのフォームを使用することをお勧めします。
Note that the problem is not just misbehavior driven by a self-interested desire for more bandwidth. Indeed, congestion control may be attacked by someone who makes no gain for themselves, other than the satisfaction of harming others (see Security Considerations in Section 4).
問題は、より多くの帯域幅のための利己的な欲望によって駆動だけで不正行為がないことに注意してください。確かに、輻輳制御は、他人を傷つけるの満足度以外の自分自身のためのゲインを行うものではありません誰か、（第4節ではセキュリティ上の考慮事項を参照）によって攻撃することができます。
Open research questions resulting from these considerations are:
これらの考察から生じたオープン研究課題は以下のとおりです。
- By design, new congestion control protocols need to enable one end to check the other for protocol compliance. How would such mechanisms be designed?
- 設計することにより、新たな輻輳制御プロトコルは、プロトコルに準拠するために他をチェックするために一端を有効にする必要があります。どのようなメカニズムを設計することでしょうか？
- Which congestion control primitives could safely satisfy more demanding applications (smoother than TFRC, faster than high-speed TCPs), so that application developers and users do not turn off congestion control to get the rate they expect and need?
- そのアプリケーションの開発者とユーザーが期待する割合を取得し、必要に輻輳制御をオフにしないように制御プリミティブは、安全に、（高速のTCPよりも速くTFRCよりスムーズに、）より要求の厳しいアプリケーションを満たすことができた渋滞？
Note also that self-restraint could disappear from the Internet. So, it may no longer be sufficient to rely on developers/users voluntarily submitting themselves to congestion control. As a consequence, mechanisms to enforce fairness (see Sections 2.3, 3.4, and 3.5) need to have more emphasis within the research agenda.
その自制はインターネットから消える可能性にも注意してください。だから、もはや、開発者/ユーザーが自主的に輻輳制御に自分自身を提出するに頼るのに十分でないかもしれません。その結果、公平性を強制するメカニズムは（セクション2.3、3.4を参照してください、そして3.5）研究課題の中に、より重点を持っている必要があります。
This section provides additional challenges and open research issues that are not (at this point in time) deemed so significant, or they are of a different nature compared to the main challenges depicted so far.
このセクションでは、みなし（この時点で）それほど重要ではありません、追加の課題とオープンな研究課題を提供し、または彼らがこれまでに示されている主な課題とは異なる性質のものです。
Several congestion control schemes have to precisely know the round-trip time (RTT) of a path. The RTT is a measure of the current delay on a network. It is defined as the delay between the sending of a packet and the reception of a corresponding response, if echoed back immediately by the receiver upon receipt of the packet. This corresponds to the sum of the one-way delay of the packet and the (potentially different) one-way delay of the response. Furthermore, any RTT measurement also includes some additional delay due to the packet processing in both end-systems.
いくつかの輻輳制御方式は、正確にパスのラウンドトリップ時間（RTT）を知っている必要があります。 RTTは、ネットワーク上の現在の遅延の尺度です。パケットを受信すると、受信機によって即座にエコーバック場合には、パケットの送信及び対応する応答の受信との間の遅延として定義されます。これは、パケットの一方向の遅延と応答の（潜在的に異なる）一方向遅延の和に相当します。さらに、任意のRTT測定は、両方のエンドシステムにおけるパケット処理のためにいくつかの追加の遅延を含みます。
There are various techniques to measure the RTT: active measurements inject special probe packets into the network and then measure the response time, using, e.g., ICMP. In contrast, passive measurements determine the RTT from ongoing communication processes, without sending additional packets.
活性測定はネットワークに特別なプローブパケットを注入した後、例えば、ICMPを使用して、応答時間を測定：RTTを測定するための様々な技術が存在します。対照的に、受動的測定は、追加のパケットを送信せず、進行中の通信プロセスからRTTを決定します。
The connection endpoints of transport protocols such as TCP, the Stream Control Transmission Protocol (SCTP), and DCCP, as well as several application protocols, keep track of the RTT in order to dynamically adjust protocol parameters such as the retransmission timeout (RTO) or the rate-control equation. They can implicitly measure the RTT on the sender side by observing the time difference between the sending of data and the arrival of the corresponding acknowledgments. For TCP, this is the default RTT measurement procedure; it is used in combination with Karn's algorithm, which prohibits RTT measurements from retransmitted segments [RFC2988]. Traditionally, TCP implementations take one RTT measurement at a time (i.e., about once per RTT). As an alternative, the TCP timestamp option [RFC1323] allows more frequent explicit measurements, since a sender can safely obtain an RTT sample from every received acknowledgment. In principle, similar measurement mechanisms are used by protocols other than TCP.
このようなTCP、ストリーム制御伝送プロトコル（SCTP）、およびDCCP、ならびにいくつかのアプリケーションプロトコルのようなトランスポートプロトコルの接続エンドポイントは、動的に、このような再送タイムアウト（RTO）またはプロトコルパラメータを調整するためにRTTを追跡しますレート制御式。彼らは、暗黙的にデータを送信し、対応する確認応答の到着の間の時間差を観察することによって、送信者側のRTTを測定することができます。 TCPの場合、これがデフォルトRTTの測定手順です。これは、再送セグメント[RFC2988]からのRTT測定値を禁止カーンのアルゴリズムと組み合わせて使用されます。伝統的に、TCPの実装では（すなわち、約回RTTごとに）一度に一つのRTT測定値を取ります。送信者が安全にすべての受信確認応答からRTTのサンプルを得ることができるので、代替として、TCPタイムスタンプオプション[RFC1323]は、より頻繁に明示的な測定を可能にします。原則として、同様の測定メカニズムは、TCP以外のプロトコルで使用されています。
Sometimes it would be beneficial to know the RTT not only at the sender, but also at the receiver, e.g., to find the one-way variation in delay due to one-way congestion. A passive receiver can deduce some information about the RTT by analyzing the sequence numbers of received segments. But this method is error-prone and only works if the sender permanently sends data. Other network entities on the path can apply similar heuristics in order to approximate the RTT of a connection, but this mechanism is protocol-specific and requires per-connection state. In the current Internet, there is no simple and safe solution to determine the RTT of a connection in network entities other than the sender. The more fundamental question is to determine whether it is necessary or not for network elements to measure or know the RTT.
時には一方通行渋滞による遅延で一方向の変化を見つけるために、例えば、送信側ではなく、受信機ではないだけRTTを知ることは有益であろう。パッシブ受信機は、受信したセグメントのシーケンス番号を分析することによってRTTに関する情報を推定することができます。しかし、この方法ではエラーが発生しやすいと送信者が永続的にデータを送信する場合にのみ機能します。経路上の他のネットワーク・エンティティは、接続のRTTを近似するために、同様の経験則を適用することができるが、このメカニズムは、プロトコル固有であり、接続ごとの状態を必要とします。現在のインターネットでは、送信者以外のネットワークエンティティにおけるコネクションのRTTを決定するためのシンプルで安全な解決策はありません。もっと根本的な問題は、ネットワーク要素がRTTを測定するか、知ることが必要であるかどうかを決定することです。
As outlined earlier in this document, the round-trip time is typically not a constant value. For a given path, there is a theoretical minimum value, which is given by the minimum transmission, processing, and propagation delay on that path. However, additional variable delays might be caused by congestion, cross-traffic, shared-media access control schemes, recovery procedures, or other sub-IP layer mechanisms. Furthermore, a change of the path (e.g., route flapping, hand-over in mobile networks) can result in completely different delay characteristics.
この文書で先に概説したように、ラウンドトリップ時間は、通常、一定値ではありません。指定されたパスは、そのパス上の最小の送信、処理、及び伝搬遅延によって与えられる理論的な最小値が存在します。しかし、追加の可変遅延は、輻輳、クロストラフィック、共有メディアアクセス制御方式、リカバリ手順、または他のサブIPレイヤ機構によって引き起こされるかもしれません。また、パスの変化（例えば、ルートフラッピング、モバイルネットワークにおけるハンドオーバー）は、完全に異なる遅延特性をもたらすことができます。
Due to this variability, one single measured RTT value is hardly sufficient to characterize a path. This is why many protocols use RTT estimators that derive an averaged value and keep track of a certain history of previous samples. For instance, TCP endpoints derive a smoothed round-trip time (SRTT) from an exponential weighted moving average [RFC2988]. Such a low-pass filter ensures that measurement noise and single outliers do not significantly affect the estimated RTT. Still, a fundamental drawback of low-pass filters is that the averaged value reacts more slowly to sudden changes in the measured RTT. There are various solutions to overcome this effect: For instance, the standard TCP retransmission timeout calculation considers not only the SRTT, but also a measure for the variability of the RTT measurements [RFC2988]. Since this algorithm is not well suited for frequent RTT measurements with timestamps, certain implementations modify the weight factors (e.g., [Sarola02]). There are also proposals for more sophisticated estimators, such as Kalman filters or estimators that utilize mainly peak values.
この変動に起因して、単一の測定されたRTT値は、経路を特徴付けるためにほとんど十分です。多くのプロトコルは、平均値を導出し、前のサンプルの特定の歴史を追跡するRTT推定器を使用する理由です。例えば、TCPエンドポイントは、指数加重移動平均[RFC2988]からの平滑化往復時間（SRTT）を導出します。このような低域通過フィルタは、測定ノイズおよび単一の異常値が大幅に推定RTTに影響を与えないことを保証します。それでも、低域通過フィルタの基本的な欠点は、平均値が測定されたRTTの急激な変化に、よりゆっくりと反応することです。この効果を克服するための様々なソリューションがあります。たとえば、標準のTCPの再送タイムアウト計算はSRTT、だけでなく、RTT測定[RFC2988]のばらつきのための尺度ではないだけを考慮します。このアルゴリズムは、タイムスタンプと頻繁RTT測定にはあまり適していないので、いくつかの実装は、重み係数を変更する（例えば、[Sarola02]）。このようカルマン・フィルタや、主ピーク値を利用推定など、より洗練された推定のための提案もあります。
However, open questions related to RTT estimation in the Internet remain:
しかし、インターネットでRTT推定に関連する未解決の問題が残っています：
- Optimal measurement frequency: Currently, there is no theory or common understanding of the right time scale of RTT measurement. In particular, the necessity for rather frequent measurements (e.g., per packet) is not well understood. There is some empirical evidence that such frequent sampling may not have a significant benefit [Allman99].
- 最適な測定周波数：現在、理論やRTT測定の右の時間スケールの共通の理解がありません。具体的には、かなり頻繁な測定値（例えば、パケット当たり）の必要性はよく理解されていません。頻繁なサンプリングが大きな利点[Allman99]を持つことができないことを、いくつかの実証的証拠があります。
- Filter design: A closely related question is how to design good filters for the measured samples. The existing algorithms are known to be robust, but they are far from being perfect. The fundamental problem is that there is no single set of RTT values that could characterize the Internet as a whole, i.e., it is hard to define a design target.
- フィルタの設計：密接に関連する質問は、測定したサンプルのための良いフィルタを設計する方法です。既存のアルゴリズムは、堅牢であることが知られているが、彼らは完璧には程遠いされています。根本的な問題は、すなわち、設計目標を定義するのは難しいです、全体としてインターネットを特徴付けることができRTT値の単一のセットがないことです。
- Default values: RTT estimators can fail in certain scenarios, e.g., when any feedback is missing. In this case, default values have to be used. Today, most default values are set to conservative values that may not be optimal for most Internet communication. Still, the impact of more aggressive settings is not well understood.
- デフォルト値：任意のフィードバックが欠落しているとき、RTT推定量は、例えば、特定のシナリオで失敗することができます。この場合、デフォルト値を使用しなければなりません。今日では、ほとんどのデフォルト値は、ほとんどのインターネット通信のためには最適ではないかもしれない保守的な値に設定されています。それでも、より積極的な設定の影響は十分に理解されていません。
- Clock granularities: RTT estimation depends on the clock granularities of the protocol stacks. Even though there is a trend toward higher-precision timers, limited granularity (particularly on low-cost devices) may still prevent highly accurate RTT estimations.
- クロックの粒度：RTT推定は、プロトコルスタックのクロック粒度に依存します。より高い精度のタイマー傾向があるにもかかわらず、（特に低コストのデバイスに）制限された粒度は依然として非常に正確なRTT推定を防止することができます。
There is a long history of malfunctioning devices harming the deployment of new and potentially beneficial functionality in the Internet. Sometimes, such devices drop packets or even crash completely when a certain mechanism is used, causing users to opt for reliability instead of performance and disable the mechanism, or operating-system vendors to disable it by default. One well-known example is ECN, whose deployment was long hindered by malfunctioning firewalls and is still hindered by malfunctioning home-hubs, but there are many other examples (e.g., the Window Scaling option of TCP) [Thaler07].
インターネットの新しいし、潜在的に有益な機能の展開を傷つける誤動作デバイスの長い歴史があります。時には、このようなデバイスはパケットをドロップするか、特定のメカニズムが使用されている場合でも、ユーザーは代わりに、性能の信頼性を選ぶと、デフォルトでは、それを無効にするには、ベンダーをメカニズムを無効にする、またはオペレーティング・システムを引き起こし、完全にクラッシュ。 1つのよく知られた例は、その展開長い誤動作ファイアウォールによって妨げられたとまだ誤動作ホームハブによって妨げられるECN、であるが、他の多くの例がある（例えば、TCPのオプションをスケーリングウィンドウ）[Thaler07]。
As new congestion control mechanisms are developed with the intention of eventually seeing them deployed in the Internet, it would be useful to collect information about failures caused by devices of this sort, analyze the reasons for these failures, and determine whether there are ways for such devices to do what they intend to do without causing unintended failures. Recommendations for vendors of these devices could be derived from such an analysis. It would also be useful to see whether there are ways for failures caused by such devices to become more visible to endpoints, or to the maintainers of such devices.
新しい輻輳制御メカニズムが最終的に彼らはインターネットで展開見ての意図して開発されているとして、この種のデバイスに起因する障害についての情報を収集し、これらの障害の理由を分析し、方法は、そのようなのためにあるかどうかを判断するために有用であろう彼らは意図しない不具合を発生させずに行うつもり何をすべきかのデバイス。これらのデバイスのベンダーへの提言は、このような分析から導き出すことができました。また、エンドポイントへ、またはそのようなデバイスのメンテナにもっと目に見えるようになるために、このようなデバイスに起因する障害のための方法があるかどうかを確認することは有用であろう。
A possible way to reduce such problems in the future would be guidelines for standards authors to ensure that "forward compatibility" is considered in all IETF work. That is, the default behavior of a device should be precisely defined for all possible values and combinations of protocol fields, and not just the minimum necessary for the protocol being defined. Then, when previously unused or reserved fields start to be used by newer devices to comply with a new standard, older devices encountering unusual fields should at least behave predictably.
将来的にはこのような問題を低減することが可能な方法は、「前方互換性は、」すべてのIETFの作業で考慮されることを確実にするための規格の作者のためのガイドラインになります。すなわち、デバイスのデフォルトの挙動を正確に全ての可能な値と組み合わせプロトコルフィールドのではなく、定義されたプロトコルに必要なだけの最小のために定義されるべきです。以前に未使用または予約フィールドが新しい標準に準拠するために新しいデバイスが使用することを開始したときに続いて、異例のフィールドに遭遇古いデバイスは、少なくとも予想どおりに動作しなければなりません。
AIMD window algorithms that have the goal of packet conservation end up converging on a rate that is inversely proportional to RTT. However, control theoretic approaches to stability have shown that only the increase in rate (acceleration), and not the target rate, needs to be inversely proportional to RTT [Jin04].
パケットの保全の目標を持ってAIMDウィンドウアルゴリズムはRTTに反比例する率に収束終わります。しかし、安定性の理論的アプローチは、速度（加速度）の増加はなく、目標速度は、RTT [Jin04]に反比例する必要があることが示されている制御します。
It is possible to have more aggressive behaviors for some demanding applications as long as they are part of a mix with less aggressive transports [Key04]. This beneficial effect of transport type mixing is probably how the Internet currently manages to remain stable even in the presence of TCP slow-start, which is more aggressive than the theory allows for stability. Research giving deeper insight into these aspects would be very useful.
彼らがあまり積極的なトランスポート[Key04]とのミックスの一部である限り、いくつかの要求の厳しいアプリケーションのためのより積極的な行動をすることが可能です。トランスポート・タイプ混合のこの有益な効果は、インターネットが現在の理論は、安定性を可能以上に積極的である、でもTCPスロースタートの存在下での安定性を維持するためにどのように管理するか考えられます。これらの側面に深い洞察を与える研究は非常に有用であろう。
A network of IP nodes is just as vulnerable to congestion in the lower layers between IP-capable nodes as it is to congestion on the IP-capable nodes themselves. If network elements take a greater part in congestion control (ECN, XCP, RCP, etc. -- see Section 3.1), these techniques will either need to be deployed at lower layers as well, or they will need to interwork with lower-layer mechanisms.
それはIP対応のノード自身の輻輳であるように、IPノードのネットワークは、IP対応のノード間の下位層における輻輳に同じように脆弱です。ネットワーク要素は（等ECN、XCP、RCP、 - セクション3.1を参照）輻輳制御に大きく関与している場合、これらの技術は、同様に下位層に配備する必要がありますのいずれか、またはそれらは下層と相互作用する必要がありますメカニズム。
[RFC5129] shows how to propagate ECN from lower layers upwards for the specific case of MPLS, but to the authors' knowledge the layering problem has not been addressed for explicit rate protocol proposals such as XCP and RCP. Some issues are straightforward matters of interoperability (e.g., how exactly to copy fields up the layers) while others are less obvious (e.g., re-framing issues: if RCP were deployed in a lower layer, how might multiple small RCP frames, all with different rates in their headers, be assembled into a larger IP layer datagram?).
[RFC5129]は上向きMPLSの特定の場合のために下位レイヤからECNを伝播する方法を示しているが、著者の知識に階層化問題は、XCPとRCPとして明示レートプロトコルの提案のために取り組まれていません。他の人があまり明白である間、いくつかの問題が（例えば、再フレーミング問題の相互運用性の直接的な事柄（例えば、どのように正確に層をフィールドをコピーする）です：RCPは、下層に配備された場合、どのように複数の小さなRCPフレームかもしれないが、すべてでそのヘッダーに異なる速度が、より大きなIP層データグラムに組み込むこと？）。
Multi-layer considerations also confound many mechanisms that aim to discover whether every node on the path supports a new congestion control protocol. For instance, some proposals maintain a secondary Time to Live (TTL) field parallel to that in the IP header. Any nodes that support the new behavior update both TTL fields, whereas legacy IP nodes will only update the IP TTL field. This allows the endpoints to check whether all IP nodes on the path support the new behavior, in which case both TTLs will be equal at the receiver. But mechanisms like these overlook nodes at lower layers that might not support the new behavior.
マルチレイヤの考察はまた、パス上のすべてのノードが新しい輻輳制御プロトコルをサポートしているかどうかを発見することを目指して多くのメカニズムを混乱させる。例えば、いくつかの提案は、IPヘッダーのものと（TTL）フィールド平行を生きて二時間を維持します。従来のIPノードのに対し、新しい動作更新の両方TTLフィールドをサポートする任意のノードは、IP TTLフィールドを更新します。これは、エンドポイントは、パス上のすべてのIPノードが両方のTTLが受信機に等しくなり、その場合、新しい動作をサポートするかどうかをチェックすることを可能にします。しかし、このようなメカニズムは、新しい動作をサポートしていない可能性があります下位層のノードを見渡すことができます。
A further related issue is congestion control across overlay networks of relays [Hilt08] [Noel07] [Shen08].
さらに関連する問題は、[Shen08] [Hilt08] [Noel07】リレーのオーバレイネットワーク全体の輻輳制御です。
Section 3.5.3 deals with inelastic multi-domain pseudowires (PWs), where the identity of the pseudowire itself implies the characteristics of the traffic crossing the multi-domain PSN (independently of the actual characteristics of the traffic carried in the PW). A more complex situation arises when inelastic traffic is carried as part of a pseudowire (e.g., inelastic traffic over Ethernet PW over PSN) whose edges do not have the means to characterize the properties of the traffic encapsulated in the Ethernet frames. In this case, the problem explained in Section 3.5.3 is not limited to multi-domain pseudowires but more generally arises from a "pseudowire carrying inelastic traffic" (whether over a single- or multi-domain PSN).
セクション疑似回線自体のアイデンティティは（独立PWで運ばれるトラフィックの実際の特性の）マルチドメインPSNを通過するトラフィックの特性を意味し、非弾性マルチドメイン疑似回線（PWの）と3.5.3扱います。非弾性トラフィックがエッジイーサネットフレーム内にカプセル化されたトラフィックの特性を特徴付けるための手段を持っていない疑似回線（PSNオーバーイーサネットPWオーバー例えば、非弾性トラフィック）の一部として実施される場合、より複雑な状況が生じます。この場合、問題は、セクション3.5.3で説明したマルチドメイン疑似回線に限定されるものではなく、より一般的に「非弾性トラフィックを運ぶスードワイヤ」（シングルまたはマルチドメインPSN上か）から生じます。
The problem becomes even more intricate when the Ethernet PW carries both inelastic and elastic traffic. Addressing this issue further supports our observation that a general framework to efficiently deal with congestion control problems in multi-layer networks without harming evolvability is absolutely necessary.
イーサネットPWは、非弾性及び弾性の両方のトラフィックを伝送する場合、問題はさらに複雑になります。さらに、この問題に対処する効率的な発展性を損なうことなく、マルチレイヤネットワークにおける輻輳制御の問題に対処するための一般的なフレームワークが絶対に必要であるという我々の観察をサポートしています。
Recent work has shown that multipath endpoint congestion control [Kelly05] offers considerable benefits in terms of resilience and resource usage efficiency. The IETF has since initiated a work item on multipath TCP [MPTCP]. By pooling the resources on all paths, even nodes not using multiple paths benefit from those that are.
最近の研究では、[Kelly05]をそのマルチエンドポイントの輻輳制御を示している回復力と資源の利用効率の点でかなりの利点を提供します。 IETFは、以来、[MPTCP]マルチパスTCP上の作業項目を開始しました。すべてのパス上のリソースをプールすることにより、偶数であるものの恩恵を受ける複数のパスを使用していないノード。
There is considerable further research to do in this area, particularly to understand interactions with network-operator-controlled route provisioning and traffic engineering, and indeed whether multipath congestion control can perform better traffic engineering than the network itself, given the right incentives [Arkko09].
特にネットワーク・オペレータ制御ルートのプロビジョニングおよびトラフィックエンジニアリング、およびとの相互作用を理解するために、この領域で行うにはかなりの更なる研究があり、マルチパスの輻輳制御は、右のインセンティブ与えられたネットワークそのものよりも優れたトラフィック・エンジニアリングを行うことができます実際にするかどうか[Arkko09] 。
An increasing number of application layer gateways (ALGs), middleboxes, and proxies (see Section 3.6 of [RFC2775]) are deployed at domain boundaries to verify conformance but also filter traffic and control flows. One motivation is to prevent information beyond routing data leaking between autonomous systems. These systems split up end-to-end TCP connections and disrupt end-to-end congestion control. Furthermore, transport over encrypted tunnels may not allow other network entities to participate in congestion control.
アプリケーション層ゲートウェイ（のALG）、中間装置、及びプロキシの増加は、（[RFC2775]のセクション3.6を参照）の適合性を検証するだけでなく、トラフィック及び制御フローをフィルタリングするドメインの境界に配備されています。一つの動機は、自律システム間で漏れたデータをルーティングを超えて情報を防ぐためです。これらのシステムは、エンド・ツー・エンドのTCPコネクションを分割し、エンドツーエンドの輻輳制御を混乱させる。さらに、暗号化されたトンネルを介した輸送は他のネットワークエンティティは、輻輳制御に参加することができない場合があります。
Basically, such systems disrupt the primal and dual congestion control components. In particular, end-to-end congestion control may be replaced by flow-control backpressure mechanisms on the split connections. A large variety of ALGs and middleboxes use such mechanisms to improve the performance of applications (Performance Enhancing Proxies, Application Accelerators, etc.). However, the implications of such mechanisms, which are often proprietary and not documented, have not been studied systematically so far.
基本的に、このようなシステムは、原始およびデュアル輻輳制御コンポーネントを混乱させる。具体的には、エンドツーエンドの輻輳制御は、分割接続のフロー制御背圧機構に置き換えてもよいです。 ALG及び中間装置の多種多様なアプリケーション（パフォーマンス等プロキシ、アプリケーションアクセラレータを高める）の性能を改善するために、このようなメカニズムを使用します。しかし、多くの場合、独自の、文書化されないようなメカニズムの意味合いは、これまで体系的に研究されていません。
There are two levels of interference:
干渉の2つのレベルがあります。
- The "transparent" case, i.e., the endpoint address from the sender perspective is still visible to the receiver (the destination IP address). Relay systems that intercept payloads but do not relay congestion control information provide an example. Such middleboxes can prevent the operation of end-to-end congestion control.
- 「透明」の場合には、すなわち、送信側の観点からエンドポイントアドレスは依然として受信機（宛先IPアドレス）に表示されています。ペイロードを傍受が、例を提供輻輳制御情報を中継しないシステムリレー。そのような中間装置は、エンドツーエンドの輻輳制御の動作を防止することができます。
- The "non-transparent" case, which causes fewer problems for congestion control. Although these devices interfere with end-to-end network transparency, they correctly terminate network, transport, and application layer protocols on both sides, which individually can be congestion controlled.
- 輻輳制御のための少数の問題を引き起こし、「非透過」の場合、。これらのデバイスは、エンドツーエンドのネットワーク透過性を妨害するが、それらは正確に個々に輻輳制御することができる両側のネットワーク、トランスポート、およびアプリケーション層プロトコルを終端します。
Misbehavior may be driven by pure malice, or malice may in turn be driven by wider selfish interests, e.g., using distributed denial-of-service (DDoS) attacks to gain rewards by extortion [RFC4948]. DDoS attacks are possible both because of vulnerabilities in operating systems and because the Internet delivers packets without requiring congestion control.
恐喝[RFC4948]によって報酬を得るために、分散型サービス拒否（DDoS）攻撃の攻撃を使用して、例えば、不正行為は純粋な悪意によって駆動されてもよい、あるいは悪意は、順番に、より広い利己的な利益によって駆動されてもよいです。 DDoS攻撃は、オペレーティング・システムの脆弱性により、インターネットは、輻輳制御を必要とせずにパケットを提供するための両方可能です。
To date, compliance with congestion control rules and being fair require endpoints to cooperate. The possibility of uncooperative behavior can be regarded as a security issue; its implications are discussed throughout these documents in a scattered fashion.
日付、輻輳制御ルールを遵守し、公正であることに協力するエンドポイントが必要です。非協力的な行動の可能性は、セキュリティ上の問題とみなすことができます。その意味は、散乱形でこれらの文書全体で議論されています。
Currently the focus of the research agenda against denial of service is about identifying attack-packets that attack machines and the networks hosting them, with a particular focus on mitigating source address spoofing. But if mechanisms to enforce congestion control fairness were robust to both selfishness and malice [Bri06], they would also naturally mitigate denial of service against the network, which can be considered (from the perspective of a well-behaved Internet user) as a congestion control enforcement problem. Even some denial-of-service attacks on hosts (rather than the network) could be considered as a congestion control enforcement issue at the higher layer. But clearly there are also denial-of-service attacks that would not be solved by enforcing congestion control.
現在、サービス拒否に対する研究課題の焦点は、送信元アドレススプーフィングの軽減に特に焦点を当てて、マシンとそれらをホストするネットワークを攻撃する攻撃パケットを識別についてです。メカニズムは、輻輳制御公平性を強制する場合は利己との両方に対してロバストであった悪意[Bri06]、彼らはまた、天然に輻輳として（行儀のインターネットユーザの観点から）と考えることができるネットワークに対するサービス拒否攻撃を軽減するであろう執行の問題を制御します。 （ネットワークではなく）ホスト上でも、いくつかのサービス拒否攻撃は、上位層で輻輳制御執行の問題として考えることができます。しかし、明らかに輻輳制御を実施することによって解決されないDoS攻撃もあります。
Sections 3.5 and 3.7 on multi-domain issues and misbehaving senders and receivers also discuss some information security issues suffered by various congestion control approaches.
マルチドメインの問題や不正な動作送信側と受信側のセクション3.5および3.7にも様々な輻輳制御手法により被ったいくつかの情報セキュリティ上の問題を議論します。
[Allman99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", Proceedings of ACM SIGCOMM'99, September 1999.
「エンドツーエンドのネットワークパスのプロパティの推定について」[Allman99]オールマン、M.およびV.パクソン、ACM SIGCOMM'99、1999年9月の議事。
[Andrew05] Andrew, L., Wydrowski, B., and S. Low, "An Example of Instability in XCP", Manuscript available at <http://netlab.caltech.edu/maxnet/XCP_instability.pdf>.
【Andrew05]アンドリュー、L.、Wydrowski、B.、およびS.低、 "XCPにおける不安定性の例"、<http://netlab.caltech.edu/maxnet/XCP_instability.pdf>で入手可能写本。
[Arkko09] Arkko, J., Briscoe, B., Eggert, L., Feldmann, A., and M. Handley, "Dagstuhl Perspectives Workshop on End-to-End Protocols for the Future Internet," ACM SIGCOMM Computer Communication Review, Vol. 39, No. 2, pp. 42-47, April 2009.
[Arkko09] Arkko、J.、ブリスコー、B.、エッゲルト、L.、フェルドマン、A.、およびM.ハンドリー、 "未来のインターネットのエンドツーエンドのプロトコル上のDagstuhl展望ワークショップ、" ACM SIGCOMMコンピュータコミュニケーションレビュー巻。 39、第2号、頁42-47、2009年4月。
[Ath01] Athuraliya, S., Low, S., Li, V., and Q. Yin, "REM: Active Queue Management", IEEE Network Magazine, Vol. 15, No. 3, pp. 48-53, May 2001.
[Ath01] Athuraliya、S.、低、S.、李、V.、およびQ.殷、 "REM：アクティブキュー管理"、IEEEネットワークマガジン、巻。 15、第3号、PP。48-53、2001年5月。
[Balan01] Balan, R.K., Lee, B.P., Kumar, K.R.R., Jacob, L., Seah, W.K.G., and A.L. Ananda, "TCP HACK: TCP Header Checksum Option to Improve Performance over Lossy Links", Proceedings of IEEE INFOCOM'01, Anchorage (Alaska), USA, April 2001.
[Balan01]バラン、RK、リー、BP、クマー、KRR、ジェイコブ、L.、SEAH、WKG、およびALアナンダ、 "TCPのHACK：ロッシーリンク上でのパフォーマンスを向上させるTCPヘッダチェックサム・オプション"、IEEE INFOCOM'01の議事録、アンカレッジ（アラスカ州）、USA、2001年4月。
[Bonald00] Bonald, T., May, M., and J.-C. Bolot, "Analytic Evaluation of RED Performance", Proceedings of IEEE INFOCOM'00, Tel Aviv, Israel, March 2000.
【Bonald00]ボナルド、T.、月、M.、およびJ.-C. Bolot、 "REDパフォーマンスの分析評価"、IEEE INFOCOM'00、テルアビブ、イスラエル、2000年3月の議事。
[Bri06] Briscoe, B., "Using Self-interest to Prevent Malice; Fixing the Denial of Service Flaw of the Internet", Workshop on the Economics of Securing the Information Infrastructure, October 2006, <http://wesii.econinfosec.org/draft.php?paper_id=19>.
「防止マリスに自己の利益を使用して、インターネットのサービス拒否の欠陥を修正する」[Bri06]ブリスコー、B.、情報インフラストラクチャ、2006年10月、<HTTPのセキュリティ保護の経済学に関するワークショップ：//wesii.econinfosec。 ORG / draft.php？paper_id = 19>。
[Bri07] Briscoe, B., "Flow Rate Fairness: Dismantling a Religion", ACM SIGCOMM Computer Communication Review, Vol. 37, No. 2, pp. 63-74, April 2007.
[Bri07]ブリスコー、B.、 "流量フェアネス：宗教を解体"、ACM SIGCOMMコンピュータコミュニケーションレビュー、巻。 37、第2号、頁63-74、2007年4月。
[Bri08] Briscoe, B., Moncaster, T. and L. Burness, "Problem Statement: Transport Protocols Don't Have To Do Fairness", Work in Progress, July 2008.
[Bri08]ブリスコー、B.、Moncaster、T.およびL. Burness、 "問題文：トランスポートプロトコルは、フェアネスを行う必要はありません"、進歩、2008年7月に作業。
[Bri09] Briscoe, B., "Re-feedback: Freedom with Accountability for Causing Congestion in a Connectionless Internetwork", UCL PhD Thesis (2009).
【Bri09】ブリスコー、B.、「再フィードバック：コネクションレスインターネットワークの輻輳を引き起こすための責任の自由」、UCL博士論文（2009）。
[Bri10] Briscoe, B. and J. Manner, "Byte and Packet Congestion Notification," Work in Progress, October 2010.
進歩、2010年10月[Bri10]ブリスコー、B.及びJ.ようにして、「バイトおよびパケットの輻輳通知、」ワーク。
[Chester04] Chesterfield, J., Chakravorty, R., Banerjee, S., Rodriguez, P., Pratt, I., and J. Crowcroft, "Transport level optimisations for streaming media over wide-area wireless networks", WIOPT'04, March 2004.
【Chester04]チェスターフィールド、J.、Chakravorty、R.、バネルジー、S.、ロドリゲス、P.、プラット、I.、およびJ.クロウクロフト、 "広域無線ネットワーク上でメディアをストリーミングするためのトランスポートレベルの最適化"、WIOPT」 04、2004年3月。
[Chhabra02] Chhabra, P., Chuig, S., Goel, A., John, A., Kumar, A., Saran, H., and R. Shorey, "XCHOKe: Malicious Source Control for Congestion Avoidance at Internet Gateways," Proceedings of IEEE International Conference on Network Protocols (ICNP'02), Paris, France, November 2002.
[Chhabra02] Chhabra、P.、Chuig、S.、Goelさん、A.、ジョン、A.、クマー、A.、サラン、H.、およびR.ショーリー、「XCHOKe：インターネットゲートウェイでの輻輳回避のための悪意のあるソースコントロール、」IEEEの国際ネットワークプロトコル上の会議（ICNP'02）、パリ、フランス、2002年11月の議事。
[Chiu89] Chiu, D.M. and R. Jain, "Analysis of the increase and decrease algorithms for congestion avoidance in computer networks", Computer Networks and ISDN Systems, Vol. 17, pp. 1-14, 1989.
【Chiu89]チウ、D.M.そして、R.ジャイナ教、「コンピュータネットワークにおける輻輳回避のための増減アルゴリズムの分析」、コンピュータネットワークとISDNシステム、巻。 17頁。1-14、1989。
[Clark88] Clark, D., "The design philosophy of the DARPA internet protocols", ACM SIGCOMM Computer Communication Review, Vol. 18, No. 4, pp. 106-114, August 1988.
[Clark88]クラーク、D.、「DARPAインターネットプロトコルの設計思想」、ACM SIGCOMMコンピュータコミュニケーションレビュー、巻。 18、第4号、頁106-114、1988年8月。
[Clark98] Clark, D. and W. Fang, "Explicit Allocation of Best-Effort Packet Delivery Service", IEEE/ACM Transactions on Networking, Vol. 6, No. 4, pp. 362-373, August 1998.
[Clark98]クラーク、D.およびW.牙、「ベストエフォートパケットデリバリサービスの明示的な配分」、ネットワーキング、巻上のIEEE / ACM取引。図6に示すように、第4号、頁362から373まで、1998年8月。
[Chu10] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", Work in Progress, October 2010.
[Chu10]チュー、J.、Dukkipati、N.、チェン、Y.、およびM.マシス、 "TCPの初期ウィンドウを増やす"、進歩、2010年10月に作業。
[CONEX] IETF WG Action: Congestion Exposure (conex).
[コーネックス] IETF WG処置：輻輳露出（コネックス）。
[Dukki05] Dukkipati, N., Kobayashi, M., Zhang-Shen, R., and N. McKeown, "Processor Sharing Flows in the Internet", Proceedings of International Workshop on Quality of Service (IWQoS'05), Passau, Germany, June 2005.
[Dukki05] Dukkipati、N.、小林、M.、チャン・シェン、R.、およびN.マッケオン、サービス品質（IWQoS'05）、パッサウに、国際ワークショップの議事録「プロセッサの共有がインターネットに流れ」ドイツ、2005年6月。
[Dukki06] Dukkipati, N. and N. McKeown, "Why Flow-Completion Time is the Right Metric for Congestion Control", ACM SIGCOMM Computer Communication Review, Vol. 36, No. 1, January 2006.
[Dukki06] Dukkipati、N.とN.マッケオンは、ACM SIGCOMMコンピュータコミュニケーションレビュー、集「なぜ、フロー完了時間は、輻輳制御のための右のメトリックです」。 36、第1号、2006年1月。
[ECODE] "ECODE Project", European Commission Seventh Framework Program, Grant No. 223936, <http://www.ecode-project.eu>.
[ECODE] "ECODEプロジェクト"、欧州委員会第七枠組みプログラム、認可番号223936、<http://www.ecode-project.eu>。
[Falk07] Falk, A., Pryadkin, Y., and D. Katabi, "Specification for the Explicit Control Protocol (XCP)", Work in Progress, January 2007.
[Falk07]フォーク、A.、Pryadkin、Y.、およびD. Katabi、 "明示的な制御プロトコル（XCP）のための仕様"、進歩、2007年1月の作業。
[Feldman04] Feldman, M., Papadimitriou, C., Chuang, J., and I. Stoica, "Free-Riding and Whitewashing in Peer-to-Peer Systems" Proceedings of ACM SIGCOMM Workshop on Practice and Theory of Incentives in Networked Systems (PINS'04) 2004.
実践及びネットワークにおけるインセンティブの理論上のACM SIGCOMMワークショップの議事録「ピアツーピアシステムにおけるただ乗りとWhitewashing」[Feldman04]フェルドマン、M.、Papadimitriou、C.、荘、J.、およびI.ストイカ、システムズ（PINS'04）2004。
[Firoiu00] Firoiu, V. and M. Borden, "A Study of Active Queue Management for Congestion Control", Proceedings of IEEE INFOCOM'00, Tel Aviv, Israel, March 2000.
[Firoiu00] Firoiu、V.とM.ボーデン、「輻輳制御のためのアクティブキュー管理の研究」、IEEE INFOCOM'00、テルアビブ、イスラエル、2000年3月の議事。
[Floyd93] Floyd, S. and V. Jacobson, "Random early detection gateways for congestion avoidance", IEEE/ACM Transactions on Networking, Vol. 1, No. 4, pp. 397-413, August 1993.
[Floyd93]フロイド、S.とV. Jacobson氏、 "輻輳回避のためのランダム早期検出・ゲートウェイ"、ネットワーキング、巻上のIEEE / ACM取引。図1に示すように、第4号、頁397から413まで、1993年8月。
[Floyd94] Floyd, S., "TCP and Explicit Congestion Notification", ACM Computer Communication Review, Vol. 24, No. 5, pp. 10-23, October 1994.
[Floyd94]フロイド、S.、 "TCPおよび明示的輻輳通知"、ACMコンピュータコミュニケーションレビュー、巻。 24、第5号、頁10-23、1994年10月。
[Gibbens02] Gibbens, R. and Kelly, F., "On Packet Marking at Priority Queues", IEEE Transactions on Automatic Control, Vol. 47, No. 6, pp. 1016-1020, 2002.
「プライオリティキューでパケットマーキングについて」[Gibbens02] Gibbens、R.ケリー、F.、自動制御、巻上のIEEEトランザクション。 47、第6号、頁1016年から1020年2002年。
[Ha08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A new TCP-friendly high-speed TCP variant", ACM SIGOPS Operating System Review, Vol. 42, No. 5, pp. 64-74, 2008.
[Ha08]ハ、S.、李承晩、I.、およびL.徐、 "CUBIC：新しいTCPに優しい高速TCP変異体"、ACM SIGOPSオペレーティングシステムのレビュー、巻。 42、第5号、PP。64-74、2008。
[Hilt08] Hilt, V. and I. Widjaja, "Controlling Overload in Networks of SIP Servers", Proceedings of IEEE International Conference on Network Protocols (ICNP'08), Orlando (Florida), USA, October 2008.
[Hilt08]柄、V.およびI. Widjaja、 "SIPサーバーのネットワークでの制御過負荷"、ネットワークプロトコル上のIEEE国際会議（ICNP'08）、オーランド（フロリダ州）、USA、2008年10月の議事。
[Hollot01] Hollot, C., Misra, V., Towsley, D., and W.-B. Gong, "A Control Theoretic Analysis of RED", Proceedings of IEEE INFOCOM'01, Anchorage (Alaska), USA, April 2001.
【Hollot01] Hollot、C.、Misraの、V.、Towsley、D.、およびW.-B.ゴング、 "REDの制御理論解析"、IEEE INFOCOM'01、アンカレッジ（アラスカ州）、USA、2001年4月の議事。
[Jacobson88] Jacobson, V., "Congestion Avoidance and Control", Proceedings of ACM SIGCOMM'88 Symposium, August 1988.
[Jacobson88]ジェーコブソン、V.、 "輻輳回避とコントロール"、ACM SIGCOMM'88シンポジウム、1988年8月の議事。
[Jain88] Jain, R. and K. Ramakrishnan, "Congestion Avoidance in Computer Networks with a Connectionless Network Layer: Concepts, Goals, and Methodology", Proceedings of IEEE Computer Networking Symposium, Washington DC, USA, April 1988.
[Jain88]ジャイナ教、R.とK.ラマクリシュナン、「コネクションレスネットワーク層でのコンピュータネットワークにおける輻輳回避：コンセプト、目標、および方法論」、IEEEコンピュータネットワークシンポジウム、ワシントンDC、USA、1988年4月の議事。
[Jain90] Jain, R., "Congestion Control in Computer Networks: Trends and Issues", IEEE Network, pp. 24-30, May 1990.
[Jain90]ジャイナ教、R.、 "コンピュータネットワークにおける輻輳制御：動向と課題"、IEEEネットワーク、頁24-30、1990年5月。
[Jin04] Jin, Ch., Wei, D.X., and S. Low, "FAST TCP: Motivation, Architecture, Algorithms, Performance", Proceedings of IEEE INFOCOM'04, Hong-Kong, China, March 2004.
[Jin04]ジンのCh、魏、D.X.、およびS.ロー、 "FAST TCP：動機、アーキテクチャ、アルゴリズム、パフォーマンス"。、IEEE INFOCOM'04、香港、中国、2004年3月の議事。
[Jourjon08] Jourjon, G., Lochin, E., and P. Senac, "Design, Implementation and Evaluation of a QoS-aware Transport Protocol", Elsevier Computer Communications, Vol. 31, No. 9, pp. 1713-1722, June 2008.
[Jourjon08] Jourjon、G.、Lochin、E.、およびP. SENAC、 "QoS対応トランスポートプロトコルの設計、実装と評価"、エルゼビアコンピュータ通信、巻。 31、第9号、頁。1713年から1722年、2008年6月。
[Katabi02] Katabi, D., M. Handley, and C. Rohrs, "Internet Congestion Control for Future High Bandwidth-Delay Product Environments", Proceedings of ACM SIGCOMM'02 Symposium, August 2002.
[Katabi02] Katabi、D.、M.ハンドリー、およびC. Rohrs、 "将来の高帯域幅遅延製品の環境のためのインターネットの輻輳制御"、ACM SIGCOMM'02シンポジウム、2002年8月の議事。
[Katabi04] Katabi, D., "XCP Performance in the Presence of Malicious Flows", Proceedings of PFLDnet'04 Workshop, Argonne (Illinois), USA, February 2004.
[Katabi04] Katabi、D.、 "悪意のあるフローの存在下でのXCPの性能"、PFLDnet'04ワークショップ、アルゴンヌ（イリノイ州）、米国、2004年2月の議事。
[Kelly05] Kelly, F. and Th. Voice, "Stability of end-to-end algorithms for joint routing and rate control", ACM SIGCOMM Computer Communication Review, Vol. 35, No. 2, pp. 5-12, April 2005.
[Kelly05]ケリー、F.およびThが。声、「関節のルーティングおよびレート制御のためのエンドツーエンドのアルゴリズムの安定性」、ACM SIGCOMMコンピュータコミュニケーションレビュー、巻。 35、第2号、頁5-12、2005年4月。
[Kelly98] Kelly, F., Maulloo, A., and D. Tan, "Rate control in communication networks: shadow prices, proportional fairness, and stability", Journal of the Operational Research Society, Vol. 49, pp. 237-252, 1998.
「通信ネットワークにおけるレート制御：影の価格、プロポーショナルフェアネス、および安定性」[Kelly98]ケリー、F.、Maulloo、A.、およびD.タン、オペレーショナル・リサーチ学会誌、Vol。 49頁237から252、1998。
[Keshav07] Keshav, S., "What is congestion and what is congestion control", Presentation at IRTF ICCRG Workshop, PFLDnet 2007, Los Angeles (California), USA, February 2007.
[Keshav07] Keshav、S.は、 "渋滞は何で、輻輳制御するものである"、IRTF ICCRGワークショップ、PFLDnet 2007、ロサンゼルス（カリフォルニア州）、米国、2007年2月のプレゼンテーション。
[Key04] Key, P., Massoulie, L., Bain, A., and F. Kelly, "Fair Internet Traffic Integration: Network Flow Models and Analysis", Annales des Telecommunications, Vol. 59, No. 11-12, pp. 1338-1352, November-December 2004.
[Key04]キー、P.、Massoulie、L.、ベイン、A.、およびF.ケリー、 "フェアインターネットトラフィックの統合：ネットワークフローモデルと分析"、学派デテレコミュニケーション、巻。 59号11-12頁。1338年から1352年11月 - 2004年12月。
[Krishnan04] Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C., and M. Allman, "Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks", Computer Networks, Vol. 46, No. 3, October 2004.
"エラーが発生しやすい無線および衛星ネットワークのための明示的な輸送エラー通知（ETEN）" [Krishnan04]クリシュナン、R.、Sterbenz、J.、エディ、W.、ヤマウズラ、C.、およびM.オールマン、コンピュータネットワーク、巻。 46、第3号、2004年10月。
[Kuzmanovic03] Kuzmanovic, A. and E.W. Knightly, "TCP-LP: A Distributed Algorithm for Low Priority Data Transfer", Proceedings of IEEE INFOCOM'03, San Francisco (California), USA, April 2003.
[Kuzmanovic03] Kuzmanovic、A.及びE.W.騎士、 "TCP-LP：低優先度のデータ転送のための分散アルゴリズム"、IEEE INFOCOM'03、サンフランシスコ（カリフォルニア州）、米国、2003年4月の議事録。
[LEDBAT] IETF WG Action: Low Extra Delay Background Transport (ledbat).
[LEDBAT] IETF WGの処置：低余分な遅延の背景トランスポート（ledbat）。
[Lochin06] Lochin, E., Dairaine, L., and G. Jourjon, "Guaranteed TCP Friendly Rate Control (gTFRC) for DiffServ/AF Network", Work in Progress, August 2006.
[Lochin06] Lochin、E.、Dairaine、L.、およびG. Jourjonは、進捗状況、2006年8月ワーク "のDiffServ / AFネットワークのためのTCPフレンドリーレート制御（gTFRC）保証"。
[Lochin07] Lochin, E., Jourjon, G., and L. Dairaine, "Study and enhancement of DCCP over DiffServ Assured Forwarding class", 4th Conference on Universal Multiservice Networks (ECUMN 2007), Toulouse, France, February 2007.
[Lochin07] Lochin、E.、Jourjon、G.、およびL. Dairaine、 "DiffServの保証転送クラス以上の研究とDCCPの強化"、ユニバーサルマルチサービス・ネットワーク（ECUMN 2007）、トゥールーズ、フランス、2007年2月の第4回会議。
[Low02] Low, S., Paganini, F., Wang, J., Adlakha, S., and J.C. Doyle, "Dynamics of TCP/RED and a Scalable Control", Proceedings of IEEE INFOCOM'02, New York (New Jersey), 2002.
【Low02低、S.、パガニーニ、F.、王、J.、Adlakha、S.、およびJCドイル、 "TCP / REDとスケーラブルな制御のダイナミクス"、IEEE INFOCOM'02の議事録、ニューヨーク（新ジャージー）、2002。
[Low03.1] Low, S., "A duality model of TCP and queue management algorithms", IEEE/ACM Transactions on Networking, Vol. 11, No. 4, pp. 525-536, August 2003.
[Low03.1]低、S.、ネットワーキング、巻上のIEEE / ACMトランザクション「TCPおよびキュー管理アルゴリズムの双対モデル」。 11、第4号、頁525から536 2003年8月。
[Low03.2] Low, S., Paganini, F., Wang, J., and J. Doyle, "Linear stability of TCP/RED and a scalable control", Computer Networks Journal, Vol. 43, No. 5, pp. 633-647, December 2003.
[Low03.2]低、S.、パガニーニ、F.、王、J.、およびJ.ドイル、 "TCP / REDの線形安定性と拡張性の制御"、コンピュータネットワーク誌、巻。 43、第5号、頁633から647 2003年12月。
[Low05] Low, S., Andrew, L., and B. Wydrowski, "Understanding XCP: equilibrium and fairness", Proceedings of IEEE INFOCOM'05, Miami (Florida), USA, March 2005.
[Low05]低、S.、アンドリュー、L.、およびB. Wydrowski、 "理解XCP：均衡と公平性"、IEEE INFOCOM'05、マイアミ（フロリダ州）、USA、2005年3月の議事。
[MacK95] MacKie-Mason, J. and H. Varian, "Pricing Congestible Network Resources", IEEE Journal on Selected Areas in Communications, Advances in the Fundamentals of Networking, Vol. 13, No. 7, pp. 1141-1149, 1995.
【MacK95]マッキー・メイソン、J.及びH.バリアン、「Congestibleネットワークリソースの価格設定」、IEEEジャーナル通信における選択された領域に、ネットワーキング、VOLの基礎の進歩。 13、第7号、頁1141年から1149年、1995。
[Mascolo01] Mascolo, S., Casetti, Cl., Gerla M., Sanadidi, M.Y., and R. Wang, "TCP Westwood: Bandwidth estimation for enhanced transport over wireless links", Proceedings of MOBICOM 2001, Rome, Italy, July 2001.
[Mascolo01] Mascolo、S.、Casetti、Clで、Gerla M.、Sanadidi、MY、およびR.王、 "TCPのウエストウッド：無線リンク上で強化された輸送のための帯域幅の推定"。、MOBICOM 2001の議事録、ローマ、イタリア、7月2001。
[Moors02] Moors, T., "A critical review of "End-to-end arguments in system design"", Proceedings of IEEE International Conference on Communications (ICC) 2002, New York City (New Jersey), USA, April/May 2002.
[Moors02]ムーア、T.、システム設計におけるエンド・ツー・エンドの引数「『通信に関するIEEE国際会議の議事録（ICC）2002』の批判的検討」、ニューヨーク・シティ（ニュージャージー州）、USA、4月/ 2002年5月。
[MPTCP] IETF WG Action: Multipath TCP (mptcp).
[MPTCP] IETF WG処置：マルチTCP（MPTCP）。
[Noel07] Noel, E. and C. Johnson, "Initial Simulation Results That Analyze SIP Based VoIP Networks Under Overload", International Teletraffic Congress (ITC'07), Ottawa, Canada, June 2007.
[Noel07]ノエル、E.およびC.ジョンソン、「過負荷SIPベースのVoIPネットワークを分析し、初期シミュレーション結果」、国際トラヒック議会（ITC'07）、オタワ、カナダ、2007年6月。
[Padhye98] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, "Modeling TCP Throughput: A Simple Model and Its Empirical Validation", University of Massachusetts (UMass), CMPSCI Tech. Report TR98-008, February 1998.
【Padhye98] Padhye、J.、Firoiu、V.、Towsley、D.、およびJ.黒瀬、 "モデルTCPスループット：簡単なモデルとその経験的検証"、マサチューセッツ大学（UMass）、CMPSCIテック。レポートTR98-008、1998年2月。
[Pan00] Pan, R., Prabhakar, B., and K. Psounis, "CHOKe: a stateless AQM scheme for approximating fair bandwidth allocation", Proceedings of IEEE INFOCOM'00, Tel Aviv, Israel, March 2000.
[Pan00]パン、R.、Prabhakar、B.、およびK. Psounis、 "チョーク：公平な帯域幅の割り当てを近似するためのステートレスAQMスキーム"、IEEE INFOCOM'00、テルアビブ、イスラエル、2000年3月の議事。
[Pap02] Papadimitriou, I. and G. Mavromatis, "Stability of Congestion Control Algorithms using Control Theory with an application to XCP", Technical Report, 2002. <http://www.stanford.edu/class/ee384y/projects/ reports/ionnis.pdf>.
【Pap02] Papadimitriou、I.およびG. Mavromatis、「XCPのアプリケーションと制御理論を用いて、輻輳制御アルゴリズムの安定性」、技術報告、2002 <http://www.stanford.edu/class/ee384y/projects/レポート/ ionnis.pdf>。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、R.、およびD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1701]ハンクス、S.、李、T.、ファリナッチ、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 1701、1994年10月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、エド。、 "インターネットの建築原則"、RFC 1958、1996年6月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]マティス、M.、Mahdavi、J.、フロイド、S.、とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[RFC2208] Mankin, A., Ed., Baker, F., Braden, B., Bradner, S., O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997.
[RFC2208]マンキン、A.編、ベイカー、F.、ブレーデン、B.、ブラドナー、S.、オデル、M.、Romanow、A.、Weinrib、A.、およびL.チャン、「リソース予約プロトコル（RSVP） - バージョン1適用性に関する声明展開に関するいくつかのガイドライン」、RFC 2208、1997年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[RFC2637] Hamzeh、K.、ポール、G.、Verthein、W.、Taarud、J.、リトル、W.、およびG.ゾルン、 "ポイントツーポイントトンネリングプロトコル（PPTP）"、RFC 2637、2011 1999。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC2775]大工、B.、 "インターネットの透明性"、RFC 2775、2000年2月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861]ハンドレー、M.、Padhye、J.、およびS.フロイド、 "TCP輻輳ウィンドウ検証"、RFC 2861、2000年6月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[RFC2990]ヒューストン、G.、 "IP QoSのアーキテクチャーのための次のステップ"、RFC 2990、2000年11月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]グロスマン、D.、 "Diffservのための新しい用語と明確化"、RFC 3260、2002年4月。
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3517]ブラントン、E.、オールマン、M.、秋、K.、およびL.王は、 "保守的な選択的確認応答（SACK）はTCPのために損失回復アルゴリズムをベース"、RFC 3517、2003年4月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]春、N.、Wetherall、D.、およびD.イーリー、 "ロバスト明示的輻輳通知（ECN）ナンスとシグナリング"、RFC 3540、2003年6月。
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
[RFC3662]祝福、R.、ニコルズ、K.、およびK. Wehrleの、 "低級努力ドメイン単位の行動差別化サービスのための（PDB）"、RFC 3662、2003年12月。
[RFC3714] Floyd, S., Ed., and J. Kempf, Ed., "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[RFC3714]フロイド、S.、エド。、およびJ.ケンプ、エド。、 "インターネットでの音声トラフィックのための輻輳制御に関するIAB心配"、RFC 3714、2004年3月。
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large Congestion Windows", RFC 3742, March 2004.
[RFC3742]フロイド、S.、 "大混雑のWindowsとのTCPのための限定スロースタート"、RFC 3742、2004年3月。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]ブライアント、S.、エド。、およびP.パテ、エド。、 "疑似ワイヤーエミュレーション端から端まで（PWE3）アーキテクチャ"、RFC 3985、2005年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[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月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006.
[RFC4341]フロイド、S.、およびE.コーラー、 "データグラム輻輳制御プロトコル（DCCP）輻輳制御ID 2用のプロフィール：TCPのような輻輳制御"、RFC 4341、2006年3月。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006.
[RFC4342]フロイド、S.、コーラー、E.、およびJ. Padhye、 "データグラム混雑制御プロトコル（DCCP）輻輳制御ID 3のプロフィール：TCPフレンドリーレート制御（TFRC）"、RFC 4342、2006年3月。
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553] Vainshtein、A.編、及びYJ。スタイン、エド。、 "パケット（のSAToP）以上の構造に依存しない時分割多重（TDM）"、RFC 4553、2006年6月。
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006.
[RFC4614]デューク、M.、ブレーデン、R.、エディ、W.、及びE.ブラントン、RFC 4614、2006年9月 "伝送制御プロトコル（TCP）仕様書のためのロードマップ"。
[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月。
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007.
[RFC4828]フロイド、S.、およびE.コーラー、 "TCPフレンドリーレート制御（TFRC）：小パケット（SP）バリアント"、RFC 4828、2007年4月。
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007.
[RFC4948]アンデション、L.、デイヴィス、E.、およびL.チャン、 "不要なトラフィック月9-10、2006年IABワークショップからの報告書"、RFC 4948、2007年8月。
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion Control Algorithms", BCP 133, RFC 5033, August 2007.
[RFC5033]フロイド、S.とM.オールマン、 "新しい輻輳制御アルゴリズムの指定"、BCP 133、RFC 5033、2007年8月。
[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, December 2007.
[RFC5086] Vainshtein、A.編、Sasson、I.、メッツ、E.、フロスト、T.、およびP.パテ、「構造-Awareの時分割多重（TDM）回線エミュレーションサービスパケットネットワーク（のCESoPSNをスイッチの上に）」、RFC 5086、2007年12月。
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, December 2007.
[RFC5087]スタイン、Y（J）。、Shashoua、R.、Insler、R.、およびM. Anavi、 "IPオーバー時分割多重（のTDMoIP）"、RFC 5087、2007年12月。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008.
[RFC5129]デイビー、B.、ブリスコー、B.、およびJ.テイ、 "MPLSマーキング明示的輻輳"、RFC 5129、2008年1月。
[RFC5290] Floyd, S. and M. Allman, "Comments on the Usefulness of Simple Best-Effort Traffic", RFC 5290, July 2008.
[RFC5290]フロイド、S.とM.オールマン、「シンプルなベストエフォート型トラフィックの有用性に関するコメント」、RFC 5290、2008年7月。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[RFC5348]フロイド、S.、ハンドリー、M.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 5348、2008年9月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]エッゲルト、L.とG. Fairhurst、 "アプリケーションデザイナーのためのユニキャストUDPの使用上の注意事項"、BCP 145、RFC 5405、2008年11月。
[RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, August 2009.
[RFC5622]フロイド、S.、およびE.コーラー、 "データグラム輻輳制御プロトコル（DCCP）輻輳ID 4のためのプロフィール：小パケット用のTCPフレンドリーレート制御（TFRC-SP）"、RFC 5622、2009年8月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681 (Obsoletes RFC 2581), September 2009.
[RFC5681]オールマン、M.、パクソン、V.、およびE.ブラントン、 "TCP輻輳制御"、RFC 5681（以下を時代遅れにするRFC 2581）、2009年9月。
[RFC5783] Welzl, M. and W. Eddy, "Congestion Control in the RFC Series", RFC 5783, February 2010.
[RFC5783] Welzl、M.およびW.エディ、 "RFCシリーズにおける輻輳制御"、RFC 5783、2010年2月。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010.
[RFC6040]ブリスコウ、B.、 "明示的輻輳通知のトンネリング"、RFC 6040、2010年11月。
[Rossi06] Rossi, M., "Evaluating TCP with Corruption Notification in an IEEE 802.11 Wireless LAN", Master Thesis, University of Innsbruck, November 2006. Available from http://heim.ifi.uio.no/michawe/research/projects/ corruption/.
[Rossi06]ロッシ、M.は、http://heim.ifi.uio.no/michawe/research/からインスブルック、2006年11月の大学が利用できる、修士論文、「IEEE 802.11無線LANで破損通知とTCPの評価します」プロジェクト/破損/。
[Saltzer84] Saltzer, J., Reed, D., and D. Clark, "End-to-end arguments in system design", ACM Transactions on Computer Systems, Vol. 2, No. 4, November 1984.
[Saltzer84] Saltzer、J.、リード、D.、およびD.クラークは、「エンド・ツー・エンドのシステム設計では、引数」、コンピュータシステム、巻上のACMトランザクション。 2、第4号、1984年11月。
[Sarola02] Sarolahti, P. and A. Kuznetsov, "Congestion Control in Linux TCP", Proceedings of the USENIX Annual Technical Conference, 2002.
[Sarola02] Sarolahti、P.およびA.クズネツォフ、 "LinuxのTCPにおける輻輳制御"、USENIX年次技術会議議事録、2002年。
[Sarola07] Sarolahti, P., Floyd, S., and M. Kojo, "Transport-layer Considerations for Explicit Cross-layer Indications", Work in Progress, March 2007.
[Sarola07] Sarolahti、P.、フロイド、S.、およびM.古城、「明示的なクロスレイヤ適応のためのトランスポート層の考慮事項」、進歩、2007年3月に作業。
[Savage99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM SIGCOMM Computer Communication Review, 1999.
[Savage99]サベージ、S.、カードウェル、N.、Wetherall、D.、およびT.アンダーソン、 "ふらちなレシーバーとのTCP輻輳制御"、ACM SIGCOMMコンピュータコミュニケーションレビュー、1999。
[Shal10] Shalunov, S., Hazel, G., and J. Iyengar, "Low Extra Delay Background Transport (LEDBAT)", Work in Progress, October 2010.
【Shal10] Shalunov、S.、ヘーゼル、G.、およびJ.アイアンガー、 "低余分な遅延の背景トランスポート（LEDBAT）"、進歩、2010年10月ワーク。
[Shen08] Shen, C., Schulzrinne, H., and E. Nahum, "Session Initiation Protocol (SIP) Server Overload Control: Design and Evaluation, Principles", Systems and Applications of IP Telecommunications (IPTComm'08), Heidelberg, Germany, July 2008.
[Shen08]シェン、C.、Schulzrinneと、H.、およびE.ナホム、 "セッション開始プロトコル（SIP）サーバー過負荷制御：設計と評価、原則"、システムおよびIP通信（IPTComm'08）、ハイデルベルクの応用、ドイツ、2008年7月。
[Shin08] Shin, M., Chong, S., and I. Rhee, "Dual-Resource TCP/AQM for Processing-Constrained Networks", IEEE/ACM Transactions on Networking, Vol. 16, No. 2, pp. 435-449, April 2008.
[Shin08]伸、M.、チョン、S.、およびI.李承晩、 "デュアルリソースTCP / AQM処理-制約ネットワークの" ネットワーク上の、IEEE / ACM取引、巻。 16、第2号、頁435から449まで、2008年4月。
[Thaler07] Thaler, D., Sridharan, M., and D. Bansal, "Implementation Report on Experiences with Various TCP RFCs", Presentation to the IETF Transport Area, March 2007. <http://www.ietf.org/proceedings/07mar/ slides/tsvarea-3/>.
[Thaler07]ターラー、D.、Sridharan、M.、およびD. Bansal氏、 "様々なTCPのRFCとの経験上の実施報告"、IETF交通エリアへのプレゼンテーション、2007年3月<http://www.ietf.org/議事録/ 07mar /スライド/ tsvarea-3 />。
[Tickoo05] Tickoo, O., Subramanian, V., Kalyanaraman, S., and K.K. Ramakrishnan, "LT-TCP: End-to-End Framework to Improve TCP Performance over Networks with Lossy Channels", Proceedings of International Workshop on QoS (IWQoS), Passau, Germany, June 2005.
【Tickoo05] Tickoo、O.、スブラマニアン、V.、Kalyanaraman、S.、およびK.K.ラマクリシュナン、「LT-TCP：エンドツーエンドのフレームワークロッシーチャンネルでネットワーク上のTCPのパフォーマンスを向上させる」、国際QoSのワークショップ（IWQoS）、パッサウ、ドイツ、2005年6月の議事。
[TRILOGY] "Trilogy Project", European Commission Seventh Framework Program (FP7), Grant No: 216372, <http://www.trilogy-project.org>.
[TRILOGY] "トリロジープロジェクト"、欧州委員会セブンス枠組み計画（FP7）、グラント番号：216372、<http://www.trilogy-project.org>。
[Vinnic02] Vinnicombe, G., "On the stability of networks operating TCP-like congestion control," Proceedings of IFAC World Congress, Barcelona, Spain, 2002.
[Vinnic02] Vinnicombe、G.、 "TCP-のような輻輳制御を動作するネットワークの安定性に、" IFAC世界会議、バルセロナ、スペイン、2002年の議事。
[Welzl03] Welzl, M., "Scalable Performance Signalling and Congestion Avoidance", Springer (ISBN 1-4020-7570-7), September 2003.
[Welzl03] Welzl、M.、 "スケーラブルなパフォーマンスシグナリングおよび輻輳回避"、スプリンガー（ISBN 1-4020-7570-7）、2003年9月。
[Welzl08] Welzl, M., Rossi, M., Fumagalli, A., and M. Tacca, "TCP/IP over IEEE 802.11b WLAN: the Challenge of Harnessing Known-Corrupt Data", Proceedings of IEEE International Conference on Communications (ICC) 2008, Beijing, China, May 2008.
[Welzl08] Welzl、M.、ロッシ、M.、フマガリ、A.、およびM. Tacca、 "TCP / IPは、IEEE 802.11bの無線LAN経由：データ破損既知の活用への挑戦"、通信に関するIEEE国際会議の議事録（ICC）2008、北京、中国、2008年5月。
[Xia05] Xia, Y., Subramanian, L., Stoica, I., and S. Kalyanaraman, "One more bit is enough", ACM SIGCOMM Computer Communication Review, Vol. 35, No. 4, pp. 37-48, 2005.
[Xia05]夏、Y.、サブラマニアン、L.、ストイカ、I.、およびS・カリヤナラーマン、ACM SIGCOMMコンピュータコミュニケーションレビュー、集 "もう一つのビットが十分にあります"。 35、第4号、PP。37-48、2005。
[Zhang03] Zhang, H., Towsley, D., Hollot, C., and V. Misra, "A Self-Tuning Structure for Adaptation in TCP/AQM Networks", Proceedings of ACM SIGMETRICS'03 Conference, San Diego (California), USA, June 2003.
、ACM SIGMETRICS'03会議の議事録、サンディエゴ（カリフォルニア州 "TCP / AQMネットワークにおける適応のためのセルフチューニング構造" [Zhang03]チャン、H.、Towsley、D.、Hollot、C.、およびV.ミスラ、 ）、USA、2003年6月。
The authors would like to thank the following people whose feedback and comments contributed to this document: Keith Moore, Jan Vandenabeele, and Larry Dunn (his comments at the Manchester ICCRG and discussions with him helped with the section on packet-congestibility).
キース・ムーア、ヤンVandenabeele、そしてラリー・ダン（マンチェスターICCRGと彼との議論で彼のコメントは、パケットcongestibility上のセクションを手伝ってくれました）：著者は、そのフィードバックやコメント、この文書に貢献した以下の方々に感謝したいと思います。
Dimitri Papadimitriou's contribution was partly funded by [ECODE], a Seventh Framework Program (FP7) research project sponsored by the European Commission.
ディミトリPapadimitriouの貢献は、部分的に[ECODE]、欧州委員会が主催する第七次フレームワーク・プログラム（FP7）の研究プロジェクトによって資金を供給されました。
Bob Briscoe's contribution was partly funded by [TRILOGY], a research project supported by the European Commission.
ボブ・ブリスコーの貢献は、部分的に[TRILOGY]、欧州委員会でサポートされている研究プロジェクトによって資金を供給されました。
Michael Scharf is now with Alcatel-Lucent.
マイケル・シャーフは、アルカテル・ルーセントとなりました。
The following additional people have contributed to this document:
次の追加の人々は、この文書に貢献しています：
- Wesley Eddy <weddy@grc.nasa.gov>
- ウェズリーエディ<weddy@grc.nasa.gov>
- Bela Berde <bela.berde@gmx.de>
- ベラBerde <bela.berde@gmx.de>
- Paulo Loureiro <loureiro.pjg@gmail.com>
- パウロLOUREIRO <loureiro.pjg@gmail.com>
- Chris Christou <christou_chris@bah.com>
- クリスChristouの<christou_chris@bah.com>
Authors' Addresses
著者のアドレス
Dimitri Papadimitriou (editor) Alcatel-Lucent Copernicuslaan, 50 2018 Antwerpen, Belgium
ディミトリPapadimitriou（編集者）アルカテル・Lykent Kopernikoslaan、50 2018アントワープ、Velgiom
Phone: +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel-lucent.com
電話：+32 3 240 8491 Eメール：dimitri.papadimitriou@alcatel-lucent.com
Michael Welzl University of Oslo, Department of Informatics PO Box 1080 Blindern N-0316 Oslo, Norway
オスロのマイケルWelzl大学、学部情報の私書箱1080 Blindern N-0316オスロ、ノルウェー
EMail: michawe@ifi.uio.no
メールアドレス：michawe@ifi.uio.no
Michael Scharf University of Stuttgart Pfaffenwaldring 47 70569 Stuttgart, Germany
シュトゥットガルトPfaffenwaldring 47 70569シュトゥットガルト、ドイツのマイケル・シャーフ大学
EMail: michael.scharf@googlemail.com
メールアドレス：michael.scharf@googlemail.com
Bob Briscoe BT & UCL B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE, UK
ボブ・ブリスコーBT＆UCL B54 / 77、Adastral公園MartleshamヒースイプスウィッチIP5 3RE、英国
EMail: bob.briscoe@bt.com
メールアドレス：bob.briscoe@bt.com