Internet Research Task Force (IRTF) M. Bagnulo
Request for Comments: 9840 A. García-Martínez
Category: Experimental Universidad Carlos III de Madrid
ISSN: 2070-1721 G. Montenegro
P. Balasubramanian
Confluent
September 2025
This document specifies receiver-driven Low Extra Delay Background Transport (rLEDBAT) -- a set of mechanisms that enable the execution of a less-than-best-effort congestion control algorithm for TCP at the receiver end. This document is a product of the Internet Congestion Control Research Group (ICCRG) of the Internet Research Task Force (IRTF).
このドキュメントは、受信機駆動型の低追加遅延バックグラウンドトランスポート（rLEDBAT）を指定します。これは、受信者端でのTCPのベストよりも低いエフォルトの混雑制御アルゴリズムの実行を可能にする一連のメカニズムです。このドキュメントは、インターネット研究タスクフォース（IRTF）のインターネット輻輳制御研究グループ（ICCRG）の製品です。
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 Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Internet Congestion Control Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティ向けの実験プロトコルを定義しています。このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）のインターネット輻輳制御研究グループのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9840.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9840で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
2. Conventions and Terminology
3. Motivations for rLEDBAT
4. rLEDBAT Mechanisms
4.1. Controlling the Receive Window
4.1.1. Avoiding Window Shrinking
4.1.2. Setting the Window Scale Option
4.2. Measuring Delays
4.2.1. Measuring RTT to Estimate the Queuing Delay
4.2.2. Measuring One-Way Delay to Estimate the Queuing Delay
4.3. Detecting Packet Losses and Retransmissions
5. Experiment Considerations
5.1. Status of the Experiment at the Time of This Writing
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. rLEDBAT Pseudocode
Acknowledgments
Authors' Addresses
LEDBAT (Low Extra Delay Background Transport) [RFC6817] is a congestion control algorithm used for less-than-best-effort (LBE) traffic.
LEDBAT（余分な遅延バックグラウンドトランスポートが低い）[RFC6817]は、ベストよりも少ない（LBE）トラフィックに使用される混雑制御アルゴリズムです。
When LEDBAT traffic shares a bottleneck with other traffic using standard congestion control algorithms (for example, TCP traffic using CUBIC [RFC9438], hereafter referred to as "standard-TCP" for short), it reduces its sending rate earlier and more aggressively than standard-TCP congestion control, allowing other non-background traffic to use more of the available capacity. In the absence of competing traffic, LEDBAT aims to make efficient use of the available capacity, while keeping the queuing delay within predefined bounds.
LEDBATトラフィックが、標準の混雑制御アルゴリズム（たとえば、Cubic [RFC9438]を使用したTCPトラフィック[RFC9438]を使用してTCPトラフィックを使用して他のトラフィックとボトルネックを共有すると、「標準TCP」と呼ばれる）を共有すると、送信率がより早く、より攻撃的に送信率が低下し、標準的な混雑制御が標準化されない容量を利用できます。競合するトラフィックがない場合、LEDBATは、定義された境界内でキューイングの遅延を維持しながら、利用可能な容量を効率的に使用することを目指しています。
LEDBAT reacts to both packet loss and variations in delay. With respect to packet loss, LEDBAT reacts with a multiplicative decrease, similar to most TCP congestion controllers. Regarding delay, LEDBAT aims for a target queuing delay. When the measured current queuing delay is below the target, LEDBAT increases the sending rate, and when the delay is above the target, it reduces the sending rate. LEDBAT estimates the queuing delay by subtracting the measured current one-way delay from the estimated base one-way delay (i.e., the one-way delay in the absence of queues).
LEDBATは、パケットの損失と遅延の変動の両方に反応します。パケットの損失に関して、LEDBATは、ほとんどのTCP混雑コントローラーと同様に、乗法減少と反応します。遅延に関して、LEDBATはターゲットキューイングの遅延を目指しています。測定された電流キューイング遅延がターゲットを下回ると、LEDBATは送信率を増加させ、遅延がターゲットを上回ると送信率が低下します。LEDBATは、推定されたベースの一方向遅延から測定された電流の一方向遅延を減算することにより、キューイング遅延を推定します（つまり、キューの非存在下での一方向遅延）。
The LEDBAT specification [RFC6817] defines the LEDBAT congestion control algorithm, implemented in the sender to control its sending rate. LEDBAT is specified in a protocol-agnostic and layer-agnostic manner.
LEDBAT仕様[RFC6817]は、送信者に実装されたLEDBAT輻輳制御アルゴリズムを定義し、送信率を制御します。LEDBATは、プロトコルに依存しないおよび層と存在する方法で指定されています。
LEDBAT++ [LEDBAT++] is also an LBE congestion control algorithm that is inspired by LEDBAT while addressing several problems identified with the original LEDBAT specification. In particular, the differences between LEDBAT and LEDBAT++ include the following:
LEDBAT ++ [LEDBAT ++]は、元のLEDBAT仕様で特定されたいくつかの問題に対処しながら、LEDBATに触発されたLBE混雑制御アルゴリズムでもあります。特に、LEDBATとLEDBAT ++の違いには、次のものが含まれます。
i) LEDBAT++ uses the round-trip time (RTT) (as opposed to the one-way delay used in LEDBAT) to estimate the queuing delay.
i) LEDBAT ++は、往復時間（RTT）を使用して（LEDBATで使用されている一方向遅延とは対照的に）キューイング遅延を推定します。
ii) LEDBAT++ uses an additive increase/multiplicative decrease algorithm to achieve inter-LEDBAT++ fairness and avoid the latecomer advantage observed in LEDBAT.
ii）LEDBAT ++は、添加剤の増加/乗法減少アルゴリズムを使用して、LEDBATで観察されるLEDBAT ++の公平性を回避し、LEDBATで観察された潜伏者の利点を回避します。
iii) LEDBAT++ performs periodic slowdowns to improve the measurement of the base delay.
iii）LEDBAT ++は、定期的な減速を実行して、塩基遅延の測定を改善します。
iv) LEDBAT++ is defined for TCP.
iv）LEDBAT ++はTCPに対して定義されています。
In this specification, we describe receiver-driven Low Extra Delay Background Transport (rLEDBAT) -- a set of mechanisms that enable the execution of an LBE delay-based congestion control algorithm such as LEDBAT or LEDBAT++ at the receiver end of a TCP connection.
この仕様では、TCP接続のレシーバー端でLEDBATやLEDBAT ++などのLBE遅延ベースの輻輳制御アルゴリズムの実行を可能にする一連のメカニズムである、レシーバー駆動型の低追加遅延バックグラウンドトランスポート（RLEDBAT）について説明します。
The consensus of the Internet Congestion Control Research Group (ICCRG) is to publish this document to encourage further experimentation and review of rLEDBAT. This document is not an IETF product and is not an Internet Standards Track specification. The status of this document is Experimental. In Section 5 ("Experiment Considerations"), we describe the purpose of the experiment and its current status.
インターネット輻輳制御研究グループ（ICCRG）のコンセンサスは、この文書を公開して、rledBatのさらなる実験とレビューを促進することです。このドキュメントはIETF製品ではなく、インターネット標準の追跡仕様でもありません。このドキュメントのステータスは実験的です。セクション5（「実験の考慮事項」）では、実験の目的と現在の状況について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
We use the following abbreviations throughout the text and include them here for the reader's convenience:
テキスト全体で次の略語を使用し、読者の利便性のためにそれらをここに含めます。
RCV.WND:
rcv.wnd：
The value included in the Receive Window field of the TCP header (the computation of which is modified by its specification).
TCPヘッダーの受信ウィンドウフィールドに含まれる値（その計算は、その仕様によって変更されます）。
SND.WND:
snd.wnd：
The TCP sender's window.
TCP送信者のウィンドウ。
cwnd:
CWND：
The congestion window as computed by the congestion control algorithm running at the TCP sender.
TCP送信者で実行されている輻輳制御アルゴリズムによって計算される輻輳ウィンドウ。
RLWND:
rlwnd：
The window value calculated by the rLEDBAT algorithm.
rledbatアルゴリズムによって計算されたウィンドウ値。
fcwnd:
fcwnd：
The value that a standard-TCP receiver compliant with [RFC9293] calculates to set in the receive window for flow control purposes.
[RFC9293]に準拠した標準-TCPレシーバーが、フロー制御の目的で受信ウィンドウに設定する値を計算します。
RCV.HGH:
rcv.hgh：
The highest sequence number corresponding to a received byte of data at one point in time.
一度に受信したデータのバイトに対応する最高のシーケンス番号。
TSV.HGH:
tsv.hgh：
The Timestamp Value (TSval) [RFC7323] corresponding to the segment in which RCV.HGH was carried at that point in time.
その時点でRCV.HGHが運ばれたセグメントに対応するタイムスタンプ値（TSVAL）[RFC7323]。
SEG.SEQ:
seg.seq：
The sequence number of the last received segment.
最後に受信したセグメントのシーケンス番号。
TSV.SEQ:
tsv.seq：
The TSval of the last received segment.
最後に受信したセグメントのtsval。
rLEDBAT enables new use cases and new deployment models, fostering the use of LBE traffic. The following scenarios are enabled by rLEDBAT:
RLEDBATは、新しいユースケースと新しい展開モデルを可能にし、LBEトラフィックの使用を促進します。次のシナリオは、rledbatによって有効になります。
Content Delivery Networks (CDNs) and more sophisticated file distribution scenarios:
コンテンツ配信ネットワーク（CDN）およびより洗練されたファイル配布シナリオ：
Consider the case where the source of a file to be distributed (e.g., a software developer that wishes to distribute a software update) would prefer to use LBE and enables LEDBAT/LEDBAT++ in the servers containing the source file. However, because the file is being distributed through a CDN that does not implement LBE congestion control, the result is that the file transfers originated from CDN surrogates will not be using LBE. Interestingly enough, in the case of the software update, the developer may also control the software performing the download in the client (the receiver of the file), but because current LEDBAT/ LEDBAT++ are sender-based algorithms, controlling the client is not enough to enable LBE congestion control in the communication. rLEDBAT would enable the use of an LBE traffic class for file distribution in this setup.
配布されるファイルのソース（たとえば、ソフトウェアアップデートを配布したいソフトウェア開発者）がLBEを使用することを好み、ソースファイルを含むサーバーにLEDBAT/LEDBAT ++を有効にする場合を考えてください。ただし、LBE輻輳制御を実装しないCDNを介してファイルが配布されているため、その結果、CDN代理から発生したファイル転送はLBEを使用しません。興味深いことに、ソフトウェアアップデートの場合、開発者はクライアント（ファイルの受信者）でダウンロードを実行するソフトウェアを制御することもできますが、現在のLEDBAT/ LEDBAT ++は送信者ベースのアルゴリズムであるため、クライアントを制御するだけでは通信でLBEうっ血制御を有効にすることができません。rledBatは、このセットアップでファイル配布にLBEトラフィッククラスを使用できるようにします。
Interference from proxies and other middleboxes:
プロキシやその他のミドルボックスからの干渉：
Proxies and other middleboxes are commonplace in the Internet. For instance, in the case of mobile networks, proxies are frequently used. In the case of enterprise networks, it is common to deploy corporate proxies for filtering and firewalling. In the case of satellite links, Performance Enhancing Proxies (PEPs) are deployed to mitigate the effect of long delays in a TCP connection. These proxies terminate the TCP connection on both ends and prevent the use of LBE congestion control in the segment between the proxy and the sink of the content, the client. By enabling rLEDBAT, clients can then enable LBE traffic between them and the proxy.
プロキシやその他のミドルボックスは、インターネットでは一般的です。たとえば、モバイルネットワークの場合、プロキシが頻繁に使用されます。エンタープライズネットワークの場合、フィルタリングとファイアーワークのために企業プロキシを展開することが一般的です。衛星リンクの場合、TCP接続における長い遅延の効果を軽減するために、パフォーマンスを向上させるプロキシ（PEP）が展開されます。これらのプロキシは、両端のTCP接続を終了し、プロキシとコンテンツのシンクであるクライアントとの間のセグメントでのLBE輻輳制御の使用を防ぎます。rledbatを有効にすることにより、クライアントは自分とプロキシの間のLBEトラフィックを有効にすることができます。
Receiver-defined preferences:
受信者定義の設定：
Frequently, the access link is the communication bottleneck. This is particularly true in the case of mobile devices. It is then especially relevant for mobile devices to properly manage the capacity of the access link. With current technologies, it is possible for the mobile device to use different congestion control algorithms expressing different preferences for the traffic. For instance, a device can choose to use standard-TCP for some traffic and use LEDBAT/LEDBAT++ for other traffic. However, this would only affect the outgoing traffic, since both standard-TCP and LEDBAT/LEDBAT++ are driven by the sender. The mobile device has no means to manage the traffic in the downlink, which is, in most cases, the communication bottleneck for a typical "eyeball" end user. rLEDBAT enables the mobile device to selectively use an LBE traffic class for some of the incoming traffic. For instance, by using rLEDBAT, a user can use regular standard-TCP/UDP for a video stream (e.g., YouTube) and use rLEDBAT for other background file downloads.
多くの場合、アクセスリンクは通信ボトルネックです。これは、モバイルデバイスの場合に特に当てはまります。その場合、アクセスリンクの容量を適切に管理するために、モバイルデバイスが特に関連します。現在のテクノロジーを使用すると、モバイルデバイスがトラフィックのさまざまな好みを表現するさまざまな輻輳制御アルゴリズムを使用することが可能です。たとえば、デバイスは一部のトラフィックに標準-TCPを使用することを選択し、他のトラフィックにLEDBAT/LEDBAT ++を使用することができます。ただし、標準-TCPとLEDBAT/LEDBAT ++の両方が送信者によって駆動されるため、これは発信トラフィックにのみ影響します。モバイルデバイスには、ダウンリンクでトラフィックを管理する手段はありません。これは、ほとんどの場合、典型的な「眼球」エンドユーザーの通信ボトルネックです。rledBatを使用すると、モバイルデバイスは、いくつかの入っているトラフィックにLBEトラフィッククラスを選択的に使用できます。たとえば、RLEDBATを使用すると、ユーザーは通常の標準-TCP/UDPをビデオストリーム（YouTubeなど）に使用し、他のバックグラウンドファイルのダウンロードにrledBatを使用できます。
rLEDBAT provides the mechanisms to implement an LBE congestion control algorithm at the receiver end of a TCP connection. The rLEDBAT receiver controls the sender's rate through the receive window announced by the receiver in the TCP header.
RLEDBATは、TCP接続の受信エンドでLBE輻輳制御アルゴリズムを実装するメカニズムを提供します。rledBatレシーバーは、TCPヘッダーの受信機によって発表された受信ウィンドウを通じて送信者のレートを制御します。
rLEDBAT assumes that the sender is a standard-TCP sender. rLEDBAT does not require any rLEDBAT-specific modifications to the TCP sender. The envisioned deployment model for rLEDBAT is that the clients implement rLEDBAT and this enables rLEDBAT in communications with existing standard-TCP senders. In particular, the sender MUST implement [RFC9293] and also MUST implement the TCP Timestamps (TS) option as defined in [RFC7323]. Also, the sender should implement some of the standard congestion control mechanisms, such as CUBIC [RFC9438] or NewReno [RFC5681] [RFC6582].
rledbatは、送信者が標準TCP送信者であると想定しています。rledbatは、TCP送信者に対するrledBat固有の変更を必要としません。RLEDBATの想定されている展開モデルは、クライアントがRLEDBATを実装し、これにより既存の標準-TCP送信者との通信を可能にすることです。特に、送信者は[RFC9293]を実装する必要があり、[RFC7323]で定義されているように、TCPタイムスタンプ（TS）オプションを実装する必要があります。また、送信者は、Cubic [RFC9438]やNewReno [RFC5681] [RFC6582]などの標準的な混雑制御メカニズムの一部を実装する必要があります。
rLEDBAT does not define a new congestion control algorithm. The definition of the actual LBE congestion control algorithm executed in the rLEDBAT receiver is beyond the scope of this document. The rLEDBAT receiver MUST use an LBE congestion control algorithm. Because rLEDBAT assumes a standard-TCP sender, the sender will be using a "best effort" congestion control algorithm (such as CUBIC or NewReno). Since rLEDBAT uses the receive window to control the sender's rate and the sender calculates the sender's window as the minimum of the receive window and the congestion window, rLEDBAT will only be effective as long as the congestion control algorithm executed in the receiver yields a smaller window than the one calculated by the sender. This is normally the case when the receiver is using an LBE congestion control algorithm. The rLEDBAT receiver SHOULD use the LEDBAT congestion control algorithm [RFC6817] or the LEDBAT++ congestion control algorithm [LEDBAT++]. rLEDBAT MAY use other LBE congestion control algorithms defined elsewhere. Irrespective of which congestion control algorithm is executed in the receiver, a rLEDBAT connection will never be more aggressive than standard-TCP, since it is always bounded by the congestion control algorithm executed at the sender.
rledbatは、新しい輻輳制御アルゴリズムを定義しません。rledBatレシーバーで実行された実際のLBE輻輳制御アルゴリズムの定義は、このドキュメントの範囲を超えています。rledbatレシーバーは、lbe輻輳制御アルゴリズムを使用する必要があります。rledBatは標準-TCP送信者を想定しているため、送信者は「最良の」渋滞制御アルゴリズム（CubicやNewrenoなど）を使用します。rledbatは受信ウィンドウを使用して送信者のレートを制御し、送信者は送信者のウィンドウを受信ウィンドウの最小値と輻輳ウィンドウとして計算するため、レディバットがレシーバーで実行された輻輳制御アルゴリズムが送信者によって計算されたものよりも小さなウィンドウを生成する限り、rledbatは効果的です。これは通常、受信機がLBE輻輳制御アルゴリズムを使用している場合です。rledBatレシーバーは、LEDBAT輻輳制御アルゴリズム[RFC6817]またはLEDBAT ++輻輳制御アルゴリズム[LEDBAT ++]を使用する必要があります。rledbatは、他の場所で定義されている他のLBE輻輳制御アルゴリズムを使用する場合があります。渋滞制御アルゴリズムが受信機で実行されることに関係なく、送信者で実行された輻輳制御アルゴリズムによって常に境界があるため、rledBat接続は標準TCPよりも攻撃的ではありません。
rLEDBAT is essentially composed of three types of mechanisms, namely those that provide the means to measure the packet delay (either the RTT or the one-way delay, depending on the selected algorithm), mechanisms to detect packet loss, and the means to manipulate the receive window to control the sender's rate. The first two provide input to the LBE congestion control algorithm, while the third uses the congestion window computed by the LBE congestion control algorithm to manipulate the receive window, as depicted in Figure 1.
rledbatは、本質的に3種類のメカニズム、すなわちパケット遅延（選択したアルゴリズムに応じてRTTまたは一方向遅延のいずれか）を測定する手段を提供するメカニズム、パケット損失を検出するメカニズム、および受信ウィンドウを操作して送信者のレートを制御する手段で構成されています。最初の2つは、LBE輻輳制御アルゴリズムへの入力を提供し、3番目は図1に示すように、LBE輻輳制御アルゴリズムによって計算された渋滞ウィンドウを使用して受信ウィンドウを操作します。
+------------------------------------------+
| TCP Receiver |
| +-----------------+ |
| | +------------+ | |
| +---------------------| RTT | | |
| | | | Estimation | | |
| | | +------------+ | |
| | | | |
| | | +------------+ | |
| | +--------------| Loss, RTX | | |
| | | | | Detection | | |
| | | | +------------+ | |
| v v | | |
| +----------------+ | | |
| | LBE Congestion | | rLEDBAT | |
| | Control | | | |
| +----------------+ | | |
| | | +------------+ | |
| | | | RCV.WND | | |
| +---------------->| Control | | |
| | +------------+ | |
| +-----------------+ |
+------------------------------------------+
Figure 1: The rLEDBAT Architecture
図1：rledbatアーキテクチャ
We next describe each of the rLEDBAT components.
次に、各rledbatコンポーネントのそれぞれについて説明します。
rLEDBAT uses the TCP receive window (RCV.WND) to enable the receiver to control the sender's rate. [RFC9293] specifies that the RCV.WND is used to announce the available receive buffer to the sender for flow control purposes. In order to avoid confusion, we will call fcwnd the value that a standard-TCP receiver compliant with [RFC9293] calculates to set in the receive window for flow control purposes. We call RLWND the window value calculated by the rLEDBAT algorithm, and we call RCV.WND the value actually included in the Receive Window field of the TCP header. For a receiver compliant with [RFC9293], RCV.WND == fcwnd.
RLEDBATは、TCP受信ウィンドウ（RCV.WND）を使用して、受信者が送信者のレートを制御できるようにします。[RFC9293]は、RCV.WNDがフロー制御の目的で利用可能な受信バッファーを送信者に発表するために使用されることを指定します。混乱を避けるために、[RFC9293]に準拠した標準TCPレシーバーがフロー制御の目的で受信ウィンドウに設定する値をFCWNDに呼びます。rlwndをrledbatアルゴリズムによって計算されたウィンドウ値を呼び出し、rcv.wndを呼び出します。[rfc9293]に準拠した受信者の場合、rcv.wnd == fcwnd。
In the case of the rLEDBAT receiver, this receiver MUST NOT set the RCV.WND to a value larger than fcwnd and SHOULD set the RCV.WND to the minimum of RLWND and fcwnd, honoring both.
rledBatレシーバーの場合、この受信者はRCV.WNDをFCWNDよりも大きい値に設定してはならず、RCV.WNDをRLWNDとFCWNDの最小値に設定して、両方を尊重する必要があります。
When using rLEDBAT, two congestion controllers are in action in the flow of data from the sender to the receiver, namely the TCP congestion control algorithm on the sender side and the LBE congestion control algorithm executed in the receiver and conveyed to the sender through the RCV.WND. In the normal TCP operation, the sender uses the minimum of the cwnd and the RCV.WND to calculate the SND.WND. This is also true for rLEDBAT, as the sender is a regular TCP sender. This guarantees that the rLEDBAT flow will never transmit more aggressively than a standard-TCP flow, as the sender's congestion window limits the sending rate. Moreover, because an LBE congestion control algorithm such as LEDBAT/LEDBAT++ is designed to react earlier and more aggressively to congestion than regular TCP congestion control, the RLWND contained in the TCP RCV.WND field will generally be smaller than the congestion window calculated by the TCP sender, implying that the rLEDBAT congestion control algorithm will be effectively controlling the sender's window. One exception to this scenario is that at the beginning of the connection, when there is no information to set RLWND, RLWND is set to its maximum value, so that the sending rate of the sender is governed by the flow control algorithm of the receiver and the TCP slow start mechanism of the sender.
RLEDBATを使用すると、送信者から受信機へのデータの流れ、つまり送信者側のTCPうっ血コントロールアルゴリズムと、レシーバーで実行され、RCV.WNDを介して送信者に伝達されたLBEうっ血コントロールアルゴリズムの2つの輻輳コントローラーが動作しています。通常のTCP操作では、送信者はCWNDとRCV.WNDの最小値を使用してSND.WNDを計算します。送信者は通常のTCP送信者であるため、これはrledbatにも当てはまります。これにより、送信者の混雑ウィンドウが送信率を制限するため、rledbatフローが標準のTCPフローよりも積極的に送信されないことが保証されます。さらに、LEDBAT/LEDBAT ++などのLBE鬱血制御制御アルゴリズムは、通常のTCP輻輳制御よりも早期かつ積極的に輻輳に反応するように設計されているため、TCP RCV.WNDフィールドに含まれるRLWNDは、一般に、REGESTION CONTRUMTIN CONSMESTERが計算された混合物のコントロールで計算された混雑の窓よりも一般的に小さくなります。送信者のウィンドウ。このシナリオの1つの例外は、接続の開始時にRLWNDを設定する情報がない場合、RLWNDが最大値に設定されているため、送信者の送信率は受信機のフロー制御アルゴリズムと送信者のTCPスロースタートメカニズムによって支配されることです。
In summary, the sender's window is SND.WND = min(cwnd, RLWND, fcwnd)
要約すると、送信者のウィンドウはsnd.wnd = min（cwnd、rlwnd、fcwnd）です。
The LEDBAT/LEDBAT++ algorithm executed in a rLEDBAT receiver increases or decreases RLWND according to congestion signals (variations in the estimated queuing delay and packet loss). If RLWND is decreased and directly announced in RCV.WND, this could lead to an announced window that is smaller than what is currently in use. This so-called "shrinking the window" is discouraged as per [RFC9293], as it may cause unnecessary packet loss and performance penalties. To be consistent with [RFC9293], the rLEDBAT receiver SHOULD NOT shrink the receive window.
REDBATレシーバーで実行されたLEDBAT/LEDBAT ++アルゴリズムは、うっ血信号（推定されたキューイング遅延とパケット損失の変動）に従ってRLWNDを増加または減少させます。RLWNDが減少し、RCV.WNDで直接発表された場合、これは現在使用されているものよりも小さい発表されたウィンドウにつながる可能性があります。このいわゆる「窓の縮小」は、[RFC9293]に従って不必要なパケットの損失とパフォーマンスのペナルティを引き起こす可能性があるため、落胆しています。[rfc9293]と一致するために、rledbatレシーバーは受信ウィンドウを縮小してはなりません。
In order to avoid window shrinking, the receiver MUST only reduce RCV.WND by the number of bytes contained in a received data packet. This may fall short to honor the new calculated value of the RLWND immediately. However, the receiver SHOULD progressively reduce the advertised RCV.WND, always honoring that the reduction is less than or equal to the received bytes, until the target window determined by the rLEDBAT algorithm is reached. This implies that it may take up to one RTT for the rLEDBAT receiver to drain enough in-flight bytes to completely close its receive window without shrinking it. This is sufficient to honor the window output from the LEDBAT/LEDBAT++ algorithms, since they are only allowed to perform at most one multiplicative decrease per RTT.
ウィンドウの縮小を避けるために、受信者は受信したデータパケットに含まれるバイト数だけRCV.WNDを減らす必要があります。これは、すぐにRLWNDの新しい計算値を尊重するために不足する可能性があります。ただし、レシーバーは、rEDBATアルゴリズムによって決定されるターゲットウィンドウに到達するまで、削減が受信バイト以下であることを常に尊重し、常に宣伝されているrcv.wndを徐々に減らす必要があります。これは、REDBATレシーバーが縮小せずに受信ウィンドウを完全に閉じるのに十分な機内バイトを排出するのに最大1つのRTTが必要になる可能性があることを意味します。これは、RTTごとに最大1つの乗法減少のみを実行することが許可されているため、LEDBAT/LEDBAT ++アルゴリズムからのウィンドウ出力を尊重するのに十分です。
The Window Scale (WS) option [RFC7323] is a means to increase the maximum window size permitted by the receive window. The WS option defines a scale factor that restricts the granularity of the receive window that can be announced. This means that the rLEDBAT client will have to accumulate the increases resulting from multiple received packets and only convey a change in the window when the accumulated sum of increases is equal to or higher than one increase step as imposed by the scaling factor according to the WS option in place for the TCP connection.
ウィンドウスケール（WS）オプション[RFC7323]は、受信ウィンドウで許可される最大ウィンドウサイズを増やす手段です。WSオプションは、発表できる受信ウィンドウの粒度を制限するスケールファクターを定義します。これは、rledBatクライアントが、複数の受信パケットから生じる増加を蓄積する必要があり、累積された増加の合計が、TCP接続のWSオプションに従ってスケーリング係数によって課されるように1つ以上の増加ステップが等しい場合のみ、ウィンドウの変更を伝える必要があることを意味します。
Changes in the receive window that are smaller than 1 MSS (Maximum Segment Size) are unlikely to have any immediate impact on the sender's rate. As usual, TCP's segmentation practice results in sending full segments (i.e., segments of size equal to the MSS). [RFC7323], which defines the WS option, specifies that allowed values for the WS option are between 0 and 14. Assuming an MSS of around 1500 bytes, WS option values between 0 and 11 result in the receive window being expressed in units that are about 1 MSS or smaller. So, WS option values between 0 and 11 have no impact in rLEDBAT (unless packets smaller than the MSS are being exchanged).
1ミリ秒未満の受信ウィンドウ（最大セグメントサイズ）の変更は、送信者のレートにすぐに影響を与える可能性は低いです。いつものように、TCPのセグメンテーションの練習により、完全なセグメント（つまり、MSSに等しいサイズのセグメント）が送信されます。WSオプションを定義する[RFC7323]は、WSオプションの値を許可する値が0〜14であることを指定します。約1500バイトのMSSを想定して、WSオプション値は0〜11の間で、1ミリ秒以下のユニットで受信ウィンドウが表現されます。したがって、0〜11の間のWSオプション値は、rledBatに影響を与えません（MSSが交換されているよりもパケットが小さい場合を除く）。
WS option values higher than 11 can affect the dynamics of rLEDBAT, since control may become too coarse (e.g., with a WS option value of 14, a change in one unit of the receive window implies a change of 10 MSS in the effective window).
コントロールが粗すぎる可能性があるため、11を超えるWSオプション値はrledBatのダイナミクスに影響を与える可能性があります（たとえば、WSオプション値が14の場合、受信ウィンドウの1単位の変更は、有効ウィンドウの10ミリ秒の変更を意味します）。
For the above reasons, the rLEDBAT client SHOULD set WS option values lower than 12. Additional experimentation is required to explore the impact of larger WS values on rLEDBAT dynamics.
上記の理由により、RLEDBATクライアントはWSオプション値を12未満に設定する必要があります。RLEDBATダイナミクスに対するより大きなWS値の影響を調査するには、追加の実験が必要です。
Note that the recommendation for rLEDBAT to set the WS option values to lower values does not preclude communication with servers that set the WS option values to larger values, since WS option values are set independently for each direction of the TCP connection.
WSオプション値がTCP接続の各方向に個別に設定されるため、WSオプション値を低い値にWSオプション値をより低い値に設定するように推奨することは、WSオプション値をより大きな値に設定するサーバーとの通信を排除しないことに注意してください。
Both LEDBAT and LEDBAT++ measure base and current delays to estimate the queuing delay. LEDBAT uses the one-way delay, while LEDBAT++ uses the RTT. In the next sections, we describe how rLEDBAT mechanisms enable the receiver to measure the one-way delay or the RTT -- whichever is needed, depending on the congestion control algorithm used.
LEDBATとLEDBAT ++の両方がベースと電流の遅延を測定して、キューイングの遅延を推定します。LEDBATは一方向遅延を使用し、LEDBAT ++はRTTを使用します。次のセクションでは、rledBatメカニズムが、使用される輻輳制御アルゴリズムに応じて、必要な方向のどちらかを受信者がどのように測定できるかについて説明します。
LEDBAT++ uses the RTT to estimate the queuing delay. In order to estimate the queuing delay using RTT, the rLEDBAT receiver estimates the base RTT (i.e., the constant components of RTT) and also measures the current RTT. By subtracting these two values, we obtain the queuing delay to be used by the rLEDBAT controller.
LEDBAT ++は、RTTを使用してキューイング遅延を推定します。RTTを使用してキューイング遅延を推定するために、rledBatレシーバーはベースRTT（つまり、RTTの定数成分）を推定し、現在のRTTを測定します。これら2つの値を減算することにより、rledBatコントローラーが使用するキューイング遅延を取得します。
LEDBAT++ discovers the base RTT (RTTb) by taking the minimum value of the measured RTTs over a period of time. The current RTT (RTTc) is estimated using a number of recent samples and applying a filter, such as the minimum (or the mean) of the last k samples. Using RTT to estimate the queuing delay has a number of shortcomings and difficulties, as discussed below.
LEDBAT ++は、一定期間にわたって測定されたRTTの最小値を取得することにより、ベースRTT（RTTB）を発見します。現在のRTT（RTTC）は、最近の多くのサンプルを使用して推定され、最後のKサンプルの最小（または平均）などのフィルターを適用します。以下で説明するように、RTTを使用してキューイング遅延を推定するには、多くの欠点と困難があります。
The queuing delay measured using RTT also includes the queuing delay experienced by the return packets in the direction from the rLEDBAT receiver to the sender. This is a fundamental limitation of this approach. The impact of this limitation is that the rLEDBAT controller will also react to congestion in the reverse path direction, resulting in an even more conservative mechanism.
RTTを使用して測定されたキューイング遅延には、REDBATレシーバーから送信者への方向に戻るパケットが経験したキューイング遅延も含まれます。これは、このアプローチの基本的な制限です。この制限の影響は、rledbatコントローラーが逆経路方向の輻輳にも反応し、さらに保守的なメカニズムをもたらすことです。
In order to measure RTT, the rLEDBAT client MUST enable the TS option [RFC7323]. By matching the TSval carried in outgoing packets with the Timestamp Echo Reply (TSecr) value [RFC7323] observed in incoming packets, it is possible to measure RTT. This allows the rLEDBAT receiver to measure RTT even if it is acting as a pure receiver. In a pure receiver, there is no data flowing from the rLEDBAT receiver to the sender, making it impossible to match data packets with Acknowledgment packets to measure RTT, in contrast to what is usually done in TCP for other purposes.
RTTを測定するには、RLEDBATクライアントはTSオプション[RFC7323]を有効にする必要があります。発信パケットで運ばれるTSVALを、着信パケットで観察されるタイムスタンプエコー応答（TSECR）値[RFC7323]と一致させることにより、RTTを測定することができます。これにより、rledbatレシーバーが純粋なレシーバーとして機能している場合でも、RTTを測定できます。純粋なレシーバーでは、rledbatレシーバーから送信者に流れるデータはありません。他の目的でTCPで通常行われることとは対照的に、データパケットを確認パケットと承認パケットと測定することを不可能にします。
Depending on the frequency of the local clock used to generate the values included in the TS option, several packets may carry the same TSval. If that happens, the rLEDBAT receiver will be unable to match the different outgoing packets carrying the same TSval with the different incoming packets also carrying the same TSecr value. However, it is not necessary for rLEDBAT to use all packets to estimate RTT, and sampling a subset of in-flight packets per RTT is enough to properly assess the queuing delay. RTT MUST then be calculated as the time since the first packet with a given TSval was sent and the first packet that was received with the same value contained in the TSecr. Other packets with repeated TS values SHOULD NOT be used for RTT calculations.
TSオプションに含まれる値を生成するために使用されるローカルクロックの頻度に応じて、いくつかのパケットが同じTSVALを運ぶ場合があります。その場合、rledbatレシーバーは、同じTSValを運ぶ異なる発信パケットを、同じTSECR値を持つ異なる着信パケットと一致させることができません。ただし、RLEDBATがすべてのパケットを使用してRTTを推定する必要はありません。また、RTTごとに飛行中のパケットのサブセットをサンプリングするだけで、キューイングの遅延を適切に評価するのに十分です。その後、RTTは、特定のTSVALを含む最初のパケットが送信されてからの時間と、TSECRに含まれる同じ値で受信された最初のパケットを計算する必要があります。繰り返しTS値を持つ他のパケットは、RTT計算に使用しないでください。
Several issues must be addressed in order to avoid an artificial increase in the observed RTT. Different issues emerge, depending on whether the rLEDBAT-capable host is sending data packets or pure ACKs to measure RTT. We next consider these issues separately.
観測されたRTTの人為的な増加を避けるために、いくつかの問題に対処する必要があります。rledBat対応のホストがRTTを測定するためにデータパケットまたは純粋なACKを送信しているかどうかに応じて、さまざまな問題が現れます。次に、これらの問題を個別に検討します。
In this scenario, the rLEDBAT node (node A) sends a pure ACK to the other endpoint of the TCP connection (node B), including the TS option. Upon the reception of the TS option, host B will copy the value of the TSval into the TSecr field of the TS option and include that option in the next data packet towards host A. However, there are two reasons why B may not send a packet immediately back to A, artificially increasing the measured RTT. The first reason is when A has no data to send. The second is when A has no available window to put more packets in flight. We next describe how each of these cases is addressed.
このシナリオでは、rledBatノード（ノードA）は、TSオプションを含むTCP接続（ノードB）のもう一方のエンドポイントに純粋なACKを送信します。TSオプションを受信すると、ホストBはTSVALの値をTSオプションのTSECRフィールドにコピーし、ホストAに向けて次のデータパケットにそのオプションを含めます。ただし、BがすぐにAにパケットを送信しない理由が2つあり、測定されたRTTを人為的に増加させます。最初の理由は、Aが送信するデータがない場合です。2つ目は、Aが飛行中により多くのパケットを配置するための利用可能なウィンドウがない場合です。次に、これらの各ケースがどのように対処されているかを説明します。
The case where host B has no data to send when it receives the pure Acknowledgment is expected to be rare in the rLEDBAT use cases. rLEDBAT will be used mostly for background file transfers, so the expected common case is that the sender will have data to send throughout the lifetime of the communication. However, if, for example, the file is structured in blocks of data, it may be the case that the sender will seldom have to wait until the next block is available to proceed with the data transfer. To address this situation, the filter used by the congestion control algorithm executed in the receiver SHOULD discard outliers (e.g., a MIN filter [RFC6817] would achieve this) when measuring RTT using pure ACK packets.
ホストBには、純粋な認識を受け取ったときに送信するデータがない場合は、rledbatのユースケースではまれであると予想されます。rledbatは主に背景ファイルの転送に使用されるため、予想される一般的なケースは、送信者が通信の生涯を通じて送信するデータを持っていることです。ただし、たとえば、ファイルがデータブロックで構造化されている場合、次のブロックがデータ転送を進めるために使用可能になるまで、送信者がめったに待たなければならない場合があります。この状況に対処するために、受信機で実行された輻輳制御アルゴリズムで使用されるフィルターは、純粋なACKパケットを使用してRTTを測定する際に外れ値を破棄する必要があります（これを実現します）。
This limitation of the sender's window can come from either the TCP congestion window in host B or the announced receive window from rLEDBAT in host A. Normally, the receive window will be the one to limit the sender's transmission rate, since the LBE congestion control algorithm used by the rLEDBAT node is designed to be more restrictive on the sender's rate than standard-TCP. If the limiting factor is the congestion window in the sender, it is less relevant if rLEDBAT further reduces the receive window due to a bloated RTT measurement, since the rLEDBAT node is not actively controlling the sender's rate. Nevertheless, the proposed approach to discard larger samples would also address this issue.
送信者のウィンドウのこの制限は、ホストBのTCP混雑ウィンドウまたはホストAのRLEDBATからの発表された受信ウィンドウのいずれかから得られます。通常、受信ウィンドウは、rledBatノードが使用するLBEの輻輳制御アルゴリズムは、送信者のレートよりも標準TCPよりも制限されるように設計されているため、送信者の伝送レートを制限するものになります。制限係数が送信者の輻輳ウィンドウである場合、rledbatノードが送信者のレートを積極的に制御していないため、肥大化したRTT測定のためにrledBatが膨満したRTT測定のために受信ウィンドウをさらに減らすと、関連性が低くなります。それにもかかわらず、より大きなサンプルを破棄する提案されたアプローチもこの問題に対処します。
To address the case in which the limiting factor is the receive window announced by rLEDBAT, the congestion control algorithm at the receiver SHOULD discard RTT measurements during the window reduction phase that are triggered by pure ACK packets. The rLEDBAT receiver is aware of whether a given TSval was sent in a pure ACK packet where the window was reduced, and if so, it can discard the corresponding RTT measurement.
制限要因がrledBatによって発表された受信ウィンドウである場合に対処するために、受信機の輻輳制御アルゴリズムは、純粋なACKパケットによってトリガーされるウィンドウ削減フェーズ中にRTT測定を破棄する必要があります。rledBatレシーバーは、特定のTSVALがウィンドウが縮小された純粋なACKパケットで送信されたかどうかを認識しており、もしそうなら、対応するRTT測定を破棄できます。
In the case that the rLEDBAT node is sending data packets and matching them with pure ACKs to measure RTT, a factor that can artificially increase the RTT measured is the presence of delayed Acknowledgments. According to the TS option generation rules [RFC7323], the value included in the TSecr for a delayed ACK is the one in the TSval field of the earliest unacknowledged segment. This may artificially increase the measured RTT.
rledBatノードがデータパケットを送信し、それらを純粋なアックと一致させてRTTを測定している場合、測定されたRTTを人為的に増やすことができる要因は、遅延承認の存在です。TSオプション生成ルール[RFC7323]によると、遅延ACKのTSECRに含まれる値は、最も早い承認されていないセグメントのTSVALフィールドの値です。これにより、測定されたRTTが人為的に増加する可能性があります。
If both endpoints of the connection are sending data packets, Acknowledgments are piggybacked onto the data packets and they are not delayed. Delayed ACKs only increase RTT measurements in the case that the sender has no data to send. Since the expected use case for rLEDBAT is that the sender will be sending background traffic to the rLEDBAT receiver, the cases where delayed ACKs increase the measured RTT are expected to be rare.
接続の両方のエンドポイントがデータパケットを送信している場合、謝辞はデータパケットにピギーバックされ、それらは遅延しません。遅延ACKSは、送信者が送信するデータがない場合にのみRTT測定を増加させます。rledBatの予想されるユースケースは、送信者がRLEDBATレシーバーにバックグラウンドトラフィックを送信することであるため、ACKが遅れている場合、測定されたRTTがまれであると予想される場合。
Nevertheless, measurements based on data packets from the rLEDBAT node matching pure ACKs from the other end will result in an increased RTT sample. The additional increase in the measured RTT will be up to 500 ms. This is because delayed ACKs are generated every second data packet received and not delayed more than 500 ms according to [RFC9293]. The rLEDBAT receiver MAY discard RTT measurements done using data packets from the rLEDBAT receiver and matching pure ACKs, especially if it has recent measurements done using other packet combinations. Applying a filter (e.g., a MIN filter) that discards outliers would also address this issue.
それにもかかわらず、rledbatノードからのデータパケットに基づく測定は、反対側からの純粋なアックを一致させると、RTTサンプルが増加します。測定されたRTTの追加の増加は最大500ミリ秒になります。これは、[RFC9293]によると、遅延ACKが受信した2秒ごとのデータパケットが生成され、500ミリ秒以上遅れていないためです。rledbatレシーバーは、特に他のパケットの組み合わせを使用して最近行われた場合、rledbatレシーバーからのデータパケットを使用して行われたRTT測定を破棄する場合があります。外れ値を破棄するフィルター（例：最小フィルター）を適用すると、この問題にも対処します。
The LEDBAT algorithm uses the one-way delay of packets as input. A TCP receiver can measure the delay of incoming packets directly (as opposed to the sender-based LEDBAT, where the receiver measures the one-way delay and needs to convey it to the sender).
LEDBATアルゴリズムは、入力としてパケットの一方向遅延を使用します。TCPレシーバーは、受信パケットの遅延を直接測定できます（送信者ベースのLEDBATとは対照的に、レシーバーは一方向遅延を測定し、送信者に伝える必要があります）。
In the case of TCP, the receiver can use the TS option to measure the one-way delay by subtracting the timestamp contained in the incoming packet from the local time at which the packet has arrived. As noted in [RFC6817], the clock offset between the sender's clock and the receiver's clock does not affect the LEDBAT operation, since LEDBAT uses the difference between the base one-way delay and the current one-way delay to estimate the queuing delay, effectively "canceling out" the clock offset error in the queuing delay estimation. There are, however, two other issues that the rLEDBAT receiver needs to take into account in order to properly estimate the one-way delay, namely the units in which the received timestamps are expressed and the clock skew. These issues are addressed below.
TCPの場合、受信機はTSオプションを使用して、パケットが到着した現地時に入っているパケットに含まれるタイムスタンプを差し引くことにより、一方向遅延を測定できます。[RFC6817]で述べたように、LEDBATはベースの一方向遅延と現在の一方向遅延の違いを使用してキューイング遅延を推定するために、キューイングの推定におけるクロックのオフセットエラーを効果的に「キャンセル」するため、[RFC6817]に記載されているように、送信者のクロックとレシーバーの時計の間のクロックオフセットはLEDBAT操作に影響しません。ただし、一方向遅延を適切に推定するために、RELDBATレシーバーが考慮する必要がある他の2つの問題、つまり、受信したタイムスタンプが表現されているユニットとクロックがゆがんでいます。これらの問題については、以下に説明します。
In order to measure the one-way delay using TCP timestamps, the rLEDBAT receiver first needs to discover the units of values in the TS option and then needs to account for the skew between the two endpoint clocks. Note that a mismatch of 100 ppm (parts per million) in the estimation of the sender's clock rate accounts for 6 ms of variation per minute in the measured delay. This is just one order of magnitude below the target delay set by rLEDBAT (or potentially more if the target is set to lower values, which is possible). Typical skew for untrained clocks is reported to be around 100-200 ppm [RFC6817].
TCPタイムスタンプを使用して一元配置遅延を測定するために、rledBatレシーバーは最初にTSオプションで値の単位を発見し、次に2つのエンドポイントクロック間のスキューを説明する必要があります。送信者の時計レートの推定における100 ppm（100万分の1部）の不一致は、測定された遅延の1分あたり6ミリ秒の変動を考慮していることに注意してください。これは、rledbatによって設定されたターゲット遅延よりも1桁下になります（または、ターゲットが値が低くなるように設定されている場合、可能です）。訓練されていない時計の典型的なスキューは、約100〜200 ppmであると報告されています[RFC6817]。
In order to learn both the TS units and the clock skew, the rLEDBAT receiver measures how much local time has elapsed between two packets with different TS values issued by the sender. By comparing the local time difference and the TS value difference, the receiver can assess the TS units and relative clock skews. In order for this to be accurate, the packets carrying the different TS values should experience equal (or at least similar) delay when traveling from the sender to the receiver, as any difference in the experienced delays would introduce an error in the unit/skew estimation. One possible approach is to select packets that experienced minimal delay (i.e., queuing delay close to zero) to make the estimations.
TSユニットとクロックスキューの両方を学習するために、rledbatレシーバーは、送信者が発行した異なるTS値を持つ2つのパケット間でローカル時間がどれだけ経過したかを測定します。局所的な時間差とTS値の差を比較することにより、受信機はTSユニットと相対的なクロックスキューを評価できます。これを正確にするためには、異なるTS値を運ぶパケットは、経験豊富な遅延の違いがユニット/スキュー推定にエラーが導入されるため、送信者から受信機への移動時に等しい（または少なくとも類似の）遅延を経験するはずです。考えられるアプローチの1つは、最小限の遅延を経験したパケット（つまり、ゼロに近いキューイング）を選択して、推定を行うことです。
An additional difficulty regarding the estimation of the TS units and clock skew in the context of (r)LEDBAT is that the LEDBAT congestion controller actions directly affect the (queuing) delay experienced by packets. In particular, if there is an error in the estimation of the TS units/skew, the LEDBAT controller will attempt to compensate for it by reducing/increasing the load. The result is that the LEDBAT operation interferes with the TS units/clock skew measurements. Because of this, measurements are more accurate when there is no traffic in the connection (in addition to the packets used for the measurements). The problem is that the receiver is unaware of whether the sender is injecting traffic at any point in time; it is therefore unable to use these quiet intervals to perform measurements. The receiver can, however, force periodic slowdowns, reducing the announced receive window to a few packets and performing the measurements at that time.
（r）LEDBATのコンテキストでTSユニットとクロックスキューの推定に関する追加の困難は、LEDBAT輻輳コントローラーのアクションがパケットが経験した（キューイング）遅延に直接影響することです。特に、TSユニット/スキューの推定にエラーがある場合、LEDBATコントローラーは負荷を削減/増加させることでそれを補償しようとします。その結果、LEDBAT操作はTSユニット/クロックスキュー測定を妨害します。このため、接続にトラフィックがない場合（測定に使用されるパケットに加えて）、測定値がより正確です。問題は、受信者が送信者がいつでもトラフィックを注入しているかどうかを知らないことです。したがって、これらの静かな間隔を使用して測定を実行することはできません。ただし、受信者は定期的な減速を強制し、発表された受信ウィンドウを少数のパケットに減らし、その時点で測定を実行できます。
It is possible for the rLEDBAT receiver to perform multiple measurements to assess both the TS units and the relative clock skew during the lifetime of the connection, in order to obtain more accurate results. Clock skew measurements are more accurate if the time period used to discover the skew is larger, as the impact of the skew becomes more apparent. It is a reasonable approach for the rLEDBAT receiver to perform an early discovery of the TS units (and the clock skew) using the first few packets of the TCP connection and then improve the accuracy of the TS units/clock skew estimation using periodic measurements later in the lifetime of the connection.
より正確な結果を得るために、REDBATレシーバーが複数の測定を実行して、接続の寿命の間にTSユニットと相対的なクロックスキューの両方を評価することができます。スキューの影響がより明確になるにつれて、スキューを発見するために使用される期間が大きい場合、クロックスキュー測定はより正確です。RLEDBATレシーバーにとって、TCP接続の最初のいくつかのパケットを使用してTSユニット（およびクロックスキュー）の早期発見を実行し、接続の寿命の後半の定期的な測定を使用してTSユニット/クロックスキュー推定の精度を改善することは合理的なアプローチです。
The rLEDBAT receiver is capable of detecting retransmitted packets as follows. We call RCV.HGH the highest sequence number corresponding to a received byte of data (not assuming that all bytes with smaller sequence numbers have been received already, there may be holes), and we call TSV.HGH the TSval corresponding to the segment in which that byte was carried. SEG.SEQ stands for the sequence number of a newly received segment, and we call TSV.SEQ the TSval of the newly received segment.
rledbatレシーバーは、次のように再送信パケットを検出できます。RCV.hghを、受信したデータに対応する最高のシーケンス番号を呼び出します（シーケンス数が既に受信されているすべてのバイトが既に受信されていると仮定していない、穴がある可能性があります）。SEG.SEQは、新しく受信したセグメントのシーケンス番号を表し、TSV.Seqを新しく受信したセグメントのTSVALと呼びます。
If SEG.SEQ < RCV.HGH and TSV.SEQ > TSV.HGH, then the newly received segment is a retransmission. This is so because the newly received segment was generated later than another already-received segment that contained data with a larger sequence number. This means that this segment was lost and was retransmitted.
seg.seq <rcv.hghおよびtsv.seq> tsv.hghの場合、新しく受け取ったセグメントは再送信です。これは、新しく受信したセグメントが、より大きなシーケンス番号を持つデータを含む別の既に推奨されるセグメントよりも遅れて生成されたためです。これは、このセグメントが失われ、再送信されたことを意味します。
The proposed mechanism to detect retransmissions at the receiver fails when there are window tail drops. If all packets in the tail of the window are lost, the receiver will not be able to detect a mismatch between the sequence numbers of the packets and the order of the timestamps. In this case, rLEDBAT will not react to losses; however, the TCP congestion controller at the sender will, most likely reducing its window to 1 MSS and taking over the control of the sending rate until slow start ramps up and catches the current value of the rLEDBAT window.
ウィンドウテールドロップがある場合、レシーバーでの再送信を検出する提案されたメカニズムは失敗します。ウィンドウのテール内のすべてのパケットが失われた場合、受信機はパケットのシーケンス番号とタイムスタンプの順序との間の不一致を検出できません。この場合、rledbatは損失に反応しません。ただし、送信者のTCP輻輳コントローラーは、ウィンドウを1ミリ秒に減らし、スロースタートが上昇してrledbatウィンドウの現在の値をキャッチするまで送信率の制御を引き継ぐ可能性が高いでしょう。
The status of this document is Experimental. The general purpose of the proposed experiment is to gain more experience running rLEDBAT over different network paths to see if the proposed rLEDBAT parameters perform well in different situations. Specifically, we would like to learn about the following aspects of the rLEDBAT mechanism:
このドキュメントのステータスは実験的です。提案された実験の一般的な目的は、さまざまなネットワークパス上でrledBatを実行している経験を増やして、提案されたrledBatパラメーターがさまざまな状況でうまく機能するかどうかを確認することです。具体的には、rledbatメカニズムの次の側面について学びたいと思います。
* Interaction between the sender's and receiver's congestion control algorithms. rLEDBAT posits that because the rLEDBAT receiver is using a less-than-best-effort congestion control algorithm, the receiver's congestion control algorithm will expose a smaller congestion window (conveyed through the receive window) than the one resulting from the congestion control algorithm executed at the sender. One of the purposes of the experiment is to learn how these two algorithms interact and if the assumption that the receiver side is always controlling the sender's rate (and making rLEDBAT effective) holds. The experiment should include the different congestion control algorithms that are currently widely used in the Internet, including CUBIC, Bottleneck Bandwidth and Round-trip propagation time (BBR), and LEDBAT(++).
* 送信者と受信者の混雑制御アルゴリズムの間の相互作用。rledbatは、rledbatレシーバーがベストよりも低い輻輳制御アルゴリズムを使用しているため、受信者の輻輳制御アルゴリズムは、送信者で実行された輻輳制御アルゴリズムから生じるものよりも小さな輻輳ウィンドウ（受信ウィンドウを通過する）を公開すると仮定しています。実験の目的の1つは、これらの2つのアルゴリズムがどのように相互作用するか、および受信者側が常に送信者のレートを制御しているという仮定（およびrledbatを効果的にする）を保持するかどうかを学ぶことです。この実験には、現在インターネットで広く使用されているさまざまな混雑制御アルゴリズムを含める必要があります。
* Interaction between rLEDBAT and Active Queue Management techniques such as Controlled Delay (CoDel); Proportional Integral controller Enhanced (PIE); and Low Latency, Low Loss, and Scalable Throughput (L4S).
* rledbatと制御遅延（Codel）などのアクティブキュー管理技術との相互作用;比例積分コントローラー強化（PIE）;低レイテンシ、低損失、スケーラブルなスループット（L4S）。
* How rLEDBAT should resume after a period during which there was no incoming traffic and the information about the rLEDBAT state information is potentially dated.
* 入ってくるトラフィックがなかった期間後にrledbatがどのように再開されるか、およびrledbat状態情報に関する情報が潜在的に日付が付けられている可能性があります。
Currently, the following implementations of rLEDBAT can be used for experimentation:
現在、RLEDBATの次の実装は、実験に使用できます。
* Windows 11. rLEDBAT is available in Microsoft's Windows 11 22H2 since October 2023 [Windows11].
* Windows11。RLEDBATは、2023年10月からMicrosoftのWindows 11 22H2で利用できます[Windows11]。
* Windows Server 2022. rLEDBAT is available in Microsoft's Windows Server 2022 since September 2022 [WindowsServer].
* Windows Server2022。RledBatは、2022年9月[WindowsServer]以降、MicrosoftのWindows Server 2022で利用できます。
* Apple. rLEDBAT is available in macOS and iOS since 2021 [Apple].
* りんご。rledbatは、2021年以降、macosおよびiOSで利用できます[Apple]。
* Linux implementation, open source, available since 2022 [rledbat_module].
* Linux実装、オープンソース、2022年以降利用可能[rledbat_module]。
* ns3 implementation, open source, available since 2020 [rLEDBAT-in-ns-3].
* NS3実装、オープンソース、2020年以降利用可能[rledbat-in-ns-3]。
In addition, rLEDBAT has been deployed by Microsoft at wide scale in the following services:
さらに、RLEDBATは、次のサービスでMicrosoftによって広く展開されています。
* BITS (Background Intelligent Transfer Service)
* ビット（背景インテリジェント転送サービス）
* DO (Delivery Optimization) service
* DO（配信最適化）サービス
* Windows update: using DO
* Windowsの更新：DOを使用します
* Windows Store: using DO
* Windowsストア：DOを使用します
* OneDrive
* onedrive
* Windows Error Reporting: wermgr.exe; werfault.exe
* Windowsエラーレポート：Wermgr.exe;werfault.exe
* System Center Configuration Manager (SCCM)
* システムセンター構成マネージャー（SCCM）
* Windows Media Player
* Windowsメディアプレーヤー
* Microsoft Office
* Microsoft Office
* Xbox (download games): using DO
* Xbox（ゲームのダウンロード）：DOを使用します
Some initial experiments involving rLEDBAT have been reported in [COMNET3]. Experiments involving the interaction between LEDBAT++ and BBR are presented in [COMNET2]. An experimental evaluation of the LEDBAT++ algorithm is presented in [COMNET1]. As LEDBAT++ is one of the less-than-best-effort congestion control algorithms that rLEDBAT relies on, the results regarding how LEDBAT++ interacts with other congestion control algorithms are relevant for the understanding of rLEDBAT as well.
rledBatを含むいくつかの初期実験が[comnet3]で報告されています。LEDBAT ++とBBRの間の相互作用を含む実験は、[COMNET2]に示されています。LEDBAT ++アルゴリズムの実験的評価は、[COMNET1]に示されています。LEDBAT ++は、REDBATが依存しているベストよりも低い輻輳制御コントロールアルゴリズムの1つであるため、LEDBAT ++が他の輻輳制御アルゴリズムと相互作用する方法に関する結果は、rledbatの理解にも関連しています。
Overall, we believe that rLEDBAT does not introduce any new vulnerabilities to existing TCP endpoints, as it relies on existing TCP knobs, notably the receive window and timestamps.
全体として、rledbatは既存のTCPノブ、特に受信ウィンドウとタイムスタンプに依存しているため、既存のTCPエンドポイントに新しい脆弱性を導入しないと考えています。
Specifically, rLEDBAT uses RCV.WND to modulate the rate of the sender. An attacker wishing to starve a flow can simply reduce the RCV.WND, irrespective of whether rLEDBAT is being used or not.
具体的には、RLEDBATはRCV.WNDを使用して送信者のレートを変調します。rledbatが使用されているかどうかに関係なく、流れを飢えさせたい攻撃者は、単にRCV.WNDを減らすことができます。
We can further ask ourselves whether the attacker can use the rLEDBAT mechanisms in place to force the rLEDBAT receiver to reduce the RCV.WND. There are two ways an attacker can do this:
さらに、攻撃者がREDBATメカニズムを使用して、REDBATレシーバーにRCV.WNDを削減するように強制できるかどうかを自問することができます。攻撃者がこれを行う方法は2つあります。
* One would be to introduce an artificial delay to the packets by either actually delaying the packets or modifying the timestamps. This would cause the rLEDBAT receiver to believe that a queue is building up and reduce the RCV.WND. Note that to do so, an attacker must be on path, so if that is the case, it is probably more direct to simply reduce the RCV.WND.
* 1つは、実際にパケットを遅らせるか、タイムスタンプを変更することにより、パケットに人工的な遅延を導入することです。これにより、rledbatレシーバーは、キューが蓄積し、RCV.WNDを削減していると信じるようになります。そうするためには、攻撃者がパスにいる必要があるため、その場合、RCV.WNDを単純に減らす方がおそらくより直接的なものであることに注意してください。
* The other option would be for the attacker to make the rLEDBAT receiver believe that a loss has occurred. To do this, it basically needs to retransmit an old packet (to be precise, it needs to transmit a packet with the correct sequence number and the correct port and IP numbers). This means that the attacker can achieve a reduction of incoming traffic to the rLEDBAT receiver not only by modifying the RCV.WND field of the packets originated from the rLEDBAT host but also by injecting packets with the proper sequence number in the other direction. This may slightly expand the attack surface.
* もう1つのオプションは、攻撃者がrledbatレシーバーに損失が発生したと信じさせることです。これを行うには、基本的に古いパケットを再送信する必要があります（正確には、正しいシーケンス番号と正しいポートとIP番号でパケットを送信する必要があります）。これは、攻撃者が、REDBATホストから発信されたパケットのRCV.WNDフィールドを変更するだけでなく、適切なシーケンス番号を反対方向に注入することにより、RELDBATレシーバーへの着信トラフィックの削減を達成できることを意味します。これにより、攻撃面がわずかに拡張される場合があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[Apple] Cheshire, S. and V. Goel, "Reduce network delays for your
app", Apple Worldwide Developers Conference (WWDC2021),
Video, 2021,
<https://developer.apple.com/videos/play/wwdc2021/10239/>.
[COMNET1] Bagnulo, M. and A. García-Martínez, "An experimental
evaluation of LEDBAT++", Computer Networks, vol. 212,
DOI 10.1016/j.comnet.2022.109036, July 2022,
<https://doi.org/10.1016/j.comnet.2022.109036>.
[COMNET2] Bagnulo, M. and A. García-Martínez, "When less is more:
BBR versus LEDBAT++", Computer Networks, vol. 219,
DOI 10.1016/j.comnet.2022.109460, December 2022,
<https://doi.org/10.1016/j.comnet.2022.109460>.
[COMNET3] Bagnulo, M., García-Martínez, A., Mandalari, A.M.,
Balasubramanian, P., Havey, D., and G. Montenegro,
"Design, implementation and validation of a receiver-
driven less-than-best-effort transport", Computer
Networks, vol. 233, DOI 10.1016/j.comnet.2023.109841,
September 2023,
<https://doi.org/10.1016/j.comnet.2023.109841>.
[LEDBAT++] Balasubramanian, P., Ertugay, O., Havey, D., and M.
Bagnulo, "LEDBAT++: Congestion Control for Background
Traffic", Work in Progress, Internet-Draft, draft-irtf-
iccrg-ledbat-plus-plus-03, 9 September 2025,
<https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-
ledbat-plus-plus-03>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.
[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
NewReno Modification to TCP's Fast Recovery Algorithm",
RFC 6582, DOI 10.17487/RFC6582, April 2012,
<https://www.rfc-editor.org/info/rfc6582>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012,
<https://www.rfc-editor.org/info/rfc6817>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed.,
"CUBIC for Fast and Long-Distance Networks", RFC 9438,
DOI 10.17487/RFC9438, August 2023,
<https://www.rfc-editor.org/info/rfc9438>.
[rLEDBAT-in-ns-3]
"Implementation-of-rLEDBAT-in-ns-3", commit 2ab34ad, 24
June 2020, <https://github.com/manas11/implementation-of-
rLEDBAT-in-ns-3>.
[rledbat_module]
"rledbat_module", commit d82ff20, 9 September 2022,
<https://github.com/net-research/rledbat_module>.
[Windows11]
Microsoft, "What's new in Delivery Optimization",
Microsoft Windows Documentation, October 2024,
<https://learn.microsoft.com/en-us/windows/deployment/do/
whats-new-do>.
[WindowsServer]
Havey, D., "LEDBAT Background Data Transfer for Windows",
Microsoft Networking Blog, September 2022,
<https://techcommunity.microsoft.com/t5/networking-blog/
ledbat-background-data-transfer-for-windows/ba-p/3639278>.
In this section, we describe how to integrate the proposed rLEDBAT mechanisms and an LBE delay-based congestion control algorithm such as LEDBAT or LEDBAT++. We describe the integrated algorithm as two procedures: one that is executed when a packet is received by a rLEDBAT-enabled endpoint (Figure 2) and another that is executed when the rLEDBAT-enabled endpoint sends a packet (Figure 3). At the beginning, RLWND is set to its maximum value, so that the sending rate of the sender is governed by the flow control algorithm of the receiver and the TCP slow start mechanism of the sender, and the ackedBytes variable is set to 0.
このセクションでは、提案されているrledBatメカニズムと、LEDBATやLEDBAT ++などのLBE遅延ベースの輻輳制御アルゴリズムを統合する方法について説明します。統合されたアルゴリズムを2つの手順として説明します。1つは、パケットがrledbat対応エンドポイント（図2）によって受信されたときに実行されるものと、rledbat対応のエンドポイントがパケットを送信するときに実行されるもう1つは実行されます（図3）。最初はRLWNDが最大値に設定されているため、送信者の送信率はレシーバーのフロー制御アルゴリズムと送信者のTCPスロースタートメカニズムによって支配され、AckedBytes変数は0に設定されます。
We assume that the LBE congestion control algorithm defines a WindowIncrease() function and a WindowDecrease() function. For example, in the case of LEDBAT++, the WindowIncrease() function is an additive increase, while the WindowDecrease() function is a multiplicative decrease. In the case of the WindowIncrease() function, we assume that it takes as input the current window size and the number of bytes that were acknowledged since the last window update (ackedBytes) and returns as output the updated window size. In the case of the WindowDecrease() function, it takes as input the current window size and returns the updated window size.
LBE輻輳制御アルゴリズムは、WindowInCrease（）関数とWindowDecRease（）関数を定義すると想定しています。たとえば、LEDBAT ++の場合、WindowInCrease（）関数は追加の増加であり、WindowDecRease（）関数は乗法減少です。WindowInCrease（）関数の場合、現在のウィンドウサイズと、最後のウィンドウの更新（AckedBytes）以降に認められたバイト数を入力として取得し、更新されたウィンドウサイズを出力として返すと仮定します。WindowDecRease（）関数の場合、入力として現在のウィンドウサイズを取り、更新されたウィンドウサイズを返します。
The data structures used in the algorithms are as follows. The sendList is a list that contains the TSval and the local send time of each packet sent by the rLEDBAT-enabled endpoint. The TSecr field of the packets received by the rLEDBAT-enabled endpoint is matched with the sendList to compute the RTT.
アルゴリズムで使用されるデータ構造は次のとおりです。SendListは、rledBat対応のエンドポイントによって送信された各パケットのTSVALおよびローカル送信時間を含むリストです。RLEDBAT対応のエンドポイントによって受信されたパケットのTSECRフィールドは、RTTを計算するためにsendListと一致します。
The RTT values computed for each received packet are stored in the RTTlist, which also contains the received TSecr (to avoid using multiple packets with the same TSecr for RTT calculations, only the first packet received for a given TSecr is used to compute the RTT). It also contains the local time at which the packet was received, to allow selecting the RTTs measured in a given period (e.g., in the last 10 minutes). RTTlist is initialized with all its values to its maximum.
受信した各パケットに対して計算されたRTT値は、受信したTSECRも含まれているRTTLISTに保存されます（RTT計算に同じTSECRを使用して複数のパケットを使用しないように、特定のTSECRに対して受信した最初のパケットのみがRTTの計算に使用されます）。また、特定の期間に測定されたRTTを選択できるように、パケットを受信した現地時間も含まれています（たとえば、最後の10分間）。RTTLISTは、すべての値で最大値に初期化されます。
procedure receivePacket()
//Looks for first sent packet with same TSval as TSecr, and
//returns time difference
receivedRTT = computeRTT(sendList, receivedTSecr, receivedTime)
//Inserts minimum value for a given receivedTSecr
//Note that many received packets may contain same receivedTSecr
insertRTT (RTTlist, receivedRTT, receivedTSecr, receivedTime)
filteredRTT = minLastKMeasures(RTTlist, K=4)
baseRTT = minLastNSeconds(RTTlist, N=180)
qd = filteredRTT - baseRTT
//ackedBytes is the number of bytes that can be used to reduce
//the receive window - without shrinking it - if necessary
ackedBytes = ackedBytes + receiveBytes
if retransmittedPacketDetected then
RLWND = DecreaseWindow(RLWND) //Only once per RTT
end if
if qd < T then
RLWND = IncreaseWindow(RLWND, ackedBytes)
else
RLWND = DecreaseWindow(RLWND)
end if
end procedure
Figure 2: Procedure Executed When a Packet Is Received
図2：パケットが受信されたときに実行される手順
procedure SENDPACKET
if (RLWND > RLWNDPrevious) or (RLWND - RLWNDPrevious < ackedBytes)
then
RLWNDPrevious = RLWND
else
RLWNDPrevious = RLWND - ackedBytes
end if
ackedBytes = 0
RLWNDPrevious = RLWND
//Compute the RLWND to include in the packet
RLWND = min(RLWND, fcwnd)
end procedure
Figure 3: Procedure Executed When a Packet Is Sent
図3：パケットが送信されたときに実行される手順
This work was supported by the EU through the StandICT projects RXQ, CCI, and CEL6; the NGI Pointer RIM project; and the H2020 5G-RANGE project; and by the Spanish Ministry of Economy and Competitiveness through the 5G-City project (TEC2016-76795-C6-3-R).
この作業は、Standict Projects RXQ、CCI、およびCEL6を通じてEUによってサポートされていました。NGIポインターリムプロジェクト。H2020 5G-Rangeプロジェクト。5Gシティプロジェクト（TEC2016-76795-C6-3-R）を通じて、スペイン経済および競争力省によって。
We would like to thank ICCRG chairs Reese Enghardt and Vidhi Goel for their support on this work. We would also like to thank Daniel Havey for his help. We would like to thank Colin Perkins, Mirja Kühlewind, and Vidhi Goel for their reviews and comments on earlier draft versions of this document.
ICCRGの椅子Reese EnghardtとVidhi Goelに感謝します。また、ダニエル・ハーイの助けに感謝したいと思います。このドキュメントの以前のドラフトバージョンに関するレビューとコメントについて、Colin Perkins、MirjaKühlewind、およびVidhi Goelに感謝します。
Marcelo Bagnulo
Universidad Carlos III de Madrid
Email: marcelo@it.uc3m.es
Alberto García-Martínez
Universidad Carlos III de Madrid
Email: alberto@it.uc3m.es
Gabriel Montenegro
Email: g.e.montenegro@hotmail.com
Praveen Balasubramanian
Confluent
Email: pravb.ietf@gmail.com