[要約] RFC 6297は、低効率な輸送プロトコルに関する調査であり、その目的は、ネットワーク上のトラフィックの品質を向上させるために、低効率な輸送プロトコルの特徴と利点を理解することです。
Internet Engineering Task Force (IETF) M. Welzl
Request for Comments: 6297 University of Oslo
Category: Informational D. Ros
ISSN: 2070-1721 IT / Telecom Bretagne
June 2011
A Survey of Lower-than-Best-Effort Transport Protocols
より低いエフォルト輸送プロトコルの調査
Abstract
概要
This document provides a survey of transport protocols that are designed to have a smaller bandwidth and/or delay impact on standard TCP than standard TCP itself when they share a bottleneck with it. Such protocols could be used for delay-insensitive "background" traffic, as they provide what is sometimes called a "less than" (or "lower than") best-effort service.
このドキュメントは、ボトルネックを共有する際に標準のTCP自体よりも標準のTCPへの遅延の影響を与えるように設計された輸送プロトコルの調査を提供します。このようなプロトコルは、「低い」（または「より低い」）のベストエフォートサービスと呼ばれることもあるため、遅延非感受性の「バックグラウンド」トラフィックに使用できます。
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 Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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/rfc6297.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6297で取得できます。
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Delay-Based Transport Protocols . . . . . . . . . . . . . . . 3
2.1. Accuracy of Delay-Based Congestion Predictors . . . . . . 6
2.2. Potential Issues with Delay-Based Congestion Control
for LBE Transport . . . . . . . . . . . . . . . . . . . . 7
3. Non-Delay-Based Transport Protocols . . . . . . . . . . . . . 8
4. Upper-Layer Approaches . . . . . . . . . . . . . . . . . . . . 8
4.1. Receiver-Oriented, Flow-Control-Based Approaches . . . . . 9
5. Network-Assisted Approaches . . . . . . . . . . . . . . . . . 10
6. LEDBAT Considerations . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Informative References . . . . . . . . . . . . . . . . . . . . 12
This document presents a brief survey of proposals to attain a Less-than-Best-Effort (LBE) service by means of end-host mechanisms. We loosely define an LBE service as a service which results in smaller bandwidth and/or delay impact on standard TCP than standard TCP itself, when sharing a bottleneck with it. We refer to systems that are designed to provide this service as LBE systems. With the exception of TCP Vegas, which we present for historical reasons, we exclude systems that have been noted to exhibit LBE behavior under some circumstances but were not designed for this purpose (e.g., RAPID [Kon09]).
このドキュメントでは、エンドホストメカニズムを使用して、ベストよりも低い（LBE）サービスを達成するための提案に関する簡単な調査を提示します。LBEサービスを、ボトルネックを共有する際に、標準TCP自体よりも標準TCPの遅延の影響をもたらすサービスとして、LBEサービスを大まかに定義します。このサービスをLBEシステムとして提供するように設計されたシステムを参照します。歴史的な理由で提示するTCPベガスを除き、状況によってはLBEの行動を示すことが指摘されているが、この目的のために設計されていないシステムを除外します（例：Rapid [KON09]）。
Generally, LBE behavior can be achieved by reacting to queue growth earlier than standard TCP would or by changing the congestion-avoidance behavior of TCP without utilizing any additional implicit feedback. It is therefore assumed that readers are familiar with TCP congestion control [RFC5681]. Some mechanisms achieve an LBE behavior without modifying transport-protocol standards (e.g., by changing the receiver window of standard TCP), whereas others leverage network-level mechanisms at the transport layer for LBE purposes. According to this classification, solutions have been categorized in this document as delay-based transport protocols, non-delay-based transport protocols, upper-layer approaches, and network-assisted approaches. Some of the schemes in the first two categories could be implemented using TCP without changing its header format; this would facilitate their deployment in the Internet. The schemes in the third category are, by design, supposed to be especially easy to deploy because they only describe a way in which existing transport protocols are used. Finally, mechanisms in the last category require changes to equipment along the path, which can greatly complicate their deployment.
一般に、LBEの挙動は、標準のTCPよりも早くキューの成長に反応するか、追加の暗黙的なフィードバックを利用せずにTCPの混雑回避挙動を変更することによって達成できます。したがって、読者はTCP混雑制御に精通していると想定されています[RFC5681]。一部のメカニズムは、トランスポートプロトコル標準を変更せずにLBEの動作を実現します（例：標準TCPの受信ウィンドウを変更することにより）。一方、LBEの目的で輸送層でネットワークレベルのメカニズムを活用するものもあります。この分類によれば、このドキュメントには、遅延ベースの輸送プロトコル、非デレイベースの輸送プロトコル、上層層アプローチ、ネットワーク支援アプローチに分類されています。最初の2つのカテゴリの一部のスキームは、ヘッダー形式を変更せずにTCPを使用して実装できます。これにより、インターネットでの展開が容易になります。3番目のカテゴリのスキームは、設計上、既存の輸送プロトコルが使用される方法のみを説明するため、特に展開が簡単になるはずです。最後に、最後のカテゴリのメカニズムには、パスに沿った機器の変更が必要であり、展開を大幅に複雑にする可能性があります。
This document is a product of the Low Extra Delay Background Transport (LEDBAT) working group. It aims at putting the congestion control algorithm that the working group has specified [Sha11] in the context of the state of the art in LBE transport. This survey is not exhaustive, as this would not be possible or useful; the authors have selected key, well-known, or otherwise interesting techniques for inclusion at their discretion. There is also a substantial amount of work that is related to the LBE concept but does not present a solution that can be installed in end-hosts or expected to work over the Internet (e.g., there is a Diffserv-based, Lower-Effort service [RFC3662], and the IETF Congestion Exposure (CONEX) working group is developing a mechanism which can incentivize LEDBAT-like applications). Such work is outside the scope of this document.
このドキュメントは、低い余分な遅延バックグラウンドトランスポート（LEDBAT）ワーキンググループの製品です。これは、ワーキンググループがLBE輸送の最新技術のコンテキストで[SHA11]を指定した混雑制御アルゴリズムを配置することを目的としています。この調査は網羅的ではありません。これは不可能または有用ではないためです。著者は、裁量で包含するためのキー、よく知られている、または興味深いテクニックを選択しました。また、LBEコンセプトに関連するが、インターネット上で機能すると予想されるソリューションを提示しないかなりの量の作業もあります（たとえば、Diffservベースの低エフェクトサービスがあります。[RFC3662]、およびIETF混雑暴露（CONEX）ワーキンググループは、LEDBATのようなアプリケーションを奨励できるメカニズムを開発しています）。このような作業は、このドキュメントの範囲外です。
It is wrong to generally equate "little impact on standard TCP" with "small sending rate". Without Explicit Congestion Notification (ECN) support, standard TCP will normally increase its congestion window (and effective sending rate) until a queue overflows, causing one or more packets to be dropped and the effective rate to be reduced. A protocol that stops increasing the rate before this event happens can, in principle, achieve a better performance than standard TCP.
一般に、「標準TCPへの影響はほとんどない」と「小さい送信率」と同一視することは間違っています。明示的な輻輳通知（ECN）サポートがなければ、標準のTCPは通常、キューがオーバーフローするまで混雑ウィンドウ（および有効送信率）を増加させ、1つ以上のパケットを削除し、有効レートを減らします。このイベントが発生する前にレートの増加を停止するプロトコルは、原則として、標準のTCPよりも優れたパフォーマンスを達成できます。
TCP Vegas [Bra94] is one of the first protocols that was known to have a smaller sending rate than standard TCP when both protocols share a bottleneck [Kur00] -- yet, it was designed to achieve more, not less, throughput than standard TCP. Indeed, when TCP Vegas is the only congestion control algorithm used by flows going through the bottleneck, its throughput is greater than the throughput of standard TCP. Depending on the bottleneck queue length, TCP Vegas itself can be starved by standard TCP flows. This can be remedied to some degree by the Random Early Detection (RED) Active Queue Management mechanism [RFC2309]. Vegas linearly increases or decreases the sending rate, based on the difference between the expected throughput and the actual throughput. The estimation is based on RTT measurements.
TCPベガス[BRA94]は、両方のプロトコルがボトルネック[KUR00]を共有している場合、標準のTCPよりも小さい送信率を持つことが知られている最初のプロトコルの1つですが、標準のTCPよりもスループットよりも多く、より少ない、スループットを達成するように設計されています。。実際、TCPベガスがボトルネックを通過するフローで使用される唯一の混雑制御アルゴリズムである場合、そのスループットは標準のTCPのスループットよりも大きくなります。ボトルネックキューの長さに応じて、TCPベガス自体は標準のTCPフローに飢えている可能性があります。これは、ランダムな早期検出（赤）アクティブキュー管理メカニズム[RFC2309]によってある程度改善できます。ベガスは、予想されるスループットと実際のスループットの差に基づいて、送信率を直線的に増加または減少させます。推定はRTT測定に基づいています。
The congestion-avoidance behavior is the protocol's most important feature in terms of historical relevance as well as relevance in the context of this document (it has been shown that other elements of the protocol can sometimes play a greater role for its overall behavior [Hen00]). In congestion avoidance, once per RTT, TCP Vegas calculates the expected throughput as WindowSize / BaseRTT, where WindowSize is the current congestion window and BaseRTT is the minimum of all measured RTTs. The expected throughput is then compared with the actual throughput, measured based on recent acknowledgements. If the actual throughput is smaller than the expected throughput minus a threshold called "beta", this is taken as a sign of congestion, causing the protocol to linearly decrease its rate. If the actual throughput is greater than the expected throughput minus a threshold called "alpha" (with alpha < beta), this is taken as a sign that the network is underutilized, causing the protocol to linearly increase its rate.
混雑回避動作は、このドキュメントのコンテキストでの歴史的関連性と関連性の観点からのプロトコルの最も重要な機能です（プロトコルの他の要素が全体的な動作に対してより大きな役割を果たすことができることが示されています[HEN00]）。混雑回避では、RTTごとに1回、TCPベガスはWindowsize / Baserttとして予想されるスループットを計算します。ここで、Windowsizeは現在の混雑ウィンドウであり、Baserttはすべての測定されたRTTの最小です。予想されるスループットは、最近の確認に基づいて測定された実際のスループットと比較されます。実際のスループットが予想されるスループットから「ベータ」と呼ばれるしきい値を引いたものよりも小さい場合、これはうっ血の兆候としてとられ、プロトコルがその速度を直線的に低下させます。実際のスループットが予想されるスループットから「アルファ」と呼ばれるしきい値（アルファ<ベータ）を引いたものよりも大きい場合、これはネットワークが十分に活用されていないという兆候と見なされ、プロトコルがレートを直線的に増加させます。
TCP Vegas has been analyzed extensively. One of the most prominent properties of TCP Vegas is its fairness between multiple flows of the same kind, which does not penalize flows with large propagation delays in the same way as standard TCP. While it was not the first protocol that uses delay as a congestion indication, its predecessors (like CARD [Jai89], Tri-S [Wan91], or DUAL [Wan92]) are not discussed here because of the historical "landmark" role that TCP Vegas has taken in the literature.
TCPベガスは広範囲に分析されています。TCPベガスの最も顕著な特性の1つは、同じ種類の複数のフロー間の公平性であり、標準のTCPと同じ方法で大きな伝播遅延でフローを罰することはありません。輻輳の表示として遅延を使用するのは最初のプロトコルではありませんでしたが、その前任者（カード[Jai89]、Tri-S [WAN91]、またはデュアル[WAN92]など）は、歴史的な「ランドマーク」の役割のためにここでは議論されていません。TCPベガスは文献を取り入れています。
Delay-based transport protocols that were designed to be non-intrusive include TCP Nice [Ven02] and TCP Low Priority (TCP-LP) [Kuz06]. TCP Nice [Ven02] follows the same basic approach as TCP Vegas but improves upon it in some aspects. Because of its moderate linear-decrease congestion response, TCP Vegas can affect standard TCP despite its ability to detect congestion early. TCP Nice removes this issue by halving the congestion window (at most once per RTT, like standard TCP) instead of linearly reducing it. To avoid being too conservative, this is only done if a fixed predefined fraction of delay-based incipient congestion signals appears within one RTT. Otherwise, TCP Nice falls back to the congestion-avoidance rules of TCP Vegas if no packet was lost or standard TCP if a packet was lost. One more feature of TCP Nice is its ability to support a congestion window of less than one packet, by clocking out single packets over more than one RTT. With ns-2 simulations and real-life experiments using a Linux implementation, the authors of [Ven02] show that TCP Nice achieves its goal of efficiently utilizing spare capacity while being non-intrusive to standard TCP.
非侵入であるように設計された遅延ベースの輸送プロトコルには、TCP NICE [VEN02]およびTCP低優先度（TCP-LP）[KUZ06]が含まれます。TCP NICE [VEN02]は、TCPベガスと同じ基本的なアプローチに従いますが、いくつかの側面では改善されます。中程度の線形抑制輻輳反応のため、TCPベガスは、混雑を早期に検出する能力にもかかわらず、標準のTCPに影響を与える可能性があります。TCP Niceは、線形に縮小するのではなく、混雑ウィンドウ（標準TCPのように、最大1回）を半分にすることにより、この問題を削除します。保守的すぎることを避けるために、これは、1つのRTT内に固定された定義された遅延性輻輳シグナルの固定された割合が現れる場合にのみ行われます。それ以外の場合、TCPは、パケットが失われなかった場合、TCPベガスの混雑回避ルールに戻ります。TCP Niceのもう1つの機能は、複数のRTTを超えるシングルパケットをクロックすることにより、1つのパケットの輻輳ウィンドウをサポートできることです。Linux実装を使用したNS-2シミュレーションと実生活の実験により、[ven02]の著者は、TCP Niceが標準のTCPに侵入しながら予備容量を効率的に利用するという目標を達成することを示しています。
Other than TCP Vegas and TCP Nice, TCP-LP [Kuz06] uses only the one-way delay (OWD) instead of the RTT as an indicator of incipient congestion. This is done to avoid reacting to delay fluctuations that are caused by reverse cross-traffic. Using the TCP Timestamps option [RFC1323], the OWD is determined as the difference between the receiver's Timestamp value in the ACK and the original Timestamp value that the receiver copied into the ACK. While the result of this subtraction can only precisely represent the OWD if clocks are synchronized, its absolute value is of no concern to TCP-LP, and hence clock synchronization is unnecessary. Using a constant smoothing parameter, TCP-LP calculates an Exponentially Weighted Moving Average (EWMA) of the measured OWD and checks whether the result exceeds a threshold within the range of the minimum and maximum OWD that was seen during the connection's lifetime; if it does, this condition is interpreted as an "early congestion indication". The minimum and maximum OWD values are initialized during the slow-start phase.
TCP VegasとTCP Niceを除いて、TCP-LP [KUZ06]は、初期輻輳の指標としてRTTの代わりに一方向遅延（OWD）のみを使用します。これは、逆トラフィックによって引き起こされる遅延変動に対する反応を避けるために行われます。TCPタイムスタンプオプション[RFC1323]を使用して、OWDは、ACKの受信機のタイムスタンプ値とレシーバーがACKにコピーした元のタイムスタンプ値の違いとして決定されます。この減算の結果は、クロックが同期されている場合にのみOWDを正確に表すことができますが、その絶対値はTCP-LPには関心がないため、クロック同期は不要です。一定のスムージングパラメーターを使用して、TCP-LPは測定されたOWDの指数加重移動平均（EWMA）を計算し、結果が接続の寿命に見られた最小値と最大OWDの範囲内のしきい値を超えるかどうかをチェックします。もしそうなら、この条件は「早期輻輳の表示」として解釈されます。最小値と最大OWD値は、スロースタートフェーズ中に初期化されます。
Regarding its reaction to an early congestion indication, TCP-LP tries to strike a middle ground between the overly conservative choice of _immediately_ setting the congestion window to one packet, and the presumably too aggressive choice of simply halving the congestion window like standard TCP; TCP-LP tries to delay the former action by an additional RTT, to see if there is persistent congestion or not. It does so by halving the window at first in response to an early congestion indication, then initializing an "inference time-out timer" and maintaining the current congestion window until this timer fires. If another early congestion indication appeared during this "inference phase", the window is then set to 1; otherwise, the window is maintained and TCP-LP continues to increase it in the standard Additive-Increase fashion. This method ensures that it takes at least two RTTs for a TCP-LP flow to decrease its window to 1, and that, like standard TCP, TCP-LP reacts to congestion at most once per RTT.
早期輻輳の兆候に対するその反応に関して、TCP-LPは_immedietally _が1つのパケットに設定するという_immediely_の過度に保守的な選択と、おそらく標準のTCPのような混雑ウィンドウを半分にするという攻撃的すぎる選択の間の中間地を攻撃しようとします。TCP-LPは、追加のRTTによって以前のアクションを遅らせようとして、しつこいうっ血があるかどうかを確認しようとします。初期の輻輳指示に応じて最初に窓を半分にし、「推論タイムアウトタイマー」を初期化し、このタイマーが発射されるまで現在の混雑ウィンドウを維持することでそうします。この「推論フェーズ」中に別の早期鬱血指示が表示された場合、ウィンドウは1に設定されます。それ以外の場合、ウィンドウが維持され、TCP-LPは標準の添加剤の順方向に増加し続けます。この方法により、TCP-LPフローに少なくとも2つのRTTがそのウィンドウを1に減らすことができ、標準のTCPと同様に、TCP-LPはRTTごとに最大1回混雑に反応することが保証されます。
Using a simple analytical model, the authors of TCP-LP [Kuz06] illustrate the feasibility of a delay-based LBE transport by showing that, due to the non-linear relationship between throughput and RTT, it is possible to avoid interfering with standard TCP traffic even when the flows under consideration have a larger RTT than standard TCP flows. With ns-2 simulations and real-life experiments using a Linux implementation, the authors of [Kuz06] show that TCP-LP is largely non-intrusive to TCP traffic while at the same time enabling it to utilize a large portion of the excess network bandwidth, which is fairly shared among competing TCP-LP flows. They also show that using their protocol for bulk data transfers greatly reduces file transfer times of competing best-effort web traffic.
単純な分析モデルを使用して、TCP-LP [KUZ06]の著者は、スループットとRTTの非線形関係により、標準のTCPとの干渉を避けることができることを示すことにより、遅延ベースのLBE輸送の実現可能性を示しています。検討中のフローが標準のTCPフローよりも大きなRTTを持っている場合でも、トラフィック。Linux実装を使用したNS-2シミュレーションと実生活の実験により、[Kuz06]の著者は、TCP-LPがTCPトラフィックにほとんど侵入していないことを示していますが、同時に過剰なネットワークの大部分を利用できるようにします。競合するTCP-LPフローの間でかなり共有されている帯域幅。また、バルクデータ転送にプロトコルを使用すると、競合するベストエフォルトWebトラフィックのファイル転送時間が大幅に短縮されることも示しています。
Sync-TCP [Wei05] follows a similar approach as TCP-LP, by adapting its reaction to congestion according to changes in the OWD. By comparing the estimated (average) forward queuing delay to the maximum observed delay, Sync-TCP adapts the Additive-Increase Multiplicative-Decrease (AIMD) parameters depending on the trend followed by the average delay over an observation window. Even though the authors of [Wei05] did not explicitly consider its use as an LBE protocol, Sync-TCP was designed to react early to incipient congestion, while grabbing available bandwidth more aggressively than a standard TCP in congestion-avoidance mode.
Sync-TCP [Wei05]は、OWDの変化に応じて混雑に対する反応を適応させることにより、TCP-LPと同様のアプローチに従います。推定された（平均）前方キューイング遅延を最大観測された遅延と比較することにより、Sync-TCPは、観測ウィンドウの平均遅延の後に続く傾向に応じて、添加剤の増加倍数抑制（AIMD）パラメーターを適応させます。[Wei05]の著者は、その使用をLBEプロトコルと明示的に考慮していませんでしたが、Sync-TCPは、混雑回避モードで標準のTCPよりも積極的に利用可能な帯域幅をつかみながら、初期の混雑に早期に反応するように設計されていました。
Delay-based congestion control is also the basis of proposals that aim at adapting TCP's congestion avoidance to very high-speed networks. Some of these proposals, like Compound TCP [Tan06] [Sri08] and TCP Illinois [Liu08], are hybrid loss- and delay-based mechanisms, whereas others (e.g., NewVegas [Dev03], FAST TCP [Wei06], or CODE TCP [Cha10]) are variants of Vegas based primarily on delays.
遅延ベースの混雑制御は、TCPの混雑回避を非常に高速ネットワークに適応させることを目的とする提案の基礎でもあります。化合物TCP [TAN06] [SRI08]やTCPイリノイ[Liu08]などのこれらの提案の一部は、ハイブリッド損失および遅延ベースのメカニズムですが、他のもの（例えば、NewVegas [Dev03]、高速TCP [Wei06]、またはコードTCP[CHA10]）は、主に遅延に基づいたベガスのバリアントです。
The accuracy of delay-based congestion predictors has been the subject of a good deal of research, see, e.g., [Bia03], [Mar03], [Pra04], [Rew06], [McC08]. The main result of most of these studies is that delays (or, more precisely, round-trip times) are, in general, weakly correlated with congestion. There are several factors that may induce such a poor correlation:
遅延ベースの混雑予測因子の精度は、多くの研究の対象となっています。これらの研究のほとんどの主な結果は、一般に、遅延（またはより正確には往復時間）が混雑と弱く相関していることです。このような貧弱な相関を誘発する可能性のあるいくつかの要因があります。
o Bottleneck buffer size: in principle, a delay-based mechanism could be made "more than TCP friendly" _if_ buffers are "large enough", so that RTT fluctuations and/or deviations from the minimum RTT can be detected by the end-host with reasonable accuracy. Otherwise, it may be hard to distinguish real delay variations from measurement noise.
o Bottleneck Bufferサイズ：原則として、遅延ベースのメカニズムを「TCPに優しい」_IF_バッファーは「十分に大きい」ため、RTTの変動および/または最小RTTからの逸脱を、エンドホストで検出できます。リーズナブルな精度。それ以外の場合、実際の遅延変動と測定ノイズを区別するのは難しいかもしれません。
o RTT measurement issues: in principle, RTT samples may suffer from poor resolution, due to timers which are too coarse-grained with respect to the scale of delay fluctuations. Also, a flow may obtain a very noisy estimate of RTTs due to undersampling, under some circumstances (e.g., the flow rate is much lower than the link bandwidth). For TCP, other potential sources of measurement noise include TCP segmentation offloading (TSO) and the use of delayed ACKs [Hay10]. A congested reverse path may also result in an erroneous assessment of the congestion state of the forward path. Finally, in the case of fast or short-distance links, the majority of the measured delay can in fact be due to processing in the involved hosts; typically, this processing delay is not of interest, and it can underlie fluctuations that are not related to the network at all.
o RTT測定の問題：原則として、RTTサンプルは、遅延変動のスケールに関して粗すぎるタイマーのために、解像度が不十分である可能性があります。また、流れは、状況によっては、アンダーサンプリングのためにRTTの非常に騒々しい推定値を取得する可能性があります（たとえば、流量はリンク帯域幅よりもはるかに低くなります）。TCPの場合、測定ノイズの他の潜在的なソースには、TCPセグメンテーションオフロード（TSO）と遅延ACKの使用が含まれます[Hay10]。混雑した逆パスは、前方経路の混雑状態の誤った評価をもたらす可能性があります。最後に、高速または短距離リンクの場合、測定された遅延の大部分は、実際には関与するホストの処理によるものです。通常、この処理遅延は関心がなく、ネットワークにまったく関係のない変動の根底にあります。
o Level of statistical multiplexing and RTT sampling: it may be easy for an individual flow to "miss" loss/queue overflow events, especially if the number of flows sharing a bottleneck buffer is significant. This is nicely illustrated, e.g., in Figure 1 of [McC08].
o 統計的多重化とRTTサンプリングのレベル：特に、ボトルネックバッファーを共有するフローの数が重要な場合、個々のフローが損失/キューオーバーフローイベントを「ミス」するのは簡単かもしれません。これは、たとえば[MCC08]の図1によく示されています。
o Impact of wireless links: several mechanisms that are typical of wireless links, like link-layer scheduling and error recovery, may induce strong delay fluctuations over short timescales [Gur04].
o ワイヤレスリンクの影響：リンク層スケジューリングやエラー回復など、ワイヤレスリンクに典型的ないくつかのメカニズムは、短いタイムスケールで強い遅延変動を誘発する可能性があります[GUR04]。
Interestingly, the results of Bhandarkar et al. [Bha07] seem to paint a slightly different picture, regarding the accuracy of delay-based congestion prediction. Bhandarkar et al. claim that it is possible to significantly improve prediction accuracy by adopting some simple techniques (smoothing of RTT samples, increasing the RTT sampling frequency). Nonetheless, they acknowledge that even with such techniques, it is not possible to eradicate detection errors. Their proposed delay-based congestion-avoidance method, PERT (Probabilistic Early Response TCP), mitigates the impact of residual detection errors by means of a probabilistic response mechanism to congestion-detection events.
興味深いことに、Bhandarkarらの結果。[BHA07]は、遅延ベースの混雑予測の精度に関して、わずかに異なる絵を描くようです。Bhandarkar et al。いくつかの簡単な手法（RTTサンプルのスムージング、RTTサンプリング頻度の増加）を採用することにより、予測の精度を大幅に改善できると主張しています。それにもかかわらず、彼らはそのような手法でさえ、検出エラーを根絶することは不可能であることを認めています。提案された遅延ベースの混雑回避法であるPERT（確率論的早期応答TCP）は、輻輳検出イベントに対する確率的応答メカニズムによる残留検出エラーの影響を軽減します。
Whether a delay-based protocol behaves in its intended manner (e.g., it is "more than TCP friendly", or it grabs available bandwidth in a very aggressive manner) may depend on the accuracy issues listed in Section 2.1. Moreover, protocols like Vegas need to keep an estimate of the minimum ("base") delay; this makes such protocols highly sensitive to eventual changes in the end-to-end route during the lifetime of the flow [Mo99].
遅延ベースのプロトコルが意図された方法で動作するかどうか（たとえば、「TCPよりも優れている」、または利用可能な帯域幅を非常に積極的につかむことができます）が、セクション2.1にリストされている精度の問題に依存する可能性があります。さらに、ベガスのようなプロトコルは、最小（「ベース」）遅延の推定値を維持する必要があります。これにより、このようなプロトコルは、流れの寿命の間にエンドツーエンドルートの最終的な変化に非常に敏感になります[MO99]。
Regarding the issue of false positives or false negatives with a delay-based congestion detector, most studies focus on the loss of throughput coming from the erroneous detection of queue build-up and of alleviation of congestion. Arguably, for an LBE transport protocol it's better to err on the "more-than-TCP-friendly side", that is, to always yield to _perceived_ congestion whether it is "real" or not; however, failure to detect congestion (due to one of the above accuracy problems) would result in behavior that is not LBE. For instance, consider the case in which the bottleneck buffer is small, so that the contribution of queueing delay at the bottleneck to the global end-to-end delay is small. In such a case, a flow using a delay-based mechanism might end up consuming a good deal of bandwidth with respect to a competing standard TCP flow, unless it also incorporates a suitable reaction to loss.
遅延ベースの混雑検出器による誤検知または偽陰性の問題に関して、ほとんどの研究は、キューの蓄積の誤った検出と輻輳の緩和によるスループットの喪失に焦点を当てています。間違いなく、LBE輸送プロトコルの場合、「TCPに優しい側面」、つまり、「本当の」かどうかにかかわらず、常に_perceived_混雑に譲る方が良いです。ただし、（上記の精度の問題の1つにより）混雑を検出できないと、LBEではない動作が生じます。たとえば、ボトルネックバッファーが小さい場合を検討して、ボトルネックでのキューイング遅延の寄与がグローバルなエンドツーエンドの遅延に小さいようになります。そのような場合、遅延ベースのメカニズムを使用したフローは、損失に対する適切な反応も組み込まれていない限り、競合する標準TCPフローに関してかなりの帯域幅を消費することになる可能性があります。
A delay-based mechanism may also suffer from the so-called "latecomer advantage" (or "latecomer unfairness") problem. Consider the case in which the bottleneck link is already (very) congested. In such a scenario, delay variations may be quite small; hence, it may be very difficult to tell an empty queue from a heavily-loaded queue, in terms of delay fluctuation. Therefore, a newly-arriving delay-based flow may start sending faster when there is already heavy congestion, eventually driving away loss-based flows [Sha05] [Car10].
遅延ベースのメカニズムは、いわゆる「Latecomer Advantation」（または「Latecomer fulairness」）の問題にも悩まされる場合があります。ボトルネックリンクがすでに（非常に）混雑している場合を考えてみましょう。このようなシナリオでは、遅延の変動は非常に少ない場合があります。したがって、遅延変動の観点から、重度に搭載されたキューから空のキューを伝えることは非常に困難な場合があります。したがって、新たに到着する遅延ベースのフローは、すでに重い輻輳がある場合に速く送信を開始する可能性があり、最終的に損失ベースのフローを追い払う[SHA05] [CAR10]。
There exist a few transport-layer proposals that achieve an LBE service without relying on delay as an indicator of congestion. In the algorithms discussed below, the loss rate of the flow determines, either implicitly or explicitly, the sending rate (which is adapted so as to obtain a lower share of the available bandwidth than standard TCP); such mechanisms likely cause more queuing delay and react to congestion more slowly than delay-based ones.
混雑の指標として遅延に依存することなくLBEサービスを達成する輸送層提案がいくつか存在します。以下で説明したアルゴリズムでは、流れの損失率が、暗黙的または明示的に、送信率を決定します（標準TCPよりも利用可能な帯域幅の低いシェアを取得するように適合しています）。このようなメカニズムは、遅延ベースのメカニズムよりも鎮静遅延を引き起こし、渋滞に反応する可能性があります。
4CP [Liu07], which stands for "Competitive and Considerate Congestion Control", is a protocol that provides an LBE service by changing the window control rules of standard TCP. A "virtual window" is maintained that, during a so-called "bad congestion phase", is reduced to less than a predefined minimum value of the actual congestion window. The congestion window is only increased again once the virtual window exceeds this minimum, and in this way the virtual window controls the duration during which the sender transmits with a fixed minimum rate. Whether the congestion state is "bad" or "good" depends on whether the loss event rate is above or below a threshold (or target) value. The 4CP congestion-avoidance algorithm allows for setting a target average window and avoids starvation of "background" flows while bounding the impact on "foreground" flows. Its performance was evaluated in ns-2 simulations and in real-life experiments with a kernel-level implementation in Microsoft Windows Vista.
4CP [Liu07]は、「競争力と思いやりのある混雑制御」を表し、標準TCPのウィンドウ制御ルールを変更することによりLBEサービスを提供するプロトコルです。「仮想ウィンドウ」は、いわゆる「輻輳段階」の間に、実際の輻輳ウィンドウの定義済みの最小値未満に削減されることを維持しています。輻輳ウィンドウは、仮想ウィンドウがこの最小値を超えると再び増加します。このようにして、仮想ウィンドウは、送信者が固定最小レートで送信する期間を制御します。混雑状態が「悪い」または「良い」かどうかは、損失イベント率がしきい値（またはターゲット）値を上回っているか下回っているかによって異なります。4CPの輻輳回避アルゴリズムは、目標平均ウィンドウを設定することを可能にし、「前景」フローへの影響を制限しながら「バックグラウンド」フローの飢starを回避します。そのパフォーマンスは、NS-2シミュレーションと、Microsoft Windows Vistaでのカーネルレベルの実装を使用した実際の実験で評価されました。
The MulTFRC [Dam09] protocol is an extension of TCP-Friendly Rate Control (TFRC) [RFC5348] for multiple flows. MulTFRC takes the main idea of MulTCP [Cro98] and similar proposals (e.g., [Hac04], [Hac08], [Kuo08]) a step further. A single MulTCP flow tries to emulate (and be as friendly as) a number N > 1 of parallel TCP flows. By supporting values of N between 0 and 1, MulTFRC can be used as a mechanism for an LBE service. Since it does not react to delay like the protocols described in Section 2 but adjusts its rate like TFRC, MulTFRC can probably be expected to be more aggressive than mechanisms such as TCP Nice or TCP-LP. This also means that MulTFRC is less likely to be prone to starvation, as its aggressiveness is tunable at a fine granularity, even when N is between 0 and 1.
MultFRC [DAM09]プロトコルは、複数のフローのTCPフレンドリーレート制御（TFRC）[RFC5348]の拡張です。MultFRCは、MultCP [CRO98]の主なアイデアと同様の提案を取ります（例：[HAC04]、[HAC08]、[Kuo08]）。単一のマルチフローは、並列TCPフローの数n> 1をエミュレートしようとします（そしてフレンドリーになります）。0から1の間のnの値をサポートすることにより、MultFRCはLBEサービスのメカニズムとして使用できます。セクション2で説明されているプロトコルのように遅延に反応しないが、TFRCのようなレートを調整するため、MultFRCはおそらくTCP NiceやTCP-LPなどのメカニズムよりも攻撃的であると予想される可能性があります。これはまた、nが0〜1の間であっても、その攻撃性は細かい粒度で調整可能であるため、MultFRCは飢starになりやすい可能性が低いことを意味します。
The proposals described in this section do not require modifying transport-protocol standards. Most of them can be regarded as running "on top" of an existing transport, even though they may be implemented either at the application layer (i.e., in user-level processes), or in the kernel of the end-hosts' operating systems.
このセクションで説明されている提案は、輸送プロトコル標準の変更を必要としません。それらのほとんどは、アプリケーションレイヤー（つまり、ユーザーレベルのプロセス）またはエンドホストのオペレーティングシステムのカーネルで実装されている場合でも、既存のトランスポートの「上」を実行していると見なすことができます。。
Such "upper-layer" mechanisms may arguably be easier to deploy than transport-layer approaches, since they do not require any changes to the transport itself.
このような「上層」メカニズムは、輸送自体に変更を必要としないため、輸送層アプローチよりも展開が容易になる可能性があります。
A simplistic, application-level approach to a background transport service may consist in scheduling automated transfers at times when the network is lightly loaded, e.g., as described in [Dyk02] for cooperative proxy caching. An issue with such a technique is that it may not necessarily be applicable to applications like peer-to-peer file transfer, since the notion of an "off-peak hour" is not meaningful when end-hosts may be located anywhere in the world.
バックグラウンドトランスポートサービスに対する単純化されたアプリケーションレベルのアプローチは、協同組合プロキシキャッシングの[dyk02]で説明されているように、ネットワークが軽くロードされる場合に自動化された転送のスケジューリングで構成されます。このような手法の問題は、「オフピーク時間」の概念が世界中のどこにでも配置されている場合に意味がないため、ピアツーピアファイル転送などのアプリケーションに必ずしも適用できるとは限らないことです。。
The so-called Background Intelligent Transfer Service [BITS] is implemented in several versions of Microsoft Windows. BITS uses a system of application-layer priority levels for file-transfer jobs, together with monitoring of bandwidth usage of the network interface (or, in more recent versions, of the network gateway connected to the end-host), so that low-priority transfers at a given end-host give way to both high-priority (foreground) transfers and traffic from interactive applications at the same host.
いわゆるバックグラウンドインテリジェント転送サービス[BITS]は、Microsoft Windowsのいくつかのバージョンに実装されています。BITSは、ファイル転送ジョブのアプリケーション層優先レベルのシステムを使用し、ネットワークインターフェイス（または最近のバージョンでは、エンドホストに接続されたネットワークゲートウェイの帯域幅使用）の監視を使用しているため、それは低いものです。特定のエンドホストでの優先転送は、同じホストでのインタラクティブアプリケーションからの優先度（前景）転送とトラフィックの両方に取って代わります。
A different approach is taken in [Egg05] -- here, the priority of a flow is reduced via a generic idletime scheduling strategy in a host's operating system. While results presented in this paper show that the new scheduler can effectively shield regular tasks from low-priority ones (e.g., TCP from greedy UDP) with only a minor performance impact, it is an underlying assumption that all involved end-hosts would use the idletime scheduler. In other words, it is not the focus of this work to protect a standard TCP flow that originates from any host where the presented scheduling scheme may not be implemented.
[EGG05]では別のアプローチが取られています。ここでは、ホストのオペレーティングシステムでの一般的なIDLETIMEスケジューリング戦略を介して、フローの優先順位が削減されます。このペーパーで提示された結果は、新しいスケジューラが小さなパフォーマンスの影響しかない低優先度のタスク（例えば、貪欲なUDPからのTCP）から通常のタスクを効果的に保護できることを示していますが、それはすべての関係するエンドホストが使用するという根本的な仮定です。IDLETIMEスケジューラ。言い換えれば、提示されたスケジューリングスキームが実装されない可能性のあるホストから発生する標準のTCPフローを保護することは、この作業の焦点ではありません。
Some proposals for achieving an LBE behavior work by exploiting existing transport-layer features -- typically, at the "receiving" side. In particular, TCP's built-in flow control can be used as a means to achieve a low-priority transport service.
既存の輸送層機能を活用することにより、LBEの行動作業を達成するためのいくつかの提案 - 通常は「受信」側で。特に、TCPの組み込みフロー制御は、低優先順位輸送サービスを達成するための手段として使用できます。
The mechanism described in [Spr00] is an example of the above technique. Such mechanism controls the bandwidth by letting the receiver intelligently manipulate the receiver window of standard TCP. This is possible because the authors assume a client-server setting where the receiver's access link is typically the bottleneck. The scheme incorporates a delay-based calculation of the expected queue length at the bottleneck, which is quite similar to the calculation in the above delay-based protocols, e.g., TCP Vegas. Using a Linux implementation, where TCP flows are classified according to their application's needs, Spring et al. show in [Spr00] that a significant improvement in packet latency can be attained over an unmodified system, while maintaining good link utilization.
[SPR00]で説明されているメカニズムは、上記の手法の例です。このようなメカニズムは、レシーバーが標準TCPの受信機ウィンドウをインテリジェントに操作できるようにすることにより、帯域幅を制御します。これは、著者がレシーバーのアクセスリンクが通常ボトルネックであるクライアントサーバー設定を想定しているため、可能です。このスキームには、ボトルネックでの予想されるキュー長の遅延ベースの計算が組み込まれています。これは、上記の遅延ベースのプロトコル、たとえばTCPベガスの計算に非常に似ています。TCPフローがアプリケーションのニーズに応じて分類されるLinux実装を使用して、Spring et al。[SPR00]では、適切なリンク利用を維持しながら、パケットレイテンシの大幅な改善が変更されていないシステムで達成できることを示しています。
A similar method is employed by Mehra et al. [Meh03], where both the advertised receiver window and the delay in sending ACK messages are dynamically adapted to attain a given rate. As in [Spr00], Mehra et al. assume that the bottleneck is located at the receiver's access link. However, the latter also propose a bandwidth-sharing system, allowing control of the bandwidth allocated to different flows, as well as allotment of a minimum rate to some flows.
同様の方法がMehraらによって採用されています。[MEH03]。広告されたレシーバーウィンドウとACKメッセージの送信の遅延の両方が、特定のレートを達成するために動的に適応されます。[SPR00]のように、Mehra et al。ボトルネックがレシーバーのアクセスリンクにあると仮定します。ただし、後者は帯域幅共有システムも提案しており、さまざまなフローに割り当てられた帯域幅の制御と、一部のフローに最小レートの割り当てを可能にします。
Receiver window tuning is also done in [Key04], where choosing the right value for the window is phrased as an optimization problem. On this basis, two algorithms are presented, binary search (which is faster than the other one at achieving a good operation point but fluctuates) and stochastic optimization (which does not fluctuate but converges slower than binary search). These algorithms merely use the previous receiver window and the amount of data received during the previous control interval as input. According to [Key04], the encouraging simulation results suggest that such an application-level mechanism can work almost as well as a transport-layer scheme like TCP-LP.
受信機ウィンドウの調整は[key04]でも行われます。ここでは、ウィンドウの正しい値を選択することは最適化の問題として表現されます。これに基づいて、2つのアルゴリズムが表示されます。バイナリ検索（優れた動作点を達成するが、変動する他のアルゴリスよりも速い）と確率的最適化（変動しないがバイナリ検索よりも遅く収束します）。これらのアルゴリズムは、以前のコントロール間隔中に入力として受信したデータの量を使用するだけです。[Key04]によれば、奨励されたシミュレーション結果は、このようなアプリケーションレベルのメカニズムがTCP-LPのような輸送層スキームとほぼ同様に機能することを示唆しています。
Another way of dealing with non-interactive flows, like web prefetching, is to rate-limit the transfer of such bursty traffic [Cro98b]. Note that one of the techniques used in [Cro98b] is, precisely, to have the downloading application adapt the TCP receiver window, so as to reduce the data rate to the minimum needed (thus disturbing other flows as little as possible while respecting a deadline for the transfer of the data).
Webプリフェッチのような非対話フローに対処する別の方法は、そのようなバーストトラフィックの転送を評価することです[CRO98B]。[CRO98B]で使用される手法の1つは、データレートを最小限に抑えるために、ダウンロードアプリケーションにTCPレシーバーウィンドウを適応させることであることに注意してください（したがって、期限を尊重しながら他のフローを可能な限り妨害することです。データの転送用）。
Network-layer mechanisms, like active queue management (AQM) and packet scheduling in routers, can be exploited by a transport protocol for achieving an LBE service. Such approaches may result in improved protection of non-LBE flows (e.g., when scheduling is used); besides, approaches using an explicit, AQM-based congestion signaling may arguably be more robust than, say, delay-based transports for detecting impending congestion. However, an obvious drawback of any network-assisted approach is that, in principle, they need modifications in both end-hosts and intermediate network nodes.
アクティブキュー管理（AQM）やルーターのパケットスケジューリングなどのネットワーク層メカニズムは、LBEサービスを達成するためのトランスポートプロトコルによって活用される可能性があります。このようなアプローチは、非LBEフローの保護が改善される可能性があります（たとえば、スケジューリングが使用される場合）。その上、明示的なAQMベースの混雑シグナル伝達を使用したアプローチは、たとえば、差し迫った混雑を検出するための遅延ベースのトランスポートよりも間違いなく堅牢である可能性があります。ただし、ネットワーク支援アプローチの明らかな欠点は、原則として、エンドホストと中間ネットワークノードの両方で変更が必要であることです。
Harp [Kok04] realizes an LBE service by dissipating background traffic to less-utilized paths of the network, based on multipath routing and multipath congestion control. This is achieved without changing all routers, by using edge nodes as relays. According to the authors, these edge nodes should be gateways of organizations in order to align their scheme with usage incentives, but the technical solution would also work if Harp was only deployed in end-hosts. It detects impending congestion by looking at delay, similar to TCP Nice [Ven02], and manages to improve the utilization and fairness of TCP over pure single-path solutions without requiring any changes to the TCP itself.
HARP [KOK04]は、マルチパスルーティングとマルチパス輻輳制御に基づいて、ネットワークのあまり活用されていないパスにバックグラウンドトラフィックを消散させることにより、LBEサービスを実現します。これは、エッジノードをリレーとして使用することにより、すべてのルーターを変更することなく達成されます。著者によると、これらのエッジノードは、スキームを使用するインセンティブに合わせるために組織のゲートウェイである必要がありますが、Harpがエンドホストでのみ展開された場合には技術的なソリューションも機能します。TCP Nice [ven02]と同様に、遅延を調べることで差し迫った輻輳を検出し、TCP自体に変更を必要とせずに、純粋なシングルパスソリューションよりもTCPの利用と公平性を改善することができます。
Another technique is that used by protocols like Network-Friendly TCP (NF-TCP) [Aru10], where a bandwidth-estimation module integrated into the transport protocol allows to rapidly take advantage of free capacity. NF-TCP combines this with an early congestion detection based on Explicit Congestion Notification (ECN) [RFC3168] and RED [RFC2309]; when congestion starts building up, appropriate tuning of a RED queue allows to mark low-priority (i.e., NF-TCP) packets with a much higher probability than high-priority (i.e., standard TCP) packets, so low-priority flows yield up bandwidth before standard TCP flows. NF-TCP could be implemented by adapting the congestion control behavior of TCP without requiring to change the protocol on the wire -- with the only exception that NF-TCP-capable routers must be able to somehow distinguish NF-TCP traffic from other TCP traffic.
もう1つの手法は、ネットワークに優しいTCP（NF-TCP）[ARU10]などのプロトコルで使用されていることです。このプロトコルに統合された帯域幅推定モジュールにより、自由容量を迅速に利用できるようになります。NF-TCPは、これを明示的な混雑通知（ECN）[RFC3168]および赤[RFC2309]に基づいた早期輻輳検出と組み合わせています。輻輳が蓄積し始めると、赤いキューの適切な調整により、優先順位（つまり、標準TCP）パケットよりもはるかに高い確率で優先順位（つまり、NF-TCP）パケットをマークすることができます。標準のTCPが流れる前の帯域幅。NF-TCPは、ワイヤー上のプロトコルを変更することを要求することなくTCPの輻輳制御挙動を適応させることで実装できます。NF-TCP対応ルーターは、NF-TCPトラフィックと何らかの形で他のTCPトラフィックを区別できる必要があるという唯一の例外を除きます。。
In [Ven08], Venkataraman et al. propose a transport-layer approach to leverage an existing, network-layer LBE service based on priority queueing. Their transport protocol, which they call PLT (Priority-Layer Transport), splits a layer-4 connection into two flows, a high-priority one and a low-priority one. The high-priority flow is sent over the higher-priority queueing class (in principle, offering a best-effort service) using an AIMD, TCP-like congestion control mechanism. The low-priority flow, which is mapped to the LBE class, uses a non TCP-friendly congestion control algorithm. The goal of PLT is thus to maximize its aggregate throughput by exploiting unused capacity in an aggressive way, while protecting standard TCP flows carried by the best-effort class. Similar in spirit, [Ott03] proposes simple changes to only the AIMD parameters of TCP for use over a network-layer LBE service, so that such "filler" traffic may aggressively consume unused bandwidth. Note that [Ven08] also considers a mechanism for detecting the lack of priority queueing in the network, so that the non-TCP friendly flow may be inhibited. The PLT receiver monitors the loss rate of both flows; if the high-priority flow starts seeing losses while the low-priority one does not experience 100% loss, this is taken as an indication of the absence of strict priority queueing.
[Ven08]では、Venkataraman et al。優先キューイングに基づいて、既存のネットワーク層LBEサービスを活用するための輸送層アプローチを提案します。PLT（優先順位層輸送）と呼ばれる輸送プロトコルは、レイヤー-4接続を2つのフロー、より優先順位のあるフローと低優先度のあるフローに分割します。より優先順位のフローは、AIMDのTCP様輻輳制御メカニズムを使用して、より優先順位のあるキューイングクラス（原則として、最良のサービスを提供する）に送信されます。LBEクラスにマッピングされた低優先順位は、非TCPに優しい混雑制御アルゴリズムを使用します。したがって、PLTの目標は、未使用の容量を積極的に活用しながら、最高のエフォルトクラスによって運ばれる標準的なTCPフローを保護することにより、その集約スループットを最大化することです。精神が同様に、[OTT03]は、ネットワーク層LBEサービスで使用するためのTCPのAIMDパラメーターのみに単純な変更を提案しているため、このような「フィラー」トラフィックにより未使用の帯域幅が積極的に消費される可能性があります。[VEN08]は、非TCPに敏感なフローが阻害されるように、ネットワーク内の優先順位のキューイングの欠如を検出するメカニズムも考慮していることに注意してください。PLTレシーバーは、両方のフローの損失率を監視します。優先順位の低下が損失を発見し、低優先順位が100％の損失を経験しない場合、これは厳格な優先順位のキューイングがないことを示しています。
The previous sections have shown that there is a large amount of work on attaining an LBE service, and that it is quite heterogeneous in nature. The algorithm developed by the LEDBAT working group [Sha11] can be classified as a delay-based mechanism; as such, it is similar in spirit to the protocols presented in Section 2. It is, however, not a protocol -- how it is actually applied to the Internet, i.e., how to use existing or even new transport protocols together with the LEDBAT algorithm, is not defined by the LEDBAT working group. As it heavily relies on delay, the discussion in Sections 2.1 and 2.2 applies to it. The performance of LEDBAT has been analyzed in comparison with some of the other work presented here in several articles, e.g. [Aru10], [Car10], [Sch10], but these analyses have to be examined with care: at the time of writing, LEDBAT was still a moving target.
以前のセクションでは、LBEサービスの達成に関する大量の作業があり、本質的に非常に異質であることが示されています。LEDBATワーキンググループ[SHA11]によって開発されたアルゴリズムは、遅延ベースのメカニズムとして分類できます。そのため、セクション2で提示されているプロトコルに精神的に似ています。ただし、プロトコルではありません。実際にインターネットに適用される方法、つまり既存または新しいトランスポートプロトコルをLEDBATと一緒に使用する方法アルゴリズムは、LEDBATワーキンググループによって定義されていません。遅延に大きく依存しているため、セクション2.1と2.2の議論が適用されます。LEDBATのパフォーマンスは、いくつかの記事で紹介する他の研究のいくつかと比較して分析されています。[aru10]、[car10]、[sch10]が、これらの分析は注意して調べる必要があります。執筆時点では、ledbatは依然として動いているターゲットでした。
The authors would like to thank Melissa Chavez, Dragana Damjanovic, and Yinxia Zhao for reference pointers, as well as Jari Arkko, Mayutan Arumaithurai, Elwyn Davies, Wesley Eddy, Stephen Farrell, Mirja Kuehlewind, Tina Tsou, and Rolf Winter for their detailed reviews and suggestions.
著者は、参照ポインターについては、メリッサ・チャベス、ドラガナ・ダムジャノビッチ、Yinxia Zhao、およびJari Arkko、Mayutan Arumaithurai、Elwyn Davies、Wesley Eddy、Stephen Farrell、Mirja Kuehlewind、Tina Tsou、Rolf Winterに感謝します。と提案。
This document introduces no new security considerations.
このドキュメントでは、新しいセキュリティ上の考慮事項は紹介されていません。
[Aru10] Arumaithurai, M., Fu, X., and K. Ramakrishnan, "NF-TCP: A Network Friendly TCP Variant for Background Delay-Insensitive Applications", Technical Report No. IFI-TB-2010-05, Institute of Computer Science, University of Goettingen, Germany, September 2010, <http:// www.net.informatik.uni-goettingen.de/publications/1718/ NF-TCP-techreport.pdf>.
[Aru10] Arumaithurai、M.、Fu、X。、およびK. Ramakrishnan、「NF-TCP：バックグラウンド遅延非感受性アプリケーション用のネットワークに優しいTCPバリアント」、テクニカルレポート番号IFI-TB-2010-05、Institute of of ofコンピューターサイエンス、ドイツ、ゲッティンゲン大学、2010年9月、<http：// www.net.informatik.uni-goettingen.de/publications/1718/ nf-tcp-techreport.pdf>。
[BITS] Microsoft, "Windows Background Intelligent Transfer Service", <http://msdn.microsoft.com/library/bb968799(VS.85).aspx>.
[ビット] Microsoft、「Windows Background Intelligent Transfer Service」、<http://msdn.microsoft.com/library/bb968799（vs.85）.aspx>。
[Bha07] Bhandarkar, S., Reddy, A., Zhang, Y., and D. Loguinov, "Emulating AQM from end hosts", Proceedings of ACM SIGCOMM 2007, 2007.
[Bha07] Bhandarkar、S.、Reddy、A.、Zhang、Y。、およびD. Loguinov、「エンドホストからのAQMをエミュレート」、ACM Sigcomm 2007、2007の議事録。
[Bia03] Biaz, S. and N. Vaidya, "Is the round-trip time correlated with the number of packets in flight?", Proceedings of the 3rd ACM SIGCOMM conference on Internet measurement (IMC '03), pages 273-278, 2003.
[BIA03] Biaz、S。およびN. Vaidya、「往復時間は飛行中のパケットの数と相関していますか？」、第3回ACM Sigcomm Conference on Internet Measurement（IMC '03）、273-278ページの議事録、2003年。
[Bra94] Brakmo, L., O'Malley, S., and L. Peterson, "TCP Vegas: New techniques for congestion detection and avoidance", Proceedings of SIGCOMM '94, pages 24-35, August 1994.
[Bra94] Brakmo、L.、O'Malley、S。、およびL. Peterson、「TCP Vegas：Commestion検出と回避のための新しい技術」、Sigcomm '94の議事録、24〜35ページ、1994年8月。
[Car10] Carofiglio, G., Muscariello, L., Rossi, D., and S. Valenti, "The quest for LEDBAT fairness", Proceedings of IEEE GLOBECOM 2010, December 2010.
[Car10] Carofiglio、G.、Muscariello、L.、Rossi、D。、およびS. Valenti、「Ledbat Fairnessの探求」、IEEE Globecom 2010の議事録、2010年12月。
[Cha10] Chan, Y., Lin, C., Chan, C., and C. Ho, "CODE TCP: A competitive delay-based TCP", Computer Communications, 33(9):1013-1029, June 2010.
[Cha10] Chan、Y.、Lin、C.、Chan、C。、およびC. Ho、「コードTCP：競争遅延ベースのTCP」、コンピューター通信、33（9）：1013-1029、2010年6月。
[Cro98] Crowcroft, J. and P. Oechslin, "Differentiated end-to-end Internet services using a weighted proportional fair sharing TCP", ACM SIGCOMM Computer Communication Review, vol. 28, no. 3, pp. 53-69, July 1998.
[CRO98] Crowcroft、J。およびP. Oechslin、「加重比例フェア共有TCPを使用したエンドツーエンドのインターネットサービス」、ACM Sigcomm Computer Communication Review、Vol。28、いいえ。3、pp。53-69、1998年7月。
[Cro98b] Crovella, M. and P. Barford, "The network effects of prefetching", Proceedings of IEEE INFOCOM 1998, April 1998.
[CRO98B] Crovella、M。およびP. Barford、「プリフェッチのネットワーク効果」、IEEE Infocom 1998の議事録、1998年4月。
[Dam09] Damjanovic, D. and M. Welzl, "MulTFRC: Providing Weighted Fairness for Multimedia Applications (and others too!)", ACM Computer Communication Review, vol. 39, no. 3, July 2009.
[DAM09] Damjanovic、D。およびM. Welzl、「Multfrc：Multimediaアプリケーション（およびその他も）に加重公平性を提供する」、ACM Computer Communication Review、Vol。39、いいえ。3、2009年7月。
[Dev03] De Vendictis, A., Baiocchi, A., and M. Bonacci, "Analysis and enhancement of TCP Vegas congestion control in a mixed TCP Vegas and TCP Reno network scenario", Performance Evaluation, 53(3-4):225-253, 2003.
[dev03] de Vendictis、A.、Baiocchi、A。、およびM. Bonacci、「混合TCPベガスとTCP RenoネットワークシナリオにおけるTCPベガス混雑制御の分析と強化」、パフォーマンス評価、53（3-4）：225-253、2003。
[Dyk02] Dykes, S. and K. Robbins, "Limitations and benefits of cooperative proxy caching", IEEE Journal on Selected Areas in Communications, 20(7):1290-1304, September 2002.
[Dyk02] Dykes、S。and K. Robbins、「協同組合プロキシキャッシュの制限と利点」、Communicationsの選択された領域に関するIEEEジャーナル、20（7）：1290-1304、2002年9月。
[Egg05] Eggert, L. and J. Touch, "Idletime Scheduling with Preemption Intervals", Proceedings of 20th ACM Symposium on Operating Systems Principles, SOSP 2005, Brighton, United Kingdom, pp. 249/262, October 2005.
[Egg05] Eggert、L。and J. Touch、「先制間隔を備えたIdletimeスケジューリング」、オペレーティングシステム原則に関する第20回ACMシンポジウムの議事録、SOSP 2005、ブライトン、イギリス、pp。249/262、2005年10月。
[Gur04] Gurtov, A. and S. Floyd, "Modeling wireless links for transport protocols", ACM SIGCOMM Computer Communications Review, 34(2):85-96, April 2004.
[Gur04] Gurtov、A。およびS. Floyd、「輸送プロトコルのワイヤレスリンクのモデリング」、ACM Sigcomm Computer Communications Review、34（2）：85-96、2004年4月。
[Hac04] Hacker, T., Noble, B., and B. Athey, "Improving Throughput and Maintaining Fairness using Parallel TCP", Proceedings of IEEE INFOCOM 2004, March 2004.
[HAC04] Hacker、T.、Noble、B。、およびB. Athey、「スループットの改善と並列TCPを使用した公平性の維持」、IEEE Infocom 2004、2004年3月の議事録。
[Hac08] Hacker, T. and P. Smith, "Stochastic TCP: A Statistical Approach to Congestion Avoidance", Proceedings of PFLDnet 2008, March 2008.
[HAC08] Hacker、T。およびP. Smith、「確率的TCP：混雑回避への統計的アプローチ」、PFLDNET 2008、2008年3月の議事録。
[Hay10] Hayes, D., "Timing enhancements to the FreeBSD kernel to support delay and rate based TCP mechanisms", Technical Report 100219A, Centre for Advanced Internet Architectures, Swinburne University of Technology, February 2010.
[Hay10] Hayes、D。、「遅延とレートベースのTCPメカニズムをサポートするためのFreeBSDカーネルのタイミングの強化」、テクニカルレポート100219A、Advanced Internet Architectures Center、Swinburne大学、2010年2月。
[Hen00] Hengartner, U., Bolliger, J., and T. Gross, "TCP Vegas revisited", Proceedings of IEEE INFOCOM 2000, March 2000.
[HEN00] Hengartner、U.、Bolliger、J。、およびT. Gross、「TCP Vegas Revisited」、IEEE Infocom 2000、2000年3月の議事録。
[Jai89] Jain, R., "A delay-based approach for congestion avoidance in interconnected heterogeneous computer networks", ACM Computer Communication Review, 19(5):56-71, October 1989.
[Jai89] Jain、R。、「相互接続された不均一なコンピューターネットワークにおける混雑回避のための遅延ベースのアプローチ」、ACMコンピューター通信レビュー、19（5）：56-71、1989年10月。
[Key04] Key, P., Massoulie, L., and B. Wang, "Emulating Low-Priority Transport at the Application Layer: a Background Transfer Service", Proceedings of ACM SIGMETRICS 2004, January 2004.
[Key04] Key、P.、Massoulie、L。、およびB. Wang、「アプリケーション層での低優先度輸送のエミュレート：バックグラウンド転送サービス」、ACM Sigmetrics 2004の議事録、2004年1月。
[Kok04] Kokku, R., Bohra, A., Ganguly, S., and A. Venkataramani, "A Multipath Background Network Architecture", Proceedings of IEEE INFOCOM 2007, May 2007.
[Kok04] Kokku、R.、Bohra、A.、Ganguly、S。、およびA. Venkataramani、「マルチパスバックグラウンドネットワークアーキテクチャ」、IEEE Infocom 2007、2007年5月の議事録。
[Kon09] Konda, V. and J. Kaur, "RAPID: Shrinking the Congestion-control Timescale", Proceedings of IEEE INFOCOM 2009, April 2009.
[Kon09] Konda、V。およびJ. Kaur、「Rapid：Shrinking the Commastion-Control Timescale」、IEEE Infocom 2009の議事録、2009年4月。
[Kuo08] Kuo, F. and X. Fu, "Probe-Aided MulTCP: an aggregate congestion control mechanism", ACM SIGCOMM Computer Communication Review, vol. 38, no. 1, pp. 17-28, January 2008.
[Kuo08] Kuo、F。およびX. Fu、「プローブ支持マルチ：凝集渋滞制御メカニズム」、ACM Sigcomm Computer Communication Review、Vol。38、いいえ。1、pp。17-28、2008年1月。
[Kur00] Kurata, K., Hasegawa, G., and M. Murata, "Fairness Comparisons Between TCP Reno and TCP Vegas for Future Deployment of TCP Vegas", Proceedings of INET 2000, July 2000.
[KUR00] Kurata、K.、Hasegawa、G。、およびM. Murata、「TCP Vegasの将来の展開のためのTCP RenoとTCP Vegasの公平性比較」、2000年7月のINET 2000年の議事録。
[Kuz06] Kuzmanovic, A. and E. Knightly, "TCP-LP: low-priority service via end-point congestion control", IEEE/ACM Transactions on Networking (ToN), Volume 14, Issue 4, pp. 739-752., August 2006, <http://www.ece.rice.edu/networks/TCP-LP/>.
[Kuz06] Kuzmanovic、A。and E. Knightly、「TCP-LP：エンドポイント輻輳制御による低優先サービス」、IEEE/ACMトランザクションに関するネットワーキング（TON）、第14巻、第4号、pp。739-752ページ。、2006年8月、<http://www.ece.rice.edu/networks/tcp-lp/>。
[Liu07] Liu, S., Vojnovic, M., and D. Gunawardena, "Competitive and Considerate Congestion Control for Bulk Data Transfers", Proceedings of IWQoS 2007, June 2007.
[Liu07] Liu、S.、Vojnovic、M。、およびD. Gunawardena、「バルクデータ転送のための競争的で思いやりのある混雑制御」、IWQOS 2007の議事録、2007年6月。
[Liu08] Liu, S., Basar, T., and R. Srikant, "TCP-Illinois: A loss-and delay-based congestion control algorithm for high-speed networks", Performance Evaluation, 65(6-7):417-440, 2008.
[Liu08] Liu、S.、Basar、T。、およびR. Srikant、「TCP-Illinois：高速ネットワークの損失と遅延ベースの混雑制御アルゴリズム」、パフォーマンス評価、65（6-7）：417-440、2008。
[Mar03] Martin, J., Nilsson, A., and I. Rhee, "Delay-based congestion avoidance for TCP", IEEE/ACM Transactions on Networking, 11(3):356-369, June 2003.
[MAR03] Martin、J.、Nilsson、A。、およびI. Rhee、「TCPの遅延ベースの混雑回避」、ネットワーキングに関するIEEE/ACMトランザクション、11（3）：356-369、2003年6月。
[McC08] McCullagh, G. and D. Leith, "Delay-based congestion control: Sampling and correlation issues revisited", Technical report, Hamilton Institute, 2008.
[MCC08] McCullagh、G。およびD. Leith、「遅延ベースの混雑制御：サンプリングと相関の問題が再検討された」、テクニカルレポート、Hamilton Institute、2008。
[Meh03] Mehra, P., Zakhor, A., and C. De Vleeschouwer, "Receiver-Driven Bandwidth Sharing for TCP", Proceedings of IEEE INFOCOM 2003, April 2003.
[Meh03] Mehra、P.、Zakhor、A。、およびC. de Vleeschouwer、「TCPのレシーバー駆動型帯域幅共有」、IEEE Infocom 2003、2003年4月の議事録。
[Mo99] Mo, J., La, R., Anantharam, V., and J. Walrand, "Analysis and Comparison of TCP Reno and TCP Vegas", Proceedings of IEEE INFOCOM 1999, March 1999.
[Mo99] Mo、J.、La、R.、Anantharam、V。、およびJ. Walrand、「TCP RenoとTCP Vegasの分析と比較」、IEEE Infocom 1999、1999年3月の議事録。
[Ott03] Ott, B., Warnky, T., and V. Liberatore, "Congestion control for low-priority filler traffic", SPIE QoS 2003 (Quality of Service over Next-Generation Internet), In Proc. SPIE, Vol. 5245, 154, Monterey (CA), USA, July 2003.
[OTT03] Ott、B.、Warnky、T。、およびV. Liberatore、「低優先充填剤の交通のための渋滞制御」、SPIE QOS 2003（次世代インターネット上のサービス品質）、Proc。Spie、vol。5245、154、モントレー（CA）、米国、2003年7月。
[Pra04] Prasad, R., Jain, M., and C. Dovrolis, "On the effectiveness of delay-based congestion avoidance", Proceedings of PFLDnet, 2004.
[PRA04] Prasad、R.、Jain、M。、およびC. Dovrolis、「遅延ベースの混雑回避の有効性に関する」、Pfldnetの議事録、2004年。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、B。、およびD. Borman、「TCP拡張のためのTCP拡張」、RFC 1323、1992年5月。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309] Braden、B.、Clark、D.、Crowcroft、J.、Davie、B.、Deering、S.、Estrin、D.、Floyd、S.、Jacobson、V.、Minshall、G.、Partridge、C.、Peterson、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J。、およびL. Zhang、「インターネットにおけるキュー管理と混雑回避に関する推奨事項」、RFC 2309、1998年4月。
[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月。
[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月。
[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月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP混雑制御」、RFC 5681、2009年9月。
[Rew06] Rewaskar, S., Kaur, J., and D. Smith, "Why don't delay-based congestion estimators work in the real-world?", Technical report TR06-001, University of North Carolina at Chapel Hill, Dept. of Computer Science, January 2006.
[Rew06] Rewaskar、S.、Kaur、J。、およびD. Smith、「なぜ遅延ベースの混雑推定器が現実世界で機能しないのですか？」、テクニカルレポートTR06-001、ノースカロライナ大学チャペルヒル大学、コンピューターサイエンス部、2006年1月。
[Sch10] Schneider, J., Wagner, J., Winter, R., and H. Kolbe, "Out of my Way -- Evaluating Low Extra Delay Background Transport in an ADSL Access Network", Proceedings of the 22nd International Teletraffic Congress ITC22, 2010.
[Sch10] Schneider、J.、Wagner、J.、Winter、R.、およびH. Kolbe、「私の邪魔にならない - ADSLアクセスネットワークでの低い余分な遅延バックグラウンド輸送の評価」、第22回国際テレトラフィック議会の議事録ITC22、2010。
[Sha05] Shalunov, S., Dunn, L., Gu, Y., Low, S., Rhee, I., Senger, S., Wydrowski, B., and L. Xu, "Design Space for a Bulk Transport Tool", Technical Report, Internet2 Transport Group, May 2005.
[Sha05] Shalunov、S.、Dunn、L.、Gu、Y.、Low、S.、Rhee、I.、Senger、S.、Wydrowski、B。、およびL. Xu、「バルク輸送用の設計スペースツール」、テクニカルレポート、Internet2 Transport Group、2005年5月。
[Sha11] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", Work in Progress, May 2011.
[Sha11] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extric Delay Background Transport（LEDBAT）」、2011年5月の進行中。
[Spr00] Spring, N., Chesire, M., Berryman, M., Sahasranaman, V., Anderson, T., and B. Bershad, "Receiver based management of low bandwidth access links", Proceedings of IEEE INFOCOM 2000, pp. 245-254, vol. 1, 2000.
[SPR00] Spring、N.、Chesire、M.、Berryman、M.、Sahasranaman、V.、Anderson、T.、およびB. Bershad、「低帯域幅アクセスリンクの受信者ベースの管理」、IEEE Infocom 2000の議事録、pp。245-254、vol。1、2000。
[Sri08] Sridharan, M., Tan, K., Bansala, D., and D. Thaler, "Compound TCP: A New TCP Congestion Control for High-Speed and Long Distance Networks", Work in Progress, November 2008.
[SRI08] Sridharan、M.、Tan、K.、Bansala、D。、およびD. Thaler、「化合物TCP：高速および長距離ネットワークの新しいTCP混雑制御」、2008年11月の作業。
[Tan06] Tan, K., Song, J., Zhang, Q., and M. Sridharan, "A Compound TCP approach for high-speed and long distance networks", Proceedings of IEEE INFOCOM 2006, Barcelona, Spain, April 2008.
[Tan06] Tan、K.、Song、J.、Zhang、Q.、およびM. Sridharan、「高速および長距離ネットワークの複合TCPアプローチ」、IEEE Infocom 2006、バルセロナ、スペイン、2008年4月の議事録。
[Ven02] Venkataramani, A., Kokku, R., and M. Dahlin, "TCP Nice: a mechanism for background transfers", Proceedings of OSDI '02, 2002.
[ven02] Venkataramani、A.、Kokku、R。、およびM. Dahlin、「TCP Nice：A Mechanism for Background Transfers」、Proceedings of OSDI '02、2002。
[Ven08] Venkataraman, V., Francis, P., Kodialam, M., and T. Lakshman, "A priority-layered approach to transport for high bandwidth-delay product networks", Proceedings of ACM CoNEXT, Madrid, December 2008.
[Ven08] Venkataraman、V.、Francis、P.、Kodialam、M.、およびT. Lakshman、「高帯域幅遅延製品ネットワークの輸送への優先順位に覆われたアプローチ」、ACM Conextの議事録、2008年12月。
[Wan91] Wang, Z. and J. Crowcroft, "A new congestion control scheme: slow start and search (Tri-S)", ACM Computer Communication Review, 21(1):56-71, January 1991.
[WAN91] Wang、Z。およびJ. Crowcroft、「新しい混雑制御スキーム：スロースタートと検索（TRI-S）」、ACMコンピューター通信レビュー、21（1）：56-71、1991年1月。
[Wan92] Wang, Z. and J. Crowcroft, "Eliminating periodic packet losses in the 4.3-Tahoe BSD TCP congestion control algorithm", ACM Computer Communication Review, 22(2):9-16, January 1992.
[WAN92] Wang、Z。およびJ. Crowcroft、「4.3-Tahoe BSD TCP混雑制御アルゴリズムの定期的なパケット損失の排除」、ACMコンピューター通信レビュー、22（2）：9-16、1992年1月。
[Wei05] Weigle, M., Jeffay, K., and F. Smith, "Delay-based early congestion detection and adaptation in TCP: impact on web performance", Computer Communications, 28(8):837-850, May 2005.
[Wei05] Weigle、M.、Jeffay、K。、およびF. Smith、「TCPにおける遅延ベースの早期輻輳検出と適応：Webパフォーマンスへの影響」、コンピューターコミュニケーションズ、28（8）：837-850、2005年5月。
[Wei06] Wei, D., Jin, C., Low, S., and S. Hegde, "FAST TCP: Motivation, architecture, algorithms, performance", IEEE/ ACM Transactions on Networking, 14(6):1246-1259, December 2006.
[Wei06] Wei、D.、Jin、C.、Low、S。、およびS. Hegde、「高速TCP：動機、アーキテクチャ、アルゴリズム、パフォーマンス」、IEEE/ ACMトランザクション、14（6）：1246-1259、2006年12月。
Authors' Addresses
著者のアドレス
Michael Welzl University of Oslo Department of Informatics, PO Box 1080 Blindern N-0316 Oslo Norway
マイケル・ウェルツルオスロ大学情報学部、PO Box 1080 Blindern N-0316 OSLO NORWAY
Phone: +47 22 85 24 20
EMail: michawe@ifi.uio.no
David Ros Institut Telecom / Telecom Bretagne Rue de la Chataigneraie, CS 17607 35576 Cesson Sevigne cedex France
David Ros Institut Telecom / Telecom Bretagne Rue de la Chataigneraie、CS 17607 35576 CESSON SEVIGNE CEDEX FRANCE
Phone: +33 2 99 12 70 46
EMail: david.ros@telecom-bretagne.eu