[要約] RFC 8311は、明示的な輻輳通知（ECN）の実験に関する制限を緩和することを目的としています。ECNの実験を促進し、ネットワークのパフォーマンスと信頼性の向上を図るためのガイドラインを提供します。
Internet Engineering Task Force (IETF) D. Black
Request for Comments: 8311 Dell EMC
Updates: 3168, 4341, 4342, 5622, 6679 January 2018
Category: Standards Track
ISSN: 2070-1721
Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation
明示的な輻輳通知（ECN）実験の制限の緩和
Abstract
概要
This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint.
このメモはRFC 3168を更新し、エンドポイントにネットワークの輻輳を示すためのパケットドロップの代わりにExplicit Congestion Notification（ECN）を指定しています。これは、RFC 3168の制限を緩和し、単なる損失の除去以上の利点への実験を妨げます。このメモは、実験の予想される領域を要約し、RFC 3168を更新して、これらの領域での実験を可能にします。これらの有効な更新を利用するには、IETFドキュメントストリームの試験的なRFCが必要です。さらに、このメモは、RFC 6679のRTPおよびRFC 4341、4342、および5622のデータグラム輻輳制御プロトコル（DCCP）のECN仕様に関連する更新を行います。このメモは、RFC 3540のECNノンス実験の結論も記録しますRFC 3540を実験的から歴史的に再分類する根拠を提供します。この再分類により、ECT（1）コードポイントの新しい実験的使用が可能になります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8311.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8311で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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として、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. ECN Terminology . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. ECN Experimentation: Overview . . . . . . . . . . . . . . . . 5
2.1. Effective Congestion Control is Required . . . . . . . . 6
2.2. Network Considerations for ECN Experimentation . . . . . 6
2.3. Operational and Management Considerations . . . . . . . . 7
3. ECN Nonce and RFC 3540 . . . . . . . . . . . . . . . . . . . 8
4. Updates to RFC 3168 . . . . . . . . . . . . . . . . . . . . . 9
4.1. Congestion Response Differences . . . . . . . . . . . . . 9
4.2. Congestion Marking Differences . . . . . . . . . . . . . 10
4.3. TCP Control Packets and Retransmissions . . . . . . . . . 13
5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 14
6. ECN for DCCP Updates to RFCs 4341, 4342, and 5622 . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
This memo updates RFC 3168 [RFC3168], which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the proposed areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IETF document stream [RFC4844] is required to take advantage of any of these enabling updates. Putting all of these updates into a single document enables experimentation to proceed without requiring a standards process exception for each Experimental RFC that needs changes to RFC 3168, a Proposed Standard RFC.
このメモは、RFC 3168 [RFC3168]を更新します。これは、エンドポイントにネットワークの輻輳を示すためのパケットドロップの代わりに、明示的輻輳通知（ECN）を指定します。これは、RFC 3168の制限を緩和し、単なる損失の除去以上の利点への実験を妨げます。このメモは、実験の提案された領域を要約し、RFC 3168を更新して、これらの領域での実験を可能にします。 IETFドキュメントストリーム[RFC4844]の試験的なRFCは、これらの有効な更新を利用するために必要です。これらすべての更新を1つのドキュメントにまとめることにより、RFC 3168（提案された標準RFC）への変更を必要とする各実験的RFCの標準プロセス例外を必要とせずに実験を進めることができます。
There is no need for this memo to update RFC 3168 to simplify standardization of protocols and mechanisms that are documented in Standards Track RFCs, as any Standards Track RFC can update RFC 3168 directly without either relying on updates in this memo or using a standards process exception.
このメモのRFC 3168を更新して、Standards Track RFCsに記載されているプロトコルとメカニズムの標準化を簡素化する必要はありません。StandardsTrack RFCは、このメモの更新に依存したり、標準プロセスの例外を使用したりせずに、RFC 3168を直接更新できるためです。 。
In addition, this memo makes related updates to the ECN specification for RTP [RFC6679] and for three DCCP profiles ([RFC4341], [RFC4342], and [RFC5622]) for the same reason. Each experiment is still required to be documented in one or more separate RFCs, but use of Experimental RFCs for this purpose does not require a process exception to modify any of these Proposed Standard RFCs when the modification falls within the bounds established by this memo (RFC 5622 is an Experimental RFC; it is modified by this memo for consistency with modifications to the other two DCCP RFCs).
さらに、このメモは、同じ理由で、RTP [RFC6679]および3つのDCCPプロファイル（[RFC4341]、[RFC4342]、および[RFC5622]）のECN仕様に関連する更新を行います。各実験は1つ以上の個別のRFCで文書化する必要がありますが、この目的で実験的RFCを使用しても、変更がこのメモ（RFC 5622は試験的なRFCであり、他の2つのDCCP RFCへの変更との整合性のために、このメモによって変更されています。
Some of the anticipated experimentation includes use of the ECT(1) codepoint that was dedicated to the ECN nonce experiment in RFC 3540 [RFC3540]. This memo records the conclusion of the ECN nonce experiment and provides the explanation for reclassification of RFC 3540 from Experimental to Historic in order to enable new experimental use of the ECT(1) codepoint.
予想される実験には、RFC 3540 [RFC3540]のECN nonce実験専用のECT（1）コードポイントの使用が含まれます。このメモは、ECNナンス実験の結論を記録し、ECT（1）コードポイントの新しい実験的使用を可能にするために、RFC 3540を実験的から歴史的に再分類するための説明を提供します。
ECT: ECN-Capable Transport. One of the two codepoints, ECT(0) or ECT(1), in the ECN field [RFC3168] of the IP header (v4 or v6). An ECN-capable sender sets one of these to indicate that both transport endpoints support ECN.
ECT：ECN対応のトランスポート。 IPヘッダー（v4またはv6）のECNフィールド[RFC3168]内の2つのコードポイントECT（0）またはECT（1）の1つ。 ECN対応の送信者は、これらのいずれかを設定して、両方のトランスポートエンドポイントがECNをサポートすることを示します。
Not-ECT: The ECN codepoint set by senders that indicates that the transport is not ECN capable.
Not-ECT：トランスポートがECNに対応していないことを示す、送信者によって設定されたECNコードポイント。
CE: Congestion Experienced. The ECN codepoint that an intermediate node sets to indicate congestion. A node sets an increasing proportion of ECT packets to Congestion Experienced (CE) as the level of congestion increases.
CE：輻輳が発生しました。中間ノードが輻輳を示すために設定するECNコードポイント。ノードは、輻輳のレベルが増加するにつれて、ECTパケットの割合をCongestion Experienced（CE）に設定します。
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]で説明されているように解釈されます。
Three areas of ECN experimentation are covered by this memo; the cited documents should be consulted for the detailed goals and rationale of each proposed experiment:
このメモでは、ECN実験の3つの領域について説明します。引用された文書は、提案された各実験の詳細な目標と根拠について参照する必要があります。
Congestion Response Differences: An ECN congestion indication communicates a higher likelihood than a dropped packet that a short queue exists at the network bottleneck node [TCP-ABE]. This difference suggests that for congestion indicated by ECN, a different sender congestion response (e.g., sender backs off by a smaller amount) may be appropriate by comparison to the sender response to congestion indicated by loss. Two examples of proposed sender congestion response changes are described in [TCP-ABE] and [ECN-L4S] -- the proposal in the latter document couples the sender congestion response change to Congestion Marking Differences functionality (see next paragraph). These changes are at variance with the requirement in RFC 3168 that a sender's congestion control response to ECN congestion indications be the same as to drops. IETF approval, e.g., via an Experimental RFC in the IETF document stream, is required for any sender congestion response used in this area of experimentation. See Section 4.1 for further discussion.
輻輳応答の違い：ECN輻輳表示は、ドロップされたパケットよりも、ネットワークボトルネックノードに短いキューが存在する可能性が高いことを伝えます[TCP-ABE]。この違いは、ECNによって示される輻輳の場合、損失によって示される輻輳に対する送信者の応答と比較すると、異なる送信者の輻輳応答（送信者が少量ずつバックオフするなど）が適切である可能性があることを示唆しています。 [TCP-ABE]と[ECN-L4S]には、送信者の輻輳応答の変更案の2つの例が記載されています。後者のドキュメントの提案では、送信者の輻輳応答の変更を輻輳マーキングの違い機能に結合しています（次の段落を参照）。これらの変更は、ECN輻輳表示に対する送信者の輻輳制御応答がドロップと同じであるというRFC 3168の要件とは異なります。 IETF文書ストリームの試験的RFCなどによるIETFの承認は、この実験の領域で使用される送信者の輻輳応答に必要です。詳細については、セクション4.1を参照してください。
Congestion Marking Differences: Congestion marking at network nodes can be configured to maintain very shallow queues in conjunction with a different sender response to congestion indications (CE marks), e.g., as proposed in [ECN-L4S]. The traffic involved needs to be identified by the senders to the network nodes in order to avoid damage to other network traffic whose senders do not expect the more frequent congestion marking used to maintain very shallow queues. Use of different ECN codepoints, specifically ECT(0) and ECT(1), is a promising means of traffic identification for this purpose, but that technique is at variance with the requirement in RFC 3168 that traffic marked as ECT(0) not receive different treatment in the network by comparison to traffic marked as ECT(1). IETF approval, e.g., via an Experimental RFC in the IETF document stream, is required for any differences in congestion marking or sender congestion response used in this area of experimentation. See Section 4.2 for further discussion.
輻輳マーキングの違い：ネットワークノードでの輻輳マーキングは、たとえば[ECN-L4S]で提案されているように、輻輳表示（CEマーク）に対するさまざまな送信者の応答とともに非常に浅いキューを維持するように構成できます。非常に浅いキューを維持するために使用されるより頻繁な輻輳マーキングを送信者が期待しない他のネットワークトラフィックへの損傷を避けるために、関連するトラフィックはネットワークノードへの送信者によって識別される必要があります。異なるECNコードポイント、具体的にはECT（0）とECT（1）の使用は、この目的のためのトラフィック識別の有望な手段ですが、その手法は、ECT（0）としてマークされたトラフィックが受信しないというRFC 3168の要件とは異なりますECT（1）としてマークされたトラフィックとの比較によるネットワークでの異なる扱い。 IETF文書ストリームの実験的RFCなどによるIETFの承認は、この実験の領域で使用される輻輳マーキングまたは送信者の輻輳応答の違いに対して必要です。詳細については、セクション4.2を参照してください。
TCP Control Packets and Retransmissions: RFC 3168 limits the use of ECN with TCP to data packets, excluding retransmissions. With the successful deployment of ECN in large portions of the Internet, there is interest in extending the benefits of ECN to TCP control packets (e.g., SYNs) and retransmitted packets, e.g., as proposed in [ECN-TCP]. This is at variance with RFC 3168's prohibition of ECN for TCP control packets and retransmitted packets. See Section 4.3 for further discussion.
TCP制御パケットと再送信：RFC 3168は、TCPでのECNの使用を、再送信を除くデータパケットに制限しています。インターネットの大部分でのECNの導入が成功したため、ECNの利点をTCP制御パケット（SYNなど）および再送信されたパケット（[ECN-TCP]で提案されているような）に拡張することに関心があります。これは、TCP制御パケットおよび再送信されたパケットに対するECNのRFC 3168の禁止とは異なります。詳細については、セクション4.3を参照してください。
The scope of this memo is limited to these three areas of experimentation. This memo expresses no view on the likely outcomes of the proposed experiments and does not specify the experiments in detail. Additional experiments in these areas are possible, e.g., on use of ECN to support deployment of a protocol similar to Data Center TCP (DCTCP) [RFC8257] beyond DCTCP's current applicability that is limited to data center environments. The purpose of this memo is to remove constraints in Standards Track RFCs that stand in the way of these areas of experimentation.
このメモの範囲は、これら3つの実験領域に限定されています。このメモは、提案された実験の可能性のある結果についての見解を表しておらず、実験を詳細に指定していません。これらの領域では、ECNを使用してデータセンターTCP（DCTCP）[RFC8257]と同様のプロトコルの展開をサポートするなど、データセンター環境に限定されているDCTCPの現在の適用範囲を超えた追加の実験が可能です。このメモの目的は、これらの実験領域の邪魔をする標準化過程RFCの制約を取り除くことです。
Congestion control remains an important aspect of the Internet architecture [RFC2914]. Any Experimental RFC in the IETF document stream that takes advantage of this memo's updates to any RFC is required to discuss the congestion control implications of the experiment(s) in order to provide assurance that deployment of the experiment(s) does not pose a congestion-based threat to the operation of the Internet.
輻輳制御は、インターネットアーキテクチャの重要な側面であり続けます[RFC2914]。このメモの更新をRFCに利用するIETFドキュメントストリームの実験的RFCは、実験の展開が輻輳を引き起こさないことを保証するために、実験の輻輳制御の影響を議論するために必要です。ベースのインターネットの運用に対する脅威。
ECN functionality [RFC3168] is becoming widely deployed in the Internet and is being designed into additional protocols such as Transparent Interconnection of Lots of Links (TRILL) [ECN-TRILL]. ECN experiments are expected to coexist with deployed ECN functionality, with the responsibility for that coexistence falling primarily upon designers of experimental changes to ECN. In addition, protocol designers and implementers, as well as network operators, may desire to anticipate and/or support ECN experiments. The following guidelines will help avoid conflicts with the areas of ECN experimentation enabled by this memo:
ECN機能[RFC3168]はインターネットで広く導入されるようになり、リンクの透過的相互接続（TRILL）[ECN-TRILL]などの追加プロトコルに組み込まれています。 ECN実験は展開されたECN機能と共存し、その共存の責任は主にECNの実験的変更の設計者にあります。さらに、プロトコルの設計者と実装者、およびネットワークオペレーターは、ECN実験を予測および/またはサポートすることを望む場合があります。次のガイドラインは、このメモによって可能になるECN実験の領域との競合を回避するのに役立ちます。
1. Forwarding behavior as described in RFC 3168 remains the preferred approach for routers that are not involved in ECN experiments, in particular continuing to treat the ECT(0) and ECT(1) codepoints as equivalent, as specified in Section 4.2 below.
1. RFC 3168で説明されている転送動作は、ECN実験に関与しないルーターの推奨アプローチであり、特に、セクション4.2で指定されているように、ECT（0）とECT（1）のコードポイントを同等として扱い続けます。
2. Network nodes that forward packets SHOULD NOT assume that the ECN CE codepoint indicates that the packet would have been dropped if ECN were not in use. This is because Congestion Response Differences experiments employ different congestion responses to dropped packets by comparison to receipt of CE-marked packets (see Section 4.1 below), so CE-marked packets SHOULD NOT be arbitrarily dropped. A corresponding difference in congestion responses already occurs when the ECN field is used for Pre-Congestion Notification (PCN) [RFC6660].
2. パケットを転送するネットワークノードは、ECN CEコードポイントが、ECNが使用されていなかった場合にパケットがドロップされることを示すと想定してはなりません（SHOULD NOT）。これは、輻輳応答の違いの実験では、CEマークの付いたパケットの受信と比較して、ドロップされたパケットに対するさまざまな輻輳応答が使用されるためです（以下のセクション4.1を参照）。 ECNフィールドが事前輻輳通知（PCN）[RFC6660]に使用されている場合、輻輳応答の対応する違いはすでに発生しています。
3. A network node MUST NOT originate traffic marked with ECT(1) unless the network node is participating in a Congestion Marking Differences experiment that uses ECT(1), as specified in Section 4.2 below.
3. 以下のセクション4.2で指定されているように、ネットワークノードがECT（1）を使用するCongestion Marking Differences実験に参加していない限り、ネットワークノードはECT（1）でマークされたトラフィックを発信してはなりません（MUST NOT）。
Some ECN experiments use ECN with packets where ECN has not been used previously, specifically TCP control packets and retransmissions; see Section 4.3 below. The new middlebox behavior requirements in that section are of particular importance. In general, any system or protocol that inspects or monitors network traffic SHOULD be prepared to encounter ECN usage on packets and traffic that currently do not use ECN.
一部のECN実験では、以前にECNが使用されていなかったパケット、特にTCP制御パケットと再送信でECNを使用します。以下のセクション4.3を参照してください。そのセクションの新しいミドルボックスの動作要件は特に重要です。一般に、ネットワークトラフィックを検査または監視するシステムまたはプロトコルは、現在ECNを使用していないパケットおよびトラフィックでのECNの使用に遭遇する準備をしておく必要があります。
ECN field handling requirements for tunnel encapsulation and decapsulation are specified in [RFC6040], which is in the process of being updated by [ECN-SHIM]. Related guidance for encapsulations whose outer headers are not IP headers can be found in [ECN-ENCAP]. These requirements and guidance apply to all traffic, including traffic that is part of any ECN experiment.
トンネルのカプセル化とカプセル化解除のECNフィールド処理要件は、[ECN-SHIM]によって更新されている[RFC6040]で指定されています。外部ヘッダーがIPヘッダーではないカプセル化に関する関連ガイダンスは、[ECN-ENCAP]にあります。これらの要件とガイダンスは、ECN実験の一部であるトラフィックを含むすべてのトラフィックに適用されます。
Changes in network traffic behavior that result from ECN experimentation are likely to impact network operations and management. Designers of ECN experiments are expected to anticipate possible impacts and consider how they may be dealt with. Specific topics to consider include possible network management changes or extensions, monitoring of the experimental deployment, collection of data for evaluation of the experiment, and possible interactions with other protocols, particularly protocols that encapsulate network traffic.
ECN実験によるネットワークトラフィック動作の変化は、ネットワークの運用と管理に影響を与える可能性があります。 ECN実験の設計者は、起こり得る影響を予測し、それらがどのように処理されるかを検討することが期待されます。考慮すべき特定のトピックには、ネットワーク管理の変更または拡張の可能性、実験的展開の監視、実験の評価のためのデータの収集、および他のプロトコル、特にネットワークトラフィックをカプセル化するプロトコルとの可能な相互作用が含まれます。
For further discussion, see [RFC5706]; the questions in Appendix A of RFC 5706 provide a concise survey of some important aspects to consider.
詳細については、[RFC5706]を参照してください。 RFC 5706の付録Aにある質問は、考慮すべきいくつかの重要な側面の簡潔な調査を提供します。
As specified in RFC 3168, ECN uses two ECN-Capable Transport (ECT) codepoints, ECT(0) and ECT(1), to indicate that a packet supports ECN. RFC 3168 assigned the second codepoint, ECT(1), to support ECN nonce functionality that discourages receivers from exploiting ECN to improve their throughput at the expense of other network users. That ECN nonce functionality is fully specified in RFC 3540 [RFC3540]. This section explains why RFC 3540 has been reclassified from Experimental to Historic and makes associated updates to RFC 3168.
RFC 3168で指定されているように、ECNは2つのECN対応トランスポート（ECT）コードポイント、ECT（0）とECT（1）を使用して、パケットがECNをサポートすることを示します。 RFC 3168は、他のネットワークユーザーを犠牲にしてスループットを改善するために受信者がECNを悪用するのを阻止するECNナンス機能をサポートするために、2番目のコードポイントECT（1）を割り当てました。そのECN nonce機能はRFC 3540 [RFC3540]で完全に指定されています。このセクションでは、RFC 3540が実験的から歴史的に再分類され、RFC 3168に関連する更新が行われる理由を説明します。
While the ECN nonce works as specified, and has been deployed in limited environments, widespread usage in the Internet has not materialized. A study of the ECN behavior of the top one million web servers using 2014 data [Trammell15] found that after ECN was negotiated, none of the 581,711 IPv4 servers tested were using both ECT codepoints, which would have been a possible sign of ECN nonce usage. Of the 17,028 IPv6 servers tested, four set both ECT(0) and ECT(1) on data packets. This might have been evidence of use of the ECN nonce by these four servers, but it might equally have been due to erroneous re-marking of the ECN field by a middlebox or router.
ECN nonceは指定どおりに機能し、限られた環境で展開されていますが、インターネットでの広範な使用は実現されていません。 2014年のデータ[Trammell15]を使用した上位100万台のWebサーバーのECN動作の調査では、ECNの交渉後、テストされた581,711 IPv4サーバーのいずれも両方のECTコードポイントを使用しておらず、ECNナンスの使用の兆候である可能性がありました。テストした17,028のIPv6サーバーのうち、4つがデータパケットにECT（0）とECT（1）の両方を設定しました。これは、これらの4つのサーバーによるECNナンスの使用の証拠であった可能性がありますが、ミドルボックスまたはルーターによるECNフィールドの誤った再マーキングが原因である可能性もあります。
With the emergence of new experimental functionality that depends on use of the ECT(1) codepoint for other purposes, continuing to reserve that codepoint for the ECN nonce experiment is no longer justified. In addition, other approaches to discouraging receivers from exploiting ECN have emerged; see Appendix B.1 of [ECN-L4S]. Therefore, in support of ECN experimentation with the ECT(1) codepoint, this memo:
他の目的でのECT（1）コードポイントの使用に依存する新しい実験的機能の出現により、ECNノンス実験のコードポイントを予約し続けることはもはや正当化されません。さらに、受信者がECNを利用するのを阻止する他のアプローチが登場しました。 [ECN-L4S]の付録B.1を参照してください。したがって、ECT（1）コードポイントを使用したECN実験をサポートするために、このメモは次のようになります。
o Declares that the ECN nonce experiment [RFC3540] has concluded and notes the absence of widespread deployment.
o ECN nonce実験[RFC3540]が終了したことを宣言し、広範囲に及ぶ展開がないことを指摘します。
o Updates RFC 3168 [RFC3168] to remove discussion of the ECN nonce and use of ECT(1) for that nonce.
o RFC 3168 [RFC3168]を更新して、ECNナンスおよびそのナンスに対するECT（1）の使用に関する議論を削除します。
The four primary updates to RFC 3168 that remove discussion of the ECN nonce and use of ECT(1) for that nonce are as follows:
ECN nonceの議論およびそのnonceに対するECT（1）の使用を削除するRFC 3168の4つの主要な更新は次のとおりです。
1. The removal of the paragraph in Section 5 that immediately follows Figure 1; this paragraph discusses the ECN nonce as the motivation for two ECT codepoints.
1. 図1に続くセクション5の段落の削除。この段落では、2つのECTコードポイントの動機としてのECNナンスについて説明します。
2. The removal of Section 11.2, "A Discussion of the ECN nonce", in its entirety.
2. セクション11.2「ECNナンスのディスカッション」全体の削除。
3. The removal of the last paragraph of Section 12, which states that ECT(1) may be used as part of the implementation of the ECN nonce.
3. セクション12の最後の段落の削除。ECT（1）はECNナンスの実装の一部として使用される可能性があると述べています。
4. The removal of the first two paragraphs of Section 20.2, which discuss the ECN nonce and alternatives. No changes are made to the rest of Section 20.2, which discusses alternative uses for the fourth ECN codepoint.
4. セクション20.2の最初の2つの段落の削除。これは、ECNナンスと代替案について説明しています。 4番目のECNコードポイントの代替使用法について説明しているセクション20.2の残りの部分は変更されていません。
In addition, other less-substantive changes to RFC 3168 are required to remove all other mentions of the ECN nonce and to remove implications that ECT(1) is intended for use by the ECN nonce; these specific text updates are omitted for brevity.
さらに、ECNナンスに関する他のすべての言及を削除し、ECT（1）がECNナンスによる使用を意図しているという意味を削除するには、RFC 3168へのその他の実質的でない変更が必要です。これらの特定のテキストの更新は簡潔にするために省略されています。
The following subsections specify updates to RFC 3168 to enable the three areas of experimentation summarized in Section 2.
以下のサブセクションでは、RFC 3168の更新を指定して、セクション2に要約されている3つの実験領域を有効にします。
RFC 3168 specifies that senders respond identically to packet drops and ECN congestion indications. ECN congestion indications are predominately originated by Active Queue Management (AQM) mechanisms in intermediate buffers. AQM mechanisms are usually configured to maintain shorter queue lengths than non-AQM-based mechanisms, particularly non-AQM drop-based mechanisms such as tail-drop, as AQM mechanisms indicate congestion before the queue overflows. While the occurrence of loss does not easily enable the receiver to determine if AQM is used, the receipt of an ECN CE mark conveys a strong likelihood that AQM was used to manage the bottleneck queue. Hence, an ECN congestion indication communicates a higher likelihood than a dropped packet that a short queue exists at the network bottleneck node [TCP-ABE]. This difference suggests that for congestion indicated by ECN, a different sender congestion response (e.g., sender backs off by a smaller amount) may be appropriate by comparison to the sender response to congestion indicated by loss. However, Section 5 of RFC 3168 specifies that:
RFC 3168は、送信者がパケットドロップとECN輻輳表示に同じように応答することを指定しています。 ECNの輻輳表示は、主に中間バッファーのアクティブキュー管理（AQM）メカニズムによって発生します。 AQMメカニズムは、キューがオーバーフローする前に輻輳を示すため、通常、非AQMベースのメカニズム、特にテールドロップなどの非AQMドロップベースのメカニズムよりも短いキューの長さを維持するように構成されます。損失が発生しても、レシーバーはAQMが使用されているかどうかを簡単に判別できませんが、ECN CEマークの受信は、ボトルネックキューの管理にAQMが使用された可能性が高いことを示しています。したがって、ECN輻輳表示は、ドロップされたパケットよりも、ネットワークボトルネックノードに短いキューが存在する可能性が高いことを伝達します[TCP-ABE]。この違いは、ECNによって示される輻輳の場合、損失によって示される輻輳に対する送信者の応答と比較すると、異なる送信者の輻輳応答（送信者が少量ずつバックオフするなど）が適切である可能性があることを示唆しています。ただし、RFC 3168のセクション5では、次のように規定されています。
Upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems MUST be essentially the same as the congestion control response to a *single* dropped packet.
単一のCEパケットをECN対応トランスポートが受信すると、エンドシステムで実行される輻輳制御アルゴリズムは、*単一*のドロップされたパケットに対する輻輳制御応答と本質的に同じでなければなりません（MUST）。
This memo updates this text from RFC 3168 to allow the congestion control response (including the TCP Sender's congestion control response) to a CE-marked packet to differ from the response to a dropped packet, provided that the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream. The specific change to RFC 3168 is to insert the words "unless otherwise specified by an Experimental RFC in the IETF document stream" at the end of the sentence quoted above.
このメモは、RFC 3168からの変更が文書化されている場合、CEマークの付いたパケットに対する輻輳制御応答（TCP送信者の輻輳制御応答を含む）がドロップされたパケットに対する応答と異なるように、このテキストをRFC 3168から更新します。 IETFドキュメントストリームの試験的なRFC。 RFC 3168への特定の変更は、上記で引用された文の終わりに「IETFドキュメントストリームの実験的RFCによって特に指定されていない限り」という単語を挿入することです。
RFC 4774 [RFC4774] quotes the above text from RFC 3168 as background, but it does not impose requirements based on that text. Therefore, no update to RFC 4774 is required to enable this area of experimentation.
RFC 4774 [RFC4774]は、RFC 3168からの上記のテキストを背景として引用していますが、そのテキストに基づく要件を課すものではありません。したがって、この実験領域を有効にするためにRFC 4774を更新する必要はありません。
Section 6.1.2 of RFC 3168 specifies that:
RFC 3168のセクション6.1.2では、次のように規定されています。
If the sender receives an ECN-Echo (ECE) ACK packet (that is, an ACK packet with the ECN-Echo flag set in the TCP header), then the sender knows that congestion was encountered in the network on the path from the sender to the receiver. The indication of congestion should be treated just as a congestion loss in non-ECN-Capable TCP. That is, the TCP source halves the congestion window "cwnd" and reduces the slow start threshold "ssthresh".
送信者がECN-Echo（ECE）ACKパケット（つまり、TCPヘッダーにECN-Echoフラグが設定されたACKパケット）を受信した場合、送信者は、送信者からのパス上のネットワークで輻輳が発生したことを認識します受信機に。輻輳の兆候は、ECN非対応TCPでの輻輳損失と同様に扱われる必要があります。つまり、TCPソースは輻輳ウィンドウ「cwnd」を半分にして、スロースタートしきい値「ssthresh」を減らします。
This memo also updates this text from RFC 3168 to allow the congestion control response (including the TCP Sender's congestion control response) to a CE-marked packet to differ from the response to a dropped packet, provided that the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream. The specific change to RFC 3168 is to insert the words "Unless otherwise specified by an Experimental RFC in the IETF document stream" at the beginning of the second sentence quoted above.
このメモはまた、RFC 3168からの変更が文書化されている場合、CEマーク付きパケットへの輻輳制御応答（TCP送信者の輻輳制御応答を含む）がドロップされたパケットへの応答と異なるように、このテキストをRFC 3168から更新しますIETFドキュメントストリームの試験的なRFC。 RFC 3168に対する特定の変更は、上記で引用された2番目の文の冒頭に「IETFドキュメントストリームの実験的RFCによって別段に指定されていない限り」という単語を挿入することです。
Taken to its limit, an AQM algorithm that uses ECN congestion indications can be configured to maintain very shallow queues, thereby reducing network latency by comparison to maintaining a larger queue. Significantly more aggressive sender responses to ECN are needed to make effective use of such very shallow queues; "Datacenter TCP (DCTCP)" [RFC8257] provides an example. In this case, separate network node treatments are essential, both to prevent the aggressive low-latency traffic from starving conventional traffic (if present) and to prevent any conventional traffic disruption to any lower-latency service that uses the very shallow queues. Use of different ECN codepoints is a promising means of identifying these two classes of traffic to network nodes; hence, this area of experimentation is based on the use of the ECT(1) codepoint to request ECN congestion marking behavior in the network that differs from ECT(0). It is essential that any such change in ECN congestion marking behavior be counterbalanced by use of a different IETF- approved congestion response to CE marks at the sender, e.g., as proposed in [ECN-L4S].
限界に達すると、ECN輻輳表示を使用するAQMアルゴリズムは、非常に浅いキューを維持するように構成できるため、より大きなキューを維持する場合と比較して、ネットワークの待ち時間を短縮できます。このような非常に浅いキューを効果的に使用するには、ECNへのかなり積極的な送信者応答が必要です。 「Datacenter TCP（DCTCP）」[RFC8257]に例があります。この場合、積極的な低遅延トラフィックが従来のトラフィック（存在する場合）を枯渇させることを防ぎ、非常に浅いキューを使用する低遅延サービスへの従来のトラフィックの中断を防ぐために、個別のネットワークノード処理が不可欠です。異なるECNコードポイントの使用は、ネットワークノードへのこれらの2つのクラスのトラフィックを識別する有望な手段です。したがって、この実験領域は、ECT（1）コードポイントを使用して、ECT（0）とは異なるネットワーク内のECN輻輳マーキング動作を要求することに基づいています。たとえば[ECN-L4S]で提案されているように、送信者でのCEマークに対する異なるIETF承認の輻輳応答を使用することにより、ECN輻輳マーキング動作のこのような変更を相殺することが不可欠です。
Section 5 of RFC 3168 specifies that "Routers treat the ECT(0) and ECT(1) codepoints as equivalent."
RFC 3168のセクション5では、「ルーターはECT（0）とECT（1）のコードポイントを同等のものとして扱う」と規定しています。
This memo updates RFC 3168 to allow routers to treat the ECT(0) and ECT(1) codepoints differently, provided that the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream. The specific change to RFC 3168 is to insert the words "unless otherwise specified by an Experimental RFC in the IETF document stream" at the end of the above sentence.
このメモはRFC 3168を更新して、ルーターがECT（0）とECT（1）のコードポイントを異なる方法で処理できるようにします。ただし、RFC 3168からの変更点は、IETFドキュメントストリームの試験的RFCに記載されています。 RFC 3168に対する特定の変更は、上記の文の終わりに「IETFドキュメントストリームの実験的RFCで特に指定されていない限り」という単語を挿入することです。
When an AQM is configured to use ECN congestion indications to maintain a very shallow queue, congestion indications are marked on packets that would not have been dropped if ECN was not in use. Section 5 of RFC 3168 specifies that:
非常に浅いキューを維持するためにECN輻輳表示を使用するようにAQMが構成されている場合、ECNが使用されていなければドロップされなかったはずのパケットに、輻輳表示がマークされます。 RFC 3168のセクション5では、次のように規定されています。
For a router, the CE codepoint of an ECN-Capable packet SHOULD only be set if the router would otherwise have dropped the packet as an indication of congestion to the end nodes. When the router's buffer is not yet full and the router is prepared to drop a packet to inform end nodes of incipient congestion, the router should first check to see if the ECT codepoint is set in that packet's IP header. If so, then instead of dropping the packet, the router MAY instead set the CE codepoint in the IP header.
ルーターの場合、ECN対応パケットのCEコードポイントは、ルーターがエンドノードへの輻輳を示すものとしてパケットをドロップする場合にのみ設定する必要があります（SHOULD）。ルーターのバッファーがまだいっぱいではなく、ルーターがパケットをドロップしてエンドノードに初期の輻輳を通知する準備ができている場合、ルーターはまず、ECTコードポイントがそのパケットのIPヘッダーに設定されているかどうかを確認する必要があります。その場合、パケットをドロップする代わりに、ルーターは代わりにIPヘッダーにCEコードポイントを設定してもよい（MAY）。
This memo updates RFC 3168 to allow congestion indications that are not equivalent to drops, provided that the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream. The specific change is to change "For a router" to "Unless otherwise specified by an Experimental RFC in the IETF document stream" at the beginning of the first sentence of the above paragraph.
RFC 3168からの変更がIETFドキュメントストリームの試験的RFCに記載されている場合、このメモはRFC 3168を更新して、ドロップとは異なる輻輳表示を許可します。具体的な変更は、上記の段落の最初の文の冒頭にある「ルーターの場合」を「IETFドキュメントストリームの実験的RFCで特に指定されていない限り」に変更することです。
A larger update to RFC 3168 is necessary to enable sender usage of ECT(1) to request network congestion marking behavior that maintains very shallow queues at network nodes. When using loss as a congestion signal, the number of signals provided should be reduced to a minimum; hence, only the presence or absence of congestion is communicated. In contrast, ECN can provide a richer signal, e.g., to indicate the current level of congestion, without the disadvantage of a larger number of packet losses. A proposed experiment in this area, Low Latency Low Loss Scalable throughput (L4S) [ECN-L4S], significantly increases the CE marking probability for traffic marked as ECT(1) in a fashion that would interact badly with existing sender congestion response functionality because that functionality assumes that the network marks ECT packets as frequently as it would drop Not-ECT packets. If network traffic that uses such a conventional sender congestion response were to encounter L4S's increased marking probability (and hence rate) at a network bottleneck queue, the resulting traffic throughput is likely to be much less than intended for the level of congestion at the bottleneck queue.
送信者がECT（1）を使用してネットワークノードで非常に浅いキューを維持するネットワーク輻輳マーキング動作を要求できるようにするには、RFC 3168のより大きな更新が必要です。損失を輻輳信号として使用する場合は、提供される信号の数を最小限に抑える必要があります。したがって、輻輳の有無のみが通信されます。対照的に、ECNは、より多くのパケット損失の不利益なしに、たとえば現在の輻輳レベルを示すために、より豊富な信号を提供できます。この領域で提案されている実験である低遅延低損失スケーラブルスループット（L4S）[ECN-L4S]は、既存の送信者輻輳応答機能と不適切に相互作用するような方法で、ECT（1）としてマークされたトラフィックのCEマーキング確率を大幅に高めます。この機能は、ネットワークがECTパケットをドロップするのと同じ頻度でECTパケットをマークすることを前提としています。このような従来の送信側輻輳応答を使用するネットワークトラフィックが、ネットワークボトルネックキューでL4Sの増加したマーキング確率（したがってレート）に遭遇した場合、結果として生じるトラフィックスループットは、ボトルネックキューでの輻輳のレベルに対して意図したものよりはるかに低くなる可能性があります。 。
This memo updates RFC 3168 to remove that interaction for ECT(1). The specific update to Section 5 of RFC 3168 is to replace the following two paragraphs:
このメモはRFC 3168を更新して、ECT（1）の相互作用を削除します。 RFC 3168のセクション5に対する具体的な更新は、次の2つの段落を置き換えることです。
Senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis.
送信者は、ECT（0）またはECT（1）コードポイントを使用して、パケットごとにECTを自由に示します。
The use of both the two codepoints for ECT, ECT(0) and ECT(1), is motivated primarily by the desire to allow mechanisms for the data sender to verify that network elements are not erasing the CE codepoint, and that data receivers are properly reporting to the sender the receipt of packets with the CE codepoint set, as required by the transport protocol. Guidelines for the senders and receivers to differentiate between the ECT(0) and ECT(1) codepoints will be addressed in separate documents, for each transport protocol. In particular, this document does not address mechanisms for TCP end-nodes to differentiate between the ECT(0) and ECT(1) codepoints. Protocols and senders that only require a single ECT codepoint SHOULD use ECT(0).
ECTの2つのコードポイントであるECT（0）とECT（1）の両方の使用は、ネットワーク要素がCEコードポイントを消去していないこと、およびデータレシーバーがトランスポートプロトコルの必要に応じて、CEコードポイントが設定されたパケットの受信を送信者に適切に報告します。送信者と受信者がECT（0）とECT（1）のコードポイントを区別するためのガイドラインは、トランスポートプロトコルごとに個別のドキュメントで扱われます。特に、このドキュメントでは、TCPエンドノードがECT（0）とECT（1）のコードポイントを区別するメカニズムについては扱いません。単一のECTコードポイントのみを必要とするプロトコルと送信者は、ECT（0）を使用する必要があります（SHOULD）。
with this paragraph:
この段落では：
Protocols and senders MUST use the ECT(0) codepoint to indicate ECT unless otherwise specified by an Experimental RFC in the IETF document stream. Protocols and senders MUST NOT use the ECT(1) codepoint to indicate ECT unless otherwise specified by an Experimental RFC in the IETF document stream. Guidelines for senders and receivers to differentiate between the ECT(0) and ECT(1) codepoints will be addressed in separate documents, for each transport protocol. In particular, this document does not address mechanisms for TCP end-nodes to differentiate between the ECT(0) and ECT(1) codepoints.
プロトコルと送信者は、IETFドキュメントストリームの実験的RFCで特に指定されていない限り、ECT（0）コードポイントを使用してECTを示す必要があります。プロトコルと送信者は、IETFドキュメントストリームの試験的RFCで特に指定されていない限り、ECT（1）コードポイントを使用してECTを示すことはできません。送信者と受信者がECT（0）とECT（1）のコードポイントを区別するためのガイドラインは、トランスポートプロトコルごとに個別のドキュメントで扱われます。特に、このドキュメントでは、TCPエンドノードがECT（0）とECT（1）のコードポイントを区別するメカニズムについては扱いません。
Congestion Marking Differences experiments SHOULD modify the network behavior for traffic marked as ECT(1) rather than ECT(0) if network behavior for only one ECT codepoint is modified. Congestion Marking Differences experiments MUST NOT modify the network behavior for traffic marked as ECT(0) in a fashion that requires changes to the sender congestion response to obtain desired network behavior. If a Congestion Marking Differences experiment modifies the network behavior for traffic marked as ECT(1), e.g., CE-marking behavior, in a fashion that requires changes to the sender congestion response to obtain desired network behavior, then the Experimental RFC in the IETF document stream for that experiment MUST specify:
輻輳マーキングの違いの実験では、ECTコードポイントのネットワーク動作が1つだけ変更された場合、ECT（0）ではなくECT（1）としてマークされたトラフィックのネットワーク動作を変更する必要があります。輻輳マーキングの違いの実験では、ECT（0）としてマークされたトラフィックのネットワーク動作を、目的のネットワーク動作を取得するために送信者の輻輳応答を変更する必要がある方法で変更してはなりません。 Congestion Marking Differences実験がECT（1）としてマークされたトラフィックのネットワーク動作、たとえばCEマーキング動作を変更して、望ましいネットワーク動作を取得するために送信者の輻輳応答を変更する必要がある場合、IETFの試験的RFCその実験のドキュメントストリームでは、以下を指定する必要があります。
o The sender congestion response to CE marking in the network, and
o ネットワーク内のCEマーキングに対する送信者の輻輳応答、および
o Router behavior changes, or the absence thereof, in forwarding CE-marked packets that are part of the experiment.
o 実験の一部であるCEマークの付いたパケットの転送において、ルーターの動作が変化するか、またはその欠如。
In addition, this memo updates RFC 3168 to remove discussion of the ECN nonce, as noted in Section 3 above.
さらに、このメモはRFC 3168を更新して、上記のセクション3で述べたように、ECNナンスの議論を削除します。
With the successful use of ECN for traffic in large portions of the Internet, there is interest in extending the benefits of ECN to TCP control packets (e.g., SYNs) and retransmitted packets, e.g., as proposed by ECN++ [ECN-TCP].
インターネットの大部分のトラフィックにECNをうまく使用することで、ECNの利点をTCP制御パケット（SYNなど）および再送信されたパケット（ECN ++ [ECN-TCP]で提案されているものなど）に拡張することに関心があります。
RFC 3168 prohibits use of ECN for TCP control packets and retransmitted packets in a number of places:
RFC 3168は、TCP制御パケットおよび再送信されたパケットに対するECNの使用をいくつかの場所で禁止しています。
o Section 5.2: "To ensure the reliable delivery of the congestion indication of the CE codepoint, an ECT codepoint MUST NOT be set in a packet unless the loss of that packet in the network would be detected by the end nodes and interpreted as an indication of congestion."
o セクション5.2：「CEコードポイントの輻輳表示の信頼性の高い配信を保証するために、ネットワーク内のそのパケットの損失がエンドノードによって検出され、混雑。」
o Section 6.1.1: "A host MUST NOT set ECT on SYN or SYN-ACK packets"
o セクション6.1.1：「ホストはSYNまたはSYN-ACKパケットにECTを設定してはならない」
o Section 6.1.4: "...pure acknowledgement packets (e.g., packets that do not contain any accompanying data) MUST be sent with the not-ECT codepoint."
o セクション6.1.4：「...純粋な確認応答パケット（たとえば、付随するデータを含まないパケット）は、ECT以外のコードポイントで送信する必要があります。」
o Section 6.1.5: "This document specifies ECN-capable TCP implementations MUST NOT set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for retransmitted data packets, and that the TCP data receiver SHOULD ignore the ECN field on arriving data packets that are outside of the receiver's current window."
o セクション6.1.5：「このドキュメントでは、ECN対応のTCP実装が、再送信されたデータパケットのIPヘッダーにECTコードポイント（ECT（0）またはECT（1））を設定してはならないこと、およびTCPデータレシーバーがECNを無視する必要があることを指定する必要があります。受信者の現在のウィンドウの外にある到着データパケットのフィールド。」
o Section 6.1.6: "...the TCP data sender MUST NOT set either an ECT codepoint or the CWR bit on window probe packets.
o セクション6.1.6：「... TCPデータ送信側は、ウィンドウプローブパケットにECTコードポイントまたはCWRビットを設定してはなりません（MUST NOT）。
This memo updates RFC 3168 to allow the use of ECT codepoints on SYN and SYN-ACK packets, pure acknowledgement packets, window probe packets, and retransmissions of packets that were originally sent with an ECT codepoint, provided that the changes from RFC 3168 are documented in an Experimental RFC in the IETF document stream. The specific change to RFC 3168 is to insert the words "unless otherwise specified by an Experimental RFC in the IETF document stream" at the end of each sentence quoted above.
このメモはRFC 3168を更新して、SYNおよびSYN-ACKパケット、純粋な確認応答パケット、ウィンドウプローブパケット、および元々ECTコードポイントで送信されたパケットの再送信でECTコードポイントを使用できるようにします（RFC 3168からの変更が文書化されている場合） IETFドキュメントストリームの試験的なRFCで。 RFC 3168への特定の変更は、上記で引用された各文の終わりに「IETFドキュメントストリームの実験的RFCで特に指定されていない限り」という単語を挿入することです。
In addition, beyond requiring TCP senders not to set ECT on TCP control packets and retransmitted packets, RFC 3168 is silent on whether it is appropriate for a network element, e.g., a firewall, to discard such a packet as invalid. For this area of ECN experimentation to be useful, middleboxes ought not to do that; therefore, RFC 3168 is updated by adding the following text to the end of Section 6.1.1.1 on Middlebox Issues:
さらに、TCP送信者がTCP制御パケットと再送信されたパケットにECTを設定しないよう要求するだけでなく、RFC 3168は、ファイアウォールなどのネットワーク要素がそのようなパケットを無効として破棄することが適切かどうかについては何も述べていません。 ECN実験のこの領域が有用であるためには、ミドルボックスはそれを行うべきではありません。したがって、ミドルボックスの問題に関するセクション6.1.1.1の最後に次のテキストを追加することにより、RFC 3168が更新されます。
Unless otherwise specified by an Experimental RFC in the IETF document stream, middleboxes SHOULD NOT discard TCP control packets and retransmitted TCP packets solely because the ECN field in the IP header does not contain Not-ECT. An exception to this requirement occurs in responding to an attack that uses ECN codepoints other than Not-ECT. For example, as part of the response, it may be appropriate to drop ECT-marked TCP SYN packets with higher probability than TCP SYN packets marked with Not-ECT. Any such exceptional discarding of TCP control packets and retransmitted TCP packets in response to an attack MUST NOT be done routinely in the absence of an attack and SHOULD only be done if it is determined that the use of ECN is contributing to the attack.
IETFドキュメントストリームの実験的RFCで特に指定されていない限り、IPヘッダーのECNフィールドにNot-ECTが含まれていないため、ミドルボックスはTCP制御パケットを破棄して再送信されないはずです。この要件の例外は、Not-ECT以外のECNコードポイントを使用する攻撃への応答で発生します。たとえば、応答の一部として、ECTでマークされたTCP SYNパケットを、Not-ECTでマークされたTCP SYNパケットよりも高い確率でドロップすることが適切な場合があります。攻撃に対するTCPコントロールパケットと再送信されたTCPパケットのこのような例外的な破棄は、攻撃がない場合は定期的に実行してはならず、ECNの使用が攻撃に寄与していると判断された場合にのみ実行する必要があります。
RFC 6679 [RFC6679] specifies use of ECN for RTP traffic; it allows use of both the ECT(0) and ECT(1) codepoints and provides the following guidance on use of these codepoints in Section 7.3.1:
RFC 6679 [RFC6679]は、RTPトラフィックに対するECNの使用を指定しています。 ECT（0）とECT（1）の両方のコードポイントの使用を許可し、セクション7.3.1でこれらのコードポイントの使用に関する次のガイダンスを提供します。
The sender SHOULD mark packets as ECT(0) unless the receiver expresses a preference for ECT(1) or for a random ECT value using the "ect" parameter in the "a=ecn-capable-rtp:" attribute.
送信者は、受信者が「a = ecn-capable-rtp：」属性の「ect」パラメーターを使用してECT（1）またはランダムなECT値の設定を表明しない限り、パケットをECT（0）としてマークする必要があります。
The Congestion Marking Differences area of experimentation increases the potential consequences of using ECT(1) instead of ECT(0); hence, the above guidance is updated by adding the following two sentences:
実験の「輻輳マーキングの違い」領域では、ECT（0）の代わりにECT（1）を使用した場合の潜在的な結果が増加します。したがって、上記のガイダンスは、次の2つの文を追加することによって更新されます。
Random ECT values MUST NOT be used, as that may expose RTP to differences in network treatment of traffic marked with ECT(1) and ECT(0) and differences in associated endpoint congestion responses. In addition, ECT(0) MUST be used unless otherwise specified in an Experimental RFC in the IETF document stream.
ランダムなECT値は使用しないでください。ECT（1）とECT（0）でマークされたトラフィックのネットワーク処理の違い、および関連するエンドポイントの輻輳応答の違いにRTPがさらされる可能性があるためです。さらに、ECT（0）は、IETFドキュメントストリームの試験的なRFCで特に指定されていない限り、使用する必要があります。
Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE-marked packets as being identical to the response to dropped packets:
RFC 6679のセクション7.3.3は、CEマークの付いたパケットの受信に対するRTPの応答が、ドロップされたパケットに対する応答と同一であることを指定しています。
The reception of RTP packets with ECN-CE marks in the IP header is a notification that congestion is being experienced. The default reaction on the reception of these ECN-CE-marked packets MUST be to provide the congestion control algorithm with a congestion notification that triggers the algorithm to react as if packet loss had occurred. There should be no difference in congestion response if ECN-CE marks or packet drops are detected.
IPヘッダーにECN-CEマークが付いたRTPパケットを受信すると、輻輳が発生していることが通知されます。これらのECN-CEマークの付いたパケットの受信に対するデフォルトの反応は、輻輳制御アルゴリズムに、パケット損失が発生したかのようにアルゴリズムが反応するようにトリガーする輻輳通知を提供するものでなければなりません（MUST）。 ECN-CEマークまたはパケットドロップが検出された場合、輻輳応答に違いはありません。
In support of Congestion Response Differences experimentation, this memo updates this text in a fashion similar to RFC 3168 to allow the RTP congestion control response to a CE-marked packet to differ from the response to a dropped packet, provided that the changes from RFC 6679 are documented in an Experimental RFC in the IETF document stream. The specific change to RFC 6679 is to insert the words "Unless otherwise specified by an Experimental RFC in the IETF document stream" and reformat the last two sentences to be subject to that condition; that is:
輻輳応答の違いの実験をサポートするため、このメモはRFC 3168と同様の方法でこのテキストを更新し、CEマークの付いたパケットへのRTP輻輳制御応答が、ドロップされたパケットへの応答と異なるようにします（RFC 6679からの変更がある場合） IETFドキュメントストリームの試験的RFCに記載されています。 RFC 6679に対する特定の変更は、「IETFドキュメントストリームの実験的RFCによって特に指定されていない限り」という単語を挿入し、最後の2つの文をその条件の対象となるように再フォーマットすることです。あれは：
The reception of RTP packets with ECN-CE marks in the IP header is a notification that congestion is being experienced. Unless otherwise specified by an Experimental RFC in the IETF document stream:
IPヘッダーにECN-CEマークが付いたRTPパケットを受信すると、輻輳が発生していることが通知されます。 IETFドキュメントストリームの試験的なRFCで特に指定されていない限り：
* The default reaction on the reception of these ECN-CE-marked packets MUST be to provide the congestion control algorithm with a congestion notification that triggers the algorithm to react as if packet loss had occurred.
* これらのECN-CEマークの付いたパケットの受信に対するデフォルトの反応は、輻輳制御アルゴリズムに、パケット損失が発生したかのようにアルゴリズムが反応するようにトリガーする輻輳通知を提供するものでなければなりません（MUST）。
* There should be no difference in congestion response if ECN-CE marks or packet drops are detected.
* ECN-CEマークまたはパケットドロップが検出された場合、輻輳応答に違いはありません。
The second sentence of the immediately following paragraph in Section 7.3.3 of RFC 6679 requires a related update:
RFC 6679のセクション7.3.3の直後の段落の2番目の文には、関連する更新が必要です。
Other reactions to ECN-CE may be specified in the future, following IETF Review. Detailed designs of such alternative reactions MUST be specified in a Standards Track RFC and be reviewed to ensure they are safe for deployment under any restrictions specified.
ECN-CEに対する他の反応は、IETFレビューに従って、将来指定される可能性があります。そのような代替反応の詳細な設計は、Standards Track RFCで指定する必要があり、指定された制限の下で展開しても安全であることを確認するためにレビューする必要があります。
The update is to change "Standards Track RFC" to "Standards Track RFC or Experimental RFC in the IETF document stream" for consistency with the first update.
更新では、最初の更新との整合性を保つために、「Standards Track RFC」を「Standards Track RFCまたはIETF document streamのExperimental RFC」に変更します。
The specifications of the three DCCP Congestion Control IDs (CCIDs), 2 [RFC4341], 3 [RFC4342], and 4 [RFC5622], contain broadly the same wording as follows:
3つのDCCP輻輳制御ID（CCID）、2 [RFC4341]、3 [RFC4342]、および4 [RFC5622]の仕様には、以下と同じ表現が広く含まれています。
each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable with either the ECT(0) or the ECT(1) codepoint set.
各DCCP-DataおよびDCCP-DataAckパケットは、ECT（0）またはECT（1）コードポイントセットのいずれかを備えたECN対応として送信されます。
This memo updates these sentences in each of the three RFCs as follows:
このメモは、3つのRFCのそれぞれでこれらの文を次のように更新します。
each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable. Unless otherwise specified by an Experimental RFC in the IETF document stream, such DCCP senders MUST set the ECT(0) codepoint.
各DCCP-DataおよびDCCP-DataAckパケットはECN対応として送信されます。 IETFドキュメントストリームの試験的なRFCで特に指定されていない限り、そのようなDCCP送信者はECT（0）コードポイントを設定する必要があります。
In support of Congestion Marking Differences experimentation (as noted in Section 3), this memo also updates all three of these RFCs to remove discussion of the ECN nonce. The specific text updates are omitted for brevity.
（セクション3で述べたように）輻輳マーキングの違いの実験をサポートするために、このメモはこれらのRFCの3つすべてを更新して、ECNナンスの議論を削除します。特定のテキストの更新は簡潔にするために省略されています。
To reflect the reclassification of RFC 3540 as Historic, IANA has updated the "Transmission Control Protocol (TCP) Header Flags" registry <https://www.iana.org/assignments/tcp-header-flags> to remove the registration of bit 7 as the NS (Nonce Sum) bit and add an annotation to the registry to state that bit 7 was used by Historic RFC 3540 as the NS (Nonce Sum) bit but is now Reserved.
RFC 3540の歴史的な再分類を反映するために、IANAは「Transmission Control Protocol（TCP）Header Flags」レジストリ<https://www.iana.org/assignments/tcp-header-flags>を更新して、ビットの登録を削除しましたNS（ノンスサム）ビットとして7を追加し、ビット7が歴史的RFC 3540によってNS（ノンスサム）ビットとして使用されたが、現在は予約されていることを示す注釈をレジストリに追加します。
As a process memo that only relaxes restrictions on experimentation, there are no protocol security considerations, as security considerations for any experiments that take advantage of the relaxed restrictions are discussed in the documents that propose the experiments.
実験の制限を緩和するだけのプロセスメモとして、緩和された制限を利用する実験のセキュリティに関する考慮事項が実験を提案するドキュメントで説明されているため、プロトコルのセキュリティに関する考慮事項はありません。
However, effective congestion control is crucial to the continued operation of the Internet; hence, this memo places the responsibility for not breaking Internet congestion control on the experiments and the experimenters who propose them. This responsibility includes the requirement to discuss congestion control implications in an Experimental RFC in the IETF document stream for each experiment, as stated in Section 2.1; review of that discussion by the IETF community and the IESG prior to RFC publication is intended to provide assurance that each experiment does not break Internet congestion control.
ただし、インターネットの継続的な運用には、効果的な輻輳制御が不可欠です。したがって、このメモは、実験とそれらを提案する実験者にインターネットの輻輳制御を壊さない責任を負います。この責任には、セクション2.1で述べたように、各実験のIETFドキュメントストリームの実験的RFCで輻輳制御の影響を議論する要件が含まれます。 RFCの公開に先立ってIETFコミュニティとIESGによるその議論を検討することは、各実験がインターネットの輻輳制御を壊さないことを保証することを目的としています。
See Appendix C.1 of [ECN-L4S] for discussion of alternatives to the ECN nonce.
ECN nonceの代替案については、[ECN-L4S]の付録C.1を参照してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.
[RFC2914]フロイド、S。、「輻輳制御原則」、BCP 41、RFC 2914、DOI 10.17487 / RFC2914、2000年9月、<https://www.rfc-editor.org/info/rfc2914>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https：// www。 rfc-editor.org/info/rfc3168>。
[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>.
[RFC3540] Spring、N.、Wetherall、D。、およびD. Ely、「Ronce Explicit Congestion Notification（ECN）Signaling with Nonces」、RFC 3540、DOI 10.17487 / RFC3540、2003年6月、<https：//www.rfc -editor.org/info/rfc3540>。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2006, <https://www.rfc-editor.org/info/rfc4341>.
[RFC4341] Floyd、S。およびE. Kohler、「Profile for Datagram Congestion Control Protocol（DCCP）Congestion Control ID 2：TCP-like Congestion Control」、RFC 4341、DOI 10.17487 / RFC4341、2006年3月、<https：// www.rfc-editor.org/info/rfc4341>。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, <https://www.rfc-editor.org/info/rfc4342>.
[RFC4342] Floyd、S.、Kohler、E.、J。Padhye、「Profile for Datagram Congestion Control Protocol（DCCP）Congestion Control ID 3：TCP-Friendly Rate Control（TFRC）」、RFC 4342、DOI 10.17487 / RFC4342 、2006年3月、<https://www.rfc-editor.org/info/rfc4342>。
[RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, DOI 10.17487/RFC5622, August 2009, <https://www.rfc-editor.org/info/rfc5622>.
[RFC5622]フロイド、S。およびE.コーラー、「Profile for Datagram Congestion Control Protocol（DCCP）Congestion ID 4：TCP-Friendly Rate Control for Small Packets（TFRC-SP）」、RFC 5622、DOI 10.17487 / RFC5622、8月2009、<https://www.rfc-editor.org/info/rfc5622>。
[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>.
[RFC6679] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「RTP over UDPの明示的輻輳通知（ECN）」、RFC 6679、DOI 10.17487 / RFC6679 、2012年8月、<https://www.rfc-editor.org/info/rfc6679>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[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-09, July 2017.
[ECN-ENCAP] Briscoe、B.、Kaippallimalil、J。、およびP. Thaler、「IPをカプセル化するプロトコルに輻輳通知を追加するためのガイドライン」、作業中、draft-ietf-tsvwg-ecn-encap-guidelines-09 、2017年7月。
[ECN-EXPERIMENT] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, "Updating the Explicit Congestion Notification (ECN) Specification to Allow IETF Experimentation", Work in Progress, draft-khademi-tsvwg-ecn-response-01, July 2016.
[ECN-EXPERIMENT] Khademi、N.、Welzl、M.、Armitage、G。、およびG. Fairhurst、「IETF実験を許可するための明示的な輻輳通知（ECN）仕様の更新」、進行中の作業、draft-khademi-tsvwg -ecn-response-01、2016年7月。
[ECN-L4S] Schepper, K. and B. Briscoe, "Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay", Work in Progress, draft-ietf-tsvwg-ecn-l4s-id-01, October 2017.
[ECN-L4S] Schepper、K。、およびB. Briscoe、「超低キュー遅延の変更された明示的輻輳通知（ECN）セマンティクスの特定」、作業中、draft-ietf-tsvwg-ecn-l4s-id-01、 2017年10月。
[ECN-SHIM] Briscoe, B., "Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim", Work in Progress, draft-ietf-tsvwg-rfc6040update-shim-05, November 2017.
[ECN-SHIM] Briscoe、B。、「Shimで区切られたIPトンネルヘッダーを介した明示的な輻輳通知の伝播」、作業中、draft-ietf-tsvwg-rfc6040update-shim-05、2017年11月。
[ECN-TCP] Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets", Work in Progress, draft-ietf-tcpm-generalized-ecn-02, October 2017.
[ECN-TCP] Bagnulo、M。、およびB. Briscoe、「ECN ++：Adding Explicit Congestion Notification（ECN）to TCP Control Packets」、Work in Progress、draft-ietf-tcpm-generalized-ecn-02、2017年10月。
[ECN-TRILL] Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit Congestion Notification) Support", Work in Progress, draft-ietf-trill-ecn-support-04, November 2017.
[ECN-TRILL]イーストレイク、D。およびB.ブリスコ、「TRILL：ECN（Explicit Congestion Notification）Support」、Work in Progress、draft-ietf-trill-ecn-support-04、2017年11月。
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, <https://www.rfc-editor.org/info/rfc4774>.
[RFC4774]フロイドS.、「明示的輻輳通知（ECN）フィールドの代替セマンティクスの指定」、BCP 124、RFC 4774、DOI 10.17487 / RFC4774、2006年11月、<https://www.rfc-editor.org/ info / rfc4774>。
[RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, July 2007, <https://www.rfc-editor.org/info/rfc4844>.
[RFC4844]ダイグル、L。、エド。およびインターネットアーキテクチャボード、「The RFC Series and RFC Editor」、RFC 4844、DOI 10.17487 / RFC4844、2007年7月、<https://www.rfc-editor.org/info/rfc4844>。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <https://www.rfc-editor.org/info/rfc5706>.
[RFC5706]ハリントン、D。、「新しいプロトコルとプロトコル拡張の操作と管理を考慮するためのガイドライン」、RFC 5706、DOI 10.17487 / RFC5706、2009年11月、<https://www.rfc-editor.org/info/rfc5706 >。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC6040] Briscoe、B。、「Tunnelling of Explicit Congestion Notification」、RFC 6040、DOI 10.17487 / RFC6040、2010年11月、<https://www.rfc-editor.org/info/rfc6040>。
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 10.17487/RFC6660, July 2012, <https://www.rfc-editor.org/info/rfc6660>.
[RFC6660] Briscoe、B.、Moncaster、T。、およびM. Menth、「単一のDiffservコードポイント（DSCP）を使用したIPヘッダー内の3つの事前輻輳通知（PCN）状態のエンコード」、RFC 6660、DOI 10.17487 / RFC6660 、2012年7月、<https://www.rfc-editor.org/info/rfc6660>。
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., and G. Judd, "Data Center TCP (DCTCP): TCP Congestion Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[RFC8257]ベンズリー、S。、ターラー、D。、バラブラマニアン、P。、エガート、L。、およびG.ジャッド、「Data Center TCP（DCTCP）：TCP Congestion Control for Data Centers」、RFC 8257、DOI 10.17487 / RFC8257、2017年10月、<https://www.rfc-editor.org/info/rfc8257>。
[TCP-ABE] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, "TCP Alternative Backoff with ECN (ABE)", Work in Progress, draft-ietf-tcpm-alternativebackoff-ecn-05, December 2017.
[TCP-ABE] Khademi、N.、Welzl、M.、Armitage、G。、およびG. Fairhurst、「ECN（ABE）によるTCP代替バックオフ」、作業中、draft-ietf-tcpm-alternativebackoff-ecn- 2017年12月5日。
[Trammell15] Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., Fairhurst, G., and R. Scheffenegger, "Enabling Internet-Wide Deployment of Explicit Congestion Notification", In Conference Proceedings of Passive and Active Measurement (PAM), pp. 193-205, March 2015, <https://doi.org/10.1007/978-3-319-15509-8_15>.
[Trammell15] Trammell、B.、Kuehlewind、M.、Boppart、D.、Learmonth、I.、Fairhurst、G.、and R. Scheffenegger、 "Enabling Internet-Wide Deployment of Explicit Congestion Notifications"、Conference Proceedings of PassiveおよびActive Measurement（PAM）、pp。193-205、2015年3月、<https://doi.org/10.1007/978-3-319-15509-8_15>。
Acknowledgements
謝辞
The content of this specification, including the specific portions of RFC 3168 that are updated, draws heavily from [ECN-EXPERIMENT], whose authors are gratefully acknowledged. The authors of the documents describing the experiments have motivated the production of this memo -- their interest in innovation is welcome and heartily acknowledged. Colin Perkins suggested updating RFC 6679 on RTP and provided guidance on where to make the updates.
更新されたRFC 3168の特定の部分を含むこの仕様の内容は、[ECN-EXPERIMENT]から大きく引用されており、その作者に感謝の意を表します。実験について説明しているドキュメントの作成者は、このメモの作成に動機を与えています。イノベーションへの関心は歓迎され、心から認められています。 Colin Perkinsは、RTPでRFC 6679を更新することを提案し、更新を行う場所に関するガイダンスを提供しました。
This specification improved as a result of comments from a number of reviewers, including Ben Campbell, Brian Carpenter, Benoit Claise, Spencer Dawkins, Gorry Fairhurst, Sue Hares, Ingemar Johansson, Naeem Khademi, Mirja Kuehlewind, Karen Nielsen, Hilarie Orman, Eric Rescorla, Adam Roach, and Michael Welzl. Bob Briscoe's thorough review of multiple draft versions of this memo resulted in numerous improvements including addition of the updates to the DCCP RFCs.
この仕様は、Ben Campbell、Brian Carpenter、Benoit Claise、Spencer Dawkins、Gorry Fairhurst、Sue Hares、Ingemar Johansson、Naeem Khademi、Mirja Kuehlewind、Karen Nielsen、Hirarie Orman、Eric Rescorlaを含む多くのレビュアーからのコメントの結果として改善されました、アダム・ローチ、マイケル・ウェルズル。 Bob Briscoeがこのメモの複数のドラフトバージョンを徹底的にレビューした結果、DCCP RFCへの更新の追加など、多くの改善が行われました。
Author's Address
著者のアドレス
David Black Dell EMC 176 South Street Hopkinton, MA 01748 United States of America
デビッドブラックDell EMC 176サウスストリートホプキントン、MA 01748アメリカ合衆国
Email: david.black@dell.com