[要約] RFC 2481は、IPに明示的な輻輳通知（ECN）を追加する提案であり、輻輳制御の改善を目的としています。
Network Working Group K. Ramakrishnan
Request for Comments: 2481 AT&T Labs Research
Category: Experimental S. Floyd
LBNL
January 1999
A Proposal to add Explicit Congestion Notification (ECN) to IP
明示的な輻輳通知（ECN）をIPに追加する提案
Status of this 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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準も規定していません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
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.
このノートでは、IPへのECN（Explicit Congestion Notification）の追加案について説明します。現在、TCPはインターネットで使用されている主要なトランスポートプロトコルです。まず、TCPによるパケットドロップの使用を輻輳の指標として説明します。次に、インターネットインフラストラクチャにアクティブキュー管理（REDなど）を追加すると、キューがオーバーフローする前にルーターが輻輳を検出するため、ルーターは輻輳の兆候としてパケットドロップに限定されなくなります。代わりに、ルーターはECN対応のトランスポートプロトコルからのパケットのパケットヘッダーにCongestion Experienced（CE）ビットを設定できます。ルータでCEビットが設定されるタイミングと、ECN対応にするためにTCPに必要な変更について説明します。他のトランスポートプロトコル（たとえば、信頼性の低いユニキャストまたはマルチキャスト、信頼性の高いマルチキャスト、その他の信頼性の高いユニキャストトランスポートプロトコル）への変更は、それらのプロトコルが開発され、標準プロセスを通じて進歩するためと考えられます。
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]で説明されているように解釈する必要があります（必須、必須ではない、必須、必須、必須ではない、必須、推奨ではありません）。
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の輻輳管理アルゴリズムには、スループットの観点からの損失の影響を最小限に抑えるための技術（高速再送信や高速回復など）が組み込まれています。
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つ以上の個々のパケットの遅延または損失に実際に敏感なアプリケーションを支援することを意図したものではありません。 Telnet、Webブラウジング、オーディオおよびビデオデータの転送などのインタラクティブトラフィックは、パケット損失（UDPなどの信頼性の低いデータ配信トランスポートを使用）またはパケットの再送信の必要性によって引き起こされるパケットの遅延の増加に影響されます損失後（TCPなどの信頼性の高いデータ配信用）。
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は、パケットのドロップが発生するまでウィンドウサイズを徐々に増やして、使用する適切な輻輳ウィンドウを決定するため、ボトルネックルーターのキューが構築されます。個々のフローによる負荷に影響されないルーターでのほとんどのパケットドロップポリシーでは、遅延に影響されやすいフローの一部のパケットがドロップされます。アクティブなキュー管理メカニズムは、キューがオーバーフローする前に輻輳を検出し、この輻輳の兆候をエンドノードに提供します。アクティブキュー管理の利点は、RFC 2309 [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 routers to use the Congestion Experienced (CE) bit in a packet header as an indication of congestion, instead of relying solely on packet drops.
アクティブなキュー管理メカニズムは、エンドノードへの輻輳を示すためにいくつかの方法の1つを使用する場合があります。 1つは、現在行われているように、パケットドロップを使用することです。ただし、アクティブキュー管理により、ルータは、パケットをキューイングまたはドロップするポリシーを、輻輳を示すポリシーから分離できます。したがって、アクティブキュー管理により、ルーターはパケットドロップのみに依存するのではなく、パケットヘッダーのCongestion Experienced（CE）ビットを輻輳の指標として使用できます。
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）ECNは徐々に採用される可能性が高いため、移行に対応することが不可欠です。一部のルーターは依然として輻輳を示すためにパケットをドロップするだけであり、一部のエンドシステムはECNに対応していない場合があります。最も実行可能な戦略は、ECN対応環境と非ECN対応環境の「島」に頼ることなく段階的な導入に対応できる戦略です。 （5）非対称ルーティングは、インターネットでは通常発生する可能性があります。データパケットが続くパス（リンクとルーターのシーケンス）は、逆方向に確認応答パケットが続くパスとは異なる場合があります。 （6）多くのルーターは、IPオプションのヘッダー情報を処理するよりもIPパケットの「通常の」ヘッダーを効率的に処理します。これは、IPパケットの通常のヘッダーに輻輳の発生した情報を保持することを示唆しています。 （7）すべてのエンドシステムが輻輳制御のメカニズムで協力するわけではないことを認識しなければなりません。ただし、新しいメカニズムによって、TCPアプリケーションがTCPの輻輳制御を無効にすることが容易になるわけではありません。 ECN機能などの新しいメカニズムへの参加について嘘をつくことの利点は小さいはずです。
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 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）は、初期の輻輳を検出するために提案されたアクティブキュー管理のメカニズム[FJ93]であり、現在インターネットバックボーン[RFC2309]に展開されています。 REDは、輻輳表示のいくつかの選択肢の1つを使用する一般的なメカニズムであることを意図していますが、インターネットの現在の環境では、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ビットが設定されたパケットを示します。
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]のように）。これには、IPヘッダーに2ビットのECNフィールドが必要です。 ECN対応トランスポート（ECT）ビットは、トランスポートプロトコルのエンドポイントがECN対応であることを示すために、データ送信者によって設定されます。エンドノードへの輻輳を示すために、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は、ECNフィールドとして指定されています。ビット6はECTビットとして指定され、ビット7はCEビットとして指定されます。 IPv4 TOSオクテットは、IPv6のトラフィッククラスオクテットに対応しています。 IPv4 TOSオクテット[RFC791]およびIPv6トラフィッククラスオクテットの定義は、DS（Differentiated Services）フィールド[DIFFSERV]によって置き換えられることを目的としています。ビット6と7は、現在未使用として[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オクテットの不安定な履歴のため、このドキュメントで指定されているECNフィールドの使用は、これらの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 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.
単一のCEパケットをECN対応トランスポートが受信すると、エンドシステムで実行される輻輳制御アルゴリズムは、*単一*のドロップされたパケットに対する輻輳制御応答と基本的に同じでなければなりません（MUST）。たとえば、ECN対応のTCPの場合、送信元TCPは、パケットドロップまたはECN表示のいずれかを含むデータのウィンドウに対して輻輳ウィンドウを半分にする必要があります。ただし、TCPの特定の実装のより短い時間スケールの詳細に従うことに関して、ソースTCPの反応におけるいくつかの注目すべき例外を指摘したいと思います。 ECNインジケーションに対するTCPの応答については、パケットドロップに応じたTahoe TCPのスロースタート、または高速復旧中のラウンドトリップ時間の約半分のReno TCPの待機などの動作はお勧めしません。
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つの理由は、エンドシステムとルーターの両方でECNの増分展開に対応するためです。一部のルーターはECN対応パケットをドロップする可能性があります（たとえば、輻輳検出に同じREDポリシーを使用）。他のルーターは、同等レベルの輻輳に対してCEビットを設定します。同様に、ルーターは、ECN非対応パケットをドロップする可能性がありますが、同等レベルの輻輳では、ECN対応パケットに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.
追加要件は、ラウンドトリップ時間内の輻輳の複数の兆候に対する複数回の反応を回避するために、データのウィンドウごとに最大1回（つまり、ラウンドトリップ時間ごとに最大1回）エンドシステムが輻輳に反応する必要があることです。
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.
ルーターの場合、ECN対応パケットのCEビットは、ルーターが他の方法でエンドノードへの輻輳を示すものとしてパケットをドロップした場合にのみ設定する必要があります。ルーターのバッファーがまだいっぱいではなく、ルーターがパケットをドロップしてエンドノードに初期の輻輳を通知する準備ができている場合、ルーターはまず、そのパケットのIPヘッダーにECTビットが設定されているかどうかを確認する必要があります。その場合、パケットをドロップする代わりに、ルーターは代わりにIPヘッダーのCEビットを設定してもよい（MAY）。
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.
すべてのエンドノードがECN対応である環境では、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 transients or in the presence of non-cooperating sources.
ルータがCEパケットを受信すると、CEビットは変更されず、パケットは通常どおり送信されます。深刻な輻輳が発生し、ルーターのキューがいっぱいになると、ルーターは新しいパケットが到着したときに一部のパケットをドロップするしかありません。大部分のエンドシステムがECN対応になり、TCPまたは他の互換性のある輻輳制御メカニズムに参加すると、このようなパケット損失は比較的まれになると予想しています。このようなECN対応環境で適切にプロビジョニングされたネットワークでは、パケットの損失は、主に一時的な状態の間、または非協力的なソースの存在下で発生するはずです。
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.
[FJ93、RFC2309]で提案されているREDアルゴリズムを使用して、平均キューサイズによって示されるように、ルーターが初期の輻輳に応答してCEビットを設定すると予想されます。私たちの知る限りでは、これはバッファがオーバーフローする前にルーターが積極的にパケットをドロップするためのIETFで現在議論されている唯一の提案です。ただし、このドキュメントでは、アクティブキュー管理の特定のメカニズムを指定することは試みず、必要に応じて、IETFの他の領域にその取り組みを任せています。 ECNはルーターでアクティブなキュー管理と密接に結びついていますが、その逆は成り立ちません。アクティブキュー管理メカニズムは、IPアーキテクチャにECNがない場合の輻輳の指標としてパケットドロップを使用して、ECNとは別に開発および展開されています。
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.
ECNは、IPパケットヘッダーのECNフィールドによって提供される機能に加えて、トランスポートプロトコルからのサポートを必要とします。トランスポートプロトコルは、セットアップ中にエンドポイント間のネゴシエーションを要求して、すべてのエンドポイントがECN対応であることを確認し、送信者が送信パケットにECTビットを設定できるようにします。次に、トランスポートプロトコルは、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.
このドキュメントでは、TCPへのECN機能の追加のみを扱い、ECNおよびその他のトランスポートプロトコルの問題はさらに調査する必要があります。 TCPの場合、ECNには3つの新しいメカニズムが必要です。セットアップ中にエンドポイント間でネゴシエーションを行い、両方がECN対応かどうかを判断します。 TCPヘッダー内のECN-Echoフラグ。CEパケットが受信されたときにデータ受信者がデータ送信者に通知できるようにします。また、TCPヘッダーのCongestion Window Reduced（CWR）フラグにより、データ送信者はデータ受信者に輻輳ウィンドウが減少したことを通知できます。他のトランスポートプロトコルに必要なサポートは、特に信頼性の低いまたは信頼性の高いマルチキャストトランスポートプロトコルの場合は異なる可能性が高く、他のトランスポートプロトコルが標準化のためにIETFに持ち込まれるときに決定する必要があります。
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でのECNの提案された使用について詳しく説明します。この提案は、[Floyd94]と基本的に同じ形式で説明されています。ソースTCPは、スロースタート、高速再送信、高速リカバリの標準的な輻輳制御アルゴリズムを使用すると想定しています[RFC 2001]。
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つの新しいフラグを指定しています。 ECN機能をネゴシエートするためのTCPメカニズムは、TCPヘッダーのECN-Echoフラグを使用します。 （これは、以前の一部のドキュメントではECN通知フラグと呼ばれていました。）TCPヘッダーの予約フィールドのビット9は、ECN-Echoフラグとして指定されています。 RFC 793 [RFC793]の図3に、TCPヘッダーの6ビット予約フィールドの場所を示します。
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レシーバーがECN-Echoフラグの設定をいつ停止するかを決定できるようにするために、TCPヘッダーに2番目の新しいフラグであるCongestion Window Reduced（CWR）フラグを導入します。 CWRフラグは、TCPヘッダーのReservedフィールドのビット8に割り当てられています。
The use of these flags is described in the sections below.
これらのフラグの使用については、以下のセクションで説明します。
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接続セットアップフェーズでは、送信元TCPと宛先TCPは、ECNを使用するという要望や機能に関する情報を交換します。このネゴシエーションの完了後、TCP送信者はデータパケットのIPヘッダーにECTビットを設定して、トランスポートがこのパケットのECNに参加でき、ECNに参加する意思があることをネットワークに示します。これは、ルーターに輻輳通知の方法としてCEビットを使用したい場合に、このパケットをCEビットでマークできることをルーターに示します。 TCP接続が特定のパケットにECN通知を使用したくない場合、送信側TCPはECTビットを0に設定し（つまり、設定しません）、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 flag set by reducing the congestion window when appropriate.
ノードがTCP SYNパケットを送信すると、TCPヘッダーにECN-EchoフラグとCWRフラグが設定される場合があります。 SYNパケットの場合、ECN-EchoフラグとCWRフラグの両方の設定は、輻輳または輻輳への応答を示すものとしてではなく、送信TCPがECN対応であることを示すものとして定義されます。より正確には、ECN-EchoフラグとCWRフラグの両方が設定されたSYNパケットは、SYNパケットを送信するTCP実装が送信者と受信者の両方としてECNに参加することを示します。受信側として、発信TCP確認応答（ACK）パケットにECN-Echoフラグを設定することにより、IPヘッダーにCEビットが設定されている着信データパケットに応答します。送信者として、適切なときに輻輳ウィンドウを減らすことにより、ECN-Echoフラグが設定されている着信パケットに応答します。
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パケットを送信すると、ノードはECN-Echoフラグを設定できますが、CWRフラグは設定しません。 SYN-ACKパケットの場合、TCPヘッダーに設定されていないECN-EchoフラグとCWRフラグのパターンは、SYN-ACKパケットを送信するTCPがECN対応であることを示します。
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.
SYNを送信するTCPがSYNパケットのTCPヘッダーの予約済みフィールドに2つのECN関連のフラグを設定するのに対し、SYN-ACKを送信する応答するTCPがECN関連のフラグを1つだけ設定するのはなぜかという疑問があります。 SYN-ACKパケット内。この非対称性は、展開されたTCP実装とのECN機能の強力なネゴシエーションに必要です。少なくとも1つのTCP実装が存在します。TCPレシーバーは、ACKパケットのTCPヘッダーの予約フィールド（したがってSYN-ACK）を設定して、受信したデータパケットのTCPヘッダーの予約フィールドを単純に反映します。 TCP SYNパケットはECN-EchoフラグとCWRフラグを設定してECN機能を示すので、SYN-ACKパケットはECN-Echoフラグのみを設定するため、送信側TCPは、Reservedフィールド内の自身のフラグの反射を次のように正しく解釈します受信者がECNに対応していないことを示します。
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.
ECNを使用するTCP接続の場合、データパケットは、IPヘッダーに設定されたECTビット（「1」に設定）で送信されます。送信者がECN-Echo ACKパケット（つまり、TCPヘッダーにECN-Echoフラグが設定されたACKパケット）を受信すると、送信者は、送信者から受信者へのパス上のネットワークで輻輳が発生したことを認識します。輻輳の兆候は、ECN非対応TCPでの輻輳損失と同様に扱われる必要があります。つまり、TCPソースは輻輳ウィンドウ「cwnd」を半分にして、スロースタートしきい値「ssthresh」を減らします。送信側TCPは、ECN-Echo 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がデータのウィンドウごとに2回以上（またはより緩やかに、ラウンドトリップ時間ごとに複数回）輻輳表示に反応しないことです。つまり、TCP送信側の輻輳ウィンドウは、単一のデータウィンドウからの一連のドロップされたパケットやCEパケットに応じて1回だけ削減する必要があります。さらに、TCPソースはスロースタートしきい値ssthreshを減らしてはなりません。最後の往復時間内に減少しました。ただし、再送信されたパケットがドロップされるか、CEビットが設定されている場合、これはソースTCPによって新しい輻輳のインスタンスとして解釈されます。
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パケットに応答して輻輳ウィンドウを減らした後、到着し続ける着信確認は、減少した輻輳ウィンドウによって許可されるように、発信パケットを「クロックアウト」できます。輻輳ウィンドウが1つのMSS（最大セグメントサイズ）のみで構成されていて、送信側TCPがECN-Echo ACKパケットを受信する場合、送信側TCPは、原則として依然として輻輳ウィンドウを半分に減らす必要があります。ただし、輻輳ウィンドウの値は、1つのMSSの値によって制限されます。送信側TCPが1 MSSの輻輳ウィンドウを使用して送信を継続する場合、これにより、往復時間あたり1つのパケットが送信されます。輻輳ウィンドウが1の場合、ECN-Echoパケットを受信すると、TCP送信側の送信レートをさらに下げることが望ましいと考えています。この状況でレートをさらに下げる手段として再送信タイマーを使用します。したがって、輻輳ウィンドウが1の場合、送信TCPはECN-Echoパケットの受信時に再送信タイマーもリセットする必要があります。送信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]は、ECNに対するTCPの応答について詳しく説明しています。 [Floyd98]は、さまざまなECNシナリオを示すnsシミュレータでの検証テストについて説明しています。これらのシナリオには、次のものが含まれます。ECNに続く別のECN、高速再送信、または再送信タイムアウト。再送信タイムアウトまたは高速再送信の後にECNが続き、1つのパケットの輻輳ウィンドウの後にECNが続きます。
TCP follows existing algorithms for sending data packets in response to incoming ACKs, multiple duplicate acknowledgements, or retransmit timeouts [RFC2001].
TCPは、着信ACK、複数の重複確認応答、または再送信タイムアウト[RFC2001]に応答してデータパケットを送信するための既存のアルゴリズムに従います。
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ヘッダーにECN-Echoフラグを設定します。現在の「遅延ACK」TCP実装のように実装されたACK源泉徴収がある場合、TCP受信者は到着する2つのデータパケットに対してACKを送信できるため、ACKパケットのECN-Echoフラグは、確認応答されるすべてのデータパケットのCEビット。つまり、受信したデータパケットのいずれかがCEパケットの場合、返されるACKにはECN-Echoフラグが設定されます。
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.
ECN-Echoフラグを運ぶドロップされたACKパケットの可能性に対する堅牢性を提供するために、TCPレシーバーは一連のACKパケットでECN-Echoフラグを設定する必要があります。 TCPレシーバーはCWRフラグを使用して、ECN-Echoフラグの設定をいつ停止するかを決定します。
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.
ECN対応のTCPが何らかの理由（再送信タイムアウト、高速再送信、またはECN通知への応答のため）で輻輳ウィンドウを減らすと、TCPは、後に送信される最初のデータパケットのTCPヘッダーにCWRフラグを設定しますウィンドウの縮小。そのデータパケットがネットワークでドロップされると、送信側TCPは再び輻輳ウィンドウを縮小して、ドロップされたパケットを再送信する必要があります。したがって、輻輳ウィンドウ削減メッセージは確実にデータ受信者に配信されます。
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レシーバーがECN-Echoビットが設定されたACKパケットを送信した後、そのTCPレシーバーは、CWRパケット（CWRフラグが設定されたパケット）を受信するまで、ACKパケットにECN-Echoフラグを設定し続けます。 CWRパケットの受信後、後続の非CEデータパケットの確認応答には、ECN-Echoフラグが設定されていません。別のCEパケットがデータレシーバーによって受信された場合、レシーバーはECN-Echoフラグが設定されたACKパケットをもう一度送信します。 CWRパケットを受信しても、データ送信者がECN-Echoメッセージを受信したことは保証されませんが、これは、データ送信者が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送信側が輻輳ウィンドウを減らすのは、データのウィンドウごとに最大で1回であるとすでに指定しています。このメカニズムでは、送信者が輻輳ウィンドウをECN通知ごとに最大1回削減し、複数の連続するデータウィンドウにまたがる複数のECNメッセージがECN送信者に適切に報告されるように注意する必要があります。これは[Floyd98]でさらに議論されています。
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実装では、1つのドロップされたACKは、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 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.
IPヘッダーには、ECN対応トランスポート（ECT）ビットと輻輳経験（CE）ビットの2ビットを指定する必要があります。 ECTビットを "0"に設定すると、トランスポートプロトコルがCEビットを無視することを示します。これは、ECTビットのデフォルト値です。 「1」に設定されたECTビットは、トランスポートプロトコルがECNに参加する意思があり、参加できることを示します。
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"です。ルータはCEビットを「1」に設定して、エンドノードに輻輳を示します。パケットヘッダーのCEビットは、ルーターによって「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つの変更、両方のエンドノードがECN対応かどうかを判断するためのセットアップ時のネゴシエーションフェーズ、およびTCPフラグフィールドの「予約済み」フラグからの、TCPヘッダーの2つの新しいフラグが必要です。 ECN-Echoフラグは、受信したCEパケットをデータ送信者に通知するためにデータ受信者によって使用されます。輻輳ウィンドウ削減フラグは、データ送信者が輻輳ウィンドウが削減されたことをデータ受信者に通知するために使用されます。
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およびフレームリレーメカニズムは、通常、中間ノードが輻輳していると判断するための基準として、平均キューサイズの概念なしで定義されているため、非常にノイズの多い信号を提供すると考えられます。このドラフトでECNに指定されているTCP送信者の反応は、輻輳通知のそのようなノイズの多い信号に対する適切な反応ではありません。 ATMのEFCIおよびフレームリレーのFECNメカニズムが、ATMネットワーク内で徐々に廃止されることが期待されています。ただし、ATMネットワークに接続するルーターに、インターフェースで平均キューを維持する方法があり、ATMサブネットが混雑しているという信頼できる判断を下すために使用する場合、ここで定義されているECN通知を使用できます。
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 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.
IPパケット内のCEビットが設定された*単一の*パケットは、輻輳制御の観点から、トランスポート層がパケットのドロップと同様に応答することを強調します。そのため、CEビットは、瞬間的なキューサイズに基づく信号などの一時的な信号とはあまり一致しません。ただし、レイヤ2の技術（ATMスイッチやフレームリレースイッチなど）での実験は推奨されます。たとえば、RED（パケットマーキングがしきい値を超える平均キュー長に基づいている）などのスキームを使用すると、レイヤー2デバイスは、輻輳の合理的に信頼できる指標を提供できます。パス内のすべてのレイヤー2デバイスがそのレイヤー自体の輻輳経験ビット（ATMのEFCIビット、フレームリレーのFECNビットなど）をこの信頼できる方法で設定すると、レイヤー2ネットワークへのインターフェイスルーターが状態をコピーできます。そのレイヤ2の輻輳経験ビットのIPヘッダーのCEビットへの。これは現在の慣行ではなく、現在の基準でもないことを認識しています。ただし、この方法で実験を奨励すると、既存のレイヤ2メカニズムが輻輳を示すために単一ビットを使用するときに、輻輳表示の信頼性の高い手段を提供するために必要な情報が提供される場合があります。
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パケットに応答しないエンドノード）に対するECNの脆弱性に関する懸念について説明します。 ECNを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.
非ECN環境の場合でも、非準拠または応答しないフロー（つまり、輻輳したリンクへの到着率を下げることで輻輳制御の指示に応答しないフロー）によって引き起こされる可能性のある損傷について深刻な懸念があります。たとえば、エンドノードは、パケットのドロップに応じて輻輳ウィンドウを縮小しないことにより、「輻輳制御をオフにする」ことができます。これは、現在のインターネットにとって懸念事項です。ルーターは、非準拠フローからのパケットを検出して差別的に処理するメカニズムを展開する必要があると主張されています。また、エンドツーエンドのフローごとのスケジューリングやフロー間の分離、差別化されたサービス、またはエンドツーエンドの予約などの手法により、応答のないフローのより有害な影響の一部を取り除くことができると主張されています。
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.
パケットをドロップすること自体が非準拠の十分な抑止力になる可能性があり、ECNを使用するとこの抑止力がなくなると主張されています。これに対応して、（1）ECN対応ルーターは、輻輳が激しいときにパケットドロップ動作を維持すると主張します。 （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.
まず、ECN対応ルーターは、パケットのマーキングレートがかなり低い場合にのみ、パケットをドロップするのではなく、パケットにマークを付けます。平均キューサイズが上限しきい値を超えているため、潜在的なパケットマーキングレートが高い期間には、ルーターはパケットヘッダーに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 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.
ECNが導入される低または中程度のパケットマーキングレートの期間中は、これらのパケットをマーキングするのではなく、ドロップの応答のないフローに対する抑止効果はほとんどありません。たとえば、信頼性の高い配信を使用する遅延に影響されないフローは、ドロップされたパケットが存在する場合に、送信レートを下げるのではなく増加させる動機を持っている場合があります。同様に、信頼性の低い配信を使用する遅延の影響を受けやすいフローでは、パケットドロップレートの増加に応じてFECの使用が増加し、送信レートが減少するのではなく増加する場合があります。同じ理由から、パケットドロップ率が高い環境でも、パケットドロップ自体が非準拠の効果的な抑止力になるとは考えていません。
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.
非準拠または応答しないフローを識別して制限するために、いくつかの方法が提案されています。 ECNをネットワーク環境に追加しても、このようなメカニズムの設計と展開の難しさは決して増すことはありません。どちらかといえば、アーキテクチャにECNを追加すると、応答しないフローを識別する作業が少し簡単になります。たとえば、ECN対応環境では、ルーターは、そのルーター自体でドロップされた、またはCEビットが設定されたパケットに関する情報に限定されません。そのような環境では、ルーターは、パスの前半でそのパケットが遭遇した輻輳を示す到着CEパケットを記録することもできます。
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.
効果的な輻輳制御の故障は、非準拠のエンドノードだけでなく、ネットワーク自体の輻輳表示の損失によっても引き起こされる可能性があります。これは、ECN非対応のトランスポートからのパケットにECTビットを設定したり、到着したパケットのCEビットを「消去」した、不正なルーターや壊れたルーターを通じて発生する可能性があります。一例として、到着する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ビットを設定することは、ルーターが不必要にパケットをドロップすることと同じです。後でネットワークでドロップされるパケットのECTビットを「消去」することにより、ルーターのアクションにより、ネットワークで後でそのパケットに不要なパケットがドロップする可能性があります。
Concerns regarding the loss of congestion indications from encapsulated, dropped, or corrupted packets are discussed below.
カプセル化された、ドロップされた、または破損したパケットからの輻輳表示の損失に関する懸念については、以下で説明します。
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ビットに関して次の規則が適用されます。最初に、カプセル化（「内部」）ヘッダーのECTビットが0の場合、カプセル化（「外部」）ヘッダーのECTビットは0でなければなりません。内部ヘッダーのECTビットが1の場合、外部ヘッダーのECTビットは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ビットのORをとる必要があります。 （つまり、この場合、外部ヘッダーのCEビット1を内部ヘッダーにコピーする必要があります。）どちらかのヘッダーの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.
カプセル化でECNを使用する特定の例は、フローがECN機能を使用して、トンネルの中間ノードでの輻輳の結果としてカプセル化されたパケットの不要なパケットドロップの危険を回避したい場合に発生します。この機能は、カプセル化時に内部IPヘッダーのECNフィールドを外部IPヘッダーにコピーし、カプセル化解除時に外部IPヘッダーのECNフィールドを使用して内部IPヘッダーにECNフィールドを設定することでサポートできます。これにより、トンネルに沿ったルーターは、ルーターが輻輳したときに、ECN対応パケットのカプセル化されていないIPヘッダーのECNフィールドにCEビットを設定できます。
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.
[ESP、AH]で定義されているIPsecプロトコルは、暗号化計算にIPヘッダーのECNフィールドを含めません（トンネルモードの場合、外部IPヘッダーのECNフィールドは含まれません）。したがって、ネットワークノードによるECNフィールドの変更は、IPsecの整合性チェックが失敗することはないため、IPsecのエンドツーエンドのセキュリティには影響しません。結果として、IPsecは、敵のECNフィールドの変更（つまり、中間者攻撃）に対する防御を提供しません。これは、敵の変更もIPsecのエンドツーエンドのセキュリティに影響を与えないためです。一部の環境では、IPsec整合性チェックに影響を与えずにECNフィールドを変更する機能が、隠れチャネルを構成する場合があります。このようなチャネルを削除するか、帯域幅を減らす必要がある場合は、トンネルの入口ノードと出口ノードで外部IPヘッダーのECNフィールドをゼロにできます。
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カプセル化解除処理によって内部ヘッダーのECNフィールドを変更しないようにする必要があります。これにより、ECNフィールドに対する攻撃者の変更を使用して、IPsecトンネルエンドポイント全体での盗難またはサービス拒否攻撃を開始できなくなります。そのような変更はトンネルエンドポイントで破棄されるためです。このドキュメントは、そのIPsec要件に変更を加えません。 IPsecプロトコルの現在の仕様の結果として、現時点でIPsecトンネリングが行われるフローについては、ECNを使用した実験を実行しないことをお勧めします。
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仕様が変更され、トンネル出口ノードが外部ヘッダーのECNフィールド値に基づいて内部IPヘッダーのECNフィールドを変更できるようにする場合（たとえば、外部ECNフィールドの一部またはすべてを内部にコピーする） ECNフィールド）、またはカプセル化中に外部IPヘッダーのECNフィールドをゼロにできるようにするには、ECNの実験をIPsecトンネリングと組み合わせて使用できます。
This discussion of ECN and IPsec tunnel considerations draws heavily on related discussions and documents from the Differentiated Services Working Group.
ECNとIPsecトンネルの考慮事項に関するこの議論は、Differentiated Services Working Groupからの関連する議論とドキュメントに大きく依存しています。
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.
追加の問題は、あるルーターでCEビットが設定されていて、後続のルーターによってドロップされるパケットに関係しています。このペーパーで提案されているECNの使用法（つまり、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パケットの到着率を低下させません。このようなパケットにECN機能を拡張するための提案は、後でネットワークでドロップされた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パケットのこの問題は、破損が原因でドロップされたパケットと、輻輳またはバッファオーバーフローが原因でドロップされたパケットを区別するためのネットワークの提案で考慮する必要があります。
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アーキテクチャにECNを追加することの利点と欠点を考慮しています。シミュレーションに基づく比較に示されているように、ECNの1つの利点は、短いTCP接続または遅延の影響を受けやすいTCP接続での不要なパケットドロップを回避できることです。 ECNの2番目の利点は、TCPでの不必要な再送信タイムアウトを回避することです。このペーパーでは、TCPの輻輳制御メカニズムへのECNの統合について詳しく説明します。このホワイトペーパーで説明されているECNの考えられる欠点は、非準拠のTCP接続がECN対応として誤ってそれ自体をアドバタイズする可能性があること、およびECN-Echoメッセージを運ぶTCP ACKパケット自体がネットワークでドロップされる可能性があることです。これら2つの問題の1つ目は、このドキュメントのセクション8で説明されており、2つ目は、セクション5.1.3のTCPヘッダーのCWRフラグの提案で対処されています。
[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でのECNの実験的な実装について報告しています。実験には、FreeBSD用のREDの既存の実装にECNの実装が含まれています。ルーターの平均キューサイズの制御、輻輳したルーターとしての単一のTCP接続のECNのパフォーマンス、および複数の競合する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パケットでECN-Echoビットを送信します。
[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]は[CKLTZ97]に基づいて構築され、TCPに対するECNの利点をさらに分析します。結論は、ECN TCPは非ECN TCPよりも適度に優れたスループットを得るということです。 ECN TCPフローは非ECN TCPフローに対して公平であること。また、ECN TCPは双方向トラフィック、両方向の輻輳、および複数のゲートウェイの輻輳に対して堅牢です。多くの短いWeb転送を使用した実験では、ECNの有無にかかわらず、ほとんどの短い接続の転送時間は類似していますが、ECNの実験と比較して、ECN以外の実験では短い接続の転送時間が非常に長くなっています。この増加した転送時間は、非ECN実験で最初のパケットがドロップされ、したがって再送信タイマーが期限切れになるまで6秒待つ必要がある短い接続では特に劇的です。
The ECN Web Page [ECN] has pointers to other implementations of ECN in progress.
ECN Webページ[ECN]には、進行中のECNの他の実装へのポインタがあります。
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を実装する現在の取り組みを考えると、これは、ルーターベンダーがパケットドロップのみに依存しない輻輳回避メカニズムを実装する方法を検討する適切な時期であると考えています。通常の輻輳通知メカニズムでは不十分であると思われるため（または、少なくとも、単一のパケットの遅延と損失に敏感なアプリケーションとトランスポート（例：リアルタイムトラフィック、短いWeb転送）の展開の増加により、パケット損失によっては（または少なくとも、非最適）。
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に貢献しています。特に、ECN-CapabilityをネゴシエートするためのTCPメカニズムの提案についてはCho Kenjiroに、CWRビットの提案についてはKevin Fall、IPv4ヘッダーチェックサム再計算に関する資料についてはSteve Blake、ECNについてはJamal Hadi Salimに感謝します。セキュリティの問題については、Steve Bellovin、Jim Bound、Brian Carpenter、Paul Ferguson、Stephen Kent、Greg Minshall、Vern Paxsonが担当します。また、これらの問題について継続的に議論していただいたInternet End-to-End Research Groupにも感謝します。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]ケント、S.、R。アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[B97] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、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] Chen、C.、Krishnan、H.、Leung、S.、Tang、N。、およびZhang、L。、「Implementing ECN for TCP / IPv6」、LA IETFでのECN BOFへのプレゼンテーション、1998年3月、URL「http://www.cs.ucla.edu/~hari/ecn-ietf.ps」。
[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] Nichols、K.、Blake、S.、Baker、F。およびD. Black、「Definition of the Differentiated Services Field（DS Field）in the IPv4 and IPv6 Headers」、RFC 2474、1998年12月。
[ECN] "The ECN Web Page", URL "http://www-nrg.ee.lbl.gov/floyd/ecn.html".
[ECN]「ECN Webページ」、URL「http://www-nrg.ee.lbl.gov/floyd/ecn.html」。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998.
[ESP]ケント、S.、R。アトキンソン、「IPカプセル化セキュリティペイロード」、RFC 2406、1998年11月。
[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".
[FJ93] Floyd、S。、およびJacobson、V。、「輻輳回避のためのランダム早期検出ゲートウェイ」、IEEE / ACM Transactions on Networking、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] Floyd、S。、「TCP and Explicit Congestion Notification」、ACM Computer Communication Review、V。24 N. 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] Floyd、S。、およびFall、K。、「エンドツーエンドの輻輳制御をサポートするルーターメカニズム」、テクニカルレポート、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] Floyd、S。、「NS SimulatorでのECN検証テスト」、URL「http://www-mash.cs.berkeley.edu/ns/」、test tcl / test / test-all-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".
[K98]クリシュナンH。、「TCPの明示的輻輳通知（ECN）の利点の分析」、修士論文、UCLA、1998年、URL "http://www.cs.ucla.edu/~hari/software/ecn/ ecn_report .ps.gz」。
[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".
[FRED] Lin、D。、およびMorris、R。、「Dynamics of Random Early Detection」、SIGCOMM '97、1997年9月。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] V. Jacobson、「輻輳回避と制御」、Proc。 ACM SIGCOMM '88、pp。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. Jacobson、「変更されたTCP輻輳回避アルゴリズム」、end2end-interestメーリングリストへのメッセージ、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。Jacobson、およびM. Vetterli、「Receiver-driven Layered Multicast」、SIGCOMM '96、1996年8月、117-130ページ。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC1141] Mallory, T. and A. Kullberg, "Incremental Updating of the Internet Checksum", RFC 1141, January 1990.
[RFC1141]マロリー、T。およびA.カルバーグ、「インターネットチェックサムの増分更新」、RFC 1141、1990年1月。
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[RFC1349] Almquist、P。、「インターネットプロトコルスイートのサービスタイプ」、RFC 1349、1992年7月。
[RFC1455] Eastlake, D., "Physical Link Security Type of Service", RFC 1455, May 1993.
[RFC1455] Eastlake、D。、「Physical Link Security Type of Service」、RFC 1455、1993年5月。
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
[RFC2001] Stevens、W。、「TCPスロースタート、輻輳回避、高速再送信、および高速回復アルゴリズム」、RFC 2001、1997年1月。
[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。、エストリン、D。、フロイド、S。、ジェイコブソン、V。、ミンシャル、G。、パートリッジ、 C.、Peterson、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J。、およびL. Zhang、「インターネットでのキュー管理と輻輳回避に関する推奨事項」、RFC 2309、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.ラマクリシュナンとRaj Jain、「コンピュータネットワークにおける輻輳回避のためのバイナリフィードバック方式」、ACM Transactions on Computer Systems、Vol.8、No.2、pp。158-181、May 1990。
Security considerations have been discussed in Section 9.
セキュリティに関する考慮事項については、セクション9で説明しています。
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ヘッダーチェックサムの再計算は、出力バッファードスイッチを使用する一部のハイエンドルーターアーキテクチャでの問題です。ECNの決定はローカルで行う必要がありますが、ほとんどすべてのヘッダー操作がスイッチの入力側で実行されるためです。出力バッファに。 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:
RFC 1141 [RFC1141]は、TTLフィールドが減少した後のIPv4チェックサムの増分更新について説明しています。 CEビットが設定された後のIPv4チェックサムの増分更新は、次のように機能します。HCを元のヘッダーチェックサムにし、HC 'をCEビットが設定された後の新しいヘッダーチェックサムにします。次に、1の補数減算で計算されたヘッダーチェックサムの場合、HC 'は次のように再計算されます。
HC' = { HC - 1 HC > 1
{ 0x0000 HC = 1
For header checksums calculated on two's complement machines, HC' would be recalculated as follows after the CE bit was set:
2の補数マシンで計算されたヘッダーチェックサムの場合、CEビットが設定された後、HCは次のように再計算されます。
HC' = { HC - 1 HC > 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ビットの必要性は、一部のトランスポートプロトコルとルーターがECNを理解しているものと理解していないものがあるインターネットにECNが段階的に展開されるという事実によって動機付けられています。 ECTビットを使用すると、ルーターはECN対応ではないフローからパケットをドロップできますが、*代わりに* ECN対応のフローにCEビットを設定できます。 ECTビットにより、エンドノードはパケットをドロップするのではなく、CEビットをパケットに設定できるため、エンドノードはECNを展開するインセンティブを持っている可能性があります。
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指示がなかった場合、ルーターはECN対応フローと非ECN対応フローの両方からのパケットにCEビットを設定する必要があります。この場合、エンドノードがECNを展開するインセンティブはなく、ECN以外の世界からECN対応の世界への段階的な展開の実行可能なパスはありません。フローのサブセットがECN対応である、このような段階的な導入の最初の段階を検討してください。輻輳の発生時に、パケットのドロップ/マーキングレートが低い場合、ルーターはパケットをドロップするのではなく、CEビットのみを設定します。ただし、ECN対応のフローのみがCEパケットを理解して応答します。その結果、ECN対応フローはバックオフし、ECN非対応フローはECN信号を認識せず、引き続き輻輳ウィンドウを開きます。
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）ECN対応フローがオフに戻る、ECN非対応フローがすべての帯域幅を取得する、輻輳が穏やかなまま、または（2）ECN対応フローがオフに戻る、ECN非対応フローはそうではなく、ルータがCEビットの設定からパケットのドロップに移行するまで、輻輳が増加します。この2番目の結果は公平性を均等化しますが、ECN対応フローは、輻輳の増加によりルーターがパケットドロップ動作を引き起こすため、ECN対応であることによるメリットはほとんどありません。
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.
自身をECN対応としてアドバタイズしたがCEビットに応答しないフローは、セクション8および9で説明されているように、輻輳制御をオフにするフローと機能的に同等です。
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.
したがって、フローのサブセットがECN対応であるが、ECN対応フローがその事実をルーターに示すメカニズムを持たない世界では、インターネットでの効果と公平性の低い輻輳制御が発生し、エンドノードがECNを展開しないことに対する強いインセンティブ。
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（ECN対応トランスポート）およびCE（輻輳経験）表示を単一ビットでオーバーロードする必要があるかどうかという問題が残っています。 [Floyd94]で検討された、このオーバーロードされた1ビットの代替案は、2つの値を持つ単一ビットを伴います。 1つの値「ECTであり、CEではない」はECN対応のトランスポートを表し、もう1つの値「CEまたはECTではない」は、輻輳経験または非ECN対応のトランスポートを表します。
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ビットと2ビットの実装の1つの違いは、複数の輻輳したルーターを通過するパケットに関係します。 2番目の輻輳したルーターに到着し、そのルーターのアクティブなキュー管理によってマーキングまたはドロップのいずれかのために選択されたCEパケットを考えます。 1ビットの実装では、2番目の輻輳したルーターはCEパケットと非ECTパケットを区別できないため、CEパケットをドロップせざるを得ません。 2ビットの実装では、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ビット実装と2ビット実装のもう1つの違いは、1ビット実装では、単一フロー内のレシーバーがCEパケットと非ECTパケットを区別できないという事実に由来します。したがって、1ビット実装では、ECN対応のデータ送信者は、各パケットがECN対応として送信されたか、ECN非対応として送信されたかを、1つまたは複数の受信者に明確に示す必要があります。 1つの可能性は、パケットがECN対応として送信されたかどうかをトランスポートヘッダーで送信者が示すことです。 1ビット実装の機能制限に関連する2番目の可能性は、送信者がパケットの*すべて*をECN対応または非ECN対応として送信することを明確に示すことです。マルチキャストトランスポートプロトコルの場合、この明確な表示は、進行中のマルチキャストセッションに参加する受信者に明らかにする必要があります。
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 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.
2ビットアプローチのもう1つの利点は、多少堅牢であることです。セクション8で説明する最も重要な問題は、デフォルトの表示が非ECN対応のトランスポートであることです。 2ビット実装では、デフォルト値のこの要件は、ECTビットがデフォルトで「OFF」であることを単に意味します。 1ビットの実装では、これは単一の過負荷ビットがデフォルトで「CEまたはECTでない」位置にあることを意味します。これは不明確で単純なものであり、エンドノードまたはルーターのいずれかでの誤った実装に対してよりオープンになる可能性があります。
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ビットの実装は可能な実装である可能性がありますが、2ビットの実装に比べて次のような大きな制限があります。まず、1ビットの実装では、2番目の輻輳したルーターでCEパケットを処理するための機能が制限されています。 2番目に、1ビットの実装では、ECN対応フローからのパケットのトランスポートヘッダーで追加情報を運ぶ必要があります（2番目のビットの機能を他の場所、つまりトランスポートヘッダーに伝えるため）、またはECN対応の送信者フローは、受信者がECN対応のパケットとECN対応でないパケットをアプリオリに判断できる必要があるという制限を受け入れます。第3に、1ビットの実装は、ECNビットに誤ったデフォルト値を選択する障害のある実装からのエラーに対してよりオープンになる可能性があります。 ECTビットのIPヘッダーで追加ビットを使用することは、これらの制限を克服するために非常に価値があると考えています。
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.
RFC 791 [RFC791]は、IPヘッダーでToS（Type of Service）オクテットを定義しました。 RFC 791では、ToSオクテットのビット6および7は「将来の使用のために予約済み」としてリストされており、ゼロに設定されていることが示されています。 ToSオクテットの最初の2つのフィールドは、優先順位とサービスの種類（TOS）フィールドとして定義されました。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | 0 | 0 | RFC 791
+-----+-----+-----+-----+-----+-----+-----+-----+
RFC 1122 included bits 6 and 7 in the TOS field, though it did not discuss any specific use for those two bits:
RFC 1122では、TOSフィールドにビット6と7が含まれていましたが、これら2つのビットの具体的な用途については説明されていませんでした。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | RFC 1122
+-----+-----+-----+-----+-----+-----+-----+-----+
The IPv4 TOS octet was redefined in RFC 1349 [RFC1349] as follows:
IPv4 TOSオクテットは、RFC 1349 [RFC1349]で次のように再定義されました。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | MBZ | RFC 1349
+-----+-----+-----+-----+-----+-----+-----+-----+
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は、RFC 1349で「Minimize Monetary Cost」について定義されています。 PrecedenceとType of Service（TOS）フィールドに加えて、最後のフィールドであるMBZ（「ゼロでなければならない」）は現在未使用として定義されています。 RFC 1349は、「データグラムの発信者は[MBZ]フィールドをゼロに設定します（そのビットを使用するインターネットプロトコル実験に参加している場合を除く）。」
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.
RFC 1455 [RFC 1455]は、保証されたレベルのリンクセキュリティを要求するために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):
RFC 1349は、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」[DIFFSERV]によって廃止されました。DSフィールドのビット6および7は、現在未使用（CU）としてリストされています。 DSフィールドの最初の6ビットは、Differentiated Services CodePoint（DSCP）として定義されています。
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".
この不安定な履歴のため、このドキュメントのECNフィールドの定義は、これら2つのビットの過去のすべての使用との下位互換性を保証できません。非ECN対応ルーターによって引き起こされる可能性のある損傷は、CEビットが設定された状態でルーターに到着したECN対応パケットの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".
ECN非対応のエンドノードがECTビットを設定してパケットを送信することによりECN対応環境で発生する可能性のある損傷については、「エンドノードによる非準拠」のセクション9で説明しています。
AUTHORS' ADDRESSES
著者のアドレス
K. K. Ramakrishnan AT&T Labs. Research
K. K.ラマクリシュナンAT＆Tラボ。研究
Phone: +1 (973) 360-8766
EMail: 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/
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。