[要約] RFC 6789は、Congestion Exposure（ConEx）の概念と使用例に関するドキュメントです。その目的は、ネットワークの過負荷状態を検出し、トラフィック制御を改善するためのフレームワークを提供することです。
Internet Engineering Task Force (IETF) B. Briscoe, Ed.
Request for Comments: 6789 BT
Category: Informational R. Woundy, Ed.
ISSN: 2070-1721 Comcast
A. Cooper, Ed.
CDT
December 2012
Congestion Exposure (ConEx) Concepts and Use Cases
輻輳露出（ConEx）の概念と使用例
Abstract
概要
This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today.
このドキュメントは、Congestion Exposure（ConEx）プロトコルに関する一連のドキュメントへのエントリポイントを提供します。 IPノードにConExマーキングを含める動機、つまりネットワークノードに輻輳に関する情報を公開する動機について説明します。このような情報にはさまざまな用途がありますが、このドキュメントでは、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/rfc6789.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6789で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Congestion . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Congestion-Volume . . . . . . . . . . . . . . . . . . . . 5
2.3. Rest-of-Path Congestion . . . . . . . . . . . . . . . . . 6
2.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Core Use Case: Informing Traffic Management . . . . . . . . . 7
3.1. Use Case Description . . . . . . . . . . . . . . . . . . . 7
3.2. Additional Benefits . . . . . . . . . . . . . . . . . . . 9
3.3. Comparison with Existing Approaches . . . . . . . . . . . 9
4. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 11
5. Deployment Arrangements . . . . . . . . . . . . . . . . . . . 12
6. Experimental Considerations . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Informative References . . . . . . . . . . . . . . . . . . . . 15
The power of Internet technology comes from multiplexing shared capacity with packets rather than circuits. Network operators aim to provide sufficient shared capacity, but when too much packet load meets too little shared capacity, congestion results. Congestion appears as either increased delay, dropped packets, or packets explicitly marked with Explicit Congestion Notification (ECN) markings [RFC3168]. As described in Figure 1, congestion control currently relies on the transport receiver detecting these 'Congestion Signals' and informing the transport sender in 'Congestion Feedback Signals'. The sender is then expected to reduce its rate in response.
インターネット技術の力は、共有容量を回線ではなくパケットで多重化することにあります。ネットワークオペレーターは十分な共有容量を提供することを目指していますが、パケット負荷が多すぎて共有容量が少なすぎると、輻輳が発生します。輻輳は、遅延の増加、パケットのドロップ、または明示的輻輳通知（ECN）マーキング[RFC3168]で明示的にマークされたパケットのいずれかとして表示されます。図1で説明されているように、輻輳制御は現在、トランスポートレシーバーがこれらの「輻輳信号」を検出し、トランスポート送信者に「輻輳フィードバック信号」を通知することに依存しています。その後、送信者は応答でそのレートを下げることが期待されます。
This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It focuses on the motivation for including a ConEx marking at the IP layer. (A companion document, [CONEX-ABS], focuses on the mechanics of the protocol.) Briefly, the idea is for the sender to continually signal expected congestion in the headers of any data it sends. To a first approximation, the sender does this by relaying the 'Congestion Feedback Signals' back into the IP layer. They then travel unchanged across the network to the receiver (shown as 'IP-Layer-ConEx-Signals' in Figure 1). This enables IP-layer devices on the path to see information about the whole-path congestion.
このドキュメントは、Congestion Exposure（ConEx）プロトコルに関する一連のドキュメントへのエントリポイントを提供します。 IP層にConExマーキングを含める動機に焦点を当てています。 （関連ドキュメント[CONEX-ABS]は、プロトコルのメカニズムに焦点を当てています。）簡単に言うと、送信者は、送信するデータのヘッダーで予想される輻輳を継続的に通知することです。最初の近似として、送信者は「輻輳フィードバック信号」をIP層に中継することによってこれを行います。次に、ネットワークを介して変更されずにレシーバーに到達します（図1で「IP-Layer-ConEx-Signals」と表示）。これにより、パス上のIPレイヤーデバイスは、パス全体の輻輳に関する情報を見ることができます。
,---------. ,---------.
|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 ConEx Protocol in the Internet Architecture
図1：インターネットアーキテクチャのConExプロトコル
One of the key benefits of exposing this congestion information at the IP layer is that it makes the information available to network operators for use as input into their traffic management procedures. A ConEx-enabled sender signals expected whole-path congestion, which is approximately the congestion at least a round-trip time earlier as reported by the receiver to the sender (Figure 1). The ConEx signal is a mark in the IP header that is easy for any IP device to read. Therefore, a node performing traffic management can count congestion as easily as it might count data volume today by simply counting the volume of packets with ConEx markings.
この輻輳情報をIP層で公開することの主な利点の1つは、ネットワークオペレーターがその情報をトラフィック管理手順への入力として使用できるようにすることです。 ConEx対応の送信側は、予想される全パスの輻輳を通知します。これは、受信側から送信側に報告されたラウンドトリップ時間の少なくとも前の輻輳とほぼ同じです（図1）。 ConEx信号は、IPヘッダー内のマークであり、どのIPデバイスでも読み取りが容易です。したがって、トラフィック管理を実行するノードは、ConExマーキングでパケットの量を数えるだけで、今日のデータ量を数えるのと同じくらい簡単に輻輳を数えることができます。
ConEx-based traffic management can make highly efficient use of capacity. In times of no congestion, all traffic management restraints can be removed, leaving the network's full capacity available to all its users. If some users on the network cause disproportionate congestion, the traffic management function can learn about this and directly limit those users' traffic in order to protect the service of other users sharing the same capacity. ConEx-based traffic management thus presents a step change in terms of the options available to network operators for managing traffic on their networks.
ConExベースのトラフィック管理では、容量を非常に効率的に使用できます。輻輳が発生していないときは、すべてのトラフィック管理の制約を取り除くことができるため、ネットワークの全容量をすべてのユーザーが利用できます。ネットワーク上の一部のユーザーが不均衡な輻輳を引き起こした場合、トラフィック管理機能はこれについて学習し、同じ容量を共有する他のユーザーのサービスを保護するためにそれらのユーザーのトラフィックを直接制限できます。このように、ConExベースのトラフィック管理は、ネットワークオペレーターがネットワーク上のトラフィックを管理するために利用できるオプションに関して、段階的な変化をもたらします。
The remainder of this document explains the concepts behind ConEx and how exposing congestion can significantly improve Internet traffic management, among other benefits. Section 2 introduces a number of concepts that are fundamental to understanding how ConEx-based traffic management works. Section 3 shows how ConEx can be used for traffic management, discusses additional benefits from such usage, and compares ConEx-based traffic management to existing traffic management approaches. Section 4 discusses other related use cases. Section 5 briefly discusses deployment arrangements. Section 6 suggests open issues that experiments in the use of ConEx could usefully be designed to answer. The final sections are standard RFC back matter.
このドキュメントの残りの部分では、ConExの背後にある概念と、他の利点の中でも特に、輻輳を公開するとインターネットトラフィック管理を大幅に改善できる方法について説明します。セクション2では、ConExベースのトラフィック管理がどのように機能するかを理解するための基本的な概念をいくつか紹介します。セクション3では、トラフィック管理にConExを使用する方法を示し、そのような使用による追加の利点について説明し、ConExベースのトラフィック管理を既存のトラフィック管理アプローチと比較します。セクション4では、他の関連するユースケースについて説明します。セクション5では、展開の配置について簡単に説明します。セクション6は、ConExを使用した実験が回答するように設計できると考えられる未解決の問題を提案しています。最後のセクションは、標準のRFCバックマターです。
The remainder of the core ConEx document suite consists of:
コアとなるConExドキュメントスイートの残りの部分は、以下で構成されます。
[CONEX-ABS], which provides an abstract encoding of ConEx signals, explains the ConEx audit and security mechanisms, and describes incremental deployment features;
[CONEX-ABS]は、ConEx信号の抽象的なエンコーディングを提供し、ConEx監査およびセキュリティメカニズムを説明し、増分展開機能を説明します。
[CONEX-DESTOPT], which specifies the IPv6 destination option encoding for ConEx;
[CONEX-DESTOPT]、ConExのIPv6宛先オプションエンコーディングを指定します。
[TCP-MOD], which specifies TCP-sender modifications for use of ConEx;
[TCP-MOD]。これは、ConExを使用するためのTCP送信者の変更を指定します。
and the following documents, which describe some feasible scenarios for deploying ConEx:
およびConExを展開するためのいくつかの実行可能なシナリオを説明する次のドキュメント：
[CONEX-DEPLOY], which describes a scenario around a fixed broadband access network;
[CONEX-DEPLOY]は、固定ブロードバンドアクセスネットワークに関するシナリオを説明しています。
[CONEX-MOBILE], which describes a scenario around a mobile communications provider;
[CONEX-MOBILE]：モバイル通信プロバイダーに関するシナリオを説明します。
[CONEX-DATA], which describes how ConEx could be used for performance isolation between tenants of a data centre.
[CONEX-DATA]。データセンターのテナント間のパフォーマンス分離にConExを使用する方法を説明します。
ConEx relies on a precise definition of congestion and a number of newer concepts that are introduced in this section. Definitions are summarized in Section 2.4.
ConExは、輻輳の正確な定義と、このセクションで紹介するいくつかの新しい概念に依存しています。定義はセクション2.4に要約されています。
Despite its central role in network control and management, congestion is a remarkably difficult concept to define. Experts in different disciplines and with different perspectives define congestion in a variety of ways [Bauer09].
ネットワークの制御と管理におけるその中心的な役割にもかかわらず、輻輳は定義するのが非常に難しい概念です。さまざまな分野のさまざまな視点を持つ専門家は、さまざまな方法で輻輳を定義します[Bauer09]。
The definition used for the purposes of ConEx is expressed as the probability of packet loss (or the probability of packet marking if ECN is in use). This definition focuses on how congestion is measured, rather than describing congestion as a condition or state.
ConExの目的で使用される定義は、パケット損失の確率（またはECNが使用されている場合はパケットマーキングの確率）として表されます。この定義は、混雑を状態または状態として説明するのではなく、混雑を測定する方法に焦点を当てています。
The metric that ConEx exposes is congestion-volume: the volume of bytes dropped or ECN-marked in a given period of time. Counting congestion-volume allows each user to be held responsible for his or her contribution to congestion. Congestion-volume can only be a property of traffic, whereas congestion can be a property of traffic or a property of a link or a path.
ConExが公開するメトリックはcongestion-volumeです：一定期間内にドロップされた、またはECNマークが付けられたバイトのボリューム。輻輳ボリュームをカウントすることで、各ユーザーが輻輳への貢献について責任を持つことができます。輻輳ボリュームはトラフィックのプロパティのみである可能性がありますが、輻輳はトラフィックのプロパティまたはリンクやパスのプロパティである可能性があります。
To understand congestion-volume, consider a simple example. Imagine Alice sends 1 GB of a file while the loss-probability is a constant 0.2%. Her contribution to congestion -- her congestion-volume -- is 1 GB x 0.2% = 2 MB. If she then sends another 3 GB of the file while the loss-probability is 0.1%, this adds 3 MB to her congestion-volume. Her total contribution to congestion is then 2 MB + 3 MB = 5 MB.
輻輳ボリュームを理解するために、簡単な例を考えます。アリスが1 GBのファイルを送信し、損失の確率が0.2％と一定であると想像してください。輻輳への彼女の貢献-彼女の輻輳ボリューム-は1 GB x 0.2％= 2 MBです。その後、損失確率が0.1％であるときに、さらに3 GBのファイルを送信すると、輻輳ボリュームに3 MBが追加されます。混雑への彼女の合計貢献はそれから2 MB + 3 MB = 5 MBです。
Fortunately, measuring Alice's congestion-volume on a real network does not require the kind of arithmetic shown above, because congestion-volume can be directly measured by counting the total volume of Alice's traffic that gets discarded or ECN-marked. (A queue with varying percentage loss does these multiplications and additions inherently.) With ConEx, network operators can count congestion-volume using techniques very similar to those they use for counting volume.
幸い、実際のネットワークでアリスの輻輳ボリュームを測定する場合、上記のような計算は必要ありません。輻輳ボリュームは、破棄されるか、またはECNマークが付けられたアリスのトラフィックの総ボリュームをカウントすることで直接測定できるためです。 （損失の割合が異なるキューは、これらの乗算と追加を本質的に実行します。）ConExを使用すると、ネットワークオペレーターは、ボリュームのカウントに使用する手法と非常に類似した手法を使用して、輻輳ボリュームをカウントできます。
At a particular measurement point within a network, "rest-of-path congestion" (also known as "downstream congestion") is the level of congestion that a traffic flow is expected to experience between the measurement point and its final destination. "Upstream congestion" is the congestion experienced up to the measurement point.
ネットワーク内の特定の測定ポイントでは、「パスの残りの輻輳」（「ダウンストリームの輻輳」とも呼ばれます）は、測定ポイントとその最終宛先の間でトラフィックフローが経験すると予想される輻輳のレベルです。 「アップストリーム輻輳」は、測定ポイントまでに発生した輻輳です。
If traffic is ECN-capable, ECN signals monitored in the middle of a network will indicate the congestion experienced so far on the path (upstream congestion). In contrast, the ConEx signals inserted into IP headers as shown in Figure 1 indicate the congestion along a whole path from transport source to transport destination. Therefore, if a measurement point detects both of these signals, it can subtract the level of ECN (upstream congestion) 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). A measurement point can calculate this measurement in the aggregate, across all flows.
トラフィックがECN対応の場合、ネットワークの途中で監視されるECN信号は、パス上でこれまでに発生した輻輳（上流の輻輳）を示します。対照的に、図1に示すようにIPヘッダーに挿入されたConEx信号は、転送元から転送先へのパス全体に沿った輻輳を示します。したがって、測定ポイントがこれらの信号の両方を検出した場合、ECX（上流の輻輳）のレベルをConEx（パス全体）のレベルから差し引いて、監視ポイントとパケットの間でパケットが経験する可能性が高い輻輳の測定値を導き出すことができます。彼らの目的地（残りのパスの混雑）。測定ポイントは、すべてのフローにわたって、この測定値を合計で計算できます。
A network monitor can usually accurately measure upstream congestion only if the traffic it observes is ECN-capable. [CONEX-ABS] further discusses the constraints around the network's ability to measure upstream and rest-of-path congestion in these circumstances. However, there are a number of initial deployment arrangements that benefit from ConEx but work without ECN (see Section 5).
通常、ネットワークモニターは、監視するトラフィックがECN対応である場合にのみ、アップストリームの輻輳を正確に測定できます。 [CONEX-ABS]は、これらの状況でのアップストリームおよびパスの残りの輻輳を測定するネットワークの機能に関する制約についてさらに説明します。ただし、ConExの恩恵を受けるがECNなしで機能する多くの初期導入の取り決めがあります（セクション5を参照）。
Congestion: In general, congestion occurs when any user's traffic suffers loss, ECN marking, or increased delay as a result of one or more network resources becoming overloaded. For the purposes of ConEx, congestion is measured using the concrete signals provided by loss and ECN markings (delay is not considered). Congestion is measured as the probability of loss or the probability of ECN marking, usually expressed as a dimensionless percentage.
輻輳：一般に、1つ以上のネットワークリソースが過負荷になり、ユーザーのトラフィックが失われたり、ECNマーキングが行われたり、遅延が増加したりすると、輻輳が発生します。 ConExの目的のために、輻輳は、損失とECNマーキングによって提供される具体的な信号を使用して測定されます（遅延は考慮されません）。輻輳は、損失の確率またはECNマーキングの確率として測定され、通常は無次元のパーセンテージで表されます。
Congestion-volume: For any granularity of traffic (packet, flow, aggregate, link, etc.), the volume of bytes dropped or ECN-marked in a given period of time. Conceptually, data volume multiplied by the congestion each packet of the volume experienced. This is usually expressed in bytes (or kB, MB, etc.).
輻輳ボリューム：トラフィックの細分性（パケット、フロー、集約、リンクなど）の場合、特定の期間にドロップまたはECNマークが付けられたバイトのボリューム。概念的には、データボリュームに、発生したボリュームの各パケットの輻輳を掛けたものです。これは通常、バイト（またはkB、MBなど）で表されます。
Congestion policer: A logical entity that allows a network operator to monitor each user's congestion-volume and enforce congestion-volume limits (discussed in Section 3.1).
輻輳ポリサー：ネットワークオペレーターが各ユーザーの輻輳ボリュームを監視し、輻輳ボリュームの制限を実施できるようにする論理エンティティ（セクション3.1で説明）。
Rest-of-path congestion (or downstream congestion): The congestion a flow of traffic is expected to experience on the remainder of its path. In other words, at a measurement point in the network, the rest-of-path congestion is the congestion the traffic flow has yet to experience as it travels from that point to the receiver. Upstream congestion is usually expressed as a dimensionless percentage.
パスの残りの輻輳（またはダウンストリームの輻輳）：トラフィックのフローがそのパスの残りの部分で発生すると予想される輻輳。言い換えると、ネットワークの測定ポイントで、パスの残りの輻輳は、トラフィックフローがそのポイントから受信機に移動するときにトラフィックフローがまだ経験していない輻輳です。上流の混雑は通常、無次元のパーセンテージとして表されます。
Upstream congestion: The accumulated congestion experienced by a traffic flow thus far, relative to a point along its path. In other words, at a measurement point in the network, the upstream congestion is the accumulated congestion the traffic flow has experienced as it travels from the sender to that point. At the receiver, this is equivalent to the end-to-end congestion level that (usually) is reported back to the sender. This is usually expressed as a dimensionless percentage.
上流の渋滞：パスに沿ったポイントと比較して、これまでにトラフィックフローが経験した累積された渋滞。つまり、ネットワークの測定ポイントでの上流の輻輳は、トラフィックフローが送信者からそのポイントに移動するときにトラフィックフローが経験した累積された輻輳です。受信側では、これは（通常は）送信側に報告されるエンドツーエンドの輻輳レベルに相当します。これは通常、無次元のパーセンテージとして表されます。
Network operator (or provider): Operator of a residential, commercial, enterprise, campus, or other network.
ネットワークオペレーター（またはプロバイダー）：住宅、商業、企業、キャンパス、またはその他のネットワークのオペレーター。
User: The contractual entity that represents an individual, household, business, or institution that uses the service of a network operator. There is no implication that the contract has to be commercial; for instance, the users of a university or enterprise network service could be students or employees who do not pay for access, but may be required to comply with some form of contract or acceptable use policy. There is also no implication that every user is an end user. Where two networks form a customer-provider relationship, the term "user" applies to the customer network.
ユーザー：ネットワークオペレーターのサービスを使用する個人、世帯、企業、または機関を表す契約上のエンティティ。契約が商業的でなければならないという意味はありません。たとえば、大学または企業のネットワークサービスのユーザーは、アクセスに料金を支払わない学生または従業員である可能性がありますが、何らかの形の契約または利用規定に準拠する必要がある場合があります。すべてのユーザーがエンドユーザーであるという意味もありません。 2つのネットワークが顧客とプロバイダーの関係を形成する場合、「ユーザー」という用語は顧客のネットワークに適用されます。
[CONEX-ABS] gives further definitions for aspects of ConEx related to protocol mechanisms.
[CONEX-ABS]は、プロトコルメカニズムに関連するConExの側面の詳細な定義を提供します。
This section explains how ConEx could be used as the basis for traffic management, highlights additional benefits derived from having ConEx-aware nodes on the network, and compares ConEx-based traffic management to existing approaches.
このセクションでは、ConExをトラフィック管理の基礎として使用する方法を説明し、ネットワークにConEx対応ノードを配置することから得られる追加の利点を強調し、ConExベースのトラフィック管理を既存のアプローチと比較します。
One of the key benefits that ConEx can deliver is in helping network operators to improve how they manage traffic on their networks. Consider the common case of a commercial broadband network where a relatively small number of users place disproportionate demand on network resources, at times resulting in congestion. The network operator seeks a way to manage traffic such that the traffic that contributes more to congestion bears more of the brunt of the management.
ConExが提供できる主な利点の1つは、ネットワークオペレーターがネットワーク上のトラフィックを管理する方法を改善できるようにすることです。比較的少数のユーザーがネットワークリソースに不釣り合いな要求を出し、時として輻輳が発生する、商用ブロードバンドネットワークの一般的なケースを考えてみます。ネットワークオペレータは、輻輳により寄与するトラフィックが管理の負担を大きくするように、トラフィックを管理する方法を模索しています。
Assuming ConEx signals are visible at the IP layer, the network operator can accomplish this by placing a congestion policer at an enforcement point within the network and configuring it with a traffic management policy that monitors each user's contribution to congestion. As described in [CONEX-ABS] and elaborated in [CongPol], one way to implement a congestion policer is in a similar way to a bit-rate policer, except that it monitors congestion-volume (based on IP-layer ConEx signals) rather than bit rate. When implemented as a token bucket, the tokens provide users with the right to cause bits of congestion-volume, rather than to send bits of data volume. The fill rate represents each user's congestion-volume quota.
ネットワークオペレーターは、ConEx信号がIPレイヤーで可視であると想定して、ネットワーク内の実施ポイントに輻輳ポリサーを配置し、輻輳への各ユーザーの寄与を監視するトラフィック管理ポリシーで構成することにより、これを実現できます。 [CONEX-ABS]で説明され、[CongPol]で詳しく説明されているように、輻輳ポリサーを実装する1つの方法は、（IPレイヤーConEx信号に基づいて）輻輳ボリュームを監視することを除いて、ビットレートポリサーと同様です。ビットレートではなく。トークンバケットとして実装されたトークンは、データボリュームのビットを送信するのではなく、輻輳ボリュームのビットを発生させる権利をユーザーに提供します。フィルレートは、各ユーザーの輻輳ボリュームクォータを表します。
The congestion policer monitors the ConEx signals of the traffic entering the network. As long as the network remains uncongested and users stay within their quotas, no action is taken. When the network becomes congested and a user exhausts his quota, some action is taken against the traffic that breached the quota in accordance with the network operator's traffic management policy. For example, the traffic may be dropped, delayed, or marked with a lower QoS class. In this way, traffic is managed according to its contribution to congestion -- not some application- or flow-specific policy -- and is not managed at all during times of no congestion.
輻輳ポリサーは、ネットワークに入るトラフィックのConEx信号を監視します。ネットワークが混雑しておらず、ユーザーが割り当て量内にいる限り、アクションは実行されません。ネットワークが混雑し、ユーザーがクォータを使い果たすと、ネットワークオペレーターのトラフィック管理ポリシーに従って、クォータに違反したトラフィックに対して何らかのアクションが実行されます。たとえば、トラフィックがドロップ、遅延、またはより低いQoSクラスでマークされる場合があります。このようにして、トラフィックは輻輳への寄与に応じて管理されます-一部のアプリケーションまたはフロー固有のポリシーではなく-輻輳のない時間帯にはまったく管理されません。
As an example of how a network operator might employ a ConEx-based traffic management system, consider a typical DSL network architecture (as elaborated in [TR-059] and [TR-101]). Traffic is routed from regional and global IP networks to an operator-controlled IP node, the Broadband Remote Access Server (BRAS). From the BRAS, traffic is delivered to access nodes. The BRAS carries enhanced functionality, including IP QoS and traffic management capabilities.
ネットワークオペレーターがConExベースのトラフィック管理システムを使用する方法の例として、典型的なDSLネットワークアーキテクチャ（[TR-059]および[TR-101]で詳しく説明されている）を検討してください。トラフィックは、地域およびグローバルIPネットワークからオペレーター制御のIPノードであるブロードバンドリモートアクセスサーバー（BRAS）にルーティングされます。 BRASから、トラフィックはアクセスノードに配信されます。 BRASは、IP QoSやトラフィック管理機能などの拡張機能を備えています。
By deploying a congestion policer at the BRAS location, the network operator can measure the congestion-volume created by users within the access nodes and police misbehaving users before their traffic affects others on the access network. The policer would be provisioned with a traffic management policy, perhaps directing the BRAS to drop packets from users that exceed their congestion-volume quotas during times of congestion. Those users' apps would be likely to react in the typical way to drops, backing off (assuming at least some use TCP), and thereby lowering the users' congestion-volumes back within the quota limits. If none of a user's apps responds, the policer would continue to increase focused drops and effectively enforce its own congestion control.
ネットワークオペレーターは、BRASロケーションに輻輳ポリサーを配置することにより、アクセスノード内のユーザーによって作成された輻輳ボリュームを測定し、トラフィックがアクセスネットワーク上の他のユーザーに影響を与える前に、ユーザーの不正動作を監視できます。ポリサーにはトラフィック管理ポリシーがプロビジョニングされ、おそらくBRASに、輻輳時に輻輳ボリュームクォータを超えるユーザーからのパケットをドロップするように指示します。これらのユーザーのアプリは、通常の方法でドロップに反応し、バックオフし（少なくとも一部はTCPを使用していると想定）、ユーザーの輻輳ボリュームを割り当て制限内に戻します。ユーザーのどのアプリも応答しない場合、ポリサーは引き続き集中ドロップを増やし、独自の輻輳制御を効果的に実施します。
The ConEx-based approach to traffic management has a number of benefits in addition to efficient management of traffic. It provides incentives for users to make use of "scavenger" transport protocols, such as the Low Extra Delay Background Transport [LEDBAT], that provide ways for bulk-transfer applications to rapidly yield when interactive applications require capacity (thereby "scavenging" remaining bandwidth). With a congestion policer in place as described in Section 3.1, users of these protocols will be less likely to run afoul of the network operator's traffic management policy than those whose bulk-transfer applications generate the same volume of traffic without being sensitive to congestion. In short, two users who produce similar traffic volumes over the same time interval may produce different congestion-volumes if one of them is using a scavenger transport protocol and the other is not; in that situation, the scavenger user's traffic is less likely to be managed by the network operator.
トラフィック管理へのConExベースのアプローチには、トラフィックの効率的な管理に加えて、いくつかの利点があります。対話型アプリケーションに容量が必要な場合にバルク転送アプリケーションが迅速に処理を実行できるように、低追加遅延バックグラウンドトランスポート[LEDBAT]などの「スカベンジャー」トランスポートプロトコルを利用するインセンティブを提供します（これにより、残りの帯域幅を「スカベンジング」します）。セクション3.1で説明されているように輻輳ポリサーが設定されていると、これらのプロトコルのユーザーは、ネットワークオペレーターのトラフィック管理ポリシーに違反する可能性が低く、一括転送アプリケーションが輻輳の影響を受けずに同じ量のトラフィックを生成する可能性があります。つまり、同じ時間間隔で同様のトラフィック量を生成する2人のユーザーは、一方がスカベンジャー転送プロトコルを使用していて、もう一方が使用していない場合、異なる輻輳ボリュームを生成する可能性があります。そのような状況では、スカベンジャーユーザーのトラフィックがネットワークオペレーターによって管理される可能性は低くなります。
ConEx-based traffic management also makes it possible for a user to control the relative performance among its own traffic flows. If a user wants some flows to have more bandwidth than others, it can reduce the rate of some traffic so that it consumes less congestion-volume "budget", leaving more congestion-volume "budget" for the user to "spend" on making other traffic go faster. This approach is most relevant if congestion is signalled by ECN, because no impairment due to loss is involved and delay can remain low.
ConExベースのトラフィック管理では、ユーザーが自身のトラフィックフロー間の相対的なパフォーマンスを制御することもできます。ユーザーが一部のフローに他のフローよりも多くの帯域幅を持たせたい場合は、一部のトラフィックのレートを下げて、輻輳ボリューム「予算」の消費を減らし、ユーザーが作成に費やす「輻輳ボリューム」予算を増やすことができます。他のトラフィックはより速く行きます。このアプローチは、ECNによって輻輳が通知されている場合に最も関連性があります。これは、損失による障害が発生しておらず、遅延を低く抑えることができるためです。
A variety of approaches already exist for network operators to manage congestion, traffic, and the disproportionate usage of scarce capacity by a small number of users. Common approaches can be categorized as rate-based, volume-based, or application-based.
ネットワーク事業者が輻輳、トラフィック、および少数のユーザーによる希少容量の不釣り合いな使用を管理するためのさまざまなアプローチがすでに存在しています。一般的なアプローチは、レートベース、ボリュームベース、またはアプリケーションベースに分類できます。
Rate-based approaches constrain the traffic rate per user or per network. A user's peak and average (or "committed") rate may be limited. These approaches have the potential to either over- or under-constrain the network, suppressing rates even when the network is uncongested or not suppressing them enough during heavy usage periods.
レートベースのアプローチは、ユーザーごとまたはネットワークごとのトラフィックレートを制限します。ユーザーのピークおよび平均（または「コミットされた」）レートは制限される場合があります。これらのアプローチは、ネットワークを過大または過少に制約する可能性があり、ネットワークが輻輳していない場合や、使用率が高いときに十分に抑制されていない場合でもレートを抑制します。
Round-robin scheduling and fair queuing were developed to address these problems. They equalize relative rates between active users (or flows) at a known bottleneck. The bit rate allocated to any one user depends on the number of active users at each instant. The drawback of these approaches is that they favor heavy users over light users over time, because they do not have any memory of usage.
これらの問題に対処するために、ラウンドロビンスケジューリングと公平なキューイングが開発されました。これらは、既知のボトルネックでのアクティブユーザー（またはフロー）間の相対レートを等しくします。 1人のユーザーに割り当てられるビットレートは、各瞬間のアクティブユーザーの数によって異なります。これらのアプローチの欠点は、使用量のメモリーがないため、ライトユーザーよりもヘビーユーザーを優先することです。
These approaches share bit rate instant by instant; however, heavy users are active at every instant, whereas light users only occupy their share of the link occasionally.
これらのアプローチは、ビットレートを瞬時に共有します。ただし、ヘビーユーザーは常にアクティブですが、ライトユーザーはリンクのシェアを時折しか占有しません。
Volume-based approaches measure the overall volume of traffic a user sends (and/or receives) over time. Users may be subject to an absolute volume cap (for example, 10GB per month) or the "heaviest" users may be sanctioned in some other manner. Many providers use monthly volume limits, and count volume regardless of whether the network is congested or not, creating the potential for over- or under-constraining problems, as with the original rate-based approaches.
ボリュームベースのアプローチは、ユーザーが送信（または受信、あるいはその両方）するトラフィックの全体的なボリュームを経時的に測定します。ユーザーには、絶対的なボリュームの上限（たとえば、1か月あたり10GB）が適用されるか、「最も重い」ユーザーが他の方法で制裁措置を受ける場合があります。多くのプロバイダーは毎月のボリューム制限を使用し、ネットワークが輻輳しているかどうかに関係なくボリュームをカウントするため、元のレートベースのアプローチと同様に、過剰または過少な制約の問題が発生する可能性があります。
ConEx-based approaches, by comparison, only react during times of congestion and in proportion to each user's congestion contribution, making more efficient use of capacity and more proportionate management decisions.
対照的に、ConExベースのアプローチは、輻輳時にのみ、各ユーザーの輻輳の寄与に比例して反応し、容量のより効率的な使用とより適切な管理決定を行います。
Unlike ConEx-based approaches, neither rate-based nor volume-based approaches provide incentives for applications to use scavenger transport protocols. They may even penalize users of applications that employ scavenger transports for the large amount of volume they send, rather than rewarding them for carefully avoiding congestion while sending it. While the volume-based approach described in "Comcast's Protocol-Agnostic Congestion Management System" [RFC6057] aims to overcome the over-/under-constraining problem by only measuring volume and triggering traffic management action during periods of high utilization, it still does not provide incentives to use scavenger transports, because congestion-causing volume cannot be distinguished from volume overall. ConEx provides this ability.
ConExベースのアプローチとは異なり、レートベースでもボリュームベースのアプローチでも、アプリケーションがスカベンジャー転送プロトコルを使用するインセンティブを提供しません。スカベンジャートランスポートを使用するアプリケーションのユーザーは、送信中の輻輳を注意深く回避することで報酬を得るのではなく、大量の送信を行うアプリケーションにユーザーにペナルティを与えることさえあります。 「ComcastのProtocol-Agnostic Congestion Management System」[RFC6057]で説明されているボリュームベースのアプローチは、ボリュームを測定し、使用率が高い期間中にトラフィック管理アクションをトリガーするだけで、過剰/不足制約の問題を克服することを目的としていますが、輻輳の原因となるボリュームは全体的なボリュームと区別できないため、スカベンジャートランスポートを使用するインセンティブを提供します。 ConExはこの機能を提供します。
Application-based approaches use deep packet inspection or other techniques to determine what application a given traffic flow is associated with. Network operators may then use this information to rate-limit or otherwise sanction certain applications, in some cases only during peak hours. These approaches suffer from being at odds with IPsec and some application-layer encryption, and they may raise additional policy concerns. In contrast, ConEx offers an application-agnostic metric to serve as the basis for traffic management decisions.
アプリケーションベースのアプローチでは、ディープパケットインスペクションまたはその他の手法を使用して、特定のトラフィックフローが関連付けられているアプリケーションを判別します。ネットワークオペレーターは、この情報を使用して、特定のアプリケーションをレート制限またはその他の方法で認可します。これらのアプローチは、IPsecと一部のアプリケーション層の暗号化との対立に悩まされており、ポリシーに関する追加の懸念を引き起こす可能性があります。対照的に、ConExは、アプリケーションに依存しないメトリックを提供して、トラフィック管理の決定の基礎として機能します。
The existing types of approaches share a further limitation that ConEx can help to overcome: performance uncertainty. Flat-rate pricing plans are popular because users appreciate the certainty of having their monthly bill amount remain the same for each billing period, allowing them to plan their costs accordingly. But while flat-rate pricing avoids billing uncertainty, it creates performance uncertainty: users cannot know whether the performance of their connections is being altered or degraded based on how the network operator is attempting to manage congestion. By exposing congestion information at the IP layer, ConEx instead provides a metric that can serve as an open, transparent basis for traffic management policies that both providers and their customers can measure and verify. It can be used to reduce the performance uncertainty that some users currently experience, without having to sacrifice their billing certainty.
既存のタイプのアプローチは、ConExが克服するのに役立つ追加の制限、つまりパフォーマンスの不確実性を共有します。定額料金プランは人気があります。これは、毎月の請求額が各請求期間で同じであり、それに応じてコストを計画できることをユーザーが確信しているためです。ただし、定額料金では請求の不確実性は回避されますが、パフォーマンスの不確実性が生じます。ユーザーは、ネットワークオペレーターが輻輳を管理しようとする方法に基づいて、接続のパフォーマンスが変更されているか低下しているのかを知ることができません。 IP層で輻輳情報を公開することにより、ConExは代わりに、プロバイダーとその顧客の両方が測定および検証できるトラフィック管理ポリシーのオープンで透過的な基盤として機能するメトリックを提供します。課金の確実性を犠牲にすることなく、一部のユーザーが現在経験しているパフォーマンスの不確実性を減らすために使用できます。
ConEx information can be put to a number of uses other than informing traffic management. These include:
ConEx情報は、トラフィック管理の通知以外にもさまざまな用途に使用できます。これらは以下を含みます：
Informing inter-operator contracts: ConEx information is made visible to every IP node, including border nodes between networks. Network operators can use ConEx combined with ECN markings to measure how much traffic from each network contributes to congestion in the other. As such, congestion-volume could be included as a metric in inter-operator contracts, just as volume or bit rate are included today. This would not be an initial deployment scenario, unless ECN became widely deployed.
オペレーター間の契約の通知：ConEx情報は、ネットワーク間の境界ノードを含むすべてのIPノードに表示されます。ネットワークオペレーターは、ECNマーキングと組み合わせたConExを使用して、各ネットワークからのトラフィックが他のネットワークの輻輳に寄与している量を測定できます。そのため、現在のボリュームまたはビットレートが含まれているのと同じように、輻輳ボリュームは、オペレーター間の契約にメトリックとして含めることができます。 ECNが広く展開されない限り、これは最初の展開シナリオではありません。
Enabling more efficient capacity provisioning: Section 3.2 explains how operators can use ConEx-based traffic management to encourage use of scavenger transport protocols, which significantly improves the performance of interactive applications while still allowing heavy users to transfer high volumes. Here we explain how this can also benefit network operators.
より効率的な容量プロビジョニングの有効化：セクション3.2では、オペレーターがConExベースのトラフィック管理を使用してスカベンジャートランスポートプロトコルの使用を促進する方法について説明します。ここでは、これがネットワークオペレータにどのように役立つかを説明します。
Today, when loss, delay, or average utilization exceeds a certain threshold, some operators just buy more capacity without attempting to manage the traffic. Other operators prefer to limit a minority of heavy users at peak times, but they still eventually buy more capacity when utilization rises.
今日、損失、遅延、または平均使用率が特定のしきい値を超えると、一部のオペレーターは、トラフィックを管理しようとせずに、より多くの容量を購入します。他のオペレーターは、ピーク時に少数のヘビーユーザーを制限することを好みますが、使用率が上がると、最終的にはより多くの容量を購入します。
With ConEx-based traffic management, a network operator should be able to provision capacity more efficiently. An operator could benefit from this in a variety of ways. For example, the operator could add capacity as it would do without ConEx, but deliver better quality of service for its users. Or, the operator could delay adding capacity while delivering similar quality of service to what it currently provides.
ConExベースのトラフィック管理により、ネットワークオペレーターは容量をより効率的にプロビジョニングできるはずです。オペレーターはさまざまな方法でこれから利益を得ることができます。たとえば、オペレーターはConExを使用しない場合と同じように容量を追加できますが、ユーザーにより良いサービス品質を提供できます。または、オペレーターは、現在提供しているものと同様のサービス品質を提供しながら、容量の追加を遅らせることができます。
ConEx is designed so that it can be incrementally deployed in the Internet and still be valuable for early adopters. As long as some senders are ConEx-enabled, a network on the path can unilaterally use ConEx-aware policy devices for traffic management; no changes to network forwarding elements are needed, and ConEx still works if there are other networks on the path that are unaware of ConEx marks.
ConExは、インターネットに段階的に導入できるように設計されていますが、アーリーアダプターにとっても価値があります。一部の送信者がConEx対応である限り、パス上のネットワークは一方的にConEx対応のポリシーデバイスをトラフィック管理に使用できます。ネットワーク転送要素に変更を加える必要はありません。パス上にConExマークを認識しない他のネットワークがある場合でも、ConExは機能します。
The above two steps seem to represent a stand-off where neither step is useful until the other has made the first move: i) some sending hosts must be modified to give information to the network, and ii) a network must deploy policy devices to monitor this information and act on it. Nonetheless, the developer of a scavenger transport protocol like LEDBAT does stand to benefit from deploying ConEx. In this case, the developer makes the first move, expecting it will prompt at least some networks to move in response, using the ConEx information to reward users of the scavenger transport protocol.
上記の2つのステップは、どちらか一方が最初の移動を行うまでどちらのステップも役に立たない場合のスタンドオフを表しているようです。i）一部の送信ホストは、ネットワークに情報を提供するように変更する必要があります。ii）ネットワークは、ポリシーデバイスを展開する必要があります。この情報を監視し、それに基づいて行動します。それにもかかわらず、LEDBATのようなスカベンジャートランスポートプロトコルの開発者は、ConExの展開から利益を得る立場にあります。この場合、開発者は最初の移動を行い、スカベンジャートランスポートプロトコルのユーザーに報酬を与えるためにConEx情報を使用して、それに応じて移動するように少なくともいくつかのネットワークを促すことを期待します。
On the host side, we have already shown (Figure 1) how the sender piggy-backs ConEx signals on normal data packets to re-insert feedback about packet drops (and/or ECN) back into the IP layer. In the case of TCP, [TCP-MOD] proposes the required sender modifications. ConEx works with any TCP receiver as long as it uses SACK (selective acknowledgment), which most do. There is a receiver optimisation [TCPM-ECN] that improves ConEx precision when using ECN, but ConEx can still use ECN without it. Networks can make use of ConEx even if the implementations of some of the transport protocols on a host do not support ConEx (e.g., the implementation of DNS over UDP might not support ConEx, while perhaps RTP over UDP and TCP will).
ホスト側では、送信者が通常のデータパケットでConEx信号をピギーバックして、パケットドロップ（またはECN）に関するフィードバックをIPレイヤーに再挿入する方法をすでに示しています（図1）。 TCPの場合、[TCP-MOD]は必要な送信者の変更を提案します。 ConExは、ほとんどのSACK（選択的確認応答）を使用している限り、どのTCPレシーバーでも動作します。 ECNを使用するときにConExの精度を向上させるレシーバー最適化[TCPM-ECN]がありますが、ConExはそれなしでもECNを使用できます。ホスト上のトランスポートプロトコルの一部の実装がConExをサポートしていない場合でも、ネットワークはConExを利用できます（たとえば、DNS over UDPの実装はConExをサポートしない可能性がありますが、おそらくRTP over UDPおよびTCPはサポートします）。
On the network side, the provider solely needs to place ConEx congestion policers at each ingress to its network in a similar arrangement to the edge-policed architecture of Diffserv [RFC2475].
ネットワーク側では、プロバイダーは、Diffserv [RFC 2475]のエッジポリシングアーキテクチャと同様の配置で、ネットワークへの各入口にConEx輻輳ポリスを配置するだけで済みます。
A sender can choose whether to send packets that support ConEx or packets that don't. ConEx-enabled packets bring information to the policer about congestion expected on the rest of the path beyond the policer. Packets that do not support ConEx bring no such information. Therefore, the network will tend to conservatively rate-limit non-ConEx-enabled packets in order to manage the unknown risk of congestion. In contrast, a network doesn't normally need to rate-limit ConEx-enabled packets unless they reveal a persistently high contribution to congestion. This natural tendency for networks to favour senders that provide ConEx information reinforces ConEx deployment.
送信者は、ConExをサポートするパケットを送信するか、サポートしないパケットを送信するかを選択できます。 ConEx対応パケットは、ポリサーを越えた残りのパスで予想される輻輳に関する情報をポリサーにもたらします。 ConExをサポートしないパケットはそのような情報をもたらしません。したがって、ネットワークは、ConEx対応でないパケットを保守的にレート制限して、未知の輻輳リスクを管理する傾向があります。対照的に、ネットワークは、通常、ConEx対応パケットが輻輳への継続的な高い寄与を明らかにしない限り、レート制限する必要はありません。ネットワークがConEx情報を提供する送信者を優先するというこの自然な傾向は、ConExの展開を強化します。
Feasible initial deployment scenarios exist for a broadband access network [CONEX-DEPLOY], a mobile communications network [CONEX-MOBILE], and a multi-tenant data centre [CONEX-DATA]. The first two of these scenarios are believed to work well without ECN support, while the data center scenario works best with ECN (and ECN can be deployed unilaterally).
ブロードバンドアクセスネットワーク[CONEX-DEPLOY]、モバイル通信ネットワーク[CONEX-MOBILE]、およびマルチテナントデータセンター[CONEX-DATA]には、実現可能な初期導入シナリオが存在します。これらのシナリオの最初の2つはECNのサポートなしで適切に機能すると考えられていますが、データセンターのシナリオはECNで最適に機能します（ECNは一方的に展開できます）。
The above gives only the most salient aspects of ConEx deployment. For further detail, [CONEX-ABS] describes the incremental deployment features of the ConEx protocol and the components that need to be deployed for ConEx to work.
上記は、ConEx展開の最も顕著な側面のみを示しています。詳細については、[CONEX-ABS]では、ConExプロトコルの増分展開機能と、ConExが機能するために展開する必要があるコンポーネントについて説明しています。
ConEx is initially designed as an experimental protocol because it makes an ambitious change at the interoperability (IP) layer, so no amount of careful design can foresee all the potential feature interactions with other uses of IP. This section identifies a number of questions that would be useful to answer through well-designed experiments:
ConExは、相互運用性（IP）レイヤーで野心的な変更を行うため、最初は実験的なプロトコルとして設計されています。このセクションでは、適切に設計された実験を通じて回答するのに役立ついくつかの質問を特定します。
o Are the compromises that were made in order to fit the ConEx encoding into IP (for example, that the initial design was solely for IPv6 and not for IPv4, and that the encoding has limited visibility when tunnelled [CONEX-DESTOPT]) the right ones?
o ConExエンコーディングをIPに適合させるために行われた妥協策（たとえば、最初の設計はIPv6のみでIPv4ではなく、トンネル化されたときに符号化の可視性が制限される[CONEX-DESTOPT]）は適切なものですか？
o Is it possible to combine techniques for distinguishing self-congestion from shared congestion with ConEx-based traffic management such that users are not penalized for congestion that does not impact others on the network? Are other techniques needed?
o 自己輻輳と共有輻輳を区別するための手法をConExベースのトラフィック管理と組み合わせて、ネットワーク上の他のユーザーに影響を与えない輻輳に対してユーザーがペナルティを受けないようにすることは可能ですか？他のテクニックは必要ですか？
o In practice, how does traffic management using ConEx compare with traditional techniques (Section 3.3)? Does it give the benefits claimed in Sections 3.1 and 3.2?
o 実際には、ConExを使用したトラフィック管理は、従来の技術（セクション3.3）とどのように比較されますか？セクション3.1と3.2で主張されている利点はありますか？
o Approaches are proposed for congestion policing of ConEx traffic alongside existing management (or lack thereof) of non-ConEx traffic, including UDP traffic [CONEX-ABS]. Are they strategy-proof against users selectively using both? Are there better transition strategies?
o UDPトラフィックを含む非ConExトラフィックの既存の管理（またはその欠如）に加えて、ConExトラフィックの輻輳ポリシングのためのアプローチが提案されています[CONEX-ABS]。それらは、両方を選択的に使用するユーザーに対して戦略的な証拠ですか？より良い移行戦略はありますか？
o Audit devices have been designed and implemented to assure ConEx signal integrity [CONEX-ABS]. Do they achieve minimal false hits and false misses in a wide range of traffic scenarios? Are there new attacks? Are there better audit designs to defend against these?
o 監査デバイスは、ConExシグナルインテグリティを保証するように設計および実装されています[CONEX-ABS]。幅広いトラフィックシナリオで最小の誤ヒットと誤ミスを実現していますか？新しい攻撃はありますか？これらを防ぐためのより良い監査設計はありますか？
o If ECN deployment remains patchy, are the proposed initial ConEx deployment scenarios (Section 5) still useful enough to kick-start deployment? Is auditing effective when based on loss at a primary bottleneck? Can rest-of-path congestion be approximated accurately enough without ECN? Are there other useful deployment scenarios?
o ECNの展開にパッチが適用されたままの場合、提案された初期ConEx展開シナリオ（セクション5）は、展開をキックスタートするのに十分役立ちますか？主要なボトルネックでの損失に基づく場合、監査は効果的ですか？パスの残りの輻輳は、ECNなしで十分正確に概算できますか？他に役立つ展開シナリオはありますか？
ConEx is intended to be a generative technology that might be used for unexpected purposes unforeseen by the designers. Therefore, this list of experimental considerations is not intended to be exhaustive.
ConExは、設計者が予期しない予期しない目的に使用される可能性のある生成技術であることを意図しています。したがって、この実験的な考慮事項のリストは、すべてを網羅することを意図したものではありません。
This document does not specify a mechanism, it merely motivates congestion exposure at the IP layer. Therefore, security considerations are described in the companion document that gives an abstract description of the ConEx protocol and the components that would use it [CONEX-ABS].
このドキュメントではメカニズムを指定していません。IPレイヤーでの輻輳の露出を動機付けるだけです。したがって、セキュリティに関する考慮事項は、ConExプロトコルとそれを使用するコンポーネントの抽象的な説明を提供する関連ドキュメントに記載されています[CONEX-ABS]。
Bob Briscoe was partly funded by Trilogy, a research project (ICT-216372) supported by the European Community under its Seventh Framework Programme. The views expressed here are those of the author only.
Bob Briscoeは、その7番目のフレームワークプログラムに基づいて、欧州共同体が支援する研究プロジェクト（ICT-216372）であるTrilogyから一部資金提供を受けました。ここで表明されている見解は、著者のみの見解です。
The authors would like to thank the many people that have commented on this document: Bernard Aboba, Mikael Abrahamsson, Joao Taveira Araujo, Marcelo Bagnulo Braun, Steve Bauer, Caitlin Bestler, Steven Blake, Louise Burness, Ken Carlberg, Nandita Dukkipati, Dave McDysan, Wes Eddy, Matthew Ford, Ingemar Johansson, Georgios Karagiannis, Mirja Kuehlewind, Dirk Kutscher, Zhu Lei, Kevin Mason, Matt Mathis, Michael Menth, Chris Morrow, Tim Shepard, Hannes Tschofenig, and Stuart Venters. Please accept our apologies if your name has been missed off this list.
著者はこの文書にコメントした多くの人々に感謝したいと思います：Bernard Aboba、Mikael Abrahamsson、Joao Taveira Araujo、Marcelo Bagnulo Braun、Steve Bauer、Caitlin Bestler、Steven Blake、Louis Burness、Ken Carlberg、Nandita Dukkipati、Dave McDysan 、ウェスエディ、マシューフォード、インゲマーヨハンソン、ゲオルギオスカラギアニス、ミルハキューレウィンド、ダーククッチャー、チューレイ、ケビンメイソン、マットマティス、マイケルメンス、クリスモロー、ティムシェパード、ハンネスツショフェニグ、スチュアートベンターズ。あなたの名前がこのリストに載っていない場合は、お詫び申し上げます。
Philip Eardley and Andrea Soppera made helpful text contributions to this document.
Philip EardleyとAndrea Sopperaは、このドキュメントに役立つテキストを寄稿しました。
The following co-edited this document through most of its life:
以下は、このドキュメントをそのほとんどの期間を通じて共同編集したものです。
Toby Moncaster Computer Laboratory William Gates Building JJ Thomson Avenue Cambridge, CB3 0FD UK EMail: toby.moncaster@cl.cam.ac.uk
Toby Moncaster Computer LaboratoryウィリアムゲイツビルディングJJトムソンアベニューケンブリッジ、CB3 0FD UKメール：toby.moncaster@cl.cam.ac.uk
John Leslie JLC.net 10 Souhegan Street Milford, NH 03055 US EMail: john@jlc.net
ジョンレスリーJLC.net 10 Souhegan Street Milford、NH 03055 US EMail：john@jlc.net
[Bauer09] Bauer, S., Clark, D., and W. Lehr, "The Evolution of Internet Congestion", 2009.
[Bauer09]バウアー、S。、クラーク、D。、およびW.レール、「インターネット混雑の進化」、2009年。
[CONEX-ABS] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts and Abstract Mechanism", Work in Progress, October 2012.
[CONEX-ABS] Mathis、M。、およびB. Briscoe、「Congestion Exposure（ConEx）Concepts and Abstract Mechanism」、Work in Progress、2012年10月。
[CONEX-DATA] Briscoe, B. and M. Sridharan, "Network Performance Isolation in Data Centres using Congestion Exposure (ConEx)", Work in Progress, July 2012.
[CONEX-DATA] Briscoe、B。およびM. Sridharan、「Congestion Exposure（ConEx）を使用したデータセンターでのネットワークパフォーマンスの分離」、作業中、2012年7月。
[CONEX-DEPLOY] Briscoe, B., "Initial Congestion Exposure (ConEx) Deployment Examples", Work in Progress, July 2012.
[CONEX-DEPLOY] Briscoe、B。、「初期の輻輳露出（ConEx）の導入例」、作業中、2012年7月。
[CONEX-DESTOPT] Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6 Destination Option for ConEx", Work in Progress, September 2012.
[CONEX-DESTOPT]クリシュナン、S。、キューレウィンド、M.、C。ウセンド、「ConExのIPv6宛先オプション」、作業中、2012年9月。
[CONEX-MOBILE] Kutscher, D., Mir, F., Winter, R., Krishnan, S., Zhang, Y., and C. Bernardos, "Mobile Communication Congestion Exposure Scenario", Work in Progress, July 2012.
[CONEX-MOBILE] Kutscher、D.、Mir、F.、Winter、R.、Krishnan、S.、Zhang、Y。、およびC. Bernardos、「Mobile Communication Congestion Exposure Scenario」、Work in Progress、2012年7月。
[CongPol] Briscoe, B., Jacquet, A., and T. Moncaster, "Policing Freedom to Use the Internet Resource Pool", ReArch 2008 hosted at the 2008 CoNEXT conference , December 2008.
[CongPol] Briscoe、B.、Jacquet、A。、およびT. Moncaster、「Policing Freedom to Use the Internet Resource Pool」、2008年12月に開催された2008 CoNEXT会議で開催されたReArch 2008。
[LEDBAT] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", Work in Progress, September 2012.
[LEDBAT] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、Work in Progress、2012年9月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「An Architecture for Differentiated Services」、RFC 2475、1998年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC6057] Bastian, C., Klieber, T., Livingood, J., Mills, J., and R. Woundy, "Comcast's Protocol-Agnostic Congestion Management System", RFC 6057, December 2010.
[RFC6057]バスティアン、C。、クリーバー、T。、リビングウッド、J。、ミルズ、J。、およびR.ウウンディ、「Comcastのプロトコルにとらわれない輻輳管理システム」、RFC 6057、2010年12月。
[TCP-MOD] Kuehlewind, M. and R. Scheffenegger, "TCP modifications for Congestion Exposure", Work in Progress, May 2012.
[TCP-MOD] Kuehlewind、M。、およびR. Scheffenegger、「輻輳露出のためのTCP変更」、作業中、2012年5月。
[TCPM-ECN] Kuehlewind, M. and R. Scheffenegger, "More Accurate ECN Feedback in TCP", Work in Progress, July 2012.
[TCPM-ECN] Kuehlewind、M。、およびR. Scheffenegger、「TCPでのより正確なECNフィードバック」、Work in Progress、2012年7月。
[TR-059] Anschutz, T., Ed., "DSL Forum Technical Report TR-059: Requirements for the Support of QoS-Enabled IP Services", September 2003.
[TR-059] Anschutz、T。、編、「DSLフォーラムテクニカルレポートTR-059：QoS対応IPサービスのサポートの要件」、2003年9月。
[TR-101] Cohen, A., Ed. and E. Schrum, Ed., "DSL Forum Technical Report TR-101: Migration to Ethernet-Based DSL Aggregation", April 2006.
[TR-101]コーエン、A。、エド。 E. Schrum、編、「DSLフォーラムテクニカルレポートTR-101：イーサネットベースのDSLアグリゲーションへの移行」、2006年4月。
Authors' Addresses
著者のアドレス
Bob Briscoe (editor) BT B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE UK
Bob Briscoe（編集者）BT B54 / 77、Adastral Park Martlesham Heath Ipswich IP5 3RE UK
Phone: +44 1473 645196
EMail: bob.briscoe@bt.com
URI: http://bobbriscoe.net/
Richard Woundy (editor) Comcast 1701 John F Kennedy Boulevard Philadelphia, PA 19103 US
リチャードワウンディ（編集者）コムキャスト1701ジョンFケネディブルバードフィラデルフィア、PA 19103米国
EMail: richard_woundy@cable.comcast.com
URI: http://www.comcast.com
Alissa Cooper (editor) CDT 1634 Eye St. NW, Suite 1100 Washington, DC 20006 US
アリッサクーパー（編集者）CDT 1634 Eye St. NW、Suite 1100 Washington、DC 20006 US
EMail: acooper@cdt.org