[要約] RFC 7560は、明示的輻輳通知（ECN）フィードバックの精度向上の問題と要件について述べています。このRFCの目的は、ECNフィードバックの信頼性と正確性を向上させるための問題の特定と要件の定義です。
Internet Engineering Task Force (IETF) M. Kuehlewind, Ed.
Request for Comments: 7560 ETH Zurich
Category: Informational R. Scheffenegger
ISSN: 2070-1721 NetApp, Inc.
B. Briscoe
BT
August 2015
Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback
明示的な輻輳通知（ECN）フィードバックの精度を高めるための問題の説明と要件
Abstract
概要
Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets, instead of dropping them, to indicate congestion to the endpoints. An ECN-capable receiver will feed this information back to the sender. ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-Trip Time (RTT). In contrast, ECN for other transport protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN feedback. Recent new TCP mechanisms (like Congestion Exposure (ConEx) or Data Center TCP (DCTCP)) need more accurate ECN feedback in the case where more than one marking is received in one RTT. This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback.
明示的輻輳通知（ECN）は、ネットワークノードがIPパケットをドロップする代わりにマークして、エンドポイントに輻輳を示すことができるメカニズムです。 ECN対応の受信者は、この情報を送信者にフィードバックします。 ECNは、ラウンドトリップ時間（RTT）ごとに1つの輻輳信号しかフィードバックできないようにTCPに指定されています。対照的に、RTP / UDPやSCTPなどの他のトランスポートプロトコルのECNは、より正確なECNフィードバックで指定されます。最近の新しいTCPメカニズム（Congestion Exposure（ConEx）やData Center TCP（DCTCP）など）では、1つのRTTで複数のマーキングを受信する場合に、より正確なECNフィードバックが必要です。このドキュメントでは、より正確なECNフィードバックを提供するためのTCPプロトコルの更新の要件を指定します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7560.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7560で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Recap of Classic ECN and ECN Nonce in IP/TCP . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Design Approaches . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Redefinition of ECN/NS Header Bits . . . . . . . . . . . 11
5.2. Using Other Header Bits . . . . . . . . . . . . . . . . . 13
5.3. Using a TCP Option . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Ambiguity of the More Accurate ECN Feedback in DCTCP 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Explicit Congestion Notification (ECN) [RFC3168] is a mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the endpoints. An ECN-capable receiver will feed this information back to the sender. ECN is specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). This is sufficient for preexisting TCP congestion control mechanisms that perform only one reduction in sending rate per RTT, independent of the number of ECN congestion marks. But recently proposed or deployed mechanisms like Congestion Exposure (ConEx) [RFC6789] or Data Center TCP (DCTCP) [DCTCP] need more accurate ECN feedback than 'classic ECN' [RFC3168] to work correctly in the case where more than one marking is received in any one RTT.
明示的輻輳通知（ECN）[RFC3168]は、ネットワークノードがIPパケットをドロップする代わりにマークして、エンドポイントへの輻輳を示すことができるメカニズムです。 ECN対応の受信者は、この情報を送信者にフィードバックします。 ECNは、ラウンドトリップタイム（RTT）ごとに1つのフィードバック信号しか送信できないようにTCPに指定されています。これは、ECN輻輳マークの数に関係なく、RTTごとに送信レートを1回だけ削減する既存のTCP輻輳制御メカニズムには十分です。ただし、最近提案または導入されたCongestion Exposure（ConEx）[RFC6789]またはData Center TCP（DCTCP）[DCTCP]のようなメカニズムは、複数のマーキングが存在する場合に正しく機能するために、「クラシックECN」[RFC3168]よりも正確なECNフィードバックを必要とします。 1つのRTTで受信されます。
For an in-depth discussion of the application benefits of using ECN (including with sufficiently granular feedback), see [ECN-BENEFITS].
ECNを使用することのアプリケーションの利点（十分に詳細なフィードバックを含む）の詳細については、[ECN-BENEFITS]を参照してください。
ECN is also defined for transport protocols beside TCP. ECN feedback as defined for RTP/UDP [RFC6679] provides a very detailed level of information, delivering individual counters for all four ECN codepoints as well as lost and duplicate segments, but at the cost of high signalling overhead. ECN feedback for SCTP has been proposed in [SCTP-ECN]. This delivers a counter for the number of ECN-capable packets that were marked due to congestion (since the last sender-side window reduction), but it comes at the cost of increased overhead.
ECNは、TCP以外のトランスポートプロトコルにも定義されています。 RTP / UDP [RFC6679]で定義されているECNフィードバックは、非常に詳細なレベルの情報を提供し、4つのECNコードポイントすべてに個別のカウンターを提供します。 SCTPのECNフィードバックは[SCTP-ECN]で提案されています。これにより、輻輳が原因でマークされたECN対応パケットの数のカウンターが提供されます（最後の送信側のウィンドウの縮小以降）が、オーバーヘッドの増加という犠牲が伴います。
Today, implementations of DCTCP already exist that alter TCP's ECN feedback protocol in proprietary ways (DCTCP was released in Microsoft Windows 8, and implementations exist for Linux and FreeBSD). However, the changes DCTCP makes to TCP omit capability negotiation, relying instead on uniform configuration across all hosts and network devices with ECN capability. A primary motivation for this document is to intervene before each proprietary implementation invents its own non-interoperable handshake, which could lead to _de facto_ consumption of the few flags or codepoints that remain available for standardizing capability negotiation.
現在、TCPのECNフィードバックプロトコルを独自の方法で変更するDCTCPの実装がすでに存在しています（DCTCPはMicrosoft Windows 8でリリースされ、LinuxおよびFreeBSD向けの実装が存在します）。ただし、DCTCPがTCPに対して行う変更は、機能のネゴシエーションを省略し、代わりに、ECN機能を持つすべてのホストとネットワークデバイスにまたがる統一された構成に依存します。このドキュメントの主な動機は、各プロプライエタリな実装が独自の相互運用できないハンドシェイクを発明する前に介入することです。これにより、機能交渉の標準化に利用可能ないくつかのフラグまたはコードポイントが実際に消費される可能性があります。
This document lists requirements for a robust and interoperable TCP/ ECN feedback protocol that is more accurate than classic ECN [RFC3168] and that all implementations of new TCP extensions, like ConEx and/or DCTCP, can use. While a new feedback scheme should still deliver as much information as classic ECN, this document also clarifies what has to be taken into consideration in addition. Thus, the listed requirements should be addressed in the specification of a more accurate ECN feedback scheme. A few solutions have already been proposed. Section 5 demonstrates how to use the requirements to compare them, by briefly sketching their high-level design choices and discussing the benefits and drawbacks of each.
このドキュメントでは、従来のECN [RFC3168]よりも正確で、ConExやDCTCPなどの新しいTCP拡張のすべての実装で使用できる、堅牢で相互運用可能なTCP / ECNフィードバックプロトコルの要件を示します。新しいフィードバックスキームでは、従来のECNと同じくらい多くの情報を提供する必要がありますが、このドキュメントでは、何を考慮に入れる必要があるかについても明確にしています。したがって、リストされた要件は、より正確なECNフィードバックスキームの仕様で対処する必要があります。いくつかの解決策がすでに提案されています。セクション5では、要件を使用してそれらを比較する方法を示します。高水準の設計選択を簡単にスケッチし、それぞれの利点と欠点を説明します。
The scope of these requirements is not limited to any specific environment and is intended for general deployment over public and private IP networks. Candidate solutions should try to adhere to all these requirements, but, where this is not possible, they should justify the deviation. The ordering of the requirements listed in this document is not to be taken as an order of importance, because each requirement might have different weight in different deployment scenarios.
これらの要件の範囲は特定の環境に限定されるものではなく、パブリックおよびプライベートIPネットワーク上での一般的な展開を対象としています。候補となるソリューションは、これらすべての要件を遵守するよう努めるべきですが、これが不可能な場合は、逸脱を正当化する必要があります。このドキュメントに記載されている要件の順序は、重要度の順序とは見なされません。これは、各要件が異なる導入シナリオでは異なる重みを持つ可能性があるためです。
These requirements are only concerned with the type and quality of the ECN feedback signal. The requirements do not stipulate how a TCP sender might react to the improved ECN signal. The requirements also do not imply that any modifications to TCP senders or receivers are obligatory.
これらの要件は、ECNフィードバック信号のタイプと品質にのみ関係します。要件は、TCP送信者が改善されたECN信号にどのように反応するかを規定していません。また、この要件は、TCPの送信者または受信者に対する変更が必須であることを意味するものではありません。
We use the following terminology from [RFC3168] and [RFC3540]:
[RFC3168]と[RFC3540]の次の用語を使用します。
The ECN field in the IP header:
IPヘッダーのECNフィールド：
Not-ECT: the not ECN-Capable Transport codepoint,
Not-ECT：ECN非対応のトランスポートコードポイント
CE: the Congestion Experienced codepoint,
CE：Congestion Experiencedコードポイント、
ECT(0): the first ECN-Capable Transport codepoint, and
ECT（0）：最初のECN対応トランスポートコードポイント、および
ECT(1): the second ECN-Capable Transport codepoint.
ECT（1）：2番目のECN対応トランスポートコードポイント。
The ECN flags in the TCP header:
TCPヘッダーのECNフラグ：
CWR: the Congestion Window Reduced flag,
CWR：Congestion Window Reducedフラグ、
ECE: the ECN-Echo flag, and
ECE：ECN-Echoフラグ、および
NS: ECN Nonce Sum.
NS：ECNノンス和。
In this document, the ECN feedback scheme as specified in [RFC3168] is called 'classic ECN' and any new proposal is called a 'more accurate ECN feedback' scheme. A 'congestion mark' is defined as an IP packet where the CE codepoint is set. A 'congestion episode' refers to one or more congestion marks that belong to the same overload situation in the network (usually during one RTT). A TCP segment with the acknowledgement flag set is simply called an ACK.
このドキュメントでは、[RFC3168]で指定されているECNフィードバックスキームを「クラシックECN」と呼び、新しい提案を「より正確なECNフィードバック」スキームと呼びます。 「輻輳マーク」は、CEコードポイントが設定されているIPパケットとして定義されます。 「輻輳エピソード」とは、ネットワーク内の同じ過負荷状態に属する1つ以上の輻輳マークを指します（通常は1つのRTTの間）。確認フラグが設定されたTCPセグメントは、単にACKと呼ばれます。
ECN requires two bits in the IP header. The ECN capability of a packet is indicated when either one of the two bits is set. A network node can set both bits simultaneously when it experiences congestion. This leads to the four codepoints (Not-ECT, ECT(0), ECT(1), and CE) as listed above.
ECNでは、IPヘッダーに2ビットが必要です。パケットのECN機能は、2ビットのいずれかが設定されている場合に示されます。ネットワークノードは、輻輳が発生したときに両方のビットを同時に設定できます。これにより、上記の4つのコードポイント（Not-ECT、ECT（0）、ECT（1）、およびCE）が導き出されます。
In the TCP header, the first two bits in byte 14 are defined as ECN feedback for each half-connection. A TCP receiver signals the reception of a congestion mark using the ECN-Echo (ECE) flag in the TCP header. For reliability, the receiver continues to set the ECE flag on every ACK. To enable the TCP receiver to determine when to stop setting the ECE flag, the sender sets the CWR flag upon reception of an ECE feedback signal. This always leads to a full RTT of ACKs with ECE set. Thus, the receiver cannot signal back any additional CE markings arriving within the same RTT.
TCPヘッダーでは、バイト14の最初の2ビットが各ハーフコネクションのECNフィードバックとして定義されています。 TCPレシーバーは、TCPヘッダーのECN-Echo（ECE）フラグを使用して、輻輳マークの受信を通知します。信頼性を高めるために、レシーバーはすべてのACKでECEフラグを設定し続けます。 TCP受信者がECEフラグの設定をいつ停止するかを決定できるように、送信者はECEフィードバック信号の受信時にCWRフラグを設定します。これは常に、ECEが設定されたACKの完全なRTTにつながります。したがって、受信機は同じRTT内に到着する追加のCEマーキングを信号で返すことができません。
The ECN Nonce [RFC3540] is an experimental addition to ECN that the TCP sender can use to protect itself against accidental or malicious concealment of CE-marked or dropped packets. This addition defines the last bit of byte 13 in the TCP header as the Nonce Sum (NS) flag. The receiver maintains a nonce sum that counts the occurrence of ECT(1) packets and signals the least significant bit of this sum on the NS flag. There are no known deployments of a TCP stack that makes use of the ECN Nonce extension.
ECN Nonce [RFC3540]は、TCP送信者がCEマーク付きパケットまたはドロップされたパケットの偶発的または悪意のある隠蔽から自分自身を保護するために使用できるECNへの実験的な追加です。この追加により、TCPヘッダーのバイト13の最後のビットがノンスサム（NS）フラグとして定義されます。レシーバーは、ECT（1）パケットの発生をカウントするノンスサムを維持し、この合計の最下位ビットをNSフラグで通知します。 ECN Nonce拡張を利用するTCPスタックの既知のデプロイメントはありません。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | N | C | E | U | A | P | R | S | F |
| Header Length | Reserved | S | W | C | R | C | S | S | Y | I |
| | | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1: The (Post-ECN Nonce) Definition of the TCP Header Flags
図1：TCPヘッダーフラグの（ECN後のノンス）定義
An alternative for a sender to assure feedback integrity has been proposed where the sender itself occasionally inserts a CE mark or reorders packets, and checks that the receiver feeds these back faithfully [TEST-RCV]. This alternative consumes no header bits or codepoints, and it releases the ECT(1) codepoint in the IP header and the NS flag in the TCP header for other uses.
送信者自身が時折CEマークを挿入するか、パケットを並べ替え、受信者がこれらを忠実にフィードバックすることを確認するフィードバック整合性を保証する送信者の代替案が提案されています[TEST-RCV]。この代替手段は、ヘッダービットまたはコードポイントを消費せず、IPヘッダーのECT（1）コードポイントとTCPヘッダーのNSフラグを解放して、他の用途に使用します。
The following two examples serve to show where existing mechanisms would already benefit from more accurate ECN feedback information. However, as it is hard to predict the future, once a more accurate ECN feedback mechanism that adheres to the requirements stated in this document is widely deployed, it's very likely that additional uses will be found. The examples listed below are in no particular order.
次の2つの例は、既存のメカニズムがより正確なECNフィードバック情報のメリットをどこにもたらすかを示しています。ただし、将来を予測するのは難しいため、このドキュメントに記載されている要件に準拠したより正確なECNフィードバックメカニズムが広く導入されると、追加の用途が見つかる可能性が高くなります。下記の例は順不同です。
ConEx is an experimental approach that allows a sender to relay congestion feedback provided by the receiver into the network along the forward data path. ConEx information can be used for traffic management to limit traffic proportionate to the actual congestion being caused, rather than limiting traffic based on rate or volume [RFC6789]. A ConEx sender uses selective acknowledgements (SACK) [RFC2018] for accurate feedback of loss signals, but until now TCP has offered no equivalent accurate feedback for ECN.
ConExは、送信側が受信側から提供された輻輳フィードバックを転送データパスに沿ってネットワークに中継できるようにする実験的なアプローチです。トラフィック管理にConEx情報を使用すると、レートまたはボリュームに基づいてトラフィックを制限するのではなく、実際に発生している輻輳に比例してトラフィックを制限できます[RFC6789]。 ConEx送信者は、損失信号の正確なフィードバックのために選択的確認応答（SACK）[RFC2018]を使用しますが、これまでのところ、TCPはECNに同等の正確なフィードバックを提供していません。
DCTCP offers very low and predictable queuing delay. DCTCP changes the reaction to congestion of a TCP sender and additionally requires switches/routers to have ECN enabled and configured with a low step threshold and no signal smoothing, so it is currently only used in private networks, e.g., internal to data centers. DCTCP was released in Microsoft Windows 8, and implementations exist for Linux and FreeBSD. To retrieve sufficient congestion information, the different DCTCP implementations use a proprietary ECN feedback protocol, but they omit capability negotiation. Moreover, the feedback protocol proposed in [DCTCP] only works if there are no losses at all, and otherwise it gets very confused (see Appendix A). Therefore, if a generic, more accurate ECN feedback scheme were available, it would solve two problems for DCTCP: i) the need for a consistent variant of DCTCP to be deployed network-wide and ii) the inability to cope with ACK loss.
DCTCPは、非常に低く予測可能なキューイング遅延を提供します。 DCTCPは、TCP送信者の輻輳への対応を変更し、さらに、スイッチ/ルーターでECNを有効にして、低いステップしきい値と信号平滑化なしで構成する必要があるため、現在、データセンター内部などのプライベートネットワークでのみ使用されています。 DCTCPはMicrosoft Windows 8でリリースされ、LinuxとFreeBSDの実装が存在します。十分な輻輳情報を取得するために、さまざまなDCTCP実装は独自のECNフィードバックプロトコルを使用しますが、機能ネゴシエーションを省略しています。さらに、[DCTCP]で提案されているフィードバックプロトコルは、損失がまったくない場合にのみ機能し、それ以外の場合は非常に混乱します（付録Aを参照）。したがって、汎用的でより正確なECNフィードバックスキームが利用可能であれば、DCTCPの2つの問題を解決します。i）DCTCPの一貫したバリアントをネットワーク全体に展開する必要性、ii）ACK損失に対処できないこと。
Classic ECN-TCP would not benefit from more accurate ECN feedback, but it would not suffer either. The same signal that is currently conveyed with ECN following the specification given in [RFC3168] would be available.
従来のECN-TCPは、より正確なECNフィードバックの恩恵を受けることはありませんが、影響を受けることもありません。 [RFC3168]で指定された仕様に従ってECNで現在伝達されているものと同じ信号が利用可能です。
The following scenarios should briefly show where accurate ECN feedback is needed or adds value:
次のシナリオは、正確なECNフィードバックが必要な場所、または付加価値を簡単に示しています。
A sender with standardized TCP congestion control that supports ConEx: In this case, the ConEx mechanism uses the extra information per RTT to re-echo the precise congestion information, but the congestion control algorithm still ignores multiple marks per RTT [RFC5681].
ConExをサポートする標準化されたTCP輻輳制御を備えた送信者：この場合、ConExメカニズムはRTTごとの追加情報を使用して正確な輻輳情報を再エコーしますが、輻輳制御アルゴリズムは依然としてRTTごとの複数のマークを無視します[RFC5681]。
A sender using DCTCP congestion control without ConEx: The congestion control algorithm uses the extra info per RTT to perform its decrease depending on the number of congestion marks.
ConExなしでDCTCP輻輳制御を使用する送信者：輻輳制御アルゴリズムは、RTTごとの追加情報を使用して、輻輳マークの数に応じて減少を実行します。
A sender using DCTCP congestion control and supporting ConEx: Both the congestion control algorithm and ConEx use the more accurate ECN feedback mechanism.
DCTCP輻輳制御を使用し、ConExをサポートする送信側：輻輳制御アルゴリズムとConExはどちらも、より正確なECNフィードバックメカニズムを使用します。
As-yet-unspecified sender mechanisms: The above are two examples of more general interest in sender mechanisms that respond to the extent of congestion feedback, not just its existence. It will greatly simplify incremental deployment if the sender can unilaterally deploy new behaviours and rely on the presence of generic receivers that have already implemented more accurate feedback.
まだ指定されていない送信者メカニズム：上記は、存在だけでなく、輻輳フィードバックの範囲に応答する送信者メカニズムに対するより一般的な関心の2つの例です。送信者が一方的に新しい動作を展開し、より正確なフィードバックを既に実装している汎用受信者の存在に依存できる場合、増分展開が大幅に簡略化されます。
A TCP sender using congestion control as specified in RFC 5681 without ConEx: No accurate feedback is necessary here. The congestion control algorithm still reacts to only one signal per RTT. But, it is best to feed back all the information the receiver gets, whether or not the sender uses it -- at least as long as overhead is low or zero.
RFC 5681で指定されているConExなしの輻輳制御を使用するTCP送信者：ここでは正確なフィードバックは必要ありません。輻輳制御アルゴリズムは、RTTごとに1つの信号にのみ反応します。ただし、少なくともオーバーヘッドが低いかゼロである限り、送信者が使用するかどうかに関係なく、受信者が取得するすべての情報をフィードバックすることをお勧めします。
Using CE for checking integrity: If a more accurate ECN feedback scheme feeds all occurrences of CE marks back, a sender could perform integrity checking by occasionally injecting CE marks itself. Specifically, a sender can send packets that it randomly marks with CE (at low frequency), then check if feedback is received for these packets. The congestion notification feedback for these self-injected markings would not require a congestion control reaction [TEST-RCV].
整合性チェックにCEを使用する：より正確なECNフィードバックスキームがCEマークのすべての発生をフィードバックする場合、送信者はCEマーク自体を時々挿入することにより整合性チェックを実行できます。具体的には、送信者はCEでランダムにマークしたパケットを（低頻度で）送信し、これらのパケットのフィードバックを受信したかどうかを確認できます。これらの自己挿入マーキングの輻輳通知フィードバックは、輻輳制御反応を必要としません[TEST-RCV]。
The requirements of the accurate ECN feedback protocol are to have fairly accurate (not necessarily perfect), timely, and protected signalling. This leads to the following requirements, which should be discussed for any proposed more accurate ECN feedback scheme:
正確なECNフィードバックプロトコルの要件は、かなり正確で（必ずしも完璧ではない）、タイムリーで、保護されたシグナリングを行うことです。これにより、次の要件が生じます。これは、提案されているより正確なECNフィードバックスキームについて検討する必要があります。
Resilience The ECN feedback signal is carried within the ACK. Pure TCP ACKs can get lost without recovery (not just due to congestion but also due to deliberate ACK thinning). Moreover, delayed ACKs are commonly used with TCP. Typically, an ACK is triggered after two data segments (or more, e.g., due to receive segment coalescing, ACK compression, ACK congestion control [RFC5690], or other phenomena; see [RFC3449]). In a high-congestion situation where most of the packets are marked with CE, an accurate feedback mechanism should still be able to signal sufficient congestion information. Thus, the accurate ECN feedback extension has to take delayed ACKs and ACK loss into account. Also, a more accurate feedback protocol should still provide more accurate feedback than classic ECN when delayed ACKs cover more than two segments, or when a thin stream disables Nagle's algorithm [RFC896]. Finally, the feedback mechanism should not be impacted by reordering of ACKs, even when the ACKed sequence number does not increase.
レジリエンスECNフィードバック信号はACK内で伝送されます。純粋なTCP ACKは、回復しないと失われる可能性があります（輻輳だけでなく、故意のACKシンニングも原因です）。さらに、遅延ACKは一般的にTCPで使用されます。通常、ACKは2つのデータセグメントの後にトリガーされます（受信セグメントの結合、ACK圧縮、ACK輻輳制御[RFC5690]、その他の現象などにより、[RFC3449]を参照）。ほとんどのパケットがCEでマークされている高輻輳状況でも、正確なフィードバックメカニズムは十分な輻輳情報を通知できるはずです。したがって、正確なECNフィードバック拡張では、遅延ACKとACK損失を考慮する必要があります。また、より正確なフィードバックプロトコルは、遅延ACKが3つ以上のセグメントをカバーする場合、またはシンストリームがNagleのアルゴリズムを無効にする場合でも、従来のECNよりも正確なフィードバックを提供する必要があります[RFC896]。最後に、フィードバックメカニズムは、ACKされたシーケンス番号が増加しない場合でも、ACKの並べ替えの影響を受けてはなりません。
Timeliness A CE mark can be induced by the sending host, or more commonly a network node on the transmission path, and is then echoed by the receiver in the TCP ACK. Thus, when this information arrives at the sender, it is naturally already about one RTT old. With a sufficient ACK rate, a further delay of a small number of packets can be tolerated. However, this information will become stale with large delays, given the dynamic nature of networks. TCP congestion control (which itself partly introduces these dynamics) operates on a time scale of one RTT. Thus, to be timely, congestion feedback information should be delivered within about one RTT.
適時性CEマークは、送信ホスト、またはより一般的には伝送経路上のネットワークノードによって誘導され、受信者によってTCP ACKでエコーされます。したがって、この情報が送信者に届いたとき、当然、RTTの古さはすでに約1です。十分なACKレートを使用すると、少数のパケットのさらなる遅延を許容できます。ただし、ネットワークの動的な性質を考えると、この情報は大きな遅延で古くなります。 TCP輻輳制御（それ自体がこれらのダイナミクスを部分的に導入）は、1つのRTTの時間スケールで動作します。したがって、タイムリーにするには、輻輳フィードバック情報を約1つのRTT内で配信する必要があります。
Integrity The integrity of the feedback in a more accurate ECN feedback scheme should be assured, at least as well as the ECN Nonce. Alternatively, it should at least be possible to give strong incentives for the receiver and network nodes to cooperate honestly.
整合性より正確なECNフィードバックスキームでのフィードバックの整合性は、少なくともECNノンスと同様に、保証する必要があります。あるいは、少なくとも、受信者とネットワークノードが正直に協力するための強力なインセンティブを与えることが可能であるべきです。
Given there are known problems with ECN Nonce deployment, this document only requires that the integrity of the more accurate ECN feedback can be assured; it does not require that the ECN Nonce mechanism is employed to achieve this. Indeed, if integrity could be provided in another manner, a more accurate ECN feedback protocol might repurpose the nonce sum (NS) flag in the TCP header.
ECN Nonceの展開には既知の問題があるため、このドキュメントでは、より正確なECNフィードバックの整合性を保証できることのみを要求しています。これを達成するためにECN Nonceメカニズムを使用する必要はありません。実際、整合性を別の方法で提供できる場合、より正確なECNフィードバックプロトコルがTCPヘッダーのノンスサム（NS）フラグを再利用する可能性があります。
If the more accurate ECN feedback scheme provides sufficient information, the integrity check could be performed by, e.g., deterministically setting the CE in the sender and monitoring the respective feedback (similar to ECT(1) and the ECN Nonce sum). Whether a sender should enforce when it detects wrong feedback information, and what kind of enforcement it should apply, are policy issues that need not be specified as part of the more accurate ECN feedback signal scheme itself, but rather when specifying an update to core TCP mechanisms like congestion control that make use of the more accurate ECN signal.
より正確なECNフィードバックスキームが十分な情報を提供する場合、整合性チェックは、たとえば、送信者のCEを決定論的に設定し、それぞれのフィードバックを監視することで実行できます（ECT（1）およびECNノンスサムと同様）。送信者が誤ったフィードバック情報を検出したときに適用する必要があるかどうか、および適用する必要がある適用の種類は、より正確なECNフィードバック信号スキーム自体の一部として指定する必要はなく、むしろコアTCPへの更新を指定するときにポリシーの問題ですより正確なECN信号を利用する輻輳制御のようなメカニズム。
Accuracy Classic ECN feeds back one congestion notification per RTT; this is sufficient for classic TCP congestion control, which reduces the sending rate at most once per RTT. Thus, the more accurate ECN feedback scheme should ensure that, if a congestion episode occurs, at least one congestion notification is echoed and received per RTT as classic ECN would do. Of course, the goal of a more accurate ECN extension is to reconstruct the number of CE markings more accurately. In the best case, the new scheme should even allow reconstruction of the exact number of payload bytes that a CE-marked packet was carrying. However, it is accepted that it may be too complex for a sender to get the exact number of congestion markings or marked bytes in all situations. Ideally, the feedback scheme should preserve the order in which any (of the four) ECN signals were received. And, ideally, it would even be possible for the sender to determine which of the packets covered by one delayed ACK were congestion marked, e.g., if the flow consists of packets of different sizes, or to allow for future protocols where the order of the markings may be important.
Accuracy Classic ECNは、RTTごとに1つの輻輳通知をフィードバックします。これは、古典的なTCP輻輳制御には十分であり、RTTごとに最大で1回送信レートを低下させます。したがって、より正確なECNフィードバックスキームは、輻輳エピソードが発生した場合、従来のECNと同様に、RTTごとに少なくとも1つの輻輳通知がエコーされて受信されることを保証する必要があります。もちろん、より正確なECN拡張の目的は、CEマーキングの数をより正確に再構築することです。最良の場合、新しいスキームでは、CEマーク付きのパケットが伝送していたペイロードバイトの正確な数を再構築することもできます。ただし、送信者がすべての状況で正確な数の輻輳マーキングまたはマーク付きバイトを取得するのは複雑すぎる可能性があることは認められています。理想的には、フィードバック方式は、（4つのうちの）ECN信号が受信された順序を維持する必要があります。そして理想的には、送信者が1つの遅延ACKでカバーされたパケットのどれが輻輳マークされているかを判断することさえ可能です。たとえば、フローが異なるサイズのパケットで構成されている場合、または将来のプロトコルがマーキングが重要な場合があります。
In the best case, a sender that sees more accurate ECN feedback information would be able to reconstruct the occurrence of any of the four codepoints (Not-ECT, CE, ECT(0), ECT(1)). However, assuming the sender marks all data packets as ECN-capable and uses a default setting of ECT(0) (as with [RFC3168]), solely feeding back the occurrence of CE and ECT(1) might be sufficient. Because the sender can keep account of the transmitted segments with any of the three ECN codepoints, conveying any two of these back to the sender is sufficient for it to reconstruct the third as observed by the receiver. Thus, a more accurate ECN feedback scheme should at least provide information on two of these signals, e.g., CE and ECT(1).
最良の場合、より正確なECNフィードバック情報を確認できる送信者は、4つのコードポイント（Not-ECT、CE、ECT（0）、ECT（1））のいずれかの発生を再構築できます。ただし、送信者がすべてのデータパケットをECN対応としてマークし、デフォルト設定のECT（0）を使用すると（[RFC3168]のように）、CEとECT（1）の発生をフィードバックするだけで十分な場合があります。送信者は3つのECNコードポイントのいずれかで送信されたセグメントを保持できるため、これらのいずれか2つを送信者に戻すだけで、受信者が3番目のコードポイントを再構築できます。したがって、より正確なECNフィードバック方式は、これらの信号の2つ、たとえばCEとECT（1）に関する情報を少なくとも提供する必要があります。
If a more accurate ECN scheme can reliably deliver feedback in most but not all circumstances, ideally the scheme should at least not introduce bias. In other words, undetected loss of some ACKs should be as likely to increase as decrease the sender's estimate of the probability of ECN marking.
より正確なECNスキームがすべてではないがほとんどの状況で確実にフィードバックを提供できる場合、理想的には、スキームが少なくともバイアスを導入しないようにする必要があります。つまり、一部のACKの検出されない損失は、ECNマーキングの確率の送信者の推定を減少させるのと同じくらい増加する可能性があります。
Complexity Implementation should be as simple as possible, and only a minimum of additional state information should be needed. This will enable more accurate ECN feedback to be used as the default feedback mechanism, even if only one ECN feedback signal per RTT is needed.
複雑さの実装は可能な限りシンプルである必要があり、最小限の追加の状態情報のみが必要です。これにより、RTTごとにECNフィードバック信号が1つだけ必要な場合でも、より正確なECNフィードバックをデフォルトのフィードバックメカニズムとして使用できます。
Overhead A more accurate ECN feedback signal should limit the additional network load, because ECN feedback is ultimately not critical information (in the worst case, loss will still be available as a congestion signal of last resort). As feedback information has to be provided frequently and in a timely fashion, potentially all or a large fraction of TCP acknowledgements might carry this information. Ideally, no additional segments should be exchanged compared to a TCP session as specified in RFC 3168, and the overhead in each segment should be minimized.
オーバーヘッドECNフィードバックは最終的に重要な情報ではないため、より正確なECNフィードバック信号が追加のネットワーク負荷を制限する必要があります（最悪の場合、損失は最後の手段の輻輳信号として利用できます）。フィードバック情報は頻繁かつタイムリーに提供する必要があるため、TCP確認応答のすべてまたは大部分がこの情報を伝える可能性があります。理想的には、RFC 3168で指定されているTCPセッションと比較して追加のセグメントを交換しないでください。また、各セグメントのオーバーヘッドを最小限に抑える必要があります。
Backward and forward compatibility Given more accurate ECN feedback will involve a change to the TCP protocol, it should be negotiated between the two TCP endpoints. If either end does not support the more accurate feedback, they should both be able to fall back to classic ECN feedback.
後方互換性と前方互換性より正確なECNフィードバックにはTCPプロトコルの変更が含まれるため、2つのTCPエンドポイント間で交渉する必要があります。どちらかの端がより正確なフィードバックをサポートしない場合、どちらも従来のECNフィードバックにフォールバックできるはずです。
A more accurate ECN feedback extension should aim to traverse most middleboxes, including firewalls and Network Address Translators (NATs). Further, a feedback mechanism should provide a method to fall back to classic ECN signalling if the new signal is suppressed by certain middleboxes.
より正確なECNフィードバック拡張は、ファイアウォールやネットワークアドレス変換（NAT）を含むほとんどのミドルボックスを通過することを目的としています。さらに、フィードバックメカニズムは、新しい信号が特定のミドルボックスによって抑制された場合に、従来のECNシグナリングにフォールバックする方法を提供する必要があります。
In order to avoid a fork in the TCP protocol specifications, if experiments with the new ECN feedback protocol are successful, the intention is to eventually update RFC 3168 for any TCP/ECN sender, not just for ConEx or DCTCP senders. Then, future senders will be able to unilaterally deploy new behaviours that exploit the existence of more accurate ECN feedback in receivers (forward compatibility). Conversely, even if another sender only needs one ECN feedback signal per RTT, it should be able to use more accurate ECN feedback and simply ignore the excess information.
TCPプロトコル仕様の分岐を回避するために、新しいECNフィードバックプロトコルでの実験が成功した場合、ConExまたはDCTCP送信者だけでなく、TCP / ECN送信者のRFC 3168を最終的に更新することが意図されています。その後、将来の送信者は、受信者におけるより正確なECNフィードバックの存在を利用する新しい動作を一方的に展開できるようになります（前方互換性）。逆に、別の送信者がRTTごとに1つのECNフィードバック信号しか必要としない場合でも、より正確なECNフィードバックを使用して、過剰な情報を単に無視できるはずです。
Furthermore, the receiver should not make assumptions about the mechanism that was used to set the markings nor about any interpretation or reaction to the congestion signal. The receiver only needs to faithfully reflect congestion information back to the sender.
さらに、受信者は、マーキングを設定するために使用されたメカニズムについて、または輻輳信号に対する解釈または反応について仮定を行うべきではありません。受信者は輻輳情報を送信者に忠実に反映する必要があるだけです。
This section introduces some possible design approaches for TCP ECN feedback. The purpose of this section is to give examples of how trade-offs might be needed between the requirements, as input to future IETF work to specify a protocol. The order is not significant, and there is no intention to endorse any particular approach.
このセクションでは、TCP ECNフィードバックのいくつかの可能な設計アプローチを紹介します。このセクションの目的は、プロトコルを指定するための将来のIETF作業への入力として、要件間のトレードオフがどのように必要になるかを例示することです。順序は重要ではなく、特定のアプローチを推奨する意図はありません。
All approaches presented below (and proposed so far) are able to provide accurate ECN feedback information as long as no ACK loss occurs and the congestion rate is reasonable. In the case of a high ACK loss rate or very high congestion (CE-marking) rate, the proposed schemes have different resilience characteristics depending on the number of bits used for the encoding. While classic ECN provides reliable (but inaccurate) feedback of a maximum of one congestion signal per RTT, the proposed schemes do not implement an explicit acknowledgement mechanism for the feedback (as, e.g., the ECE/CWR exchange of [RFC3168]).
以下に示す（およびこれまでに提案した）すべてのアプローチは、ACK損失が発生せず、輻輳率が妥当である限り、正確なECNフィードバック情報を提供できます。高いACK損失率または非常に高い輻輳（CEマーキング）率の場合、提案された方式は、符号化に使用されるビット数に応じて異なる復元力特性を持っています。従来のECNは、RTTごとに最大1つの輻輳信号の信頼できる（ただし不正確な）フィードバックを提供しますが、提案されたスキームはフィードバックの明示的な確認応答メカニズムを実装していません（たとえば、[RFC3168]のECE / CWR交換など）。
Schemes in this category can additionally use the NS bit for capability negotiation during the TCP handshake exchange. Thus a more accurate ECN could be negotiated without changing the classic ECN negotiation and thus being backwards compatible.
このカテゴリのスキームは、TCPハンドシェイク交換中の機能ネゴシエーションにNSビットをさらに使用できます。したがって、従来のECNネゴシエーションを変更せずに下位互換性を維持することなく、より正確なECNをネゴシエートできます。
Schemes in this category can simply redefine the ECN header flags, ECE and CWR, to encode the occurrence of a CE marking at the receiver. This approach provides very limited resilience against loss of ACK, particularly pure ACKs (no payload and therefore delivered unreliably).
このカテゴリのスキームは、ECNヘッダーフラグ、ECEおよびCWRを再定義するだけで、受信側でのCEマーキングの発生をエンコードできます。このアプローチは、ACK、特に純粋なACKの損失に対する非常に限られた回復力を提供します（ペイロードがないため、信頼性の低い方法で配信されます）。
A couple of schemes have been proposed so far:
これまでにいくつかのスキームが提案されています。
o A naive 1-bit scheme that sends one ECE for each CE received could use CWR to increase robustness against ACK loss by introducing redundant information on the next ACK, but this is still vulnerable to ACK loss.
o 受信したCEごとに1つのECEを送信する単純な1ビットスキームでは、CWRを使用して、次のACKに冗長情報を導入することでACK損失に対する堅牢性を高めることができますが、これでもACK損失に対して脆弱です。
o The scheme defined for DCTCP [DCTCP], which toggles the ECE feedback on an immediate ACK whenever the CE marking changes, and otherwise feeds back delayed ACKs with the ECE value unchanged. Appendix A demonstrates that this scheme is still ambiguous to the sender if the ACKs are pure ACKs, and if some may have been lost.
o DCTCPのために定義されたスキーム[DCTCP]。CEマーキングが変更されるたびに即時ACKのECEフィードバックをトグルし、そうでなければECE値を変更せずに遅延ACKをフィードバックします。付録Aは、ACKが純粋なACKであり、一部が失われた可能性がある場合、このスキームが送信者にあいまいであることを示しています。
Alternatively, the receiver uses the three ECN/NS header flags, ECE, CWR, and NS, to represent a counter that signals the accumulated number of CE markings it has received. Resilience against loss is better than the flag-based schemes but may not suffice in the presence of extended ACK loss that otherwise would not affect the TCP sender's performance.
または、受信機は3つのECN / NSヘッダーフラグ、ECE、CWR、およびNSを使用して、受信したCEマーキングの累積数を通知するカウンターを表します。損失に対する回復力は、フラグベースのスキームよりも優れていますが、TCP送信者のパフォーマンスに影響を与えない拡張ACK損失が存在する場合は十分でない場合があります。
A number of coding schemes have been proposed so far in this category:
このカテゴリでは、これまでにいくつかのコーディング方式が提案されています。
o A 3-bit counter scheme continuously feeds back the three least significant bits of a CE counter;
o 3ビットカウンタースキームは、CEカウンターの最下位3ビットを継続的にフィードバックします。
o A scheme that defines a standardized lookup table to map the eight codepoints onto either a CE counter or an ECT(1) counter.
o 8つのコードポイントをCEカウンターまたはECT（1）カウンターにマップするための標準化されたルックアップテーブルを定義するスキーム。
These proposed schemes provide accumulated information on CE marking feedback, similar to the number of acknowledged bytes in the TCP header. Due to the limited number of bits, the ECN feedback information will wrap much more often than the acknowledgement field. Thus, feedback information could be lost due to a relatively small sequence of pure-ACK losses. Resilience could be increased by introducing redundancy, e.g., send each counter increase two or more times. Of course, any of these additional mechanisms will increase the complexity. If the congestion rate is greater than the ACK rate (multiplied by the number of congestion marks that can be signaled per ACK), the congestion information cannot correctly be fed back. Covering the worst case (where every packet is CE marked) can potentially be realized by dynamically adapting the ACK rate and redundancy. This again increases complexity and perhaps the signalling overhead as well. Schemes that do not repurpose the ECN NS bit could still support the ECN Nonce.
これらの提案されたスキームは、TCPヘッダーの確認済みバイト数と同様に、CEマーキングフィードバックに関する累積情報を提供します。ビット数が限られているため、ECNフィードバック情報は、確認応答フィールドよりもはるかに頻繁に折り返されます。したがって、純粋なACK損失のシーケンスが比較的小さいため、フィードバック情報が失われる可能性があります。レジリエンスは、冗長性を導入することで増加させることができます。たとえば、各カウンターの増加を2回以上送信します。もちろん、これらの追加のメカニズムはどれも複雑さを増します。輻輳レートがACKレート（ACKごとに通知できる輻輳マークの数を掛けたもの）よりも大きい場合、輻輳情報を正しくフィードバックできません。最悪のケース（すべてのパケットにCEマークが付けられている）をカバーすることは、ACKレートと冗長性を動的に調整することで実現できる可能性があります。これにより、複雑さが増し、おそらくシグナリングのオーバーヘッドも増加します。 ECN NSビットを再利用しないスキームでも、ECNナンスをサポートできます。
As seen in Figure 1, there are currently three unused flags in the TCP header. The proposed 3-bit counter or codepoint schemes could be extended by one or more bits to add higher resilience against ACK loss. The relative gain would be exponentially higher resilience against ACK loss, while the respective drawbacks would remain identical.
図1に示すように、TCPヘッダーには現在3つの未使用のフラグがあります。提案された3ビットのカウンターまたはコードポイントスキームは、1つ以上のビットによって拡張され、ACK損失に対する回復力を高めることができます。それぞれの欠点は同じままですが、相対的な利益はACK損失に対する指数関数的に高い回復力になります。
Alternatively, a new method could standardize the use of the bits in the Urgent Pointer field (see [RFC6093]) to signal more bits of its congestion signal counter, but only whenever the Urgent Flag is not set. As this is often the case, resilience could be increased without additional header overhead.
あるいは、新しい方法は、緊急フラグフィールドのビットの使用を標準化して（[RFC6093]を参照）、その輻輳信号カウンターのより多くのビットを通知することができますが、緊急フラグが設定されていない場合に限られます。これはよくあることですが、ヘッダーのオーバーヘッドを追加しなくても回復力を高めることができます。
Any proposal to use such bits would need to check the likelihood that some middleboxes might discard or 'normalize' the currently unused flag bits or a non-zero Urgent Pointer when the Urgent Flag is cleared. If during experimentation certain bits have been proven to be usable, the assignment of any of these bits would then require an IETF standards action.
このようなビットを使用する提案では、緊急フラグがクリアされているときに、一部のミドルボックスが現在未使用のフラグビットまたはゼロ以外の緊急ポインタを破棄または「正規化」する可能性を確認する必要があります。実験中に特定のビットが使用可能であることが判明した場合、これらのビットのいずれかの割り当てには、IETF標準アクションが必要になります。
Alternatively, a new TCP option could be introduced, to help maintain the accuracy and integrity of ECN feedback between receiver and sender. Such an option could provide higher resilience and even more information, e.g., as much as is provided by a proposal for SCTP that counts the number of CE marked packet [SCTP-ECN] since the last CWR was observed, or by ECN for RTP/UDP [RFC6679]. The latter explicitly provides the total number of packets during a connection where the IP ECN field is set to ECT(0), ECT(1), CE, or Not-ECT, as well as the number of lost packets. However, deploying new TCP options has its own challenges. Moreover, to actually achieve high resilience, this option would need to be carried by most or all ACKs as the receiver cannot know if and when ACKs may be dropped. Thus, this approach would introduce considerable signalling overhead even though ECN feedback is not extremely critical information (in the worst case, loss will still be available to provide a strong congestion feedback signal). Nevertheless, such a TCP option could be used in addition to a more accurate ECN feedback scheme in the TCP header or in addition to classic ECN, only when needed and when space is available.
または、受信者と送信者の間のECNフィードバックの正確さと完全性を維持するために、新しいTCPオプションを導入することもできます。このようなオプションは、たとえば最後のCWRが観測されてからのCEマーク付きパケット[SCTP-ECN]の数をカウントするSCTPの提案、またはRTP / ECN UDP [RFC6679]。後者は、IP ECNフィールドがECT（0）、ECT（1）、CE、またはNot-ECTに設定されている接続中のパケットの総数と、失われたパケットの数を明示的に提供します。ただし、新しいTCPオプションの導入には独自の課題があります。さらに、実際に高い復元力を実現するには、ACKが破棄されるかどうか、またいつ破棄されるかを受信機が知ることができないため、ほとんどまたはすべてのACKでこのオプションを実行する必要があります。したがって、このアプローチでは、ECNフィードバックが非常に重要な情報ではない場合でも、かなりのシグナリングオーバーヘッドが発生します（最悪の場合、強い輻輳フィードバック信号を提供するために損失が発生します）。それにもかかわらず、そのようなTCPオプションは、TCPヘッダーでのより正確なECNフィードバックスキームに加えて、または従来のECNに加えて、必要なときにスペースが利用できる場合にのみ使用できます。
ECN feedback information must only be used if the other information contained in a received TCP segment indicates that the congestion was genuinely part of the flow and not spoofed. That is, the normal TCP acceptance techniques have to be used to verify that the segment is part of the flow before returning any contained ECN information, and, similarly, ECN feedback is only accepted on valid ACKs.
ECNフィードバック情報は、受信TCPセグメントに含まれる他の情報が、輻輳がフローの一部であり、スプーフィングされていないことを示している場合にのみ使用する必要があります。つまり、通常のTCP受け入れ技術を使用して、含まれているECN情報を返す前にセグメントがフローの一部であることを確認する必要があります。同様に、ECNフィードバックは有効なACKでのみ受け入れられます。
Given ECN feedback is used as input for congestion control, the respective algorithm would not react appropriately if ECN feedback were lost and the resilience mechanism to recover it was inadequate. This resilience requirement is articulated in Section 4. However, it should be noted that ECN feedback is not the last resort against congestion collapse, because if there is insufficient response to ECN, loss will ensue, and TCP will still react appropriately to loss.
ECNフィードバックが輻輳制御の入力として使用される場合、ECNフィードバックが失われ、それを回復する回復力メカニズムが不十分である場合、それぞれのアルゴリズムは適切に反応しません。この回復力の要件はセクション4に明記されています。ただし、ECNフィードバックは、輻輳の崩壊に対する最後の手段ではないことに注意してください。ECNへの応答が不十分な場合、損失が発生し、TCPは引き続き適切に損失に反応します。
A receiver could suppress ECN feedback information leading to its connections consuming excess sender or network resources. This problem is similar to that seen with the classic ECN feedback scheme and should be addressed by integrity checking as required in Section 4.
受信者はECNフィードバック情報を抑制して、その接続が過剰な送信者またはネットワークリソースを消費するようにする可能性があります。この問題は、従来のECNフィードバックスキームで見られるものと同様であり、セクション4で必要とされる整合性チェックで対処する必要があります。
[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, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<http：// www。 rfc-editor.org/info/rfc3168>。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, DOI 10.17487/RFC3540, June 2003, <http://www.rfc-editor.org/info/rfc3540>.
[RFC3540] Spring、N.、Wetherall、D.、D。Ely、「Ronce Explicit Congestion Notification（ECN）Signaling with Nonces」、RFC 3540、DOI 10.17487 / RFC3540、2003年6月、<http：//www.rfc -editor.org/info/rfc3540>。
[DCTCP] Bensley, S., Eggert, L., and D. Thaler, "Microsoft's Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters", Work in Progress, draft-bensley-tcpm-dctcp-05, July 2015.
[DCTCP] Bensley、S.、Eggert、L。、およびD. Thaler、「MicrosoftのDatacenter TCP（DCTCP）：TCP Congestion Control for Datacenters」、Work in Progress、draft-bensley-tcpm-dctcp-05、2015年7月。
[ECN-BENEFITS] Fairhurst, G. and M. Welzl, "The Benefits of using Explicit Congestion Notification (ECN)", Work in Progress draft-ietf-aqm-ecn-benefits-06, July 2015.
[ECN-BENEFITS] Fairhurst、G。およびM. Welzl、「明示的な輻輳通知（ECN）を使用する利点」、Work in Progress draft-ietf-aqm-ecn-benefits-06、2015年7月。
[RFC896] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, DOI 10.17487/RFC0896, January 1984, <http://www.rfc-editor.org/info/rfc896>.
[RFC896] Nagle、J。、「IP / TCP Internetworksの輻輳制御」、RFC 896、DOI 10.17487 / RFC0896、1984年1月、<http://www.rfc-editor.org/info/rfc896>。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <http://www.rfc-editor.org/info/rfc2018>.
[RFC2018] Mathis、M.、Madhavi、J.、Floyd、S。、およびA. Romanow、「TCP選択的確認応答オプション」、RFC 2018、DOI 10.17487 / RFC2018、1996年10月、<http：//www.rfc- editor.org/info/rfc2018>。
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, December 2002, <http://www.rfc-editor.org/info/rfc3449>.
[RFC3449] Balakrishnan、H.、Padmanabhan、V.、Fairhurst、G。、およびM. Sooriyabandara、「ネットワークパスの非対称性のTCPパフォーマンスへの影響」、BCP 69、RFC 3449、DOI 10.17487 / RFC3449、2002年12月、<http： //www.rfc-editor.org/info/rfc3449>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<http://www.rfc-editor.org/info/ rfc5681>。
[RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding Acknowledgement Congestion Control to TCP", RFC 5690, DOI 10.17487/RFC5690, February 2010, <http://www.rfc-editor.org/info/rfc5690>.
[RFC5690] Floyd、S.、Arcia、A.、Ros、D。、およびJ. Iyengar、「Adding Acknowledgement Congestion Control Control to TCP」、RFC 5690、DOI 10.17487 / RFC5690、2010年2月、<http：// www。 rfc-editor.org/info/rfc5690>。
[RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, January 2011, <http://www.rfc-editor.org/info/rfc6093>.
[RFC6093] Gont、F。およびA. Yourtchenko、「TCP緊急メカニズムの実装について」、RFC 6093、DOI 10.17487 / RFC6093、2011年1月、<http://www.rfc-editor.org/info/rfc6093 >。
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6679] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「RTP over UDPの明示的輻輳通知（ECN）」、RFC 6679、DOI 10.17487 / RFC6679 、2012年8月、<http://www.rfc-editor.org/info/rfc6679>。
[RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., "Congestion Exposure (ConEx) Concepts and Use Cases", RFC 6789, DOI 10.17487/RFC6789, December 2012, <http://www.rfc-editor.org/info/rfc6789>.
[RFC6789] Briscoe、B。、編、Woundy、R。、編、およびA. Cooper、編、「Congestion Exposure（ConEx）Concepts and Use Cases」、RFC 6789、DOI 10.17487 / RFC6789、2012年12月、 <http://www.rfc-editor.org/info/rfc6789>。
[SCTP-ECN] Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream Control Transmission Protocol (SCTP)", Work in Progress, draft-stewart-tsvwg-sctpecn-05, January 2014.
[SCTP-ECN] Stewart、R.、Tuexen、M。、およびX. Dong、「ECN for Stream Control Transmission Protocol（SCTP）」、Work in Progress、draft-stewart-tsvwg-sctpecn-05、2014年1月。
[TEST-RCV] Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to Allow Senders to Identify Receiver Non-Compliance", Work in Progress, draft-moncaster-tcpm-rcv-cheat-03, July 2014.
[TEST-RCV] Moncaster、T.、Briscoco、B。、およびA. Jacquet、「送信者が受信者の非準拠を識別できるようにするTCPテスト」、進行中の作業、draft-moncaster-tcpm-rcv-cheat-03 、2014年7月。
As defined in [DCTCP], a DCTCP receiver feeds back ECE=0 on delayed ACKs as long as CE remains 0, and also immediately sends an ACK with ECE=0 when CE transitions to 1. Similarly, it continually feeds back ECE=1 on delayed ACKs while CE remains 1 and immediately feeds back ECE=1 when CE transitions to 0. A sender can unambiguously decode this scheme if there is never any ACK loss, and the sender assumes there will never be any ACK loss.
[DCTCP]で定義されているように、DCTCPレシーバーは、CEが0のままである限り、遅延ACKでECE = 0をフィードバックし、CEが1に移行するとすぐにECE = 0でACKを送信します。同様に、継続的にECE = 1をフィードバックしますCEが1のままで、CEが0に遷移するとすぐにECE = 1をフィードバックする遅延ACKです。ACK損失がまったくない場合、送信者はこのスキームを明確にデコードでき、送信者はACK損失がないと想定します。
The following two examples show that the feedback sequence becomes highly ambiguous to the sender if either of these conditions is broken. Below, '0' represents ECE=0, '1' represents ECE=1, and '.' represents a gap of one segment between delayed ACKs. Now imagine that the sender receives the following sequence of feedback on three pure ACKs:
次の2つの例は、これらの条件のいずれかが破られた場合、フィードバックシーケンスが送信者にとって非常にあいまいになることを示しています。以下では、「0」はECE = 0を表し、「1」はECE = 1を表し、「。」遅延ACK間の1セグメントのギャップを表します。ここで、送信者が3つの純粋なACKに関する次の一連のフィードバックを受信するとします。
0.0.0
０。０。０
When the receiver sent this sequence, it could have been any of the following four sequences:
受信者がこのシーケンスを送信したとき、次の4つのシーケンスのいずれかである可能性があります。
a. 0.0.0 (0 x CE)
a. 0.0.0（0 x CE）
b. 010.0 (1 x CE)
b. 010.0（1 x CE）
c. 0.010 (1 x CE)
c. 0.010（1 x CE）
d. 01010 (2 x CE)
d. 01010（2 x CE）
where any of the 1s represent a possible pure ACK carrying ECE feedback that could have been lost. If the sender guesses (a), it might be correct, or it might miss 1 or 2 congestion marks over 5 packets. Therefore, when confronted with this simple sequence (that is not contrived), a sender can guess that congestion might have been 0%, 20%, or 40%, but it doesn't know which.
ここで、1のいずれかは、失われた可能性のあるECEフィードバックを伝送する純粋なACKを表します。送信者が（a）を推測した場合、それが正しいか、5パケットで1つまたは2つの輻輳マークを見落とす可能性があります。したがって、この単純なシーケンス（不自然ではない）に直面した場合、送信者は輻輳が0％、20％、または40％であったと推測できますが、どちらであるかはわかりません。
Sequences with a longer gap (e.g., 0...0.0) become far more ambiguous. It helps a little if the sender knows the distance the receiver uses between delayed ACKs, and it helps a lot if the distance is 1, i.e., no delayed ACKs. However, even without delayed ACKs there will still be ambiguity whenever there are pure ACK losses.
ギャップが長いシーケンス（0 ... 0.0など）は、あいまいになります。送信者が受信者が遅延ACK間で使用する距離を知っている場合は少し役立ちます。距離が1の場合、つまり遅延ACKがない場合は役立ちます。ただし、遅延ACKがなくても、純粋なACK損失がある場合は常にあいまいになります。
Acknowledgements
謝辞
Thanks to Gorry Fairhurst for his review and for ideas on CE-based integrity checking and to Mohammad Alizadeh for suggesting the need to avoid bias.
彼のレビューとCEベースの整合性チェックに関するアイデアを提供してくれたGorry Fairhurstと、偏見を避ける必要性を示唆してくれたMohammad Alizadehに感謝します。
Bob Briscoe was partly funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700) and through the Trilogy 2 project (ICT-317756). The views expressed here are solely those of the authors, in the context of the mentioned funding projects.
Bob Briscoeは、インターネットトランスポートレイテンシの削減（RITE）プロジェクト（ICT-317700）とTrilogy 2プロジェクト（ICT-317756）を通じて、その第7フレームワークプログラムの下で欧州共同体から部分的に資金提供を受けました。ここで表明された見解は、言及された資金調達プロジェクトの文脈における、単に著者の見解です。
Authors' Addresses
著者のアドレス
Mirja Kuehlewind (editor) ETH Zurich Gloriastrasse 35 Zurich 8092 Switzerland
Mirja Kuehlewind（編集者）ETHチューリッヒGloriastrasse 35チューリッヒ8092スイス
Email: mirja.kuehlewind@tik.ee.ethz.ch
Richard Scheffenegger NetApp, Inc. Am Euro Platz 2 Vienna 1120 Austria
Richard Scheffenegger NetApp、Inc. Am Euro Platz 2 Vienna 1120 Austria
Phone: +43 1 3676811 3146
Email: rs@netapp.com
Bob Briscoe BT B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE United Kingdom
Bob Briscoe BT B54 / 77、Adastral Park Martlesham Heath Ipswich IP5 3REイギリス
Phone: +44 1473 645196
Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/