[要約] RFC 4774は、ECNフィールドの代替セマンティクスを指定するための規格です。その目的は、ネットワークの混雑制御を改善し、パフォーマンスを向上させることです。
Network Working Group S. Floyd
Request for Comments: 4774 ICIR
BCP: 124 November 2006
Category: Best Current Practice
Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field
明示的な混雑通知（ECN）フィールドの代替セマンティクスの指定
Status of This Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
Abstract
概要
There have been a number of proposals for alternate semantics for the Explicit Congestion Notification (ECN) field in the IP header RFC 3168. This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics. This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics.
Table of Contents
目次
1. Introduction ....................................................2
2. An Overview of the Issues .......................................3
3. Signalling the Use of Alternate ECN Semantics ...................4
3.1. Using the Diffserv Field for Signalling ....................5
4. Issues of Incremental Deployment ................................6
4.1. Option 1: Unsafe for Deployment in the Internet ...........7
4.2. Option 2: Verification that Routers Understand the
Alternate ..................................................8
4.3. Option 3: Friendly Coexistence with Competing Traffic .....8
5. Evaluation of the Alternate ECN Semantics ......................10
5.1. Verification of Feedback from the Router ..................10
5.2. Coexistence with Competing Traffic ........................11
5.3. Proposals for Alternate ECN with Edge-to-Edge Semantics ...12
5.4. Encapsulated Packets ......................................12
5.5. A General Evaluation of the Alternate ECN Semantics .......12
6. Security Considerations ........................................12
7. Conclusions ....................................................13
8. Acknowledgements ...............................................13
9. Normative References ...........................................13
10. Informative References ........................................13
[RFC3168], a Proposed Standard document, defines the ECN field in the IP header, and specifies the semantics for the codepoints for the ECN field. However, end nodes could specify the use of alternate semantics for the ECN field, e.g., using codepoints in the diffserv field of the IP header.
提案された標準ドキュメントである[RFC3168]は、IPヘッダーのECNフィールドを定義し、ECNフィールドのコードポイントのセマンティクスを指定します。ただし、ENDノードは、ECNフィールドに代替セマンティクスの使用を指定できます。たとえば、IPヘッダーのdiffservフィールドでコードポイントを使用します。
There have been a number of proposals in the IETF and in the research community for alternate semantics for the ECN codepoint. One such proposal, [BCF05], proposes alternate ECN semantics for real-time inelastic traffic such as voice, video conferencing, and multimedia streaming in DiffServ networks. In this proposal, the alternate ECN semantics would provide information about two levels of congestion experienced along the path [BCF05]. Another research proposal, [XSSK05], proposes a low-complexity protocol, Variable-structure congestion Control Protocol (VCP), that uses the two bits in the ECN field to indicate low-load, high-load, and overload (congestion), where transport protocols can increase more rapidly during the low-load regime. Some of the proposals for alternate ECN semantics are for when ECN is used in an edge-to-edge context between gateways at the edge of a network region, e.g., for pre-congestion notification for admissions control [BESFC06]. Other proposals for alternate ECN semantics are listed on the ECN Web Page [ECN].
IETFとECNコードポイントの代替セマンティクスについては、研究コミュニティで多くの提案がありました。そのような提案の1つである[BCF05]は、DiffServネットワークでの音声、ビデオ会議、マルチメディアストリーミングなど、リアルタイムの非弾性トラフィックの代替ECNセマンティクスを提案しています。この提案では、代替ECNセマンティクスは、パスに沿って経験した2つのレベルの渋滞に関する情報を提供します[BCF05]。別の研究提案[XSSK05]は、ECNフィールドの2つのビットを使用して低負荷、高負荷、および過負荷（輻輳）を示す、低複数のプロトコルである可変構造輻輳制御プロトコル（VCP）を提案しています。輸送プロトコルは、低負荷体制の間により急速に増加する可能性があります。代替ECNセマンティクスの提案の一部は、ECNがネットワーク領域の端のゲートウェイ間のエッジツーエッジコンテキストで使用される場合、たとえば、入場制御の前通知通知[BESFC06]の場合です。代替ECNセマンティクスのその他の提案は、ECN Webページ[ECN]にリストされています。
The definition of multiple semantics for the ECN field could have significant implications on both host and router implementations. There is a huge base of installed hosts and routers in the Internet, and in other IP networks, and updating these is an enormous and potentially expensive undertaking. Some existing devices might be able to support the new ECN semantics with only a software upgrade and without significant degradation in performance. Some other equipment might be able to support the new semantics, but with a degradation in performance -- which could range from trivial to catastrophic. Some other deployed equipment might be able to support the new ECN semantics only with a hardware upgrade, which, in some cases, could be prohibitively expensive to deploy on a very wide scale. For these reasons, it would be difficult and would take a significant amount of time to universally deploy any new ECN semantics. In particular, routers can be difficult to upgrade, since small routers sometimes are not updated frequently, and large routers commonly have specialized forwarding paths to facilitate high performance.
ECNフィールドの複数のセマンティクスの定義は、ホストとルーターの両方の実装に大きな意味を持つ可能性があります。インターネットや他のIPネットワークには、インストールされたホストとルーターの大きなベースがあり、これらを更新することは、非常に高価な事業です。一部の既存のデバイスは、ソフトウェアのアップグレードのみを使用して、パフォーマンスが大幅に低下することなく、新しいECNセマンティクスをサポートできる場合があります。他のいくつかの機器は、新しいセマンティクスをサポートできるかもしれませんが、パフォーマンスが低下しています。これは、些細なものから壊滅的なものまでさまざまです。他の展開された機器の中には、ハードウェアアップグレードでのみ新しいECNセマンティクスをサポートできる場合があります。これらの理由から、それは難しく、新しいECNセマンティクスを普遍的に展開するのにかなりの時間がかかります。特に、小さなルーターが頻繁に更新されず、大規模なルーターが一般的に高性能を促進するために特殊な転送パスを持っているため、ルーターをアップグレードするのが難しい場合があります。
This document describes some of the technical issues that arise in specifying alternate semantics for the ECN field, and gives requirements for a safe coexistence in a world using the default ECN semantics (or using no ECN at all).
このドキュメントでは、ECNフィールドの代替セマンティクスを指定する際に生じる技術的な問題のいくつかについて説明し、デフォルトのECNセマンティクス（またはまったく使用しない）を使用して、世界の安全な共存の要件を提供します。
In this section, we discuss some of the issues that arise if some of the traffic in a network consists of alternate-ECN traffic (i.e., traffic using alternate semantics for the ECN field). The issues include the following: (1) how routers know which ECN semantics to use with which packets; (2) incremental deployment in a network where some routers use only the default ECN semantics or do not use ECN at all; (3) coexistence of alternate-ECN traffic with competing traffic on the path; and (4) a general evaluation of the alternate ECN semantics.
このセクションでは、ネットワーク内のトラフィックの一部が代替ECNトラフィック（つまり、ECNフィールドの代替セマンティクスを使用してトラフィック）で構成されている場合に発生する問題のいくつかについて説明します。問題には、次のものが含まれます。（1）ルーターがどのパケットで使用するかをルーターがどのように使用するかをどのように知るか。（2）一部のルーターがデフォルトのECNセマンティクスのみを使用するか、ECNをまったく使用しないネットワークでの増分展開。（3）パス上の競合するトラフィックとの代替ECNトラフィックの共存。（4）代替ECNセマンティクスの一般的な評価。
(1) The first issue concerns how routers know which ECN semantics to use with which packets in the network:
(1) 最初の問題は、ルーターがネットワーク内のパケットを使用するECNセマンティクスをどのように知っているかに関するものです。
How does the connection indicate to the router that its packets are using alternate ECN semantics? Is the specification of alternate-ECN semantics robust and unambiguous? If not, is this a problem?
接続は、パケットが代替ECNセマンティクスを使用していることをルーターにどのように示していますか？代替ECNセマンティクスの仕様は堅牢で明確ですか？そうでない場合、これは問題ですか？
As an example, in most of the proposals for alternate ECN semantics, a diffserv field is used to specify the use of alternate ECN semantics. Do all routers that understand this diffserv codepoint understand that it uses alternate ECN semantics, or not? Diffserv allows routers to re-mark DiffServ Code Point (DSCP) values within the network; what is the effect of this on the alternate ECN semantics?
例として、代替ECNセマンティクスのほとんどの提案では、DiffServフィールドを使用して、代替ECNセマンティクスの使用を指定します。このDiffServ CodePointを理解しているすべてのルーターは、代替ECNセマンティクスを使用しているかどうかを理解していますか？DiffServを使用すると、ルーターがネットワーク内でDiffServコードポイント（DSCP）値を再マークできます。代替ECNセマンティクスに対するこれの効果は何ですか？
This is discussed in more detail in Section 3 below.
これについては、以下のセクション3で詳しく説明します。
(2) A second issue is that of incremental deployment in a network where some routers only use the default ECN semantics, and other routers might not use ECN at all. In this document, we use the phrase "new routers" to refer to the routers that understand the alternate ECN semantics, and "old routers" to refer to routers that don't understand or aren't willing to use the alternate ECN semantics.
(2) 2番目の問題は、一部のルーターがデフォルトのECNセマンティクスのみを使用し、他のルーターがECNをまったく使用できないネットワークでの増分展開の問題です。このドキュメントでは、「新しいルーター」というフレーズを使用して、代替ECNセマンティクスを理解しているルーターを参照し、「古いルーター」を参照して、代替ECNセマンティクスを理解していないか、意思のないルーターを指します。
The possible existence of old routers raises the following question: How does the possible presence of old routers affect the performance of the alternate-ECN connections?
古いルーターの存在の可能性は、次の疑問を提起します。古いルーターの存在の可能性は、代替ECN接続のパフォーマンスにどのように影響しますか？
(3) The possible existence of old routers also raises the question of how the presence of old routers affects the coexistence of the alternate-ECN traffic with competing traffic on the path.
(3) 古いルーターの存在の可能性は、古いルーターの存在が、パス上の競合するトラフィックと代替ECNトラフィックの共存にどのように影響するかという問題を提起します。
Issues (2) and (3) are discussed in Section 4 below.
問題（2）および（3）については、以下のセクション4で説明します。
(4) A final issue is that of the general evaluation of the alternate ECN semantics:
(4) 最終的な問題は、代替ECNセマンティクスの一般的な評価の問題です。
How well does the alternate-ECN traffic perform, and how well does it coexist with competing traffic on the path, in a "clean" environment with new routers and with the unambiguous specification of the use of alternate ECN semantics?
代替ECNトラフィックはどの程度うまく機能し、パス上での競合するトラフィック、新しいルーター、および代替ECNセマンティクスの使用の明確な仕様でどの程度うまく共存しますか？
These issues are discussed in Section 5.
これらの問題については、セクション5で説明します。
This section discusses question (1) from Section 2:
このセクションでは、セクション2の質問（1）について説明します。
(1) How does the connection indicate to the router that its packets are using alternate ECN semantics? Is the specification of alternate ECN semantics robust and unambiguous? If not, is this a problem?
(1) 接続は、パケットが代替ECNセマンティクスを使用していることをルーターにどのように示していますか？代替ECNセマンティクスの仕様は堅牢で明確ですか？そうでない場合、これは問題ですか？
The assumption of this document is that when alternate semantics are defined for the ECN field, a codepoint in the diffserv field is used to signal the use of these alternate ECN semantics to the router. That is, the end host sets the codepoint in the diffserv field to indicate to routers that alternate semantics to the ECN field are being used. Routers that understand this diffserv codepoint would know to use the alternate semantics for interpreting and setting the ECN field. Old ECN-capable routers that do not understand this diffserv codepoint would use the default ECN semantics in interpreting and setting the ECN field.
このドキュメントの仮定は、ECNフィールドに対して代替セマンティクスが定義されている場合、DiffServフィールドのコードポイントを使用して、これらの代替ECNセマンティクスの使用をルーターに合図することです。つまり、エンドホストは、diffservフィールドにコードポイントを設定して、ecnフィールドに代わるセマンティクスが使用されていることをルーターに示します。このDiffServ CodePointを理解しているルーターは、ECNフィールドを解釈および設定するために代替のセマンティクスを使用することを知っています。このDiffServ CodePointを理解していない古いECN対応ルーターは、ECNフィールドの解釈と設定でデフォルトのECNセマンティクスを使用します。
In general, the diffserv codepoints are used to signal the per-hop behavior at router queues. One possibility would be to use one diffserv codepoint to signal a per-hop behavior with the default ECN semantics, and a separate diffserv codepoint to signal a similar per-hop behavior with the alternate ECN semantics. Another possibility would be to use a diffserv codepoint to signal the use of best-effort per-hop queueing and scheduling behavior, but with alternate ECN semantics. A detailed discussion of these issues is beyond the scope of this document.
一般に、DiffServ CodePointsは、ルーターキューでホップごとの動作を知らせるために使用されます。1つの可能性は、1つのDiffServ CodePointを使用してデフォルトのECNセマンティクスを使用してホップごとの動作を信号し、別のDiffServ CodePointを代替ECNセマンティクスで同様のホップごとの動作を知らせることです。もう1つの可能性は、DiffServ CodePointを使用して、最良のホップごとのキューイングとスケジューリング動作の使用を示すことですが、代替ECNセマンティクスを使用します。これらの問題の詳細な議論は、このドキュメントの範囲を超えています。
We note that this discussion does not exclude the possibility of using other methods, including out-of-band mechanisms, for signalling the use of alternate semantics for the ECN field. The considerations in the rest of this document apply regardless of the method used to signal the use of alternate semantics for the ECN field.
この議論は、ECNフィールドの代替セマンティクスの使用を示すために、バンド外のメカニズムを含む他の方法を使用する可能性を除外していないことに注意してください。このドキュメントの残りの部分の考慮事項は、ECNフィールドの代替セマンティクスの使用を知らせるために使用される方法に関係なく適用されます。
We note that the default ECN semantics defined in RFC 3168 are the current default semantics for the ECN field, regardless of the contents of any other fields in the IP header. In particular, the default ECN semantics apply for more than best-effort traffic with a codepoint of '000000' for the diffserv field - the default ECN semantics currently apply regardless of the contents of the diffserv field.
RFC 3168で定義されているデフォルトのECNセマンティクスは、IPヘッダー内の他のフィールドの内容に関係なく、ECNフィールドの現在のデフォルトセマンティクスであることに注意してください。特に、デフォルトのECNセマンティクスは、DiffServフィールドの「000000」のコードポイントを使用して、ベストエフォルトトラフィックを超えるトラフィックに適用されます。
There are two ways to use the diffserv field to signal the use of alternate ECN semantics. One way is to use an existing diffserv codepoint, and to modify the current definition of that codepoint, through approved IETF processes, to specify the use of alternate ECN semantics with that codepoint. A second way is to define a new diffserv codepoint, and to specify the use of alternate ECN semantics with that codepoint. We note that the first of these two mechanisms raises the possibility that some routers along the path will understand the diffserv codepoint but will use the default ECN semantics with this diffserv codepoint, or won't use ECN at all, and that other routers will use the alternate ECN semantics with this diffserv codepoint.
DiffServフィールドを使用して、代替ECNセマンティクスの使用を知らせる方法は2つあります。1つの方法は、既存のDiffServ CodePointを使用し、承認されたIETFプロセスを介してそのコードポイントの現在の定義を変更して、そのCodePointで代替ECNセマンティクスの使用を指定することです。2番目の方法は、新しいDiffServ CodePointを定義し、そのコードポイントで代替ECNセマンティクスの使用を指定することです。これらの2つのメカニズムのうちの最初のものは、パスに沿った一部のルーターがDiffServ CodePointを理解する可能性を高めているが、このDiffServ CodePointでデフォルトのECNセマンティクスを使用するか、ECNをまったく使用しない可能性があり、他のルーターが使用されることに注意してください。このDiffServ CodePointを使用した代替ECNセマンティクス。
This section discusses questions (2) and (3) posed in Section 2:
このセクションでは、セクション2で提起された質問（2）と（3）について説明します。
(2) How does the possible presence of old routers affect the performance of the alternate-ECN connections?
(2) 古いルーターの存在の可能性は、代替ECN接続のパフォーマンスにどのように影響しますか？
(3) How does the possible presence of old routers affect the coexistence of the alternate-ECN traffic with competing traffic on the path?
(3) 古いルーターの存在の可能性は、パス上の競合するトラフィックと代替ECNトラフィックの共存にどのように影響しますか？
When alternate semantics are defined for the ECN field, it is necessary to ensure that there are no problems caused by old routers along the path that don't understand the alternate ECN semantics.
ECNフィールドに対して代替セマンティクスが定義されている場合、代替ECNセマンティクスを理解していないパスに沿った古いルーターによって問題が発生しないことを確認する必要があります。
One possible problem is that of poor performance for the alternate-ECN traffic. Is it essential to the performance of the alternate-ECN traffic that all routers along the path understand the alternate ECN semantics? If not, what are the possible consequences, for the alternate-ECN traffic itself, when some old routers along the path don't understand the alternate ECN semantics? These issues have to be answered in the context of each specific proposal for alternate ECN semantics.
考えられる問題の1つは、代替ECNトラフィックのパフォーマンスが低いことです。パスに沿ったすべてのルーターが代替ECNセマンティクスを理解することが、代替ECNトラフィックのパフォーマンスに不可欠ですか？そうでない場合、パスに沿った一部の古いルーターが代替ECNセマンティクスを理解していない場合、代替ECNトラフィック自体の結果は何ですか？これらの問題は、代替ECNセマンティクスの各特定の提案のコンテキストで回答する必要があります。
A second specific problem is that of possible unfair competition with other traffic along the path. If there is an old router along the path that doesn't use ECN, that old router could drop packets from the alternate-ECN traffic, and expect the alternate-ECN traffic to reduce its sending rate as a result. Does the alternate-ECN traffic respond to packet drops as an indication of congestion?
2番目の特定の問題は、パスに沿った他のトラフィックとの不公平な競争の可能性があることです。ECNを使用しないパスに沿って古いルーターがある場合、その古いルーターは代替ECNトラフィックからパケットをドロップし、代替ECNトラフィックが結果として送信率を下げることを期待できます。交互のECNトラフィックは、混雑の兆候としてパケットドロップに応答しますか？
|--------|
Alternate-ECN traffic ----> | | ---> CE-marked packet
| Old |
Non-ECN traffic ----------> | Router | ---> dropped packet
| |
RFC-3168 ECN traffic -----> | | ---> CE-marked packet
|--------|
Figure 1: Alternate-ECN traffic, an old router, using RFC-3168 ECN, that is congested and ready to drop or mark the arriving packet.
図1：RFC-3168 ECNを使用した古いルーターである代替ECNトラフィックは、混雑しており、到着パケットをドロップまたはマークする準備ができています。
Similarly, what if there is an old router along the path that understands only the default ECN semantics from RFC 3168, as in Figure 1 above? In times of congestion, the old default-ECN router could see an alternate-ECN packet with one of the ECN-Capable Transport (ECT) codepoints set in the ECN field in the IP header, as defined in RFC 3168, and set the Congestion Experienced (CE) codepoint in the ECN field as an alternative to dropping the packet. The router in this case would expect the alternate-ECN connection to respond, in terms of congestion control, as it would if the packet has been dropped. If the alternate-ECN traffic fails to respond appropriately to the CE codepoint being set by an old router, this could increase the aggregate traffic arriving at the old router, resulting in an increase in the packet-marking and packet-dropping rates at that router, further resulting in the alternate-ECN traffic crowding out the other traffic competing for bandwidth on that link.
同様に、上記の図1のように、RFC 3168のデフォルトのECNセマンティクスのみを理解するパスに沿って古いルーターがある場合はどうなりますか？混雑の時点で、古いデフォルト-ECNルーターは、RFC 3168で定義されているように、IPヘッダーのECNフィールドに設定されたECN対応トランスポート（ECT）コードポイントの1つを備えた代替ECNパケットを見ることができ、混雑を設定します。パケットをドロップする代わりに、ECNフィールドの経験豊富な（CE）コードポイント。この場合のルーターは、パケットが削除された場合と同様に、輻輳制御の観点から、代替ECN接続が応答すると予想されます。代替ECNトラフィックが古いルーターによって設定されているCEコードポイントに適切に応答できない場合、これにより古いルーターに到着する集計トラフィックが増加し、そのルーターでパケットマークとパケットドロップレートが増加する可能性があります。、さらに、そのリンク上の帯域幅を競う他のトラフィックを混雑させる代替ECNトラフィックが発生します。
Basically, there are three possibilities for avoiding scenarios where the presence of old routers along the path results in the alternate-ECN traffic competing unfairly with other traffic along the path:
基本的に、パスに沿って古いルーターの存在がパスに沿って他のトラフィックと不当に競合する代替ECNトラフィックをもたらすシナリオを避けるための3つの可能性があります。
Option 1: Alternate-ECN traffic is clearly understood as unsafe for deployment in the global Internet; or
オプション1：代替ECNトラフィックは、グローバルインターネットでの展開が安全でないと明確に理解されています。また
Option 2: All alternate-ECN traffic deploys some mechanism for verifying that all routers on the path understand and agree to use the alternate ECN semantics for this traffic; or
オプション2：すべての代替ECNトラフィックは、パス上のすべてのルーターがこのトラフィックの代替ECNセマンティクスを理解し、同意することを確認するためのいくつかのメカニズムを展開します。また
Option 3: The alternate ECN semantics are defined in such a way as to ensure the fair and peaceful coexistence of the alternate-ECN traffic with best-effort and other traffic, even in environments that include old routers that do not understand the alternate ECN semantics.
オプション3：代替ECNセマンティクスは、代替ECNセマンティクスを理解していない古いルーターを含む環境であっても、ベストエフォートやその他のトラフィックを備えた代替ECNトラフィックの公正かつ平和的な共存を確保するような方法で定義されています。。
Each of these alternatives is explored in more detail below.
これらのそれぞれの代替案については、以下で詳しく説明します。
The first option specified above is for the alternate-ECN traffic to be clearly understood as only suitable for enclosed environments, and as unsafe for deployment in the global Internet. Specifically, this would mean that it would be unsafe for packets using the alternate ECN semantics to be unleashed in the global Internet. This restriction would prevent the alternate-ECN traffic from traversing an old router outside of the enclosed environment that didn't understand the alternate semantics. This document doesn't comment on whether a mechanism would be required to ensure that the alternate ECN semantics would not be let loose on the global Internet. This document also doesn't comment on the chances that this scenario would be considered acceptable for standardization by the IETF community.
上記で指定された最初のオプションは、代替ECNトラフィックが囲まれた環境にのみ適したものとして明確に理解され、グローバルなインターネットでの展開に安全ではないことです。具体的には、これは、グローバルなインターネットで解き放たれる代替ECNセマンティクスを使用したパケットにとって安全ではないことを意味します。この制限により、代替ECNトラフィックは、代替セマンティクスを理解していない囲まれた環境の外に古いルーターを通過することを妨げます。このドキュメントでは、代替ECNセマンティクスがグローバルインターネット上で解き放たれないようにするためにメカニズムが必要かどうかについてコメントしていません。また、このドキュメントは、このシナリオがIETFコミュニティによる標準化に受け入れられると見なされる可能性についてもコメントしていません。
The second option specified above is for the alternate-ECN traffic to include a mechanism for ensuring that all routers along the path understand and agree to the use of the alternate ECN semantics for this traffic. As an example, such a mechanism could consist of a field in an IP option that all routers along the path decrement if they agree to use the alternate ECN semantics with this traffic. (A similar mechanism is proposed for Quick-Start, for verifying that all of the routers along the path understand the Quick-Start IP Option [QuickStart].) Using such a mechanism, a sender could have reasonable assurance that the packets that are sent specifying the use of alternate ECN semantics only traverse routers that, in fact, understand and agree to use these alternate semantics for these packets. Note, however, that most existing routers are optimized for IP packets with no options, or with only some very well-known and simple IP options. Thus, the definition and use of any new IP option may have a serious detrimental effect on the performance of many existing IP routers.
上記で指定された2番目のオプションは、代替ECNトラフィックが、パスに沿ったすべてのルーターがこのトラフィックの代替ECNセマンティクスの使用を理解し、同意することを保証するメカニズムを含めることです。例として、このようなメカニズムは、このトラフィックで代替ECNセマンティクスを使用することに同意する場合、パスに沿ったすべてのルーターが低下するIPオプションのフィールドで構成されます。（パスに沿ったすべてのルーターがクイックスタートIPオプション[QuickStart]を理解していることを確認するために、クイックスタートに対して同様のメカニズムが提案されています。）そのようなメカニズムを使用して、送信者は送信されるパケットが合理的な保証を持つ可能性があります。実際、これらのパケットにこれらの代替セマンティクスを使用することを理解し、同意する代替ECNセマンティクスの使用のみを指定します。ただし、ほとんどの既存のルーターは、オプションのないIPパケット、または非常によく知られた単純なIPオプションのみで最適化されていることに注意してください。したがって、新しいIPオプションの定義と使用は、多くの既存のIPルーターのパフォーマンスに深刻な有害な影響を与える可能性があります。
Such a mechanism should be robust in the presence of paths with multi-path routing, and in the presence of routing or configuration changes along the path while the connection is in use. In particular, if this option is used, connections could include some form of monitoring for changes in path behavior and/or periodic monitoring that all routers along the path continue to understand the alternate ECN semantics.
このようなメカニズムは、マルチパスルーティングを備えたパスの存在下で、および接続が使用されている間にパスに沿ってルーティングまたは構成の変更が存在する場合、堅牢でなければなりません。特に、このオプションが使用される場合、接続には、パスの動作の変更および/または定期的な監視の何らかの監視が含まれ、パスに沿ったすべてのルーターが代替ECNセマンティクスを理解し続けることができます。
The third option specified above is for the alternate ECN semantics to be defined so that traffic using the alternate semantics would coexist safely in the Internet on a path with one or more old routers that use only the default ECN semantics. In this scenario, a connection sending alternate-ECN traffic would have to respond appropriately to a CE packet (a packet with the ECN codepoint "11") received at the receiver, using a conformant congestion control response. Hopefully, the connection sending alternate-ECN traffic would also respond appropriately to a dropped packet, which could be a congestion indication from a router that doesn't use ECN.
上記で指定された3番目のオプションは、代替セマンティクスを使用したトラフィックがデフォルトのECNセマンティクスのみを使用する1つ以上の古いルーターを使用してパス上でインターネットで安全に共存するように、代替ECNセマンティクスを定義することです。このシナリオでは、代替ECNトラフィックを送信する接続では、コンフォーマント輻輳制御応答を使用して、受信者で受信したCEパケット（ECNコードポイント「11」のパケット）に適切に応答する必要があります。うまくいけば、代替ECNトラフィックを送信する接続が、ECNを使用しないルーターからの混雑の兆候である可能性があります。
RFC 3168 defines the default ECN semantics as follows:
RFC 3168は、デフォルトのECNセマンティクスを次のように定義します。
"Upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems MUST be essentially the same as the congestion control response to a *single* dropped packet. For example, for ECN-Capable TCP the source TCP is required to halve its congestion window for any window of data containing either a packet drop or an ECN indication."
「単一のCEパケットのECN対応輸送による受領時に、最終システムで行われた輻輳制御アルゴリズムは、基本的に *単一 *ドロップされたパケットに対する輻輳制御応答と同じでなければなりません。たとえば、ECN-の場合 - 有能なTCPソースTCPは、パケットドロップまたはECN表示のいずれかを含むデータのウィンドウに対して、輻輳ウィンドウを半分にするために必要です。」
The only conformant congestion control mechanisms currently standardized in the IETF are TCP [RFC2581] and protocols using TCP-like congestion control (e.g., SCTP [RFC2960], DCCP with CCID-2 ([RFC4340], [RFC4341])), and TCP-Friendly Rate Control (TFRC) [RFC3448], and protocols with TFRC-like congestion control (e.g., DCCP using CCID-3 [RFC4342]). TCP uses Additive-Increase Multiplicative-Decrease congestion control, and responds to the loss or ECN-marking of a single packet by halving its congestion window. In contrast, the equation-based congestion control mechanism in TFRC estimates the loss event rate over some period of time, and uses a sending rate that would be comparable, in packets per round-trip-time, to that of a TCP connection experiencing the same loss event rate.
現在IETFで標準化されている唯一のコンフォーマント輻輳制御メカニズムは、TCP [RFC2581]およびTCP様鬱血制御（例：SCTP [RFC2960]、CCID-2を備えたDCCP）を使用したプロトコルです（[RFC4340]、[RFC4341]）、およびTCP - フレンドリーレートコントロール（TFRC）[RFC3448]、およびTFRC様鬱血制御（CCID-3を使用したDCCP [RFC4342]）を備えたプロトコル。TCPは、添加剤の増加倍数抑制輻輳制御を使用し、輻輳ウィンドウを半分にすることにより、単一のパケットの損失またはECNマークに応答します。対照的に、TFRCの方程式ベースの混雑制御メカニズムは、ある期間にわたる損失イベント率を推定し、往復時間ごとにパケットで同等の送信率を使用します。同じ損失イベント率。
So what are the requirements for alternate-ECN traffic to compete appropriately with other traffic on a path through an old router that doesn't understand the alternate ECN semantics (and therefore might be using the default ECN semantics)? The first and second requirements below concern compatibility between traffic using alternate ECN semantics and routers using default ECN semantics.
それでは、代替ECNセマンティクスを理解していない（したがってデフォルトのECNセマンティクスを使用している可能性がある）古いルーターを介したパス上の他のトラフィックと適切に競合するための代替ECNトラフィックの要件は何ですか？以下の最初と2番目の要件は、代替ECNセマンティクスを使用したトラフィック間の互換性と、デフォルトのECNセマンティクスを使用したルーターの互換性に関するものです。
The first requirement for compatibility with routers using default ECN is that if a packet is marked with the ECN codepoint "11" in the network, this marking is not changed on the packet's way to the receiver (unless the packet is dropped before it reaches the receiver). This requirement is necessary to ensure that congestion indications from a default-ECN router make it to the transport receiver.
デフォルトのECNを使用したルーターとの互換性の最初の要件は、パケットがネットワーク内のECNコードポイント「11」でマークされている場合、このマーキングは受信機へのパケットの方法で変更されないことです（パケットがドロップされない限り、パケットがドロップされない限り、受信機）。この要件は、デフォルトのECNルーターからのうっ血指示が輸送レシーバーに到達するようにするために必要です。
A second requirement for compatibility with routers using default ECN is that the end-nodes respond to packets that are marked with the ECN codepoint "11" in a way that is friendly to flows using IETF-conformant congestion control. This requirement is needed because the "11"-marked packets might have come from a congested router that understands only the default ECN semantics, and that expects that end-nodes will respond appropriately to CE packets. This requirement would ensure that the traffic using the alternate semantics does not `bully' competing traffic that it might encounter along the path, and that it does not drive up congestion on the shared link inappropriately.
デフォルトのECNを使用したルーターとの互換性の2番目の要件は、END-NODESがIETFコンフォーメントの混雑制御を使用して流れるのに友好的な方法で、ECNコードポイント「11」でマークされたパケットに応答することです。「11」マークされたパケットは、デフォルトのECNセマンティクスのみを理解し、エンドノードがCEパケットに適切に応答することを期待する混雑したルーターから来た可能性があるため、この要件が必要です。この要件により、代替のセマンティクスを使用したトラフィックが、パスに沿って遭遇する可能性のある競合するトラフィックを「いじめない」せず、共有リンクの混雑を不適切に駆り立てないことを保証します。
Additional requirements concern compatibility between traffic using default ECN semantics and routers using alternate ECN semantics. This situation could occur if a diffserv codepoint using default ECN semantics is redefined to use alternate ECN semantics, and traffic from an "old" source traverses a "new" router. If the router "knows" that a packet is from a sender using alternate semantics (e.g., because the packet is using a certain diffserv codepoint, and all packets with that diffserv codepoint use alternate semantics for the ECN field), then the requirements below are not necessary, and the rules for the alternate semantics apply.
追加の要件は、デフォルトのECNセマンティクスを使用したトラフィック間の互換性と、代替ECNセマンティクスを使用したルーター間の互換性に関係しています。この状況は、デフォルトのECNセマンティクスを使用したDiffServ CodePointが代替ECNセマンティクスを使用するように再定義され、「古い」ソースからのトラフィックが「新しい」ルーターを横断する場合に発生する可能性があります。ルーターは、パケットが代替セマンティクスを使用して送信者からのものであることを「知っている」（たとえば、パケットが特定のDiffServ CodePointを使用しているため、およびそのdiffserv CodePointを使用したすべてのパケットがECNフィールドに代替セマンティクスを使用しているため）、以下の要件は次のとおりです。必要ではなく、代替セマンティクスのルールが適用されます。
A requirement for compatibility with end-nodes using default ECN is that if a packet that *could* be using default semantics is marked with the ECN codepoint "00", this marking must not be changed to "01", "10", or "11" in the network. This prevents the packet from being represented incorrectly to a default-ECN router downstream as ECN-Capable. Similarly, if a packet that *could* be using default semantics is marked with the ECN codepoint "01", then this codepoint should not be changed to "10" in the network (and a "10" codepoint should not be changed to "01"). This requirement is necessary to avoid interference with the transport protocol's use of the ECN nonce [RFC3540].
デフォルトのECNを使用したエンドノードとの互換性の要件は、デフォルトのセマンティクスを使用している *可能なパケットがECNコードポイント「00」でマークされている場合、このマーキングを「01」、「10」、または「または」に変更してはならないことです。ネットワーク内の「11」。これにより、PacketがECN対応として下流のデフォルトECNルーターに誤って表されないようにします。同様に、デフォルトのセマンティクスを使用している *可能なパケットがECN CodePoint "01"でマークされている場合、このコードポイントはネットワーク内の「10」に変更しないでください（および「10」コードポイントは変更しないでください」01 "）。この要件は、輸送プロトコルによるECNノンセの使用との干渉を避けるために必要です[RFC3540]。
As discussed earlier, the current conformant congestion control responses to a dropped or default-ECN-marked packet consist of TCP and TCP-like congestion control, and of TFRC (TCP-Friendly Rate Control). Another possible response considered in RFC 3714, but not standardized in a standards-track document, is that of simply terminating an alternate-ECN connection for a period of time if the long-term sending rate is higher than would be that of a TCP connection experiencing the same packet dropping or marking rates [RFC3714]. We note that the use of such a congestion control response to CE-marked packets would require specification of time constants for measuring the loss rates and for stopping transmission, and would require a consideration of issues of packet size.
前述のように、ドロップされたまたはデフォルトのECNマークされたパケットに対する現在のコンフォーマン剤の輻輳制御応答は、TCPおよびTCP様の混雑制御、およびTFRC（TCPに優しいレート制御）で構成されています。RFC 3714で考慮された別の可能な応答は、標準トラックドキュメントで標準化されていないことですが、長期の送信率がTCP接続のそれよりも高い場合、一定期間代替ECN接続を単純に終了することです。同じパケットドロップまたはマーキングレートを経験します[RFC3714]。CEマークされたパケットに対するこのような輻輳制御応答を使用するには、損失率を測定し、伝送を停止するために時定数の指定が必要であり、パケットサイズの問題を考慮する必要があることに注意してください。
This section discusses question (4) posed in Section 2:
このセクションでは、セクション2で提起された質問（4）について説明します。
(4) How well does the alternate-ECN traffic perform, and how well does it coexist with competing traffic on the path, in a "clean" environment with new routers and with the unambiguous specification of the use of alternate ECN semantics?
(4) 代替ECNトラフィックはどの程度うまく機能し、パス上での競合するトラフィック、新しいルーター、および代替ECNセマンティクスの使用の明確な仕様でどの程度うまく共存しますか？
One issue in evaluating the alternate ECN semantics concerns mechanisms to discourage lying from the transport receiver to the transport sender. In many cases, the sender is a server that has an interest in using the alternate ECN semantics correctly, while the receiver has more incentive to lie about the congestion experienced along the path.
代替ECNセマンティクスの評価における1つの問題は、輸送受信者から輸送送信者への嘘を思いとどまらせるメカニズムに関するものです。多くの場合、送信者は代替ECNセマンティクスを正しく使用することに興味があるサーバーですが、受信者はパスに沿って経験した混雑について嘘をつくインセンティブを持っています。
In the default ECN semantics, two of the four ECN codepoints are used for ECN-Capable(0) and ECN-Capable(1). The use of two codepoints for ECN-Capable, instead of one, permits the data sender to verify the receiver's reports that packets were actually received unmarked at the receiver. In particular, the sender can specify that the receiver report to the sender whether each unmarked packet was received ECN-Capable(0) or ECN-Capable(1), as discussed in RFC 3540 [RFC3540]. This use of ECN-Capable(0) and ECN-Capable(1) is independent of the semantics of the other ECN codepoints, and could be used, if desired, with alternate semantics for the other codepoints.
デフォルトのECNセマンティクスでは、4つのECNコードポイントのうち2つがECN対応（0）およびECN対応（1）に使用されます。ECNに対応するために2つのコードポイントを使用することで、データ送信者は、パケットが実際に受信者でマークされていないことを受信者のレポートを確認することができます。特に、送信者は、RFC 3540 [RFC3540]で説明されているように、各マークのないパケットがECN対応（0）またはECN対応（1）を受信したかどうかを送信者に指定できます。ECN対応（0）およびECN対応（1）のこの使用は、他のECNコードポイントのセマンティクスとは無関係であり、必要に応じて他のコードポイントの代替セマンティクスを使用して使用できます。
If alternate semantics for the ECN codepoint don't include the use of two separate codepoints to indicate ECN-Capable, then the connections using those semantics have lost the ability to verify that the data receiver is accurately reporting the received ECN codepoint to the data sender. In this case, it might be necessary for the alternate-ECN framework to include alternate mechanisms for ensuring that the data receiver is reporting feedback appropriately to the sender. As one possibility, policers could be used in routers to ensure that end nodes are responding appropriately to marked packets.
ECN CodePointの代替セマンティクスが2つの個別のコードポイントを使用してECN対応を示すことを含めない場合、それらのセマンティクスを使用した接続は、データ受信機が受信したECNコードポイントをデータ送信者に正確に報告していることを確認する能力を失いました。。この場合、代替ECNフレームワークが、データ受信者が送信者に適切にフィードバックを報告していることを確認するための代替メカニズムを含める必要があるかもしれません。1つの可能性として、ポリサーをルーターで使用して、エンドノードがマークされたパケットに適切に応答していることを確認できます。
A second general issue concerns the coexistence of alternate-ECN traffic with competing traffic along the path, in a clean environment where all routers understand and are willing to use the alternate ECN semantics for the traffic that specifies its use.
2番目の一般的な問題は、すべてのルーターがその使用を指定するトラフィックに代替ECNセマンティクスを理解し、喜んで使用するクリーンな環境で、パスに沿った競合するトラフィックとの代替ECNトラフィックの共存に関するものです。
If the traffic using the alternate ECN semantics is best-effort traffic, then it is subject to the general requirement of fair competition with TCP and other traffic along the path [RFC2914].
代替ECNセマンティクスを使用したトラフィックが最良のトラフィックである場合、TCPおよびパスに沿った他のトラフィックとの公正な競争の一般的な要件の対象となります[RFC2914]。
If the traffic using the alternate ECN semantics is diffserv traffic, then the requirements are governed by the overall guidelines for that class of diffserv traffic. It is beyond the scope of this document to specify the requirements, if any, for the coexistence of diffserv traffic with other traffic on the link; this should be addressed in the specification of the diffserv codepoint itself.
代替ECNセマンティクスを使用したトラフィックがDiffServトラフィックである場合、要件は、DiffServトラフィックのクラスの全体的なガイドラインによって支配されます。このドキュメントの範囲を超えて、リンク上の他のトラフィックとDiffservトラフィックが共存するために要件を指定することです。これは、DiffServ CodePoint自体の仕様で対処する必要があります。
RFC 3168 specifies the use of the default ECN semantics by an end-to-end transport protocol, with the requirement that "upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems MUST be essentially the same as the congestion control response to a *single* dropped packet" ([RFC3168], Section 5). In contrast, some of the proposals for alternate ECN semantics are for ECN used in an edge-to-edge context between gateways at the edge of a network region, e.g., [BESFC06].
RFC 3168エンドツーエンド輸送プロトコルによるデフォルトのECNセマンティクスの使用を指定し、「単一のCEパケットのECN対応輸送による受領時に、渋滞制御アルゴリズムが最終システムで続いたという要件があります。*単一 *ドロップされたパケット "（[RFC3168]、セクション5）に対する輻輳制御応答と本質的に同じでなければなりません。対照的に、代替ECNセマンティクスの提案の一部は、ネットワーク領域の端のゲートウェイ間のエッジからエッジへのコンテキストで使用されるECNのためのものです[BESFC06]。
When alternate ECN is defined with edge-to-edge semantics, this definition needs to ensure that the edge-to-edge semantics do not conflict with a connection using other ECN semantics end-to-end. One way to avoid conflict would be for the edge-to-edge ECN proposal to include some mechanism to ensure that the edge-to-edge ECN is not used for connections that are using other ECN semantics (standard or otherwise) end-to-end. Alternately, the edge-to-edge semantics could be defined so that they do not conflict with a connection using other ECN semantics end-to-end.
代替ECNがエッジツーエッジセマンティクスで定義されている場合、この定義は、エッジツーエッジセマンティクスが他のECNセマンティクスを使用して接続と競合しないようにする必要があります。競合を回避する1つの方法は、エッジツーエッジECNの提案が、他のECNセマンティクス（標準またはその他）を使用している接続にエッジツーエッジECNが使用されないことを保証するためのいくつかのメカニズムを含めることです。終わり。あるいは、他のECNセマンティクスを使用して接続と競合しないように、エッジツーエッジセマンティクスを定義できます。
RFC 3168 has an extensive discussion of the interactions between ECN and IP tunnels, including IPsec and IP in IP. Proposals for alternate ECN semantics might interact with IP tunnels differently than default ECN. As a result, proposals for alternate ECN semantics must explicitly consider the issue of interactions with IP tunnels.
RFC 3168には、IPのIPSECとIPを含むECNとIPトンネルの間の相互作用について広範な議論があります。代替ECNセマンティクスの提案は、デフォルトのECNとは異なる方法でIPトンネルと相互作用する可能性があります。その結果、代替ECNセマンティクスの提案は、IPトンネルとの相互作用の問題を明示的に考慮する必要があります。
A third general issue concerns the evaluation of the general merits of the proposed alternate ECN semantics. Again, it would be beyond the scope of this document to specify requirements for the general evaluation of alternate ECN semantics.
3番目の一般的な問題は、提案された代替ECNセマンティクスの一般的なメリットの評価に関するものです。繰り返しますが、代替ECNセマンティクスの一般的な評価の要件を指定することは、このドキュメントの範囲を超えています。
This document doesn't propose any new mechanisms for the Internet protocol, and therefore doesn't introduce any new security considerations.
このドキュメントは、インターネットプロトコルの新しいメカニズムを提案していないため、新しいセキュリティに関する考慮事項は導入されません。
This document has discussed some of the issues to be considered in the specification of alternate semantics for the ECN field in the IP header.
このドキュメントでは、IPヘッダーのECNフィールドの代替セマンティクスの仕様で考慮すべき問題のいくつかについて説明しました。
Specifications of alternate ECN semantics must clearly state how they address the issues raised in this document, particularly the issues discussed in Section 2. In addition, specifications for alternate ECN semantics must meet the requirements in Section 5.2 for coexistence with competing traffic.
代替ECNセマンティクスの仕様は、このドキュメントで提起された問題、特にセクション2で説明されている問題にどのように対処するかを明確に述べなければなりません。さらに、競合するトラフィックとの共存のために、代替ECNセマンティクスの仕様はセクション5.2の要件を満たす必要があります。
This document is based in part on conversations with Jozef Babiarz, Kwok Ho Chan, and Victor Firoiu on their proposal for an alternate use of the ECN field in DiffServ environments. Many thanks to Francois Le Faucheur for feedback recommending that the document include a section at the beginning discussing the potential issues that need to be addressed. Thanks also to Mark Allman, Fred Baker, David Black, Gorry Fairhurst, and to members of the TSVWG working group for feedback on these issues.
このドキュメントは、Diffserv環境でのECNフィールドの代替使用の提案に関するJozef Babiarz、Kwok Ho Chan、およびVictor Firoiuとの会話に一部基づいています。Francois Le Faucheurに、ドキュメントには、対処する必要がある潜在的な問題について議論するセクションが最初に含まれることを推奨してくれたフィードバックについて感謝します。マーク・オールマン、フレッド・ベイカー、デビッド・ブラック、ゴーリー・フェアハースト、およびこれらの問題に関するフィードバックをしてくれたTSVWGワーキンググループのメンバーにも感謝します。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[BCF05] Babiarz, J., Chan, K., and V. Firoiu, "Congestion Notification Process for Real-Time Traffic", Work in Progress, July 2005.
[BCF05] Babiarz、J.、Chan、K。、およびV. Firoiu、「リアルタイムトラフィックの渋滞通知プロセス」、2005年7月の作業。
[BESFC06] Briscoe, B., et al., "An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a DiffServ Region", Work in Progress, June 2006.
[BESFC06] Briscoe、B.、et al。、「前もって前の通知のためのエッジツーエッジ展開モデル：Diffserv地域の入場制御」、2006年6月、進行中の作業。
[ECN] ECN Web Page, URL <www.icir.org/floyd/ecn.html>.
[ECN] ECN Webページ、url <www.icir.org/floyd/ecn.html>。
[QuickStart] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, "Quick-Start for TCP and IP", Work in Progress, October 2006.
[Quickstart] S. Floyd、M。Allman、A。Jain、およびP. Sarolahti、「TCPとIPのクイックスタート」、2006年10月、進行中の作業。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。、およびW. Stevens、「TCP渋滞制御」、RFC 2581、1999年4月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S。、「混雑制御原則」、BCP 41、RFC 2914、2000年9月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448] Handley、M.、Floyd、S.、Padhye、J。、およびJ. Widmer、「TCP Friendry Rate Control（TFRC）：プロトコル仕様」、RFC 3448、2003年1月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540] Spring、N.、Wetherall、D。、およびD. Ely、「Noncesによる堅牢な明示的な混雑通知（ECN）シグナル伝達」、RFC 3540、2003年6月。
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[RFC3714] Floyd、S。およびJ. Kempf、「IABは、インターネットでの音声トラフィックの混雑制御に関する懸念」、RFC 3714、2004年3月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagramうっ血制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006.
[RFC4341] Floyd、S。およびE. Kohler、「データグラムの混雑制御プロトコルのプロファイル（DCCP）混雑制御ID 2：TCP様渋滞制御」、RFC 4341、2006年3月。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006.
[RFC4342] Floyd、S.、Kohler、E。、およびJ. Padhye、「データグラムの混雑制御プロトコル（DCCP）混雑制御IDのプロファイル：TCPに優しいレートコントロール（TFRC）」、RFC 4342、2006年3月。
[XSSK05] Y. Xia, L. Subramanian, I. Stoica, and S. Kalyanaraman, One More Bit Is Enough, SIGCOMM 2005, September 2005.
[XSSK05] Y. Xia、L。Subramanian、I。Stoica、およびS. Kalyanaraman、もう1つだけで十分です、Sigcomm 2005、2005年9月。
Author's Address
著者の連絡先
Sally Floyd ICIR (ICSI Center for Internet Research)
Sally Floyd ICIR（ICSIセンターのインターネット研究）
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
URL: http://www.icir.org/floyd/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースは免責明示的または暗示されたすべての保証。ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。