[要約] RFC 9768は、TCPにおけるより正確な明示的輻輳通知（AccECN）フィードバックメカニズムを規定する文書です。従来のRFC 3168ではRTTごとに1つのフィードバックしか送れませんでしたが、AccECNにより複数の信号をフィードバック可能にし、DCTCPやL4Sなどの最新の輻輳制御アルゴリズムに対応します。TCPヘッダーの予約ビットや既存フラグを再利用し、ミドルボックスとの互換性も考慮されています。
Internet Engineering Task Force (IETF) B. Briscoe
Request for Comments: 9768 Independent
Updates: 3168 M. Kühlewind
Category: Standards Track Ericsson
ISSN: 2070-1721 R. Scheffenegger
NetApp
April 2026
Explicit Congestion Notification (ECN) is a mechanism by which network nodes can mark IP packets instead of dropping them to indicate incipient congestion to the endpoints. Receivers with an ECN-capable transport protocol feed back this information to the sender. ECN was originally specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). More recently defined mechanisms like Congestion Exposure (ConEx), Data Center TCP (DCTCP), or Low Latency, Low Loss, and Scalable Throughput (L4S) need more accurate ECN feedback information whenever more than one marking is received in one RTT. This document updates the original ECN specification defined in RFC 3168 by specifying a scheme that provides more than one feedback signal per RTT in the TCP header, called More Accurate ECN (AccECN). Given TCP header space is scarce, it allocates a reserved header bit previously assigned to the ECN-nonce. It also overloads the two existing ECN flags in the TCP header. The resulting extra space is additionally exploited to feed back the IP-ECN field received during the TCP connection establishment. Supplementary feedback information can optionally be provided in two new TCP Option alternatives, which are never used on the TCP SYN. The document also specifies the treatment of this updated TCP wire protocol by middleboxes.
明示的輻輳通知 (ECN) は、ネットワーク ノードが IP パケットをドロップする代わりにマークして、初期の輻輳をエンドポイントに示すことができるメカニズムです。ECN 対応のトランスポート プロトコルを備えた受信者は、この情報を送信者にフィードバックします。ECN は元々、往復時間 (RTT) ごとに 1 つのフィードバック信号のみを送信できるように TCP 用に仕様化されました。Congestion Exposure (ConEx)、Data Center TCP (DCTCP)、または Low Latency, Low Loss, and Scalable Throughput (L4S) などの最近定義されたメカニズムでは、1 つの RTT で複数のマーキングが受信されるたびに、より正確な ECN フィードバック情報が必要になります。この文書は、More Accurate ECN (AccECN) と呼ばれる、TCP ヘッダー内の RTT ごとに複数のフィードバック信号を提供するスキームを指定することにより、RFC 3168 で定義された元の ECN 仕様を更新します。TCP ヘッダー スペースが不足している場合、以前に ECN-nonce に割り当てられていた予約済みヘッダー ビットが割り当てられます。また、TCP ヘッダー内の 2 つの既存の ECN フラグもオーバーロードします。結果として生じる余分なスペースは、TCP 接続の確立中に受信した IP-ECN フィールドをフィードバックするためにさらに利用されます。補足フィードバック情報は、TCP SYN では決して使用されない 2 つの新しい TCP オプションの選択肢でオプションで提供できます。この文書では、ミドルボックスによるこの更新された TCP ワイヤ プロトコルの処理についても規定しています。
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/rfc9768.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9768 で入手できます。
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 ライセンスに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この文書には、2008 年 11 月 10 日より前に発行または一般公開された IETF 文書または IETF 寄稿の資料が含まれている場合があります。この資料の一部の著作権を管理している人物は、IETF 標準プロセス外でそのような資料の変更を許可する権利を IETF トラストに付与していない可能性があります。かかる資料の著作権を管理する者から適切なライセンスを取得しない限り、この文書を IETF 標準プロセスの外で変更することはできません。また、RFC として出版するための形式にするか、英語以外の言語に翻訳する場合を除き、IETF 標準プロセスの外でその派生著作物を作成することはできません。
1. Introduction
1.1. Document Roadmap
1.2. Goals
1.3. Terminology
1.4. Recap of Existing ECN Feedback in IP/TCP
2. AccECN Protocol Overview and Rationale
2.1. Capability Negotiation
2.2. Feedback Mechanism
2.3. Delayed ACKs and Resilience Against ACK Loss
2.4. Feedback Metrics
2.5. Generic (Mechanistic) Reflector
3. AccECN Protocol Specification
3.1. Negotiating to Use AccECN
3.1.1. Negotiation During the TCP Three-Way Handshake
3.1.2. Backward Compatibility
3.1.3. Forward Compatibility
3.1.4. Multiple SYNs or SYN/ACKs
3.1.4.1. Retransmitted SYNs
3.1.4.2. Retransmitted SYN/ACKs
3.1.5. Implications of AccECN Mode
3.2. AccECN Feedback
3.2.1. Initialization of Feedback Counters
3.2.2. The ACE Field
3.2.2.1. ACE Field on the ACK of the SYN/ACK
3.2.2.2. Encoding and Decoding Feedback in the ACE Field
3.2.2.3. Testing for Mangling of the IP/ECN Field
3.2.2.4. Testing for Zeroing of the ACE Field
3.2.2.5. Safety Against Ambiguity of the ACE Field
3.2.3. The AccECN Option
3.2.3.1. Encoding and Decoding Feedback in the AccECN Option
Fields
3.2.3.2. Path Traversal of the AccECN Option
3.2.3.3. Usage of the AccECN TCP Option
3.3. AccECN Compliance Requirements for TCP Proxies, Offload
Engines, and Other Middleboxes
3.3.1. Requirements for TCP Proxies
3.3.2. Requirements for Transparent Middleboxes and TCP
Normalizers
3.3.3. Requirements for TCP ACK Filtering
3.3.4. Requirements for TCP Segmentation Offload and Large
Receive Offload
4. Updates to RFC 3168
5. Interaction with TCP Variants
5.1. Compatibility with SYN Cookies
5.2. Compatibility with TCP Experiments and Common TCP Options
5.3. Compatibility with Feedback Integrity Mechanisms
6. Summary: Protocol Properties
7. IANA Considerations
8. Security and Privacy Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Example Algorithms
A.1. Example Algorithm to Encode/Decode the AccECN Option
A.2. Example Algorithm for Safety Against Long Sequences of ACK
Loss
A.2.1. Safety Algorithm Without the AccECN Option
A.2.2. Safety Algorithm With the AccECN Option
A.3. Example Algorithm to Estimate Marked Bytes from Marked
Packets
A.4. Example Algorithm to Count Not-ECT Bytes
Appendix B. Rationale for Usage of TCP Header Flags
B.1. Three TCP Header Flags in the SYN-SYN/ACK Handshake
B.2. Four Codepoints in the SYN/ACK
B.3. Space for Future Evolution
Acknowledgements
Authors' Addresses
Explicit Congestion Notification (ECN) [RFC3168] is a mechanism by which network nodes can mark IP packets instead of dropping them to indicate incipient congestion to the endpoints. Receivers with an ECN-capable transport protocol feed back this information to the sender. In RFC 3168, ECN was specified for TCP in such a way that only one feedback signal could be transmitted per Round-Trip Time (RTT). This is sufficient for congestion control schemes like Reno [RFC5681] and CUBIC [RFC9438], as those schemes reduce their congestion window by a fixed factor if congestion occurs within an RTT independent of the number of received congestion markings. More recently defined mechanisms like Congestion Exposure (ConEx [RFC7713]), DCTCP [RFC8257], and L4S [RFC9330] need to know when more than one marking is received in one RTT, which is information that cannot be provided by the feedback scheme as specified in [RFC3168]. This document specifies an update to the ECN feedback scheme of RFC 3168 that provides more accurate information and could be used by these and potentially other future TCP extensions, while still also supporting the pre-existing TCP congestion controllers that use just one feedback signal per round. Congestion control is the term the IETF uses to describe data rate management. It is the algorithm that a sender uses to optimize its sending rate so that it transmits data as fast as the network can carry it, but no faster. A fuller description of the motivation for this specification is given in the associated requirements document [RFC7560].
Explicit Congestion Notice (ECN) [RFC3168] は、ネットワーク ノードが IP パケットをドロップするのではなくマークして、エンドポイントに初期の輻輳を示すことができるメカニズムです。ECN 対応のトランスポート プロトコルを備えた受信者は、この情報を送信者にフィードバックします。RFC 3168 では、往復時間 (RTT) ごとに 1 つのフィードバック信号のみを送信できるように、TCP に対して ECN が指定されました。Reno [RFC5681] や CUBIC [RFC9438] のような輻輳制御方式では、受信した輻輳マーキングの数に関係なく、RTT 内で輻輳が発生した場合に輻輳ウィンドウが固定係数で縮小されるため、これは十分です。Congestion Exposure (ConEx [RFC7713])、DCTCP [RFC8257]、L4S [RFC9330] などの最近定義されたメカニズムは、1 つの RTT で複数のマーキングが受信されたときを知る必要があります。これは、[RFC3168] で指定されているフィードバック スキームでは提供できない情報です。この文書は、より正確な情報を提供する RFC 3168 の ECN フィードバック スキームの更新を規定しており、これらの拡張機能や将来の他の TCP 拡張機能で使用できると同時に、ラウンドごとに 1 つのフィードバック信号のみを使用する既存の TCP 輻輳コントローラもサポートします。輻輳制御は、IETF がデータ レート管理を説明するために使用する用語です。これは、送信者が送信速度を最適化するために使用するアルゴリズムで、ネットワークが伝送できる速度と同じ速度でデータを送信しますが、それ以上の速度ではデータを送信しません。この仕様の動機の詳細な説明は、関連する要件文書 [RFC7560] に記載されています。
This document specifies a Standards Track scheme for ECN feedback in the TCP header to provide more than one feedback signal per RTT. It is called the "more Accurate ECN feedback" scheme, or AccECN for short. This document updates RFC 3168 with respect to negotiation and use of the feedback scheme for TCP. All aspects of RFC 3168 other than the TCP feedback scheme and its negotiation remain unchanged by this specification. In particular, the definition of ECN at the IP layer is unaffected. Section 4 details the aspects of RFC 3168 that are updated by this document.
この文書は、RTT ごとに複数のフィードバック信号を提供するために、TCP ヘッダー内の ECN フィードバックの標準トラック スキームを指定します。これは、「より正確な ECN フィードバック」スキーム、または略して AccECN と呼ばれます。この文書は、TCP のフィードバック スキームのネゴシエーションと使用に関して RFC 3168 を更新します。TCP フィードバック スキームとそのネゴシエーション以外の RFC 3168 のすべての側面は、この仕様によって変更されません。特に、IP 層での ECN の定義は影響を受けません。セクション 4 では、この文書によって更新される RFC 3168 の側面について詳しく説明します。
This document uses the term "Classic ECN feedback" when it needs to distinguish the TCP/ECN feedback scheme defined in [RFC3168] from the AccECN TCP feedback scheme. AccECN is intended to offer a complete replacement for Classic TCP/ECN feedback, not a fork in the design of TCP. AccECN feedback complements TCP's loss feedback and it can coexist alongside hosts using Classic TCP/ECN feedback. So its applicability is intended to include the public Internet as well as private IP networks such as data centres (and even any non-IP networks over which TCP is used), whether or not any nodes on the path support ECN, of whatever flavour.
この文書では、[RFC3168] で定義されている TCP/ECN フィードバック スキームと AccECN TCP フィードバック スキームを区別する必要がある場合、「クラシック ECN フィードバック」という用語を使用します。AccECN は、TCP 設計のフォークではなく、Classic TCP/ECN フィードバックの完全な代替品を提供することを目的としています。AccECN フィードバックは TCP の損失フィードバックを補完し、クラシック TCP/ECN フィードバックを使用するホストと共存できます。したがって、その適用範囲は、パス上のノードが ECN をサポートしているかどうかに関係なく、パブリック インターネットだけでなく、データ センターなどのプライベート IP ネットワーク (さらには TCP が使用される非 IP ネットワークも) を含むことを目的としています。
AccECN feedback overloads the two existing ECN flags in the TCP header and allocates the currently reserved flag (previously called NS) in the TCP header to be used as one 3-bit counter field for feeding back the number of packets marked as congestion experienced (CE). Given the new definitions of these three bits, both ends have to support the new wire protocol before it can be used. Therefore, during the TCP handshake, the two ends use these three bits in the TCP header to negotiate the most advanced feedback protocol that they can both support, in a way that is backward compatible with [RFC3168].
AccECN フィードバックは、TCP ヘッダー内の 2 つの既存の ECN フラグをオーバーロードし、TCP ヘッダー内で現在予約されているフラグ (以前は NS と呼ばれていた) を割り当て、輻輳が発生した (CE) とマークされたパケットの数をフィードバックするための 1 つの 3 ビット カウンタ フィールドとして使用します。これら 3 ビットの新しい定義を考慮すると、使用する前に両端が新しいワイヤ プロトコルをサポートする必要があります。したがって、TCP ハンドシェイク中に、両端は TCP ヘッダー内のこれら 3 ビットを使用して、[RFC3168] と下位互換性のある方法で、両方がサポートできる最も高度なフィードバック プロトコルをネゴシエートします。
AccECN is solely a change to the TCP wire protocol; it covers the negotiation and signaling of more Accurate ECN feedback from a TCP Data Receiver to a Data Sender. It is completely independent of how TCP might respond to congestion feedback, which is out of scope, but ultimately the motivation for Accurate ECN feedback. Like Classic ECN feedback, AccECN can be used by standard Reno or CUBIC congestion control [RFC5681] [RFC9438] to respond to the existence of at least one congestion notification within a round trip. Or, unlike Reno or CUBIC, AccECN can be used to respond to the extent of congestion notification over a round trip, as for example DCTCP does in controlled environments [RFC8257]. For congestion response, this specification refers to the original ECN specification adopted in 2001 [RFC3168], as updated by the more relaxed rules introduced in 2018 to allow ECN experiments [RFC8311], namely: a TCP-based Low Latency Low Loss Scalable (L4S) congestion control [RFC9330]; or Alternative Backoff with ECN (ABE) [RFC8511].
AccECN は単に TCP ワイヤ プロトコルの変更です。TCP データ受信者からデータ送信者へのより正確な ECN フィードバックのネゴシエーションとシグナリングについて説明します。これは、TCP が輻輳フィードバックにどのように応答するかとは完全に独立しており、これは範囲外ですが、最終的には正確な ECN フィードバックの動機となります。Classic ECN フィードバックと同様に、AccECN は標準 Reno または CUBIC 輻輳制御 [RFC5681] [RFC9438] によって使用され、ラウンドトリップ内の少なくとも 1 つの輻輳通知の存在に応答できます。あるいは、Reno や CUBIC とは異なり、AccECN は、たとえば DCTCP が制御された環境で行うように、往復にわたる輻輳通知の範囲に応答するために使用できます [RFC8257]。輻輳応答に関して、この仕様は、2001 年に採用されたオリジナルの ECN 仕様 [RFC3168] を参照し、ECN 実験 [RFC8311] を許可するために 2018 年に導入されたより緩和されたルールによって更新されました。または ECN による代替バックオフ (ABE) [RFC8511]。
Section 5.2 explains how AccECN is compatible with current commonly used TCP Options, and a number of current experimental modifications to TCP, as well as SYN cookies.
セクション 5.2 では、AccECN が現在一般的に使用されている TCP オプションとどのように互換性があるか、TCP および SYN Cookie に対する現在の実験的な変更の多くについて説明します。
The following introductory section outlines the goals of AccECN (Section 1.2). Then, terminology is defined (Section 1.3) and a recap of existing prerequisite technology is given (Section 1.4).
次の導入セクションでは、AccECN の目標の概要を説明します (セクション 1.2)。次に、用語が定義され (セクション 1.3)、既存の前提条件となるテクノロジの概要が示されます (セクション 1.4)。
Section 2 gives an informative overview of the AccECN protocol. Then Section 3 gives the normative protocol specification, and Section 3.3 collects requirements for proxies, offload engines, and other middleboxes. Section 4 clarifies which aspects of RFC 3168 are updated by AccECN. Section 5 assesses the interaction of AccECN with commonly used variants of TCP, whether they are standardized or not. Then Section 6 summarizes the features and properties of AccECN.
セクション 2 では、AccECN プロトコルの有益な概要を説明します。次に、セクション 3 で標準的なプロトコル仕様を示し、セクション 3.3 でプロキシ、オフロード エンジン、およびその他のミドルボックスの要件を収集します。セクション 4 では、RFC 3168 のどの側面が AccECN によって更新されるかを明確にします。セクション 5 では、標準化されているかどうかに関係なく、AccECN と一般的に使用される TCP のバリアントとの相互作用を評価します。次にセクション 6 では、AccECN の機能と特性を要約します。
Section 7 summarizes the protocol fields and numbers that IANA assigned, and Section 8 points to the aspects of the protocol that will be of interest to the security community.
セクション 7 では、IANA が割り当てたプロトコルのフィールドと番号を要約し、セクション 8 では、セキュリティ コミュニティが関心を持つであろうプロトコルの側面を示します。
Appendix A gives pseudocode examples for the various algorithms that AccECN uses, and Appendix B explains why AccECN uses flags in the main TCP header and quantifies the space left for future use.
付録 A では、AccECN が使用するさまざまなアルゴリズムの擬似コードの例を示し、付録 B では、AccECN がメイン TCP ヘッダーでフラグを使用し、将来の使用のために残されたスペースを定量化する理由について説明します。
[RFC7560] enumerates requirements that a candidate feedback scheme needs to satisfy, under the headings: resilience, timeliness, integrity, accuracy (including ordering and lack of bias), complexity, overhead, and compatibility (both backward and forward). It recognizes that a perfect scheme that fully satisfies all the requirements is unlikely and tradeoffs between requirements are likely. Section 6 assesses the properties of AccECN against these requirements and discusses the tradeoffs.
[RFC7560] は、候補フィードバックスキームが満たすべき要件を、復元力、適時性、完全性、精度 (順序付けとバイアスの欠如を含む)、複雑さ、オーバーヘッド、および互換性 (後方および前方の両方) という項目で列挙しています。すべての要件を完全に満たす完璧なスキームが実現する可能性は低く、要件間のトレードオフが発生する可能性が高いことを認識しています。セクション 6 では、これらの要件に照らして AccECN の特性を評価し、トレードオフについて説明します。
The requirements document recognizes that a protocol as ubiquitous as TCP needs to be able to serve as-yet-unspecified requirements. Therefore, an AccECN receiver acts as a generic (mechanistic) reflector of congestion information with the aim that new sender behaviours can be deployed unilaterally in the future (see Section 2.5).
要件文書では、TCP のようなユビキタスなプロトコルは、まだ特定されていない要件に対応できる必要があると認識しています。したがって、AccECN 受信機は、将来的に新しい送信者の動作を一方的に展開できるようにすることを目的として、輻輳情報の一般的な (機構的な) リフレクターとして機能します (セクション 2.5 を参照)。
AccECN:
ACCECN:
The more Accurate ECN feedback scheme.
より正確な ECN フィードバック スキーム。
Classic ECN:
クラシック ECN:
The ECN protocol specified in [RFC3168].
[RFC3168]で規定されているECNプロトコル。
Classic ECN feedback:
従来の ECN フィードバック:
The feedback aspect of the ECN protocol specified in [RFC3168], including generation, encoding, transmission and decoding of feedback, but not the Data Sender's subsequent response to that feedback.
[RFC3168] で指定されている ECN プロトコルのフィードバック側面。フィードバックの生成、符号化、送信、復号化が含まれますが、そのフィードバックに対するデータ送信者のその後の応答は含まれません。
ACK:
ACK:
A TCP acknowledgement, with or without a data payload (ACK=1).
データ ペイロードの有無にかかわらず、TCP 確認応答 (ACK=1)。
Pure ACK:
純粋なACK:
A TCP acknowledgement without a data payload.
データ ペイロードのない TCP 確認応答。
Acceptable packet / segment:
受け入れ可能なパケット/セグメント:
A packet or segment that passes the acceptability tests in [RFC9293] and [RFC5961], or that has passed other tests with equivalent protection.
[RFC9293] および [RFC5961] の受け入れテストに合格するか、同等の保護を備えた他のテストに合格したパケットまたはセグメント。
TCP Client:
TCP クライアント:
The TCP stack that originates a connection (the initiator).
接続を開始する TCP スタック (イニシエーター)。
TCP Server:
TCPサーバー:
The TCP stack that responds to a connection request (the listener).
接続要求に応答する TCP スタック (リスナー)。
Three-way handshake:
スリーウェイハンドシェイク:
The procedure used to establish a TCP connection as described in the TCP protocol specification [RFC9293].
TCP プロトコル仕様 [RFC9293] に記載されている、TCP 接続を確立するために使用される手順。
Data Receiver:
データ受信者:
The endpoint of a TCP half-connection that receives data and sends AccECN feedback.
データを受信し、AccECN フィードバックを送信する TCP ハーフ接続のエンドポイント。
Data Sender:
データ送信者:
The endpoint of a TCP half-connection that sends data and receives AccECN feedback.
データを送信し、AccECN フィードバックを受信する TCP ハーフ接続のエンドポイント。
In a mild abuse of terminology, this document sometimes refers to 'TCP packets' instead of 'TCP segments'.
用語の軽度の乱用により、このドキュメントでは「TCP セグメント」ではなく「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] で説明されているように解釈されます。
Explicit Congestion Notification (ECN) [RFC3168] can be split into two parts conceptually. In the forward direction, alongside the data stream, it uses a 2-bit field in the IP header. This is referred to as IP ECN later on. This signal carried in the IP (Layer 3) header is exposed to network devices, which can modify it when they start to experience congestion (see Table 1). The second part is the feedback mechanism, by which the data receiver notifies the current congestion state to the original data sender of the intermediate path. That returned signal is carried in a transport-protocol-specific manner, and is not to be modified by intermediate network devices. While ECN is in active use for protocols such as QUIC [RFC9000], SCTP [RFC9260], RTP [RFC6679], and Remote Direct Memory Access over Converged Ethernet [RoCEv2], this document only concerns itself with the specific implementation for the TCP protocol.
Explicit Congestion Notice (ECN) [RFC3168] は、概念的に 2 つの部分に分割できます。順方向では、データ ストリームと並行して、IP ヘッダーの 2 ビット フィールドが使用されます。これは、後で IP ECN と呼ばれます。IP (レイヤ 3) ヘッダーで伝送されるこの信号はネットワーク デバイスに公開され、輻輳が発生し始めると信号が変更される可能性があります (表 1 を参照)。2 番目の部分はフィードバック メカニズムで、データ受信者が現在の輻輳状態を中間パスの元のデータ送信者に通知します。返された信号はトランスポート プロトコル固有の方法で伝送され、中間のネットワーク デバイスによって変更されることはありません。ECN は QUIC [RFC9000]、SCTP [RFC9260]、RTP [RFC6679]、リモート ダイレクト メモリ アクセス オーバー コンバージド イーサネット [RoCEv2] などのプロトコルで積極的に使用されていますが、この文書は TCP プロトコルの特定の実装のみを対象としています。
Once ECN has been negotiated for a transport layer connection, the Data Sender for either half-connection can set two possible codepoints (ECT(0) or ECT(1)) in the IP header of a data packet to indicate an ECN-capable transport (ECT). If the ECN codepoint is 0b00, the packet is considered to have been sent by a Not ECN-capable Transport (Not-ECT). When a network node experiences congestion, it will occasionally either drop or mark a packet, with the choice depending on the packet's ECN codepoint. If the codepoint is Not-ECT, only drop is appropriate. If the codepoint is ECT(0) or ECT(1), the node can mark the packet by setting the ECN codepoint to 0b11, which is termed 'Congestion Experienced' (CE), or loosely a 'congestion mark'. Table 1 summarises these codepoints.
トランスポート層接続に対して ECN がネゴシエートされると、どちらかのハーフ接続のデータ送信者は、データ パケットの IP ヘッダーに 2 つの可能なコードポイント (ECT(0) または ECT(1)) を設定して、ECN 対応トランスポート (ECT) を示すことができます。ECN コードポイントが 0b00 の場合、パケットは ECN 対応ではないトランスポート (Not-ECT) によって送信されたものとみなされます。ネットワーク ノードで輻輳が発生すると、パケットをドロップするかマークを付けることがあり、その選択はパケットの ECN コードポイントに応じて行われます。コードポイントが Not-ECT の場合、ドロップのみが適切です。コードポイントが ECT(0) または ECT(1) の場合、ノードは ECN コードポイントを 0b11 に設定することでパケットにマークを付けることができます。これは、「輻輳経験」 (CE)、または大まかに「輻輳マーク」と呼ばれます。表 1 は、これらのコードポイントをまとめたものです。
+==================+================+===========================+
| IP-ECN Codepoint | Codepoint Name | Description |
+==================+================+===========================+
| 0b00 | Not-ECT | Not ECN-Capable Transport |
+------------------+----------------+---------------------------+
| 0b01 | ECT(1) | ECN-Capable Transport (1) |
+------------------+----------------+---------------------------+
| 0b10 | ECT(0) | ECN-Capable Transport (0) |
+------------------+----------------+---------------------------+
| 0b11 | CE | Congestion Experienced |
+------------------+----------------+---------------------------+
Table 1: The ECN Field in the IP Header
表 1: IP ヘッダーの ECN フィールド
In the TCP header, the first two bits in byte 14 (the TCP header flags at bit offsets 8 and 9 labelled Congestion Window Reduced (CWR) and Explicit Congestion notification Echo (ECE) in Figure 1) are defined as flags for the use of Classic ECN [RFC3168]. A TCP Client indicates that it supports Classic ECN feedback by setting (CWR,ECE) = (1,1) in the SYN, and an ECN-enabled TCP Server confirms Classic ECN support by setting (CWR,ECE) = (0,1) in the SYN/ACK. On reception of a CE-marked packet at the IP layer, the Data Receiver for that half-connection starts to set the Echo Congestion Experienced (ECE) flag continuously in the TCP header of ACKs, which gives the signal resilience to loss or reordering of ACKs. The Data Sender for the same half-connection confirms that it has received at least one ECE signal by responding with the CWR flag, which allows the Data Receiver to stop repeating the ECN-Echo flag. This always leads to a full RTT of ACKs with ECE set. Thus Classic ECN cannot feed back any additional CE markings arriving within this RTT.
TCP ヘッダーでは、バイト 14 の最初の 2 ビット (図 1 の、ビット オフセット 8 および 9 にある輻輳ウィンドウ削減 (CWR) および明示的輻輳通知エコー (ECE) とラベル付けされた TCP ヘッダー フラグ) は、クラシック ECN [RFC3168] を使用するためのフラグとして定義されています。TCP クライアントは、SYN で (CWR,ECE) = (1,1) を設定することでクラシック ECN フィードバックをサポートしていることを示し、ECN 対応の TCP サーバーは SYN/ACK で (CWR,ECE) = (0,1) を設定することでクラシック ECN サポートを確認します。IP 層で CE マークが付けられたパケットを受信すると、その半接続のデータ受信側は、ACK の TCP ヘッダーに Echo Congestion Experienced (ECE) フラグを継続的に設定し始めます。これにより、ACK の損失または並べ替えに対する信号の回復力が与えられます。同じハーフ接続のデータ送信側は、CWR フラグで応答することで少なくとも 1 つの ECE 信号を受信したことを確認します。これにより、データ受信側は ECN-Echo フラグの繰り返しを停止できます。これにより、常に ECE が設定された ACK の完全な RTT が発生します。したがって、クラシック ECN は、この RTT 内に到着する追加の CE マーキングをフィードバックできません。
The last bit in byte 13 of the TCP header (the TCP header flag at bit offset 7 in Figure 1) was defined as the Nonce Sum (NS) for the ECN-nonce [RFC3540]. In the absence of widespread deployment, RFC 3540 was reclassified as Historic [RFC8311] and the respective flag was marked as "Reserved", which made this TCP flag available for use by AccECN instead.
TCP ヘッダーのバイト 13 の最後のビット (図 1 のビット オフセット 7 の TCP ヘッダー フラグ) は、ECN-nonce [RFC3540] の Nonce Sum (NS) として定義されました。広範な展開がなかったため、RFC 3540 はヒストリック [RFC8311] として再分類され、それぞれのフラグは「予約済み」としてマークされ、代わりにこの TCP フラグが AccECN で使用できるようになりました。
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: TCP Header Flags as Defined Before the Nonce Sum Flag Reverted to Reserved
図 1: Nonce Sum フラグが予約済みに戻る前に定義された TCP ヘッダー フラグ
This section provides an informative overview of the AccECN protocol that is normatively specified in Section 3.
このセクションでは、セクション 3 で規範的に規定されている AccECN プロトコルの有益な概要を説明します。
Like the general TCP approach, the Data Receiver of each TCP half-connection sends AccECN feedback to the Data Sender on TCP acknowledgements, reusing data packets of the other half-connection whenever possible.
一般的な TCP アプローチと同様に、各 TCP ハーフ接続のデータ受信側は、TCP 確認応答に関する AccECN フィードバックをデータ送信側に送信し、可能な限り他のハーフ接続のデータ パケットを再利用します。
The AccECN protocol has had to be designed in two parts:
AccECN プロトコルは 2 つの部分で設計する必要がありました。
* an essential feedback part that reuses the TCP-ECN header bits for the Data Receiver to feed back the number of packets arriving with CE in the IP-ECN field. This provides more accuracy than Classic ECN feedback, but limited resilience against ACK loss.
* データ受信側の TCP-ECN ヘッダー ビットを再利用して、IP-ECN フィールドの CE とともに到着するパケットの数をフィードバックする重要なフィードバック部分です。これにより、従来の ECN フィードバックよりも高い精度が得られますが、ACK 損失に対する復元力は限られています。
* a supplementary feedback part using one of two new alternative AccECN TCP Options that provide additional feedback on the number of payload bytes that arrive marked with each of the three ECN codepoints in the IP-ECN field (not just CE marks). See the BCP on Byte and Packet Congestion Notification [RFC7141] for the rationale determining that conveying congested payload bytes should be preferred over just providing feedback about congested packets. This also provides greater resilience against ACK loss than the essential feedback, but it is currently more likely to suffer from middlebox interference.
* 2 つの新しい代替 AccECN TCP オプションの 1 つを使用する補足フィードバック部分。IP-ECN フィールド内の 3 つの ECN コードポイント (CE マークだけでなく) のそれぞれでマークされた到着ペイロード バイト数に関する追加フィードバックを提供します。輻輳したパケットに関するフィードバックを提供するだけよりも、輻輳したペイロード バイトを伝達することが優先されるべきであると判断する根拠については、バイトおよびパケット輻輳通知に関する BCP [RFC7141] を参照してください。これにより、必須のフィードバックよりも ACK 損失に対する耐性が高くなりますが、現時点ではミドルボックス干渉の影響を受ける可能性が高くなります。
The two part design was necessary, given limitations on the space available for TCP Options and given the possibility that certain incorrectly designed middleboxes might prevent TCP from using any new options.
TCP オプションに使用できるスペースに制限があること、および特定の不適切に設計されたミドルボックスによって TCP が新しいオプションを使用できない可能性があることを考慮すると、2 つの部分からなる設計が必要でした。
The essential feedback part overloads the previous definition of the three flags in the TCP header that had been assigned for use by Classic ECN. This design choice deliberately allows AccECN peers to replace the Classic ECN feedback protocol, rather than leaving Classic ECN feedback intact and adding more accurate feedback separately because:
重要なフィードバック部分は、Classic ECN で使用するために割り当てられていた TCP ヘッダー内の 3 つのフラグの以前の定義をオーバーロードします。この設計選択により、クラシック ECN フィードバックをそのままにして、より正確なフィードバックを個別に追加するのではなく、AccECN ピアがクラシック ECN フィードバック プロトコルを意図的に置き換えることができます。その理由は次のとおりです。
* this efficiently reuses scarce TCP header space, given TCP Option space is approaching saturation;
* TCP オプション スペースが飽和に近づいていることを考慮すると、これにより、希少な TCP ヘッダー スペースが効率的に再利用されます。
* a single upgrade path for the TCP protocol is preferable to a fork in the design that modifies the TCP header to convey all ECN feedback;
* すべての ECN フィードバックを伝えるために TCP ヘッダーを変更する設計のフォークよりも、TCP プロトコルの単一アップグレード パスの方が望ましいです。
* otherwise, Classic and Accurate ECN feedback could give conflicting feedback about the same segment, which could open up new security concerns and make implementations unnecessarily complex;
* そうしないと、クラシック ECN フィードバックと正確な ECN フィードバックが同じセグメントに関して矛盾するフィードバックを与える可能性があり、これにより新たなセキュリティ上の懸念が生じ、実装が不必要に複雑になる可能性があります。
* middleboxes are more likely to faithfully forward the TCP-ECN flags than newly defined areas of the TCP header.
* ミドルボックスは、TCP ヘッダーの新しく定義された領域よりも TCP-ECN フラグを忠実に転送する可能性が高くなります。
AccECN is designed to work even if the supplementary feedback part is removed or zeroed out, as long as the essential feedback part gets through.
AccECN は、重要なフィードバック部分が通過する限り、補足的なフィードバック部分が削除されたりゼロになった場合でも機能するように設計されています。
AccECN changes the wire protocol of the main TCP header; therefore, it can only be used if both endpoints have been upgraded to understand it. The TCP Client signals support for AccECN on the initial SYN of a connection, and the TCP Server signals whether it supports AccECN on the SYN/ACK. The TCP flags on the SYN that the TCP Client uses to signal AccECN support have been carefully chosen so that a TCP Server will interpret them as a request to support the most recent variant of ECN feedback that it supports. Then the TCP Client falls back to the same variant of ECN feedback.
AccECN はメイン TCP ヘッダーのワイヤ プロトコルを変更します。したがって、両方のエンドポイントがそれを理解できるようにアップグレードされている場合にのみ使用できます。TCP クライアントは接続の最初の SYN で AccECN のサポートを通知し、TCP サーバーは SYN/ACK で AccECN をサポートするかどうかを通知します。TCP クライアントが AccECN サポートを通知するために使用する SYN 上の TCP フラグは、TCP サーバーがサポートする ECN フィードバックの最新のバリアントをサポートする要求として解釈できるように、慎重に選択されています。その後、TCP クライアントは同じバリアントの ECN フィードバックに戻ります。
An AccECN TCP Client does not send an AccECN Option on the SYN as SYN option space is limited. The TCP Server sends an AccECN Option on the SYN/ACK, and the TCP Client sends one on the first ACK to test whether the network path forwards these options correctly.
SYN オプションのスペースが限られているため、AccECN TCP クライアントは SYN 上で AccECN オプションを送信しません。TCP サーバーは SYN/ACK で AccECN オプションを送信し、TCP クライアントは最初の ACK で AccECN オプションを送信して、ネットワーク パスがこれらのオプションを正しく転送するかどうかをテストします。
A Data Receiver maintains four counters initialized at the start of the half-connection. Three count the number of arriving payload bytes marked CE, ECT(1), and ECT(0) in the IP-ECN field. These byte counters reflect only the TCP payload length, excluding the TCP header and TCP Options. The fourth counter counts the number of packets arriving marked with a CE codepoint (including control packets without payload if they are CE-marked).
データ レシーバは、ハーフ接続の開始時に初期化された 4 つのカウンタを維持します。3 つは、IP-ECN フィールドで CE、ECT(1)、ECT(0) とマークされた到着ペイロード バイト数をカウントします。これらのバイト カウンタは、TCP ヘッダーと TCP オプションを除く、TCP ペイロード長のみを反映します。4 番目のカウンタは、CE コードポイントでマークされた到着パケットの数をカウントします (CE マークが付いている場合は、ペイロードのない制御パケットを含みます)。
The Data Sender maintains four equivalent counters for the half-connection, and the AccECN protocol is designed to ensure they will match the values in the Data Receiver's counters, albeit after a little delay.
データ送信側はハーフ接続用に 4 つの同等のカウンタを維持しており、AccECN プロトコルは、多少の遅延はあるものの、データ受信側のカウンタの値と確実に一致するように設計されています。
Each ACK carries the three least significant bits (LSBs) of the packet-based CE counter using the ECN bits in the TCP header, now renamed the Accurate ECN (ACE) field (see Figure 3). The 24 LSBs of some or all of the byte counters can be optionally carried in an AccECN Option. For efficient use of limited option space, two alternative forms of the AccECN Option are specified with the fields in the opposite order to each other.
各 ACK は、TCP ヘッダーの ECN ビットを使用して、パケットベースの CE カウンタの 3 つの最下位ビット (LSB) を伝送します。このビットは現在、Accurate ECN (ACE) フィールドに名前が変更されています (図 3 を参照)。一部またはすべてのバイト カウンタの 24 LSB は、オプションで AccECN オプションで伝送できます。限られたオプション空間を効率的に使用するために、AccECN オプションの 2 つの代替形式が、フィールドを互いに逆の順序で指定します。
With both the ACE and the AccECN Option mechanisms, the Data Receiver continually repeats the current LSBs of each of its respective counters. There is no need to acknowledge these continually repeated counters, so the CWR mechanism of [RFC3168] is no longer used. Even if some ACKs are lost, the Data Sender ought to be able to infer how much to increment its own counters, even if the protocol field has wrapped.
ACE と AccECN オプション メカニズムの両方を使用して、データ レシーバはそれぞれのカウンタの現在の LSB を継続的に繰り返します。これらの継続的に繰り返されるカウンタを確認する必要がないため、[RFC3168] の CWR メカニズムは使用されなくなりました。一部の ACK が失われた場合でも、データ送信者は、プロトコル フィールドがラップされている場合でも、自身のカウンタをどの程度増分するかを推測できる必要があります。
The 3-bit ACE field can wrap fairly frequently. Therefore, even if it appears to have incremented by one (say), the field might have actually cycled completely and then incremented by one. The Data Receiver is not allowed to delay sending an ACK to such an extent that the ACE field would cycle. However, ACKs received at the Data Sender could still cycle because a whole sequence of ACKs carrying intervening values of the field might all be lost or delayed in transit.
3 ビットの ACE フィールドはかなり頻繁にラップされる可能性があります。したがって、(たとえば) 1 ずつ増加しているように見えても、フィールドは実際には完全に循環してから 1 ずつ増加している可能性があります。データ受信者は、ACE フィールドが循環するほど ACK の送信を遅らせることはできません。ただし、フィールドの介在する値を運ぶ ACK のシーケンス全体が送信中にすべて失われるか遅延する可能性があるため、データ送信側で受信される ACK は依然として循環する可能性があります。
The fields in an AccECN Option are larger, but they will increment in larger steps because they count bytes not packets. Nonetheless, their size has been chosen such that a whole cycle of the field would never occur between ACKs unless there had been an infeasibly long sequence of ACK losses. Therefore, provided that an AccECN Option is available, it can be treated as a dependable feedback channel.
AccECN オプションのフィールドは大きくなりますが、パケットではなくバイトをカウントするため、より大きなステップで増加します。それにも関わらず、実行不可能なほど長い一連の ACK 損失がない限り、フィールドのサイクル全体が ACK の間に発生しないように、そのサイズが選択されています。したがって、AccECN オプションが利用可能な場合は、信頼できるフィードバック チャネルとして扱うことができます。
If an AccECN Option is not available, e.g., it is being stripped by a middlebox, the AccECN protocol will only feed back information on CE markings (using the ACE field). Although not ideal, this will be sufficient, because it is envisaged that neither ECT(0) nor ECT(1) will ever indicate more severe congestion than CE, even though future uses for ECT(0) or ECT(1) are still unclear [RFC8311]. Because the 3-bit ACE field is so small, when it is the only field available, the Data Sender has to interpret it assuming the most likely wrap, but with a degree of conservatism.
AccECN オプションが利用できない場合、たとえばミドルボックスによって削除されている場合、AccECN プロトコルは CE マーキングに関する情報のみをフィードバックします (ACE フィールドを使用)。理想的ではありませんが、ECT(0) または ECT(1) の将来の使用法がまだ不明であるにもかかわらず、ECT(0) または ECT(1) のいずれも CE よりも深刻な輻輳を示すことはないと想定されているため、これで十分です [RFC8311]。3 ビット ACE フィールドは非常に小さいため、それが利用可能な唯一のフィールドである場合、データ送信者は、最も可能性の高いラップを想定して、ある程度の保守性を持ってそれを解釈する必要があります。
Certain specified events trigger the Data Receiver to include an AccECN Option on an ACK. The rules are designed to ensure that the order in which different markings arrive at the receiver is communicated to the sender (as long as options are reaching the sender and as long as there is no ACK loss). Implementations are encouraged to send an AccECN Option more frequently, but this is left up to the implementer.
特定の指定されたイベントは、データ受信側をトリガーして、ACK に AccECN オプションを含めます。このルールは、さまざまなマーキングが受信者に到着する順序が送信者に確実に伝達されるように設計されています (オプションが送信者に到達している限り、および ACK 損失がない限り)。実装では AccECN オプションをより頻繁に送信することが推奨されますが、これは実装者に任されます。
The CE packet counter in the ACE field and the CE byte counter in AccECN Options both provide feedback on received CE marks. The CE packet counter includes control packets that do not have payload data, while the CE byte counter solely includes marked payload bytes. If both are present, the byte counter in an AccECN Option will provide the more accurate information needed for modern congestion control and policing schemes, such as L4S, DCTCP, or ConEx. If AccECN Options are stripped, a simple algorithm to estimate the number of marked bytes from the ACE field is given in Appendix A.3.
ACE フィールドの CE パケット カウンタと AccECN オプションの CE バイト カウンタは両方とも、受信した CE マークに関するフィードバックを提供します。CE パケット カウンタにはペイロード データを持たない制御パケットが含まれますが、CE バイト カウンタにはマークされたペイロード バイトのみが含まれます。両方が存在する場合、AccECN オプションのバイト カウンタは、L4S、DCTCP、ConEx などの最新の輻輳制御およびポリシング スキームに必要なより正確な情報を提供します。AccECN オプションが削除された場合、ACE フィールドからマークされたバイト数を推定する簡単なアルゴリズムが付録 A.3 に示されています。
The AccECN design has been generalized so that it ought to be able to support possible future uses of the experimental ECT(1) codepoint other than the L4S experiment [RFC9330], such as a lower severity or a more instant congestion signal than CE.
AccECN の設計は一般化されており、L4S 実験 [RFC9330] 以外の実験的な ECT(1) コードポイントの将来の使用 (CE よりも低い重大度や即時的な輻輳信号など) をサポートできるようになりました。
Feedback in bytes is provided to protect against the receiver or a middlebox using attacks similar to 'ACK-Division' to artificially inflate the congestion window, which is why [RFC5681] now recommends that TCP counts acknowledge bytes not packets.
バイト単位のフィードバックは、輻輳ウィンドウを人為的に拡大する「ACK-Division」に類似した攻撃を使用する受信機またはミドルボックスから保護するために提供されます。そのため、[RFC5681] は現在、TCP がパケットではなく確認応答バイトをカウントすることを推奨しています。
The ACE field provides feedback about CE markings in the IP-ECN field of both data and control packets. According to [RFC3168], the Data Sender is meant to set the IP-ECN field of control packets to Not-ECT. However, mechanisms in certain private networks (e.g., data centres) set control packets to be ECN-capable because they are precisely the packets that performance depends on most.
ACE フィールドは、データ パケットと制御パケットの両方の IP-ECN フィールドの CE マーキングに関するフィードバックを提供します。[RFC3168] によれば、データ送信者は制御パケットの IP-ECN フィールドを Not-ECT に設定することになっています。ただし、特定のプライベート ネットワーク (データ センターなど) のメカニズムは、制御パケットがまさにパフォーマンスに最も依存するパケットであるため、制御パケットを ECN 対応に設定します。
For this reason, AccECN is designed to be a generic reflector of whatever ECN markings it sees, whether or not they are compliant with a current standard. Then as standards evolve, Data Senders can upgrade unilaterally without any need for receivers to upgrade too.
このため、AccECN は、現在の標準に準拠しているかどうかに関係なく、表示されるあらゆる ECN マーキングの汎用リフレクターとなるように設計されています。その後、標準が進化するにつれて、受信側もアップグレードする必要がなく、データ送信側が一方的にアップグレードできるようになります。
It is also useful to be able to rely on generic reflection behaviour when senders need to test for unexpected interference with markings (for instance Sections 3.2.2.3, 3.2.2.4, and 3.2.3.2 of the present document and paragraph 2 of Section 20.2 of [RFC3168]).
また、送信者がマーキングによる予期せぬ干渉をテストする必要がある場合に、一般的なリフレクション動作に依存できることも役立ちます (たとえば、本文書のセクション 3.2.2.3、3.2.2.4、および 3.2.3.2、および [RFC3168] のセクション 20.2 のパラグラフ 2)。
The initial SYN and SYN/ACK are the most critical control packets, so AccECN feeds back their IP-ECN fields. Although RFC 3168 prohibits ECN-capable SYNs and SYN/ACKs, providing feedback of ECN marking on the SYN and SYN/ACK supports future scenarios in which SYNs might be ECN-enabled (without prejudging whether they ought to be). For instance, [RFC8311] updates this aspect of RFC 3168 to allow experimentation with ECN-capable TCP control packets.
最初の SYN と SYN/ACK は最も重要な制御パケットであるため、AccECN はそれらの IP-ECN フィールドをフィードバックします。RFC 3168 は ECN 対応の SYN および SYN/ACK を禁止していますが、SYN および SYN/ACK に ECN マーキングのフィードバックを提供することで、SYN が ECN 対応になる可能性がある将来のシナリオをサポートします (そうすべきかどうかを事前に判断することなく)。たとえば、[RFC8311] は RFC 3168 のこの側面を更新し、ECN 対応の TCP 制御パケットの実験を可能にします。
Even if the TCP Client (or Server) has set the SYN (or SYN/ACK) to Not-ECT in compliance with RFC 3168, feedback on the state of the IP-ECN field when it arrives at the receiver could still be useful, because middleboxes have been known to overwrite the IP-ECN field as if it is still part of the old Type of Service (ToS) field [Mandalari18]. For example, if a TCP Client has set the SYN to Not-ECT, but receives feedback that the IP-ECN field on the SYN arrived with a different codepoint, it can detect such middlebox interference. Previously, neither end knew what IP-ECN field the other sent. So, if a TCP Server received ECT or CE on a SYN, it could not know whether it was invalid because only the TCP Client knew whether it originally marked the SYN as Not-ECT (or ECT). Therefore, prior to AccECN, the Server's only safe course of action in this example was to disable ECN for the connection. Instead, the AccECN protocol allows the Server and Client to feed back the ECN field received on the SYN and SYN/ACK to their peer, which now has all the information to decide whether the connection has to fall back from supporting ECN (or not).
TCP クライアント (またはサーバー) が RFC 3168 に従って SYN (または SYN/ACK) を Not-ECT に設定している場合でも、受信者に到着したときの IP-ECN フィールドの状態に関するフィードバックは依然として役立つ可能性があります。これは、ミドルボックスが IP-ECN フィールドを、あたかも古い Type of Service (ToS) フィールドの一部であるかのように上書きすることが知られているためです [Mandalari18]。たとえば、TCP クライアントが SYN を Not-ECT に設定していても、SYN の IP-ECN フィールドが異なるコードポイントで到着したというフィードバックを受信した場合、そのようなミドルボックス干渉を検出できます。以前は、どちらの側も相手がどの IP-ECN フィールドを送信したかを知りませんでした。そのため、TCP サーバーが SYN で ECT または CE を受信した場合、それが無効であるかどうかを知ることはできません。これは、SYN を最初に Not-ECT (または ECT) としてマークしたかどうかを知っているのは TCP クライアントだけであるためです。したがって、AccECN が導入される前は、この例におけるサーバーの唯一の安全なアクションは、接続に対して ECN を無効にすることでした。代わりに、AccECN プロトコルを使用すると、サーバーとクライアントは、SYN および SYN/ACK で受信した ECN フィールドをピアにフィードバックできます。ピアには、接続が ECN サポートからフォールバックする必要があるかどうか (またはフォールバックしないか) を決定するためのすべての情報が含まれています。
Given the ECN-nonce [RFC3540] has been reclassified as Historic [RFC8311], the TCP flag that was previously called NS (Nonce Sum) is renamed as the AE (Accurate ECN) flag (the TCP header flag at bit offset 7 in Figure 2). See the IANA Considerations in Section 7.
ECN-nonce [RFC3540] が Historic [RFC8311] として再分類されたことを考慮すると、以前 NS (Nonce Sum) と呼ばれていた TCP フラグは、AE (Accurate ECN) フラグ (図 2 のビット オフセット 7 の TCP ヘッダー フラグ) に名前が変更されます。セクション 7 の IANA の考慮事項を参照してください。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | A | C | E | U | A | P | R | S | F |
| Header Length | Reserved | E | W | C | R | C | S | S | Y | I |
| | | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: The New Definition of the TCP Header Flags During the TCP Three-Way Handshake
図 2: TCP スリーウェイ ハンドシェイク中の TCP ヘッダー フラグの新しい定義
During the TCP three-way handshake at the start of a connection, to request more Accurate ECN feedback the TCP Client (host A) MUST set the TCP flags (AE,CWR,ECE) = (1,1,1) in the initial SYN segment.
接続開始時の TCP スリーウェイ ハンドシェイク中に、より正確な ECN フィードバックを要求するには、TCP クライアント (ホスト A) は、初期 SYN セグメントで TCP フラグ (AE、CWR、ECE) = (1,1,1) を設定しなければなりません。
If a TCP Server (host B) that is AccECN-enabled receives a SYN with the above three flags set, it MUST set both its half-connections into AccECN mode. Then it MUST set the AE, CWR, and ECE TCP flags on the SYN/ACK to the combination in the top block of Table 2 that feeds back the IP-ECN field that arrived on the SYN. This applies whether or not the Server itself supports setting the IP-ECN field on a SYN or SYN/ACK (see Section 2.5 for rationale).
AccECN 対応の TCP サーバー (ホスト B) が上記の 3 つのフラグが設定された SYN を受信した場合、その両方のハーフ接続を AccECN モードに設定しなければなりません。次に、SYN/ACK の AE、CWR、および ECE TCP フラグを、SYN で到着した IP-ECN フィールドをフィードバックする表 2 の一番上のブロックの組み合わせに設定しなければなりません (MUST)。これは、サーバー自体が SYN または SYN/ACK での IP-ECN フィールドの設定をサポートしているかどうかに関係なく適用されます (根拠についてはセクション 2.5 を参照)。
When the TCP Server returns any of the four combinations in the top block of Table 2, it confirms that it supports AccECN. The TCP Server MUST NOT set one of these four combinations of flags on the SYN/ACK unless the preceding SYN requested support for AccECN as above.
TCP サーバーが表 2 の上部のブロックにある 4 つの組み合わせのいずれかを返すと、TCP サーバーが AccECN をサポートしていることを確認します。TCP サーバーは、前の SYN が上記のように AccECN のサポートを要求しない限り、SYN/ACK にこれら 4 つのフラグの組み合わせのいずれかを設定してはなりません (MUST NOT)。
Once a TCP Client (A) has sent the above SYN to declare that it supports AccECN, and once it has received the above SYN/ACK segment that confirms that the TCP Server supports AccECN, the TCP Client MUST set both its half-connections into AccECN mode. The TCP Client MUST NOT enter AccECN mode (or any feedback mode) before it has received the first SYN/ACK.
TCP クライアント (A) が AccECN をサポートしていることを宣言するために上記の SYN を送信し、TCP サーバーが AccECN をサポートしていることを確認する上記の SYN/ACK セグメントを受信したら、TCP クライアントは両方のハーフコネクションを AccECN モードに設定しなければなりません (MUST)。TCP クライアントは、最初の SYN/ACK を受信する前に AccECN モード (または任意のフィードバック モード) に入ってはなりません (MUST NOT)。
Once in AccECN mode, a TCP Client or Server has the rights and obligations defined in Section 3.1.5 concerning use of ECN.
AccECN モードになると、TCP クライアントまたはサーバーは ECN の使用に関してセクション 3.1.5 で定義された権利と義務を負います。
The procedures for retransmission of SYNs or SYN/ACKs are given in Section 3.1.4.
SYN または SYN/ACK の再送信手順はセクション 3.1.4 に記載されています。
It is RECOMMENDED that the AccECN protocol be implemented alongside Selective Acknowledgement (SACK) [RFC2018]. If SACK is implemented with AccECN, Duplicate Selective Acknowledgement (D-SACK) [RFC2883] MUST also be implemented.
AccECN プロトコルを選択的確認応答 (SACK) [RFC2018] と一緒に実装することが推奨されます。SACK が AccECN で実装されている場合は、Duplicate Selective Acknowledgment (D-SACK) [RFC2883] も実装しなければなりません (MUST)。
The TCP flags used to indicate AccECN support on the SYN were carefully chosen to enable natural fall-back to prior stages in the evolution of ECN. Table 2 tabulates all the negotiation possibilities for ECN-related capabilities that involve at least one AccECN-capable host. The entries in the first two columns have been abbreviated, as follows:
SYN での AccECN サポートを示すために使用される TCP フラグは、ECN の進化の前段階への自然なフォールバックを可能にするために慎重に選択されました。表 2 は、少なくとも 1 つの AccECN 対応ホストが関係する ECN 関連機能のすべてのネゴシエーションの可能性を表にまとめたものです。最初の 2 つの列のエントリは次のように省略されています。
AccECN:
ACCECN:
Supports more Accurate ECN feedback (the present specification).
より正確な ECN フィードバック (現在の仕様) をサポートします。
Nonce:
ナンス:
Supports ECN-nonce feedback [RFC3540].
ECN-nonce フィードバック [RFC3540] をサポートします。
ECN:
ECN:
Supports 'Classic' ECN feedback [RFC3168].
「クラシック」ECN フィードバック [RFC3168] をサポートします。
No ECN:
ECNなし:
Not ECN-capable. Implicit congestion notification using packet drop.
ECN 対応ではありません。パケットドロップを使用した暗黙的な輻輳通知。
+========+========+============+============+======================+
| Host A | Host B | SYN | SYN/ACK | Feedback Mode |
| | | A->B | B->A | of Host A |
| | | AE CWR ECE | AE CWR ECE | |
+========+========+============+============+======================+
| AccECN | AccECN | 1 1 1 | 0 1 0 | AccECN (Not-ECT SYN) |
| AccECN | AccECN | 1 1 1 | 0 1 1 | AccECN (ECT1 on SYN) |
| AccECN | AccECN | 1 1 1 | 1 0 0 | AccECN (ECT0 on SYN) |
| AccECN | AccECN | 1 1 1 | 1 1 0 | AccECN (CE on SYN) |
+--------+--------+------------+------------+----------------------+
+--------+--------+------------+------------+----------------------+
| AccECN | Nonce | 1 1 1 | 1 0 1 | (Reserved) |
| AccECN | ECN | 1 1 1 | 0 0 1 | Classic ECN |
| AccECN | No ECN | 1 1 1 | 0 0 0 | Not ECN |
+--------+--------+------------+------------+----------------------+
+--------+--------+------------+------------+----------------------+
| Nonce | AccECN | 0 1 1 | 0 0 1 | Classic ECN |
| ECN | AccECN | 0 1 1 | 0 0 1 | Classic ECN |
| No ECN | AccECN | 0 0 0 | 0 0 0 | Not ECN |
+--------+--------+------------+------------+----------------------+
+--------+--------+------------+------------+----------------------+
| AccECN | Broken | 1 1 1 | 1 1 1 | Not ECN |
+--------+--------+------------+------------+----------------------+
Table 2: ECN Capability Negotiation Between Client (A) and Server (B)
表 2: クライアント (A) とサーバー (B) 間の ECN 機能ネゴシエーション
Table 2 is divided into blocks, with each block separated by an empty row.
表 2 はブロックに分割されており、各ブロックは空の行で区切られています。
1. The top block shows the case already described in Section 3.1 where both endpoints support AccECN and how the TCP Server (B) indicates congestion feedback.
1. 一番上のブロックは、セクション 3.1 ですでに説明した、両方のエンドポイントが AccECN をサポートするケースと、TCP サーバー (B) が輻輳フィードバックを示す方法を示しています。
2. The second block shows the cases where the TCP Client (A) supports AccECN but the TCP Server (B) supports some earlier variant of TCP feedback, as indicated in its SYN/ACK. Therefore, as soon as an AccECN-capable TCP Client (A) receives the SYN/ACK shown, it MUST set both its half-connections into the feedback mode shown in the rightmost column. If the TCP Client has set itself into Classic ECN feedback mode, it MUST comply with [RFC3168].
2. 2 番目のブロックは、TCP クライアント (A) が AccECN をサポートしているが、TCP サーバー (B) が、SYN/ACK で示されている TCP フィードバックの以前のバージョンをサポートしているケースを示しています。したがって、AccECN 対応 TCP クライアント (A) は、示されている SYN/ACK を受信するとすぐに、両方のハーフコネクションを右端の列に示されているフィードバック モードに設定しなければなりません (MUST)。TCP クライアントが自身をクラシック ECN フィードバック モードに設定している場合、[RFC3168] に準拠しなければなりません (MUST)。
An AccECN implementation has no need to recognize or support the Server response labelled 'Nonce' or ECN-nonce feedback more generally [RFC3540], as RFC 3540 has been reclassified as Historic [RFC8311]. AccECN is compatible with alternative ECN feedback integrity approaches to the nonce (see Section 5.3). The SYN/ACK labelled 'Nonce' with (AE,CWR,ECE) = (1,0,1) is reserved for future use. A TCP Client (A) that receives such a SYN/ACK follows the procedure for forward compatibility given in Section 3.1.3.
RFC 3540 はヒストリック [RFC8311] として再分類されたため、AccECN 実装は、「Nonce」とラベル付けされたサーバー応答、またはより一般的には [RFC3540] ECN-nonce フィードバックを認識またはサポートする必要はありません。AccECN は、ノンスに対する代替 ECN フィードバック整合性アプローチと互換性があります (セクション 5.3 を参照)。(AE,CWR,ECE) = (1,0,1) で「Nonce」とラベル付けされた SYN/ACK は、将来の使用のために予約されています。このような SYN/ACK を受信した TCP クライアント (A) は、セクション 3.1.3 に示されている前方互換性の手順に従います。
3. The third block shows the cases where the TCP Server (B) supports AccECN but the TCP Client (A) supports some earlier variant of TCP feedback, as indicated in its SYN.
3. 3 番目のブロックは、TCP サーバー (B) が AccECN をサポートしているが、TCP クライアント (A) が、その SYN に示されている TCP フィードバックの以前のバージョンをサポートしているケースを示しています。
When an AccECN-enabled TCP Server (B) receives a SYN with (AE,CWR,ECE) = (0,1,1), it MUST do one of the following:
AccECN 対応の TCP サーバー (B) が (AE,CWR,ECE) = (0,1,1) の SYN を受信した場合、次のいずれかを実行しなければなりません。
* set both its half-connections into the Classic ECN feedback mode and return a SYN/ACK with (AE,CWR,ECE) = (0,0,1) as shown. Then it MUST comply with [RFC3168].
* 両方の半分の接続をクラシック ECN フィードバック モードに設定し、図に示すように (AE,CWR,ECE) = (0,0,1) の SYN/ACK を返します。その後、[RFC3168] に準拠しなければなりません。
* set both its half-connections into Not ECN mode and return a SYN/ACK with (AE,CWR,ECE) = (0,0,0), then continue with ECN disabled. This latter case is unlikely to be desirable, but it is allowed as a possibility, e.g., for minimal TCP implementations.
* 両方の半分の接続を非 ECN モードに設定し、(AE,CWR,ECE) = (0,0,0) の SYN/ACK を返し、ECN を無効にして続行します。この後者のケースは望ましいとは考えられませんが、最小限の TCP 実装などでは可能性として許容されます。
When an AccECN-enabled TCP Server (B) receives a SYN with (AE,CWR,ECE) = (0,0,0), it MUST set both its half-connections into the Not ECN feedback mode, return a SYN/ACK with (AE,CWR,ECE) = (0,0,0) as shown, and continue with ECN disabled.
AccECN が有効な TCP サーバー (B) が (AE,CWR,ECE) = (0,0,0) の SYN を受信した場合、両方のハーフコネクションを Not ECN フィードバック モードに設定し、示されているように (AE,CWR,ECE) = (0,0,0) の SYN/ACK を返し、ECN を無効にして続行しなければなりません。
4. The fourth block displays a combination labelled 'Broken'. Some older TCP Server implementations incorrectly set the TCP-ECN flags in the SYN/ACK by reflecting those in the SYN. Such broken TCP Servers (B) cannot support ECN; so as soon as an AccECN-capable TCP Client (A) receives such a broken SYN/ACK, it MUST fall back to Not ECN mode for both its half-connections and continue with ECN disabled.
4. 4 番目のブロックには、「Broken」というラベルの付いた組み合わせが表示されます。一部の古い TCP サーバー実装では、SYN 内の TCP-ECN フラグを反映することにより、SYN/ACK 内の TCP-ECN フラグが誤って設定されます。このような壊れた TCP サーバー (B) は ECN をサポートできません。そのため、AccECN 対応の TCP クライアント (A) は、そのような壊れた SYN/ACK を受信するとすぐに、両方のハーフ接続で Not ECN モードにフォールバックし、ECN を無効にして続行しなければなりません (MUST)。
The following additional rules do not fit the structure of the table, but they complement it:
次の追加ルールはテーブルの構造には適合しませんが、それを補完します。
Simultaneous Open:
同時オープン:
An originating AccECN Host (A), having sent a SYN with (AE,CWR,ECE) = (1,1,1), might receive another SYN from host B. Host A MUST then enter the same feedback mode as it would have entered had it been a responding host and received the same SYN. Then host A MUST send the same SYN/ACK as it would have sent had it been a responding host.
(AE,CWR,ECE) = (1,1,1) の SYN を送信した発信元の AccECN ホスト (A) は、ホスト B から別の SYN を受信する可能性があります。ホスト A は、その後、応答ホストで同じ SYN を受信した場合と同じフィードバック モードに入らなければなりません (MUST)。次に、ホスト A は、応答ホストだった場合に送信するのと同じ SYN/ACK を送信しなければなりません (MUST)。
In-window SYN during TIME-WAIT:
TIME-WAIT 中のウィンドウ内 SYN:
Many TCP implementations create a new TCP connection if they receive an in-window SYN packet during TIME-WAIT state. When a TCP host enters TIME-WAIT or CLOSED state, it ought to ignore any previous state about the negotiation of AccECN for that connection and renegotiate the feedback mode according to Table 2.
多くの TCP 実装は、TIME-WAIT 状態中にウィンドウ内 SYN パケットを受信すると、新しい TCP 接続を作成します。TCP ホストが TIME-WAIT または CLOSED 状態に入ると、その接続の AccECN のネゴシエーションに関する以前の状態を無視し、表 2 に従ってフィードバック モードを再ネゴシエートする必要があります。
If a TCP Server that implements AccECN receives a SYN with the three TCP header flags (AE,CWR,ECE) set to any combination other than (0,0,0), (0,1,1), or (1,1,1) and it does not have logic specific to such a combination, the Server MUST negotiate the use of AccECN as if the three flags had been set to (1,1,1). However, an AccECN Client implementation MUST NOT send a SYN with any combination other than the three listed.
AccECN を実装する TCP サーバーが、3 つの TCP ヘッダー フラグ (AE、CWR、ECE) が (0,0,0)、(0,1,1)、または (1,1,1) 以外の組み合わせに設定された SYN を受信し、そのような組み合わせに固有のロジックを持たない場合、サーバーは、3 つのフラグが (1,1,1) に設定されているかのように AccECN の使用をネゴシエートしなければなりません (MUST)。ただし、AccECN クライアント実装は、リストされている 3 つ以外の組み合わせで SYN を送信してはなりません (MUST NOT)。
If a TCP Client sent a SYN requesting AccECN feedback with (AE,CWR,ECE) = (1,1,1) and then receives a SYN/ACK with the currently reserved combination (AE,CWR,ECE) = (1,0,1) but it does not have logic specific to such a combination, the Client MUST enable AccECN mode as if the SYN/ACK confirmed that the Server supported AccECN and as if it fed back that the IP-ECN field on the SYN had arrived unchanged. However, an AccECN Server implementation MUST NOT send a SYN/ACK with this combination (AE,CWR,ECE) = (1,0,1).
TCP クライアントが (AE,CWR,ECE) = (1,1,1) の AccECN フィードバックを要求する SYN を送信し、現在予約されている組み合わせ (AE,CWR,ECE) = (1,0,1) の SYN/ACK を受信したが、そのような組み合わせに固有のロジックを持たない場合、クライアントは、SYN/ACK がサーバーが AccECN をサポートしていることを確認し、それをフィードバックしたかのように AccECN モードを有効にしなければなりません (MUST)。SYN の IP-ECN フィールドは変更されずに到着しました。ただし、AccECN サーバー実装は、この組み合わせ (AE,CWR,ECE) = (1,0,1) で SYN/ACK を送信してはなりません (MUST NOT)。
For the avoidance of doubt, the behaviour described in the present specification applies whether or not the three remaining reserved TCP header flags are zero.
誤解を避けるために言うと、本明細書で説明されている動作は、残りの 3 つの予約済み TCP ヘッダー フラグがゼロであるかどうかに関係なく適用されます。
All of these requirements ensure that future uses of all the Reserved combinations of all the TCP header bits on a SYN or SYN/ACK (see Table 2) can rely on consistent behaviour from the installed base of AccECN implementations. See Appendix B.3 for related discussion.
これらすべての要件により、SYN または SYN/ACK (表 2 を参照) 上のすべての TCP ヘッダー ビットのすべての予約済みの組み合わせを今後使用する際に、AccECN 実装のインストール ベースからの一貫した動作に依存できることが保証されます。関連する議論については、付録 B.3 を参照してください。
If the sender of an AccECN SYN (the TCP Client) times out before receiving the SYN/ACK, it SHOULD attempt to negotiate the use of AccECN at least one more time by continuing to set all three TCP-ECN flags (AE,CWR,ECE) = (1,1,1) on the first retransmitted SYN (using the usual retransmission timeouts). If this first retransmission also fails to be acknowledged, in deployment scenarios where AccECN path traversal might be problematic, the TCP Client SHOULD send subsequent retransmissions of the SYN with the three TCP-ECN flags cleared (AE,CWR,ECE) = (0,0,0). Such a retransmitted SYN MUST use the same initial sequence number (ISN) as the original SYN.
AccECN SYN の送信者 (TCP クライアント) が SYN/ACK を受信する前にタイムアウトした場合、(通常の再送タイムアウトを使用して) 最初に再送された SYN で 3 つの TCP-ECN フラグ (AE、CWR、ECE) = (1,1,1) をすべて設定し続けることにより、少なくとももう一度 AccECN の使用のネゴシエーションを試行すべきです(SHOULD)。この最初の再送信も確認応答に失敗した場合、AccECN パス トラバーサルに問題がある可能性がある展開シナリオでは、TCP クライアントは 3 つの TCP-ECN フラグ (AE、CWR、ECE) = (0,0,0) をクリアした状態で SYN の後続の再送信を送信すべきです (SHOULD)。このような再送信された SYN は、元の SYN と同じ初期シーケンス番号 (ISN) を使用しなければなりません (MUST)。
Retrying once before fall-back adds delay in the case where a middlebox drops an AccECN (or ECN) SYN deliberately. However, recent measurements [Mandalari18] imply that a drop is less likely to be due to middlebox interference than other intermittent causes of loss, e.g., congestion, wireless transmission loss, etc.
ミドルボックスが意図的に AccECN (または ECN) SYN をドロップする場合、フォールバックの前に 1 回再試行すると遅延が追加されます。しかし、最近の測定 [Mandalari18] は、ドロップが他の断続的な損失原因 (例: 輻輳や無線伝送損失など) よりもミドルボックス干渉による可能性が低いことを示唆しています。
Implementers MAY use other fall-back strategies if they are found to be more effective, e.g., attempting to negotiate AccECN on the SYN only once or more than twice (most appropriate during high levels of congestion).
実装者は、他のフォールバック戦略の方が効果的であると判明した場合、たとえば SYN 上で AccECN のネゴシエーションを 1 回だけまたは 2 回以上試行する (高レベルの輻輳時に最も適切) 場合、他のフォールバック戦略を使用してもよい(MAY)。
Further it might make sense to also remove any other new or experimental fields or options on the SYN in case a middlebox might be blocking them, although the required behaviour will depend on the specification of the other option(s) and any attempt to coordinate fall-back between different modules of the stack. For instance, if taking part in an [RFC8311] experiment that allows ECT on a SYN, it would be advisable to have a fall-back strategy that tries use of AccECN without setting ECT on the SYN.
さらに、ミドルボックスがそれらをブロックしている可能性がある場合に備えて、SYN 上の他の新しいフィールドや実験的なフィールドやオプションも削除することは意味があるかもしれませんが、必要な動作は他のオプションの仕様と、スタックの異なるモジュール間のフォールバックを調整する試みによって異なります。たとえば、SYN 上で ECT を許可する [RFC8311] 実験に参加する場合は、SYN 上で ECT を設定せずに AccECN の使用を試みるフォールバック戦略を持つことをお勧めします。
Whichever fall-back strategy is used, the TCP initiator SHOULD cache failed connection attempts. If it does, it SHOULD NOT give up attempting to negotiate AccECN on the SYN of subsequent connection attempts until it is clear that the blockage is persistently and specifically due to AccECN. The cache needs to be arranged to expire so that the initiator will infrequently attempt to check whether the problem has been resolved.
どちらのフォールバック戦略が使用される場合でも、TCP イニシエーターは失敗した接続試行をキャッシュする必要があります (SHOULD)。そうなった場合、ブロックが永続的かつ具体的に AccECN によるものであることが明らかになるまで、後続の接続試行の SYN で AccECN のネゴシエーションを諦めるべきではありません。イニシエーターが問題が解決したかどうかのチェックをめったに試行しないように、キャッシュは期限切れになるように調整する必要があります。
All fall-back strategies will need to follow all the normative rules in Section 3.1.5, which concern behaviour when SYNs or SYN/ACKs negotiating different types of feedback have been sent within the same connection, including the possibility that they arrive out of order. As examples, the following non-normative bullets call out those rules from Section 3.1.5 that apply to the above fall-back strategies:
すべてのフォールバック戦略は、セクション 3.1.5 のすべての規範的なルールに従う必要があります。このルールは、異なる種類のフィードバックをネゴシエートする SYN または SYN/ACK が同じ接続内で送信されたときの動作に関するものであり、それらが順序どおりに到着しない可能性も含みます。例として、次の非規範的な箇条書きでは、上記のフォールバック戦略に適用されるセクション 3.1.5 のルールを呼び出します。
* Once the TCP Client has sent SYNs with (AE,CWR,ECE) = (1,1,1) and with (AE,CWR,ECE) = (0,0,0), it might eventually receive a SYN/ACK from the Server in response to one, the other, or both, and possibly reordered.
* TCP クライアントが (AE,CWR,ECE) = (1,1,1) および (AE,CWR,ECE) = (0,0,0) の SYN を送信すると、最終的にはどちらか一方、または両方に応答してサーバーから SYN/ACK を受信する可能性があり、場合によっては順序が変更される可能性があります。
* Such a TCP Client enters the feedback mode appropriate to the first SYN/ACK it receives according to Table 2, and it does not switch to a different mode, whatever other SYN/ACKs it might receive or send.
* このような TCP クライアントは、表 2 に従って受信した最初の SYN/ACK に適切なフィードバック モードに入り、他の SYN/ACK が受信または送信されても、別のモードに切り替わりません。
* If a TCP Client has entered AccECN mode but then subsequently sends a SYN or receives a SYN/ACK with (AE,CWR,ECE) = (0,0,0), it is still allowed to set ECT on packets for the rest of the connection. Note that this rule is different from that of a Server in an equivalent position (Section 3.1.5 explains).
* TCP クライアントが AccECN モードに入った後、SYN を送信するか、(AE,CWR,ECE) = (0,0,0) の SYN/ACK を受信した場合でも、残りの接続のパケットに ECT を設定することができます。このルールは、同等の位置にあるサーバーのルールとは異なることに注意してください (セクション 3.1.5 で説明します)。
* Having entered AccECN mode, in general a TCP Client commits to respond to any incoming congestion feedback, whether or not it sets ECT on outgoing packets (for rationale and some exceptions see Section 3.2.2.3, Section 3.2.2.4).
* AccECN モードに入ると、一般に、TCP クライアントは、送信パケットに ECT を設定するかどうかに関係なく、受信する輻輳フィードバックに応答することを約束します (理論的根拠と一部の例外については、セクション 3.2.2.3、セクション 3.2.2.4 を参照)。
* Having entered AccECN mode, a TCP Client commits to using AccECN to feed back the IP-ECN field in incoming packets for the rest of the connection, as specified in Section 3.2, even if it is not itself setting ECT on outgoing packets.
* AccECN モードに入ると、TCP クライアントは、送信パケットに ECT を設定していない場合でも、セクション 3.2 で指定されているように、接続の残りの部分で受信パケットの IP-ECN フィールドをフィードバックするために AccECN を使用することを約束します。
A TCP Server might send multiple SYN/ACKs indicating different feedback modes. For instance, when falling back to sending a SYN/ACK with (AE,CWR,ECE) = (0,0,0) after previous AccECN SYN/ACKs have timed out (Section 3.2.3.2.2); or to acknowledge different retransmissions of the SYN (Section 3.1.4.1).
TCP サーバーは、異なるフィードバック モードを示す複数の SYN/ACK を送信する場合があります。たとえば、以前の AccECN SYN/ACK がタイムアウトした後、(AE,CWR,ECE) = (0,0,0) で SYN/ACK を送信するようにフォールバックする場合 (セクション 3.2.3.2.2)。または、SYN のさまざまな再送信を確認します (セクション 3.1.4.1)。
All fall-back strategies will need to follow all the normative rules in Section 3.1.5, which concern behaviour when SYNs or SYN/ACKs negotiating different types of feedback are sent within the same connection, including the possibility that they arrive out of order. As examples, the following non-normative bullets call out those rules from Section 3.1.5 that apply to the above fall-back strategies:
すべてのフォールバック戦略は、異なるタイプのフィードバックをネゴシエートする SYN または SYN/ACK が同じ接続内で送信されるときの動作に関する、セクション 3.1.5 のすべての規範的なルールに従う必要があります。これには、それらが順番どおりに到着しない可能性も含まれます。例として、次の非規範的な箇条書きでは、上記のフォールバック戦略に適用されるセクション 3.1.5 のルールを呼び出します。
* An AccECN-capable TCP Server enters the feedback mode appropriate to the first SYN it receives using Table 2, and it does not switch to a different mode, whatever other SYNs it might receive and whatever SYN/ACKs it might send.
* AccECN 対応 TCP サーバーは、表 2 を使用して受信した最初の SYN に適切なフィードバック モードに入り、他の SYN を受信したり、SYN/ACK を送信したりしても、別のモードに切り替わりません。
* If a TCP Server in AccECN mode receives a SYN with (AE,CWR,ECE) = (0,0,0), it preferably acknowledges it first using an AccECN SYN/ ACK, but it can retry using a SYN/ACK with (AE,CWR,ECE) = (0,0,0).
* AccECN モードの TCP サーバーが (AE,CWR,ECE) = (0,0,0) の SYN を受信した場合、最初に AccECN SYN/ACK を使用して確認応答することが望ましいですが、(AE,CWR,ECE) = (0,0,0) の SYN/ACK を使用して再試行することもできます。
* If a TCP Server in AccECN mode sends multiple AccECN SYN/ACKs, it uses the TCP-ECN flags in each SYN/ACK to feed back the IP-ECN field on the latest SYN to have arrived.
* AccECN モードの TCP サーバーが複数の AccECN SYN/ACK を送信する場合、各 SYN/ACK の TCP-ECN フラグを使用して、到着した最新の SYN の IP-ECN フィールドをフィードバックします。
* If a TCP Server enters AccECN mode and then subsequently sends a SYN/ACK or receives a SYN with (AE,CWR,ECE) = (0,0,0), it is prohibited from setting ECT on any packet for the rest of the connection.
* TCP サーバーが AccECN モードに入り、その後 SYN/ACK を送信するか、(AE,CWR,ECE) = (0,0,0) の SYN を受信した場合、残りの接続ではパケットに ECT を設定することが禁止されます。
* Having entered AccECN mode, in general a TCP Server commits to respond to any incoming congestion feedback, whether or not it sets ECT on outgoing packets (for rationale and some exceptions see Sections 3.2.2.3, 3.2.2.4).
* AccECN モードに入ると、一般に、TCP サーバーは、送信パケットに ECT を設定するかどうかに関係なく、受信する輻輳フィードバックに応答することを約束します (理論的根拠と一部の例外については、セクション 3.2.2.3、3.2.2.4 を参照)。
* Having entered AccECN mode, a TCP Server commits to using AccECN to feed back the IP-ECN field in incoming packets for the rest of the connection, as specified in Section 3.2, even if it is not itself setting ECT on outgoing packets.
* AccECN モードに入ると、TCP サーバーは、送信パケットに ECT を設定していない場合でも、セクション 3.2 で指定されているように、接続の残りの部分で受信パケットの IP-ECN フィールドをフィードバックするために AccECN を使用することを約束します。
Section 3.1.1 describes the only ways that a host can enter AccECN mode, whether as a Client or as a Server.
セクション 3.1.1 では、ホストがクライアントまたはサーバーとして AccECN モードに入る唯一の方法について説明します。
An implementation that supports AccECN has the rights and obligations concerning the use of ECN defined below, which update those in Section 6.1.1 of [RFC3168]. This section uses the following definitions:
AccECN をサポートする実装には、以下に定義されている ECN の使用に関する権利と義務があり、[RFC3168] のセクション 6.1.1 の権利と義務が更新されます。このセクションでは次の定義を使用します。
'During the handshake':
「握手中」：
The connection states prior to synchronization.
同期前の接続状態。
'Valid SYN':
「有効な SYN」:
A SYN that has the same port numbers and the same ISN as the SYN that first caused the Server to open the connection. An 'Acceptable' packet is defined in Section 1.3.
最初にサーバーに接続を開かせた SYN と同じポート番号と同じ ISN を持つ SYN。「Acceptable」パケットはセクション 1.3 で定義されています。
Handling SYNs or SYN/ACKs of multiple types (e.g., fall-back):
複数のタイプの SYN または SYN/ACK の処理 (フォールバックなど):
* Any implementation that supports AccECN:
* AccECN をサポートする実装:
- MUST NOT switch into a different feedback mode from the one it first entered according to Table 2, no matter whether it subsequently receives valid SYNs or Acceptable SYN/ACKs of different types;
- 有効な SYN を受信するか、異なるタイプの許容可能な SYN/ACK を受信するかに関係なく、表 2 に従って最初に入ったフィードバック モードとは異なるフィードバック モードに切り替えてはなりません。
- SHOULD ignore the TCP-ECN flags in SYNs or SYN/ACKs that are received after the implementation reaches the ESTABLISHED state, in line with the general TCP approach [RFC9293];
- 一般的な TCP アプローチ [RFC9293] に従って、実装が ESTABLISHED 状態に達した後に受信される SYN または SYN/ACK 内の TCP-ECN フラグを無視すべきです (SHOULD)。
Reason: Reaching ESTABLISHED state implies that at least one SYN and one SYN/ACK have successfully been delivered. And all the rules for handshake fall-back are designed to work based on those packets that successfully traverse the path, whatever other handshake packets are lost or delayed.
理由: ESTABLISHED 状態に達すると、少なくとも 1 つの SYN と 1 つの SYN/ACK が正常に配信されたことを意味します。また、ハンドシェイク フォールバックのすべてのルールは、他のハンドシェイク パケットが失われたり遅延したりしても、パスを正常に通過したパケットに基づいて機能するように設計されています。
- MUST NOT send a 'Classic' ECN-setup SYN [RFC3168] with (AE,CWR,ECE) = (0,1,1) and a SYN with (AE,CWR,ECE) = (1,1,1) requesting AccECN feedback within the same connection;
- (AE,CWR,ECE) = (0,1,1) の「クラシック」ECN セットアップ SYN [RFC3168] と、(AE,CWR,ECE) = (1,1,1) の SYN を同じ接続内で送信してはなりません。
- MUST NOT send a 'Classic' ECN-setup SYN/ACK [RFC3168] with (AE,CWR,ECE) = (0,0,1) and a SYN/ACK agreeing to use AccECN feedback within the same connection;
- (AE,CWR,ECE) = (0,0,1) の「クラシック」 ECN セットアップ SYN/ACK [RFC3168] と、同じ接続内で AccECN フィードバックの使用に同意する SYN/ACK を送信してはなりません。
- MUST reset the connection with a RST packet, if it receives a 'Classic' ECN-setup SYN with (AE,CWR,ECE) = (0,1,1) and a SYN requesting AccECN feedback during the same handshake;
- 同じハンドシェイク中に (AE,CWR,ECE) = (0,1,1) の「クラシック」 ECN セットアップ SYN と AccECN フィードバックを要求する SYN を受信した場合、RST パケットとの接続をリセットしなければなりません。
- MUST reset the connection with a RST packet, if it receives 'Classic' ECN-setup SYN/ACK with (AE,CWR,ECE) = (0,0,1) and a SYN/ACK agreeing to use AccECN feedback during the same handshake.
- (AE,CWR,ECE) = (0,0,1) の「クラシック」 ECN セットアップ SYN/ACK と、同じハンドシェイク中に AccECN フィードバックの使用に同意する SYN/ACK を受信した場合、RST パケットで接続をリセットしなければなりません。
The last four rules are necessary because, if one peer were to negotiate the feedback mode in two different types of handshake, it would not be possible for the other peer to know for certain which handshake packet(s) the other end had eventually received or in which order it received them. So, in the absence of these rules, the two peers could end up using different ECN feedback modes without knowing it.
最後の 4 つのルールが必要なのは、一方のピアが 2 つの異なるタイプのハンドシェイクでフィードバック モードをネゴシエートする場合、もう一方のピアは、相手側が最終的にどのハンドシェイク パケットを受信したか、またはどの順序でパケットを受信したかを確実に知ることができないためです。したがって、これらのルールが存在しない場合、2 つのピアは知らないうちに異なる ECN フィードバック モードを使用してしまう可能性があります。
* A host in AccECN mode that is feeding back the IP-ECN field on a SYN or SYN/ACK:
* SYN または SYN/ACK で IP-ECN フィールドをフィードバックしている AccECN モードのホスト:
- MUST feed back the IP-ECN field on the latest valid SYN or acceptable SYN/ACK to arrive.
- 最新の有効な SYN または受信可能な SYN/ACK を IP-ECN フィールドにフィードバックしなければなりません。
* A TCP Server already in AccECN mode:
* TCP サーバーはすでに AccECN モードになっています:
- SHOULD acknowledge a valid SYN arriving with (AE,CWR,ECE) = (0,0,0) by emitting an AccECN SYN/ACK (with the appropriate combination of TCP-ECN flags to feed back the IP-ECN field of this latest SYN);
- (AE,CWR,ECE) = (0,0,0) で到着する有効な SYN を、(この最新の SYN の IP-ECN フィールドをフィードバックするための TCP-ECN フラグの適切な組み合わせを使用して) AccECN SYN/ACK を発行することによって確認すべきです (SHOULD)。
- MAY acknowledge a valid SYN arriving with (AE,CWR,ECE) = (0,0,0) by sending a SYN/ACK with (AE,CWR,ECE) = (0,0,0).
- (AE,CWR,ECE) = (0,0,0) の SYN/ACK を送信することで、(AE,CWR,ECE) = (0,0,0) で到着した有効な SYN を確認してもよい(MAY)。
Rationale: When a SYN arrives with (AE,CWR,ECE) = (0,0,0) at a TCP Server that is already in AccECN mode, it implies that the TCP Client had probably not received the previous AccECN SYN/ACK emitted by the TCP Server. Therefore, the first bullet recommends attempting at least one more AccECN SYN/ACK. Nonetheless, the second bullet recognizes that the Server might eventually need to fall back to a non-ECN SYN/ACK. In either case, the TCP Server remains in AccECN feedback mode (according to the earlier requirement not to switch modes).
理論的根拠: すでに AccECN モードになっている TCP サーバーに SYN が (AE,CWR,ECE) = (0,0,0) で到着した場合、TCP クライアントが TCP サーバーによって発行された以前の AccECN SYN/ACK をおそらく受信していなかったことを意味します。したがって、最初の箇条書きでは、少なくとも 1 回以上 AccECN SYN/ACK を試行することをお勧めします。それにもかかわらず、2 番目の箇条書きでは、サーバーが最終的に非 ECN SYN/ACK にフォールバックする必要がある可能性があることを認識しています。どちらの場合でも、TCP サーバーは AccECN フィードバック モードのままになります (モードを切り替えないという以前の要件に従って)。
* An AccECN-capable TCP Server already in Not ECN mode:
* AccECN 対応の TCP サーバーはすでに非 ECN モードになっています:
- SHOULD respond to any subsequent valid SYN using a SYN/ACK with (AE,CWR,ECE) = (0,0,0), even if the SYN is offering to negotiate Classic ECN or AccECN feedback mode.
- SYN が Classic ECN または AccECN フィードバック モードのネゴシエーションを提案している場合でも、(AE,CWR,ECE) = (0,0,0) の SYN/ACK を使用して後続の有効な SYN に応答すべきです (SHOULD)。
Rationale: There would be no point in the Server offering any type of ECN feedback, because the Client will not be using ECN. However, there is no interoperability reason to make this rule mandatory.
理論的根拠: クライアントは ECN を使用しないため、サーバーがいかなる種類の ECN フィードバックを提供しても意味がありません。ただし、このルールを必須にする相互運用性の理由はありません。
If for any reason a host is not willing to provide ECN feedback on a particular TCP connection, it SHOULD clear the AE, CWR, and ECE flags in all SYN and/or SYN/ACK packets that it sends.
何らかの理由で、ホストが特定の TCP 接続上で ECN フィードバックを提供したくない場合、送信するすべての SYN および/または SYN/ACK パケット内の AE、CWR、および ECE フラグをクリアする必要があります (SHOULD)。
Sending ECT:
ECT の送信:
* Any implementation that supports AccECN:
* AccECN をサポートする実装:
- MUST NOT set ECT if it is in Not ECN feedback mode.
- Not ECN フィードバック モードの場合は、ECT を設定してはなりません。
A Data Sender in AccECN mode:
AccECN モードのデータ送信者:
- SHOULD set an ECT codepoint in the IP header of packets to indicate to the network that the transport is capable and willing to participate in ECN for this packet;
- トランスポートがこのパケットの ECN に参加する能力があり、参加する意思があることをネットワークに示すために、パケットの IP ヘッダーに ECT コードポイントを設定すべきです。
- MAY not set ECT on any packet (for instance if it has reason to believe such a packet would be blocked).
- どのパケットにも ECT を設定してはなりません (たとえば、そのようなパケットがブロックされると信じる理由がある場合)。
A TCP Server in AccECN mode:
AccECN モードの TCP サーバー:
- MUST NOT set ECT on any packet for the rest of the connection, if it has received or sent at least one valid SYN or Acceptable SYN/ACK with (AE,CWR,ECE) = (0,0,0) during the handshake.
- ハンドシェイク中に (AE,CWR,ECE) = (0,0,0) で少なくとも 1 つの有効な SYN または許容可能な SYN/ACK を受信または送信した場合、接続の残りのパケットに ECT を設定してはなりません (MUST NOT)。
This rule solely applies to a Server because, when a Server enters AccECN mode, it doesn't know for sure whether the Client will end up in AccECN mode. But when a Client enters AccECN mode, it can be certain that the Server is already in AccECN feedback mode.
サーバーが AccECN モードに入ったとき、クライアントが最終的に AccECN モードになるかどうかはわからないため、このルールはサーバーにのみ適用されます。ただし、クライアントが AccECN モードに入ると、サーバーはすでに AccECN フィードバック モードになっていることがわかります。
Congestion response:
輻輳対応:
* A host in AccECN mode:
* AccECN モードのホスト:
- is obliged to respond appropriately to AccECN feedback that indicates there were ECN marks on packets it had previously sent, where 'appropriately' is defined in Section 6.1 of [RFC3168] and updated by Sections 2.1 and 4.1 of [RFC8311];
- は、以前に送信したパケットに ECN マークがあったことを示す AccECN フィードバックに適切に応答する義務があります。「適切に」とは [RFC3168] のセクション 6.1 で定義され、[RFC8311] のセクション 2.1 および 4.1 によって更新されます。
- is still obliged to respond appropriately to congestion feedback, even when it is solely sending non-ECN-capable packets (for rationale, some examples and some exceptions see Sections 3.2.2.3 and 3.2.2.4);
- ECN 非対応パケットのみを送信している場合でも、輻輳フィードバックに適切に応答する義務があります (根拠については、いくつかの例と例外についてはセクション 3.2.2.3 および 3.2.2.4 を参照)。
- is still obliged to respond appropriately to congestion feedback, even if it has sent or received a SYN or SYN/ACK packet with (AE,CWR,ECE) = (0,0,0) during the handshake;
- ハンドシェイク中に (AE,CWR,ECE) = (0,0,0) の SYN または SYN/ACK パケットを送受信した場合でも、輻輳フィードバックに適切に応答する義務があります。
- MUST NOT set CWR to indicate that it has received and responded to indications of congestion.
- 輻輳の兆候を受信して応答したことを示すように CWR を設定してはなりません。
For the avoidance of doubt, this is unlike an RFC 3168 data sender and this does not preclude the Data Sender from setting the bits of the ACE counter field, which includes an overloaded use of the same bit.
誤解を避けるため、これは RFC 3168 データ送信者とは異なり、同じビットのオーバーロード使用を含む ACE カウンタ フィールドのビットを設定することをデータ送信者が妨げるものではありません。
Receiving ECT:
ECTの受信:
* A host in AccECN mode:
* AccECN モードのホスト:
- MUST feed back the information in the IP-ECN field of incoming packets using Accurate ECN feedback, as specified in Section 3.2.
- セクション 3.2 で規定されているように、正確な ECN フィードバックを使用して、受信パケットの IP-ECN フィールドの情報をフィードバックしなければなりません (MUST)。
For the avoidance of doubt, this requirement stands even if the AccECN host has also sent or received a SYN or SYN/ACK with (AE,CWR,ECE) = (0,0,0). Reason: Such a SYN or SYN/ACK implies some form of packet mangling might be present. Even if the remote peer is not setting ECT, it could still be set erroneously by packet mangling at the IP layer (see Section 3.2.2.3). In such cases, the Data Sender is best placed to decide whether ECN markings are valid, but it can only do that if the Data Receiver mechanistically feeds back any ECN markings. This approach will not lead to TCP Options being generated unnecessarily if the recommended simple scheme in Section 3.2.3.3 is used, because no byte counters will change if no packets are set to ECT.
誤解を避けるため、この要件は、AccECN ホストが (AE,CWR,ECE) = (0,0,0) で SYN または SYN/ACK を送信または受信した場合でも有効です。理由: このような SYN または SYN/ACK は、何らかの形式のパケットマングリングが存在する可能性があることを意味します。リモート ピアが ECT を設定していない場合でも、IP 層でのパケットマングリングによって誤って設定される可能性があります (セクション 3.2.2.3 を参照)。このような場合、データ送信者は ECN マーキングが有効かどうかを判断するのに最適ですが、データ受信者が何らかの ECN マーキングを機械的にフィードバックする場合にのみそれが可能です。このアプローチでは、セクション 3.2.3.3 で推奨されている単純なスキームが使用されている場合、パケットが ECT に設定されていない場合はバイト カウンタが変更されないため、TCP オプションが不必要に生成されることはありません。
- MUST NOT use reception of packets with ECT set in the IP-ECN field as an implicit signal that the peer is ECN-capable.
- IP-ECN フィールドに ECT が設定されたパケットの受信を、ピアが ECN 対応であることを示す暗黙の信号として使用してはなりません (MUST NOT)。
Reason: ECT at the IP layer does not explicitly confirm the peer has the correct ECN feedback logic, because the packets could have been mangled at the IP layer.
理由: パケットが IP 層で破損している可能性があるため、IP 層の ECT は、ピアが正しい ECN フィードバック ロジックを備えていることを明示的に確認しません。
Each Data Receiver of each half-connection maintains four counters, r.cep, r.ceb, r.e0b, and r.e1b:
各ハーフ接続の各データ レシーバーは、r.cep、r.ceb、r.e0b、および r.e1b の 4 つのカウンターを維持します。
* The Data Receiver MUST increment the CE packet counter (r.cep), for every Acceptable packet that it receives with the CE code point in the IP-ECN field, including CE-marked control packets and retransmissions but excluding CE on SYN packets (SYN=1; ACK=0).
* データ受信者は、IP-ECN フィールドの CE コード ポイントを持つすべての Acceptable パケットを受信するたびに、CE パケット カウンター (r.cep) をインクリメントしなければなりません (MUST)。これには、CE マークが付けられた制御パケットと再送信が含まれますが、SYN パケット (SYN=1; ACK=0) の CE は含まれません。
* A Data Receiver that supports sending of AccECN TCP Options MUST increment the r.ceb, r.e0b, or r.e1b byte counters by the number of TCP payload octets in Acceptable packets marked with the CE, ECT(0), and ECT(1) codepoint in their IP-ECN field, including any payload octets on control packets and retransmissions, but not including any payload octets on SYN packets (SYN=1; ACK=0).
* AccECN TCP オプションの送信をサポートするデータ受信者は、IP-ECN フィールドの CE、ECT(0)、および ECT(1) コードポイントでマークされた Acceptable パケット内の TCP ペイロード オクテットの数だけ r.ceb、r.e0b、または r.e1b バイト カウンタを増分しなければなりません (制御パケットと再送信のペイロード オクテットは含みますが、制御パケットと再送信のペイロード オクテットは含みません)。SYN パケット (SYN=1; ACK=0)。
Each Data Sender of each half-connection maintains four counters, s.cep, s.ceb, s.e0b, and s.e1b, intended to track the equivalent counters at the Data Receiver.
各ハーフ接続の各データ送信者は、データ受信者での同等のカウンタを追跡することを目的とした 4 つのカウンタ s.cep、s.ceb、s.e0b、および s.e1b を維持します。
A Data Receiver feeds back the CE packet counter using the Accurate ECN (ACE) field, as explained in Section 3.2.2. And it optionally feeds back all the byte counters using the AccECN TCP Option, as specified in Section 3.2.3.
データ受信機は、セクション 3.2.2 で説明されているように、Accurate ECN (ACE) フィールドを使用して CE パケット カウンタをフィードバックします。また、オプションで、セクション 3.2.3 で指定されているように、AccECN TCP オプションを使用してすべてのバイト カウンタをフィードバックします。
Whenever a Data Receiver feeds back the value of any counter, it MUST report the most recent value, no matter whether it is in a pure ACK, or an ACK piggybacked on a packet used by the other half-connection, whether a new payload data or a retransmission. Therefore, the feedback piggybacked on a retransmitted packet is unlikely to be the same as the feedback on the original packet.
データ受信者がカウンタの値をフィードバックするときは、それが純粋な ACK であるか、他の半接続で使用されるパケットに便乗した ACK (新しいペイロード データであるか再送信であるか) であるかどうかに関係なく、最新の値を報告しなければなりません(MUST)。したがって、再送信されたパケットに追加されたフィードバックは、元のパケットのフィードバックと同じである可能性は低くなります。
When a host first enters AccECN mode, in its role as a Data Receiver, it initializes its counters to r.cep = 5, r.e0b = r.e1b = 1, and r.ceb = 0.
ホストが初めて AccECN モードに入ると、データ レシーバーとしての役割で、カウンターを r.cep = 5、r.e0b = r.e1b = 1、および r.ceb = 0 に初期化します。
Non-zero initial values are used to support a stateless handshake (see Section 5.1) and to be distinct from cases where the fields are incorrectly zeroed (e.g., by middleboxes -- see Section 3.2.3.2.4).
ゼロ以外の初期値は、ステートレス ハンドシェイク (セクション 5.1 を参照) をサポートし、フィールドが誤ってゼロに設定される場合 (例: ミドルボックスによって -- セクション 3.2.3.2.4 を参照) を区別するために使用されます。
When a host enters AccECN mode, in its role as a Data Sender, it initializes its counters to s.cep = 5, s.e0b = s.e1b = 1, and s.ceb = 0.
ホストが AccECN モードに入ると、データ送信側としての役割で、カウンターを s.cep = 5、s.e0b = s.e1b = 1、および s.ceb = 0 に初期化します。
After AccECN has been negotiated on the SYN and SYN/ACK, both hosts overload the three TCP flags (AE, CWR, and ECE) in the main TCP header as one 3-bit field. Then the field is given a new name, ACE, as shown in Figure 3.
AccECN が SYN および SYN/ACK でネゴシエートされた後、両方のホストがメイン TCP ヘッダー内の 3 つの TCP フラグ (AE、CWR、および ECE) を 1 つの 3 ビット フィールドとしてオーバーロードします。次に、図 3 に示すように、フィールドに ACE という新しい名前が付けられます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | | U | A | P | R | S | F |
| Header Length | Reserved | ACE | R | C | S | S | Y | I |
| | | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 3: Definition of the ACE Field Within Bytes 13 and 14 of the TCP Header (When AccECN Has Been Negotiated and SYN=0).
図 3: TCP ヘッダーのバイト 13 および 14 内の ACE フィールドの定義 (AccECN がネゴシエートされており、SYN=0 の場合)。
The original definition of these three flags in the TCP header, including the addition of support for the ECN-nonce, is shown for comparison in Figure 1. This specification does not rename these three TCP flags to ACE unconditionally; it merely overloads them with another name and definition once an AccECN connection has been established.
ECN-nonce のサポートの追加を含む、TCP ヘッダー内のこれら 3 つのフラグの元の定義を比較のために図 1 に示します。この仕様では、これら 3 つの TCP フラグの名前を無条件に ACE に変更するわけではありません。AccECN 接続が確立されたら、単に別の名前と定義でオーバーロードするだけです。
With one exception (Section 3.2.2.1), a host with both of its half-connections in AccECN mode MUST interpret the AE, CWR, and ECE flags as the 3-bit ACE counter on a segment with the SYN flag cleared (SYN=0). On such a packet, a Data Receiver MUST encode the 3 least significant bits of its r.cep counter into the ACE field that it feeds back to the Data Sender. The least significant bit is at bit offset 9 in Figure 3. A host MUST NOT interpret the three flags as a 3-bit ACE field on any segment with SYN=1 (whether ACK is 0 or 1), or if AccECN negotiation is incomplete or has not succeeded.
1 つの例外 (セクション 3.2.2.1) を除き、両方のハーフ接続が AccECN モードであるホストは、AE、CWR、および ECE フラグを、SYN フラグがクリアされた (SYN=0) セグメント上の 3 ビット ACE カウンタとして解釈しなければなりません (MUST)。このようなパケットでは、データ受信者は、r.cep カウンタの最下位 3 ビットをデータ送信者にフィードバックする ACE フィールドにエンコードしなければなりません (MUST)。最下位ビットは、図 3 のビット オフセット 9 にあります。ホストは、SYN=1 (ACK が 0 か 1 かに関係なく) のセグメント上、または AccECN ネゴシエーションが不完全であるか成功していない場合に、3 つのフラグを 3 ビットの ACE フィールドとして解釈してはなりません (MUST NOT)。
Both parts of each of these conditions are equally important. For instance, even if AccECN negotiation has been successful, the ACE field is not defined on any segments with SYN=1 (e.g., a retransmission of an unacknowledged SYN/ACK, or when both ends send SYN/ACKs after AccECN support has been successfully negotiated during a simultaneous open).
これらの各条件の両方の部分が同様に重要です。たとえば、AccECN ネゴシエーションが成功した場合でも、SYN=1 のセグメントでは ACE フィールドは定義されません (たとえば、未確認の SYN/ACK の再送信、または同時オープン中に AccECN サポートのネゴシエーションが成功した後に両端が SYN/ACK を送信した場合など)。
If the TCP Client (A) in AccECN mode uses a pure ACK with no SACK blocks to acknowledge the SYN/ACK, it MUST use the binary encoding in Table 3 when writing the ACE field (which is the same as the encoding used on the SYN/ACK in Table 2). This feeds back which of the 4 possible values of the IP-ECN field was on the SYN/ACK. This shall be called the "handshake encoding" of the ACE field, and it is the only exception to the rule that the ACE field carries the 3 least significant bits of the r.cep counter on packets with SYN=0.
AccECN モードの TCP クライアント (A) が、SYN/ACK の確認応答に SACK ブロックのない純粋な ACK を使用する場合、ACE フィールドを書き込むときに、表 3 のバイナリ エンコーディングを使用しなければなりません (表 2 の SYN/ACK で使用されるエンコーディングと同じです)。これは、IP-ECN フィールドの 4 つの可能な値のうちどれが SYN/ACK にあったかをフィードバックします。これは、ACE フィールドの「ハンドシェイク エンコーディング」と呼ばれるもので、ACE フィールドが SYN=0 のパケットの r.cep カウンタの最下位 3 ビットを伝送するというルールの唯一の例外です。
Normally, a TCP Client acknowledges a SYN/ACK with an ACK that satisfies the above conditions anyway (SYN=0, no data, no SACK blocks). If an AccECN TCP Client intends to acknowledge the SYN/ACK with a packet that does not satisfy these conditions (e.g., it has data to include on the ACK), it SHOULD first send a pure ACK that does satisfy these conditions (see Section 5.2), so that it can feed back which of the four values of the IP-ECN field arrived on the SYN/ ACK. A valid exception to this "SHOULD" would be where the implementation will only be used in an environment where mangling of the ECN field is unlikely.
通常、TCP クライアントは、上記の条件を満たす ACK で SYN/ACK を確認します (SYN=0、データなし、SACK ブロックなし)。AccECN TCP クライアントが、これらの条件を満たさないパケット (例、ACK に含めるデータがある) で SYN/ACK を確認しようとする場合、SYN/ACK で到着した IP-ECN フィールドの 4 つの値をフィードバックできるように、これらの条件を満たす純粋な ACK を最初に送信する必要があります (セクション 5.2 を参照)。この「SHOULD」に対する有効な例外は、ECN フィールドのマングリングが起こりそうもない環境でのみ実装が使用される場合です。
The TCP Client MUST also use the handshake encoding for the pure ACK of any retransmitted SYN/ACK that confirms that the TCP Server supports AccECN. If the TCP Server does not receive the final ACK of the handshake before its retransmission timer expires, the procedure for it to follow is given in Section 3.1.4.2.
TCP クライアントは、TCP サーバーが AccECN をサポートしていることを確認する、再送信された SYN/ACK の純粋な ACK にもハンドシェイク エンコーディングを使用しなければなりません (MUST)。TCP サーバーが再送信タイマーが期限切れになる前にハンドシェイクの最終 ACK を受信しなかった場合、TCP サーバーが従う手順はセクション 3.1.4.2 に示されています。
+==================+================+=====================+
| IP-ECN Codepoint | ACE on Pure | r.cep of TCP Client |
| on SYN/ACK | ACK of SYN/ACK | in AccECN Mode |
+==================+================+=====================+
| Not-ECT | 0b010 | 5 |
+------------------+----------------+---------------------+
| ECT(1) | 0b011 | 5 |
+------------------+----------------+---------------------+
| ECT(0) | 0b100 | 5 |
+------------------+----------------+---------------------+
| CE | 0b110 | 6 |
+------------------+----------------+---------------------+
Table 3: The Encoding of the ACE Field in the ACK of the SYN-ACK to Reflect the SYN-ACK's IP-ECN Field
表 3: SYN-ACK の IP-ECN フィールドを反映するための、SYN-ACK の ACK 内の ACE フィールドのエンコーディング
When an AccECN Server in SYN-RCVD state receives a pure ACK with SYN=0 and no SACK blocks, it MUST infer the meaning of each possible value of the ACE field from Table 4 instead of treating the ACE field as a counter. As a result, an AccECN Server MUST set s.cep to the respective value, also shown in Table 4.
SYN-RCVD 状態の AccECN サーバーが、SYN=0 で SACK ブロックのない純粋な ACK を受信した場合、ACE フィールドをカウンターとして扱うのではなく、表 4 から ACE フィールドの可能な各値の意味を推測しなければなりません (MUST)。その結果、AccECN サーバーは、s.cep を表 4 に示すそれぞれの値に設定しなければなりません (MUST)。
Given this encoding of the ACE field on the ACK of a SYN/ACK is exceptional, an AccECN Server using large receive offload (LRO) might prefer to disable LRO until it transitions out of SYN-RCVD state (when it first receives an ACK that covers the SYN/ACK).
SYN/ACK の ACK 上の ACE フィールドのエンコーディングが例外的であることを考慮すると、大規模受信オフロード (LRO) を使用する AccECN サーバーは、SYN-RCVD 状態から移行するまで (SYN/ACK をカバーする ACK を最初に受信したとき)、LRO を無効にすることを好む可能性があります。
+============+==========================+=====================+
| ACE on ACK | IP-ECN Codepoint on SYN/ | s.cep of TCP Server |
| of SYN/ACK | ACK Inferred by Server | in AccECN Mode |
+============+==========================+=====================+
| 0b000 | {Notes 1, 3} | Disable s.cep |
+------------+--------------------------+---------------------+
| 0b001 | {Notes 2, 3} | 5 |
+------------+--------------------------+---------------------+
| 0b010 | Not-ECT | 5 |
+------------+--------------------------+---------------------+
| 0b011 | ECT(1) | 5 |
+------------+--------------------------+---------------------+
| 0b100 | ECT(0) | 5 |
+------------+--------------------------+---------------------+
| 0b101 | Currently Unused {Note | 5 |
| | 2} | |
+------------+--------------------------+---------------------+
| 0b110 | CE | 6 |
+------------+--------------------------+---------------------+
| 0b111 | Currently Unused {Note | 5 |
| | 2} | |
+------------+--------------------------+---------------------+
Table 4: Meaning of the ACE Field on the ACK of the SYN/ACK
表 4: SYN/ACK の BACK の ACE フィールドの意味
Note 1:
注1:
If the Server is in AccECN mode and in SYN-RCVD state, and if it receives a value of zero on a pure ACK with SYN=0 and no SACK blocks, for the rest of the connection the Server MUST NOT set ECT on outgoing packets and MUST NOT respond to AccECN feedback. Nonetheless, as a Data Receiver, it MUST NOT disable AccECN feedback.
サーバーが AccECN モードで SYN-RCVD 状態にあり、SYN=0 で SACK ブロックを持たない純粋な ACK で値 0 を受信した場合、残りの接続中、サーバーは発信パケットに ECT を設定してはならず、AccECN フィードバックに応答してはなりません (MUST NOT)。それにもかかわらず、データ受信者として、AccECN フィードバックを無効にしてはなりません。
Any of the circumstances below could cause a value of zero but, whatever the cause, the actions above would be the appropriate response:
以下のいずれかの状況では値が 0 になる可能性がありますが、原因が何であれ、上記のアクションが適切な対応となります。
* The TCP Client has somehow entered No ECN feedback mode (most likely if the Server received a SYN or sent a SYN/ ACK with (AE,CWR,ECE) = (0,0,0) after entering AccECN mode, but possible even if it didn't).
* TCP クライアントが何らかの理由で ECN フィードバックなしモードに入っています (サーバーが AccECN モードに入った後に (AE,CWR,ECE) = (0,0,0) で SYN を受信したか、SYN/ACK を送信した場合が最も考えられますが、そうでない場合でも可能性があります)。
* The TCP Client genuinely might be in AccECN mode, but its count of received CE marks might have caused the ACE field to wrap to zero. This is highly unlikely, but not impossible because the Server might have already sent multiple packets while still in SYN-RCVD state, e.g., using TFO (see Section 5.2), and some might have been CE-marked. Then ACE on the first ACK seen by the Server might be zero, due to previous ACKs experiencing an unfortunate pattern of loss or delay.
* TCP クライアントは実際には AccECN モードである可能性がありますが、受信した CE マークの数によって ACE フィールドがゼロにラップされた可能性があります。これは可能性は非常に低いですが、不可能ではありません。サーバーが SYN-RCVD 状態にある間に、たとえば TFO (セクション 5.2 を参照) を使用してすでに複数のパケットを送信している可能性があり、一部には CE マークが付けられている可能性があるためです。その場合、以前の ACK で損失または遅延という不幸なパターンが発生したために、サーバーが認識した最初の ACK の ACE がゼロになる可能性があります。
* There is some form of non-compliance at the TCP Client or on the path.
* TCP クライアントまたはパス上に何らかの形式の不準拠があります。
Note 2:
注2:
If the Server is in AccECN mode, these values are Currently Unused but the AccECN Server's behaviour is still defined for forward compatibility. Then the designer of a future protocol can know for certain what AccECN Servers will do with these codepoints.
サーバーが AccECN モードの場合、これらの値は現在未使用ですが、AccECN サーバーの動作は上位互換性のために定義されています。そうすれば、将来のプロトコルの設計者は、AccECN サーバーがこれらのコードポイントで何を行うかを確実に知ることができます。
Note 3:
注3:
In the case where a Server that implements AccECN is also using a stateless handshake (termed a SYN cookie), it will not remember whether it entered AccECN mode. The values 0b000 or 0b001 will remind it that it did not enter AccECN mode, because AccECN does not use them (see Section 5.1 for details). If a Server that uses a stateless handshake and implements AccECN receives either of these two values in the ACK, its action is implementation-dependent and outside the scope of this document. It will certainly not take the action in the third column because, after it receives either of these values, it is not in AccECN mode. That is, it will not disable ECN (at least not just because ACE is 0b000) and it will not set s.cep.
AccECN を実装するサーバーがステートレス ハンドシェイク (SYN Cookie と呼ばれる) も使用している場合、サーバーは AccECN モードに入ったかどうかを記憶しません。値 0b000 または 0b001 は、AccECN がそれらを使用しないため、AccECN モードに入っていないことを思い出させます (詳細についてはセクション 5.1 を参照)。ステートレス ハンドシェイクを使用し、AccECN を実装するサーバーが ACK でこれら 2 つの値のいずれかを受信した場合、その動作は実装に依存し、このドキュメントの範囲外になります。これらの値のいずれかを受け取った後は AccECN モードではないため、3 列目のアクションは実行されません。つまり、ECN は無効になりません (少なくとも ACE が 0b000 であるという理由だけではありません)。また、s.cep も設定されません。
Whenever the Data Receiver sends an ACK with SYN=0 (with or without data), unless the handshake encoding in Section 3.2.2.1 applies, the Data Receiver MUST encode the least significant 3 bits of its r.cep counter into the ACE field (see Appendix A.2).
データ受信者が SYN=0 の ACK (データの有無にかかわらず) を送信するときは常に、セクション 3.2.2.1 のハンドシェイク エンコーディングが適用されない限り、データ受信者は r.cep カウンタの最下位 3 ビットを ACE フィールドにエンコードしなければなりません (付録 A.2 を参照)。
Whenever the Data Sender receives an ACK with SYN=0 (with or without data), it first checks whether it has already been superseded (defined in Appendix A.1) by another ACK in which case it ignores the ECN feedback. If the ACK has not been superseded, and if the special handshake encoding in Section 3.2.2.1 does not apply, the Data Sender decodes the ACE field as follows (see Appendix A.2 for examples).
データ送信側が SYN=0 の ACK (データの有無にかかわらず) を受信するたびに、まずその ACK がすでに別の ACK (付録 A.1 で定義) に置き換えられているかどうかをチェックします。その場合、ECN フィードバックは無視されます。ACK が置き換えられておらず、セクション 3.2.2.1 の特殊なハンドシェイク エンコーディングが適用されない場合、データ送信側は次のように ACE フィールドをデコードします (例については付録 A.2 を参照)。
* It takes the least significant 3 bits of its local s.cep counter and subtracts them from the incoming ACE counter to work out the minimum positive increment it could apply to s.cep (assuming the ACE field only wrapped once at most).
* ローカル s.cep カウンタの最下位 3 ビットを取得し、受信 ACE カウンタから減算して、s.cep に適用できる最小の正の増分を計算します (ACE フィールドが最大 1 回のみラップされると仮定します)。
* It then follows the safety procedures in Section 3.2.2.5.2 to calculate or estimate how many packets the ACK could have acknowledged under the prevailing conditions to determine whether the ACE field might have wrapped more than once.
* 次に、セクション 3.2.2.5.2 の安全手順に従って、一般的な条件下で ACK が確認できた可能性のあるパケットの数を計算または推定し、ACE フィールドが複数回ラップされた可能性があるかどうかを判断します。
The encode/decode procedures during the three-way handshake are exceptions to the general rules given so far, so they are spelled out step by step below for clarity:
スリーウェイ ハンドシェイク中のエンコード/デコード手順は、これまでに示した一般ルールの例外であるため、明確にするために以下に手順ごとに詳しく説明します。
* If a TCP Server in AccECN mode receives a CE mark in the IP-ECN field of a SYN (SYN=1, ACK=0), it MUST NOT increment r.cep (it remains at its initial value of 5).
* AccECN モードの TCP サーバーが SYN (SYN=1、ACK=0) の IP-ECN フィールドで CE マークを受信した場合、r.cep をインクリメントしてはなりません (初期値の 5 のままです)。
Reason: It would be redundant for the Server to include CE-marked SYNs in its r.cep counter, because it already reliably delivers feedback of any CE marking using the encoding in the top block of Table 2 in the SYN/ACK. This also ensures that, when the Server starts using the ACE field, it has not unnecessarily consumed more than one initial value, given they can be used to negotiate variants of the AccECN protocol (see Appendix B.3).
理由: サーバーは、SYN/ACK の表 2 の先頭ブロックのエンコーディングを使用して、CE マーキングのフィードバックをすでに確実に配信しているため、r.cep カウンターに CE マークの付いた SYN を含めることは冗長です。これにより、サーバーが ACE フィールドの使用を開始するときに、AccECN プロトコルのバリアントのネゴシエーションに使用できるため、複数の初期値が不必要に消費されないことも保証されます (付録 B.3 を参照)。
* If a TCP Client in AccECN mode receives CE feedback in the TCP flags of a SYN/ACK, it MUST NOT increment s.cep (it remains at its initial value of 5) so that it stays in step with r.cep on the Server. Nonetheless, the TCP Client still triggers the congestion control actions necessary to respond to the CE feedback.
* AccECN モードの TCP クライアントが SYN/ACK の TCP フラグで CE フィードバックを受信した場合、サーバー上の r.cep と歩調を合わせるために s.cep をインクリメントしてはなりません (初期値の 5 のままです)。それにもかかわらず、TCP クライアントは、CE フィードバックに応答するために必要な輻輳制御アクションをトリガーします。
* If a TCP Client in AccECN mode receives a CE mark in the IP-ECN field of a SYN/ACK, it MUST increment r.cep, but no more than once no matter how many CE-marked SYN/ACKs it receives (i.e., incremented from 5 to 6, but no further).
* AccECN モードの TCP クライアントが SYN/ACK の IP-ECN フィールドで CE マークを受信した場合、r.cep をインクリメントしなければなりません (MUST)。 ただし、受信した CE マーク付きの SYN/ACK の数に関係なく、1 回を超えてはいけません (つまり、5 から 6 にインクリメントしますが、それ以上は増分しません)。
Reason: Incrementing r.cep ensures the Client will eventually deliver any CE marking to the Server reliably when it starts using the ACE field. Even though the Client also feeds back any CE marking on the ACK of the SYN/ACK using the encoding in Table 3, this ACK is not delivered reliably, so it can be considered as a timely notification that is redundant but unreliable. The Client does not increment r.cep more than once, because the Server can only increment s.cep once (see next bullet). Also, this limits the unnecessarily consumed initial values of the ACE field to two.
理由: r.cep をインクリメントすると、クライアントが ACE フィールドの使用を開始したときに、クライアントが最終的にサーバーに CE マーキングを確実に配信できるようになります。クライアントも表 3 のエンコーディングを使用して SYN/ACK の ACK に CE マーキングをフィードバックしますが、この ACK は確実に配信されないため、冗長ではあるが信頼性の低いタイムリーな通知と見なすことができます。サーバーは s.cep を 1 回しかインクリメントできないため、クライアントは r.cep を複数回インクリメントしません (次の項目を参照)。また、これにより、不必要に消費される ACE フィールドの初期値が 2 に制限されます。
* If a TCP Server in AccECN mode and in SYN-RCVD state receives CE feedback in the TCP flags of a pure ACK with no SACK blocks, it MUST increment s.cep (from 5 to 6). The TCP Server then triggers the congestion control actions necessary to respond to the CE feedback.
* AccECN モードおよび SYN-RCVD 状態の TCP サーバーが、SACK ブロックのない純粋な ACK の TCP フラグで CE フィードバックを受信した場合、s.cep を (5 から 6 に) インクリメントしなければなりません (MUST)。次に、TCP サーバーは、CE フィードバックに応答するために必要な輻輳制御アクションをトリガーします。
Reasoning: The TCP Server can only increment s.cep once, because the first ACK it receives will cause it to transition out of SYN-RCVD state. The Server's congestion response would be no different, even if it could receive feedback of more than one CE-marked SYN/ACK.
理由: TCP サーバーは、最初に ACK を受信すると SYN-RCVD 状態から移行するため、s.cep を 1 回だけインクリメントできます。サーバーの輻輳応答は、複数の CE マーク付き SYN/ACK のフィードバックを受信できたとしても変わりません。
Once the TCP Server transitions to ESTABLISHED state, it might later receive other pure ACK(s) with the handshake encoding in the ACE field. A Server MAY implement a test for such a case, but it is not required. Therefore, once in the ESTABLISHED state, it will be sufficient for the Server to consider the ACE field to be encoded as the normal ACE counter on all packets with SYN=0.
TCP サーバーが ESTABLISHED 状態に移行すると、後で ACE フィールドのハンドシェイク エンコーディングを持つ他の純粋な ACK を受信する可能性があります。サーバーはそのような場合に備えてテストを実装してもよいですが、必須ではありません。したがって、ESTABLISHED 状態になると、サーバーは ACE フィールドが SYN=0 のすべてのパケットで通常の ACE カウンタとしてエンコードされるとみなすだけで十分です。
Reasoning: Such ACKs will be quite unusual, e.g., a SYN/ACK (or ACK of the SYN/ACK) that is delayed for longer than the Server's retransmission timeout; or packet duplication by the network. And the impact of any error in the feedback on such ACKs will only be temporary.
理由: このような ACK は非常に珍しいものです。たとえば、サーバーの再送信タイムアウトよりも長く遅延する SYN/ACK (または SYN/ACK の ACK)。またはネットワークによるパケットの重複。そして、そのような ACK に対するフィードバックにおけるエラーの影響は一時的なものにすぎません。
* TCP Client side:
* TCP クライアント側:
The value of the TCP-ECN flags on the SYN/ACK indicates the value of the IP-ECN field when the SYN arrived at the Server. The TCP Client can compare this with how it originally set the IP-ECN field on the SYN. If this comparison implies an invalid transition (defined below) of the IP-ECN field, for the remainder of the half-connection the Client is advised to send non-ECN-capable packets, but it still ought to respond to any feedback of CE markings (explained below). However, the TCP Client MUST remain in the AccECN feedback mode and it MUST continue to feed back any ECN markings on arriving packets (in its role as Data Receiver).
SYN/ACK の TCP-ECN フラグの値は、SYN がサーバーに到着したときの IP-ECN フィールドの値を示します。TCP クライアントは、これを最初に SYN に IP-ECN フィールドを設定した方法と比較できます。この比較が IP-ECN フィールドの無効な遷移 (以下で定義) を意味する場合、半接続の残りの間、クライアントは非 ECN 対応パケットを送信するようアドバイスされますが、それでも CE マーキング (以下で説明) のフィードバックには応答する必要があります。ただし、TCP クライアントは AccECN フィードバック モードのままでなければならず、(データ受信側としての役割で) 到着パケットの ECN マーキングをフィードバックし続けなければなりません (MUST)。
* TCP Server side:
* TCPサーバー側:
The value of the ACE field on the last ACK of the three-way handshake indicates the value of the IP-ECN field when the SYN/ACK arrived at the TCP Client. The Server can compare this with how it originally set the IP-ECN field on the SYN/ACK. If this comparison implies an invalid transition of the IP-ECN field, for the remainder of the half-connection the Server is advised to send non-ECN-capable packets, but it still ought to respond to any feedback of CE markings (explained below). However, the Server MUST remain in the AccECN feedback mode and it MUST continue to feed back any ECN markings on arriving packets (in its role as Data Receiver).
3 ウェイ ハンドシェイクの最後の ACK の ACE フィールドの値は、SYN/ACK が TCP クライアントに到着したときの IP-ECN フィールドの値を示します。サーバーはこれを、SYN/ACK の IP-ECN フィールドを最初に設定した方法と比較できます。この比較が IP-ECN フィールドの無効な遷移を意味する場合、サーバーは、半接続の残りの間、非 ECN 対応パケットを送信するよう推奨されますが、それでも CE マーキング (以下で説明) のフィードバックには応答する必要があります。ただし、サーバーは AccECN フィードバック モードのままでなければならず、(データ受信者としての役割で) 到着パケットの ECN マーキングをフィードバックし続けなければなりません。
If a Data Sender in AccECN mode starts sending non-ECN-capable packets because it has detected mangling, it is still advised to respond to CE feedback. Reason: Any CE marking arriving at the Data Receiver could be due to something early in the path mangling the non-ECN-capable IP-ECN field into an ECN-capable codepoint and then, later in the path, a network bottleneck might be applying CE markings to indicate genuine congestion. This argument applies whether the handshake packet originally sent by the TCP Client or Server was non-ECN-capable or ECN-capable because, in either case, an unsafe transition could imply that non-ECN-capable packets later in the connection might get mangled.
AccECN モードのデータ送信者がマングリングを検出したために ECN 非対応パケットの送信を開始した場合でも、CE フィードバックに応答することをお勧めします。理由: データ受信者に到着する CE マーキングは、パスの早い段階で非 ECN 対応の IP-ECN フィールドを ECN 対応のコードポイントに変換する何かが原因である可能性があり、その後、パスの後半でネットワークのボトルネックが本物の輻輳を示すために CE マーキングを適用している可能性があります。この引数は、TCP クライアントまたはサーバーによって最初に送信されたハンドシェイク パケットが ECN 非対応であるか ECN 対応であるかに関係なく適用されます。これは、どちらの場合でも、安全でない遷移は、接続の後半で ECN 非対応のパケットが破損する可能性があることを意味する可能性があるためです。
Once a Data Sender has entered AccECN mode it is advised to check whether it is receiving continuous feedback of CE. Specifying exactly how to do this is beyond the scope of the present specification, but the sender might check whether the feedback for every packet it sends for the first three or four rounds indicates CE marking. If continuous CE marking is detected, for the remainder of the half-connection, the Data Sender ought to send non-ECN-capable packets, and it is advised not to respond to any feedback of CE markings. The Data Sender might occasionally test whether it can resume sending ECN-capable packets.
データ送信者が AccECN モードに入ったら、CE のフィードバックを継続的に受信しているかどうかを確認することをお勧めします。これを行う方法を正確に指定することは、本仕様の範囲を超えていますが、送信者は、最初の 3 ラウンドまたは 4 ラウンドで送信するすべてのパケットのフィードバックが CE マーキングを示しているかどうかを確認する可能性があります。継続的な CE マーキングが検出された場合、残りの半接続では、データ送信者は ECN 非対応パケットを送信する必要があり、CE マーキングのフィードバックには応答しないことをお勧めします。データ送信者は、ECN 対応パケットの送信を再開できるかどうかをテストする場合があります。
The above advice on switching to sending non-ECN-capable packets but still responding to CE markings unless they become continuous is not stated normatively (in capitals), because the best strategy might depend on experience of the most likely types of mangling, which can only be known at the time of deployment. For instance, later in a connection, sender implementations might need to detect the onset (or the end) of mangling and stop (or start) sending ECN-capable packets accordingly.
ECN 非対応パケットの送信に切り替えても、継続的にならない限り CE マーキングに応答することに関する上記のアドバイスは、規範的に (大文字で) 述べられていません。最適な戦略は、展開時にのみ知ることができる最も可能性の高いタイプのマングリングの経験に依存する可能性があるためです。たとえば、接続の後半で、送信者の実装はマングリングの開始 (または終了) を検出し、それに応じて ECN 対応パケットの送信を停止 (または開始) する必要がある場合があります。
As always, once a host has entered AccECN mode, it follows the general mandatory requirements (Section 3.1.5) to remain in the same feedback mode and to continue feeding back any ECN markings on arriving packets using AccECN feedback. This follows the general approach where an AccECN Data Receiver mechanistically reflects whatever it receives (Section 2.5).
いつものように、ホストは AccECN モードに入ると、一般的な必須要件 (セクション 3.1.5) に従い、同じフィードバック モードを維持し、AccECN フィードバックを使用して到着パケットの ECN マーキングをフィードバックし続けます。これは、AccECN Data Receiver が受信したものをすべて機械的に反映するという一般的なアプローチに従います (セクション 2.5)。
The ACK of the SYN/ACK is not reliably delivered (nonetheless, the count of CE marks is still eventually delivered reliably). If this ACK does not arrive, the Server is advised to continue to send ECN-capable packets without having tested for mangling of the IP-ECN field on the SYN/ACK.
SYN/ACK の ACK は確実に配信されません (それでも、CE マークのカウントは最終的には確実に配信されます)。この ACK が到着しない場合、サーバーは SYN/ACK の IP-ECN フィールドの破損をテストせずに ECN 対応パケットの送信を続けることが推奨されます。
All the fall-back behaviours in this section are necessary in case mangling of the IP-ECN field is asymmetric, which is currently common over some mobile networks [Mandalari18]. In this case, one end might see no unsafe transition and continue sending ECN-capable packets, while the other end sees an unsafe transition and stops sending ECN-capable packets.
このセクションのフォールバック動作はすべて、IP-ECN フィールドのマングリングが非対称である場合に必要です。これは現在一部のモバイル ネットワークで一般的です [Mandalari18]。この場合、一方の端では安全でない遷移が検出されず、ECN 対応パケットの送信を継続する一方、もう一方の端では安全でない遷移が検出され、ECN 対応パケットの送信が停止される可能性があります。
Invalid transitions of the IP-ECN field are defined in Section 18 of the Classic ECN specification [RFC3168] and repeated here for convenience:
IP-ECN フィールドの無効な遷移は、クラシック ECN 仕様 [RFC3168] のセクション 18 で定義されており、便宜上ここで繰り返します。
* the Not-ECT codepoint changes;
* Not-ECT コードポイントの変更。
* either ECT codepoint transitions to Not-ECT;
* いずれかの ECT コードポイントが Not-ECT に移行します。
* the CE codepoint changes.
* CE コードポイントが変更されます。
RFC 3168 says that a router that changes ECT to Not-ECT is invalid but safe. However, from a host's viewpoint, this transition is unsafe because it could be the result of two transitions at different routers on the path: ECT to CE (safe) then CE to Not-ECT (unsafe). This scenario could well happen where an ECN-enabled home router congests its upstream mobile broadband bottleneck link, then the ingress to the mobile network clears the ECN field [Mandalari18].
RFC 3168 には、ECT を Not-ECT に変更するルーターは無効ですが安全であると記載されています。ただし、ホストの観点から見ると、この移行はパス上の異なるルーターでの 2 つの移行 (ECT から CE (安全)、次に CE から Not-ECT (安全ではない)) の結果である可能性があるため、安全ではありません。このシナリオは、ECN 対応のホーム ルータが上流のモバイル ブロードバンド ボトルネック リンクを輻輳させ、モバイル ネットワークへの入力によって ECN フィールドがクリアされる場合に発生する可能性があります [Mandalari18]。
Note that this section concerns the ACE field after the three way handshake. It does not concern the case where the ACE field is zero when the handshake encoding has been used on the ACK of the SYN/ACK under the carefully worded conditions in Section 3.2.2.1
このセクションは、3 ウェイ ハンドシェイク後の ACE フィールドに関するものであることに注意してください。セクション 3.2.2.1 の慎重に記述された条件の下で、ハンドシェイク エンコーディングが SYN/ACK の ACK で使用されている場合に、ACE フィールドがゼロである場合には関係ありません。
Section 3.2.2 required the Data Receiver to initialize the r.cep counter to a non-zero value. Therefore, in either direction the ACE counter ought to be non-zero in the first feedback packet (with or without data) that arrives at a host in AccECN mode after the three-way handshake. However, if reordering occurs, the first feedback packet that arrives will not necessarily be the same as the first packet in sequence order. The possibility of reordering means that there is a chance that the ACE field on the first packet to arrive after the three-way handshake is genuinely zero (without middlebox interference). Disabling ECN for a half-connection in this case would be unnecessary. Therefore, it is NOT RECOMMENDED for either Data Sender to explicitly test for zeroing/bleaching of the ACE field after the three-way handshake.
セクション 3.2.2 では、データ受信側が r.cep カウンターをゼロ以外の値に初期化する必要がありました。したがって、どちらの方向においても、スリーウェイ ハンドシェイク後に AccECN モードでホストに到着する最初のフィードバック パケット (データの有無にかかわらず) では、ACE カウンタはゼロ以外である必要があります。ただし、並べ替えが発生した場合、最初に到着するフィードバック パケットは、シーケンス順序で最初のパケットと必ずしも同じではありません。並べ替えの可能性は、スリーウェイ ハンドシェイク後に到着する最初のパケットの ACE フィールドが (ミドルボックスの干渉なしで) 完全にゼロになる可能性があることを意味します。この場合、半接続の ECN を無効にする必要はありません。したがって、いずれのデータ送信者も、スリーウェイ ハンドシェイク後に ACE フィールドのゼロ化/ブリーチングを明示的にテストすることは推奨されません。
Further, the Data Sender MUST NOT test whether the arriving counter in the initial ACE field has been initialized to a specific valid value. This allows hosts to use different initial values as an additional signalling channel in the future.
さらに、データ送信者は、初期 ACE フィールドの到着カウンタが特定の有効な値に初期化されているかどうかをテストしてはなりません (MUST NOT)。これにより、ホストは将来、追加のシグナリング チャネルとして異なる初期値を使用できるようになります。
If too many CE-marked segments are acknowledged at once, or if a long run of ACKs is lost or thinned out, the 3-bit counter in the ACE field might have cycled between two ACKs arriving at the Data Sender. The following safety procedures minimize this ambiguity.
一度に確認応答される CE マーク付きセグメントの数が多すぎる場合、または ACK の長い連続が失われたか間引かれた場合、ACE フィールドの 3 ビット カウンタは、データ送信者に到着する 2 つの ACK 間で循環している可能性があります。次の安全手順により、この曖昧さは最小限に抑えられます。
The following rules define when the receiver of a packet in AccECN mode emits an ACK:
次のルールは、AccECN モードのパケットの受信者がいつ ACK を送信するかを定義します。
Change-Triggered ACKs:
変更トリガーの ACK:
An AccECN Data Receiver SHOULD emit an ACK whenever a data packet marked CE arrives after the previous packet was not CE.
AccECN データ受信者は、前のパケットが CE でなかった後に CE とマークされたデータパケットが到着するたびに、ACK を発行すべきである(SHOULD)。
Even though this rule is stated as a "SHOULD", it is important for a transition to trigger an ACK if at all possible. The only valid exception to this rule is due to Large Receive Offload (LRO) or Generic Receive Offload (GRO) as further described below.
このルールは「SHOULD」として記載されていますが、可能であれば遷移で ACK をトリガーすることが重要です。このルールに対する唯一の有効な例外は、以下でさらに説明するように、Large Receive Offload (LRO) または Generic Receive Offload (GRO) によるものです。
For the avoidance of doubt, this rule is deliberately worded to apply solely when _data_ packets arrive, but the comparison with the previous packet includes any packet, not just data packets.
誤解を避けるため、このルールは、_data_ パケットが到着した場合にのみ適用されるように意図的に表現されていますが、前のパケットとの比較には、データ パケットだけでなくあらゆるパケットが含まれます。
Increment-Triggered ACKs:
インクリメントトリガーの ACK:
An AccECN receiver of a packet MUST emit an ACK if 'n' CE marks have arrived since the previous ACK. If there is unacknowledged data at the receiver, 'n' SHOULD be 2. If there is no unacknowledged data at the receiver, 'n' SHOULD be 3 and MUST be no less than 3. In either case, 'n' MUST be no greater than 7.
パケットの AccECN 受信者は、前の ACK 以降に 'n' 個の CE マークが到着した場合、ACK を送信しなければなりません (MUST)。受信側に未確認のデータがある場合、「n」は 2 である必要があります。受信側に未確認のデータがない場合、「n」は 3 である必要があり、3 以上でなければなりません。いずれの場合も、「n」は 7 以下でなければなりません。
The above rules for when to send an ACK are designed to be complemented by those in Section 3.2.3.3, which concern whether an AccECN TCP Option ought to be included on ACKs.
ACK をいつ送信するかに関する上記のルールは、AccECN TCP オプションを ACK に含めるべきかどうかに関するセクション 3.2.3.3 のルールによって補完されるように設計されています。
If the arrivals of a number of data packets are all processed as one event, e.g., using large receive offload (LRO) or generic receive offload (GRO), both the above rules SHOULD be interpreted as requiring multiple ACKs to be emitted back to back (for each transition and for each sequence of 'n' CE marks). If this is problematic for high performance, either rule can be interpreted as requiring just a single ACK at the end of the whole receive event.
たとえば、大規模受信オフロード (LRO) または汎用受信オフロード (GRO) を使用して、多数のデータ パケットの到着がすべて 1 つのイベントとして処理される場合、上記の両方のルールは、(各遷移および「n」個の CE マークの各シーケンスに対して) 複数の ACK を連続して発行することを要求すると解釈すべきです(SHOULD)。これが高パフォーマンスにとって問題となる場合は、どちらのルールも、受信イベント全体の最後に 1 つの ACK だけを必要とするものとして解釈できます。
Even if a number of data packets do not arrive as one event, the 'Change-Triggered ACKs' rule could sometimes cause the ACK rate to be problematic for high performance (although high performance protocols such as DCTCP already successfully use change-triggered ACKs). The rationale for change-triggered ACKs is so that the Data Sender can rely on them to detect queue growth as soon as possible, particularly at the start of a flow. The approach can lead to some additional ACKs but it feeds back the timing and the order in which ECN marks are received with minimal additional complexity. If CE marks are infrequent, as is the case for most Active Queue Management (AQM) algorithms at the time of writing, or there are multiple marks in a row, the additional load will be low. However, marking patterns with numerous non-contiguous CE marks could increase the load significantly. One possible compromise would be for the receiver to heuristically detect whether the sender is in slow-start, then to implement change-triggered ACKs while the sender is in slow-start, and offload otherwise.
多数のデータ パケットが 1 つのイベントとして到着しない場合でも、「変更トリガー ACK」ルールにより、高性能の ACK レートに問題が生じる場合があります (ただし、DCTCP などの高性能プロトコルはすでに変更トリガー ACK を正常に使用しています)。変更トリガー ACK の理論的根拠は、データ送信側がこれを利用して、特にフローの開始時にキューの増大をできるだけ早く検出できるようにするためです。このアプローチでは、追加の ACK が発生する可能性がありますが、追加の複雑さは最小限に抑えて、ECN マークが受信されるタイミングと順序をフィードバックします。執筆時点でのほとんどのアクティブ キュー管理 (AQM) アルゴリズムの場合のように、CE マークが頻繁に発生しない場合、または連続して複数のマークがある場合、追加の負荷は低くなります。ただし、多数の不連続な CE マークを含むマーキング パターンでは、負荷が大幅に増加する可能性があります。考えられる妥協案の 1 つは、受信側が送信側がスロースタート状態にあるかどうかをヒューリスティックに検出し、送信側がスロースタート状態にある間は変更トリガーの ACK を実装し、それ以外の場合はオフロードするというものです。
In a scenario where both endpoints support AccECN, if host B has chosen to use ECN-capable pure ACKs (as allowed in [RFC8311] experiments) and enough of these ACKs become CE marked, then the 'Increment-Triggered ACKs' rule ensures that its peer (host A) gives B sufficient feedback about this congestion on the ACKs from B to A. Normally, for instance in a unidirectional data scenario from host A to B, the Data Sender (A) can piggyback that feedback on its data. But if A stops sending data, the second part of the 'Increment-Triggered ACKs' rule requires A to emit a pure ACK for at least every third CE-marked incoming ACK over the subsequent round trip.
両方のエンドポイントが AccECN をサポートするシナリオで、ホスト B が ECN 対応の純粋な ACK ([RFC8311] 実験で許可されている) を使用することを選択し、これらの ACK の十分な数が CE マークになった場合、「増分トリガー ACK」ルールにより、ピア (ホスト A) が B から A への ACK の輻輳について十分なフィードバックを B に与えることが保証されます。 通常、たとえばホスト A から B への単方向データ シナリオでは、データ送信者 (A) は、そのデータにそのフィードバックを便乗させることができます。しかし、A がデータの送信を停止した場合、「増分トリガー ACK」ルールの 2 番目の部分では、A はその後の往復で少なくとも 3 回の CE マーク付き受信 ACK に対して純粋な ACK を送信する必要があります。
Although TCP normally only ACKs data segments, in this case the increment-triggered ACK rule makes it mandatory for A to emit ACKs of ACKs. This is justifiable because the ACKs in this case are ECN-capable and so, even though the ACKs of these ACKs do not acknowledge new data, they feed back new congestion state (useful in case B starts sending). The minimum of 3 for 'n' in this case ensures that, even if A also uses ECN-capable pure ACKs, and even if there is pathological congestion in both directions, any resulting ping-pong of ACKs will be rapidly damped.
通常、TCP はデータ セグメントに対して ACK のみを送信しますが、この場合、インクリメント トリガーの ACK ルールにより、A は ACK の ACK を送信することが必須になります。この場合の ACK は ECN 対応であり、これらの ACK の ACK が新しいデータを確認応答しない場合でも、新しい輻輳状態をフィードバックするため、これは正当です (B が送信を開始する場合に役立ちます)。この場合の「n」の最小値が 3 であるため、A が ECN 対応の純粋な ACK も使用している場合でも、両方向に異常な輻輳がある場合でも、結果として生じる ACK のピンポンは急速に減衰されます。
In the above bidirectional scenario, incoming ACKs of ACKs could be mistaken for duplicate ACKs. But ACKs of ACKs can be distinguished from duplicate ACKs because they do not contain any SACK blocks even when SACK has been negotiated. It is outside the scope of this AccECN specification to normatively specify this additional test for DupACKs, because ACKs of ACKs can only arise if the original ACKs are ECN-capable. Instead, any specification that allows ECN-capable pure ACKs MUST make sending ACKs of ACKs conditional on measures to distinguish ACKs of ACKs from DupACKs (see for example [ECN++]). All that is necessary here is to require that these ACKs of ACKs MUST NOT contain any SACK blocks (which would normally not happen anyway).
上記の双方向シナリオでは、ACK の受信 ACK が重複した ACK と誤認される可能性があります。ただし、ACK の ACK は、SACK がネゴシエートされている場合でも SACK ブロックを含まないため、重複 ACK と区別できます。ACK の ACK は元の ACK が ECN 対応である場合にのみ発生する可能性があるため、DupACK に対するこの追加テストを規範的に指定することは、この AccECN 仕様の範囲外です。その代わりに、ECN 対応の純粋な ACK を許可する仕様では、ACK の ACK を DupACK から区別するための措置を条件として、ACK の ACK の送信を行わなければなりません (たとえば、[ECN++] を参照)。ここで必要なことは、これらの ACK の ACK に SACK ブロックが含まれてはいけない (通常はいずれにせよ発生しない) ことを要求することだけです。
If the Data Sender has not received AccECN TCP Options to give it more dependable information, and it detects that the ACE field could have cycled, it SHOULD deem whether it cycled by taking the safest likely case under the prevailing conditions. It can detect if the counter could have cycled by using the jump in the acknowledgement number since the last ACK to calculate or estimate how many segments could have been acknowledged. An example algorithm to implement this policy is given in Appendix A.2. An implementation MAY use an alternative algorithm as long as it satisfies the requirements in this subsection.
データ送信者が、より信頼性の高い情報を提供するための AccECN TCP オプションを受信しておらず、ACE フィールドが循環した可能性があることを検出した場合、データ送信者は、一般的な条件下で最も安全である可能性が高いケースを採用して、循環したかどうかを判断する必要があります(SHOULD)。最後の ACK 以降の確認応答番号のジャンプを使用して、確認応答されたセグメントの数を計算または推定することで、カウンターが循環したかどうかを検出できます。このポリシーを実装するアルゴリズムの例を付録 A.2 に示します。実装は、このサブセクションの要件を満たす限り、代替アルゴリズムを使用してもよい(MAY)。
If missing acknowledgement numbers arrive later (reordering) and prove that the counter did not cycle, the Data Sender MAY attempt to neutralize the effect of any action it took based on a conservative assumption that it later found to be incorrect.
欠落している確認応答番号が後から到着し (並べ替え)、カウンタが循環していなかったことが証明された場合、データ送信者は、後に誤りであることが判明したという保守的な仮定に基づいて、自身が行ったアクションの影響を無効化しようとしてもよい(MAY)。
The Data Sender can estimate how many packets (of any marking) an ACK acknowledges. If the ACE counter on an ACK seems to imply that the minimum number of newly CE-marked packets is greater than the number of newly acknowledged packets, the Data Sender SHOULD consider the ACE counter to be correct (and its count of control packets to be incomplete), unless it can be sure that it is counting all control packets correctly.
データ送信者は、ACK が確認応答する (任意のマーキングの) パケット数を推定できます。ACK の ACE カウンタが、新たに CE マークが付けられたパケットの最小数が新たに確認応答されたパケットの数よりも大きいことを示唆しているように見える場合、データ送信者は、すべての制御パケットを正しくカウントしていることが確認できない限り、ACE カウンタが正しい (そしてその制御パケットのカウントが不完全である) と見なすべきです(SHOULD)。
Two alternative AccECN Options are defined as shown in Figure 4. The initial 'E' of each field name stands for 'Echo'.
図 4 に示すように、2 つの代替 AccECN オプションが定義されています。各フィールド名の最初の「E」は「Echo」を表します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind = 172 | Length = 11 | EE0B field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EE0B (cont'd) | ECEB field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EE1B field | Order 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind = 174 | Length = 11 | EE1B field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EE1B (cont'd) | ECEB field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EE0B field | Order 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Two Alternative AccECN TCP Options
図 4: 2 つの代替 AccECN TCP オプション
Figure 4 shows two option field orders; order 0 and order 1. They both consist of three 24-bit fields. Order 0 provides the 24 least significant bits of the r.e0b, r.ceb, and r.e1b counters, respectively. Order 1 provides the same fields, but in the opposite order. On each packet, the Data Receiver can use whichever order is more efficient. In either case, the bytes within the fields are in network byte order (big-endian).
図 4 は、2 つのオプション フィールドの順序を示しています。order 0 と order 1。どちらも 3 つの 24 ビット フィールドで構成されます。次数 0 は、それぞれ r.e0b、r.ceb、および r.e1b カウンターの最下位 24 ビットを提供します。順序 1 では、同じフィールドが逆の順序で提供されます。各パケットにおいて、データ受信者はより効率的な順序を使用できます。どちらの場合も、フィールド内のバイトはネットワーク バイト オーダー (ビッグ エンディアン) になります。
The choice to use three bytes (24 bits) fields in the options was made to strike a balance between TCP Option space usage, and the required fidelity of the counters to accommodate typical scenarios such as hardware TCP Segmentation Offloading (TSO), and periods during which no option may be transmitted (e.g., SACK loss recovery). Providing only 2 bytes (16 bits) for these counters could easily roll over within a single TSO transmission or large/generic receive offload (LRO/GRO) event. Having two distinct orderings further allows the transmission of the most pertinent changes in an abbreviated option (see below).
オプションで 3 バイト (24 ビット) フィールドを使用するという選択は、TCP オプション スペースの使用量と、ハードウェア TCP セグメンテーション オフロード (TSO) やオプションが送信されない期間 (SACK 損失回復など) などの一般的なシナリオに対応するために必要なカウンタの忠実度の間のバランスをとるために行われました。これらのカウンターに 2 バイト (16 ビット) だけを提供すると、単一の TSO 送信または大規模/汎用受信オフロード (LRO/GRO) イベント内で簡単にロールオーバーする可能性があります。2 つの異なる順序を持つことにより、省略されたオプションで最も適切な変更を送信できるようになります (以下を参照)。
When a Data Receiver sends an AccECN Option, it MUST set the Kind field to 172 if using Order 0, or to 174 if using Order 1. These two new TCP Option Kinds are registered in Section 7 and are called AccECN0 and AccECN1, respectively.
データ受信者が AccECN オプションを送信するとき、オーダー 0 を使用する場合は Kind フィールドを 172 に、オーダー 1 を使用する場合は 174 に設定しなければなりません。これら 2 つの新しい TCP オプションの種類はセクション 7 に登録されており、それぞれ AccECN0 および AccECN1 と呼ばれます。
Note that there is no field to feed back Not-ECT bytes. Nonetheless, an algorithm for the Data Sender to calculate the number of payload bytes received as Not-ECT is given in Appendix A.4.
Not-ECT バイトをフィードバックするフィールドがないことに注意してください。それにもかかわらず、データ送信者が Not-ECT として受信したペイロード バイト数を計算するためのアルゴリズムは、付録 A.4 に記載されています。
Whenever a Data Receiver sends an AccECN Option, the rules in Section 3.2.3.3 allow it to omit unchanged fields from the tail of the option, to help cope with option space limitations, as long as it preserves the order of the remaining fields and includes any field that has changed. The length field MUST indicate which fields are present as follows:
データ受信者が AccECN オプションを送信するときは常に、セクション 3.2.3.3 のルールにより、残りのフィールドの順序が保持され、変更されたフィールドが含まれている限り、オプションのスペース制限に対処するために、オプションの末尾から変更されていないフィールドを省略することができます。長さフィールドは、次のようにどのフィールドが存在するかを示さなければなりません。
+========+==================+==================+
| Length | Order 0 | Order 1 |
+========+==================+==================+
| 11 | EE0B, ECEB, EE1B | EE1B, ECEB, EE0B |
+--------+------------------+------------------+
| 8 | EE0B, ECEB | EE1B, ECEB |
+--------+------------------+------------------+
| 5 | EE0B | EE1B |
+--------+------------------+------------------+
| 2 | (empty) | (empty) |
+--------+------------------+------------------+
Table 5: Fields included in AccECN TCP Options of each length and order
表 5: 各長さと順序の AccECN TCP オプションに含まれるフィールド
The empty option of Length=2 is provided to allow for a case where an AccECN Option has to be sent (e.g., on the SYN/ACK to test the path), but there is very limited space for the option.
Length=2 の空のオプションは、AccECN オプションを送信する必要がある場合 (たとえば、パスをテストするための SYN/ACK 上) を考慮して提供されていますが、オプション用のスペースは非常に限られています。
All implementations of a Data Sender that read any AccECN Option MUST be able to read AccECN Options of any of the above lengths. For forward compatibility, if the AccECN Option is of any other length, implementations MUST use those whole 3-octet fields that fit within the length and ignore the remainder of the option, treating it as padding.
AccECN オプションを読み取るデータ送信者のすべての実装は、上記の長さのいずれかの AccECN オプションを読み取ることができなければなりません (MUST)。上位互換性のために、AccECN オプションが他の長さの場合、実装は長さ内に収まる 3 オクテットのフィールド全体を使用し、オプションの残りの部分を無視してパディングとして処理しなければなりません (MUST)。
AccECN Options have to be optional to implement, because both sender and receiver have to be able to cope without options anyway -- in cases where they do not traverse a network path. It is RECOMMENDED to implement both sending and receiving of AccECN Options. Support for AccECN Options is particularly valuable over paths that introduce a high degree of ACK filtering, where the 3-bit ACE counter alone might sometimes be insufficient, when it is ambiguous whether it has wrapped. If sending of AccECN Options is implemented, the fall-backs described in this document will need to be implemented as well (unless solely for a controlled environment where path traversal is not considered a problem). Even if a developer does not implement logic to understand received AccECN Options, it is RECOMMENDED that they implement logic to send AccECN Options. Otherwise, those remote peers that implement the receiving logic will still be excluded from congestion feedback that is robust against the increasingly aggressive ACK filtering in the Internet. The logic to send AccECN Options is the simpler to implement of the two sides.
AccECN オプションの実装はオプションである必要があります。これは、送信者と受信者の両方が、ネットワーク パスを通過しない場合に、いずれにしてもオプションなしで対処できなければならないためです。AccECN オプションの送信と受信の両方を実装することが推奨されます。AccECN オプションのサポートは、高度な ACK フィルタリングを導入するパスで特に役立ちます。ラップされているかどうかが曖昧な場合、3 ビット ACE カウンタだけでは不十分な場合があります。AccECN オプションの送信が実装されている場合は、このドキュメントで説明されているフォールバックも実装する必要があります (パス トラバーサルが問題とみなされない制御された環境のみの場合を除く)。開発者が、受信した AccECN オプションを理解するロジックを実装していない場合でも、AccECN オプションを送信するロジックを実装することが推奨されます。そうしないと、受信ロジックを実装するリモート ピアは、インターネットでのますます積極的な ACK フィルタリングに対して堅牢な輻輳フィードバックから引き続き除外されます。AccECN オプションを送信するロジックは、両方の側の実装がより簡単です。
If a Data Receiver intends to send an AccECN Option at any time during the rest of the connection, it is RECOMMENDED to also test path traversal of the AccECN Option as specified in Section 3.2.3.2.
データ受信者が残りの接続中にいつでも AccECN オプションを送信しようとする場合、セクション 3.2.3.2 で指定されているように、AccECN オプションのパス トラバーサルもテストすることが推奨されます。
Whenever the Data Receiver includes any of the counter fields (ECEB, EE0B, EE1B) in an AccECN Option, it MUST encode the 24 least significant bits of the current value of the associated counter into the field (respectively r.ceb, r.e0b, r.e1b).
データ受信者が AccECN オプションにカウンタ フィールド (ECEB、EE0B、EE1B) のいずれかを含める場合は常に、関連するカウンタの現在値の最下位 24 ビットをフィールド (それぞれ r.ceb、r.e0b、r.e1b) にエンコードしなければなりません (MUST)。
Whenever the Data Sender receives an ACK carrying an AccECN Option, it first checks whether the ACK has already been superseded by another ACK in which case it ignores the ECN feedback. If the ACK has not been superseded, the Data Sender normally decodes the fields in the AccECN Option as follows. For each field, it takes the least significant 24 bits of its associated local counter (s.ceb, s.e0b, or s.e1b) and subtracts them from the counter in the associated field of the incoming AccECN Option (respectively ECEB, EE0B, EE1B), to work out the minimum positive increment it could apply to s.ceb, s.e0b, or s.e1b (assuming the field in the option only wrapped once at most).
データ送信者は、AccECN オプションを含む ACK を受信するたびに、その ACK がすでに別の ACK に置き換えられているかどうかを最初にチェックします。その場合、ECN フィードバックは無視されます。ACK が置き換えられていない場合、データ送信者は通常、次のように AccECN オプションのフィールドをデコードします。各フィールドについて、関連するローカル カウンタ (s.ceb、s.e0b、または s.e1b) の最下位 24 ビットを受信 AccECN オプション (それぞれ ECEB、EE0B、EE1B) の関連フィールドのカウンタから減算して、s.ceb、s.e0b、または s.e1b (フィールドがオプションは最大でも 1 回のみラップされます)。
Appendix A.1 gives an example algorithm for the Data Receiver to encode its byte counters into an AccECN Option, and for the Data Sender to decode the AccECN Option fields into its byte counters.
付録 A.1 では、データ受信者がバイト カウンタを AccECN オプションにエンコードし、データ送信者が AccECN オプション フィールドをバイト カウンタにデコードするアルゴリズムの例を示します。
Note that, as specified in Section 3.2, any data on the SYN (SYN=1, ACK=0) is not included in any of the byte counters held locally for each ECN marking nor in an AccECN Option on the wire.
セクション 3.2 で指定されているように、SYN 上のデータ (SYN=1、ACK=0) は、各 ECN マーキングに対してローカルに保持されるバイト カウンタにも、回線上の AccECN オプションにも含まれないことに注意してください。
The TCP Client MUST NOT include an AccECN TCP Option on the SYN. If there is somehow an AccECN Option on a SYN, it MUST be ignored when forwarded or received.
TCP クライアントは、SYN に AccECN TCP オプションを含めてはなりません (MUST NOT)。SYN に何らかの形で AccECN オプションがある場合、転送または受信時にそれを無視しなければなりません (MUST)。
A TCP Server that confirms its support for AccECN (in response to an AccECN SYN from the Client as described in Section 3.1) SHOULD include an AccECN TCP Option on the SYN/ACK.
(セクション3.1で説明されているように、クライアントからのAccECN SYNに応答して)AccECNのサポートを確認するTCPサーバーは、SYN/ACKにAccECN TCPオプションを含めるべきです(SHOULD)。
A TCP Client that has successfully negotiated AccECN SHOULD include an AccECN Option in the first ACK at the end of the three-way handshake. However, this first ACK is not delivered reliably, so the TCP Client SHOULD also include an AccECN Option on the first data segment it sends (if it ever sends one).
AccECN のネゴシエーションに成功した TCP クライアントは、3 ウェイ ハンドシェイクの最後の最初の ACK に AccECN オプションを含めるべきです (SHOULD)。ただし、この最初の ACK は確実に配信されないため、TCP クライアントは、送信する最初のデータ セグメント (送信する場合) にも AccECN オプションを含めるべきです (SHOULD)。
A host MAY omit an AccECN Option in any of the above three cases because of insufficient option space or because it has cached knowledge that the packet would be likely to be blocked on the path to the other host if it included an AccECN Option.
ホストは、オプションスペースが不十分なため、またはパケットに AccECN オプションが含まれている場合、他のホストへのパスでブロックされる可能性が高いという情報をキャッシュしているため、上記の 3 つのケースのいずれかで AccECN オプションを省略してもよい(MAY)。
If the TCP Server has not received an ACK to acknowledge its SYN/ACK after the normal TCP timeout or if it receives a second SYN with a request for AccECN support, then either the SYN/ACK might just have been lost, e.g., due to congestion, or a middlebox might be blocking AccECN Options. To expedite connection setup in deployment scenarios where AccECN path traversal might be problematic, the TCP Server SHOULD retransmit the SYN/ACK, but with no AccECN Option. If this retransmission times out, to expedite connection setup, the TCP Server SHOULD retransmit the SYN/ACK with (AE,CWR,ECE) = (0,0,0) and no AccECN Option, but it remains in AccECN feedback mode (per Section 3.1.5).
TCP サーバーが通常の TCP タイムアウト後に SYN/ACK を確認するための ACK を受信しなかった場合、または AccECN サポートの要求を含む 2 番目の SYN を受信した場合は、SYN/ACK が輻輳などにより単に失われたか、ミドルボックスが AccECN オプションをブロックしている可能性があります。AccECN パスのトラバーサルに問題がある可能性がある展開シナリオでの接続セットアップを迅速化するために、TCP サーバーは AccECN オプションを使用せずに SYN/ACK を再送信する必要があります (SHOULD)。この再送信がタイムアウトした場合、接続セットアップを促進するために、TCP サーバーは (AE,CWR,ECE) = (0,0,0) で AccECN オプションなしで SYN/ACK を再送信すべきです (SHOULD)。 ただし、AccECN フィードバック モードのままです (セクション 3.1.5 に従って)。
Note that a retransmitted AccECN SYN/ACK will not necessarily have the same TCP-ECN flags as the original SYN/ACK, because it feeds back the IP-ECN field of the latest SYN to have arrived (by the rule in Section 3.1.5).
再送信された AccECN SYN/ACK は、(セクション 3.1.5 の規則により) 到着した最新の SYN の IP-ECN フィールドをフィードバックするため、必ずしも元の SYN/ACK と同じ TCP-ECN フラグを持つわけではないことに注意してください。
The above fall-back approach limits any interference by middleboxes that might drop packets with unknown options, even though it is more likely that SYN/ACK loss is due to congestion. The TCP Server MAY try to send another packet with an AccECN Option at a later point during the connection but it ought to monitor if that packet got lost as well, in which case it SHOULD disable the sending of AccECN Options for this half-connection.
上記のフォールバック アプローチは、SYN/ACK 損失が輻輳による可能性が高い場合でも、未知のオプションを持つパケットをドロップする可能性のあるミドルボックスによる干渉を制限します。TCP サーバーは、接続中の後の時点で、AccECN オプションを持つ別のパケットの送信を試みてもよい (MAY) が、そのパケットが失われたかどうかも監視する必要があり、その場合、この半分の接続に対する AccECN オプションの送信を無効にする必要がある (SHOULD)。
Implementers MAY use other fall-back strategies if they are found to be more effective (e.g., retrying an AccECN Option for a second time before fall-back -- most appropriate during high levels of congestion). However, other fall-back strategies will need to follow all the rules in Section 3.1.5, which concern behaviour when SYNs or SYN/ACKs negotiating different types of feedback have been sent within the same connection.
実装者は、他のフォールバック戦略の方が効果的であると判明した場合、他のフォールバック戦略を使用してもよい(MAY) (例: フォールバックの前に AccECN オプションを 2 回再試行する -- 高レベルの輻輳時に最も適切)。ただし、他のフォールバック戦略は、異なるタイプのフィードバックをネゴシエートする SYN または SYN/ACK が同じ接続内で送信されたときの動作に関するセクション 3.1.5 のすべてのルールに従う必要があります。
Further it might make sense to also remove any other new or experimental fields or options on the SYN/ACK, although the required behaviour will depend on the specification of the other option(s) and on any attempt to coordinate fall-back between different modules of the stack.
さらに、SYN/ACK のその他の新しいまたは実験的なフィールドやオプションも削除することが合理的である可能性がありますが、必要な動作は、他のオプションの仕様と、スタックの異なるモジュール間のフォールバックを調整する試みによって異なります。
If the TCP Client detects that the first data segment it sent with an AccECN Option was lost, in deployment scenarios where AccECN path traversal might be problematic, it SHOULD fall back to no AccECN Option on the retransmission. Again, implementers MAY use other fall-back strategies such as attempting to retransmit a second segment with an AccECN Option before fall-back, and/or caching whether AccECN Options are blocked for subsequent connections. [RFC9040] further discusses caching of TCP parameters and status information.
TCP クライアントが、AccECN パス トラバーサルに問題がある可能性がある展開シナリオで、AccECN オプションを使用して送信した最初のデータ セグメントが失われたことを検出した場合、再送信時に AccECN オプションなしにフォールバックする必要があります (SHOULD)。繰り返しになりますが、実装者は、フォールバックの前に AccECN オプションを使用して 2 番目のセグメントの再送信を試みたり、AccECN オプションが後続の接続でブロックされるかどうかをキャッシュしたりするなど、他のフォールバック戦略を使用してもよい(MAY)。[RFC9040] では、TCP パラメータとステータス情報のキャッシュについてさらに議論しています。
If a middlebox is dropping packets with options it does not recognize, a host that is sending little or no data but mostly pure ACKs will not inherently detect such losses. Such a host MAY detect loss of ACKs carrying the AccECN Option by detecting whether the acknowledged data always reappears as a retransmission. In such cases, the host SHOULD disable the sending of the AccECN Option for this half-connection.
ミドルボックスが認識できないオプションを持つパケットをドロップしている場合、データをほとんどまたはまったく送信せず、ほとんどが純粋な ACK を送信しているホストは、本質的にそのような損失を検出しません。このようなホストは、確認応答されたデータが再送信として常に再出現するかどうかを検出することによって、AccECN オプションを伝送する ACK の損失を検出してもよい(MAY)。このような場合、ホストは、この半接続に対する AccECN オプションの送信を無効にする必要があります (SHOULD)。
If a host falls back to not sending AccECN Options, it will continue to process any incoming AccECN Options as normal.
ホストが AccECN オプションを送信しないようにフォールバックした場合、ホストは受信した AccECN オプションを通常どおり処理し続けます。
Either host MAY include AccECN Options in one or more subsequent segments to retest whether AccECN Options can traverse the path.
いずれのホストも、AccECN オプションがパスを通過できるかどうかを再テストするために、1 つ以上の後続セグメントに AccECN オプションを含めてもよい(MAY)。
Similarly, an AccECN endpoint MAY separately memorize which data packets carried an AccECN Option and disable the sending of AccECN Options if the loss probability of those packets is significantly higher than that of all other data packets in the same connection.
同様に、AccECN エンドポイントは、どのデータ パケットが AccECN オプションを伝送したかを個別に記憶し、それらのパケットの損失確率が同じ接続内の他のすべてのデータ パケットの損失確率よりも大幅に高い場合には、AccECN オプションの送信を無効にしてもよい(MAY)。
If the TCP Client has successfully negotiated AccECN but does not receive an AccECN Option on the SYN/ACK (e.g., because is has been stripped by a middlebox or not sent by the Server), the Client switches into a mode that assumes that the AccECN Option is not available for this half-connection.
TCP クライアントが AccECN のネゴシエーションに成功したが、SYN/ACK で AccECN オプションを受信しない場合 (たとえば、ミドルボックスによって削除されているか、サーバーによって送信されていないため)、クライアントは、このハーフ接続では AccECN オプションが利用できないと想定するモードに切り替わります。
Similarly, if the TCP Server has successfully negotiated AccECN but does not receive an AccECN Option on the first segment that acknowledges sequence space at least covering the ISN, it switches into a mode that assumes that the AccECN Option is not available for this half-connection.
同様に、TCP サーバーが AccECN のネゴシエーションに成功したにもかかわらず、少なくとも ISN をカバーするシーケンス スペースを確認する最初のセグメントで AccECN オプションを受信しなかった場合、TCP サーバーは、この半接続では AccECN オプションが利用できないと想定するモードに切り替わります。
While a host is in this mode that assumes incoming AccECN Options are not available, it MUST adopt the conservative interpretation of the ACE field discussed in Section 3.2.2.5. However, it cannot make any assumption about support of outgoing AccECN Options on the other half-connection, so it SHOULD continue to send AccECN Options itself (unless it has established that sending AccECN Options is causing packets to be blocked as in Section 3.2.3.2.2).
ホストがこのモードにある間は、受信 AccECN オプションが利用できないと想定していますが、セクション 3.2.2.5 で説明した ACE フィールドの保守的な解釈を採用しなければなりません (MUST)。ただし、他の半分の接続での発信 AccECN オプションのサポートについてはいかなる仮定もできません。そのため、AccECN オプション自体を送信し続ける必要があります (セクション 3.2.3.2.2 のように、AccECN オプションの送信によってパケットがブロックされることが確立されていない限り)。
If a host is in the mode that assumes incoming AccECN Options are not available, but it receives an AccECN Option at any later point during the connection, this clearly indicates that AccECN Options are no longer blocked on the respective path, and the AccECN endpoint MAY switch out of the mode that assumes AccECN Options are not available for this half-connection.
ホストが、受信 AccECN オプションが利用できないと想定するモードにあるにもかかわらず、接続中の任意の時点で AccECN オプションを受信する場合、これは、AccECN オプションがそれぞれのパスでブロックされなくなったことを明確に示しており、AccECN エンドポイントは、この半接続では AccECN オプションが利用できないと想定するモードから切り替えてもよい(MAY)。
For the merits of a related test for invalid initialization of the ACE field, see Section 3.2.2.4.
ACE フィールドの無効な初期化に関する関連テストの利点については、セクション 3.2.2.4 を参照してください。
Section 3.2.1 required the Data Receiver to initialize the r.e0b and r.e1b counters to a non-zero value. Therefore, in either direction the initial value of the EE0B field or EE1B field in an AccECN Option (if one exists) ought to be non-zero. If AccECN has been negotiated:
セクション 3.2.1 では、データ レシーバーが r.e0b カウンターと r.e1b カウンターをゼロ以外の値に初期化する必要がありました。したがって、どちらの方向でも、AccECN オプション (存在する場合) の EE0B フィールドまたは EE1B フィールドの初期値はゼロ以外である必要があります。AccECN がネゴシエートされている場合:
* the TCP Server MAY check that the initial value of the EE0B field or the EE1B field is non-zero in the first segment that acknowledges sequence space that at least covers the ISN plus 1. If it runs a test and either initial value is zero, the Server will switch into a mode that ignores AccECN Options for this half-connection.
* TCP サーバーは、少なくとも ISN プラス 1 をカバーするシーケンス スペースを確認する最初のセグメントで、EE0B フィールドまたは EE1B フィールドの初期値がゼロ以外であることをチェックしてもよい(MAY)。テストを実行し、いずれかの初期値がゼロの場合、サーバーは、この半接続の AccECN オプションを無視するモードに切り替わる。
* the TCP Client MAY check that the initial value of the EE0B field or the EE1B field is non-zero on the SYN/ACK. If it runs a test and either initial value is zero, the Client will switch into a mode that ignores AccECN Options for this half-connection.
* TCP クライアントは、SYN/ACK 上の EE0B フィールドまたは EE1B フィールドの初期値がゼロ以外であることをチェックしてもよい(MAY)。テストを実行し、どちらかの初期値がゼロの場合、クライアントはこの半接続の AccECN オプションを無視するモードに切り替わります。
While a host is in the mode that ignores AccECN Options, it MUST adopt the conservative interpretation of the ACE field discussed in Section 3.2.2.5.
ホストが AccECN オプションを無視するモードにある間は、セクション 3.2.2.5 で説明した ACE フィールドの保守的な解釈を採用しなければなりません (MUST)。
Note that the Data Sender MUST NOT test whether the arriving byte counters in an initial AccECN Option have been initialized to specific valid values -- the above checks solely test whether these fields have been incorrectly zeroed. This allows hosts to use different initial values as an additional signalling channel in the future. Also note that the initial value of either field might be greater than its expected initial value, because the counters might already have been incremented. Nonetheless, the initial values of the counters have been chosen so that they cannot wrap to zero on these initial segments.
データ送信者は、初期 AccECN オプションの到着バイト カウンタが特定の有効な値に初期化されているかどうかをテストしてはいけないことに注意してください。上記のチェックは、これらのフィールドが誤ってゼロに設定されているかどうかのみをテストします。これにより、ホストは将来、追加のシグナリング チャネルとして異なる初期値を使用できるようになります。また、カウンタがすでにインクリメントされている可能性があるため、いずれかのフィールドの初期値が予想される初期値より大きくなる可能性があることにも注意してください。それにもかかわらず、カウンターの初期値は、これらの初期セグメントでゼロにラップできないように選択されています。
When AccECN Options are available, they ought to provide more unambiguous feedback. However, they supplement but do not replace the ACE field. An endpoint using AccECN feedback MUST always reconcile the information provided in the ACE field with that in any AccECN Option, so that the state of the ACE-related packet counter can be relied on if future feedback does not carry an AccECN Option.
AccECN オプションが利用可能な場合、より明確なフィードバックを提供する必要があります。ただし、これらは ACE フィールドを補足するものではありますが、置き換えるものではありません。AccECN フィードバックを使用するエンドポイントは、将来のフィードバックに AccECN オプションが含まれていない場合でも、ACE 関連のパケット カウンタの状態を信頼できるように、ACE フィールドで提供される情報と AccECN オプションの情報を常に調整しなければなりません (MUST)。
If an AccECN Option is present, the s.cep counter might increase more than expected from the increase of the s.ceb counter (e.g., due to a CE-marked control packet). The sender's response to such a situation is out of scope, and needs to be dealt with in a specification that uses ECN-capable control packets. Theoretically, this situation could also occur if a middlebox mangled an AccECN Option but not the ACE field. However, the Data Sender has to assume that the integrity of AccECN Options is sound, based on the above test of the well-known initial values and optionally other integrity tests (Section 5.3).
AccECN オプションが存在する場合、s.cep カウンタは、s.ceb カウンタの増加により予想以上に増加する可能性があります (たとえば、CE マークが付けられた制御パケットが原因)。このような状況に対する送信者の応答は範囲外であり、ECN 対応の制御パケットを使用する仕様で処理する必要があります。理論的には、ミドルボックスが ACE フィールドではなく AccECN オプションを破壊した場合にも、この状況が発生する可能性があります。ただし、データ送信者は、既知の初期値の上記のテストと、オプションで他の整合性テスト (セクション 5.3) に基づいて、AccECN オプションの整合性が健全であると想定する必要があります。
If either endpoint detects that the s.ceb counter has increased but the s.cep has not (and by testing ACK coverage it is certain how much the ACE field has wrapped), and if there is no explanation other than an invalid protocol transition due to some form of feedback mangling, the Data Sender MUST disable sending ECN-capable packets for the remainder of the half-connection by setting the IP-ECN field in all subsequent packets to Not-ECT.
いずれかのエンドポイントが s.ceb カウンタが増加したが s.cep が増加していないことを検出した場合 (そして、ACK カバレッジをテストすることで、ACE フィールドがどの程度ラップしたかが確実である)、および何らかの形式のフィードバックマングリングによる無効なプロトコル遷移以外の説明がない場合、データ送信者は、後続のすべてのパケットの IP-ECN フィールドを Not-ECT に設定することにより、半接続の残りの部分で ECN 対応パケットの送信を無効にしなければなりません (MUST)。
If a Data Receiver in AccECN mode intends to use AccECN TCP Options to provide feedback, the rules below determine when to include an AccECN TCP Option, and which fields to include, given other options might be competing for limited option space:
AccECN モードのデータ受信者が AccECN TCP オプションを使用してフィードバックを提供する場合、他のオプションが限られたオプション スペースをめぐって競合する可能性があることを考慮して、以下のルールによって AccECN TCP オプションを含めるタイミングと含めるフィールドが決定されます。
Importance of Congestion Control:
輻輳制御の重要性:
AccECN is for congestion control, which implementations SHOULD generally prioritize over other TCP Options when there is insufficient space for all the options in use.
AccECN は輻輳制御用であり、使用中のすべてのオプションに十分なスペースがない場合、実装は通常、他の TCP オプションよりも優先する必要があります。
If SACK has been negotiated [RFC2018], and the smallest recommended AccECN Option would leave insufficient space for two SACK blocks on a particular ACK, the Data Receiver MUST give precedence to the SACK option (total 18 octets), because loss feedback is more critical.
SACK がネゴシエートされており [RFC2018]、推奨される最小の AccECN オプションでは特定の ACK 上の 2 つの SACK ブロックに十分なスペースが残らない場合、損失フィードバックの方がより重要であるため、データ受信者は SACK オプション (合計 18 オクテット) を優先しなければなりません (MUST)。
Recommended Simple Scheme:
推奨される簡単なスキーム:
The Data Receiver SHOULD include an AccECN TCP Option on every scheduled ACK if any byte counter has incremented since the last ACK. Whenever possible, it SHOULD include a field for every byte counter that has changed at some time during the connection (see examples later).
データ受信者は、最後の ACK 以降にバイト カウンタが増加した場合、すべてのスケジュールされた ACK に AccECN TCP オプションを含めるべきです (SHOULD)。可能な限り、接続中に変更されたすべてのバイト カウンターのフィールドを含める必要があります (後述の例を参照)。
A scheduled ACK means an ACK that the Data Receiver would send by its regular delayed ACK rules. Recall that Section 1.3 defines an 'ACK' as either with data payload or without. But the above rule is worded so that, in the common case when most of the data is from a Server to a Client, the Server only includes an AccECN TCP Option while it is acknowledging data from the Client.
スケジュールされた ACK とは、データ受信側が通常の遅延 ACK ルールに従って送信する ACK を意味します。セクション 1.3 では、「ACK」をデータ ペイロードありまたはデータ ペイロードなしとして定義していることを思い出してください。ただし、上記のルールは、データの大部分がサーバーからクライアントに送られる一般的なケースでは、サーバーはクライアントからのデータを確認している間、AccECN TCP オプションのみを含めるように記述されています。
When available TCP Option space is limited on particular packets, the recommended scheme will need to include compromises. To guide the implementer, the rules below are ranked in order of importance, but the final decision has to be implementation-dependent, because tradeoffs will alter as new TCP Options are defined and new use-cases arise.
利用可能な TCP オプション スペースが特定のパケットに制限されている場合、推奨されるスキームには妥協を含める必要があります。実装者をガイドするために、以下のルールは重要性の順にランク付けされていますが、新しい TCP オプションが定義され、新しいユースケースが発生するとトレードオフが変化するため、最終的な決定は実装に依存する必要があります。
Necessary Option Length:
必要なオプションの長さ:
When TCP Option space is limited, an AccECN TCP Option MAY be truncated to omit one or two fields from the end of the option, as indicated by the permitted variants listed in Table 5, provided that the counter(s) that have changed since the previous AccECN TCP Option are not omitted.
TCP オプションのスペースが限られている場合、AccECN TCP オプションは、前の AccECN TCP オプション以降に変更されたカウンタが省略されない限り、表 5 にリストされている許可されたバリアントで示されているように、オプションの末尾から 1 つまたは 2 つのフィールドを省略するために切り詰められてもよい(MAY)。
If there is insufficient space to include an AccECN TCP Option containing the counter(s) that have changed since the previous AccECN TCP Option, then the entire AccECN TCP Option MUST be omitted. (see Section 3.2.3);
以前の AccECN TCP オプション以降に変更されたカウンタを含む AccECN TCP オプションを含める十分なスペースがない場合は、AccECN TCP オプション全体を省略しなければなりません (MUST)。(セクション 3.2.3 を参照);
Change-Triggered AccECN TCP Options:
変更によってトリガーされる AccECN TCP オプション:
If an arriving packet increments a different byte counter to that incremented by the previous packet, the Data Receiver SHOULD feed it back in an AccECN Option on the next scheduled ACK.
到着したパケットが、前のパケットによってインクリメントされたものとは異なるバイト カウンタをインクリメントした場合、データ受信者は、次にスケジュールされた ACK の AccECN オプションでそれをフィードバックする必要があります (SHOULD)。
For the avoidance of doubt, this rule does not concern the arrival of control packets with no payload, because they cannot alter any byte counters.
誤解を避けるため、このルールはペイロードのない制御パケットの到着には関係しません。これは、制御パケットはバイト カウンタを変更できないためです。
Continual Repetition:
継続的な繰り返し:
Otherwise, if arriving packets continue to increment the same byte counter:
それ以外の場合、到着パケットが同じバイト カウンターをインクリメントし続ける場合は、次のようになります。
* the Data Receiver SHOULD include a counter that has continued to increment on the next scheduled ACK following a change-triggered AccECN TCP Option;
* データ受信者は、変更によってトリガーされた AccECN TCP オプションに続いて、次にスケジュールされた ACK でインクリメントし続けるカウンターを含めるべきです(SHOULD)。
* while the same counter continues to increment, it SHOULD include the counter every n ACKs as consistently as possible, where n can be chosen by the implementer;
* 同じカウンタがインクリメントし続ける間、可能な限り一貫して n 回の ACK ごとにカウンタを含めるべきです (SHOULD)。n は実装者が選択できます。
* it SHOULD always include an AccECN Option if the r.ceb counter is incrementing and it MAY include an AccECN Option if r.e0b or r.e1b is incrementing;
* r.ceb カウンタがインクリメントしている場合は、常に AccECN オプションを含める必要があります (SHOULD)。また、r.e0b または r.e1b がインクリメントしている場合は、AccECN オプションを含めてもよいです。
* it SHOULD include each counter at least once for every 2^22 bytes incremented to prevent overflow during continual repetition.
* 継続的な繰り返し中のオーバーフローを防ぐために、インクリメントされる 2^22 バイトごとに少なくとも 1 回、各カウンターを含めるべきです(SHOULD)。
The above rules complement those in Section 3.2.2.5, which determine when to generate an ACK irrespective of whether an AccECN TCP Option is to be included.
上記のルールは、AccECN TCP オプションが含まれるかどうかに関係なく、いつ ACK を生成するかを決定するセクション 3.2.2.5 のルールを補完します。
The recommended scheme is intended as a simple way to ensure that all the relevant byte counters will be carried on any ACK that reaches the Data Sender, no matter how many pure ACKs are filtered or coalesced along the network path, and without consuming the space available for payload data with counter field(s) that have never changed.
推奨されるスキームは、ネットワーク パスに沿ってフィルタリングまたは結合された純粋な ACK の数に関係なく、また、変更されていないカウンタ フィールドを持つペイロード データに利用可能なスペースを消費することなく、データ送信者に到達するすべての ACK で関連するすべてのバイト カウンタが確実に伝送されることを保証する簡単な方法を目的としています。
As an example of the recommended scheme, if ECT(0) is the only codepoint that has ever arrived in the IP-ECN field, the Data Receiver will feed back an AccECN0 TCP Option with only the EE0B field on every packet that acknowledges new data. However, as soon as even one CE-marked packet arrives, on every packet that acknowledges new data it will start to include an option with two fields, EE0B and ECEB. As a second example, if the first packet to arrive happens to be CE marked, the Data Receiver will have to arbitrarily choose whether to precede the ECEB field with an EE0B field or an EE1B field. If it chooses, say, EE0B but it turns out never to receive ECT(0), it can start sending EE1B and ECEB instead -- it does not have to include the EE0B field if the r.e0b counter never changed during the connection.
推奨されるスキームの例として、ECT(0) が IP-ECN フィールドに到着した唯一のコードポイントである場合、データ受信側は、新しいデータを確認するすべてのパケットで EE0B フィールドのみを含む AccECN0 TCP オプションをフィードバックします。ただし、CE マークの付いたパケットが 1 つでも到着すると、新しいデータを確認するすべてのパケットに、EE0B と ECEB の 2 つのフィールドを持つオプションが含まれ始めます。2 番目の例として、最初に到着したパケットに CE マークが付いている場合、データ受信側は ECEB フィールドの前に EE0B フィールドを置くか EE1B フィールドを置くかを任意に選択する必要があります。たとえば、EE0B を選択したが、ECT(0) を受信しないことが判明した場合は、代わりに EE1B と ECEB の送信を開始できます。接続中に r.e0b カウンタが変更されなかった場合、EE0B フィールドを含める必要はありません。
With the recommended scheme, if the data sending direction switches during a connection, there can be cases where the AccECN TCP Option that is meant to feed back the counter values at the end of a volley in one direction never reaches the other peer due to packet loss. ACE feedback ought to be sufficient to fill this gap, given accurate feedback becomes moot after data transmission has paused.
推奨されるスキームでは、接続中にデータ送信方向が切り替わった場合、一方向の一斉送信の終了時にカウンタ値をフィードバックすることを目的とした AccECN TCP オプションが、パケット損失によりもう一方のピアに到達しない場合があります。データ送信が一時停止した後は正確なフィードバックが意味をなさなくなるため、ACE フィードバックはこのギャップを埋めるのに十分であるはずです。
Appendix A.3 gives an example algorithm to estimate the number of marked bytes from the ACE field alone, if AccECN Options are not available.
付録 A.3 では、AccECN オプションが使用できない場合に、ACE フィールドのみからマークされたバイト数を推定するアルゴリズムの例を示します。
If a host has determined that segments with AccECN Options always seem to be discarded somewhere along the path, it is no longer obliged to follow any of the rules in this section.
AccECN オプションを持つセグメントが常にパス上のどこかで破棄されるように見えるとホストが判断した場合、このセクションのルールに従う義務はなくなります。
Given AccECN alters the TCP protocol on the wire, this section specifies new requirements on certain networking equipment that forwards TCP and inspects TCP header information.
AccECN が回線上の TCP プロトコルを変更することを前提として、このセクションでは、TCP を転送し、TCP ヘッダー情報を検査する特定のネットワーク機器に関する新しい要件を指定します。
A large class of middleboxes split TCP connections. Such a middlebox would be compliant with the AccECN protocol if the TCP implementation on each side complied with the present AccECN specification and each side negotiated AccECN independently of the other side.
大規模なクラスのミドルボックスは TCP 接続を分割します。このようなミドルボックスは、各側の TCP 実装が現在の AccECN 仕様に準拠し、各側がもう一方の側とは独立して AccECN をネゴシエートする場合、AccECN プロトコルに準拠します。
Another large class of middleboxes intervenes to some degree at the transport layer, but attempts to be transparent (invisible) to the end-to-end connection. A subset of this class of middleboxes attempts to 'normalize' the TCP wire protocol by checking that all values in header fields comply with a rather narrow interpretation of the TCP specifications that is also not always kept up to date.
別の大きなクラスのミドルボックスは、トランスポート層にある程度介入しますが、エンドツーエンド接続に対して透過的 (不可視) にしようとします。このクラスのミドルボックスのサブセットは、ヘッダー フィールドのすべての値が、常に最新に保たれているわけではない TCP 仕様のかなり狭い解釈に準拠していることを確認することによって、TCP ワイヤ プロトコルを「正規化」しようとします。
A middlebox that is not normalizing the TCP protocol and does not itself act as a back-to-back pair of TCP endpoints (i.e., a middlebox that intends to be transparent or invisible at the transport layer) ought to forward AccECN TCP Options unaltered, whether or not the length value matches one of those specified in Section 3.2.3, and whether or not the initial values of the byte-counter fields match those in Section 3.2.1. This is because blocking apparently invalid values prevents the standardized set of values from being extended in the future (such outdated normalizers would block updated hosts from using the extended AccECN standard).
TCP プロトコルを正規化しておらず、それ自体が TCP エンドポイントの連続ペアとして機能しないミドルボックス (つまり、トランスポート層で透過的または不可視であることを意図しているミドルボックス) は、長さの値がセクション 3.2.3 で指定されている値のいずれかに一致するかどうか、およびバイトカウンターフィールドの初期値がセクション 3.2.1 の初期値と一致するかどうかに関係なく、AccECN TCP オプションを変更せずに転送する必要があります。これは、明らかに無効な値をブロックすると、標準化された値のセットが将来拡張されなくなるためです (そのような古いノーマライザーは、更新されたホストが拡張された AccECN 標準を使用することをブロックします)。
A TCP normalizer is likely to block or alter an AccECN TCP Option if the length value or the initial values of its byte-counter fields do not match one of those specified in Sections 3.2.3 or 3.2.1. However, to comply with the present AccECN specification, a middlebox MUST NOT change the ACE field; or those fields of an AccECN Option that are currently specified in Section 3.2.3; or any AccECN field covered by integrity protection (e.g., [RFC5925]).
TCP ノーマライザーは、バイトカウンターフィールドの長さの値または初期値がセクション 3.2.3 または 3.2.1 で指定されている値のいずれかと一致しない場合、AccECN TCP オプションをブロックまたは変更する可能性があります。ただし、現在の AccECN 仕様に準拠するために、ミドルボックスは ACE フィールドを変更してはなりません (MUST NOT)。または現在セクション 3.2.3 で指定されている AccECN オプションのフィールド。または完全性保護の対象となる AccECN フィールド (例: [RFC5925])。
Section 5.2.1 of [RFC3449] gives best current practice on filtering (aka thinning or coalescing) of pure TCP ACKs. It advises that filtering ACKs carrying ECN feedback ought to preserve the correct operation of ECN feedback. As the present specification updates the operation of ECN feedback, this section discusses how an ACK filter might preserve correct operation of AccECN feedback as well.
[RFC3449] のセクション 5.2.1 は、純粋な TCP ACK のフィルタリング (間引きまたは結合とも呼ばれます) に関する現在のベスト プラクティスを示しています。これは、ECN フィードバックを運ぶ ACK をフィルタリングすることで、ECN フィードバックの正しい動作を維持する必要があるとアドバイスしています。本仕様では ECN フィードバックの動作が更新されるため、このセクションでは、ACK フィルタが AccECN フィードバックの正しい動作をどのように維持するかについて説明します。
The problem divides into two parts: determining if an ACK is part of a connection that is using AccECN and then preserving the correct operation of AccECN feedback:
この問題は 2 つの部分に分かれています。1 つは ACK が AccECN を使用する接続の一部であるかどうかを判断する部分、もう 1 つは AccECN フィードバックの正しい動作を維持する部分です。
* To determine whether a pure TCP ACK is part of an AccECN connection without resorting to connection tracking and per-flow state, a useful heuristic would be to check for a non-zero ECN field at the IP layer (because the ECN++ experiment only allows TCP pure ACKs to be ECN-capable if AccECN has been negotiated [ECN++]). This heuristic is simple and stateless. However, it might omit some AccECN ACKs because AccECN can be used without ECN++. Even if a sender uses ECN++, it does not necessarily have to mark pure ACKs as ECN-capable -- only deployment experience will tell. Also, TCP ACKs might be ECN-capable owing to some scheme other than AccECN, e.g., [RFC5690] or some future standards action. Again, only deployment experience will tell.
* 接続追跡やフローごとの状態に頼ることなく、純粋な TCP ACK が AccECN 接続の一部であるかどうかを判断するには、IP 層で非ゼロの ECN フィールドをチェックすることが有用なヒューリスティックです (ECN++ 実験では、AccECN がネゴシエートされている場合にのみ、TCP 純粋な ACK を ECN 対応にすることが許可されているためです [ECN++])。このヒューリスティックはシンプルでステートレスです。ただし、AccECN は ECN++ なしでも使用できるため、一部の AccECN ACK が省略される場合があります。送信者が ECN++ を使用する場合でも、純粋な ACK を ECN 対応としてマークする必要はありません。展開の経験だけがそれを示します。また、TCP ACK は、AccECN 以外のスキーム ([RFC5690] や将来の標準アクションなど) によって ECN 対応になる可能性があります。繰り返しますが、展開の経験だけがそれを伝えます。
* The main concern with preserving correct AccECN operation involves leaving enough ACKs for the Data Sender to work out whether the 3-bit ACE field has wrapped. In the worst case, in feedback about a run of received packets that were all ECN-marked, the ACE field will wrap every 8 acknowledged packets. ACE field wrap might be of less concern if packets also carry AccECN TCP Options. However, note that logic to read an AccECN TCP Option is optional to implement (albeit recommended -- see Section 3.2.3). So one end writing an AccECN TCP Option into a packet does not necessarily imply that the other end will read it.
* 正しい AccECN 動作を維持する際の主な懸念事項は、データ送信者が 3 ビット ACE フィールドがラップしたかどうかを判断するのに十分な ACK を残すことです。最悪の場合、すべて ECN マークが付けられた一連の受信パケットに関するフィードバックで、ACE フィールドは 8 つの確認応答パケットごとにラップされます。パケットが AccECN TCP オプションも伝送する場合、ACE フィールド ラップはあまり問題にならない可能性があります。ただし、AccECN TCP オプションを読み取るロジックの実装はオプションであることに注意してください (推奨されていますが、セクション 3.2.3 を参照)。したがって、一方の端が AccECN TCP オプションをパケットに書き込むことは、必ずしも他方の端がそれを読み取ることを意味するわけではありません。
Note that the present specification of AccECN in TCP does not presume to rely on any of the above ACK filtering behaviour in the network, because it has to be robust against pre-existing network nodes that do not distinguish AccECN ACKs, and robust against ACK loss during overload more generally.
TCP における AccECN の現在の仕様は、ネットワーク内の上記の ACK フィルタリング動作のいずれにも依存することを前提としていないことに注意してください。これは、AccECN ACK を区別しない既存のネットワーク ノードに対して堅牢でなければならず、より一般的には過負荷時の ACK 損失に対して堅牢である必要があるためです。
Hardware to offload certain TCP processing represents another large class of middleboxes (even though it is often a function of a host's network interface and rarely in its own 'box').
特定の TCP 処理をオフロードするハードウェアは、別の大きなクラスのミドルボックスを表します (ホストのネットワーク インターフェイスの機能であることが多く、独自の「ボックス」内にあることはほとんどありませんが)。
Offloading can happen in the transmit path, usually referred to as TCP Segmentation Offload (TSO), and the receive path where it is called Large Receive Offload (LRO).
オフロードは、通常 TCP セグメンテーション オフロード (TSO) と呼ばれる送信パスと、Large Receive Offload (LRO) と呼ばれる受信パスで発生する可能性があります。
In the transmit direction, with AccECN, all segments created from the same super-segment should retain the same ACE field, which should make TSO straightforward.
送信方向では、AccECN を使用すると、同じスーパーセグメントから作成されたすべてのセグメントが同じ ACE フィールドを保持する必要があり、これにより TSO が簡単になります。
However, with TSO hardware that supports [RFC3168], the CWR bit is usually masked out on the middle and last segments. If applied to an AccECN segment, this would change the ACE field, and would be interpreted as having received numerous CE marks in the receive direction. Therefore, currently available TSO hardware with [RFC3168] support may need some minor driver changes, to adjust the bitmask for the first, middle, and last segments processed with TSO.
ただし、[RFC3168] をサポートする TSO ハードウェアでは、通常、CWR ビットは中間セグメントと最後のセグメントでマスクされます。AccECN セグメントに適用すると、ACE フィールドが変更され、受信方向に多数の CE マークを受信したものとして解釈されます。したがって、[RFC3168] をサポートする現在利用可能な TSO ハードウェアでは、TSO で処理される最初、中間、および最後のセグメントのビットマスクを調整するために、ドライバーのマイナーな変更が必要になる可能性があります。
Initially, when Classic ECN [RFC3168] and Accurate ECN flows coexist on the same offloading engine, the host software may need to work around incompatibilities (e.g., when only global configurable TSO TCP Flag bitmasks are available), otherwise this would cause some issues.
最初は、Classic ECN [RFC3168] フローと Accurate ECN フローが同じオフロード エンジン上に共存する場合、ホスト ソフトウェアは非互換性を回避する必要がある場合があります (たとえば、グローバルに構成可能な TSO TCP フラグ ビットマスクのみが利用可能な場合)。そうしないと、いくつかの問題が発生します。
One way around this could be to only negotiate for Accurate ECN, but not offer a fall back to Classic ECN [RFC3168]. Another way could be to allow TSO only as long as the CWR flag in the TCP header is not set -- at the cost of more processing overhead while the ACE field has this bit set.
これを回避する 1 つの方法は、正確な ECN のみをネゴシエートし、クラシック ECN [RFC3168] へのフォールバックを提供しないことです。もう 1 つの方法は、TCP ヘッダーの CWR フラグが設定されていない限り TSO を許可することです。ただし、ACE フィールドにこのビットが設定されている間は、処理オーバーヘッドが増加します。
For LRO in the receive direction, a different issue may get exposed with hardware that supports Classic ECN [RFC3168].
受信方向の LRO の場合、クラシック ECN [RFC3168] をサポートするハードウェアでは別の問題が発生する可能性があります。
The ACE field changes with every received CE marking, so today's receive offloading could lead to many interrupts in high congestion situations. Although that would be useful (because congestion information is received sooner), it could also significantly increase processor load, particularly in scenarios such as DCTCP or L4S where the marking rate is generally higher.
ACE フィールドは CE マーキングを受信するたびに変化するため、今日の受信オフロードでは、輻輳が高い状況では多くの割り込みが発生する可能性があります。これは (輻輳情報がより早く受信されるため) 便利ですが、特にマーキング レートが一般に高い DCTCP や L4S などのシナリオでは、プロセッサの負荷が大幅に増加する可能性もあります。
Current offload hardware ejects a segment from the coalescing process whenever the TCP-ECN flags change. In data centres, it has been fortunate for this offload hardware that DCTCP-style feedback changes less often when there are long sequences of CE marks, which is more common with a step marking threshold (but less likely the more short flows are in the mix). The ACE counter approach has been designed so that coalescing can continue over arbitrary patterns of marking and only needs to stop when the counter wraps. Nonetheless, until the particular offload hardware in use implements this more efficient approach, it is likely to be more efficient for AccECN connections to implement this counter-style logic using software segmentation offload.
現在のオフロード ハードウェアは、TCP-ECN フラグが変化するたびに、結合プロセスからセグメントを除外します。データ センターでは、このオフロード ハードウェアにとって幸運だったのは、CE マークの長いシーケンスがある場合、DCTCP スタイルのフィードバックが変化する頻度が低くなることです。これは、ステップ マーキングしきい値の場合によく見られます (ただし、短いフローが多く含まれる場合はその可能性は低くなります)。ACE カウンタのアプローチは、マーキングの任意のパターンにわたって合体を継続できるように設計されており、カウンタがラップするときにのみ停止する必要があります。それにもかかわらず、使用中の特定のオフロード ハードウェアがこのより効率的なアプローチを実装するまでは、AccECN 接続ではソフトウェア セグメンテーション オフロードを使用してこのカウンター スタイルのロジックを実装する方が効率的である可能性があります。
ECN encodes a varying signal in the ACK stream, so it is inevitable that offload hardware will ultimately need to handle any form of ECN feedback exceptionally. The ACE field has been designed as a counter so that it is straightforward for offload hardware to pass on the highest counter, and to push a segment from its cache before the counter wraps. The purpose of working towards standardized TCP-ECN feedback is to reduce the risk for hardware developers, who would otherwise have to guess which scheme is likely to become dominant.
ECN は ACK ストリーム内の変化する信号をエンコードするため、最終的にオフロード ハードウェアがあらゆる形式の ECN フィードバックを例外的に処理する必要があることは避けられません。ACE フィールドは、オフロード ハードウェアが最も高いカウンタを渡し、カウンタがラップする前にキャッシュからセグメントをプッシュすることが簡単になるように、カウンタとして設計されています。標準化された TCP-ECN フィードバックに向けて取り組む目的は、ハードウェア開発者がどのスキームが支配的になるかを推測する必要があるリスクを軽減することです。
The above process has been designed to enable a continuing incremental deployment path -- to more highly dynamic congestion control. Once offload hardware supports AccECN, it will be able to coalesce efficiently for any sequence of marks, instead of relying on the long marking sequences from step marking for efficiency. In the next stage, marking can evolve from a step to a ramp function. That in turn will allow host congestion control algorithms to respond faster to dynamics, while being backwards compatible with existing host algorithms.
上記のプロセスは、より高度に動的な輻輳制御への継続的な増分展開パスを可能にするように設計されています。オフロード ハードウェアが AccECN をサポートすると、効率のためにステップ マーキングからの長いマーキング シーケンスに依存するのではなく、任意のマーク シーケンスを効率的に結合できるようになります。次の段階では、マーキングはステップからランプ関数に進化します。これにより、既存のホスト アルゴリズムとの下位互換性を維持しながら、ホストの輻輳制御アルゴリズムがダイナミクスにさらに速く応答できるようになります。
This section clarifies which parts of RFC 3168 are updated and maps them to the relevant updated sections of the present AccECN specification.
このセクションでは、RFC 3168 のどの部分が更新されるかを明確にし、それらを現在の AccECN 仕様の関連する更新されたセクションにマップします。
* The whole of Section 6.1.1 (TCP Initialization) of [RFC3168] is updated by Section 3.1 of the present specification.
* [RFC3168] のセクション 6.1.1 (TCP Initialization) の全体が、本仕様のセクション 3.1 によって更新されます。
* In Section 6.1.2 (The TCP Sender) of [RFC3168], all mentions of a congestion response to an ECN-Echo (ECE) ACK packet are updated by Section 3.2 of the present specification to mean an increment to the sender's count of CE-marked packets, s.cep. And the requirements to set the CWR flag no longer apply, as specified in Section 3.1.5 of the present specification. Otherwise, the remaining requirements in Section 6.1.2 (The TCP Sender) of [RFC3168] still stand.
* [RFC3168] のセクション 6.1.2 (TCP 送信者) では、ECN-Echo (ECE) ACK パケットに対する輻輳応答に関するすべての記述が、本仕様のセクション 3.2 によって更新され、送信者の CE マーク付きパケットのカウントの増加を意味します。また、本仕様のセクション 3.1.5 で指定されているように、CWR フラグを設定する要件は適用されなくなりました。それ以外の場合、[RFC3168] のセクション 6.1.2 (TCP 送信者) の残りの要件は依然として有効です。
Note that [RFC8311] already updates a number of the requirements in Section 6.1.2 (The TCP Sender) of [RFC3168]. Section 6.1.2 of [RFC3168] extended standard TCP congestion control [RFC5681] to cover ECN marking as well as packet drop. Whereas, [RFC8311] enables experimentation with alternative responses to ECN marking, if specified for instance by an Experimental RFC produced by the IETF Stream. [RFC8311] also strengthened the statement that "ECT(0) SHOULD be used" to a "MUST" (see [RFC8311] for the details).
[RFC8311] は、[RFC3168] のセクション 6.1.2 (TCP 送信者) の多くの要件をすでに更新していることに注意してください。[RFC3168] のセクション 6.1.2 は、標準 TCP 輻輳制御 [RFC5681] を拡張し、ECN マーキングとパケットドロップをカバーしました。一方、[RFC8311] では、たとえば IETF ストリームによって作成された実験 RFC によって指定されている場合、ECN マーキングに対する代替応答の実験が可能になります。[RFC8311] はまた、「ECT(0) を使用すべきである」という記述を「しなければならない」に強化しました (詳細については [RFC8311] を参照)。
* The whole of Section 6.1.3 (The TCP Receiver) of [RFC3168] is updated by Section 3.2 of the present specification, with the exception of the last paragraph (about congestion response to drop and ECN in the same round trip), which still stands. Incidentally, this last paragraph is in the wrong section, because it relates to "TCP Sender" behaviour.
* [RFC3168] のセクション 6.1.3 (The TCP Receiver) の全体は、最後の段落 (同じラウンドトリップにおけるドロップと ECN に対する輻輳応答について) を除いて、本仕様書のセクション 3.2 によって更新され、現在もそのままです。ちなみに、この最後の段落は「TCP 送信者」の動作に関連しているため、間違ったセクションにあります。
* The following text within Section 6.1.5 (Retransmitted TCP packets) of [RFC3168]:
* [RFC3168] のセクション 6.1.5 (再送信された TCP パケット) 内の次のテキスト:
* the TCP data receiver SHOULD ignore the ECN field on arriving data packets that are outside of the receiver's current window.
* TCP データ受信者は、受信者の現在のウィンドウ外に到着するデータ パケットの ECN フィールドを無視する必要があります (SHOULD)。
is updated by more stringent acceptability tests for any packet (not just data packets) in the present specification. Specifically, in the normative specification of AccECN (Section 3), only 'Acceptable' packets contribute to the ECN counters at the AccECN receiver and Section 1.3 defines an Acceptable packet as one that passes acceptability tests equivalent in strength to those in both [RFC9293] and [RFC5961].
本仕様のあらゆるパケット (データ パケットだけでなく) に対するより厳格な受容性テストによって更新されます。具体的には、AccECN の規範的仕様 (セクション 3) では、「Acceptable」パケットのみが AccECN 受信側の ECN カウンタに寄与し、セクション 1.3 では、[RFC9293] と [RFC5961] の両方の強度と同等の許容性テストに合格するパケットとして Acceptable パケットを定義しています。
* Sections 5.2 (Dropped or Corrupted Packets), 6.1.1 (TCP Initialization), 6.1.4 (Congestion on the ACK-path), 6.1.5 (Retransmitted TCP packets), and 6.1.6 (TCP Window Probes) of [RFC3168] prohibit use of ECN on TCP control packets and retransmissions. The present specification does not update that aspect of [RFC3168], but it does say what feedback an AccECN Data Receiver ought to provide if it receives an ECN-capable control packet or retransmission. This ensures AccECN is forward compatible with any future scheme that allows ECN on these packets, as provided for in Section 4.3 of [RFC8311] and as proposed in [ECN++].
* [RFC3168] のセクション 5.2 (ドロップまたは破損したパケット)、6.1.1 (TCP 初期化)、6.1.4 (ACK パスの輻輳)、6.1.5 (再送信された TCP パケット)、および 6.1.6 (TCP ウィンドウ プローブ) では、TCP 制御パケットと再送信での ECN の使用を禁止しています。本仕様書は[RFC3168]のその側面を更新するものではないが、AccECNデータ受信機がECN対応の制御パケットまたは再送信を受信した場合にどのようなフィードバックを提供すべきかについては述べている。これにより、[RFC8311] のセクション 4.3 で規定されているように、また [ECN++] で提案されているように、AccECN はこれらのパケットで ECN を許可する将来のスキームと前方互換性があることが保証されます。
This section is informative, not normative.
このセクションは参考情報であり、規範ではありません。
A TCP Server can use SYN Cookies (see Appendix A of [RFC4987]) to protect itself from SYN flooding attacks. It places minimal commonly used connection state in the SYN/ACK, and deliberately does not hold any state while waiting for the subsequent ACK (e.g., it closes the thread). Therefore, it cannot record the fact that it entered AccECN mode for both half-connections. Indeed, it cannot even remember whether it negotiated the use of Classic ECN [RFC3168].
TCP サーバーは、SYN Cookie ([RFC4987] の付録 A を参照) を使用して、SYN フラッディング攻撃から自身を保護できます。これは、一般的に使用される最小限の接続状態を SYN/ACK に配置し、後続の ACK を待機している間は意図的に状態を保持しません (たとえば、スレッドを閉じます)。したがって、両方のハーフコネクションに対して AccECN モードに入ったことを記録することはできません。実際、Classic ECN [RFC3168] の使用を交渉したかどうかさえ思い出せません。
Nonetheless, such a Server can determine that it negotiated AccECN as follows. If a TCP Server using SYN Cookies supports AccECN and if it receives a pure ACK that acknowledges an ISN that is a valid SYN cookie, and if the ACK contains an ACE field with the value 0b010 to 0b111 (decimal 2 to 7), the Server can infer the first two stages of the handshake:
それにもかかわらず、そのようなサーバーは、次のように AccECN をネゴシエートしたと判断できます。SYN Cookie を使用する TCP サーバーが AccECN をサポートし、有効な SYN Cookie である ISN を確認する純粋な ACK を受信し、その ACK に値 0b010 ～ 0b111 (10 進数 2 ～ 7) の ACE フィールドが含まれている場合、サーバーはハンドシェイクの最初の 2 段階を推論できます。
* the TCP Client has to have requested AccECN support on the SYN;
* TCP クライアントは SYN 上で AccECN サポートをリクエストする必要があります。
* then, even though the Server kept no state, it has to have confirmed that it supported AccECN.
* その場合、サーバーは状態を保持していなかったとしても、AccECN をサポートしていることを確認する必要があります。
Therefore, the Server can switch itself into AccECN mode, and continue as if it had never forgotten that it switched itself into AccECN mode earlier.
したがって、サーバーは自身を AccECN モードに切り替え、以前に自身を AccECN モードに切り替えたことを忘れていないかのように続行できます。
If the pure ACK that acknowledges a SYN cookie contains an ACE field with the value 0b000 or 0b001, these values indicate that the TCP Client did not request support for AccECN; therefore, the Server does not enter AccECN mode for this connection. Further, 0b001 on the ACK implies that the Server sent an ECN-capable SYN/ACK, which was marked CE in the network, and the non-AccECN TCP Client fed this back by setting ECE on the ACK of the SYN/ACK.
SYN Cookie を確認する純粋な ACK に値 0b000 または 0b001 の ACE フィールドが含まれている場合、これらの値は TCP クライアントが AccECN のサポートを要求していないことを示します。したがって、サーバーはこの接続に対して AccECN モードに入りません。さらに、ACK の 0b001 は、サーバーがネットワーク内で CE とマークされた ECN 対応の SYN/ACK を送信し、非 AccECN TCP クライアントが SYN/ACK の ACK に ECE を設定することでこれをフィードバックしたことを意味します。
AccECN is compatible (at least on paper) with the most commonly used TCP Options: MSS, timestamp, window scaling, SACK, and TCP-AO. It is also compatible with Multipath TCP (MPTCP [RFC8684]) and the experimental TCP Option TCP Fast Open (TFO [RFC7413]). AccECN is friendly to all these protocols, because space for TCP Options is particularly scarce on the SYN, where AccECN consumes zero additional header space.
AccECN は、最も一般的に使用される TCP オプション (MSS、タイムスタンプ、ウィンドウ スケーリング、SACK、TCP-AO) と (少なくとも紙の上では) 互換性があります。また、マルチパス TCP (MPTCP [RFC8684]) および実験的な TCP オプション TCP Fast Open (TFO [RFC7413]) とも互換性があります。AccECN はこれらすべてのプロトコルに適しています。これは、SYN では TCP オプション用のスペースが特に不足しており、AccECN は追加のヘッダー スペースを消費しないためです。
Because option space is limited, Section 3.2.3.3 specifies which AccECN Option fields are more important to include and provides guidance on the relative importance of AccECN Options against other TCP Options.
オプションのスペースは限られているため、セクション 3.2.3.3 では、どの AccECN オプション フィールドを含めるのがより重要かを指定し、他の TCP オプションに対する AccECN オプションの相対的な重要性に関するガイダンスを提供します。
Implementers of TFO need to take careful note of the recommendation in Section 3.2.2.1. That section recommends that, if the TCP Client has successfully negotiated AccECN, when acknowledging the SYN/ACK, even if it has data to send, it sends a pure ACK immediately before the data. Then it can reflect the IP-ECN field of the SYN/ACK on this pure ACK, which allows the Server to detect ECN mangling. Note that, as specified in Section 3.2, any data on the SYN (SYN=1, ACK=0) is not included in any of the byte counters held locally for each ECN marking, nor in the AccECN Option on the wire.
TFO の実装者は、セクション 3.2.2.1 の推奨事項に注意する必要があります。このセクションでは、TCP クライアントが AccECN のネゴシエーションに成功した場合、SYN/ACK を確認するときに、送信するデータがある場合でも、データの直前に純粋な ACK を送信することを推奨しています。次に、この純粋な ACK に SYN/ACK の IP-ECN フィールドを反映できます。これにより、サーバーは ECN マングリングを検出できるようになります。セクション 3.2 で指定されているように、SYN 上のデータ (SYN=1、ACK=0) は、各 ECN マーキングに対してローカルに保持されるバイト カウンタにも、回線上の AccECN オプションにも含まれないことに注意してください。
AccECN feedback is compatible with the ECN++ experiment [ECN++], which allows TCP control packets and retransmissions to be ECN-capable ([RFC3168] was updated by [RFC8311] to permit such experiments). AccECN is likely to inherently support any experiment with ECN-capable packets, because it feeds back the contents of the ECN field mechanistically, without judging whether or not a packet ought to use the ECN capability (Section 2.5). This specification does not discuss implementing AccECN alongside [RFC5562], which was an earlier experimental protocol with narrower scope than ECN++ and a 5-way handshake.
AccECN フィードバックは、ECN++ 実験 [ECN++] と互換性があり、TCP 制御パケットと再送信を ECN 対応にすることができます ([RFC3168] は、そのような実験を許可するために [RFC8311] によって更新されました)。AccECN は、パケットが ECN 機能を使用すべきかどうかを判断することなく、ECN フィールドの内容を機構的にフィードバックするため、本質的に ECN 対応パケットを使用したあらゆる実験をサポートする可能性があります (セクション 2.5)。この仕様では、[RFC5562] と並行して AccECN を実装することについては説明しません。RFC5562 は、ECN++ よりも範囲が狭く、5 ウェイ ハンドシェイクを備えた初期の実験プロトコルでした。
Three alternative mechanisms are available to assure the integrity of ECN and/or loss signals. AccECN is compatible with any of these approaches:
ECN および/または損失信号の完全性を保証するために、3 つの代替メカニズムが利用可能です。AccECN は、次のいずれかのアプローチと互換性があります。
* The Data Sender can test the integrity of the receiver's ECN (or loss) feedback by occasionally setting the IP-ECN field to a value normally only set by the network (and/or deliberately leaving a sequence number gap). Then it can test whether the Data Receiver's feedback faithfully reports what it expects (similar to paragraph 2 of Section 20.2 of [RFC3168]). Unlike the ECN-nonce [RFC3540], this approach does not waste the ECT(1) codepoint in the IP header, it does not require standardization, and it does not rely on misbehaving receivers volunteering to reveal feedback information that allows them to be detected. However, setting the CE mark by the sender might conceal actual congestion feedback from the network and therefore ought to only be done sparingly.
* データ送信者は、IP-ECN フィールドを通常はネットワークによってのみ設定される値に時折設定する (および/または意図的にシーケンス番号のギャップを残す) ことによって、受信者の ECN (または損失) フィードバックの整合性をテストできます。次に、データ受信者のフィードバックが期待するものを忠実に報告しているかどうかをテストできます ([RFC3168] のセクション 20.2 の段落 2 と同様)。ECN-nonce [RFC3540] とは異なり、このアプローチは IP ヘッダー内の ECT(1) コードポイントを無駄にせず、標準化を必要とせず、検出を可能にするフィードバック情報を明らかにするために自発的に不正動作を行う受信機に依存しません。ただし、送信者が CE マークを設定すると、実際の輻輳フィードバックがネットワークから隠蔽される可能性があるため、慎重に行う必要があります。
* Networks generate congestion signals when they are becoming congested, so networks are more likely than Data Senders to be concerned about the integrity of the receiver's feedback of these signals. A network can enforce a congestion response to its ECN markings (or packet losses) using congestion exposure (ConEx) audit [RFC7713]. Whether the receiver or a downstream network is suppressing congestion feedback, or the sender is unresponsive to the feedback, or both, ConEx audit can neutralize any advantage that any of these three parties would otherwise gain.
* ネットワークは輻輳が進むと輻輳信号を生成するため、ネットワークはデータ送信者よりも受信者によるこれらの信号のフィードバックの完全性を懸念する可能性が高くなります。ネットワークは、輻輳エクスポージャ (ConEx) 監査 [RFC7713] を使用して、ECN マーキング (またはパケット損失) に対する輻輳応答を強制できます。受信者またはダウンストリーム ネットワークが輻輳フィードバックを抑制している場合でも、送信者がフィードバックに応答していない場合でも、あるいはその両方でも、ConEx 監査を使用すると、これら 3 者が他の方法で得られるであろう利点を無効にすることができます。
ConEx is an experimental change to the Data Sender that would be most useful when combined with AccECN. Without AccECN, the ConEx behaviour of a Data Sender would have to be more conservative than would be necessary if it had the accurate feedback of AccECN.
ConEx は、AccECN と組み合わせると最も役立つデータ センダーへの実験的な変更です。AccECN がなければ、データ送信者の ConEx 動作は、AccECN の正確なフィードバックがある場合よりも保守的になる必要があります。
* The Standards Track TCP authentication option (TCP-AO [RFC5925]) can be used to detect any tampering with AccECN feedback between the Data Receiver and the Data Sender (whether malicious or accidental). The AccECN fields are immutable end to end, so they are amenable to TCP-AO protection, which covers TCP Options by default. However, TCP-AO is often too brittle to use on many end-to-end paths, where middleboxes can make verification fail in their attempts to improve performance or security, e.g., Network Address Translation (NAT) and Network Address Port Translation (NAPT), resegmentation, or shifting the sequence space.
* Standards Track TCP 認証オプション (TCP-AO [RFC5925]) を使用すると、データ受信者とデータ送信者間の AccECN フィードバックの改ざん (悪意があるか偶発的かにかかわらず) を検出できます。AccECN フィールドはエンドツーエンドで不変であるため、デフォルトで TCP オプションをカバーする TCP-AO 保護に適しています。ただし、TCP-AO は多くのエンドツーエンド パスで使用するには脆弱すぎることがよくあり、ミドルボックスでは、ネットワーク アドレス変換 (NAT) やネットワーク アドレス ポート変換 (NAPT)、再セグメント化、シーケンス スペースのシフトなど、パフォーマンスやセキュリティを向上させる試みで検証が失敗する可能性があります。
This section is informative, not normative. It describes how well the protocol satisfies the agreed requirements for a more Accurate ECN feedback protocol [RFC7560].
このセクションは参考情報であり、規範ではありません。これは、より正確な ECN フィードバック プロトコル [RFC7560] の合意された要件をプロトコルがどの程度満たしているかを説明します。
Accuracy:
正確さ：
From each ACK, the Data Sender can infer the number of new CE-marked segments since the previous ACK. This provides better accuracy on CE feedback than Classic ECN. In addition, if an AccECN Option is present (not blocked by the network path), the number of bytes marked with CE, ECT(1), and ECT(0) are provided.
データ送信側は、各 ACK から、前の ACK 以降に新たに CE マークが付けられたセグメントの数を推測できます。これにより、クラシック ECN よりも CE フィードバックの精度が向上します。さらに、AccECN オプションが存在する場合 (ネットワーク パスによってブロックされていない場合)、CE、ECT(1)、および ECT(0) でマークされたバイト数が提供されます。
Overhead:
オーバーヘッド：
The AccECN scheme is divided into two parts. The essential feedback part reuses the three flags already assigned to ECN in the TCP header. The supplementary feedback part adds an additional TCP Option consuming up to 11 bytes. However, no TCP Option space is consumed in the SYN.
AccECN スキームは 2 つの部分に分かれています。重要なフィードバック部分は、TCP ヘッダーの ECN にすでに割り当てられている 3 つのフラグを再利用します。補足フィードバック部分は、最大 11 バイトを消費する追加の TCP オプションを追加します。ただし、SYN では TCP オプション スペースは消費されません。
Ordering:
注文:
The order in which marks arrive at the Data Receiver is preserved in AccECN feedback, because the Data Receiver is expected to send an ACK immediately whenever a different mark arrives.
データ受信者は、別のマークが到着するたびに ACK をすぐに送信することが期待されるため、マークがデータ受信者に到着する順序は AccECN フィードバックに保存されます。
Timeliness:
適時性:
While the same ECN markings are arriving continually at the Data Receiver, it can defer ACKs as TCP does normally, but it will immediately send an ACK as soon as a different ECN marking arrives.
同じ ECN マーキングが継続的にデータ受信側に到着している間、TCP が通常行うように ACK を延期できますが、別の ECN マーキングが到着するとすぐに ACK を送信します。
Timeliness vs Overhead:
適時性とオーバーヘッド:
Change-Triggered ACKs are intended to enable latency-sensitive uses of ECN feedback by capturing the timing of transitions but not wasting resources while the state of the signalling system is stable. Within the constraints of the change-triggered ACK rules, the receiver can control how frequently it sends AccECN TCP Options and therefore to some extent it can control the overhead induced by AccECN.
Change-Triggered ACK は、信号システムの状態が安定している間にリソースを無駄にせず、遷移のタイミングを捕捉することで、遅延に敏感な ECN フィードバックの使用を可能にすることを目的としています。変更トリガー ACK ルールの制約内で、受信側は AccECN TCP オプションを送信する頻度を制御できるため、AccECN によって引き起こされるオーバーヘッドをある程度制御できます。
Resilience:
回復力:
All information is provided based on counters. Therefore if ACKs are lost, the counters on the first ACK following the losses allow the Data Sender to immediately recover the number of the ECN markings that it missed. If data or ACKs are reordered, stale congestion information can be identified and ignored.
すべての情報はカウンターに基づいて提供されます。したがって、ACK が失われた場合、損失後の最初の ACK のカウンタにより、データ送信者は失われた ECN マーキングの数を即座に回復できます。データまたは ACK が並べ替えられた場合、古い輻輳情報が特定され、無視される可能性があります。
Resilience against Bias:
偏見に対する回復力:
Because feedback is based on repetition of counters, random losses do not remove any information, they only delay it. Therefore, even though some ACKs are change-triggered, random losses will not alter the proportions of the different ECN markings in the feedback.
フィードバックはカウンターの繰り返しに基づいているため、ランダムな損失は情報を削除せず、遅延させるだけです。したがって、一部の ACK が変更によってトリガーされる場合でも、ランダムな損失によってフィードバック内のさまざまな ECN マーキングの割合が変わることはありません。
Resilience vs Overhead:
復元力とオーバーヘッド:
If space is limited in some segments (e.g., because more options are needed on some segments, such as the SACK option after loss), the Data Receiver can send AccECN Options less frequently or truncate fields that have not changed, usually down to as little as 5 bytes.
一部のセグメントでスペースが制限されている場合（たとえば、損失後の SACK オプションなど、一部のセグメントでより多くのオプションが必要なため）、データ受信側は AccECN オプションの送信頻度を下げるか、変更されていないフィールドを通常は 5 バイトまで切り捨てることができます。
Resilience vs Timeliness and Ordering:
回復力 vs 適時性と順序:
Ordering information and the timing of transitions cannot be communicated in three cases: i) during ACK loss; ii) if something on the path strips AccECN Options; or iii) if the Data Receiver is unable to support Change-Triggered ACKs. Following ACK reordering, the Data Sender can reconstruct the order in which feedback was sent, but not until all the missing feedback has arrived.
順序付け情報と遷移のタイミングは、次の 3 つの場合に通信できません。i) ACK 損失中。ii) パス上の何かが AccECN オプションを削除する場合。または iii) データ受信者が変更トリガー ACK をサポートできない場合。ACK の並べ替えに続いて、データ送信者はフィードバックが送信された順序を再構築できますが、欠落しているフィードバックがすべて到着するまでは再構築できません。
Complexity:
複雑：
An AccECN implementation solely involves simple counter increments, some modulo arithmetic to communicate the least significant bits and allow for wrap, and some heuristics for safety against fields cycling due to prolonged periods of ACK loss. Each host needs to maintain eight additional counters. The hosts have to apply some additional tests to detect tampering by middleboxes, but in general the protocol is simple to understand and implement and requires few cycles per packet to execute.
AccECN の実装には、単純なカウンタの増分、最下位ビットを通信してラップを可能にするモジュロ演算、および長時間にわたる ACK 損失によるフィールドの循環に対する安全のためのヒューリスティックのみが含まれます。各ホストは 8 つの追加カウンターを維持する必要があります。ホストは、ミドルボックスによる改ざんを検出するために追加のテストを適用する必要がありますが、一般に、プロトコルは理解および実装が簡単で、実行に必要なパケットあたりのサイクルは数サイクルです。
Integrity:
誠実さ：
AccECN is compatible with at least three approaches that can assure the integrity of ECN feedback. If AccECN Options are stripped, the resolution of the feedback is degraded, but the integrity of this degraded feedback can still be assured.
AccECN は、ECN フィードバックの完全性を保証できる少なくとも 3 つのアプローチと互換性があります。AccECN オプションが削除されると、フィードバックの解像度は低下しますが、この低下したフィードバックの整合性は依然として保証されます。
Backward Compatibility:
下位互換性:
If only one endpoint supports the AccECN scheme, it will fall back to the most advanced ECN feedback scheme supported by the other end.
1 つのエンドポイントのみが AccECN スキームをサポートする場合、もう一方のエンドポイントがサポートする最も高度な ECN フィードバック スキームにフォールバックします。
If AccECN Options are stripped by a middlebox, AccECN still provides basic congestion feedback in the ACE field. Further, AccECN can be used to detect mangling of the IP-ECN field; mangling of the TCP-ECN flags; blocking of ECT-marked segments; and blocking of segments carrying an AccECN Option. It can detect these conditions during TCP's three-way handshake so that it can fall back to operation without ECN and/or operation without AccECN Options.
AccECN オプションがミドルボックスによって削除された場合でも、AccECN は ACE フィールドで基本的な輻輳フィードバックを提供します。さらに、AccECN を使用して、IP-ECN フィールドのマングリングを検出できます。TCP-ECN フラグの破損。ECTでマークされたセグメントのブロック。AccECN オプションを含むセグメントのブロック。TCP の 3 ウェイ ハンドシェイク中にこれらの状態を検出できるため、ECN なしの動作や AccECN オプションなしの動作にフォールバックできます。
Forward Compatibility:
上位互換性:
The behaviour of endpoints and middleboxes is carefully defined for all reserved or currently unused codepoints in the scheme. Then, the designers of security devices can understand which currently unused values might appear in the future. So, even if they choose to treat such values as anomalous while they are not widely used, any blocking will at least be under policy control, not hard-coded. Then, if previously unused values start to appear on the Internet (or in standards), such policies could be quickly reversed.
エンドポイントとミドルボックスの動作は、スキーム内のすべての予約済みまたは現在未使用のコードポイントに対して慎重に定義されます。これにより、セキュリティ デバイスの設計者は、現在使用されていない値が将来出現する可能性があるかを理解できます。したがって、広く使用されていない間はそのような値を異常なものとして扱うことを選択したとしても、ブロックは少なくともポリシーの制御下にあり、ハードコーディングされることはありません。その後、以前は使用されていなかった値がインターネット (または標準規格) 上に現れ始めた場合、そのようなポリシーはすぐに覆される可能性があります。
This document reassigns the TCP header flag at bit offset 7 to the AccECN protocol. This bit was previously called the Nonce Sum (NS) flag [RFC3540], but RFC 3540 has been reclassified as Historic [RFC8311]. The flag is now defined as the following in the "TCP Header Flags" registry in the "Transmission Control Protocol (TCP) Parameters" registry group:
この文書は、ビット オフセット 7 の TCP ヘッダー フラグを AccECN プロトコルに再割り当てします。このビットは以前は Nonce Sum (NS) フラグ [RFC3540] と呼ばれていましたが、RFC 3540 はヒストリック [RFC8311] として再分類されました。このフラグは、「伝送制御プロトコル (TCP) パラメーター」レジストリ グループの「TCP ヘッダー フラグ」レジストリで次のように定義されています。
+=====+==============+===========+==============================+
| Bit | Name | Reference | Assignment Notes |
+=====+==============+===========+==============================+
| 7 | AE (Accurate | RFC 9768 | Previously used as NS (Nonce |
| | ECN) | | Sum) by [RFC3540], which is |
| | | | now Historic [RFC8311] |
+-----+--------------+-----------+------------------------------+
Table 6: TCP Header Flag Reassignment
表 6: TCP ヘッダー フラグの再割り当て
This document also defines two new TCP Options for AccECN from the TCP Option space. These values are defined as the following in the "TCP Option Kind Numbers" registry in the "Transmission Control Protocol (TCP) Parameters" registry group:
この文書では、TCP オプション スペースから AccECN 用の 2 つの新しい TCP オプションも定義します。これらの値は、「Transmission Control Protocol (TCP) Parameters」レジストリ グループの「TCP Option Kind Numbers」レジストリで次のように定義されています。
+======+========+================================+===========+
| Kind | Length | Meaning | Reference |
+======+========+================================+===========+
| 172 | N | Accurate ECN Order 0 (AccECN0) | RFC 9768 |
+------+--------+--------------------------------+-----------+
| 174 | N | Accurate ECN Order 1 (AccECN1) | RFC 9768 |
+------+--------+--------------------------------+-----------+
Table 7: New TCP Option Assignments
表 7: 新しい TCP オプションの割り当て
Early experimental implementations of the two AccECN Options used experimental option 254 per [RFC6994] with the 16-bit magic numbers 0xACC0 and 0xACC1, respectively, for Order 0 and 1, as allocated in the IANA "TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)" registry. Even earlier experimental implementations used the single magic number 0xACCE (16 bits). Uses of these experimental options SHOULD migrate to use the new option kinds (172 and 174).
2 つの AccECN オプションの初期の実験的実装では、IANA「TCP/UDP 実験的オプション実験識別子 (TCP/UDP ExID)」レジストリで割り当てられた、オーダー 0 と 1 に対して、それぞれ 16 ビットのマジックナンバー 0xACC0 と 0xACC1 を持つ [RFC6994] による実験的オプション 254 を使用しました。以前の実験的な実装でも、単一のマジックナンバー 0xACCE (16 ビット) が使用されていました。これらの実験的なオプションの使用は、新しいオプションの種類 (172 および 174) を使用するように移行する必要があります。
If ever the supplementary feedback part of AccECN that is based on one of the new AccECN TCP Options is unusable (due for example to middlebox interference), the essential feedback part of AccECN's congestion feedback offers only limited resilience to long runs of ACK loss (see Section 3.2.2.5). These problems are unlikely to be due to malicious intervention (because if an attacker could strip a TCP Option or discard a long run of ACKs, it could wreak other arbitrary havoc). However, it would be of concern if AccECN's resilience could be indirectly compromised during a flooding attack. AccECN is still considered safe though, because if AccECN Options are not present, the AccECN Data Sender is then required to switch to more conservative assumptions about wrap of congestion indication counters (see Section 3.2.2.5 and Appendix A.2).
新しい AccECN TCP オプションの 1 つに基づく AccECN の補足フィードバック部分が (ミドルボックス干渉などにより) 使用できない場合、AccECN の輻輳フィードバックの必須フィードバック部分は、長時間にわたる ACK 損失に対して限られた回復力しか提供しません (セクション 3.2.2.5 を参照)。これらの問題は、悪意のある介入によるものである可能性は低いです (攻撃者が TCP オプションを剥奪したり、長時間の ACK を破棄したりすると、他の任意の大混乱を引き起こす可能性があるため)。ただし、フラッディング攻撃中に AccECN の回復力が間接的に侵害される可能性がある場合は懸念されます。ただし、AccECN オプションが存在しない場合、AccECN データ送信側は輻輳表示カウンタのラップに関するより保守的な想定に切り替える必要があるため、AccECN は依然として安全であると考えられています (セクション 3.2.2.5 および付録 A.2 を参照)。
Section 5.1 describes how a TCP Server can negotiate AccECN and use the SYN cookie method for mitigating SYN flooding attacks.
セクション 5.1 では、TCP サーバーが AccECN をネゴシエートし、SYN フラッディング攻撃を軽減するために SYN Cookie メソッドを使用する方法について説明します。
There is concern that ECN feedback could be altered or suppressed, particularly because a misbehaving Data Receiver could increase its own throughput at the expense of others. AccECN is compatible with the three schemes known to assure the integrity of ECN feedback (see Section 5.3 for details). If AccECN Options are stripped by an incorrectly implemented middlebox, the resolution of the feedback will be degraded, but the integrity of this degraded information can still be assured. Assuring that Data Senders respond appropriately to ECN feedback is possible, but the scope of the present document is confined to the feedback protocol and excludes the response to this feedback.
特に不正な動作をするデータ受信者が他のデータ受信者を犠牲にして自身のスループットを増加させる可能性があるため、ECN フィードバックが変更または抑制される可能性があるという懸念があります。AccECN は、ECN フィードバックの整合性を保証するために知られている 3 つのスキームと互換性があります (詳細についてはセクション 5.3 を参照)。不適切に実装されたミドルボックスによって AccECN オプションが削除された場合、フィードバックの解像度は低下しますが、この低下した情報の整合性は依然として保証されます。データ送信者が ECN フィードバックに適切に応答することを保証することは可能ですが、本書の範囲はフィードバック プロトコルに限定され、このフィードバックへの応答は除外されます。
In Section 3.2.3, a Data Sender is allowed to ignore an unrecognized TCP AccECN Option length and read as many whole 3-octet fields from it as possible up to a maximum of 3, treating the remainder as padding. This opens up a potential covert channel of up to 29B (40 - (2+3*3)). However, it is really an overt channel (not hidden) and it is no different from the use of unknown TCP Options with unknown option lengths in general. Therefore, where this is of concern, it can already be adequately mitigated by regular TCP normalizer technology (see Section 3.3.2).
セクション 3.2.3 では、データ送信者は、認識できない TCP AccECN オプションの長さを無視し、そこから 3 オクテット全体のフィールドをできるだけ多く読み取り、最大 3 つまで読み取り、残りをパディングとして扱うことができます。これにより、最大 29B (40 - (2+3*3)) の潜在的な秘密チャネルが開かれます。ただし、これは実際には (隠蔽されていない) 明白なチャネルであり、一般にオプション長が不明な不明な TCP オプションを使用するのと何ら変わりません。したがって、これが懸念される場合は、通常の TCP ノーマライザー テクノロジによってすでに適切に軽減できます (セクション 3.3.2 を参照)。
There is a potential concern that a Data Receiver could deliberately omit AccECN Options pretending that they had been stripped by a middlebox. Currently, there is no known way for a receiver to take advantage of this behaviour, which seems to always degrade its own performance. However, the concern is mentioned here for completeness.
データ受信者が、AccECN オプションがミドルボックスによって削除されたかのように意図的に省略される可能性があるという潜在的な懸念があります。現時点では、受信機がこの動作を利用する既知の方法はなく、常に受信機自体のパフォーマンスが低下するようです。ただし、完全を期すためにここではその懸念について言及します。
The AccECN protocol is not believed to introduce any new privacy concerns, because it merely counts and feeds back signals at the transport layer that had already been visible at the IP layer. A covert channel can be used to compromise privacy. However, as explained above, undefined TCP Options in general open up such channels, and common techniques are available to close them off.
AccECN プロトコルは、IP 層ですでに表示されていた信号をトランスポート層でカウントしてフィードバックするだけであるため、新たなプライバシーの問題を引き起こすとは考えられていません。秘密チャネルはプライバシーを侵害するために使用される可能性があります。ただし、上で説明したように、未定義の TCP オプションは一般にそのようなチャネルを開き、それらを閉じるために一般的な技術を利用できます。
A generic privacy concern of any new protocol is that for a while it will be used by a small population of hosts, and thus those hosts could be more easily identified. However, it is expected that AccECN will become available in more operating systems over time and that it will eventually be turned on by default. Thus, an individual identification of a particular user is less of a concern than the fingerprinting of specific versions of operation systems. However, the latter can be done using different means independent of Accurate ECN.
新しいプロトコルに関する一般的なプライバシー上の懸念は、しばらくの間、少数のホストによって使用されることになるため、それらのホストがより簡単に識別される可能性があることです。ただし、時間の経過とともに、AccECN はより多くのオペレーティング システムで利用可能になり、最終的にはデフォルトでオンになることが予想されます。したがって、特定のユーザーの個人識別は、オペレーティング システムの特定のバージョンのフィンガープリンティングほど重要ではありません。ただし、後者は、Accurate ECN とは独立した別の手段を使用して実行できます。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC 2883, DOI 10.17487/RFC2883, July 2000,
<https://www.rfc-editor.org/info/rfc2883>.
[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>.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961,
DOI 10.17487/RFC5961, August 2010,
<https://www.rfc-editor.org/info/rfc5961>.
[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>.
[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>.
[ECN++] Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit
Congestion Notification (ECN) to TCP Control Packets",
Work in Progress, Internet-Draft, draft-ietf-tcpm-
generalized-ecn-17, 21 April 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-
generalized-ecn-17>.
[Mandalari18]
Mandalari, A., Lutu, A., Briscoe, B., Bagnulo, M., and Ö.
Alay, "Measuring ECN++: Good News for ++, Bad News for ECN
over Mobile", IEEE Communications Magazine , March 2018,
<http://www.it.uc3m.es/amandala/
ecn++/ecn_commag_2018.html>.
[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, <https://www.rfc-editor.org/info/rfc3449>.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, DOI 10.17487/RFC3540, June 2003,
<https://www.rfc-editor.org/info/rfc3540>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>.
[RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K.
Ramakrishnan, "Adding Explicit Congestion Notification
(ECN) Capability to TCP's SYN/ACK Packets", RFC 5562,
DOI 10.17487/RFC5562, June 2009,
<https://www.rfc-editor.org/info/rfc5562>.
[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>.
[RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding
Acknowledgement Congestion Control to TCP", RFC 5690,
DOI 10.17487/RFC5690, February 2010,
<https://www.rfc-editor.org/info/rfc5690>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[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, <https://www.rfc-editor.org/info/rfc6679>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options",
RFC 6994, DOI 10.17487/RFC6994, August 2013,
<https://www.rfc-editor.org/info/rfc6994>.
[RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion
Notification", BCP 41, RFC 7141, DOI 10.17487/RFC7141,
February 2014, <https://www.rfc-editor.org/info/rfc7141>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
[RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe,
"Problem Statement and Requirements for Increased Accuracy
in Explicit Congestion Notification (ECN) Feedback",
RFC 7560, DOI 10.17487/RFC7560, August 2015,
<https://www.rfc-editor.org/info/rfc7560>.
[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
Concepts, Abstract Mechanism, and Requirements", RFC 7713,
DOI 10.17487/RFC7713, December 2015,
<https://www.rfc-editor.org/info/rfc7713>.
[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>.
[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>.
[RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"TCP Alternative Backoff with ECN (ABE)", RFC 8511,
DOI 10.17487/RFC8511, December 2018,
<https://www.rfc-editor.org/info/rfc8511>.
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
2020, <https://www.rfc-editor.org/info/rfc8684>.
[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>.
[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>.
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G.
White, "Low Latency, Low Loss, and Scalable Throughput
(L4S) Internet Service: Architecture", RFC 9330,
DOI 10.17487/RFC9330, January 2023,
<https://www.rfc-editor.org/info/rfc9330>.
[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>.
[RoCEv2] InfiniBand Trade Association, "InfiniBand Architecture
Specification", Volume 1, Release 1.4, 2020,
<https://www.infinibandta.org/ibta-specification/>.
This appendix is informative, not normative. It gives example algorithms that would satisfy the normative requirements of the AccECN protocol. However, implementers are free to choose other ways to satisfy the requirements.
この付録は参考情報であり、規範ではありません。AccECN プロトコルの標準要件を満たすアルゴリズムの例を示します。ただし、実装者は要件を満たすために他の方法を自由に選択できます。
The example algorithms below show how a Data Receiver in AccECN mode could encode its CE byte counter r.ceb into the ECEB field within an AccECN TCP Option, and how a Data Sender in AccECN mode could decode the ECEB field into its byte counter s.ceb. The other counters for bytes marked ECT(0) and ECT(1) in an AccECN Option would be similarly encoded and decoded.
以下のアルゴリズム例は、AccECN モードのデータ受信者が CE バイト カウンタ r.ceb を AccECN TCP オプション内の ECEB フィールドにエンコードする方法と、AccECN モードのデータ送信者が ECEB フィールドをバイト カウンタ s.ceb にデコードする方法を示しています。AccECN オプション内の ECT(0) および ECT(1) とマークされたバイトの他のカウンターも同様にエンコードおよびデコードされます。
It is assumed that each local byte counter is an unsigned integer greater than 24b (probably 32b), and that the following constant has been assigned:
各ローカル バイト カウンタは 24b (おそらく 32b) より大きい符号なし整数であり、次の定数が割り当てられていると想定されます。
DIVOPT = 2^24
Every time a CE-marked data segment arrives, the Data Receiver increments its local value of r.ceb by the size of the TCP Data. Whenever it sends an ACK with an AccECN Option, the value it writes into the ECEB field is
CE マークが付けられたデータ セグメントが到着するたびに、データ レシーバーは r.ceb のローカル値を TCP データのサイズだけインクリメントします。AccECN オプションを使用して ACK を送信するたびに、ECEB フィールドに書き込まれる値は次のとおりです。
ECEB = r.ceb % DIVOPT
where '%' is the remainder operator.
ここで、「%」は剰余演算子です。
On the arrival of an AccECN Option, the Data Sender first makes sure the ACK has not been superseded in order to avoid winding the s.ceb counter backwards. It uses the TCP acknowledgement number and any SACK options [RFC2018] to calculate newlyAckedB, the amount of new data that the ACK acknowledges in bytes (newlyAckedB can be zero but not negative). If newlyAckedB is zero, either the ACK has been superseded or CE-marked packet(s) without data could have arrived. To break the tie for the latter case, the Data Sender could use timestamps [RFC7323] (if present) to work out newlyAckedT, the amount of new time that the ACK acknowledges. If the Data Sender determines that the ACK has been superseded, it ignores the AccECN Option. Otherwise, the Data Sender calculates the minimum non-negative difference d.ceb between the ECEB field and its local s.ceb counter, using modulo arithmetic as follows:
AccECN オプションが到着すると、データ送信側は、s.ceb カウンタが逆に巻き戻されるのを避けるために、ACK が置き換えられていないことをまず確認します。TCP 確認応答番号と SACK オプション [RFC2018] を使用して、ACK が確認する新しいデータの量 (バイト単位) newAckedB を計算します (newlyAckedB はゼロにすることはできますが、負にすることはできません)。newAckedB が 0 の場合、ACK が置き換えられたか、データのない CE マークが付けられたパケットが到着した可能性があります。後者の場合の決着を解くために、データ送信者はタイムスタンプ [RFC7323] (存在する場合) を使用して、ACK が確認する新たな時間である newAckedT を計算することができます。データ送信者は、ACK が置き換えられたと判断した場合、AccECN オプションを無視します。それ以外の場合、データ送信者は、次のようにモジュロ算術を使用して、ECEB フィールドとそのローカル s.ceb カウンタ間の最小の非負の差 d.ceb を計算します。
if ((newlyAckedB > 0) || (newlyAckedT > 0)) {
d.ceb = (ECEB + DIVOPT - (s.ceb % DIVOPT)) % DIVOPT
s.ceb += d.ceb
}
For example, if s.ceb is 33,554,433 and ECEB is 1461 (both decimal), then
たとえば、s.ceb が 33,554,433、ECEB が 1461 (どちらも 10 進数) の場合、
s.ceb % DIVOPT = 1
d.ceb = (1461 + 2^24 - 1) % 2^24
= 1460
s.ceb = 33,554,433 + 1460
= 33,555,893
In practice, an implementation might use heuristics to guess the feedback in missing ACKs. Then when it subsequently receives feedback, it might find that it needs to correct its earlier heuristics as part of the decoding process. The above decoding process does not include any such heuristics.
実際には、実装ではヒューリスティックを使用して、欠落した ACK のフィードバックを推測する場合があります。その後、フィードバックを受け取ったときに、デコード プロセスの一部として以前のヒューリスティックを修正する必要があることが判明する可能性があります。上記のデコードプロセスには、そのようなヒューリスティックは含まれていません。
The example algorithms below show how a Data Receiver in AccECN mode could encode its CE packet counter r.cep into the ACE field, and how the Data Sender in AccECN mode could decode the ACE field into its s.cep counter. The Data Sender's algorithm includes code to heuristically detect a long enough unbroken string of ACK losses that could have concealed a cycle of the congestion counter in the ACE field of the next ACK to arrive.
以下のアルゴリズム例は、AccECN モードのデータ受信者が CE パケット カウンタ r.cep を ACE フィールドにエンコードする方法と、AccECN モードのデータ送信者が ACE フィールドを s.cep カウンタにデコードする方法を示しています。データ送信者のアルゴリズムには、次に到着する ACK の ACE フィールド内の輻輳カウンタのサイクルを隠蔽する可能性がある、十分に長い連続した ACK 損失の文字列をヒューリスティックに検出するコードが含まれています。
Two variants of the algorithm are given: i) a more conservative variant for a Data Sender to use if it detects that AccECN Options are not available (see Section 3.2.2.5 and Section 3.2.3.2); and ii) a less conservative variant that is feasible when complementary information is available from AccECN Options.
アルゴリズムには 2 つのバリアントが与えられています: i) データ送信者が AccECN オプションが利用できないことを検出した場合に使用する、より保守的なバリアント (セクション 3.2.2.5 およびセクション 3.2.3.2 を参照)。ii) AccECN オプションから補足情報が入手できる場合に実現可能な、あまり保守的ではないバリアント。
It is assumed that each local packet counter is a sufficiently sized unsigned integer (probably 32b) and that the following constant has been assigned:
各ローカル パケット カウンタは十分なサイズの符号なし整数 (おそらく 32b) であり、次の定数が割り当てられていると想定されます。
DIVACE = 2^3
Every time an Acceptable CE-marked packet arrives (Section 3.2.2.2), the Data Receiver increments its local value of r.cep by 1. It repeats the same value of ACE in every subsequent ACK until the next CE marking arrives, where
許容可能な CE マーク付きパケットが到着するたびに (セクション 3.2.2.2)、データ受信側は r.cep のローカル値を 1 ずつ増分します。データ受信側は、次の CE マーキングが到着するまで、後続のすべての ACK で同じ値の ACE を繰り返します。
ACE = r.cep % DIVACE.
If the Data Sender received an earlier value of the counter that had been delayed due to ACK reordering, it might incorrectly calculate that the ACE field had wrapped. Therefore, on the arrival of every ACK, the Data Sender ensures the ACK has not been superseded using the TCP acknowledgement number, any SACK options, and timestamps (if available) to calculate newlyAckedB, as in Appendix A.1. If the ACK has not been superseded, the Data Sender calculates the minimum difference d.cep between the ACE field and its local s.cep counter, using modulo arithmetic as follows:
データ送信側が ACK の並べ替えにより遅延したカウンタの以前の値を受信した場合、ACE フィールドがラップされたと誤って計算される可能性があります。したがって、すべての ACK が到着すると、データ送信者は、付録 A.1 にあるように、TCP 確認応答番号、SACK オプション、タイムスタンプ (利用可能な場合) を使用して newAckedB を計算し、ACK が置き換えられていないことを確認します。ACK が置き換えられていない場合、データ送信側は、次のようにモジュロ算術を使用して、ACE フィールドとそのローカル s.cep カウンタの間の最小差 d.cep を計算します。
if ((newlyAckedB > 0) || (newlyAckedT > 0))
d.cep = (ACE + DIVACE - (s.cep % DIVACE)) % DIVACE
Section 3.2.2.5 expects the Data Sender to assume that the ACE field cycled if it is the safest likely case under prevailing conditions. The 3-bit ACE field in an arriving ACK could have cycled and become ambiguous to the Data Sender if a sequence of ACKs goes missing that covers a stream of data long enough to contain 8 or more CE marks. We use the word 'missing' rather than 'lost', because some or all the missing ACKs might arrive eventually, but out of order. Even if some of the missing ACKs were piggybacked on data (i.e., not pure ACKs) retransmissions will not repair the lost AccECN information, because AccECN requires retransmissions to carry the latest AccECN counters, not the original ones.
セクション 3.2.2.5 では、一般的な条件下で最も安全である可能性が高い場合に、データ送信者が ACE フィールドが循環したと想定することを期待しています。8 個以上の CE マークを含むのに十分な長さのデータ ストリームをカバーする ACK のシーケンスが失われると、到着した ACK の 3 ビット ACE フィールドが循環し、データ送信者にとって曖昧になる可能性があります。欠落している ACK の一部またはすべてが最終的には到着する可能性があるため、「失われた」ではなく「欠落」という言葉を使用しますが、順序は変わりません。たとえ欠落した ACK の一部がデータに便乗していたとしても (つまり、純粋な ACK ではなく)、再送信では失われた AccECN 情報は修復されません。AccECN では、元の AccECN カウンタではなく最新の AccECN カウンタを再送信する必要があるためです。
The phrase 'under prevailing conditions' allows for implementation-dependent interpretation. A Data Sender might take account of the prevailing size of data segments and the prevailing CE marking rate just before the sequence of missing ACKs. However, we shall start with the simplest algorithm, which assumes segments are all full-sized, and ultra-conservatively it assumes that ECN marking was 100% on the forward path when ACKs on the reverse path started to all be dropped. Specifically, if newlyAckedB is the amount of data that an ACK acknowledges since the previous ACK, then the Data Sender could assume that this acknowledges newlyAckedPkt full-sized segments, where newlyAckedPkt = newlyAckedB/MSS. Then it could assume that the ACE field incremented by
「一般的な条件下で」という表現は、実装に依存した解釈を可能にします。データ送信者は、一連の欠落 ACK の直前に、データ セグメントの一般的なサイズと一般的な CE マーキング レートを考慮する場合があります。ただし、最も単純なアルゴリズムから始めます。このアルゴリズムは、セグメントがすべてフルサイズであることを前提とし、非常に保守的に、逆方向パス上の ACK がすべてドロップされ始めたときに順方向パス上の ECN マーキングが 100% であると仮定します。具体的には、newAckedB が前回の ACK 以降に ACK が確認応答したデータの量である場合、データ送信者は、これが newAckedPkt のフルサイズのセグメントを確認応答したと想定できます (newAckedPkt = newAckedB/MSS)。次に、ACE フィールドが によって増加すると想定できます。
dSafer.cep = newlyAckedPkt - ((newlyAckedPkt - d.cep) % DIVACE)
For example, imagine an ACK acknowledges newlyAckedPkt=9 more full-size segments than any previous ACK, and that ACE increments by a minimum of 2 CE marks (d.cep=2). The above formula indicates that it would still be safe to assume 2 CE marks (because 9 - ((9-2) % 8) = 2). However, if ACE increases by a minimum of 2 but acknowledges 10 full-sized segments, then it would be necessary to assume that there could have been 10 CE marks (because 10 - ((10-2) % 8) = 10).
たとえば、ACK が以前の ACK よりも多くのフルサイズ セグメントを新しく AckedPkt=9 認識し、ACE が少なくとも 2 CE マーク (d.cep=2) だけ増加すると想像してください。上の式は、2 CE マークを想定しても安全であることを示しています (9 - ((9-2) % 8) = 2 であるため)。ただし、ACE が少なくとも 2 増加するが、10 個のフルサイズ セグメントを認識する場合は、10 個の CE マークがあった可能性があると想定する必要があります (10 - ((10-2) % 8) = 10 であるため)。
Note that checks would need to be added to the above pseudocode for (d.cep > newlyAckedPkt), which could occur if newlyAckedPkt had been wrongly estimated using an inappropriate packet size.
上記の疑似コードに (d.cep > newAckedPkt) のチェックを追加する必要があることに注意してください。これは、newAckedPkt が不適切なパケット サイズを使用して誤って推定された場合に発生する可能性があります。
ACKs that acknowledge a large stretch of packets might be common in data centres to achieve a high packet rate or might be due to ACK thinning by a middlebox. In these cases, cycling of the ACE field would often appear to have been possible, so the above algorithm would be overly conservative, leading to a false high marking rate and poor performance. Therefore, it would be reasonable to only use dSafer.cep rather than d.cep if the moving average of newlyAckedPkt was well below 8.
大量のパケットを確認する ACK は、高いパケット レートを達成するためにデータ センターで一般的である可能性があります。あるいは、ミドルボックスによる ACK の間引きが原因である可能性があります。このような場合、ACE フィールドの循環は可能であるように見えることが多いため、上記のアルゴリズムは過度に保守的となり、誤った高いマーキング率とパフォーマンスの低下につながります。したがって、newAckedPkt の移動平均が 8 を大きく下回る場合は、d.cep ではなく dSafer.cep のみを使用するのが合理的です。
Implementers could build in more heuristics to estimate a prevailing average segment size and prevailing ECN marking. For instance, newlyAckedPkt in the above formula could be replaced with newlyAckedPktHeur = newlyAckedPkt*p*MSS/s, where s is the prevailing segment size and p is the prevailing ECN marking probability. However, ultimately, if TCP's ECN feedback becomes inaccurate, it still has loss detection to fall back on. Therefore, it would seem safe to implement a simple algorithm, rather than a perfect one.
実装者は、一般的な平均セグメント サイズと一般的な ECN マーキングを推定するために、より多くのヒューリスティックを組み込むことができます。たとえば、上記の式の newAckedPkt は、newAckedPktHeur = newAckedPkt*p*MSS/s に置き換えることができます。ここで、s は一般的なセグメント サイズ、p は一般的な ECN マーキング確率です。ただし、最終的には、TCP の ECN フィードバックが不正確になった場合でも、引き続き頼れる損失検出が存在します。したがって、完璧なアルゴリズムではなく、単純なアルゴリズムを実装する方が安全であると思われます。
The simple algorithm for dSafer.cep above requires no monitoring of prevailing conditions and it would still be safe if, for example, segments were on average at least 5% of a full-sized segment as long as ECN marking was 5% or less. Assuming it was used, the Data Sender would increment its packet counter as follows:
上記の dSafer.cep の単純なアルゴリズムでは、一般的な状況を監視する必要はありません。たとえば、ECN マーキングが 5% 以下である限り、セグメントが平均してフルサイズのセグメントの少なくとも 5% であったとしても安全です。これが使用されたと仮定すると、データ送信者は次のようにパケット カウンターをインクリメントします。
s.cep += dSafer.cep
If missing acknowledgement numbers arrive later (due to reordering), Section 3.2.2.5.2 says "the Data Sender MAY attempt to neutralize the effect of any action it took based on a conservative assumption that it later found to be incorrect". To do this, the Data Sender would have to store the values of all the relevant variables whenever it made assumptions, so that it could re-evaluate them later. Given this could become complex and it is not required, we do not attempt to provide an example of how to do this.
欠落している確認応答番号が（並べ替えにより）後で到着した場合、セクション 3.2.2.5.2 には、「データ送信者は、後で間違っていることが判明したという保守的な仮定に基づいて実行したアクションの影響を無効化しようとしてもよい (MAY)」と記載されています。これを行うには、データ送信者は、仮定を行うたびに、後で再評価できるように、関連するすべての変数の値を保存する必要があります。これは複雑になる可能性があり、必須ではないため、これを行う方法の例は提供しません。
When AccECN Options are available on the ACKs before and after the possible sequence of ACK losses, if the Data Sender only needs CE-marked bytes, it will have sufficient information in AccECN Options without needing to process the ACE field. If for some reason it needs CE-marked packets, if dSafer.cep is different from d.cep, it can determine whether d.cep is likely to be a safe enough estimate by checking whether the average marked segment size (s = d.ceb/d.cep) is less than the MSS (where d.ceb is the amount of newly CE-marked bytes -- see Appendix A.1). Specifically, it could use the following algorithm:
AccECN オプションが ACK 損失の可能性のあるシーケンスの前後の ACK で使用できる場合、データ送信者が CE マークの付いたバイトのみを必要とする場合、ACE フィールドを処理する必要なく、AccECN オプションに十分な情報が含まれます。何らかの理由で CE マークが付けられたパケットが必要な場合、dSafer.cep が d.cep と異なる場合、平均マーク付きセグメント サイズ (s = d.ceb/d.cep) が MSS より小さいかどうかをチェックすることで、d.cep が十分に安全な推定値である可能性が高いかどうかを判断できます (d.ceb は新たに CE マークが付けられたバイトの量です。付録 A.1 を参照)。具体的には、次のアルゴリズムを使用できます。
SAFETY_FACTOR = 2
if (dSafer.cep > d.cep) {
if (d.ceb <= MSS * d.cep) { % Same as (s <= MSS), but no DBZ
sSafer = d.ceb/dSafer.cep
if (sSafer < MSS/SAFETY_FACTOR)
dSafer.cep = d.cep % d.cep is a safe enough estimate
} % else
% No need for else; dSafer.cep is already correct,
% because d.cep must have been too small
}
The chart below shows when the above algorithm will replace dSafer.cep with d.cep as a safe enough estimate of the number of CE-marked packets:
以下のグラフは、CE マークが付けられたパケット数の十分に安全な推定値として、上記のアルゴリズムが dSafer.cep を d.cep に置き換えるタイミングを示しています。
^
sSafer|
|
MSS+
|
| dSafer.cep
| is
MSS/SAFETY_FACTOR+--------------+ safest
| |
| d.cep is safe|
| enough |
+-------------------->
MSS s
The following examples give the reasoning behind the algorithm, assuming MSS=1460 :
次の例は、 MSS=1460 を前提としたアルゴリズムの背後にある理由を示しています。
* if d.cep=0, dSafer.cep=8, and d.ceb=1460, then s=infinity and sSafer=182.5.
* d.cep=0、dSafer.cep=8、および d.ceb=1460 の場合、s=無限大および sSafer=182.5。
Therefore, even though the average size of 8 data segments is unlikely to have been as small as MSS/8, d.cep cannot have been correct, because it would imply an average segment size greater than the MSS.
したがって、8 データ セグメントの平均サイズが MSS/8 ほど小さい可能性は低いですが、平均セグメント サイズが MSS よりも大きいことを意味するため、d.cep が正しいとは考えられません。
* if d.cep=2, dSafer.cep=10, and d.ceb=1460, then s=730 and sSafer=146.
* d.cep=2、dSafer.cep=10、および d.ceb=1460 の場合、s=730、sSafer=146。
Therefore d.cep is safe enough, because the average size of 10 data segments is unlikely to have been as small as MSS/10.
したがって、10 データ セグメントの平均サイズが MSS/10 ほど小さい可能性は低いため、d.cep は十分に安全です。
* if d.cep=7, dSafer.cep=15, and d.ceb=10200, then s=1457 and sSafer=680.
* d.cep=7、dSafer.cep=15、および d.ceb=10200 の場合、s=1457、sSafer=680。
Therefore d.cep is safe enough, because the average data segment size is more likely to have been just less than one MSS, rather than below MSS/2.
したがって、平均データ セグメント サイズは MSS/2 未満ではなく、1 MSS 未満である可能性が高いため、d.cep は十分に安全です。
If pure ACKs were allowed to be ECN-capable, missing ACKs would be far less likely. However, because [RFC3168] currently precludes this, the above algorithm assumes that pure ACKs are not ECN-capable.
純粋な ACK が ECN 対応であることが許可されていれば、ACK が失われる可能性ははるかに低くなります。しかし、[RFC3168] では現在これを妨げているため、上記のアルゴリズムは純粋な ACK が ECN 対応ではないと想定しています。
If AccECN Options are not available, the Data Sender can only decode the ACE field as a number of marked packets. Every time an ACK arrives, to convert the number of CE markings into an estimate of CE-marked bytes, it needs an average of the segment size, s_ave. Then it can add or subtract s_ave from the value of d.ceb as the value of d.cep increments or decrements. Some possible ways to calculate s_ave are outlined below. The precise details will depend on why an estimate of marked bytes is needed.
AccECN オプションが利用できない場合、データ送信者は ACE フィールドをマークされたパケットの数としてデコードすることしかできません。ACK が到着するたびに、CE マーキングの数を CE マーキングされたバイトの推定値に変換するには、セグメント サイズの平均 s_ave が必要になります。次に、d.cep の値が増減するにつれて、d.ceb の値に s_ave を加算または減算できます。s_ave を計算するために考えられるいくつかの方法を以下に概説します。正確な詳細は、マークされたバイトの推定値が必要な理由によって異なります。
The implementation could keep a record of the byte numbers of all the boundaries between packets in flight (including control packets), and recalculate s_ave on every ACK. However, it would be simpler to merely maintain a counter packets_in_flight for the number of packets in flight (including control packets), which is reset once per RTT. Either way, it would estimate s_ave as:
この実装では、送信中のパケット (制御パケットを含む) 間のすべての境界のバイト数の記録を保持し、ACK ごとに s_ave を再計算できます。ただし、送信中のパケット (制御パケットを含む) の数を表すカウンター packets_in_flight を維持するだけの方が簡単です。これは RTT ごとに 1 回リセットされます。いずれにせよ、s_ave は次のように推定されます。
s_ave ~= flightsize / packets_in_flight,
where flightsize is the variable that TCP already maintains for the number of bytes in flight and '~=' means 'approximately equal to'. To avoid floating point arithmetic, it could right-bit-shift by lg(packets_in_flight), where lg() means log base 2.
ここで、flightsize は TCP がすでに保持している飛行中のバイト数の変数で、「~=」は「ほぼ等しい」を意味します。浮動小数点演算を回避するには、lg(packets_in_flight) によって右ビット シフトすることができます。ここで、lg() は対数 2 を意味します。
An alternative would be to maintain an exponentially weighted moving average (EWMA) of the segment size:
別の方法としては、セグメント サイズの指数加重移動平均 (EWMA) を維持することもできます。
s_ave = a * s + (1-a) * s_ave,
where a is the decay constant for the EWMA. However, then it is necessary to choose a good value for this constant, which ought to depend on the number of packets in flight. Also the decay constant needs to be power of two to avoid floating point arithmetic.
ここで、a は EWMA の減衰定数です。ただし、この定数には適切な値を選択する必要があり、これは送信中のパケット数に依存する必要があります。また、浮動小数点演算を避けるために、減衰定数は 2 のべき乗である必要があります。
A Data Sender in AccECN mode can infer the amount of TCP payload data arriving at the receiver marked Not-ECT from the difference between the amount of newly ACKed data and the sum of the bytes with the other three markings, d.ceb, d.e0b, and d.e1b.
AccECN モードのデータ送信者は、新しく ACK されたデータの量と他の 3 つのマーキング (d.ceb、d.e0b、および d.e1b) のバイトの合計との差から、Not-ECT とマークされた受信者に到着する TCP ペイロード データの量を推測できます。
For this approach to be precise, it has to be assumed that spurious (unnecessary) retransmissions do not lead to double counting. This assumption is currently correct, given that RFC 3168 requires that the Data Sender mark retransmitted segments as Not-ECT. However, the converse is not true; necessary retransmissions will result in undercounting.
このアプローチを正確にするには、偽の (不必要な) 再送信が二重カウントにつながらないことを前提にする必要があります。RFC 3168 では、データ送信者が再送信されたセグメントを Not-ECT としてマークすることが要求されているため、この仮定は現時点では正しいです。ただし、その逆は当てはまりません。必要な再送信では過小カウントが発生します。
However, such precision is unlikely to be necessary. The only known use of a count of Not-ECT marked bytes is to test whether equipment on the path is clearing the ECN field (perhaps due to an outdated attempt to clear, or bleach, what used to be the IPv4 ToS byte or the IPv6 Traffic Class field). To detect bleaching, it will be sufficient to detect whether nearly all bytes arrive marked as Not-ECT. Therefore, there ought to be no need to keep track of the details of retransmissions.
ただし、そのような精度は必要ありません。Not-ECT マーク付きバイト数の既知の唯一の用途は、パス上の機器が ECN フィールドをクリアしているかどうかをテストすることです (おそらく、以前は IPv4 ToS バイトまたは IPv6 トラフィック クラス フィールドであったものをクリアまたはブリーチしようとする時代遅れの試みが原因です)。ブリーチングを検出するには、ほぼすべてのバイトが Not-ECT としてマークされて到着するかどうかを検出するだけで十分です。したがって、再送信の詳細を追跡する必要はありません。
AccECN uses a rather unorthodox approach to negotiate the highest version TCP-ECN feedback scheme that both ends support, as justified below. It follows from the original TCP-ECN capability negotiation [RFC3168], in which the Client set the 2 least significant of the original reserved flags in the TCP header, and fell back to no support for ECN if the Server responded with the 2 flags cleared, which had previously been the default.
AccECN は、以下で正当化されるように、かなり型破りなアプローチを使用して、両端がサポートする最高バージョンの TCP-ECN フィードバック スキームをネゴシエートします。これは、元の TCP-ECN 機能ネゴシエーション [RFC3168] に従っており、クライアントは TCP ヘッダー内の元の予約済みフラグのうち最も重要でない 2 つを設定し、サーバーが 2 つのフラグをクリアして応答した場合、以前はデフォルトであった ECN のサポートなしにフォールバックします。
Classic ECN used header flags rather than a TCP Option because it was considered more efficient to use a header flag for 1 bit of feedback per ACK, and this bit could be overloaded to indicate support for Classic ECN during the handshake. During the development of ECN, 1 bit crept up to 2, in order to deliver the feedback reliably and to work round some broken hosts that reflected the reserved flags during the handshake.
クラシック ECN は、ACK ごとに 1 ビットのフィードバックにヘッダー フラグを使用する方が効率的であると考えられていたため、TCP オプションではなくヘッダー フラグを使用しました。また、このビットは、ハンドシェイク中にクラシック ECN のサポートを示すためにオーバーロードされる可能性がありました。ECN の開発中、フィードバックを確実に配信し、ハンドシェイク中に予約フラグを反映する一部の壊れたホストを回避するために、1 ビットが 2 まで急上昇しました。
In order to be backward compatible with RFC 3168, AccECN continues this approach, using the 3rd least significant TCP header flag that had previously been allocated for the ECN-nonce (now Historic). Then, whatever form of Server an AccECN Client encounters, the connection can fall back to the highest version of feedback protocol that both ends support, as explained in Section 3.1.
RFC 3168 との下位互換性を保つために、AccECN はこのアプローチを継続し、以前に ECN-nonce (現在はヒストリック) に割り当てられていた下から 3 番目の TCP ヘッダー フラグを使用します。その後、セクション 3.1 で説明したように、AccECN クライアントがどのような形式のサーバーに遭遇しても、接続は両端がサポートするフィードバック プロトコルの最高バージョンにフォールバックできます。
If AccECN capability negotiation had used the more orthodox approach of a TCP Option, it would still have had to set the two ECN flags in the main TCP header to be able to fall back to Classic ECN [RFC3168], or to disable ECN support, without another round of negotiation. Then AccECN would also have had to handle all the different ways that Servers currently respond to settings of the ECN flags in the main TCP header, including all of the conflicting cases where a Server might have said it supported one approach in the flags and another approach in a new TCP Option. And AccECN would have had to deal with all of the additional possibilities where a middlebox might have mangled the ECN flags, or removed TCP Options. Thus, usage of the 3rd reserved TCP header flag simplified the protocol.
AccECN 機能ネゴシエーションが TCP オプションのよりオーソドックスなアプローチを使用していた場合、別のネゴシエーションを行わずに、クラシック ECN [RFC3168] にフォールバックできるようにするか、ECN サポートを無効にするために、メイン TCP ヘッダーに 2 つの ECN フラグを設定する必要がありました。その場合、AccECN は、サーバーがフラグで 1 つのアプローチをサポートし、新しい TCP オプションで別のアプローチをサポートしていると述べた可能性があるすべての矛盾するケースを含め、サーバーが現在メイン TCP ヘッダーの ECN フラグの設定に応答するさまざまな方法すべてを処理する必要があります。そして、AccECN は、ミドルボックスが ECN フラグを破壊したり、TCP オプションを削除したりする可能性がある追加の可能性すべてに対処する必要がありました。したがって、3 番目の予約済み TCP ヘッダー フラグを使用することで、プロトコルが簡素化されました。
The third flag was used in a way that could be distinguished from the ECN-nonce, in case any nonce deployment was encountered. Previous usage of this flag for the ECN-nonce was integrated into the original ECN negotiation. This further justified the third flag's use for AccECN, because a non-ECN usage of this flag would have had to use it as a separate single bit, rather than in combination with the other 2 ECN flags.
3 番目のフラグは、nonce デプロイメントが発生した場合に備えて、ECN-nonce と区別できる方法で使用されました。ECN-nonce に対するこのフラグの以前の使用法は、元の ECN ネゴシエーションに統合されました。これにより、3 番目のフラグを AccECN に使用することがさらに正当化されました。これは、このフラグを ECN 以外で使用するには、他の 2 つの ECN フラグと組み合わせてではなく、別個の単一ビットとして使用する必要があったためです。
Indeed, having overloaded the original uses of these three flags for its handshake, AccECN overloads all three bits again as a 3-bit counter.
実際、ハンドシェイクでのこれら 3 つのフラグの本来の使用法をオーバーロードした後、AccECN は 3 ビットすべてを 3 ビット カウンタとして再度オーバーロードします。
Of the eight possible codepoints that the three TCP-ECN header flags can indicate on the SYN/ACK, four already indicated earlier (or broken) versions of ECN support, one now being Historic. In the early design of AccECN, an AccECN Server could use only 2 of the 4 remaining codepoints. They both indicated AccECN support, but one fed back that the SYN had arrived marked as CE. Even though ECN support on a SYN is not yet on the Standards Track, the idea is for either end to act as a mechanistic reflector, so that future capabilities can be unilaterally deployed without requiring 2-ended deployment (justified in Section 2.5).
3 つの TCP-ECN ヘッダー フラグが SYN/ACK で示すことができる 8 つの可能なコードポイントのうち、4 つはすでに ECN サポートの以前の (または壊れた) バージョンを示しており、現在 1 つはヒストリックです。AccECN の初期の設計では、AccECN サーバーは残りの 4 つのコードポイントのうち 2 つだけを使用できました。どちらも AccECN のサポートを示していましたが、1 つは SYN が CE としてマークされて到着したとフィードバックしました。SYN での ECN サポートはまだ標準化トラックに載っていませんが、そのアイデアは、どちらかの端が機構的なリフレクターとして機能することで、将来の機能を 2 端の展開を必要とせずに一方的に展開できるようにすることです (セクション 2.5 で正当化されています)。
During traversal testing, it was discovered that the IP-ECN field in the SYN was mangled on a non-negligible proportion of paths. Therefore, it was necessary to allow the SYN/ACK to feed all four IP-ECN codepoints that the SYN could arrive with back to the Client. Without this, the Client could not know whether to disable ECN for the connection due to mangling of the IP-ECN field (also explained in Section 2.5). This development consumed the remaining two codepoints on the SYN/ACK that had been reserved for future use by AccECN in earlier draft versions of this document.
トラバーサル テスト中に、SYN の IP-ECN フィールドが無視できない割合のパスで破損していることが判明しました。したがって、SYN/ACK が、SYN が到着してクライアントに返送できる 4 つの IP-ECN コードポイントすべてをフィードできるようにする必要がありました。これがないと、クライアントは、IP-ECN フィールドの破損により、接続の ECN を無効にするかどうかを知ることができません (セクション 2.5 で説明されています)。この開発では、この文書の以前のドラフト版で AccECN が将来使用するために予約していた SYN/ACK 上の残り 2 つのコードポイントが消費されました。
Despite availability of usable TCP header space being extremely scarce, the AccECN protocol has taken all possible steps to ensure that there is space to negotiate possible future variants of the protocol, either if a variant of AccECN is required, or if a completely different ECN feedback approach is needed.
使用可能な TCP ヘッダー スペースが非常に不足しているにもかかわらず、AccECN プロトコルは、AccECN のバリアントが必要な場合、または完全に異なる ECN フィードバック アプローチが必要な場合に、プロトコルの将来の可能性のあるバリアントをネゴシエートするためのスペースを確保するためにあらゆる手段を講じています。
Future AccECN variants:
将来の AccECN の亜種:
When the AccECN capability is negotiated during TCP's three-way handshake, the rows in Table 2 tagged as 'Nonce' and 'Broken' in the column for the capability of node B are unused by any current protocol defined in the RFC Series. These could be used by TCP Servers in the future to indicate a variant of the AccECN protocol. In recent measurement studies in which the response of large numbers of Servers to an AccECN SYN has been tested, e.g., [Mandalari18], a very small number of SYN/ ACKs arrive with the pattern tagged as 'Nonce', and a small but more significant number arrive with the pattern tagged as 'Broken'. The 'Nonce' pattern could be a sign that a few Servers have implemented the ECN-nonce [RFC3540], which has now been reclassified as Historic [RFC8311], or it could be the random result of some unknown middlebox behaviour. The greater prevalence of the 'Broken' pattern suggests that some instances still exist of the broken code that reflects the reserved flags on the SYN.
TCP の 3 ウェイ ハンドシェイク中に AccECN 機能がネゴシエートされると、表 2 のノード B の機能の列で「Nonce」および「Broken」とタグ付けされた行は、RFC シリーズで定義されている現在のプロトコルでは使用されません。これらは、将来、TCP サーバーによって AccECN プロトコルのバリアントを示すために使用される可能性があります。AccECN SYN に対する多数のサーバーの応答がテストされた最近の測定研究 ([Mandalari18] など) では、非常に少数の SYN/ACK が「Nonce」としてタグ付けされたパターンで到着し、少数ではあるがより重要な数が「Broken」としてタグ付けされたパターンで到着します。「Nonce」パターンは、いくつかのサーバーが ECN-nonce [RFC3540] (現在はヒストリック [RFC8311] として再分類されています) を実装していることを示す兆候である可能性があります。あるいは、未知のミドルボックスの動作のランダムな結果である可能性があります。「壊れた」パターンの蔓延は、SYN の予約済みフラグを反映する壊れたコードのインスタンスがまだ存在していることを示唆しています。
The requirement not to reject unexpected initial values of the ACE counter (in the main TCP header) in the last paragraph of Section 3.2.2.4 ensures that three unused codepoints on the ACK of the SYN/ACK, six unused values on the first SYN=0 data packet from the Client, and seven unused values on the first SYN=0 data packet from the Server could be used to declare future variants of the AccECN protocol. The word 'declare' is used rather than 'negotiate' because, at this late stage in the three-way handshake, it would be too late for a negotiation between the endpoints to be completed. A similar requirement not to reject unexpected initial values in AccECN TCP Options (Section 3.2.3.2.4) is for the same purpose. If traversal of AccECN TCP Options were reliable, this would have enabled a far wider range of future variation of the whole AccECN protocol. Nonetheless, it could be used to reliably negotiate a wide range of variation in the semantics of the AccECN Option.
セクション 3.2.2.4 の最後の段落にある、(メイン TCP ヘッダー内の) ACE カウンタの予期しない初期値を拒否しないという要件により、SYN/ACK の ACK 上の 3 つの未使用のコードポイント、クライアントからの最初の SYN=0 データ パケット上の 6 つの未使用の値、およびサーバーからの最初の SYN=0 データ パケット上の 7 つの未使用の値が、AccECN プロトコルの将来のバリアントを宣言するために使用できることが保証されます。「ネゴシエート」ではなく「宣言」という言葉が使用されているのは、スリーウェイ ハンドシェイクのこの段階では、エンドポイント間のネゴシエーションを完了するには遅すぎるためです。AccECN TCP オプション (セクション 3.2.3.2.4) の予期しない初期値を拒否しないという同様の要件も、同じ目的です。AccECN TCP オプションのトラバースが信頼できるものであれば、AccECN プロトコル全体の将来のバリエーションをさらに広範囲に拡張できるようになったでしょう。それにもかかわらず、AccECN オプションのセマンティクスの幅広いバリエーションを確実にネゴシエートするために使用できます。
Future non-AccECN variants:
将来の非 AccECN バリアント:
Five codepoints out of the eight possible in the three TCP header flags used by AccECN are unused on the initial SYN (in the order (AE,CWR,ECE)): (0,0,1), (0,1,0), (1,0,0), (1,0,1), (1,1,0). Section 3.1.3 ensures that the installed base of AccECN Servers will all assume these are equivalent to AccECN negotiation with (1,1,1) on the SYN. These codepoints would not allow fall-back to Classic ECN support for a Server that did not understand them, but this approach ensures they are available in the future, perhaps for uses other than ECN alongside the AccECN scheme. All possible combinations of SYN/ACK could be used in response except either (0,0,0) or reflection of the same values sent on the SYN.
AccECN によって使用される 3 つの TCP ヘッダー フラグで可能な 8 つのコードポイントのうち 5 つのコードポイントは、初期 SYN ((AE、CWR、ECE) の順序で) では使用されません: (0,0,1)、(0,1,0)、(1,0,0)、(1,0,1)、(1,1,0)。セクション 3.1.3 は、AccECN サーバーのインストール ベースがすべて、これらが SYN 上の (1,1,1) との AccECN ネゴシエーションと同等であると想定することを保証します。これらのコードポイントは、コードポイントを理解できないサーバーに対してクラシック ECN サポートへのフォールバックを許可しませんが、このアプローチにより、おそらく AccECN スキームと並行して ECN 以外の用途でも将来的に利用できることが保証されます。(0,0,0) または SYN で送信された同じ値の反映を除いて、SYN/ACK の考えられるすべての組み合わせを応答に使用できます。
In order to extend AccECN or ECN in the future, other ways could be resorted to, although their traversal properties are likely to be inferior. They include a new TCP Option; using the remaining reserved flags in the main TCP header (preferably extending the 3-bit combinations used by AccECN to 4-bit combinations, rather than burning one bit for just one state); a non-zero urgent pointer in combination with the URG flag cleared; or some other unexpected combination of fields yet to be invented.
将来 AccECN または ECN を拡張するには、トラバース特性が劣る可能性がありますが、他の方法に頼る可能性があります。これらには、新しい TCP オプションが含まれています。メイン TCP ヘッダー内の残りの予約済みフラグを使用します (1 つの状態に対して 1 ビットを書き込むのではなく、AccECN で使用される 3 ビットの組み合わせを 4 ビットの組み合わせに拡張することが望ましい)。ゼロ以外の緊急ポインタと URG フラグの組み合わせがクリアされる。または、まだ発明されていない分野の他の予期しない組み合わせ。
We want to thank Koen De Schepper, Praveen Balasubramanian, Michael Welzl, Gorry Fairhurst, David Black, Spencer Dawkins, Michael Scharf, Michael Tüxen, Yuchung Cheng, Kenjiro Cho, Olivier Tilmans, Ilpo Järvinen, Neal Cardwell, Yoshifumi Nishida, Martin Duke, Jonathan Morton, Vidhi Goel, Alex Burr, Markku Kojo, Grenville Armitage and Wes Eddy for their input and discussion. The idea of using the three ECN-related TCP flags as one field for more accurate TCP-ECN feedback was first introduced in the re-ECN protocol that was the ancestor of ConEx.
Koen De Schepper、Praveen Balasubramanian、Michael Welzl、Gorry Fairhurst、David Black、Spencer Dawkins、Michael Scharf、Michael Tüxen、Yuchung Cheng、Kenjiro Cho、Olivier Tilmans、Ilpo Järvinen、Neal Cardwell、西田佳史、Martin Duke、Jonathan Morton、Vidhi Goel、Alex Burr、Markku に感謝します。Kojo、Grenville Armitage、Wes Eddy の意見とディスカッションに感謝します。より正確な TCP-ECN フィードバックのために 3 つの ECN 関連 TCP フラグを 1 つのフィールドとして使用するというアイデアは、ConEx の前身である re-ECN プロトコルで初めて導入されました。
The following contributed implementations of AccECN that validated and helped to improve this specification:
以下は、この仕様を検証し、改善するのに役立つ AccECN の実装に貢献しました。
Linux:
Linux:
Mirja Kühlewind, Ilpo Järvinen, Neal Cardwell, and Chia-Yu Chang
ミルヤ・キューレヴィント、イルポ・ヤルヴィネン、ニール・カードウェル、チアユー・チャン
FreeBSD:
FreeBSD:
Richard Scheffenegger
リチャード・シェフェネッガー
Apple OSs:
Apple OS:
Vidhi Goel
ヴィディ・ゴエル
Bob Briscoe was part-funded by Apple Inc, the Comcast Innovation Fund, 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), and the Research Council of Norway through the TimeIn project. The views expressed here are solely those of the authors.
Bob Briscoe は、Apple Inc、Comcast Innovation Fund、インターネット トランスポート遅延の削減 (RITE) プロジェクト (ICT-317700) および Trilogy 2 プロジェクト (ICT-317756) を通じて第 7 フレームワーク プログラムに基づく欧州共同体、および TimeIn プロジェクトを通じてノルウェー研究評議会から一部資金提供を受けました。ここで表明されている見解は、単に著者の見解です。
Mirja Kühlewind was partly supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and Innovation under contract no. 15.0268. This support does not imply endorsement.
Mirja Kühlewind は、Horizon 2020 助成契約第 2 号に基づき、欧州委員会から部分的に支援を受けました。688421 ミドルボックス インターネットの測定とアーキテクチャ (MAMI)、および契約番号 688421 に基づくスイス州教育研究イノベーション事務局による。15.0268。このサポートは承認を意味するものではありません。
Bob Briscoe
Independent
United Kingdom
Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/
Mirja Kühlewind
Ericsson
Germany
Email: ietf@kuehlewind.net
Richard Scheffenegger
NetApp
Vienna
Austria
Email: Richard.Scheffenegger@netapp.com