[要約] 要約：RFC 8087は、明示的な輻輳通知（ECN）の利点について説明しており、ネットワークのパフォーマンスと信頼性の向上を目指しています。目的：ECNの利点を明確に示し、ネットワークの輻輳制御におけるECNの有用性を広めることを目指しています。
Internet Engineering Task Force (IETF) G. Fairhurst
Request for Comments: 8087 University of Aberdeen
Category: Informational M. Welzl
ISSN: 2070-1721 University of Oslo
March 2017
The Benefits of Using Explicit Congestion Notification (ECN)
明示的な輻輳通知（ECN）を使用する利点
Abstract
概要
The goal of this document is to describe the potential benefits of applications using a transport that enables Explicit Congestion Notification (ECN). The document outlines the principal gains in terms of increased throughput, reduced delay, and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms to use ECN nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers, or other network devices.
このドキュメントの目的は、明示的輻輳通知（ECN）を有効にするトランスポートを使用するアプリケーションの潜在的な利点を説明することです。このドキュメントでは、輻輳経験（CE）マーキングをサポートする機器を含むネットワークパスでECNを使用した場合のスループットの向上、遅延の削減、およびその他の利点に関する主な利点について概説しています。また、ECNの展開を成功させるための課題についても説明します。 ECNを使用するための新しいアルゴリズムは提案されておらず、エンドポイントデバイス（インターネットホスト）、ルーター、またはその他のネットワークデバイスでのECNの実装の詳細についても説明されていません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8087.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8087で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Benefit of Using ECN to Avoid Congestion Loss . . . . . . . . 5
2.1. Improved Throughput . . . . . . . . . . . . . . . . . . . 5
2.2. Reduced Head-of-Line Blocking . . . . . . . . . . . . . . 6
2.3. Reduced Probability of RTO Expiry . . . . . . . . . . . . 6
2.4. Applications That Do Not Retransmit Lost Packets . . . . 7
2.5. Making Incipient Congestion Visible . . . . . . . . . . . 8
2.6. Opportunities for New Transport Mechanisms . . . . . . . 8
3. Network Support for ECN . . . . . . . . . . . . . . . . . . . 9
3.1. The ECN Field . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Forwarding ECN-Capable IP Packets . . . . . . . . . . . . 10
3.3. Enabling ECN in Network Devices . . . . . . . . . . . . . 11
3.4. Coexistence of ECN and Non-ECN Flows . . . . . . . . . . 11
3.5. Bleaching and Middlebox Requirements to Deploy ECN . . . 11
3.6. Tunneling ECN and the Use of ECN by Lower-Layer Networks 12
4. Using ECN across the Internet . . . . . . . . . . . . . . . . 12
4.1. Partial Deployment . . . . . . . . . . . . . . . . . . . 13
4.2. Detecting Whether a Path Really Supports ECN . . . . . . 13
4.3. Detecting ECN-Receiver Feedback Cheating . . . . . . . . 14
5. Summary: Enabling ECN in Network Devices and Hosts . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Internet transports (such as TCP and Stream Control Transmission Protocol (SCTP)) are implemented in endpoints (Internet hosts) and are designed to detect and react to network congestion. Congestion may be detected by loss of an IP packet or, if Explicit Congestion Notification (ECN) [RFC3168] is enabled, by the reception of a packet with a Congestion Experienced (CE) marking in the IP header. Both of these are treated by transports as indications of congestion. ECN may also be enabled by other transports: UDP applications that provide congestion control may enable ECN when they are able to correctly process the ECN signals [RFC8085] (e.g., ECN with RTP [RFC6679]).
インターネットトランスポート（TCPやストリーム制御伝送プロトコル（SCTP）など）は、エンドポイント（インターネットホスト）に実装され、ネットワークの輻輳を検出して対応するように設計されています。輻輳は、IPパケットの損失によって、または明示的輻輳通知（ECN）[RFC3168]が有効になっている場合は、IPヘッダーにCongestion Experienced（CE）マーキングが付いたパケットの受信によって検出されます。これらは両方とも、交通機関によって混雑の兆候として扱われます。 ECNは他のトランスポートでも有効にできます。輻輳制御を提供するUDPアプリケーションは、ECN信号[RFC8085]（例：RTP付きECN [RFC6679]）を正しく処理できる場合、ECNを有効にすることができます。
Active Queue Management (AQM) [RFC7567] is a class of techniques that can be used by network devices (a router, middlebox, or other device that forwards packets through the network) to manage the size of queues in network buffers.
Active Queue Management（AQM）[RFC7567]は、ネットワークデバイス（ルーター、ミドルボックス、またはネットワークを介してパケットを転送する他のデバイス）がネットワークバッファー内のキューのサイズを管理するために使用できる手法のクラスです。
A network device that does not support AQM typically uses a drop-tail policy to drop excess IP packets when its queue becomes full. The discard of packets is treated by transport protocols as a signal that indicates congestion on the end-to-end network path. End-to-end transports, such as TCP, can cause a low level of loss while seeking to share capacity with other flows. Although losses are not always due to congestion (loss may be due to link corruption, receiver overrun, etc.), endpoints have to conservatively presume that all loss is potentially due to congestion and reduce their rate. Observed loss therefore results in a congestion control reaction by the transport to reduce the maximum rate permitted by the sending endpoint.
AQMをサポートしていないネットワークデバイスは、通常、キューがいっぱいになると、ドロップテールポリシーを使用して過剰なIPパケットをドロップします。パケットの廃棄は、トランスポートプロトコルによって、エンドツーエンドのネットワークパスの輻輳を示す信号として扱われます。 TCPなどのエンドツーエンドのトランスポートは、他のフローと容量を共有しようとしているときに、低レベルの損失を引き起こす可能性があります。損失は常に輻輳が原因ではない（損失はリンクの破損、レシーバーのオーバーランなどが原因である可能性がある）が、エンドポイントはすべての損失が輻輳が原因である可能性があると控えめに推定し、レートを下げる必要があります。したがって、観測された損失により、トランスポートによる輻輳制御反応が発生し、送信側エンドポイントで許可されている最大レートが低下します。
ECN makes it possible for the network to signal the presence of incipient congestion without incurring packet loss; it lets the network deliver some packets to an application that would otherwise have been dropped if the application or transport did not support ECN. This packet-loss reduction is the most obvious benefit of ECN, but it is often relatively modest. However, enabling ECN can also result in a number of beneficial side effects, some of which may be much more significant than the immediate packet-loss reduction from receiving a CE marking instead of dropping packets. Several benefits reduce latency (e.g., reduced head-of-line blocking).
ECNにより、ネットワークは、パケット損失を発生させることなく、初期の輻輳の存在を通知できます。これにより、アプリケーションまたはトランスポートがECNをサポートしていなかった場合にドロップされるパケットを、ネットワークがアプリケーションに配信できるようになります。このパケット損失の削減は、ECNの最も明白な利点ですが、多くの場合比較的控えめです。ただし、ECNを有効にすると、多くの有益な副作用が発生する可能性があり、そのいくつかは、パケットをドロップする代わりにCEマーキングを受信することによる即時のパケット損失の削減よりもはるかに重要になる場合があります。いくつかの利点により、待ち時間が短縮されます（例えば、行頭ブロッキングの削減）。
The use of ECN is indicated in the ECN field [RFC3168], which is carried in the packet header of all IPv4 and IPv6 packets. This field may be set to one of the four values shown in Figure 1. The Not-ECT codepoint '00' indicates a packet that is not using ECN. The ECT(0) codepoint '01' and the ECT(1) codepoint '10' both indicate that the transport protocol using the IP layer supports the use of ECN. The CE codepoint '11' is set by an ECN-capable network device to indicate congestion to the transport endpoint.
ECNの使用は、すべてのIPv4およびIPv6パケットのパケットヘッダーで伝送されるECNフィールド[RFC3168]で示されます。このフィールドは、図1に示す4つの値のいずれかに設定できます。Not-ECTコードポイント「00」は、ECNを使用していないパケットを示します。 ECT（0）コードポイント '01'とECT（1）コードポイント '10'はどちらも、IP層を使用するトランスポートプロトコルがECNの使用をサポートしていることを示しています。 CEコードポイント「11」は、ECN対応のネットワークデバイスによって設定され、トランスポートエンドポイントへの輻輳を示します。
+-----+-----+---------+
| ECN FIELD | Name |
+-----+-----+---------+
| 0 | 0 | Not-ECT |
| 0 | 1 | ECT(1) |
| 1 | 0 | ECT(0) |
| 1 | 1 | CE |
+-----+-----+---------+
Figure 1: The ECN Field in the IP Packet Header (based on [RFC3168])
図1：IPパケットヘッダーのECNフィールド（[RFC3168]に基づく）
When an application uses a transport that enables use of ECN [RFC3168], the transport layer sets the ECT(0) or ECT(1) codepoint in the IP header of packets that it sends. This indicates to network devices that they may mark, rather than drop, the ECN-capable IP packets. An ECN-capable network device can then signal incipient congestion (network queuing) at a point before a transport experiences congestion loss or high queuing delay. The marking is generally performed as the result of various AQM algorithms [RFC7567] where the exact combination of AQM/ECN algorithms does not need to be known by the transport endpoints.
アプリケーションがECN [RFC3168]の使用を可能にするトランスポートを使用する場合、トランスポート層は、送信するパケットのIPヘッダーにECT（0）またはECT（1）コードポイントを設定します。これは、ネットワークデバイスに、ECN対応IPパケットをドロップするのではなく、マークする可能性があることを示します。その後、ECN対応のネットワークデバイスは、トランスポートで輻輳損失または大きなキューイング遅延が発生する前の時点で、初期輻輳（ネットワークキューイング）を通知できます。マーキングは通常、さまざまなAQMアルゴリズム[RFC7567]の結果として実行されます。AQM/ ECNアルゴリズムの正確な組み合わせをトランスポートエンドポイントが認識する必要はありません。
The focus of the document is on usage of ECN by transport- and application-layer flows, not its implementation in endpoint hosts, routers, and other network devices.
このドキュメントの焦点は、トランスポート層およびアプリケーション層のフローによるECNの使用であり、エンドポイントホスト、ルーター、およびその他のネットワークデバイスでの実装ではありません。
The following terms are used:
次の用語が使用されます。
AQM: Active Queue Management.
AQM：アクティブキュー管理。
CE: Congestion Experienced; a codepoint value '11' marked in the ECN field of the IP packet header.
CE：混雑が発生。 IPパケットヘッダーのECNフィールドにマークされたコードポイント値 '11'。
ECN-capable IP Packet: A packet where the ECN field is set to a non-zero ECN value (i.e., with ECT(0), ECT(1), or the CE codepoint).
ECN対応IPパケット：ECNフィールドがゼロ以外のECN値に設定されているパケット（つまり、ECT（0）、ECT（1）、またはCEコードポイントを使用）。
ECN-capable network device: An ECN-capable network device may forward, drop, or queue an ECN-capable packet and may choose to CE mark this packet when there is incipient congestion.
ECN対応ネットワークデバイス：ECN対応ネットワークデバイスは、ECN対応パケットを転送、ドロップ、またはキューイングし、混雑が発生したときにこのパケットにCEマークを付けることを選択できます。
ECN-capable transport/application: A transport that sends ECN-capable IP Packets, monitors reception of the ECN field, and generates appropriate feedback to control the rate of the sending endpoint to provide end-to-end congestion control.
ECN対応のトランスポート/アプリケーション：ECN対応のIPパケットを送信し、ECNフィールドの受信を監視し、適切なフィードバックを生成して送信エンドポイントのレートを制御し、エンドツーエンドの輻輳制御を提供するトランスポート。
ECN field: A 2-bit field specified for use with explicit congestion signaling in the IPv4 and IPv6 packet headers.
ECNフィールド：IPv4およびIPv6パケットヘッダーの明示的な輻輳シグナリングで使用するために指定された2ビットのフィールド。
Endpoint: An Internet host that terminates a transport protocol connection across an Internet path.
エンドポイント：インターネットパスを介したトランスポートプロトコル接続を終了するインターネットホスト。
Incipient Congestion: The detection of congestion when it is starting, perhaps by a network device noting that the arrival rate exceeds the forwarding rate.
Incipient Congestion：到着率が転送率を超えていることを通知するネットワークデバイスによる、開始時の輻輳の検出。
Network device: A router, middlebox, or other device that forwards IP packets through the network.
ネットワークデバイス：IPパケットをネットワーク経由で転送するルーター、ミドルボックス、またはその他のデバイス。
non-ECN-capable: A network device or endpoint that does not interpret the ECN field. Such a device is not permitted to change the ECN codepoint.
非ECN対応：ECNフィールドを解釈しないネットワークデバイスまたはエンドポイント。このようなデバイスは、ECNコードポイントを変更することはできません。
not-ECN-capable IP Packet: An IP packet with the ECN field set to a value of zero ('00'). A not-ECN-capable packet may be forwarded, dropped, or queued by a network device.
not-ECN-capable IP Packet：ECNフィールドがゼロ（ '00'）の値に設定されたIPパケット。非ECN対応のパケットは、ネットワークデバイスによって転送、ドロップ、またはキューイングされる場合があります。
An ECN-capable network device is expected to CE mark an ECN-capable IP packet as a CE when an AQM method detects incipient congestion rather than drop the packet [RFC7567]. An application can benefit from this marking in several ways, which are detailed in the rest of this section.
AQMメソッドがパケットをドロップするのではなく初期輻輳を検出すると、ECN対応ネットワークデバイスは、ECN対応IPパケットをCEとしてCEマークすることが期待されます[RFC7567]。アプリケーションは、このマーキングのメリットをいくつかの方法で享受できます。詳細については、このセクションの残りの部分で説明します。
ECN seeks to avoid the inefficiency of dropping data that has already made it across at least part of the network path.
ECNは、ネットワークパスの少なくとも一部で既に作成されているデータをドロップする非効率を回避しようとします。
ECN can improve the throughput of an application, although this increase in throughput is often not the most significant gain. When an application uses a lightly to moderately loaded network path, the number of packets that are dropped due to congestion is small. Using an example from Table 1 of [RFC3649], for a standard TCP sender with an RTT of 0.1 seconds, a packet size of 1500 bytes, and an average throughput of 1 Mbps, the average packet-drop ratio would be 0.02 (i.e., 1 in 50 packets). This translates into an approximate 2% throughput gain if ECN is enabled. (Note that in heavy congestion, packet loss may be unavoidable with or without ECN.)
ECNは、アプリケーションのスループットを向上させることができますが、このスループットの増加は、多くの場合、最も重要な利点ではありません。アプリケーションが軽度から中程度の負荷のネットワークパスを使用する場合、輻輳が原因でドロップされるパケットの数は少なくなります。 [RFC3649]の表1の例を使用すると、RTTが0.1秒、パケットサイズが1500バイト、平均スループットが1 Mbpsの標準TCP送信者の場合、平均パケットドロップ率は0.02（つまり、 50パケットに1つ）。これは、ECNが有効になっている場合、約2％のスループット向上につながります。 （重い輻輳では、ECNの有無にかかわらず、パケット損失が避けられない場合があることに注意してください。）
Many Internet transports provide in-order delivery of received data segments to the applications they support. For these applications, use of ECN can reduce the delay that can result when these applications experience packet loss.
多くのインターネットトランスポートは、サポートするアプリケーションに受信したデータセグメントを順番に配信します。これらのアプリケーションの場合、ECNを使用すると、これらのアプリケーションでパケット損失が発生したときに発生する可能性がある遅延を減らすことができます。
Packet loss may occur for various reasons. One cause arises when an AQM scheme drops a packet as a signal of incipient congestion. Whatever the cause of loss, a missing packet needs to trigger a congestion control response. A reliable transport also triggers retransmission to recover the lost data. For a transport providing in-order delivery, this requires that the transport receiver stall (or wait) for all data that was sent ahead of a lost segment to be correctly received before it can forward any later data to the application. A loss therefore creates a delay of at least one RTT after a loss event before data can be delivered to an application. We call this head-of-line blocking. This is the usual requirement for TCP and SCTP. Partially Reliable SCTP (PR-SCTP) [RFC3758], UDP [RFC768] [RFC8085], and the Datagram Congestion Control Protocol (DCCP) [RFC4340] provide a transport that does not provide reordering.
パケット損失はさまざまな理由で発生する可能性があります。 AQMスキームが初期の輻輳の信号としてパケットをドロップすると、1つの原因が発生します。損失の原因が何であれ、欠落したパケットは輻輳制御応答をトリガーする必要があります。信頼性の高いトランスポートは、失われたデータを回復するための再送信もトリガーします。順序どおりの配信を提供するトランスポートでは、失われたセグメントの前に送信されたすべてのデータが正しく受信されるのをトランスポートレシーバーがストール（または待機）してから、後のデータをアプリケーションに転送する必要があります。したがって、損失は、損失イベントの後、データがアプリケーションに配信される前に、少なくとも1つのRTTの遅延を引き起こします。これを行頭ブロッキングと呼びます。これは、TCPおよびSCTPの通常の要件です。部分的に信頼できるSCTP（PR-SCTP）[RFC3758]、UDP [RFC768] [RFC8085]、およびデータグラム輻輳制御プロトコル（DCCP）[RFC4340]は、並べ替えを提供しないトランスポートを提供します。
By enabling ECN, a transport continues to receive in-order data when there is incipient congestion and can pass this data to the receiving application. Use of ECN avoids the additional reordering delay in a reliable transport. The sender still needs to make an appropriate congestion response to reduce the maximum transmission rate for future traffic, which usually will require a reduction in the sending rate [RFC8085].
ECNを有効にすることで、トランスポートは、初期の輻輳が発生したときに引き続き順序どおりのデータを受信し、このデータを受信側アプリケーションに渡すことができます。 ECNを使用すると、信頼性の高いトランスポートでの追加の並べ替え遅延が回避されます。送信者は、将来のトラフィックの最大伝送速度を下げるために適切な輻輳応答を行う必要があります。これには通常、送信速度の低減が必要です[RFC8085]。
Some patterns of packet loss can result in a Retransmission Timeout (RTO), which causes a sudden and significant change in the allowed rate at which a transport/application can forward packets. Because ECN provides an alternative to drop for network devices to signal incipient congestion, this can reduce the probability of loss and hence reduce the likelihood of RTO expiry.
パケット損失のパターンによっては、再送信タイムアウト（RTO）が発生する可能性があり、これにより、トランスポート/アプリケーションがパケットを転送できる許容レートが突然大きく変化します。 ECNはネットワークデバイスがドロップの代わりに初期の輻輳を通知するための代替手段を提供するため、これにより損失の可能性が減り、RTOの期限切れの可能性が減ります。
Internet transports/applications generally use an RTO timer as a last resort to detect and recover loss [RFC8085] [RFC5681]. Specifically, an RTO timer detects loss of a packet that is not followed by other packets, such as at the end of a burst of data segments or when an application becomes idle (either because the application has no further data to send or the network prevents sending further data, e.g., flow or congestion control at the transport layer). This loss of the last segment (or last few segments) of a traffic burst is also known as a "tail loss". Standard transport recovery methods, such as Fast Recovery [RFC5681], are often unable to recover from a tail loss. This is because the endpoint receiver is unaware that the lost segments were actually sent and therefore generates no feedback [Fla13]. Retransmission of these segments relies on expiry of a transport retransmission timer. This timer is also used to detect a lack of forwarding along a path. Expiry of the RTO results in the consequent loss of state about the network path being used. This typically includes resetting path estimates such as the RTT, reinitializing the congestion window, and possibly making updates to other transport state. This can reduce the performance of the transport until it again adapts to the path.
インターネットトランスポート/アプリケーションは、通常、損失を検出して回復するための最後の手段としてRTOタイマーを使用します[RFC8085] [RFC5681]。具体的には、RTOタイマーは、データセグメントのバーストの終わりや、アプリケーションがアイドル状態になったときなど、他のパケットが続かないパケットの損失を検出します（アプリケーションに送信するデータがないか、ネットワークがネットワークを妨げているため）トランスポート層でのフローや輻輳制御などのさらなるデータの送信）。トラフィックバーストの最後のセグメント（または最後のいくつかのセグメント）のこの損失は、「テールロス」とも呼ばれます。 Fast Recovery [RFC5681]などの標準のトランスポート回復方法では、テールロスから回復できないことがよくあります。これは、失われたセグメントが実際に送信されたことをエンドポイントレシーバーが認識していないため、フィードバックが生成されないためです[Fla13]。これらのセグメントの再送信は、トランスポート再送信タイマーの有効期限に依存しています。このタイマーは、パスに沿った転送の欠如を検出するためにも使用されます。 RTOが期限切れになると、使用されているネットワークパスに関する状態が失われます。これには通常、RTTなどのパス推定値のリセット、輻輳ウィンドウの再初期化、場合によっては他のトランスポート状態の更新が含まれます。これにより、トランスポートが再びパスに適応するまで、トランスポートのパフォーマンスが低下する可能性があります。
An ECN-capable network device cannot eliminate the possibility of tail loss because a drop may occur due to a traffic burst exceeding the instantaneous available capacity of a network buffer or as a result of the AQM algorithm (e.g., overload protection mechanisms [RFC7567]). However, an ECN-capable network device that observes incipient congestion may be expected to buffer the IP packets of an ECN-capable flow and set a CE mark in one or more packet(s) rather than triggering packet drop. Setting a CE mark signals incipient congestion without forcing the transport/application to enter retransmission timeout. This reduces application-level latency and can improve the throughput for applications that send intermittent bursts of data.
トラフィックバーストがネットワークバッファーの瞬間的な利用可能容量を超えたため、またはAQMアルゴリズムの結果（たとえば、過負荷保護メカニズム[RFC7567]）が原因でドロップが発生する可能性があるため、ECN対応ネットワークデバイスはテールロスの可能性を排除できません。 。ただし、初期の輻輳を観察するECN対応ネットワークデバイスは、ECN対応フローのIPパケットをバッファリングし、パケットドロップをトリガーするのではなく、1つ以上のパケットにCEマークを設定することが期待されます。 CEマークを設定すると、トランスポート/アプリケーションに再送信タイムアウトを強制することなく、初期の輻輳を通知します。これにより、アプリケーションレベルのレイテンシが削減され、断続的なデータバーストを送信するアプリケーションのスループットが向上します。
The benefit of avoiding retransmission loss is expected to be significant when ECN is used on TCP SYN/ACK packets [RFC5562] where the RTO interval may be large because TCP cannot base the timeout period on prior RTT measurements from the same connection.
TCPが同じ接続からの以前のRTT測定にタイムアウト期間を基にできないため、RTO間隔が大きくなる可能性があるTCP SYN / ACKパケット[RFC5562]でECNが使用される場合、再送損失を回避することの利点は重要であると予想されます。
A transport that enables ECN can receive timely congestion signals without the need to retransmit packets each time it receives a congestion signal.
ECNを有効にするトランスポートは、輻輳信号を受信するたびにパケットを再送信する必要なく、タイムリーな輻輳信号を受信できます。
Some latency-critical applications do not retransmit lost packets, yet they may be able to adjust their sending rate following detection of incipient congestion. Examples of such applications include UDP-based services that carry Voice over IP (VoIP), interactive video, or real-time data. The performance of many such applications degrades rapidly with increasing packet loss, and the transport/application may therefore employ mechanisms (e.g., packet forward error correction, data duplication, or media codec error concealment) to mitigate the immediate effect of congestion loss on the application. Some mechanisms consume additional network capacity, some require additional processing, and some contribute additional path latency when congestion is experienced. By decoupling congestion control from loss, ECN can allow transports that support these applications to reduce their rate before the application experiences loss from congestion. This can reduce the negative impact of triggering loss-hiding mechanisms with a direct positive impact on the quality experienced by the users of these applications.
一部の遅延が重要なアプリケーションは、失われたパケットを再送信しませんが、初期の輻輳の検出に続いて送信レートを調整できる場合があります。このようなアプリケーションの例には、Voice over IP（VoIP）、インタラクティブビデオ、またはリアルタイムデータを伝送するUDPベースのサービスが含まれます。多くのそのようなアプリケーションのパフォーマンスは、パケット損失の増加に伴って急速に低下します。したがって、トランスポート/アプリケーションはメカニズム（たとえば、パケット転送エラー訂正、データ複製、またはメディアコーデックエラー隠蔽）を使用して、アプリケーションに対する輻輳損失の即時の影響を軽減できます。 。一部のメカニズムは追加のネットワーク容量を消費し、いくつかは追加の処理を必要とし、いくつかは輻輳が発生したときに追加のパス遅延を引き起こします。輻輳制御を損失から切り離すことにより、ECNは、アプリケーションが輻輳による損失を経験する前に、これらのアプリケーションをサポートするトランスポートがレートを下げることを許可できます。これにより、これらのアプリケーションのユーザーが体験する品質に直接プラスの影響を与えることで、損失を隠すメカニズムをトリガーすることのマイナスの影響を減らすことができます。
A characteristic of using ECN is that it exposes the presence of congestion on a network path to the transport and network layers, thus allowing information to be collected about the presence of incipient congestion.
ECNを使用する特徴は、ネットワークパス上の輻輳の存在をトランスポート層とネットワーク層に公開することです。これにより、初期の輻輳の存在に関する情報を収集できます。
Recording the presence of CE-marked packets can provide information about the current congestion level experienced on a network path. A network flow that only experiences CE marking and no loss implies that the sending endpoint is experiencing only congestion. A network flow may also experience loss (e.g., due to queue overflow, AQM methods that protect other flows, link corruption, or loss in middleboxes). When a mixture of CE marking and packet loss is experienced, transports and measurements need to assume there is congestion [RFC7567]. Therefore, an absence of CE marks does not indicate a path has not experienced congestion.
CEマークの付いたパケットの存在を記録すると、ネットワークパスで発生している現在の輻輳レベルに関する情報が得られます。 CEマーキングのみが発生し、損失がないネットワークフローは、送信側エンドポイントで輻輳のみが発生していることを意味します。ネットワークフローでも損失が発生する可能性があります（キューのオーバーフロー、他のフローを保護するAQMメソッド、リンクの破損、ミドルボックスの損失など）。 CEマーキングとパケット損失の混合が発生した場合、トランスポートと測定は輻輳があると想定する必要があります[RFC7567]。したがって、CEマークがない場合でも、パスで輻輳が発生していないことを示しているわけではありません。
The reception of CE-marked packets can be used to monitor the level of congestion by a transport/application or a network operator. For example, ECN measurements are used by Congestion Exposure (ConEx) [RFC6789]. In contrast, metering packet loss is harder.
CEマークの付いたパケットの受信を使用して、トランスポート/アプリケーションまたはネットワークオペレーターによる輻輳レベルを監視できます。たとえば、ECN測定はCongestion Exposure（ConEx）[RFC6789]によって使用されます。対照的に、パケット損失の測定は困難です。
ECN can enable design and deployment of new algorithms in network devices and Internet transports. Internet transports need to regard both loss and CE marking as an indication of congestion. However, while the amount of feedback provided by drop ought naturally be minimized, this is not the case for ECN. In contrast, an ECN-capable network device could provide richer (more frequent and fine-grained) indication of its congestion state to the transport.
ECNは、ネットワークデバイスとインターネットトランスポートでの新しいアルゴリズムの設計と展開を可能にします。インターネットトランスポートでは、損失とCEマーキングの両方を輻輳の兆候と見なす必要があります。ただし、ドロップによって提供されるフィードバックの量は当然最小化する必要がありますが、ECNの場合はそうではありません。対照的に、ECN対応のネットワークデバイスは、その輻輳状態をより詳細な（より頻繁で細かい）表示をトランスポートに提供できます。
For any ECN-capable transport (ECT), the receiving endpoint needs to provide feedback to the transport sender to indicate that CE marks have been received. [RFC3168] provides one method that signals once each round-trip time (RTT) that CE-marked packets have been received.
ECN対応のトランスポート（ECT）の場合、受信エンドポイントは、CEマークが受信されたことを示すフィードバックをトランスポート送信者に提供する必要があります。 [RFC3168]は、CEマークの付いたパケットが受信されたことをラウンドトリップ時間（RTT）ごとに一度通知する1つの方法を提供します。
A receiving endpoint may provide more detailed feedback to the congestion controller at the sender (e.g., describing the set of received ECN codepoints or indicating each received CE-marked packet). Precise feedback about the number of CE marks encountered is supported by RTP when used over UDP [RFC6679] and has been proposed for SCTP [ST14] and TCP [ECN-FEEDBACK].
受信側エンドポイントは、送信側の輻輳コントローラーにさらに詳細なフィードバックを提供する場合があります（たとえば、受信したECNコードポイントのセットを記述するか、受信したCEマーク付きの各パケットを示します）。遭遇したCEマークの数に関する正確なフィードバックは、UDPを介して使用される場合にRTPによってサポートされ[RFC6679]、SCTP [ST14]およびTCP [ECN-FEEDBACK]に提案されています。
More detailed feedback is expected to enable evolution of transport protocols allowing the congestion control mechanism to make a more appropriate decision on how to react to congestion. Designers of transport protocols need to consider not only how network devices CE-mark packets but also how the control loop in the application/ transport reacts to reception of these CE-marked packets.
より詳細なフィードバックにより、トランスポートプロトコルの進化が可能になり、輻輳制御メカニズムが輻輳への対応方法についてより適切な決定を行えるようになります。トランスポートプロトコルの設計者は、ネットワークデバイスがパケットにCEマークを付ける方法だけでなく、アプリケーション/トランスポートの制御ループがこれらのCEマーク付きパケットの受信にどのように反応するかも考慮する必要があります。
Benefit has been noted when packets are CE marked early using an instantaneous queue, and if the receiving endpoint provides feedback about the number of packet marks encountered, an improved sender behavior has been shown to be possible, e.g, Data Center TCP (DCTCP) [AL10]. DCTCP is targeted at controlled environments such as a data center. This is a work in progress, and it is currently unknown whether or how such behavior could be safely introduced into the Internet. Any update to an Internet transport protocol requires careful consideration of the robustness of the behavior when working with endpoints or network devices that were not designed for the new congestion reaction.
瞬間的なキューを使用してパケットに早期にCEマークが付けられ、受信エンドポイントが遭遇したパケットマークの数についてフィードバックを提供する場合、データセンターTCP（DCTCP）などの改善された送信者動作が可能であることが示されています。 AL10]。 DCTCPは、データセンターなどの制御された環境を対象としています。これは進行中の作業であり、現在、そのような動作がインターネットに安全に導入されるかどうか、またはどのように行われるかは不明です。インターネットトランスポートプロトコルを更新する場合は、新しい輻輳反応用に設計されていないエンドポイントまたはネットワークデバイスを操作するときの動作の堅牢性を慎重に検討する必要があります。
For an application to use ECN requires that the endpoints enable ECN within the transport being used. It also requires that all network devices along the path at least forward IP packets that set a non-zero ECN codepoint.
アプリケーションでECNを使用するには、エンドポイントが使用中のトランスポート内でECNを有効にする必要があります。また、パス上のすべてのネットワークデバイスが、ゼロ以外のECNコードポイントを設定するIPパケットを少なくとも転送する必要もあります。
ECN can be deployed both in the general Internet and in controlled environments:
ECNは、一般的なインターネットと制御された環境の両方に展開できます。
o ECN can be incrementally deployed in the general Internet. The IETF has provided guidance on configuration and usage in [RFC7567].
o ECNは、一般的なインターネットに段階的に導入できます。 IETFは、[RFC7567]で構成と使用法に関するガイダンスを提供しています。
o ECN may be deployed within a controlled environment, for example, within a data center or within a well-managed private network. This use of ECN may be tuned to the specific use case. An example is DCTCP [AL10] [DCTCP].
o ECNは、制御された環境内、たとえばデータセンター内、または適切に管理されたプライベートネットワーク内に展開できます。このECNの使用は、特定の使用事例に合わせて調整できます。たとえば、DCTCP [AL10] [DCTCP]です。
Early experience of using ECN across the general Internet encountered a number of operational difficulties when the network path either failed to transfer ECN-capable packets or inappropriately changed the ECN codepoints [BA11]. A recent survey reported a growing support for network paths to pass ECN codepoints [TR15].
一般的なインターネットでECNを使用した初期の経験では、ネットワークパスがECN対応パケットの転送に失敗したか、ECNコードポイントを不適切に変更したときに、いくつかの運用上の問題が発生しました[BA11]。最近の調査では、ECNコードポイントを通過するためのネットワークパスのサポートが増加していることが報告されています[TR15]。
The remainder of this section identifies what is needed for network devices to effectively support ECN.
このセクションの残りの部分では、ネットワークデバイスがECNを効果的にサポートするために必要なものを識別します。
The current IPv4 and IPv6 specifications assign usage of 2 bits in the IP header to carry the ECN codepoint. This 2-bit field was reserved in [RFC2474] and assigned in [RFC3168].
現在のIPv4およびIPv6仕様では、ECNコードポイントを伝送するためにIPヘッダーの2ビットの使用法が割り当てられています。この2ビットのフィールドは[RFC2474]で予約され、[RFC3168]で割り当てられました。
[RFC4774] discusses some of the issues in defining alternate semantics for the ECN field and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics.
[RFC4774]は、ECNフィールドの代替セマンティクスを定義する際のいくつかの問題について説明し、定義された代替セマンティクスを理解しないルーターを含む可能性があるインターネットでの安全な共存の要件を指定します。
Some network devices were configured to use a routing hash that included the set of 8 bits forming the now deprecated Type of Service (TOS) field [RFC1349]. The present use of this field assigns 2 of these bits to carry the ECN field. This is incompatible with use in a routing hash because it could lead to IP packets that carry a CE mark being routed over a different path to those packets that carried an ECT mark. The resultant reordering would impact the performance of transport protocols (such as TCP or SCTP) and UDP-based applications that are sensitive to reordering. A network device that conforms to this older specification needs to be updated to the current specifications [RFC2474] to support ECN. Configuration of network devices must note that the ECN field may be updated by any ECN-capable network device along a path.
一部のネットワークデバイスは、現在非推奨のType of Service（TOS）フィールド[RFC1349]を形成する8ビットのセットを含むルーティングハッシュを使用するように構成されていました。このフィールドの現在の使用は、これらのビットのうちの2つを割り当てて、ECNフィールドを伝送します。これは、ルーティングハッシュでの使用と互換性がありません。これは、CEマークを運ぶIPパケットが、ECTマークを運ぶパケットへの異なるパスを介してルーティングされる可能性があるためです。結果として生じる並べ替えは、並べ替えの影響を受けやすいトランスポートプロトコル（TCPまたはSCTPなど）およびUDPベースのアプリケーションのパフォーマンスに影響を与えます。 ECNをサポートするには、この古い仕様に準拠するネットワークデバイスを現在の仕様[RFC2474]に更新する必要があります。ネットワークデバイスの構成では、ECNフィールドがパス上のECN対応ネットワークデバイスによって更新される可能性があることに注意する必要があります。
Not all network devices along a path need to be ECN-capable (i.e., perform CE marking). However, all network devices need to be configured not to drop packets solely because the ECT(0) or ECT(1) codepoints are used.
パス上のすべてのネットワークデバイスがECN対応である必要はありません（つまり、CEマーキングを実行します）。ただし、すべてのネットワークデバイスは、ECT（0）またはECT（1）コードポイントが使用されるため、パケットをドロップしないように構成する必要があります。
Any network device that does not perform CE marking of an ECN-capable packet can be expected to drop these packets under congestion. Applications that experience congestion at these network devices do not see any benefit from enabling ECN. However, they may see benefit if the congestion were to occur within a network device that did support ECN.
ECN対応パケットのCEマーキングを実行しないネットワークデバイスは、輻輳下でこれらのパケットをドロップすることが予想されます。これらのネットワークデバイスで輻輳が発生するアプリケーションでは、ECNを有効にしてもメリットはありません。ただし、ECNをサポートするネットワークデバイス内で輻輳が発生した場合は、メリットが得られる可能性があります。
Network devices should use an AQM algorithm that CE-marks ECN-capable traffic when making decisions about the response to congestion [RFC7567]. An ECN method should set a CE mark on ECN-capable packets in the presence of incipient congestion. A CE-marked packet will be interpreted as an indication of incipient congestion by the transport endpoints.
ネットワークデバイスは、輻輳への応答に関する決定を行うときにECN対応トラフィックにCEマークを付けるAQMアルゴリズムを使用する必要があります[RFC7567]。 ECNメソッドは、初期の輻輳が存在する場合、ECN対応パケットにCEマークを設定する必要があります。 CEマーク付きのパケットは、トランスポートエンドポイントによる初期の輻輳を示すものとして解釈されます。
There is an opportunity to design an AQM method for an ECN-capable network device that differs from an AQM method designed to drop packets. [RFC7567] states that the network device should allow this behavior to be configurable.
パケットをドロップするように設計されたAQMメソッドとは異なる、ECN対応ネットワークデバイス用のAQMメソッドを設計する機会があります。 [RFC7567]は、ネットワークデバイスがこの動作を構成可能にする必要があることを述べています。
[RFC3168] describes a method in which a network device sets the CE mark at the time that the network device would otherwise have dropped the packet. While it has often been assumed that network devices should CE-mark packets at the same level of congestion at which they would otherwise have dropped them, [RFC7567] recommends that network devices allow independent configuration of the settings for AQM dropping and ECN marking. Such separate configuration of the drop and mark policies is supported in some network devices.
[RFC3168]は、ネットワークデバイスがパケットをドロップしたときにネットワークデバイスがCEマークを設定する方法を説明しています。多くの場合、ネットワークデバイスはパケットをドロップしたときと同じレベルの輻輳でパケットをCEマークする必要があると想定されていましたが、[RFC7567]は、ネットワークデバイスがAQMドロップとECNマーキングの設定を個別に構成できるようにすることを推奨しています。ドロップアンドマークポリシーのこのような個別の設定は、一部のネットワークデバイスでサポートされています。
Network devices need to be able to forward all IP flows and provide appropriate treatment for both ECN and non-ECN traffic.
ネットワークデバイスは、すべてのIPフローを転送し、ECNトラフィックと非ECNトラフィックの両方を適切に処理できる必要があります。
The design considerations for an AQM scheme supporting ECN needs to consider the impact of queueing during incipient congestion. For example, a simple AQM scheme could choose to queue ECN-capable and non-ECN-capable flows in the same queue with an ECN scheme that CE-marks packets during incipient congestion. The CE-marked packets that remain in the queue during congestion can continue to contribute to queueing delay. In contrast, non-ECN-capable packets would normally be dropped by an AQM scheme under incipient congestion. This difference in queueing is one motivation for consideration of more advanced AQM schemes and may provide an incentive for enabling flow isolation using scheduling [RFC7567]. The IETF is defining methods to evaluate the suitability of AQM schemes for deployment in the general Internet [RFC7928].
ECNをサポートするAQMスキームの設計上の考慮事項は、初期の輻輳時のキューイングの影響を考慮する必要があります。たとえば、単純なAQMスキームでは、ECN対応フローと非ECN対応フローを同じキューにキューイングすることを選択できます。ECNスキームでは、初期輻輳時にパケットにCEマークを付けます。輻輳中にキューに残っているCEマークの付いたパケットは、キューイング遅延の一因となる可能性があります。対照的に、ECN非対応パケットは通常、初期の輻輳下でAQMスキームによってドロップされます。このキューイングの違いは、より高度なAQMスキームを検討する動機の1つであり、スケジューリングを使用してフロー分離を有効にするインセンティブを提供する可能性があります[RFC7567]。 IETFは、一般的なインターネット[RFC7928]での展開に対するAQMスキームの適合性を評価する方法を定義しています。
Network devices should not be configured to change the ECN codepoint in the packets that they forward, except to set the CE codepoint to signal incipient congestion.
ネットワークデバイスは、CEのコードポイントを設定して初期の輻輳を通知する場合を除き、転送するパケットのECNコードポイントを変更するように構成しないでください。
Cases have been noted where an endpoint sends a packet with a non-zero ECN mark, but the packet is received by the remote endpoint with a zero ECN codepoint [TR15]. This could be a result of a policy that erases or "bleaches" the ECN codepoint values at a network edge (resetting the codepoint to zero). Bleaching may occur for various reasons (including normalizing packets to hide which equipment supports ECN). This policy prevents use of ECN by applications.
エンドポイントがゼロ以外のECNマークの付いたパケットを送信するが、パケットはゼロのECNコードポイント[TR15]のあるリモートエンドポイントによって受信される場合が指摘されています。これは、ネットワークエッジでECNコードポイント値を消去または「無効化」するポリシーの結果である可能性があります（コードポイントをゼロにリセットします）。漂白はさまざまな理由で発生する可能性があります（ECNをサポートする機器を隠すためにパケットを正規化することを含む）。このポリシーは、アプリケーションによるECNの使用を防止します。
When ECN-capable IP packets, marked as ECT(0) or ECT(1), are re-marked to non-ECN-capable (i.e., the ECN field is set to the zero codepoint), this could result in the packets being dropped by ECN-capable network devices further along the path. This eliminates the advantage of using of ECN.
ECT（0）またはECT（1）としてマークされたECN対応IPパケットが非ECN対応に再マークされると（つまり、ECNフィールドがゼロコードポイントに設定されます）、これによりパケットがパスに沿ってさらに進んだECN対応ネットワークデバイスによってドロップされます。これにより、ECNを使用する利点がなくなります。
A network device must not change a packet with a CE mark to a zero codepoint; if the network device decides not to forward the packet with the CE mark, it has to instead drop the packet and not bleach the marking. This is because a CE-marked packet has already received ECN treatment in the network, and re-marking it would then hide the congestion signal from the receiving endpoint. This eliminates the benefits of ECN. It can also slow down the response to congestion compared to using AQM because the transport will only react if it later discovers congestion by some other mechanism.
ネットワークデバイスは、CEマークの付いたパケットをゼロコードポイントに変更してはなりません。ネットワークデバイスがCEマーク付きのパケットを転送しないことを決定した場合、代わりにパケットをドロップし、マーキングを漂白しないようにする必要があります。これは、CEでマークされたパケットがネットワークですでにECN処理を受信しており、再マーキングすると、受信側のエンドポイントから輻輳信号が隠されるためです。これにより、ECNの利点がなくなります。また、トランスポートは他のメカニズムによって後で輻輳を発見した場合にのみトランスポートが反応するため、AQMを使用する場合と比較して、輻輳への応答が遅くなる可能性もあります。
Prior to [RFC2474], a previous usage assigned the bits now forming the ECN field as a part of the now deprecated TOS field [RFC1349]. A network device that conforms to this older specification was allowed to re-mark or erase the ECN codepoints, and such equipment needs to be updated to the current specifications in order to support ECN.
[RFC2474]の前は、以前の使用法により、現在非推奨のTOSフィールド[RFC1349]の一部としてECNフィールドを形成するビットが割り当てられていました。この古い仕様に準拠するネットワークデバイスは、ECNコードポイントを再マークまたは消去することが許可されていました。ECNをサポートするには、そのような機器を現在の仕様に更新する必要があります。
Some networks may use ECN internally or tunnel ECN (e.g., for traffic engineering or security). These methods need to ensure that the ECN field of the tunnel packets is handled correctly at the ingress and egress of the tunnel. Guidance on the correct use of ECN is provided in [RFC6040].
一部のネットワークは、ECNを内部で使用するか、ECNをトンネルします（トラフィックエンジニアリングやセキュリティなどのため）。これらの方法では、トンネルパケットのECNフィールドがトンネルの入口と出口で正しく処理されるようにする必要があります。 ECNの正しい使用に関するガイダンスは、[RFC6040]で提供されています。
Further guidance on the encapsulation and use of ECN by non-IP network devices is provided in [ECN-ENCAP].
非IPネットワークデバイスによるECNのカプセル化と使用に関する詳細なガイダンスは、[ECN-ENCAP]で提供されています。
A receiving endpoint needs to report the loss it experiences when it uses loss-based congestion control. So also, when ECN is enabled, a receiving endpoint must correctly report the presence of CE marks by providing a mechanism to feed this congestion information back to the sending endpoint [RFC3168] [RFC8085], thus enabling the sender to react to experienced congestion. This mechanism needs to be designed to operate robustly across a wide range of Internet path characteristics. This section describes partial deployment, that is, how ECN-enabled endpoints can continue to work effectively over a path that experiences misbehaving network devices or when an endpoint does not correctly provide feedback of ECN information.
受信エンドポイントは、損失ベースの輻輳制御を使用する場合に、発生する損失を報告する必要があります。そのため、ECNが有効になっている場合、受信エンドポイントは、この輻輳情報を送信エンドポイントにフィードバックするメカニズムを提供することにより、CEマークの存在を正しく報告する必要があります[RFC3168] [RFC8085]。これにより、送信者は経験した輻輳に対応できます。このメカニズムは、幅広いインターネットパス特性にわたって堅牢に動作するように設計する必要があります。このセクションでは、部分的な展開について説明します。つまり、ECN対応のエンドポイントが、ネットワークデバイスの動作に問題がある場合、またはエンドポイントがECN情報のフィードバックを正しく提供しない場合に、パスを介して効果的に機能し続ける方法について説明します。
Use of ECN is negotiated between the endpoints prior to using the mechanism.
ECNの使用は、メカニズムを使用する前にエンドポイント間でネゴシエートされます。
ECN has been designed to allow incremental partial deployment [RFC3168]. Any network device can choose to use either ECN or some other loss-based policy to manage its traffic. Similarly, transport/ application negotiation allows sending and receiving endpoints to choose whether ECN will be used to manage congestion for a particular network flow.
ECNは、増分部分展開を可能にするように設計されています[RFC3168]。どのネットワークデバイスでも、ECNまたはその他の損失ベースのポリシーを使用してトラフィックを管理できます。同様に、トランスポート/アプリケーションネゴシエーションにより、エンドポイントの送受信で、特定のネットワークフローの輻輳を管理するためにECNを使用するかどうかを選択できます。
Internet transports and applications need to be robust to the variety and sometimes varying path characteristics that are encountered in the general Internet. They need to monitor correct forwarding of ECN over the entire path and duration of a session.
インターネットトランスポートおよびアプリケーションは、一般的なインターネットで遭遇するさまざまな、場合によっては変化するパス特性に対して堅牢である必要があります。彼らは、パス全体とセッションの期間にわたってECNの正しい転送を監視する必要があります。
To be robust, applications and transports need to be designed with the expectation of heterogeneous forwarding (e.g., where some IP packets are CE marked by one network device and some by another, possibly using a different AQM algorithm, or when a combination of CE marking and loss-based congestion indications are used). Note that [RFC7928] describes methodologies for evaluating AQM schemes.
堅牢であるためには、アプリケーションとトランスポートは、異種フォワーディングを想定して設計する必要があります（たとえば、一部のIPパケットが別のネットワークデバイスによってCEマーキングされ、別のAQMアルゴリズムを使用している可能性がある場合、またはCEマーキングの組み合わせ損失ベースの輻輳表示が使用されます）。 [RFC7928]はAQMスキームを評価するための方法論を説明していることに注意してください。
A transport/application also needs to be robust to path changes. A change in the set of network devices along a path could impact the ability to effectively signal or use ECN across the path, e.g., when a path changes to use a middlebox that bleaches ECN codepoints (see Section 3.5).
トランスポート/アプリケーションは、パスの変更に対しても堅牢である必要があります。パスに沿った一連のネットワークデバイスの変更は、パス全体でECNを効果的に通知または使用する機能に影響を与える可能性があります。
A sending endpoint can check that any CE marks applied to packets received over the path are indeed delivered to the remote receiving endpoint and that appropriate feedback is provided. (This could be done by a sender setting a known CE codepoint for specific packets in a network flow and then checking whether the remote endpoint correctly reports these marks [ECN-FALLBACK] [TR15].) If a sender detects persistent misuse of ECN, it needs to fall back to using loss-based recovery and congestion control. Guidance on a suitable transport reaction is provided in [ECN-FALLBACK].
送信エンドポイントは、パスを介して受信されたパケットに適用されたCEマークが実際にリモート受信エンドポイントに配信され、適切なフィードバックが提供されていることを確認できます。 （これは、送信者がネットワークフロー内の特定のパケットに既知のCEコードポイントを設定し、リモートエンドポイントがこれらのマークを正しく報告するかどうかをチェックすることで実行できます[ECN-FALLBACK] [TR15]。）送信者がECNの永続的な誤用を検出した場合、損失ベースの回復と輻輳制御の使用にフォールバックする必要があります。適切な輸送反応に関するガイダンスは、[ECN-FALLBACK]で提供されています。
Appropriate feedback requires that the endpoint receiver not try to conceal reception of CE-marked packets in the ECN feedback information provided to the sending endpoint [RFC7567]. Designers of applications/transports are therefore encouraged to include mechanisms that can detect this misbehavior. If a sending endpoint detects that a receiver is not correctly providing this feedback, it needs to fall back to using loss-based recovery instead of ECN.
適切なフィードバックでは、エンドポイントレシーバーが送信エンドポイントに提供されるECNフィードバック情報でCEマーク付きパケットの受信を隠さないようにする必要があります[RFC7567]。したがって、アプリケーション/トランスポートの設計者は、この誤動作を検出できるメカニズムを組み込むことをお勧めします。送信側エンドポイントが、レシーバーがこのフィードバックを正しく提供していないことを検出した場合、ECNの代わりに損失ベースのリカバリーを使用するようにフォールバックする必要があります。
This section summarizes the benefits of deploying and using ECN within the Internet. It also provides a list of prerequisites to achieve ECN deployment.
このセクションでは、インターネット内でECNを展開して使用する利点を要約します。また、ECN展開を実現するための前提条件のリストも示します。
Application developers should, where possible, use transports that enable ECN. Applications that directly use UDP need to provide support to implement the functions required for ECN [RFC8085]. Once enabled, an application that uses a transport that supports ECN will experience the benefits of ECN as network deployment starts to enable ECN. The application does not need to be rewritten to gain these benefits. Figure 2 summarizes the key benefits.
アプリケーション開発者は、可能な場合、ECNを有効にするトランスポートを使用する必要があります。 UDPを直接使用するアプリケーションは、ECN [RFC8085]に必要な機能を実装するためのサポートを提供する必要があります。有効にすると、ECNをサポートするトランスポートを使用するアプリケーションは、ネットワークの展開がECNを有効にし始めると、ECNの利点を体験します。これらの利点を得るためにアプリケーションを書き直す必要はありません。図2は、主な利点をまとめたものです。
+---------+-----------------------------------------------------+
| Section | Benefit |
+---------+-----------------------------------------------------+
| 2.1 | Improved Throughput |
| 2.2 | Reduced Head-of-Line Blocking |
| 2.3 | Reduced Probability of RTO Expiry |
| 2.4 | Applications that do not Retransmit Lost Packets |
| 2.5 | Making Incipient Congestion Visible |
| 2.6 | Opportunities for New Transport Mechanisms |
+---------+-----------------------------------------------------+
Figure 2: Summary of Key Benefits
図2：主な利点の概要
Network operators and people configuring network devices should enable ECN [RFC7567].
ネットワークオペレーターおよびネットワークデバイスを構成する人々は、ECN [RFC7567]を有効にする必要があります。
Prerequisites for network devices (including IP routers) to enable use of ECN include:
ECNの使用を有効にするためのネットワークデバイス（IPルーターを含む）の前提条件は次のとおりです。
o A network device that updates the ECN field in IP packets must use IETF-specified methods (see Section 3.1).
o IPパケットのECNフィールドを更新するネットワークデバイスは、IETF指定のメソッドを使用する必要があります（セクション3.1を参照）。
o A network device may support alternate ECN semantics (see Section 3.1).
o ネットワークデバイスは、代替のECNセマンティクスをサポートする場合があります（セクション3.1を参照）。
o A network device must not choose a different network path solely because a packet carries a CE-codepoint set in the ECN Field; CE-marked packets need to follow the same path as packets with an ECT(0) or ECT(1) codepoint (see Section 3.1). Network devices need to be configured not to drop packets solely because the ECT(0) or ECT(1) codepoints are used (see Section 3.2).
o パケットがECNフィールドに設定されたCEコードポイントを運ぶからといって、ネットワークデバイスは別のネットワークパスを選択してはなりません。 CEマークの付いたパケットは、ECT（0）またはECT（1）コードポイントを持つパケットと同じパスをたどる必要があります（セクション3.1を参照）。ネットワークデバイスは、ECT（0）またはECT（1）コードポイントが使用されるためだけにパケットをドロップしないように構成する必要があります（セクション3.2を参照）。
o An ECN-capable network device should correctly update the ECN codepoint of ECN-capable packets in the presence of incipient congestion (see Section 3.3).
o ECN対応ネットワークデバイスは、初期の輻輳が存在する場合に、ECN対応パケットのECNコードポイントを正しく更新する必要があります（セクション3.3を参照）。
o Network devices need to be able to forward both ECN-capable and not-ECN-capable flows (see Section 3.4).
o ネットワークデバイスは、ECN対応フローと非ECN対応フローの両方を転送できる必要があります（セクション3.4を参照）。
o A network device must not change a packet with a CE mark to a not-ECN-capable codepoint ('00'); if the network device decides not to forward the packet with the CE mark, it has to instead drop the packet and not bleach the marking (see Section 3.5).
o ネットワークデバイスは、CEマークの付いたパケットを非ECN対応コードポイント（ '00'）に変更してはなりません。ネットワークデバイスがCEマーク付きのパケットを転送しないことを決定した場合は、代わりにパケットをドロップし、マーキングを漂白しないようにする必要があります（セクション3.5を参照）。
Prerequisites for network endpoints to enable use of ECN include the following:
ECNの使用を有効にするためのネットワークエンドポイントの前提条件は次のとおりです。
o An application should use an Internet transport that can set and receive ECN marks (see Section 4).
o アプリケーションは、ECNマークを設定および受信できるインターネットトランスポートを使用する必要があります（セクション4を参照）。
o An ECN-capable transport/application must return feedback indicating congestion to the sending endpoint and perform an appropriate congestion response (see Section 4).
o ECN対応のトランスポート/アプリケーションは、送信側エンドポイントに輻輳を示すフィードバックを返し、適切な輻輳応答を実行する必要があります（セクション4を参照）。
o An ECN-capable transport/application should detect paths where there is persistent misuse of ECN and fall back to not sending ECT(0) or ECT(1) (see Section 4.2).
o ECN対応のトランスポート/アプリケーションは、ECNの永続的な誤用があるパスを検出し、ECT（0）またはECT（1）を送信しないようにフォールバックする必要があります（セクション4.2を参照）。
o Designers of applications/transports are encouraged to include mechanisms that can detect and react appropriately to misbehaving receivers that fail to report CE-marked packets (see Section 4.3).
o アプリケーション/トランスポートの設計者は、CEマークの付いたパケットの報告に失敗した、正しく動作しないレシーバーを検出して適切に反応できるメカニズムを含めることをお勧めします（セクション4.3を参照）。
This document introduces no new security considerations. Each RFC listed in this document discusses the security considerations of the specification it contains.
このドキュメントでは、セキュリティに関する新しい考慮事項は紹介されていません。このドキュメントにリストされている各RFCでは、そこに含まれている仕様のセキュリティに関する考慮事項について説明しています。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<http://www.rfc-editor.org/info/rfc2474>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<http：// www。 rfc-editor.org/info/rfc3168>。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC6040] Briscoe、B。、「Tunnelling of Explicit Congestion Notification」、RFC 6040、DOI 10.17487 / RFC6040、2010年11月、<http://www.rfc-editor.org/info/rfc6040>。
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <http://www.rfc-editor.org/info/rfc7567>.
[RFC7567]ベイカー、F。、エド。およびG.フェアハースト編、「アクティブキュー管理に関するIETFの推奨事項」、BCP 197、RFC 7567、DOI 10.17487 / RFC7567、2015年7月、<http://www.rfc-editor.org/info/rfc7567>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <http://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<http://www.rfc-editor.org / info / rfc8085>。
[AL10] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data Center TCP (DCTCP)", ACM SIGCOMM Computer Communication Review, Volume 40, Issue 4, pages 63-74, DOI 10.1145/1851182.1851192, October 2010.
[AL10] Alizadeh、M.、Greenberg、A.、Maltz、D.、Padhye、J.、Patel、P.、Prabhakar、B.、Sengupta、S。、およびM. Sridharan、「Data Center TCP（DCTCP） "、ACM SIGCOMM Computer Communication Review、Volume 40、Issue 4、63-74ページ、DOI 10.1145 / 1851182.1851192、2010年10月。
[BA11] Bauer, Steven., Beverly, Robert., and Arthur. Berger, "Measuring the State of ECN Readiness in Servers, Clients, and Routers", Proceedings of the 2011 ACM SIGCOMM Conference on ICM, pages 171-180, DOI 10.1145/2068816.2068833, November 2011.
[BA11]バウアー、スティーブン、ビバリー、ロバート、およびアーサー。 Berger、「サーバー、クライアント、およびルーターのECN準備状態の測定」、ICMに関する2011 ACM SIGCOMM会議の議事録、ページ171-180、DOI 10.1145 / 2068816.2068833、2011年11月。
[DCTCP] Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P., and G. Judd, "Microsoft's Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters", Work in Progress, draft-bensley-tcpm-dctcp-05, July 2015.
[DCTCP]ベンズリー、S。、エガート、L。、ターラー、D。、バラブラマニアン、P。、およびG.ジャッド、「MicrosoftのデータセンターTCP（DCTCP）：データセンターのTCP輻輳制御」、作業中、ドラフトベンズリー-tcpm-dctcp-05、2015年7月。
[ECN-ENCAP] Briscoe, B., Kaippallimalil, J., and P. Thaler, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", Work in Progress, draft-ietf-tsvwg-ecn-encap-guidelines-07, July 2016.
[ECN-ENCAP] Briscoe、B.、Kaippallimalil、J。、およびP. Thaler、「IPをカプセル化するプロトコルに輻輳通知を追加するためのガイドライン」、作業中、draft-ietf-tsvwg-ecn-encap-guidelines-07 、2016年7月。
[ECN-FALLBACK] Kuehlewind, M. and B. Trammell, "A Mechanism for ECN Path Probing and Fallback", Work in Progress, draft-kuehlewind-tcpm-ecn-fallback-01, September 2013.
[ECN-FALLBACK] Kuehlewind、M。、およびB. Trammell、「ECNパスプローブおよびフォールバックのメカニズム」、作業中、draft-kuehlewind-tcpm-ecn-fallback-01、2013年9月。
[ECN-FEEDBACK] Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More Accurate ECN Feedback in TCP", Work in Progress, draft-ietf-tcpm-accurate-ecn-02, October 2016.
[ECNフィードバック] Briscoe、B.、Kuehlewwind、M。、およびR. Scheffenegger、「TCPでのより正確なECNフィードバック」、作業中、draft-ietf-tcpm-accurate-ecn-02、2016年10月。
[Fla13] Flach, Tobias., Dukkipati, Nandita., Terzis, Andreas., Raghavan, Barath., Cardwell, Neal., Cheng, Yuchung., Jain, Ankur., Hao, Shuai., Katz-Bassett, Ethan., and Ramesh. Govindan, "Reducing web latency: the virtue of gentle aggression", ACM SIGCOMM Computer Communication Review, Volume 43, Issue 4, pages 159-170, DOI 10.1145/2534169.2486014, October 2013.
[Fla13]フラック、トビアス、ダッキパティ、ナンディタ、テルジス、アンドレアス、ラガヴァン、バラス、カードウェル、ニール、チェン、ユチュン、ジャイン、アンクル、ハオ、シュアイ、カッツバセット、イーサン、そしてラメシュ。 Govindan、「Webレイテンシの削減：穏やかな攻撃の美徳」、ACM SIGCOMM Computer Communication Review、Volume 43、Issue 4、159-170ページ、DOI 10.1145 / 2534169.2486014、2013年10月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<http://www.rfc-editor.org/info/rfc768>。
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992, <http://www.rfc-editor.org/info/rfc1349>.
[RFC1349] Almquist、P。、「インターネットプロトコルスイートのサービスタイプ」、RFC 1349、DOI 10.17487 / RFC1349、1992年7月、<http://www.rfc-editor.org/info/rfc1349>。
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, DOI 10.17487/RFC3649, December 2003, <http://www.rfc-editor.org/info/rfc3649>.
[RFC3649] Floyd、S。、「大きな輻輳ウィンドウ用のHighSpeed TCP」、RFC 3649、DOI 10.17487 / RFC3649、2003年12月、<http://www.rfc-editor.org/info/rfc3649>。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, <http://www.rfc-editor.org/info/rfc3758>.
[RFC3758]スチュワート、R。、ラマーリョ、M.、Xie、Q.、Tuexen、M。、およびP.コンラッド、「ストリーム制御伝送プロトコル（SCTP）部分信頼性拡張」、RFC 3758、DOI 10.17487 / RFC3758、5月2004、<http://www.rfc-editor.org/info/rfc3758>。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、DOI 10.17487 / RFC4340、2006年3月、<http：//www.rfc-editor。 org / info / rfc4340>。
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, <http://www.rfc-editor.org/info/rfc4774>.
[RFC4774]フロイド、S。、「明示的な輻輳通知（ECN）フィールドの代替セマンティクスの指定」、BCP 124、RFC 4774、DOI 10.17487 / RFC4774、2006年11月、<http://www.rfc-editor.org/ info / rfc4774>。
[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, <http://www.rfc-editor.org/info/rfc5562>.
[RFC5562]クズマノビッチ、A。、モンダル、A。、フロイド、S。、およびK.ラマクリシュナン、「TCPのSYN / ACKパケットへの明示的輻輳通知（ECN）機能の追加」、RFC 5562、DOI 10.17487 / RFC5562、2009年6月、<http://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, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<http://www.rfc-editor.org/info/ rfc5681>。
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6679] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「RTP over UDPの明示的輻輳通知（ECN）」、RFC 6679、DOI 10.17487 / RFC6679 、2012年8月、<http://www.rfc-editor.org/info/rfc6679>。
[RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., "Congestion Exposure (ConEx) Concepts and Use Cases", RFC 6789, DOI 10.17487/RFC6789, December 2012, <http://www.rfc-editor.org/info/rfc6789>.
[RFC6789] Briscoe、B。、編、Woundy、R。、編、およびA. Cooper、編、「Congestion Exposure（ConEx）Concepts and Use Cases」、RFC 6789、DOI 10.17487 / RFC6789、2012年12月、 <http://www.rfc-editor.org/info/rfc6789>。
[RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N., Ed., and D. Ros, "Characterization Guidelines for Active Queue Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 2016, <http://www.rfc-editor.org/info/rfc7928>.
[RFC7928] Kuhn、N。、編、Natarajan、P。、編、Kademi、N。、編、D。Ros、「Characterization Guidelines for Active Queue Management（AQM）」、RFC 7928、DOI 10.17487 / RFC7928、2016年7月、<http://www.rfc-editor.org/info/rfc7928>。
[ST14] Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream Control Transmission Protocol (SCTP)", Work in Progress, draft-stewart-tsvwg-sctpecn-05, January 2014.
[ST14] Stewart、R.、Tuexen、M。、およびX. Dong、「ECN for Stream Control Transmission Protocol（SCTP）」、Work in Progress、draft-stewart-tsvwg-sctpecn-05、2014年1月。
[TR15] Tranmmel, Brian., Kuehlewind, Mirja., Boppart, Damiano, Learmonth, Iain., and Gorry. Fairhurst, "Enabling Internet-Wide Deployment of Explicit Congestion Notification", Lecture Notes in Computer Science, Volume 8995, pp 193-205, DOI 10.1007/978-3-319-15509-8_15, March 2015.
[TR15]トランメル、ブライアン、キューレウィンド、ミルハ、ボパルト、ダミアーノ、リアマンス、イアン、ゴーリー。フェアハースト、「明示的な輻輳通知のインターネット全体への展開を有効にする」、コンピュータサイエンスの講義ノート、ボリューム8995、pp 193-205、DOI 10.1007 / 978-3-319-15509-8_15、2015年3月。
Acknowledgements
謝辞
The authors were partly funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). The views expressed are solely those of the authors.
著者は、インターネットトランスポートレイテンシの削減（RITE）プロジェクト（ICT-317700）を通じて、その第7フレームワークプログラムの下で欧州共同体から部分的に資金提供を受けました。表明された見解は、著者の見解のみです。
The authors would like to thank the following people for their comments on prior draft versions of this document: Bob Briscoe, David Collier-Brown, Colin Perkins, Richard Scheffenegger, Dave Taht, Wes Eddy, Fred Baker, Mikael Abrahamsson, Mirja Kuehlewind, John Leslie, and other members of the TSVWG and AQM working groups.
著者は、このドキュメントの以前のドラフトバージョンに対するコメントについて、次の方々に感謝します。レスリー、およびTSVWGおよびAQMワーキンググループの他のメンバー。
Authors' Addresses
著者のアドレス
Godred Fairhurst University of Aberdeen School of Engineering, Fraser Noble Building Aberdeen AB24 3UE United Kingdom
Godred Fairhurst University of Aberdeen School of Engineering、Fraser Noble Building Aberdeen AB24 3UE United Kingdom
Email: gorry@erg.abdn.ac.uk
Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway
マイケルウェルズル大学オスロ私書箱1080ブリンデンオスロN-0316ノルウェー
Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no