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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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）サービスを実現するための提案の簡単な調査を提示します。それにボトルネックを共有する場合、我々は緩く、標準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の動作を達成します。この分類によれば、溶液は、遅延ベースのトランスポートプロトコル、非遅延ベースのトランスポートプロトコル、上層アプローチ、及びネットワーク支援のアプローチとして、本文書に分類されてきました。最初の二つのカテゴリーにおけるスキームのいくつかは、そのヘッダフォーマットを変更せずにTCPを使用して実施することができます。これは、インターネットでの展開を促進するであろう。彼らは唯一の既存のトランスポートプロトコルが使用される方法を説明するため、第三のカテゴリー内の方式は、設計により、導入するのが特に簡単にできるようになっています。最後に、最後のカテゴリ内のメカニズムが大幅に彼らの展開を複雑にすることができますパスに沿った機器への変更を、必要としています。
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よりもスループット - TCP Vegasが[Bra94]両方のプロトコルがボトルネック[Kur00]を共有する場合、標準のTCPよりも小さい送信レートを持つことが知られていた最初のプロトコルの一つであります。 TCPラスベガスボトルネックを通過する流れで使用される唯一の輻輳制御アルゴリズムであるとき確かに、そのスループットは、標準のTCPのスループットよりも大きくなります。ボトルネックキューの長さに応じて、TCPラスベガス自体は標準のTCPフローによって不足することができます。これは、ランダム早期検出（RED）アクティブキュー管理メカニズム[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ごとに、TCPラスベガスWindowSizeは、現在の輻輳ウィンドウとBaseRTTすべての測定のRTTの最小値であるWindowSize / BaseRTT、として予想スループットを算出します。予期されるスループットは、その後、最近確認応答に基づいて測定され、実際のスループットと比較されます。実際のスループットが期待されるスループットのマイナス「ベータ」と呼ばれる閾値より小さい場合、これは直線的にその速度を低下させるプロトコルを引き起こし、輻輳の兆候とみなされます。実際のスループットが期待されるスループットマイナス（アルファ<ベータで）「アルファ」と呼ばれる閾値よりも大きい場合、これは、プロトコルが直線的にその速度を増加させ、ネットワークが十分に活用されていること兆候とみなされます。
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 Vegasが広範囲に分析されています。 TCPラスベガスの最も顕著な特性の1つは、標準のTCPと同じように大きな伝搬遅延とフローを処罰しない同じ種類の複数のフロー間の公平さです。それが輻輳指標として遅延を使用して第1のプロトコルではありませんでしたが、その前身（CARD等[Jai89]、トライS [Wan91]、またはDUAL [Wan92]）をそのため歴史「ランドマーク」の役割をここで説明されていませんTCP Vegasが文献に取りました。
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ニース[Ven02]およびTCP低優先度（TCP-LP）[Kuz06]が含まれます。 TCPニースは[Ven02] TCPラスベガスと同じ基本的なアプローチに従いますが、いくつかの側面では、それを改善します。理由は、その適度なリニアに減少輻輳応答の、TCP Vegasが早期に輻輳を検出する能力にもかかわらず、標準のTCPに影響を与えることができます。 TCPニースではなく、直線的にそれを低下させる（高々度RTTごとに、標準TCPのような）輻輳ウィンドウを半分にすることにより、この問題を削除します。遅延ベースの初期輻輳信号の一定の所定の割合が1 RTT内に現れる場合には、あまりにも保守的であることを避けるために、これはのみ行われます。それ以外の場合は、TCPニースはバックパケットが失われた場合には何のパケットが失われたまたは標準のTCPなかった場合はTCPラスベガスの輻輳回避ルールに落ちます。 TCPニースのもう一つの特徴は、複数のRTT上の単一パケットをクロックすることで、より少ない1つのパケットの輻輳ウィンドウをサポートする能力です。 Linuxの実装を使用してNS-2シミュレーションと現実の実験では、[Ven02]の著者は、TCPニースは、標準的な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ラスベガスとTCPニース以外、TCP-LPは、[Kuz06】初期輻輳の指標として代わりRTTの唯一の一方向遅延（OWD）を使用します。これは、逆クロストラフィックによって引き起こされる変動を遅らせるために反応しないようにするために行われます。 TCPタイムスタンプオプション[RFC1323]を使用して、OWDは、ACKにおける受信機のタイムスタンプ値との差と受信機はACKにコピーした元のタイムスタンプ値として決定されます。クロックが同期している場合は、この減算の結果のみ正確OWDを表すことができるが、その絶対値は、TCP-LPへない関心事であるので、クロック同期は不要です。一定の平滑化パラメータを使用して、TCP-LPは、結果は、接続の存続期間中に見られた最小値と最大OWDの範囲内で閾値を超えたか否かを測定OWDとチェックの指数加重移動平均（EWMA）を算出します。それがない場合、この条件は「早期輻輳指示」と解釈されます。最小値と最大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は、1つのパケットに輻輳ウィンドウを設定_immediately_の過度に保守的な選択、および単に標準のTCPのような輻輳ウィンドウを半減させるという、おそらくあまりにも積極的な選択肢の間で妥協点を打つことを試みます。 TCP-LPが永続的な輻輳があるかどうかを確認するために、追加のRTTによって元の行動を遅らせるしようとします。これは、「推論タイムアウトタイマー」を初期化し、このタイマーが起動するまで、現在の輻輳ウィンドウを維持し、その後、初期の輻輳指示に応答して第1の窓を半分にすることによって、そうします。別の初期の輻輳表示は、この「推論フェーズ」中に登場した場合、ウィンドウはその後、1に設定されています。そうでない場合は、ウィンドウが維持され、TCP-LPは、標準添加-増加のファッションでそれを増加し続けています。この方法は、それが1にそのウィンドウを小さくするためにTCP-LPの流れのために、少なくとも2つのRTTをとることを保証し、そしてそれは、標準の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.
同期-TCPは、[Wei05] OWDの変化に応じて輻輳への反応を適応させることによって、TCP-LPと同様のアプローチに従います。前方観察された最大遅延にキューイング遅延推定（平均）を比較することにより、同期-TCPは、観察窓にわたる平均遅延が続く傾向に応じて添加剤増加乗法-減少（AIMD）パラメータを適応させます。 [Wei05]の著者は明示的LBEプロトコルとしての使用を考慮していないにもかかわらず、輻輳回避モードにおける標準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]であるハイブリッドloss-が遅延ベースのメカニズム、他のもの（例えば、NewVegas [Dev03]、FAST 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:
遅延に基づく渋滞予測器の精度は、[Mar03]、[Pra04]、[Rew06]、[McC08]、[Bia03]、例えば、参照、研究の良い取引の対象となっています。これらの研究のほとんどの主な結果は、遅延（または、より正確には、往復時間）は、一般的には、弱い混雑と相関していることです。貧弱な相関関係を誘導することができるいくつかの要因があります。
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ボトルネックバッファサイズ：原理的には、遅延ベースのメカニズムは、最小からRTTの変動および/または偏差がRTTがエンドホストによって検出することができるように_if_バッファ、「十分に大きい」である「TCPフレンドリ以上」作ることができます合理的な精度で。それ以外の場合は、測定ノイズから真の遅延変動を区別するのは難しいかもしれません。
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.
RTT測定の問題O：原理的には、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].
統計的多重化およびRTTのサンプリングのOレベル：個々のフローがボトルネックバッファを共有するフロー数が大きい場合は特に、損失/キューのオーバーフローイベントを「ミス」することは簡単かもしれません。これがうまく[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のら。かなりいくつかの簡単な技術（RTTサンプルの平滑化、RTTのサンプリング周波数を増加させる）を採用することにより、予測精度を向上させることができると主張しています。それにもかかわらず、彼らも、このような技術と、検出誤差を根絶することは不可能であることを認めます。それらの提案された遅延ベースの輻輳回避方法、PERT（確率初期応答TCP）は、輻輳の検出イベントに確率的応答機構により残留検出誤差の影響を軽減します。
2.2. Potential Issues with Delay-Based Congestion Control for LBE Transport
2.2. LBE輸送のための遅延ベースの輻輳制御の潜在的な問題
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.
偽陽性または遅延ベースの輻輳検出と偽陰性の問題については、ほとんどの研究は、キューのビルドアップの誤検出からと混雑の緩和の到来スループットの損失に焦点を当てます。おそらく、それは「より-より-TCPフレンドリー側」に誤る方が良いでしょうLBEトランスポートプロトコルのために、それは常に、それは「本物」であるか否かの輻輳を_perceived_し得るために、です。しかし、障害は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].
遅延ベースのメカニズムは、いわゆる「後発利点」（又は「後発不公平」）の問題に悩まされることができます。ボトルネックリンクが既に（非常に）混雑である場合を考えてみましょう。そのようなシナリオでは、遅延変動は非常に小さくてもよいです。したがって、遅延揺らぎの観点から、負荷の重いキューから空のキューを伝えることは非常に困難であろう。したがって、新たに到着遅延ベースのフロー重輻輳が既に存在する場合、最終的に[Car10] [Sha05]喪失ベースのフローを離れ駆動、高速送信を開始してもよいです。
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輻輳回避アルゴリズムは、目標平均ウィンドウを設定することを可能にし、「背景」の飢餓を避ける「前景」の流れに影響を境界ながら流れます。その性能は、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]）の主な考え方をとります。単一MulTCPフローは並列TCPフローの数N> 1をエミュレート（及びほどフレンドリーである）しよう。 0と1との間にNの値をサポートすることにより、MulTFRCはLBEサービスのためのメカニズムとして使用することができます。それは第2節で説明したプロトコルのように遅らせるように反応するが、TFRCのようなそのレートを調整していないので、MulTFRCは、おそらく、このようなTCPニースやTCP-LPなどのメカニズムよりもより積極的なことが期待できます。これはまた、Nは、0と1の間であっても、その攻撃性は、細かい粒度で調整可能であるようMulTFRCは、飢餓する傾向がしにくいことを意味します。
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]で撮影された - ここでは、フローの優先順位は、ホストのオペレーティングシステムでは、一般的なアイドル時間のスケジューリング戦略を経由して減少しています。結果は新しいスケジューラが効果的にわずかなパフォーマンスへの影響と、優先順位の低いもの（貪欲UDPから例えば、TCP）からの定期的なタスクを遮蔽することができることを本論文ショーで発表が、それはすべての関係するエンドホストが使用することを基本的な仮定がありますアイドル時間スケジューラ。言い換えれば、提示さスケジューリング方式が実装されていない可能性任意のホストから発信標準の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の実装を、使用。良好なリンク利用率を維持したまま、パケット待ち時間の大幅な改善が修飾されていないシステムを介して達成することができる[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メッセージを送信における遅延の両方を動的に指定されたレートを達成するように適合されます。 Mehraら、[Spr00]です。ボトルネックは、受信者のアクセスリンクに位置していることを前提としています。しかし、後者はまた、異なるフローに割り当てられた帯域幅だけでなく、いくつかのフローに対する最小レートの割り当ての制御を可能にする、帯域共有システムを提案します。
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).
ウェブプリフェッチのように、非対話型のフローに対処する別の方法は、[Cro98b】このようなバースト性トラフィックのレート制限転送することです。 【Cro98b]で使用される技術の一つは、正確に、必要な最小のデータレートを低減するようにダウンロードアプリケーションは、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.
ハープは[Kok04】マルチパスルーティングとマルチパス輻輳制御に基づいて、ネットワークのあまり利用パスにバックグラウンドトラフィックを放散することによってLBEサービスを実現します。これは、リレーとしてエッジノードを使用して、すべてのルータを変更することなく達成されます。著者によると、これらのエッジノードは、使用上の優遇措置とのスキームを揃えるために、組織のゲートウェイをする必要がありますが、ハープだけのエンドホストに配備された場合の技術的な解決策にも働くだろう。これは、TCPニース[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.
別の技術は、トランスポート・プロトコルに組み込ま帯域幅推定モジュールは急速に空き容量を活用することを可能にするネットワーク可TCP（NF-TCP）[Aru10]、のようなプロトコルによって使用されるということです。 NF-TCPは、明示的輻輳通知（ECN）[RFC3168]及びRED [RFC2309]に基づいて、初期輻輳検出とこれを組み合わせ。輻輳が構築起動時に、REDキューの適切なチューニングが優先度の高い（すなわち、標準TCP）よりはるかに高い確率で優先順位の低い（すなわち、NF-TCP）パケットのパケットをマークすることができますので、低優先度がアップ得流れ標準のTCPフローの前に帯域幅。 NF-TCPは、ワイヤ上のプロトコルを変更する必要なしにTCPの輻輳制御動作を適合させることにより実現することができる - 唯一の例外でNF-TCP対応ルータが何らかの形で他のTCPトラフィックからNF-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]において、ベンカタラマンら。プライオリティキューイングに基づいて、既存のネットワーク層LBEサービスを活用するトランスポート・レイヤ・アプローチを提案します。それらはPLT（優先レイヤトランスポート）を呼び出し、そのトランスポート・プロトコルは、2つの流れ、高優先度1と低優先一つにレイヤ4接続を分割します。優先度の高いフローはAIMD、TCPのような輻輳制御機構を使用して（ベストエフォート型のサービスを提供し、原則的に）優先度の高いキューイングクラスを介して送信されます。 LBEクラスにマッピングされている優先度の低いフローは、非TCPフレンドリーな輻輳制御アルゴリズムを使用しています。標準のTCPはベストエフォートクラスによって運ばフロー保護しながら、PLTの目標は、積極的な方法で、未使用の容量を活用することによって、その総スループットを最大化することです。このような「充填剤」トラフィックは積極的に未使用の帯域幅を消費するように精神に類似した、[Ott03]、ネットワーク層LBEサービス上の使用のためのTCPのみAIMDパラメータの簡単な変更を提案しています。非TCPフレンドリ流れを阻害することができるように[Ven08】また、ネットワーク内のプライオリティキューイングの欠如を検出するためのメカニズムを考慮することに注意してください。 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]によって開発されたアルゴリズムは、遅延ベースのメカニズムとして分類することができます。それは実際にインターネットにどのように適用されるか、すなわち、どのようにLEDBATとともに、既存の、あるいは新しいトランスポートプロトコルを使用する - など、それは、しかし、ではないプロトコルれる第2節で提示したプロトコルとその精神において似ていますアルゴリズムは、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.
著者は、その詳細なレビューのための参照ポインタにメリッサチャベス、Dragana Damjanovic、およびYinxia趙に感謝したい、だけでなく、ヤリArkko、Mayutan Arumaithurai、エルウィン・デイヴィス、ウェズリーエディ、スティーブン・ファレル、Mirja Kuehlewind、ティナツオウ、およびロルフ冬うそして、提案。
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.、フー、X.、およびK.ラマクリシュナン、 "NF-TCP：ネットワークフレンドリーTCPバリアント背景耐遅延アプリケーションのための" テクニカルレポートNo. IFI-TB-2010-05、研究所コンピュータサイエンス、ゲッティンゲン大学、ドイツ、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>.
[BITS]マイクロソフト、 "Windowsのバックグラウンドインテリジェント転送サービス"、<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.、レディ、A.、張、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は、「飛行中のパケット数と相関往復時間ですか？」、インターネット上の測定第三ACM SIGCOMM会議の議事録（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.、オマリー、S.、およびL.ピーターソン、 "TCPベガス：輻輳検出と回避のための新技術"、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.、ロッシ、D.、およびS.アーチャー、 "公平性LEDBATの探求"、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】チャン、Y.、リン、C.、チャン、C.、及びC.ホー、 "コード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]クロウクロフト、J.とP. Oechslin、「加重比例公平な共有のTCPを使用して差別化、エンドツーエンドのインターネットサービス」、ACM SIGCOMMコンピュータコミュニケーションレビュー、巻。 28、ありません。 3、頁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：マルチメディアアプリケーションのための加重フェアネスを提供する（そして、あまりにも他の人！）"、ACMコンピュータコミュニケーションレビュー、巻。 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】デVendictis、A.、Baiocchi、A.、およびM. Bonacci、 "分析、混合TCPラスベガスとTCPリノネットワークシナリオにおける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]コミュニケーションズダイクス、S.とK.ロビンス、「制限と協力プロキシキャッシングのメリット」選択された領域に、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]エッゲルト、L.およびJ.タッチ、「プリエンプション間隔でアイドル時間のスケジューリング」、オペレーティングシステムの原理、SOSP 2005年第20回ACMシンポジウム、ブライトン、イギリス、頁262分の249、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.フロイド、 "トランスポートプロトコルのための無線リンクのモデル化"、ACM SIGCOMMコンピュータコミュニケーションレビュー、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]ハッカー、T.、ノーブル、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]ハッカー、T.およびP.スミス、 "確率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]ヘイズ、D.は、テクニカルレポート100219A、高度なインターネットアーキテクチャ、テクノロジー、2010年2月のスウィンバーン大学センター「遅延とレートベースのTCPメカニズムをサポートするために、FreeBSDカーネルの機能強化タイミング」。
[Hen00] Hengartner, U., Bolliger, J., and T. Gross, "TCP Vegas revisited", Proceedings of IEEE INFOCOM 2000, March 2000.
[Hen00] Hengartner、U.、Bolliger、J.、およびT.グロスは、 "TCPベガスは再訪"、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]ジャイナ教、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.
、ACM SIGMETRICS 2004、2004年1月の議事録： "バックグラウンド転送サービスアプリケーション層で優先度の低いトランスポートをエミュレート" [Key04]キー、P.、Massoulie、L.、およびB.王、。
[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.、ガングリー、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】今田、V.およびJ. Kaurさん、 "RAPID：輻輳制御のタイムスケールを縮小"、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]クオ、F.およびX.フー、「プローブ援用MulTCP：集約輻輳制御機構」、ACM SIGCOMMコンピュータコミュニケーションレビュー、巻。 38、ありません。 1、頁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]倉田、K.、長谷川、G.、およびM.村田、 "TCPラスベガスの今後の展開のためのTCPリノとTCPラスベガス間の公平性の比較"、INET 2000の議事録、2000年7月。
[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.及びE.騎士、 "TCP-LP：エンドポイント輻輳制御を介して、優先度の低いサービス"、ネットワーク上のIEEE / ACMトランザクション（トン）、14巻、4号、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]劉、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]劉、S.、Basar、T.、およびR. Srikant、 "TCP-イリノイ：高速ネットワークの損失と遅延ベースの輻輳制御アルゴリズム"、性能評価、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]マーティン、J.、ニルソン、A.、およびI.李、 "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.リース、「遅延ベースの輻輳制御：サンプリングと相関の問題は再訪」、技術報告書、ハミルトン研究所、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.デブリースコーワー、 "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.、ラ、R.、Anantharam、V.、およびJ. Walrand、 "TCPリノとTCPラスベガスの分析と比較"、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.
PROCで【Ott03]オット、B.、Warnky、T.、およびV. Liberatoreの、 "低優先フィラートラフィックの輻輳制御"、SPIEのQoS 2003（次世代インターネット上でサービス品質）。 SPIE、巻。 5245、154、モントレー（CA）、USA、2003年7月。
[Pra04] Prasad, R., Jain, M., and C. Dovrolis, "On the effectiveness of delay-based congestion avoidance", Proceedings of PFLDnet, 2004.
"遅延ベースの輻輳回避の効果に関する" [Pra04]プラサド、R.、ジェイン、M.、およびC. Dovrolis、PFLDnet 2004年の議事録。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、B.、およびD.ボーマン、 "ハイパフォーマンスのための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]ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、G.、ヤマウズラ、 C.、ピーターソン、L.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.、およびL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、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.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、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]祝福、R.、ニコルズ、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]フロイド、S.、ハンドリー、M.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 5348、2008年9月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681]オールマン、M.、パクソン、V.、およびE.ブラントン、 "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.スミス、「なぜ遅延ベースの輻輳推定量は、現実世界で働くのか？」、技術報告書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]シュナイダー、J.、ワーグナー、J.、冬、R.、およびH.コルベ、「私の邪魔にならないように - 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.、ダン、L.、区、Y.、低、S.、李、I.、Sengerの、S.、Wydrowski、B.、およびL.徐、「バルク転送のためにデザインスペースツール」、技術報告書、Internet2の交通グループ、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.、ヘーゼル、G.、アイアンガー、J.、およびM. Kuehlewind、 "低余分な遅延の背景トランスポート（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]春、N.、Chesire、M.、ベリーマン、M.、Sahasranaman、V.、アンダーソン、T.、およびB.ベールシャジ、 "低帯域幅アクセスリンクの受信機ベースの管理"、IEEE INFOCOM 2000会報、 PP。245-254、巻。 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.、タン、K.、Bansala、D.、およびD.ターラー、 "化合物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]タン、K.、歌、J.、張、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.ダーリン、 "TCPニース：バックグラウンド転送するための機構"、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]ベンカタラマン、V.、フランシス、P.、Kodialam、M.、およびT.ラクシュマン、「高帯域幅遅延積ネットワークに搬送する優先度層アプローチ」、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]王、Z.およびJ.クロウクロフト、 "新しい輻輳制御方式：スロースタートと検索（トライ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]王、Z.およびJ.クロウクロフト、 "4.3-タホ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.スミス、 "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】ウェイ、D.、ジン、C.、低、S.、およびS. Hegde、 "FAST 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
情報のオスロ部門のマイケル・Welzl大学、私書箱1080 Blindern N-0316オスロノルウェー
Phone: +47 22 85 24 20 EMail: michawe@ifi.uio.no
電話：+47 22 85 24 20 Eメール：michawe@ifi.uio.no
David Ros Institut Telecom / Telecom Bretagne Rue de la Chataigneraie, CS 17607 35576 Cesson Sevigne cedex France
デビッド・ロス研究所テレコム/テレコムブルターニュルー・デ・ラ・Chataigneraie、CS 17607 35576セッソンセヴィニエセデックスフランス
Phone: +33 2 99 12 70 46 EMail: david.ros@telecom-bretagne.eu
電話：+33 2 99 12 70 46 Eメール：david.ros@telecom-bretagne.eu