Internet Engineering Task Force (IETF) M. Mathis
Request for Comments: 9937
Obsoletes: 6937 N. Cardwell
Category: Standards Track Y. Cheng
ISSN: 2070-1721 N. Dukkipati
Google, Inc.
December 2025
This document specifies a Standards Track version of the Proportional Rate Reduction (PRR) algorithm that obsoletes the Experimental version described in RFC 6937. PRR regulates the amount of data sent by TCP or other transport protocols during fast recovery. PRR accurately regulates the actual flight size through recovery such that at the end of recovery it will be as close as possible to the slow start threshold (ssthresh), as determined by the congestion control algorithm.
この文書は、RFC 6937 で説明されている実験版を廃止する比例速度削減 (PRR) アルゴリズムの標準トラック バージョンを指定します。PRR は、高速リカバリ中に TCP または他のトランスポート プロトコルによって送信されるデータの量を規制します。PRR は、回復を通じて実際のフライト サイズを正確に調整し、回復の終了時に輻輳制御アルゴリズムによって決定されるスロー スタートしきい値 (ssthresh) にできるだけ近づくようにします。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、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/rfc9937.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9937 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Conventions
3. Definitions
4. Changes Relative to RFC 6937
5. Relationships to Other Standards
6. Algorithm
6.1. Initialization Steps
6.2. Per-ACK Steps
6.3. Per-Transmit Steps
6.4. Completion Steps
7. Properties
8. Examples
9. Adapting PRR to Other Transport Protocols
10. Measurement Studies
11. Operational Considerations
11.1. Incremental Deployment
11.2. Fairness
11.3. Protecting the Network Against Excessive Queuing and
Packet Loss
12. IANA Considerations
13. Security Considerations
14. References
14.1. Normative References
14.2. Informative References
Appendix A. Strong Packet Conservation Bound
Acknowledgments
Authors' Addresses
Van Jacobson's packet conservation principle [Jacobson88] defines a self clock process wherein N data segments delivered to the receiver generate acknowledgments that the data sender uses as the clock to trigger sending another N data segments into the network.
Van Jacobson のパケット保存原理 [Jacobson88] は、受信者に配信された N データ セグメントが肯定応答を生成するセルフ クロック プロセスを定義しており、データ送信者はそれをクロックとして使用して、ネットワークへの別の N データ セグメントの送信をトリガーします。
Congestion control algorithms like Reno [RFC5681] and CUBIC [RFC9438] are built on the conceptual foundation of this self clock process. They control the sending process of a transport protocol connection by using a congestion window ("cwnd") to limit "inflight", the volume of data that a connection estimates is in flight in the network at a given time. Furthermore, these algorithms require that transport protocol connections reduce their cwnd in response to packet losses. Fast recovery (see [RFC5681] and [RFC6675]) is the algorithm for making this cwnd reduction using feedback from acknowledgments. Its stated goal is to maintain a sender's self clock by relying on returning ACKs during recovery to clock more data into the network. Without Proportional Rate Reduction (PRR), fast recovery typically adjusts the window by waiting for a large fraction of a round-trip time (RTT) (one half round-trip time of ACKs for Reno [RFC5681] or 30% of a round-trip time for CUBIC [RFC9438]) to pass before sending any data.
Reno [RFC5681] や CUBIC [RFC9438] のような輻輳制御アルゴリズムは、この自己クロック プロセスの概念基盤に基づいて構築されています。これらは、輻輳ウィンドウ (「cwnd」) を使用してトランスポート プロトコル接続の送信プロセスを制御し、「飛行中」(接続が特定の時間にネットワーク内で送信中であると推定されるデータの量) を制限します。さらに、これらのアルゴリズムでは、トランスポート プロトコル接続がパケット損失に応じて cwnd を削減する必要があります。高速リカバリ ([RFC5681] および [RFC6675] を参照) は、確認応答からのフィードバックを使用してこの cwnd 削減を行うためのアルゴリズムです。その目標は、回復中に返される ACK に依存して、より多くのデータをネットワークにクロックすることによって、送信者の自己クロックを維持することです。Proportional Rate Reduction (PRR) を使用しない場合、高速リカバリは通常、データを送信する前に往復時間 (RTT) の大部分 (Reno [RFC5681] の場合は ACK の往復時間の 2 分の 1、CUBIC [RFC9438] の場合は往復時間の 30%) が経過するのを待つことによってウィンドウを調整します。
[RFC6675] makes fast recovery with Selective Acknowledgment (SACK) [RFC2018] more accurate by computing "pipe", a sender-side estimate of the number of bytes still outstanding in the network. With [RFC6675], fast recovery is implemented by sending data as necessary on each ACK to allow pipe to rise to match ssthresh, the target window size for fast recovery, as determined by the congestion control algorithm. This protects fast recovery from timeouts in many cases where there are heavy losses. However, [RFC6675] has two significant drawbacks. First, because it makes a large multiplicative decrease in cwnd at the start of fast recovery, it can cause a timeout if the entire second half of the window of data or ACKs are lost. Second, a single ACK carrying a SACK option that implies a large quantity of missing data can cause a step discontinuity in the pipe estimator, which can cause Fast Retransmit to send a large burst of data.
[RFC6675] は、ネットワーク内でまだ未処理のバイト数の送信側推定値である「パイプ」を計算することにより、選択的確認応答 (SACK) [RFC2018] による高速リカバリをより正確にします。[RFC6675] では、各 ACK で必要に応じてデータを送信することによって高速リカバリが実装され、輻輳制御アルゴリズムによって決定される高速リカバリのターゲット ウィンドウ サイズである ssthresh に一致するようにパイプを上昇させることができます。これにより、大きな損失が発生する多くの場合、タイムアウトからの迅速な回復が保護されます。しかし、[RFC6675] には 2 つの重大な欠点があります。まず、高速リカバリの開始時に cwnd が大幅に乗算的に減少するため、データ ウィンドウの後半全体または ACK が失われるとタイムアウトが発生する可能性があります。第 2 に、大量の欠落データを意味する SACK オプションを含む 1 つの ACK により、パイプ推定器でステップの不連続が発生する可能性があり、高速再送信で大量のデータ バーストが送信される可能性があります。
PRR regulates the transmission process during fast recovery in a manner that avoids these excess window adjustments, such that transmissions progress smoothly, and at the end of recovery, the actual window size will be as close as possible to ssthresh.
PRR は、これらの過剰なウィンドウ調整を回避する方法で高速リカバリ中に送信プロセスを調整します。これにより、送信がスムーズに進行し、リカバリの終了時に実際のウィンドウ サイズが ssthresh にできるだけ近くなります。
PRR's approach is inspired by Van Jacobson's packet conservation principle. As much as possible, PRR relies on the self clock process and is only slightly affected by the accuracy of estimators, such as the estimate of the volume of in-flight data. This is what gives the algorithm its precision in the presence of events that cause uncertainty in other estimators.
PRR のアプローチは、Van Jacobson のパケット保存原則に触発されています。PRR はできる限りセルフ クロック プロセスに依存しており、飛行中のデータ量の推定などの推定精度の影響はほとんど受けません。これにより、他の推定量に不確実性を引き起こすイベントが存在する場合でも、アルゴリズムに精度が与えられます。
When inflight is above ssthresh, PRR reduces inflight smoothly toward ssthresh by clocking out transmissions at a rate that is in proportion to both the delivered data and ssthresh.
inflight が ssthresh を超える場合、PRR は、配信されたデータと ssthresh の両方に比例するレートで送信をクロックアウトすることにより、ssthresh に向かってスムーズに inflight を減らします。
When inflight is less than ssthresh, PRR adaptively chooses between one of two Reduction Bounds to limit the total window reduction due to all mechanisms, including transient application stalls and the losses themselves. As a baseline, to be cautious when there may be considerable congestion, PRR uses its Conservative Reduction Bound (CRB), which is strictly packet conserving. When recovery seems to be progressing well, PRR uses its Slow Start Reduction Bound (SSRB), which is more aggressive than PRR-CRB by at most one segment per ACK. PRR-CRB meets the Strong Packet Conservation Bound described in Appendix A; however, when used in real networks as the sole approach, it does not perform as well as the algorithm described in [RFC6675], which proves to be more aggressive in a significant number of cases. PRR-SSRB offers a compromise by allowing a connection to send one additional segment per ACK, relative to PRR-CRB, in some situations. Although PRR-SSRB is less aggressive than [RFC6675] (transmitting fewer segments or taking more time to transmit them), it outperforms due to the lower probability of additional losses during recovery.
inflight が ssthresh 未満の場合、PRR は 2 つの削減境界のいずれかを適応的に選択して、一時的なアプリケーションの停止や損失自体を含むすべてのメカニズムによるウィンドウの合計削減を制限します。ベースラインとして、かなりの輻輳が発生する可能性がある場合に注意するために、PRR は厳密にパケットを節約する Conservative Reduction Bound (CRB) を使用します。回復が順調に進んでいるように見える場合、PRR は Slow Start Reduction Bound (SSRB) を使用します。これは、ACK ごとに最大 1 セグメント分だけ PRR-CRB よりも積極的です。PRR-CRB は、付録 A に記載されている強力なパケット保存限界を満たしています。しかし、実際のネットワークで唯一のアプローチとして使用される場合、[RFC6675] で説明されているアルゴリズムほどパフォーマンスは良くなく、多くの場合、より攻撃的であることが判明しています。PRR-SSRB は、状況によっては、PRR-CRB と比較して、接続が ACK ごとに 1 つの追加セグメントを送信できるようにすることで妥協策を提供します。PRR-SSRB は [RFC6675] よりも積極的ではありませんが (送信するセグメントが少ない、または送信に時間がかかる)、回復中に追加の損失が発生する可能性が低いため、優れたパフォーマンスを発揮します。
The original definition of the packet conservation principle [Jacobson88] treated packets that are presumed to be lost (e.g., marked as candidates for retransmission) as having left the network. This idea is reflected in the inflight estimator used by PRR, but it is distinct from the Strong Packet Conservation Bound as described in Appendix A, which is defined solely on the basis of data arriving at the receiver.
パケット保存原則 [Jacobson88] の元の定義では、失われたと推定される (たとえば、再送信の候補としてマークされた) パケットをネットワークから出たものとして扱いました。この考え方は、PRR で使用されるインフライト推定量に反映されていますが、付録 A で説明されている、受信機に到着するデータのみに基づいて定義される強力なパケット保護境界とは異なります。
This document specifies several main changes from the earlier version of PRR in [RFC6937]. First, it introduces a new adaptive heuristic that replaces a manual configuration parameter that determined how conservative PRR was when inflight was less than ssthresh (whether to use PRR-CRB or PRR-SSRB). Second, the algorithm specifies behavior for non-SACK connections (connections that have not negotiated SACK [RFC2018] support via the "SACK-permitted" option). Third, the algorithm ensures a smooth sending process even when the sender has experienced high reordering and starts loss recovery after a large amount of sequence space has been SACKed. Finally, this document also includes additional discussion about the integration of PRR with congestion control and loss detection algorithms.
この文書では、[RFC6937] の以前のバージョンの PRR からのいくつかの主な変更点を指定します。まず、inflight が ssthresh 未満の場合 (PRR-CRB または PRR-SSRB を使用するかどうか) に PRR がどの程度保守的であるかを決定する手動構成パラメーターを置き換える新しい適応ヒューリスティックが導入されています。第 2 に、このアルゴリズムは、非 SACK 接続 (「SACK-permitted」オプションを介して SACK [RFC2018] サポートをネゴシエートしていない接続) の動作を指定します。第三に、このアルゴリズムは、送信者が大量の並べ替えを経験し、大量のシーケンス スペースが SACK された後に損失回復を開始する場合でも、スムーズな送信プロセスを保証します。最後に、このドキュメントには、PRR と輻輳制御および損失検出アルゴリズムの統合に関する追加の説明も含まれています。
PRR has extensive deployment experience in multiple TCP implementations since the first widely deployed TCP PRR implementation in 2011 [First_TCP_PRR].
PRR は、2011 年に最初に広く展開された TCP PRR 実装以来、複数の TCP 実装における広範な展開経験を持っています [First_TCP_PRR]。
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] で説明されているように解釈されます。
The following terms, parameters, and state variables are used as they are defined in earlier documents:
次の用語、パラメータ、および状態変数は、以前のドキュメントで定義されているとおりに使用されます。
SND.UNA:
SND.UNA:
The oldest unacknowledged sequence number. This is defined in Section 3.4 of [RFC9293].
確認されていない最も古いシーケンス番号。これは [RFC9293] のセクション 3.4 で定義されています。
SND.NXT:
SND.NXT:
The next sequence number to be sent. This is defined in Section 3.4 of [RFC9293].
次に送信されるシーケンス番号。これは [RFC9293] のセクション 3.4 で定義されています。
duplicate ACK:
重複したACK:
An acknowledgment is considered a "duplicate ACK" or "duplicate acknowledgment" when (a) the receiver of the ACK has outstanding data, (b) the incoming acknowledgment carries no data, (c) the SYN and FIN bits are both off, (d) the acknowledgment number is equal to SND.UNA, and (e) the advertised window in the incoming acknowledgment equals the advertised window in the last incoming acknowledgment. This is defined in Section 2 of [RFC5681].
確認応答は、(a) ACK の受信側に未処理のデータがあり、(b) 受信確認にデータが含まれていない、(c) SYN ビットと FIN ビットが両方ともオフ、(d) 確認応答番号が SND.UNA に等しい、および (e) 受信確認のアドバタイズされたウィンドウが SND.UNA に等しい場合に、「重複 ACK」または「重複確認応答」とみなされます。最後の受信確認でアドバタイズされたウィンドウ。これは[RFC5681]のセクション2で定義されています。
FlightSize:
フライトサイズ:
The amount of data that has been sent but not yet cumulatively acknowledged. This is defined in Section 2 of [RFC5681].
送信されたがまだ累積的に確認されていないデータの量。これは[RFC5681]のセクション2で定義されています。
Receiver Maximum Segment Size (RMSS):
受信機最大セグメント サイズ (RMSS):
The RMSS is the size of the largest segment the receiver is willing to accept. This is the value specified in the MSS option sent by the receiver during connection startup (see Section 3.7.1 of [RFC9293]). Or if the MSS option is not used, it is the default of 536 bytes for IPv4 or 1220 bytes for IPv6 (see Section 3.7.1 of [RFC9293]). The size does not include the TCP/IP headers and options. The RMSS is defined in Section 2 of [RFC5681] and Section 3.8.6.3 of [RFC9293].
RMSS は、受信側が受け入れ可能な最大セグメントのサイズです。これは、接続開始時に受信側によって送信される MSS オプションで指定された値です ([RFC9293] のセクション 3.7.1 を参照)。または、MSS オプションが使用されない場合、IPv4 の場合はデフォルトの 536 バイト、IPv6 の場合は 1220 バイトになります ([RFC9293] のセクション 3.7.1 を参照)。このサイズには、TCP/IP ヘッダーとオプションは含まれません。RMSS は [RFC5681] のセクション 2 および [RFC9293] のセクション 3.8.6.3 で定義されています。
Sender Maximum Segment Size (SMSS):
送信者の最大セグメント サイズ (SMSS):
The SMSS is the size of the largest segment that the sender can transmit. This value can be based on the Maximum Transmission Unit (MTU) of the network, the path MTU discovery [RFC1191] [RFC8201] [RFC4821] algorithm, RMSS, or other factors. The size does not include the TCP/IP headers and options. This is defined in Section 2 of [RFC5681].
SMSS は、送信者が送信できる最大セグメントのサイズです。この値は、ネットワークの最大伝送単位 (MTU)、パス MTU 検出 [RFC1191] [RFC8201] [RFC4821] アルゴリズム、RMSS、またはその他の要素に基づくことができます。このサイズには、TCP/IP ヘッダーとオプションは含まれません。これは[RFC5681]のセクション2で定義されています。
Receiver Window (rwnd):
受信ウィンドウ (rwnd):
The most recently received advertised receiver window, in bytes. At any given time, a connection MUST NOT send data with a sequence number higher than the sum of SND.UNA and rwnd. This is defined in Section 2 of [RFC5681].
最後に受信したアドバタイズされたレシーバー ウィンドウ (バイト単位)。いかなる場合でも、接続は SND.UNA と rwnd の合計より大きいシーケンス番号を持つデータを送信してはなりません。これは[RFC5681]のセクション2で定義されています。
Congestion Window (cwnd):
輻輳ウィンドウ (cwnd):
A state variable that limits the amount of data a connection can send. At any given time, a connection MUST NOT send data if inflight (see below) matches or exceeds cwnd. This is defined in Section 2 of [RFC5681].
接続が送信できるデータの量を制限する状態変数。inflight (以下を参照) が cwnd と一致するかそれを超える場合、接続は常にデータを送信してはなりません (MUST NOT)。これは[RFC5681]のセクション2で定義されています。
Slow Start Threshold (ssthresh):
スロースタートしきい値 (ssthresh):
The slow start threshold (ssthresh) state variable is used to determine whether the slow start or congestion avoidance algorithm is used to control data transmission. During fast recovery, ssthresh is the target window size for a fast recovery episode, as determined by the congestion control algorithm. This is defined in Section 3.1 of [RFC5681].
スロー スタートしきい値 (ssthresh) 状態変数は、データ送信の制御にスロー スタート アルゴリズムと輻輳回避アルゴリズムのどちらを使用するかを決定するために使用されます。高速リカバリ中、 ssthresh は、輻輳制御アルゴリズムによって決定される、高速リカバリ エピソードのターゲット ウィンドウ サイズです。これは [RFC5681] のセクション 3.1 で定義されています。
PRR defines additional variables and terms:
PRR は追加の変数と用語を定義します。
Delivered Data (DeliveredData):
配信データ (DeliveredData):
The data sender's best estimate of the total number of bytes that the current ACK indicates have been delivered to the receiver since the previously received ACK.
前回受信した ACK 以降に受信者に配信されたことを現在の ACK が示す総バイト数のデータ送信者の最良の推定値。
In-Flight Data (inflight):
機内データ (機内):
The data sender's best estimate of the number of unacknowledged bytes in flight in the network, i.e., bytes that were sent and neither lost nor received by the data receiver.
ネットワーク内で送信中の未確認のバイト数、つまり、送信されて損失もデータ受信者によっても受信されなかったバイト数についての、データ送信者の最良の推定値。
Recovery Flight Size (RecoverFS):
リカバリ フライト サイズ (RecoverFS):
The number of bytes the sender estimates might possibly be delivered over the course of the current PRR episode.
送信者が推定するバイト数は、現在の PRR エピソード中に配信される可能性があります。
SafeACK:
セーフACK:
A local boolean variable indicating that the current ACK indicates the recovery is making good progress and the sender can send more aggressively, increasing inflight, if appropriate.
現在の ACK が回復が順調に進んでいることを示しており、必要に応じて送信者がより積極的に送信してインフライトを増やすことができることを示すローカル ブール変数。
SndCnt:
SndCnt:
A local variable indicating exactly how many bytes should be sent in response to each ACK.
各 ACK に応答して送信するバイト数を正確に示すローカル変数。
Voluntary window reductions:
自主的な窓口縮小:
Choosing not to send data in response to some ACKs, for the purpose of reducing the sending window size and data rate.
送信ウィンドウ サイズとデータ レートを削減するために、一部の ACK に応答してデータを送信しないことを選択します。
The largest change since [RFC6937] is the introduction of a new heuristic that uses good recovery progress (for TCP, when the latest ACK advances SND.UNA and does not indicate that a prior fast retransmit has been lost) to select the Reduction Bound (PRR-CRB or PRR-SSRB). [RFC6937] left the choice of Reduction Bound to the discretion of the implementer but recommended to use PRR-SSRB by default. For all of the environments explored in earlier PRR research, the new heuristic is consistent with the old recommendation.
[RFC6937] 以降の最大の変更は、良好な回復の進行状況 (TCP の場合、最新の ACK が SND.UNA を進めており、以前の高速再送信が失われたことを示していない場合) を使用して削減限界 (PRR-CRB または PRR-SSRB) を選択する新しいヒューリスティックが導入されたことです。[RFC6937] では、Reduction Bound の選択は実装者の裁量に委ねられていますが、デフォルトで PRR-SSRB を使用することが推奨されています。以前の PRR 研究で調査されたすべての環境について、新しいヒューリスティックは古い推奨事項と一致しています。
The paper "An Internet-Wide Analysis of Traffic Policing" [Flach2016policing] uncovered a crucial situation not previously explored, where both Reduction Bounds perform very poorly but for different reasons. Under many configurations, token bucket traffic policers can suddenly start discarding a large fraction of the traffic when tokens are depleted, without any warning to the end systems. The transport congestion control has no opportunity to measure the token rate and sets ssthresh based on the previously observed path performance. This value for ssthresh may cause a data rate that is substantially larger than the token replenishment rate, causing high loss. Under these conditions, both Reduction Bounds perform very poorly. PRR-CRB is too timid, sometimes causing very long recovery times at smaller than necessary windows, and PRR-SSRB is too aggressive, often causing many retransmissions to be lost for multiple rounds. Both cases lead to prolonged recovery, decimating application latency and/or goodput.
論文「トラフィックポリシングのインターネット規模の分析」[Flach2016policing] では、両方の削減境界のパフォーマンスが非常に低いにもかかわらず、異なる理由で行われている、これまで調査されていなかった重大な状況が明らかになりました。多くの構成では、トークン バケット トラフィック ポリサーは、トークンが枯渇すると、エンド システムに何の警告もなく、突然トラフィックの大部分の破棄を開始する可能性があります。トランスポート輻輳制御にはトークン レートを測定する機会がなく、以前に観察されたパス パフォーマンスに基づいて ssthresh を設定します。ssthresh のこの値により、データ レートがトークン補充レートより大幅に大きくなり、大きな損失が発生する可能性があります。このような条件下では、両方の削減限界のパフォーマンスが非常に低くなります。PRR-CRB は弱気すぎるため、必要なウィンドウよりも小さいウィンドウで非常に長い回復時間が発生する場合があります。また、PRR-SSRB は積極的すぎるため、多くの場合、複数のラウンドで多くの再送信が失われます。どちらの場合も、回復に時間がかかり、アプリケーションの遅延やグッドプットが減少します。
Investigating these environments led to the development of a "SafeACK" heuristic to dynamically switch between Reduction Bounds: by default, conservatively use PRR-CRB and only switch to PRR-SSRB when ACKs indicate the recovery is making good progress (SND.UNA is advancing without detecting any new losses). The SafeACK heuristic was experimented with in Google's Content Delivery Network (CDN) [Flach2016policing] and implemented in Linux TCP since 2015.
これらの環境を調査した結果、削減境界を動的に切り替える「SafeACK」ヒューリスティックが開発されました。デフォルトでは、PRR-CRB を控えめに使用し、回復が順調に進んでいることを ACK が示した場合にのみ PRR-SSRB に切り替えます (SND.UNA が新たな損失を検出せずに進んでいる)。SafeACK ヒューリスティックは、Google のコンテンツ配信ネットワーク (CDN) [Flach2016policing] で実験され、2015 年から Linux TCP に実装されました。
This SafeACK heuristic is only invoked where losses, application-limited behavior, or other events cause the current estimate of in-flight data to fall below ssthresh. The high loss rates that make the heuristic essential are only common in the presence of heavy losses, such as traffic policers [Flach2016policing]. In these environments, the heuristic performs better than either bound by itself.
この SafeACK ヒューリスティックは、損失、アプリケーション限定の動作、またはその他のイベントにより、実行中のデータの現在の推定値が ssthresh を下回った場合にのみ呼び出されます。ヒューリスティックが不可欠となる高い損失率は、トラフィック ポリサー [Flach2016policing] などの重大な損失が存在する場合にのみ一般的です。このような環境では、ヒューリスティックは、単独でバインドされるよりも優れたパフォーマンスを発揮します。
Another PRR algorithm change improves the sending process when the sender enters recovery after a large portion of sequence space has been SACKed. This scenario could happen when the sender has previously detected reordering, for example, by using [RFC8985]. In the previous version of PRR, RecoverFS did not properly account for sequence ranges SACKed before entering fast recovery, which caused PRR to initially send too slowly. With the change, PRR properly accounts for sequence ranges SACKed before entering fast recovery.
PRR アルゴリズムのもう 1 つの変更により、シーケンス スペースの大部分が SACK された後に送信側が回復に入るときの送信プロセスが改善されました。このシナリオは、送信者が以前に、たとえば [RFC8985] を使用して並べ替えを検出した場合に発生する可能性があります。PRR の以前のバージョンでは、RecoverFS は高速リカバリに入る前に SACK されたシーケンス範囲を適切に考慮しなかったため、PRR の最初の送信が遅すぎました。この変更により、PRR は高速リカバリに入る前に SACK されたシーケンス範囲を適切に考慮します。
Yet another change is to force a fast retransmit upon the first ACK that triggers the recovery. Previously, PRR may not allow a fast retransmit (i.e., SndCnt is 0) on the first ACK in fast recovery, depending on the loss situation. Forcing a fast retransmit is important to maintain the ACK clock and avoid potential retransmission timeout (RTO) events. The forced fast retransmit only happens once during the entire recovery and still follows the packet conservation principles in PRR. This heuristic has been implemented since the first widely deployed TCP PRR implementation in 2011 [First_TCP_PRR].
さらに別の変更は、回復をトリガーする最初の ACK で高速再送信を強制することです。以前は、PRR は、損失状況に応じて、高速リカバリ時の最初の ACK での高速再送信 (つまり、SndCnt が 0) を許可しない場合がありました。高速再送信を強制することは、ACK クロックを維持し、潜在的な再送信タイムアウト (RTO) イベントを回避するために重要です。強制高速再送信はリカバリ全体で 1 回だけ発生し、PRR のパケット保存原則に従います。このヒューリスティックは、2011 年に初めて広く導入された TCP PRR 実装以来実装されてきました [First_TCP_PRR]。
In another change, upon exiting recovery, a data sender sets cwnd to ssthresh. This is important for robust performance. Without setting cwnd to ssthresh at the end of recovery and with application-limited sender behavior and some loss patterns, cwnd could end fast recovery well below ssthresh, leading to bad performance. The performance could, in some cases, be worse than [RFC6675] recovery, which simply sets cwnd to ssthresh at the start of recovery. This behavior of setting cwnd to ssthresh at the end of recovery has been implemented since the first widely deployed TCP PRR implementation in 2011 [First_TCP_PRR] and is similar to [RFC6675], which specifies setting cwnd to ssthresh at the start of recovery.
別の変更では、リカバリを終了すると、データ送信者は cwnd を ssthresh に設定します。これは堅牢なパフォーマンスにとって重要です。リカバリの終了時に cwnd を ssthresh に設定しないと、アプリケーションに制限された送信者の動作や一部の損失パターンがあると、cwnd が ssthresh を大幅に下回って高速リカバリを終了し、パフォーマンスの低下につながる可能性があります。場合によっては、リカバリの開始時に cwnd を ssthresh に設定するだけの [RFC6675] リカバリよりもパフォーマンスが悪化する可能性があります。リカバリの終了時に cwnd を ssthresh に設定するこの動作は、2011 年に初めて広く導入された TCP PRR 実装 [First_TCP_PRR] 以来実装されており、リカバリの開始時に cwnd を ssthresh に設定することを指定する [RFC6675] に似ています。
Since [RFC6937] was written, PRR has also been adapted to perform multiplicative window reduction for non-loss-based congestion control algorithms, such as for Explicit Congestion Notification (ECN) as specified in [RFC3168]. This can be done by using some parts of the loss recovery state machine (in particular, the RecoveryPoint from [RFC6675]) to invoke the PRR ACK processing for exactly one round trip worth of ACKs. However, there can be interactions between using PRR and approaches to Active Queue Management (AQM) and ECN; guidance on the development and assessment of congestion control mechanisms is provided in [RFC9743].
[RFC6937] が書かれて以来、PRR は、[RFC3168] で規定されている明示的輻輳通知 (ECN) などの非損失ベースの輻輳制御アルゴリズムに対して乗算ウィンドウ削減を実行するようにも適応されています。これは、損失回復ステート マシンの一部 (特に [RFC6675] の RecoveryPoint) を使用して、正確に 1 往復分の ACK に対して PRR ACK 処理を呼び出すことで実行できます。ただし、PRR の使用と、アクティブ キュー管理 (AQM) および ECN へのアプローチとの間に相互作用が発生する可能性があります。輻輳制御メカニズムの開発と評価に関するガイダンスは [RFC9743] で提供されています。
PRR MAY be used in conjunction with any congestion control algorithm that intends to make a multiplicative decrease in its sending rate over approximately the time scale of one round-trip time, as long as the current volume of in-flight data is limited by a congestion window (cwnd) and the target volume of in-flight data during that reduction is a fixed value given by ssthresh. In particular, PRR is applicable to both Reno [RFC5681] and CUBIC [RFC9438] congestion control. PRR is described as a modification to "A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP" [RFC6675]. It is most accurate with SACK [RFC2018] but does not require SACK.
PRR は、飛行中のデータの現在の量が輻輳ウィンドウ (cwnd) によって制限され、その削減中の飛行中のデータの目標量が ssthresh によって与えられる固定値である限り、ほぼ 1 往復時間の時間スケールにわたって送信レートを乗算的に減少させることを目的とした輻輳制御アルゴリズムと組み合わせて使用できます (MAY)。特に、PRR は Reno [RFC5681] と CUBIC [RFC9438] の両方の輻輳制御に適用できます。PRR は、「TCP の選択的確認応答 (SACK) に基づく保守的な損失回復アルゴリズム」[RFC6675] の修正として説明されています。SACK [RFC2018] を使用すると最も正確になりますが、SACK は必要ありません。
PRR can be used in conjunction with a wide array of loss detection algorithms. This is because PRR does not have any dependencies on the details of how a loss detection algorithm estimates which packets have been delivered and which packets have been lost. Upon the reception of each ACK, PRR simply needs the loss detection algorithm to communicate how many packets have been marked as lost and how many packets have been marked as delivered. Thus, PRR MAY be used in conjunction with the loss detection algorithms specified or described in the following documents: Reno [RFC5681], NewReno [RFC6582], SACK [RFC6675], Forward Acknowledgment (FACK) [FACK], and Recent Acknowledgment Tail Loss Probe (RACK-TLP) [RFC8985]. Because of the performance properties of RACK-TLP, including resilience to tail loss, reordering, and lost retransmissions, it is RECOMMENDED that PRR is implemented together with RACK-TLP loss recovery [RFC8985].
PRR は、さまざまな損失検出アルゴリズムと組み合わせて使用できます。これは、PRR が、損失検出アルゴリズムがどのパケットが配信され、どのパケットが失われたかを推定する方法の詳細に依存していないためです。PRR は、各 ACK を受信すると、損失検出アルゴリズムを使用して、損失としてマークされたパケットの数と配信済みとしてマークされたパケットの数を通信するだけで済みます。したがって、PRR は、Reno [RFC5681]、NewReno [RFC6582]、SACK [RFC6675]、Forward Acknowledgment (FACK) [FACK]、および Recent Acknowledgment Tail Loss Probe (RACK-TLP) [RFC8985] の文書で指定または説明されている損失検出アルゴリズムと組み合わせて使用してもよい[MAY]。テールロス、並べ替え、再送損失に対する回復力を含む RACK-TLP のパフォーマンス特性のため、PRR を RACK-TLP 損失回復 [RFC8985] と一緒に実装することが推奨されます。
The SafeACK heuristic came about as a result of robust Lost Retransmission Detection under development in an early precursor to [RFC8985]. Without Lost Retransmission Detection, policers that cause very high loss rates are at very high risk of causing retransmission timeouts because Reno [RFC5681], CUBIC [RFC9438], and [RFC6675] can send retransmissions significantly above the policed rate.
SafeACK ヒューリスティックは、[RFC8985] の初期段階で開発中の堅牢な再送損失検出の結果として生まれました。再送損失検出がないと、Reno [RFC5681]、CUBIC [RFC9438]、および [RFC6675] はポリシングされたレートを大幅に上回る再送を送信する可能性があるため、非常に高い損失率を引き起こすポリサーは再送タイムアウトを引き起こすリスクが非常に高くなります。
At the beginning of a congestion control response episode initiated by the congestion control algorithm, a data sender using PRR MUST initialize the PRR state.
輻輳制御アルゴリズムによって開始される輻輳制御応答エピソードの開始時に、PRR を使用するデータ送信者は PRR 状態を初期化しなければなりません (MUST)。
The timing of the start of a congestion control response episode is entirely up to the congestion control algorithm, and (for example) could correspond to the start of a fast recovery episode, or a once-per-round-trip reduction when lost retransmits or lost original transmissions are detected after fast recovery is already in progress.
輻輳制御応答エピソードの開始のタイミングは完全に輻輳制御アルゴリズムに依存し、(たとえば) 高速回復エピソードの開始、または高速回復がすでに進行中の後に失われた再送信または失われた元の送信が検出された場合の往復に 1 回の削減に対応する可能性があります。
The PRR initialization allows a congestion control algorithm, CongCtrlAlg(), that might set ssthresh to something other than FlightSize/2 (including, e.g., CUBIC [RFC9438]).
PRR の初期化により、ssthresh を FlightSize/2 以外のもの (CUBIC [RFC9438] など) に設定する可能性がある輻輳制御アルゴリズム CongCtrlAlg() が可能になります。
A key step of PRR initialization is computing Recovery Flight Size (RecoverFS), the number of bytes the data sender estimates might possibly be delivered over the course of the PRR episode. This can be thought of as the sum of the following values at the start of the episode: inflight, the bytes cumulatively acknowledged in the ACK triggering recovery, the bytes SACKed in the ACK triggering recovery, and the bytes between SND.UNA and SND.NXT that have been marked lost. The RecoverFS includes losses because losses are marked using heuristics, so some packets previously marked as lost may ultimately be delivered (without being retransmitted) during recovery. PRR uses RecoverFS to compute a smooth sending rate. Upon entering fast recovery, PRR initializes RecoverFS, and RecoverFS remains constant during a given fast recovery episode.
PRR 初期化の重要なステップは、リカバリ フライト サイズ (RecoverFS) を計算することです。これは、データ送信者が PRR エピソード中に配信される可能性があると推定するバイト数です。これは、エピソードの開始時の次の値の合計と考えることができます: 飛行中、回復をトリガーする ACK で累積的に確認応答されたバイト、回復をトリガーする ACK で SACK されたバイト、および失われたとマークされた SND.UNA と SND.NXT の間のバイト。RecoverFS には損失が含まれます。損失はヒューリスティックを使用してマークされるため、以前に損失としてマークされた一部のパケットは、回復中に最終的に (再送信されずに) 配信される可能性があります。PRR は RecoverFS を使用してスムーズな送信速度を計算します。高速リカバリに入ると、PRR は RecoverFS を初期化し、特定の高速リカバリ エピソード中、RecoverFS は一定のままになります。
The full sequence of PRR algorithm initialization steps is as follows:
PRR アルゴリズムの初期化手順の完全なシーケンスは次のとおりです。
ssthresh = CongCtrlAlg() // Target flight size in recovery
prr_delivered = 0 // Total bytes delivered in recovery
prr_out = 0 // Total bytes sent in recovery
RecoverFS = SND.NXT - SND.UNA
// Bytes SACKed before entering recovery will not be
// marked as delivered during recovery:
RecoverFS -= (bytes SACKed in scoreboard)
// Include the (common) case of selectively ACKed bytes:
RecoverFS += (bytes newly SACKed)
// Include the (rare) case of cumulatively ACKed bytes:
RecoverFS += (bytes newly cumulatively acknowledged)
On every ACK starting or during fast recovery, excluding the ACK that concludes a PRR episode, PRR executes the following steps.
PRR エピソードを終了する ACK を除く、ACK の開始時または高速リカバリ中に、PRR は次の手順を実行します。
First, the sender computes DeliveredData, the data sender's best estimate of the total number of bytes that the current ACK indicates have been delivered to the receiver since the previously received ACK. With SACK, DeliveredData can be computed precisely as the change in SND.UNA, plus the signed change in quantity of data marked SACKed in the scoreboard. Thus, in the special case when there are no SACKed sequence ranges in the scoreboard before or after the ACK, DeliveredData is the change in SND.UNA. In recovery without SACK, DeliveredData is estimated to be 1 SMSS on each received duplicate ACK (i.e., SND.UNA did not change). When SND.UNA advances (i.e., a full or partial ACK), DeliveredData is the change in SND.UNA, minus 1 SMSS for each preceding duplicate ACK. Note that without SACK, a poorly behaved receiver that returns extraneous duplicate ACKs (as described in [Savage99]) could attempt to artificially inflate DeliveredData. As a mitigation, if not using SACK, then PRR disallows incrementing DeliveredData when the total bytes delivered in a PRR episode would exceed the estimated data outstanding upon entering recovery (RecoverFS).
まず、送信側は、前回受信した ACK 以降に受信側に配信されたことを現在の ACK が示す合計バイト数のデータ送信側の最良推定値である DeliveredData を計算します。SACK を使用すると、DeliveredData は、SND.UNA の変化と、スコアボードで SACK とマークされたデータ量の符号付き変化として正確に計算できます。したがって、ACK の前後に SACK されたシーケンス範囲がスコアボードに存在しない特殊なケースでは、DeliveredData は SND.UNA の変更になります。SACK なしのリカバリでは、DeliveredData は、受信した重複 ACK ごとに 1 SMSS であると推定されます (つまり、SND.UNA は変化しませんでした)。SND.UNA が進むと (つまり、完全または部分的な ACK)、DeliveredData は、SND.UNA の変更から、先行する重複 ACK ごとに 1 SMSS を引いたものになります。SACK がないと、([Savage99] で説明されているように) 無関係な重複 ACK を返す行儀の悪い受信者が、DeliveredData を人為的にインフレートしようとする可能性があることに注意してください。軽減策として、SACK を使用しない場合、PRR エピソードで配信される合計バイト数がリカバリ (RecoverFS) 開始時に未処理の推定データを超える場合、PRR は DeliveredData のインクリメントを禁止します。
Next, the sender computes inflight, the data sender's best estimate of the number of bytes that are in flight in the network. To calculate inflight, connections with SACK enabled and using [RFC6675] loss detection MAY use the "pipe" algorithm as specified in [RFC6675]. SACK-enabled connections using RACK-TLP loss detection [RFC8985] or other loss detection algorithms MUST calculate inflight by starting with SND.NXT - SND.UNA, subtracting out bytes SACKed in the scoreboard, subtracting out bytes marked lost in the scoreboard, and adding bytes in the scoreboard that have been retransmitted since they were last marked lost. For non-SACK-enabled connections, instead of subtracting out bytes SACKed in the SACK scoreboard, senders MUST subtract out: min(RecoverFS, 1 SMSS for each preceding duplicate ACK in the fast recovery episode); the min() with RecoverFS is to protect against misbehaving receivers [Savage99].
次に、送信者は、ネットワーク内で送信中のバイト数のデータ送信者の最良の推定値である inflight を計算します。Inflight を計算するために、SACK を有効にし、[RFC6675] 損失検出を使用する接続は、[RFC6675] で指定されている「パイプ」アルゴリズムを使用してもよい(MAY)。RACK-TLP 損失検出 [RFC8985] または他の損失検出アルゴリズムを使用する SACK 対応接続は、SND.NXT - SND.UNA で開始し、スコアボードで SACK されたバイトを減算し、スコアボードで損失とマークされたバイトを減算し、最後に損失とマークされてから再送信されたスコアボードのバイトを加算することによって、インフライトを計算しなければなりません (MUST)。SACK が有効になっていない接続の場合、送信者は、SACK スコアボードで SACK されたバイトを減算する代わりに、次の値を減算しなければなりません (MUST)。 min(RecoverFS, 高速リカバリ エピソードの先行重複 ACK ごとに 1 SMSS);RecoverFS の min() は、不正な動作をする受信者から保護するためのものです [Savage99]。
Next, the sender computes SafeACK, a local boolean variable indicating that the current ACK reported good progress. SafeACK is true only when the ACK has cumulatively acknowledged new data and the ACK does not indicate further losses. For example, an ACK triggering "rescue" retransmission (Section 4 of [RFC6675], NextSeg() condition 4) may indicate further losses. Both conditions indicate the recovery is making good progress and the sender can send more aggressively, increasing inflight, if appropriate.
次に、送信者は、現在の ACK が良好な進捗状況を報告したことを示すローカル ブール変数である SafeACK を計算します。SafeACK は、ACK が累積的に新しいデータを確認応答しており、ACK がさらなる損失を示していない場合にのみ true になります。たとえば、「レスキュー」再送信をトリガーする ACK ([RFC6675] のセクション 4、NextSeg() 条件 4) は、さらなる損失を示す可能性があります。どちらの条件も、回復が順調に進んでいることを示しており、必要に応じて、送信者はより積極的に送信して、インフライトを増やすことができます。
Finally, the sender uses DeliveredData, inflight, SafeACK, and other PRR state to compute SndCnt, a local variable indicating exactly how many bytes should be sent in response to each ACK, and then uses SndCnt to update cwnd.
最後に、送信側は、DeliveredData、inflight、SafeACK、およびその他の PRR 状態を使用して、各 ACK に応答して送信するバイト数を正確に示すローカル変数である SndCnt を計算し、SndCnt を使用して cwnd を更新します。
The full sequence of per-ACK PRR algorithm steps is as follows:
ACK ごとの PRR アルゴリズム ステップの完全なシーケンスは次のとおりです。
if (DeliveredData is 0)
Return
prr_delivered += DeliveredData
inflight = (estimated volume of in-flight data)
SafeACK = (SND.UNA advances and no further loss indicated)
if (inflight > ssthresh) {
// Proportional Rate Reduction
// This uses integer division, rounding up:
#define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
out = DIV_ROUND_UP(prr_delivered * ssthresh, RecoverFS)
SndCnt = out - prr_out
} else {
// PRR-CRB by default
SndCnt = MAX(prr_delivered - prr_out, DeliveredData)
if (SafeACK) {
// PRR-SSRB when recovery is making good progress
SndCnt += SMSS
}
// Attempt to catch up, as permitted
SndCnt = MIN(ssthresh - inflight, SndCnt)
}
if (prr_out is 0 AND SndCnt is 0) {
// Force a fast retransmit upon entering recovery
SndCnt = SMSS
}
cwnd = inflight + SndCnt
After the sender computes SndCnt and uses it to update cwnd, the sender transmits more data. Note that the decision of which data to send (e.g., retransmit missing data or send more new data) is out of scope for this document.
送信者は SndCnt を計算し、それを使用して cwnd を更新した後、さらにデータを送信します。どのデータを送信するかの決定 (欠落したデータを再送信するか、さらに新しいデータを送信するなど) は、このドキュメントの範囲外であることに注意してください。
On any data transmission or retransmission, PRR executes the following:
データ送信または再送信時に、PRR は次の処理を実行します。
prr_out += (data sent)
A PRR episode ends upon either completing fast recovery or before initiating a new PRR episode due to a new congestion control response episode.
PRR エピソードは、高速回復が完了すると終了するか、新しい輻輳制御応答エピソードにより新しい PRR エピソードが開始される前に終了します。
On the completion of a PRR episode, PRR executes the following:
PRR エピソードが完了すると、PRR は以下を実行します。
cwnd = ssthresh
Note that this step that sets cwnd to ssthresh can potentially, in some scenarios, allow a burst of back-to-back segments into the network.
cwnd を ssthresh に設定するこの手順により、シナリオによっては、ネットワークへの連続セグメントのバーストが可能になる可能性があることに注意してください。
It is RECOMMENDED that implementations use pacing to reduce the burstiness of data traffic. This recommendation is consistent with current practice to mitigate bursts (e.g., [PACING]), including pacing transmission bursts after restarting from idle.
実装ではペーシングを使用してデータ トラフィックのバースト性を軽減することが推奨されます。この推奨事項は、アイドル状態から再起動した後の送信バーストのペーシングを含む、バーストを軽減する現在の慣行 ([PACING] など) と一致しています。
The following properties are common to both PRR-CRB and PRR-SSRB, except as noted:
次のプロパティは、特に明記されている場合を除き、PRR-CRB と PRR-SSRB の両方に共通です。
PRR attempts to maintain the sender's ACK clocking across recovery events, including burst losses. By contrast, [RFC6675] can send large, unclocked bursts following burst losses.
PRR は、バースト損失を含む回復イベント全体にわたって送信者の ACK クロッキングを維持しようとします。対照的に、[RFC6675] は、バースト損失後に大規模な非クロックバーストを送信できます。
Normally, PRR will spread voluntary window reductions out evenly across a full RTT. This has the potential to generally reduce the burstiness of Internet traffic and could be considered to be a type of soft pacing. Hypothetically, any pacing increases the probability that different flows are interleaved, reducing the opportunity for ACK compression and other phenomena that increase traffic burstiness. However, these effects have not been quantified.
通常、PRR は自主的なウィンドウ削減を RTT 全体にわたって均等に分散します。これは一般的にインターネット トラフィックのバースト性を軽減する可能性があり、一種のソフト ペーシングと考えることができます。仮説上、ペーシングによって異なるフローがインターリーブされる可能性が高まり、ACK 圧縮やトラフィックのバースト性を高めるその他の現象の機会が減少します。ただし、これらの効果は定量化されていません。
If there are minimal losses, PRR will converge to exactly the target window chosen by the congestion control algorithm. Note that as the sender approaches the end of recovery, prr_delivered will approach RecoverFS and SndCnt will be computed such that prr_out approaches ssthresh.
損失が最小限であれば、PRR は輻輳制御アルゴリズムによって選択されたターゲット ウィンドウに正確に収束します。送信側がリカバリの終了に近づくと、prr_delivered は RecoverFS に近づき、SndCnt は prr_out が ssthresh に近づくように計算されることに注意してください。
Implicit window reductions, due to multiple isolated losses during recovery, cause later voluntary reductions to be skipped. For small numbers of losses, the window size ends at exactly the window chosen by the congestion control algorithm.
回復中に複数の個別の損失が発生するため、暗黙的なウィンドウの削減により、後の自発的な削減がスキップされます。損失の数が少ない場合、ウィンドウ サイズは、輻輳制御アルゴリズムによって選択されたウィンドウと正確に一致します。
For burst losses, earlier voluntary window reductions can be undone by sending extra segments in response to ACKs arriving later during recovery. Note that as long as some voluntary window reductions are not undone, and there is no application stall, the final value for inflight will be the same as ssthresh.
バースト損失の場合、回復中に後で到着する ACK に応答して追加のセグメントを送信することで、初期の自発的なウィンドウ縮小を元に戻すことができます。一部の自発的なウィンドウ削減が元に戻されず、アプリケーションの停止がない限り、inflight の最終値は ssthresh と同じになることに注意してください。
PRR using either Reduction Bound improves the situation when there are application stalls, e.g., when the sending application does not queue data for transmission quickly enough or the receiver stops advancing its receive window. When there is an application stall early during recovery, prr_out will fall behind the sum of transmissions allowed by SndCnt. The missed opportunities to send due to stalls are treated like banked voluntary window reductions; specifically, they cause prr_delivered - prr_out to be significantly positive. If the application catches up while the sender is still in recovery, the sender will send a partial window burst to grow inflight to catch up to exactly where it would have been had the application never stalled. Although such a burst could negatively impact the given flow or other sharing flows, this is exactly what happens every time there is a partial-RTT application stall while not in recovery. PRR makes partial-RTT stall behavior uniform in all states. Changing this behavior is out of scope for this document.
いずれかの Reduction Bound を使用する PRR は、アプリケーションの停止が発生したときの状況を改善します。たとえば、送信側アプリケーションが送信用のデータを十分な速さでキューに入れない場合や、受信側が受信ウィンドウの進行を停止した場合です。回復中の早い段階でアプリケーションの停止が発生すると、prr_out は SndCnt によって許可される送信の合計よりも遅れます。失速により送信できなかった機会は、バンクされた自発的なウィンドウ削減と同様に扱われます。具体的には、prr_delivered - prr_out が大幅にプラスになります。送信側がまだ回復中にアプリケーションが追いついた場合、送信側は部分的なウィンドウ バーストを送信して、アプリケーションが停止しなかった場合に正確に追いつくために、処理中に拡大します。このようなバーストは、特定のフローや他の共有フローに悪影響を与える可能性がありますが、回復中でないときに部分的な RTT アプリケーションが停止するたびに、これがまさに発生します。PRR により、部分的な RTT ストール動作がすべての状態で均一になります。この動作の変更は、このドキュメントの範囲外です。
PRR with Reduction Bound is less sensitive to errors in the inflight estimator. While in recovery, inflight is intrinsically an estimator, using incomplete information to estimate if un-SACKed segments are actually lost or merely out of order in the network. Under some conditions, inflight can have significant errors; for example, inflight is underestimated when a burst of reordered data is prematurely assumed to be lost and marked for retransmission. If the transmissions are regulated directly by inflight as they are with [RFC6675], a step discontinuity in the inflight estimator causes a burst of data, which cannot be retracted once the inflight estimator is corrected a few ACKs later. For PRR dynamics, inflight merely determines which algorithm, PRR or the Reduction Bound, is used to compute SndCnt from DeliveredData. While inflight is underestimated, the algorithms are different by at most 1 segment per ACK. Once inflight is updated, they converge to the same final window at the end of recovery.
Reduction Bound を使用した PRR は、インフライト推定器のエラーの影響を受けにくくなります。回復中、inflight は本質的に推定器であり、不完全な情報を使用して、SACK されていないセグメントが実際に失われたか、ネットワーク内で単に故障しているかどうかを推定します。状況によっては、飛行中に重大なエラーが発生する可能性があります。たとえば、並べ替えられたデータのバーストが時期尚早に失われたと想定され、再送信のマークが付けられた場合、インフライトは過小評価されます。[RFC6675] のように送信が機内によって直接規制されている場合、機内推定器のステップの不連続によりデータのバーストが発生し、機内推定器が数回の ACK で修正されると取り消すことができなくなります。PRR ダイナミクスの場合、inflight は、DeliveredData から SndCnt を計算するために PRR または Reduction Bound のどちらのアルゴリズムを使用するかを決定するだけです。インフライトは過小評価されていますが、アルゴリズムの違いは ACK あたり最大 1 セグメントです。インフライトが更新されると、リカバリの終了時に同じ最終ウィンドウに収束します。
Under all conditions and sequences of events during recovery, PRR-CRB strictly bounds the data transmitted to be equal to or less than the amount of data delivered to the receiver. This Strong Packet Conservation Bound is the most aggressive algorithm that does not lead to additional forced losses in some environments. It has the property that if there is a standing queue at a bottleneck with no cross traffic, the queue will maintain exactly constant length for the duration of the recovery, except for +1/-1 fluctuation due to differences in packet arrival and exit times. See Appendix A for a detailed discussion of this property.
リカバリ中のすべての条件および一連のイベントの下で、PRR-CRB は、送信されるデータが受信側に配信されるデータ量以下になるように厳密に制限します。この強力なパケット保存限界は、一部の環境で追加の強制損失を引き起こさない最も積極的なアルゴリズムです。これには、交差トラフィックのないボトルネックに待機キューがある場合、パケットの到着時間と終了時間の違いによる +1/-1 の変動を除いて、キューは回復期間中正確に一定の長さを維持するという特性があります。このプロパティの詳細については、付録 A を参照してください。
Although the Strong Packet Conservation Bound is very appealing for a number of reasons, earlier measurements (in Section 6 of [RFC6675]) demonstrate that it is less aggressive and does not perform as well as [RFC6675], which permits bursts of data when there are bursts of losses. PRR-SSRB is a compromise that permits a sender to send one extra segment per ACK as compared to the Packet Conserving Bound when the ACK indicates the recovery is in good progress without further losses. From the perspective of a strict Packet Conserving Bound, PRR-SSRB does indeed open the window during recovery; however, it is significantly less aggressive than [RFC6675] in the presence of burst losses.
強力なパケット保存限界は多くの理由から非常に魅力的ですが、初期の測定 ([RFC6675] のセクション 6) では、これが積極的ではなく、バースト損失が発生した場合にデータのバーストを許可する [RFC6675] ほどパフォーマンスが良くないことが実証されています。PRR-SSRB は、ACK がさらなる損失なく回復が順調に進行していることを示している場合に、パケット保存境界と比較して、送信者が ACK ごとに 1 つの余分なセグメントを送信できるようにする妥協策です。厳密なパケット保存限界の観点から見ると、PRR-SSRB は確かに回復中にウィンドウを開きます。ただし、バースト損失が存在する場合、[RFC6675] よりも攻撃性が大幅に低くなります。
This section illustrates the PRR and [RFC6675] algorithms by showing their different behaviors for two example scenarios: a connection experiencing either a single loss or a burst of 15 consecutive losses. All cases use bulk data transfers (no application pauses), Reno congestion control [RFC5681], and cwnd = FlightSize = inflight = 20 segments, so ssthresh will be set to 10 at the beginning of recovery. The scenarios use standard Fast Retransmit [RFC5681] and Limited Transmit [RFC3042], so the sender will send two new segments followed by one retransmit in response to the first three duplicate ACKs following the losses.
このセクションでは、PRR および [RFC6675] アルゴリズムを 2 つのシナリオ例 (単一の損失または 15 回連続の損失のバーストが発生した接続) での異なる動作を示して説明します。すべてのケースで、バルク データ転送 (アプリケーションの一時停止なし)、Reno 輻輳制御 [RFC5681]、および cwnd = FlightSize = inflight = 20 セグメントが使用されるため、リカバリの開始時に ssthresh は 10 に設定されます。このシナリオでは標準の高速再送信 [RFC5681] と制限付き送信 [RFC3042] を使用するため、送信者は 2 つの新しいセグメントを送信し、その後、損失後の最初の 3 つの重複 ACK に応答して 1 回の再送信を行います。
Each of the diagrams below shows the per ACK response to the first round trip for the two recovery algorithms when the zeroth segment is lost. The top line ("ack#") indicates the transmitted segment number triggering the ACKs, with an X for the lost segment. The "cwnd" and "inflight" lines indicate the values of cwnd and inflight, respectively, for these algorithms after processing each returning ACK but before further (re)transmission. The "sent" line indicates how much "N"ew or "R"etransmitted data would be sent. Note that the algorithms for deciding which data to send are out of scope of this document.
以下の各図は、0 番目のセグメントが失われた場合の 2 つの回復アルゴリズムの最初の往復に対する ACK ごとの応答を示しています。一番上の行 (「ack#」) は、ACK をトリガーする送信されたセグメント番号を示し、失われたセグメントを表す X が付いています。「cwnd」行と「inflight」行は、返される ACK をそれぞれ処理した後、さらに (再) 送信する前の、これらのアルゴリズムの cwnd と inflight の値をそれぞれ示します。「送信済み」行は、「新しい」または「再」送信されたデータの量を示します。どのデータを送信するかを決定するアルゴリズムは、このドキュメントの範囲外であることに注意してください。
RFC 6675
a X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
c 20 20 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
i 19 19 18 18 17 16 15 14 13 12 11 10 9 9 9 9 9 9 9 9 9 9
s N N R N N N N N N N N N N
PRR
a X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
c 20 20 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10 10
i 19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10 9 9
s N N R N N N N N N N N N N
a: ack#; c: cwnd; i: inflight; s: sent
Figure 1
In this first example, ACK#1 through ACK#19 contain SACKs for the original flight of data, ACK#20 and ACK#21 carry SACKs for the limited transmits triggered by the first and second SACKed segments, and ACK#22 carries the full cumulative ACK covering all data up through the limited transmits. ACK#22 completes the fast recovery episode and thus completes the PRR episode.
この最初の例では、ACK#1 ～ ACK#19 には元のデータ フライトに対する SACK が含まれ、ACK#20 と ACK#21 には最初と 2 番目の SACK セグメントによってトリガーされた制限された送信に対する SACK が含まれ、ACK#22 には制限された送信までのすべてのデータをカバーする完全な累積 ACK が含まれます。ACK#22 は高速回復エピソードを完了し、したがって PRR エピソードを完了します。
Note that both algorithms send the same total amount of data, and both algorithms complete the fast recovery episode with a cwnd matching the ssthresh of 20. [RFC6675] experiences a "half window of silence" while PRR spreads the voluntary window reduction across an entire RTT.
どちらのアルゴリズムも同じ総データ量を送信し、両方のアルゴリズムが 20 の ssthresh に一致する cwnd で高速リカバリ エピソードを完了することに注意してください。[RFC6675] では「半分の沈黙のウィンドウ」が発生しますが、PRR は自発的なウィンドウ削減を RTT 全体に広げます。
Next, consider an example scenario with the same initial conditions, except that the first 15 packets (0-14) are lost. During the remainder of the lossy round trip, only 5 ACKs are returned to the sender. The following examines each of these algorithms in succession.
次に、最初の 15 パケット (0 ～ 14) が失われることを除いて、同じ初期条件を持つシナリオ例を考えてみましょう。損失の多い往復の残りの期間中に、送信者に返される ACK は 5 つだけです。以下では、これらの各アルゴリズムを順番に調べます。
RFC 6675
a X X X X X X X X X X X X X X X 15 16 17 18 19
c 20 20 10 10 10
i 19 19 4 9 9
s N N 6R R R
PRR
a X X X X X X X X X X X X X X X 15 16 17 18 19
c 20 20 5 5 5
i 19 19 4 4 4
s N N R R R
a: ack#; c: cwnd; i: inflight; s: sent
Figure 2
In this specific situation, [RFC6675] is more aggressive because once Fast Retransmit is triggered (on the ACK for segment 17), the sender immediately retransmits sufficient data to bring inflight up to cwnd. Earlier measurements (in Section 6 of [RFC6675]) indicate that [RFC6675] significantly outperforms the [RFC6937] version of PRR using only PRR-CRB and some other similarly conservative algorithms that were tested, showing that it is significantly common for the actual losses to exceed the cwnd reduction determined by the congestion control algorithm.
この特定の状況では、[RFC6675] はより積極的です。これは、高速再送信が (セグメント 17 の ACK で) トリガーされると、送信者は送信中のデータを cwnd に到達させるのに十分なデータをすぐに再送信するためです。以前の測定 ([RFC6675] のセクション 6) は、[RFC6675] が、テストされた PRR-CRB およびその他の同様に保守的なアルゴリズムのみを使用した [RFC6937] バージョンの PRR よりも大幅に優れていることを示しており、実際の損失が輻輳制御アルゴリズムによって決定された cwnd 削減を超えることが非常に一般的であることを示しています。
Under such heavy losses, during the first round trip of fast recovery, PRR uses the PRR-CRB to follow the packet conservation principle. Since the total losses bring inflight below ssthresh, data is sent such that the total data transmitted, prr_out, follows the total data delivered to the receiver as reported by returning ACKs. Transmission is controlled by the sending limit, which is set to prr_delivered - prr_out.
このような重大な損失が発生した場合、高速リカバリの最初のラウンド トリップ中に、PRR は PRR-CRB を使用してパケット保存原則に従います。総損失は inflight を ssthresh 未満にするため、送信される総データ prr_out が、返される ACK によって報告される受信機に配信される総データに従うようにデータが送信されます。送信は、prr_delivered - prr_out に設定される送信制限によって制御されます。
While not shown in the figure above, once the fast retransmits sent starting at ACK#17 are delivered and elicit ACKs that increment the SND.UNA, PRR enters PRR-SSRB and increases the window by exactly 1 segment per ACK until inflight rises to ssthresh during recovery. On heavy losses when cwnd is large, PRR-SSRB recovers the losses exponentially faster than PRR-CRB. Although increasing the window during recovery seems to be ill advised, it is important to remember that this is actually less aggressive than permitted by [RFC6675], which sends the same quantity of additional data as a single burst in response to the ACK that triggered Fast Retransmit.
上の図には示されていませんが、ACK#17 から始まる高速再送信が配信され、SND.UNA をインクリメントする ACK を引き出すと、PRR は PRR-SSRB に入り、回復中にインフライトが ssthresh に上昇するまで、ACK ごとに 1 セグメントだけウィンドウを増やします。cwnd が大きい場合に大きな損失が発生した場合、PRR-SSRB は PRR-CRB よりも指数関数的に速く損失を回復します。回復中にウィンドウを拡大することはお勧めできないように思えますが、これは実際には、高速再送信をトリガーした ACK に対する応答として単一バーストとして同量の追加データを送信する [RFC6675] で許可されているほど積極的ではないことを覚えておくことが重要です。
For less severe loss events, where the total losses are smaller than the difference between FlightSize and ssthresh, PRR-CRB and PRR-SSRB are not invoked since PRR stays in the Proportional Rate Reduction mode.
損失の合計が FlightSize と ssthresh の差よりも小さい、それほど深刻ではない損失イベントの場合、PRR は比例レート削減モードのままであるため、PRR-CRB および PRR-SSRB は呼び出されません。
The main PRR algorithm and reductions bounds can be adapted to any transport that can support [RFC6675]. In one major implementation (Linux TCP), PRR has been the fast recovery algorithm for its default and supported congestion control modules since its introduction in 2011 [First_TCP_PRR].
主要な PRR アルゴリズムと削減限界は、[RFC6675] をサポートできるあらゆるトランスポートに適応できます。1 つの主要な実装 (Linux TCP) では、PRR は 2011 年の導入以来、デフォルトおよびサポートされている輻輳制御モジュールの高速回復アルゴリズムとなっています [First_TCP_PRR]。
The SafeACK heuristic can be generalized as any ACK of a retransmission that does not cause some other segment to be marked for retransmission.
SafeACK ヒューリスティックは、他のセグメントに再送信のマークを付けない再送信の ACK として一般化できます。
For [RFC6937], a companion paper [IMC11] evaluated [RFC3517] and various experimental PRR versions in a large-scale measurement study. At the time of publication, the legacy algorithms used in that study are no longer present in the code base used in that study, making such comparisons difficult without recreating historical algorithms. Readers interested in the measurement study should review Section 5 of [RFC6937] and the IMC paper [IMC11].
[RFC6937] については、関連論文 [IMC11] が [RFC3517] と大規模な測定研究でさまざまな実験的な PRR バージョンを評価しました。出版時点では、その研究で使用されていたレガシー アルゴリズムはその研究で使用されたコード ベースには存在していないため、過去のアルゴリズムを再作成しない限り、そのような比較は困難です。測定研究に興味のある読者は、[RFC6937] のセクション 5 と IMC 論文 [IMC11] を参照してください。
PRR is incrementally deployable, because it utilizes only existing transport protocol mechanisms for data delivery acknowledgment and the detection of lost data. PRR only requires changes to the transport protocol implementation at the data sender; it does not require any changes at data receivers or in networks. This allows data senders using PRR to work correctly with any existing data receivers or networks. PRR does not require any changes to or assistance from routers, switches, or other devices in the network.
PRR は、データ配信の確認と失われたデータの検出に既存のトランスポート プロトコル メカニズムのみを利用するため、段階的に展開できます。PRR では、データ送信側のトランスポート プロトコル実装の変更のみが必要です。データ受信側やネットワーク側での変更は必要ありません。これにより、PRR を使用するデータ送信者は、既存のデータ受信者またはネットワークと正しく連携できます。PRR では、ネットワーク内のルーター、スイッチ、またはその他のデバイスに対する変更や支援は必要ありません。
PRR is designed to maintain the fairness properties of the congestion control algorithm with which it is deployed. PRR only operates during a congestion control response episode, such as fast recovery or when there is a step reduction in the cwnd from the TCP ECN reaction defined in [RFC3168], and only makes short-term, per-acknowledgment decisions to smoothly regulate the volume of in-flight data during an episode such that at the end of the episode it will be as close as possible to the slow start threshold (ssthresh), as determined by the congestion control algorithm. PRR does not modify the congestion control cwnd increase or decrease mechanisms outside of congestion control response episodes.
PRR は、導入された輻輳制御アルゴリズムの公平性特性を維持するように設計されています。PRR は、高速回復などの輻輳制御応答エピソード中にのみ動作するか、[RFC3168] で定義されている TCP ECN 反応からの cwnd の段階的減少がある場合にのみ動作し、エピソード中のインフライト データの量をスムーズに調整するために、短期間の確認応答ごとの決定のみを行い、エピソードの終了時に輻輳制御アルゴリズムによって決定されるスロー スタートしきい値 (ssthresh) にできるだけ近づくようにします。PRR は、輻輳制御応答エピソード以外の輻輳制御の増加または減少メカニズムを変更しません。
Over long time scales, PRR is designed to maintain the queuing and packet loss properties of the congestion control algorithm with which it is deployed. As noted above, PRR only operates during a congestion control response episode, such as fast recovery or response to ECN, and only makes short-term, per-acknowledgment decisions to smoothly regulate the volume of in-flight data during an episode such that at the end of the episode it will be as close as possible to the slow start threshold (ssthresh), as determined by the congestion control algorithm.
PRR は、長期間にわたって、展開される輻輳制御アルゴリズムのキューイングとパケット損失の特性を維持するように設計されています。上で述べたように、PRR は、高速回復や ECN への応答などの輻輳制御応答エピソード中にのみ動作し、エピソード中のインフライト データの量をスムーズに調整するために、エピソードの終了時に輻輳制御アルゴリズムによって決定されるスロー スタートしきい値 (ssthresh) にできるだけ近づくように、短期間の確認応答ごとの決定のみを行います。
Over short time scales, PRR is designed to cause lower packet loss rates than preceding approaches like [RFC6675]. At a high level, PRR is inspired by the packet conservation principle, and as much as possible, PRR relies on the self clock process. By contrast, with [RFC6675], a single ACK carrying a SACK option that implies a large quantity of missing data can cause a step discontinuity in the pipe estimator, which can cause Fast Retransmit to send a large burst of data that is much larger than the volume of delivered data. PRR avoids such bursts by basing transmission decisions on the volume of delivered data rather than the volume of lost data. Furthermore, as noted above, PRR-SSRB is less aggressive than [RFC6675] (transmitting fewer segments or taking more time to transmit them), and it outperforms due to the lower probability of additional losses during recovery.
PRR は、短期間のスケールで、[RFC6675] などの以前のアプローチよりも低いパケット損失率を引き起こすように設計されています。大まかに言えば、PRR はパケット保存原理に基づいており、可能な限り自己クロック プロセスに依存しています。対照的に、[RFC6675] では、大量の欠落データを意味する SACK オプションを含む 1 つの ACK がパイプ推定器でステップの不連続を引き起こす可能性があり、これにより高速再送信が配信データの量よりはるかに大きい大量のデータ バーストを送信する可能性があります。PRR は、失われたデータの量ではなく、配信されたデータの量に基づいて送信を決定することで、このようなバーストを回避します。さらに、上で述べたように、PRR-SSRB は [RFC6675] よりも攻撃的ではなく (送信するセグメントが少ないか、送信に時間がかかる)、回復中に追加の損失が発生する可能性が低いため、優れたパフォーマンスを発揮します。
This document has no IANA actions.
この文書には IANA のアクションはありません。
PRR does not change the risk profile for transport protocols.
PRR は、トランスポート プロトコルのリスク プロファイルを変更しません。
Implementers that change PRR from counting bytes to segments have to be cautious about the effects of ACK splitting attacks [Savage99], where the receiver acknowledges partial segments for the purpose of confusing the sender's congestion accounting.
PRR をバイト数カウントからセグメントに変更する実装者は、ACK 分割攻撃 [Savage99] の影響に注意する必要があります。ACK 分割攻撃では、送信側の輻輳アカウンティングを混乱させる目的で、受信側が部分セグメントを確認応答します。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>.
[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>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[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>.
[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M.,
and Y. Nishida, "A Conservative Loss Recovery Algorithm
Based on Selective Acknowledgment (SACK) for TCP",
RFC 6675, DOI 10.17487/RFC6675, August 2012,
<https://www.rfc-editor.org/info/rfc6675>.
[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>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC8985] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The
RACK-TLP Loss Detection Algorithm for TCP", RFC 8985,
DOI 10.17487/RFC8985, February 2021,
<https://www.rfc-editor.org/info/rfc8985>.
[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>.
[FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgment:
Refining TCP Congestion Control", SIGCOMM '96: Conference
Proceedings on Applications, Technologies, Architectures,
and Protocols for Computer Communications, pp. 281-291,
DOI 10.1145/248156.248181, August 1996,
<https://dl.acm.org/doi/10.1145/248156.248181>.
[First_TCP_PRR]
"Proportional Rate Reduction for TCP.", commit
a262f0cdf1f2916ea918dc329492abb5323d9a6c, August 2011,
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
linux.git/
commit/?id=a262f0cdf1f2916ea918dc329492abb5323d9a6c>.
[Flach2016policing]
Flach, T., Papageorge, P., Terzis, A., Pedrosa, L., Cheng,
Y., Karim, T., Katz-Bassett, E., and R. Govindan, "An
Internet-Wide Analysis of Traffic Policing", SIGCOMM '16:
Proceedings of the 2016 ACM SIGCOMM Conference, pp.
468-482, DOI 10.1145/2934872.2934873, August 2016,
<https://doi.org/10.1145/2934872.2934873>.
[Hoe96Startup]
Hoe, J., "Improving the Start-up Behavior of a Congestion
Control Scheme for TCP", SIGCOMM '96: Conference
Proceedings on Applications, Technologies, Architectures,
and Protocols for Computer Communications, pp. 270-280,
DOI 10.1145/248156.248180, August 1996,
<https://doi.org/10.1145/248156.248180>.
[IMC11] Dukkipati, N., Mathis, M., Cheng, Y., and M. Ghobadi,
"Proportional Rate Reduction for TCP", IMC '11:
Proceedings of the 2011 ACM SIGCOMM Conference on Internet
Measurement Conference, pp. 155-170,
DOI 10.1145/2068816.2068832, November 2011,
<https://doi.org/10.1145/2068816.2068832>.
[Jacobson88]
Jacobson, V., "Congestion Avoidance and Control",
Symposium proceedings on Communications architectures and
protocols (SIGCOMM '88), pp. 314-329,
DOI 10.1145/52325.52356, August 1988,
<https://doi.org/10.1145/52325.52356>.
[PACING] Welzl, M., Eddy, W., Goel, V., and M. Tüxen, "Pacing in
Transport Protocols", Work in Progress, Internet-Draft,
draft-welzl-iccrg-pacing-03, 7 July 2025,
<https://datatracker.ietf.org/doc/html/draft-welzl-iccrg-
pacing-03>.
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
TCP's Loss Recovery Using Limited Transmit", RFC 3042,
DOI 10.17487/RFC3042, January 2001,
<https://www.rfc-editor.org/info/rfc3042>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Conservative Selective Acknowledgment (SACK)-based Loss
Recovery Algorithm for TCP", RFC 3517,
DOI 10.17487/RFC3517, April 2003,
<https://www.rfc-editor.org/info/rfc3517>.
[RFC6937] Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional
Rate Reduction for TCP", RFC 6937, DOI 10.17487/RFC6937,
May 2013, <https://www.rfc-editor.org/info/rfc6937>.
[RFC9743] Duke, M., Ed. and G. Fairhurst, Ed., "Specifying New
Congestion Control Algorithms", BCP 133, RFC 9743,
DOI 10.17487/RFC9743, March 2025,
<https://www.rfc-editor.org/info/rfc9743>.
[Savage99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
"TCP Congestion Control with a Misbehaving Receiver", ACM
SIGCOMM Computer Communication Review, vol. 29, no. 5, pp.
71-78, DOI 10.1145/505696.505704, October 1999,
<https://doi.org/10.1145/505696.505704>.
[TCP-RH] Mathis, M., Mahdavi, J., and J. Semke, "The Rate-Halving
Algorithm for TCP Congestion Control", Work in Progress,
Internet-Draft, draft-mathis-tcp-ratehalving-00, 30 August
1999, <https://datatracker.ietf.org/doc/html/draft-mathis-
tcp-ratehalving-00>.
PRR-CRB is based on a conservative, philosophically pure, and aesthetically appealing Strong Packet Conservation Bound, described here. Although inspired by the packet conservation principle [Jacobson88], it differs in how it treats segments that are missing and presumed lost. Under all conditions and sequences of events during recovery, PRR-CRB strictly bounds the data transmitted to be equal to or less than the amount of data delivered to the receiver. Note that the effects of presumed losses are included in the inflight calculation but do not affect the outcome of PRR-CRB once inflight has fallen below ssthresh.
PRR-CRB は、ここで説明する保守的で、哲学的に純粋で、美的に魅力的な強いパケット保存限界に基づいています。パケット保存原則 [Jacobson88] からインスピレーションを受けていますが、欠落しているセグメントや失われたと推定されるセグメントの処理方法が異なります。リカバリ中のすべての条件および一連のイベントの下で、PRR-CRB は、送信されるデータが受信側に配信されるデータ量以下になるように厳密に制限します。推定損失の影響は飛行中の計算に含まれますが、飛行中の損失が ssthresh を下回った場合は PRR-CRB の結果に影響を与えないことに注意してください。
This Strong Packet Conservation Bound is the most aggressive algorithm that does not lead to additional forced losses in some environments. It has the property that if there is a standing queue at a bottleneck that is carrying no other traffic, the queue will maintain exactly constant length for the entire duration of the recovery, except for +1/-1 fluctuation due to differences in packet arrival and exit times. Any less aggressive algorithm will result in a declining queue at the bottleneck. Any more aggressive algorithm will result in an increasing queue or additional losses if it is a full drop tail queue.
この強力なパケット保存限界は、一部の環境で追加の強制損失を引き起こさない最も積極的なアルゴリズムです。これには、他のトラフィックを伝送しないボトルネックに待機キューがある場合、そのキューは、パケットの到着時間と終了時間の違いによる +1/-1 の変動を除いて、回復期間全体にわたって正確に一定の長さを維持するという特性があります。あまり積極的でないアルゴリズムでは、ボトルネックでのキューが減少します。これ以上積極的なアルゴリズムを使用すると、キューが増加するか、完全なドロップ テール キューの場合は追加の損失が発生します。
This property is demonstrated with a thought experiment:
この性質は思考実験で実証されます。
Imagine a network path that has insignificant delays in both directions, except for the processing time and queue at a single bottleneck in the forward path. In particular, when a packet is "served" at the head of the bottleneck queue, the following events happen in much less than one bottleneck packet time: the packet arrives at the receiver; the receiver sends an ACK that arrives at the sender; the sender processes the ACK and sends some data; the data is queued at the bottleneck.
順方向パスの 1 つのボトルネックにおける処理時間とキューを除いて、両方向でわずかな遅延があるネットワーク パスを想像してください。特に、パケットがボトルネック キューの先頭で「処理」されると、ボトルネック パケット時間よりもはるかに短い時間で次のイベントが発生します。パケットは受信者に到着します。受信者は ACK を送信し、それが送信者に到着します。送信者は ACK を処理し、データを送信します。データはボトルネックでキューに入れられます。
If SndCnt is set to DeliveredData and nothing else is inhibiting sending data, then clearly the data arriving at the bottleneck queue will exactly replace the data that was served at the head of the queue, so the queue will have a constant length. If the queue is drop tail and full, then the queue will stay exactly full. Losses or reordering on the ACK path only cause wider fluctuations in the queue size but do not raise its peak size, independent of whether the data is in order or out of order (including loss recovery from an earlier RTT). Any more aggressive algorithm that sends additional data will overflow the drop tail queue and cause loss. Any less aggressive algorithm will under-fill the queue. Therefore, setting SndCnt to DeliveredData is the most aggressive algorithm that does not cause forced losses in this simple network. Relaxing the assumptions (e.g., making delays more authentic and adding more flows, delayed ACKs, etc.) is likely to increase the fine-grained fluctuations in queue size but does not change its basic behavior.
SndCnt が DeliveredData に設定されており、他にデータの送信を妨げるものがない場合、ボトルネック キューに到着するデータはキューの先頭で提供されたデータを正確に置き換えることになるため、キューの長さは一定になります。キューがドロップテールでいっぱいの場合、キューは完全にいっぱいのままになります。ACK パスでの損失または順序変更は、データが正しいかどうかに関係なく (以前の RTT からの損失回復を含む)、キュー サイズの大きな変動を引き起こすだけで、ピーク サイズは増加しません。追加のデータを送信するより積極的なアルゴリズムは、ドロップ テール キューをオーバーフローさせ、損失を引き起こします。あまり積極的ではないアルゴリズムでは、キューが不足してしまいます。したがって、SndCnt を DeliveredData に設定することは、この単純なネットワークで強制的な損失を引き起こさない最も積極的なアルゴリズムです。仮定を緩和すると (たとえば、遅延をより本物にし、より多くのフローや遅延 ACK を追加するなど)、キュー サイズのきめ細かい変動が増加する可能性がありますが、基本的な動作は変わりません。
Note that the congestion control algorithm implements a broader notion of optimal that includes appropriately sharing the network. Typical congestion control algorithms are likely to reduce the data sent relative to the Packet Conserving Bound implemented by PRR, bringing TCP's actual window down to ssthresh.
輻輳制御アルゴリズムは、ネットワークの適切な共有を含む、より広範な最適概念を実装していることに注意してください。一般的な輻輳制御アルゴリズムは、PRR によって実装されるパケット保存境界に比べて送信されるデータを削減し、TCP の実際のウィンドウを ssthresh まで下げる可能性があります。
This document is based in part on previous work by Janey C. Hoe (see "Recovery from Multiple Packet Losses", Section 3.2 of [Hoe96Startup]), Matt Mathis, Jeff Semke, and Jamshid Mahdavi [TCP-RH] and influenced by several discussions with John Heffner.
この文書は、Janey C. Hoe ([Hoe96Startup] のセクション 3.2 の「Recovery from Multiple Packet Losses」を参照)、Matt Mathis、Jeff Semke、Jamshid Mahdavi [TCP-RH] による以前の著作に一部基づいており、John Heffner とのいくつかの議論の影響を受けています。
Monia Ghobadi and Sivasankar Radhakrishnan helped analyze the experiments. Ilpo Jarvinen reviewed the initial implementation. Mark Allman, Richard Scheffenegger, Markku Kojo, Mirja Kuehlewind, Gorry Fairhurst, Russ Housley, Paul Aitken, Daniele Ceccarelli, and Mohamed Boucadair improved the document through their insightful reviews and suggestions.
Monia Ghobadi と Sivasankar Radhakrishnan は実験の分析に協力しました。Ilpo Jarvinen は初期実装をレビューしました。Mark Allman 氏、Richard Scheffenegger 氏、Markku Kojo 氏、Mirja Kuehlewind 氏、Gorry Fairhurst 氏、Russ Housley 氏、Paul Aitken 氏、Daniele Ceccarelli 氏、Mohamed Boucadair 氏が洞察力に富んだレビューと提案を通じてこの文書を改良しました。
Matt Mathis
Email: matt.mathis@gmail.com
Neal Cardwell
Google, Inc.
Email: ncardwell@google.com
Yuchung Cheng
Google, Inc.
Email: ycheng@google.com
Nandita Dukkipati
Google, Inc.
Email: nanditad@google.com