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
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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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.
この文書では、ECNフィールドの代わりの意味を定義する際に問題のいくつかについて説明し、中に安全に共存するための要件を指定するIPヘッダRFC 3168.に明示的輻輳通知のための代替の意味論の提案の数（ECN）フィールドがありました定義された代替意味を理解していないルータが含まれる可能性があり、インターネット。この文書では、そのような代替の意味論のための1つの最近の提案の著者との協議の結果として進化しました。
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フィールドのコードポイントのためのセマンティクスを指定します。しかし、エンド・ノードは、IPヘッダーのDiffServフィールド内のコードポイントを使用して、例えば、ECNフィールドの代わりの意味論を使用することを指定することができます。
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].
ECNコードポイント用の代替セマンティクスのためにIETFにし、研究コミュニティに多数の提案がありました。そのような提案は、[BCF05]、音声、ビデオ会議、およびDiffServのネットワークでマルチメディアストリーミングなどのリアルタイム非弾性トラフィックのための代わりのECN意味論を提案しています。この提案では、代替のECN意味論は、パス[BCF05]沿っ経験輻輳2つのレベルに関する情報を提供するであろう。低負荷、高負荷、過負荷（輻輳）を示すために、ECNフィールドに2ビットを使用する別の研究提案、[XSSK05]、低複雑プロトコルを提案し、可変構造輻輳制御プロトコル（VCP）、どこトランスポートプロトコルは、低負荷時の政権より急速に増加することができます。 ECNは、受付制御[BESFC06]の事前輻輳通知のために、例えば、ネットワーク領域のエッジにおけるゲートウェイ間のエッジ・ツー・エッジのコンテキストで使用される場合、代替のECN意味論の提案のいくつかはのためのものです。代わりの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意味論を使用して（またはまったく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）ルータがどのパケットで使用するECNの意味論を知っていますか。 （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?
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のコードポイントを理解するすべてのルータは、それが代わりの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）第二の問題は、一部のルータは、デフォルトの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?
(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?
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意味論の使用を通知するために使用されることです。つまり、エンドホストがECNフィールドへの代替セマンティクスが使用されているルータに指示するためにDiffServフィールドでコードポイントを設定します。このDiffServのコードポイントを理解するルータは、ECNフィールドを解釈し、設定するための代替セマンティクスを使用して知っているだろう。このDiffServのコードポイントを理解していない旧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のコードポイントは、ルータキューでホップ単位動作を知らせるために使用されています。一つの可能性は、代替のECN意味論と同様のホップ単位動作を知らせるためにデフォルトECN意味論を持つホップ単位動作、及び別のDiffServコードポイントをシグナリングするために1つのDiffServコードポイントを使用することであろう。別の可能性は、ホップごとのキューイングおよびスケジューリングの振る舞いが、代わりのECN意味論とベストエフォートの使用を知らせるためのDiffServコードポイントを使用することです。これらの問題の詳細な議論は、この文書の範囲を超えています。
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」のコードポイントとよりベストエフォートトラフィックに適用する - デフォルトECN意味論は、現在、関係なく、DiffServフィールドの内容が適用されます。
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.
代わりのECN意味論の使用を通知するためにDiffServフィールドを使用するには、2つの方法があります。一つの方法は、既存のDiffServコードポイントを使用すると、承認されたIETFプロセスを経て、そのコードポイントの現在の定義を変更するために、そのコードポイントで代わりのECN意味論の使用を指定することです。第二の方法は、新規のDiffServコードポイントを定義するために、そのコードポイントを有する代替のECN意味論の使用を指定することです。我々は、これら二つのメカニズムの最初のパスに沿って、いくつかのルータがDiffServのコードポイントを理解しますが、これのDiffServコードポイントでデフォルトECN意味論を使用する、またはまったくECNを使用することはありませんし、他のルータが使用する可能性を高めることに注意してくださいこのDiffServのコードポイントで代わりのECN意味論。
This section discusses questions (2) and (3) posed in Section 2:
このセクションでは、質問を議論（2）と（3）は第2節で提起しました：
(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.
一つの可能性のある問題は、代替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?
第二の特異的な問題は、パスに沿って他のトラフィックで可能な不公正な競争のものです。 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：代替-ECNのトラフィック、古いルーター、RFC-3168 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)
同様に、上記図1のように、RFC 3168からのみデフォルトECN意味論を理解し、パスに沿って古いルータは何がある場合は？輻輳時に、古いデフォルト-ECNルータは、ECN-できるトランスポート（ECT）の1つと代替ECNパケットは、RFC 3168で定義されるように、IPヘッダ内のECNフィールドに設定し、輻輳を設定するコードポイント見ることができます経験豊富な（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.
パケットをドロップする代わりとして、ECNフィールドのコードポイント。この場合、ルータは、パケットが破棄されたかのように代替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コミュニティによって標準化のために許容できると考えられるという可能性についてはコメントしません。
4.2. Option 2: Verification that Routers Understand the Alternate Semantics
4.2. オプション2：検証ルーターは代替セマンティクスを理解します
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オプション[クイックスタート]を理解することを確認するために、クイックスタートのために提案されている。）このような機構を使用して、送信側は、パケットが送信されていることを合理的な保証を持つことができ代わりの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.
上記の指定された第三の選択肢は、代替セマンティクスを使用して、トラフィックは、デフォルトの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（[RFC4340]、[RFC4341]）とDCCP）、およびTCPやさしいレート制御（TFRC）[RFC3448]、およびTFRC状輻輳制御とプロトコル（例えば、DCCP用いCCID-3 [RFC4342]）。 TCPは、添加剤-増加乗法-減少の輻輳制御を使用し、その輻輳ウィンドウを半分にすることにより、単一のパケットの損失やECNマーキングに応答します。これとは対照的に、TFRCで方程式ベースの輻輳制御機構は、一定の期間にわたり、損失イベント率を推定し、ラウンドトリップ時間あたりのパケットで、匹敵する送信レートを使用して、経験してTCP接続のものに同じ損失イベント率。
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のトラフィックのための要件は何ですか？デフォルト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を使用して、ルータとの互換性のための第二の要件は、エンドノードは、IETF準拠の輻輳制御を使用して流れに優しい方法で、ECNコードポイント「11」でマークされているパケットに応答することです。この要件は、「11」-markedパケットが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コードポイントが代わりのECN意味論を使用するように再定義されている場合、このような状況が発生する可能性があり、そして「古い」のソースからのトラフィックは、「新しい」ルータを通過します。ルータは（パケットが特定のDiffServコードポイントを使用して、そのDiffServのコードポイントを持つすべてのパケットが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」。これは、ECN対応などの下流デフォルト-ECNルータに間違って表現されるからパケットを防ぐことができます。 *デフォルトのセマンティクスを使用することができ*パケットはECNコードポイント「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:
このセクションでは、質問（4）第2節で提起について説明します。
(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コードポイントの両者はECN-可能に使用されている（0）とECN-できる（1）。 ECN対応のための2つのコードポイントの使用、代わりの一つは、パケットが実際に受信機でマークされていない受信されたことを受信者のレポートを確認するために、データの送信者を許可します。具体的には、送信者が各マークされていないパケット（0）またはECN対応（1）、RFC 3540 [RFC3540]で議論するようにECN対応受信されたかどうかを送信側にそのレシーバレポートを指定することができます。 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コードポイントの代替セマンティクスはECN対応を示すために二つの別々のコードポイントの使用が含まれていない場合は、これらのセマンティクスを使用した接続は、データ受信機が正確にデータ送信側、受信したECNコードポイントを報告していることを確認する能力を失っています。代替ECNフレームワークは、データ受信者が送信者に適切にフィードバックを報告していることを確実にするための代替メカニズムを含むようにするため、この場合には、必要かもしれません。一つの可能性として、ポリサーは、エンドノードがマークされたパケットに適切に対応していることを確実にするためにルータで使用することができます。
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.
第二の一般的な問題は、すべてのルータが理解し、その使用を指定するトラフィックに対して代わりの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のコードポイント自体の仕様で対処しなければなりません。
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は、単一のCEパケットのECN-可能な輸送によって受信すると、輻輳制御アルゴリズムは、エンドシステムで追跡」要件と、エンド・ツー・エンド伝送プロトコルによってデフォルト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フィールドの代わりの使用のために自分の提案についてヨゼフBabiarz、クォックホーチャン、およびビクターFiroiuとの会話に基づいています。フィードバックのためのフランソワ・ルFaucheurに感謝し、文書が対処する必要がある潜在的な問題を議論先頭にセクションが含まれていることを推奨します。また、マーク・オールマン、フレッド・ベイカー、デビッド・ブラック、Gorry Fairhurstに、これらの問題についてのフィードバックのためのTSVWGワーキンググループのメンバーに感謝します。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、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.、チャン、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]ブリスコー、B.ら、「プリ輻輳通知の端から端まで展開モデル：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.
[クイックスタート] S.フロイド、M.オールマン、A.ジャイナ教、およびP. Sarolahti、 "TCPとIPのためのクイックスタート"、進歩、2006年10月に作業。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "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]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、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]ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（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]春、N.、Wetherall、D.、およびD.イーリー、 "ロバスト明示的輻輳通知（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]フロイド、S.とJ.ケンプ、「インターネットでの音声トラフィックのための輻輳制御に関するIAB心配」、RFC 3714、2004年3月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（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]フロイド、S.、およびE.コーラー、 "データグラム輻輳制御プロトコル（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]フロイド、S.、コーラー、E.、およびJ. Padhye、 "データグラム混雑制御プロトコル（DCCP）輻輳制御ID 3のプロフィール：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.夏、L.サブラマニアン、I.ストイカ、およびS・カリヤナラーマンは、ひとつ以上のビットは、SIGCOMM 2005、2005年9月で十分です。
Author's Address
著者のアドレス
Sally Floyd ICIR (ICSI Center for Internet Research)
サリーフロイドICIR（インターネットリサーチのためのICSIセンター）
Phone: +1 (510) 666-2989 EMail: floyd@icir.org URL: http://www.icir.org/floyd/
電話：+1（510）666-2989 Eメール：floyd@icir.org URL：http://www.icir.org/floyd/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。