[要約] RFC 6817は、Low Extra Delay Background Transport（LEDBAT）プロトコルに関するものであり、遅延を最小限に抑えながらバックグラウンドトラフィックを送信することを目的としています。LEDBATは、ネットワークの過負荷を回避し、他のトラフィックに影響を与えずにバックグラウンドアプリケーションのパフォーマンスを向上させることを目指しています。
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.
Low Extra Delay Background Transport（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.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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]は、ボトルネックで競合するフロー間で公平にボトルネックリンクの帯域幅を共有しようとします。これは、インターネットで使用される主な輻輳制御メカニズムです。ただし、すべてのアプリケーションがネットワークスループットの公平なシェアを求めるわけではありません。ソフトウェア更新プログラムやファイル共有アプリケーションなどの「バックグラウンド」アプリケーションは、よりインタラクティブで遅延や帯域幅に敏感な「フォアグラウンド」アプリケーションのパフォーマンスを妨げることなく動作しようとします。 [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.
Low Extra Delay Background Transport（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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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）で使用でき、必要に応じて適切な拡張を行います。また、ピアツーピア（P2P）アプリケーションのUDPの上に構築されたプロトコルなど、独自のアプリケーションプロトコルで使用できます。
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].
[RFC3168]で指定されているように、ECN対応のフレーミングプロトコルで使用する場合、LEDBATは、明示的な輻輳通知（ECN）マークに反応して、損失に対応する必要があります。
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よりも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]、輻輳ウィンドウを増やします。これは、ネットワークにリンクエラーがない場合、エンド上のボトルネックリンクのキューがto-endパスがオーバーフローするか、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）を使用して、送信側が1回のラウンドトリップ時間（RTT）でネットワークに送信できるデータの量をゲートします。送信者はバイトまたはパケットでそのcwndを維持してもよい（MAY）。このドキュメントではバイト単位の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の初期ウィンドウで開始する場合があります。 （INIT_CWNDについては、セクション2.5で後述します。）
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()
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.
受信者は、たとえば標準TCPの遅延ACKのように、ACKの送信を遅延することを選択し、複数のデータパケットの確認応答を1つのACKパケットに結合できます。そのような場合、受信機はすべての遅延サンプルを1つのACKパケットにバンドルしてもよい（MAY）、生成された順序でサンプルを送信しなければならない（MUST）。複数の遅延サンプルが単一の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で後ほど説明します。 TARGETは、LEDBAT自体がネットワークに導入する可能性のある最大のキューイング遅延であり、GAINはcwndがキューイング遅延の変化に応答する速度を決定します。両方の定数は後で指定されます。 off_targetは、測定された現在のキューイング遅延と所定のTARGET遅延との差を表す正規化された値です。 off_targetは正または負にできます。その結果、cwndはoff_targetに比例して増加または減少します。
on initialization: base_delay = +INFINITY
初期化時：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
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()は、エンドツーエンドパスの基本遅延の変化を測定および追跡するために、1分の間隔で一方向遅延の最小値のリストを維持します。これらのリストは両方とも、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
CURRENT_FILTER要素を持つcurrent_delaysリストを作成しますBASE_HISTORY要素を持つbase_delaysリストを作成しますbase_delays内の要素を+ INFINITYに初期化しますFILTER()に従ってcurrent_delays内の要素を初期化します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.
確認時：＃flightizeは、このACKが受信される前に未処理のデータ量で、＃後で更新されます。 ＃bytes_newly_ackedは、このACKが新しく確認したバイト数＃であり、MSSに設定される場合があります。
for each delay sample in the acknowledgement: delay = acknowledgement.delay update_base_delay(delay) update_current_delay(delay)
確認応答の各遅延サンプル：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()
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
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_CTO()＃データを使用してRTT推定メカニズムを実装します＃送信時間とACK受信時間＃輻輳タイムアウト（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
update_current_delay（delay）＃監視された最後の遅延CURRENT_FILTERのリストを維持します。 current_delaysリストの最初の項目を削除し、current_delaysリストに遅延を追加します
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)
update_base_delay（delay）＃BASE_HISTORY delay-minimaを維持します。 ＃各最小値は1分間測定されます。 ＃ 'now'は、round_to_minute（now）の場合、現在のシステム時刻です！= round_to_minute（last_rollover）last_rollover = now base_delaysリストの最初の項目を削除し、base_delaysリストに遅延を追加します。それ以外の場合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()を実装して外れ値を排除することにより、current_delayサンプルから実際の遅延推定値を抽出しようとします。 FILTER()にはさまざまなタイプのフィルターを使用できます-フィルターをまったくかけないNULLフィルターも妥当な候補です。LEDBATがcwndの増加と減少にリニアコントローラーを使用すると、フィルターをすばやく回復できるためです。不良サンプルによって引き起こされるエラー。フィルターのもう1つの例は、変化するネットワーク遅延の俊敏な追跡を可能にする重みを持つ、指数加重移動平均（EWMA）関数です。小さなウィンドウ（BASE_HISTORYよりもはるかに小さい）に適用される単純なMINフィルターは、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.
複数の遅延サンプルが1つのACKにバンドルされている場合、送信者の結果のcwndは、サンプルが個別のACKで個別に送信される場合とは若干異なる場合があることに注意してください。 cwndは、ACK内の遅延サンプルの数に関係なく、ACKされたバイトの総数と、filtering_delayの最終的なフィルタリングされた値に基づいて調整されます。
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送信者はBASE_HISTORYの個別の最小値を保存します。最後のBASE_HISTORY-1分間に1つずつ、現在の1分間に1つです。現在の分の終わりに、ウィンドウが移動します。最も早い最小値が削除され、最後の最小値が追加されます。接続が一定の時間アイドル状態の場合、一方向の遅延に使用できるデータがないため、+ INFINITYの値をリストに格納する必要があります。接続がBASE_HISTORY分間アイドル状態であった場合、リスト内のすべての最小値は+ INFINITYに設定され、新たに測定が開始されます。したがって、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の成長を制限します。送信者がアプリケーションに制限されている場合、送信者のcwndは、max_allowed_cwndを使用して、flightsizeを少し超える値に制限されます。 TCPBATに対応するために、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 MSSに減少し、CTO間隔の指数バックオフになります。 CTO値のこのバックオフにより、過負荷のキューにさらにデータが送信されるのを防ぎ、送信者がパスのRTTの突然の変化に対処することもできます。 CTOの機能はTCPの再送信タイムアウト（RTO）の機能と似ていますが[RFC6298]、LEDBATは信頼性を輻輳制御から分離しているため、CTOが再送信をトリガーする必要はありません。ただし、LEDBATは、LEDBAT輻輳制御がTCPフレーミングおよび信頼性とともに使用される場合のように、CTOが再送信をトリガーすることを妨げません。
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に基づいて設定された「next-time-to-send」変数を使用して、送信者が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.
TARGETは100ミリ秒以下である必要があり、この値の選択はセクション3.3でさらに説明されています。 LEDBATフロー全体で同じTARGET値を使用すると、ボトルネック帯域幅を公平に共有できることに注意してください。他の競合するLEDBATフローよりも高いTARGET値を持つフローは、ボトルネック帯域幅の大きなシェアを獲得する可能性があります。優先度の高いフローに対してより高いTARGET値を設定することにより、2つの競合するLEDBATフロー間の相対的な優先度を実装するために、異なるTARGET値の使用を検討することが可能です。
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.
ALLOWED_INCREASEは1である必要があり、0より大きくなければなりません。0のALLOWED_INCREASEは、cwndの増加をまったく引き起こさず、1のALLOWED_INCREASEは、以前のRTTのフライトサイズに基づいてcwndの増加を許可および制限します。 1より大きいALLOWED_INCREASEは、LEDBATとフレーミングプロトコル間の相互作用がそうする明確な理由を提供する場合に使用される場合があります。
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 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.
GAINは1以下に設定する必要があります。 GAINが1の場合、最大cwndランプアップは、輻輳回避のTCP Renoと同じレートに制限されます。このドキュメントでは、cwndの増加（off_targetがゼロより大きい場合）と減少（off_targetがゼロ未満の場合）の両方に同じGAINを使用することを指定していますが、実装では、増加よりもcwndの減少に高いGAINを使用できます。私たちの正当化は次のとおりです。競合する非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.
base_delaysリストのサイズ、BASE_HISTORY、SHOULDは10です。たとえば、ルートの変更により実際のベース遅延が減少した場合、BASE_HISTORYの値に関係なく、LEDBAT送信側はすぐに適応します。ただし、実際のベース遅延が増加した場合、LEDBAT送信側は適応にBASE_HISTORY分かかり、その間、意図した（TARGET）よりも少しだけ余分な遅延が誤って推論される可能性があります。したがって、BASE_HISTORYの値はトレードオフです。値が大きいほど、ベース遅延が変化していないときにより正確な測定が得られ、値が小さいほど、ベース遅延の実際の増加に対する応答が速くなります。
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リストを使用して、過去のRTT時間内に行われた遅延測定のみを維持し、ネットワークを介した現在の一方向遅延の測定におけるノイズスパイクを排除しようとします。このリストのサイズCURRENT_FILTERは可変であり、FILTER()関数と、過去のRTT時間内に行われた成功した測定の数によって異なります。送信者は、各RTTで十分な遅延サンプルを収集して、測定値に統計的な信頼性を持たせるようにする必要があります。このような信頼性に必要な遅延サンプルの数はネットワークの状態によって異なりますが、輻輳ウィンドウが小さいためにサンプル数が少ない場合を除き、送信者は各RTTで少なくとも4つの遅延サンプルを使用する必要があります（SHOULD）。 CURRENT_FILTERの値は、使用されているフィルターによって異なりますが、リスト内のサンプルが過去のRTTよりも古くないように、CURRENT_FILTERを制限する必要があります。
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である必要があります。2のINIT_CWNDは、フローの最初にサンプルがない場合に送信者でFILTER()をシードするのに役立ち、2のMIN_CWNDにより、FILTER()は単一の瞬間的な遅延より多くを使用できますあまり積極的ではなく見積もります。たとえば、INIT_CWNDおよびMIN_CWNDのこれらの値がフレーミングプロトコルと十分に相互作用しない場合、わずかな偏差が保証される場合があります。ただし、INIT_CWNDとMIN_CWNDは、TCP [RFC5681]に指定された対応する値以下でなければなりません（MUST）。
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は、測定がデータパケットで行われることを想定しているため、個別の測定パケットの必要性を回避し、ネットワーク内のデータパケットとは異なる方法で処理される測定パケットの落とし穴を回避します。
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 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は、エンドツーエンドの遅延測定とベース遅延の現在の推定値の差として、キューイング遅延を測定します。パス上のノードでの処理遅延のスパイクなどによる遅延推定のノイズを排除するには、キューイング遅延を（使用シナリオに応じて）フィルタリングする必要があります。
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.
このドキュメントのTARGETパラメータで指定されているように、キューイング遅延が遅延ターゲット値よりも小さい場合、LEDBAT送信側は、現在のキューイング遅延と遅延ターゲットの間の相対差に比例して輻輳ウィンドウを増やします。現在のキューイング遅延がTARGETに近づくと、LEDBATのウィンドウの成長が遅くなります。同時TCPフローと公平に競争するために、LEDBATのウィンドウ成長の最大レート（現在のキューイング遅延の見積もりがゼロの場合）をTCPと同じになるように設定します（RTTあたり1パケットの増加）。つまり、LEDBATフローは、同じパス上で競合するTCPフローよりも速く立ち上がることはありません。 TARGET値は、LEDBATが引き起こす最大の追加のキューイング遅延を指定します。現在のキューイング遅延がTARGET値と等しい場合、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ごとに最大で1回、その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ミリ秒を十分に下回る必要があります。一方、ターゲットが低すぎると、一方向遅延および遅延測定プロセスのノイズに対する送信者のアルゴリズムの感度が高くなり、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].
ターゲットとしてこれらの考慮事項の間のトレードオフである100 ms以下の推奨事項。事例証拠は、この値が適切に機能することを示しています-LEDBATが実装され、2つのBitTorrent実装で100 msのターゲット値で正常に展開されました：BitTorrent Delivery Network Accelerator（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.
LEDBATを使用するプロトコルの実際のフレーミングとワイヤフォーマットはこのドキュメントの範囲外ですが、LEDBATメカニズムのデータフレーミングと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レシーバーは、受信したデータパケットごとに1つまたはそれ以下の頻度でACKを送信できます。 LEDBATは、レシーバーがすべてのRTTで少なくとも1つの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 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 [RFC5681]よりも早く輻輳表示に応答するように設計されています。キューイング遅延の見積もりが低くなるほど、LEDBATフローはより積極的になります。キューイング遅延の見積もりは負ではないため、キューイング遅延の見積もりがゼロの場合、LEDBATは最も積極的です。この場合、LEDBATは標準TCP [RFC5681]と同じレートで輻輳ウィンドウを増加させます。 LEDBATは、標準のTCPよりも早くレートを低下させる可能性があり、損失時に輻輳ウィンドウを常に半分にします。したがって、遅延推定が完全に一貫してオフである最悪の場合、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の両方）に影響を与えますが、Voice over IP（VoIP）などのボトルネックキューで測定可能な遅延を引き起こさない、低負荷で遅延の影響を受けやすいトラフィックには影響を与えない場合があります。トラフィック。このようなフローでは、並行するLEDBATフローが原因で追加の遅延が発生しますが、TARGET遅延では、並行するすべてのLEDBATフローが共同で誘発する追加の遅延の合計量に制限が設定されます。 TARGET遅延がボトルネックキューが維持できるよりも大きい場合、LEDBATフローは損失を経験し、標準の損失ベースのTCP動作にフォールバックします。したがって、最悪の場合、LEDBATは非TCPフローと競合するときに標準TCPよりもレイテンシを追加しません。ただし、一般的なケースでは、LEDBATフローがTARGETの遅延を追加すると予想されます。これは、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の主要な設計目標は、標準のTCPと競合するときのLEDBATフローの集約動作に焦点を当てています。 LEDBATはバックグラウンドトラフィック用に設計されているため、LEDBATフロー間の公平性よりもリンク使用率が重要であると考えています。それでも、競合するLEDBATフローの中で発生する可能性のある公平性の問題を検討します。
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 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".
遅延ベースの輻輳制御システムでは、後発者が誤って測定し、以前に開始したアクティブフローよりも高いベース遅延を使用する可能性があります。ボトルネックが単一のLEDBATフローによって飽和しているため、フローがボトルネックキューをTARGET遅延に維持していることを考慮してください。新しいLEDBATフローがボトルネックに到達すると、パスのベース遅延の測定に定常キューイング遅延が誤って含まれる可能性があります。新しいフローでは、ベース遅延の推定値が大きくなり、既存の、すでに最大のキューイング遅延の上に効果的に構築できるようになりました。遅発者のフローが増えると、古いフローは実際のキューイング遅延を確認してバックオフしますが、遅発者は増え続け、リンク全体の容量を使い果たし、古いフローを効果的に遮断します。この利点を「後発者の利点」と呼びます。
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.
最悪の場合、最初のフローが新しいフローの送信レートと同じレートで生成される場合、新しいフローは、最初のフローがバックオフするまで、一定のエンドツーエンド遅延（ベース遅延であると想定）を確認します完全に。その結果、2番目のフローがそのcwndの増加を停止するまでに、ターゲットキューイング遅延がネットワークに2倍追加されていました。
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フローが既存のフロー[Car10]よりも不当な利点を得る可能性があることに注意します。実際には、この懸念はネットワークトラフィックのバースト性によって緩和されるべきです。基本遅延を測定するために必要なのは、LEDBATフロー間の伝送スケジュールの小さなギャップの1つだけです。これらのギャップは、アプリケーションの送信パターン、送信者でのOSスケジューリング、送信者または任意のネットワークノードでの処理遅延、リンクの競合が原因で発生する遅延など、さまざまな理由で発生する可能性があります。遅刻者が開始している間に最初の送信者の送信でそのようなギャップが発生した場合、ベース遅延はすぐに正しく測定されます。 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 broad goals: (i) to understand the effects of different network mechanisms on LEDBAT, and (ii) to understand the impact of LEDBAT on the network.
非テールドロップ、非FIFOキューのあるネットワーク、頻繁なルート変更のあるネットワーク、およびネットワークレベルのロードバランシングのあるネットワークでのLEDBATの動作と収束特性を完全に理解するには、さらに調査が必要です。これらの調査には2つの大きな目標があります。（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フローの数が増えると、オペレーターに見えるネットワーク効果も発生する可能性が高いため、これらを調査する必要があります。たとえば、ネットワーク内のボトルネックキューがTARGETよりも大きい限り（遅延に関して）、LEDBATトラフィックがネットワーク内のトラフィックミックスをますます支配するようになるため、ネットワーク内の平均キューイング遅延と損失率の両方が減少するはずです。 。 TARGETよりも小さいボトルネックキューの場合、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フローの動作を確認できる場合があることに注意してください。このドキュメントで指定されているように、ボトルネックキューでのキューイング遅延がTARGETを超えている場合、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.
推奨されるパラメーター値TARGET、減少GAIN、BASE_HISTORY、INIT_CWND、およびMIN_CWNDに対するLEDBATのスループットと応答は、ボトルネックキューでのさまざまなAQMスキームを含め、さまざまなネットワーク設定でさまざまなタイプの競合トラフィックを使用して評価する必要があります。 TARGETはLEDBATの追加レイテンシを制御し、reduce-GAINは競合するトラフィックに対するLEDBATの応答を制御します。 LEDBATは競合するトラフィックへの侵入を最小限に抑えることを目的としているため、遅延の影響を受けやすいトラフィックに対するTARGETと減少ゲインの影響を調査する必要があります。 TARGETは、off_targetが1より小さい場合、輻輳ウィンドウの成長率にも影響します。CARNDの成長率に対するTARGETの影響を調査する必要があります。基本遅延推定器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の遅延サンプルの数に関係なく、cwnd適応はACKごとに1回行われるため、遅延サンプルがACKにバンドルされている場合、FILTER()はcwndダイナミクスにも影響を与える可能性があります。この影響は、さまざまなフィルターを検討するときに検討する必要があります。
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の積極性は、遅延の見積もりとTARGETの遅延値に依存します。送信側のこれらのパラメーター値が危険にさらされ、遅延推定が意図的にゼロに設定され、TARGET遅延値が+ INFINITYに設定されると、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.
真ん中の人は、ネットワークパスのキューイング遅延を変更したり、LEDBAT送信者が送信したタイムスタンプを変更したり、LEDBAT受信者が報告した遅延を変更したりして、LEDBATフローをオフにしても、混雑はありません。 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]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「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、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、2009年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、「Computing TCP's Retransmission Timer」、RFC 6298、2011年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 Vegas：輻輳の検出と回避のための新しい技術」、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、「Rethinking Low Extra Delay Background Transport Protocols」、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、「Understanding TCP Vegas：A Duality Model」、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、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年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 6297、2011年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、「Out of my Way-Evaluating Low Extra Delay Background Transport in aDSL Access Network」、Proceedings of 22nd International Teletraffic Congress（ 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。 114、2003年5月。
[uTorrent] Hazel, G., "uTorrent Transport Protocol library", July 2012, <http://github.com/bittorrent/libutp>.
[uTorrent] Hazel、G。、「uTorrent Transport Protocol library」、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.
LEDBATは一方向の遅延を測定して使用するため、タイムスタンプの生成と使用における測定エラーを考慮します。このセクションでは、ネットワークタイムプロトコル（NTP）[RFC5905]と同じローカル線形クロックモデルと同じ用語を使用します。特に、NTPは「オフセット」という用語を使用して、測定された時間と実際の時間の差を表し、「スキュー」は、クロックレートと実際のレートの差を表します。したがって、クロックには2つの時間測定エラーがあります。それは、真の時間からの固定オフセットとスキューです。これらのエラーをLEDBATのコンテキストで検討します。
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の一方向遅延推定のスキューは、2つのクロックのスキュー間の差です。ただし、オフセットとは異なり、2つのクロックのオフセットが時間とともに変化するため、キューイング遅延の見積もりが計算されるときにスキューはキャンセルされません。
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）のようです。100ppmのスキューは、1分あたり6ミリ秒のエラー累積に相当します。この累積はLEDBATでは制限されます。エラーの累積は、BASE_HISTORYパラメーターで指定されているように、ベース遅延推定器によって維持される履歴の量に制限されるためです。 LEDBATでのクロックスキューエラーの影響は、スキューが異常に高い場合、またはTARGET（非常に低い）とBASE_HISTORY（非常に大きい）に極端な値が選択されていない限り、一般的に重要ではありません。それでも、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.
クロックスキューは、送信者のクロックが受信者のクロックよりも速い場合と、受信者のクロックが送信者のクロックより速い場合の2つの方法で現れます。最初のケースでは、送信者のクロックが進むにつれて、測定された一方向の遅延は減少します。このドリフトは、キューイング遅延の人為的に低い推定につながる可能性がありますが、ドリフトは、基本遅延の測定値が低くなり、その結果、一方向の遅延推定値の誤った減少を吸収します。
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.
2番目のケースでは、一方向の遅延推定値は時間とともに人為的に増加します。この増加により、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送信側は、基本遅延の最小値の履歴を維持します。この履歴は、2つのホスト間のクロックスキューの差を計算するための基礎を提供します。一連の最小ベース遅延に適合した線形関数の勾配により、クロックスキューの推定値が得られます。この推定は、クロックを修正するために使用できます。他のエンドポイントが同じことをしている場合、クロックは推定されたスキュー量の半分だけ修正されるべきです。
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
Stanislav Shalunov BitTorrent、Inc. 303 Second St.、Suite S200 San Francisco、CA 94107 USA
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、Inc. 303 Second St.、Suite S200 San Francisco、CA 94107 USA
EMail: greg@bittorrent.com
Janardhan Iyengar Franklin and Marshall College 415 Harrisburg Ave. Lancaster, PA 17603 USA
Janardhan Iyengar Franklin and Marshall College 415 Harrisburg Ave. Lancaster、PA 17603 USA
EMail: jiyengar@fandm.edu
Mirja Kuehlewind University of Stuttgart Stuttgart DE
Mirja Kuehlewind University of StuttgartシュトゥットガルトDE
EMail: mirja.kuehlewind@ikr.uni-stuttgart.de