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
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的带宽和/或延迟影响小于标准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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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的带宽和/或延迟影响小于标准TCP本身的服务。我们将设计用于提供此服务的系统称为LBE系统。除了TCP Vegas（我们出于历史原因提出）之外，我们排除了在某些情况下表现出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概念相关，但没有提供可安装在终端主机中或预期通过互联网工作的解决方案（例如，存在基于区分服务的低工作量服务[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通常会增加其拥塞窗口（和有效发送速率），直到队列溢出，导致一个或多个数据包被丢弃，有效速率降低。原则上，在事件发生之前停止增加速率的协议可以实现比标准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 Vegas[Bra94]是已知在两个协议共享瓶颈[Kur00]时具有比标准TCP更小的发送速率的首批协议之一——然而，它的设计目的是实现比标准TCP更多而不是更少的吞吐量。事实上，当TCP Vegas是通过瓶颈的流使用的唯一拥塞控制算法时，其吞吐量大于标准TCP的吞吐量。根据瓶颈队列长度，TCP Vegas本身可能会被标准TCP流耗尽。这可以通过随机早期检测（RED）主动队列管理机制[RFC2309]在一定程度上解决。Vegas根据预期吞吐量和实际吞吐量之间的差异线性增加或减少发送速率。该估算基于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
拥塞避免行为是协议在历史相关性以及本文档上下文中的相关性方面最重要的特征（已经证明，协议的其他元素有时可以对其整体行为发挥更大的作用[Hen00]）。在拥塞避免中，每RTT一次，TCP Vegas将预期吞吐量计算为WindowsSize/BaseRTT，其中WindowsSize是当前拥塞窗口，BaseRTT是所有测量RTT的最小值。然后将预期吞吐量与根据最近的确认测量的实际吞吐量进行比较。如果实际吞吐量小于
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.
预期吞吐量减去称为“beta”的阈值，这被视为拥塞的标志，导致协议线性降低其速率。如果实际吞吐量大于预期吞吐量减去称为“alpha”的阈值（alpha<beta），则这被视为网络未充分利用的标志，导致协议线性增加其速率。
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 Vegas最突出的特性之一是它在相同类型的多个流之间的公平性，这不会像标准TCP那样惩罚具有大传播延迟的流。虽然这不是第一个使用延迟作为拥塞指示的协议，但由于TCP Vegas在文献中扮演的历史性“里程碑”角色，其前身（如CARD[Jai89]、Tri-S[Wan91]或DUAL[Wan92]）在此不作讨论。
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 Vegas相同的基本方法，但在某些方面有所改进。由于其适度的线性减少拥塞响应，TCP Vegas可以影响标准TCP，尽管它能够早期检测拥塞。TCP Nice通过将拥塞窗口减半（与标准TCP一样，每个RTT最多一次）而不是线性减少来消除此问题。为了避免过于保守，只有在一个RTT内出现基于延迟的初始拥塞信号的固定预定义部分时，才可以这样做。否则，如果没有数据包丢失，TCP Nice将返回TCP Vegas的拥塞避免规则，如果数据包丢失，则返回标准TCP。TCP Nice的另一个特性是，通过在多个RTT上发送单个数据包，它能够支持小于一个数据包的拥塞窗口。[Ven02]的作者通过ns-2仿真和使用Linux实现的实际实验表明，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
除了TCP Vegas和TCP Nice之外，TCP-LP[Kuz06]仅使用单向延迟（OWD）而不是RTT作为初期拥塞的指标。这样做是为了避免对反向交叉交通引起的延迟波动作出反应。使用TCP时间戳选项[RFC1323]，OWD被确定为ACK中接收器的时间戳值与接收器复制到ACK中的原始时间戳值之间的差值。虽然此减法的结果只能精确表示时钟同步时的OWD，但其绝对值与TCP-LP无关，因此不需要时钟同步。TCP-LP使用常数平滑参数计算测量OWD的指数加权移动平均值（EWMA），并检查结果是否超过最小值和最小值范围内的阈值
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.
连接生存期内看到的最大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试图在过于保守的选择（立即将拥塞窗口设置为一个数据包）和过于激进的选择（简单地将拥塞窗口减半，如标准TCP）之间找到一个中间点；TCP-LP尝试通过额外的RTT延迟前一个操作，以查看是否存在持续拥塞。它首先响应早期拥塞指示将窗口减半，然后初始化“推断超时计时器”，并保持当前拥塞窗口，直到该计时器触发。如果在此“推断阶段”期间出现另一个早期拥塞指示，则将窗口设置为1；否则，窗口将保持不变，TCP-LP将以标准的加法增加方式继续增加窗口。此方法确保TCP-LP流至少需要两个RTT才能将其窗口减少到1，并且与标准TCP一样，TCP-LP每个RTT最多对拥塞做出一次反应。
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之间的非线性关系，即使所考虑的流的RTT大于标准TCP流，也可以避免干扰标准TCP流量，从而说明基于延迟的LBE传输的可行性。[Kuz06]的作者通过使用Linux实现的ns-2模拟和实际实验表明，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]采用与TCP-LP类似的方法，根据OWD的变化调整其对拥塞的反应。通过将估计（平均）前向队列延迟与最大观测延迟进行比较，Sync-TCP根据观测窗口上的平均延迟所遵循的趋势来调整相加-增加-乘法-减少（AIMD）参数。尽管[Wi05]的作者没有明确地将其用作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]是基于丢失和延迟的混合机制，而其他方案（如NewVegas[Dev03]、FAST TCP[Wei06]或代码TCP[Cha10]）是主要基于延迟的Vegas的变体。
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:
基于延迟的拥塞预测器的准确性一直是大量研究的主题，例如参见[Bia03]、[Mar03]、[Pra04]、[Rew06]、[McC08]。大多数研究的主要结果是，一般而言，延误（或者更准确地说，往返时间）与拥堵的相关性较弱。有几个因素可能导致相关性差：
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 瓶颈缓冲区大小：原则上，如果缓冲区“足够大”，可以使基于延迟的机制“比TCP更友好”，以便终端主机能够以合理的精度检测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等人声称，通过采用一些简单的技术（平滑RTT样本，增加RTT采样频率），可以显著提高预测精度。尽管如此，他们承认，即使使用这种技术，也不可能消除检测错误。他们提出的基于延迟的拥塞避免方法PERT（Probabilistic Early Response 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节中列出的准确性问题。此外，像Vegas这样的协议需要保持对最小（“基本”）延迟的估计；这使得此类协议在流的生命周期内对端到端路由的最终变化高度敏感[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更友好的方面”出错，也就是说，无论拥塞是“真实的”还是“非真实的”，总是屈服于“感知的”拥塞；但是，未能检测到拥塞（由于上述精度问题之一）将导致非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].
基于延迟的机制也可能受到所谓的“后发优势”（或“后发不公平”）问题的影响。考虑瓶颈链路已经（非常）拥塞的情况。在这种情况下，延迟变化可能非常小；因此，就延迟波动而言，可能很难区分空队列和重负载队列。因此，当已经存在严重拥塞时，新到达的基于延迟的流可能开始更快地发送，最终赶走基于损失的流[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拥塞避免算法允许设置目标平均窗口，并在限制对“前景”流的影响的同时避免“背景”流的不足。它的性能在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流尝试模拟（并像模拟）多个N>1的并行TCP流。通过支持0到1之间的N值，MulTFRC可以用作LBE服务的机制。由于MulTFRC不像第2节中描述的协议那样对延迟做出反应，而是像TFRC一样调整其速率，因此MulTFRC可能比TCP Nice或TCP-LP等机制更具攻击性。这也意味着MulTFRC不太可能挨饿，因为它的攻击性在细粒度上是可调的，即使N在0到1之间。
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]中采用了一种不同的方法——在这里，通过主机操作系统中的通用空闲时间调度策略来降低流的优先级。虽然本文中的结果表明，新的调度程序可以有效地屏蔽常规任务与低优先级任务（例如，TCP与贪婪的UDP），但对性能的影响很小，这是一个基本假设，即所有相关的终端主机都将使用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
[Spr00]中描述的机制是上述技术的一个示例。这种机制通过让接收器智能地操纵标准TCP的接收器窗口来控制带宽。这是可能的，因为作者假设客户端-服务器设置，其中接收方的访问链路通常是瓶颈。该方案结合了瓶颈处预期队列长度的基于延迟的计算，这与上述基于延迟的协议（例如TCP Vegas）中的计算非常相似。使用Linux实现，其中TCP流被分类
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.
根据其应用程序的需要，Spring等人在[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等人假设瓶颈位于接收器的接入链路上。然而，后者也提出了带宽共享系统，允许控制分配给不同流的带宽，以及分配给某些流的最小速率。
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]中完成，其中为窗口选择正确的值是一个优化问题。在此基础上，提出了两种算法：二进制搜索（在获得良好的操作点时比另一种算法更快，但波动性较大）和随机优化（不波动但收敛速度慢于二进制搜索）。这些算法仅使用前一个接收器窗口和前一个控制间隔期间接收的数据量作为输入。根据[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]中使用的技术之一就是让下载应用程序调整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
Harp[Kok04]基于多路径路由和多路径拥塞控制，通过将后台流量耗散到网络中利用率较低的路径，实现LBE服务。这是在不改变所有路由器的情况下通过使用边缘节点作为中继来实现的。根据
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仅部署在终端主机中，技术解决方案也会起作用。它通过查看延迟来检测即将发生的拥塞，类似于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.
另一种技术由网络友好型TCP（NF-TCP）[Aru10]等协议使用，其中集成到传输协议中的带宽估计模块允许快速利用空闲容量。NF-TCP将其与基于显式拥塞通知（ECN）[RFC3168]和RED[RFC2309]的早期拥塞检测相结合；当拥塞开始累积时，适当调整红色队列允许标记低优先级（即NF-TCP）数据包，其概率比高优先级（即标准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等人提出了一种传输层方法，以利用现有的基于优先级排队的网络层LBE服务。他们称之为PLT（优先级层传输）的传输协议将第4层连接分成两个流，一个高优先级流和一个低优先级流。高优先级流通过更高优先级的排队类（原则上，提供尽力而为的服务）发送，使用AIMD、类似TCP的拥塞控制机制。映射到LBE类的低优先级流使用非TCP友好的拥塞控制算法。因此，PLT的目标是通过积极利用未使用的容量来最大化其总吞吐量，同时保护best effort类所承载的标准TCP流。类似的精神，[Ott03]建议只对TCP的AIMD参数进行简单更改，以便在网络层LBE服务上使用，这样“填充”流量可能会大量消耗未使用的带宽。请注意，[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.
作者要感谢Melissa Chavez、Dragana Damjanovic和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] ARUMAITURURI，M，FU，X，和K. Ramakrishnan，“NF-TCP：一个网络友好的TCP变体，用于背景延迟不敏感的应用”，技术报告编号IF-TB-201005，计算机科学学院，哥廷根大学，德国，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.，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，“往返时间是否与飞行中的数据包数量相关？”，第三届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.，O'Malley，S.，和L.Peterson，“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.，Rossi，D.，和S.Valenti，“对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]Chan，Y.，Lin，C.，Chan，C.，和C.Ho，“编码TCP：一种基于延迟的竞争性TCP”，计算机通信，33（9）：1013-10292010年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计算机通信评论，第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，“预取的网络效应”，1998年4月，IEEE信息通信会议录，1998年。
[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]De Vendictis，A.，Baiocchi，A.，和M.Bonacci，“TCP Vegas和TCP Reno混合网络场景中TCP Vegas拥塞控制的分析和增强”，性能评估，53（3-4）：225-2532003。
[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.和K.Robbins，“协作代理缓存的局限性和好处”，IEEE通信选定领域杂志，20（7）：1290-13042002年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.和J.Touch，“具有抢占间隔的空闲时间调度”，第20届ACM操作系统原理研讨会论文集，SOSP 2005，英国布莱顿，第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计算机通信评论，34（2）：85-962004年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]海因斯，D，“FreeBSD内核的时序增强以支持基于延迟和基于速率的TCP机制”，技术报告100219A，斯文本科技大学高级互联网架构中心，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拉斯维加斯重访”，IEEE信息通信会议录，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.
[Jain，R.，“互连异构计算机网络中基于延迟的拥塞避免方法”，ACM计算机通信评论，19（5）：56-711989年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，“快速：缩短拥塞控制时间尺度”，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，“探针辅助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]Kurata，K.，Hasegawa，G.，和M.Murata，“TCP Reno和TCP Vegas之间在未来部署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.和E.Knightly，“TCP-LP：通过端点拥塞控制的低优先级服务”，IEEE/ACM网络交易（ToN），第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]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伊利诺伊州：一种基于丢失和延迟的高速网络拥塞控制算法”，性能评估，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，“基于延迟的拥塞控制：重新审视采样和相关问题”，技术报告，汉密尔顿研究所，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雷诺和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.
[Ott03]Ott，B.，Warnky，T.，和V.Liberatore，“低优先级填充流量的拥塞控制”，SPIE QoS 2003（下一代互联网服务质量），在Proc。《间谍》第5245154卷，蒙特利（加利福尼亚州），美国，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扩展”，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 36622003年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友好速率控制（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 56812009年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] Reaskar，S.，Kaur，J.和D. Smith，“为什么不基于延迟的拥塞估计在现实世界中工作？”，北卡罗来纳大学教堂山分校计算机科学系，技术报告Tr06－01，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运输集团，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，“低额外延迟背景传输（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会议录，第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.，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：后台传输机制”，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-711991年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
米迦勒WelZl奥斯陆大学信息系，PO盒1080奥斯陆挪威N0316盲
Phone: +47 22 85 24 20
EMail: michawe@ifi.uio.no
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 Chataignerie，CS 17607 35576塞森塞维尼塞德克斯法国
Phone: +33 2 99 12 70 46
EMail: david.ros@telecom-bretagne.eu
Phone: +33 2 99 12 70 46
EMail: david.ros@telecom-bretagne.eu