この文書はRFC 4774の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
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). 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. IPヘッダのRFC3168の明示的な混雑通知(ECN)フィールドの代 替の意味論の多くの提案がありました。ECNフィールドの代替の意味を定 義する際に、この文書はいくつかの問題を論じて、そして定義された代替の 意味を理解しないルータを含むインターネットでの安全な共存のための必要 条件を指定します。この文書はこのような代替の意味論の1つの最近の提案 の著者との論議の結果として進展しました。 Table of Contents 目次 1. Introduction 1. はじめに 2. An Overview of the Issues 2. 問題の概観 3. Signalling the Use of Alternate ECN Semantics 3. 代わりのECN意味論の使用を示すこと 3.1. Using the Diffserv Field for Signalling 3.1. Diffservフィールドを合図に使うこと 4. Issues of Incremental Deployment 4. 逐次的な配置の問題 4.1. Option 1: Unsafe for Deployment in the Internet 4.1. 選択肢1:インターネットの配置は安全でありません 4.2. Option 2: Verification that Routers Understand the Alternate Semantics 4.2. 選択肢2:ルータが代わりの意味論を理解するという検証 4.3. Option 3: Friendly Coexistence with Competing Traffic 4.3. 選択肢3:競争トラフィックとの友好的共存 5. Evaluation of the Alternate ECN Semantics 5. 代わりのECN意味論の評価 5.1. Verification of Feedback from the Router 5.1. ルータからのフィードバックの検証 5.2. Coexistence with Competing Traffic 5.2. 競争しているトラフィックとの共存 5.3. Proposals for Alternate ECN with Edge-to-Edge Semantics 5.3. エンドエンドの意味論を持つ代わりのECNの提案 5.4. Encapsulated Packets 5.4. カプセル化パケット 5.5. A General Evaluation of the Alternate ECN Semantics 5.5. 代わりのECN意味論の一般的な評価 6. Security Considerations 6. セキュリティの考察 7. Conclusions 7. 結論 8. Acknowledgements 8. 謝辞 9. Normative References 9. 参照する参考文献 10. Informative References 10. 有益な参考文献 1. Introduction 1. はじめに [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フィールドの値の意味を指定します。しかしながら終端ノードはE CNフィールドに、例えば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]. ECNコードポイントのための代わりの意味論として、IETFと研究共同 体での多くの提案がありました。1つのそのような提案[BCF05]はDiffServ ネットワークの音声とビデオ会議とマルチメディアストリーミングのような リアルタイム双方向トラフィックに対して代わりのECNの意味を提案しま す。この提案で、代わりのECNの意味は経路に沿って経験された2段階の 混雑レベルの情報を提供します[BCF05]。他の研究提案[XSSK05]は低混雑プロ トコル、可変構造輻輳制御プロトコル(VCP)を提案し、これはECNフィール ドの2ビットが低負荷、高付加、過負荷(輻輳)を意味し、輸送プロトコル は低負荷の間により急速にかさんできます。代わりのECN意味論の提案の いくつかは、ENCをネットワーク領域の端のゲートウェイ間のエッジエッ ジの意味で使うものです、例えば入場許可管理の混雑前通知です[BESFC06]。 代わりのECN意味論の他の提案はECNウェブページ[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を使わない世界)との安全な共存のための必要条件を 与えます。 2. An Overview of the Issues 2. 問題の概観 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) 第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コードポイントを理解する全ルータが代わりの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章で論じられます。 3. Signalling the Use of Alternate ECN Semantics 3. 代わりのECN意味論の使用を示すこと 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フィールドにコードポイントを設定します。この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コードポイントはルータ待ち行列においてホップ毎の動作 を合図するために使われます。1つの可能性は1つのdiffservコードポイン トがデフォルトECN意味論のホップ毎の動作を示すのに使われ、別の diffservコードポイントが代わりのECN意味論の類似のホップ毎の動作を 示すために使われる事です。もう1つの可能性は1つのdiffservコードポイ ントがホップ毎の最善努力のキューイングとスケジューリング行動を示すの に使い、他のが代わりの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フィールドのために代わりの意 味論の使用を示すために使われる方法にかかわらず適用されます。 3.1. Using the Diffserv Field for Signalling 3.1. Diffservフィールドを合図に使うこと 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. 我々は、IPヘッダの他のフィールドの中身にかかわらず、RFC3168 で定義されるデフォルトECN意味論が3168が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. diffservフィールドを代わりのECN意味論の使用を示すために使う2つの 方法があります。1つの方法が既存のdiffservコードポイントを使い、その コードポイントで代わりのECN意味論の使用を指定するために、公認のI ETF過程を通して、そのコードポイントの最新の定義を修正することです。 2番目の方法は新しいdiffservコードポイントを定義し、そのコードポイン トで代わりのECN意味論の使用を指定することです。我々は、前者はパス 上のあるルータがdiffservコードポイントを理解するがこのdiffservコード ポイントでデフォルトECN意味論を使う、あるいはまったくECNを使わ ず、他のルータがこのdiffservコードポイントで代わりのECN意味論を使 う、可能性を指摘します。 4. Issues of Incremental Deployment 4. 逐次的な配置の問題 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意味論を理解しないとき、代わりのEC Nのトラフィック自身で可能性のある結果は何ですか?これらの問題は代わ りの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 代わりのECNのトラフィック | | CE印パケット | Old | Non-ECN traffic ----------> | Router | ---> dropped packet 非ECNのトラフィック | | 廃棄パケット | | RFC-3168 ECN traffic -----> | | ---> CE-marked packet RFC3168ECNのトラフィック | | CE印パケット |--------| 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のトラフィックとRFC3168ECNを使う旧ルー タ、混雑していて到着するパケットを廃棄するか印を付ける準備ができてい る。 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のように、パスに沿ってRFC3168の元のECN 意味論だけを理解する旧ルータがあるならどうでしょう?混雑時に、RFC 3168で定義されるようにIPヘッダのECNフィールドがECN対応ト ランスポート(ECT)コードポイントの1つに設定された代わりのECNの パケットを見た旧ECNルータは、パケット廃棄の代わりに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の接続が、混雑管理に関して、パケットが 廃棄されたとき同様に反応することを予想するでしょう。もし代わりのEC Nのトラフィックが旧ルータによって設定された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意味論を理解しない旧 ルータを含む環境でさえでも、最善努力と他のトラフィックと代わりのEC Nのトラフィックの公正なで平和的共存を保証するような方法で定義される。 Each of these alternatives is explored in more detail below. これらの選択肢のそれぞれが下記のでより多く探究されます。 4.1. Option 1: Unsafe for Deployment in the Internet 4.1. 選択肢1:インターネットの配置は安全でありません 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オプション[QuickStart]を理解することを確かめるため、速いスター トに対して提案されます。)このようなメカニズムを使って、送信者は代わ りのECN意味論の使用を指定たパケットを、代わりの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意 味論を理解し続けるための何らかの監視を含む事が出来ます。 4.3. Option 3: Friendly Coexistence with Competing Traffic 4.3. 選択肢3:競争トラフィックとの友好的共存 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: RFC3168が次のようにデフォルト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." 「ECN対応トランスポートでの単一のCEパケットの受信時は、エンドシ ステムの混雑制御アルゴリズムは本質的に*単一*の廃棄パケットに対する 混雑制御の応答と同じであるに違いありません(MUST)。例えば、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で現在標準化されているものは、TC P[RFC2581]とTCPにに類似した輻輳制御を使うプロトコル(例えば、SC TP[RFC2960]や、CCID−2と一緒のDCCP([RFC4340], [RFC4341])) や、TCPに友好的なレート制御(TFRC)[RFC3448]や、TFRCのよう な輻輳制御を持つプロトコル(例えば、CCID−3[RFC4342]を使うDCC P)です。 TCPは加法増加と乗法減少の混雑制御を使い、その混雑窓を 半減することによって、1つのパケットの損失やECNマーク付けに対応し ます。それと対照的に、TFRCの方程式ベースの輻輳制御機構はある期間 の損失イベント率を見積もって、パケット往復時間が同等で損失が同等なT CP接続同等の送信率を使います。 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番目の必要条件は、終端ノー ドがECNコードポイント「11」のマークが付いているパケットに、IE TF準拠の混雑制御を使う通信に友好的な方法での返答するということです。 「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コードポイントが代わりのECN意 味論で再定義され、そして「旧」情報源が「新」ルータを通過するなら、こ の状況は起こり得ます。もしルータがパケットが代わりの意味論を使う送信 者からと「知っている」なら(例えば、パケットがあるdiffservコードポイ ントを使い、そしてそのdiffservコードポイントのすべてのパケットがEC Nフィールドの代わりの意味論を使うなら)、下の必要条件は必要ではあり ません、そして代わりの意味論のための規則は適用されます。 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のような混雑制御とT FRC(TCPに友好的なレートコントロール)から成り立ちます。標準化 されていない標準化中文書のRFC3714で考えられた他の可能な応答は、 もし長期間の送信レートが、同じパケット廃棄あるいはマーク率のTCP接 続の経験するもの[RFC3714]より、高すぎるなら、単純に代わりのECNの接 続を一定期間後に終了させる事です。我々は、CEのマークされたパケット へのこのような輻輳制御の応答の使用は、損失率を測のと、伝達を止めるた めに、時間定数の仕様を必要とし、パケットの大きさの問題の考慮を必要と することを指摘します。 5. Evaluation of the Alternate ECN Semantics 5. 代わりのECN意味論の評価 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意味論の明確な仕様を使用する「きれ いな」環境で、どれほどよくパス上の競争トラフィックと共存しますか? 5.1. Verification of Feedback from the Router 5.1. ルータからのフィードバックの検証 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つがEC N対応(0)とECN対応(1)のために使われます。EECN対応が1つでなく 2つのコードポイントを使うのは、パケットが受信者に印なしで実際に受け られたという受信者の報告を、データ送信者が実証するのを許すためです。 特に、RFC3540[RFC3540]で論じたように、それぞれの印がないパケッ トがECN対応(0)かECN対応(1)かを、受信者から送信者へ報告するよう に送信者は明示できます。ECN対応(0)とECN対応(1)の使用は他のEC Nコードポイントの意味論とは独立で、そして、もし望ましいなら、他のコー ドポイントの代わりの意味論で使うことができます。 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コードポイントのための代わりの意味論が2つのECN対応を使 う事を含まないなら、この意味論を使う接続で、データ受信者が受信したE CNコードポイントをデータ送信者に正確に報告していることを確かめる能 力を失うことを示します。この場合、データ受信者がフィードバックを適切 に送信者に報告していることを保証するための代わりのメカニズムを含むこ とは代わりのECNの枠組みにとって必要であるかもしれません。1つの可 能性として、終端ノードが適切に印を付けたパケットに返答していることを 保証するために、ルータでポリシが使われるかもしれません。 5.2. Coexistence with Competing Traffic 5.2. 競争しているトラフィックとの共存 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意味論を使うと指定されたトラヒックに代わりの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コードポイント自身の仕様で取り上 げられるべきです。 5.3. Proposals for Alternate ECN with Edge-to-Edge Semantics 5.3. エンドエンドの意味論を持つ代わりのECNの提案 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]. RFC3168が「ECN対応トランスポートで1つのCEパケットを受信 したら、末端システムの輻輳制御アルゴリズムが本質的に*1つ*のパケット 廃棄時の輻輳制御応答と同じにに違いありません」という必要条件([RFC3168] 5章)で、エンドエンドトランスポートプロトコルによってデフォルトEC N意味論の使用を指定します。それと対照的に、いくつかの代わりの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が端と端の意味論で定義されるとき、この定義は他のエンド エンドのENC意味論を使う接続で衝突をしないことを保証する必要があり ます。衝突を避ける1つの方法は、端と端のECN提案に、他のエンドエン ドの(標準あるいは他の)ENC意味論を使う接続に端と端のECNが使わ れない事を保証する何らかのメカニズムを含めることです。あるいは、他の エンドエンドECN意味論を使っている接続と競合しないように、端と端の 意味論は定義する事です。 5.4. Encapsulated Packets 5.4. カプセル化パケット 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. RFC3168が、IPsecとIP内IPを含め、ECNとIPトンネル の間の相互作用の大規模な論議をします。代わりのECN意味論の提案がデ フォルトECNt異なるIPトンネルと相互に作用をするかもしれません。 つまり、代わりのECN意味論の提案は、IPトンネルとの相互作用の問題 を明示的に相互作用の問題を考慮に入れなくてはなりません。 5.5. A General Evaluation of the Alternate ECN Semantics 5.5. 代わりのECN意味論の一般的な評価 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意味論の一般的な評価のための必要条 件を指定することはこの文書の範囲外です。 6. Security Considerations 6. セキュリティの考察 This document doesn't propose any new mechanisms for the Internet protocol, and therefore doesn't introduce any new security considerations. この文書はインターネット・プロトコルに対して新しいメカニズムを提案し ません、従って新しいセキュリティの懸念を導きません。 7. Conclusions 7. 結論 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章の必要条件を満たさなくてはなりません。 8. Acknowledgements 8. 謝辞 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に感謝します。同じくこれらの問 題に関するフィードバックに対し、Mark Allman, Fred Baker, David Black, Gorry Fairhurst とTSVWG作業班のメンバーに感謝します。 9. Normative References 9. 参照する参考文献 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. 10. Informative References 10. 有益な参考文献 [BCF05] Babiarz, J., Chan, K., and V. Firoiu, "Congestion Notification Process for Real-Time Traffic", Work in Progress, July 2005. [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. [ECN] ECN Web Page, 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. [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [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. [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003. [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003. [RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [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. [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. [XSSK05] Y. Xia, L. Subramanian, I. Stoica, and S. Kalyanaraman, One More Bit Is Enough, SIGCOMM 2005, September 2005. Author's Address 著者のアドレス Sally Floyd ICIR (ICSI Center for Internet Research) Phone: +1 (510) 666-2989 EMail: 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. この文書はBCP78に含まれる権利と許可と制限の適用を受け、そして この中に明らかにされる以外は著者がすべての権利を維持します。 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文書の権利に関する手続 きの情報はBCP78とBCP79を見てください。 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エディタ機能のための資金供給が現在インターネット学会によって 供給されます。