Internet Engineering Task Force (IETF) S. Shalunov
Request for Comments: 6817 G. Hazel
Category: Experimental BitTorrent, Inc.
ISSN: 2070-1721 J. Iyengar
Franklin and Marshall College
M. Kuehlewind
University of Stuttgart
December 2012
Internet Engineering Task Force (IETF) S. Shalunov
Request for Comments: 6817 G. Hazel
Category: Experimental BitTorrent, Inc.
ISSN: 2070-1721 J. Iyengar
Franklin and Marshall College
M. Kuehlewind
University of Stuttgart
December 2012
Low Extra Delay Background Transport (LEDBAT)
低额外延迟背景传输（LEDBAT）
Abstract
摘要
Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows.
低额外延迟背景传输（LEDBAT）是一种实验性的基于延迟的拥塞控制算法，旨在利用端到端路径上的可用带宽，同时限制该路径上排队延迟的增加。LEDBAT使用单向延迟测量的变化来限制流量本身在网络中引起的拥塞。LEDBAT设计用于后台批量传输应用程序，其攻击性不超过标准TCP拥塞控制（如RFC 5681中所规定），并在存在竞争流时产生，从而限制对竞争流网络性能的干扰。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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/rfc6817.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6817.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ....................................................4
1.1. Requirements Notation ......................................4
1.2. Design Goals ...............................................4
1.3. Applicability ..............................................5
2. LEDBAT Congestion Control .......................................6
2.1. Overview ...................................................6
2.2. Preliminaries ..............................................6
2.3. Receiver-Side Operation ....................................7
2.4. Sender-Side Operation ......................................7
2.4.1. An Overview .........................................7
2.4.2. The Complete Sender Algorithm .......................8
2.5. Parameter Values ..........................................11
3. Understanding LEDBAT Mechanisms ................................13
3.1. Delay Estimation ..........................................13
3.1.1. Estimating Base Delay ..............................13
3.1.2. Estimating Queueing Delay ..........................13
3.2. Managing the Congestion Window ............................14
3.2.1. Window Increase: Probing for More Bandwidth ........14
3.2.2. Window Decrease: Responding to Congestion ..........14
3.3. Choosing the Queuing Delay Target .........................15
4. Discussion .....................................................15
4.1. Framing and ACK Frequency Considerations ..................15
4.2. Competing with TCP Flows ..................................15
4.3. Competing with Non-TCP Flows ..............................16
4.4. Fairness among LEDBAT Flows ...............................16
5. Open Areas for Experimentation .................................17
5.1. Network Effects and Monitoring ............................17
5.2. Parameter Values ..........................................18
5.3. Filters ...................................................19
5.4. Framing ...................................................19
6. Security Considerations ........................................19
7. Acknowledgements ...............................................20
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................20
Appendix A. Measurement Errors ....................................22
A.1. Clock Offset ...............................................22
A.2. Clock Skew .................................................22
1. Introduction ....................................................4
1.1. Requirements Notation ......................................4
1.2. Design Goals ...............................................4
1.3. Applicability ..............................................5
2. LEDBAT Congestion Control .......................................6
2.1. Overview ...................................................6
2.2. Preliminaries ..............................................6
2.3. Receiver-Side Operation ....................................7
2.4. Sender-Side Operation ......................................7
2.4.1. An Overview .........................................7
2.4.2. The Complete Sender Algorithm .......................8
2.5. Parameter Values ..........................................11
3. Understanding LEDBAT Mechanisms ................................13
3.1. Delay Estimation ..........................................13
3.1.1. Estimating Base Delay ..............................13
3.1.2. Estimating Queueing Delay ..........................13
3.2. Managing the Congestion Window ............................14
3.2.1. Window Increase: Probing for More Bandwidth ........14
3.2.2. Window Decrease: Responding to Congestion ..........14
3.3. Choosing the Queuing Delay Target .........................15
4. Discussion .....................................................15
4.1. Framing and ACK Frequency Considerations ..................15
4.2. Competing with TCP Flows ..................................15
4.3. Competing with Non-TCP Flows ..............................16
4.4. Fairness among LEDBAT Flows ...............................16
5. Open Areas for Experimentation .................................17
5.1. Network Effects and Monitoring ............................17
5.2. Parameter Values ..........................................18
5.3. Filters ...................................................19
5.4. Framing ...................................................19
6. Security Considerations ........................................19
7. Acknowledgements ...............................................20
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................20
Appendix A. Measurement Errors ....................................22
A.1. Clock Offset ...............................................22
A.2. Clock Skew .................................................22
TCP congestion control [RFC5681] seeks to share bandwidth at a bottleneck link equitably among flows competing at the bottleneck, and it is the predominant congestion control mechanism used on the Internet. However, not all applications seek an equitable share of network throughput. "Background" applications, such as software updates or file-sharing applications, seek to operate without interfering with the performance of more interactive and delay-and/or bandwidth-sensitive "foreground" applications. Standard TCP congestion control, as specified in [RFC5681], may be too aggressive for use with such background applications.
TCP拥塞控制[RFC5681]寻求在瓶颈处竞争的流之间公平地共享瓶颈链路上的带宽，它是Internet上使用的主要拥塞控制机制。然而，并非所有应用程序都寻求公平的网络吞吐量份额。“后台”应用程序，如软件更新或文件共享应用程序，寻求在不干扰更具交互性、延迟和/或带宽敏感性的“前台”应用程序性能的情况下运行。[RFC5681]中规定的标准TCP拥塞控制对于此类后台应用程序来说可能过于激进。
Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control mechanism that reacts early to congestion in the network, thus enabling "background" applications to use the network while avoiding interference with the network performance of competing flows. A LEDBAT sender uses one-way delay measurements to estimate the amount of queueing on the data path, controls the LEDBAT flow's congestion window based on this estimate, and minimizes interference with competing flows by adding low extra queueing delay on the end-to-end path.
低额外延迟背景传输（LEDBAT）是一种实验性的基于延迟的拥塞控制机制，它对网络中的拥塞做出早期反应，从而使“背景”应用程序能够使用网络，同时避免干扰竞争流的网络性能。LEDBAT发送器使用单向延迟测量来估计数据路径上的排队量，基于此估计控制LEDBAT流的拥塞窗口，并通过在端到端路径上添加较低的额外排队延迟来最小化对竞争流的干扰。
Delay-based congestion control protocols, such as TCP-Vegas [Bra94][Low02], are generally designed to achieve more, not less throughput than standard TCP, and often outperform TCP under particular network settings. For further discussion on Lower-than-Best-Effort transport protocols see [RFC6297]. In contrast, LEDBAT is designed to be no more aggressive than TCP [RFC5681]; LEDBAT is a "scavenger" congestion control mechanism that seeks to utilize all available bandwidth and yields quickly when competing with standard TCP at a bottleneck link.
基于延迟的拥塞控制协议，如TCP Vegas[Bra94][Low02]，通常设计为比标准TCP实现更多而不是更少的吞吐量，并且在特定网络设置下通常优于TCP。有关低于最佳努力传输协议的进一步讨论，请参见[RFC6297]。相比之下，LEDBAT的设计并不比TCP更具攻击性[RFC5681]；LEDBAT是一种“清道夫”拥塞控制机制，当在瓶颈链路上与标准TCP竞争时，它寻求利用所有可用带宽并快速产生。
In the rest of this document, we refer to congestion control specified in [RFC5681] as "standard TCP".
在本文档的其余部分中，我们将[RFC5681]中指定的拥塞控制称为“标准TCP”。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
LEDBAT congestion control seeks to achieve the following goals:
LEDBAT拥塞控制旨在实现以下目标：
1. to utilize end-to-end available bandwidth and to maintain low queueing delay when no other traffic is present,
1. 为了利用端到端可用带宽，并在没有其他流量时保持较低的排队延迟，
2. to add limited queuing delay to that induced by concurrent flows, and
2. 将有限的排队延迟添加到并发流引起的排队延迟上，以及
3. to yield quickly to standard TCP flows that share the same bottleneck link.
3. 快速向共享同一瓶颈链路的标准TCP流屈服。
LEDBAT is a "scavenger" congestion control mechanism that is motivated primarily by background bulk-transfer applications, such as large file transfers (as with file-sharing applications) and software updates. It can be used with any application that seeks to minimize its impact on the network and on other interactive delay- and/or bandwidth-sensitive network applications. LEDBAT is expected to work well when the sender and/or receiver is connected via a residential access network.
LEDBAT是一种“清道夫”拥塞控制机制，主要由后台批量传输应用程序驱动，例如大型文件传输（与文件共享应用程序一样）和软件更新。它可用于任何试图将其对网络和其他交互式延迟和/或带宽敏感网络应用程序的影响降至最低的应用程序。当发送方和/或接收方通过住宅接入网络连接时，LEDBAT有望正常工作。
LEDBAT can be used as part of a transport protocol or as part of an application, as long as the data transmission mechanisms are capable of carrying timestamps and acknowledging data frequently. LEDBAT can be used with TCP, Stream Control Transmission Protocol (SCTP), and Datagram Congestion Control Protocol (DCCP), with appropriate extensions where necessary; and it can be used with proprietary application protocols, such as those built on top of UDP for peer-to-peer (P2P) applications.
LEDBAT可以用作传输协议的一部分或应用程序的一部分，只要数据传输机制能够频繁地携带时间戳和确认数据。LEDBAT可与TCP、流控制传输协议（SCTP）和数据报拥塞控制协议（DCCP）一起使用，必要时可进行适当的扩展；它还可以与专有的应用程序协议一起使用，例如构建在UDP之上的对等（P2P）应用程序协议。
When used with an ECN-capable framing protocol, LEDBAT should react to an Explicit Congestion Notification (ECN) mark as it would to a loss, as specified in [RFC3168].
当与支持ECN的成帧协议一起使用时，LEDBAT应对显式拥塞通知（ECN）标记作出反应，就像对丢失作出反应一样，如[RFC3168]中所述。
LEDBAT is designed to reduce buildup of a standing queue by long-lived LEDBAT flows at a link with a tail-drop FIFO queue, so as to avoid persistently delaying other flows sharing the queue. If Active Queue Management (AQM) is configured to drop or ECN-mark packets before the LEDBAT flow starts reacting to persistent queue buildup, LEDBAT reverts to standard TCP behavior rather than yielding to other TCP flows. However, such an AQM is still desirable since it keeps queuing delay low, achieving an outcome that is in line with LEDBAT's goals. Additionally, a LEDBAT transport that supports ECN enjoys the advantages that an ECN-capable TCP enjoys over an ECN-agnostic TCP; avoiding losses and possible retransmissions. Weighted Fair Queuing (WFQ), as employed by some home gateways, seeks to isolate and protect delay-sensitive flows from delays due to standing queues built up by concurrent long-lived flows. Consequently, while it prevents LEDBAT from yielding to other TCP flows, it again achieves an outcome that is in line with LEDBAT's goals [Sch10].
LEDBAT设计用于减少在带有尾部下降FIFO队列的链路上的长寿命LEDBAT流对固定队列的累积，从而避免持续延迟共享队列的其他流。如果主动队列管理（AQM）配置为在LEDBAT流开始对持久队列累积作出反应之前丢弃或ECN标记数据包，则LEDBAT将恢复为标准TCP行为，而不是屈服于其他TCP流。然而，这样的AQM仍然是可取的，因为它可以保持较低的排队延迟，从而实现与LEDBAT目标一致的结果。此外，支持ECN的LEDBAT传输与支持ECN的TCP相比具有优势；避免丢失和可能的重新传输。一些家庭网关采用的加权公平队列（WFQ）旨在隔离和保护延迟敏感流，使其免受由于并发长寿命流建立的站立队列而造成的延迟。因此，虽然它阻止了LEDBAT屈服于其他TCP流，但它再次实现了与LEDBAT目标一致的结果[Sch10]。
A standard TCP sender increases its congestion window until a loss occurs [RFC5681] or an ECN mark is received [RFC3168], which, in the absence of link errors in the network, occurs only when the queue at the bottleneck link on the end-to-end path overflows or an AQM is applied. Since packet loss or marking at the bottleneck link is expected to be preceded by an increase in the queueing delay at the bottleneck link, LEDBAT congestion control uses this increase in queueing delay as an early signal of congestion, enabling it to respond to congestion earlier than standard TCP and enabling it to yield bandwidth to a competing TCP flow.
标准TCP发送方增加其拥塞窗口，直到发生丢失[RFC5681]或接收到ECN标记[RFC3168]，在网络中没有链路错误的情况下，仅当端到端路径上瓶颈链路处的队列溢出或应用AQM时才会发生这种情况。由于预计在瓶颈链路上的数据包丢失或标记之前，瓶颈链路上的排队延迟会增加，因此LEDBAT拥塞控制将排队延迟的增加用作拥塞的早期信号，使其能够比标准TCP更早地响应拥塞，并使其能够为竞争的TCP流提供带宽。
LEDBAT employs one-way delay measurements to estimate queueing delay. When the estimated queueing delay is less than a predetermined target, LEDBAT infers that the network is not yet congested and increases its sending rate to utilize any spare capacity in the network. When the estimated queueing delay becomes greater than the predetermined target, LEDBAT decreases its sending rate as a response to potential congestion in the network.
LEDBAT采用单向延迟测量来估计排队延迟。当估计的排队延迟小于预定目标时，LEDBAT推断网络尚未拥塞，并增加其发送速率以利用网络中的任何备用容量。当估计的排队延迟大于预定目标时，LEDBAT降低其发送速率，作为对网络中潜在拥塞的响应。
A LEDBAT sender uses a congestion window (cwnd) to gate the amount of data that the sender can send into the network in one round-trip time (RTT). A sender MAY maintain its cwnd in bytes or in packets; this document uses cwnd in bytes. LEDBAT requires that each data segment carries a "timestamp" from the sender, based on which the receiver computes the one-way delay from the sender and sends this computed value back to the sender.
LEDBAT发送器使用拥塞窗口（cwnd）来控制发送器在一个往返时间（RTT）内可以发送到网络中的数据量。发送方可以以字节或数据包的形式维护其cwnd；此文档使用cwnd（字节）。LEDBAT要求每个数据段携带来自发送方的“时间戳”，接收方根据该时间戳计算来自发送方的单向延迟，并将该计算值发送回发送方。
In addition to the LEDBAT mechanism described below, we note that a slow start mechanism can be used as specified in [RFC5681]. Since slow start leads to faster increase in the window than that specified in LEDBAT, conservative congestion control implementations employing LEDBAT may skip slow start altogether and start with an initial window of INIT_CWND * MSS. (INIT_CWND is described later in Section 2.5.)
除了下面描述的LEDBAT机制外，我们注意到可以按照[RFC5681]中的规定使用慢启动机制。由于慢启动导致窗口的增加速度比LEDBAT中指定的快，因此使用LEDBAT的保守拥塞控制实现可能完全跳过慢启动，并以初始窗口INIT_CWND*MSS开始。（第2.5节稍后将介绍初始CWND。）
The term "MSS", or the sender's Maximum Segment Size, used in this document refers to the size of the largest segment that the sender can transmit. The value of MSS can be based on the path MTU discovery [RFC4821] algorithm and/or on other factors.
本文件中使用的术语“MSS”或发送方的最大段大小是指发送方可以传输的最大段的大小。MSS的值可以基于路径MTU发现[RFC4821]算法和/或其他因素。
A LEDBAT receiver calculates the one-way delay from the sender to the receiver based on its own system time and timestamps in the received data packets. The receiver then feeds the computed one-way delay back to the sender in the next acknowledgement. A LEDBAT receiver operates as follows:
LEDBAT接收器根据其自身的系统时间和接收数据包中的时间戳计算从发送方到接收方的单向延迟。然后，接收方在下一次确认中将计算出的单向延迟反馈给发送方。LEDBAT接收器的工作原理如下：
on data_packet:
remote_timestamp = data_packet.timestamp
acknowledgement.delay = local_timestamp() - remote_timestamp
# fill in other fields of acknowledgement
acknowledgement.send()
on data_packet:
remote_timestamp = data_packet.timestamp
acknowledgement.delay = local_timestamp() - remote_timestamp
# fill in other fields of acknowledgement
acknowledgement.send()
A receiver may choose to delay sending an ACK and may combine acknowledgements for more than one data packet into a single ACK packet, as with delayed ACKs in standard TCP, for example. In such cases, the receiver MAY bundle all the delay samples into one ACK packet and MUST transmit the samples in the order generated. When multiple delay samples are bundled within a single ACK, the sender applies these bundled delay samples at once during its cwnd adjustment (discussed in the next section). Since the sender's adjustment may be sensitive to the order in which the delay samples are applied, the computed delay samples should be available to the sender in the order they were generated at the receiver.
接收机可以选择延迟发送ACK，并且可以将多个数据分组的确认组合成单个ACK分组，例如，与标准TCP中的延迟确认一样。在这种情况下，接收机可以将所有延迟样本捆绑成一个ACK分组，并且必须按照生成的顺序发送样本。当在单个ACK中捆绑多个延迟样本时，发送方在其cwnd调整期间立即应用这些捆绑的延迟样本（将在下一节中讨论）。由于发送方的调整可能对延迟样本的应用顺序很敏感，因此计算出的延迟样本应按照在接收方生成的顺序提供给发送方。
As a first approximation, a LEDBAT sender operates as shown below; the complete algorithm is specified later in Section 2.4.2. TARGET is the maximum queueing delay that LEDBAT itself may introduce in the network, and GAIN determines the rate at which the cwnd responds to changes in queueing delay; both constants are specified later. off_target is a normalized value representing the difference between the measured current queueing delay and the predetermined TARGET delay. off_target can be positive or negative; consequently, cwnd increases or decreases in proportion to off_target.
作为第一近似值，LEDBAT发送器的操作如下所示；完整的算法将在第2.4.2节中详细说明。目标是LEDBAT本身可能在网络中引入的最大排队延迟，增益决定cwnd响应排队延迟变化的速率；这两个常量稍后指定。off_target是一个归一化值，表示测量的当前排队延迟和预定目标延迟之间的差值。偏离目标可以是积极的，也可以是消极的；因此，cwnd的增加或减少与偏离目标成比例。
on initialization: base_delay = +INFINITY
初始化时：基本延迟=+无穷大
on acknowledgement:
current_delay = acknowledgement.delay
base_delay = min(base_delay, current_delay)
queuing_delay = current_delay - base_delay
off_target = (TARGET - queuing_delay) / TARGET
cwnd += GAIN * off_target * bytes_newly_acked * MSS / cwnd
on acknowledgement:
current_delay = acknowledgement.delay
base_delay = min(base_delay, current_delay)
queuing_delay = current_delay - base_delay
off_target = (TARGET - queuing_delay) / TARGET
cwnd += GAIN * off_target * bytes_newly_acked * MSS / cwnd
The simplified mechanism above ignores multiple delay samples in an acknowledgement, noise filtering, base delay expiration, and sender idle times, which we now take into account in our complete sender algorithm below.
上面的简化机制忽略了确认中的多个延迟样本、噪声过滤、基本延迟过期和发送方空闲时间，我们现在在下面的完整发送方算法中考虑了这些。
update_current_delay() maintains a list of one-way delay measurements, of which a filtered value is used as an estimate of the current end-to-end delay. update_base_delay() maintains a list of one-way delay minima over a number of one-minute intervals, to measure and to track changes in the base delay of the end-to-end path. Both of these lists are maintained per LEDBAT flow.
update_current_delay（）维护单向延迟测量的列表，其中的过滤值用作当前端到端延迟的估计值。update_base_delay（）以一分钟的间隔维护一个单向最小延迟列表，以测量和跟踪端到端路径的基本延迟的变化。这两个列表都按照LEDBAT流进行维护。
We note this algorithm assumes that slight random fluctuations exist in inter-packet arrival times at the bottleneck queue, to allow a LEDBAT sender to correctly measure the base delay. See Section 4.4 for a more complete discussion.
我们注意到，该算法假设瓶颈队列中的包间到达时间存在轻微的随机波动，以允许LEDBAT发送方正确测量基本延迟。有关更完整的讨论，请参见第4.4节。
The full sender-side algorithm is given below:
完整的发送方算法如下所示：
on initialization: # cwnd is the amount of data that is allowed to be # outstanding in an RTT and is defined in bytes. # CTO is the congestion timeout value.
在初始化时：#cwnd是RTT中允许未完成的数据量，以字节为单位定义CTO是拥塞超时值。
create current_delays list with CURRENT_FILTER elements create base_delays list with BASE_HISTORY number of elements initialize elements in base_delays to +INFINITY initialize elements in current_delays according to FILTER() last_rollover = -INFINITY # More than a minute in the past flightsize = 0 cwnd = INIT_CWND * MSS CTO = 1 second
使用当前过滤器元素创建当前延迟列表使用基本过滤器元素创建基本延迟列表使用基本过滤器元素历史记录初始化基本过滤器中的元素数延迟到+无限初始化当前延迟中的元素根据过滤器（）上一次滚动=-无限#过去一分钟以上flightsize=0 cwnd=INIT\u cwnd*MSS CTO=1秒
on acknowledgement: # flightsize is the amount of data outstanding before this ACK # was received and is updated later; # bytes_newly_acked is the number of bytes that this ACK # newly acknowledges, and it MAY be set to MSS.
确认时：#flightsize是收到此确认之前未完成的数据量，稍后会更新；#bytes_New_acked是此确认新确认的字节数，可以设置为MSS。
for each delay sample in the acknowledgement: delay = acknowledgement.delay update_base_delay(delay) update_current_delay(delay)
对于确认中的每个延迟样本：延迟=确认。延迟更新\基本\延迟（延迟）更新\当前\延迟（延迟）
queuing_delay = FILTER(current_delays) - MIN(base_delays)
off_target = (TARGET - queuing_delay) / TARGET
cwnd += GAIN * off_target * bytes_newly_acked * MSS / cwnd
max_allowed_cwnd = flightsize + ALLOWED_INCREASE * MSS
cwnd = min(cwnd, max_allowed_cwnd)
cwnd = max(cwnd, MIN_CWND * MSS)
flightsize = flightsize - bytes_newly_acked
update_CTO()
queuing_delay = FILTER(current_delays) - MIN(base_delays)
off_target = (TARGET - queuing_delay) / TARGET
cwnd += GAIN * off_target * bytes_newly_acked * MSS / cwnd
max_allowed_cwnd = flightsize + ALLOWED_INCREASE * MSS
cwnd = min(cwnd, max_allowed_cwnd)
cwnd = max(cwnd, MIN_CWND * MSS)
flightsize = flightsize - bytes_newly_acked
update_CTO()
on data loss:
# at most once per RTT
cwnd = min (cwnd, max (cwnd/2, MIN_CWND * MSS))
if data lost is not to be retransmitted:
flightsize = flightsize - bytes_not_to_be_retransmitted
on data loss:
# at most once per RTT
cwnd = min (cwnd, max (cwnd/2, MIN_CWND * MSS))
if data lost is not to be retransmitted:
flightsize = flightsize - bytes_not_to_be_retransmitted
if no ACKs are received within a CTO:
# extreme congestion, or significant RTT change.
# set cwnd to 1MSS and backoff the congestion timer.
cwnd = 1 * MSS
CTO = 2 * CTO
if no ACKs are received within a CTO:
# extreme congestion, or significant RTT change.
# set cwnd to 1MSS and backoff the congestion timer.
cwnd = 1 * MSS
CTO = 2 * CTO
update_CTO() # implements an RTT estimation mechanism using data # transmission times and ACK reception times, # which is used to implement a congestion timeout (CTO). # If implementing LEDBAT in TCP, sender SHOULD use # mechanisms described in RFC 6298 [RFC6298], # and the CTO would be the same as the retransmission timeout (RTO).
update#u CTO（）#使用数据#传输时间和ACK接收时间实现RTT估计机制，用于实现拥塞超时（CTO）如果在TCP中实现LEDBAT，发送方应使用RFC 6298[RFC6298]中描述的机制，并且CTO与重传超时（RTO）相同。
update_current_delay(delay) # Maintain a list of CURRENT_FILTER last delays observed. delete first item in current_delays list append delay to current_delays list
更新_current_delay（delay）#维护最近观察到的当前_过滤器延迟列表。删除当前\u延迟列表中的第一项将延迟附加到当前\u延迟列表
update_base_delay(delay) # Maintain BASE_HISTORY delay-minima. # Each minimum is measured over a period of a minute. # 'now' is the current system time if round_to_minute(now) != round_to_minute(last_rollover) last_rollover = now delete first item in base_delays list append delay to base_delays list else base_delays.tail = MIN(base_delays.tail, delay)
更新基本延迟（延迟）#保持基本历史延迟最小值。#在一分钟内测量每个最小值“现在”是当前的系统时间，如果四舍五入到每分钟（现在）！=四舍五入到分钟（最后一次滚动）最后一次滚动=现在删除基本延迟列表中的第一项将延迟附加到基本延迟列表中其他基本延迟。尾=分钟（基本延迟。尾，延迟）
The LEDBAT sender seeks to extract the actual delay estimate from the current_delay samples by implementing FILTER() to eliminate any outliers. Different types of filters MAY be used for FILTER() -- a NULL filter, that does not filter at all, is a reasonable candidate as well, since LEDBAT's use of a linear controller for cwnd increase and decrease may allow it to recover quickly from errors induced by bad samples. Another example of a filter is the exponentially weighted moving average (EWMA) function, with weights that enable agile tracking of changing network delay. A simple MIN filter applied over a small window (much smaller than BASE_HISTORY) may also provide robustness to large delay peaks, as may occur with delayed ACKs in TCP. Care should be taken that the filter used, while providing robustness to noise, remains sensitive to persistent congestion signals.
LEDBAT发送器通过实现FILTER（）来消除任何异常值，试图从当前延迟样本中提取实际延迟估计值。FILTER（）可以使用不同类型的过滤器——一个完全不过滤的空过滤器也是一个合理的选择，因为LEDBAT使用线性控制器来增加和减少cwnd可能使其能够从坏样本引起的错误中快速恢复。滤波器的另一个例子是指数加权移动平均（EWMA）函数，其权重能够灵活跟踪不断变化的网络延迟。在一个小窗口上应用一个简单的MIN滤波器（比BASE_HISTORY小得多）也可以提供对大延迟峰值的鲁棒性，就像TCP中延迟的ack一样。应注意使用的滤波器在提供噪声鲁棒性的同时，对持续拥塞信号保持敏感。
We note that when multiple delay samples are bundled within a single ACK, the sender's resulting cwnd may be slightly different than when the samples are sent individually in separate ACKs. The cwnd is adjusted based on the total number of bytes ACKed and the final filtered value of queueing_delay, irrespective of the number of delay samples in an ACK.
我们注意到，当在单个ACK中捆绑多个延迟样本时，发送方产生的cwnd可能与在单独ACK中单独发送样本时略有不同。cwnd根据确认的字节总数和队列延迟的最终过滤值进行调整，而与确认中的延迟样本数无关。
To implement an approximate minimum over the past few minutes, a LEDBAT sender stores BASE_HISTORY separate minima -- one each for the last BASE_HISTORY-1 minutes, and one for the running current minute. At the end of the current minute, the window moves -- the earliest minimum is dropped and the latest minimum is added. If the connection is idle for a given minute, no data is available for the one-way delay and, therefore, a value of +INFINITY has to be stored in the list. If the connection has been idle for BASE_HISTORY minutes, all minima in the list are thus set to +INFINITY and measurement begins anew. LEDBAT thus requires that during idle periods, an implementation must maintain the base delay list.
为了在过去几分钟内实现一个近似最小值，LEDBAT发送器将基本历史记录单独存储一个最小值——最后一个基本历史记录1分钟各存储一个，运行当前分钟各存储一个。在当前分钟结束时，窗口移动——删除最早的最小值，添加最新的最小值。如果连接空闲一分钟，则单向延迟没有可用数据，因此必须在列表中存储+无穷大的值。如果连接已空闲了BASE_历史分钟，则列表中的所有最小值都将因此设置为+无穷大，并重新开始测量。因此，LEDBAT要求在空闲期间，实现必须维护基本延迟列表。
LEDBAT restricts cwnd growth after a period of inactivity. When the sender is application-limited, the sender's cwnd is clamped down using max_allowed_cwnd to a little more than flightsize. To be TCP-friendly, LEDBAT halves its cwnd on data loss.
LEDBAT在一段时间不活动后限制cwnd的生长。当发送方受到应用程序限制时，使用max_allowed_cwnd将发送方的cwnd限制为略大于flightsize。为了对TCP友好，LEDBAT在数据丢失时将其cwnd减半。
LEDBAT uses a congestion timeout (CTO) to avoid transmitting data during periods of heavy congestion and to avoid congestion collapse. A CTO is used to detect heavy congestion indicated by loss of all outstanding data or acknowledgements, resulting in reduction of the cwnd to 1 MSS and an exponential backoff of the CTO interval. This backoff of the CTO value avoids sending more data into an overloaded queue, and it also allows the sender to cope with sudden changes in the RTT of the path. The function of a CTO is similar to that of an retransmission timeout (RTO) in TCP [RFC6298], but since LEDBAT separates reliability from congestion control, a retransmission need not be triggered by a CTO. LEDBAT, however, does not preclude a CTO from triggering retransmissions, as could be the case if LEDBAT congestion control were to be used with TCP framing and reliability.
LEDBAT使用拥塞超时（CTO）来避免在严重拥塞期间传输数据，并避免拥塞崩溃。CTO用于检测所有未完成数据或确认丢失所指示的严重拥塞，从而将cwnd减少到1毫秒，并使CTO间隔呈指数级后退。CTO值的这种回退避免了将更多数据发送到过载队列中，并且还允许发送方处理路径RTT中的突然变化。CTO的功能类似于TCP[RFC6298]中的重传超时（RTO），但由于LEDBAT将可靠性与拥塞控制分离，因此重传不需要由CTO触发。然而，LEDBAT并不排除CTO触发重传，如果将LEDBAT拥塞控制与TCP帧和可靠性结合使用，则可能会发生这种情况。
The CTO is a gating mechanism that ensures exponential backoff of sending rate under heavy congestion, and it may be implemented with or without a timer. An implementation choosing to avoid timers may consider using a "next-time-to-send" variable, set based on the CTO, to control the earliest time a sender may transmit without receiving any ACKs. A maximum value MAY be placed on the CTO, and if placed, it MUST be at least 60 seconds.
CTO是一种门控机制，可确保在严重拥塞情况下发送速率的指数衰减，它可以使用或不使用计时器来实现。选择避免定时器的实现可以考虑使用基于CTO的“下一次发送”变量来控制发送者可以在不接收任何ACK的情况下发送的最早时间。可以在CTO上设置最大值，如果设置，则该值必须至少为60秒。
TARGET MUST be 100 milliseconds or less, and this choice of value is explained further in Section 3.3. Note that using the same TARGET value across LEDBAT flows enables equitable sharing of the bottleneck bandwidth. A flow with a higher TARGET value than other competing LEDBAT flows may get a larger share of the bottleneck bandwidth. It is possible to consider the use of different TARGET values for implementing a relative priority between two competing LEDBAT flows by setting a higher TARGET value for the higher-priority flow.
目标值必须小于等于100毫秒，此值的选择将在第3.3节中进一步解释。请注意，在LEDBAT流中使用相同的目标值可以实现瓶颈带宽的公平共享。目标值高于其他竞争LEDBAT流的流可能会获得更大的瓶颈带宽份额。可以考虑使用不同的目标值，通过为更高优先级的流设置更高的目标值来在两个竞争的ReBATT流之间实现相对优先级。
ALLOWED_INCREASE SHOULD be 1, and it MUST be greater than 0. An ALLOWED_INCREASE of 0 results in no cwnd growth at all, and an ALLOWED_INCREASE of 1 allows and limits the cwnd increase based on flightsize in the previous RTT. An ALLOWED_INCREASE greater than 1 MAY be used when interactions between LEDBAT and the framing protocol provide a clear reason for doing so.
允许的_增加值应为1，且必须大于0。允许的_增加0将导致完全没有cwnd增长，允许的_增加1将允许并限制基于前一RTT中的flightsize的cwnd增长。当LEDBAT和成帧协议之间的交互提供了明确的理由时，可以使用大于1的允许_增加。
GAIN MUST be set to 1 or less. A GAIN of 1 limits the maximum cwnd ramp-up to the same rate as TCP Reno in Congestion Avoidance. While this document specifies the use of the same GAIN for both cwnd
增益必须设置为1或更小。增益1将最大cwnd爬升限制为与TCP Reno在避免拥塞方面相同的速率。而本文件规定了两个cwnd使用相同的增益
increase (when off_target is greater than zero) and decrease (when off_target is less than zero), implementations MAY use a higher GAIN for cwnd decrease than for the increase; our justification follows. When a competing non-LEDBAT flow increases its sending rate, the LEDBAT sender may only measure a small amount of additional delay and decrease the sending rate slowly. To ensure no impact on a competing non-LEDBAT flow, the LEDBAT flow should decrease its sending rate at least as quickly as the competing flow increases its sending rate. A higher decrease-GAIN MAY be used to allow the LEDBAT flow to decrease its sending rate faster than the competing flow's increase rate.
增加（当off_target大于零时）和减少（off_target小于零时），实现可能使用比增加更高的cwnd减少增益；我们的理由如下。当竞争的非LEDBAT流增加其发送速率时，LEDBAT发送器可能仅测量少量额外延迟，并缓慢降低发送速率。为确保对竞争性非LEDBAT流没有影响，LEDBAT流应至少以竞争性流增加其发送速率的速度降低其发送速率。更高的减少增益可用于允许LEDBAT流以比竞争流的增加速率更快的速度减少其发送速率。
The size of the base_delays list, BASE_HISTORY, SHOULD be 10. If the actual base delay decreases, due to a route change, for instance, a LEDBAT sender adapts immediately, irrespective of the value of BASE_HISTORY. If the actual base delay increases, however, a LEDBAT sender will take BASE_HISTORY minutes to adapt and may wrongly infer a little more extra delay than intended (TARGET) in the meanwhile. A value for BASE_HISTORY is thus a trade-off: a higher value may yield a more accurate measurement when the base delay is unchanging, and a lower value results in a quicker response to actual increase in base delay.
基本\u延迟列表（基本\u历史记录）的大小应为10。例如，如果由于路由更改，实际的基本延迟减少，则LEDBAT发送器会立即进行自适应，而与基本U历史记录的值无关。但是，如果实际的基本延迟增加，LEDBAT发送器将花费基本U历史分钟来适应，并且可能错误地推断出比预期（目标）稍微多一些的额外延迟。因此，基本延迟历史值是一种折衷：当基本延迟不变时，较高的值可能会产生更准确的测量，较低的值会更快地响应基本延迟的实际增加。
A LEDBAT sender uses the current_delays list to maintain only delay measurements made within an RTT amount of time in the past, seeking to eliminate noise spikes in its measurement of the current one-way delay through the network. The size of this list, CURRENT_FILTER, may be variable, and it depends on the FILTER() function as well as the number of successful measurements made within an RTT amount of time in the past. The sender should seek to gather enough delay samples in each RTT so as to have statistical confidence in the measurements. While the number of delay samples required for such confidence will vary depending on network conditions, the sender SHOULD use at least 4 delay samples in each RTT, unless the number of samples is lower due to a small congestion window. The value of CURRENT_FILTER will depend on the filter being employed, but CURRENT_FILTER MUST be limited such that samples in the list are not older than an RTT in the past.
LEDBAT发送器使用current_delays list（当前_延迟列表）仅维护过去在RTT时间量内进行的延迟测量，以消除其通过网络测量当前单向延迟时的噪声峰值。此列表的大小（CURRENT_FILTER）可能是可变的，它取决于FILTER（）函数以及过去RTT时间内成功测量的次数。发送方应在每个RTT中收集足够的延迟样本，以便对测量结果具有统计置信度。尽管这种置信度所需的延迟样本数量将根据网络条件而变化，但发送方应在每个RTT中使用至少4个延迟样本，除非由于拥塞窗口较小，样本数量较低。CURRENT_FILTER的值将取决于所使用的筛选器，但必须限制CURRENT_FILTER，以便列表中的样本不早于过去的RTT。
INIT_CWND and MIN_CWND SHOULD both be 2. An INIT_CWND of 2 should help seed FILTER() at the sender when there are no samples at the beginning of a flow, and a MIN_CWND of 2 allows FILTER() to use more than a single instantaneous delay estimate while not being too aggressive. Slight deviations may be warranted, for example, when these values of INIT_CWND and MIN_CWND interact poorly with the framing protocol. However, INIT_CWND and MIN_CWND MUST be no larger than the corresponding values specified for TCP [RFC5681].
INIT_CWND和MIN_CWND都应该是2。当流开始时没有样本时，INIT_CWND为2有助于在发送方进行种子筛选（），MIN_CWND为2允许FILTER（）在不太激进的情况下使用多个瞬时延迟估计。例如，当INIT_CWND和MIN_CWND的这些值与帧协议交互不良时，可以保证轻微的偏差。但是，INIT_CWND和MIN_CWND不得大于为TCP[RFC5681]指定的相应值。
This section describes the delay estimation and window management mechanisms used in LEDBAT.
本节介绍LEDBAT中使用的延迟估计和窗口管理机制。
LEDBAT estimates congestion in the direction of the data flow, and to avoid measuring additional delay from, e.g., queue buildup on the reverse path (or ACK path) or reordering, LEDBAT uses one-way delay estimates. LEDBAT assumes that measurements are done with data packets, thus avoiding the need for separate measurement packets and avoiding the pitfall of measurement packets being treated differently from the data packets in the network.
LEDBAT估计数据流方向上的拥塞，为了避免测量额外的延迟，例如反向路径（或ACK路径）上的队列累积或重新排序，LEDBAT使用单向延迟估计。LEDBAT假设测量是用数据包完成的，因此避免了需要单独的测量包，并避免了测量包与网络中的数据包不同处理的陷阱。
End-to-end delay can be decomposed into transmission (or serialization) delay, propagation (or speed-of-light) delay, queueing delay, and processing delay. On any given path, barring some noise, all delay components except for queueing delay are constant. To observe an increase in the queueing delay in the network, a LEDBAT sender separates the queueing delay component from the rest of the end-to-end delay, as described below.
端到端延迟可以分解为传输（或序列化）延迟、传播（或光速）延迟、排队延迟和处理延迟。在任何给定的路径上，除非存在噪声，否则除排队延迟外，所有延迟分量都是常数。为了观察网络中排队延迟的增加，LEDBAT发送器将排队延迟组件与其余端到端延迟分离，如下所述。
Since queuing delay is always additive to the end-to-end delay, LEDBAT estimates the sum of the constant delay components, which we call "base delay", to be the minimum delay observed on the end-to-end path.
由于排队延迟总是与端到端延迟相加，因此LEDBAT将恒定延迟分量之和（我们称之为“基本延迟”）估计为端到端路径上观察到的最小延迟。
To respond to true changes in the base delay, as can be caused by a route change, LEDBAT uses only recent measurements in estimating the base delay. The duration of the observation window itself is a trade-off between robustness of measurement and responsiveness to change -- a larger observation window increases the chances that the true base delay will be detected (as long as the true base delay is unchanged), whereas a smaller observation window results in faster response to true changes in the base delay.
为了响应可能由路由变化引起的基本延迟的真实变化，LEDBAT仅使用最近的测量值来估计基本延迟。观察窗口的持续时间本身是测量的稳健性和对变化的响应性之间的折衷——较大的观察窗口增加了检测到真实基本延迟的机会（只要真实基本延迟不变），而较小的观测窗口则能更快地响应基准延迟的真实变化。
Assuming that the base delay is constant (in the absence of any route changes), the queueing delay is represented by the variable component of the measured end-to-end delay. LEDBAT measures queueing delay as simply the difference between an end-to-end delay measurement and the current estimate of base delay. The queueing delay should be
假设基本延迟为常数（在没有任何路由更改的情况下），排队延迟由测量的端到端延迟的可变分量表示。LEDBAT将排队延迟测量为端到端延迟测量值与当前基本延迟估计值之间的差值。排队延迟应为
filtered (depending on the usage scenario) to eliminate noise in the delay estimation, such as due to spikes in processing delay at a node on the path.
过滤（取决于使用场景）以消除延迟估计中的噪声，例如由于路径上节点处的处理延迟峰值引起的噪声。
LEDBAT uses a simple linear controller to determine the sending rate as a function of the delay estimate, where the response of the sender is proportional to the difference between the current queueing delay estimate and the target.
LEDBAT使用一个简单的线性控制器来确定发送速率作为延迟估计的函数，其中发送方的响应与当前排队延迟估计和目标之间的差成正比。
When the queuing delay is smaller than a delay target value, as specified by the TARGET parameter in this document, a LEDBAT sender will increase its congestion window proportionally to the relative difference between the current queueing delay and the delay target. As the current queuing delay gets closer to TARGET, LEDBAT's window growth gets slower. To compete fairly with concurrent TCP flows, we set the highest rate of LEDBAT's window growth (when the current queueing delay estimate is zero) to be the same as TCP's (increase of one packet per RTT). In other words, a LEDBAT flow never ramps up faster than a competing TCP flow over the same path. The TARGET value specifies the maximum extra queuing delay that LEDBAT will induce. If the current queuing delay equals the TARGET value, LEDBAT tries to maintain this extra delay.
当排队延迟小于本文档中目标参数指定的延迟目标值时，LEDBAT发送方将根据当前排队延迟和延迟目标之间的相对差值按比例增加其拥塞窗口。随着当前排队延迟接近目标，LEDBAT的窗口增长变慢。为了与并发TCP流公平竞争，我们将LEDBAT窗口增长的最高速率（当前排队延迟估计为零时）设置为与TCP相同（每个RTT增加一个数据包）。换句话说，LEDBAT流在同一路径上的爬坡速度永远不会比竞争TCP流快。目标值指定LEDBAT将导致的最大额外排队延迟。如果当前排队延迟等于目标值，LEDBAT将尝试保持此额外延迟。
When a sender's queueing delay estimate is higher than the target, the LEDBAT flow's rate should be reduced. LEDBAT's linear controller allows the sender to decrease the window proportional to the difference between the target and the current queueing delay.
当发送方的排队延迟估计值高于目标值时，应降低LEDBAT流的速率。LEDBAT的线性控制器允许发送方减少与目标和当前排队延迟之间的差值成比例的窗口。
Unlike TCP-like loss-based congestion control, LEDBAT seeks to avoid losses and so a LEDBAT sender is not expected to normally rely on losses to determine the sending rate. However, when data loss does occur, LEDBAT must respond as standard TCP does; even if the queueing delay estimates indicate otherwise, a loss is assumed to be a strong indication of congestion. Thus, to deal with severe congestion when packets are dropped in the network, and to provide a fallback against incorrect queuing delay estimates, a LEDBAT sender halves its congestion window when a loss event is detected. As with TCP New-Reno, LEDBAT reduces its cwnd by half at most once per RTT.
与类似TCP的基于丢失的拥塞控制不同，LEDBAT寻求避免丢失，因此LEDBAT发送方通常不会依赖丢失来确定发送速率。然而，当数据确实丢失时，LEDBAT必须像标准TCP那样响应；即使排队延迟估计值表明情况并非如此，损失也被认为是拥塞的强烈迹象。因此，为了处理网络中丢包时的严重拥塞，并针对错误的排队延迟估计提供回退，当检测到丢失事件时，LEDBAT发送方将其拥塞窗口减半。与TCP New Reno一样，LEDBAT每RTT最多可将其cwnd减少一半。
The International Telecommunication Union's (ITU's) Recommendation G.114 defines a one-way delay of 150 ms to be acceptable for most user voice applications [g114]. Thus, the delay induced by LEDBAT must be well below 150 ms to limit its impact on concurrent delay-sensitive traffic sharing the same bottleneck queue. A target that is too low, on the other hand, increases the sensitivity of the sender's algorithm to noise in the one-way delays and in the delay measurement process, and may lead to reduced throughput for the LEDBAT flow and to under-utilization of the bottleneck link.
国际电信联盟（ITU）建议G.114定义了150 ms的单向延迟，大多数用户语音应用可接受[g114]。因此，LEDBAT引起的延迟必须远低于150 ms，以限制其对共享同一瓶颈队列的并发延迟敏感流量的影响。另一方面，过低的目标会增加发送方算法对单向延迟和延迟测量过程中噪声的敏感性，并可能导致LEDBAT流吞吐量降低和瓶颈链路利用率不足。
Our recommendation of 100 ms or less as the target is a trade-off between these considerations. Anecdotal evidence indicates that this value works well -- LEDBAT has been implemented and successfully deployed with a target value of 100 ms in two BitTorrent implementations: as the exclusive congestion control mechanism in BitTorrent Delivery Network Accelerator (DNA), and as an experimental mechanism in uTorrent [uTorrent].
我们建议将100ms或以下作为目标是这些考虑因素之间的权衡。传闻证据表明，该值运行良好——LEDBAT已在两种BitTorrent实现中实现并成功部署，目标值为100 ms：作为BitTorrent交付网络加速器（DNA）中的专用拥塞控制机制，以及作为uTorrent[uTorrent]中的实验机制。
While the actual framing and wire format of the protocols using LEDBAT are outside the scope of this document, we briefly consider the data framing and ACK frequency needs of LEDBAT mechanisms.
虽然使用LeBAT的协议的实际帧和线格式超出了本文档的范围，但我们简要地考虑了数据结构和ACID机制的ACK频率需求。
To compute the data path's one-way delay, our discussion of LEDBAT assumes a framing that allows the sender to timestamp packets and for the receiver to convey the measured one-way delay back to the sender in ACK packets. LEDBAT does not require this particular method, but it does require unambiguous delay estimates using data and ACK packets.
为了计算数据路径的单向延迟，我们对LEDBAT的讨论假设了一个帧，该帧允许发送方给数据包加时间戳，并允许接收方在ACK数据包中将测量的单向延迟传递回发送方。LEDBAT不需要这种特殊的方法，但它确实需要使用数据和ACK数据包进行明确的延迟估计。
A LEDBAT receiver may send an ACK as frequently as one for every data packet received or less frequently; LEDBAT does require that the receiver MUST transmit at least one ACK in every RTT.
LEDBAT接收机可发送ACK的频率与接收到的每个数据分组的频率相同或更低；LEDBAT确实要求接收器必须在每个RTT中至少发送一个ACK。
LEDBAT is designed to respond to congestion indications earlier than loss-based standard TCP [RFC5681]. A LEDBAT flow gets more aggressive as the queueing delay estimate gets lower; since the queueing delay estimate is non-negative, LEDBAT is most aggressive when the queueing delay estimate is zero. In this case, LEDBAT ramps up its congestion window at the same rate as standard TCP [RFC5681]. LEDBAT may reduce its rate earlier than standard TCP and always
LEDBAT设计用于比基于丢失的标准TCP[RFC5681]更早地响应拥塞指示。随着排队延迟估计值的降低，LEDBAT流变得更具攻击性；由于排队延迟估计为非负，因此当排队延迟估计为零时，LEDBAT最具攻击性。在这种情况下，LEDBAT以与标准TCP[RFC5681]相同的速率增加其拥塞窗口。LEDBAT可以比标准TCP更早地降低其速率，并且始终
halves its congestion window on loss. Thus, in the worst case, where the delay estimates are completely and consistently off, a LEDBAT flow falls back to standard TCP behavior, and is no more aggressive than standard TCP [RFC5681].
将其拥塞窗口减半。因此，在最坏的情况下，延迟估计值完全一致地关闭，LEDBAT流返回到标准TCP行为，并且不比标准TCP更具攻击性[RFC5681]。
While LEDBAT yields to all high-load flows, both TCP and non-TCP, LEDBAT may not yield to low-load and latency-sensitive traffic that do not induce a measurable delay at the bottleneck queue, such as Voice over IP (VoIP) traffic. While such flows will experience additional delay due to any concurrent LEDBAT flows, the TARGET delay sets a limit to the total amount of additional delay that all the concurrent LEDBAT flows will jointly induce. If the TARGET delay is higher than what the bottleneck queue can sustain, the LEDBAT flows should experience loss and will fall back to standard loss-based TCP behavior. Thus, in the worst case, LEDBAT will add no more latency than standard TCP when competing with non-TCP flows. In the common case however, we expect LEDBAT flows to add TARGET amount of delay, which ought to be within the delay tolerance for most latency-sensitive applications, including VoIP applications.
虽然LEDBAT会产生所有高负载流量，包括TCP和非TCP，但LEDBAT可能不会产生低负载和对延迟敏感的流量，这些流量不会在瓶颈队列中产生可测量的延迟，例如IP语音（VoIP）流量。虽然由于任何并发LEDBAT流，此类流将经历额外延迟，但目标延迟将限制所有并发LEDBAT流将共同导致的额外延迟总量。如果目标延迟高于瓶颈队列所能承受的，则LEDBAT流将经历丢失，并将返回到标准的基于丢失的TCP行为。因此，在最坏的情况下，当与非TCP流竞争时，LEDBAT不会增加比标准TCP更多的延迟。然而，在常见情况下，我们期望LEDBAT流增加目标延迟量，对于大多数延迟敏感的应用程序（包括VoIP应用程序），该延迟量应该在延迟容差范围内。
The primary design goals of LEDBAT are focused on the aggregate behavior of LEDBAT flows when they compete with standard TCP. Since LEDBAT is designed for background traffic, we consider link utilization to be more important than fairness amongst LEDBAT flows. Nevertheless, we now consider fairness issues that might arise amongst competing LEDBAT flows.
LEDBAT的主要设计目标集中在LEDBAT流与标准TCP竞争时的聚合行为上。由于LeBAT是为后台流量设计的，所以我们认为链路利用比LeBAT流中的公平性更重要。然而，我们现在考虑公平竞争问题，可能出现在竞争的莱巴特流。
LEDBAT as described so far lacks a mechanism specifically designed to equalize utilization amongst LEDBAT flows. Anecdotally observed behavior of existing implementations indicates that a rough equalization does occur since in most environments some amount of randomness in the inter-packet transmission times exists, as explained further below.
到目前为止，所述LEDBAT缺乏专门设计用于均衡LEDBAT流之间利用率的机制。从轶事上观察到的现有实现的行为表明，粗均衡确实发生，因为在大多数环境中，分组间传输时间存在一定数量的随机性，如下所述。
Delay-based congestion control systems suffer from the possibility of latecomers incorrectly measuring and using a higher base-delay than an active flow that started earlier. Consider that a bottleneck is saturated by a single LEDBAT flow, and the flow therefore maintains the bottleneck queue at TARGET delay. When a new LEDBAT flow arrives at the bottleneck, it might incorrectly include the steady queueing delay in its measurement of the base delay on the path. The new flow has an inflated estimate of the base delay, and may now effectively build on top of the existing, already maximal, queueing delay. As the latecomer flow builds up, the old flow sees the true queueing
基于延迟的拥塞控制系统可能会遇到迟到者错误地测量和使用比先前启动的主动流更高的基本延迟的情况。考虑到一个瓶颈被单个LeBATA流饱和，并且流因此保持瓶颈队列在目标延迟。当一个新的LEDBAT流到达瓶颈时，它可能会错误地将稳定排队延迟包含在其对路径上基本延迟的测量中。新的流对基本延迟有一个膨胀的估计，现在可以有效地建立在现有的、已经最大的排队延迟之上。随着后来者流的建立，旧流看到了真正的排队
delay and backs off, while the latecomer keeps building up, using up the entire link's capacity, and effectively shutting the old flow out. This advantage is called the "latecomer's advantage".
延迟和回退，而后来者不断累积，耗尽了整个链路的容量，有效地关闭了旧的流量。这种优势被称为“后发优势”。
In the worst case, if the first flow yields at the same rate as the new flow increases its sending rate, the new flow will see constant end-to-end delay, which it assumes is the base delay, until the first flow backs off completely. As a result, by the time the second flow stops increasing its cwnd, it would have added twice the target queueing delay to the network.
在最坏的情况下，如果第一个流以与新流增加其发送速率相同的速率产生，则新流将看到恒定的端到端延迟，它假定这是基本延迟，直到第一个流完全退出。因此，当第二个流停止增加其cwnd时，它将为网络增加两倍的目标排队延迟。
This advantage can be reduced if the first flow yields and empties the bottleneck queue faster than the incoming flow increases its occupancy in the queue. In such a case, the latecomer might measure correctly a delay that is closer to the base delay. While such a reduction might be achieved through a multiplicative decrease of the congestion window, this may cause strong fluctuations in flow throughput during the flow's steady state. Thus, we do not recommend a multiplicative decrease scheme.
如果第一个流产生瓶颈队列并清空瓶颈队列的速度快于传入流增加其在队列中的占用率，则此优势可能会降低。在这种情况下，迟到者可能会正确测量接近基本延迟的延迟。虽然这种减少可以通过拥塞窗口的乘法减少来实现，但这可能会在流的稳定状态期间导致流吞吐量的剧烈波动。因此，我们不建议采用乘法递减方案。
We note that in certain use-case scenarios, it is possible for a later LEDBAT flow to gain an unfair advantage over an existing one [Car10]. In practice, this concern ought to be alleviated by the burstiness of network traffic: all that's needed to measure the base delay is one small gap in transmission schedules between the LEDBAT flows. These gaps can occur for a number of reasons such as latency introduced due to application sending patterns, OS scheduling at the sender, processing delay at the sender or any network node, and link contention. When such a gap occurs in the first sender's transmission while the latecomer is starting, base delay is immediately correctly measured. With a small number of LEDBAT flows, system noise may sufficiently regulate the latecomer's advantage.
我们注意到，在某些用例场景中，后期的LEDBAT流可能会比现有的LEDBAT流获得不公平的优势[Car10]。实际上，这种担忧应该通过网络流量的突发性得到缓解：测量基本延迟所需的只是LEDBAT流之间传输计划中的一个小间隙。出现这些间隙的原因有很多，如应用程序发送模式引起的延迟、发送方的操作系统调度、发送方或任何网络节点的处理延迟以及链路争用。当第一个发送方的传输在后发方启动时出现这种间隙时，立即正确测量基本延迟。对于少量的LEDBAT流，系统噪声可以充分调节后发者的优势。
We now outline some areas that need experimentation in the Internet and under different network scenarios. These experiments should help the community understand LEDBAT's dynamics and should help towards further standardization of LEDBAT and LEDBAT-related documents.
我们现在概述了一些需要在互联网和不同网络场景下进行实验的领域。这些实验应有助于社区了解LEDBAT的动态，并有助于LEDBAT和LEDBAT相关文件的进一步标准化。
Further study is required to fully understand the behavior and convergence properties of LEDBAT in networks with non-tail-drop, non-FIFO queues, in networks with frequent route changes, and in networks with network-level load balancing. These studies should have two
需要进一步研究，以充分了解LEDBAT在具有非尾部下降、非FIFO队列的网络、具有频繁路由变化的网络以及具有网络级负载平衡的网络中的行为和收敛特性。这些研究应该有两个方面
broad goals: (i) to understand the effects of different network mechanisms on LEDBAT, and (ii) to understand the impact of LEDBAT on the network.
广泛目标：（i）了解不同网络机制对LEDBAT的影响，（ii）了解LEDBAT对网络的影响。
Network mechanisms and dynamics can influence LEDBAT flows in unintended ways. For instance, frequent route changes that result in increasing base delays may, in the worst case, throttle a LEDBAT flow's throughput significantly. The influence of different network traffic management mechanisms on LEDBAT throughput should be studied.
网络机制和动态会以非预期的方式影响LEDBAT流。例如，导致基本延迟增加的频繁路由更改在最坏的情况下可能会显著限制LEDBAT流的吞吐量。应研究不同网络流量管理机制对LEDBAT吞吐量的影响。
An increasing number of LEDBAT flows in the network will likely result in operator-visible network effects as well, and these should thus be studied. For instance, as long as the bottleneck queue in a network is larger than TARGET (in terms of delay), we expect that both the average queueing delay and loss rate in the network should reduce as LEDBAT traffic increasingly dominates the traffic mix in the network. Note that for bottleneck queues that are smaller than TARGET, LEDBAT will appear to behave very similar to standard TCP and its flow-level behavior may not be distinguishable from that of standard TCP.
网络中越来越多的LEDBAT流可能也会导致运营商可见的网络效应，因此应对此进行研究。例如，只要网络中的瓶颈队列大于目标队列（就延迟而言），我们期望网络中的平均排队延迟和丢失率都应该减少，因为LEDBAT流量日益主导网络中的流量组合。请注意，对于小于目标的瓶颈队列，LEDBAT的行为与标准TCP非常相似，其流级行为可能无法与标准TCP的流级行为区分开来。
We note that a network operator may be able to verify the operation of a LEDBAT flow by monitoring per-flow behavior and queues in the network -- when the queueing delay at a bottleneck queue is above TARGET as specified in this document, LEDBAT flows should be expected to back off and reduce their sending rate.
我们注意到，网络运营商可能能够通过监控网络中的每个流行为和队列来验证LEDBAT流的操作——当瓶颈队列的排队延迟高于本文档中指定的目标时，应预期LEDBAT流后退并降低其发送速率。
The throughput and response of LEDBAT to the proposed parameter values of TARGET, decrease-GAIN, BASE_HISTORY, INIT_CWND, and MIN_CWND should be evaluated with different types of competing traffic in different network settings, including with different AQM schemes at the bottleneck queue. TARGET controls LEDBAT's added latency, while decrease-GAIN controls LEDBAT's response to competing traffic. Since LEDBAT is intended to be minimally intrusive to competing traffic, the impact of TARGET and decrease-GAIN on delay-sensitive traffic should be studied. TARGET also impacts the growth rate of the congestion window when off_target is smaller than 1. This impact of TARGET on the rate of cwnd growth should be studied. The amount of history maintained by the base delay estimator, BASE_HISTORY, influences the responsiveness of LEDBAT to changing network conditions. LEDBAT's responsiveness and throughput should be evaluated in the wide area and under conditions where abrupt changes in base delay might occur, such as with route changes and with cellular handovers. The impact and efficacy of these parameters should be carefully studied with tests over the Internet.
LEDBAT的吞吐量和对目标、减少增益、基本历史、初始CWND和最小CWND的建议参数值的响应应在不同网络设置下的不同竞争流量类型下进行评估，包括在瓶颈队列中使用不同的AQM方案。目标控制LEDBAT增加的延迟，而减少增益控制LEDBAT对竞争流量的响应。由于LEDBAT对竞争流量的干扰最小，因此应研究目标和减少增益对延迟敏感流量的影响。当off_TARGET小于1时，TARGET还会影响拥塞窗口的增长率。应研究目标对cwnd增长率的影响。由基本延迟估计器（base_history）维护的历史量影响LEDBAT对不断变化的网络条件的响应。LEDBAT的响应能力和吞吐量应在广域范围内以及可能发生基础延迟突然变化的条件下进行评估，例如路由变化和蜂窝切换。应通过互联网上的测试仔细研究这些参数的影响和功效。
LEDBAT's effectiveness depends on a sender's ability to accurately estimate end-to-end queueing delay from delay samples. Consequently, the filtering algorithm used for this estimation, FILTER(), is an important candidate for experiments. This document suggests the use of NULL, EWMA, and MIN filters for estimating the current delay; the efficacy of these and other possible filters for this estimate should be investigated. FILTER() may also impact cwnd dynamics when delay samples are bundled in ACKs, since cwnd adaption is done once per ACK irrespective of the number of delay samples in the ACK. This impact should be studied when the different filters are considered.
LEDBAT的有效性取决于发送方根据延迟样本准确估计端到端排队延迟的能力。因此，用于此估计的滤波算法FILTER（）是实验的重要候选算法。本文件建议使用NULL、EWMA和MIN过滤器来估计当前延迟；应调查这些和其他可能的过滤器对该估计的有效性。当延迟样本捆绑在ACK中时，FILTER（）还可能影响cwnd动态，因为无论ACK中延迟样本的数量如何，cwnd自适应都会在每个ACK中执行一次。当考虑不同的过滤器时，应研究这种影响。
This document defines only a congestion control algorithm and assumes that framing mechanisms for exchanging delay information exist within the protocol in which LEDBAT is being implemented. If implemented in a new protocol, both the sender and receiver may be LEDBAT-aware, but if implemented in an existing protocol that is capable of providing one-way delay information, LEDBAT may be implemented as a sender-side-only modification. In either case, the parent protocol may interact with LEDBAT's algorithms; for instance, the rate of ACK feedback to the data sender may be dictated by other protocol parameters, but will interact with the LEDBAT flow's dynamics. Careful experimentation is necessary to understand and integrate LEDBAT into both new and existing protocols.
本文件仅定义了一种拥塞控制算法，并假设在实施LEDBAT的协议中存在用于交换延迟信息的帧机制。如果在新协议中实现，发送方和接收方都可以感知LEDBAT，但是如果在能够提供单向延迟信息的现有协议中实现，LEDBAT可以实现为仅发送方的修改。在任何一种情况下，父协议都可能与LEDBAT的算法交互；例如，发送给数据发送方的ACK反馈速率可能由其他协议参数决定，但会与LEDBAT流的动态相互作用。仔细的实验对于理解LEDBAT并将其集成到新的和现有的协议中是必要的。
LEDBAT's aggressiveness is contingent on the delay estimates and on the TARGET delay value. If these parameter values at the sender are compromised such that delay estimates are artificially set to zero and the TARGET delay value is set to +INFINITY, the LEDBAT algorithm deteriorates to TCP-like behavior. Thus, while LEDBAT is sensitive to these parameters, the algorithm is fundamentally limited in the worst case to be as aggressive as standard TCP.
莱德巴特的攻击性取决于延迟估计和目标延迟值。如果发送方的这些参数值受到损害，从而人为地将延迟估计设置为零，并且将目标延迟值设置为+无穷大，则LEDBAT算法将退化为类似TCP的行为。因此，虽然LEDBAT对这些参数很敏感，但在最坏的情况下，该算法基本上受到限制，与标准TCP一样具有攻击性。
A man in the middle may be able to change queueing delay on a network path, and/or modify the timestamps transmitted by a LEDBAT sender and/or modify the delays reported by a LEDBAT receiver, thus causing a LEDBAT flow to back off even when there's no congestion. A protocol using LEDBAT ought to minimize the risk of such man-in-the-middle attacks by at least authenticating the timestamp field in the data packets and the delay field in the ACK packets.
中间的人可能能够改变网络路径上的排队延迟，和/或修改由LeBAT发送器发送的时间戳和/或修改由LeBAT接收器报告的延迟，从而导致即使在没有拥塞的情况下也能使LeBAT流退回。使用LEDBAT的协议应该通过至少认证数据分组中的时间戳字段和ACK分组中的延迟字段来最小化这种中间人攻击的风险。
LEDBAT is not known to introduce any new concerns with privacy, integrity, or other security issues for flows that use it. LEDBAT is compatible with use of IPsec and Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS).
众所周知，LEDBAT不会对使用它的流的隐私性、完整性或其他安全问题提出任何新的担忧。LEDBAT与IPsec和传输层安全（TLS）/数据报传输层安全（DTLS）的使用兼容。
We thank folks in the LEDBAT working group for their comments and feedback. Special thanks to Murari Sridharan and Rolf Winter for their patient and untiring shepherding.
我们感谢LEDBAT工作组的成员提出的意见和反馈。特别感谢Murari Sridharan和Rolf Winter的耐心和不懈的牧羊。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[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月。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
[RFC6298]Paxson，V.，Allman，M.，Chu，J.，和M.Sargent，“计算TCP的重传计时器”，RFC 62982011年6月。
[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., Testa, C., and S. Valenti, "Rethinking Low Extra Delay Background Transport Protocols", October 2010, <http://arxiv.org/abs/1010.5623v1>.
[Car10]Carofiglio，G.，Muscariello，L.，Rossi，D.，Testa，C.，和S.Valenti，“重新思考低额外延迟背景传输协议”，2010年10月<http://arxiv.org/abs/1010.5623v1>.
[Low02] Low, S., Peterson, L., and L. Wang, "Understanding TCP Vegas: A Duality Model", JACM 49 (2), March 2002.
[Low02]Low，S.，Peterson，L.，和L.Wang，“理解TCP拉斯维加斯：二元模型”，JACM 49（2），2002年3月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort Transport Protocols", RFC 6297, June 2011.
[RFC6297]Welzl，M.和D.Ros，“低于最大努力传输协议的调查”，RFC 62972011年6月。
[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 22nd International Teletraffic Congress (ITC22), September 2010.
[Sch10]Schneider，J.，Wagner，J.，Winter，R.，和H.Kolbe，“别挡我的路——评估ADSL接入网络中的低额外延迟背景传输”，第22届国际电信大会（ITC22）会议记录，2010年9月。
[g114] "SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS; International telephone connections and circuits - General; Recommendations on the transmission quality for an entire international telephone connection; One-way transmission time", ITU-T Recommendation G.114, 05/2003.
[g114]“G系列：传输系统和媒体、数字系统和网络；国际电话连接和电路——概述；关于整个国际电话连接传输质量的建议；单向传输时间”，ITU-T建议G.11405/2003。
[uTorrent] Hazel, G., "uTorrent Transport Protocol library", July 2012, <http://github.com/bittorrent/libutp>.
[uTorrent]Hazel，G.，“uTorrent传输协议库”，2012年7月<http://github.com/bittorrent/libutp>.
LEDBAT measures and uses one-way delays, and we now consider measurement errors in timestamp generation and use. In this section, we use the same locally linear clock model and the same terminology as Network Time Protocol (NTP) [RFC5905]. In particular, NTP uses the terms "offset" to refer to the difference between measured time and true time, and "skew" to refer to difference of clock rate from the true rate. A clock thus has two time measurement errors: a fixed offset from the true time, and a skew. We now consider these errors in the context of LEDBAT.
LeBAT测量并使用单向延迟，我们现在考虑时间戳生成和使用中的测量误差。在本节中，我们使用与网络时间协议（NTP）[RFC5905]相同的本地线性时钟模型和术语。具体而言，NTP使用术语“偏移”表示测量时间和真实时间之间的差异，“偏移”表示时钟速率与真实速率之间的差异。因此，时钟有两个时间测量误差：与真实时间的固定偏移和偏移。我们现在在莱德巴特的背景下考虑这些错误。
The offset of the clocks, both the sender's and the receiver's, shows up as a fixed error in LEDBAT's one-way delay measurement. The offset in the measured one-way delay is simply the difference in offsets between the receiver's and the sender's clocks. LEDBAT, however, does not use this estimate directly, but uses the difference between the measured one-way delay and a measured base delay. Since the offset error (difference of clock offsets) is the same for the measured one-way delay and the base delay, the offsets cancel each other out in the queuing delay estimate, which LEDBAT uses for its window computations. Clock offset error thus has no impact on LEDBAT.
在LEDBAT的单向延迟测量中，发送方和接收方的时钟偏移显示为固定误差。测得的单向延迟中的偏移量只是接收器和发送器时钟之间的偏移量差。然而，LEDBAT不直接使用该估计，而是使用测量的单向延迟和测量的基本延迟之间的差值。由于测得的单向延迟和基本延迟的偏移误差（时钟偏移的差值）相同，因此这些偏移在LEDBAT用于窗口计算的排队延迟估计中相互抵消。因此，时钟偏移误差对LEDBAT没有影响。
Clock skew generally shows up as a linearly changing error in a time estimate. Similar to the offset, the skew of LEDBAT's one-way delay estimate is thus the difference between the two clocks' skews. Unlike the offset, however, skew does not cancel out when the queuing delay estimate is computed, since it causes the two clocks' offsets to change over time.
时钟偏差通常表现为时间估计中的线性变化误差。与偏移量类似，LEDBAT的单向延迟估计值的偏差就是两个时钟偏差之间的差值。然而，与偏移不同的是，在计算排队延迟估计时，skew不会抵消，因为它会导致两个时钟的偏移量随时间变化。
While the offset could be large, with some clocks off by minutes or even hours or more, skew is typically small. Typical skews of untrained clocks seem to be around 100-200 parts per million (ppm) [RFC5905], where a skew of 100 ppm translates to an error accumulation of 6 milliseconds per minute. This accumulation is limited in LEDBAT, since any error accumulation is limited to the amount of history maintained by the base delay estimator, as dictated by the BASE_HISTORY parameter. The effects of clock skew error on LEDBAT should generally be insignificant unless the skew is unusually high, or unless extreme values have been chosen for TARGET (extremely low) and BASE_HISTORY (extremely large). Nevertheless, we now consider the possible impact of skew on LEDBAT behavior.
虽然偏移量可能很大，一些时钟的偏移量为分钟甚至小时或更长，但偏移量通常很小。未经培训的时钟的典型偏差似乎约为100-200 ppm[RFC5905]，其中100 ppm的偏差转化为每分钟6毫秒的误差累积。这种累积在LEDBAT中是有限的，因为任何误差累积都被限制在基本延迟估计器维持的历史量内，如基本_历史参数所指示。时钟偏差误差对LEDBAT的影响通常应不显著，除非偏差异常高，或者为目标（极低）和基准_历史（极大）选择了极值。然而，我们现在考虑歪斜对莱德巴特行为的可能影响。
Clock skew can manifest in two ways: the sender's clock can be faster than the receiver's clock, or the receiver's clock can be faster than the sender's clock. In the first case, the measured one-way delay will decrease as the sender's clock drifts forward. While this drift can lead to an artificially low estimate of the queueing delay, the drift should also lead to a lower base delay measurement, which consequently absorbs the erroneous reduction in the one-way delay estimates.
时钟偏移可以通过两种方式表现：发送方的时钟可以快于接收方的时钟，或者接收方的时钟可以快于发送方的时钟。在第一种情况下，测得的单向延迟将随着发送方时钟向前漂移而减小。虽然这种漂移会导致对排队延迟的人为低估计，但这种漂移也会导致较低的基本延迟测量，从而吸收单向延迟估计中的错误减少。
In the second case, the one-way delay estimate will artificially increase with time. This increase can reduce a LEDBAT flow's throughput unnecessarily. In this case, a skew correction mechanism can be beneficial.
在第二种情况下，单向延迟估计将人为地随时间增加。这种增加会不必要地降低LEDBAT流的吞吐量。在这种情况下，倾斜校正机制可能是有益的。
We now discuss an example clock skew correction mechanism. In this example, the receiver sends back raw (sending and receiving) timestamps. Using this information, the sender can estimate one-way delays in both directions, and the sender can also compute and maintain an estimate of the base delay as would be observed by the receiver. If the sender detects the receiver reducing its estimate of the base delay, it may infer that this reduction is due to clock drift. The sender then compensates by increasing its base delay estimate by the same amount. To apply this mechanism, timestamps need to be transmitted in both directions.
我们现在讨论一个示例时钟偏移校正机制。在此示例中，接收器发回原始（发送和接收）时间戳。使用此信息，发送方可以估计两个方向上的单向延迟，并且发送方还可以计算并保持接收机将观察到的基本延迟的估计。如果发送方检测到接收机减少了其对基址延迟的估计，则可以推断该减少是由于时钟漂移引起的。然后，发送方通过将其基本延迟估计值增加相同的量来进行补偿。为了应用这种机制，需要在两个方向上传输时间戳。
We now outline a few other ideas that can be used for skew correction.
现在，我们概述了一些可用于倾斜校正的其他想法。
o Skew correction with faster virtual clock:
o 使用更快的虚拟时钟进行倾斜校正：
Since having a faster clock on the sender will result in continuous updates of the base delay, a faster virtual clock can be used for sender timestamping. This virtual clock can be computed from the default machine clock through a linear transformation. For instance, with a 500 ppm speed-up the sender's clock is very likely to be faster than a receiver's clock. Consequently, LEDBAT will benefit from the implicit correction when updating the base delay.
由于在发送方上具有更快的时钟将导致基本延迟的连续更新，因此更快的虚拟时钟可用于发送方时间戳。该虚拟时钟可以通过线性变换从默认机器时钟计算出来。例如，在500 ppm的加速下，发送方的时钟很可能比接收方的时钟快。因此，在更新基准延迟时，LEDBAT将受益于隐式校正。
o Skew correction with estimating drift:
o 带估计漂移的倾斜校正：
A LEDBAT sender maintains a history of base delay minima. This history can provide a base to compute the clock skew difference between the two hosts. The slope of a linear function fitted to the set of minima base delays gives an estimate of the clock skew. This estimation can be used to correct the clocks. If the other endpoint is doing the same, the clock should be corrected by half of the estimated skew amount.
LEDBAT发送器保持基本延迟最小值的历史记录。此历史记录可以为计算两台主机之间的时钟偏差差异提供基础。拟合到最小基延迟集合的线性函数的斜率给出了时钟偏移的估计。此估计可用于校正时钟。如果另一个端点也在这样做，则时钟应按估计的偏移量的一半进行校正。
o Byzantine skew correction:
o 拜占庭倾斜校正：
When it is known that each host maintains long-lived connections to a number of different other hosts, a byzantine scheme can be used to estimate the skew with respect to the true time. Namely, a host calculates the skew difference for each of the peer hosts as described with the previous approach, then take the median of the skew differences. While this scheme is not universally applicable, it combines well with other schemes, since it is essentially a clock training mechanism. The scheme also corrects fast, since state is preserved between connections.
当已知每个主机与许多不同的其他主机保持长期连接时，可以使用拜占庭方案来估计相对于真实时间的偏差。即，主机按照前面的方法计算每个对等主机的倾斜差异，然后取倾斜差异的中值。虽然该方案并不普遍适用，但它与其他方案结合良好，因为它本质上是一种时钟训练机制。由于连接之间的状态保持不变，因此该方案也能快速纠正错误。
Authors' Addresses
作者地址
Stanislav Shalunov BitTorrent, Inc. 303 Second St., Suite S200 San Francisco, CA 94107 USA
StitasLav-Salunv BitTorrent，公司303秒ST，套房S200旧金山，CA 94107美国
EMail: shalunov@shlang.com
URI: http://shlang.com
EMail: shalunov@shlang.com
URI: http://shlang.com
Greg Hazel BitTorrent, Inc. 303 Second St., Suite S200 San Francisco, CA 94107 USA
Greg Hazel BitTorrent，公司303秒ST，套房S200旧金山，CA 94107美国
EMail: greg@bittorrent.com
EMail: greg@bittorrent.com
Janardhan Iyengar Franklin and Marshall College 415 Harrisburg Ave. Lancaster, PA 17603 USA
美国宾夕法尼亚州兰开斯特哈里斯堡大道415号詹纳丹·伊扬格·富兰克林和马歇尔学院，邮编17603
EMail: jiyengar@fandm.edu
EMail: jiyengar@fandm.edu
Mirja Kuehlewind University of Stuttgart Stuttgart DE
斯图加特斯图加特大学
EMail: mirja.kuehlewind@ikr.uni-stuttgart.de
EMail: mirja.kuehlewind@ikr.uni-stuttgart.de