RFC4774 日本語訳
4774 Specifying Alternate Semantics for the Explicit CongestionNotification (ECN) Field. S. Floyd. November 2006. (Format: TXT=37144 bytes) (Also BCP0124) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Floyd Request for Comments: 4774 ICIR BCP: 124 November 2006 Category: Best Current Practice
コメントを求めるワーキンググループS.フロイド要求をネットワークでつないでください: 4774ICIR BCP: 124 2006年11月のカテゴリ: 最も良い現在の習慣
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).
IETFが信じる著作権(C)(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のExplicit Congestion Notification(電子証券取引ネットワーク)分野への交互の意味論のための多くの提案がありました。 このドキュメントは、交互の意味論を定義する際に電子証券取引ネットワーク分野と問題のいくつかについて議論して、定義された交互の意味論を理解していないルータを含むことができたインターネットでの安全な共存に要件を指定します。 このドキュメントはそのような交互の意味論のための1つの最近の提案の作者との議論の結果、発展しました。
Floyd Best Current Practice [Page 1] RFC 4774 Alternate Semantics for the ECN Field November 2006
フロイド最も良い現在の習慣[1ページ]RFC4774は分野2006年11月に電子証券取引ネットワークのために意味論を交替します。
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
1. 序論…2 2. 問題の概観…3 3. 交互の電子証券取引ネットワーク意味論の使用に合図します…4 3.1. 合図するのにDiffserv分野を使用します…5 4. 増加の展開の問題…6 4.1. オプション1: インターネットでの展開に危険…7 4.2. オプション2: 検証、そのRouters Understand Alternate…8 4.3. オプション3: 競争している交通との好意的な共存…8 5. 交互の電子証券取引ネットワーク意味論の評価…10 5.1. ルータからのフィードバックの検証…10 5.2. 競争している交通との共存…11 5.3. 縁から縁への意味論がある…交互の電子証券取引ネットワークのための提案12 5.4. パケットをカプセルに入れります…12 5.5. 交互の電子証券取引ネットワーク意味論の一般的評価…12 6. セキュリティ問題…12 7. 結論…13 8. 承認…13 9. 標準の参照…13 10. 有益な参照…13
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](Proposed Standardドキュメント)は、IPヘッダーで電子証券取引ネットワーク分野を定義して、電子証券取引ネットワーク分野としてcodepointsに意味論を指定します。 しかしながら、エンドノードはIPヘッダーのdiffserv分野で交互の意味論の電子証券取引ネットワーク分野、例えば、使用codepointsの使用を指定するかもしれません。
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].
多くの提案が電子証券取引ネットワークcodepointのための交互の意味論のためにIETFと研究団体にありました。 そのような提案の1つ[BCF05]は声や、ビデオ会議や、DiffServを流れるマルチメディアなどのリアルタイムの弾力性のない交通ネットワークのために交互の電子証券取引ネットワーク意味論を提案します。 この提案に、交互の電子証券取引ネットワーク意味論はおよそ2つのレベルの混雑が経路[BCF05]に沿ってなった情報を提供するでしょう。 別の研究提案[XSSK05]は低複雑さプロトコル、低い負荷政権の間、より急速に、低い負荷、高い負荷、およびトランスポート・プロトコルが増加できるオーバーロード(混雑)を示すのに電子証券取引ネットワーク分野で2ビットを使用するVariable-構造混雑Controlプロトコル(VCP)を提案します。 交互の電子証券取引ネットワーク意味論のための提案のいくつかが電子証券取引ネットワークが縁から縁への文脈で使用される時の間、ネットワーク領域の縁にゲートウェイの間にあります、例えば、入場コントロール[BESFC06]のためのプレ混雑通知のために。 交互の電子証券取引ネットワーク意味論のための他の提案は電子証券取引ネットワークウェブページ[電子証券取引ネットワーク]に記載されています。
Floyd Best Current Practice [Page 2] RFC 4774 Alternate Semantics for the ECN Field November 2006
フロイド最も良い現在の習慣[2ページ]RFC4774は分野2006年11月に電子証券取引ネットワークのために意味論を交替します。
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.
電子証券取引ネットワーク分野への複数の意味論の定義はホストとルータ実現の両方に重要な意味を持っているかもしれません。 インストールされたホストの巨大なベースとインターネット、および他のIPネットワークにおけるルータがあります、そして、これらをアップデートするのは、莫大で潜在的に高価な仕事です。 いくつかの既存の装置がソフトウェアの更新だけと性能における重要な退行なしで新しい電子証券取引ネットワーク意味論を支持できるかもしれません。 新しい意味論を支持できますが、ある他の設備は性能(些細であるのから壊滅的になるまで及ぶことができた)における退行でそうするかもしれません。 ある他の配備された設備は単にハードウェアアップグレードで新しい電子証券取引ネットワーク意味論を支持できるかもしれません。(いくつかの場合、それは、非常に広いスケールで配備するために法外に高価であるかもしれません)。 これらの理由で、難しいだろう、一般にどんな新しい電子証券取引ネットワーク意味論も配備するには重要な時かかるでしょう。 ルータはアップグレードさせるのが特に、難しい場合があります、時々頻繁に小さいルータをアップデートしないで、大きいルータが高性能を促進するために一般的に推進経路を専門にしたので。
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).
このドキュメントは、交互の意味論を指定する際に起こる専門的な問題のいくつかについて電子証券取引ネットワーク分野に説明して、世界での安全な共存のためにデフォルト電子証券取引ネットワーク意味論を使用することで要件を与えます(電子証券取引ネットワークを全く使用しないで)。
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.
このセクションで、私たちはネットワークの何らかの交通が交互の電子証券取引ネットワーク交通(すなわち、電子証券取引ネットワーク分野に交互の意味論を使用する交通)から成るなら起こる問題のいくつかについて議論します。 問題は以下を含んでいます: (1) ルータは、どのパケットと共にどの電子証券取引ネットワーク意味論を使用したらよいかをどう知っているか。 (2) いくつかのルータがデフォルト電子証券取引ネットワーク意味論だけを使用するか、または全く電子証券取引ネットワークを使用しないネットワークにおける増加の展開。 (3) 競争している交通が経路にある交互の電子証券取引ネットワーク交通の共存。 (4) そして、交互の電子証券取引ネットワーク意味論の一般的評価。
(1) The first issue concerns how routers know which ECN semantics to
use with which packets in the network:
(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?
接続は、パケットがどのように交互の電子証券取引ネットワーク意味論を使用しているのをルータに示しますか? 交互の電子証券取引ネットワーク意味論の仕様は、強健であって、明白ですか? まして、これは問題ですか?
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
例として、交互の電子証券取引ネットワーク意味論のための提案の大部分では、diffserv分野は、交互の電子証券取引ネットワーク意味論の使用を指定するのに使用されます。 このdiffserv codepointを理解しているすべてのルータがそれが交互の電子証券取引ネットワークを使用するのがわかりますか?
Floyd Best Current Practice [Page 3] RFC 4774 Alternate Semantics for the ECN Field November 2006
フロイド最も良い現在の習慣[3ページ]RFC4774は分野2006年11月に電子証券取引ネットワークのために意味論を交替します。
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?
意味論である、-- Diffservはルータにネットワークの中でDiffServ Code Point(DSCP)値を述べさせます。 交互の電子証券取引ネットワーク意味論へのこの効果は何ですか?
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刷はいくつかのルータがデフォルト電子証券取引ネットワーク意味論、および他のルータを使用するだけであるネットワークにおける増加の展開のものが全く電子証券取引ネットワークを使用しないかもしれないということです。 本書では、私たちは、分かっていないか、または交互の電子証券取引ネットワーク意味論を使用することを望んでいないルータについて言及するのに交互の電子証券取引ネットワーク意味論を理解しているルータ、および「古いルータ」への参照する「新しいルータ」という句を使用します。
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)また、競争している交通が経路にある状態で、古いルータの可能な存在は古いルータの存在がどう交互の電子証券取引ネットワーク交通の共存に影響するかに関する疑問を挙げます。
Issues (2) and (3) are discussed in Section 4 below.
以下のセクション4で問題(2)と(3)について議論します。
(4) A final issue is that of the general evaluation of the alternate
ECN semantics:
(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?
交互の電子証券取引ネットワーク交通はどれくらいよく働くか、そして、それは新しいルータと交互の電子証券取引ネットワーク意味論の使用の明白な仕様で「清潔な」環境における経路における競争している交通とどれくらいよく共存しますか?
These issues are discussed in Section 5.
セクション5でこれらの問題について議論します。
3. Signalling the Use of Alternate ECN Semantics
3. 交互の電子証券取引ネットワーク意味論の使用に合図します。
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) 接続は、パケットがどのように交互の電子証券取引ネットワーク意味論を使用しているのをルータに示しますか? 交互の電子証券取引ネットワーク意味論の仕様は、強健であって、明白ですか? まして、これは問題ですか?
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
このドキュメントの仮定は交互の意味論が電子証券取引ネットワーク分野と定義されるとき、diffserv分野のcodepointがこれらの交互の電子証券取引ネットワーク意味論の使用にルータに合図するのに使用されるということです。 電子証券取引ネットワーク分野への交互の意味論はルータに示すdiffserv分野のcodepointですが、すなわち、終わりのホストはセットします。
Floyd Best Current Practice [Page 4] RFC 4774 Alternate Semantics for the ECN Field November 2006
フロイド最も良い現在の習慣[4ページ]RFC4774は分野2006年11月に電子証券取引ネットワークのために意味論を交替します。
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.
使用されること。 このdiffserv codepointを理解しているルータは電子証券取引ネットワーク分野を解釈して、設定するのに交互の意味論を使用するのを知っているでしょう。 このdiffserv codepointを理解していない古い電子証券取引ネットワークできるルータが電子証券取引ネットワーク分野を解釈して、設定する際にデフォルト電子証券取引ネットワーク意味論を使用するでしょう。
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つの可能性は交互の電子証券取引ネットワーク意味論で1ホップあたり1つの同様の振舞いに合図するようにデフォルト電子証券取引ネットワーク意味論、および別々のdiffserv codepointとの1ホップあたり1つの振舞いに合図するのに1diffserv codepointを使用するだろうことです。 1ホップあたりのベストエフォート型待ち行列とスケジューリングの振舞いの使用に合図するのにdiffserv codepointを使用することになっていますが、交互の電子証券取引ネットワーク意味論で別の可能性はそうでしょう。 これらの問題の詳細な論議はこのドキュメントの範囲を超えています。
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.
私たちは、この議論が他の方法を使用する可能性を除かないことに注意します、バンドの外にメカニズムを含んでいて、交互の意味論の電子証券取引ネットワーク分野の使用に合図するために。 このドキュメントの残りにおける問題は交互の意味論の電子証券取引ネットワーク分野の使用に合図するのに使用される方法にかかわらず適用されます。
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.
私たちは、RFC3168で定義されたデフォルト電子証券取引ネットワーク意味論が電子証券取引ネットワーク分野への現在のデフォルト意味論であることに注意します、IPヘッダーのいかなる他の分野のコンテンツにかかわらず。 特に、デフォルト電子証券取引ネットワーク意味論は'000000'のcodepointとのベストエフォート型交通以上にdiffserv分野に申し込みます--デフォルト電子証券取引ネットワーク意味論は現在、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分野を使用する2つの方法があります。 1つの方法は、そのcodepointとの交互の電子証券取引ネットワーク意味論の使用を指定するように既存のdiffserv codepointを使用して、承認されたIETFの過程によるそのcodepointの現在の定義を変更することです。 2番目の道は、新しいdiffserv codepointを定義して、そのcodepointとの交互の電子証券取引ネットワーク意味論の使用を指定することです。 私たちは、これらの2つのメカニズムの1番目がこのdiffserv codepointで経路に沿ったいくつかのルータがdiffserv codepointを理解しますが、デフォルト電子証券取引ネットワーク意味論を使用する可能性を上げるか、または全く電子証券取引ネットワークを使用しないで、他のルータがこのdiffserv codepointがある交互の電子証券取引ネットワーク意味論を使用することに注意します。
Floyd Best Current Practice [Page 5] RFC 4774 Alternate Semantics for the ECN Field November 2006
フロイド最も良い現在の習慣[5ページ]RFC4774は分野2006年11月に電子証券取引ネットワークのために意味論を交替します。
4. Issues of Incremental Deployment
4. 増加の展開の問題
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) 古いルータの可能な存在はどのように交互の電子証券取引ネットワークの接続に関する実績に影響しますか?
(3) How does the possible presence of old routers affect the
coexistence of the alternate-ECN traffic with competing traffic
on the path?
(3) 競争している交通が経路にある状態で、古いルータの可能な存在はどのように交互の電子証券取引ネットワーク交通の共存に影響しますか?
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.
交互の意味論が電子証券取引ネットワーク分野と定義されるとき、経路に沿った交互の電子証券取引ネットワーク意味論を理解していない古いルータによって引き起こされた問題が全くないのを保証するのが必要です。
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つの起こりうる問題が交互の電子証券取引ネットワーク交通のための不十分な性能のものです。 経路に沿ったすべてのルータが交互の電子証券取引ネットワーク意味論を理解しているのは、交互の電子証券取引ネットワーク交通の性能に不可欠ですか? まして、経路に沿ったいくつかの古いルータが交互の電子証券取引ネットワーク意味論を理解していないとき、可能な結果は交互の電子証券取引ネットワーク交通自体への何ですか? これらの問題は交互の電子証券取引ネットワーク意味論のためのそれぞれの明確な提案の文脈で答えられなければなりません。
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番目の特定の問題は経路に沿った他の交通との可能な不公正競争のものです。 電子証券取引ネットワークを使用しない経路に沿って古いルータがあれば、その古いルータは、交互の電子証券取引ネットワーク交通からパケットを落として、交互の電子証券取引ネットワーク交通がその結果送付レートを低下させると予想するかもしれません。 交互の電子証券取引ネットワーク交通は混雑のしるしとしてパケット滴に応じますか?
|--------|
Alternate-ECN traffic ----> | | ---> CE-marked packet
| Old |
Non-ECN traffic ----------> | Router | ---> dropped packet
| |
RFC-3168 ECN traffic -----> | | ---> CE-marked packet
|--------|
|--------| 交互の電子証券取引ネットワーク交通---->|、| --->のCEが著しいパケット| 古い| 非電子証券取引ネットワーク交通---------->| ルータ| --->はパケットを落としました。| | RFC-3168 ECN交通----->|、| --->の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: 交互の電子証券取引ネットワーク交通、古いルータが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のようにRFC3168からデフォルト電子証券取引ネットワーク意味論だけを理解している経路に沿ってあると、どうなるでしょうか? 混雑の時代に、古いデフォルト電子証券取引ネットワークルータは、codepointsがIPヘッダーの電子証券取引ネットワーク分野に設定する電子証券取引ネットワークできるTransport(ECT)の1つと共にRFC3168で定義されるように交互の電子証券取引ネットワークパケットを見て、Congestion Experiencedを設定するかもしれません。(Ce)
Floyd Best Current Practice [Page 6] RFC 4774 Alternate Semantics for the ECN Field November 2006
フロイド最も良い現在の習慣[6ページ]RFC4774は分野2006年11月に電子証券取引ネットワークのために意味論を交替します。
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.
パケットを落とすことに代わる手段として電子証券取引ネットワーク分野のcodepoint。 この場合、ルータは、交互の電子証券取引ネットワークの接続が応じると予想するでしょう、輻輳制御で、パケットが落とされたならそうするように。 交互の電子証券取引ネットワーク交通が適切に古いルータで用意ができているCE codepointに応じないなら、これは古いルータに到着する集合交通を増加させるかもしれません、そのルータでパケットをマークしていてパケットが低下するレートの増加をもたらして、そのリンクにおける帯域幅を競争するもう片方の交通入らないようにしながら、より遠くに交互の電子証券取引ネットワーク交通をもたらして。
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:
基本的に、経路に沿ってシナリオを避けるための3つの可能性が経路に沿った古いルータの存在が不公平に他の交通と競争する交互の電子証券取引ネットワーク交通をもたらすところにあります:
Option 1: Alternate-ECN traffic is clearly understood as unsafe for deployment in the global Internet; or
オプション1: 交互の電子証券取引ネットワーク交通は世界的なインターネットでの展開に危険であるとして明確に理解されています。 または
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: すべての交互の電子証券取引ネットワーク交通が経路のすべてのルータが、分かって、この交通に交互の電子証券取引ネットワーク意味論を使用するのに同意することを確かめるために何らかのメカニズムを配備します。 または
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: 交互の電子証券取引ネットワーク意味論はベストエフォート型の、そして、他の交通に伴う交互の電子証券取引ネットワーク交通の公正で平和な共存を確実にするほどそのような方法で定義されます、交互の電子証券取引ネットワーク意味論を理解していない古いルータを含んでいる環境でさえ。
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.
上で指定された第1の選択は交互の電子証券取引ネットワーク交通が単に同封の環境に適することとして世界的なインターネットでの展開に危険として明確に理解されることです。 明確に、これは、交互の電子証券取引ネットワーク意味論を使用するパケットに、世界的なインターネットで解き放たれるのが危険であることを意味するでしょう。 この制限は、交互の電子証券取引ネットワーク交通が交互の意味論を理解していなかった同封の環境の外に古いルータを横断するのを防ぐでしょう。 メカニズムが交互の電子証券取引ネットワーク意味論が世界的なインターネットで放たれないのを保証するのに必要であるだろうかどうかに関してこのドキュメントはコメントしません。 このドキュメントもこのシナリオが標準化において許容できるとIETF共同体によって考えられるだろうという可能性を批評しません。
Floyd Best Current Practice [Page 7] RFC 4774 Alternate Semantics for the ECN Field November 2006
フロイド最も良い現在の習慣[7ページ]RFC4774は分野2006年11月に電子証券取引ネットワークのために意味論を交替します。
4.2. Option 2: Verification that Routers Understand the Alternate
Semantics
4.2. オプション2: 検証はそのRouters Understand Alternate Semanticsです。
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番目のオプションは交互の電子証券取引ネットワーク交通が経路に沿ったすべてのルータが交互の電子証券取引ネットワーク意味論のこの交通の使用を理解して、同意するのを確実にするためのメカニズムを含むことです。 例、IPがそれをゆだねるメカニズムが分野から成ることができたそのようなものとして、経路減少に沿ったすべてのルータが、それらであるならこの交通に伴う交互の電子証券取引ネットワーク意味論を使用するのに同意します。 (同様のメカニズムはクィック-始めに提案されます、経路に沿ったルータのすべてがクィック-スタートIP Option[QuickStart]を理解していることを確かめるために。) そのようなメカニズムを使用して、送付者は交互の電子証券取引ネットワーク意味論の使用が指定させられるパケットがこれらのパケットのために事実上、分かって、これらの交互の意味論を使用するのに同意するルータを横断するだけであるという手頃な保証を持つことができました。 しかしながら、ほとんどの既存のルータが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.
そのようなメカニズムはマルチ経路ルーティング、ルーティングおよびがあるとき経路か接続が使用中である間の経路に沿った構成変更があるとき強健であるべきです。 このオプションが使用されているなら、特に、接続は、交互の電子証券取引ネットワーク意味論を理解するために経路に沿ったすべてのルータが続けている経路の振舞い、そして/または、周期的なモニターで変化のためのモニターの何らかのフォームを入れるかもしれません。
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番目のオプションは交互の電子証券取引ネットワーク意味論が交互の意味論を使用する交通が経路のインターネットに安全にデフォルト電子証券取引ネットワーク意味論だけを使用する1つ以上の古いルータに共存するように定義されることです。 このシナリオでは、接続送付交互の電子証券取引ネットワーク交通は適切にCEパケットに応じなければならないでしょう。(電子証券取引ネットワークのcodepoint「11インチ) 受信機で受け取られていていて、使用しているa conformant混雑操舵応答」があるパケット。 また、うまくいけば、接続送付交互の電子証券取引ネットワーク交通は適切に低下しているパケットに応じるでしょう(電子証券取引ネットワークを使用しないルータからの混雑指示であるかもしれません)。
RFC 3168 defines the default ECN semantics as follows:
RFC3168は以下のデフォルト電子証券取引ネットワーク意味論を定義します:
"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
「単一のCEパケットの電子証券取引ネットワークできる輸送による領収書では、エンドシステムで従われた輻輳制御アルゴリズムは*シングル*への輻輳制御応答がパケットを落としたのと本質的には同じでなければなりません。」 例えば、電子証券取引ネットワークできるTCPに関して、ソースTCPはそうです。
Floyd Best Current Practice [Page 8] RFC 4774 Alternate Semantics for the ECN Field November 2006
フロイド最も良い現在の習慣[8ページ]RFC4774は分野2006年11月に電子証券取引ネットワークのために意味論を交替します。
required to halve its congestion window for any window of data containing either a packet drop or an ECN indication."
「パケット滴か電子証券取引ネットワークの指示のどちらかを含むデータのどんな窓にも混雑ウィンドウを半分にするのが必要です。」
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で標準化されている唯一のconformant混雑制御機構が、輻輳制御(例えば、SCTP[RFC2960]、CCID-2とDCCP[RFC4340][RFC4341])、TCP好意的なRate Control(TFRC)[RFC3448]、およびTFRCのような輻輳制御があるプロトコル(例えば、CCID-3[RFC4342]を使用するDCCP)のようにTCP[RFC2581]とTCPを使用するプロトコルです。 TCPは、Additive-増加Multiplicative-減少輻輳制御を使用して、混雑ウィンドウを半分にすることによって、単一のパケットの損失か電子証券取引ネットワーク-マークに応じます。 対照的に、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.
それで、交互の電子証券取引ネットワーク交通が交互の電子証券取引ネットワーク意味論(そして、したがって、デフォルト電子証券取引ネットワーク意味論を使用しているかもしれない)を理解していない古いルータを通して経路で適切に他の交通と競争するという要件は何ですか? 交互の電子証券取引ネットワーク意味論を使用する交通とデフォルト電子証券取引ネットワーク意味論を使用するルータとの関心の互換性の下における1番目と2番目の要件。
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.
パケットが「ネットワークにおける11インチ、この印は受信機へのパケットの道で変え(受信機に達する前にパケットが落とされない場合)にされなく」電子証券取引ネットワークcodepointなマークされるなら、デフォルト電子証券取引ネットワークを使用するルータとの互換性のための最初の要件はそれです。 この要件が、デフォルト電子証券取引ネットワークルータからの混雑指摘が輸送受信機に行くのを保証するのに必要です。
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.
デフォルト電子証券取引ネットワークを使用するルータとの互換性のための2番目の要件はエンドノードが電子証券取引ネットワークcodepoint「IETF- conformant輻輳制御を使用することで流れに好意的な方法で11インチ」でマークされるパケットに応じるということです。 この要件が必要である、「11インチで著しいパケットはデフォルト電子証券取引ネットワーク意味論だけを理解している混雑しているルータから来たかもしれません、そして、それはエンドノードが適切に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
追加要件は、交互の電子証券取引ネットワーク意味論を使用することでデフォルト電子証券取引ネットワーク意味論を使用する交通とルータとの互換性に関係があります。 デフォルト電子証券取引ネットワーク意味論を使用するdiffserv codepointが交互の電子証券取引ネットワーク意味論、および交通を使用するために再定義されるなら、この状況は起こるかもしれません。
Floyd Best Current Practice [Page 9] RFC 4774 Alternate Semantics for the ECN Field November 2006
フロイド最も良い現在の習慣[9ページ]RFC4774は分野2006年11月に電子証券取引ネットワークのために意味論を交替します。
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.
「古い」ソースから、「新しい」ルータを横断します。 ルータが、交互の意味論を使用することで(例えば、パケットが、あるdiffserv codepointを使用していて、そのdiffserv codepointがあるすべてのパケットが電子証券取引ネットワーク分野に交互の意味論を使用するので)パケットが送付者から来ているのを「知っている」なら、以下の要件は必要ではありません、そして、交互の意味論のための規則は適用されます。
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].
*デフォルト意味論を使用して、*がそうすることができたパケットが電子証券取引ネットワークcodepointでマークされるならデフォルトを使用するエンドノード電子証券取引ネットワークとの互換性のための要件がそれである、「何0インチも、このマークを変えてはいけない、「1インチ、「10インチ、または「ネットワークにおける11インチ。」 これは、パケットが電子証券取引ネットワークできるとして不当にデフォルト電子証券取引ネットワークルータ川下に表されるのを防ぎます。 同様に、*デフォルト意味論を使用して、*がそうすることができたパケットがaであるなら電子証券取引ネットワークcodepointでマークされる、「1インチ、次に、このcodepointに変えるべきでない、「ネットワークにおける10インチ、(a、「10インチのcodepointを変えるべきでない、「1インチ)、」 この要件が、電子証券取引ネットワーク一回だけ[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.
以前に検討したことであるが、低下したか電子証券取引ネットワーク著しい状態でデフォルトとしているパケットへの現在のconformant混雑操舵応答はTCPとTCPのような輻輳制御、およびTFRC(TCP好意的なRate Control)から成ります。 長期の送付レートがレートが[RFC3714]であると低下するか、またはマークする同じパケットを経験するTCP接続のものであるだろうより高いなら、しばらく、RFC3714で考えられますが、標準化過程文書で標準化されなかった別の可能な応答は単に交互の電子証券取引ネットワークの接続を終えるものです。 私たちは、CEが著しいパケットへのそのような混雑操舵応答の使用が損失率を測定して、トランスミッションを止めるために時定数の仕様を必要として、パケットサイズの問題の考慮を必要とすることに注意します。
5. Evaluation of the Alternate ECN Semantics
5. 交互の電子証券取引ネットワーク意味論の評価
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) 交互の電子証券取引ネットワーク交通はどれくらいよく働くか、そして、それは新しいルータと交互の電子証券取引ネットワーク意味論の使用の明白な仕様で「清潔な」環境における経路における競争している交通とどれくらいよく共存しますか?
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
交互の電子証券取引ネットワーク意味論を評価することにおける1つの問題が、メカニズムが輸送受信機から輸送送付者まで嘘をつくことをがっかりさせるのが関係があります。 多くの場合、送付者は正しく交互の電子証券取引ネットワーク意味論を使用するのに関心を持っているサーバです。
Floyd Best Current Practice [Page 10] RFC 4774 Alternate Semantics for the ECN Field November 2006
フロイド最も良い現在の習慣[10ページ]RFC4774は分野2006年11月に電子証券取引ネットワークのために意味論を交替します。
receiver has more incentive to lie about the congestion experienced along the path.
受信機には、経路に沿って経験された混雑に関して嘘をつくより多くの誘因があります。
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.
デフォルト電子証券取引ネットワーク意味論では、2 4電子証券取引ネットワークcodepointsが電子証券取引ネットワークできる(0)と電子証券取引ネットワークできる(1)に使用されます。 実際に受信機で無印でパケットを受け取りました。2の使用がcodepointsする、電子証券取引ネットワークできます、1、許可証の代わりに特に、送付者がそうすることができるという受信機のレポートについて確かめるデータ送付者は、受信機がそれぞれの無印のパケットが容認された電子証券取引ネットワークできる(0)か電子証券取引ネットワークできる(1)であったことにかかわらず送付者に報告すると指定します、RFC3540[RFC3540]で議論するように。 電子証券取引ネットワークできる(0)と電子証券取引ネットワークできる(1)のこの使用は、他の電子証券取引ネットワークcodepointsの意味論から独立していて、使用できました、望まれているなら、他のcodepointsのための交互の意味論で。
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.
電子証券取引ネットワークcodepointのための交互の意味論であるなら、容認された電子証券取引ネットワークcodepointをデータ送付者に報告しながら、電子証券取引ネットワークできて、次に、それらの意味論を使用している接続が確かめる能力を失ったのを示す2の別々のcodepointsのデータ受信装置が正確にそうである使用を含めないでください。 この場合、交互の電子証券取引ネットワーク枠組みがデータ受信装置が適切にフィードバックを送付者に報告しているのを確実にするための交互のメカニズムを含むのが必要であるかもしれません。 1つの可能性として、エンドノードが適切に著しいパケットに応じているのを保証するのにルータにpolicersを使用できました。
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番目の一般答弁は交互の電子証券取引ネットワーク交通の共存に関係があります、すべてのルータが分かって、使用を指定する交通に交互の電子証券取引ネットワーク意味論を使用しても構わないと思っている汚染されていない環境で。
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].
交互の電子証券取引ネットワーク意味論を使用する交通がベストエフォート型交通であるなら、経路[RFC2914]に沿ってTCPと他の交通で公正な競争の一般的な要件を受けることがあります。
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.
交互の電子証券取引ネットワーク意味論を使用する交通がdiffserv交通であるなら、要件はそのクラスのdiffserv交通のための総合的なガイドラインによって治められます。 それは要件を指定するためにこのドキュメントの範囲を超えています、もしあれば、リンクの上に他の交通があるdiffserv交通の共存のために。 これはdiffserv codepoint自身の仕様に記述されるべきです。
Floyd Best Current Practice [Page 11] RFC 4774 Alternate Semantics for the ECN Field November 2006
フロイド最も良い現在の習慣[11ページ]RFC4774は分野2006年11月に電子証券取引ネットワークのために意味論を交替します。
5.3. Proposals for Alternate ECN with Edge-to-Edge Semantics
5.3. 縁から縁への意味論がある交互の電子証券取引ネットワークのための提案
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は終わりまでの終わりのトランスポート・プロトコルでデフォルト電子証券取引ネットワーク意味論の使用を指定します、「単一のCEパケットの電子証券取引ネットワークできる輸送による領収書では、エンドシステムで従われた輻輳制御アルゴリズムは*シングル*への輻輳制御応答がパケットを落としたのと本質的には同じでなければならない」という要件([RFC3168]、セクション5)で。 対照的に、交互の電子証券取引ネットワーク意味論のための提案のいくつかが縁への縁の文脈で使用される電子証券取引ネットワークのためにネットワーク領域例えば、[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.
交互の電子証券取引ネットワークが縁から縁への意味論で定義されるとき、この定義は、接続と共に他の電子証券取引ネットワークの意味論の終わりから終わりを使用することで意味論がそうしない縁から縁とのその闘争を確実にする必要があります。 闘争を避ける1つの方法が斜めに進ませる縁の電子証券取引ネットワークが他の電子証券取引ネットワーク意味論(標準の、または、そうでない)の終わりから終わりを使用している接続に使用されないのを保証するために何らかのメカニズムを含んでいるという縁から縁への電子証券取引ネットワークの提案のためのものでしょう。 交互に、縁から縁への意味論を定義できたので、彼らは他の電子証券取引ネットワークの意味論の終わりから終わりを使用することで接続と衝突しません。
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はIPにIPsecとIPを含む電子証券取引ネットワークとIPトンネルとの相互作用の大規模な議論をします。 交互の電子証券取引ネットワーク意味論のための提案はデフォルト電子証券取引ネットワークと異なってIPトンネルと対話するかもしれません。 その結果、交互の電子証券取引ネットワーク意味論のための提案は明らかにIPトンネルとの相互作用の問題を考えなければなりません。
5.5. A General Evaluation of the Alternate ECN Semantics
5.5. 交互の電子証券取引ネットワーク意味論の一般的評価
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番目の一般答弁は提案された交互の電子証券取引ネットワーク意味論の一般的な長所の評価に関係があります。 一方、それは、交互の電子証券取引ネットワーク意味論の一般的評価のための要件を指定するためにこのドキュメントの範囲を超えているでしょう。
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.
このドキュメントは、インターネットプロトコルのためにどんな新しいメカニズムも提案しないで、またしたがって、どんな新しいセキュリティ問題も紹介しません。
Floyd Best Current Practice [Page 12] RFC 4774 Alternate Semantics for the ECN Field November 2006
フロイド最も良い現在の習慣[12ページ]RFC4774は分野2006年11月に電子証券取引ネットワークのために意味論を交替します。
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ヘッダーの電子証券取引ネットワーク分野と考えられるために問題のいくつかについて議論しました。
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.
交互の電子証券取引ネットワーク意味論の仕様は明確にそれらがどう本書では提起された問題を記述するかを述べなければなりません、特にセクション2で議論した問題。 さらに、交互の電子証券取引ネットワーク意味論のための仕様は競争している交通との共存のためにセクション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環境における電子証券取引ネットワーク分野の交互の使用のための彼らの提案でのユゼフBabiarz、クォック・Hoチェン、およびビクタFiroiuとの会話に一部基づいています。 ドキュメントが始めの記述される必要がある潜在的問題について論ずるセクションを含むことを勧めるフィードバックのためにフランソアLe Faucheurをありがとうございます。 また、マーク・オールマン、フレッド・ベイカー、デヴィッドBlack、ゴーリー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.
[RFC3168] Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168(2001年9月)。
10. Informative References
10. 有益な参照
[BCF05] Babiarz, J., Chan, K., and V. Firoiu, "Congestion
Notification Process for Real-Time Traffic", Work in
Progress, July 2005.
J.、チェン、K.、およびV.Firoiu、「リアルタイムの交通のための混雑通知の過程」という[BCF05]Babiarzは進歩、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.、他、「Pre-混雑Notificationのための縁から縁へのDeployment Model:」 「DiffServ領域の入場コントロール」、処理中の作業、2006年6月。
[ECN] ECN Web Page, URL <www.icir.org/floyd/ecn.html>.
[電子証券取引ネットワーク]電子証券取引ネットワークウェブページ、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.
「TCPとIPのための迅速な始め」という[QuickStart]S.フロイド、M.オールマン、A.ジャイナ教徒、およびP.Sarolahtiは進行中(2006年10月)で働いています。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソン、V.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
Floyd Best Current Practice [Page 13] RFC 4774 Alternate Semantics for the ECN Field November 2006
フロイド最も良い現在の習慣[13ページ]RFC4774は分野2006年11月に電子証券取引ネットワークのために意味論を交替します。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、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.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「流れの制御伝動プロトコル」、RFC2960(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)を制御します」。 「プロトコル仕様」、RFC3448、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.イーリー、「一回だけで合図する体力を要している明白な混雑通知(電子証券取引ネットワーク)」、RFC3540、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心配はインターネットの音声トラヒックに制御します」、RFC3714、2004年3月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March
2006.
[RFC4340] コーラー、E.、ハンドレー、M.、およびS.フロイド、「データグラム混雑制御プロトコル(DCCP)」、RFC4340、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)輻輳制御ID2のために以下の輪郭を描きます」。 「TCPのような輻輳制御」、RFC4341、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)輻輳制御ID3のために以下の輪郭を描きます」。 「TCPに優しい速度制御(TFRC)」、2006年3月のRFC4342。
[XSSK05] Y. Xia, L. Subramanian, I. Stoica, and S. Kalyanaraman,
One More Bit Is Enough, SIGCOMM 2005, September 2005.
[XSSK05]Y.シャー、L.Subramanian、I.ストイカ、およびS.Kalyanaraman、もうひとつのビットが十分なSIGCOMM2005、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 メールしてください: floyd@icir.org URL: http://www.icir.org/floyd/
Floyd Best Current Practice [Page 14] RFC 4774 Alternate Semantics for the ECN Field November 2006
フロイド最も良い現在の習慣[14ページ]RFC4774は分野2006年11月に電子証券取引ネットワークのために意味論を交替します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Floyd Best Current Practice [Page 15]
フロイドBest現在の習慣[15ページ]
一覧
スポンサーリンク
