[要約] RFC 7713は、Congestion Exposure（ConEx）の概念、抽象メカニズム、および要件に関するドキュメントです。このRFCの目的は、ネットワークの過負荷状態を検出し、制御するためのフレームワークを提供することです。
Internet Engineering Task Force (IETF) M. Mathis
Request for Comments: 7713 Google, Inc.
Category: Informational B. Briscoe
ISSN: 2070-1721 BT
December 2015
Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements
輻輳露出（ConEx）の概念、抽象的なメカニズム、および要件
Abstract
概要
This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by Explicit Congestion Notification (ECN) markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called Congestion Exposure, or ConEx. The companion document, "Congestion Exposure (ConEx) Concepts and Use Cases" (RFC 6789), provides the entry point to the set of ConEx documentation.
このドキュメントでは、同じフローのパケットが最近遭遇した輻輳について送信者がネットワークに通知する抽象的なメカニズムについて説明します。今日、任意の層のネットワーク要素は、パケットをドロップするか、明示的輻輳通知（ECN）マーキングによって受信者に輻輳を通知し、受信者はこの情報をトランスポート層フィードバックで送信者に返します。ここで説明するメカニズムにより、送信者はこの輻輳情報をIP層で帯域内のネットワークに中継して戻すことができるため、パス上のすべての要素からの輻輳の総量が、パス上のすべてのIP要素に明らかになり、たとえば、トラフィック管理への入力を提供するために使用できます。このメカニズムは、Congestion ExposureまたはConExと呼ばれます。関連ドキュメント「Congestion Exposure（ConEx）Concepts and Use Cases」（RFC 6789）は、ConExドキュメントのセットへのエントリポイントを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7713.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7713で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements for the ConEx Abstract Mechanism . . . . . . . . 7
3.1. Requirements for ConEx Signals . . . . . . . . . . . . . 7
3.2. Constraints on the Audit Function . . . . . . . . . . . . 8
3.3. Requirements for Non-abstract ConEx Specifications . . . 9
4. Encoding Congestion Exposure . . . . . . . . . . . . . . . . 12
4.1. Naive Encoding . . . . . . . . . . . . . . . . . . . . . 12
4.2. Null Encoding . . . . . . . . . . . . . . . . . . . . . . 13
4.3. ECN-Based Encoding . . . . . . . . . . . . . . . . . . . 13
4.4. Independent Bits . . . . . . . . . . . . . . . . . . . . 14
4.5. Codepoint Encoding . . . . . . . . . . . . . . . . . . . 14
4.6. Units Implied by an Encoding . . . . . . . . . . . . . . 15
5. Congestion Exposure Components . . . . . . . . . . . . . . . 16
5.1. Network Devices (Not Modified) . . . . . . . . . . . . . 16
5.2. Modified Senders . . . . . . . . . . . . . . . . . . . . 16
5.3. Receivers (Optionally Modified) . . . . . . . . . . . . . 17
5.4. Policy Devices . . . . . . . . . . . . . . . . . . . . . 17
5.4.1. Congestion Monitoring Devices . . . . . . . . . . . . 18
5.4.2. Rest-of-Path Congestion Monitoring . . . . . . . . . 18
5.4.3. Congestion Policers . . . . . . . . . . . . . . . . . 18
5.5. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Support for Incremental Deployment . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
This document describes an abstract mechanism by which, to a first approximation, senders inform the network about the congestion encountered by packets earlier in the same flow. It is not a complete protocol specification because it is known that designing an encoding (e.g., packet formats, codepoint allocations, etc.) is likely to entail compromises that preclude some uses of the protocol. The goal of this document is to provide a framework for developing and testing algorithms to evaluate the benefits of the ConEx protocol and to evaluate the consequences of the compromises in various different encoding designs. This document lays out requirements for concrete protocol specifications.
このドキュメントでは、最初の近似として、送信者が同じフローの早い段階でパケットが遭遇した輻輳についてネットワークに通知する抽象的なメカニズムについて説明します。エンコーディング（パケット形式、コードポイントの割り当てなど）の設計は、プロトコルの一部の使用を妨げる妥協を伴う可能性が高いことが知られているため、完全なプロトコル仕様ではありません。このドキュメントの目的は、アルゴリズムを開発およびテストして、ConExプロトコルの利点を評価し、さまざまな異なるエンコーディング設計における妥協の結果を評価するためのフレームワークを提供することです。このドキュメントでは、具体的なプロトコル仕様の要件について説明します。
A companion document [RFC6789] provides the entry point to the set of ConEx documentation. It outlines concepts that are prerequisites to understanding why ConEx is useful, and it outlines various ways that ConEx might be used.
関連ドキュメント[RFC6789]は、ConExドキュメントのセットへのエントリポイントを提供します。 ConExが有用である理由を理解するための前提条件である概念の概要と、ConExが使用されるさまざまな方法の概要を示します。
As typical end-to-end transport protocols continually seek out more network capacity, network elements signal whenever congestion results, and the transports are responsible for controlling this network congestion [RFC5681]. The more a transport tries to use capacity that others want to use, the more congestion signals will be attributable to that transport. Likewise, the more transport sessions sustained by a user and the longer the user sustains them, the more congestion signals will be attributable to that user. The goal of ConEx is to ensure that the resulting congestion signals are sufficiently visible and robust, because they are an ideal metric for networks to use as the basis of traffic management or other related functions.
典型的なエンドツーエンドトランスポートプロトコルは継続的にさらに多くのネットワーク容量を探し出すため、ネットワーク要素は輻輳が発生するたびに信号を送り、トランスポートはこのネットワーク輻輳の制御を担当します[RFC5681]。トランスポートが他のユーザーが使用したい容量を使用しようとするほど、そのトランスポートに起因する輻輳信号が多くなります。同様に、ユーザーが維持するトランスポートセッションが多いほど、またユーザーがセッションを維持する時間が長いほど、そのユーザーに起因する輻輳信号が多くなります。 ConExの目的は、ネットワークがトラフィック管理やその他の関連機能の基礎として使用するための理想的なメトリックであるため、結果として生じる輻輳信号が十分に可視的で堅牢であることを確認することです。
Networks indicate congestion by three possible signals: packet loss, ECN marking, or queueing delay. ECN marking and some packet loss may be the outcome of Active Queue Management (AQM), which the network uses to warn senders to reduce their rates. Packet loss is also the natural consequence of complete exhaustion of a buffer or other network resource. Some experimental transport protocols and TCP variants infer impending congestion from increasing queuing delay. However, delay is too amorphous to use as a congestion metric. In this and other ConEx documents, the term 'congestion signals' is generally used solely for ECN markings and packet losses because they are unambiguous signals of congestion.
ネットワークは、3つの可能な信号（パケット損失、ECNマーキング、またはキューイング遅延）によって輻輳を示します。 ECNマーキングと一部のパケット損失は、ネットワークが送信者に警告してレートを下げるために使用するアクティブキュー管理（AQM）の結果である可能性があります。パケット損失は、バッファまたはその他のネットワークリソースが完全に使い果たされることの当然の結果でもあります。一部の実験的なトランスポートプロトコルとTCPバリアントは、キューイング遅延の増加から近い将来の輻輳を推測します。ただし、遅延は混雑メトリックとして使用するには不定形です。このドキュメントおよび他のConExドキュメントでは、「輻輳信号」という用語は、ECNマーキングとパケット損失のために一般的に使用されています。これは、輻輳の明確な信号であるためです。
In both cases, the congestion signals follow the route indicated in Figure 1. A congested network device sends a signal in the data stream on the forward path to the transport receiver, the receiver passes it back to the sender through transport-level feedback, and the sender makes some congestion control adjustment.
どちらの場合も、輻輳信号は図1に示すルートに従います。輻輳したネットワークデバイスは、転送パス上のデータストリームで信号をトランスポートレシーバーに送信し、レシーバーはトランスポートレベルのフィードバックを介して送信者に信号を渡します。送信者はいくつかの輻輳制御調整を行います。
This document extends the capabilities of the Internet protocol suite with the addition of a new Congestion Exposure signal. To a first approximation, this signal (also shown in Figure 1) relays the congestion information from the transport sender back through the internetwork layer where it is visible to any interested internetwork-layer devices along the forward path. This document frames the engineering problem of designing the ConEx Signal. The requirements are described in Section 3 and some example encodings are presented in Section 4. Section 5 describes all of the protocol components.
このドキュメントでは、新しいCongestion Exposure信号を追加して、インターネットプロトコルスイートの機能を拡張しています。最初の概算では、この信号（図1にも示されています）は、トランスポート送信者からの輻輳情報を中継ネットワークを通じて中継し、フォワードパスに沿った関心のあるすべてのインターネットネットワーク層デバイスに表示されます。このドキュメントでは、ConEx信号を設計する際のエンジニアリング上の問題について説明します。要件はセクション3で説明されており、エンコーディングの例はセクション4で示されています。セクション5では、すべてのプロトコルコンポーネントについて説明します。
This new signal is expressly designed to support a variety of new policy mechanisms that might be used to instrument, monitor, or manage traffic. The policy devices are not shown in Figure 1 but might be placed anywhere along the forward data path (see Section 5.4).
この新しい信号は、トラフィックの計測、監視、または管理に使用できるさまざまな新しいポリシーメカニズムをサポートするように明示的に設計されています。ポリシーデバイスは図1には示されていませんが、転送データパスに沿ってどこにでも配置できます（セクション5.4を参照）。
,---------. ,---------.
|Transport| |Transport|
| Sender | . |Receiver |
| | /|___________________________________________| |
| ,-<---------------Congestion-Feedback-Signals--<--------. |
| | |/ | | |
| | |\ Transport Layer Feedback Flow | | |
| | | \ ___________________________________________| | |
| | | \| | | |
| | | ' ,-----------. . | | |
| | |_____________| |_______________|\ | | |
| | | IP Layer | | Data Flow \ | | |
| | | |(Congested)| \ | | |
| | | | Network |--Congestion-Signals--->-' |
| | | | Device | \| |
| | | | | /| |
| `----------->--(new)-IP-Layer-ConEx-Signals-------->| |
| | | | / | |
| |_____________| |_______________ / | |
| | | | |/ | |
`---------' `-----------' ' `---------'
Figure 1: The Flow of Congestion and ConEx Signals
図1：輻輳とConEx信号のフロー
Since the policy devices can affect how traffic is treated, it is assumed that there is an intrinsic motivation for users, applications, or operating systems to understate the congestion that they are causing. Therefore, it is important to be able to audit ConEx Signals and to be able to apply sufficient sanction to discourage cheating of congestion policies. The general approach to auditing is to count signals on the forward path to confirm that there are never fewer ConEx Signals than congestion signals. Many ConEx design constraints come from the need to assure that the audit function is sufficiently robust. The audit function is described in Section 5.5; however, significant portions of this document (and prior research [Refb-dis]) are motivated by issues relating to the audit function and making it robust.
ポリシーデバイスはトラフィックの処理方法に影響を与える可能性があるため、ユーザー、アプリケーション、またはオペレーティングシステムには、それらが引き起こしている輻輳を過小評価する本質的な動機があると想定されます。したがって、ConExシグナルを監査できること、および輻輳ポリシーの不正行為を阻止するために十分な制裁を適用できることが重要です。監査の一般的な方法は、フォワードパス上の信号をカウントして、輻輳信号よりもConEx信号の数が少ないことはないことを確認することです。多くのConEx設計の制約は、監査機能が十分に堅牢であることを保証する必要から生じます。監査機能については、セクション5.5で説明します。ただし、このドキュメントの重要な部分（および以前の調査[Refb-dis]）は、監査機能に関連する問題によって動機付けられ、監査機能を堅牢にします。
The congestion and ConEx Signals shown in Figure 1 represent a series of discrete events: ECN marks or lost packets, carried by the forward data stream and fed back into the internetwork layer. The policy and audit functions are most likely to act on the accumulated values of these signals, for which we use the term "volume". For example, "traffic volume" is the total number of bytes delivered optionally over a specified time interval and over some aggregate of traffic (e.g., all traffic from a site), while "loss volume" is the total amount of bytes discarded from some aggregate over an interval. The term "congestion-volume" is defined precisely in [RFC6789]. Note that volume per unit time is average rate.
図1に示されている輻輳とConEx信号は、一連の個別のイベントを表しています。ECNマークまたはパケットの損失は、転送データストリームによって伝送され、インターネットワークレイヤーにフィードバックされます。ポリシーおよび監査機能は、これらの信号の累積値に作用する可能性が最も高く、そのために「ボリューム」という用語を使用します。たとえば、「トラフィック量」は、指定された時間間隔およびトラフィックの一部の集計（サイトからのすべてのトラフィックなど）でオプションで配信されたバイトの合計数ですが、「損失量」は、一部から破棄されたバイトの合計量です間隔で集計します。 「輻輳ボリューム」という用語は、[RFC6789]で正確に定義されています。単位時間あたりのボリュームは平均レートであることに注意してください。
A design goal of the ConEx protocol is that the important policy mechanisms can be implemented per logical link without per-flow state (see Section 5.4). However, the trade-off is that per-flow state could be needed to audit ConEx Signals (Section 5.5). This is justified in that i) auditing at the edges, with a limited number of flows, enables policy elsewhere, including in the core, without any per-flow state; ii) auditing can use soft flow state, which does not require route pinning.
ConExプロトコルの設計目標は、重要なポリシーメカニズムをフローごとの状態なしで論理リンクごとに実装できることです（セクション5.4を参照）。ただし、トレードオフは、フローごとの状態がConEx信号を監査するために必要になる可能性があることです（セクション5.5）。これは、i）フローの数が制限されたエッジでの監査により、フローごとの状態なしに、コアを含む他の場所でポリシーを有効にするという点で正当化されます。 ii）監査では、ルートの固定を必要としないソフトフロー状態を使用できます。
There is a long standing argument over units of congestion: bytes vs packets (see [RFC7141] and its references). Section 4.6 explains why this problem must be addressed carefully. However, this document does not take a strong position on this issue. Nonetheless, it does require that the units of congestion must be an explicitly stated property of any proposed encoding, and the consequences of that design decision must be evaluated along with other aspects of the design.
輻輳の単位については長年の議論があります：バイト対パケット（[RFC7141]とそのリファレンスを参照）。セクション4.6では、この問題に慎重に対処する必要がある理由を説明しています。ただし、このドキュメントでは、この問題について強い立場を示していません。それにもかかわらず、輻輳の単位は、提案されたエンコーディングの明示的に記述されたプロパティでなければならず、その設計決定の結果は、設計の他の側面と一緒に評価する必要があります。
To be successful, the ConEx protocol needs to have the property that the relevant stakeholders each have the incentive to unilaterally start on each stage of partial deployment, which in turn creates incentives for further deployment. Furthermore, legacy systems that will never be upgraded do not become a barrier to deploying ConEx. Issues relating to partial deployment are described in Section 6.
成功するためには、ConExプロトコルには、関係する各利害関係者が部分的な展開の各段階で一方的に開始するインセンティブを持ち、それがさらに展開のインセンティブを生み出すという特性が必要です。さらに、決してアップグレードされないレガシーシステムは、ConExの展開の障害にはなりません。部分展開に関する問題については、セクション6で説明します。
Note that ConEx Signals are not intended to be used for fine-grained congestion control. They are anticipated to be most useful at longer time scales and/or at coarser granularity than single microflows. For example, the total congestion caused by a user might serve as an input to higher-level policy or accountability functions designed to create incentives for improving user behavior, such as choosing to send large quantities of data at off-peak times, at lower data rates, or with less aggressive protocols such as Low Extra Delay Background Transport (LEDBAT) [RFC6817]; see [RFC6789].
ConEx信号は、きめ細かい輻輳制御に使用することを意図していないことに注意してください。それらは、単一のマイクロフローよりも長い時間スケールおよび/または粗い粒度で最も有用であると予想されます。たとえば、ユーザーによって引き起こされた総混雑は、より低いレベルのデータでオフピーク時に大量のデータを送信することを選択するなど、ユーザーの行動を改善するためのインセンティブを作成するように設計された高レベルのポリシーまたはアカウンタビリティ機能への入力として機能する可能性がありますレート、または低エクストラ遅延バックグラウンドトランスポート（LEDBAT）[RFC6817]などのそれほど積極的ではないプロトコル。 [RFC6789]を参照してください。
Ultimately, ConEx Signals have the potential to provide a mechanism to regulate global Internet congestion. From the earliest days of research on congestion control, there has been a concern that there is no mechanism to prevent transport designers from incrementally making protocols more aggressive without bound and spiraling to a "tragedy of the commons" Internet congestion collapse. The "TCP friendly" paradigm was created in part to forestall this failure. However, it no longer commands any authority because it has little to say about the Internet of today, which has moved beyond the scaling range of standard TCP. As a consequence, many transports and applications are opening arbitrarily large numbers of connections or using arbitrary levels of aggressiveness. ConEx represents a recognition that the IETF cannot regulate this space directly because it concerns the behaviour of users and applications, not individual transport protocols. Instead, the IETF can give network operators the protocol tools to arbitrate the space themselves with better bulk traffic management. This, in turn, should create incentives for users and designers of applications and of transport protocols to be more mindful about contributing to congestion.
最終的に、ConExシグナルは、グローバルなインターネットの輻輳を調整するメカニズムを提供する可能性があります。輻輳制御に関する研究の最初の頃から、トランスポートの設計者がプロトコルを段階的に攻撃的にして、「コモンズの悲劇」のインターネット輻輳の崩壊に束縛され、急上昇するのを防ぐメカニズムがないという懸念がありました。 「TCPフレンドリー」パラダイムは、この失敗を未然に防ぐために一部作成されました。ただし、標準のTCPのスケーリング範囲を超えた今日のインターネットについてはほとんど言及していないため、もはや権限を命令しません。その結果、多くのトランスポートとアプリケーションが任意の数の接続を開いたり、任意のレベルの積極性を使用したりしています。 ConExは、IETFが個々のトランスポートプロトコルではなく、ユーザーとアプリケーションの動作に関係するため、このスペースを直接規制できないという認識を表しています。代わりに、IETFは、ネットワークオペレーターに、より適切なバルクトラフィック管理を使用してスペース自体を調停するためのプロトコルツールを提供できます。これにより、アプリケーションとトランスポートプロトコルのユーザーと設計者が、輻輳の発生に注意を払うようになるインセンティブが生まれます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
ConEx Signals in IP packet headers from the sender to the network:
送信者からネットワークへのIPパケットヘッダーのConEx信号：
Not-ConEx: The transport (or at least this packet) is not using ConEx.
Not-ConEx：トランスポート（または少なくともこのパケット）はConExを使用していません。
ConEx-Capable: The transport is using ConEx. This is the opposite of Not-ConEx.
ConEx対応：トランスポートはConExを使用しています。これはNot-ConExの反対です。
ConEx Signal: A signal in a packet sent by a ConEx-capable transport. It carries at least one of the following signals:
ConEx信号：ConEx対応トランスポートによって送信されたパケット内の信号。次の信号の少なくとも1つを伝送します。
Re-Echo-Loss: The transport has experienced a loss.
Re-Echo-Loss：トランスポートは損失を経験しました。
Re-Echo-ECN: The transport has detected an ECN Congestion Experienced (CE) mark.
Re-Echo-ECN：トランスポートはECN Congestion Experienced（CE）マークを検出しました。
Credit: The transport is building up credit to signal advance notice of the risk of packets contributing to congestion, in contrast to signalling only after inherently delayed feedback of actual congestion.
クレジット：実際の輻輳の本質的に遅延したフィードバックの後にのみ信号を送るのとは対照的に、トランスポートは、輻輳に寄与するパケットのリスクの事前通知を知らせるためにクレジットを増やしています。
ConEx-Not-Marked: The transport is ConEx-capable but is not signaling Re-Echo-Loss, Re-Echo-ECN, or Credit.
ConEx-Not-Marked：トランスポートはConEx対応ですが、Re-Echo-Loss、Re-Echo-ECN、またはCreditを通知していません。
ConEx-Marked: At least one of Re-Echo-Loss, Re-Echo-ECN, or Credit.
ConEx-Marked：Re-Echo-Loss、Re-Echo-ECN、またはCreditの少なくとも1つ。
ConEx-Re-Echo: At least one of Re-Echo-Loss or Re-Echo-ECN.
ConEx-Re-Echo：Re-Echo-LossまたはRe-Echo-ECNの少なくとも1つ。
First-time readers may wish to skim this section, since it is more understandable having read the entire document.
ドキュメント全体を読んだ方が理解しやすいため、初めての読者はこのセクションを読み飛ばしたいと思うかもしれません。
Ideally, all the following requirements would be met by a Congestion Exposure Signal:
理想的には、以下のすべての要件が輻輳露出信号によって満たされるでしょう。
a. The ConEx Signal SHOULD be visible to internetwork-layer devices along the entire path from the transport sender to the transport receiver. Equivalently, it SHOULD be present in the IPv4 or IPv6 header and in the outermost IP header if using IP-in-IP tunneling. It MAY need to be visible if other encapsulating headers are used to interconnect networks. The ConEx Signal SHOULD be immutable once set by the transport sender. A corollary of these requirements is that the chosen ConEx encoding SHOULD pass silently without modification through preexisting networking gear.
a. ConEx信号は、トランスポート送信側からトランスポート受信側までのパス全体に沿って、インターネットワーク層デバイスから見える必要があります（SHOULD）。同様に、IP-in-IPトンネリングを使用する場合は、IPv4またはIPv6ヘッダーと最も外側のIPヘッダーに存在する必要があります（SHOULD）。他のカプセル化ヘッダーを使用してネットワークを相互接続する場合は、表示される必要があります。 ConExシグナルは、トランスポート送信者によって設定された後は不変である必要があります（SHOULD）。これらの要件の結果として、選択したConExエンコーディングは、既存のネットワーキングギアを介して変更なしでサイレントパスで転送する必要があります（SHOULD）。
b. The ConEx Signal SHOULD be useful under only partial deployment. A minimal deployment SHOULD only require changes to transport senders. Furthermore, partial deployment SHOULD create incentives for additional deployment, both in terms of enabling ConEx on more devices and adding richer features to existing devices. Nonetheless, ConEx deployment need never be universal, and it is anticipated that some hosts and some transports may never support the ConEx protocol and some networks may never use the ConEx Signals.
b。 ConExシグナルは、部分的な展開でのみ役立つはずです。最小限の展開では、トランスポート送信者の変更のみが必要です（SHOULD）。さらに、部分的な展開では、より多くのデバイスでConExを有効にすることと、既存のデバイスに豊富な機能を追加することの両方に関して、追加の展開に対するインセンティブを作成する必要があります（SHOULD）。それにもかかわらず、ConExの展開は普遍的である必要はなく、一部のホストと一部のトランスポートはConExプロトコルをサポートしない可能性があり、一部のネットワークはConEx信号を使用しない可能性があると予想されます。
c. The ConEx Signal SHOULD be timely. There will be a minimum delay of one RTT and often longer if the transport protocol sends infrequent feedback (consider Real-time Transport Control Protocol (RTCP) [RFC3550] [RFC6679], for example).
c. ConExシグナルはタイムリーである必要があります。トランスポートプロトコルが頻繁にフィードバックを送信しない場合、最小の遅延は1 RTTであり、多くの場合より長くなります（たとえば、リアルタイムトランスポートコントロールプロトコル（RTCP）[RFC3550] [RFC6679]を検討してください）。
d. The ConEx Signal SHOULD be accurate and auditable. The general approach for auditing is to observe the volume of congestion signals and ConEx Signals on the forward data path and verify that the ConEx Signals do not underrepresent the congestion signals (see Section 5.5).
d. ConExシグナルは正確かつ監査可能である必要があります。監査の一般的なアプローチは、フォワードデータパス上の輻輳信号とConEx信号の量を観察し、ConEx信号が輻輳信号を代表していないことを確認することです（セクション5.5を参照）。
e. The ConEx Signals for packet loss and ECN marking SHOULD have distinct encodings because they are likely to require different auditing techniques.
e. パケット損失とECNマーキング用のConEx信号は、異なる監査技術を必要とする可能性が高いため、別個のエンコーディングを使用する必要があります（SHOULD）。
f. Additionally, there SHOULD be an auditable ConEx Credit signal. A sender can use Credit to indicate potential future congestion, for example, as is often seen during startup. ConEx Credit is intended to overestimate congestion actually experienced across the network.
f. さらに、監査可能なConEx Creditシグナルが存在する必要があります（SHOULD）。送信者はクレジットを使用して、たとえば起動時によく見られるように、潜在的な将来の輻輳を示すことができます。 ConEx Creditは、ネットワーク全体で実際に発生する輻輳を過大評価することを目的としています。
It is already known that implementing ConEx Signals is likely to entail some compromises, and therefore, all the requirements above are expressed with the keyword "SHOULD" rather than "MUST". The only mandatory requirement is that a concrete protocol description MUST give sound reasoning if it chooses not to meet some requirement.
ConEx Signalsの実装にはある程度の妥協が伴う可能性が高いことがすでにわかっているため、上記のすべての要件は「MUST」ではなく「SHOULD」というキーワードで表現されます。唯一の必須の要件は、具体的なプロトコルの説明が、ある要件を満たさないことを選択した場合、適切な理由を提示しなければならないことです。
The role of the audit function and constraints on it are described in Section 5.5. There is no intention to standardise the audit function. However, it is necessary to lay down the following normative constraints on audit behaviour so that transport designers will know what to design against and implementers of audit devices will know what pitfalls to avoid:
監査機能の役割と監査機能に対する制約については、セクション5.5で説明します。監査機能を標準化する意図はありません。ただし、監査の振る舞いに関する次の規範的な制約を定める必要があります。これにより、トランスポート設計者は何に対して設計すべきかがわかり、監査デバイスの実装者は避けるべき落とし穴を知ることができます。
Minimal False Hits: Audit SHOULD introduce minimal false hits for honest flows.
最小限の偽ヒット：監査は、正直なフローに対して最小限の偽ヒットを導入する必要があります。
Minimal False Misses: Audit SHOULD quickly detect and sanction dishonest flows, ideally on the first dishonest packet.
最小限の誤り：監査は、理想的には最初の不正パケットで、不正フローを迅速に検出して認可します。
Transport Oblivious: Audit SHOULD NOT be designed around one particular rate response, such as any particular TCP congestion control algorithm or one particular resource-sharing regime such as TCP friendliness [RFC5348]. An important goal is to give ingress networks the freedom to unilaterally allow different rate responses to congestion and different resource sharing regimes [Evol_cc] without having to coordinate with other networks over details of individual flow behaviour.
トランスポートOblivious：監査は、特定のTCP輻輳制御アルゴリズムやTCPフレンドリ[RFC5348]などの特定のリソース共有方式など、特定のレート応答を中心に設計するべきではありません。重要な目標は、個々のフロー動作の詳細について他のネットワークと調整する必要なしに、輻輳に対するさまざまなレート応答とさまざまなリソース共有レジーム[Evol_cc]を一方的に許可する自由を入口ネットワークに与えることです。
Sufficient Sanction: Audit SHOULD introduce sufficient sanction (e.g., loss in goodput) such that senders cannot gain from understating congestion.
十分な制裁措置：監査は、送信者が過密状態の過小評価から得ることができないように、十分な制裁措置（たとえば、グッドプットの損失）を導入する必要があります（SHOULD）。
Proportionate Sanction: To the extent that the audit might be subject to false hits, the sanction SHOULD be proportionate to the degree to which congestion is understated. If the audit over-punishes, attackers will find ways to harness it into amplifying attacks on others. Ideally the audit should, in the long run, cause the user to get no better performance than they would get by being accurate.
制裁措置の比例：監査が誤った結果を被る可能性がある場合、制裁措置は、混雑が軽視されている程度に比例している必要があります。監査が過度に罰する場合、攻撃者はそれを利用して他者への攻撃を拡大する方法を見つけるでしょう。理想的には、監査により、長期的には、ユーザーは正確であるよりも優れたパフォーマンスを得ることができます。
Manage Memory Exhaustion: Audit SHOULD be able to counter state-exhaustion attacks. For instance, if the audit function uses flow state, it should not be possible for senders to exhaust its memory capacity by gratuitously sending numerous packets, each with a different flow ID.
メモリ枯渇の管理：監査は、状態枯渇攻撃に対抗できる必要があります（SHOULD）。たとえば、監査機能がフロー状態を使用する場合、送信者がそれぞれ異なるフローIDを持つ多数のパケットを不当に送信することによってメモリ容量を使い果たすことは不可能であるべきです。
Identifier Accountability: Audit SHOULD NOT be vulnerable to 'identity whitewashing', where a transport can label a flow with a new ID more cheaply than paying the cost of continuing to use its current ID [CheapPseud].
識別子の説明責任：監査は、「アイデンティティホワイトウォッシング」に対して脆弱ではありません。トランスポートは、現在のID [CheapPseud]の使用を継続するコストを支払うよりも安価に新しいIDでフローにラベルを付けることができます。
An experimental ConEx specification SHOULD describe the following protocol details:
実験的なConEx仕様では、次のプロトコルの詳細を説明する必要があります。
Network Layer:
ネットワーク層：
A. the specific ConEx Signal encodings with packet formats, bit fields, and/or codepoints;
A.パケット形式、ビットフィールド、コードポイント、またはその両方を使用した特定のConEx信号エンコーディング。
B. an inventory of invalid combinations of flags or invalid codepoints in the encoding, as well as whether security gateways should normalise, discard, or ignore such invalid encodings, and what values they should be considered equivalent to by ConEx-aware elements;
B.エンコーディング内のフラグまたは無効なコードポイントの無効な組み合わせの一覧、およびセキュリティゲートウェイがそのような無効なエンコーディングを正規化、破棄、または無視するかどうか、およびConEx対応要素によって同等と見なされる値。
C. an inventory of any conflated signals or any other effects that are known to compromise signal integrity;
C.信号の整合性を損なうことが知られている、混乱した信号またはその他の影響の一覧。
D. whether the source is responsible for allowing for the round-trip delay in ConEx Signals (e.g., using a Credit marking), and if so, whether Credit is maintained for the duration of a flow or degrades over time, and what defines the end of the duration of a flow;
D.ソースがConEx信号の往復遅延を可能にする責任があるか（たとえば、クレジットマーキングを使用して）、そうである場合、クレジットがフローの期間中維持されるか、時間とともに劣化するか、および何を定義するかフローの期間の終わり。
E. a specification for signal units (bytes vs. packets, etc.), any approximations allowed, and the algorithms to do any implied conversions or accounting;
E.信号単位（バイトとパケットなど）の仕様、許可される近似、および暗黙の変換またはアカウンティングを実行するアルゴリズム。
F. if the units are bytes, a definition of which headers are included in the size of the packet;
F.単位がバイトの場合、どのヘッダーがパケットのサイズに含まれるかの定義。
G. how tunnels should propagate the ConEx encoding;
G.トンネルがConExエンコーディングを伝播する方法。
H. whether the encoding fields are mutable or not, to ensure that header authentication, checksum calculation, etc., process them correctly; a ConEx encoding field SHOULD be immutable end-to-end, then endpoints can detect if it has been tampered with in transit;
H.エンコーディングフィールドが変更可能かどうかにかかわらず、ヘッダー認証、チェックサム計算などがそれらを正しく処理するようにします。 ConExエンコーディングフィールドはエンドツーエンドで不変である必要があり（SHOULD）、エンドポイントはそれが転送中に改ざんされたかどうかを検出できます。
I. if a specific encoding allows mutability (e.g., at proxies),
then an inventory of invalid transitions between codepoints;
in all encodings, transitions from any ConEx marking to Not-
ConEx MUST be invalid;
J. a statement that the ConEx encoding is only applicable to unicast and anycast and that forwarding elements should silently ignore any ConEx signalling on multicast packets (they should be forwarded unchanged);
J. ConExエンコーディングはユニキャストとエニーキャストにのみ適用可能であり、転送要素はマルチキャストパケットのConExシグナリングを暗黙のうちに無視する必要がある（ステートメントは変更せずに転送する必要がある）
K. the definition of any extensibility;
K.拡張性の定義。
L. backward and forward compatibility and potential migration strategies; in all cases, a ConEx encoding MUST be arranged so that legacy transport senders implicitly send Not-ConEx;
L.後方互換性と前方互換性、および潜在的な移行戦略。すべての場合において、レガシートランスポート送信者が暗黙的にNot-ConExを送信するように、ConExエンコーディングを調整する必要があります。
M. any (optional) modification to data-plane forwarding dependent on the encoding (e.g., preferential discard, interaction with Diffserv, ECN, etc.); and
M.エンコーディングに依存するデータプレーン転送に対する（オプションの）変更（たとえば、優先的な破棄、Diffserv、ECNとの相互作用など）。そして
N. any warning or error messages relevant to the encoding.
N.エンコーディングに関連する警告またはエラーメッセージ。
Note regarding item J on multicast: A multicast tree may involve different levels of congestion on each leg. Any traffic management can only monitor or control multicast congestion at or near each receiver. It would make no sense for the sender to try to expose "whole-path congestion" in sent packets because it cannot hope to describe all the differing congestion levels on every leg of the tree.
マルチキャストに関する項目Jに関する注意：マルチキャストツリーでは、レッグごとに異なるレベルの輻輳が発生する場合があります。トラフィック管理は、各受信機またはその近くのマルチキャスト輻輳のみを監視または制御できます。ツリーのすべてのレッグで異なるすべての輻輳レベルを説明することはできないため、送信者が送信パケットで「パス全体の輻輳」を公開しようとしても意味がありません。
Transport Layer:
トランスポート層：
A. a specification of any required changes to congestion feedback in particular transport protocols;
A.特定のトランスポートプロトコルでの輻輳フィードバックに必要な変更の仕様。
B. a specification (or, minimally, a recommendation) for how a transport should estimate credits at the beginning of a connection and while it is in progress;
B.トランスポートが接続の開始時と接続の進行中にクレジットを推定する方法の仕様（または、最低限の推奨）。
C. a specification of whether any other protocol options should (or must) be enabled along with an implementation of ConEx (e.g., at least attempting to negotiate ECN and Selective Acknowledgement (SACK) capability);
C. ConExの実装と共に、他のプロトコルオプションを有効にする必要がある（または必要がある）かどうかの仕様（たとえば、少なくともECNと選択的確認応答（SACK）機能のネゴシエーションの試行）。
D. a specification of any configuration that a ConEx stack may require (or, preferably, confirmation that it requires no configuration); and
D. ConExスタックが必要とする可能性のある構成の仕様（または、できれば構成が不要であることの確認）。そして
E. a specification of the statistics that a protocol stack should log for each type of marking on a per-flow or aggregate basis.
E.プロトコルスタックがフローごとまたは集約ベースで各タイプのマーキングについてログに記録する必要がある統計の仕様。
Security:
セキュリティ：
A. an example of a strong audit algorithm suitable for detecting if a single flow is misstating congestion; this algorithm should present minimal false results but need not have optimal scaling properties (e.g., may need per-flow state).
A.単一のフローが輻輳を誤解しているかどうかを検出するのに適した強力な監査アルゴリズムの例。このアルゴリズムは最小限の偽の結果を表示する必要がありますが、最適なスケーリングプロパティを持つ必要はありません（たとえば、フローごとの状態が必要な場合があります）。
B. an example of an audit algorithm suitable for detecting misstated congestion in a large aggregate (e.g., no per-flow state).
B.大規模な集合体での誤った輻輳の検出に適した監査アルゴリズムの例（フローごとの状態がないなど）。
C. a definition of the level of ConEx-Re-Echo and ConEx-Credit signals that will be sufficient to pass audit (see Section 5.5).
C.監査に合格するのに十分なConEx-Re-EchoおよびConEx-Credit信号のレベルの定義（セクション5.5を参照）。
The possibility exists that these specifications overconstrain the ConEx design and can not be fully satisfied. An important part of the evaluation of any particular design will be a thorough inventory of all ways in which it might fail to satisfy these specifications.
これらの仕様はConEx設計を過度に制約し、完全に満足できない可能性があります。特定の設計の評価の重要な部分は、これらの仕様を満たさない可能性のあるすべての方法の完全なインベントリになります。
Most protocol specifications start with a description of packet formats and codepoints with their associated meanings. This document does not: It is already known that choosing the encoding for ConEx is likely to entail some engineering compromises that have the potential to reduce the protocol's usefulness in some settings. For instance, the experimental ConEx encoding chosen for IPv6 [CONEX-DESTOPT] had to make compromises on tunnelling. Rather than making these engineering choices prematurely, this document sidesteps the encoding problem by making it abstract. It describes several different representations of ConEx Signals, none of which are specified to the level of specific bits or codepoints.
ほとんどのプロトコル仕様は、パケット形式とコードポイントの説明から始まり、それに関連する意味があります。このドキュメントには含まれていません。ConExのエンコーディングを選択すると、一部の設定でプロトコルの有用性が低下する可能性のあるエンジニアリング上の妥協が必要になる可能性が高いことがすでに知られています。たとえば、IPv6 [CONEX-DESTOPT]に選択された実験的なConExエンコーディングは、トンネリングに関して妥協する必要がありました。このドキュメントでは、これらのエンジニアリングの選択を時期尚早に行うのではなく、抽象化することでエンコードの問題を回避しています。これは、ConEx信号のいくつかの異なる表現について説明しています。これらのどれも、特定のビットまたはコードポイントのレベルに指定されていません。
The goal of this approach is to be as complete as possible for discovering the potential usage and capabilities of the ConEx protocol, so we have some hope of making optimal design decisions when choosing the encoding. Even if experiments reveal particular problems due to the encoding, then this document will still serve as a reference model.
このアプローチの目標は、ConExプロトコルの潜在的な使用法と機能を発見するために可能な限り完全であることです。そのため、エンコーディングを選択するときに最適な設計決定を行うことができます。実験により、エンコーディングによる特定の問題が明らかになったとしても、このドキュメントは参照モデルとして機能します。
For tutorial purposes, it is helpful to describe a naive encoding of the ConEx protocol for TCP and similar protocols: set a bit (not specified here) in the IP header on each retransmission and on each ECN-signalled window reduction. Network devices along the forward path can see this bit and act on it. For example, any device along the path might limit the rate of all traffic if the rate of marked (congested) packets exceeds a threshold.
チュートリアルの目的で、TCPおよび類似のプロトコル用のConExプロトコルの単純なエンコードを説明すると役立ちます。各再送信時および各ECNシグナルウィンドウ削減時にIPヘッダーにビット（ここでは指定しません）を設定します。転送パスに沿ったネットワークデバイスは、このビットを確認して動作できます。たとえば、パス上のデバイスは、マークされた（輻輳した）パケットのレートがしきい値を超えると、すべてのトラフィックのレートを制限する可能性があります。
This simple encoding is sufficient to illustrate many of the benefits envisioned for ConEx. At first glance, it looks like it might motivate people to deploy and use it. It is a one-line code change that a small number of OS developers and content providers could unilaterally deploy across a significant fraction of all Internet traffic. However, this encoding does not support auditing so it would also motivate users and/or applications to misrepresent the congestion that they are causing [RFC3514]. As a consequence, the naive encoding is not likely to be trusted and thus creates its own disincentives for deployment.
この単純なエンコーディングは、ConExに想定される多くの利点を示すのに十分です。一見すると、それをデプロイして使用する動機付けになるかもしれません。これは1行のコード変更であり、少数のOS開発者とコンテンツプロバイダーがすべてのインターネットトラフィックのかなりの部分に一方的に展開できます。ただし、このエンコーディングは監査をサポートしていないため、ユーザーやアプリケーションに、それらが引き起こしている輻輳を誤って伝えさせる動機にもなります[RFC3514]。結果として、単純なエンコードは信頼されない可能性が高く、展開のための独自の阻害要因を作成します。
Nonetheless, this Naive encoding does present a clear mental model of how the ConEx protocol might function under various uses. It is useful for thought experiments where it can be stipulated that all participants are honest and it does illustrate some of the incentives that might be introduced by ConEx.
それにもかかわらず、このNaiveエンコーディングは、ConExプロトコルがさまざまな用途でどのように機能するかについての明確なメンタルモデルを提供します。これは、すべての参加者が正直であると規定できる思考実験に役立ち、ConExによって導入される可能性のあるインセンティブの一部を示しています。
In limited contexts, it is possible to implement ConEx-like functions without any signals at all by measuring rest-of-path congestion directly from TCP headers. The algorithm is to keep at least one RTT of past TCP headers and match each new header against the history to count duplicate data.
限られた状況では、TCPヘッダーからパスの残りの輻輳を直接測定することにより、信号なしでConExのような機能を実装することが可能です。このアルゴリズムでは、過去のTCPヘッダーのRTTを少なくとも1つ保持し、新しいヘッダーをそれぞれ履歴と照合して、重複データをカウントします。
This could implement many ConEx policies, without any explicit protocol. It is fairly easy to implement, at least at low rate (e.g., in a software-based edge router). However, it would only be useful in cases where the network operator can see the TCP headers. At the time of writing (2014), those cases are the majority of traffic because UDP, IPsec, and VPN tunnels are used far less than Secure Socket Layer (SSL) or Transport Layer Security (TLS) over TCP/IP, which do not hide TCP sequence numbers from network devices. However, anyone specifically intending to avoid the attention of a congestion policy device would only have to hide their TCP headers from the network operator (e.g., by using a VPN tunnel).
これにより、明示的なプロトコルなしで多くのConExポリシーを実装できます。少なくとも低速での実装はかなり簡単です（たとえば、ソフトウェアベースのエッジルーターで）。ただし、ネットワークオペレータがTCPヘッダーを確認できる場合にのみ役立ちます。執筆時点（2014）では、UDP、IPsec、およびVPNトンネルはTCP / IP上のSecure Socket Layer（SSL）またはTransport Layer Security（TLS）よりもはるかに少ないため、これらのケースがトラフィックの大半を占めています。 TCPシーケンス番号をネットワークデバイスから非表示にします。ただし、輻輳ポリシーデバイスの注意を特に避けようとする人は、（VPNトンネルを使用するなどして）TCPヘッダーをネットワークオペレーターから隠すだけで済みます。
The re-ECN specification [RE-ECN-TCP] presents an encoding of ConEx in IPv4 and IPv6 that was tightly integrated with ECN encoding in order to fit into the IPv4 header. Any individual packet may need to represent any ECN codepoint and any ConEx Signal value independently. So, ideally, their encoding should be entirely independent. However, given the limited number of header bits and/or codepoints, re-ECN chooses to partially share codepoints and to re-echo both losses and ECN with just one codepoint.
re-ECN仕様[RE-ECN-TCP]は、IPv4ヘッダーに適合するようにECNエンコーディングと緊密に統合されたIPv4およびIPv6のConExのエンコーディングを示しています。個々のパケットは、ECNコードポイントとConEx信号値を個別に表す必要がある場合があります。したがって、理想的には、それらのエンコーディングは完全に独立している必要があります。ただし、ヘッダービットやコードポイントの数が限られている場合、re-ECNはコードポイントを部分的に共有し、1つのコードポイントで損失とECNの両方を再エコーすることを選択します。
The central theme of the re-ECN work is an audit mechanism that provides sufficient disincentives against misrepresenting congestion [RE-ECN-MOTIVATION]. It is analyzed extensively in Briscoe's PhD dissertation [Refb-dis]. For a tutorial background on re-ECN motivation and techniques, see [Re-fb] and [FairerFaster].
再ECN作業の中心的なテーマは、混雑の不実表示に対して十分な阻害要因を提供する監査メカニズムです[RE-ECN-MOTIVATION]。これは、ブリスコの博士論文[Refb-dis]で広く分析されています。 re-ECNの動機と手法に関するチュートリアルの背景については、[Re-fb]および[FairerFaster]を参照してください。
Re-ECN is an example of one chosen set of compromises attempting to meet the requirements of Section 3. The present document takes a step back, aiming to state the ideal requirements in order to allow the Internet community to assess whether different compromises might be better.
Re-ECNは、セクション3の要件を満たそうとする1つの選択された妥協策の例です。現在のドキュメントは、インターネットコミュニティがさまざまな妥協策がより良いかどうかを評価できるようにするための理想的な要件を述べることを目的として、一歩後退します。
The problem with re-ECN is that it requires that receivers be ECN enabled in addition to sender changes. Newer encodings [CONEX-DESTOPT] overcome this problem by being able to represent loss and ECN-based congestion separately.
re-ECNの問題は、送信者の変更に加えて、受信者がECNを有効にする必要があることです。新しいエンコーディング[CONEX-DESTOPT]は、損失とECNベースの輻輳を別々に表すことができるようにすることで、この問題を克服しています。
This encoding involves flag bits, each of which the sender can set independently to indicate to the network one of the following four signals:
このエンコードにはフラグビットが含まれます。それぞれのフラグビットは、次の4つの信号のいずれかをネットワークに通知するために個別に設定できます。
ConEx (Not-ConEx): The transport is (or is not) using ConEx with this packet (network-layer encoding requirement L in Section 3.3 says the protocol must be arranged so that legacy transport senders implicitly send Not-ConEx).
ConEx（Not-ConEx）：トランスポートはこのパケットでConExを使用している（または使用していない）（3.3節のネットワークレイヤーエンコーディング要件Lは、レガシートランスポート送信者が暗黙的にNot-ConExを送信するようにプロトコルを調整する必要があることを示しています）。
Re-Echo-Loss (Not-Re-Echo-Loss): The transport has (or has not) experienced a loss.
Re-Echo-Loss（Not-Re-Echo-Loss）：トランスポートで損失が発生した（または発生しなかった）。
Re-Echo-ECN (Not-Re-Echo-ECN): The transport has (or has not) experienced ECN-signalled congestion.
Re-Echo-ECN（Not-Re-Echo-ECN）：トランスポートで、ECN信号による輻輳が発生した（または発生していない）。
Credit (Not-Credit): The transport is (or is not) building up congestion credit (see Section 5.5 on the audit function).
クレジット（クレジットではない）：交通機関は渋滞クレジットを積み上げている（または積み上げていない）（監査機能のセクション5.5を参照）。
A packet with ConEx set, combined with all the three other flags cleared, implies ConEx-Not-Marked.
ConExが設定されたパケットは、他の3つのフラグがすべてクリアされた状態で、ConEx-Not-Markedを意味します。
This encoding does not imply any exclusion property among the signals. Multiple types of congestion (ECN, loss) can be signalled on the same ACK. So, ideally, a ConEx sender would be able to reflect these in the next packet. However, there will be many invalid combinations of flags (e.g., Not-ConEx combined with any of the ConEx-Marked flags), which a malicious sender could use to advantage against naive policy devices that only check each flag separately.
このエンコーディングは、信号間の除外プロパティを意味しません。複数のタイプの輻輳（ECN、損失）を同じACKで通知できます。したがって、理想的には、ConEx送信者はこれらを次のパケットに反映できます。ただし、フラグの無効な組み合わせは多数あり（たとえば、ConExマーク付きのフラグと組み合わせたNot-ConEx）、悪意のある送信者は、各フラグを個別にチェックするだけの単純なポリシーデバイスに対して有利になる可能性があります。
As long as the packets in a flow have uniform sizes, it does not matter whether the units of congestion are packets or bytes. However, if an application sends very irregular packet sizes, it may be necessary for the sender to mark multiple packets to avoid being in technical violation of an audit function measuring in bytes (see Section 4.6).
フロー内のパケットのサイズが均一である限り、輻輳の単位がパケットであるかバイトであるかは問題ではありません。ただし、アプリケーションが非常に不規則なパケットサイズを送信する場合、バイト単位で測定する監査機能の技術的違反を回避するために、送信者が複数のパケットをマークする必要がある場合があります（セクション4.6を参照）。
This encoding involves signaling one of the following five codepoints:
このエンコーディングには、次の5つのコードポイントのいずれかを通知することが含まれます。
ENUM {Not-ConEx, ConEx-Not-Marked, Re-Echo-Loss, Re-Echo-ECN, Credit} Each named codepoint has the same meaning as in the encoding using independent bits in the previous section. The use of any one codepoint implies the negative of all the others.
ENUM {Not-ConEx、ConEx-Not-Marked、Re-Echo-Loss、Re-Echo-ECN、Credit}各名前付きコードポイントは、前のセクションの独立したビットを使用したエンコーディングと同じ意味です。 1つのコードポイントの使用は、他のすべてのコードポイントの否定を意味します。
Inherently, the semantics of most of the enumerated codepoints are mutually exclusive. 'Credit' is the only one that might need to be used in combination with either Re-Echo-Loss or Re-Echo-ECN, but even that requirement is questionable. It must not be forgotten that the enumerated encoding loses the flexibility to signal these two combinations, whereas the encoding with four independent bits is not so limited. Alternatively, two extra codepoints could be assigned to these two combinations of semantics. The comment in the previous section about units also applies.
本質的に、列挙されたコードポイントのほとんどのセマンティクスは相互に排他的です。 「クレジット」は、Re-Echo-LossまたはRe-Echo-ECNのいずれかと組み合わせて使用する必要がある可能性がある唯一のものですが、その要件でさえ疑わしいものです。列挙されたエンコーディングはこれら2つの組み合わせを通知する柔軟性を失うことを忘れてはなりませんが、4つの独立したビットによるエンコーディングはそれほど制限されていません。あるいは、これら2つのセマンティクスの組み合わせに2つの追加のコードポイントを割り当てることもできます。ユニットに関する前のセクションのコメントも適用されます。
The following comments apply generally to all the other encodings.
以下のコメントは、他のすべてのエンコーディングに一般的に適用されます。
Congestion can be due to exhaustion of bit-carrying capacity or exhaustion of packet-processing power. When a packet is discarded or marked to indicate congestion, there is no easy way to know whether the lost or marked packet signifies bit congestion or packet congestion. The above ConEx encodings that rely on marking packets suffer from the same ambiguity.
混雑は、ビット伝送容量の枯渇またはパケット処理能力の枯渇が原因である可能性があります。パケットが破棄されるか、輻輳を示すマークが付けられた場合、失われたパケットまたはマークされたパケットがビットの輻輳を示しているのか、パケットの輻輳を示しているのかを知る簡単な方法はありません。パケットのマーキングに依存する上記のConExエンコーディングは、同じあいまいさの影響を受けます。
This problem is most acute when audit needs to check that one count of markings matches another. For example, if there are ConEx markings on three large (1500 B) packets, is that sufficient to match the loss of five small (60 B) packets? If a packet marking is defined to mean all the bytes in the packet are marked, then we have 4500 B of ConEx-Marked data against 300 B of lost data, which is easily sufficient. If instead we are counting packets, then we have three ConEx packets against five lost packets, which is not sufficient. This problem will not arise when all the packets in a flow are the same size, but a choice needs to be made for flows in which packet sizes vary, such as BGP, SPDY, and some variable-rate video encoding schemes.
この問題は、監査がマーキングの1つのカウントが別のカウントと一致することを確認する必要がある場合に最も深刻です。たとえば、3つの大きな（1500 B）パケットにConExマーキングがある場合、5つの小さな（60 B）パケットの損失と一致するのに十分ですか？パケットマーキングがパケット内のすべてのバイトがマークされることを意味するように定義されている場合、300 Bの失われたデータに対して4500 BのConEx-Markedデータがあり、簡単に十分です。代わりにパケットをカウントしている場合、5つの失われたパケットに対して3つのConExパケットがあり、これは十分ではありません。この問題は、フロー内のすべてのパケットが同じサイズの場合は発生しませんが、BGP、SPDY、および一部の可変レートビデオエンコードスキームなど、パケットサイズが異なるフローに対して選択する必要があります。
Whether to use bytes or packets is not obvious. For instance, the most expensive links in the Internet, in terms of cost per bit, are all at lower data rates, where transmission times are large and packet sizes are important. In order for a policy to consider wire time, it needs to know the number of congested bytes. However, high speed networking equipment and the transport protocols themselves sometimes gauge resource consumption and congestion in terms of packets.
バイトとパケットのどちらを使用するかは明らかではありません。たとえば、インターネットの最も高価なリンクは、ビットあたりのコストの点で、すべてデータ転送速度が低く、伝送時間が長く、パケットサイズが重要です。ポリシーが通信時間を考慮するためには、輻輳したバイト数を知る必要があります。ただし、高速ネットワーキング機器とトランスポートプロトコル自体は、パケットの観点からリソースの消費と輻輳を測定することがあります。
[RFC7141] advises that congestion indications should be interpreted in units of bytes when responding to congestion, at least on today's Internet. [RFC6789] takes the same view in its definition of congestion-volume, again, for today's Internet.
[RFC7141]は、少なくとも今日のインターネットでは、輻輳に応答するとき、輻輳の表示はバイト単位で解釈されるべきであるとアドバイスしています。 [RFC6789]は、今日のインターネットについても、輻輳ボリュームの定義に同じ見方をしています。
In any TCP implementation, this is simple to achieve for varying size packets given that TCP SACK tracks losses in bytes. If an encoding is specified in units of bytes, the encoding should also specify which headers to include in the size of a packet (see network-layer requirement F in Section 3.3).
どのTCP実装でも、TCP SACKがバイト単位で損失を追跡する場合、さまざまなサイズのパケットでこれを簡単に実現できます。エンコーディングがバイト単位で指定されている場合、エンコーディングでは、パケットのサイズに含めるヘッダーも指定する必要があります（セクション3.3のネットワーク層要件Fを参照）。
RFC 7141 constructs an argument for why equipment tends to be built so that the bottleneck will be the bit-carrying capacity of its interfaces, not its packet-processing capacity. However, RFC 7141 acknowledges that the position may change in future and notes that new techniques will need to be developed to distinguish packet and bit congestion.
RFC 7141は、ボトルネックがそのパケット処理能力ではなく、インターフェイスのビット伝送能力になるように、機器が構築される傾向がある理由についての議論を構築します。ただし、RFC 7141は位置が将来変更される可能性があることを認めており、パケットとビットの輻輳を区別するために新しい技術を開発する必要があると指摘しています。
Given this document describes an abstract ConEx mechanism, it is intended to be timeless. Therefore, it does not take a strong position on this issue. However, a ConEx encoding will need to explicitly specify whether it assumes units of bytes or packets consistently for both congestion indications and ConEx markings (see network-layer requirement E in Section 3.3). It may help to refer to the guidance in [RFC7141].
このドキュメントでは、抽象的なConExメカニズムについて説明しているため、時代を超越することを目的としています。したがって、それはこの問題に関して強い立場をとりません。ただし、ConExエンコーディングでは、輻輳表示とConExマーキングの両方に対して一貫してバイト単位またはパケット単位を想定するかどうかを明示的に指定する必要があります（セクション3.3のネットワーク層要件Eを参照）。 [RFC7141]のガイダンスを参照すると役立つ場合があります。
The components shown in Figure 1 as well as policy and audit are described in more detail.
図1に示されているコンポーネントと、ポリシーおよび監査について詳しく説明します。
Congestion signals originate from network devices as they do today. A congested router, switch, or other network device can discard or ECN-mark packets when it is congested.
輻輳信号は、今日と同様にネットワークデバイスから発信されます。輻輳しているルーター、スイッチ、またはその他のネットワークデバイスは、輻輳時にパケットを破棄したり、ECNマークを付けたりできます。
The sending transport needs to be modified to send Congestion Exposure signals in response to congestion feedback signals (e.g., for the case of a TCP transport, see [TCP-MODIFICATION]). We want to permit ConEx without ECN (e.g., if the receiver does not support ECN). However, we want to encourage a ConEx sender to at least attempt to negotiate ECN (a ConEx transport protocol specification may require this) because it is believed that ConEx without ECN is harder to audit and thus potentially exposed to cheating. Since honest users have the potential to benefit from stronger mechanisms to manage traffic, they have an incentive to deploy ConEx and ECN together. This incentive is not sufficient to prevent a dishonest user from constructing (or configuring) a sender that enables ConEx after choosing not to negotiate ECN, but it should be sufficient to prevent this from being the sustained default case for any significant pool of users.
送信トランスポートは、輻輳フィードバック信号に応答してCongestion Exposure信号を送信するように変更する必要があります（たとえば、TCPトランスポートの場合は、[TCP-MODIFICATION]を参照してください）。 ECNなしでConExを許可したい（たとえば、受信者がECNをサポートしていない場合）。ただし、ECNなしのConExは監査が困難であり、不正行為にさらされる可能性があると考えられているため、ConEx送信者が少なくともECNのネゴシエーションを試みるように推奨します（ConExトランスポートプロトコル仕様ではこれが必要になる場合があります）。正直なユーザーは、トラフィックを管理するためのより強力なメカニズムから恩恵を受ける可能性があるため、ConExとECNを一緒に展開するインセンティブがあります。このインセンティブは、ECNをネゴシエートしないことを選択した後にConExを有効にする送信者を不正なユーザーが作成（または構成）することを防ぐには十分ではありませんが、これが重要なユーザーのプールの持続的なデフォルトのケースになるのを防ぐには十分です。
Permitting ConEx without ECN is necessary to facilitate bootstrapping other parts of ConEx deployment.
ECNなしでConExを許可することは、ConEx展開の他の部分のブートストラップを容易にするために必要です。
Any receiving transport may already feedback sufficiently useful signals to the sender so that it does not need to be altered.
受信側のトランスポートはすでに、送信者に十分に有用な信号をフィードバックしている可能性があるため、変更する必要はありません。
The native loss or ECN signaling mechanism required for compliance with existing congestion control standards (e.g., RTCP, Stream Control Transmission Protocol (SCTP)) will typically be sufficient for the Sender to generate ConEx Signals.
既存の輻輳制御標準（RTCP、ストリーム制御伝送プロトコル（SCTP）など）に準拠するために必要なネイティブの損失またはECNシグナリングメカニズムは、通常、送信者がConEx信号を生成するのに十分です。
TCP's loss feedback is sufficient for ConEx if SACK is used [RFC2018]. However, the original specification for ECN in TCP [RFC3168] signals congestion no more than once per round trip. The sender may require more precise feedback from the receiver otherwise it is at risk of appearing to be understating its ConEx Signals.
SACKが使用される場合、TCPの損失フィードバックはConExに十分です[RFC2018]。ただし、TCPのECN [RFC3168]の元の仕様では、輻輳はラウンドトリップごとに1回しか通知されません。送信者は受信者からのより正確なフィードバックを必要とする場合があります。そうしないと、ConEx信号を過小評価しているように見えるリスクがあります。
Ideally, ConEx should be added to a transport like TCP without mandatory modifications to the receiver. But in the TCP-ECN case, an optional modification to the receiver could be recommended for precision (see [RFC7560], which is based on the approach originally taken when adding re-ECN to TCP [RE-ECN-TCP]).
理想的には、ConExは、受信者に必須の変更を加えることなく、TCPなどのトランスポートに追加する必要があります。ただし、TCP-ECNの場合、精度を高めるためにレシーバーのオプションの変更を推奨できます（[RFC7560]を参照してください。これは、TCPにre-ECNを追加するときに最初に採用されたアプローチに基づいています[RE-ECN-TCP]）。
Policy devices are characterised by a need to be configured with a policy related to the users or neighboring networks being served. In contrast, auditing devices solely enforce compliance with the ConEx protocol and do not need to be configured with any client-specific policy.
ポリシーデバイスの特徴は、サービスを提供するユーザーまたは隣接ネットワークに関連するポリシーを設定する必要があることです。対照的に、監査デバイスは、ConExプロトコルへの準拠を強制するだけであり、クライアント固有のポリシーで構成する必要はありません。
One of the design goals of the ConEx protocol is that none of the important policy mechanisms requires per-flow state and that policy mechanisms can even be implemented for heavily aggregated traffic in the core of the Internet with complexity akin to accumulating marking volumes per logical link. Of course, policy mechanisms may sometimes choose to focus down on individual flows, but ConEx aims to make aggregate policy devices feasible.
ConExプロトコルの設計目標の1つは、フローごとの状態を必要とする重要なポリシーメカニズムがないこと、および論理リンクごとにマーキングボリュームを蓄積するのと同様の複雑さで、インターネットのコアに大量に集約されたトラフィックに対してもポリシーメカニズムを実装できることです。 。もちろん、ポリシーメカニズムは個別のフローに焦点を絞ることを選択する場合がありますが、ConExは集約されたポリシーデバイスを実現可能にすることを目的としています。
Policy devices can typically be decomposed into two functions: i) monitoring the ConEx Signal to compare it with a policy; then ii) acting in some way on the result. Various actions might be invoked against 'out of contract' traffic, such as policing (see Section 5.4.3), re-routing, or downgrading the class of service.
ポリシーデバイスは通常、2つの機能に分解できます。i）ConEx信号を監視してポリシーと比較します。次に、ii）結果に対して何らかの方法で行動します。ポリシング（5.4.3項を参照）、再ルーティング、サービスクラスのダウングレードなど、さまざまなアクションが「契約外」トラフィックに対して呼び出される可能性があります。
Alternatively, a policy device might not act directly on the traffic, but instead report to management systems that are designed to control congestion indirectly. For instance, the reports might trigger capacity upgrades, penalty clauses in contracts, levy charges based on congestion, or merely send warnings to clients who are causing excessive congestion.
または、ポリシーデバイスはトラフィックに直接作用せず、間接的に輻輳を制御するように設計された管理システムに報告する場合があります。たとえば、レポートは、容量のアップグレード、契約の罰則条項、輻輳に基づく課税、または単に過度の輻輳を引き起こしているクライアントに警告を送信する場合があります。
Nonetheless, whatever action is invoked, the congestion monitoring function will always be a necessary part of any policy device.
それにもかかわらず、どのようなアクションが呼び出されても、輻輳監視機能は常にポリシーデバイスの必要な部分になります。
ConEx Signals indicate the level of congestion along a whole path from source to destination. In contrast, ECN signals monitored in the middle of a network indicate the level of congestion experienced so far on the path (of course, only in ECN-capable traffic).
ConEx信号は、送信元から宛先へのパス全体に沿った輻輳のレベルを示します。対照的に、ネットワークの中央で監視されるECN信号は、パス上でこれまでに経験した輻輳のレベルを示します（もちろん、ECN対応のトラフィックでのみ）。
If a monitor in the middle of a network (e.g., at a network border) measures both of these signals, it can subtract the level of ECN (path so far) from the level of ConEx (whole path) to derive a measure of the congestion that packets are likely to experience between the monitoring point and their destination (rest-of-path congestion).
ネットワークの中央（ネットワーク境界など）でこれらの信号の両方を測定するモニターは、ConEx（パス全体）のレベルからECN（これまでのパス）のレベルを差し引いて、測定値を導き出すことができます。パケットが監視ポイントとその宛先の間で経験する可能性が高い輻輳（パスの残りの輻輳）。
It will often be preferable for policy devices to monitor rest-of-path congestion if they can, because it is a measure of the downstream congestion that the policy device can directly influence by controlling the traffic passing through it.
ポリシーデバイスは、通過するトラフィックを制御することによって直接影響を与えることができるダウンストリームの輻輳の測定値であるため、可能であれば、パスの残りの輻輳を監視することがポリシーデバイスにとって望ましいことになります。
A congestion policer can be implemented in a very similar way to a bit-rate policer, but its effect can be focused solely on traffic of users causing congestion downstream, which ConEx Signals make visible. Without ConEx Signals, the only way to mitigate congestion is to blindly limit the traffic bit-rate on the assumption that high bit-rate is more likely to cause congestion.
輻輳ポリサーは、ビットレートポリサーと非常によく似た方法で実装できますが、その効果は、ConEx信号によって可視化される、ダウンストリームの輻輳を引き起こしているユーザーのトラフィックにのみ集中できます。 ConEx信号がない場合、輻輳を緩和する唯一の方法は、高いビットレートが輻輳を引き起こす可能性が高いという前提で、トラフィックのビットレートを盲目的に制限することです。
A congestion policer monitors all ConEx traffic entering a network or some identifiable subset. Using ConEx Signals and/or Credit signals (and preferably subtracting ECN signals to yield rest-of-path congestion), it measures the amount of congestion that this traffic is contributing somewhere downstream. If this persistently exceeds a policy-configured 'congestion-bit-rate', the congestion policer can limit all the monitored ConEx traffic.
輻輳ポリサーは、ネットワークまたは特定のサブセットに入るすべてのConExトラフィックを監視します。 ConEx信号またはクレジット信号（あるいはその両方）を使用して（できればECN信号を差し引いて、パスの残りの輻輳を生成します）、このトラフィックがダウンストリームのどこかに寄与している輻輳の量を測定します。これがポリシーで設定された「輻輳ビットレート」を永続的に超える場合、輻輳ポリサーは監視されるすべてのConExトラフィックを制限できます。
A congestion policer can be implemented by a simple token bucket applied to an aggregate. But unlike a bit-rate policer, it removes tokens only when it forwards packets that are ConEx-Marked, effectively treating Not-ConEx-Marked packets as invisible. Consequently, because tokens give the right to send congested bits, the fill rate of the token bucket will represent the allowed congestion-bit-rate. This should provide sufficient traffic management without having to additionally constrain the straight bit-rate at all. See [ISOLATION-POLICING] for details.
輻輳ポリサーは、集約に適用される単純なトークンバケットによって実装できます。ただし、ビットレートポリサーとは異なり、ConEx-Markedであるパケットを転送する場合にのみトークンを削除し、Not-ConEx-Markedパケットを非表示として効果的に扱います。その結果、トークンは輻輳したビットを送信する権利を与えるため、トークンバケットのフィルレートは、許容される輻輳ビットレートを表します。これにより、ストレートビットレートを追加で制限する必要なく、十分なトラフィック管理が提供されます。詳細については、[ISOLATION-POLICING]を参照してください。
Note that the policing action could be to introduce a throttle (discard some traffic) immediately upstream of the congestion monitor. Alternatively, this throttle could introduce delay using a queue with its own AQM, which potentially increases the whole path congestion. In effect, the congestion policer has moved the congestion earlier in the path and focused it on one user to protect downstream resources by reducing the congestion in the rest of the path.
ポリシングアクションは、輻輳モニターのすぐ上流にスロットルを導入する（トラフィックを破棄する）場合があることに注意してください。または、このスロットルにより、独自のAQMを持つキューを使用して遅延が生じ、パス全体の輻輳が増加する可能性があります。実際、輻輳ポリサーは、パスの早い段階で輻輳を移動し、それを1人のユーザーに集中させて、パスの残りの部分の輻輳を減らすことにより、下流のリソースを保護しました。
The most critical aspect of ConEx is the capability to support robust auditing. It can be assumed that sanctions based on ConEx Signals will create an intrinsic motivation for users to understate the congestion that they are causing. So, without strong audit functions, the ConEx Signal would become understated to the point of being useless. Therefore, the most important feature of an encoding design is likely to be the robustness of the auditing it supports.
ConExの最も重要な側面は、堅牢な監査をサポートする機能です。 ConExシグナルに基づく制裁措置は、ユーザーが引き起こしている輻輳を過小評価する本質的な動機を生み出すと想定できます。したがって、強力な監査機能がないと、ConExシグナルは役に立たなくなるほど控えめになります。したがって、エンコーディング設計の最も重要な機能は、それがサポートする監査の堅牢性です。
The general goal of an auditor is to make sure that any ConEx-enabled traffic is sent with sufficient ConEx-Re-Echo and ConEx-Credit signals. A concrete definition of the ConEx protocol MUST define what sufficient means.
監査人の一般的な目標は、ConEx対応のトラフィックが十分なConEx-Re-EchoおよびConEx-Credit信号で送信されることを確認することです。 ConExプロトコルの具体的な定義では、十分な手段を定義する必要があります。
If a ConEx-enabled transport does not carry sufficient ConEx Signals, then an auditor is likely to apply some sanction to that traffic. Although sanctions are beyond the scope of this document, an example sanction might be to throttle the traffic immediately upstream of the auditor to prevent the user from getting any advantage by understating congestion. Such a throttle would likely include some combination of delaying or dropping traffic.
ConEx対応のトランスポートが十分なConEx信号を伝送しない場合、監査人はそのトラフィックに何らかの制裁を適用する可能性があります。制裁措置はこのドキュメントの範囲を超えていますが、制裁措置の例としては、監査員のすぐ上流のトラフィックを抑制して、ユーザーが輻輳を過小評価することによる利点を得られないようにすることがあります。このようなスロットルには、トラフィックの遅延またはドロップの組み合わせが含まれる可能性があります。
A ConEx auditor might use one of the following techniques:
ConEx監査人は、次のいずれかの手法を使用する可能性があります。
Generic loss auditing: For congestion signalled by loss, totally accurate auditing is not believed to be possible in the general case because it involves a network node detecting the absence of some packets when it cannot always necessarily identify retransmissions or missing packets. The missing packet might simply be taking a different route, or the IP payload may be encrypted.
一般的な損失の監査：損失によって通知された輻輳の場合、必ずしも再送信または欠落したパケットを必ずしも識別できない場合でも、ネットワークノードが一部のパケットの欠如を検出するため、完全な正確な監査は一般的なケースでは不可能と考えられます。欠落したパケットは単に別のルートを取っているか、IPペイロードが暗号化されている可能性があります。
It is for this reason that it is desirable to motivate the deploying of ECN, even though ECN is not strictly required for ConEx.
このため、ECNはConExに厳密には必要ありませんが、ECNの導入を動機付けることが望ましいです。
ECN auditing: Directly observe and compare the volume of ECN and ConEx marks. Since the volume of ECN marks rises monotonically along a path, ECN auditing is most accurate when located near the transport receiver. For this reason, ECN should be monitored downstream of the predominant bottleneck.
ECN監査：ECNおよびConExマークの量を直接観察して比較します。 ECNマークの量はパスに沿って単調に増加するため、ECN監査は、トランスポートレシーバーの近くに配置すると最も正確になります。このため、主なボトルネックの下流でECNを監視する必要があります。
TCP-specific loss auditing: For non-encrypted standard TCP traffic on a single path, a tactical audit approach could be to measure losses by detecting retransmissions, which appear as duplicate sequence numbers upstream of the loss and out of order data downstream of the loss. Since some reordering is present in the Internet, such a loss estimator would be most accurate near the sender. Such an audit device should treat non-ECN-capable packets with encrypted IP payload as Not-ConEx, even if they claim to be ConEx-capable, unless the operator is also using one of the other two techniques below that can audit such packets against losses.
TCP固有の損失監査：単一パスの暗号化されていない標準TCPトラフィックの場合、戦術的な監査アプローチは、損失の上流に重複したシーケンス番号として、損失の下流に順不同のデータとして表示される再送信を検出することにより、損失を測定することです。 。一部の並べ替えがインターネットに存在するため、このような損失推定器は送信者の近くで最も正確になります。そのような監査デバイスは、オペレーターがこのようなパケットを監査できる以下の他の2つの手法のいずれかを使用していない限り、暗号化されたIPペイロードを持つ非ECN対応パケットをNot-ConExとして扱う必要があります。損失。
Predominant bottleneck loss auditing: For networks designed so that losses predominantly occur under the control of one IP-aware bottleneck node on the path, the auditor could be located at this bottleneck. It could simply compare ConEx Signals with actual local packet discards (and ECN marks). This is a good model for most consumer access networks where audit accuracy could well be sufficient even if losses occasionally occur elsewhere in the network.
主要なボトルネック損失の監査：損失が主にパス上の1つのIP対応ボトルネックノードの制御下で発生するように設計されたネットワークの場合、監査人はこのボトルネックに配置できます。 ConEx信号と実際のローカルパケット破棄（およびECNマーク）を単純に比較できます。これは、ネットワークの他の場所で損失が時折発生する場合でも、監査の精度で十分であるほとんどのコンシューマーアクセスネットワークに適したモデルです。
Although the auditor at the predominant bottleneck would not be able to count losses at other nodes, transports would not know where losses were occurring either. Therefore, a transport would not know which losses it could cheat and which ones it couldn't without getting caught.
主要なボトルネックの監査人は他のノードでの損失をカウントすることはできませんが、トランスポートは損失が発生している場所もわかりません。したがって、トランスポートは、それがだまされる可能性がある損失と、捕まることなくできなかった損失を知りません。
ECN tunnel loss auditing: A network operator can arrange IP-in-IP tunnels (or IP-in-MPLS, etc.) so that any losses within the tunnels are deferred until the tunnel egress. Then, the audit function can be deployed at the egress and be aware of all losses. This is possible by enabling ECN marking on switches and routers within a tunnel, irrespective of whether end systems support ECN, by exploiting a side effect of the way tunnels handle the ECN field. After encapsulation at the tunnel ingress, the network should arrange for any non-ECN packets (with '00' in the ECN field of the outer) to be set to the ECN-capable transport (ECT(0)) codepoint. Then, if they experience congestion at one of the ECN-capable switches or routers within the tunnel, some will be ECN-marked rather than immediately dropped. However, when the tunnel decapsulator strips the outer from such an ECN-marked packet, if it finds the inner header has '00' in the ECN field (meaning that the endpoints do not support ECN), it will automatically drop the packet, assuming it complies with [RFC6040]. Thus, an audit function at the decapsulator can know which packets would have been dropped within the tunnel (and even which are genuinely ECN-marked for the end-to-end protocol). Non-ECN end systems outside the tunnel see no sign of the use of ECN internally.
ECNトンネル損失監査：ネットワークオペレーターは、IP-in-IPトンネル（またはIP-in-MPLSなど）を調整して、トンネル内の損失がトンネルの出口まで延期されるようにすることができます。次に、監査機能を出口に配置して、すべての損失を認識することができます。これは、トンネルがECNフィールドを処理する方法の副作用を利用して、エンドシステムがECNをサポートしているかどうかに関係なく、トンネル内のスイッチとルーターでECNマーキングを有効にすることで可能になります。トンネルの入口でカプセル化した後、ネットワークは、ECN非対応パケット（外部のECNフィールドに '00'を含む）がECN対応トランスポート（ECT（0））コードポイントに設定されるように調整する必要があります。次に、トンネル内のECN対応スイッチまたはルーターの1つで輻輳が発生すると、すぐにドロップされるのではなく、ECNマークが付けられます。ただし、トンネルカプセル開放装置がこのようなECNマークの付いたパケットから外部を削除するときに、内部ヘッダーのECNフィールドに「00」が含まれていることがわかると（エンドポイントがECNをサポートしていないことを意味します）、パケットを自動的にドロップします。 [RFC6040]に準拠しています。したがって、カプセル化解除装置の監査機能は、トンネル内でドロップされたパケット（さらに、エンドツーエンドプロトコルに対して本当にECNマークが付けられているパケット）を知ることができます。トンネル外の非ECNエンドシステムでは、内部でECNを使用する兆候は見られません。
In addition, other audit techniques may be identified in the future.
さらに、他の監査手法が将来的に特定される可能性があります。
[Refb-dis] gives a comprehensive inventory of attacks against audit proposed by various people. It includes pseudocode for both deterministic and statistical audit functions designed to thwart these attacks and analyses the effectiveness of an implementation. Although this work is specific to the re-ECN protocol, most of the material is useful for designing and assessing audit of other specific ConEx encodings, against both ECN and loss.
[Refb-dis]は、さまざまな人々によって提案された監査に対する攻撃の包括的な一覧を提供します。これらの攻撃を阻止し、実装の有効性を分析するように設計された確定的および統計的監査機能の両方の疑似コードが含まれています。この作業はre-ECNプロトコルに固有ですが、ほとんどの資料は、ECNと損失の両方に対して、他の特定のConExエンコーディングの監査の設計と評価に役立ちます。
The auditing function should be able to trigger sufficient sanction to discourage understating congestion [Salvatori05]. This seems to require designing the sanction in concert with the policy functions, even though they might be implemented in different parts of the network. However, [Refb-dis] proves audit and policy functions can be independent as long as audit drops sufficient traffic to 'normalise' actual congestion signals to be no greater than ConEx Signals.
監査機能は、過小評価されている輻輳を阻止するために十分な制裁を引き起こすことができるはずです[Salvatori05]。これは、ネットワークのさまざまな部分に実装されている場合でも、ポリシー機能と協調して制裁措置を設計する必要があるようです。ただし、[Refb-dis]は、監査が実際の輻輳信号をConEx信号より大きくないように「正規化」するのに十分なトラフィックをドロップする限り、監査とポリシー機能が独立していることを証明します。
Similarly, the job of incentivising the sending of ConEx-enabled packets is proper solely to policy devices independent of the audit function. The audit function's job is policy neutral, so it should be solely confined to checking for correctness within those packets that have been marked as ConEx-capable. Even if there are Not-ConEx packets mixed with ConEx packets within a flow, audit will not need to monitor any Not-ConEx packets.
同様に、ConEx対応パケットの送信を奨励する仕事は、監査機能とは独立したポリシーデバイスにのみ適切です。監査機能の仕事はポリシーに依存しないため、ConEx対応としてマークされているパケット内の正当性をチェックすることに限定する必要があります。フロー内にConExパケットと混合されたNot-ConExパケットがある場合でも、監査はNot-ConExパケットを監視する必要はありません。
Note that in the future it might prove to be desirable to provide advice on uniformly implementing sanctions, because otherwise insufficient sanctions could impair the ability to implement policy elsewhere in the network.
制裁が不十分であるとネットワーク内の他の場所にポリシーを実装する機能が損なわれる可能性があるため、将来的に制裁を一律に実装することについてアドバイスを提供することが望ましいことが判明する可能性があることに注意してください。
Some of the audit algorithms require per-flow state. This cost is expected to be tolerable because these techniques are most apropos near the edges of the network where traffic is generally much less aggregated so the state need not overwhelm any one device. The flow state required for the audit creates itself as it detects new flows. Therefore, a flow will not fail if it is re-routed away from the audit box currently holding its flow state, so auditing does not require route pinning and works fine with multipath flows.
一部の監査アルゴリズムでは、フローごとの状態が必要です。これらの技術は、トラフィックの集約が一般的にはるかに少なく、状態が1つのデバイスを圧倒する必要がないネットワークのエッジの近くで最も適切であるため、このコストは許容できると予想されます。監査に必要なフローの状態は、新しいフローを検出するときに作成されます。したがって、現在フローの状態を保持している監査ボックスから別のルートにルーティングされても、フローは失敗しません。そのため、監査では、ルートの固定は必要なく、マルチパスフローで正常に機能します。
Holding flow state seems to create a vulnerability to attacks that exhaust the auditor's memory by opening numerous new short flows. The audit function can protect itself from this attack by not allocating new flow state unless a ConEx-Marked packet arrives (e.g., credit at the start of a flow). Because policy devices rate limit ConEx-Marked packets, this sets a natural limit to the rate at which a source can create flow state in audit devices. The auditor would treat all the remaining flows without any ConEx-Marked packets as a single misbehaving aggregate.
フロー状態を保持すると、多数の新しい短いフローを開いて監査人の記憶を使い果たす攻撃に対して脆弱性が生じるようです。監査機能は、ConEx-Markedパケットが到着しない限り、新しいフローの状態を割り当てないことで、この攻撃から身を守ることができます（フローの開始時のクレジットなど）。ポリシーデバイスはConEx-Markedパケットをレート制限するため、これにより、ソースが監査デバイスでフロー状態を作成できるレートに自然な制限が設定されます。監査人は、ConEx-Markedパケットのない残りのすべてのフローを、1つの不正な集約として扱います。
Auditing can be distributed and redundant. One flow may be audited in multiple places, using multiple techniques. Some audit techniques do not require any per-flow state and can be applied to aggregate traffic. These might be able to detect the presence of understated congestion at large scale and support recursively hunting for individual flows that are understating their congestion. Even at large scales, flows can be randomly selected for individual auditing.
監査は分散して冗長にすることができます。複数の手法を使用して、1つのフローを複数の場所で監査できます。一部の監査手法は、フローごとの状態を必要とせず、トラフィックの集約に適用できます。これらは、控えめな輻輳の存在を大規模に検出し、輻輳を過小評価している個々のフローの再帰的なハンティングをサポートできる場合があります。大規模な場合でも、個々の監査のためにフローをランダムに選択できます。
Sampling techniques can also be used to bound the total auditing memory footprint, although the implementer needs to counter the tactic where a source cheats until caught by sampling, then simply discards that flow ID and starts cheating with a new one (termed 'identifier whitewashing when caught').
サンプリングテクニックを使用して、監査メモリフットプリントの合計を制限することもできますが、実装者は、サンプリングによって捕捉されるまでソースがチートする戦術に対抗する必要があり、その後、そのフローIDを破棄し、新しいフローIDでチートを開始します（「IDホワイトウォッシング」と呼ばれます）。キャッチされた '）。
For the concrete ConEx protocol encoding defined in [CONEX-DESTOPT], ConEx Credit and ConEx-Re-Echo signals are intended to be audited separately. The Credit signal can be audited directly against actual congestion (loss and ECN). However, there will be an inherent delay of at least one round trip between a congestion signal and the subsequent ConEx-Re-Echo signal it triggers, as shown in Figure 1.
[CONEX-DESTOPT]で定義された具体的なConExプロトコルエンコーディングの場合、ConEx Credit信号とConEx-Re-Echo信号は別々に監査されることを目的としています。クレジット信号は、実際の輻輳（損失とECN）に対して直接監査できます。ただし、図1に示すように、輻輳信号とそれがトリガーする後続のConEx-Re-Echo信号の間には、少なくとも1つのラウンドトリップの固有の遅延があります。
Therefore, ConEx-Re-Echo signals will need to be audited with some allowance for this delay. Further discussion of design and implementation choices for functions intended to audit this concrete ConEx encoding can be found in [CONEX-AUDIT].
したがって、ConEx-Re-Echo信号は、この遅延をある程度許容して監査する必要があります。この具体的なConExエンコーディングを監査することを目的とした機能の設計と実装の選択に関するさらなる議論は、[CONEX-AUDIT]にあります。
The ConEx abstract protocol described so far is intended to support incremental deployment in every possible respect. For convenience, the following list collects together all the features that support incremental deployment in the concrete ConEx specifications and points to further information on each:
これまでに説明したConEx抽象プロトコルは、あらゆる点で段階的な展開をサポートすることを目的としています。便宜上、次のリストは具体的なConEx仕様で増分展開をサポートするすべての機能をまとめたもので、それぞれの詳細情報を示しています。
Packets: The wire protocol encoding allows each packet to indicate whether it is using ConEx or not (see Section 4 on Encoding Congestion Exposure).
パケット：ワイヤープロトコルエンコードにより、各パケットはConExを使用しているかどうかを示すことができます（輻輳露出のエンコードに関するセクション4を参照）。
Senders: ConEx requires a modification to the source in order to send ConEx packet markings (see Section 5.2). Although ConEx support can be indicated on a packet-by-packet basis, it is likely that all the packets in a flow will either consistently support ConEx or consistently not. It is also likely that, if the implementation of a transport protocol supports ConEx, all the packets sent from that host using that protocol will be ConEx-Capable.
送信者：ConExパケットマーキングを送信するために、ConExはソースを変更する必要があります（セクション5.2を参照）。 ConExサポートはパケットごとに示すことができますが、フロー内のすべてのパケットがConExを一貫してサポートするか、一貫してサポートしない可能性があります。また、トランスポートプロトコルの実装がConExをサポートしている場合、そのプロトコルを使用してそのホストから送信されるすべてのパケットがConEx対応になる可能性があります。
The implementations of some of the transport protocols on a host might not support ConEx (e.g., the implementation of DNS over UDP might not support ConEx, while perhaps RTP over UDP and TCP will). Any non-upgraded transports and non-upgraded hosts will simply continue to send regular Not-ConEx packets as always.
ホスト上のトランスポートプロトコルの一部の実装はConExをサポートしない場合があります（たとえば、DNS over UDPの実装はConExをサポートしない場合がありますが、RTP over UDPおよびTCPはおそらくサポートします）。アップグレードされていないトランスポートとアップグレードされていないホストは、通常どおり通常のNot-ConExパケットを送信し続けます。
A network operator can create incentives for senders to voluntarily reveal ConEx information (see the item on incremental deployment by 'Networks' below).
ネットワークオペレーターは、送信者がConEx情報を自発的に公開するためのインセンティブを作成できます（以下の「ネットワーク」による増分展開に関する項目を参照してください）。
Receivers: A ConEx source should be able to work with the regular receiver for the transport in question without requiring any ConEx-specific modifications. This is true for modern transport protocols (RTCP, SCTP, etc.) and it is even true for TCP, as long as the receiver supports SACK, which is widely deployed anyway. However, it is not true for ECN feedback in TCP. The need for more precise ECN feedback in TCP is not exclusive to ConEx; for instance, Data Centre TCP [DCTCP] uses precise feedback to good effect. Therefore, if a receiver offers precise feedback, [RFC7560] it will be best if ConEx uses it (see Section 5.3).
受信者：ConExソースは、ConEx固有の変更を必要とせずに、問題のトランスポートの通常の受信者と連携できる必要があります。これは、最新のトランスポートプロトコル（RTCP、SCTPなど）に当てはまり、受信者がSACKをサポートしている限り、TCPにも当てはまります。ただし、TCPのECNフィードバックには当てはまりません。 TCPでのより正確なECNフィードバックの必要性は、ConExに限定されません。たとえば、Data Center TCP [DCTCP]は正確なフィードバックを使用して効果を上げています。したがって、受信機が正確なフィードバックを提供する場合、[RFC7560] ConExがそれを使用するのが最適です（セクション5.3を参照）。
Alternatively, without sufficiently precise congestion feedback from the receiver, the source may have to conservatively send extra ConEx markings in order to avoid understating congestion.
あるいは、受信機からの十分に正確な輻輳フィードバックがない場合、輻輳の過小評価を回避するために、ソースは追加のConExマーキングを控えめに送信する必要がある場合があります。
Proxies: Although it was stated above that ConEx requires a modification to the source, ConEx Signals could theoretically be introduced by a proxy for the source as long as it can intercept feedback from the receiver. Similarly, more precise feedback could theoretically be provided by a proxy for the receiver rather than modifying the receiver itself.
プロキシ：上記では、ConExはソースの変更が必要であると述べましたが、ConEx信号は、受信側からのフィードバックを傍受できる限り、理論的にはソースのプロキシによって導入できます。同様に、理論的には、レシーバー自体を変更するのではなく、レシーバーのプロキシーにより正確なフィードバックを提供できます。
Forwarding: No modification to forwarding or queuing is needed for ConEx.
転送：ConExの転送またはキューイングを変更する必要はありません。
However, once some ConEx is deployed, it is possible that a queue implementation could optionally take advantage of the ConEx information in packets. For instance, it has been suggested [CONEX-DESTOPT] that a queue would be more robust against flooding if it preferentially discarded Not-ConEx packets then Not-Marked ConEx packets.
ただし、一部のConExが展開されると、キューの実装がオプションでパケット内のConEx情報を利用できる可能性があります。たとえば、[CONEX-DESTOPT]は、Not-ConExパケットよりもNot-Marked ConExパケットを優先的に破棄した場合、フラッディングに対してより堅牢になることが提案されています[CONEX-DESTOPT]。
A ConEx sender re-echoes congestion whether the queues signaling congestion are ECN enabled or not. Nonetheless, an operator relying on ConEx Signals is recommended to enable ECN in queues wherever possible. This is because auditing works best if most congestion is indicated by ECN rather than loss (see Section 3). Also, monitoring rest-of-path congestion is not accurate if there are congested non-ECN queues upstream of the monitoring point (Section 5.4.2).
ConEx送信者は、輻輳を通知するキューがECN対応かどうかに関係なく、輻輳を再エコーします。それにもかかわらず、可能な限り、キューでECNを有効にするには、ConExシグナルに依存するオペレーターをお勧めします。これは、ほとんどの輻輳が損失ではなくECNで示されている場合に監査が最適に機能するためです（セクション3を参照）。また、監視ポイントの上流に非ECNキューが輻輳している場合（セクション5.4.2）、パスの残りの輻輳の監視は正確ではありません。
Networks: If a subset of traffic sources (or proxies) use ConEx Signals to reveal congestion in the internetwork layer, a network operator can choose (or not) to use this information for traffic management. As long as the end-to-end ConEx Signals are present, each network can unilaterally choose to use them -- independently of whether other networks do.
ネットワーク：トラフィックソース（またはプロキシ）のサブセットがConEx信号を使用してインターネットワークレイヤーの輻輳を明らかにする場合、ネットワークオペレーターはトラフィック管理にこの情報を使用するかどうかを選択できます。エンドツーエンドのConEx信号が存在する限り、各ネットワークは、他のネットワークがそうであるかどうかに関係なく、一方的にそれらを使用することを選択できます。
ConEx marked packets may safely traverse a network that ignores them. ConEx Signals are defined to remain unchanged once set by the sender, but some encodings may allow changes in transit (e.g., by proxies). In no circumstances will a network node change ConEx-Capable packets to Not-ConEx (network-layer encoding requirement I in Section 3.3). If necessary, endpoints should be able to detect if a network is removing ConEx Signals (network-layer encoding requirement H in Section 3.3).
ConExでマークされたパケットは、それらを無視するネットワークを安全に通過できます。送信者が設定すると、ConExシグナルは変更されないままであると定義されますが、一部のエンコーディングでは、転送中（プロキシなど）の変更が許可される場合があります。どのような状況でも、ネットワークノードはConEx対応パケットをNot-ConExに変更しません（セクション3.3のネットワーク層エンコーディング要件I）。必要に応じて、エンドポイントは、ネットワークがConEx信号を削除しているかどうかを検出できる必要があります（セクション3.3のネットワーク層エンコーディング要件H）。
An operator can deploy policy devices (Section 5.4) wherever traffic enters its network in order to monitor the downstream congestion that incoming traffic contributes to and control it if necessary. A network operator can create incentives for the developers of sending applications and transports to voluntarily reveal ConEx information. Without ConEx information, a network operator tends to have to limit the bit-rate or volume from a site more than is necessary, just in case it might congest others. With ConEx information, the operator can solely limit congestion-causing traffic and otherwise allow complete freedom. This greater freedom acts as an inducement for the source to volunteer ConEx information. An operator may also monitor whether a source transport has sent ConEx packets and treat the same transport with greater suspicion (e.g., a more stringent rate limit) whenever it selectively sends packets without ConEx support. See [RFC6789] for further discussion of deployment incentives for networks and references to scenarios where some networks use ConEx-based policy devices and others don't.
オペレーターは、着信トラフィックが寄与するダウンストリームの輻輳を監視し、必要に応じて制御するために、トラフィックがネットワークに入る場所にポリシーデバイス（セクション5.4）を展開できます。ネットワークオペレーターは、アプリケーションとトランスポートを送信する開発者が自発的にConEx情報を公開するインセンティブを作成できます。 ConEx情報がないと、ネットワークオペレーターは、他のユーザーを輻輳させる可能性がある場合に備えて、サイトからのビットレートまたはボリュームを必要以上に制限する傾向があります。オペレーターはConEx情報を使用して、混雑の原因となるトラフィックを制限するだけで、完全に自由にすることができます。この大きな自由は、ソースがConEx情報を志願する誘因として機能します。オペレーターは、ソーストランスポートがConExパケットを送信したかどうかを監視し、ConExサポートなしでパケットを選択的に送信するときはいつでも、同じトランスポートをより疑わしい（たとえば、より厳しいレート制限）で扱うことができます。ネットワークの導入インセンティブの詳細と、一部のネットワークがConExベースのポリシーデバイスを使用し、他のネットワークが使用しないシナリオへの参照については、[RFC6789]を参照してください。
An operator can deploy audit devices (Section 5.5) unilaterally within its own network to verify that traffic sources are not understating ConEx information. From the viewpoint of one network operator (say N_a), it only cares that the level of ConEx signaling is sufficient to cover congestion in its own network. If traffic continues into a congested downstream network (say N_b), it is of no concern to the first network (N_a) if the end-to-end ConEx signaling is insufficient to cover the congestion in N_b as well. This is N_b's concern, and N_b can both detect such anomalous traffic and deal with it using ConEx-based audit devices itself.
オペレーターは、独自のネットワーク内に一方的に監査デバイス（セクション5.5）を展開して、トラフィックソースがConEx情報を過小評価していないことを確認できます。 1つのネットワークオペレーター（たとえば、N_a）の観点から見ると、ConExシグナリングのレベルがそれ自体のネットワークの輻輳をカバーするのに十分であることだけが重要です。トラフィックが輻輳したダウンストリームネットワーク（N_bなど）に続く場合、エンドツーエンドのConExシグナリングがN_bの輻輳をカバーするのに不十分であるかどうかは、最初のネットワーク（N_a）には関係ありません。これはN_bの懸念事項であり、N_bはこのような異常なトラフィックを検出し、ConExベースの監査デバイス自体を使用してそれを処理できます。
The only known risk associated with ConEx is that users and applications are very likely to be motivated to underrepresent the congestion that they are causing. Significant portions of this document are about mechanisms to audit the ConEx Signals and create sufficient sanction to inhibit such underrepresentation. In particular, see Section 5.5.
ConExに関連する唯一の既知のリスクは、ユーザーとアプリケーションが引き起こしている輻輳を過小評価する動機になる可能性が非常に高いということです。このドキュメントの重要な部分は、ConExシグナルを監査し、そのような過小表示を抑制するための十分な制裁措置を作成するメカニズムについてです。特に、セクション5.5を参照してください。
Security attacks and their defences are best discussed against a concrete protocol specification, not the abstract mechanism of this document. A concrete ConEx protocol will need to be accompanied by a document describing how the protocol and its audit mechanisms defend against likely attacks. [Refb-dis] will be a useful source for such a document. It gives a comprehensive inventory of attacks against audit that have been proposed by various parties. It includes pseudocode for both deterministic and statistical audit functions designed to thwart these attacks and analyses the effectiveness of an implementation.
セキュリティ攻撃とその防御は、このドキュメントの抽象的なメカニズムではなく、具体的なプロトコル仕様に対して最もよく議論されます。具体的なConExプロトコルには、プロトコルとその監査メカニズムが可能性のある攻撃からどのように防御するかを説明するドキュメントを添付する必要があります。 [Refb-dis]はそのようなドキュメントの有用なソースになります。これは、さまざまな関係者によって提案された監査に対する攻撃の包括的な一覧を提供します。これらの攻撃を阻止し、実装の有効性を分析するように設計された確定的および統計的監査機能の両方の疑似コードが含まれています。
However, [Refb-dis] is specific to the re-ECN protocol, which signalled ECN and loss together, whereas the concrete ConEx protocol defined in [CONEX-DESTOPT] signals them separately. Therefore, although likely attacks will be similar, there will be more combinations of attacks to worry about, and defences and their analysis are likely to be a little different for ConEx.
ただし、[Refb-dis]はre-ECNプロトコルに固有であり、ECNと損失を一緒に通知しましたが、[CONEX-DESTOPT]で定義された具体的なConExプロトコルはそれらを個別に通知します。したがって、可能性のある攻撃は類似していますが、心配する必要のある攻撃の組み合わせはさらに多くなり、防御とその分析はConExでは少し異なる可能性があります。
The main known attacks that a security document for a concrete ConEx protocol will need to address are listed below and [Refb-dis] should be referred to for how re-ECN was designed to defend against similar attacks:
具体的なConExプロトコルのセキュリティドキュメントで対処する必要がある主な既知の攻撃を以下に示します。同様の攻撃を防ぐためにre-ECNがどのように設計されているかについては、[Refb-dis]を参照してください。
o Attacks on the audit function (see Section 7.5 of [Refb-dis]):
o 監査機能への攻撃（[Refb-dis]のセクション7.5を参照）：
Flow ID Whitewashing: Designing the audit function so that a source cannot gain from starting a new flow once audit has detected cheating in a previous flow.
フローIDのホワイトウォッシング：監査が前のフローでの不正行為を検出した後、ソースが新しいフローの開始から利益を得られないように監査機能を設計します。
Dragging Down an Aggregate: Avoiding audit discarding packets from all flows within an aggregate, which would allow one flow to pull down the average so that the audit function would discard packets from all flows, not just the offending flow.
集約のドラッグダウン：集約内のすべてのフローからパケットを破棄する監査を回避します。これにより、1つのフローが平均を引き下げ、監査機能が問題のあるフローだけでなくすべてのフローからパケットを破棄することができます。
Dragging Down a Spoofed Flow ID: An attacker understates ConEx markings in packets that spoof another flow, which fools the audit function into dropping the genuine user's packets.
スプーフィングされたフローIDをドラッグする：攻撃者は、別のフローをスプーフィングするパケットのConExマーキングを過小評価し、監査機能を騙して、本物のユーザーのパケットをドロップさせます。
o Attacks by networks on other networks (see Section 8.2 of [Refb-dis]):
o 他のネットワーク上のネットワークによる攻撃（[Refb-dis]のセクション8.2を参照）：
Dummy Traffic: Sending dummy traffic across a border with understated ConEx markings to bring down the average ConEx markings in the aggregate of border traffic. This attack can be combined with a TTL that expires before the packets reach an audit function.
ダミートラフィック：控えめなConExマーキングを使用して境界を越えてダミートラフィックを送信し、ボーダートラフィックの合計の平均ConExマーキングを下げます。この攻撃は、パケットが監査機能に到達する前に期限が切れるTTLと組み合わせることができます。
Signal Poisoning with 'Cancelled' Marking: Sending high volumes of valid packets that are both ConEx-Marked and ECN-marked, which seems to represent congestion upstream, but it makes these packets immune to being further ECN-marked downstream.
「キャンセルされた」マーキングによるシグナルポイズニング：ConEx-MarkedとECN-markedの両方である有効なパケットを大量に送信します。これは、アップストリームの輻輳を表しているようですが、これらのパケットはさらに下流のECNマークの影響を受けません。
It is planned to document all known attacks and their defences (including all of the above) in the RFC series against a concrete ConEx protocol specification. In the interim, [Refb-dis] and its references should be referred to for details and ways to address these attacks in the case of re-ECN.
具体的なConExプロトコル仕様に対して、RFCシリーズですべての既知の攻撃とその防御（上記のすべてを含む）を文書化する予定です。当面の間、[Refb-dis]とそのリファレンスは、再ECNの場合にこれらの攻撃に対処する詳細と方法について参照する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[CheapPseud] Friedman, E. and P. Resnick, "The Social Cost of Cheap Pseudonyms", Journal of Economics and Management Strategy, Volume 10, Issue 2, pp. 173-199, DOI 10.1111/j.1430-9134.2001.00173.x, Summer 2001.
[CheapPseud]フリードマン、E。およびP.レズニック、「安価な偽名の社会的コスト」、経済学と経営戦略、第10巻、第2号、pp。173-199、DOI 10.1111 / j.1430-9134.2001.00173 .x、2001年夏。
[CONEX-AUDIT] Wagner, D. and M. Kuehlewind, "Auditing of Congestion Exposure (ConEx) signals", Work in Progress, draft-wagner-conex-audit-01, February 2014.
[CONEX-AUDIT] Wagner、D.、M。Kuehlewind、「Congestion Exposure（ConEx）信号の監査」、Work in Progress、draft-wagner-conex-audit-01、2014年2月。
[CONEX-DESTOPT] Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6 Destination Option for Congestion Exposure (ConEx)", Work in Progress, draft-ietf-conex-destopt-11, October 2015.
[CONEX-DESTOPT]クリシュナン、S。、キュールウィンド、M。、およびC.ウセンド、「輻輳露出のIPv6宛先オプション（ConEx）」、作業中、draft-ietf-conex-destopt-11、2015年10月。
[DCTCP] 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, <http://portal.acm.org/citation.cfm?id=1851192>.
[DCTCP] 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、pages 63-74、DOI 10.1145 / 1851182.1851192、October 2010、<http://portal.acm.org/citation.cfm?id=1851192>。
[Evol_cc] Gibbens, R. and F. Kelly, "Resource pricing and the evolution of congestion control", Automatica, Volume 35, Issue 12, pages 1969-1985, DOI 10.1016/S0005-1098(99)00135-1, December 1999, <http://www.sciencedirect.com/science/article/pii/ S0005109899001351>.
[Evol_cc] Gibbens、R。およびF. Kelly、「リソースの価格設定と輻輳制御の進化」、Automatica、Volume 35、Issue 12、1969-1985ページ、DOI 10.1016 / S0005-1098（99）00135-1、12月1999、<http://www.sciencedirect.com/science/article/pii/ S0005109899001351>。
[FairerFaster] Briscoe, B., "A Fairer, Faster Internet Protocol", IEEE Spectrum, pages 38-43, DOI 10.1109/MSPEC.2008.4687368, December 2008, <http://spectrum.ieee.org/telecom/standards/ a-fairer-faster-internet-protocol>.
[FairerFaster] Briscoe、B。、「A Fairer、Faster Internet Protocol」、IEEE Spectrum、38〜43ページ、DOI 10.1109 / MSPEC.2008.4687368、2008年12月、<http://spectrum.ieee.org/telecom/standards/ a-fairer-faster-internet-protocol>。
[ISOLATION-POLICING] Briscoe, B., "Network Performance Isolation using Congestion Policing", Work in Progress, draft-briscoe-conex-policing-01, February 2014.
[ISOLATION-POLICING] Briscoe、B。、「輻輳ポリシングを使用したネットワークパフォーマンスの分離」、作業中、draft-briscoe-conex-policing-01、2014年2月。
[RE-ECN-MOTIVATION] Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith, "Re-ECN: A Framework for adding Congestion Accountability to TCP/IP", Work in Progress, draft-briscoe-conex-re-ecn-motiv-03, March 2014.
[RE-ECN-MOTIVATION] Briscoe、B.、Jacquet、A.、Moncaster、T。、およびA. Smith、「Re-ECN：A Framework for Congestion Accountability to TCP / IP」、Work in Progress、draft- briscoe-conex-re-ecn-motiv-03、2014年3月。
[RE-ECN-TCP] Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith, "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Work in Progress, draft-briscoe-conex-re-ecn-tcp-04, July 2014.
[RE-ECN-TCP] Briscoe、B.、Jacquet、A.、Moncaster、T.、A。Smith、「Re-ECN：Adding Accountability for Causing Congestion to TCP / IP」、Work in Progress、draft-briscoe -conex-re-ecn-tcp-04、2014年7月。
[Re-fb] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C., Salvatori, A., Soppera, A., and M. Koyabe, "Policing Congestion Response in an Internetwork Using Re-Feedback", ACM SIGCOMM Computer Communication Review, Volume 35, Issue 4, pages 277--288, DOI 10.1145/1090191.1080124, August 2005, <http://portal.acm.org/citation.cfm?id=1080091.1080124>.
[Re-fb] Briscoe、B.、Jacquet、A.、Di Cairano-Gilfedder、C.、Salvatori、A.、Soppera、A。、およびM. Koyabe、「Re-Feedbackを使用したインターネットワークでの輻輳応答のポリシング」 、ACM SIGCOMM Computer Communication Review、Volume 35、Issue 4、ページ277--288、DOI 10.1145 / 1090191.1080124、2005年8月、<http://portal.acm.org/citation.cfm?id=1080091.1080124>。
[Refb-dis] Briscoe, B., "Re-feedback: Freedom with Accountability for Causing Congestion in a Connectionless Internetwork", PhD Dissertation, University College London, May 2009, <http://discovery.ucl.ac.uk/16274/>.
[Refb-dis] Briscoe、B。、「Re-feedback：Freedom with Caucing原因Congestion in Connectionless Internetwork」、博士論文、ロンドン大学ユニバーシティカレッジ、2009年5月、<http://discovery.ucl.ac.uk/ 16274 />。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <http://www.rfc-editor.org/info/rfc2018>.
[RFC2018] Mathis、M.、Madhavi、J.、Floyd、S。、およびA. Romanow、「TCP選択的確認応答オプション」、RFC 2018、DOI 10.17487 / RFC2018、1996年10月、<http：//www.rfc- editor.org/info/rfc2018>。
[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>。
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, DOI 10.17487/RFC3514, April 2003, <http://www.rfc-editor.org/info/rfc3514>.
[RFC3514] Bellovin、S。、「IPv4ヘッダーのセキュリティフラグ」、RFC 3514、DOI 10.17487 / RFC3514、2003年4月、<http://www.rfc-editor.org/info/rfc3514>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, <http://www.rfc-editor.org/info/rfc5348>.
[RFC5348] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：Protocol Specification」、RFC 5348、DOI 10.17487 / RFC5348、2008年9月、<http： //www.rfc-editor.org/info/rfc5348>。
[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>。
[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>。
[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>。
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <http://www.rfc-editor.org/info/rfc6817>.
[RFC6817] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、RFC 6817、DOI 10.17487 / RFC6817、2012年12月、<http：// www.rfc-editor.org/info/rfc6817>。
[RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion Notification", BCP 41, RFC 7141, DOI 10.17487/RFC7141, February 2014, <http://www.rfc-editor.org/info/rfc7141>.
[RFC7141] Briscoe、B。およびJ. Manner、「Byte and Packet Congestion Notification」、BCP 41、RFC 7141、DOI 10.17487 / RFC7141、2014年2月、<http://www.rfc-editor.org/info/rfc7141 >。
[RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, "Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback", RFC 7560, DOI 10.17487/RFC7560, August 2015, <http://www.rfc-editor.org/info/rfc7560>.
[RFC7560] Kuehlewind、M。、編、Scheffenegger、R。、およびB. Briscoe、「Problem Statement and Requirements for Accuracy in Explicit Congestion Notification（ECN）Feedback」、RFC 7560、DOI 10.17487 / RFC7560、2015年8月、 <http://www.rfc-editor.org/info/rfc7560>。
[Salvatori05] Salvatori, A., "Closed Loop Traffic Policing", Politecnico Torino and Institut Eurecom Masters Thesis, September 2005.
[Salvatori05] Salvatori、A。、「クローズドループトラフィックポリシング」、ポリテクニコトリノおよびInstitut Eurecom修士論文、2005年9月。
[TCP-MODIFICATION] Kuehlewind, M. and R. Scheffenegger, "TCP modifications for Congestion Exposure", Work in Progress, draft-ietf-conex-tcp-modifications-10, October 2015.
[TCP-MODIFICATION] Kuehlewind、M。、およびR. Scheffenegger、「輻輳露出のためのTCP変更」、作業中、draft-ietf-conex-tcp-modifications-10、2015年10月。
Acknowledgments
謝辞
This document was improved by review comments from Toby Moncaster, Nandita Dukkipati, Mirja Kuehlewind, Caitlin Bestler, Marcelo Bagnulo Braun, John Leslie, Ingemar Johansson, and David Wagner.
このドキュメントは、Toby Moncaster、Nandita Dukkipati、Mirja Kuehlewind、Caitlin Bestler、Marcelo Bagnulo Braun、John Leslie、Ingemar Johansson、およびDavid Wagnerからのレビューコメントによって改善されました。
Bob Briscoe's work on this specification received part-funding from the European Union's Seventh Framework Programme FP7/2007-2013 under the Trilogy 2 project, grant agreement no. 317756. The views expressed here are solely those of the authors.
Bob Briscoeのこの仕様に関する作業は、EUの第7フレームワークプログラムFP7 / 2007-2013からTrilogy 2プロジェクトの下で一部助成を受けました。 317756.ここで表明された見解は、執筆者の見解のみです。
Authors' Addresses
著者のアドレス
Matt Mathis Google, Inc. 1600 Amphitheater Parkway Mountain View, California 93117 United States
Matt Mathis Google、Inc. 1600 Amphitheatre Parkway Mountain View、California 93117 United States
Email: mattmathis@google.com
Bob Briscoe BT (now at Simula Research Laboratory)
Bob Briscoe BT（現在はSimula Research Laboratory）
Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/