[要約] RFC 6077は、インターネットの過負荷制御に関するオープンな研究課題をまとめたものであり、その目的は、現在の制御手法の課題を特定し、将来の研究や改善に向けた方向性を提供することです。
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.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネットリサーチタスクフォース（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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年のVan Jacobsonの研究以来、混雑制御はTCPに関連していますが、TCP以外の混雑制御もあります（例：リアルタイムマルチメディアアプリケーション、マルチキャスト、およびルーターベースのメカニズムなど）[RFC5783]。Van Jacobson End-to-Endの混雑制御アルゴリズム[Jacobson88] [RFC2581] [RFC5681]は、インターネット輸送プロトコルTCP [RFC4614]によって使用されます。彼らは長年にわたって非常に成功していることが証明されていますが、一方ではデータリンクと物理層の不均一性と他方のアプリケーションの不均一性が、その自然な動作を超えてTCPの混雑制御を引き出しているため、彼らの限界に達し始めました政権。これは、帯域幅または遅延が増加するにつれてパフォーマンスが低下するためです。これらの欠陥の副作用は、ホストのシェアの増加が非標準化された混雑制御強化を使用することです（たとえば、多くのLinux分布は、デフォルトのTCP輻輳制御メカニズムとして「キュービック」[HA08]に出荷されています）。
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.
元のVan Jacobson Algorithmでは、ルーターで混雑関連状態を必要としませんが、最近の修正は、混雑の崩壊を避けるために、エンドツーエンドの原則[Saltzer84]の厳密な適用から逸脱しています。ルーターのアクティブキュー管理（AQM）、たとえば赤や適応型赤などのバリアントの一部は、キューを小さく保つことでパフォーマンスを向上させます（ドロップされたパケットを介した暗黙のフィードバック）、明示的な混雑通知（ECN）[FLOYD94] [FLOYD94] [FLOYD94] [FLOYD94] [RFC3168]は、AQMが通常パケットをドロップすると、1つの混雑情報を送信者に渡します。加重赤（脚付き）や赤と/out（rio）[clark98]など、AQM上に構築された赤の他のバリエーションは質の高い施行であり、安定した赤（SRED）、チョーク[PAN00]はXchoke [Chhabra02]などの拡張機能はフローポリサーです。[Bonald00]では、著者は赤い性能を分析的に評価しました。
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.2]、[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ネットワークが含まれます。その結果、多種多様なリンクとパスの特性が生じます。高速光リンクには豊富な供給がある可能性があります（1秒あたり数ギガビット）。遅延に関して、シナリオは、ローカルの相互接続（ミリ秒未満）から特定のワイヤレスおよび衛星リンクまで、非常に大きなレイテンシと1秒以上）までの範囲です。さらに高いレイテンシは、宇宙通信で発生する可能性があります。結果として、インターネットでの利用可能な帯域幅とエンドツーエンドの遅延の両方が多くの桁で変化する可能性があり、パラメーターの範囲が将来さらに増加する可能性があります。
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.
混雑制御アルゴリズムは、この多様性を効率的で安定した方法で処理する必要があります。Van Jacobsonによって導入された混雑制御原則は、かなり静的なシナリオを想定しており、帯域幅遅延製品がせいぜい数十のパケットのオーダーである構成を暗黙的にターゲットにしています。これらの原則は、ほぼ20年にわたってインターネットで機能することが証明されていますが、はるかに大きな帯域幅遅延製品とダイナミクスの増加がますますそれらに挑戦しています。今日の輻輳制御アルゴリズムが最適ではない方法で反応し、とりわけ低リソースの利用が得られる多くの状況があります。
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]と1つのリソースを共有する2つのコントローラーの単純なベクトルベースの分析に基づいています。また、コントロールが「定常状態」に達すると、パケットがネットワークを離れたときにネットワークにパケットを送信することにより、いつでも飛行中に等量のパケットを維持しようとする「パケットの保存原則」は送信者に到着する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に依存する限り、RTTに依存しないレートに収束することができます（例：高速TCP [JIN04]）。
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.
それに比べて、Max-Min、比例、TCPの公平性の議論は、ほぼ単なる詳細です。これら3つはすべて、等しい流量が望ましいという仮定を共有しています。それらは、多くのボトルネックのネットワークで過剰な容量を共有する方法の2次問題に単に異なります。対照的に、コストの公平性は、設計により非常に不平等な流量につながるはずです。同等に、等しい流量は通常、非常に不公平と見なされます。
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])?
- ターゲットの流量はRTT（TCPのように）に依存する必要がありますか、それともフローダイナミクスのみがRTT（たとえば、高速TCP [JIN04]のように）に依存する必要がありますか？
- 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?
- 瞬間的な混雑に対する1つのアプリケーションの感度は、競合するアプリケーションの長期的な説明責任によって本当に保護できますか？
- Which protocol mechanism(s) are needed to give accountability for causing congestion?
- 混雑を引き起こすために説明責任を与えるために必要なプロトコルメカニズムはどれですか？
- 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?
- 重量に対するアプリケーションポリシー制御を追加して、1つまたは2つの加重トランスポートプロトコル（TCP、UDPなど）をどのように設計できますか？
- 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.
この課題は、おそらく正しくなるために最も重要なものです。エンドポイントとネットワーク機器の間の機能のバランスの変更には、トランスポートレイヤーとネットワークレイヤー間のダタグラムごとのデータプレーンインターフェイスの変更が必要になる場合があります。ネットワーク機器ベンダーは、ファームウェアとハードウェアに組み込むのに十分な（10年のタイムスケールで）新しいインターフェイスが十分に安定していることを保証する必要があり、オペレーティングシステムベンダーは、広く展開されない場合を除き、新しいインターフェイスを使用しません。
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、青、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.
アプローチの2番目のクラスでは、明示的なシグナリングを使用します。ネットワークからの明示的なフィードバックを使用することにより、接続エンドポイントは、パス上の現在のネットワーク特性に関するより正確な情報を取得できます。これにより、エンドポイントは、混雑をよりよく制御できるより正確な決定を下すことができます。
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はまだ研究の対象となります。[Andrew05]が指摘しているように、XCPは局所的に安定していますが、流れの最大RTTが平均RTTよりもはるかに大きい場合は世界的に不安定です。この不安定性は、推定間隔の更新戦略を変更することで削除できますが、これにより、システムは誤った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はフロー完了時間の短縮[Dukki06]に焦点を当て、次のRTTに到着する可能性が高いフローに楽観的なアプローチをとり、より大きな瞬間キューサイズ[Dukki05]を許容します。一方、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].
インターネットの重要な設計原則の1つであるエンドツーエンドの引数[Saltzer84]のコンテキストでは、暗黙的および明示的なルーターの両方のサポートを考慮する必要があります。最終システムとネットワークで実現できる機能は、エンドシステムに実装する必要があることを示唆しています。この原則により、ネットワークが一般的なサービスを提供し、可能な限り単純なままであることが保証されます（追加の複雑さは、IPレイヤーの上に、つまりエッジに配置されます）。さらに、Fate-Sharingの原則（[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）レートを宣言したときに嘘をつかないソース。iii）フィードバックに応じてレートを設定するときにチートしないソース[katabi04]。
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.
新しいプロトコル構造が見つかったとしても、ネットワークごとの流量命令が実際の流量の変動と比較する必要があるため、ネットワークフロー状態を回避できる可能性は低いようです。。これらの問題は、1997年に統合サービス（INTSERV）が無視できないと特定されて以来、顕著です[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?
- ネットワーク要素は、エンドツーエンドのメカニズムを損傷したり影響を与えたりすることなく、インターネットに存在するコミュニケーションシナリオの完全な範囲のパフォーマンスを理論的に改善できますか？
- 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.
ネットワークエンティティの関与に関して、ネットワーク管理手順のいくつかの追加機能から、ソリューションスペースのもう一方の端のパケットごとの追加処理まで、いくつかの自由度があります。さらに、さまざまな量の状態をルーターに保持できます（流量あたりの状態、部分的な流量状態、ソフトステート、またはハードステート）。追加のルーター処理は、インターネットのスケーラビリティにとって課題であり、エンドツーエンドのレイテンシを増加させる可能性もあります。
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.
混雑制御をサポートするために、ネットワークコンポーネントは、次の情報の少なくともサブセットを取得する必要があります。その情報を取得すると、複雑なタスクが発生する可能性があります。
1. Capacity of (outgoing) links
1. （発信）リンクの容量
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-in-IPトンネル[RFC2003]、IPSECトンネル[RFC4301]、レイヤー2トンネリングプロトコル（L2TP）[RFC2661]にカプセル化されたIPを使用すると、難易度が発生します。ポイントツーポイントトンネルプロトコル（PPTP）[RFC2637]、またはマルチプロトコルラベルスイッチング（MPLS）[RFC3031] [RFC3032]。これらの場合、リンク情報はクロスレイヤー情報交換によって決定できますが、これにはリンクレイヤーテクノロジー固有の情報を処理できるインターフェイスが必要です。別の方法はオンライン測定値ですが、これにより、かなりの追加ネットワークオーバーヘッドを引き起こす可能性があります。これは、オンライントラフィック測定が（実行時に）許容される場合、どれだけの場合、どれだけの量の研究の質問です。明示的な混雑情報のカプセル化と脱カプセル化は、IP-in-IPトンネリング[RFC6040]およびMPLS-in-MPLSまたはMPLS-in-IP [RFC5129]に指定されています。
2. Traffic carried over (outgoing) links
2. トラフィックが持ち越された（発信）リンク
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.
トラフィックが破裂した場合、データレートの正確なオンライン測定は困難です。たとえば、「電流リンク負荷」を測定するには、適切な測定間隔 /サンプリング間隔を定義する必要があります。これは、現在のリンク利用に関する知識を必要とする提案の課題です。
3. Internal buffer statistics
3. 内部バッファー統計
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 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.
ワイヤレスおよび衛星上のTCPは、長い間調査されてきたトピックです[Krishnan04]。混雑制御メカニズムが腐敗の存在下でパケットがドロップされていないかのように反応するいくつかの提案があります（TCPハック[Balan01]を参照）が、IETFでの議論は示しています（たとえば、例えば、議論を参照してください。2003年4月にデータグラムの混雑制御プロトコル（DCCP）ワーキンググループリストhttp://www.ietf.org/mail-archive/web/dccp/current/mail6.html）適切です。たとえば、混雑は共有ワイヤレスリンクの破損として自分自身を明らかにする可能性があると言われています。また、リンクノイズによって継続的に損なわれているパケットを送信するソースが、の完全性が失われたため、高いレートで送信し続けるかどうかは疑問です。フィードバックループ。
Generally, two questions must be addressed when designing a congestion control mechanism that takes corruption loss into account:
一般的に、腐敗の損失を考慮に入れる混雑制御メカニズムを設計する際には、2つの質問に対処する必要があります。
1. How is corruption detected?
1. 腐敗はどのように検出されますか？
2. What should be the reaction?
2. 反応は何ですか？
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について説明するのとほぼ同じ方法で、暗黙の検出を考慮することができます。リンク層は、誤ったフレームを再送信することがあります。 - 増加するまでの遅延 - しかし、輸送層の送信者の観点からは、そのような効果には他にも多くの考えられる理由があります。
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.
ヘッダーチェックサムは、別の暗黙の検出の可能性を提供します。チェックサムが必要なヘッダーフィールドのすべてをカバーし、このチェックサムにエラーが表示されない場合、2番目のチェックサムを使用してペイロードにエラーが見つかる可能性があります。このようなエラー検出は、UDP-LiteおよびDCCPで可能です。研究[Chester04]で一般的なパケットラジオサービス（GPRS）ネットワークを介してうまく機能し、別の研究[Rossi06] [welzl08]でWiFiネットワーク上でうまく機能することがわかりました。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 Westwood [Mascolo01]は、3つのデュパックまたはタイムアウトに応答して、うっ血時に測定された帯域幅に等しい輻輳ウィンドウを設定します。この測定は、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対応のフローは、損失エピソードに関する明示的な混雑通知の欠如による腐敗によるものでなければならないと推測できますか？または、パス上のすべてのキューが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.
TCPは、損失またはECNに応答する際にパケットサイズを考慮しません。過去数年にわたり、TCP混雑回避アルゴリズムのパフォーマンスが広範囲に研究されてきました。よく知られている「平方根式」は、TCP RENO [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
Cは定数sですsはTCPセグメントサイズ（バイト単位）ですRTTはTCP接続のエンドツーエンドの往復時間（秒単位）です。Pはパケットドロップ確率です
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.
データグラムの混雑制御プロトコル（DCCP）[RFC4340]の状況はすでに異なります。これは、信頼できないが輻輳制御されたデータグラム伝送を可能にし、TCPに関連する任意の遅延を回避するように設計されています。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は、うっ血制御識別子（CCID）を使用して、輻輳制御メカニズムを指定します。現在、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は、TCPの混雑制御の密接な近似を使用してデータを送信し、選択的承認のバリアント（SACK）[RFC2018] [RFC3517]を組み込みます。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スモールパケット（TFRC-SP）[RFC4828]は、小さなパケットを交換するアプリケーション向けに設計されています。TFRC-SPの目的は、最大1500バイトのパケットを使用してTCPフローと同じ帯域幅を1秒あたりビットで達成することです。TFRC-SPは、データパケット間の10 msの最小間隔を強制し、単一のフローが小さなパケットが頻繁に頻繁に送信するのを防ぎます。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 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.
ただし、現実的な機器は、多くの場合、すべての最小サイズのパケットの最悪のシナリオではなく、ミックスにいくつかの大きなパケットを備えた、ほぼWorstケースのワークロードにのみ対処するように設計されています。この場合、x = r*（h e）eのわずかな値の場合。したがって、パケットの混雑は、小さなパケットの実行では不可能ではありません（たとえば、TCP ACKまたはTCP Synsまたは小さな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）、その問題が解決された場合、さらに開かれた問題は、上記のすべての損失の原因を区別するソリューションを標準化するかどうかです。。
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ソリューションがインターネット全体のあらゆるうなリソースに展開されていると想定することはできません。ファイアウォール、プロキシ、サーバーなどのデバイス。ローエンドのハブ、DSLAMS、ワイヤレス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.
上記の推奨事項が正しい場合 - 輸送が書かれたときに、ネットワークが書くときではなく通知が読み取られたときに混雑通知のパケットサイズを考慮する必要があるということは、プロトコルエンジニアリングと再設計の重大な問題を開きます。実際、TCPは、損失またはECNに応答する際にパケットサイズを考慮していません。現在、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.
新しい混雑制御プロトコルの標準化を続けているため、パケットサイズをどのように説明するかという問題に直面する必要があります。Packetサイズを考慮しないで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.
Van Jacobson [Jacobson88]は、フロースタートアップとフロー再起動の両方にスロースタートメカニズムを使用することを提案しました。これは今日の標準ソリューション[RFC2581] [RFC5681]です。[RFC5681]ごとに、スロースタートアルゴリズムは、渋滞ウィンドウ（CWND）<スロースタートしきい値（SSTHRESH）の場合に使用されます。混雑に応じて。スロースタート中、TCPは、受信した各ACKの最大の送信者最大セグメントサイズ（MSS）バイトでCWNDを累積的に累積的に認めていることを累積的に認めます。Slow-Startは、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 Acksを使用してその情報をフィードバックすると、ホストが送信速度を再調整できるため、ネットワークを効率的に使用することが促進されます。IPでは、ECNは（前者）IPv4タイプのサービス（TOS）Octetまたは（前）IPv6トラフィッククラスOctet [RFC2474] [RFC3260]の2つの最も有意なビットを使用します。さらに、TCPのECNは、以前に予約されたものとして定義されていたTCPヘッダーの2つのビットを使用します[RFC793]。
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]は、ネットワークからホストへの混雑フィードバックメカニズムの例です。ただし、混雑ベースのフィードバックスキームには、ドメイン間ベースで適用されると制限があります。実際、[RFC3168]のセクション8および19は、2つの可能な攻撃の意味を詳しく説明しています。
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. Subversion：ECN対応のトランスポート（not-ect）を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
これらの問題はどちらも、たとえ輸送が正しく動作していても、攻撃ネットワークが上流のネットワークで過剰な混雑を引き起こす可能性があります。コンプライアンス違反の問題に対する2つの可能な解決策（上記の番号1）があります。ECN-Nonce [RFC3540]とReeCNインセンティブシステムに触発された[Conex]ワークアイテム
[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の場合よりも影響を与える可能性があることを意味する問題です。
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は、マークされたフラグメントを隠す誤動作レシーバーから保護することはできません。したがって、Path MTU発見が無効になっている状況では、ある程度の保護が失われます。また、ECN-Nonceは、定義上、非接続パケットはECN対応のないソースから来ているため、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.
それにもかかわらず、これらの問題の程度を判断するには、運用/展開の経験が必要です。2番目の問題は、主に展開と使用法に関連しており、特定の研究課題にはなりないようです。
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).
マルチドメイン環境におけるもう1つの物議を醸すソリューションは、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 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).
インターネット間操作の将来の進化は、より多くのマルチドメイン情報交換を効果的に実現できるかどうかを示す必要があります。これは、明示的なダタグラムごとのレートフィードバック（RCPやXCPなど）を使用する輻輳制御スキームまたは帯域内輻輳シグナル伝達（クイックスタートなど）または帯域外の明示的なレートフィードバックを使用する渋滞制御スキームにとって特に重要です。シグナル伝達（例：CADPC/PTP）。ローカルドメイントリガーをもたらすドメイン間レベルでの明示的なシグナリング交換は現在、インターネットには存在しません。この観点から、異なる管理ユニット間の限られた信頼に起因するセキュリティの問題により、明示的なフィードバックの混雑制御情報がドメイン間で交換されると遭遇する困難を悪化させる政策執行が生じます。この目的のために認証メカニズムを拡張できるにもかかわらず（RCPやXCPなどの明示的なレートスキームには、ドメイン間のセキュリティ要件と構造がINTSERVと同じであることを認識することにより）、[RFC2208で特定された同じスケーラビリティの問題に苦しんでいることに注意してください。]。実際、帯域内のレートシグナル伝達またはフローごとのトラフィック仕様シグナリング（リソース予約プロトコル（RSVP）など）は、同様のスケーラビリティの問題をもたらします（セクション3.1を参照）。
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).
複数のドメインで擬似動物を拡張すると、特定の問題が発生します。Pseudowires（PWS）[RFC3985]は、マルチドメインIPネットワークで非TCPデータフロー（時間分割マルチプレックス（TDM）トラフィックまたは一定ビットレート（CBR）ATMトラフィック）を運ぶことができます。パケット（SATOP）[RFC4553]、パケットスイッチネットワーク上の回路エミュレーションサービス（CESOPSN）[RFC5086]、およびTDM over IP（TDMOIP）[RFC5087]を介した構造 - 存在するTDM [RFC4553]、[RFC2914]で議論されている混雑コントロールには反応しません（RFC2914]（[RFC5033]も参照してください。同じ観察結果は、Packet Switched Network（PSN）を介してCBR機器（例：プライベートブランチ交換（PBX））を相互接続するATM回路エミュレーションサービス（CESS）に当てはまります。
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は、そのようなトラフィックを速度制限しています。Transit Provider P2を備えたプロバイダーP1のサービスレベル契約（SLA）は、後者が交通パターンを想定し、分布が一般的な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.
Transit Provider P2には問題が発生します。なぜなら、IPパケットが唯一の有用な混雑制御メカニズムが暗黙的または明示的な登録制御に依存する一定のビットレートサービストラフィックを運んでいることを検出できないため、セルフブロッキングまたは強制ブロッキングを意味する、 それぞれ。
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.
P1プロバイダーがレート制限であると仮定すると、すべてのTDM PWSが同じルーターを通過するため、トランジットP2プロバイダールーターRは深刻な混雑の影響を受ける可能性があります。TCPに優しいトラフィック（たとえば、別のPW内の各フロー）は、各パケットドロップに応じて、送信率を半分に減らすというTCPのAIMDアルゴリズムに従います。それにもかかわらず、TDMトラフィックを運ぶPWSは利用可能なすべての容量をとる可能性がありますが、他のTCPフレンドリーまたは一般的に渋滞に応じたトラフィックは何も減少しませんでした。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やインスタントメッシングトラフィックなどの短命の弾性トラフィック、および[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]の相互作用は最近までreddされていないことを指摘しています。
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/Assured Forwarding（AF）クラスでのユニキャストフローのスループット保証を提供するTCPフレンドリーレート制御の適応です。GTFRCの目的は、保証された部分をAF条件付けに起因するトラフィックの最良の部分と区別することです。提案された輻輳制御は、DIFFSERV/AFネットワーク[lochin07] [Jourjon08]の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キャッシュと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番目のアプローチが一般的になる可能性があります。ただし、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は、準拠した送信者をそのレシーバーに過剰なネットワークおよび/またはサーバーリソースを割り当てることに混乱させる可能性のあるTCPレシーバーの誤動作に特に焦点を当てています（例：[Savage99]、[RFC3540]）。しかし、そのような戦略は心配そうに強力ですが、それらはまだ一般的ではないようです（ただし、攻撃の有病率の証拠はそれ自体が研究要件です）。
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.
RTTを測定するためのさまざまな手法があります。アクティブ測定では、特別なプローブパケットをネットワークに注入し、ICMPを使用して応答時間を測定します。対照的に、パッシブ測定は、追加のパケットを送信することなく、進行中の通信プロセスから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などの輸送プロトコルの接続エンドポイント、およびいくつかのアプリケーションプロトコルは、RTTを追跡して、再送信タイムアウト（RTO）やなどのプロトコルパラメーターを動的に調整するために追跡します。レート制御方程式。彼らは、データの送信と対応する謝辞の到着との間の時差を観察することにより、送信者側のRTTを暗黙的に測定できます。TCPの場合、これはデフォルトのRTT測定手順です。カーンのアルゴリズムと組み合わせて使用され、再送信セグメント[RFC2988]からのRTT測定を禁止しています。従来、TCPの実装は、一度に1つのRTT測定値を取得します（つまり、RTTごとに約1回）。別の方法として、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.
この変動により、1つの測定されたRTT値では、パスを特徴付けるのに十分ではありません。これが、多くのプロトコルが平均値を導き出し、以前のサンプルの特定の履歴を追跡するRTT推定器を使用する理由です。たとえば、TCPエンドポイントは、指数関数的な重みの移動平均[RFC2988]から滑らかな往復時間（SRTT）を導き出します。このようなローパスフィルターは、測定ノイズと単一の外れ値が推定RTTに大きな影響を与えないことを保証します。それでも、ローパスフィルターの根本的な欠点は、平均値が測定されたRTTの突然の変化に対してよりゆっくりと反応することです。この効果を克服するためのさまざまなソリューションがあります。たとえば、標準のTCP再送信タイムアウト計算は、SRTTだけでなく、RTT測定の変動性の尺度も考慮します[RFC2988]。このアルゴリズムは、タイムスタンプを使用した頻繁なRTT測定にはあまり適していないため、特定の実装により重み係数が変更されます（[Sarola02]）。また、主にピーク値を利用するKalmanフィルターや推定器など、より洗練された推定器の提案もあります。
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）のフィールドを維持しています。新しい動作をサポートするノードは、両方のTTLフィールドを更新しますが、レガシーIPノードはIP TTLフィールドのみを更新します。これにより、エンドポイントは、パス上のすべてのIPノードが新しい動作をサポートするかどうかを確認できます。この場合、両方のTTLが受信機で等しくなります。しかし、これらのようなメカニズムは、新しい動作をサポートしない可能性のある下層のノードを見落としています。
A further related issue is congestion control across overlay networks of relays [Hilt08] [Noel07] [Shen08].
さらに関連する問題は、リレーのオーバーレイネットワーク全体の混雑制御[HILT08] [NOEL07] [SHEN08]です。
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).
セクション3.5.3では、非弾性マルチドメイン擬似動物（PWS）を扱っています。ここでは、擬似ワイヤ自体のアイデンティティ自体が、マルチドメインPSNを横切るトラフィックの特性を意味します（PWで運ばれるトラフィックの実際の特性とは無関係です）。イーサネットフレームにカプセル化されたトラフィックのプロパティを特徴付ける手段がエッジにない擬似ワイヤの一部（例えば、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は、MultiPath TCP [MPTCP]の作業項目を開始しました。すべてのパスにリソースをプールすることにより、複数のパスを使用していないノードでさえ、そのパスから恩恵を受けます。
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].
この分野では、特にネットワークオペレーター制御ルートプロビジョニングとトラフィックエンジニアリングとの相互作用を理解するために、かなりの研究があります。。
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.
アプリケーションレイヤーゲートウェイ（アルグ）、ミドルボックス、およびプロキシの数が増えている（[RFC2775]のセクション3.6を参照）は、適合性を確認するだけでなく、トラフィックとコントロールフローをフィルタリングするだけでなく、ドメイン境界に展開されます。1つの動機は、自律システム間でデータを漏らしているルーティングを超えて情報を防ぐことです。これらのシステムは、エンドツーエンドの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.
基本的に、このようなシステムは、原始および二重輻輳制御コンポーネントを破壊します。特に、エンドツーエンドの混雑制御は、分割接続のフローコントロールバックプレッシャーメカニズムに置き換えることができます。多種多様なアルグとミドルボックスは、そのようなメカニズムを使用して、アプリケーションのパフォーマンスを改善します（パフォーマンスのプロキシ、アプリケーションアクセラレータなど）。しかし、しばしば独自であり、文書化されていないこのようなメカニズムの意味は、これまで体系的に研究されていません。
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.
不正行為は純粋な悪意によって駆動される可能性があります。または、悪意が順番に、より広範な利己的な利益によって駆動される場合があります。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]、彼らは自然にネットワークに対するサービスの拒否を軽減するでしょう。制御施行の問題。（ネットワークではなく）ホストに対するサービス拒否攻撃でさえ、高層での混雑制御執行の問題と見なすことができます。しかし、明らかに、混雑制御を強制することによって解決されないサービス拒否攻撃もあります。
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] Allman、M。and V. Paxson、「エンドツーエンドのネットワークパスプロパティの推定について」、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] Andrew、L.、Wydrowski、B。、およびS. Low、「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.、Briscoe、B.、Eggert、L.、Feldmann、A。、およびM. Handley、 "Dagstuhl Perspectives Workshop future Internetのエンドツーエンドプロトコルに関するワークショップ、ACM Sigcomm Computer Communication Review、Vol。39、No。2、pp。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.、Low、S.、Li、V。、およびQ. Yin、「Rem：Active Keue Management」、IEEE Network Magazine、Vol。15、No。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] Balan、R.K.、Lee、B.P.、Kumar、K.R.R.、Jacob、L.、Seah、W.K.G。、およびA.L. Ananda、「TCP Hack：TCP Header Checksumオプション」、アンカレッジ（アラスカ）、米国、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] Bonald、T.、May、M。、およびJ.-C。Bolot、「Red Performanceの分析評価」、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] Briscoe、B。、「自己利益を使用して悪意を防ぐ;インターネットのサービス拒否の欠陥の修正」、情報インフラストラクチャの保護の経済学に関するワークショップ、2006年10月、<http：//wesii.econinfosec。org/drawt.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] Briscoe、B。、「流量の公平性：宗教の解体」、ACM Sigcomm Computer Communication Review、Vol。37、No。2、pp。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] Briscoe、B.、Moncaster、T。and L. Burness、「問題声明：輸送プロトコルは公平性を行う必要はありません」、2008年7月の作業。
[Bri09] Briscoe, B., "Re-feedback: Freedom with Accountability for Causing Congestion in a Connectionless Internetwork", UCL PhD Thesis (2009).
[BRI09] Briscoe、B。、「Re-Feedback：Connectionless Internetworkに混雑を引き起こす説明責任を伴う自由」、UCL PhD論文（2009）。
[Bri10] Briscoe, B. and J. Manner, "Byte and Packet Congestion Notification," Work in Progress, October 2010.
[BRI10] Briscoe、B。およびJ. Mather、「Byte and Packet commestion notification」、Work in Progress、2010年10月。
[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] Chesterfield、J.、Chakravorty、R.、Banerjee、S.、Rodriguez、P.、Pratt、I。、およびJ. Crowcroft、「広いエリアのワイヤレスネットワーク上のメディアをストリーミングするための輸送レベルの最適化」、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.、John、A.、Kumar、A.、Saran、H。、およびR. Shorey、 "xchoke：インターネットゲートウェイでの混雑回避のための悪意のあるソースコントロール、「2002年11月、フランス、パリのネットワークプロトコルに関するIEEE国際会議（ICNP'02）の議事録。
[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] Chiu、D.M。およびR. Jain、「コンピューターネットワークにおける混雑回避のための増加および減少アルゴリズムの分析」、コンピューターネットワークおよびISDN Systems、Vol。17、pp。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] Clark、D。、「DARPAインターネットプロトコルの設計哲学」、ACM Sigcomm Computer Communication Review、Vol。18、No。4、pp。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] Clark、D。およびW. Fang、「Best-Effort Packet Delivery Serviceの明示的な割り当て」、IEEE/ACM Transactions on Networking、Vol。6、No。4、pp。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] Chu、J.、Dukkipati、N.、Cheng、Y。、およびM. Mathis、「TCPの最初のウィンドウの増加」、2010年10月の作業。
[CONEX] IETF WG Action: Congestion Exposure (conex).
[Conex] IETF WGアクション：混雑暴露（Conex）。
[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.、Kobayashi、M.、Zhang-Shen、R。、およびN. McKeown、「インターネットでのプロセッサ共有フロー」、品質に関する国際ワークショップの議事録（IWQOS'05）、Passau、ドイツ、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. McKeown、「なぜフロー完了時間が混雑制御に適したメトリックであるのか」、ACM Sigcomm Computer Communication Review、Vol。36、No。1、2006年1月。
[ECODE] "ECODE Project", European Commission Seventh Framework Program, Grant No. 223936, <http://www.ecode-project.eu>.
[Ecode]「Ecode Project」、欧州委員会セブンフレームワークプログラム、助成金番号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] Falk、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.
[Feldman04] Feldman、M.、Papadimitriou、C.、Chuang、J。、およびI. Stoica、「ピアツーピアシステムにおけるフリーライディングとホワイトウォッシュ」ACM Sigcommワークショップの議事録ネットワークにおけるインセンティブの実践と理論に関するProceedingsシステム（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. Borden、「混雑制御のためのアクティブキュー管理の研究」、IEEE Infocom'00、Tel Aviv、イスラエル、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] Floyd、S。およびV. Jacobson、「混雑回避のためのランダムアーリー検出ゲートウェイ」、IEEE/ACMトランザクションに関するネットワーキング、Vol。1、No。4、pp。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] Floyd、S。、「TCPおよび明示的な混雑通知」、ACMコンピューター通信レビュー、Vol。24、No。5、pp。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。and Kelly、F。、「優先キューでのパケットマーキングについて」、IEEEトランザクションの自動制御、Vol。47、No。6、pp。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] Ha、S.、Rhee、I。、およびL. Xu、「Cubic：A New TCPフレンドリー高速TCPバリアント」、ACM Sigopsオペレーティングシステムレビュー、Vol。42、No。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] Hilt、V。およびI. Widjaja、「SIPサーバーのネットワークの過負荷の制御」、2008年10月、オーランド（フロリダ）、オーランド（フロリダ）、ネットワークプロトコルに関するIEEE国際会議（ICNP'08）の議事録。
[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。Gong、「Redの制御理論分析」、IEEE Infocom'01の議事録、Anchorage（Alaska）、米国、2001年4月。
[Jacobson88] Jacobson, V., "Congestion Avoidance and Control", Proceedings of ACM SIGCOMM'88 Symposium, August 1988.
[Jacobson88] Jacobson、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] Jain、R。およびK. Ramakrishnan、「コネクションレスネットワークレイヤーを備えたコンピューターネットワークの混雑回避：概念、目標、および方法論」、IEEEコンピューターネットワーキングシンポジウム、ワシントンDC、米国、1988年4月の議事録。
[Jain90] Jain, R., "Congestion Control in Computer Networks: Trends and Issues", IEEE Network, pp. 24-30, May 1990.
[Jain90] Jain、R。、「コンピューターネットワークにおける混雑制御：トレンドと問題」、IEEE Network、pp。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] Jin、Ch。、Wei、D.X.、およびS. Low、「高速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-Aware Transport Protocolの設計、実装、評価」、Elsevier Computer Communications、vol。31、No。9、pp。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。Handley、および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 Computer Communication Review、Vol。35、No。2、pp。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] Kelly、F.、Maulloo、A。、およびD. Tan、「通信ネットワークのレート制御：影の価格、比例公平性、および安定性」、Journal of the Operational Research Society、Vol。49、pp。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] Key、P.、Massoulie、L.、Bain、A。、およびF. Kelly、「公正なインターネットトラフィック統合：ネットワークフローモデルと分析」、Annales des Telecommunications、vol。59、No。11-12、pp。1338-1352、2004年11月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.
[Krishnan04] Krishnan、R.、Sterbenz、J.、Eddy、W.、Partridge、C。、およびM. Allman、「エラーが発生しやすいワイヤレスおよび衛星ネットワークの明示的な輸送エラー通知（ETEN）」、コンピューターネットワーク、Vol。46、No。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. Knightly、「TCP-LP：低優先度データ転送のための分散アルゴリズム」、IEEE InfoCom'03、San Francisco（California）、米国、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、「Diffserv/AFネットワークのTCPフレンドリーレートコントロール（GTFRC）保証」、2006年8月の進行中。
[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 Assured Forwarding Classを介したDCCPの研究と強化」、第4回Universal Multiservice Networks（Ecumn 2007）、フランス、フランス、Touluse、Touluse on Ecumn Conference（Ecumn 2007）。
[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] Low、S.、Paganini、F.、Wang、J.、Adlakha、S.、およびJ.C. Doyle、「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] Low、S。、「TCPおよびキュー管理アルゴリズムの二重性モデル」、IEEE/ACMトランザクションに関するネットワーク、Vol。11、No。4、pp。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] Low、S.、Paganini、F.、Wang、J。、およびJ. Doyle、「TCP/REDの線形安定性とスケーラブルコントロール」、Computer Networks Journal、Vol。43、No。5、pp。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] Low、S.、Andrew、L。、およびB. Wydrowski、「XCPの理解：平衡と公平性」、IEEE Infocom'05、マイアミ（フロリダ）、米国、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] Mackie-Mason、J。and H. Varian、「価格設定うっ血性ネットワークリソース」、Communicationsの選択された領域に関するIEEEジャーナル、Networkingの基礎の進歩、Vol。13、No。7、pp。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、M.Y。、およびR. Wang、「TCP Westwood：Wireless Links以上の輸送の強化のための帯域幅推定」、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] Moors、T。、「システム設計におけるエンドツーエンドの議論」の批判的レビュー、IEEE国際通信会議（ICC）2002、ニューヨーク市（ニュージャージー）、米国、4月/2002年5月。
[MPTCP] IETF WG Action: Multipath TCP (mptcp).
[MPTCP] IETF WGアクション：MultiPath 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] Noel、E。およびC. Johnson、「過負荷の下で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. Kurose、「モデリングTCPスループット：単純なモデルとその経験的検証」、マサチューセッツ大学（UMASS）、CMPSCI Tech。レポート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] Pan、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年。Reports/ionnis.pdf>。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、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] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のためのTCP拡張」、RFC 1323、1992年5月。
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1701] Hanks、S.、Li、T.、Farinacci、D。、およびP. Traina、「ジェネリックルーティングカプセル化（GRE）」、RFC 1701、1994年10月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958] Carpenter、B.、ed。、「インターネットの建築原理」、RFC 1958、1996年6月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、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] Mathis、M.、Mahdavi、J.、Floyd、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] Mankin、A.、Ed。、Baker、F.、Braden、B.、Bradner、S.、O'Dell、M.、Romanow、A.、Weinrib、A.、およびL. Zhang、 "Resource予約プロトコル（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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。、およびW. Stevens、「TCP輻輳制御」、RFC 2581、1999年4月。
[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.、Pall、G.、Verthein、W.、Taarud、J.、Little、W.、およびG. Zorn、「ポイントツーポイントトンネルプロトコル（PPTP）」、RFC 2637、7月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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、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] Handley、M.、Padhye、J。、およびS. Floyd、「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] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[RFC2990] Huston、G。、「IP QoSアーキテクチャの次のステップ」、RFC 2990、2000年11月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、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] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、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.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260] Grossman、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] Blanton、E.、Allman、M.、Fall、K。、およびL. Wang、「TCPの保守的な選択的承認（SACK）ベースの損失回復アルゴリズム」、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] Spring、N.、Wetherall、D。、およびD. Ely、「Noncesによる堅牢な明示的な混雑通知（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] Bless、R.、Nichols、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] Floyd、S.、ed。、およびJ. Kempf、ed。、「インターネットでの音声トラフィックの混雑制御に関するIABの懸念」、RFC 3714、2004年3月。
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large Congestion Windows", RFC 3742, March 2004.
[RFC3742] Floyd、S。、「大規模な混雑窓を備えた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] Bryant、S.、ed。、およびP. Pate、ed。、「Pseudo Wire Emulation Edge-to-Edge（PWE3）Architecture」、RFC 3985、2005年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、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] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram混雑制御プロトコル（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] Floyd、S。およびE. Kohler、「データグラムの混雑制御プロトコルのプロファイル（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] Floyd、S.、Kohler、E。、およびJ. Padhye、「データグラム混雑制御プロトコル（DCCP）混雑制御IDのプロファイル：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.、ed。、およびYJ。Stein、ed。、「パケット（TDM）（TDM）（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] Duke、M.、Braden、R.、Eddy、W。、およびE. Blanton、「伝送制御プロトコルのロードマップ（TCP）仕様文書」、RFC 4614、2006年9月。
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, January 2007.
[RFC4782] Floyd、S.、Allman、M.、Jain、A。、およびP. Sarolahti、「TCPとIPのクイックスタート」、RFC 4782、2007年1月。
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007.
[RFC4828] Floyd、S。およびE. Kohler、「TCP Friendly Rate Control（TFRC）：The Small-Packet（SP）Variant」、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] Andersson、L.、Davies、E。、およびL. Zhang、「2006年3月9〜10日、不要なトラフィックに関するIABワークショップの報告」、RFC 4948、2007年8月。
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion Control Algorithms", BCP 133, RFC 5033, August 2007.
[RFC5033] Floyd、S。およびM. Allman、「新しい混雑制御アルゴリズムの指定」、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.、Ed。、Sasson、I.、Metz、E.、Frost、T.、およびP. Pate、「構造認識時分割多重化（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] Stein、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] Davie、B.、Briscoe、B。、およびJ. Tay、「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] Floyd、S。およびM. Allman、「単純なベストエフォートトラフィックの有用性に関するコメント」、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] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendry Rate Control（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] Eggert、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] Floyd、S。およびE. Kohler、「データグラムの混雑制御プロトコルのプロファイル（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] Allman、M.、Paxson、V。、およびE. Blanton、「TCP混雑制御」、RFC 5681（Obsoletes RFC 2581）、2009年9月。
[RFC5783] Welzl, M. and W. Eddy, "Congestion Control in the RFC Series", RFC 5783, February 2010.
[RFC5783] Welzl、M。およびW. Eddy、「RFCシリーズの混雑制御」、RFC 5783、2010年2月。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010.
[RFC6040] Briscoe、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] Rossi、M。、「IEEE 802.11ワイヤレスLANでの汚職通知でTCPを評価する」、Master論文、Innsbruck大学、2006年11月。http：//heim.io.uio.no/michawe/research/プロジェクト/腐敗/。
[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.、Reed、D。、およびD. Clark、「システム設計におけるエンドツーエンドの引数」、ACM Transactions on Computer Systems、Vol。2、No。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. Kuznetsov、「Linux TCPの混雑制御」、2002年のUsenix年次技術会議の議事録。
[Sarola07] Sarolahti, P., Floyd, S., and M. Kojo, "Transport-layer Considerations for Explicit Cross-layer Indications", Work in Progress, March 2007.
[Sarola07] Sarolahti、P.、Floyd、S。、およびM. Kojo、「明示的な透明指示のための輸送層の考慮事項」、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] Savage、S.、Cardwell、N.、Wetherall、D。、およびT. Anderson、「不正行為レシーバーによるTCP混雑制御」、ACM Sigcomm Computer Communication Review、1999。
[Shal10] Shalunov, S., Hazel, G., and J. Iyengar, "Low Extra Delay Background Transport (LEDBAT)", Work in Progress, October 2010.
[Shal10] Shalunov、S.、Hazel、G。、およびJ. Iyengar、「低追加遅延バックグラウンドトランスポート（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] Shen、C.、Schulzrinne、H。、およびE. Nahum、「セッション開始プロトコル（SIP）サーバーの過負荷制御：設計と評価、原則」、IP電気通信のシステムとアプリケーション（IPTCOMM'08）、Heidelberg、ドイツ、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] Shin、M.、Chong、S。、およびI. Rhee、「処理制限ネットワーク用のデュアルリソースTCP/AQM」、IEEE/ACM Transactions on Networking、Vol。16、No。2、pp。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] Thaler、D.、Sridharan、M。、およびD. Bansal、「さまざまなTCP RFCSの経験に関する実装レポート」、IETF輸送エリアへのプレゼンテーション、2007年3月。<http://www.ietf.org/Proceedings/07mar/Slides/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.、Subramanian、V.、Kalyanaraman、S。、およびK.K.Ramakrishnan、「LT-TCP：損失のあるチャネルを備えたネットワーク上のTCPパフォーマンスを改善するためのエンドツーエンドのフレームワーク」、2005年6月、ドイツ、パッサウ、QoS（IWQOS）に関する国際ワークショップの議事録。
[TRILOGY] "Trilogy Project", European Commission Seventh Framework Program (FP7), Grant No: 216372, <http://www.trilogy-project.org>.
[Trilogy]「Trilogy Project」、欧州委員会Seventh Frameworkプログラム（FP7）、Grant No：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。、「スケーラブルパフォーマンスシグナル伝達と輻輳回避」、Springer（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.、Rossi、M.、Fumagalli、A。、およびM. Tacca、「IEEE 802.11b WLAN上のTCP/IP：既知の腐敗データを活用するという課題」、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] Xia、Y.、Subramanian、L.、Stoica、I。、およびS. Kalyanaraman、「もう1つだけで十分」、ACM Sigcomm Computer Communication Review、Vol。35、No。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.
[Zhang03] Zhang、H.、Towsley、D.、Hollot、C。、およびV. Misra、「TCP/AQMネットワークでの適応のためのセルフチューニング構造」、ACM Sigmetrics'03 Conference、San Diego（カリフォルニア州）、米国、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).
著者は、フィードバックとコメントがこの文書に貢献した次の人々に感謝したいと思います：キース・ムーア、ヤン・ヴァンデナビエル、ラリー・ダン（マンチェスターICCRGでの彼のコメントと彼との議論は、パケット化された性能に関するセクションを助けました）。
Dimitri Papadimitriou's contribution was partly funded by [ECODE], a Seventh Framework Program (FP7) research project sponsored by the European Commission.
Dimitri Papadimitriouの貢献は、欧州委員会が後援する7番目のフレームワークプログラム（FP7）の研究プロジェクトである[Ecode]によって部分的に資金提供されました。
Bob Briscoe's contribution was partly funded by [TRILOGY], a research project supported by the European Commission.
ボブ・ブリスコの貢献は、欧州委員会が支援する研究プロジェクトである[三部作]によって部分的に資金提供されていました。
Michael Scharf is now with Alcatel-Lucent.
マイケル・シャーフは現在、アルカテル・ルーセントと一緒にいます。
The following additional people have contributed to this document:
次の追加の人々がこの文書に貢献しています。
- Wesley Eddy <weddy@grc.nasa.gov>
- Wesley Eddy <weddy@grc.nasa.gov>
- Bela Berde <bela.berde@gmx.de>
- Bela Berde <bela.berde@gmx.de>
- Paulo Loureiro <loureiro.pjg@gmail.com>
- Paulo Loureiro <loureiro.pjg@gmail.com>
- Chris Christou <christou_chris@bah.com>
- Chris Christou <Christou_chris@bah.com>
Authors' Addresses
著者のアドレス
Dimitri Papadimitriou (editor) Alcatel-Lucent Copernicuslaan, 50 2018 Antwerpen, Belgium
Dimitri Papadimitriou（編集者）Alcatel-Lucent Copernicuslaan、50 2018 Antwerpen、ベルギー
Phone: +32 3 240 8491
EMail: dimitri.papadimitriou@alcatel-lucent.com
Michael Welzl University of Oslo, Department of Informatics PO Box 1080 Blindern N-0316 Oslo, Norway
マイケル・ウェルツルオスロ大学、情報学部PO Box 1080 Blindern N-0316オスロ、ノルウェー
EMail: michawe@ifi.uio.no
Michael Scharf University of Stuttgart Pfaffenwaldring 47 70569 Stuttgart, Germany
マイケルシャーフシュトゥットガルト大学Pfaffenwaldring 47 70569シュトゥットガルト、ドイツ
EMail: michael.scharf@googlemail.com
Bob Briscoe BT & UCL B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE, UK
Bob Briscoe BT＆UCL B54/77、Adastral Park Martlesham Heath Ipswich IP5 3RE、英国
EMail: bob.briscoe@bt.com