RFC2481 日本語訳
2481 A Proposal to add Explicit Congestion Notification (ECN) to IP.K. Ramakrishnan, S. Floyd. January 1999. (Format: TXT=64559 bytes) (Obsoleted by RFC3168) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Ramakrishnan
Request for Comments: 2481 AT&T Labs Research
Category: Experimental S. Floyd
LBNL
January 1999
Ramakrishnanがコメントのために要求するワーキンググループK.をネットワークでつないでください: 2481のAT&T研究室がカテゴリについて研究します: 実験的なS.フロイドLBNL1999年1月
A Proposal to add Explicit Congestion Notification (ECN) to IP
Explicit Congestion Notification(電子証券取引ネットワーク)をIPに追加するProposal
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. TCP is currently the dominant transport protocol used in the Internet. We begin by describing TCP's use of packet drops as an indication of congestion. Next we argue that with the addition of active queue management (e.g., RED) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion. Routers could instead set a Congestion Experienced (CE) bit in the packet header of packets from ECN-capable transport protocols. We describe when the CE bit would be set in the routers, and describe what modifications would be needed to TCP to make it ECN-capable. Modifications to other transport protocols (e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols are developed and advance through the standards process.
この注意は電子証券取引ネットワーク(明白なCongestion Notification)の提案された追加をIPに説明します。 現在、TCPはインターネットで使用される優位なトランスポート・プロトコルです。 私たちは、パケット滴のTCPの使用を混雑のしるしとして記述することによって、始めます。 次に、私たちは、活発な待ち行列管理(例えば、RED)のインターネット基盤への追加で、待ち行列があふれて、ルータがもう混雑のしるしとしてパケット滴に制限されないと主張します。そこでは、ルータが混雑を検出します。 ルータは代わりに電子証券取引ネットワークできるトランスポート・プロトコルからパケットのパケットのヘッダーにCongestion Experienced(CE)ビットをはめ込むかもしれません。 私たちは、CEビットがいつルータで設定されるかを説明して、どんな変更がそれを電子証券取引ネットワークできるようにするのにTCPに必要であるかを説明します。 他のトランスポート・プロトコル(例えば、頼り無いユニキャストかマルチキャスト、信頼できるマルチキャスト、他の信頼できるユニキャストトランスポート・プロトコル)への変更は、みなされて、それらのプロトコルが開発されているということであり、標準化過程で進むことができるでしょう。
1. Conventions and Acronyms
1. コンベンションと頭文字語
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [B97].
キーワードが解釈しなければならない、本書では現れるとき、[B97]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
Ramakrishnan & Floyd Experimental [Page 1] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[1ページ]RFC2481電子証券取引ネットワーク
2. Introduction
2. 序論
TCP's congestion control and avoidance algorithms are based on the notion that the network is a black-box [Jacobson88, Jacobson90]. The network's state of congestion or otherwise is determined by end- systems probing for the network state, by gradually increasing the load on the network (by increasing the window of packets that are outstanding in the network) until the network becomes congested and a packet is lost. Treating the network as a "black-box" and treating loss as an indication of congestion in the network is appropriate for pure best-effort data carried by TCP which has little or no sensitivity to delay or loss of individual packets. In addition, TCP's congestion management algorithms have techniques built-in (such as Fast Retransmit and Fast Recovery) to minimize the impact of losses from a throughput perspective.
TCPの輻輳制御と回避アルゴリズムはネットワークがブラックボックス[Jacobson88、Jacobson90]であるという概念に基づいています。 ネットワークの混雑かそうでないことの状態はネットワーク状態に調べられるエンドシステムで決定します、ネットワークが混雑するようになって、パケットが無くなるまでネットワーク(ネットワークに傑出しているパケットの窓を増加させるのによる)で負荷を徐々に増加させることによって。 まず個々のパケットの遅れか損失に感度を持っていないTCPによって運ばれた純粋なベストエフォート型データに、「ブラックボックス」としてネットワークを扱って、ネットワークにおける、混雑のしるしとして損失を扱うのは適切です。 さらに、TCPのふくそう管理アルゴリズムで、テクニックはスループット見解からの損失の衝撃を最小にするために内蔵に(Fast RetransmitやFast Recoveryなどの)なります。
However, these mechanisms are not intended to help applications that are in fact sensitive to the delay or loss of one or more individual packets. Interactive traffic such as telnet, web-browsing, and transfer of audio and video data can be sensitive to packet losses (using an unreliable data delivery transport such as UDP) or to the increased latency of the packet caused by the need to retransmit the packet after a loss (for reliable data delivery such as TCP).
しかしながら、これらのメカニズムが事実上1つ以上の個々のパケットの遅れか損失に敏感なアプリケーションを助けることを意図しません。 損失(TCPなどの確実な資料配送のための)の後に必要性でパケットを再送したオーディオとビデオ・データのtelnet、ウェブ閲覧、および転送がパケット損失に敏感であることができるか(UDPなどの頼り無いデータ配送輸送を使用して)、パケットの増加する潜在へのそのような対話的な通信。
Since TCP determines the appropriate congestion window to use by gradually increasing the window size until it experiences a dropped packet, this causes the queues at the bottleneck router to build up. With most packet drop policies at the router that are not sensitive to the load placed by each individual flow, this means that some of the packets of latency-sensitive flows are going to be dropped. Active queue management mechanisms detect congestion before the queue overflows, and provide an indication of this congestion to the end nodes. The advantages of active queue management are discussed in RFC 2309 [RFC2309]. Active queue management avoids some of the bad properties of dropping on queue overflow, including the undesirable synchronization of loss across multiple flows. More importantly, active queue management means that transport protocols with congestion control (e.g., TCP) do not have to rely on buffer overflow as the only indication of congestion. This can reduce unnecessary queueing delay for all traffic sharing that queue.
TCPが、ウィンドウサイズを徐々にそれまで増加させることによって使用するのが適切である混雑ウィンドウが低下しているパケットを経験することを決定するので、これで、ボトルネックルータにおける待ち行列は増します。 ルータにおけるほとんどのそれぞれの個々の流れによって置かれた負荷に敏感でないパケット低下方針で、これは、潜在敏感な流れのいくつかのパケットが落とされることを意味します。 アクティブな待ち行列管理メカニズムは、待ち行列があふれる前に混雑を検出して、この混雑のしるしをエンドノードに供給します。 RFC2309[RFC2309]で活発な待ち行列管理の利点について議論します。 活発な待ち行列管理は待ち行列オーバーフローのときに低下するいくつかの悪い特性を避けます、複数の流れの向こう側に損失の望ましくない同期を含んでいて。 より重要に、活発な待ち行列管理は、輻輳制御(例えば、TCP)があるトランスポート・プロトコルが混雑の唯一のしるしとしてバッファオーバーフローに依存する必要はないことを意味します。 これはその待ち行列を共有するすべての交通に不要な待ち行列遅れを減少させることができます。
Active queue management mechanisms may use one of several methods for indicating congestion to end-nodes. One is to use packet drops, as is currently done. However, active queue management allows the router to separate policies of queueing or dropping packets from the policies for indicating congestion. Thus, active queue management allows
アクティブな待ち行列管理メカニズムは、混雑をエンドノードに示すのにいくつかの方法の1つを使用するかもしれません。 1つは現在しているようにパケット滴を使用することになっています。 しかしながら、活発な待ち行列管理で、ルータは混雑を示すための方針と待ち行列かパケットを落とす方針を切り離すことができます。 その結果経営者側が許容する活発な待ち行列
Ramakrishnan & Floyd Experimental [Page 2] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[2ページ]RFC2481電子証券取引ネットワーク
routers to use the Congestion Experienced (CE) bit in a packet header as an indication of congestion, instead of relying solely on packet drops.
唯一パケット滴を当てにすることの代わりに混雑のしるしとしてパケットのヘッダーでCongestion Experienced(CE)ビットを使用するルータ。
3. Assumptions and General Principles
3. 仮定と綱領
In this section, we describe some of the important design principles and assumptions that guided the design choices in this proposal.
このセクションで、私たちはこの提案におけるデザイン選択を誘導した重要な設計原理といくつかの仮定について説明します。
(1) Congestion may persist over different time-scales. The time
scales that we are concerned with are congestion events that may
last longer than a round-trip time.
(2) The number of packets in an individual flow (e.g., TCP connection
or an exchange using UDP) may range from a small number of
packets to quite a large number. We are interested in managing
the congestion caused by flows that send enough packets so that
they are still active when network feedback reaches them.
(3) New mechanisms for congestion control and avoidance need to co-
exist and cooperate with existing mechanisms for congestion
control. In particular, new mechanisms have to co-exist with
TCP's current methods of adapting to congestion and with routers'
current practice of dropping packets in periods of congestion.
(4) Because ECN is likely to be adopted gradually, accommodating
migration is essential. Some routers may still only drop packets
to indicate congestion, and some end-systems may not be ECN-
capable. The most viable strategy is one that accommodates
incremental deployment without having to resort to "islands" of
ECN-capable and non-ECN-capable environments.
(5) Asymmetric routing is likely to be a normal occurrence in the
Internet. The path (sequence of links and routers) followed by
data packets may be different from the path followed by the
acknowledgment packets in the reverse direction.
(6) Many routers process the "regular" headers in IP packets more
efficiently than they process the header information in IP
options. This suggests keeping congestion experienced
information in the regular headers of an IP packet.
(7) It must be recognized that not all end-systems will cooperate in
mechanisms for congestion control. However, new mechanisms
shouldn't make it easier for TCP applications to disable TCP
congestion control. The benefit of lying about participating in
new mechanisms such as ECN-capability should be small.
(1) 混雑は異なったタイムスケールの上持続するかもしれません。 私たちが関するタイムスケールは往復の時間より長い間続くかもしれない混雑出来事です。 (2) 個々の流れ(例えば、TCP接続かUDPを使用する交換)における、パケットの数は少ない数のパケットからかなり大きい数まで及ぶかもしれません。 ネットワークフィードバックがそれらに達するとき、彼らがまだアクティブであるように十分なパケットを送る流れによって引き起こされた混雑を管理したいと思います。 (3) 輻輳制御と回避のための新しいメカニズムは、共同存在して、輻輳制御のために既存のメカニズムに協力する必要があります。 特定の、そして、新しいメカニズムでは、混雑の一区切りはTCPの混雑に順応する現在の方法とルータのパケットをちょっと立ち寄らせる現在の習慣に共存しなければなりません。 (4) 電子証券取引ネットワークが徐々に採用されそうであるので、親切な移動は不可欠です。 いくつかのルータが混雑を示すためにまだパケットを落としているだけであるかもしれません、そして、いくつかのエンドシステムはできる電子証券取引ネットワークでないかもしれません。 最も実行可能な戦略は、電子証券取引ネットワークできることの「島」によく行く必要はなくて増加の展開を収容するものとできる非電子証券取引ネットワーク環境です。 (5) 非対称のルーティングはインターネットでの通常の発生である傾向があります。 データ・パケットがあとに続いた経路(リンクとルータの系列)は確認応答パケットが反対の方向にあとに続いた経路と異なっているかもしれません。 (6) 多くのルータがIPパケットでIPオプションにおけるヘッダー情報を処理するより効率的に「通常」のヘッダーを処理します。 これは、IPパケットのレギュラーのヘッダーに混雑が経験豊富な情報であることを保つのを示します。 (7) すべてのエンドシステムが輻輳制御のためにメカニズムに協力するというわけではないと認めなければなりません。 しかしながら、新しいメカニズムで、TCPアプリケーションがTCP輻輳制御を損傷するのが、より簡単になるはずがありません。 電子証券取引ネットワーク-能力などの新しいメカニズムに参加しながらころがっている利益はわずかであるべきです。
4. Random Early Detection (RED)
4. 無作為の早期発見(赤)
Random Early Detection (RED) is a mechanism for active queue management that has been proposed to detect incipient congestion [FJ93], and is currently being deployed in the Internet backbone [RFC2309]. Although RED is meant to be a general mechanism using one
無作為のEarly Detection(RED)は始まりの混雑[FJ93]を検出するために提案されて、現在インターネットの基幹[RFC2309]で配備されている活発な待ち行列管理のためのメカニズムです。 REDは一般的機構であることが1つを使用することで意味されますが
Ramakrishnan & Floyd Experimental [Page 3] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[3ページ]RFC2481電子証券取引ネットワーク
of several alternatives for congestion indication, in the current environment of the Internet RED is restricted to using packet drops as a mechanism for congestion indication. RED drops packets based on the average queue length exceeding a threshold, rather than only when the queue overflows. However, when RED drops packets before the queue actually overflows, RED is not forced by memory limitations to discard the packet.
REDが混雑指示にメカニズムとしてパケット滴を使用するのに制限されるというインターネットの現在の環境における混雑指示のためのいくつかの選択肢について。 パケットが基礎づけたRED低下は平均して待ち行列があふれる時だけよりむしろ敷居を超えている長さを列に並ばせます。 しかしながら、待ち行列が実際にあふれる前にREDがパケットを落とすとき、REDはメモリ制限でやむを得ずパケットを捨てません。
RED could set a Congestion Experienced (CE) bit in the packet header instead of dropping the packet, if such a bit was provided in the IP header and understood by the transport protocol. The use of the CE bit would allow the receiver(s) to receive the packet, avoiding the potential for excessive delays due to retransmissions after packet losses. We use the term 'CE packet' to denote a packet that has the CE bit set.
REDはトランスポート・プロトコルでそのようなものが少し、低下したならパケットを落とすことの代わりにパケットのヘッダーにIPヘッダーに供給していた状態でCongestion Experienced(CE)ビットをはめ込むことができて、分かりました。 受信機はCEビットの使用でパケットを受けることができるでしょう、パケット損失の後に「再-トランスミッション」のため過度の遅れの可能性を避けて。 私たちは、CEビットを設定するパケットを指示するのに'CEパケット'という用語を使用します。
5. Explicit Congestion Notification in IP
5. IPの明白な混雑通知
We propose that the Internet provide a congestion indication for incipient congestion (as in RED and earlier work [RJ90]) where the notification can sometimes be through marking packets rather than dropping them. This would require an ECN field in the IP header with two bits. The ECN-Capable Transport (ECT) bit would be set by the data sender to indicate that the end-points of the transport protocol are ECN-capable. The CE bit would be set by the router to indicate congestion to the end nodes. Routers that have a packet arriving at a full queue would drop the packet, just as they do now.
私たちは、インターネットが始まりの混雑(REDと以前の仕事[RJ90]のように)のための混雑指示を通知がそれらを落とすよりむしろパケットをマークすることで時々あることができるところに提供するよう提案します。 これは2ビットでIPヘッダーの電子証券取引ネットワーク分野を必要とするでしょう。 電子証券取引ネットワークできるTransport(ECT)ビットが、トランスポート・プロトコルのエンドポイントが電子証券取引ネットワークできるのを示すようにデータ送付者によって設定されるでしょう。 ルータで、CEビットが混雑をエンドノードに示すように設定されるでしょう。 パケットが完全な待ち行列に到達するルータはちょうど現在するようにパケットを落とすでしょう。
Bits 6 and 7 in the IPv4 TOS octet are designated as the ECN field. Bit 6 is designated as the ECT bit, and bit 7 is designated as the CE bit. The IPv4 TOS octet corresponds to the Traffic Class octet in IPv6. The definitions for the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet are intended to be superseded by the DS (Differentiated Services) Field [DIFFSERV]. Bits 6 and 7 are listed in [DIFFSERV] as Currently Unused. Section 19 gives a brief history of the TOS octet.
IPv4 TOS八重奏におけるビット6と7は電子証券取引ネットワーク分野として指定されます。 ECTが噛み付いたので、ビット6は指定されます、そして、CEが噛み付いたので、ビット7は指定されます。 IPv4 TOS八重奏はIPv6のTraffic Class八重奏に対応しています。 DS(Servicesを微分する)分野[DIFFSERV]によってIPv4 TOS八重奏[RFC791]とIPv6 Traffic Class八重奏のための定義が取って代わられることを意図します。 ビット6と7はCurrently Unusedとして[DIFFSERV]に記載されています。 セクション19はTOS八重奏に関する小史を与えます。
Because of the unstable history of the TOS octet, the use of the ECN field as specified in this document cannot be guaranteed to be backwards compatible with all past uses of these two bits. The potential dangers of this lack of backwards compatibility are discussed in Section 19.
TOS八重奏の不安定な歴史のために、後方にこれらの2ビットの過去のすべての用途と互換性があった状態であるように本書では指定されるとしての電子証券取引ネットワーク分野の使用を保証できません。 この不足という後方にでは、セクション19で互換性について議論するという潜在的危険。
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
単一のCEパケットの電子証券取引ネットワークできる輸送による領収書では、エンドシステムで従われた輻輳制御アルゴリズムは*シングル*への輻輳制御応答がパケットを落としたのと本質的には同じでなければなりません。 例えば、電子証券取引ネットワークできるTCPに関して、ソースTCPはデータのどんな窓にも混雑ウィンドウを半分にしなければなりません。
Ramakrishnan & Floyd Experimental [Page 4] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[4ページ]RFC2481電子証券取引ネットワーク
containing either a packet drop or an ECN indication. However, we would like to point out some notable exceptions in the reaction of the source TCP, related to following the shorter-time-scale details of particular implementations of TCP. For TCP's response to an ECN indication, we do not recommend such behavior as the slow-start of Tahoe TCP in response to a packet drop, or Reno TCP's wait of roughly half a round-trip time during Fast Recovery.
パケット滴か電子証券取引ネットワークの指示のどちらかを含んでいます。 しかしながら、TCPの特定の実現の、より短いタイムスケールの詳細に従うと関連するソースTCPの反応でいくつかの注目に値する例外を指摘したいと思います。 電子証券取引ネットワークの指示へのTCPの応答のために、私たちはパケット滴に対応したタホTCPの遅れた出発、またはリノTCPのFast Recoveryの間のおよそ半分のa往復の時間の待ちのような振舞いを推薦しません。
One reason for requiring that the congestion-control response to the CE packet be essentially the same as the response to a dropped packet is to accommodate the incremental deployment of ECN in both end- systems and in routers. Some routers may drop ECN-Capable packets (e.g., using the same RED policies for congestion detection) while other routers set the CE bit, for equivalent levels of congestion. Similarly, a router might drop a non-ECN-Capable packet but set the CE bit in an ECN-Capable packet, for equivalent levels of congestion. Different congestion control responses to a CE bit indication and to a packet drop could result in unfair treatment for different flows.
CEパケットへの輻輳制御応答が低下しているパケットへの応答と本質的には同じであることが必要であることの1つの理由は両方のエンドシステムとルータにおける、電子証券取引ネットワークの増加の展開を収容することです。 他のルータがCEビットを設定している間、いくつかのルータが電子証券取引ネットワークできるパケット(例えば、混雑検出に同じRED方針を使用する)を落とすかもしれません、同等なレベルの混雑のために。 同様に、ルータは、できる非電子証券取引ネットワークパケットを落としますが、電子証券取引ネットワークできるパケットにCEビットをはめ込むかもしれません、同等なレベルの混雑のために。 CEビット指示と、そして、パケット滴への異なった混雑操舵応答は異なった流れに関する不公平な処理をもたらすかもしれません。
An additional requirement is that the end-systems should react to congestion at most once per window of data (i.e., at most once per roundtrip time), to avoid reacting multiple times to multiple indications of congestion within a roundtrip time.
すなわち、追加要件がエンドシステムが高々データの窓に一度混雑に反応するはずであるということである、(高々一度往復の時間あたり)、往復の時以内に複数の回混雑の複数のしるしに反応するのを避けるために。
For a router, the CE bit of an ECN-Capable packet should only be set if the router would otherwise have dropped the packet as an indication of congestion to the end nodes. When the router's buffer is not yet full and the router is prepared to drop a packet to inform end nodes of incipient congestion, the router should first check to see if the ECT bit is set in that packet's IP header. If so, then instead of dropping the packet, the router MAY instead set the CE bit in the IP header.
ルータにおいて、そうでなければ、ルータが混雑のしるしとしてパケットをエンドノードに落とした場合にだけ、電子証券取引ネットワークできるパケットのCEビットは設定されるべきです。 ルータのバッファがまだ完全でなく、ルータが始まりの混雑のエンドノードを知らせるためにパケットを落とすように準備されるとき、ルータは、最初に、ECTビットがそのパケットのIPヘッダーに設定されるかどうか確認するためにチェックするべきです。 そうだとすれば、そしてパケットを落とすことの代わりに、ルータは代わりにIPヘッダーにCEビットをはめ込むかもしれません。
An environment where all end nodes were ECN-Capable could allow new criteria to be developed for setting the CE bit, and new congestion control mechanisms for end-node reaction to CE packets. However, this is a research issue, and as such is not addressed in this document.
すべてのエンドノードが電子証券取引ネットワークできた環境で、新しい評価基準は、CEビット、および新しい混雑制御機構をCEパケットへのエンドノード反応に設定するために展開できました。 しかしながら、これは、研究課題であり、そういうものとして本書では記述されません。
When a CE packet is received by a router, the CE bit is left unchanged, and the packet transmitted as usual. When severe congestion has occurred and the router's queue is full, then the router has no choice but to drop some packet when a new packet arrives. We anticipate that such packet losses will become relatively infrequent when a majority of end-systems become ECN- Capable and participate in TCP or other compatible congestion control mechanisms. In an adequately-provisioned network in such an ECN- Capable environment, packet losses should occur primarily during
ルータでCEパケットを受け取るとき、CEビットを変わりがないままにしました、そして、パケットはいつものように伝わりました。 新しいパケットが到着するとき、厳しい混雑が起こって、ルータの待ち行列が完全であると、ルータはあるパケットを落とさざるを得ません。 私たちは、エンドシステムの大部分ができる電子証券取引ネットワークになって、TCPか他のコンパチブル混雑制御機構に参加するとき、そのようなパケット損失が比較的珍しくなると予期します。そのような電子証券取引ネットワークのできる環境における適切に食糧を供給されたネットワークでは、パケット損失は主として起こるべきです。
Ramakrishnan & Floyd Experimental [Page 5] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[5ページ]RFC2481電子証券取引ネットワーク
transients or in the presence of non-cooperating sources.
過渡現象かソース非協力しているがあるとき。
We expect that routers will set the CE bit in response to incipient congestion as indicated by the average queue size, using the RED algorithms suggested in [FJ93, RFC2309]. To the best of our knowledge, this is the only proposal currently under discussion in the IETF for routers to drop packets proactively, before the buffer overflows. However, this document does not attempt to specify a particular mechanism for active queue management, leaving that endeavor, if needed, to other areas of the IETF. While ECN is inextricably tied up with active queue management at the router, the reverse does not hold; active queue management mechanisms have been developed and deployed independently from ECN, using packet drops as indications of congestion in the absence of ECN in the IP architecture.
私たちは、ルータが平均した待ち行列サイズによって示されるように始まりの混雑に対応してCEビットを設定すると予想します、[FJ93、RFC2309]に示されたREDアルゴリズムを使用して。 私たちが知っている限り、これはIETFでルータがパケット予測するのを落とすという現在議論での唯一の提案です、バッファがあふれる前に。 しかしながら、このドキュメントは、活発な待ち行列管理に特定のメカニズムを指定するのを試みません、その努力を残して、必要であるなら、IETFの他の領域に。 電子証券取引ネットワークがルータにおける活発な待ち行列管理で解決できなくタイアップされている間、逆は成立しません。 アクティブな待ち行列管理メカニズムは、電子証券取引ネットワークから独自に開発されて、配備されました、IP構造の電子証券取引ネットワークが不在のとき混雑のしるしとしてパケット滴を使用して。
6. Support from the Transport Protocol
6. トランスポート・プロトコルからのサポート
ECN requires support from the transport protocol, in addition to the functionality given by the ECN field in the IP packet header. The transport protocol might require negotiation between the endpoints during setup to determine that all of the endpoints are ECN-capable, so that the sender can set the ECT bit in transmitted packets. Second, the transport protocol must be capable of reacting appropriately to the receipt of CE packets. This reaction could be in the form of the data receiver informing the data sender of the received CE packet (e.g., TCP), of the data receiver unsubscribing to a layered multicast group (e.g., RLM [MJV96]), or of some other action that ultimately reduces the arrival rate of that flow to that receiver.
電子証券取引ネットワークはトランスポート・プロトコルから支持を要します、IPパケットのヘッダーの電子証券取引ネットワーク分野によって与えられた機能性に加えて。 トランスポート・プロトコルは終点のすべてが電子証券取引ネットワークできることを決定するためにセットアップの間、終点の間の交渉を必要とするかもしれません、送付者が伝えられたパケットにECTビットをはめ込むことができるように。 2番目に、トランスポート・プロトコルは適切にCEパケットの領収書に反応できなければなりません。 この反応は、容認されたCEパケット(例えば、TCP)、層にされたマルチキャストグループ(例えば、RLM[MJV96])に外すデータ受信装置、または結局その流れ対その受信機の到着率を低下させるある他の動きについてデータ送付者に知らせながら、データ受信装置の形にあるかもしれません。
This document only addresses the addition of ECN Capability to TCP, leaving issues of ECN and other transport protocols to further research. For TCP, ECN requires three new mechanisms: negotiation between the endpoints during setup to determine if they are both ECN-capable; an ECN-Echo flag in the TCP header so that the data receiver can inform the data sender when a CE packet has been received; and a Congestion Window Reduced (CWR) flag in the TCP header so that the data sender can inform the data receiver that the congestion window has been reduced. The support required from other transport protocols is likely to be different, particular for unreliable or reliable multicast transport protocols, and will have to be determined as other transport protocols are brought to the IETF for standardization.
このドキュメントは電子証券取引ネットワークCapabilityのTCPへの添加を記述するだけです、研究を促進するために電子証券取引ネットワークと他の輸送の問題をプロトコルに残して。 TCPに関しては、電子証券取引ネットワークは3つの新しいメカニズムを必要とします: それらが電子証券取引ネットワークともにできるかどうか決定するセットアップの間の終点の間の交渉。 電子証券取引ネットワーク-エコーは弛みます。データ受信装置がそうすることができるように、TCPヘッダーでは、CEパケットがいつ受け取られたかをデータ送付者に知らせてください。 そして、Congestion Window Reduced(CWR)は、データ送付者が、混雑ウィンドウが減少したことをデータ受信装置に知らせることができるように、TCPヘッダーで弛みます。 他のトランスポート・プロトコルから必要であるサポートは、頼り無いか信頼できるマルチキャストトランスポート・プロトコルのために異なって、特定である傾向があって、他のトランスポート・プロトコルが標準化にIETFにもたらされているとき、決定しなければならないでしょう。
Ramakrishnan & Floyd Experimental [Page 6] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[6ページ]RFC2481電子証券取引ネットワーク
6.1. TCP
6.1. TCP
The following sections describe in detail the proposed use of ECN in TCP. This proposal is described in essentially the same form in [Floyd94]. We assume that the source TCP uses the standard congestion control algorithms of Slow-start, Fast Retransmit and Fast Recovery [RFC 2001].
以下のセクションは詳細にTCPにおける電子証券取引ネットワークの提案された使用について説明します。 この提案は[Floyd94]の本質的には同じフォームで説明されます。 私たちは、ソースTCPがSlow-始め、Fast Retransmit、およびFast Recovery[RFC2001]の標準の輻輳制御アルゴリズムを使用すると思います。
This proposal specifies two new flags in the Reserved field of the TCP header. The TCP mechanism for negotiating ECN-Capability uses the ECN-Echo flag in the TCP header. (This was called the ECN Notify flag in some earlier documents.) Bit 9 in the Reserved field of the TCP header is designated as the ECN-Echo flag. The location of the 6-bit Reserved field in the TCP header is shown in Figure 3 of RFC 793 [RFC793].
この提案はTCPヘッダーのReserved分野の2個の新しい旗を指定します。 交渉電子証券取引ネットワーク-能力のためのTCPメカニズムはTCPヘッダーで電子証券取引ネットワーク-エコー旗を使用します。 (これはいくつかの以前のドキュメントの電子証券取引ネットワークNotify旗と呼ばれました。) TCPヘッダーのReserved分野のビット9は電子証券取引ネットワーク-エコー旗として指定されます。 TCPヘッダーの6ビットのReserved分野の位置はRFC793[RFC793]の図3に示されます。
To enable the TCP receiver to determine when to stop setting the ECN-Echo flag, we introduce a second new flag in the TCP header, the Congestion Window Reduced (CWR) flag. The CWR flag is assigned to Bit 8 in the Reserved field of the TCP header.
TCP受信機が、電子証券取引ネットワーク-エコー旗を設定するのをいつ止めるかを決定するのを可能にするために、私たちはTCPヘッダー(Congestion Window Reduced(CWR)旗)で2番目の新しい旗を導入します。 CWR旗はTCPヘッダーのReserved分野でBit8に割り当てられます。
The use of these flags is described in the sections below.
これらの旗の使用は下のセクションで説明されます。
6.1.1. TCP Initialization
6.1.1. TCP初期設定
In the TCP connection setup phase, the source and destination TCPs exchange information about their desire and/or capability to use ECN. Subsequent to the completion of this negotiation, the TCP sender sets the ECT bit in the IP header of data packets to indicate to the network that the transport is capable and willing to participate in ECN for this packet. This will indicate to the routers that they may mark this packet with the CE bit, if they would like to use that as a method of congestion notification. If the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECT bit equal to 0 (i.e., not set), and the TCP receiver ignores the CE bit in the received packet.
TCP接続設定フェーズ、ソース、および目的地では、TCPsが彼らの願望、そして/または、電子証券取引ネットワークを使用する能力に関して情報交換します。 この交渉の完成にその後です、TCP送付者は輸送が、できてこのパケットのために電子証券取引ネットワークに参加しても構わないと思っているのをネットワークに示すためにデータ・パケットのIPヘッダーにECTビットをはめ込みます。 これは、CEビットでこのパケットをマークするかもしれないのをルータに示すでしょう、混雑通知の方法としてそれを使用したいと思うなら。 TCP接続が電子証券取引ネットワークの通知を使用したいと思わないなら、特定のパケット、0(すなわち、セットしない)、およびTCP受信機と等しいECTビットが無視する送付TCPセットのために、CEは容認されたパケットで噛み付きました。
When a node sends a TCP SYN packet, it may set the ECN-Echo and CWR flags in the TCP header. For a SYN packet, the setting of both the ECN-Echo and CWR flags are defined as an indication that the sending TCP is ECN-Capable, rather than as an indication of congestion or of response to congestion. More precisely, a SYN packet with both the ECN-Echo and CWR flags set indicates that the TCP implementation transmitting the SYN packet will participate in ECN as both a sender and receiver. As a receiver, it will respond to incoming data packets that have the CE bit set in the IP header by setting the ECN-Echo flag in outgoing TCP Acknowledgement (ACK) packets. As a sender, it will respond to incoming packets that have the ECN-Echo
ノードがTCP SYNパケットを送るとき、それはTCPヘッダーに電子証券取引ネットワーク-エコーとCWR旗を設定するかもしれません。 SYNパケットに関しては、電子証券取引ネットワーク-エコーとCWR旗の両方の設定は発信しているTCPが電子証券取引ネットワークできるという指示と定義されます、むしろ混雑か応答の混雑へのしるしより。 より正確に、旗が設定する電子証券取引ネットワーク-エコーとCWRの両方があるSYNパケットは、SYNパケットを伝えるTCP実現が両方として電子証券取引ネットワークに参加するのを示します。a送付者と受信機受信機として、それはIPヘッダーに出発しているTCP Acknowledgement(ACK)パケットに電子証券取引ネットワーク-エコー旗をはめ込むことによってCEビットを設定する受信データパケットにこたえるでしょう。 送付者として、それは電子証券取引ネットワーク-エコーを持っている入って来るパケットに応じるでしょう。
Ramakrishnan & Floyd Experimental [Page 7] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[7ページ]RFC2481電子証券取引ネットワーク
flag set by reducing the congestion window when appropriate.
旗は、適切であるときに混雑ウィンドウを減少させることによって、セットしました。
When a node sends a SYN-ACK packet, it may set the ECN-Echo flag, but it does not set the CWR flag. For a SYN-ACK packet, the pattern of the ECN-Echo flag set and the CWR flag not set in the TCP header is defined as an indication that the TCP transmitting the SYN-ACK packet is ECN-Capable.
ノードがSYN-ACKパケットを送るとき、電子証券取引ネットワーク-エコー旗を設定するかもしれませんが、それはCWR旗を設定しません。 SYN-ACKパケットに関しては、電子証券取引ネットワーク-エコー旗のパターンはセットしました、そして、TCPヘッダーに設定されなかったCWR旗はSYN-ACKパケットを伝えるTCPが電子証券取引ネットワークできるという指示と定義されます。
There is the question of why we chose to have the TCP sending the SYN set two ECN-related flags in the Reserved field of the TCP header for the SYN packet, while the responding TCP sending the SYN-ACK sets only one ECN-related flag in the SYN-ACK packet. This asymmetry is necessary for the robust negotiation of ECN-capability with deployed TCP implementations. There exists at least one TCP implementation in which TCP receivers set the Reserved field of the TCP header in ACK packets (and hence the SYN-ACK) simply to reflect the Reserved field of the TCP header in the received data packet. Because the TCP SYN packet sets the ECN-Echo and CWR flags to indicate ECN-capability, while the SYN-ACK packet sets only the ECN-Echo flag, the sending TCP correctly interprets a receiver's reflection of its own flags in the Reserved field as an indication that the receiver is not ECN-capable.
私たちが、TCPにSYNパケットのためにTCPヘッダーのReserved分野で2個の電子証券取引ネットワーク関連の旗をSYNセットに送らせるのを選んだ理由に関する質問があります、SYN-ACKを送る応じているTCPは1個の電子証券取引ネットワーク関連の旗だけをSYN-ACKパケットにはめ込みますが。 この非対称が配備されたTCP実現との電子証券取引ネットワーク-能力の体力を要している交渉に必要です。 TCP受信機がACKパケット(そして、したがって、SYN-ACK)のTCPヘッダーのReserved分野に単にTCPヘッダーのReserved分野を受信データパケットに反映するように設定する少なくとも1つのTCP実現が存在しています。 TCP SYNパケットが、電子証券取引ネットワーク-エコーとCWR旗に電子証券取引ネットワーク-能力を示すように設定しますが、SYN-ACKパケットが電子証券取引ネットワーク-エコー旗だけを設定するので、発信しているTCPは受信機が電子証券取引ネットワークできないという指示として正しくReserved分野でのそれ自身の旗に関する受信機の反省を解釈します。
6.1.2. The TCP Sender
6.1.2. TCP送付者
For a TCP connection using ECN, data packets are transmitted with the ECT bit set in the IP header (set to a "1"). If the sender receives an ECN-Echo ACK packet (that is, an ACK packet with the ECN-Echo flag set in the TCP header), then the sender knows that congestion was encountered in the network on the path from the sender to the receiver. The indication of congestion should be treated just as a congestion loss in non-ECN-Capable TCP. That is, the TCP source halves the congestion window "cwnd" and reduces the slow start threshold "ssthresh". The sending TCP does NOT increase the congestion window in response to the receipt of an ECN-Echo ACK packet.
電子証券取引ネットワークを使用しているTCP接続においてデータ・パケットがIPヘッダーに設定されたECTビットで伝えられる、(aにセットしてください、「1インチ)」 送付者が電子証券取引ネットワーク-エコーACKパケットを受けるなら(すなわち、電子証券取引ネットワーク-エコー旗があるACKパケットはTCPヘッダーにセットしました)、送付者は、混雑が経路のネットワークで送付者から受信機まで遭遇したのを知っています。混雑のしるしはちょうどできる非電子証券取引ネットワークTCPの混雑の損失として扱われるべきです。 すなわち、TCPソースは、混雑ウィンドウ"cwnd"を半分にして、遅れた出発敷居"ssthresh"を減少させます。 発信しているTCPは電子証券取引ネットワーク-エコーACKパケットの領収書に対応して混雑ウィンドウを増加させません。
A critical condition is that TCP does not react to congestion indications more than once every window of data (or more loosely, more than once every round-trip time). That is, the TCP sender's congestion window should be reduced only once in response to a series of dropped and/or CE packets from a single window of data, In addition, the TCP source should not decrease the slow-start threshold, ssthresh, if it has been decreased within the last round trip time. However, if any retransmitted packets are dropped or have the CE bit set, then this is interpreted by the source TCP as a new instance of congestion.
または、危篤状態がTCPがかつてのデータのあらゆる窓より混雑に指摘で反応するというわけではないということである、(より多くのゆるみ、往復の毎回一度以上) TCPソースがデータ、In添加の単一の窓からの一連の低下する、そして/または、CEパケットに対応して遅れた出発敷居をいったん減少させないとだけ、すなわち、TCP送付者の混雑ウィンドウは減少するべきです、ssthresh、それが最後の周遊旅行時間中に減少したなら。 しかしながら、どんな再送されたパケットでも落とされるか、またはCEビットを設定するなら、これは混雑の新しい例としてソースTCPによって解釈されます。
Ramakrishnan & Floyd Experimental [Page 8] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[8ページ]RFC2481電子証券取引ネットワーク
After the source TCP reduces its congestion window in response to a CE packet, incoming acknowledgements that continue to arrive can "clock out" outgoing packets as allowed by the reduced congestion window. If the congestion window consists of only one MSS (maximum segment size), and the sending TCP receives an ECN-Echo ACK packet, then the sending TCP should in principle still reduce its congestion window in half. However, the value of the congestion window is bounded below by a value of one MSS. If the sending TCP were to continue to send, using a congestion window of 1 MSS, this results in the transmission of one packet per round-trip time. We believe it is desirable to still reduce the sending rate of the TCP sender even further, on receipt of an ECN-Echo packet when the congestion window is one. We use the retransmit timer as a means to reduce the rate further in this circumstance. Therefore, the sending TCP should also reset the retransmit timer on receiving the ECN-Echo packet when the congestion window is one. The sending TCP will then be able to send a new packet when the retransmit timer expires.
ソースTCPがCEパケットに対応して混雑ウィンドウを減少させた後に、ずっと到着する入って来る承認は減少している混雑ウィンドウによって許容されているように出発しているパケットの「仕事を終えることができます」。 混雑ウィンドウが1MSS(最大のセグメントサイズ)だけから成って、発信しているTCPが電子証券取引ネットワーク-エコーACKパケットを受けるなら、発信しているTCPは原則として混雑ウィンドウをまだ半分に減少させているはずです。 しかしながら、混雑ウィンドウの値は1MSSの値による以下であることで境界があります。 1MSSの混雑ウィンドウを使用して、発信しているTCPが、発信し続けるつもりであったなら、これは往復の時間あたり1つのパケットのトランスミッションをもたらします。 私たちは、混雑ウィンドウが1であるときに、それが電子証券取引ネットワーク-エコーパケットを受け取り次第TCP送付者の送付レートをまださらにさえ低下させているのにおいて望ましいと信じています。 私たちはこの状況で、より遠くにレートを低下させる手段として再送信タイマを使用します。 したがって、また、混雑ウィンドウが1であるときに電子証券取引ネットワーク-エコーパケットを受けるとき、発信しているTCPは再送信タイマをリセットするはずです。 再送信タイマがその時期限が切れるとき、発信しているTCPは新しいパケットを送ることができるでしょう。
[Floyd94] discusses TCP's response to ECN in more detail. [Floyd98] discusses the validation test in the ns simulator, which illustrates a wide range of ECN scenarios. These scenarios include the following: an ECN followed by another ECN, a Fast Retransmit, or a Retransmit Timeout; a Retransmit Timeout or a Fast Retransmit followed by an ECN, and a congestion window of one packet followed by an ECN.
[Floyd94]はさらに詳細に電子証券取引ネットワークへのTCPの応答について議論します。 [Floyd98]が合法化テストについて議論する、ナノ秒、シミュレータ、さまざまな電子証券取引ネットワークシナリオを例証する。 これらのシナリオは以下を含んでいます: 電子証券取引ネットワークは別の電子証券取引ネットワーク、Fast Retransmit、またはRetransmit Timeoutで続きました。 Retransmit TimeoutかFast Retransmitが電子証券取引ネットワークで続きました、そして、1つのパケットの混雑ウィンドウは電子証券取引ネットワークで続きました。
TCP follows existing algorithms for sending data packets in response to incoming ACKs, multiple duplicate acknowledgements, or retransmit timeouts [RFC2001].
TCPは入って来るACKsに対応してデータ・パケットを送るための既存のアルゴリズム、複数の写し承認に続くか、またはタイムアウト[RFC2001]を再送します。
6.1.3. The TCP Receiver
6.1.3. TCP受信機
When TCP receives a CE data packet at the destination end-system, the TCP data receiver sets the ECN-Echo flag in the TCP header of the subsequent ACK packet. If there is any ACK withholding implemented, as in current "delayed-ACK" TCP implementations where the TCP receiver can send an ACK for two arriving data packets, then the ECN-Echo flag in the ACK packet will be set to the OR of the CE bits of all of the data packets being acknowledged. That is, if any of the received data packets are CE packets, then the returning ACK has the ECN-Echo flag set.
TCPが目的地エンドシステムでCEデータ・パケットを受けるとき、TCPデータ受信装置はその後のACKパケットのTCPヘッダーに電子証券取引ネットワーク-エコー旗をはめ込みます。 何か現在の「遅れたACK」TCP実現のように実行されたACK源泉徴収がTCP受信機が2つの到着データ・パケットのためにACKを送ることができるところにあると、承認されていて、ACKパケットの電子証券取引ネットワーク-エコー旗はデータ・パケットのすべてのCEビットのORに設定されるでしょう。 すなわち、受信データパケットのどれかがCEパケットであるなら、戻っているACKは電子証券取引ネットワーク-エコー旗を設定させます。
To provide robustness against the possibility of a dropped ACK packet carrying an ECN-Echo flag, the TCP receiver must set the ECN-Echo flag in a series of ACK packets. The TCP receiver uses the CWR flag to determine when to stop setting the ECN-Echo flag.
電子証券取引ネットワーク-エコー旗を運びながら低下しているACKパケットの可能性に対する丈夫さを提供するために、TCP受信機は電子証券取引ネットワーク-エコー旗を一連のACKパケットにはめ込まなければなりません。 TCP受信機は、電子証券取引ネットワーク-エコー旗を設定するのをいつ止めるかを決定するのにCWR旗を使用します。
Ramakrishnan & Floyd Experimental [Page 9] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[9ページ]RFC2481電子証券取引ネットワーク
When an ECN-Capable TCP reduces its congestion window for any reason (because of a retransmit timeout, a Fast Retransmit, or in response to an ECN Notification), the TCP sets the CWR flag in the TCP header of the first data packet sent after the window reduction. If that data packet is dropped in the network, then the sending TCP will have to reduce the congestion window again and retransmit the dropped packet. Thus, the Congestion Window Reduced message is reliably delivered to the data receiver.
電子証券取引ネットワークできるTCPがどんな理由でも混雑ウィンドウを減少させると(aのためにタイムアウト、Fast Retransmitを再送するか、または電子証券取引ネットワークNotificationに対応して)、TCPは窓の減少の後に送られた最初のデータ・パケットのTCPヘッダーにCWR旗をはめ込みます。 そのデータ・パケットがネットワークで落とされると、発信しているTCPは再び混雑ウィンドウを減少させて、低下しているパケットを再送しなければならないでしょう。 したがって、Congestion Window Reducedメッセージをデータ受信装置に確かに渡します。
After a TCP receiver sends an ACK packet with the ECN-Echo bit set, that TCP receiver continues to set the ECN-Echo flag in ACK packets until it receives a CWR packet (a packet with the CWR flag set). After the receipt of the CWR packet, acknowledgements for subsequent non-CE data packets do not have the ECN-Echo flag set. If another CE packet is received by the data receiver, the receiver would once again send ACK packets with the ECN-Echo flag set. While the receipt of a CWR packet does not guarantee that the data sender received the ECN-Echo message, this does indicate that the data sender reduced its congestion window at some point *after* it sent the data packet for which the CE bit was set.
電子証券取引ネットワーク-エコービットがセットした状態でTCP受信機がACKパケットを送った後に、そのTCP受信機は、CWRパケットを受けるまで(CWR旗があるパケットはセットしました)電子証券取引ネットワーク-エコー旗をACKパケットにはめ込み続けています。 CWRパケットの領収書の後に、その後の非CEデータ・パケットのための承認で、電子証券取引ネットワーク-エコー旗を設定しません。 データ受信装置で別のCEパケットを受け取るなら、受信機はもう一度電子証券取引ネットワーク-エコー旗のセットがあるパケットをACKに送るでしょう。 CWRパケットの領収書は、データ送付者が電子証券取引ネットワーク-エコーメッセージを受け取ったのを保証しませんが、これは、**CEビットが設定されたデータ・パケットを送った後にデータ送付者が何らかのポイントで混雑ウィンドウを減少させたのを示します。
We have already specified that a TCP sender reduces its congestion window at most once per window of data. This mechanism requires some care to make sure that the sender reduces its congestion window at most once per ECN indication, and that multiple ECN messages over several successive windows of data are properly reported to the ECN sender. This is discussed further in [Floyd98].
私たちは、TCP送付者が混雑ウィンドウを高々データの窓に一度減少させると既に指定しました。 このメカニズムは、送付者が混雑ウィンドウを高々電子証券取引ネットワークの指示に一度減少させて、データのいくつかの連続した窓の上の複数の電子証券取引ネットワークメッセージが適切に電子証券取引ネットワークの送付者に報告されるのを確実にするために何らかの注意を必要とします。 [Floyd98]で、より詳しくこれについて議論します。
6.1.4. Congestion on the ACK-path
6.1.4. ACK-経路における混雑
For the current generation of TCP congestion control algorithms, pure acknowledgement packets (e.g., packets that do not contain any accompanying data) should be sent with the ECT bit off. Current TCP receivers have no mechanisms for reducing traffic on the ACK-path in response to congestion notification. Mechanisms for responding to congestion on the ACK-path are areas for current and future research. (One simple possibility would be for the sender to reduce its congestion window when it receives a pure ACK packet with the CE bit set). For current TCP implementations, a single dropped ACK generally has only a very small effect on the TCP's sending rate.
TCP輻輳制御アルゴリズムの現代に、ECTビットがオフな状態で純粋な確認応答パケット(例えば、少しの付随のデータも含まないパケット)を送るべきです。 現在のTCP受信機はACK-経路に混雑通知に対応して交通を抑えるためのメカニズムを全く持っていません。 ACK-経路で混雑に応じるためのメカニズムは現在の、そして、今後の調査のための領域です。 (1つの簡単な可能性はCEビットがセットした状態で純粋なACKパケットを受けるとき、送付者が混雑ウィンドウを減少させるだろうことです。) 一般に、現在のTCP実現のために、独身の低下しているACKはTCPの送付レートに非常に小さい影響だけを与えます。
7. Summary of changes required in IP and TCP
7. 変化の概要がIPとTCPで必要です。
Two bits need to be specified in the IP header, the ECN-Capable Transport (ECT) bit and the Congestion Experienced (CE) bit. The ECT bit set to "0" indicates that the transport protocol will ignore the
2ビットは、IPヘッダー、電子証券取引ネットワークできるTransport(ECT)ビット、およびCongestion Experienced(CE)ビットで指定される必要があります。 ECTビットがセットした、「0インチが、トランスポート・プロトコルが無視されるのを示す、」
Ramakrishnan & Floyd Experimental [Page 10] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[10ページ]RFC2481電子証券取引ネットワーク
CE bit. This is the default value for the ECT bit. The ECT bit set to "1" indicates that the transport protocol is willing and able to participate in ECN.
CEは噛み付きました。 これはECTビット単位でデフォルト値です。 ECTビットは「1インチは、トランスポート・プロトコルが望んでいて電子証券取引ネットワークに参加できるのを示すこと」にセットしました。
The default value for the CE bit is "0". The router sets the CE bit to "1" to indicate congestion to the end nodes. The CE bit in a packet header should never be reset by a router from "1" to "0".
CEビット単位でデフォルト値は「0インチ」です。 ルータは「混雑をエンドノードに示す1インチ」にCEビットを設定します。 CEがパケットのヘッダーがaによるリセットがルータであるなら決してそうしないコネに噛み付いた、「1インチから「0インチ。」
TCP requires three changes, a negotiation phase during setup to determine if both end nodes are ECN-capable, and two new flags in the TCP header, from the "reserved" flags in the TCP flags field. The ECN-Echo flag is used by the data receiver to inform the data sender of a received CE packet. The Congestion Window Reduced flag is used by the data sender to inform the data receiver that the congestion window has been reduced.
TCPは3回の変化を必要とします、両方のエンドノードがTCPヘッダーの電子証券取引ネットワークできるのと2個の新しい旗であるかどうか決定するセットアップの間の交渉フェーズ、旗がさばくTCPの「予約された」旗から。 電子証券取引ネットワーク-エコー旗はデータ受信装置によって使用されて、容認されたCEパケットについてデータ送付者に知らせます。 Congestion Window Reduced旗は、混雑ウィンドウが減少したことをデータ受信装置に知らせるのにデータ送付者によって使用されます。
8. Non-relationship to ATM's EFCI indicator or Frame Relay's FECN
8. ATMのEFCIインディケータかFrame RelayのFECNとの非関係
Since the ATM and Frame Relay mechanisms for congestion indication have typically been defined without any notion of average queue size as the basis for determining that an intermediate node is congested, we believe that they provide a very noisy signal. The TCP-sender reaction specified in this draft for ECN is NOT the appropriate reaction for such a noisy signal of congestion notification. It is our expectation that ATM's EFCI and Frame Relay's FECN mechanisms would be phased out over time within the ATM network. However, if the routers that interface to the ATM network have a way of maintaining the average queue at the interface, and use it to come to a reliable determination that the ATM subnet is congested, they may use the ECN notification that is defined here.
混雑指示のためのATMとFrame Relayメカニズムが平均した待ち行列サイズの少しも概念なしで中間的ノードが鬱血していることを決定する基礎と通常定義されたので、私たちは、それらが非常に騒がしい信号を提供すると信じています。 この草稿で電子証券取引ネットワークに指定されたTCP-送付者反応は混雑通知のそのような騒がしい信号に関する適切な反応ではありません。 ATMのEFCIとFrame RelayのFECNメカニズムが時間がたつにつれてATMネットワークの中で段階的に廃止されるのは、私たちの期待です。 しかしながら、ATMネットワークに連結するルータが平均を維持する方法がインタフェースに列を作って、それを使用するのをさせるなら、ATMサブネットが信頼できる決断ですが、意識を取り戻すのは充血して、それらはここで定義される電子証券取引ネットワークの通知を使用するかもしれません。
We emphasize that a *single* packet with the CE bit set in an IP packet causes the transport layer to respond, in terms of congestion control, as it would to a packet drop. As such, the CE bit is not a good match to a transient signal such as one based on the instantaneous queue size. However, experiments in techniques at layer 2 (e.g., in ATM switches or Frame Relay switches) should be encouraged. For example, using a scheme such as RED (where packet marking is based on the average queue length exceeding a threshold), layer 2 devices could provide a reasonably reliable indication of congestion. When all the layer 2 devices in a path set that layer's own Congestion Experienced bit (e.g., the EFCI bit for ATM, the FECN bit in Frame Relay) in this reliable manner, then the interface router to the layer 2 network could copy the state of that layer 2 Congestion Experienced bit into the CE bit in the IP header. We recognize that this is not the current practice, nor is it in current standards. However, encouraging experimentation in this manner may
私たちは、トランスポート層がIPパケットに設定されたCEビットがある*単一の*パケットで応じると強調します、輻輳制御で、パケット滴にそうするように。 そういうものとして、CEビットは瞬時に起こっている待ち行列サイズに基づいた1などの一時的な信号への良いマッチではありません。 しかしながら、層2(例えば、ATMスイッチかFrame Relayスイッチの)のテクニックにおける実験は奨励されるべきです。 例えば、RED(パケットマークが敷居を超えている平均した待ち行列の長さに基づいているところ)などの計画を使用して、層の2装置は混雑の合理的に信頼できるしるしを供給するかもしれません。 経路のすべての層の2装置がこの信頼できる方法でその層の自身のCongestion Experiencedビット(例えば、EFCIはATMのために噛み付きました、Frame RelayのFECNビット)を設定すると、2がネットワークでつなぐ層へのインタフェースルータはIPヘッダーでCEビットに噛み付かれたその2Congestion Experienced層の状態をコピーするかもしれません。 私たちはこれが現在の習慣でなく、またそれが現在の規格にないと認めます。 しかしながら、実験を奨励するのはこの様にそうするかもしれません。
Ramakrishnan & Floyd Experimental [Page 11] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[11ページ]RFC2481電子証券取引ネットワーク
provide the information needed to enable evolution of existing layer 2 mechanisms to provide a more reliable means of congestion indication, when they use a single bit for indicating congestion.
既存の層2のメカニズムの発展が混雑指示の、より信頼できる手段を提供するのを可能にするのに必要である情報を提供してください、混雑を示すのに1ビットを使用すると。
9. Non-compliance by the End Nodes
9. エンドノードによる不承諾
This section discusses concerns about the vulnerability of ECN to non-compliant end-nodes (i.e., end nodes that set the ECT bit in transmitted packets but do not respond to received CE packets). We argue that the addition of ECN to the IP architecture would not significantly increase the current vulnerability of the architecture to unresponsive flows.
このセクションは不従順なエンドノード(すなわち、伝えられたパケットにECTビットをはめ込みますが、容認されたCEパケットに応じないエンドノード)に電子証券取引ネットワークの脆弱性に関する心配について論じます。 私たちは、IP構造への電子証券取引ネットワークの追加が構造の現在の脆弱性を無反応流れようにかなり増加させないと主張します。
Even for non-ECN environments, there are serious concerns about the damage that can be done by non-compliant or unresponsive flows (that is, flows that do not respond to congestion control indications by reducing their arrival rate at the congested link). For example, an end-node could "turn off congestion control" by not reducing its congestion window in response to packet drops. This is a concern for the current Internet. It has been argued that routers will have to deploy mechanisms to detect and differentially treat packets from non-compliant flows. It has also been argued that techniques such as end-to-end per-flow scheduling and isolation of one flow from another, differentiated services, or end-to-end reservations could remove some of the more damaging effects of unresponsive flows.
非電子証券取引ネットワーク環境のためにさえ、不従順であるか無反応流れ(すなわち、混雑しているリンクでそれらの到着率を低下させることによって輻輳制御指摘に応じない流れる)で与えられることができる損害に関する真剣な心配があります。 例えば、エンドノードは、パケット滴に対応して混雑ウィンドウを減少させないことによって、「輻輳制御をオフにするかもしれません」。 これは現在のインターネットに関する心配です。 ルータが不従順な流れからパケットを検出して、特異的、扱うためにメカニズムを配備しなければならないと主張されました。 また、終わりから終わりへの1流れあたりのスケジューリングや別のものからの1回の流れ、微分されたサービス、または終わりから終わりへの予約の孤立などのテクニックが無反応流れの、よりダメージが大きい効果のいくつかを取り除くことができたと主張されました。
It has been argued that dropping packets in itself may be an adequate deterrent for non-compliance, and that the use of ECN removes this deterrent. We would argue in response that (1) ECN-capable routers preserve packet-dropping behavior in times of high congestion; and (2) even in times of high congestion, dropping packets in itself is not an adequate deterrent for non-compliance.
本来パケットを落とすのが、不承諾のための適切な抑止力であるかもしれなく、電子証券取引ネットワークの使用がこの抑止力を取り除くと主張されました。 私たちは、応答で(1) 電子証券取引ネットワークできるルータが高い混雑の時代にパケットが低下する振舞いを保持すると主張するでしょう。 (2) そして、高い混雑の時代にさえ、本来パケットを落とすのは、不承諾のための適切な抑止力ではありません。
First, ECN-Capable routers will only mark packets (as opposed to dropping them) when the packet marking rate is reasonably low. During periods where the average queue size exceeds an upper threshold, and therefore the potential packet marking rate would be high, our recommendation is that routers drop packets rather then set the CE bit in packet headers.
レートをマークするパケットがかなり低いときにだけ、まず最初に、電子証券取引ネットワークできるルータはパケット(それらを落とすことと対照的に)をマークするでしょう。 期間、平均した待ち行列サイズが上側の敷居を超えて、したがって、レートをマークする潜在的パケットが高いだろうところでは、私たちの推薦は次に、ルータ低下パケットがむしろCEビットをパケットのヘッダーにはめ込むということです。
During the periods of low or moderate packet marking rates when ECN would be deployed, there would be little deterrent effect on unresponsive flows of dropping rather than marking those packets. For example, delay-insensitive flows using reliable delivery might have an incentive to increase rather than to decrease their sending rate in the presence of dropped packets. Similarly, delay-sensitive flows using unreliable delivery might increase their use of FEC in response to an increased packet drop rate, increasing rather than decreasing
電子証券取引ネットワークが配備されるだろうというときレートをマークする低いか適度のパケットの期間、抑止効果がそれらのパケットをマークするよりむしろ低下する無反応流れにほとんどないでしょう。 例えば、信頼できる配信を使用する遅れ神経の鈍い流れは低下しているパケットがあるときそれらの送付レートを減少させるというよりむしろ増加する誘因を持っているかもしれません。 同様に、頼り無い配送を使用する遅れ敏感な流れは増加するパケット低下率に対応して彼らのFECの使用を増加させるかもしれません、減少するよりむしろ増加して
Ramakrishnan & Floyd Experimental [Page 12] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[12ページ]RFC2481電子証券取引ネットワーク
their sending rate. For the same reasons, we do not believe that packet dropping itself is an effective deterrent for non-compliance even in an environment of high packet drop rates.
彼らはレートを送ります。 同じ理由で、私たちは、パケット低下自体が高いパケット低下率の環境さえにおける不承諾のための効果のある抑止物であると信じていません。
Several methods have been proposed to identify and restrict non- compliant or unresponsive flows. The addition of ECN to the network environment would not in any way increase the difficulty of designing and deploying such mechanisms. If anything, the addition of ECN to the architecture would make the job of identifying unresponsive flows slightly easier. For example, in an ECN-Capable environment routers are not limited to information about packets that are dropped or have the CE bit set at that router itself; in such an environment routers could also take note of arriving CE packets that indicate congestion encountered by that packet earlier in the path.
いくつかの方法が、非対応するか無反応流れを特定して、制限するために提案されました。 ネットワーク環境への電子証券取引ネットワークの参加はそのようなメカニズムを設計して、配備するという困難を何らかの方法で増加させないでしょう。どちらかと言えば、構造への電子証券取引ネットワークの追加で、無反応流れをわずかに特定する仕事は、より簡単になるでしょう。 例えば、電子証券取引ネットワークできる環境ルータでは、落とされるか、またはそのルータ自体でCEビットを設定するパケットの情報に制限されません。 また、そのような環境で、ルータは、より早く経路でそのパケットで遭遇した混雑を示す到着しているCEパケットに注目するかもしれません。
10. Non-compliance in the Network
10. ネットワークにおける不承諾
The breakdown of effective congestion control could be caused not only by a non-compliant end-node, but also by the loss of the congestion indication in the network itself. This could happen through a rogue or broken router that set the ECT bit in a packet from a non-ECN-capable transport, or "erased" the CE bit in arriving packets. As one example, a rogue or broken router that "erased" the CE bit in arriving CE packets would prevent that indication of congestion from reaching downstream receivers. This could result in the failure of congestion control for that flow and a resulting increase in congestion in the network, ultimately resulting in subsequent packets dropped for this flow as the average queue size increased at the congested gateway.
有効な輻輳制御の故障は不従順なエンドノードで引き起こされるだけではなく、ネットワーク自体の混雑指示の損失でも引き起こされる場合がありました。 これはできる非電子証券取引ネットワークの輸送からパケットにECTビットをはめ込むか、または到着パケットでCEビットを「消した」凶暴であるか壊れているルータを通して起こることができました。 1つの例として、到着しているCEパケットでCEビットを「消した」凶暴であるか壊れているルータは、混雑のそのしるしが川下の受信機に達するのを防ぐでしょう。 これはネットワークで混雑のその流れと結果として起こる増加のための輻輳制御の失敗をもたらすかもしれません、結局平均した待ち行列サイズが混雑しているゲートウェイで増加するのに応じてこの流れのために落とされたその後のパケットをもたらして。
The actions of a rogue or broken router could also result in an unnecessary indication of congestion to the end-nodes. These actions can include a router dropping a packet or setting the CE bit in the absence of congestion. From a congestion control point of view, setting the CE bit in the absence of congestion by a non-compliant router would be no different than a router dropping a packet unecessarily. By "erasing" the ECT bit of a packet that is later dropped in the network, a router's actions could result in an unnecessary packet drop for that packet later in the network.
また、凶暴であるか壊れているルータの動作はエンドノードへの混雑の不要なしるしをもたらすかもしれません。 これらの動作は、パケットを落とすルータか混雑がないときCEビットを設定するのを含むことができます。 混雑制御点と、不従順なルータによる混雑がないときCEビットを設定するのはunecessarilyにパケットを落とすルータと異なっていないでしょう。 後でネットワークで落とされるパケットのECTビットが「消す」であることによって、ルータの動作は後でネットワークでそのパケットのための不要なパケット滴をもたらすかもしれません。
Concerns regarding the loss of congestion indications from encapsulated, dropped, or corrupted packets are discussed below.
以下で要約の、または、低下したか、崩壊したパケットからの混雑指摘の損失に関する心配について議論します。
Ramakrishnan & Floyd Experimental [Page 13] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[13ページ]RFC2481電子証券取引ネットワーク
10.1. Encapsulated packets
10.1. 要約のパケット
Some care is required to handle the CE and ECT bits appropriately when packets are encapsulated and de-encapsulated for tunnels.
何らかの注意が、パケットがカプセルに入れられて、反-トンネルにカプセルに入れられるとき、適切にCEとECTビットを扱うのに必要です。
When a packet is encapsulated, the following rules apply regarding
the ECT bit. First, if the ECT bit in the encapsulated ('inside')
header is a 0, then the ECT bit in the encapsulating ('outside')
header MUST be a 0. If the ECT bit in the inside header is a 1, then
the ECT bit in the outside header SHOULD be a 1.
パケットがカプセルに入れられるとき、以下の規則はECTビットに関して適用されます。 まず最初に、要約の('inside')ヘッダーのECTビットが0であるなら、要約('外')のヘッダーのECTビットは0であるに違いありません。 ECTは内部のヘッダーのECTビットが1であるなら外のヘッダーSHOULDで噛み付きました。1になってください。
When a packet is de-encapsulated, the following rules apply regarding the CE bit. If the ECT bit is a 1 in both the inside and the outside header, then the CE bit in the outside header MUST be ORed with the CE bit in the inside header. (That is, in this case a CE bit of 1 in the outside header must be copied to the inside header.) If the ECT bit in either header is a 0, then the CE bit in the outside header is ignored. This requirement for the treatment of de-encapsulated packets does not currently apply to IPsec tunnels.
パケットが反-カプセルに入れられるとき、以下の規則はCEビットに関して適用されます。 ECTビットが内部と外部のヘッダーの両方の1であるなら、外部のヘッダーのCEビットはCEビットが内面のヘッダーにあるORedであるに違いありません。 (すなわち、この場合外部のヘッダーの1のCEビットを内面のヘッダーにコピーしなければなりません。) どちらかのヘッダーのECTビットが0であるなら、外部のヘッダーのCEビットは無視されます。 反-要約されたパケットの処理のためのこの要件は現在、IPsecトンネルに適用されません。
A specific example of the use of ECN with encapsulation occurs when a flow wishes to use ECN-capability to avoid the danger of an unnecessary packet drop for the encapsulated packet as a result of congestion at an intermediate node in the tunnel. This functionality can be supported by copying the ECN field in the inner IP header to the outer IP header upon encapsulation, and using the ECN field in the outer IP header to set the ECN field in the inner IP header upon decapsulation. This effectively allows routers along the tunnel to cause the CE bit to be set in the ECN field of the unencapsulated IP header of an ECN-capable packet when such routers experience congestion.
不要なパケットの危険を避ける電子証券取引ネットワーク-能力を使用するという流れ願望がトンネルの中間的ノードでの混雑の結果、要約のパケットのために低下すると、カプセル化がある電子証券取引ネットワークの使用の特定の例は現れます。 内側のIPヘッダーにカプセル化の外側のIPヘッダーに電子証券取引ネットワーク分野をコピーして、被膜剥離術で内側のIPヘッダーに電子証券取引ネットワーク分野をはめ込むのに外側のIPヘッダーで電子証券取引ネットワーク分野を使用することによって、この機能性を支持できます。 そのようなルータが混雑になるとき、これで、事実上、トンネルに沿ったルータは電子証券取引ネットワークできるパケットの非要約のIPヘッダーの電子証券取引ネットワーク分野にCEビットを設定できます。
10.2. IPsec Tunnel Considerations
10.2. IPsecトンネル問題
The IPsec protocol, as defined in [ESP, AH], does not include the IP header's ECN field in any of its cryptographic calculations (in the case of tunnel mode, the outer IP header's ECN field is not included). Hence modification of the ECN field by a network node has no effect on IPsec's end-to-end security, because it cannot cause any IPsec integrity check to fail. As a consequence, IPsec does not provide any defense against an adversary's modification of the ECN field (i.e., a man-in-the-middle attack), as the adversary's modification will also have no effect on IPsec's end-to-end security. In some environments, the ability to modify the ECN field without affecting IPsec integrity checks may constitute a covert channel; if it is necessary to eliminate such a channel or reduce its bandwidth, then the outer IP header's ECN field can be zeroed at the tunnel ingress and egress nodes.
[超能力、AH]で定義されるIPsecプロトコルは暗号の計算のいずれにもIPヘッダーの電子証券取引ネットワーク分野を含んでいません(トンネルモードの場合では、外側のIPヘッダーの電子証券取引ネットワーク分野は含まれていません)。 したがって、ネットワーク・ノードによる電子証券取引ネットワーク分野の変更は終わりから終わりへのIPsecのセキュリティで効き目がありません、それがどんなIPsec保全チェックにも失敗できないので。 結果として、IPsecは敵の電子証券取引ネットワーク分野(すなわち、介入者攻撃)の変更に対してどんなディフェンスも提供しません、また、敵の変更が終わりから終わりへのIPsecのセキュリティで効き目がないとき。 いくつかの環境で、IPsec保全チェックに影響しないで電子証券取引ネットワーク分野を変更する能力はひそかなチャンネルを構成するかもしれません。 そのようなチャンネルを排除するか、または帯域幅を減少させるのが必要であるなら、トンネルイングレスと出口ノードで外側のIPヘッダーの電子証券取引ネットワーク分野のゼロを合わせることができます。
Ramakrishnan & Floyd Experimental [Page 14] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[14ページ]RFC2481電子証券取引ネットワーク
The IPsec protocol currently requires that the inner header's ECN field not be changed by IPsec decapsulation processing at a tunnel egress node. This ensures that an adversary's modifications to the ECN field cannot be used to launch theft- or denial-of-service attacks across an IPsec tunnel endpoint, as any such modifications will be discarded at the tunnel endpoint. This document makes no change to that IPsec requirement. As a consequence of the current specification of the IPsec protocol, we suggest that experiments with ECN not be carried out for flows that will undergo IPsec tunneling at the present time.
IPsecプロトコルは、現在、内側のヘッダーの電子証券取引ネットワーク分野がトンネル出口ノードでIPsec被膜剥離術処理で変えられないのを必要とします。 これは、IPsecトンネル終点の向こう側に窃盗かサービス不能攻撃に着手するのに電子証券取引ネットワーク分野への敵の変更を使用できないのを確実にします、どんなそのような変更もトンネル終点で捨てられるとき。 このドキュメントはそのIPsec要件への変更を全く行いません。 IPsecプロトコルの現在の仕様の結果として、私たちは、電子証券取引ネットワークとの実験が現在でIPsecトンネリングを受ける流れのために行われないことを提案します。
If the IPsec specifications are modified in the future to permit a tunnel egress node to modify the ECN field in an inner IP header based on the ECN field value in the outer header (e.g., copying part or all of the outer ECN field to the inner ECN field), or to permit the ECN field of the outer IP header to be zeroed during encapsulation, then experiments with ECN may be used in combination with IPsec tunneling.
IPsec仕様が将来トンネル出口ノードが、外側のヘッダー(例えば、外側の電子証券取引ネットワーク分野の部分かすべてを内側の電子証券取引ネットワーク分野にコピーする)で電子証券取引ネットワーク分野価値に基づく内側のIPヘッダーの電子証券取引ネットワーク分野を変更するか、または外側のIPヘッダーの電子証券取引ネットワーク分野のゼロがカプセル化の間、合わせられることを許可することを許可するように変更されるなら、電子証券取引ネットワークとの実験はIPsecトンネリングと組み合わせて使用されるかもしれません。
This discussion of ECN and IPsec tunnel considerations draws heavily on related discussions and documents from the Differentiated Services Working Group.
電子証券取引ネットワークとIPsecトンネル問題のこの議論は大いにDifferentiated Services作業部会からの関連する議論とドキュメントを利用します。
10.3. Dropped or Corrupted Packets
10.3. 低下したか崩壊したパケット
An additional issue concerns a packet that has the CE bit set at one router and is dropped by a subsequent router. For the proposed use for ECN in this paper (that is, for a transport protocol such as TCP for which a dropped data packet is an indication of congestion), end nodes detect dropped data packets, and the congestion response of the end nodes to a dropped data packet is at least as strong as the congestion response to a received CE packet.
追加設定は1つのルータでCEビットを設定させて、その後のルータによって落とされるパケットに関係があります。 この紙(すなわち、低下しているデータ・パケットが混雑のしるしであるTCPなどのトランスポート・プロトコルのための)の電子証券取引ネットワークの提案された使用のために、ノードが検出する終わりがデータ・パケットを落として、低下しているデータ・パケットへのエンドノードの混雑応答は容認されたCEパケットへの混雑応答と少なくとも同じくらい強いです。
However, transport protocols such as TCP do not necessarily detect all packet drops, such as the drop of a "pure" ACK packet; for example, TCP does not reduce the arrival rate of subsequent ACK packets in response to an earlier dropped ACK packet. Any proposal for extending ECN-Capability to such packets would have to address concerns raised by CE packets that were later dropped in the network.
しかしながら、TCPなどのトランスポート・プロトコルは必ずすべてのパケット滴を検出するというわけではありません、「純粋な」ACKパケットの滴などのように。 例えば、TCPは以前の低下しているACKパケットに対応してその後のACKパケットの到着率を低下させません。 後でネットワークで落とされたCEパケットによって上げられて、そのようなパケットへの電子証券取引ネットワーク-能力が危惧に対処するように持っている広げるどんな提案。
Similarly, if a CE packet is dropped later in the network due to corruption (bit errors), the end nodes should still invoke congestion control, just as TCP would today in response to a dropped data packet. This issue of corrupted CE packets would have to be considered in any proposal for the network to distinguish between packets dropped due to corruption, and packets dropped due to congestion or buffer overflow.
同様に、不正(誤りに噛み付く)のため、CEパケットが後でネットワークで落とされるなら、エンドノードはちょうどTCPが今日呼び出すようにまだ低下しているデータ・パケットに対応して輻輳制御を呼び出しているべきです。 崩壊したCEパケットのこの問題はネットワークが不正のため落とされたパケットを見分けるというどんな提案でも考えられなければならなかったでしょう、そして、パケットは混雑かバッファオーバーフローのため低下しました。
Ramakrishnan & Floyd Experimental [Page 15] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[15ページ]RFC2481電子証券取引ネットワーク
11. A summary of related work.
11. 関連する仕事の概要。
[Floyd94] considers the advantages and drawbacks of adding ECN to the TCP/IP architecture. As shown in the simulation-based comparisons, one advantage of ECN is to avoid unnecessary packet drops for short or delay-sensitive TCP connections. A second advantage of ECN is in avoiding some unnecessary retransmit timeouts in TCP. This paper discusses in detail the integration of ECN into TCP's congestion control mechanisms. The possible disadvantages of ECN discussed in the paper are that a non-compliant TCP connection could falsely advertise itself as ECN-capable, and that a TCP ACK packet carrying an ECN-Echo message could itself be dropped in the network. The first of these two issues is discussed in Section 8 of this document, and the second is addressed by the proposal in Section 5.1.3 for a CWR flag in the TCP header.
[Floyd94]はTCP/IP構造に電子証券取引ネットワークを追加する利点と欠点を考えます。 シミュレーションベースの比較で示されるように、電子証券取引ネットワークの1つの利点は略して不要なパケット滴か遅れ敏感なTCP接続を避けることです。 電子証券取引ネットワークの2番目の利点は不要な状態でいくつかを避ける際に、TCPのタイムアウトに再送されているということです。 この論文は詳細にTCPの混雑制御機構と電子証券取引ネットワークの統合について議論します。紙で議論した電子証券取引ネットワークの可能な損失は不従順なTCP接続自体が、低下しているコネがネットワークであるなら電子証券取引ネットワークできるとしてのそれ自体と、電子証券取引ネットワーク-エコーメッセージを伝えるTCP ACKパケットがそうすることができたのは間違って広告を出すことができるということです。 このドキュメントのセクション8でこれらの2冊の1番目について議論します、そして、2番目はTCPヘッダーのCWR旗のためにセクション5.1.3における提案で記述されます。
[CKLTZ97] reports on an experimental implementation of ECN in IPv6. The experiments include an implementation of ECN in an existing implementation of RED for FreeBSD. A number of experiments were run to demonstrate the control of the average queue size in the router, the performance of ECN for a single TCP connection as a congested router, and fairness with multiple competing TCP connections. One conclusion of the experiments is that dropping packets from a bulk- data transfer can degrade performance much more severely than marking packets.
[CKLTZ97]はIPv6での電子証券取引ネットワークの実験的な実現に関して報告します。 実験は無料OSの一つのためのREDの既存の実現における、電子証券取引ネットワークの実現を含んでいます。 多くの実験はルータ、混雑しているルータとしての単独のTCP接続のための電子証券取引ネットワークの性能、および公正における、複数の競争しているTCP接続による平均した待ち行列サイズのコントロールを実施説明する走行でした。 実験の1つの結論は大量データ転送からパケットを落とすとパケットをマークするよりはるかに厳しく性能を下げることができるということです。
Because the experimental implementation in [CKLTZ97] predates some of the developments in this document, the implementation does not conform to this document in all respects. For example, in the experimental implementation the CWR flag is not used, but instead the TCP receiver sends the ECN-Echo bit on a single ACK packet.
[CKLTZ97]での実験的な実現が本書では開発のいくつかより前に起こるので、実現はあらゆる点でこのドキュメントに従いません。 例えば、CWR旗が実験的な実現は使用されていませんが、代わりに、TCP受信機は単一のACKパケットの電子証券取引ネットワーク-エコービットを送ります。
[K98] and [CKLTZ98] build on [CKLTZ97] to further analyze the benefits of ECN for TCP. The conclusions are that ECN TCP gets moderately better throughput than non-ECN TCP; that ECN TCP flows are fair towards non-ECN TCP flows; and that ECN TCP is robust with two- way traffic, congestion in both directions, and with multiple congested gateways. Experiments with many short web transfers show that, while most of the short connections have similar transfer times with or without ECN, a small percentage of the short connections have very long transfer times for the non-ECN experiments as compared to the ECN experiments. This increased transfer time is particularly dramatic for those short connections that have their first packet dropped in the non-ECN experiments, and that therefore have to wait six seconds for the retransmit timer to expire.
[K98]と[CKLTZ98]は、TCPのためにさらに電子証券取引ネットワークの利益を分析するために[CKLTZ97]に建てます。 結論はECN TCPが適度に非ECN TCPより良い効率を得るということです。 ECN TCP流れが公正であることは非ECN TCPに向かって流れます。 そして、そのECN TCPは交通、両方の指示、および倍数がある混雑がゲートウェイを充血させた2方法で強健です。 多くの短いウェブ転送を伴う実験は、電子証券取引ネットワークの実験と比べて、背の低い接続の大部分が電子証券取引ネットワークのあるなしにかかわらず同様の転送時を過す間の背の低い接続のわずかな百分率が非電子証券取引ネットワークの実験のための非常に長い転送時を過すのを示します。 彼らの最初のパケットが非電子証券取引ネットワークの実験で落とされて、したがって再送信タイマが期限が切れるのを6秒待たなければならないそれらの背の低い接続には、この増加する転送時間は特に劇的です。
The ECN Web Page [ECN] has pointers to other implementations of ECN in progress.
電子証券取引ネットワークウェブページ[電子証券取引ネットワーク]は進行中の電子証券取引ネットワークの他の実現にポインタを持っています。
Ramakrishnan & Floyd Experimental [Page 16] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[16ページ]RFC2481電子証券取引ネットワーク
12. Conclusions
12. 結論
Given the current effort to implement RED, we believe this is the right time for router vendors to examine how to implement congestion avoidance mechanisms that do not depend on packet drops alone. With the increased deployment of applications and transports sensitive to the delay and loss of a single packet (e.g., realtime traffic, short web transfers), depending on packet loss as a normal congestion notification mechanism appears to be insufficient (or at the very least, non-optimal).
REDを実行するための現在の努力を考えて、私たちは、これがルータ業者が単独でパケット滴によらない輻輳回避メカニズムを実行する方法を調べる正しい時間であると信じています。 遅れに敏感なアプリケーションと輸送の増加する展開と単一のパケット(例えば、リアルタイムで交通、短いウェブ転送)の損失で、正常な混雑通知メカニズムとしてパケット損失によるのが不十分であるように見える、(少なくとも、非最適である、)
13. Acknowledgements
13. 承認
Many people have made contributions to this RFC. In particular, we would like to thank Kenjiro Cho for the proposal for the TCP mechanism for negotiating ECN-Capability, Kevin Fall for the proposal of the CWR bit, Steve Blake for material on IPv4 Header Checksum Recalculation, Jamal Hadi Salim for discussions of ECN issues, and Steve Bellovin, Jim Bound, Brian Carpenter, Paul Ferguson, Stephen Kent, Greg Minshall, and Vern Paxson for discussions of security issues. We also thank the Internet End-to-End Research Group for ongoing discussions of these issues.
多くの人々がこのRFCへの貢献をしました。 特に、安全保障問題の議論のための交渉電子証券取引ネットワーク-能力のためのTCPメカニズム、CWRビットの提案のためのケビンFall、IPv4 Header Checksum Recalculationの材料のためのスティーブ・ブレーク、電子証券取引ネットワーク問題の議論のためのジャマル・ハディ・サリム、スティーブBellovin、ジムBound、ブライアンCarpenter、ポールファーガソン、スティーブン・ケント、グレッグMinshall、およびバーン・パクソンのために提案についてKenjiro Choに感謝申し上げます。 また、私たちはこれらの問題の現在行われている議論についてインターネットのEndから終わりへのResearch Groupに感謝します。
14. References
14. 参照
[AH] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[ああ] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[B97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[B97] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[CKLT98] Chen, C., Krishnan, H., Leung, S., Tang, N., and Zhang,
L., "Implementing ECN for TCP/IPv6", presentation to the
ECN BOF at the L.A. IETF, March 1998, URL
"http://www.cs.ucla.edu/~hari/ecn-ietf.ps".
[CKLT98] 「L.A. IETF、1998年3月、URL" http://www.cs.ucla.edu/~hari/ecn-ietf.ps "の電子証券取引ネットワーク転炉にTCP/IPv6"、プレゼンテーションのための電子証券取引ネットワークを実行する」チェンとC.とクリシュナンとH.とレオンとS.とTang、N.とチャン、L.。
[DIFFSERV] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[DIFFSERV]ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。
[ECN] "The ECN Web Page", URL "http://www-
nrg.ee.lbl.gov/floyd/ecn.html".
[電子証券取引ネットワーク] 「電子証券取引ネットワークウェブページ」、URL「 http://www- nrg.ee.lbl.gov/floyd/ecn.html。」
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload", RFC 2406, November 1998.
[超能力] ケントとS.とR.アトキンソン、「セキュリティ有効搭載量を要約するIP」、RFC2406、1998年11月。
Ramakrishnan & Floyd Experimental [Page 17] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[17ページ]RFC2481電子証券取引ネットワーク
[FJ93] Floyd, S., and Jacobson, V., "Random Early Detection
gateways for Congestion Avoidance", IEEE/ACM
Transactions on Networking, V.1 N.4, August 1993, p.
397-413. URL "ftp://ftp.ee.lbl.gov/papers/early.pdf".
Networkingの上の[FJ93]フロイド、S.とジェーコブソン、V.、「Congestion Avoidanceのための無作為のEarly Detectionゲートウェイ」IEEE/ACM Transactions、V.1 N.4、1993年8月(p)。 397-413. URL" ftp://ftp.ee.lbl.gov/papers/early.pdf "。
[Floyd94] Floyd, S., "TCP and Explicit Congestion Notification",
ACM Computer Communication Review, V. 24 N. 5, October
1994, p. 10-23. URL
"ftp://ftp.ee.lbl.gov/papers/tcp_ecn.4.ps.Z".
[Floyd94] フロイド、S.、「TCPの、そして、明白な混雑通知」、ACMコンピュータCommunication Review、V.24N.5、1994年10月、p。 10-23. URL" ftp://ftp.ee.lbl.gov/papers/tcp_ecn.4.ps.Z "。
[Floyd97] Floyd, S., and Fall, K., "Router Mechanisms to Support
End-to-End Congestion Control", Technical report,
February 1997. URL "http://www-
nrg.ee.lbl.gov/floyd/end2end-paper.html".
[Floyd97]フロイド、S.とFall、K.、「終わりからエンドへの輻輳制御を支えるルータメカニズム」Technicalは1997年2月に報告します。 URL「 http://www- nrg.ee.lbl.gov/floyd/end2end-paper.html。」
[Floyd98] Floyd, S., "The ECN Validation Test in the NS
Simulator", URL "http://www-mash.cs.berkeley.edu/ns/",
test tcl/test/test-all-ecn.
[Floyd98] フロイド、S.、「電子証券取引ネットワークの合法化はナノ秒にシミュレータを検査する」URL" http://www-mash.cs.berkeley.edu/ns/ "が試しにオールtcl/テスト/ecnをテストします。
[K98] Krishnan, H., "Analyzing Explicit Congestion
Notification (ECN) benefits for TCP", Master's thesis,
UCLA, 1998, URL
"http://www.cs.ucla.edu/~hari/software/ecn/
ecn_report.ps.gz".
H. [K98]クリシュナン、「TCPのためにExplicit Congestion Notification(電子証券取引ネットワーク)利益を分析すること」でのMasterの論文、UCLA、1998、「 http://www.cs.ucla.edu/~hari/software/ecn/ ecn_report.ps.gz」というURL。
[FRED] Lin, D., and Morris, R., "Dynamics of Random Early
Detection", SIGCOMM '97, September 1997. URL
"http://www.inria.fr/rodeo/sigcomm97/program.html#ab078".
1997年9月の[フレッド]リン、D.とモリス、R.、「無作為の早期発見の力学」SIGCOMM97年。 URL" http://www.inria.fr/rodeo/sigcomm97/program.html#ab078 "。
[Jacobson88] V. Jacobson, "Congestion Avoidance and Control", Proc.
ACM SIGCOMM '88, pp. 314-329. URL
"ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z".
ジェーコブソンと、「輻輳回避とコントロール」に対する[Jacobson88]、Proc。 ACM SIGCOMM88年、ページ 314-329. URL" ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z "。
[Jacobson90] V. Jacobson, "Modified TCP Congestion Avoidance
Algorithm", Message to end2end-interest mailing list,
April 1990. URL
"ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt".
[Jacobson90]V.ジェーコブソン、「変更されたTCP輻輳回避アルゴリズム」、end2end-関心メーリングリストへのMessage、1990年4月。 URL" ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt "。
[MJV96] S. McCanne, V. Jacobson, and M. Vetterli, "Receiver-
driven Layered Multicast", SIGCOMM '96, August 1996, pp.
117-130.
[MJV96]S.McCanne、V.ジェーコブソンとM.Vetterli、「受信機の駆動Layered Multicast」SIGCOMM96年、1996年8月、ページ 117-130.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
Ramakrishnan & Floyd Experimental [Page 18] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[18ページ]RFC2481電子証券取引ネットワーク
[RFC1141] Mallory, T. and A. Kullberg, "Incremental Updating of
the Internet Checksum", RFC 1141, January 1990.
[RFC1141] マロリー・ワイス症候群とT.とA.Kullberg、「インターネットチェックサムの増加のアップデート」、RFC1141、1990年1月。
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC 1349, July 1992.
[RFC1349] Almquist、P.、「インターネットプロトコル群のサービスのタイプ」、RFC1349、1992年7月。
[RFC1455] Eastlake, D., "Physical Link Security Type of Service",
RFC 1455, May 1993.
[RFC1455]イーストレーク(D.、「物理的なリンクセキュリティタイプのサービス」、RFC1455)は1993がそうするかもしれません。
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001,
January 1997.
[RFC2001] スティーブンスと、W.と、「遅れた出発、輻輳回避が速く再送するTCP、および速い回復アルゴリズム」、RFC2001、1月1997日
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B.,
Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
Minshall, G., Partridge, C., Peterson, L., Ramakrishnan,
K., Shenker, S., Wroclawski, J. and L. Zhang,
"Recommendations on Queue Management and Congestion
Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]ブレーデンとB.とクラークとD.とクロウクロフトとJ.とデイビーとB.とデアリングとS.とEstrinとD.とフロイドとS.とジェーコブソンとV.とMinshallとG.とヤマウズラとC.とピーターソンとL.とRamakrishnanとK.、ShenkerとS.とWroclawskiとJ.とL.チャン、「インターネットの待ち行列管理と輻輳回避の推薦」RFC2309(1998年4月)。
[RJ90] K. K. Ramakrishnan and Raj Jain, "A Binary Feedback
Scheme for Congestion Avoidance in Computer Networks",
ACM Transactions on Computer Systems, Vol.8, No.2, pp.
158-181, May 1990.
[RJ90] K.K.RamakrishnanとRajジャイナ教です、「2進のフィードバックはコンピュータネットワークにおける輻輳回避を計画します」、コンピュータシステムズのACM Transactions、Vol.8、No.2、ページ 158-181と、1990年5月。
15. Security Considerations
15. セキュリティ問題
Security considerations have been discussed in Section 9.
セクション9でセキュリティ問題について議論しました。
16. IPv4 Header Checksum Recalculation
16. IPv4ヘッダーチェックサム再計算
IPv4 header checksum recalculation is an issue with some high-end router architectures using an output-buffered switch, since most if not all of the header manipulation is performed on the input side of the switch, while the ECN decision would need to be made local to the output buffer. This is not an issue for IPv6, since there is no IPv6 header checksum. The IPv4 TOS octet is the last byte of a 16-bit half-word.
IPv4ヘッダーチェックサム再計算は出力でバッファリングされたスイッチを使用するいくつかの上位ルータ構造の問題です、ヘッダー操作の大部分かすべてがスイッチのインプット側に実行されるので、電子証券取引ネットワークの決定は、出力バッファにローカルにする必要があるでしょうが。 IPv6ヘッダーチェックサムが全くないので、これはIPv6のための問題ではありません。 IPv4 TOS八重奏は16ビットのハーフ・ワードの最後のバイトです。
RFC 1141 [RFC1141] discusses the incremental updating of the IPv4 checksum after the TTL field is decremented. The incremental updating of the IPv4 checksum after the CE bit was set would work as follows: Let HC be the original header checksum, and let HC' be the new header checksum after the CE bit has been set. Then for header checksums calculated with one's complement subtraction, HC' would be recalculated as follows:
TTL分野が減少した後にRFC1141[RFC1141]はIPv4チェックサムの増加のアップデートについて議論します。 CEビットが設定された後にIPv4チェックサムの増加のアップデートは以下の通り働いているでしょう: 'HCがオリジナルのヘッダーチェックサムであることをさせてください、そして、HCをさせてください'という後の新しいヘッダーチェックサムがCEであったならビットは設定されました。 'そして、1の補数引き算、HCと共に計算されたヘッダーチェックサム'は以下の通り再計算されるでしょう:
Ramakrishnan & Floyd Experimental [Page 19] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[19ページ]RFC2481電子証券取引ネットワーク
HC' = { HC - 1 HC > 1
{ 0x0000 HC = 1
'HC'が等しい、HC--、1HC>1、0×0000HC=1
For header checksums calculated on two's complement machines, HC' would be recalculated as follows after the CE bit was set:
CEビットが設定された後に'2の補数マシン、HCで計算されたヘッダーチェックサム'は以下の通り再計算されるでしょう:
HC' = { HC - 1 HC > 0
{ 0xFFFE HC = 0
'HC'が等しい、HC--、1HC>0、0xFFFE HC=0
17. The motivation for the ECT bit.
17. ECTビットに関する動機。
The need for the ECT bit is motivated by the fact that ECN will be deployed incrementally in an Internet where some transport protocols and routers understand ECN and some do not. With the ECT bit, the router can drop packets from flows that are not ECN-capable, but can *instead* set the CE bit in flows that *are* ECN-capable. Because the ECT bit allows an end node to have the CE bit set in a packet *instead* of having the packet dropped, an end node might have some incentive to deploy ECN.
電子証券取引ネットワークがいくつかのトランスポート・プロトコルとルータが電子証券取引ネットワークと何かがそうしないのを理解しているインターネットで増加して配備されるという事実によってECTビットの必要性は動機づけられています。 ルータは、ECTビットで、電子証券取引ネットワークできない流れからパケットを落とすことができますが、**はCEが流れで噛み付いたセットですが、*代わりに低下できます。電子証券取引ネットワークできる*。 エンドノードには、*代わりにパケットにECTビットでCEビットを設定できるので、エンドノードでパケットを持つ*は低下して、電子証券取引ネットワークを配備する何らかの誘因があるかもしれません。
If there was no ECT indication, then the router would have to set the CE bit for packets from both ECN-capable and non-ECN-capable flows. In this case, there would be no incentive for end-nodes to deploy ECN, and no viable path of incremental deployment from a non-ECN world to an ECN-capable world. Consider the first stages of such an incremental deployment, where a subset of the flows are ECN-capable. At the onset of congestion, when the packet dropping/marking rate would be low, routers would only set CE bits, rather than dropping packets. However, only those flows that are ECN-capable would understand and respond to CE packets. The result is that the ECN- capable flows would back off, and the non-ECN-capable flows would be unaware of the ECN signals and would continue to open their congestion windows.
ECT指示が全くなければ、ルータは両方からのパケットのための電子証券取引ネットワークできるCEビットを設定しなければならないでしょうに、そして、できる非電子証券取引ネットワークは流れます。 この場合、電子証券取引ネットワークを配備しますが、エンドノードが増加の非電子証券取引ネットワーク世界から電子証券取引ネットワークできる世界までの展開のどんな実行可能な経路も配備しない誘因が全くないでしょう。 そのような増加の展開の最初のステージを考えてください。そこでは、流れの部分集合が電子証券取引ネットワークできます。 パケット低下/マークレートが混雑の開始のときに低いだろうというときにだけ、ルータはパケットを落とすよりむしろCEビットを設定するでしょう。 しかしながら、それらの電子証券取引ネットワークできる流れだけが、CEパケットに分かって、応じるでしょう。 結果が電子証券取引ネットワークのできる流れが引き返すだろうということであり、できる非電子証券取引ネットワーク流れは、電子証券取引ネットワーク信号に気づかないだろう、それらの混雑ウィンドウを開け続けているでしょう。
In this case, there are two possible outcomes: (1) the ECN-capable flows back off, the non-ECN-capable flows get all of the bandwidth, and congestion remains mild, or (2) the ECN-capable flows back off, the non-ECN-capable flows don't, and congestion increases until the router transitions from setting the CE bit to dropping packets. While this second outcome evens out the fairness, the ECN-capable flows would still receive little benefit from being ECN-capable, because the increased congestion would drive the router to packet- dropping behavior.
この場合、2つの可能な結果があります: (1) (2) できる非電子証券取引ネットワーク流れは帯域幅のすべてを得ます、そして、電子証券取引ネットワークできる流れは引き返します、そして、できる非電子証券取引ネットワーク流れは増加しません、そして、電子証券取引ネットワークできる流れが引き返すか、混雑が温和なままで残っているか、またはルータがパケットを落とすのにCEビットを設定するので移行するまで、混雑は増加します。 この2番目の結果が公正をならしている間、電子証券取引ネットワークできる流れは電子証券取引ネットワークできるのから利益をまだほとんど受け取っていないでしょう、増加する混雑が振舞いを落としながら、パケットにルータを動かすでしょう、したがって。
A flow that advertised itself as ECN-Capable but does not respond to CE bits is functionally equivalent to a flow that turns off congestion control, as discussed in Sections 8 and 9.
電子証券取引ネットワークできるとして自分を売り込みますが、CEビットまで応じない流れは輻輳制御をオフにする流れに機能上同等です、セクション8と9で議論するように。
Ramakrishnan & Floyd Experimental [Page 20] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[20ページ]RFC2481電子証券取引ネットワーク
Thus, in a world when a subset of the flows are ECN-capable, but where ECN-capable flows have no mechanism for indicating that fact to the routers, there would be less effective and less fair congestion control in the Internet, resulting in a strong incentive for end nodes not to deploy ECN.
したがって、それほど有効でなくてまたそれほど公正でない輻輳制御がインターネットに流れの部分集合が電子証券取引ネットワークできますが、電子証券取引ネットワークできる流れがその事実をルータに示すためのメカニズムを全く持っていない世界にあるでしょう、エンドノードが電子証券取引ネットワークを配備しない強い動機をもたらして。
18. Why use two bits in the IP header?
18. なぜIPヘッダーで2ビットを使用しますか?
Given the need for an ECT indication in the IP header, there still remains the question of whether the ECT (ECN-Capable Transport) and CE (Congestion Experienced) indications should be overloaded on a single bit. This overloaded-one-bit alternative, explored in [Floyd94], would involve a single bit with two values. One value, "ECT and not CE", would represent an ECN-Capable Transport, and the other value, "CE or not ECT", would represent either Congestion Experienced or a non-ECN-Capable transport.
IPヘッダーのECT指示の必要性を考えて、ビットはまだシングルでのECT(電子証券取引ネットワークできるTransport)とCE(混雑Experienced)指摘が積みすぎられるべきであるかどうかに関する質問のままで残っています。 [Floyd94]で探られたこの積みすぎられた1ビットの代替手段は2つの値に1ビットを伴うでしょう。 「Ceではなく、ECT」という1つの値が電子証券取引ネットワークできるTransportを表すでしょう、そして、「ECTではなく、Ce」というもう片方の値はCongestion Experiencedかできる非電子証券取引ネットワークの輸送のどちらかを表すでしょう。
One difference between the one-bit and two-bit implementations concerns packets that traverse multiple congested routers. Consider a CE packet that arrives at a second congested router, and is selected by the active queue management at that router for either marking or dropping. In the one-bit implementation, the second congested router has no choice but to drop the CE packet, because it cannot distinguish between a CE packet and a non-ECT packet. In the two-bit implementation, the second congested router has the choice of either dropping the CE packet, or of leaving it alone with the CE bit set.
1ビットの、そして、安っぽい実現の1つの違いが複数の混雑しているルータを横断するパケットに関係があります。 2番目の混雑しているルータに到着して、マークか低下のためにそのルータで活発な待ち行列管理によって選択されるCEパケットを考えてください。 1ビットの実現では、2番目の混雑しているルータはCEパケットを落とさざるを得ません、CEパケットと非ECTパケットを見分けることができないので。 安っぽい実現では、2番目の混雑しているルータはCEパケットを落とすか、またはCEビットがセットした状態でそれを放っておくことの選択を持っています。
Another difference between the one-bit and two-bit implementations comes from the fact that with the one-bit implementation, receivers in a single flow cannot distinguish between CE and non-ECT packets. Thus, in the one-bit implementation an ECN-capable data sender would have to unambiguously indicate to the receiver or receivers whether each packet had been sent as ECN-Capable or as non-ECN-Capable. One possibility would be for the sender to indicate in the transport header whether the packet was sent as ECN-Capable. A second possibility that would involve a functional limitation for the one- bit implementation would be for the sender to unambiguously indicate that it was going to send *all* of its packets as ECN-Capable or as non-ECN-Capable. For a multicast transport protocol, this unambiguous indication would have to be apparent to receivers joining an on-going multicast session.
1ビットの、そして、安っぽい実現の別の違いは1ビットの実現で、ただ一つの流れにおける受信機がCEと非ECTパケットを見分けることができないという事実から来ます。 したがって、1ビットの実現では、電子証券取引ネットワーク有能なデータ送付者は、明白に各パケットが電子証券取引ネットワークできることとして、または、できる非電子証券取引ネットワークとして送られたかどうかを受信機か受信機に示さなければならないでしょう。 1つの可能性は送付者が、輸送ヘッダーでパケットが電子証券取引ネットワークできるとして送られたかどうかを示すだろうことです。 1ビットの実現のための機能的制約にかかわる2番目の可能性は送付者が、電子証券取引ネットワークできることとして、または、できる非電子証券取引ネットワークとしてパケットのすべての*を*に送るつもりであったのを明白に示すだろうことです。 マルチキャストトランスポート・プロトコルにおいて、この明白な指示は継続しているマルチキャストセッションに参加する受信機に明らかでなければならないでしょう。
Another advantage of the two-bit approach is that it is somewhat more robust. The most critical issue, discussed in Section 8, is that the default indication should be that of a non-ECN-Capable transport. In a two-bit implementation, this requirement for the default value simply means that the ECT bit should be `OFF' by default. In the
安っぽいアプローチの別の利点はそれがいくらか強健であるということです。 セクション8で議論する中で最も批判的な問題はデフォルト指示ができる非電子証券取引ネットワークの輸送のものであるべきであるということです。 安っぽい実現では、デフォルト値のためのこの要件は、単にECTビットがデフォルトで'OFF'であるべきであると意味します。 in
Ramakrishnan & Floyd Experimental [Page 21] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[21ページ]RFC2481電子証券取引ネットワーク
one-bit implementation, this means that the single overloaded bit should by default be in the "CE or not ECT" position. This is less clear and straightforward, and possibly more open to incorrect implementations either in the end nodes or in the routers.
1ビットの実現、単一の積みすぎられたビットがデフォルトで「ECTではなく、Ce」位置にあるはずであるこの手段。 これは、それほど明確でなくて、簡単で、ことによるとエンドノードかルータにおける不正確な実現によりオープンです。
In summary, while the one-bit implementation could be a possible implementation, it has the following significant limitations relative to the two-bit implementation. First, the one-bit implementation has more limited functionality for the treatment of CE packets at a second congested router. Second, the one-bit implementation requires either that extra information be carried in the transport header of packets from ECN-Capable flows (to convey the functionality of the second bit elsewhere, namely in the transport header), or that senders in ECN-Capable flows accept the limitation that receivers must be able to determine a priori which packets are ECN-Capable and which are not ECN-Capable. Third, the one-bit implementation is possibly more open to errors from faulty implementations that choose the wrong default value for the ECN bit. We believe that the use of the extra bit in the IP header for the ECT-bit is extremely valuable to overcome these limitations.
概要では、1ビットの実現は可能な実現であるかもしれませんが、それは安っぽい実現に比例して以下の重要な制限を持っています。 まず最初に、1ビットの実現は2番目の混雑しているルータでCEパケットの処理のための、より限られた機能性を持っています。 2番目に、1ビットの実現がパケットの輸送ヘッダーで電子証券取引ネットワークできる流れ(すなわち、ほかの場所、輸送ヘッダーの2番目のビットの機能性を伝える)から運ばれた状態でその他の情報があるどちらかを必要とするか、または電子証券取引ネットワークできる流れにおける送付者は、受信機が決定できなければならない制限が先験的であると受け入れます(それのパケットが電子証券取引ネットワークできて、電子証券取引ネットワークできません)。 3番目に、電子証券取引ネットワークビットにおいて、1ビットの実現はことによると間違ったデフォルト値を選ぶ不完全な実現からの誤りにより開かれています。 私たちは、IPヘッダーにおける、余分なビットのECT-ビットの使用がこれらの限界を克服するのにおいて非常に貴重であると信じています。
19. Historical definitions for the IPv4 TOS octet
19. IPv4 TOS八重奏のための歴史的な定義
RFC 791 [RFC791] defined the ToS (Type of Service) octet in the IP header. In RFC 791, bits 6 and 7 of the ToS octet are listed as "Reserved for Future Use", and are shown set to zero. The first two fields of the ToS octet were defined as the Precedence and Type of Service (TOS) fields.
RFC791[RFC791]はIPヘッダーでToS(Serviceのタイプ)八重奏を定義しました。 RFC791では、ToS八重奏のビット6と7は、「今後の使用のために、予約される」ように記載されていて、ゼロへのセットに見せられます。 ToS八重奏の最初の2つの分野がService(TOS)分野のPrecedenceとTypeと定義されました。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | 0 | 0 | RFC 791
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 先行| TOS| 0 | 0 | RFC791+-----+-----+-----+-----+-----+-----+-----+-----+
RFC 1122 included bits 6 and 7 in the TOS field, though it did not discuss any specific use for those two bits:
RFC1122はTOS分野にビット6と7を含んでいました、それらの2ビットの少しの特定的用法についても議論しませんでしたが:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | RFC 1122
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 先行| TOS| RFC1122+-----+-----+-----+-----+-----+-----+-----+-----+
The IPv4 TOS octet was redefined in RFC 1349 [RFC1349] as follows:
IPv4 TOS八重奏は以下のRFC1349[RFC1349]に再定義されました:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | MBZ | RFC 1349
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 先行| TOS| MBZ| RFC1349+-----+-----+-----+-----+-----+-----+-----+-----+
Ramakrishnan & Floyd Experimental [Page 22] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[22ページ]RFC2481電子証券取引ネットワーク
Bit 6 in the TOS field was defined in RFC 1349 for "Minimize Monetary Cost". In addition to the Precedence and Type of Service (TOS) fields, the last field, MBZ (for "must be zero") was defined as currently unused. RFC 1349 stated that "The originator of a datagram sets [the MBZ] field to zero (unless participating in an Internet protocol experiment which makes use of that bit)."
TOS分野のビット6は「貨幣原価を最小にしてください」のためにRFC1349で定義されました。 Service(TOS)分野、最後の分野、MBZのPrecedenceとTypeに加えた(「ゼロでなければならない」、)、現在未使用と定義されました。 「データグラムの創始者はゼロ(そのビットを利用するインターネットプロトコル実験に参加しない場合)に[MBZ]分野を設定します。」と、RFC1349は述べました。
RFC 1455 [RFC 1455] defined an experimental standard that used all four bits in the TOS field to request a guaranteed level of link security.
RFC1455[RFC1455]は保証されたレベルのリンクセキュリティを要求するのにTOS分野ですべての4ビットを使用した実験規格を定義しました。
RFC 1349 is obsoleted by "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" [DIFFSERV], in which bits 6 and 7 of the DS field are listed as Currently Unused (CU). The first six bits of the DS field are defined as the Differentiated Services CodePoint (DSCP):
「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」[DIFFSERV]でRFC1349は時代遅れにされます。(DS分野のビット6と7はCurrently Unused(CU)としてそれで記載されています)。 DS分野の最初の6ビットはDifferentiated Services CodePoint(DSCP)と定義されます:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DSCP | CU |
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DSCP| Cu| +-----+-----+-----+-----+-----+-----+-----+-----+
Because of this unstable history, the definition of the ECN field in this document cannot be guaranteed to be backwards compatible with all past uses of these two bits. The damage that could be done by a non-ECN-capable router would be to "erase" the CE bit for an ECN- capable packet that arrived at the router with the CE bit set, or set the CE bit even in the absence of congestion. This has been discussed in Section 10 on "Non-compliance in the Network".
この不安定な歴史のために、後方にこれらの2ビットの過去のすべての用途と互換性があった状態であるように本書では電子証券取引ネットワーク分野の定義を保証できません。 できる非電子証券取引ネットワークルータで与えられることができた損害は、CEビットがセットした状態でルータに到着した電子証券取引ネットワークのできるパケットのためにCEビットを「消す」か、または混雑がないときでさえCEビットを設定するだろうことです。 「ネットワークにおける不承諾」のときにセクション10でこれについて議論しました。
The damage that could be done in an ECN-capable environment by a non-ECN-capable end-node transmitting packets with the ECT bit set has been discussed in Section 9 on "Non-compliance by the End Nodes".
「エンドノードによる不承諾」のときにセクション9でECTビットがセットした状態でパケットを伝えるできる非電子証券取引ネットワークエンドノードで電子証券取引ネットワークできる環境で与えられることができた損害について議論しました。
Ramakrishnan & Floyd Experimental [Page 23] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[23ページ]RFC2481電子証券取引ネットワーク
AUTHORS' ADDRESSES
作者のアドレス
K. K. Ramakrishnan AT&T Labs. Research
K.K.Ramakrishnan AT&T研究室。 研究
Phone: +1 (973) 360-8766 EMail: kkrama@research.att.com URL: http://www.research.att.com/info/kkrama
以下に電話をしてください。 +1 (973) 360-8766 メールしてください: kkrama@research.att.com URL: http://www.research.att.com/info/kkrama
Sally Floyd Lawrence Berkeley National Laboratory
サリー・フロイド・ローレンス・バークレー国家の研究所
Phone: +1 (510) 486-7518 EMail: floyd@ee.lbl.gov URL: http://www-nrg.ee.lbl.gov/floyd/
以下に電話をしてください。 +1 (510) 486-7518 メールしてください: floyd@ee.lbl.gov URL: http://www-nrg.ee.lbl.gov/floyd/
Ramakrishnan & Floyd Experimental [Page 24] RFC 2481 ECN to IP January 1999
IP1999年1月へのRamakrishnanとフロイド実験的な[24ページ]RFC2481電子証券取引ネットワーク
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Ramakrishnan & Floyd Experimental [Page 25]
RamakrishnanとフロイドExperimentalです。[25ページ]
一覧
スポンサーリンク
