[要約] RFC 8511は、TCP Alternative Backoff with ECN（ABE）プロトコルに関するものであり、ECNを使用したTCPのバックオフアルゴリズムの代替手法を提案しています。ABEの目的は、ネットワークの過負荷を回避しながら、TCPのパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) N. Khademi
Request for Comments: 8511 M. Welzl
Category: Experimental University of Oslo
ISSN: 2070-1721 G. Armitage
Netflix
G. Fairhurst
University of Aberdeen
December 2018
TCP Alternative Backoff with ECN (ABE)
ECNによるTCP代替バックオフ（ABE）
Abstract
概要
Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay product (BDP) is large. The reception of a Congestion Experienced (CE) Explicit Congestion Notification (ECN) mark indicates that an AQM mechanism is used at the bottleneck, and the bottleneck network queue is therefore likely to be short. Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss. Therefore, this specification defines an experimental change to the TCP reaction specified in RFC 3168, as permitted by RFC 8311.
アクティブキュー管理（AQM）メカニズムは、短いキューを適用しながらバーストトレランスを可能にし、パケットがボトルネックでキューに入れられる時間を最小限に抑えます。これは、特にフローが少ない場合、またはそれらの帯域幅遅延積（BDP）が大きい場合に、このようなボトルネックを通過するTCP接続のパフォーマンスが著しく低下する可能性があります。 Congestion Experienced（CE）Explicit Congestion Notification（ECN）マークを受信すると、ボトルネックでAQMメカニズムが使用されているため、ボトルネックネットワークキューが短い可能性があります。この信号のフィードバックにより、輻輳回避におけるTCP送信側のECN反応が、推測されたパケット損失に対する輻輳制御アルゴリズムの反応よりも少ない量で輻輳ウィンドウ（cwnd）を減らすことができます。したがって、この仕様では、RFC 8311で許可されているように、RFC 3168で指定されているTCP反応に対する実験的な変更が定義されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc8511.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8511で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Choice of ABE Multiplier . . . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Rationale for Using ECN to Vary the Degree of Backoff . . 6
4.2. An RTT-Based Response to Indicated Congestion . . . . . . 7
5. ABE Deployment Requirements . . . . . . . . . . . . . . . . . 7
6. ABE Experiment Goals . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Explicit Congestion Notification (ECN) [RFC3168] makes it possible for an Active Queue Management (AQM) mechanism to signal the presence of incipient congestion without necessarily incurring packet loss. This lets the network deliver some packets to an application that would have been dropped if the application or transport did not support ECN. This packet loss reduction is the most obvious benefit of ECN, but it is often relatively modest. Other benefits of deploying ECN have been documented in [RFC8087].
明示的輻輳通知（ECN）[RFC3168]は、アクティブキュー管理（AQM）メカニズムが、パケット損失を必ずしも発生させることなく、初期輻輳の存在を通知できるようにします。これにより、アプリケーションまたはトランスポートがECNをサポートしていなかった場合にドロップされるパケットを、ネットワークがアプリケーションに配信できるようになります。このパケット損失の削減は、ECNの最も明白な利点ですが、多くの場合比較的控えめです。 ECNを展開する他の利点は[RFC8087]で文書化されています。
The rules for ECN were originally written to be very conservative, and they required the congestion control algorithms of ECN-Capable Transport (ECT) protocols to treat indications of congestion signalled by ECN exactly the same as they would treat an inferred packet loss [RFC3168]. Research has demonstrated the benefits of reducing network delays that are caused by interaction of loss-based TCP congestion control and excessive buffering [BUFFERBLOAT]. This has led to the creation of AQM mechanisms like Proportional Integral Controller Enhanced (PIE) [RFC8033] and Controlling Queue Delay (CoDel) [RFC8289], which prevent bloated queues that are common with unmanaged and excessively large buffers deployed across the Internet [BUFFERBLOAT].
ECNのルールはもともと非常に保守的であるように書かれており、ECNによって通知された輻輳の兆候を、推定されたパケット損失を扱うのとまったく同じように扱うには、ECN対応トランスポート（ECT）プロトコルの輻輳制御アルゴリズムが必要でした[RFC3168] 。研究により、損失ベースのTCP輻輳制御と過度のバッファリングの相互作用によって引き起こされるネットワーク遅延を削減することの利点が実証されています[BUFFERBLOAT]。これにより、Proportional Integral Controller Enhanced（PIE）[RFC8033]やControlling Queue Delay（CoDel）[RFC8289]などのAQMメカニズムが作成されました。これにより、インターネット全体に展開される管理されていない過度に大きなバッファーに共通する肥大化したキューが防止されます[BUFFERBLOAT ]。
The AQM mechanisms mentioned above aim to keep a sustained queue short while tolerating transient (short-term) packet bursts. However, currently used loss-based congestion control mechanisms are not always able to effectively utilise a bottleneck link where there are short queues. For example, a TCP sender using the Reno congestion control needs to be able to store at least an end-to-end bandwidth-delay product (BDP) worth of data at the bottleneck buffer if it is to maintain full path utilisation in the face of loss-induced reduction of the congestion window (cwnd) [RFC5681]. This amount of buffering effectively doubles the amount of data that can be in flight and the maximum round-trip time (RTT) experienced by the TCP sender.
上記のAQMメカニズムは、一時的な（短期的な）パケットバーストを許容しながら、持続キューを短く保つことを目的としています。ただし、現在使用されている損失ベースの輻輳制御メカニズムは、キューが短い場合にボトルネックリンクを常に効率的に利用できるとは限りません。たとえば、Reno輻輳制御を使用するTCP送信者は、フルパスの使用率を維持するために、ボトルネックバッファーに少なくともエンドツーエンドの帯域幅遅延積（BDP）相当のデータを格納できる必要があります。損失によって引き起こされる輻輳ウィンドウ（cwnd）の減少の原因[RFC5681]。この量のバッファリングにより、処理中のデータ量とTCP送信者が経験する最大ラウンドトリップ時間（RTT）が事実上2倍になります。
Modern AQM mechanisms can use ECN to signal the early signs of impending queue buildup long before a tail-drop queue would be forced to resort to dropping packets. It is therefore appropriate for the transport protocol congestion control algorithm to have a more measured response when it receives an indication with an early warning of congestion after the remote endpoint receives an ECN CE-marked packet. Recognizing these changes in modern AQM practices, the strict requirement that ECN CE signals be treated identically to inferred packet loss has been relaxed [RFC8311]. This document therefore defines a new sender-side-only congestion control response called "ABE" (Alternative Backoff with ECN). ABE improves TCP's average throughput when routers use AQM-controlled buffers that allow only for short queues.
最新のAQMメカニズムは、ECNを使用して、テールドロップキューがパケットのドロップに強制的に強制されるずっと前に、キューの構築が迫っていることの初期の兆候を知らせます。したがって、リモートエンドポイントがECN CEマークの付いたパケットを受信した後、輻輳の早期警告を伴う指示を受信したときに、トランスポートプロトコル輻輳制御アルゴリズムがより測定された応答を持つことが適切です。現代のAQMプラクティスにおけるこれらの変更を認識して、推測されたパケット損失と同じようにECN CE信号を処理するという厳密な要件が緩和されました[RFC8311]。したがって、このドキュメントでは、「ABE」（ECNを使用した代替バックオフ）と呼ばれる新しい送信側のみの輻輳制御応答を定義しています。ルーターが短いキューのみを許可するAQM制御のバッファーを使用する場合、ABEはTCPの平均スループットを向上させます。
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]で説明されているように解釈されます。
This specification changes the congestion control algorithm of an ECN-Capable TCP transport protocol by changing the TCP-sender response to feedback from the TCP receiver that indicates the reception of a CE-marked packet, i.e., receipt of a packet with the ECN-Echo flag (defined in [RFC3168]) set, following the process defined in [RFC8311].
この仕様は、TCP送信者の応答を、CEマークの付いたパケットの受信、つまりECN-Echoによるパケットの受信を示すTCP受信者からのフィードバックに変更することにより、ECN対応TCPトランスポートプロトコルの輻輳制御アルゴリズムを変更します。フラグ（[RFC3168]で定義）は、[RFC8311]で定義されたプロセスに従って設定されます。
The TCP-sender response is currently specified in Section 6.1.2 of the ECN specification [RFC3168] and has been slightly updated by Section 4.1 of [RFC8311] to read as:
TCP送信者の応答は現在、ECN仕様[RFC3168]のセクション6.1.2で指定されており、[RFC8311]のセクション4.1で次のようにわずかに更新されています。
The indication of congestion should be treated just as a congestion loss in non-ECN-Capable TCP. That is, the TCP source halves the congestion window "cwnd" and reduces the slow start threshold "ssthresh", unless otherwise specified by an Experimental RFC in the IETF document stream.
輻輳の兆候は、ECN非対応TCPでの輻輳損失と同様に扱われる必要があります。つまり、TCPソースは、IETFドキュメントストリームの実験的RFCで特に指定されていない限り、輻輳ウィンドウ「cwnd」を半分にし、スロースタートしきい値「ssthresh」を減らします。
As permitted by RFC 8311, this document specifies a sender-side change to TCP where receipt of a packet with the ECN-Echo flag SHOULD trigger the TCP source to set the slow start threshold (ssthresh) to 0.8 times the FlightSize, with a lower bound of 2 * SMSS applied to the result (where SMSS stands for Sender Maximum Segment Size)). As in [RFC5681], the TCP sender also reduces the cwnd value to no more than the new ssthresh value. Section 6.1.2 of RFC 3168 provides guidance on setting a cwnd less than 2 * SMSS.
RFC 8311で許可されているように、このドキュメントでは、ECN-Echoフラグ付きのパケットの受信がTCPソースをトリガーしてスロースタートしきい値（ssthresh）をFlightSizeの0.8倍に設定し、TCPの送信側の変更を指定しています。 2の境界* SMSSが結果に適用されます（SMSSは送信者の最大セグメントサイズを表します）。 [RFC5681]と同様に、TCP送信側もcwnd値を新しいssthresh値以下に減らします。 RFC 3168のセクション6.1.2は、2 * SMSS未満のcwndの設定に関するガイダンスを提供しています。
ABE decouples the reaction of a TCP sender to inferred packet loss from the indication of ECN-signalled congestion in the congestion avoidance phase. To achieve this, ABE uses a different scaling factor for Equation 4 in Section 3.1 of [RFC5681]. The description respectively uses beta_{loss} and beta_{ecn} to refer to the multiplicative decrease factors applied in response to inferred packet loss, and in response to a receiver indicating ECN-signalled congestion. For non-ECN-enabled TCP connections, only beta_{loss} applies.
ABEは、TCP送信者の推測パケット損失に対する反応を、輻輳回避フェーズでのECNシグナリングの輻輳の表示から切り離します。これを達成するために、ABEは[RFC5681]のセクション3.1の式4に別の倍率を使用します。説明では、それぞれbeta_ {loss}およびbeta_ {ecn}を使用して、推定パケット損失に応答して、およびECN信号による輻輳を示す受信機に応答して適用される乗法的減少係数を示します。非ECN対応のTCP接続の場合、beta_ {loss}のみが適用されます。
In other words, in response to inferred packet loss:
つまり、推測されたパケット損失に応じて、
ssthresh = max (FlightSize * beta_{loss}, 2 * SMSS)
and in response to an indication of an ECN-signalled congestion:
そして、ECNで通知された輻輳の表示に応じて：
ssthresh = max (FlightSize * beta_{ecn}, 2 * SMSS)
and
そして
cwnd = ssthresh
(If ssthresh == 2 * SMSS, Section 6.1.2 of RFC 3168 provides guidance on setting a cwnd lower than 2 * SMSS.)
（ssthresh == 2 * SMSSの場合、RFC 3168のセクション6.1.2に、2 * SMSSよりも低いcwndの設定に関するガイダンスが記載されています）。
where FlightSize is the amount of outstanding data in the network, upper-bounded by the smaller of the sender's cwnd and the receiver's advertised window (rwnd) [RFC5681]. The higher the values of beta_{loss} and beta_{ecn}, the less aggressive the response of any individual backoff event.
ここで、FlightSizeはネットワーク内の未処理のデータ量であり、送信者のcwndと受信者のアドバタイズされたウィンドウ（rwnd）の小さい方が上限となります[RFC5681]。 beta_ {loss}とbeta_ {ecn}の値が高いほど、個々のバックオフイベントの積極性が低くなります。
The appropriate choice for beta_{loss} and beta_{ecn} values is a balancing act between path utilisation and draining the bottleneck queue. More aggressive backoff (smaller beta_*) risks the underutilisation of the path, while less-aggressive backoff (larger beta_*) can result in slower draining of the bottleneck queue.
beta_ {loss}とbeta_ {ecn}の値の適切な選択は、パスの使用率とボトルネックキューの排出のバランスをとることです。積極的なバックオフ（beta_ *が小さい）はパスの使用率が低下する危険性がありますが、積極的なバックオフ（beta_ *が大きい）はボトルネックキューの排出が遅くなる可能性があります。
The Internet has already been running with at least two different beta_{loss} values for several years: the standard value is 0.5 [RFC5681], and the Linux implementation of CUBIC [RFC8312] has used a multiplier of 0.7 since kernel version 2.6.25 released in 2008. ABE does not change the value of beta_{loss} used by current TCP implementations.
インターネットはすでに数年間、少なくとも2つの異なるbeta_ {loss}値で実行されています。標準値は0.5 [RFC5681]であり、CUBICのLinux実装[RFC8312]はカーネルバージョン2.6.25以降、0.7の乗数を使用しています。 ABEは、現在のTCP実装で使用されているbeta_ {loss}の値を変更しません。
The recommendation in this document specifies a value of beta_{ecn}=0.8. This recommended beta_{ecn} value is only applicable for the standard TCP congestion control [RFC5681]. The selection of beta_{ecn} enables tuning the response of a TCP connection to shallow AQM-marking thresholds. beta_{loss} characterizes the response of a congestion control algorithm to packet loss, i.e., exhaustion of buffers (of unknown depth). Different values for beta_{loss} have been suggested for TCP congestion control algorithms. Consequently, beta_{ecn} is likely to be an algorithm-specific parameter rather than a constant multiple of the algorithm's existing beta_{loss}.
このドキュメントの推奨事項では、beta_ {ecn} = 0.8の値を指定しています。この推奨されるbeta_ {ecn}値は、標準のTCP輻輳制御[RFC5681]にのみ適用されます。 beta_ {ecn}を選択すると、浅いAQMマーキングしきい値に対するTCP接続の応答を調整できます。 beta_ {loss}は、パケット損失に対する輻輳制御アルゴリズムの応答、つまり（深さが不明な）バッファの枯渇を特徴付けます。 TCPの輻輳制御アルゴリズムには、beta_ {loss}のさまざまな値が提案されています。その結果、beta_ {ecn}は、アルゴリズムの既存のbeta_ {loss}の定数倍ではなく、アルゴリズム固有のパラメーターになる可能性があります。
A range of tests (Section IV of [ABE2017]) with NewReno and CUBIC over CoDel and PIE in lightly multiplexed scenarios have explored this choice of parameter. The results of these tests indicate that CUBIC connections benefit from beta_{ecn} of 0.85 (cf. beta_{loss} = 0.7), and NewReno connections see improvements with beta_{ecn} in the range 0.7 to 0.85 (cf. beta_{loss} = 0.5).
軽く多重化されたシナリオでCoDelとPIEを介してNewRenoとCUBICを使用した一連のテスト（[ABE2017]のセクションIV）は、このパラメーターの選択を調査しました。これらのテストの結果は、CUBIC接続がbeta_ {ecn}の0.85（cf. beta_ {loss} = 0.7）の恩恵を受けていることを示しており、NewReno接続はbeta_ {ecn}で0.7から0.85の範囲の改善を見ています（cf. beta_ {loss } = 0.5）。
Much of the technical background for ABE can be found in [ABE2017], which uses a mix of experiments, theory, and simulations with NewReno [RFC5681] and CUBIC [RFC8312] to evaluate its performance. ABE was shown to present significant performance gains in lightly-multiplexed (few concurrent flows) scenarios, without losing the delay-reduction benefits of deploying CoDel or PIE. The performance improvement is achieved when reacting to ECN-Echo in congestion avoidance (when ssthresh > cwnd) by multiplying cwnd and ssthresh with a value in the range [0.7,0.85]. Applying ABE when cwnd is smaller than or equal to ssthresh is not currently recommended, but its use in that scenario may benefit from additional attention, experimentation, and specification.
ABEの技術的背景の多くは、[ABE2017]にあり、実験、理論、シミュレーションを組み合わせて、NewReno [RFC5681]とCUBIC [RFC8312]でパフォーマンスを評価しています。 ABEは、CoDelまたはPIEの導入による遅延削減の利点を失うことなく、軽く多重化された（同時フローが少ない）シナリオで大幅なパフォーマンスの向上をもたらすことが示されました。パフォーマンスの向上は、輻輳回避でECN-Echoに反応する場合（ssthresh> cwndの場合）、cwndとssthreshを[0.7,0.85]の範囲の値で乗算することによって達成されます。 cwndがssthresh以下の場合にABEを適用することは現在推奨されていませんが、そのシナリオでの使用は、追加の注意、実験、および仕様から利益を得る可能性があります。
AQM mechanisms such as CoDel [RFC8289] and PIE [RFC8033] set a delay target in routers and use congestion notifications to constrain the queuing delays experienced by packets rather than in response to impending or actual bottleneck buffer exhaustion. With current default delay targets, CoDel and PIE both effectively emulate a bottleneck with a short queue (Section II of [ABE2017]) while also allowing short traffic bursts into the queue. This provides acceptable performance for TCP connections over a path with a low BDP, or in highly multiplexed scenarios (many concurrent transport flows). However, in a lightly multiplexed case over a path with a large BDP, conventional TCP backoff leads to gaps in packet transmission and underutilisation of the path.
CoDel [RFC8289]やPIE [RFC8033]などのAQMメカニズムは、ルーターに遅延ターゲットを設定し、輻輳通知を使用して、差し迫ったまたは実際のボトルネックバッファーの枯渇に対応するのではなく、パケットが経験するキューイング遅延を抑制します。現在のデフォルトの遅延ターゲットでは、CoDelとPIEの両方が短いキュー（[ABE2017]のセクションII）でボトルネックを効果的にエミュレートし、同時にキューへの短いトラフィックバーストを許可します。これにより、BDPが低いパスを介したTCP接続、または高度に多重化されたシナリオ（多数の同時トランスポートフロー）で、TCP接続に許容可能なパフォーマンスが提供されます。ただし、大規模なBDPを使用するパスで軽く多重化されたケースでは、従来のTCPバックオフにより、パケット送信にギャップが生じ、パスの利用率が低下します。
Instead of discarding packets, an AQM mechanism is allowed to mark ECN-Capable packets with an ECN CE mark. The reception of CE-mark feedback not only indicates congestion on the network path, it also indicates that an AQM mechanism exists at the bottleneck along the path. Therefore, the CE mark likely came from a bottleneck with a controlled short queue. Reacting differently to an ECN-signalled congestion than to an inferred packet loss can then yield the benefit of a reduced backoff when queues are short. Using ECN can also be advantageous for several other reasons [RFC8087].
パケットを破棄する代わりに、AQMメカニズムでECN対応のパケットにECN CEマークを付けることができます。 CEマークフィードバックの受信は、ネットワークパスの輻輳を示すだけでなく、パスに沿ったボトルネックにAQMメカニズムが存在することも示します。したがって、CEマークは、制御されたショートキューのボトルネックに起因する可能性があります。 ECNで通知された輻輳に対して、推測されたパケット損失に対して異なる反応をすることで、キューが短い場合のバックオフを削減できるという利点があります。 ECNを使用することは、他のいくつかの理由でも有利になることがあります[RFC8087]。
The idea of reacting differently to inferred packet loss and detection of an ECN-signalled congestion predates this specification, e.g., previous research proposed using ECN CE-marked feedback to modify TCP congestion control behaviour via a larger multiplicative decrease factor in conjunction with a smaller additive increase factor [ICC2002]. The goal of this former work was to operate across AQM bottlenecks (using Random Early Detection (RED)) that were not necessarily configured to emulate a short queue. (The current usage of RED as an Internet AQM method is limited [RFC7567].)
推論されたパケット損失とECNシグナリングの輻輳の検出に異なる反応をするという考えは、この仕様よりも前に存在します。たとえば、以前の研究は、ECN CEマーク付きフィードバックを使用して、小さい乗数と組み合わせて大きい乗法減少係数を介してTCP輻輳制御動作を変更することを提案しました。増加係数[ICC2002]。この以前の作業の目標は、短いキューをエミュレートするように構成されているとは限らないAQMボトルネック（ランダム早期検出（RED）を使用）を操作することでした。 （インターネットAQMメソッドとしてのREDの現在の使用は制限されています[RFC7567]。）
This specification applies to the use of ECN feedback as defined in [RFC3168], which specifies a response to indicated congestion that is no more frequent than once per path round-trip time. Since ABE responds to indicated congestion once per RTT, it does not respond to any further loss within the same RTT because an ABE sender has already reduced the congestion window. If congestion persists after such reduction, ABE continues to reduce the congestion window in each consecutive RTT. This consecutive reduction can protect the network against long-standing unfairness in the case of AQM algorithms that do not keep a small average queue length. The mechanism does not rely on Accurate ECN [ACC-ECN-FEEDBACK].
この仕様は、[RFC3168]で定義されているECNフィードバックの使用に適用されます。これは、パスのラウンドトリップ時間ごとに1回より頻繁ではない、示された輻輳への応答を指定します。 ABEは指定された輻輳にRTTごとに1回応答するため、ABE送信者がすでに輻輳ウィンドウを縮小しているため、同じRTT内のそれ以上の損失には応答しません。このような削減後も輻輳が続く場合、ABEは連続する各RTTで輻輳ウィンドウを削減し続けます。この連続的な削減により、AQMアルゴリズムが短い平均キュー長を維持しない場合に、長期にわたる不公平からネットワークを保護できます。このメカニズムは、正確なECN [ACC-ECN-FEEDBACK]には依存しません。
In contrast, transport protocol mechanisms can also be designed to utilise more frequent and detailed ECN feedback (e.g., Accurate ECN [ACC-ECN-FEEDBACK]), which then permit a congestion control response that adjusts the sending rate more frequently. Data Center TCP (DCTCP) [RFC8257] is an example of this approach.
対照的に、トランスポートプロトコルメカニズムは、より頻繁で詳細なECNフィードバック（たとえば、正確なECN [ACC-ECN-FEEDBACK]）を利用するように設計することもできます。これにより、送信レートをより頻繁に調整する輻輳制御応答が可能になります。データセンターTCP（DCTCP）[RFC8257]は、このアプローチの例です。
This update is a sender-side-only change. Like other changes to congestion control algorithms, it does not require any change to the TCP receiver or to network devices. It does not require any ABE-specific changes in routers or the use of Accurate ECN feedback [ACC-ECN-FEEDBACK] by a receiver.
この更新は送信側のみの変更です。輻輳制御アルゴリズムの他の変更と同様に、TCPレシーバーやネットワークデバイスを変更する必要はありません。ルーターでのABE固有の変更や、レシーバーによる正確なECNフィードバック[ACC-ECN-FEEDBACK]の使用は必要ありません。
If the method is only deployed by some senders, and not by others, the senders using it can gain some advantage, possibly at the expense of other flows that do not use this updated method. Because this advantage applies only to ECN-marked packets and not to packet-loss indications, an ECN-Capable bottleneck will still fall back to dropping packets if a TCP sender using ABE is too aggressive. The result is no different than if the TCP sender were using traditional loss-based congestion control.
メソッドが一部の送信者によってのみ展開され、他の送信者によっては展開されない場合、このメソッドを使用する送信者は、この更新されたメソッドを使用しない他のフローを犠牲にして、何らかの利点を得ることができます。この利点はECNマークの付いたパケットにのみ適用され、パケット損失の表示には適用されないため、ABEを使用するTCP送信側が非常に攻撃的である場合、ECN対応のボトルネックはパケットのドロップにフォールバックします。結果は、TCP送信者が従来の損失ベースの輻輳制御を使用していた場合と同じです。
When used with bottlenecks that do not support ECN marking, the specification does not modify the transport protocol.
ECNマーキングをサポートしないボトルネックで使用される場合、仕様はトランスポートプロトコルを変更しません。
[RFC3168] states that the congestion control response following an indication of ECN-signalled congestion is the same as the response to a dropped packet. [RFC8311] updates this specification to allow systems to provide a different behaviour when they experience ECN-signalled congestion rather than packet loss. The present specification defines such an experiment and is an Experimental RFC. We expect to propose it as a Standards-Track document in the future.
[RFC3168]は、ECNシグナリングによる輻輳の表示に続く輻輳制御応答は、ドロップされたパケットに対する応答と同じであると述べています。 [RFC8311]は、この仕様を更新して、システムがパケット損失ではなくECNシグナルの輻輳を経験したときに別の動作を提供できるようにします。現在の仕様はそのような実験を定義し、実験的RFCです。将来的にはStandards-Trackドキュメントとして提案する予定です。
The purpose of the Internet experiment is to collect experience with the deployment of ABE and confirm acceptable safety in deployed networks that use this update to TCP congestion control. To evaluate ABE, this experiment requires support in AQM routers for the ECN-marking of packets carrying the ECN-Capable Transport codepoint ECT(0) [RFC3168].
インターネット実験の目的は、ABEの展開に関する経験を収集し、このTCP輻輳制御の更新を使用する展開されたネットワークで許容可能な安全性を確認することです。 ABEを評価するには、この実験では、ECN対応トランスポートコードポイントECT（0）[RFC3168]を伝送するパケットのECNマーキングをAQMルーターでサポートする必要があります。
The result of this Internet experiment ought to include an investigation of the implications of experiencing an ECN-CE mark followed by loss within the same RTT. At the end of the experiment, this will be reported to the TCPM Working Group or the IESG.
このインターネット実験の結果には、ECN-CEマークが発生した後に同じRTT内で損失が発生した場合の影響の調査が含まれているはずです。実験の最後に、これはTCPMワーキンググループまたはIESGに報告されます。
ABE is implemented as a patch for Linux and FreeBSD. This is meant for research and experimentation and is available for download at <https://heim.ifi.uio.no/michawe/research/abe/>. This code was used to produce the test results that are reported in [ABE2017]. The FreeBSD code was committed to the mainline kernel on March 19, 2018 [ABE-REVISION].
ABEはLinuxおよびFreeBSDのパッチとして実装されています。これは研究と実験を目的としており、<https://heim.ifi.uio.no/michawe/research/abe/>からダウンロードできます。このコードは、[ABE2017]で報告されるテスト結果を生成するために使用されました。 FreeBSDコードは、2018年3月19日にメインラインカーネルにコミットされました[ABE-REVISION]。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
The described method is a sender-side-only transport change, and it does not change the protocol messages exchanged. Therefore, the security considerations for ECN [RFC3168] still apply.
説明されている方法は送信側のみのトランスポート変更であり、交換されるプロトコルメッセージは変更されません。したがって、ECN [RFC3168]のセキュリティに関する考慮事項が引き続き適用されます。
This is a change to TCP congestion control with ECN that will typically lead to a change in the capacity achieved when flows share a network bottleneck. This could result in some flows receiving more than their fair share of capacity. Similar unfairness in the way that capacity is shared is also exhibited by other congestion control mechanisms that have been in use in the Internet for many years (e.g., CUBIC [RFC8312]). Unfairness may also be a result of other factors, including the round-trip time experienced by a flow. ABE applies only when ECN-marked packets are received, not when packets are lost. Therefore, use of ABE cannot lead to congestion collapse.
これは、ECNを使用したTCP輻輳制御の変更であり、通常、フローがネットワークボトルネックを共有するときに達成される容量が変更されます。これにより、一部のフローが容量のフェアシェアを超える量を受け取る可能性があります。キャパシティの共有方法における同様の不公平さは、インターネットで長年使用されてきた他の輻輳制御メカニズム（CUBIC [RFC8312]など）でも見られます。不公平は、フローが経験する往復時間など、他の要因の結果である場合もあります。 ABEは、ECNマーク付きのパケットが受信された場合にのみ適用され、パケットが失われた場合には適用されません。したがって、ABEを使用しても、輻輳が崩壊することはありません。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https：// www。 rfc-editor.org/info/rfc3168>。
[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>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<https://www.rfc-editor.org/info/ rfc5681>。
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.
[RFC7567]ベイカー、F。、エド。およびG.フェアハースト編、「アクティブキュー管理に関するIETFの推奨事項」、BCP 197、RFC 7567、DOI 10.17487 / RFC7567、2015年7月、<https://www.rfc-editor.org/info/rfc7567>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., and G. Judd, "Data Center TCP (DCTCP): TCP Congestion Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[RFC8257]ベンズリー、S。、ターラー、D。、バラブラマニアン、P。、エガート、L。、およびG.ジャッド、「Data Center TCP（DCTCP）：TCP Congestion Control for Data Centers」、RFC 8257、DOI 10.17487 / RFC8257、2017年10月、<https://www.rfc-editor.org/info/rfc8257>。
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, January 2018, <https://www.rfc-editor.org/info/rfc8311>.
[RFC8311]ブラック、D。、「明示的な輻輳通知（ECN）実験に関する制限の緩和」、RFC 8311、DOI 10.17487 / RFC8311、2018年1月、<https://www.rfc-editor.org/info/rfc8311>。
[ABE-REVISION] Stewart, L., "ABE patch review in FreeBSD", Revision 331214, March 2018, <https://svnweb.freebsd.org/ base?view=revision&revision=331214>.
[ABE-REVISION] Stewart、L。、「FreeBSDのABEパッチレビュー」、リビジョン331214、2018年3月、<https://svnweb.freebsd.org/base?view=revision&revision=331214>。
[ABE2017] Khademi, N., Armitage, G., Welzl, M., Zander, S., Fairhurst, G., and D. Ros, "Alternative backoff: Achieving low latency and high throughput with ECN and AQM", IFIP Networking Conference and Workshops Stockholm, Sweden, DOI 10.23919/IFIPNetworking.2017.8264863, June 2017.
[ABE2017] Khademi、N.、Armitage、G.、Welzl、M.、Zander、S.、Fairhurst、G。、およびD. Ros、「代替バックオフ：ECNとAQMによる低遅延と高スループットの実現」、IFIPネットワーキング会議およびワークショップ、スウェーデン、ストックホルム、DOI 10.23919 / IFIPNetworking.2017.8264863、2017年6月。
[ACC-ECN-FEEDBACK] Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More Accurate ECN Feedback in TCP", Work in Progress, draft-ietf-tcpm-accurate-ecn-07, July 2018.
[ACC-ECN-FEEDBACK] Briscoe、B.、Kuehlewwind、M。、およびR. Scheffenegger、「TCPでのより正確なECNフィードバック」、作業中、draft-ietf-tcpm-accurate-ecn-07、2018年7月。
[BUFFERBLOAT] Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in the Internet", ACM Queue, Volume 9, Issue 11, DOI 10.1145/2063166.2071893, November 2011, <https://queue.acm.org/detail.cfm?id=2071893>.
[BUFFERBLOAT] Gettys、J。およびK. Nichols、「Bufferbloat：Dark Buffers in the Internet」、ACM Queue、Volume 9、Issue 11、DOI 10.1145 / 2063166.2071893、2011年11月、<https://queue.acm.org/ detail.cfm？id = 2071893>。
[ICC2002] Kwon, M. and S. Fahmy, "TCP increase/decrease behavior with explicit congestion notification (ECN)", 2002 IEEE International Conference on Communications Conference Proceedings, ICC 2002, Cat. No.02CH37333, DOI 10.1109/ICC.2002.997262, May 2002, <http://dx.doi.org/10.1109/ICC.2002.997262>.
[ICC2002]クォン、M、およびS.ファミー、「明示的な輻輳通知（ECN）による動作のTCP増減」、2002年、IEEE International Conference on Communications Conference Proceedings、ICC 2002、Cat。 No.02CH37333、DOI 10.1109 / ICC.2002.997262、2002年5月、<http://dx.doi.org/10.1109/ICC.2002.997262>。
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, "Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, <https://www.rfc-editor.org/info/rfc8033>.
[RFC8033]パン、R。、ナタラジャン、P。、ベイカー、F。、およびG.ホワイト、「プロポーショナルインテグラルコントローラーエンハンスド（PIE）：バッファブロート問題に対処する軽量制御方式」、RFC 8033、DOI 10.17487 / RFC8033 、2017年2月、<https://www.rfc-editor.org/info/rfc8033>。
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using Explicit Congestion Notification (ECN)", RFC 8087, DOI 10.17487/RFC8087, March 2017, <https://www.rfc-editor.org/info/rfc8087>.
[RFC8087] Fairhurst、G。およびM. Welzl、「明示的な輻輳通知（ECN）を使用する利点」、RFC 8087、DOI 10.17487 / RFC8087、2017年3月、<https://www.rfc-editor.org/info / rfc8087>。
[RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. Iyengar, Ed., "Controlled Delay Active Queue Management", RFC 8289, DOI 10.17487/RFC8289, January 2018, <https://www.rfc-editor.org/info/rfc8289>.
[RFC8289] Nichols、K.、Jacobson、V.、McGregor、A。、編、およびJ. Iyengar、編、「Controlled Delay Active Queue Management」、RFC 8289、DOI 10.17487 / RFC8289、2018年1月、<https ：//www.rfc-editor.org/info/rfc8289>。
[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", RFC 8312, DOI 10.17487/RFC8312, February 2018, <https://www.rfc-editor.org/info/rfc8312>.
[RFC8312] Rhee、I.、Xu、L.、Ha、S.、Zimmermann、A.、Eggert、L.、and R. Scheffenegger、 "CUBIC for Fast Long-Distance Networks"、RFC 8312、DOI 10.17487 / RFC8312 、2018年2月、<https://www.rfc-editor.org/info/rfc8312>。
Acknowledgements
謝辞
Authors N. Khademi, M. Welzl, and G. Fairhurst were partly funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). The views expressed are solely those of the authors.
著者のN. Khademi、M。Welzl、およびG. Fairhurstは、インターネットトランスポートレイテンシの削減（RITE）プロジェクト（ICT-317700）を通じて、第7フレームワークプログラムの下で欧州共同体から部分的に資金提供を受けました。表明された見解は、著者の見解のみです。
Author G. Armitage performed most of his work on this document while employed by Swinburne University of Technology, Melbourne, Australia.
著者G.アーミテージは、オーストラリアのメルボルンにあるスウィンバーン工科大学に雇用されている間に、このドキュメントのほとんどの作業を行いました。
The authors would like to thank Stuart Cheshire for many suggestions when revising this document. They would also like to thank the following people for their contributions to [ABE2017]: Chamil Kulatunga, David Ros, Stein Gjessing, and Sebastian Zander. Thanks also to (in alphabetical order) David Black, Roland Bless, Bob Briscoe, Markku Kojo, John Leslie, Lawrence Stewart, and the TCPM Working Group for providing valuable feedback on this document.
このドキュメントを改訂する際に、多くの提案をしてくれたStuart Cheshireに感謝します。彼らはまた、[ABE2017]への貢献に対して、Chamil Kulatunga、David Ros、Stein Gjessing、およびSebastian Zanderに感謝します。このドキュメントに関する貴重なフィードバックを提供してくれたDavid Black、Roland Bless、Bob Briscoe、Markku Kojo、John Leslie、Lawrence Stewart、およびTCPMワーキンググループにも感謝します。
Finally, the authors would like to thank everyone who provided feedback on the congestion control behaviour specified in this document that was received from the IRTF Internet Congestion Control Research Group (ICCRG).
最後に、著者は、IRTFインターネット輻輳制御研究グループ（ICCRG）から受け取った、このドキュメントで指定された輻輳制御動作についてフィードバックを提供してくださったすべての人に感謝します。
Authors' Addresses
著者のアドレス
Naeem Khademi University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway
Naeem Khademi University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway
Email: naeemk@ifi.uio.no
Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway
マイケルウェルズル大学オスロ私書箱1080ブリンデンオスロN-0316ノルウェー
Email: michawe@ifi.uio.no
Grenville Armitage Netflix Inc.
グレンビルアーミテージネットフリックス
Email: garmitage@netflix.com
Godred Fairhurst University of Aberdeen School of Engineering, Fraser Noble Building Aberdeen AB24 3UE United Kingdom
Godred Fairhurst University of Aberdeen School of Engineering、Fraser Noble Building Aberdeen AB24 3UE United Kingdom
Email: gorry@erg.abdn.ac.uk