[要約] RFC 9959は、過去の接続で観測された通信パス特性のパラメータを再利用し、新しい接続の初期輻輳制御（CC）を迅速かつ安全に立ち上げる「慎重な再開（Careful Resume）」方式を規定します。偵察、未検証、検証、安全な退避の4つのフェーズを通じて、他フローへの過度な輻輳リスクを抑えつつ高速な転送開始を実現します。
Internet Engineering Task Force (IETF) N. Kuhn
Request for Comments: 9959 Thales Alenia Space
Category: Standards Track E. Stephan
ISSN: 2070-1721 Orange
G. Fairhurst
R. Secchi
University of Aberdeen
C. Huitema
Private Octopus Inc.
May 2026
This document specifies a cautious method for Internet transports that enables fast startup of Congestion Control (CC) for a wide range of connections, known as "Careful Resume". It reuses a set of computed CC parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are saved, allowing them to be later used to modify the CC behaviour of a subsequent connection.
この文書では、「慎重な再開」として知られる、幅広い接続に対する輻輳制御 (CC) の高速起動を可能にする、インターネット トランスポートの慎重な方法を指定します。これは、トランスポート エンドポイントの同じペア間で以前に観察されたパス特性に基づいて計算された CC パラメータのセットを再利用します。これらのパラメータは保存されるため、後続の接続の CC 動作を変更するために使用できるようになります。
This document describes the assumptions and defines the requirements for how a sender utilises these parameters to provide opportunities for a connection to more rapidly get up to speed and utilise available capacity. It discusses how the use of this method impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate.
この文書では、接続がより迅速に速度を上げ、利用可能な容量を利用する機会を提供するために、送信者がこれらのパラメータをどのように利用するかに関する前提条件を説明し、要件を定義します。この方法の使用が共有ネットワークのボトルネックでの容量にどのような影響を与えるか、および新しいレートが不適切であることが示された後に必要な安全な対応について説明します。
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/rfc9959.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9959 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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
1.1. Use of Saved CC Parameters by a Sender
1.2. Receiver Preference
1.3. Transport Protocol Interaction
1.4. Examples of Scenarios of Interest
1.5. Design Principles
2. Language, Notation, and Terms
2.1. Requirements Language
2.2. The Remote Endpoint
2.3. Logging Support
2.4. Notation and Terms
3. The Phases of CC Using Careful Resume
3.1. Observing
3.2. Reconnaissance Phase
3.3. Unvalidated Phase
3.4. Validating Phase
3.5. Safe Retreat Phase
3.6. Detecting Persistent Congestion While Using Careful Resume
3.7. Returning to Use Normal CC
4. Implementation Notes and Guidelines
4.1. Observing the Path Capacity
4.2. Confirming the Path in the Reconnaissance Phase
4.2.1. Confirming the Path
4.3. Safety in the Unvalidated Phase
4.3.1. Lifetime of CC Parameters
4.3.2. Pacing in the Unvalidated Phase
4.3.3. Exit from the Unvalidated Phase Because of Variable
Network Conditions
4.4. The Validating Phase
4.5. Safety in the Safe Retreat Phase
4.6. Returning to Normal Congestion Control
4.7. Limitations from Transport Protocols
5. Operational Considerations
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Notes on the Careful Resume Phases
Appendix B. Examples of the Careful Resume Phases
B.1. Example with No Loss
B.2. Example with No Loss, Rate Limited
B.3. Example with Loss Detected in the Reconnaissance Phase
B.4. Example with Loss Detected in the Validating Phase
Appendix C. Implementation Notes for Using BBR
C.1. Sending Unvalidated Packets Using BBR
C.2. Validation for BBR
C.3. Safe Retreat for BBR
Acknowledgments
Authors' Addresses
All Internet transports are required to either use a Congestion Control (CC) algorithm or to constrain their rate of transmission [RFC2914] [RFC8085]. In 2010, a survey of alternative CC algorithms [RFC5783] noted that there are challenges when a CC algorithm operates across an Internet path with a high and/or varying Bandwidth-Delay Product (BDP). The specified method targets a solution for these challenges.
すべてのインターネットトランスポートは、輻輳制御 (CC) アルゴリズムを使用するか、送信速度を制限する必要があります [RFC2914] [RFC8085]。2010 年に、代替 CC アルゴリズムに関する調査 [RFC5783] では、高い帯域幅遅延積 (BDP) や変動する帯域幅遅延積 (BDP) を伴うインターネット パス上で CC アルゴリズムが動作する場合に課題があることが指摘されました。指定された方法は、これらの課題の解決策を対象としています。
A CC algorithm typically takes time to ramp up the sending rate. This is called the "Slow Start Phase" and is informally known as the time to "get up to speed". This defines a time during which a sender intentionally uses less capacity than might be available, with the intention to avoid or limit overshoot of the available capacity for the path. In the context of CC, a path is associated with the end-to-end communication between a pair of transport endpoints, each identified by a source IP address and a unicast or anycast destination IP address. (This document does not define support for broadcast or multicast destination addresses.) A path can also be associated with a specific Differentiated Services Code Point (DSCP). Below the transport layer, a specific path could be realised in various ways, but this is not normally evident to the transport endpoints. (When known, additional path information could potentially provide an explicit signal to the CC algorithm to allow it to detect a change in the path.)
CC アルゴリズムは通常、送信レートを上げるのに時間がかかります。これは「スロー スタート フェーズ」と呼ばれ、非公式には「スピードを上げる」時期として知られています。これは、パスの利用可能な容量のオーバーシュートを回避または制限することを目的として、送信者が利用可能な容量よりも意図的に少ない容量を使用する時間を定義します。CC のコンテキストでは、パスは、送信元 IP アドレスとユニキャストまたはエニーキャスト宛先 IP アドレスによってそれぞれ識別されるトランスポート エンドポイントのペア間のエンドツーエンド通信に関連付けられます。(この文書では、ブロードキャストまたはマルチキャスト宛先アドレスのサポートは定義されていません。) パスは、特定の DSCP (Differentiated Services Code Point) に関連付けることもできます。トランスポート層の下では、特定のパスはさまざまな方法で実現できますが、これは通常、トランスポート エンドポイントには明らかではありません。(追加のパス情報がわかっている場合、CC アルゴリズムに明示的な信号を提供して、パスの変更を検出できるようにする可能性があります。)
Any overshoot of the bottleneck rate can have a detrimental effect on other flows that share a common bottleneck. A sender can also use a method that observes the rate of acknowledged data to seek to avoid an overshoot of this bottleneck capacity (e.g., Hystart++ [RFC9406]).
ボトルネック レートのオーバーシュートは、共通のボトルネックを共有する他のフローに悪影響を与える可能性があります。送信者は、このボトルネック容量のオーバーシュートを回避するために、確認応答されたデータのレートを観察する方法を使用することもできます (例: Hystart++ [RFC9406])。
In the extreme case, an overshoot can result in persistent congestion with unwanted starvation of other flows that share a common capacity bottleneck (i.e., preventing other flows from successfully sharing the capacity at a common bottleneck [RFC2914]).
極端なケースでは、オーバーシュートにより、共通の容量ボトルネックを共有する他のフローの望ましくない枯渇による永続的な輻輳が発生する可能性があります (つまり、他のフローが共通のボトルネックで容量を正常に共有できなくなります [RFC2914])。
A separate instance of a CC algorithm typically executes over a transport path. This seeks to avoid an increase in the queuing (latency or jitter) and/or congestion packet loss for the flow. In the case of a multipath transport, there can be more than one path with a separate CC context for each path.
CC アルゴリズムの別のインスタンスは通常、トランスポート パス上で実行されます。これは、フローのキューイング (遅延またはジッター) や輻輳パケット損失の増加を回避することを目的としています。マルチパス トランスポートの場合、パスごとに個別の CC コンテキストを持つ複数のパスが存在する可能性があります。
This document specifies Careful Resume, a method that seeks to reduce the time to complete a transfer when the sending rate is limited by the congestion controller using the congestion window (CWND). Specifically, this is when a transfer seeks to send significantly more data than allowed by the initial congestion window (IW) and where the BDP of the path is also significantly more than the product of the IW and path Round Trip Time (RTT).
この文書は、輻輳ウィンドウ (CWND) を使用して輻輳コントローラによって送信レートが制限されている場合に、転送を完了するまでの時間を短縮する方法である Careful Resume を規定します。具体的には、これは、転送が初期輻輳ウィンドウ (IW) で許容されるよりも大幅に多くのデータを送信しようとする場合、およびパスの BDP も IW とパスの往復時間 (RTT) の積よりも大幅に大きい場合です。
Careful Resume introduces an alternative method to select initial CC parameters that seeks to more rapidly and safely grow the sending rate controlled by the CWND.
Careful Resume では、CWND によって制御される送信レートをより迅速かつ安全に増加させることを目的とした、初期 CC パラメータを選択するための代替方法が導入されています。
Careful Resume is based on temporal sharing (sometimes known as "caching") of a saved set of CC parameters that relate to previous observations of the same path. The parameters are saved and used to modify the CC behaviour of a subsequent connection between the same endpoints.
Careful Resume は、同じパスの以前の観察に関連する CC パラメータの保存されたセットの一時的な共有 (「キャッシュ」とも呼ばれる) に基づいています。パラメータは保存され、同じエンドポイント間の後続の接続の CC 動作を変更するために使用されます。
CC algorithms that are rate based can make similar adjustments to their target sending rate. When saving the observed capacity, some CC algorithms might save a different parameter that is equivalent to the saved_cwnd. For example, a rate-based CC algorithm such as Bottleneck Bandwidth and Round-trip propagation time (BBR) [BBR-CC] can retain the value of the bottleneck bandwidth required to reach the capacity available to the flow (e.g., BBR.max_bw).
レートベースの CC アルゴリズムは、ターゲット送信レートに対して同様の調整を行うことができます。監視された容量を保存するとき、一部の CC アルゴリズムは、saved_cwnd と同等の別のパラメータを保存する場合があります。たとえば、ボトルネック帯域幅および往復伝播時間 (BBR) [BBR-CC] などのレートベースの CC アルゴリズムは、フローで利用可能な容量 (例: BBR.max_bw) に達するために必要なボトルネック帯域幅の値を保持できます。
CC parameters are used by Careful Resume for three functions:
CC パラメータは、Careful Resume によって次の 3 つの機能に使用されます。
1. Information to confirm whether a saved path corresponds to the current path.
1. 保存したパスが現在のパスと一致するかどうかを確認するための情報。
2. Information about the utilised path capacity and observed RTT to set CC parameters for the current connection.
2. 現在の接続の CC パラメータを設定するために使用されるパス容量と観測された RTT に関する情報。
3. Information to check the CC parameters are not too old.
3. CCパラメータを確認するための情報はそれほど古いものではありません。
CC algorithms need to be cautious when using saved CC parameters on a new path (see [RFC9000] and [RFC9040]). Care is therefore needed to assure safe use and to be robust to changes in traffic patterns, network routing, and link/node conditions. There are cases where using the saved parameters of a previous connection is not appropriate (see Section 4).
CC アルゴリズムは、保存された CC パラメータを新しいパスで使用する場合には注意する必要があります ([RFC9000] および [RFC9040] を参照)。したがって、安全な使用を保証し、トラフィック パターン、ネットワーク ルーティング、およびリンク/ノードの状態の変化に対して堅牢であるように注意する必要があります。以前の接続の保存されたパラメータの使用が適切でない場合があります (セクション 4 を参照)。
Whilst the sender could take optimisation decisions without considering the receiver's preference, there are cases where a receiver could have information that is not available at the sender or might benefit from understanding that Careful Resume might be used. In these cases, a receiver could use a transport mechanism to explicitly ask to either enable or inhibit Careful Resume when an application initiates a new connection.
送信者は受信者の好みを考慮せずに最適化の決定を下すことができますが、受信者が送信者では利用できない情報を持っている可能性がある場合や、Careful Resume が使用される可能性があることを理解することで利益が得られる場合があります。このような場合、受信側はトランスポート メカニズムを使用して、アプリケーションが新しい接続を開始するときに慎重な再開を有効にするか禁止するかを明示的に要求できます。
Receivers might request the ability to inhibit the use of Careful Resume in some situations, for example:
受信者は、次のような場合に、慎重な再開の使用を禁止する機能を要求する場合があります。
1. when a receiver can predict the pattern of traffic (e.g., insight into the volume of data to be sent, the expected length of a connection, or the requested maximum transfer rate);
1. 受信側がトラフィックのパターンを予測できる場合（たとえば、送信されるデータの量、予想される接続の長さ、要求された最大転送速度など）。
2. when a receiver with a local indication that a path/local interface has changed since the CC parameters were saved;
2. CC パラメータが保存されてからパス/ローカル インターフェイスが変更されたことを受信機がローカルに示したとき。
3. when a receiver has knowledge of the current hardware limitations;
3. 受信機が現在のハードウェア制限を知っている場合。
4. when a receiver can predict additional capacity will be needed for other concurrent or later flows (i.e., it prefers to activate Careful Resume for a different connection).
4. 受信側が、他の同時フローまたはその後のフローに追加の容量が必要になると予測できる場合 (つまり、別の接続に対して慎重な再開をアクティブ化することを好みます)。
The CWND is one factor that limits the sending rate of a transport protocol. Other mechanisms also constrain the maximum sending rate. These include the sender pacing rate and the receiver-advertised window [RFC9293] or flow control credit [RFC9000]; see Section 4.7.
CWND は、トランスポート プロトコルの送信速度を制限する 1 つの要因です。他のメカニズムも最大送信速度を制限します。これらには、送信側ペーシング レートと受信側アドバタイズド ウィンドウ [RFC9293] またはフロー制御クレジット [RFC9000] が含まれます。セクション 4.7 を参照してください。
This section provides a set of examples where Careful Resume is expected to improve performance. Either endpoint can assume the role of a sender or a receiver. Careful Resume can also be independently used for each direction of a bidirectional connection.
このセクションでは、Careful Resume によってパフォーマンスの向上が期待される一連の例を示します。どちらのエンドポイントも送信者または受信者の役割を引き受けることができます。Careful Resume は、双方向接続の各方向に対して独立して使用することもできます。
For example, consider an application that uses a series of connections over a path: Without a new method, each connection would need to individually discover appropriate CC parameters, whereas Careful Resume allows the flow to use a rate based on the previously observed CC parameters.
たとえば、パス上で一連の接続を使用するアプリケーションを考えてみましょう。新しい方法がなければ、各接続は適切な CC パラメータを個別に検出する必要がありますが、Careful Resume を使用すると、フローは以前に観察された CC パラメータに基づくレートを使用できます。
Another example considers an application that connects after a disruption had temporarily reduced the path capacity: When this endpoint returns to use the path using Careful Resume, the sending rate can be based on the previously observed CC parameters.
別の例では、中断によりパス容量が一時的に減少した後に接続するアプリケーションを考慮します。このエンドポイントが慎重な再開を使用してパスの使用に戻ると、送信速度は以前に観察された CC パラメータに基づくことができます。
There is a particular benefit for any path with an RTT that is much larger than for typical Internet paths. In a specific example, an application connected via a geo-stationary satellite access network [IJSCN] could take 9 seconds to complete a 5.3 MB transfer using standard CC, whereas a sender using Careful Resume could reduce this transfer time to 4 seconds. The time to complete a 1 MB transfer could similarly be reduced by 62 % [MAPRG111]. This benefit is also expected for other sizes of transfer and for different path characteristics when a path has a large BDP. [CR25] provides further discussion of the method defined in this document and includes analysis over various types of paths.
一般的なインターネット パスよりもはるかに大きい RTT を使用するパスには、特に利点があります。特定の例では、静止衛星アクセス ネットワーク [IJSCN] 経由で接続されたアプリケーションは、標準 CC を使用して 5.3 MB の転送を完了するのに 9 秒かかる可能性がありますが、Careful Resume を使用する送信者はこの転送時間を 4 秒に短縮できます。1 MB の転送を完了するまでの時間も同様に 62 % 短縮できます [MAPRG111]。この利点は、他のサイズの転送や、パスの BDP が大きい場合のさまざまなパス特性でも期待されます。[CR25] では、この文書で定義されている方法についてさらに詳しく説明しており、さまざまなタイプのパスにわたる分析が含まれています。
Resuming a connection with CC parameters that were observed during a previous connection is inherently a tradeoff between the potential performance gains for the new connection and the risks of degraded performance for other connections that share a common bottleneck. The specified method is designed to obtain good performance when resuming is appropriate, while seeking to minimise the impact on other connections when it is not appropriate.
以前の接続中に観察された CC パラメータを使用して接続を再開することは、本質的に、新しい接続の潜在的なパフォーマンス向上と、共通のボトルネックを共有する他の接続のパフォーマンス低下のリスクとの間のトレードオフになります。指定されたメソッドは、再開が適切な場合には良好なパフォーマンスが得られるように設計されており、再開が適切でない場合には他の接続への影響を最小限に抑えるよう努めます。
The following precautions mitigate the risk of a sender adding excessive congestion to a path:
次の予防措置により、送信者がパスに過度の輻輳を追加するリスクが軽減されます。
1. The first precaution is to recognise whether the conditions have changed so much that the saved values are no longer valid. We describe that as the "Reconnaissance Phase". During that phase, the sender will not send more data than allowed for any new connection, e.g., using the recommended maximum IW for the first RTT of transmitting data [RFC6928] [RFC9002]. The sender will only proceed with the resume process if the reconnaissance succeeds. If it fails (for example, if previous packets in a connection experience congestion or the RTT is significantly different), the sender will follow the standard process for a new connection. This provides some protection against aggravating severe congestion and allows establishing the minimum RTT.
1. 最初の予防策は、保存された値が無効になるほど条件が変化したかどうかを認識することです。これを「偵察フェーズ」と呼びます。そのフェーズ中、送信者は、たとえば、データ送信の最初の RTT に推奨される最大 IW を使用するなど、新しい接続で許可されている以上のデータを送信しません [RFC6928] [RFC9002]。送信者は、偵察が成功した場合にのみ再開プロセスを続行します。これが失敗した場合 (たとえば、接続内の以前のパケットで輻輳が発生した場合、または RTT が大幅に異なる場合)、送信者は新しい接続の標準プロセスに従います。これにより、深刻な輻輳の悪化に対するある程度の保護が提供され、最小 RTT を確立できるようになります。
2. The second precaution is to cautiously use the saved parameters when resuming. This is called the "Unvalidated Phase". For example, the jump in the size of CWND/rate is restricted to a fraction (1/2) of the saved_cwnd, to avoid starving other flows that may have started or increased their capacity after the last capacity measurement. The same principle applies for CC algorithms that use different parameters to classic TCP CC: i.e., a sender must not send faster than allowed by a fraction of the saved CC parameters. For example, a connection using a rate-based CC algorithm (e.g., BBR) will set the pacing rate to half the remembered value of the "bottleneck bandwidth". The sender also needs to pace all unvalidated packets, to ensure the rate does not exceed the previously used rate. This is intended to avoid a sudden influx of packets that could result in building a bottleneck queue and disrupting existing flows. Successful validation can allow further increases of the CWND, after first validating that the used rate did not result in congestion.
2. 2 番目の予防措置は、再開するときに保存したパラメータを慎重に使用することです。これを「未検証フェーズ」と呼びます。たとえば、CWND/レートのサイズのジャンプは、最後の容量測定後に開始または容量を増加した可能性がある他のフローが枯渇するのを避けるために、saved_cwnd の一部 (1/2) に制限されます。同じ原則が、従来の TCP CC とは異なるパラメータを使用する CC アルゴリズムにも当てはまります。つまり、送信者は、保存された CC パラメータの一部によって許可される速度よりも速く送信してはなりません。たとえば、レートベースの CC アルゴリズム (BBR など) を使用する接続では、ペーシング レートが「ボトルネック帯域幅」の記憶されている値の半分に設定されます。また、送信者は、レートが以前に使用されたレートを超えないようにするために、すべての未検証のパケットのペースを調整する必要があります。これは、ボトルネック キューが構築され、既存のフローが中断される可能性のあるパケットの突然の流入を回避することを目的としています。検証が成功すると、使用されたレートが輻輳を引き起こさないことを最初に検証した後、CWND をさらに増やすことができます。
3. The third precaution is to enter a "Safe Retreat Phase" if the validation fails, for example, if congestion is detected during validation. The risk here is that the trial use of the saved CC parameters could have disrupted existing connections. For example, consider a connection using Reno CC: When exiting "Slow Start" mode due to loss, Reno would normally update the CWND to a "Slow Start threshold" set to half the volume of data in flight. However, during this validation, the CWND is restored from the saved CC parameters. The resultant sending rate could be much larger than the value that would have been reached by a "standard" Slow Start process, resulting in an overload of the path that potentially could cause significant congestion to other flows. Instead of continuing with that "too large" value, the retreat process resets the congestion window (rate) to a value no greater than what a standard process would have discovered. For other CC algorithms, such as CUBIC [RFC9438] or BBR, the implementation details may differ, but the principle remains: Trying and failing should not unduly disadvantage existing connections that share a common bottleneck (e.g., resulting in starving these connections).
3. 3 番目の予防措置は、検証中に輻輳が検出された場合など、検証が失敗した場合に「安全な退避フェーズ」に入るというものです。ここでのリスクは、保存された CC パラメータを試用すると、既存の接続が中断される可能性があることです。たとえば、Reno CC を使用した接続を考えてみましょう。損失により「スロー スタート」モードを終了すると、Reno は通常、CWND を、送信中のデータ量の半分に設定された「スロー スタートしきい値」に更新します。ただし、この検証中に、CWND は保存された CC パラメータから復元されます。結果として生じる送信速度は、「標準」スロー スタート プロセスによって到達される値よりもはるかに大きくなる可能性があり、その結果、パスの過負荷が発生し、他のフローに重大な輻輳を引き起こす可能性があります。「大きすぎる」値を継続する代わりに、後退プロセスは輻輳ウィンドウ (レート) を標準プロセスが検出する値を超えない値にリセットします。CUBIC [RFC9438] や BBR などの他の CC アルゴリズムの場合、実装の詳細は異なる場合がありますが、原則は変わりません。試行して失敗しても、共通のボトルネックを共有する既存の接続に不当な不利益を与えてはなりません (たとえば、これらの接続が枯渇する結果となる)。
This section provides a brief summary of key terms and the requirements language.
このセクションでは、重要な用語と要件言語の簡単な概要を説明します。
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 Remote Endpoint is an implementation-dependent value that identifies the sender's view of the network path being used. This is used to match the current path with a set of CC parameters associated with a previously observed path. It includes:
リモート エンドポイントは、使用されているネットワーク パスに対する送信者の見解を識別する実装に依存する値です。これは、現在のパスを、以前に観察されたパスに関連付けられた CC パラメータのセットと照合するために使用されます。これには次のものが含まれます。
* an identifier representing the sending interface (e.g., a globally assigned address/prefix or other local identifier);
* 送信インターフェースを表す識別子（グローバルに割り当てられたアドレス/プレフィックスまたは他のローカル識別子など）。
* an identifier representing the destination (e.g., a unicast or anycast IP address).
* 宛先を表す識別子 (ユニキャストまたはエニーキャスト IP アドレスなど)。
The Remote Endpoint could also include information such as the DSCP. If included, such information needs to be set consistently for a resumed connection to the same endpoint. Although additional information could improve the path differentiation, it could reduce the reusability of saved parameters.
リモート エンドポイントには、DSCP などの情報も含まれる場合があります。含まれている場合、そのような情報は、同じエンドポイントへの接続を再開するために一貫して設定する必要があります。情報を追加するとパスの区別が向上しますが、保存されたパラメータの再利用性が低下する可能性があります。
The saved CC parameters can only be used to modify the startup when the Remote Endpoint is not known to have changed (see Section 3.2).
保存された CC パラメータは、リモート エンドポイントが変更されたことがわかっていない場合にのみ、起動を変更するために使用できます (セクション 3.2 を参照)。
This document defines triggers to support logging key events. For example, [LOG] provides definitions that enable a Careful Resume implementation to generate QLOG events when using QUIC.
このドキュメントでは、主要なイベントのログ記録をサポートするトリガーを定義します。たとえば、[LOG] は、QUIC の使用時に Careful Resume 実装で QLOG イベントを生成できるようにする定義を提供します。
The document uses language drawn from a range of RFCs. The following terms are defined:
この文書では、さまざまな RFC から引用された言語が使用されています。次の用語が定義されています。
ACK:
ACK:
The indication at the transport layer that the Remote Endpoint has correctly received the acknowledged data. In a CC algorithm, an ACK also confirms that the acknowledged data is no longer in flight.
リモート エンドポイントが確認応答データを正しく受信したことをトランスポート層で示す。CC アルゴリズムでは、ACK は、確認応答されたデータが送信されていないことも確認します。
Beta:
ベータ：
A scaling factor between 0.5 and 1; the default value is 0.5.
0.5 ～ 1 のスケール係数。デフォルト値は 0.5 です。
Careful Resume:
慎重な履歴書:
The method specified in this document to select initial CC parameters and to more rapidly and safely increase the initial sending rate.
この文書で指定された方法は、初期 CC パラメータを選択し、初期送信レートをより迅速かつ安全に増加させるために使用されます。
Congestion Control (CC) parameters:
輻輳制御 (CC) パラメータ:
A set of saved CC parameters from observing the capacity of an established connection (see Section 1.1).
確立された接続の容量を監視して保存された CC パラメータのセット (セクション 1.1 を参照)。
congestion window (CWND):
輻輳ウィンドウ (CWND):
The congestion window or equivalent CC variable limiting the maximum sending rate (see [RFC5681]).
最大送信レートを制限する輻輳ウィンドウまたは同等の CC 変数 ([RFC5681] を参照)。
current Round Trip Time (RTT):
現在の往復時間 (RTT):
A sample measurement of the current RTT measured using the most recent ACK.
最新の ACK を使用して測定された現在の RTT の測定例。
flight_size:
フライトサイズ:
The current volume of unacknowledged data (see [RFC5681]).
未確認データの現在の量 ([RFC5681] を参照)。
jump_cwnd:
ジャンプ_cwnd:
The resumed CWND, used in the Unvalidated Phase.
再開された CWND。未検証フェーズで使用されます。
Lifetime:
一生：
The configured time after which a set of saved CC parameters can no longer be safely reused.
保存された CC パラメータのセットを安全に再利用できなくなるまでの設定された時間。
max_jump:
最大ジャンプ:
The configured maximum jump_cwnd.
設定された最大のjump_cwnd。
PipeSize:
パイプサイズ:
A measure of the validated available capacity based on the acknowledged data.
確認済みのデータに基づいて検証された利用可能な容量の測定値。
Remote Endpoint:
リモートエンドポイント:
The endpoint corresponding to a connection; see Section 2.2.
接続に対応するエンドポイント。セクション 2.2 を参照してください。
saved_cwnd:
保存済み_cwnd:
A CC parameter with the preserved capacity derived from observation of a previous connection (see Section 4.1).
以前の接続の観察から導出された保存された容量を持つ CC パラメータ (セクション 4.1 を参照)。
saved_remote_endpoint:
保存された_リモート_エンドポイント:
The Remote Endpoint that was associated with a set of saved CC parameters.
保存された CC パラメーターのセットに関連付けられたリモート エンドポイント。
saved_rtt:
保存済み_rtt:
A CC parameter with the preserved minimum RTT (see Section 4.1).
保存された最小 RTT を持つ CC パラメータ (セクション 4.1 を参照)。
unvalidated packet:
未検証のパケット:
A packet sent when the CWND has been increased beyond the size normally permitted by the CC algorithm; if such a packet is acknowledged by an ACK, it contributes to the PipeSize, but if congestion is detected, it triggers entry to the Safe Retreat Phase.
CWND が CC アルゴリズムで通常許可されるサイズを超えて増加したときに送信されるパケット。このようなパケットが ACK によって確認された場合、PipeSize に寄与しますが、輻輳が検出された場合は、安全な退避フェーズへのエントリがトリガーされます。
This section defines a series of phases that the congestion controller moves through as a connection uses Careful Resume. Each rule is prefixed by the name of the relevant phase.
このセクションでは、接続が慎重な再開を使用するときに輻輳コントローラが通過する一連のフェーズを定義します。各ルールには、関連するフェーズの名前が接頭辞として付けられます。
Normal CC...> Connect -> Reconnaissance --------------------> Normal CC
(Observing) | ^
v |
Unvalidated --------------------------+
| | |
| +--> Validating --------------+
| | |
| | |
+---------------+--> Safe Retreat ---+
Figure 1: Key Transitions Between Phases in Careful Resume
図 1: 慎重な履歴書のフェーズ間の主な移行
The key phases of Careful Resume are illustrated in Figure 1. Examples of transitions between these phases are provided in Appendices A and B.
Careful Resume の主要なフェーズを図 1 に示します。これらのフェーズ間の移行の例は、付録 A および B に示されています。
An established connection can save a set of CC parameters for the specific path to the current endpoint. A set of CC parameters includes a Lifetime (e.g., as a timestamp after which the parameters must not be used) and corresponds to one saved_remote_endpoint.
確立された接続では、現在のエンドポイントへの特定のパスの CC パラメータのセットを保存できます。CC パラメータのセットにはライフタイム (たとえば、それ以降はパラメータを使用してはならないタイムスタンプとして) が含まれており、1 つの Saved_remote_endpoint に対応します。
The following rules apply to observing a connection:
接続の監視には次のルールが適用されます。
* Observing (saved_cwnd): The currently utilised capacity for the connection is measured as the volume of bytes sent during an RTT and is recorded in the saved_cwnd. This could be computed by measuring the volume of data acknowledged in one RTT. If the measured CWND is less than four times the IW, the sender can choose to not save the CC parameters, because the additional actions associated with performing Careful Resume for a small CWND would not justify its use.
* 監視 (saved_cwnd): 接続で現在使用されている容量が、RTT 中に送信されたバイト量として測定され、saved_cwnd に記録されます。これは、1 つの RTT で確認されたデータの量を測定することで計算できます。測定された CWND が IW の 4 倍未満の場合、送信者は CC パラメータを保存しないことを選択できます。これは、小規模な CWND に対する慎重な再開の実行に関連する追加アクションがその使用を正当化しないためです。
* Observing (saved_rtt): The minimum RTT at the time of observation is saved as the saved_rtt.
* 観測中（saved_rtt）：観測時の最小RTTをsaved_rttとして保存します。
* Observing (updating saved CC parameters): A sender MUST NOT retain more than one set of CC parameters for a Remote Endpoint, but the set of CC parameters SHOULD be updated (or replaced) after a later observation of a path to the same Remote Endpoint.
* 監視（保存された CC パラメータの更新）：送信者は、リモート エンドポイントに対して複数の CC パラメータ セットを保持してはなりません（MUST NOT）が、同じリモート エンドポイントへのパスを後で監視した後、CC パラメータのセットを更新（または置換）する必要があります（SHOULD）。
Implementation notes are provided in Section 4.1.
実装に関する注意事項はセクション 4.1 に記載されています。
During this phase, the sender attempts to retrieve CC parameters that were previously saved, then determine whether the path is consistent with a previously observed path (i.e, match the saved_remote_endpoint in a set of saved CC parameters).
このフェーズ中、送信者は以前に保存された CC パラメータの取得を試み、パスが以前に観察されたパスと一致するかどうか (つまり、保存された CC パラメータのセット内の Saved_remote_endpoint と一致するか) を判断します。
The sender enters the Reconnaissance Phase after connection setup (using normal CC). In this phase, the CWND is initialised to the IW, and the sender transmits any initial data.
送信者は、接続セットアップ後に偵察フェーズに入ります (通常の CC を使用)。このフェーズでは、CWND が IW に対して初期化され、送信側は初期データを送信します。
In the Reconnaissance Phase, the sender performs the following action:
偵察フェーズでは、送信者は次のアクションを実行します。
* Reconnaissance Phase (received acknowledgment): The CWND is increased using normal CC as each ACK confirms delivery of previously unacknowledged data (i.e., the base CC algorithm continues to operate normally).
* 偵察フェーズ (確認応答の受信): 各 ACK が以前に確認されていないデータの配信を確認するため、通常の CC を使用して CWND が増加します (つまり、基本 CC アルゴリズムは正常に動作し続けます)。
The sender exits the Reconnaissance Phase and stops using Careful Resume when one of the following events occurs:
次のいずれかのイベントが発生すると、送信者は偵察フェーズを終了し、慎重な再開の使用を停止します。
* Reconnaissance Phase (detected congestion): If the sender detects congestion (e.g., packet loss or ECN-CE marking), this indicates that use of the saved CC parameters is inappropriate. The sender stops using Careful Resume and MUST continue using normal CC to react to the detected congestion.
* 偵察フェーズ (輻輳の検出): 送信者が輻輳 (パケット損失や ECN-CE マーキングなど) を検出した場合、保存された CC パラメータの使用が不適切であることを示します。送信者は、Careful Resume の使用を停止し、検出された輻輳に対応するために通常の CC を使用し続けなければなりません (MUST)。
* Reconnaissance Phase (using saved_cwnd): Only one connection can use a specific set of saved CC parameters. If another connection has already started to use the saved_cwnd, the sender MUST exit Careful Resume and return to use normal CC.
* 偵察フェーズ (saved_cwnd を使用): 保存された CC パラメーターの特定のセットを使用できる接続は 1 つだけです。別の接続がすでにsaved_cwndの使用を開始している場合、送信者はCareful Resumeを終了し、通常のCCの使用に戻らなければなりません(MUST)。
* Reconnaissance Phase (path change): If the Remote Endpoint is not the same as any saved_remote_endpoint, or the sender receives a signal from the local stack indicating that the path is now different to the observed path, the sender MUST stop using Careful Resume and returns to use normal CC.
* 偵察フェーズ (パス変更): リモート エンドポイントがどの Saved_remote_endpoint とも異なる場合、または送信者がローカル スタックからパスが観測されたパスと異なることを示す信号を受信した場合、送信者は Careful Resume の使用を停止し、通常の CC の使用に戻らなければなりません (MUST)。
* Reconnaissance Phase (lifetime of saved CC parameters): The CC parameters are temporal. If the Lifetime of the observed CC parameters is exceeded, this set of CC parameters is not used. The saved CC parameters are deleted, and the sender MUST stop using Careful Resume and return to using normal CC.
* 偵察フェーズ (保存された CC パラメータの有効期間): CC パラメータは一時的なものです。観察された CC パラメータのライフタイムを超えた場合、この CC パラメータのセットは使用されません。保存された CC パラメータは削除され、送信者は Careful Resume の使用を中止し、通常の CC の使用に戻らなければなりません。
* Reconnaissance Phase (minimum RTT too small): If the minimum RTT recorded in the Reconnaissance Phase is less than or equal to (saved_rtt / 2) (see Section 4.2.1), the sender MUST stop using Careful Resume (e.g., logged as rtt_not_validated in [LOG]) and returns to use normal CC. This is because the calculation of a sending rate from a saved_cwnd is directly impacted by the RTT; therefore, a significant change in the RTT is a strong indication that the previously observed CC parameters are not valid for the current path.
* 偵察フェーズ (最小 RTT が小さすぎる): 偵察フェーズで記録された最小 RTT が (saved_rtt / 2) 以下の場合 (セクション 4.2.1 を参照)、送信者は慎重な再開 (例: [LOG] に rtt_not_validated として記録される) の使用を中止し、通常の CC の使用に戻らなければなりません (MUST)。これは、saved_cwnd からの送信レートの計算が RTT の影響を直接受けるためです。したがって、RTT の大幅な変化は、以前に観察された CC パラメータが現在のパスに対して有効ではないことを強く示しています。
Note: When a path is not confirmed, Careful Resume does not modify the CWND before it exits to use normal CC.
注: パスが確認されていない場合、Careful Resume は通常の CC を使用するために終了する前に CWND を変更しません。
The sender is permitted to enter the Unvalidated Phase as described below:
送信者は、以下に説明するように、未検証フェーズに入ることが許可されます。
* Reconnaissance Phase (path confirmed): When the sender has received an ACK that acknowledges all the initial data (usually the IW) without reported congestion, it MAY then enter the Unvalidated Phase. Although a sender can immediately transition to the Unvalidated Phase, this transition MAY be deferred to the time at which more data is sent than would have been normally permitted by the CC algorithm.
* 偵察フェーズ (パス確認): 送信者が輻輳が報告されずにすべての初期データ (通常は IW) を確認する ACK を受信した場合、未検証フェーズに入ってもよい(MAY)。送信者はすぐに未検証フェーズに移行できますが、この移行は、CC アルゴリズムで通常許可されているよりも多くのデータが送信される時点まで延期されてもよい(MAY)。
Implementation notes are provided in Section 4.2.
実装に関する注意事項はセクション 4.2 に記載されています。
The Unvalidated Phase is designed to enable the CWND to more rapidly get up to speed by using paced transmission of a tentatively increased CWND.
未検証フェーズは、暫定的に増加した CWND のペース送信を使用することで、CWND がより迅速に速度に対応できるように設計されています。
On entry to the Unvalidated Phase, the following actions are performed:
未検証フェーズに入ると、次のアクションが実行されます。
* Unvalidated Phase (initialising PipeSize): The variable PipeSize is initialised to the flight_size on entry to the Unvalidated Phase. This records the used portion of the CWND before a jump is applied.
* 未検証フェーズ (PipeSize の初期化): 変数 PipeSize は、未検証フェーズに入るときに、flight_size に初期化されます。これは、ジャンプが適用される前に CWND の使用された部分を記録します。
* Unvalidated Phase (setting the jump_cwnd): To avoid starving other flows that could have either started or increased their use of capacity since observing the capacity of a path, the jump_cwnd MUST be no more than half of the saved_cwnd. Hence, jump_cwnd is less than or equal to Min(max_jump,(saved_cwnd/2)). CWND = jump_cwnd.
* 未検証フェーズ (jump_cwnd の設定): パスの容量を監視してから容量の使用を開始または増加した可能性がある他のフローが枯渇するのを避けるために、jump_cwnd は Save_cwnd の半分以下でなければなりません (MUST)。したがって、jump_cwnd は Min(max_jump,(saved_cwnd/2)) 以下になります。CWND = ジャンプ_cwnd。
In the Unvalidated Phase, the sender performs the following actions:
未検証フェーズでは、送信者は次のアクションを実行します。
* Unvalidated Phase (pacing transmission): All packets sent in the Unvalidated Phase MUST use pacing based on the current RTT.
* 未検証フェーズ (ペーシング送信): 未検証フェーズで送信されるすべてのパケットは、現在の RTT に基づいたペーシングを使用しなければなりません (MUST)。
* Unvalidated Phase (tracking PipeSize): The variable PipeSize is increased by the volume of data that is newly acknowledged by each received ACK. (This indicates a previously unvalidated packet has been successfully sent over the path.)
* 未検証フェーズ (PipeSize の追跡): 変数 PipeSize は、受信した ACK ごとに新たに確認応答されたデータの量だけ増加します。(これは、以前に検証されていないパケットがパス上で正常に送信されたことを示します。)
The sender exits the Unvalidated Phase and enters the Safe Retreat Phase when one of the following events occurs:
次のいずれかのイベントが発生すると、送信者は未検証フェーズを終了し、安全な退却フェーズに入ります。
* Unvalidated Phase (confirming the path during transmission): If the sender determines that it is not valid to use the previous CC parameters due to a detected path change (e.g., a change in the RTT or an explicit signal indicating a path change), the Safe Retreat Phase MUST be entered (e.g., logged as path_changed in [LOG]).
* 未検証フェーズ（送信中のパスの確認）：検出されたパス変更（例：RTT の変更またはパス変更を示す明示的な信号）により、送信者が以前の CC パラメータの使用が無効であると判断した場合、安全な退却フェーズに入らなければなりません（例：[LOG] に path_changed として記録されます）。
* Unvalidated Phase (detected congestion): If the sender detects congestion (e.g., packet loss or ECN-CE marking), the Safe Retreat Phase MUST be entered (e.g., logged as either packet_loss or ECN_CE in [LOG]). (Note that insufficient time has passed in the Unvalidated Phase for a sender to receive any feedback validating the jump in the CWND. Therefore, any detected congestion must have resulted from packets sent before the Unvalidated Phase.)
* 未検証フェーズ (輻輳の検出): 送信者が輻輳 (例: パケット損失または ECN-CE マーキング) を検出した場合、安全な退却フェーズに入らなければなりません (例: [LOG] に packet_loss または ECN_CE として記録されます)。(未検証フェーズでは、送信者が CWND でのジャンプを検証するフィードバックを受信するには十分な時間が経過していないことに注意してください。したがって、検出された輻輳は、未検証フェーズの前に送信されたパケットに起因するものである必要があります。)
The sender exits the Unvalidated Phase and evaluates whether to enter the Validating Phase when one of the following events occurs:
次のいずれかのイベントが発生すると、送信者は未検証フェーズを終了し、検証フェーズに入るかどうかを評価します。
* Unvalidated Phase (completed sending all unvalidated packets): The sender enters the Validating Phase when the flight_size equals the CWND (e.g., logged as last_unvalidated_packet_sent in [LOG]). For an implementation that measures the CWND in bytes, this condition is also true when the remaining unused CWND is less than one maximum-sized packet.
* 未検証フェーズ (すべての未検証パケットの送信が完了): 送信者は、flight_size が CWND と等しい場合 (たとえば、[LOG] に last_unvalidated_packet_sent として記録される) に検証フェーズに入ります。CWND をバイト単位で測定する実装の場合、この条件は、残りの未使用の CWND が最大サイズのパケット 1 つ未満である場合にも当てはまります。
* Unvalidated Phase (receiving acknowledgment for an unvalidated packet): The sender enters the Validating Phase when an ACK is received that acknowledges the first packet number (or higher) that was sent in the Unvalidated Phase (e.g., logged as first_unvalidated_packet_acknowledged in [LOG]).
* 未検証フェーズ（未検証パケットに対する確認応答の受信）：未検証フェーズで送信された最初のパケット番号（またはそれ以上）を確認する ACK が受信されると、送信者は検証フェーズにに入ります（たとえば、[LOG] に first_unvalidated_packet_acknowledged として記録されます）。
* Unvalidated Phase (limiting time in the Unvalidated Phase): The sender enters the Validating Phase if more than one RTT has elapsed while in the Unvalidated Phase (e.g., logged as rtt_exceeded in [LOG]).
* 未検証フェーズ（未検証フェーズの時間制限）：未検証フェーズ中に複数の RTT が経過した場合（たとえば、[LOG] に rtt_exceeded として記録される）、送信者は検証フェーズに入ります。
Unvalidated Phase (check flight_size): Upon any of these events, and after processing any Acknowledgments that update the PipeSize and flight_size, the sender checks if the flight_size is less than the IW or if the flight_size is less than or equal to the PipeSize, and if true, resets the CWND to the PipeSize (e.g., logged as rate_limited in [LOG]) and stops using Careful Resume and returns to use normal CC. In the absence of detected congestion, the CWND is not reduced below the IW. (The PipeSize does not include the part of the jump_cwnd that was not utilised.) Otherwise, the CWND MUST be set to the flight_size and the sender progresses to the Validating Phase.
未検証フェーズ (flight_size を確認): これらのイベントのいずれかが発生した後、PipeSize と Flight_size を更新する確認応答を処理した後、送信者は、flight_size が IW 未満であるかどうか、または Flight_size が PipeSize 以下であるかどうかを確認し、true の場合は、CWND を PipeSize にリセットし (たとえば、[LOG] に rate_limited として記録される)、慎重な再開の使用を停止し、通常の使用に戻ります。CC。輻輳が検出されない場合、CWND は IW を下回ることはありません。(PipeSize には、使用されなかった Jump_cwnd の部分は含まれません。)それ以外の場合は、CWND を Flight_size に設定しなければならず、送信側は検証フェーズに進みます。
Implementation notes are provided in Section 4.3.
実装に関する注意事項はセクション 4.3 に記載されています。
Notes for BBR are provided in Appendix C.1.
BBR に関する注意事項は、付録 C.1 に記載されています。
The Validating Phase checks whether all packets sent in the Unvalidated Phase were received without inducing congestion. The CWND remains unvalidated and the sender typically remains in this phase for one RTT.
検証フェーズでは、未検証フェーズで送信されたすべてのパケットが輻輳を引き起こすことなく受信されたかどうかをチェックします。CWND は未検証のままであり、送信者は通常、1 RTT の間このフェーズに留まります。
In the Validating Phase, the sender performs the following actions:
検証フェーズでは、送信者は次のアクションを実行します。
* Validating Phase (tracking PipeSize): The PipeSize is increased by the volume of acknowledged data for each received ACK that indicates a packet was successfully sent over the path.
* 検証フェーズ (PipeSize の追跡): PipeSize は、パケットがパス上で正常に送信されたことを示す、受信した ACK ごとに確認応答されたデータの量だけ増加します。
* Validating Phase (updating the CWND): The CWND is updated using the normal rules for the current congestion controller. This typically will use "Slow Start", which allows the CWND to be increased for each received ACK that indicates a packet has been successfully sent across the path.
* Validating Phase (updating the CWND): The CWND is updated using the normal rules for the current congestion controller.これには通常、「スロー スタート」が使用されます。これにより、パケットがパス上で正常に送信されたことを示す ACK を受信するたびに CWND を増やすことができます。
The sender exits the Validating Phase when one of the following events occurs:
次のいずれかのイベントが発生すると、送信者は検証フェーズを終了します。
* Validating Phase (detected congestion): If the sender determines that congestion was detected (e.g., packet loss or ECN-CE marking), Careful Resume enters the Safe Retreat Phase (e.g., logged as either packet_loss or ECN_CE in [LOG]).
* 検証フェーズ (輻輳の検出): 送信者が輻輳が検出されたと判断した場合 (例: パケット損失または ECN-CE マーキング)、慎重な再開は安全なリトリートフェーズに入ります (例: [LOG] に packet_loss または ECN_CE として記録されます)。
* Validating Phase (receiving acknowledgment of the unvalidated packets): The sender stops using Careful Resume when an ACK is received that acknowledges the last packet number (or higher) that was sent in the Unvalidated Phase (e.g., logged as last_unvalidated_packet_acknowledged in [LOG]). This means that the packets sent in the Unvalidated Phase were acknowledged without congestion.
* 検証フェーズ（未検証パケットの確認応答の受信）：未検証フェーズで送信された最後のパケット番号（またはそれ以上）を確認するACK（たとえば、[LOG]にlast_unvalidated_packet_acknowledgedとして記録される）を受信した場合、送信側はCareful Resumeの使用を停止します。これは、未検証フェーズで送信されたパケットが輻輳なしで確認応答されたことを意味します。
Notes for BBR are provided in Appendix C.2.
BBR に関する注意事項は、付録 C.2 に記載されています。
This phase is entered when congestion is detected for an unvalidated packet. It drains the path of other unvalidated packets.
このフェーズは、未検証のパケットの輻輳が検出されると開始されます。他の未検証パケットのパスを排出します。
On entry to the Safe Retreat Phase, the following actions are performed:
安全退却フェーズに入ると、次のアクションが実行されます。
* Safe Retreat Phase (removing saved information): The set of saved CC parameters for the path are deleted, to prevent these from being used again by later flows.
* 安全な退避フェーズ (保存された情報の削除): パスの保存された CC パラメータのセットが削除され、これらが後のフローで再度使用されるのを防ぎます。
* Safe Retreat Phase (re-initializing the CWND): The CWND MUST be reduced to no more than (PipeSize/2). This avoids persistent starvation by allowing capacity for other flows to regain their share of the total capacity. (Note: The minimum CWND in QUIC is 2 packets; see [RFC9002], Section 4.8).
* 安全な退避フェーズ (CWND の再初期化): CWND は (PipeSize/2) 以下に減らさなければなりません。これにより、他のフローの容量が総容量のシェアを取り戻すことができるようになり、持続的な飢餓が回避されます。(注: QUIC の最小 CWND は 2 パケットです。[RFC9002]、セクション 4.8 を参照)。
* Safe Retreat Phase (loss recovery): Loss recovery commences using the newly reduced CWND that was set on entry to the Safe Retreat Phase. When the CWND is reduced, a QUIC sender can immediately send a single packet prior to the reduction [RFC9002] to speed up loss recovery. A similar method for TCP is described in Section 5 of [RFC6675]. The loss recovery continues until acknowledgment of the last packet number (or a later packet) sent in the Unvalidated or Validating Phase. (Note: If the last unvalidated packet is not cumulatively acknowledged, then additional packets might also need to be retransmitted.)
* 安全な退却フェーズ (損失回復): 安全な退却フェーズへの開始時に設定された、新しく削減された CWND を使用して損失の回復が開始されます。CWND が削減されると、QUIC 送信者は損失回復を高速化するために、削減前に 1 つのパケットをただちに送信できます [RFC9002]。TCP の同様の方法は、[RFC6675] のセクション 5 で説明されています。損失回復は、未検証フェーズまたは検証フェーズで送信された最後のパケット番号 (またはそれ以降のパケット) が確認されるまで継続します。(注: 最後の未検証パケットが累積的に確認応答されない場合、追加のパケットも再送信する必要がある可能性があります。)
In the Safe Retreat Phase, the sender performs the following actions:
安全な退却フェーズでは、送信者は次のアクションを実行します。
* Safe Retreat Phase (tracking PipeSize): The sender continues to update the PipeSize after processing each ACK. (The PipeSize will be used to update the ssthresh when leaving this phase, but it does not affect the CWND.)
* 安全な退却フェーズ (PipeSize の追跡): 送信者は、各 ACK を処理した後も PipeSize を更新し続けます。(PipeSize は、このフェーズを終了するときに ssthresh を更新するために使用されますが、CWND には影響しません。)
* Safe Retreat Phase (maintaining the CWND): The CWND MUST NOT be increased in the Safe Retreat Phase.
* 安全撤退フェーズ (CWND の維持): 安全撤退フェーズでは CWND を増加させてはなりません。
* Safe Retreat Phase (acknowledgment of unvalidated packets): When the last packet (or a later packet) sent during the Unvalidated Phase has been acknowledged, the sender stops using Careful Resume and returns to use normal CC.
* 安全なリトリート フェーズ (未検証パケットの確認応答): 未検証フェーズ中に送信された最後のパケット (またはそれ以降のパケット) が確認応答されると、送信者は慎重な再開の使用を停止し、通常の CC の使用に戻ります。
On leaving the Safe Retreat Phase, the ssthresh MUST be set to no larger than the most recently measured PipeSize * Beta, where Beta is a scaling factor between 0.5 and 1. The default value is 0.5, chosen to reduce the probability of inducing a second round of congestion. CUBIC defines a Beta__cubic of 0.7 [RFC9438] (e.g., logged as exit_recovery in [LOG]).
安全な退却フェーズを終了するとき、ssthresh は、最後に測定された PipeSize * Beta 以下に設定しなければなりません (MUST)。ここで、Beta は 0.5 から 1 までの倍率です。デフォルト値は 0.5 で、2 回目の輻輳を引き起こす可能性を減らすために選択されています。CUBIC は、0.7 [RFC9438] の Beta__cubic を定義します (たとえば、[LOG] に exit_recovery として記録されます)。
Implementation notes are provided in Section 4.5.
実装に関する注意事項はセクション 4.5 に記載されています。
Notes for BBR are described in Appendix C.3.
BBR に関する注意事項は、付録 C.3 に記載されています。
A sender that experiences persistent congestion (e.g., a Retransmission Time Out (RTO) or expiry in TCP) ceases to use Careful Resume. The sender stops using Careful Resume and returns to use normal CC. If using BBR, the normal processing of packet losses will cause it to enter the Drain state while the "carefully-resuming" flag is set to True; see Appendix C.3.
永続的な輻輳 (再送信タイムアウト (RTO) や TCP の期限切れなど) が発生した送信者は、慎重な再開の使用を中止します。送信者は Careful Resume の使用を中止し、通常の CC の使用に戻ります。BBR を使用する場合、パケット損失の通常の処理により、「慎重に再開」フラグが True に設定されている間、BBR はドレイン状態になります。付録 C.3 を参照してください。
As in loss recovery, data sent in the Unvalidated Phase could be later acknowledged after an RTO event.
損失回復の場合と同様に、未検証フェーズで送信されたデータは、RTO イベント後に後で確認される可能性があります。
After exiting Careful Resume, the sender returns to using the normal CC algorithm (e.g., in congestion avoidance when the CWND is more than ssthresh, or Slow Start when less than or equal to ssthresh).
Careful Resume を終了した後、送信者は通常の CC アルゴリズムの使用に戻ります (たとえば、CWND が ssthresh を超える場合の輻輳回避、または ssthresh 以下の場合のスロー スタート)。
Implementation notes are provided in Section 4.6.
実装に関する注意事項はセクション 4.6 に記載されています。
This section provides guidance for implementation and use.
このセクションでは、実装と使用に関するガイダンスを提供します。
There are various approaches to measuring the capacity used by a connection. Congestion controllers, such as Reno [RFC5681] or CUBIC [RFC9438], could estimate the capacity based on the CWND, flight_size, acknowledged rate, etc. A different approach could estimate the same parameters for a rate-based congestion controller, such as BBR [BBR-CC], or by observing the rate at which data is acknowledged by the Remote Endpoint.
接続で使用される容量を測定するには、さまざまな方法があります。Reno [RFC5681] や CUBIC [RFC9438] などの輻輳コントローラは、CWND、flight_size、確認応答レートなどに基づいて容量を推定できます。別のアプローチでは、BBR [BBR-CC] などのレートベースの輻輳コントローラの同じパラメータを推定したり、リモート エンドポイントによってデータが確認応答されるレートを観察したりすることによって、同じパラメータを推定できます。
Implementations are required to calculate a saved_rtt, measuring the minimum RTT while observing the capacity. For example, this could be the minimum of a set RTT of measurements measured over the previous 5 minutes.
実装では、容量を観察しながら最小 RTT を測定して、saved_rtt を計算する必要があります。たとえば、これは、過去 5 分間に測定された測定値のセット RTT の最小値である可能性があります。
* There are cases where the current CWND does not reflect the path capacity. At the end of Slow Start, the CWND can be significantly larger than needed to fully utilise the path (i.e., a CWND overshoot). It is inappropriate to use an overshoot in the CWND as a basis for estimating the capacity. In most cases, the CWND will converge to a stable value after several more RTTs. One mitigation when a connection is in Slow Start could be to set the saved_cwnd based on the validated pipe size (i.e., CWND / 2).
* 現在の CWND がパス容量を反映していない場合があります。スロー スタートの終了時には、CWND がパスを完全に利用するために必要な値より大幅に大きくなる可能性があります (つまり、CWND オーバーシュート)。容量を見積もるための基礎として CWND のオーバーシュートを使用することは不適切です。ほとんどの場合、さらに数回 RTT を繰り返すと、CWND は安定した値に収束します。接続がスロー スタートにある場合の緩和策の 1 つは、検証されたパイプ サイズ (CWND / 2) に基づいて Saved_cwnd を設定することです。
* When the sender is rate limited or in the RTT following a burst of transmission, a sender typically transmits less data than allowed by the CWND. Such observations could be discounted when estimating the saved_cwnd (e.g., when a previous observation recorded a higher value).
* 送信者がレート制限されている場合、または送信バースト後の RTT にある場合、送信者は通常、CWND で許可されているデータよりも少ないデータを送信します。このような観測値は、saved_cwnd を推定するときに割り引かれる可能性があります (たとえば、前の観測値がより高い値を記録した場合)。
In the Reconnaissance Phase, the sender initiates a connection and starts sending initial data, while measuring the current RTT. The CC is not modified. A sender therefore needs to limit the initial data, sent in the first RTT of transmitted data, to no more than the IW [RFC9002]. This transmission using the IW is assumed to be a safe starting point for any path to avoid adding excessive load to a potentially congested path.
偵察フェーズでは、送信者は接続を開始し、現在の RTT を測定しながら初期データの送信を開始します。CC は変更されません。したがって、送信者は、送信データの最初の RTT で送信される初期データを IW [RFC9002] 以下に制限する必要があります。IW を使用したこの送信は、輻輳の可能性があるパスに過剰な負荷を追加することを避けるために、あらゆるパスの安全な開始点であると想定されます。
Careful Resume does not permit multiple concurrent reuse of the saved CC parameters. When multiple new concurrent connections are made to a server, each can have a valid saved_remote_endpoint, but the saved_cwnd can only be used by one connection at a time. This is to prevent the sender from performing multiple jumps in the CWND, each individually based on the same saved_cwnd, and hence creating an excessive aggregate load at the bottleneck.
Careful Resume では、保存された CC パラメータを複数同時に再利用することはできません。サーバーに対して複数の新しい同時接続が行われる場合、それぞれに有効な Saved_remote_endpoint を設定できますが、saved_cwnd を使用できるのは一度に 1 つの接続のみです。これは、送信側が同じ Saved_cwnd に基づいて CWND で複数のジャンプを実行し、ボトルネックで過度の総負荷が発生することを防ぐためです。
The method that is used to prevent reuse of the saved CC parameters will depend upon the design of the server. For example, if a simple sender receives multiple connections from a Remote Endpoint, then the sender process could use a hash table to manage the CC parameters, whereas when using some types of load balancing, a distributed system might be needed to ensure this invariant when the load balancing hashes connections by 4-tuple and hence multiple connections from the same client device are served by different server processes; see also Section 4.2.
保存された CC パラメータの再利用を防ぐために使用される方法は、サーバーの設計によって異なります。たとえば、単純な送信者がリモート エンドポイントから複数の接続を受信する場合、送信者プロセスはハッシュ テーブルを使用して CC パラメーターを管理できますが、一部の種類の負荷分散を使用する場合、負荷分散が 4 タプルで接続をハッシュし、そのため同じクライアント デバイスからの複数の接続が異なるサーバー プロセスによって処理される場合、この不変性を確保するために分散システムが必要になる場合があります。セクション 4.2 も参照してください。
A sender that is rate limited [RFC7661] sends insufficient data to be able to validate transmission at a higher rate. Such a sender is allowed to remain in the Reconnaissance Phase and to not transition to the Unvalidated Phase until there is more data in the transmission buffer than would normally be permitted by the CC algorithm.
レート制限 [RFC7661] が設定されている送信者は、より高いレートでの送信を検証するには不十分なデータを送信します。このような送信者は、CC アルゴリズムで通常許可されるよりも多くのデータが送信バッファに存在するまで、偵察フェーズに留まり、未検証フェーズに移行しないことが許可されます。
Path characteristics can change over time for many reasons. This can result in the previously observed CC parameters becoming irrelevant. To help confirm the path, the sender compares the saved_rtt with each current RTT sample.
パスの特性は、さまざまな理由により時間の経過とともに変化する可能性があります。これにより、以前に観察された CC パラメータが無関係になる可能性があります。パスを確認するために、送信者は、saved_rtt を現在の各 RTT サンプルと比較します。
If the current RTT sample is less than a half of the saved_rtt, this is regarded as too small. This is an indicator of a path change. This factor of two arises because the jump_cwnd is calculated as half the measured saved_cwnd and the sending rate ought not to exceed the observed rate when the saved_cwnd was measured.
現在の RTT サンプルが Saved_rtt の半分未満である場合、これは小さすぎるとみなされます。これはパスの変更を示すインジケータです。この係数 2 は、jump_cwnd が測定された save_cwnd の半分として計算され、送信レートが、saved_cwnd が測定されたときに観測されたレートを超えてはいけないために発生します。
If the current RTT is larger than the saved_rtt, this would result in a proportionally lower rate for the unvalidated packets, because the transmission is paced based on the current RTT. Hence, this rate is still safe. If the current RTT has been incorrectly measured as larger than the actual path RTT, the sender will receive an ACK for an unvalidated packet before it has completed the Unvalidated Phase. This ACK resets the CWND to reflect the flight_size, and the sender then enters the Validating Phase. The flight_size reflects the amount of outstanding data in the network rather than the maximum that is permitted by the CWND.
現在の RTT が Saved_rtt よりも大きい場合、送信のペースは現在の RTT に基づいて調整されるため、未検証のパケットのレートが比例して低くなります。したがって、このレートはまだ安全です。現在の RTT が実際のパス RTT よりも大きいと誤って測定された場合、送信者は未検証フェーズが完了する前に未検証パケットに対する ACK を受信します。この ACK は、flight_size を反映するために CWND をリセットし、送信者は検証フェーズに入ります。Flight_size は、CWND によって許可されている最大値ではなく、ネットワーク内の未処理のデータの量を反映しています。
A current RTT that is more than ten times the saved_rtt is indicative of a path change. The value of ten accommodates both increases in latency from buffering on a path and any variation between RTT samples.
現在の RTT が Saved_rtt の 10 倍を超える場合は、パスの変更を示します。10 という値は、パス上のバッファリングによる遅延の増加と、RTT サンプル間の変動の両方に対応します。
Note 1: In the Reconnaissance Phase, the sender calculates a minimum RTT over the phase and checks this on entry to the Unvalidated Phase. This avoids a need to check after each current RTT sample.
注 1: 偵察フェーズでは、送信者はフェーズ全体の最小 RTT を計算し、未検証フェーズへの開始時にこれを確認します。これにより、現在の RTT サンプルごとにチェックする必要がなくなります。
Note 2: During the Unvalidated Phase, the minimum RTT cannot increase, and hence the minimum RTT can never be larger than (saved_rtt x 10) during the Unvalidated Phase.
注 2: 未検証フェーズ中は最小 RTT を増やすことはできないため、未検証フェーズ中は最小 RTT が (saved_rtt x 10) より大きくなることはありません。
The sender also verifies that the initial data was acknowledged. Any loss could be indicative of persistent congestion. If a sender in the Reconnaissance Phase detects congestion, it stops using Careful Resume and returns to using normal CC. Some transport protocols implement CC mechanisms that infer potential congestion from an increase in the current RTT. Designs need to consider whether such an indication is a suitable trigger to stop using Careful Resume and revert to using normal CC.
送信者は、初期データが確認応答されたことも検証します。損失がある場合は、持続的な輻輳を示している可能性があります。偵察フェーズの送信者が輻輳を検出すると、慎重な再開の使用を中止し、通常の CC の使用に戻ります。一部のトランスポート プロトコルは、現在の RTT の増加から潜在的な輻輳を推測する CC メカニズムを実装しています。設計では、そのような兆候が Careful Resume の使用を中止し、通常の CC の使用に戻す適切なトリガーであるかどうかを検討する必要があります。
This section considers the safety for using saved CC parameters to tentatively update the CWND. This seeks to avoid starving other flows that could have either started or increased their use of capacity since observing the capacity of a path.
このセクションでは、保存された CC パラメータを使用して CWND を暫定的に更新する場合の安全性を検討します。これは、パスの容量を観察してから容量の使用を開始または増加させた可能性がある他のフローが枯渇するのを避けることを目的としています。
To avoid inducing significant congestion to any connections that have started to use a shared bottleneck, a sender must not directly use the previous saved_cwnd to directly initialise a new flow causing it to resume sending at the same rate. The jump_cwnd is therefore limited to half the previously saved_cwnd.
共有ボトルネックの使用を開始した接続に重大な輻輳が引き起こされるのを避けるために、送信者は以前の Saved_cwnd を直接使用して新しいフローを直接初期化し、同じレートでの送信を再開してはなりません。したがって、jump_cwnd は以前に保存された_cwnd の半分に制限されます。
The long-term use of the previously observed parameters is not appropriate; a Lifetime defines the duration during which a set of saved CC parameters can be safely reused. The maximum Lifetime is a configurable parameter for a sender. An implementation also needs to provide a method to flush the set of saved CC parameters following a configuration change.
以前に観察されたパラメータを長期間使用することは適切ではありません。ライフタイムは、保存された CC パラメータのセットを安全に再利用できる期間を定義します。最大ライフタイムは、送信者の構成可能なパラメータです。実装では、設定変更後に保存された CC パラメータのセットをフラッシュするメソッドも提供する必要があります。
[RFC9040] provides guidance on the implementation of TCP Control Block Interdependence, but it does not specify how long a saved parameter can safely be reused. [RFC7661] specifies a method for managing an unvalidated CWND. It states:
[RFC9040] は、TCP 制御ブロックの相互依存性の実装に関するガイダンスを提供していますが、保存されたパラメータを安全に再利用できる期間については規定していません。[RFC7661] は、検証されていない CWND を管理する方法を指定しています。それは次のように述べています：
After a fixed period of time (the non-validated period (NVP)), the sender adjusts the CWND (Section 4.4.3). The NVP SHOULD NOT exceed five minutes.
一定期間 (非検証期間 (NVP)) が経過すると、送信者は CWND を調整します (セクション 4.4.3)。NVP は 5 分を超えてはなりません。
Section 5 of [RFC7661] discusses the rationale for choosing that period. However, [RFC7661] targets rate-limited connections using normal CC. Careful Resume includes additional mechanisms to avoid and mitigate the effects of overshoot, and therefore a longer period can be justified when using a saved_cwnd with Careful Resume.
[RFC7661] のセクション 5 では、その期間を選択した根拠について説明しています。ただし、[RFC7661] は通常の CC を使用したレート制限された接続を対象としています。Careful Resume には、オーバーシュートの影響を回避および軽減するための追加メカニズムが含まれているため、Careful Resume で Saved_cwnd を使用する場合は、より長い期間を正当化できます。
When the path characteristics are known to be dynamic, or the path varies, a small Lifetime is desirable (e.g., measured in minutes). For stable paths, and where the sender does not expect the path to be shared by many senders, a longer Lifetime (e.g., measured in hours) could be used. A bottleneck that is shared by a large number of senders brings greater risk that Careful Resume connections could contribute congestion that leads to prolonged overload with starvation. This can be mitigated by setting a small Lifetime.
パス特性が動的であることがわかっている場合、またはパスが変化する場合、短いライフタイムが望ましい（たとえば、分単位で測定される）。安定したパスの場合、および送信者がパスが多くの送信者によって共有されることを予期していない場合は、より長いライフタイム（たとえば、時間単位で測定）を使用できます。多数の送信者によって共有されるボトルネックは、Careful Resume 接続が輻輳を引き起こし、飢餓による長期にわたる過負荷につながる可能性があるという大きなリスクをもたらします。これは、ライフタイムを小さく設定することで軽減できます。
A sender needs to avoid any step increase in the CWND resulting in a burst of packets that is greater than the size of the CC algorithm's IW. This is consistent with [RFC8085] and [RFC9000].
A sender needs to avoid any step increase in the CWND resulting in a burst of packets that is greater than the size of the CC algorithm's IW.これは [RFC8085] および [RFC9000] と一致しています。
Pacing packets as a function of the current RTT, rather than the saved_rtt, provides additional safety during the Unvalidated Phase, because it avoids a smaller saved_rtt inflating the sending rate. The lower bound to the minimum acceptable current RTT avoids sending unvalidated packets at a rate that would be higher than was previously observed.
Saved_rtt ではなく現在の RTT の関数としてパケットをペーシングすると、送信レートが上昇するより小さな Saved_rtt が回避されるため、未検証フェーズ中の安全性がさらに高まります。現在の最小許容 RTT の下限により、以前に観察された速度よりも高い速度で未検証のパケットが送信されることが回避されます。
The following example provides a relevant pacing rhythm: An Inter-packet Transmission Time (ITT) is determined by using the current Maximum Packet Size (MPS), including headers, the saved_cwnd, and the current RTT. A safety margin can be configured to avoid sending more than a maximum (max_jump):
次の例は、関連するペーシング リズムを示しています。 パケット間送信時間 (ITT) は、ヘッダー、saved_cwnd、および現在の RTT を含む現在の最大パケット サイズ (MPS) を使用して決定されます。安全マージンを設定して、最大値 (max_jump) を超える送信を避けることができます。
jump_cwnd = Min(max_jump,saved_cwnd/2)
ITT = (current RTT x MPS)/jump_cwnd
This follows the idea presented in [RFC4782], [INIT-SPREADING], and [CONEXT15]. Other sender mitigations have also been suggested to avoid line-rate bursts (e.g., [TCP-SSR]).
これは、[RFC4782]、[INIT-SPREADING]、および [CONEXT15] で提示されているアイデアに従います。ラインレート バーストを回避するために、他の送信側の緩和策も提案されています ([TCP-SSR] など)。
* Careful Resume has been designed to be robust to changes in network conditions due to variations in the forwarding path (see Section 1.5), such as reconfiguration of equipment or changes in the link conditions. This is mitigated by path confirmation.
* Careful Resume は、機器の再構成やリンク状態の変化など、転送パス (セクション 1.5 を参照) の変動によるネットワーク状態の変化に対して堅牢になるように設計されています。これはパス確認によって軽減されます。
* Careful Resume has been designed to be robust to changes in network traffic, including the arrival of new flows that compete for capacity at a shared bottleneck. This is mitigated by jumping to no more than a half of the saved_cwnd and by pacing.
* Careful Resume は、共有ボトルネックでの容量を競合する新しいフローの到着など、ネットワーク トラフィックの変化に対して堅牢になるように設計されています。これは、saved_cwnd の半分以下にジャンプし、ペーシングすることで軽減されます。
* Careful Resume has been designed to avoid unduly suppressing flows that have used the capacity since the capacity was observed. This is further mitigated by bounding the duration of the Unvalidated Phase and the following Validating Phase, and the conservative design of the Safe Retreat Phase.
* Careful Resume は、容量が観察されてからその容量を使用したフローを不当に抑制しないように設計されています。これは、未検証フェーズとそれに続く検証フェーズの期間を制限し、安全な撤退フェーズの保守的な設計を行うことでさらに軽減されます。
The purpose of the Validating Phase is to trigger an entry to the Safe Retreat Phase if the capacity is not validated.
検証フェーズの目的は、容量が検証されなかった場合に安全な退却フェーズへの移行をトリガーすることです。
When the sender completes the Unvalidated Phase, either by sending a jump_cwnd of data or after one RTT or an acknowledgment for an unvalidated packet, it ceases to use the unvalidated CWND.
送信者がデータのjump_cwndを送信することによって、または1つのRTTまたは未検証のパケットに対する確認応答の後に未検証フェーズを完了すると、未検証のCWNDの使用を停止します。
If the flight_size was less than or equal to the PipeSize, the sender resets the CWND to the PipeSize and stops using Careful Resume. Otherwise, if the CWND is larger than the flight_size, the CWND is reset to the flight_size. The sender then awaits reception of ACKs to validate the use of this capacity.
Flight_size が PipeSize 以下の場合、送信者は CWND を PipeSize にリセットし、Careful Resume の使用を停止します。それ以外の場合、CWND が Flight_size より大きい場合、CWND は Flight_size にリセットされます。次に、送信者は ACK の受信を待って、この容量の使用を検証します。
New packets are sent when previously sent data is newly acknowledged. The CWND is increased during the Validating Phase, based on received ACKs. This allows new data to be sent, but this does not have any final impact on the CWND if congestion is subsequently detected.
以前に送信されたデータが新たに確認されると、新しいパケットが送信されます。CWND は、受信した ACK に基づいて、検証フェーズ中に増加します。これにより、新しいデータの送信が可能になりますが、その後輻輳が検出された場合、CWND に最終的な影響はありません。
This section considers the safety after congestion has been detected for unvalidated packets.
このセクションでは、未検証パケットの輻輳が検出された後の安全性を検討します。
The Safe Retreat Phase sets a safe CWND value to drain any unvalidated packets from the path after a packet loss has been detected or when ACKs that indicate the sent packets were marked as ECN-CE. The CC parameters that were used are invalid and are removed.
安全な退避フェーズでは、パケット損失が検出された後、または送信されたパケットが ECN-CE としてマークされたことを示す ACK が検出された後、パスから未検証のパケットを排出するための安全な CWND 値を設定します。使用された CC パラメータは無効であるため、削除されました。
The Safe Retreat reaction differs from a traditional reaction to detected congestion, because a jump_cwnd can result in a significantly higher rate than would be allowed by Slow Start. Such a jump could aggressively feed a congested bottleneck, resulting in overshoot where a disproportionate number of packets from existing flows are displaced from the buffer at the congested bottleneck. For this reason, a sender in the Safe Retreat Phase needs to react to detected congestion by reducing the CWND significantly below the saved_cwnd.
Safe Retreat の反応は、jump_cwnd の速度がスロー スタートで許容される速度よりも大幅に高くなる可能性があるため、検出された輻輳に対する従来の反応とは異なります。このようなジャンプは、混雑したボトルネックに積極的に供給する可能性があり、その結果、既存のフローからの不釣り合いな数のパケットが混雑したボトルネックのバッファから追い出されるオーバーシュートが発生する可能性があります。このため、安全な退避フェーズにある送信者は、CWND を Saved_cwnd よりも大幅に小さくすることで、検出された輻輳に対応する必要があります。
During loss recovery, a receiver can cumulatively acknowledge data that was previously sent in the Unvalidated Phase in addition to acknowledging the successful retransmission of data. [RFC3465] describes how to appropriately account for such ACKs. The sender tracks received ACKs that acknowledge the reception of the unvalidated packets to measure the maximum available capacity, called the "PipeSize". (The first unvalidated packet can be determined by recording the sequence number of the first packet sent in the Unvalidated Phase.) This calculated PipeSize is later used to reset the ssthresh. However, note that this is not a safe measure of the currently available share of the capacity whenever there was also a significant overshoot at the bottleneck, and it must not be used to reinitialise the CWND.
損失回復中、受信機は、データの再送信が成功したことを確認することに加えて、未検証フェーズで以前に送信されたデータを累積的に確認することができます。[RFC3465] は、そのような ACK を適切に説明する方法を説明しています。送信者は、未検証パケットの受信を確認する受信 ACK を追跡し、「PipeSize」と呼ばれる最大利用可能容量を測定します。(最初の未検証パケットは、未検証フェーズで送信された最初のパケットのシーケンス番号を記録することで特定できます。)この計算された PipeSize は、後で ssthresh をリセットするために使用されます。ただし、ボトルネックで大幅なオーバーシュートがあった場合、これは現在利用可能な容量のシェアを示す安全な尺度ではないことに注意してください。また、CWND を再初期化するために使用してはなりません。
Proportional Rate Reduction (PRR) [RFC9937] assumes that it is safe to reduce the rate gradually when in congestion avoidance. PRR is therefore not appropriate when there might be significant overshoot in the use of the capacity, which can be the case when the Safe Retreat Phase is entered.
Proportional Rate Reduction (PRR) [RFC9937] では、輻輳回避時にレートを徐々に下げても安全であると想定しています。したがって、PRR は、安全な退却フェーズに入った場合など、容量の使用に重大なオーバーシュートが発生する可能性がある場合には適切ではありません。
The recovery from loss depends on the design of a transport protocol. A TCP or SCTP sender is required to retransmit all lost data [RFC5681]. For some transports (e.g., QUIC and DCCP), the need for loss recovery depends on the sender policy for retransmission. On entry to the Safe Retreat Phase, the CWND can be significantly reduced. When there were multiple losses, a sender recovering all lost data could then take multiple RTTs to complete.
損失からの回復は、トランスポート プロトコルの設計によって異なります。TCP または SCTP の送信者は、失われたデータをすべて再送信する必要があります [RFC5681]。一部のトランスポート (QUIC や DCCP など) では、損失回復の必要性は再送信の送信側ポリシーによって異なります。安全退却フェーズに入ると、CWND は大幅に減少する可能性があります。複数の損失があった場合、送信者が失われたデータをすべて回復するのに完了するまでに複数の RTT がかかる可能性があります。
After using Careful Resume, the CC controller returns to using normal CC.
Careful Resume を使用した後、CC コントローラーは通常の CC の使用に戻ります。
The CWND at entry to the phase will have been increased when a sender has passed through the Unvalidated Phase, unless the sender was rate limited, which causes the CWND to be reset based on the used capacity. The CWND is not reduced below the IW, unless congestion was detected. However, note that in some cases the value of the CWND could be significantly lower than the jump_cwnd (e.g., when a sender did not utilise the entire CWND in the Unvalidated Phase). The implementation details for different CC algorithms depend on the design of the algorithm.
送信者がレート制限されている場合を除き、送信者が未検証フェーズを通過すると、フェーズ開始時の CWND が増加します。これにより、使用容量に基づいて CWND がリセットされます。輻輳が検出されない限り、CWND は IW を下回ることはありません。ただし、場合によっては、CWND の値が Jump_cwnd よりも大幅に低くなる可能性があることに注意してください (たとえば、送信者が未検証フェーズで CWND 全体を利用しなかった場合)。さまざまな CC アルゴリズムの実装の詳細は、アルゴリズムの設計によって異なります。
Once a sender is no longer using Careful Resume, the sender is permitted to start observing the capacity of the path.
送信者が Careful Resume を使用しなくなると、送信者はパスの容量の監視を開始できるようになります。
The CWND is one factor that limits the sending rate of the sender. Other mechanisms can also constrain the maximum sending rate of a transport protocol. A transport protocol might need to update these mechanisms to fully utilise the CWND made available by Careful Resume:
CWND は、送信側の送信速度を制限する 1 つの要因です。他のメカニズムも、トランスポート プロトコルの最大送信速度を制限する可能性があります。Careful Resume で利用できる CWND を最大限に活用するには、トランスポート プロトコルでこれらのメカニズムを更新する必要がある場合があります。
* A TCP sender is limited by the receiver window (rwnd). Unless configured at a receiver, the rwnd constrains the rate of increase for a connection and reduces the benefit of Careful Resume.
* TCP 送信者は受信者ウィンドウ (rwnd) によって制限されます。受信側で設定しない限り、rwnd は接続の増加率を制限し、慎重な再開の利点を減らします。
* QUIC includes flow control mechanisms and mechanisms to prevent amplification attacks. In particular, a QUIC receiver might need to issue proactive MAX_DATA frames to increase the flow control limits of a connection that is started when using Careful Resume to gain the expected benefit.
* QUIC には、フロー制御メカニズムと増幅攻撃を防止するメカニズムが含まれています。特に、QUIC 受信機は、予期される利点を得るために、Careful Resume を使用するときに開始される接続のフロー制御制限を増やすために、プロアクティブな MAX_DATA フレームを発行する必要がある場合があります。
This section provides some operational considerations for network providers. As noted above, using CC parameters that were observed during a previous connection is inherently a tradeoff between the potential performance gains for the new connection and the risks of degraded performance for other connections that share a common bottleneck. A transport endpoint often has no visibility of changes in the level of network traffic, nor the forwarding path over which the transport path is supported. Careful Resume is therefore a sender-side transport change that has been designed so that any potential "harm" to other flows is constrained. It seeks to detect whether the transport path has changed since the observation of that capacity. Importantly, whenever a sender detects that assumptions about the capacity are not valid, the sender safely responds to reduce the impact on other flows (see Section 1.5).
このセクションでは、ネットワーク プロバイダーの運用上の考慮事項をいくつか説明します。上で述べたように、以前の接続中に観察された CC パラメーターを使用することは、本質的に、新しい接続の潜在的なパフォーマンス向上と、共通のボトルネックを共有する他の接続のパフォーマンス低下のリスクとの間のトレードオフになります。トランスポート エンドポイントでは、ネットワーク トラフィックのレベルの変化や、トランスポート パスがサポートされている転送パスを認識できないことがよくあります。したがって、慎重な再開は、他のフローに対する潜在的な「害」が抑制されるように設計された送信者側のトランスポートの変更です。輸送経路がその容量の観察以降に変更されたかどうかを検出しようとします。重要なのは、容量に関する仮定が有効ではないことを送信者が検出したときはいつでも、送信者は他のフローへの影響を軽減するために安全に応答するということです (セクション 1.5 を参照)。
There are three ways that the use of Careful Resume can be constrained:
Careful Resume の使用を制限するには、次の 3 つの方法があります。
* The maximum configured jump window (max_jump) (see Section 3.3),
* 設定された最大ジャンプ ウィンドウ (max_jump) (セクション 3.3 を参照)、
* The Remote Endpoint identifying the client and the server that are permitted to use a specific set of saved CC parameters (see Section 2.2),
* 保存された CC パラメーターの特定のセットの使用を許可されているクライアントとサーバーを識別するリモート エンドポイント (セクション 2.2 を参照)、
* The configured Lifetime for a set of saved CC parameters (see Section 4.3.1).
* 保存された CC パラメータのセットに対して設定されたライフタイム (セクション 4.3.1 を参照)。
Network methods such as Equal Cost Multipath Routing, Anycast Routing, and Network Address Translation can result in changes to the forwarding path. The impact of these methods on Careful Resume can be minimised when the network is configured so that the alternative paths are provisioned to support equivalent capacity (i.e., a change to the forwarding path does not introduce a significant reduction in the capacity of the smallest bottleneck on the end-to-end path).
等コスト マルチパス ルーティング、エニーキャスト ルーティング、ネットワーク アドレス変換などのネットワーク方式により、転送パスが変更される場合があります。代替パスが同等の容量をサポートするようにプロビジョニングされるようにネットワークが構成されている場合、これらの方法による慎重な再開への影響を最小限に抑えることができます (つまり、転送パスの変更によって、エンドツーエンド パス上の最小のボトルネックの容量が大幅に減少することはありません)。
For many network paths, the smallest bottleneck is located in the access part of the end-to-end path. As an example, consider a typical client on an access network could connect to a remote server with a capacity bottleneck located in the access part of this path. When the client connects to a server using an anycast destination address, the anycast routing would be configured to distribute connections to a corresponding server. A client would then be unaware of whether different instances of the client's connections (with the same address pair) would terminate at the same or different servers, or at servers located at different "server farms". Hence, if a server is configured to send using Careful Resume, there is an onus to appropriately manage the use of saved CC parameters (see Section 4.2).
多くのネットワーク パスでは、最小のボトルネックはエンドツーエンド パスのアクセス部分にあります。例として、アクセス ネットワーク上の一般的なクライアントが、このパスのアクセス部分に容量のボトルネックがあるリモート サーバーに接続する可能性があると考えてください。クライアントがエニーキャスト宛先アドレスを使用してサーバーに接続すると、対応するサーバーに接続を分散するようにエニーキャスト ルーティングが設定されます。その場合、クライアントは、(同じアドレス ペアを持つ) クライアントの接続の異なるインスタンスが同じサーバーで終了するのか、異なるサーバーで終了するのか、あるいは異なる「サーバー ファーム」にあるサーバーで終了するのかを認識できなくなります。したがって、サーバーが Careful Resume を使用して送信するように設定されている場合、保存された CC パラメータの使用を適切に管理する責任があります (セクション 4.2 を参照)。
The way in which this is realised will depend upon the design choices in configuring the network and the servers. On the one hand, if all the servers responding to a given IP address share the same location (e.g., are in the same data center), then a method could be provided to coordinate their sharing of the CC parameters that are used to send data using Careful Resume. On the other hand, if the service configuration is such that subsequent use of the IP anycast address might result in a very different path to a server (e.g., at a different location where the path would be unable to support the same capacity), a sender should not use Careful Resume based on saved CC parameters.
これを実現する方法は、ネットワークとサーバーを構成する際の設計上の選択によって異なります。一方で、特定の IP アドレスに応答するすべてのサーバーが同じ場所を共有している (たとえば、同じデータセンター内にある) 場合、Careful Resume を使用してデータを送信するために使用される CC パラメーターの共有を調整する方法を提供できます。一方、サービス構成が、その後の IP エニーキャスト アドレスの使用により、サーバーへの非常に異なるパスが生成される可能性がある場合 (たとえば、パスが同じ容量をサポートできない別の場所にある場合)、送信者は、保存された CC パラメータに基づく慎重な再開を使用すべきではありません。
This document has no IANA actions.
この文書には IANA のアクションはありません。
The security considerations are the same as for other sender-based CC methods. Such methods rely on the receiver appropriately acknowledging receipt of data. The ability of an on-path or off-path attacker to influence CC depends upon the security properties of the transport protocol being used.
セキュリティに関する考慮事項は、他の送信者ベースの CC 方式と同じです。このような方法は、受信側がデータの受信を適切に確認することに依存します。パス上またはパス外の攻撃者が CC に影響を与える能力は、使用されているトランスポート プロトコルのセキュリティ特性によって決まります。
[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>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[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>.
[BBR-CC] Cardwell, N., Swett, I., and J. Beshay, "BBR Congestion
Control", Work in Progress, Internet-Draft, draft-ietf-
ccwg-bbr-05, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccwg-
bbr-05>.
[CONEXT15] Li, Q., Dong, M., and P. B. Godfrey, "Halfback: Running
Short Flows Quickly and Safely", CoNEXT '15: Proceedings
of the 11th ACM Conference on Emerging Networking
Experiments and Technologies, DOI 10.1145/2716281.2836107,
2015, <https://doi.org/10.1145/2716281.2836107>.
[CR25] Yanev, M., Custura, A., Secchi, R., and G. Fairhurst,
"Analysis of Careful Resumption of Internet Congestion
Control from Retained Path State", Computer Networks, vol.
276, DOI 10.1016/j.comnet.2025.111950, 2026,
<https://www.sciencedirect.com/science/article/abs/pii/
S1389128625009156>.
[IJSCN] Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google
QUIC performance over a public SATCOM access",
International Journal of Satellite Communications and
Networking, vol. 37, no. 6, pp. 601-611,
DOI 10.1002/sat.1301, 2019,
<https://doi.org/10.1002/sat.1301>.
[INIT-SPREADING]
Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput,
E., and A. Beylot, "Safe increase of the TCP's Initial
Window Using Initial Spreading", Work in Progress,
Internet-Draft, draft-irtf-iccrg-sallantin-initial-
spreading-00, 15 January 2014,
<https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-
sallantin-initial-spreading-00>.
[LOG] Custura, A. and G. Fairhurst, "Quic Logging for
Convergence of Congestion Control from Retained State",
Work in Progress, Internet-Draft, draft-ietf-tsvwg-
careful-resume-qlog-02, 2 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
careful-resume-qlog-02>.
[MAPRG111] Kuhn, N., Stephan, E., Fairhurst, G., Jones, T., and C.
Huitema, "Feedback from using QUIC's 0-RTT-BDP extension
over SATCOM public access", IETF 111 Proceedings, July
2021, <https://www.ietf.org/proceedings/111/slides/slides-
111-maprg-feedback-from-using-quics-0-rtt-bdp-extension-
over-satcom-public-access-00.pdf>.
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte
Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February
2003, <https://www.rfc-editor.org/info/rfc3465>.
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782,
January 2007, <https://www.rfc-editor.org/info/rfc4782>.
[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>.
[RFC5783] Welzl, M. and W. Eddy, "Congestion Control in the RFC
Series", RFC 5783, DOI 10.17487/RFC5783, February 2010,
<https://www.rfc-editor.org/info/rfc5783>.
[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>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013,
<https://www.rfc-editor.org/info/rfc6928>.
[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
TCP to Support Rate-Limited Traffic", RFC 7661,
DOI 10.17487/RFC7661, October 2015,
<https://www.rfc-editor.org/info/rfc7661>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/info/rfc9002>.
[RFC9040] Touch, J., Welzl, M., and S. Islam, "TCP Control Block
Interdependence", RFC 9040, DOI 10.17487/RFC9040, July
2021, <https://www.rfc-editor.org/info/rfc9040>.
[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>.
[RFC9406] Balasubramanian, P., Huang, Y., and M. Olson, "HyStart++:
Modified Slow Start for TCP", RFC 9406,
DOI 10.17487/RFC9406, May 2023,
<https://www.rfc-editor.org/info/rfc9406>.
[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>.
[RFC9937] Mathis, M., Cardwell, N., Cheng, Y., and N. Dukkipati,
"Proportional Rate Reduction (PRR)", RFC 9937,
DOI 10.17487/RFC9937, December 2025,
<https://www.rfc-editor.org/info/rfc9937>.
[TCP-SSR] Hughes, A., Touch, J., and J. Heidemann, "Issues in TCP
Slow-Start Restart After Idle", Work in Progress,
Internet-Draft, draft-hughes-restart-00, December 2001,
<https://datatracker.ietf.org/doc/html/draft-hughes-
restart-00>.
The table below is provided to illustrate the operation of Careful Resume. This table is informative; please refer to the body of the document for the normative specification. The description is based on a normal CC that uses Reno. The PipeSize tracks the validated CWND.
以下の表は、慎重な再開の操作を説明するために提供されています。この表は参考になります。規格仕様については文書の本文を参照してください。Renoを使用した通常のCCに基づいて説明します。PipeSize は、検証された CWND を追跡します。
The phases in Table 1 correspond to Sections 3.2 through 3.5. This table also uses the following abbreviations:
表 1 のフェーズは、セクション 3.2 ～ 3.5 に対応します。この表では次の略語も使用しています。
SS
SS
= Slow Start
= スロースタート
FS
FS
= flight_size
= フライトサイズ
PS
PS
= PipeSize
= パイプサイズ
ACK
確認応答
= highest acknowledged packet
= 最も高い確認応答パケット
CC
CC
= Congestion Control
= 混雑制御
CR
CR
= Careful Resume
= 慎重な履歴書
IW
IW
= Initial congestion Window
= 初期輻輳ウィンドウ
CWND
CWND
= Congestion Window
= 混雑ウィンドウ
+=======+=========+============+============+===========+===========+
|Phase |Normal |Recon. |Unvalidated |Validating |Safe Ret. |
+=======+=========+============+============+===========+===========+
| |Observing|Confirm path|Send faster |Validate |Drain path;|
| |CC params| |using |new CWND; |Update PS |
| | | |saved_cwnd |Update PS | |
+-------+---------+------------+------------+-----------+-----------+
|On | - |CWND=IW |PS=FS |If (FS>PS) |CWND=(PS/2)|
|entry: | | |jump_cwnd |{CWND=FS} | |
| | | |=saved_cwnd |else | |
| | | |/2; CWND |{CWND=PS; | |
| | | |=jump_cwnd |use Normal | |
| | | | |CC} | |
+-------+---------+------------+------------+-----------+-----------+
|CWND: |When in |CWND |CWND is not |CWND can |CWND is not|
| |observe, |increases |increased |increase |increased |
| |measure |using SS | |using | |
| |saved | | |normal CC | |
| |_cwnd | | | | |
+-------+---------+------------+------------+-----------+-----------+
|PS: | - | - |PS+=ACKed |
+-------+---------+------------+------------+-----------+-----------+
|RTT: |Measure |Measure | - | - | - |
| |saved_rtt|current RTT | | | |
+-------+---------+------------+------------+-----------+-----------+
|If loss|Normal CC|Normal CC; |Enter Safe Retreat | - |
|or ECN-| |CR is not | | |
|CE: | |allowed | | |
+-------+---------+------------+------------+-----------+-----------+
|Next |Observing|If (CWND, |If (FS>CWND |If (ACK >= |If (ACK >= |
|Phase: |(as |Lifetime, |or >1 RTT |last |last |
| |needed) |and RTT |has passed |unvalidated|unvalidated|
| | |confirmed), |or ACK >= |packet), |packet), |
| | |enter |first |use Normal |ssthresh = |
| | |Unvalidated;|unvalidated |CC |PS x Beta; |
| | |else |packet), If | |and use |
| | |CWND=Max |((FS>CWND) | |Normal CC |
| | |(PS,IW); and|or | | |
| | |use Normal |(FS<=PS)) | | |
| | |CC |cwnd=PS; | | |
| | | |and use | | |
| | | |Normal CC | | |
| | | |else | | |
| | | |cwnd=FS; | | |
| | | |enter | | |
| | | |Validating | | |
+-------+---------+------------+------------+-----------+-----------+
Table 1: Illustration of the Operation of Careful Resume
表 1: 慎重な履歴書の操作イメージ
The following examples consider an implementation that keeps track of transmitted data in terms of packets and provide informative examples of use.
次の例では、パケットの観点から送信されたデータを追跡する実装を検討し、有益な使用例を示します。
In the Unvalidated Phase, the first unvalidated packet corresponds to the highest sent packet recorded on entry to this phase. In the Validating Phase and Safe Retreat Phase, the sender tracks the last unvalidated packet (this is also the highest sent packet number recorded on entry to this phase). The PipeSize (PS) tracks the validated portion of the CWND. The PS is set to the CWND on entry to the Unvalidated Phase. It is updated after receiving an ACK for each additional packet. The default value of Beta is 0.5.
未検証フェーズでは、最初の未検証パケットは、このフェーズへの入り口で記録された最も高い送信パケットに対応します。検証フェーズと安全な退避フェーズでは、送信者は最後の未検証パケットを追跡します (これは、このフェーズへの入り口で記録された最大の送信パケット番号でもあります)。PipeSize (PS) は、CWND の検証された部分を追跡します。PS は、未検証フェーズへの開始時に CWND に設定されます。追加パケットごとに ACK を受信した後に更新されます。ベータのデフォルト値は 0.5 です。
Note: To simplify the description, these examples are described using packet numbers (whereas QLOG variables are expressed in bytes).
注: 説明を簡単にするために、これらの例はパケット番号を使用して説明されています (QLOG 変数はバイト単位で表されます)。
In the first example of using Careful Resume, the sender starts by sending IW packets, assumed to be 10 packets, in the Reconnaissance Phase, and then continues in a subsequent RTT to send more packets until the sender becomes CWND limited (i.e., flight_size = CWND).
Careful Resume を使用する最初の例では、送信者は偵察フェーズで IW パケット (10 パケットと仮定) を送信することから開始し、その後の RTT で送信者が CWND 制限になる (つまり、flight_size = CWND) までさらに多くのパケットを送信し続けます。
The sender in the Reconnaissance Phase then confirms the RTT and other conditions for using Careful Resume. In this example, this is confirmed when the sender has 29 packets in flight.
次に、偵察フェーズの送信者は、RTT および慎重な再開を使用するためのその他の条件を確認します。この例では、送信者が 29 個のパケットを送信しているときにこれが確認されます。
The sender then enters the Unvalidated Phase. (This path confirmation could have happened earlier if data had been available to send.) The sender initialises the PipeSize to the flight_size (in this case, 29 packets) and then sets the CWND to 150 packets (based upon half of the previously observed saved_cwnd of 300 packets).
その後、送信者は未検証フェーズに入ります。(データが送信可能であれば、このパス確認はもっと早くに行われた可能性があります。) 送信者は PipeSize を Flight_size (この場合は 29 パケット) に初期化し、次に CWND を 150 パケット (以前に観察された 300 パケットの save_cwnd の半分に基づいて) に設定します。
The sender now sends 121 unvalidated packets (the unused portion of the current CWND). Each time a packet is sent, the sender checks whether 1 RTT has passed since entering the Unvalidated Phase (otherwise, the Validating Phase is entered). This check triggers only for cases where the sender is rate limited, as shown in the following example: The PipeSize increases after each ACK is received.
送信者は 121 個の未検証パケット (現在の CWND の未使用部分) を送信します。パケットが送信されるたびに、送信者は、未検証フェーズに入ってから 1 RTT が経過したかどうかを確認します (そうでない場合は、検証フェーズに入ります)。このチェックは、次の例に示すように、送信側がレート制限されている場合にのみトリガーされます。 PipeSize は、ACK を受信するたびに増加します。
When the first unvalidated packet is acknowledged (packet number 30), the sender enters the Validating Phase. (This transition would also occur if the flight_size increased to equal the CWND.) During this phase, the CWND can be increased for each ACK that acknowledges an unvalidated packet, because this indicates that the packet was validated.
最初の未検証パケットが確認応答されると (パケット番号 30)、送信者は検証フェーズに入ります。(この遷移は、flight_size が CWND と等しくなるまで増加した場合にも発生します。) この段階では、パケットが検証されたことを示すため、未検証のパケットを確認する ACK ごとに CWND を増やすことができます。
When an ACK is received that acknowledges the last packet that was sent in the Unvalidated Phase, the sender stops using Careful Resume. For example, if the CWND is less than ssthresh, a Reno or CUBIC sender using normal CC is permitted to use Slow Start to grow the CWND towards the ssthresh and will then enter congestion avoidance.
未検証フェーズで送信された最後のパケットを確認する ACK を受信すると、送信者は Careful Resume の使用を停止します。たとえば、CWND が ssthresh 未満の場合、通常の CC を使用する Reno または CUBIC 送信側は、スロー スタートを使用して CWND を ssthresh に向かって拡大し、輻輳回避に入ります。
A rate-limited sender will not fully utilise the available CWND when using Careful Resume, and the CWND is therefore reset on entry to the Validating Phase, as described below.
レート制限のある送信者は、慎重な再開を使用する場合、利用可能な CWND を十分に活用しないため、以下で説明するように、検証フェーズに入るときに CWND がリセットされます。
The sender starts by sending up to IW packets (10) in the Reconnaissance Phase. It commences as described in the first example, transitioning to the Unvalidated Phase, where the CWND is set to 150 packets, and the PipeSize is set to the flight_size (i.e., 29 packets).
送信者は、偵察フェーズで最大 IW パケット (10) を送信することから始めます。最初の例で説明したように開始され、未検証フェーズに移行します。そこで CWND は 150 パケットに設定され、PipeSize は Flight_size (つまり、29 パケット) に設定されます。
The sender then becomes rate limited, because the example only sends 50 unvalidated packets.
この例では未検証のパケットが 50 個しか送信されないため、送信側はレートが制限されます。
After about one RTT (e.g., by comparing the current time with local timestamps for each sent packet or by receiving an ACK for the first unvalidated packet), the sender will still not have fully used the CWND. It then enters the Validating Phase and resets the CWND to the current flight_size (i.e., 50 packets). During this phase, the CWND can be increased for each received ACK that validates reception of an unvalidated packet. The PipeSize also increases with each ACK received, to reflect the discovered capacity.
約 1 RTT 後 (たとえば、送信された各パケットのローカル タイムスタンプと現在時刻を比較することによって、または最初の未検証パケットの ACK を受信することによって)、送信者はまだ CWND を完全には使用していません。次に、検証フェーズに入り、CWND を現在の Flight_size (つまり、50 パケット) にリセットします。このフェーズでは、未検証のパケットの受信を検証する ACK を受信するたびに CWND を増やすことができます。PipeSize も、検出された容量を反映するために、ACK を受信するたびに増加します。
The sender completes using Careful Resume when a received ACK acknowledges the last packet that was sent in the Unvalidated Phase. It then stops using Careful Resume, as in the example with no loss.
受信した ACK が未検証フェーズで送信された最後のパケットを確認すると、送信者は Careful Resume の使用を完了します。その後、損失のない例のように、Careful Resume の使用を停止します。
When a sender detects that a packet was lost in the Reconnaissance Phase, it will stop using Careful Resume and recover the loss using the normal loss recovery algorithm and normal CC. It is considered that the sender may have discovered a capacity limit and it is not allowed to continue to use Careful Resume. In this case, there is no change to the CC algorithm and the CWND is the same as if Careful Resume had not been attempted.
送信者は、偵察フェーズでパケットが失われたことを検出すると、慎重な再開の使用を停止し、通常の損失回復アルゴリズムと通常の CC を使用して損失を回復します。送信者が容量制限を発見した可能性があるため、慎重履歴書の使用を継続することはできません。この場合、CC アルゴリズムに変更はなく、CWND は慎重な再開が試行されなかった場合と同じになります。
As in the first example, the sender enters the Unvalidated Phase with a CWND of 150 packets and with the PipeSize initialised to the flight_size (i.e., 29 packets).
最初の例と同様に、送信者は 150 パケットの CWND と、flight_size (つまり 29 パケット) に初期化された PipeSize で未検証フェーズに入ります。
The sender now sends 121 unvalidated packets (consuming the remaining unused CWND). This example considers the case when one of the unvalidated packets is lost. We assume in the example that the lost packet is 64 (the 35th packet sent in the Unvalidated Phase).
送信者は 121 個の未検証パケットを送信します (残りの未使用の CWND を消費します)。この例では、未検証のパケットの 1 つが失われた場合を考慮します。この例では、失われたパケットが 64 (未検証フェーズで送信された 35 番目のパケット) であると仮定します。
The received ACKs acknowledge the reception of the first 34 unvalidated packets. The PipeSize at this time is equal to 63 (29 + 34) packets.
受信した ACK は、最初の 34 個の未検証パケットの受信を確認します。この時点の PipeSize は 63 (29 + 34) パケットに相当します。
A loss is then detected (by a timer or by receiving three ACKs that do not acknowledge packet number 35). The sender then enters the Safe Retreat Phase because the CWND was not validated. Assuming that the IW was 10 packets, the CWND is reset to Max(10,PS/2) = Max(10,63/2) = 31 packets. This CWND is used during the Safe Retreat Phase, because congestion was detected and the sender still does not yet know if the remaining unvalidated packets will be successfully acknowledged. This conservative CWND calculation ensures the sender drains the path after this potentially severe congestion event. There is no further increase in the CWND in this phase.
その後、損失が検出されます (タイマーまたはパケット番号 35 を確認しない 3 つの ACK を受信することによって)。CWND が検証されなかったため、送信者は安全な退却フェーズに入ります。IW が 10 パケットであると仮定すると、CWND は Max(10,PS/2) = Max(10,63/2) = 31 パケットにリセットされます。この CWND は、安全な退避フェーズ中に使用されます。これは、輻輳が検出され、残りの未検証パケットが正常に確認応答されるかどうかが送信者にまだ分からないためです。この保守的な CWND 計算により、この潜在的に重大な輻輳イベントの後に送信者がパスを排出することが保証されます。このフェーズでは、CWND がそれ以上増加することはありません。
The sender continues to receive ACKs that acknowledge the remaining 86 (121-35) unvalidated packets. Recall that the 35th unvalidated packet was lost and had packet number 64 (29+35). The PipeSize tracks the capacity discovered by ACKs that acknowledge the unvalidated packets (i.e., the PipeSize is increased for each received ACK that acknowledges new data). Although this PipeSize cannot be used to safely initialise the CWND (because it was measured when the sender had aggressively created overload), the estimated PipeSize (which, in this case, is 121-1 = 120 packets) can be used to set the ssthresh on exit from Safe Retreat, since it does indicate a measured upper limit to the current capacity.
送信者は、残りの 86 (121 ～ 35) 個の未検証パケットを確認する ACK を受信し続けます。35 番目の未検証のパケットが失われ、パケット番号 64 (29+35) が付いていたことを思い出してください。PipeSize は、未検証のパケットを確認する ACK によって検出された容量を追跡します (つまり、PipeSize は、新しいデータを確認する ACK を受信するたびに増加します)。この PipeSize は、CWND を安全に初期化するために使用することはできませんが (送信者が積極的にオーバーロードを作成したときに測定されたため)、推定された PipeSize (この場合、121-1 = 120 パケット) は、現在の容量に対する測定された上限を示すため、安全なリトリートからの終了時に ssthresh を設定するために使用できます。
At the point where all the unvalidated packets that were sent in the Unvalidated Phase have been either acknowledged or have been declared lost, the sender updates the ssthresh to be no larger than the recently measured PipeSize multiplied by Beta (the final action of the Safe Retreat Phase), and the sender stops using Careful Resume. Because the CWND will now be less than ssthresh, a sender using normal CC is permitted to use Slow Start to grow the CWND towards the ssthresh, after which it will enter congestion avoidance.
未検証フェーズで送信されたすべての未検証パケットが確認応答されるか、失われたと宣言された時点で、送信者は、最近測定された PipeSize にベータを乗算した値以下になるように ssthresh を更新し (安全な退避フェーズの最後のアクション)、送信者は慎重な再開の使用を停止します。CWND が ssthresh 未満になるため、通常の CC を使用する送信者は、スロー スタートを使用して CWND を ssthresh に向かって拡大することが許可され、その後、輻輳回避に入ります。
Bottleneck Bandwidth and Round-trip propagation time (BBR) uses recent measurements of a transport connection's delivery rate, Round Trip Time (RTT), and packet loss rate to build an explicit model of the network path. BBR then uses this model to control both how fast it sends data and the maximum volume of data it allows in flight in the network at any time [BBR-CC].
ボトルネック帯域幅と往復伝播時間 (BBR) は、トランスポート接続の配信速度、往復時間 (RTT)、およびパケット損失率の最近の測定値を使用して、ネットワーク パスの明示的なモデルを構築します。次に、BBR はこのモデルを使用して、データの送信速度とネットワーク内での送信を許可するデータの最大量の両方をいつでも制御します [BBR-CC]。
When the flow is controlled using BBR Appendix C, Careful Resume is implemented by setting the pacing rate from the saved CC parameters, with the following precautions:
BBR 付録 C を使用してフローが制御されている場合、次の注意事項に従って、保存された CC パラメータからペーシング レートを設定することによって慎重な再開が実装されます。
* The flag "carefully-resuming" is added to the BBR state to indicate that the sender is allowed to send unvalidated packets. This is initialised to False when a BBR flow starts.
* 「慎重に再開」フラグが BBR 状態に追加され、送信者が未検証のパケットの送信を許可されていることを示します。これは、BBR フローの開始時に False に初期化されます。
* Prerequisites for using Careful Resume are described in Section 3.2.
* Careful Resume を使用するための前提条件については、セクション 3.2 で説明されています。
Careful Resume is allowed to transmit unvalidated packets only when the BBR flow is in the Startup state.
Careful Resume は、BBR フローが Startup 状態にある場合にのみ、未検証のパケットを送信できます。
The probing rate is configured to 1/2 of the bottleneck bandwidth, derived from the CWND calculation specified in the saved CC parameters according to the requirements in Section 3.3.
プロービング レートは、セクション 3.3 の要件に従って、保存された CC パラメータで指定された CWND 計算から導出されたボトルネック帯域幅の 1/2 に設定されます。
The sender starts the Unvalidated Phase at the beginning of a BBR round, and sets the "carefully-resuming" flags to True. When this "carefully-resuming" flag is set, the BBR congestion controller sets the BBR pacing rate to the larger of the nominal pacing rate (BBR.bw multiplied bytes BBRStartupPacingGain) or the calculated probing rate. Then, the CWND is set to the larger of BBR.bw and the probing rate, multiplied by BBR.rtt_min times BBRStartupCwndGain.
送信者は、BBR ラウンドの開始時に未検証フェーズを開始し、「慎重に再開」フラグを True に設定します。この「慎重に再開」フラグが設定されている場合、BBR 輻輳コントローラは、BBR ペーシング レートを公称ペーシング レート (BBR.bw 乗算バイト BBRStartupPacingGain) または計算されたプローブ レートの大きい方に設定します。次に、CWND は、BBR.bw とプローブ レートの大きい方に、BBR.rtt_min と BBRStartupCwndGain を掛けた値に設定されます。
The "carefully-resuming" flag is reset to False two rounds after it is set (i.e., after all the packets sent in the first round of "carefully resuming" have been received and acknowledged by the peer). At that stage (after the capacity has been validated), the measured delivery rate is expected to reflect the probing rate.
「慎重に再開」フラグは、設定されてから 2 ラウンド後 (つまり、「慎重に再開」の最初のラウンドで送信されたすべてのパケットが受信され、ピアによって確認応答された後)、False にリセットされます。その段階 (容量が検証された後) では、測定された配信速度はプローブ速度を反映すると予想されます。
If congestion is detected while the "carefully-resuming" flag is True, BBR exits the Startup state and enters the Drain state (implementing the Safe Retreat Phase).
「慎重に再開」フラグが True のときに輻輳が検出された場合、BBR はスタートアップ ステートを終了し、ドレイン ステートに入ります (安全な退避フェーズを実装します)。
When using BBR, the Validation Phase is realised using the BBR rules for exiting Startup. Upon exiting Startup, the connection estimates that the measured delivery rate will reflect the flow's share of the actual bottleneck bandwidth. If congestion is detected while using Careful Resume (i.e, the "carefully-resuming" flag is True), BBR then exits the Startup state and enters the Drain state.
BBR を使用する場合、検証フェーズは、スタートアップを終了するための BBR ルールを使用して実現されます。起動を終了すると、接続は、測定された配信レートが実際のボトルネック帯域幅のフローのシェアを反映すると推定します。Careful Resume の使用中に輻輳が検出された場合 (つまり、「careful-resuming」フラグが True)、BBR は Startup 状態を終了し、Drain 状態に入ります。
When using BBR, the Safe Retreat Phase is entered if the Drain state is entered while the "carefully-resuming" flag (see Appendix C) is still True (i.e., if less than 2 full rounds have elapsed after the sender entered the Unvalidated Phase). The delivery rates measured in these conditions are tainted, because packets sent during the attempt are still queued at the bottleneck buffer and could have "pushed out" packets belonging to any competing flows. Therefore, any delivery rates measured in the Drain state MUST be discarded if the "carefully-resuming" flag is set to True. This flag is cleared upon exiting the Drain state.
BBR を使用する場合、「慎重に再開」フラグ (付録 C を参照) がまだ True の間にドレイン状態に入った場合 (つまり、送信者が未検証フェーズに入ってから 2 ラウンド未満しか経過していない場合)、安全な退却フェーズに入ります。これらの条件で測定された配信レートは、試行中に送信されたパケットが依然としてボトルネック バッファでキューに入れられており、競合するフローに属するパケットを「押し出した」可能性があるため、汚染されています。したがって、「慎重に再開」フラグが True に設定されている場合、ドレイン状態で測定された配信レートはすべて破棄されなければなりません (MUST)。このフラグは、ドレイン状態が終了するとクリアされます。
The authors would like to thank John Border, Gabriel Montenegro, Patrick McManus, Ian Swett, Igor Lubashev, Robin Marx, Roland Bless, Franklin Simo, Kazuho Oku, Tong, Ana Custura, Neal Cardwell, Marten Seemann, Matthias Hofstaetter, Nicolai Fischer, Yi Huang, Mihail Yanev, and Joerg Deutschmann for their fruitful comments in developing this specification. They also thank Mike Bishop for his careful suggestions on the structure to describe the phases. Thanks also to Mohamed Boucadair and to Dan Harkins for his secdir review.
著者らは、John Border、Gabriel Montenegro、Patrick McManus、Ian Swett、Igor Lubashev、Robin Marx、Roland Bless、Franklin Simo、Kazuho Oku、Tong、Ana Custura、Neal Cardwell、Marten Seemann、Matthias Hofstaetter、Nicolai Fischer、Yi Huang、Mihail Yanev、Joerg Deutschmann に感謝します。この仕様の開発における有益なコメント。また、フェーズを説明するための構造について注意深く提案してくれた Mike Bishop にも感謝しています。Mohamed Boucadair と、secdir レビューを書いてくれた Dan Harkins にも感謝します。
The authors would like to thank Tom Jones for co-authoring previous draft versions of this document.
著者らは、このドキュメントの以前の草稿バージョンを共同執筆してくださった Tom Jones に感謝の意を表します。
Nicolas Kuhn
Thales Alenia Space
Email: nicolas.kuhn.ietf@gmail.com
Emile Stephan
Orange
Email: emile.stephan@orange.com
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Email: gorry@erg.abdn.ac.uk
Raffaello Secchi
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Email: r.secchi@abdn.ac.uk
Christian Huitema
Private Octopus Inc.
Email: huitema@huitema.net