[要約] 要約：RFC 5562は、TCPのSYN/ACKパケットに明示的な輻輳通知（ECN）機能を追加するための規格です。 目的：このRFCの目的は、SYN/ACKパケットにECN機能を追加することで、ネットワークの輻輳をより効果的に検出および制御することです。
Network Working Group A. Kuzmanovic
Request for Comments: 5562 A. Mondal
Category: Experimental Northwestern University
S. Floyd
ICSI
K. Ramakrishnan
AT&T Labs Research
June 2009
Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets
TCPのSyn/ACKパケットに明示的な輻輳通知（ECN）機能を追加する
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
The proposal in this document is Experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of Explicit Congestion Notification (ECN) in TCP SYN/ACK packets.
この文書の提案は実験的です。現在のインターネットに展開される可能性がありますが、これがTCP syn/ACKパケットで明示的な輻輳通知（ECN）を使用するための可能な限り最良のメカニズムであるというコンセンサスを表すものではありません。
This document describes an optional, experimental modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 specifies setting an ECN-Capable codepoint on data packets, but not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document describes the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN-marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer).
このドキュメントでは、TCP syn/ACKパケットをECN対応にするために、RFC 3168のオプションの実験的変更について説明します。TCPの場合、RFC 3168は、データパケットにECN対応のコードポイントの設定を指定しますが、SynおよびSyn/ACKパケットでは設定しません。ただし、Syn/ACKパケットを削除したTCP転送のコストが高いため、結果として結果を得た再送信タイムアウトでは、このドキュメントでは、Syn/ACKパケット自体にECNの使用を説明します。TCPヘッダーに設定された2つのECNフラグは、ECNを使用する意欲を示しています。初期のTCP syn/ACKパケットをECN対応として設定することは、TCP接続に大きな利益をもたらす可能性があり、ネットワーク上にまだ負荷をかけ始めていない接続の再送信タイムアウトの厳しいペナルティを回避します。TCPレスポンダー（Syn/ACKパケットの送信者）は、ECN/ACKパケットをECN対応ではないSyn/ACKパケットを留保することにより、ECNマーク型Syn/ACKパケットのレポートに返信する必要があります。Resatent Syn/ACKパケットが認められている場合、TCP Responderは最初の輻輳ウィンドウを2、3、または4つのセグメントに1つのセグメントに減らし、ネットワーク上のその接続からその後の負荷を削減します。代わりに、Syn/ACKパケットがドロップされている場合、または他の理由でTCP Responderが指定された時間に確認を受け取らない場合、TCP ResponderはDropped Syn/ACKパケットのTCP標準に従います（再送信タイマーの設定）。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions and Terminology .....................................5
3. Specification ...................................................6
3.1. SYN/ACK Packets Dropped in the Network ....................7
3.2. SYN/ACK Packets ECN-Marked in the Network .................8
3.3. Management Interface .....................................10
4. Discussion .....................................................11
4.1. Flooding Attacks .........................................11
4.2. The TCP SYN Packet .......................................11
4.3. SYN/ACK Packets and Packet Size ..........................12
4.4. Response to ECN-Marking of SYN/ACK Packets ...............12
5. Related Work ...................................................14
6. Performance Evaluation .........................................15
6.1. The Costs and Benefits of Adding ECN-Capability ..........15
6.2. An Evaluation of Different Responses to ECN-Marked
SYN/ACK Packets ..........................................16
6.3. Experiments ..............................................17
7. Security Considerations ........................................18
7.1. "Bad" Routers or Middleboxes .............................18
7.2. Congestion Collapse ......................................18
8. Conclusions ....................................................19
9. Acknowledgements ...............................................19
Appendix A. Report on Simulations .................................20
A.1. Simulations with RED in Packet Mode .......................20
A.2. Simulations with RED in Byte Mode .........................25
Appendix B. Issues of Incremental Deployment ......................28
Normative References ..............................................30
Informative References ............................................30
TCP's congestion control mechanism has primarily used packet loss as the congestion indication, with packets dropped when buffers overflow. With such tail-drop mechanisms, the packet delay can be high, as the queue at bottleneck routers can be fairly large. Dropping packets only when the queue overflows, and having TCP react only to such losses, results in:
TCPの輻輳制御メカニズムは、主に渋滞の表示としてパケット損失を使用しており、バッファーがオーバーフローするとパケットが低下しました。このようなテールドロップメカニズムを使用すると、ボトルネックルーターのキューがかなり大きくなる可能性があるため、パケットの遅延が高くなる可能性があります。キューがオーバーフローした場合にのみパケットを落とし、TCPにそのような損失のみに反応する場合、次の結果が得られます。
1) significantly higher packet delay;
1) パケット遅延が大幅に高くなります。
2) unnecessarily many packet losses; and
2) 不必要に多くのパケット損失。と
3) unfairness due to synchronization effects.
3) 同期効果による不公平。
The adoption of Active Queue Management (AQM) mechanisms allows better control of bottleneck queues [RFC2309]. This use of AQM has the following potential benefits:
アクティブキュー管理（AQM）メカニズムの採用により、ボトルネックキューをより適切に制御できます[RFC2309]。AQMのこの使用には、次の潜在的な利点があります。
1) better control of the queue, with reduced queuing delay;
1) キューの遅延が減少し、キューのより良い制御。
2) fewer packet drops; and
2) パケットドロップが少ない。と
3) better fairness because of fewer synchronization effects.
3) 同期効果が少ないため、より良い公平性。
With the adoption of ECN, performance may be further improved. When the router detects congestion before buffer overflow, the router can provide a congestion indication either by dropping a packet or by setting the Congestion Experienced (CE) codepoint in the Explicit Congestion Notification (ECN) field in the IP header [RFC3168]. The IETF has standardized the use of the Congestion Experienced (CE) codepoint in the IP header for routers to indicate congestion. For incremental deployment and backwards compatibility, the RFC on ECN [RFC3168] specifies that routers may mark ECN-Capable packets that would otherwise have been dropped, using the Congestion Experienced codepoint in the ECN field. The use of ECN allows TCP to react to congestion while avoiding unnecessary retransmission timeouts. Thus, using ECN has several benefits:
ECNの採用により、パフォーマンスがさらに向上する可能性があります。バッファオーバーフローの前にルーターが輻輳を検出すると、ルーターはパケットをドロップするか、IPヘッダー[RFC3168]の明示的な輻輳通知（ECN）フィールドに経験豊富な（CE）コードポイントを設定することにより、うっ血を示すことができます。IETFは、混雑を示すために、ルーターのIPヘッダーで経験豊富な（CE）コードポイントの使用を標準化しました。増分展開と逆方向の互換性のために、ECN [RFC3168]のRFCは、RouterがECNフィールドの輻輳経験豊富なコードポイントを使用して、それ以外の場合はドロップされていたECN対応パケットをマークする可能性があることを指定します。ECNの使用により、TCPは不必要な再送信のタイムアウトを避けながら、混雑に反応することができます。したがって、ECNの使用にはいくつかの利点があります。
1) For short transfers, a TCP connection's congestion window may be small. For example, if the current window contains only one packet, and that packet is dropped, TCP will have to wait for a retransmission timeout to recover, reducing its overall throughput. Similarly, if the current window contains only a few packets and one of those packets is dropped, there might not be enough duplicate acknowledgements for a fast retransmission, and the sender of the data packet might have to wait for a delay of several round-trip times (RTT) using Limited Transmit [RFC3042]. With the use of ECN, short flows are less likely to have packets dropped, sometimes avoiding unnecessary delays or costly retransmission timeouts.
1) 短い転送の場合、TCP接続の輻輳ウィンドウが小さい場合があります。たとえば、現在のウィンドウに1つのパケットのみが含まれ、そのパケットがドロップされている場合、TCPは再送信タイムアウトが回復するのを待つ必要があり、全体的なスループットを減らします。同様に、現在のウィンドウにいくつかのパケットのみが含まれていて、それらのパケットの1つがドロップされている場合、迅速な再送信のための十分な重複謝辞がない場合があり、データパケットの送信者は数回の往復の遅延を待つ必要がある場合があります。限られた送信[RFC3042]を使用した時間（RTT）。ECNを使用すると、短いフローがパケットを削除する可能性が低く、不必要な遅延や費用のかかる再送信のタイムアウトを回避することもあります。
2) While longer flows may not see substantially improved throughput with the use of ECN, they may experience lower loss. This may benefit TCP applications that are latency- and loss-sensitive, because of the avoidance of retransmissions.
2) より長いフローは、ECNを使用するとスループットが大幅に改善されない場合がありますが、低下が低下する可能性があります。これは、再送信の回避のために、遅延および損失に敏感なTCPアプリケーションに利益をもたらす可能性があります。
RFC 3168 [RFC3168] specifies setting the ECN-Capable codepoint on TCP data packets, but not on TCP SYN and SYN/ACK packets. RFC 3168 [RFC3168] specifies the negotiation of the use of ECN between the two TCP endpoints in the TCP SYN and SYN-ACK exchange, using flags in the TCP header. Erring on the side of being conservative, RFC 3168 [RFC3168] does not specify the use of ECN for the first SYN/ACK packet itself. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document specifies the use of ECN for the SYN/ACK packet itself. This can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to a report of an ECN-marked SYN/ACK packet (a SYN/ACK packet with the CE codepoint set in the ECN field in the IP header) by sending a non-ECN-Capable SYN/ACK packet, and by reducing its initial congestion window from two, three, or four segments to one segment, reducing the subsequent load from that connection on the network.
RFC 3168 [RFC3168]は、TCP Data PacketsにECNに対応するCodePointの設定を指定しますが、TCP SynおよびSyn/ACKパケットでは設定していません。RFC 3168 [RFC3168]は、TCPヘッダーのフラグを使用して、TCP synとsyn-ack交換の2つのTCPエンドポイント間のECNの使用の交渉を指定します。保守的であることの誤りであるRFC 3168 [RFC3168]は、最初のSyn/ACKパケット自体にECNの使用を指定していません。ただし、Syn/ACKパケットを削除したTCP転送のコストが高いため、結果として結果を回復するタイムアウトでは、このドキュメントはSyn/ACKパケット自体にECNを使用することを指定します。これは、TCP接続にとって大きな利益をもたらす可能性があります。これは、ネットワーク上にまだ負荷をかけ始めていない接続に対する再送信タイムアウトの厳しいペナルティを回避します。Syn/ACKパケットの送信者は、非ECN対応を送信することにより、ECNマーク型SYN/ACKパケット（IPヘッダーのECNフィールドにCEN/ACKパケットを使用）のレポートに応答する必要があります。Syn/ACKパケット、および最初の輻輳ウィンドウを2、3、または4つのセグメントから1つのセグメントに減らして、ネットワーク上のその接続からその後の負荷を減らします。
The use of ECN for SYN/ACK packets has the following potential benefits:
syn/ackパケットへのECNの使用には、次の潜在的な利点があります。
1) Avoidance of a retransmission timeout;
1) 再送信タイムアウトの回避。
2) Improvement in the throughput of short connections.
2) 短い接続のスループットの改善。
This document specifies a modification to RFC 3168 [RFC3168] to allow TCP SYN/ACK packets to be ECN-Capable. Section 3 contains the specification of the change, while Section 4 discusses some of the issues, and Section 5 discusses related work. Section 6 contains an evaluation of the specified change.
このドキュメントは、TCP Syn/ACKパケットをECN対応にするために、RFC 3168 [RFC3168]の変更を指定します。セクション3には変更の仕様が含まれており、セクション4では問題のいくつかについて説明し、セクション5では関連する作業について説明します。セクション6には、指定された変更の評価が含まれています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
We use the following terminology from RFC 3168 [RFC3168]:
RFC 3168 [RFC3168]の次の用語を使用します。
The ECN field in the IP header:
IPヘッダーのECNフィールド：
o CE: the Congestion Experienced codepoint; and
o CE：混雑はコードポイントを経験しました。と
o ECT: either one of the two ECN-Capable Transport codepoints.
o ECT：2つのECN対応トランスポートコードポイントのいずれか。
The ECN flags in the TCP header:
TCPヘッダーのECNフラグ：
o CWR: the Congestion Window Reduced flag; and
o CWR：混雑ウィンドウが旗を縮小しました。と
o ECE: the ECN-Echo flag.
o ECE：ECNエコーフラグ。
ECN-setup packets:
ecn-setupパケット：
o ECN-setup SYN packet: a SYN packet with the ECE and CWR flags;
o ECN-Setup synパケット：ECEおよびCWRフラグを備えたSynパケット。
o ECN-setup SYN-ACK packet: a SYN-ACK packet with ECE but not CWR.
o ECN-Setup syn-ackパケット：CWRではなくECEを備えたSyn-ackパケット。
In this document, we use the terms "initiator" and "responder" to refer to the sender of the SYN packet and of the SYN-ACK packet, respectively.
このドキュメントでは、「イニシエーター」と「レスポンダー」という用語を使用して、それぞれSynパケットとSyn-ackパケットの送信者を参照しています。
This section specifies the modification to RFC 3168 [RFC3168] to allow TCP SYN/ACK packets to be ECN-Capable.
このセクションでは、RFC 3168 [RFC3168]への変更を指定して、TCP Syn/ACKパケットをECN対応にすることができます。
Section 6.1.1 of RFC 3168 [RFC3168] states that "A host MUST NOT set ECT on SYN or SYN-ACK packets". In this section, we specify that a TCP node may respond to an initial ECN-setup SYN packet by setting ECT in the responding ECN-setup SYN/ACK packet, indicating to routers that the SYN/ACK packet is ECN-Capable. This allows a congested router along the path to mark the packet instead of dropping the packet as an indication of congestion.
RFC 3168 [RFC3168]のセクション6.1.1は、「ホストはsynまたはsyn-ackパケットにECTを設定してはならない」と述べています。このセクションでは、TCPノードが、応答するECNセットアップSyn/ACKパケットにECTを設定することにより、初期のECNセットアップSynパケットに応答できることを指定し、Syn/ACKパケットがECN対応であることをルーターに示します。これにより、混雑したルーターをパスに沿ってパケットをマークするために、混雑の指示としてパケットをドロップするのではなく、パケットをマークすることができます。
Assume that TCP node A transmits to TCP node B an ECN-setup SYN packet, indicating willingness to use ECN for this connection. As specified by RFC 3168 [RFC3168], if TCP node B is willing to use ECN, node B responds with an ECN-setup SYN-ACK packet.
TCPノードAがTCPノードBにECNセットアップSynパケットに送信され、この接続にECNを使用する意欲を示していると仮定します。RFC 3168 [RFC3168]で指定されているように、TCPノードBがECNを使用する意思がある場合、ノードBはECNセットアップsyn-ackパケットで応答します。
Figure 1 shows an interchange with the SYN/ACK packet dropped by a congested router. Node B waits for a retransmission timeout, and then retransmits the SYN/ACK packet.
図1は、混雑したルーターによってドロップされたSyn/ACKパケットとの交換を示しています。ノードBは再送信タイムアウトを待ってから、Syn/ACKパケットを再送信します。
---------------------------------------------------------------
TCP Node A Router TCP Node B
(initiator) (responder)
---------- ------ ----------
ECN-setup SYN packet --->
ECN-setup SYN packet --->
<--- ECN-setup SYN/ACK, possibly ECT
3-second timer set
SYN/ACK dropped .
.
.
3-second timer expires
<--- ECN-setup SYN/ACK, not ECT
<--- ECN-setup SYN/ACK
Data/ACK --->
Data/ACK --->
<--- Data (one to four segments)
---------------------------------------------------------------
Figure 1: SYN exchange with the SYN/ACK packet dropped
図1：syn/ackパケットとのsyn交換がドロップされました
If the SYN/ACK packet is dropped in the network, the responder (node B) responds by waiting three seconds for the retransmission timer to expire [RFC2988]. If a SYN/ACK packet with the ECT codepoint is dropped, the responder should resend the SYN/ACK packet without the ECN-Capable codepoint. (Although we are not aware of any middleboxes that drop SYN/ACK packets that contain an ECN-Capable codepoint in the IP header, we have learned to design our protocols defensively in this regard [RFC3360].)
Syn/ACKパケットがネットワークにドロップされている場合、再送信タイマーが期限切れになるまで3秒待って応答者（ノードB）が応答します[RFC2988]。ECT CodePointを使用したSyn/ACKパケットがドロップされている場合、ResponderはECN対応のCodePointなしでSyn/ACKパケットを再送信する必要があります。（IPヘッダーにECN対応のコードポイントを含むSYN/ACKパケットをドロップするミドルボックスを認識していませんが、この点でプロトコルを防御的に設計することを学びました[RFC3360]。）
We note that if syn-cookies were used by the responder (node B) in the exchange in Figure 1, the responder wouldn't set a timer upon transmission of the SYN/ACK packet [SYN-COOK] [RFC4987]. In this case, if the SYN/ACK packet was lost, the initiator (node A) would have to timeout and retransmit the SYN packet in order to trigger another SYN-ACK.
図1の交換でレスポンダー（ノードB）がSyn-Cookieを使用した場合、ResponderはSyn/ACKパケット[Syn-Cook] [RFC4987]の送信時にタイマーを設定しないことに注意してください。この場合、Syn/ACKパケットが失われた場合、イニシエーター（ノードA）は、別のSyn-ackをトリガーするためにSynパケットをタイムアウトして再送信する必要があります。
Figure 2 shows an interchange with the SYN/ACK packet sent as ECN-Capable, and ECN-marked instead of dropped at the congested router. This document specifies ECN+/TryOnce, which differs from the original proposal for ECN+ in [ECN+]; with ECN+/TryOnce, if the TCP responder is informed that the SYN/ACK was ECN-marked, the TCP responder immediately sends a SYN/ACK packet that is not ECN-Capable. The TCP responder is only allowed to send data packets after the TCP initiator reports the receipt of a SYN/ACK packet that is not ECN-marked.
図2は、混雑したルーターでドロップされる代わりに、ECN対応として送信され、ECNマーク化されたSYN/ACKパケットとの交換を示しています。このドキュメントは、[ECN]のECNの元の提案とは異なるECN /TryOnceを指定しています。ECN/TRYONCEを使用すると、TCP ResponderにSyn/ACKがECNマークされていることを通知された場合、TCP ResponderはすぐにECN対応ではないSyn/ACKパケットを送信します。TCPイニシエーターがECNマークされていないSyn/ACKパケットの受領を報告した後、TCPレスポンダーはデータパケットを送信することができます。
---------------------------------------------------------------
TCP Node A Router TCP Node B
(initiator) (responder)
---------- ------ ----------
ECN-setup SYN packet --->
ECN-setup SYN packet --->
<--- ECN-setup SYN/ACK, ECT 3-second timer set <--- Sets CE on SYN/ACK <--- ECN-setup SYN/ACK, CE
<--- ecn-setup syn/ack、ect 3秒タイマーセット<--- syn/ackにceを設定<--- ecn-setup syn/ack、ce
ACK, ECN-Echo ---> ACK, ECN-Echo ---> Window reduced to one segment. <--- ECN-setup SYN/ACK, not ECT <--- ECN-setup SYN/ACK
ACK、ECN-ECHO ---> ACK、ECN-ECHO --->ウィンドウが1つのセグメントに縮小されました。<--- ecn-setup syn/ack、ectではありません<--- ecn-setup syn/ack
Data/ACK, ECT --->
Data/ACK, ECT --->
<--- Data, ECT (one segment only)
---------------------------------------------------------------
Figure 2: SYN exchange with the SYN/ACK packet marked - ECN+/TryOnce
図2：syn /ackパケットとの交換マーク-ECN /TRYONCE
If the initiator (node A) receives a SYN/ACK packet that has been ECN-marked by the congested router, with the CE codepoint set, the initiator restarts the retransmission timer. The initiator responds to the ECN-marked SYN/ACK packet by setting the ECN-Echo flag in the TCP header of the responding ACK packet. The initiator uses the standard rules in setting the cumulative acknowledgement field in the responding ACK packet.
イニシエーター（ノードA）が、CEDopointセットを使用して、混雑したルーターによってECNマークされたSyn/ACKパケットを受信した場合、イニシエーターは再送信タイマーを再起動します。イニシエーターは、Responsing ACKパケットのTCPヘッダーにECN-ECHOフラグを設定することにより、ECNマークSyn/ACKパケットに応答します。イニシエーターは、応答するACKパケットに累積確認フィールドを設定する際に標準ルールを使用します。
The initiator does not advance from the "SYN-Sent" to the "Established" state until it receives a SYN/ACK packet that is not ECN-marked.
イニシエーターは、eCNマークされていないSyn/ACKパケットを受信するまで、「Syn-Sent」から「確立された」状態に進みません。
When the responder (node B) receives the ECN-Echo packet reporting the Congestion Experienced indication in the SYN/ACK packet, the responder sets the initial congestion window to one segment, instead of two segments as allowed by [RFC2581], or three or four segments allowed by [RFC3390]. As illustrated in Figure 2, if the responder (node B) receives an ECN-Echo packet informing it of a Congestion Experienced indication on its SYN/ACK packet, the responder sends a SYN/ACK packet that is not ECN-Capable, in addition to setting the initial window to one segment. The responder does not advance the send sequence number. The responder also sets the retransmission timer. The responder follows RFC 2988 [RFC2988] in setting the RTO (retransmission timeout).
Responder（ノードB）がSyn/ACKパケットで経験した輻輳を報告するECNエコーパケットを受信すると、Responderは[RFC2581]、または3つまたは3つまたは[RFC3390]によって許可されている4つのセグメント。図2に示すように、Responder（ノードB）がSyn/ACKパケットでの輻輳が発生した兆候を通知するECNエコーパケットを受信した場合、ResponderはECN対応ではないSyn/ACKパケットを送信します。初期ウィンドウを1つのセグメントに設定します。レスポンダーは、送信シーケンス番号を進めません。レスポンダーはまた、再送信タイマーを設定します。レスポンダーは、RTO（再送信タイムアウト）を設定する際に、RFC 2988 [RFC2988]に続きます。
The TCP hosts follow the standard specification for the response to duplicate SYN/ACK packets (e.g., Section 3.4 of RFC 793 [RFC793]).
TCPホストは、syn/ACKパケットを複製するための応答の標準仕様に従います（例：RFC 793 [RFC793]のセクション3.4）。
We note that the mechanism in this document differs from RFC 3168 [RFC3168], which specifies that "the sending TCP MUST restart the retransmission timer on receiving the ECN-Echo packet when the congestion window is one". RFC 3168 [RFC3168] does not allow SYN/ACK packets to be ECN-Capable. RFC 3168 [RFC3168] specifies that in response to an ECN-Echo packet, the TCP responder also sets the CWR flag in the TCP header of the next data packet sent, to acknowledge its receipt of and reaction to the ECN-Echo flag. In contrast, in response to an ECN-Echo packet acknowledging the receipt of an ECN-Capable SYN/ACK packet, the TCP responder doesn't set the CWR flag, but simply sends a SYN/ACK packet that is not ECN-Capable. On receiving the non-ECN-Capable SYN/ACK packet, the TCP initiator clears the ECN-Echo flag on replying packets.
このドキュメントのメカニズムは、RFC 3168 [RFC3168]とは異なることに注意してください。これは、「送信TCPは、渋滞ウィンドウが1つの場合のECNエコーパケットの受信時に再送信タイマーを再起動する必要がある」と指定しています。RFC 3168 [RFC3168]は、Syn/ACKパケットをECN対応にすることを許可しません。RFC 3168 [RFC3168]は、ECNエコーパケットに応じて、TCPレスポンダーが送信された次のデータパケットのTCPヘッダーにCWRフラグを設定し、ECN-ECHOフラグの受領と反応を認めることを指定します。対照的に、ECN対応Syn/ACKパケットの受領を認めるECNエコーパケットに応じて、TCPレスポンダーはCWRフラグを設定しませんが、ECN対応ではないSyn/ACKパケットを送信するだけです。非ECN対応Syn/ACKパケットを受信すると、TCPイニシエーターは、ReplyingパケットのECNエコーフラグをクリアします。
---------------------------------------------------------------
TCP Node A Router TCP Node B
(initiator) (responder)
---------- ------ ----------
ECN-setup SYN packet --->
ECN-setup SYN packet --->
<--- ECN-setup SYN/ACK, ECT <--- Sets CE on SYN/ACK <--- ECN-setup SYN/ACK, CE
<--- ecn-setup syn/ack、ect <--- syn/ackにceを設定<--- ecn-setup syn/ack、ce
ACK, ECN-Echo ---> ACK, ECN-Echo ---> Window reduced to one segment.
ACK、ECN-ECHO ---> ACK、ECN-ECHO --->ウィンドウが1つのセグメントに縮小されました。
<--- ECN-setup SYN/ACK, not ECT
3-second timer set
SYN/ACK dropped .
.
.
3-second timer expires
<--- ECN-setup SYN/ACK, not ECT
<--- ECN-setup SYN/ACK, not ECT
Data/ACK, ECT --->
Data/ACK, ECT --->
<--- Data, ECT (one segment only)
---------------------------------------------------------------
Figure 3: SYN exchange with the first SYN/ACK packet marked and the second SYN/ACK packet dropped - ECN+/TryOnce
図3：マークされた最初のsyn/ackパケットとのsyn交換および2番目のsyn/ackパケットがドロップされた-ecn/tryonce
In contrast to Figure 2, Figure 3 shows an interchange where the first SYN/ACK packet is ECN-marked and the second SYN/ACK packet is dropped in the network. As in Figure 2, the TCP responder sets a timer when the second SYN/ACK packet is sent. Figure 3 shows that if the timer expires before the TCP responder receives an acknowledgement for the other end, the TCP responder resends the SYN/ACK packet, following the TCP standards.
図2とは対照的に、図3は、最初のSyn/ACKパケットがECNマーク化され、2番目のSyn/ACKパケットがネットワークでドロップされる場合の交換を示しています。図2のように、TCPレスポンダーは、2番目のSyn/ACKパケットが送信されるときにタイマーを設定します。図3は、TCPレスポンダーがもう一方の端の確認を受信する前にタイマーが期限切れになった場合、TCPレスポンダーがTCP標準に従ってSyn/ACKパケットを再送信することを示しています。
The TCP implementation using ECN-Capable SYN/ACK packets should include a management interface to allow the use of ECN to be turned off for SYN/ACK packets. This is to deal with possible backwards compatibility problems such as those discussed in Appendix B.
ECN対応Syn/ACKパケットを使用したTCP実装には、ECNの使用をSyn/ACKパケットに使用できるようにする管理インターフェイスを含める必要があります。これは、付録Bで説明したような、可能な後方互換性の問題に対処することです。
The rationale for the specification in this document is the following. When node B receives a TCP SYN packet with ECN-Echo bit set in the TCP header, this indicates that node A is ECN-Capable. If node B is also ECN-Capable, there are no obstacles to immediately setting one of the ECN-Capable codepoints in the IP header in the responding TCP SYN/ACK packet.
このドキュメントの仕様の理論的根拠は次のとおりです。Node BがTCPヘッダーにECN-ECHO BITセットを使用してTCP Synパケットを受信すると、これはノードAがECN対応であることを示します。ノードBもECN対応の場合、応答するTCP Syn/ACKパケットのIPヘッダーにECN対応のコードポイントの1つをすぐに設定する障害はありません。
There can be a great benefit in setting an ECN-Capable codepoint in SYN/ACK packets, as is discussed further in [ECN+], and reported briefly in Section 5 below. Congestion is most likely to occur in the server-to-client direction. As a result, setting an ECN-Capable codepoint in SYN/ACK packets can reduce the occurrence of three-second retransmission timeouts resulting from the drop of SYN/ACK packets.
[ECN]でさらに説明し、以下のセクション5で簡単に報告したように、Syn/ACKパケットにECN対応のコードポイントを設定することには大きな利点があります。輻輳は、サーバーからクライアントへの方向に発生する可能性が最も高くなります。その結果、syn/ackパケットにECN対応のコードポイントを設定すると、syn/ackパケットのドロップに起因する3秒の再送信タイムアウトの発生を減らすことができます。
Setting an ECN-Capable codepoint in the responding TCP SYN/ACK packets does not raise any new or additional security vulnerabilities. For example, provoking servers or hosts to send SYN/ACK packets to a third party in order to perform a "SYN/ACK flood" attack would be highly inefficient. Third parties would immediately drop such packets, since they would know that they didn't generate the TCP SYN packets in the first place. Moreover, such SYN/ACK attacks would have the same signatures as the existing TCP SYN attacks. Provoking servers or hosts to reply with SYN/ACK packets in order to congest a certain link would also be highly inefficient because SYN/ACK packets are small in size.
応答性のあるTCP Syn/ACKパケットにECN対応のコードポイントを設定しても、新しいまたは追加のセキュリティの脆弱性はありません。たとえば、「Syn/ACK洪水」攻撃を実行するためにSyn/ACKパケットをサードパーティに送信するサーバーまたはホストを引き起こすことは非常に非効率的です。第三者は、そもそもTCP Synパケットを生成しなかったことを知っているため、すぐにそのようなパケットをドロップします。さらに、このようなSyn/ACK攻撃には、既存のTCP Syn攻撃と同じ署名があります。Syn/ACKパケットのサイズが小さいため、特定のリンクを混雑させるためにSyn/ACKパケットで返信するサーバーまたはホストを誘発することも非常に非効率的です。
However, the addition of ECN-Capability to SYN/ACK packets could allow SYN/ACK packets to persist for more hops along a network path before being dropped, thus adding somewhat to the ability of a SYN/ACK attack to flood a network link.
ただし、syn/ackパケットにECNキャピールを追加すると、syn/ackパケットがネットワークパスに沿ってより多くのホップを持続することを可能にすることで、ドロップされる前に、ネットワークリンクをあふれさせるsyn/ack攻撃の能力に多少追加されます。
There are several reasons why an ECN-Capable codepoint must not be set in the IP header of the initiating TCP SYN packet. First, when the TCP SYN packet is sent, there are no guarantees that the other TCP endpoint (node B in Figure 2) is ECN-Capable, or that it would be able to understand and react if the ECN CE codepoint was set by a congested router.
ECN対応のCodePointを開始TCP SynパケットのIPヘッダーに設定してはならない理由はいくつかあります。まず、TCP synパケットが送信されると、他のTCPエンドポイント（図2のノードB）がECN対応であること、またはECN CEコードポイントがAによって設定された場合に理解して反応できるという保証はありません。混雑したルーター。
Second, the ECN-Capable codepoint in TCP SYN packets could be misused by malicious clients to "improve" the well-known TCP SYN attack. By setting an ECN-Capable codepoint in TCP SYN packets, a malicious host might be able to inject a large number of TCP SYN packets through a potentially congested ECN-enabled router, congesting it even further.
第二に、TCP SynパケットのECN対応のコードポイントは、悪意のあるクライアントによって悪用され、よく知られているTCP Syn攻撃を「改善」する可能性があります。TCP synパケットにECN対応のコードポイントを設定することにより、悪意のあるホストは、潜在的に混雑しているECN対応ルーターを介して多数のTCP synパケットを注入し、さらに混雑させることができます。
For both these reasons, we continue the restriction that the TCP SYN packet must not have the ECN-Capable codepoint in the IP header set.
これらの両方の理由により、TCP SynパケットがIPヘッダーセットにECN対応のコードポイントを持っていてはならないという制限を継続します。
There are a number of router buffer architectures that have smaller dropping rates for small (SYN) packets than for large (data) packets. For example, for a Drop-Tail queue in units of packets, where each packet takes a single slot in the buffer regardless of packet size, small and large packets are equally likely to be dropped. However, for a Drop-Tail queue in units of bytes, small packets are less likely to be dropped than are large ones. Similarly, for Random Early Detection (RED) in packet mode, small and large packets are equally likely to be dropped or marked, while for RED in byte mode, a packet's chance of being dropped or marked is proportional to the packet size in bytes.
大規模な（データ）パケットよりも小さい（syn）パケットのドロップレートが小さいルーターバッファーアーキテクチャが多数あります。たとえば、各パケットがパケットサイズに関係なくバッファーに単一のスロットを使用するパケット単位のドロップテールキューの場合、小型および大型パケットは等しくドロップされる可能性があります。ただし、バイト単位のドロップテールキューの場合、小さなパケットは大きなパケットよりもドロップされる可能性が低くなります。同様に、パケットモードでのランダム早期検出（赤）の場合、小型および大型のパケットはドロップまたはマークされる可能性がありますが、バイトモードの赤の場合、パケットのドロップまたはマークの可能性はバイトのパケットサイズに比例します。
For a congested router with an AQM mechanism in byte mode, where a packet's chance of being dropped or marked is proportional to the packet size in bytes, the drop or marking rate for TCP SYN/ACK packets should generally be low. In this case, the benefit of making SYN/ACK packets ECN-Capable should be similarly moderate. However, for a congested router with a Drop-Tail queue in units of packets or with an AQM mechanism in packet mode, and with no priority queuing for smaller packets, small and large packets should have the same probability of being dropped or marked. In such a case, making SYN/ACK packets ECN-Capable should be of significant benefit.
BYTEモードのAQMメカニズムを備えた混雑したルーターの場合、パケットのドロップまたはマークの可能性がバイトのパケットサイズに比例する場合、TCP Syn/ACKパケットのドロップまたはマークレートは一般的に低くなります。この場合、syn/ackパケットをECN対応にすることの利点も同様に中程度でなければなりません。ただし、パケットの単位またはパケットモードのAQMメカニズムを備えたドロップテールキューを備えた混雑したルーターの場合、小さいパケットの優先順位のキューイングがないため、小規模および大型パケットは同じ可能性を削除またはマークする必要があります。このような場合、syn/ackパケットを作成することは、大きな利益をもたらす必要があります。
We believe that there are a wide range of behaviors in the real world in terms of the drop or mark behavior at routers as a function of packet size (see Section 10 of [Tools]). We note that all of these alternatives listed above are available in the NS simulator (Drop-Tail queues are by default in units of packets, while the default for RED queue management has been changed from packet mode to byte mode).
パケットサイズの関数として、ルーターのドロップまたはマークの動作に関して、現実の世界には幅広い動作があると考えています（[ツール]のセクション10を参照）。上記のこれらの代替品はすべてNSシミュレーターで利用できることに注意してください（ドロップテールキューはパケットの単位でデフォルトで、レッドキュー管理のデフォルトはパケットモードからバイトモードに変更されています）。
One question is why TCP SYN/ACK packets should be treated differently from other packets in terms of the end node's response to an ECN-marked packet. Section 5 of RFC 3168 [RFC3168] specifies the following:
質問の1つは、TCP Syn/ACKパケットを、ECNマークされたパケットに対するエンドノードの応答に関して、他のパケットとは異なる方法で扱われるべき理由です。RFC 3168 [RFC3168]のセクション5に次を指定します。
Upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems MUST be essentially the same as the congestion control response to a *single* dropped packet. For example, for ECN-Capable TCP the source TCP is required to halve its congestion window for any window of data containing either a packet drop or an ECN indication.
単一のCEパケットのECNで利用可能な輸送による受領時に、最終システムで行われた輻輳制御アルゴリズムは、 *単一 *ドロップされたパケットに対する混雑制御応答と本質的に同じでなければなりません。たとえば、ECN対応TCPの場合、パケットドロップまたはECN表示のいずれかを含むデータのウィンドウに対して、うっ血ウィンドウを半分にするためにソースTCPが必要です。
In particular, Section 6.1.2 of RFC 3168 [RFC3168] specifies that when the TCP congestion window consists of a single packet and that packet is ECN-marked in the network, then the data sender must reduce the sending rate below one packet per round-trip time, by waiting for one RTO before sending another packet. If the RTO was set to the average round-trip time, this would result in halving the sending rate; because the RTO is in fact larger than the average round-trip time, the sending rate is reduced to less than half of its previous value.
特に、RFC 3168 [RFC3168]のセクション6.1.2 [RFC3168]は、TCP輻輳ウィンドウが単一のパケットで構成されている場合、パケットがネットワークにeCNマークされている場合、データ送信者は送信速度を1ラウンドあたり1つのパケット以下に減らす必要があることを指定しています。 - 別のパケットを送信する前に1つのRTOを待つことにより、時間を整理します。RTOが平均往復時間に設定された場合、これにより送信率が半分になります。RTOは実際には平均往復時間よりも大きいため、送信率は以前の値の半分未満に減少します。
TCP's congestion control response to the *dropping* of a SYN/ACK packet is to wait a default time before sending another packet. This document argues that ECN gives end-systems a wider range of possible responses to the *marking* of a SYN/ACK packet, and that waiting a default time before sending another packet is not the desired response.
Syn/ACKパケットの *ドロップ *に対するTCPの混雑制御応答は、別のパケットを送信する前にデフォルト時間を待つことです。このドキュメントは、ECNに、syn/ackパケットの *マーキング *に対するエンドシステムに可能な範囲のより広い範囲の応答を提供し、別のパケットを送信する前にデフォルトの時間を待つことは望ましい応答ではないと主張しています。
On the conservative end, one could assume an effective congestion window of one packet for the SYN/ACK packet, and respond to an ECN-marked SYN/ACK packet by reducing the sending rate to one packet every two round-trip times. As an approximation, the TCP end node could measure the round-trip time T between the sending of the SYN/ACK packet and the receipt of the acknowledgement, and reply to the acknowledgement of the ECN-marked SYN/ACK packet by waiting T seconds before sending a data packet.
保守的な目的では、Syn/ACKパケットの1つのパケットの効果的な輻輳ウィンドウを想定し、2つの往復時間ごとに送信速度を1つのパケットに減らすことにより、ECNマークされたSyn/ACKパケットに応答できます。近似として、TCPエンドノードは、syn/ackパケットの送信と確認の受領の間の往復時間tを測定し、t秒待ってECNマークされたsyn/ackパケットの謝辞に返信することができます。データパケットを送信する前。
However, we note that for an ECN-marked SYN/ACK packet, halving the *congestion window* is not the same as halving the *sending rate*; there is no "sending rate" associated with an ECN-Capable SYN/ACK packet, as such packets are only sent as the first packet in a connection from that host. Further, a router's marking of a SYN/ACK packet is not affected by any past history of that connection.
ただし、ECNマークされたSyn/ACKパケットの場合、 *輻輳ウィンドウ *を半分にすることは、 *送信速度 *を半分にすることと同じではないことに注意してください。そのようなパケットは、そのホストから接続中の最初のパケットとしてのみ送信されるため、ECN対応Syn/ACKパケットに関連付けられた「送信レート」はありません。さらに、syn/ackパケットのルーターのマーキングは、その接続の過去の歴史の影響を受けません。
Adding ECN-Capability to SYN/ACK packets allows the response of the responder setting the initial congestion window to one packet, instead of its allowed default value of two, three, or four packets. The responder sends a non-ECN-Capable SYN/ACK packet, and proceeds with a cautious sending rate of one data packet per round-trip time after that SYN/ACK packet is acknowledged. This document argues that this approach is useful to users, with no dangers of congestion collapse or of starvation of competing traffic. This is discussed in more detail below in Section 6.2.
syn/ackパケットにECNキャピールを追加すると、2つ、3つ、または4つのパケットのデフォルト値が許可されているデフォルト値の代わりに、応答者の応答を1つのパケットに設定する応答が可能になります。Responderは、ECNに対応できないSyn/ACKパケットを送信し、Syn/ACKパケットが認められた後、往復時間ごとに1つのデータパケットの慎重な送信率を獲得します。このドキュメントは、このアプローチはユーザーにとって有用であり、混雑の崩壊や競合するトラフィックの飢starの危険はないと主張しています。これについては、以下でセクション6.2で詳しく説明します。
We note that if the data transfer is entirely from node A to node B, there is still a difference in performance between the original mechanism ECN+ and the mechanism ECN+/TryOnce specified in this document. In particular, with ECN+/TryOnce, the TCP originator does not send data packets until it has received a non-ECN-marked SYN/ACK packet from the other end.
データ転送が完全にノードAからノードBへのものである場合、このドキュメントで指定された元のメカニズムECNとメカニズムECN /TRYONCEとの間にパフォーマンスに依然として違いがあることに注意してください。特に、ECN /TRYONCEでは、TCPオリジネーターは、反対側から非ECNマークのSyn /ACKパケットを受信するまでデータパケットを送信しません。
The addition of ECN-Capability to TCP's SYN/ACK packets was initially proposed in [ECN+]. The paper includes an extensive set of simulation and testbed experiments to evaluate the effects of the proposal, using several Active Queue Management (AQM) mechanisms, including Random Early Detection (RED) [RED], Random Exponential Marking (REM) [REM], and Proportional Integrator (PI) [PI]. The performance measures were the end-to-end response times for each request/response pair, and the aggregate throughput on the bottleneck link. The end-to-end response time was computed as the time from the moment when the request for the file is sent to the server, until that file is successfully downloaded by the client.
TCPのSyn/ACKパケットへのECNキャピールの追加が最初に[ECN]で提案されました。このペーパーには、ランダムアーリー検出（赤）[赤]、ランダム指数マーキング（REM）[REM]、いくつかのアクティブキュー管理（AQM）メカニズムを使用して、提案の効果を評価するためのシミュレーションとテストベッドの広範な実験セットが含まれています。および比例積分器（PI）[PI]。パフォーマンス測定は、各リクエスト/応答ペアのエンドツーエンド応答時間、およびボトルネックリンクの集計スループットでした。エンドツーエンドの応答時間は、ファイルのリクエストがサーバーに送信される瞬間から、そのファイルがクライアントによって正常にダウンロードされるまで計算されました。
The measurements from [ECN+] show that setting an ECN-Capable codepoint in the IP packet header in TCP SYN/ACK packets systematically improves performance with all evaluated AQM schemes. When SYN/ACK packets at a congested router are ECN-marked instead of dropped, this can avoid a long initial retransmission timeout, improving the response time for the affected flow dramatically.
[ECN]からの測定値は、TCP Syn/ACKパケットのIPパケットヘッダーにECN対応のコードポイントを設定すると、評価されたすべてのAQMスキームでパフォーマンスが体系的に向上することを示しています。混雑したルーターのsyn/ackパケットがドロップされる代わりにecnマークされている場合、これにより、長い最初の再送信タイムアウトを回避し、影響を受けるフローの応答時間を劇的に改善できます。
[ECN+] shows that the impact on aggregate throughput can also be quite significant, because marking SYN ACK packets can prevent larger flows from suffering long timeouts before being "admitted" into the network. In addition, the testbed measurements from [ECN+] show that web servers setting the ECN-Capable codepoint in TCP SYN/ACK packets could serve more requests.
[ECN]は、Syn ACKパケットをマークすると、ネットワークに「認められた」前に大きなフローが長い時間をかけるのを防ぐことができるため、集約スループットへの影響も非常に重要である可能性があることを示しています。さらに、[ECN]からのテストベッド測定では、TCP Syn/ACKパケットのECN対応コードポイントを設定するWebサーバーがより多くのリクエストを提供できることを示しています。
As a final step, [ECN+] explores the coexistence of flows that do and don't set the ECN-Capable codepoint in TCP SYN/ACK packets. The results in [ECN+] show that both types of flows can coexist, with some performance degradation for flows that don't use ECN+. Flows that do use ECN+ improve their end-to-end performance. At the same time, the performance degradation for flows that don't use ECN+, as a result of the flows that do use ECN+, increases as a greater fraction of flows use ECN+.
最後のステップとして、[ECN]は、TCP syn/ACKパケットにECN対応のコードポイントを設定しないフローの共存を調査します。[ECN]の結果は、両方のタイプのフローが共存できることを示しており、ECNを使用しないフローのパフォーマンス劣化があります。ECNを使用するフローは、エンドツーエンドのパフォーマンスを改善します。同時に、ECNを使用するフローの結果として、ECNを使用しないフローのパフォーマンス分解は、ECNを使用するフローの割合が大きくなるにつれて増加します。
[ECN+] explores the costs and benefits of adding ECN-Capability to SYN/ACK packets with both simulations and experiments. The addition of ECN-Capability to SYN/ACK packets could be of significant benefit for those ECN connections that would have had the SYN/ACK packet dropped in the network, and for which the ECN-Capability would allow the SYN/ACK to be marked rather than dropped.
[ECN]は、シミュレーションと実験の両方を使用して、Syn/ACKパケットにECNキャピールを追加することのコストと利点を調査します。Syn/ACKパケットへのECNキャピールの追加は、NetworkでSyn/ACKパケットをドロップし、ECN担当性によりSyn/ACKをマークすることを可能にするECN接続にとって大きな利点がある可能性があります。落とすのではなく。
The percent of SYN/ACK packets on a link can be quite high. In particular, measurements on links dominated by web traffic indicate that 15-20% of the packets can be SYN/ACK packets [SCJO01].
リンク上のsyn/ackパケットの割合は非常に高い場合があります。特に、Webトラフィックが支配するリンクの測定は、パケットの15〜20％がSyn/ACKパケットである可能性があることを示しています[SCJO01]。
The benefit of adding ECN-Capability to SYN/ACK packets depends in part on the size of the data transfer. The drop of a SYN/ACK packet can increase the download time of a short file by an order of magnitude, by requiring a three-second retransmission timeout. For longer-lived flows, the effect of a dropped SYN/ACK packet on file download time is less dramatic. However, even for longer-lived flows, the addition of ECN-Capability to SYN/ACK packets can improve the fairness among long-lived flows, as newly arriving flows would be less likely to have to wait for retransmission timeouts.
syn/ackパケットにECNキャピールを追加することの利点は、データ転送のサイズに一部依存します。SYN/ACKパケットのドロップにより、3秒の再送信タイムアウトを必要とすることにより、短いファイルのダウンロード時間を数桁増加させることができます。長寿命のフローの場合、ファイルのダウンロード時間に対するsyn/ackパケットの落下の効果は劇的ではありません。ただし、長寿命のフローであっても、新たに到着するフローは再送信のタイムアウトを待つ必要がないため、syn/ackパケットへのECN能力を追加すると、長寿命のフローの公平性が向上する可能性があります。
One question that arises is what fraction of connections would see the benefit from making SYN/ACK packets ECN-Capable in a particular scenario. Specifically:
発生する質問の1つは、特定のシナリオでsyn/ackパケットをecn対応にすることで、接続の一部がどのように利益を得るかです。具体的には：
(1) What fraction of arriving SYN/ACK packets are dropped at the congested router when the SYN/ACK packets are not ECN-Capable?
(1) syn/ackパケットがecn対応ではない場合、到着したsyn/ackパケットの割合は、混雑したルーターでドロップされますか？
(2) Of those SYN/ACK packets that are dropped, what fraction would have been ECN-marked instead of dropped if the SYN/ACK packets had been ECN-Capable?
(2) ドロップされたsyn/ackパケットのうち、syn/ackパケットがecn対応であった場合、どの割合がドロップされる代わりにecnマークされていたでしょうか？
To answer (1), it is necessary to consider not only the level of congestion but also the queue architecture at the congested link. As described in Section 4 above, for some queue architectures, small packets are less likely to be dropped than large ones. In such an environment, SYN/ACK packets would have lower packet drop rates; question (1) could not necessarily be inferred from the overall packet drop rate, but could be answered by measuring the drop rate for SYN/ACK packets directly. In such an environment, adding ECN-Capability to SYN/ACK packets would be of less dramatic benefit than in environments where all packets are equally likely to be dropped regardless of packet size.
（1）に答えるには、輻輳のレベルだけでなく、混雑したリンクのキューアーキテクチャも考慮する必要があります。上記のセクション4で説明されているように、いくつかのキューアーキテクチャの場合、小さなパケットは大きなパケットよりも削除される可能性が低くなります。このような環境では、Syn/ACKパケットのパケットドロップレートが低くなります。質問（1）は、パケット全体のドロップレートから必ずしも推測することはできませんでしたが、Syn/ACKパケットのドロップレートを直接測定することで回答することができます。このような環境では、syn/ackパケットにECNキャピールを追加することは、パケットサイズに関係なくすべてのパケットが等しく削除される可能性が高い環境よりも劇的な利点がありません。
As question (2) implies, even if all of the SYN/ACK packets were ECN-Capable, there could still be some SYN/ACK packets dropped instead of marked at the congested link; the full answer to question (2) depends on the details of the queue management mechanism at the router. If congestion is sufficiently bad, and the queue management mechanism cannot prevent the buffer from overflowing, then SYN/ACK packets will be dropped rather than marked upon buffer overflow whether or not they are ECN-Capable.
質問（2）が示唆するように、すべてのSyn/ACKパケットがECN対応であったとしても、混雑したリンクでマークされる代わりに、いくつかのSyn/ACKパケットがドロップされる可能性があります。質問（2）への完全な答えは、ルーターのキュー管理メカニズムの詳細に依存します。輻輳が十分に悪い場合、キュー管理メカニズムがバッファーのオーバーフローを防ぐことができない場合、syn/ackパケットは、それらがecn対応であるかどうかにかかわらず、バッファオーバーフローにマークされるのではなく削除されます。
For some AQM mechanisms, ECN-Capable packets are marked instead of dropped any time this is possible, that is, any time the buffer is not yet full. For other AQM mechanisms however, such as the RED mechanism as recommended in [RED], packets are dropped rather than marked when the packet drop/mark rate exceeds a certain threshold, e.g., 10%, even if the packets are ECN-Capable. For a router with such an AQM mechanism, when congestion is sufficiently severe to cause a high drop/mark rate, some SYN/ACK packets would be dropped instead of marked whether or not they were ECN-Capable.
一部のAQMメカニズムの場合、ECN対応パケットは、これが可能な時間、つまりバッファがまだ満たされていないときはいつでもドロップされる代わりにマークされます。ただし、[赤]で推奨される赤いメカニズムなど、他のAQMメカニズムの場合、パケットのドロップ/マークレートが特定のしきい値を超える場合、パケットがecn対応であっても10％を超える場合ではなく、パケットがマークされるのではなく削除されます。このようなAQMメカニズムを備えたルーターの場合、輻輳が高いドロップ/マークレートを引き起こすのに十分に深刻な場合、ECN対応であるかどうかにかかわらず、一部のSYN/ACKパケットがドロップされます。
Thus, the degree of benefit of adding ECN-Capability to SYN/ACK packets depends not only on the overall packet drop rate in the network, but also on the queue management architecture at the congested link.
したがって、syn/ackパケットにECNキャピールを追加する利点の程度は、ネットワークの全体的なパケットドロップレートだけでなく、混雑したリンクのキュー管理アーキテクチャにも依存します。
This document specifies that the end node responds to the report of an ECN-marked SYN/ACK packet by setting the initial congestion window to one segment, instead of its possible default value of two to four segments, and resending a SYN/ACK packet that is not ECN-Capable. We call this ECN+/TryOnce.
このドキュメントは、エンドノードが、2〜4つのセグメントの可能なデフォルト値ではなく、1つのセグメントに初期輻輳ウィンドウを1つのセグメントに設定し、syn/ackパケットを留保することにより、ECNマークされたSyn/ACKパケットのレポートに応答することを指定しています。ECN対応ではありません。これをECN /TRYONCEと呼びます。
However, Section 4 discussed two other possible responses to an ECN-marked SYN/ACK packet. In ECN+, the original proposal from [ECN+], the end node responds to the report of an ECN-marked SYN/ACK packet by setting the initial congestion window to one segment and immediately sending a data packet, if it has one to send. In ECN+/Wait, the end node responds to the report of an ECN-marked SYN/ACK packet by setting the initial congestion window to one segment and waiting an RTT before sending a data packet.
ただし、セクション4では、ECNマークされたSyn/ACKパケットに対する他の2つの可能な応答について説明しました。[ECN]からの元の提案であるECNでは、Endノードは、最初の輻輳ウィンドウを1つのセグメントに設定し、送信するものがある場合はすぐにデータパケットを送信することにより、ECNマークされたSyn/ACKパケットのレポートに応答します。ECN /待機では、エンドノードは、初期輻輳ウィンドウを1つのセグメントに設定し、データパケットを送信する前にRTTを待機することにより、ECNマーク型Syn /ACKパケットのレポートに応答します。
Simulations comparing the performance with Standard ECN (without ECN-marked SYN/ACK packets), ECN+, ECN+/Wait, and ECN/TryOnce show little difference, in terms of aggregate congestion, between ECN+ and ECN+/Wait. However, for some scenarios with queues that are packet-based rather than byte-based, and with packet drop rates above 25% without ECN+, the use of ECN+ or of ECN+/Wait can more than double the packet drop rates to greater than 50%. The details are given in Tables 1 and 3 of Appendix A below. ECN+/TryOnce does not increase the packet drop rate in scenarios of high congestion. Therefore, ECN+/TryOnce is superior to ECN+ or to ECN+/Wait, which both significantly increase the packet drop rate in scenarios of high congestion. At the same time, ECN+/TryOnce gives a performance improvement similar to that of ECN+ or ECN+/Wait (Tables 2 and 4 of Appendix A).
パフォーマンスを標準のECN（ECNマーク付きSYN /ACKパケットなし）、ECN、ECN /待機、およびECN /TryOnceと比較するシミュレーションは、ECNとECN /待機の間の集約輻輳の観点からほとんど違いを示しません。ただし、バイトベースではなくパケットベースのキューを備えた一部のシナリオの場合、ECNなしで25％を超えるパケットドロップレートを使用すると、ECNまたはECN /待機の使用は、パケットドロップレートを50を超える2倍以上になります。％。詳細については、以下の付録Aの表1および3に記載されています。ECN /TRYONCEは、高い輻輳のシナリオでパケットドロップレートを上げることはありません。したがって、ECN /TRYONCEはECNまたはECN /待機よりも優れており、どちらも高い輻輳のシナリオでパケットドロップレートを大幅に増加させます。同時に、ECN /TRYONCEは、ECNまたはECN /待機のパフォーマンスと同様のパフォーマンス改善を提供します（付録Aの表2および4）。
Our conclusions are that ECN+/TryOnce is safe, and has significant benefits to the user, and avoids the problems of ECN+ or ECN+/Wait under extreme levels of congestion. As a consequence, this document specifies the use of ECN+/TryOnce.
私たちの結論は、ECN /TryOnceは安全であり、ユーザーにとって大きな利点があり、ECNまたはECN /待機の問題を回避することです。結果として、このドキュメントはECN /TRYONCEの使用を指定します。
Note: We only discovered the occasional congestion-related problems of ECN+ and of ECN+/Wait when re-running the simulations with an updated version of the ns-2 simulator, after the document had almost completed the standardization process.
注：ドキュメントが標準化プロセスをほぼ完了した後、NS-2シミュレーターの更新バージョンでシミュレーションを再ランニングするとき、ECNおよびECN /待機の時折の混雑関連の問題を発見しました。
This section discusses experiments that would be useful before a widespread deployment of ECN-Capability for TCP SYN/ACK packets.
このセクションでは、TCP Syn/ACKパケットのECNキャピールの広範な展開の前に役立つ実験について説明します。
Section 7.1 below discusses some of the known deployment problems of ECN, in terms of routers or middleboxes that react inappropriately to packets that use ECN codepoints in the IP or TCP packet headers. One goal of a measurement study of ECN-Capability for TCP SYN/ACK packets would be to determine if there were any routers or middleboxes that react inappropriately to TCP SYN/ACK packets containing an ECN-Capable or CE codepoint in the IP header. A second goal of a measurement study would be to check the deployment status of older TCP implementations that are ECN-Capable, but that don't respond to ECN-Capability for SYN/ACK packets. (This is discussed in more detail in Appendix B below.)
以下のセクション7.1では、IPまたはTCPパケットヘッダーでECNコードポイントを使用するパケットに不適切に反応するルーターまたはミドルボックスの観点から、ECNの既知の展開問題のいくつかについて説明します。TCP Syn/ACKパケットのECNキャピールの測定研究の1つの目標は、IPヘッダーにECN対応またはCEコードポイントを含むTCP Syn/ACKパケットに不適切に反応するルーターまたはミドルボックスがあるかどうかを判断することです。測定研究の2番目の目標は、ECN対応の古いTCP実装の展開ステータスを確認することですが、Syn/ACKパケットのECNキャピールに応答しないことです。（これについては、以下の付録Bで詳しく説明しています。）
Following the discussion in Section 6.2, an experimental study could explore the use of ECN-Capability for TCP SYN/ACK packets in highly congested environments with ECN-Capable routers.
セクション6.2の議論に続いて、実験的研究では、ECN対応ルーターを使用した非常に混雑した環境でのTCP Syn/ACKパケットのECN能力の使用を調査できます。
TCP packets carrying the ECT codepoint in IP headers can be marked rather than dropped by ECN-Capable routers. This raises several security concerns that we discuss below.
IPヘッダーでECT CodePointを運ぶTCPパケットは、ECN対応ルーターでドロップするのではなく、マークできます。これは、以下で説明するいくつかのセキュリティ上の懸念を提起します。
There are a number of known deployment problems from using ECN with TCP traffic in the Internet. The first reported problem, dating back to 2000, is of a small but decreasing number of routers or middleboxes that reset a TCP connection in response to TCP SYN packets using flags in the TCP header to negotiate ECN-Capability [Kelson00] [RFC3360] [MAF05]. Dave Thaler reported at the March 2007 IETF of two new problems encountered by TCP connections using ECN; the first of the two problems concerns routers that crash when a TCP data packet arrives with the ECN field in the IP header with the codepoint ECT(0) or ECT(1), indicating that an ECN-Capable connection has been established [SBT07].
インターネットでTCPトラフィックを使用してECNを使用することから、多くの既知の展開の問題があります。2000年にさかのぼる最初の報告された問題は、TCPヘッダーのフラグを使用してTCP SynパケットをリセットするためにECNキャピール[KELSON00] [RFC3360] [[RFC3360] []を使用してTCP Synパケットをリセットするルーターまたはミドルボックスの数が小さくなっていますが、小規模ですがミドルボックスの数が減少しています。MAF05]。Dave Thalerは、2007年3月に、ECNを使用してTCP接続で遭遇した2つの新しい問題のIETFを報告しました。2つの問題のうち最初の問題は、TCPデータパケットがCodePoint ECT（0）またはECT（1）を使用してIPヘッダーのECNフィールドに到着したときにクラッシュするルーターに関係しています。。
While there is no evidence that any routers or middleboxes drop SYN/ACK packets that contain an ECN-Capable or CE codepoint in the IP header, such behavior cannot be excluded. (There seems to be a number of routers or middleboxes that drop TCP SYN packets that contain known or unknown IP options (see figure 1 of [MAF05].) Thus, as specified in Section 3, if a SYN/ACK packet with the ECT or CE codepoint is dropped, the TCP node should resend the SYN/ACK packet without the ECN-Capable codepoint. There is also no evidence that any routers or middleboxes crash when a SYN/ACK arrives with an ECN-Capable or CE codepoint in the IP header (over and above the routers already known to crash when a data packet arrives with either ECT(0) or ECT(1)), but we have not conducted any measurement studies of this [F07].
ルーターまたはミドルボックスがIPヘッダーにECN対応またはCEコードポイントを含むSyn/ACKパケットをドロップするという証拠はありませんが、そのような動作は除外できません。（既知または未知のIPオプションを含むTCP Synパケットをドロップする多くのルーターまたはミドルボックスがあるようです（[MAF05]の図1を参照）。またはCE CodePointがドロップされ、TCPノードはECN対応のコードポイントなしでSyn/ACKパケットを再送信する必要があります。Syn/ACKがECN対応またはCEコードポイントでsyn/ackが到着したときにルーターまたはミドルボックスがクラッシュするという証拠もありません。IPヘッダー（ECT（0）またはECT（1）のいずれかでデータパケットが到着したときにクラッシュすることがすでに知られているルーターの上にあります）が、この[F07]の測定研究を実施していません。
Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN-marked instead of dropped at an ECN-Capable router, the concern is whether this can either invoke congestion or worsen performance in highly congested scenarios. However, after learning that a SYN/ACK packet was ECN-marked, the responder sends a SYN/ACK packet that is not ECN-Capable; if this SYN/ACK packet is dropped, the responder then waits for a retransmission timeout, as specified in the TCP standards. In addition, routers are free to drop rather than mark arriving packets in times of high congestion, regardless of whether the packets are ECN-Capable. When congestion is very high and a router's buffer is full, the router has no choice but to drop rather than to mark an arriving packet.
ECT CodePointを運ぶTCP syn/ACKパケットは、ECN対応ルーターでドロップする代わりにECNマークを付ける可能性があるため、これが非常に混雑したシナリオで混雑を呼び出すか、パフォーマンスを悪化させるかどうかです。ただし、syn/ackパケットがecnマークされていることを知った後、レスポンダーはecn/ckパケットを送信します。このSyn/ACKパケットがドロップされた場合、ResponderはTCP標準で指定されているように、再送信タイムアウトを待ちます。さらに、パケットがECN対応であるかどうかにかかわらず、ルーターは高い輻輳の時に到着するのではなく、自由にドロップできます。輻輳が非常に高く、ルーターのバッファーがいっぱいになると、ルーターは到着するパケットをマークするのではなく、ドロップする以外に選択肢がありません。
The simulations reported in Appendix A show that even with demanding traffic mixes dominated by short flows and high levels of congestion, the aggregate packet dropping rates are not significantly different with Standard ECN or with ECN+/TryOnce. However, in our simulations, we have one scenario where ECN+ or ECN+/Wait results in a significantly higher packet drop rate than ECN or ECN+/TryOnce (Tables 1 and 3 in Appendix A below).
付録Aで報告されたシミュレーションは、要求の厳しいトラフィックが短いフローと高レベルの輻輳に支配されている場合でも、総パケットのドロップレートが標準のECNまたはECN /トリオンセと有意差がないことを示しています。ただし、シミュレーションでは、ECNまたはECN /待機により、ECNまたはECN /TryOnceよりも大幅に高いパケットドロップレートが得られるシナリオが1つあります（下の付録Aの表1および3）。
This document specifies a modification to RFC 3168 [RFC3168] to allow TCP nodes to send SYN/ACK packets as being ECN-Capable. Making the SYN/ACK packet ECN-Capable avoids the high cost to a TCP transfer when a SYN/ACK packet is dropped by a congested router, by avoiding the resulting retransmission timeout. This improves the throughput of short connections. This document specifies the ECN+/TryOnce mechanism for ECN-Capability for SYN/ACK packets, where the sender of the SYN/ACK packet responds to an ECN mark by reducing its initial congestion window from two, three, or four segments to one segment, and sending a SYN/ACK packet that is not ECN-Capable. The addition of ECN-Capability to SYN/ACK packets is particularly beneficial in the server-to-client direction, where congestion is more likely to occur. In this case, the initial information provided by the ECN marking in the SYN/ACK packet enables the server to appropriately adjust the initial load it places on the network, while avoiding the delay of a retransmission timeout.
このドキュメントは、RFC 3168 [RFC3168]の変更を指定して、TCPノードがsyn/ACKパケットをECN対応として送信できるようにします。SYN/ACKパケットECN対応を作成すると、結果として生じる再送信時刻を回避することにより、Syn/ACKパケットが混雑したルーターによってドロップされた場合、TCP転送の高コストを回避します。これにより、短い接続のスループットが改善されます。このドキュメントは、Syn/ACKパケットのECN/ACKパケットの送信者が2つ、3つ、または4つのセグメントから1つのセグメントに4つのセグメントに削減することによりECNマークに応答するECN/ACKパケットのECN/TRYONCEメカニズムを指定します。ECN対応ではないSyn/ACKパケットを送信します。Syn/ACKパケットへのECNキャピールの追加は、輻輳が発生する可能性が高いサーバーからクライアントへの方向で特に有益です。この場合、Syn/ACKパケットでECNマーキングによって提供される初期情報により、サーバーは、再送信タイムアウトの遅延を避けながら、ネットワーク上に配置された初期負荷を適切に調整できます。
We thank Anil Agarwal, Mark Allman, Remi Denis-Courmont, Wesley Eddy, Lars Eggert, Alfred Hoenes, Janardhan Iyengar, and Pasi Sarolahti for feedback on earlier working drafts of this document. We thank Adam Langley [L08] for contributing a patch for ECN+/TryOnce for the Linux development tree.
Anil Agarwal、Mark Allman、Remi Denis-Courmont、Wesley Eddy、Lars Eggert、Alfred Hoenes、Janardhan Iyengar、Pasi Sarolahtiに、この文書の以前の作業ドラフトに関するフィードバックに感謝します。Linux開発ツリーのECN /TryOnceのパッチを提供してくれたAdam Langley [L08]に感謝します。
This section reports on simulations showing the costs of adding ECN+ in highly congested scenarios. This section also reports on simulations for a comparative evaluation between ECN, ECN+, ECN+/Wait, and ECN+/TryOnce.
このセクションでは、非常に混雑したシナリオにECNを追加するコストを示すシミュレーションについて報告します。また、このセクションでは、ECN、ECN、ECN /待機、およびECN /TryOnce間の比較評価のシミュレーションについても報告しています。
The simulations are run with a range of file-size distributions, using the PackMime traffic generator in the ns-2 simulator. They all use a heavy-tailed distribution of file sizes. The simulations reported in the tables below use a mean file size of 3 Kbytes, to show the results with a traffic mix with a large number of small transfers. Other simulations were run with mean file sizes of 5 Kbytes, 7 Kbytes, 14 Kbytes, and 17 Kbytes. The title of each chart gives the targeted average load from the traffic generator. Because the simulations use a heavy-tailed distribution of file sizes, and run for only 85 seconds (including ten seconds of warm-up time), the actual load is often much smaller than the targeted load. The congested link is 100 Mbps. RED is run in gentle mode, and arriving ECN-Capable packets are only dropped instead of marked if the buffer is full (and the router has no choice).
シミュレーションは、NS-2シミュレーターのPackmimeトラフィックジェネレーターを使用して、さまざまなファイルサイズ分布で実行されます。それらはすべて、ファイルサイズの重尾の分布を使用しています。下の表で報告されているシミュレーションは、3 kバイトの平均ファイルサイズを使用して、多数の小さな転送とトラフィックミックスで結果を示します。他のシミュレーションは、5 kバイト、7 kバイト、14 kバイト、17 kバイトの平均ファイルサイズで実行されました。各チャートのタイトルは、トラフィックジェネレーターからのターゲットの平均負荷を示しています。シミュレーションはファイルサイズの重尾の分布を使用し、わずか85秒（10秒のウォームアップ時間を含む）だけ実行されるため、実際の負荷はターゲット負荷よりもはるかに小さいことがよくあります。混雑したリンクは100 Mbpsです。赤は穏やかなモードで実行され、到着するECN対応パケットは、バッファがいっぱいの場合にのみマークされる代わりにドロップされます（ルーターには選択肢がありません）。
We explore three possible mechanisms for a TCP node's response to a report of an ECN-marked SYN/ACK packet. With ECN+, the TCP node sends a data packet immediately (with an initial congestion window of one segment). With ECN+/Wait, the TCP node waits a round-trip time before sending a data packet; the responder already has one measurement of the round-trip time when the acknowledgement for the SYN/ACK packet is received. With ECN+/TryOnce, the mechanism standardized in this document, the TCP responder replies to a report of an ECN-marked SYN/ACK packet by sending a SYN/ACK packet that is not ECN-Capable, and reducing the initial congestion window to one segment.
ECNマークされたSyn/ACKパケットのレポートに対するTCPノードの応答の3つの可能なメカニズムを調査します。ECNを使用すると、TCPノードはデータパケットをすぐに送信します（1つのセグメントの初期輻輳ウィンドウを使用）。ECN /待機すると、TCPノードはデータパケットを送信する前に往復時間を待ちます。Responderには、Syn/ACKパケットの確認が受信された往復時間の測定値がすでに1つあります。このドキュメントに標準化されたメカニズムであるECN/TRYONCEを使用すると、TCP ResponderはECN/ACKパケットを送信してECN/ACKパケットを送信し、初期輻輳ウィンドウを1つに減らすことにより、ECNマーク型Syn/ACKパケットのレポートに返信します。セグメント。
The simulation scripts are available on [ECN-SYN], along with graphs showing the distribution of response times for the TCP connections.
シミュレーションスクリプトは、[ECN-Syn]で利用でき、TCP接続の応答時間の分布を示すグラフが利用できます。
The simulations with RED in packet mode and with the queue in packets show that ECN+ is useful in times of moderate or high congestion. However, for the simulations with a target load of 125%, with a packet loss rate of over 25% for ECN, ECN+ and ECN+/Wait both result in a packet loss rate of over 50%. (In contrast, the packet loss rate with ECN+/TryOnce is less than that of ECN alone.) For the distribution of response times, the simulations show that ECN+, ECN+/Wait, and ECN+/TryOnce all significantly improve the response times, when compared to the response times with Standard ECN.
パケットモードの赤とパケットのキューを伴うシミュレーションは、ECNが中程度または高い輻輳の時に有用であることを示しています。ただし、ターゲット負荷が125％のシミュレーションでは、ECN、ECN、およびECN /待機のパケット損失率が25％を超えると、両方とも50％を超えるパケット損失率が得られます。（対照的に、ECN /TRYONCEによるパケット損失率はECN単独のパケット損失率よりも少ない。）応答時間の分布については、シミュレーションでは、ECN、ECN /待機、およびECN /TRYONCEが応答時間を大幅に改善することを示しています。標準ECNを使用した応答時間と比較してください。
Table 1 shows the congestion levels for simulations with RED in packet mode, with a queue in packets. To explore a worst-case scenario, these simulations use a traffic mix with an unrealistically small flow size distribution, with a mean flow size of 3 Kbytes. For each table showing a particular traffic load, the four rows show the number of packets dropped, the number of packets ECN-marked, the aggregate packet drop rate, and the aggregate throughput. The four columns show the simulations with Standard ECN, ECN+, ECN+/Wait, and ECN+/TryOnce.
表1は、パケットモードで赤い赤のシミュレーションの輻輳レベルを示しています。パケットにキューがあります。最悪のシナリオを調査するために、これらのシミュレーションは、平均フローサイズが3 kバイトの非現実的に小さなフローサイズ分布を備えたトラフィックミックスを使用します。特定のトラフィック負荷を示す各テーブルについて、4行にはドロップされたパケットの数、ECNマークのパケットの数、集約パケットドロップレート、および集計スループットが表示されます。4つの列には、標準のECN、ECN、ECN /待機、およびECN /トリオンセによるシミュレーションが表示されます。
These simulations were run with RED set to mark instead of drop packets any time that the queue is not full. This is a worst-case scenario for ECN+ and its variants. For the default implementation of RED in the ns-2 simulator, when the average queue size exceeds a configured threshold, the router drops all arriving packets. For scenarios with this RED mechanism, it is less likely that ECN+ or one of its variants would increase the average queue size above the configured threshold.
これらのシミュレーションは、キューがいっぱいになっていないときはいつでもドロップパケットの代わりに赤いセットで実行されました。これは、ECNとそのバリアントの最悪のシナリオです。NS-2シミュレーターでのREDのデフォルト実装の場合、平均キューサイズが構成されたしきい値を超えると、ルーターはすべての到着パケットをドロップします。この赤いメカニズムを備えたシナリオの場合、ECNまたはそのバリアントの1つが、構成されたしきい値を上回る平均キューサイズを増加させる可能性は低くなります。
The usefulness of ECN+: The first thing to observe is that for all of the simulations, the use of ECN+ or ECN+/Wait significantly increases the number of packets marked. In contrast, the use of ECN+/TryOnce significantly increases the number of packets marked in the simulations with moderate congestion, and gives a more moderate increase in the number of packets marked for the simulations with higher levels of congestion. However, the cumulative distribution function (CDF) in Table 2 shows that ECN+, ECN+/Wait, and ECN+/TryOnce all improve response times for all of the simulations, with moderate or with larger levels of congestion.
ECNの有用性：最初に観察することは、すべてのシミュレーションで、ECNまたはECN /待機を使用すると、マークされたパケットの数が大幅に増加することです。対照的に、ECN /TryOnceを使用すると、中程度の輻輳があるシミュレーションでマークされたパケットの数が大幅に増加し、輻輳のレベルが高いシミュレーションにマークされたパケットの数がより中程度の増加をもたらします。ただし、表2の累積分布関数（CDF）は、ECN、ECN /待機、およびECN /TryOnceがすべてのシミュレーションの応答時間をすべて改善し、中程度またはより大きなレベルの輻輳を示していることを示しています。
Little increase in congestion, sometimes: The second thing to observe is that for the simulations with low or moderate levels of congestion (that is, with packet drop rates less than 10%), the use of ECN+, ECN+/Wait, and ECN+/TryOnce all decrease the aggregate packet drop rate relative to the simulations with ECN. This makes sense, since with low or moderate levels of congestion, ECN+ allows SYN/ACK packets to be marked instead of dropped, and the use of ECN+ doesn't add to the aggregate congestion. However, for the simulations with packet drop rates of 15% or higher with ECN, the use of ECN+ or ECN+/Wait increases the aggregate packet drop rate, sometimes even doubling it.
うっ血のほとんどの増加、時には次のとおりです。2番目に観察することは、うっ血の低いまたは中程度のレベルのシミュレーション（つまり、パケットドロップ率が10％未満）、ECN、ECN /待機、ECN / /すべてのTRYONCEは、ECNを使用したシミュレーションと比較して、集計パケットドロップレートを減少させます。これは理にかなっています。中程度のレベルの輻輳が低いか中程度のレベルであるため、ECNは削除する代わりにSyn/ACKパケットをマークすることができ、ECNの使用は凝集渋滞に追加されません。ただし、ECNを使用して15％以上のパケットドロップレートを備えたシミュレーションでは、ECNまたはECN /待機を使用すると、合計パケットドロップレートが増加し、倍増する場合もあります。
Comparing ECN+, ECN+/Wait, and ECN+/TryOnce: The aggregate packet drop rate is generally higher with ECN+/Wait than with ECN+. Thus, there is no congestion-related reason to prefer ECN+/Wait over ECN+. In contrast, the aggregate packet drop rate with ECN+/TryOnce is often significantly lower than the aggregate packet drop rate with either ECN, ECN+, or ECN+/Wait.
ECN、ECN /待機、およびECN /トリオンセの比較：集約パケットドロップレートは、ECN /待機で一般にECNよりも高くなります。したがって、ECNを好む /ECNを待つための混雑関連の理由はありません。対照的に、ECN /TRYONCEを使用した集計パケットドロップレートは、ECN、ECN、またはECN /待機のいずれかを使用した集計パケットドロップレートよりも大幅に低いことがよくあります。
Target Load = 95%:
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 20,516 11,226 11,735 16,755`
Marked 30,586 37,741 37,425 40,764
Loss rate 1.41% 0.78% 0.81% 1.02%
Throughput 81% 81% 81% 81%
Target Load = 110%:
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 165,566 106,083 147,180 208,422
Marked 179,735 281,306 308,473 235,483
Loss rate 9.01% 6.12% 8.02% 6.89%
Throughput 92% 92% 92% 94%
Target Load = 125%:
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 600,628 1,746,768 2,176,530 625,552
Marked 418,433 1,166,450 1,164,932 439,847
Loss rate 25.45% 51.73% 56.87% 18.31%
Throughput 94% 98% 97% 95%
Target Load = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 1,449,945 1,565,0517 1,563,0801 1,351,637
Marked 669,840 583,378 591,315 684,715
Loss rate 46.7% 59.0% 59.0% 32.7%
Throughput 88% 94% 94% 92%
Table 1: Simulations with an average flow size of 3 Kbytes, a 100 Mbps link, RED in packet mode, queue in packets
表1：平均フローサイズが3 kbytes、100 mbpsリンク、パケットモードの赤、パケットのキューのシミュレーション
Target Load = 95%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.07 0.26 0.51 0.82 0.96 0.97 0.97 0.97 1.00 1.00
ECN+: 0.00 0.07 0.27 0.53 0.85 0.99 1.00 1.00 1.00 1.00 1.00
Wait: 0.00 0.07 0.26 0.51 0.83 0.97 1.00 1.00 1.00 1.00 1.00
Once: 0.00 0.07 0.24 0.49 0.83 0.97 1.00 1.00 1.00 1.00 1.00
Target Load = 110%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.05 0.19 0.41 0.67 0.79 0.80 0.80 0.80 0.96 0.96
ECN+: 0.00 0.07 0.22 0.48 0.81 0.96 1.00 1.00 1.00 1.00 1.00
Wait: 0.00 0.05 0.18 0.38 0.64 0.77 0.95 1.00 1.00 1.00 1.00
Once: 0.00 0.06 0.19 0.42 0.70 0.86 0.95 0.96 0.96 0.99 0.99
Target Load = 125%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.04 0.13 0.27 0.46 0.56 0.58 0.59 0.59 0.82 0.82
ECN+: 0.00 0.06 0.18 0.33 0.58 0.76 0.97 0.99 0.99 1.00 1.00
Wait: 0.00 0.01 0.06 0.13 0.21 0.27 0.68 0.98 0.99 1.00 1.00
Once: 0.00 0.05 0.16 0.34 0.58 0.73 0.85 0.87 0.87 0.95 0.96
Target Load = 150%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.03 0.08 0.18 0.31 0.39 0.42 0.42 0.43 0.68 0.68
ECN+: 0.00 0.06 0.18 0.39 0.67 0.81 0.83 0.84 0.84 0.93 0.93
Wait: 0.00 0.06 0.18 0.39 0.67 0.81 0.83 0.84 0.84 0.93 0.94
Once: 0.00 0.04 0.13 0.27 0.46 0.59 0.72 0.75 0.75 0.88 0.88
Table 2: The cumulative distribution function (CDF) for transfer times, for simulations with an average flow size of 3 Kbytes, a 100 Mbps link, RED in packet mode, queue in packets (the graphs are available from "http://www.icir.org/floyd/ecn-syn/")
表2：転送時間の累積分布関数（CDF）、平均フローサイズ3 kbytes、100 mbpsリンク、パケットモードの赤、パケットのキュー（http：// wwwから入手できます）.icir.org/floyd/ecn-syn/"）
Target Load = 95%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 8,448 6,362 7,740 14,107
Marked 9,891 16,787 17,456 16,132
Loss rate 5.5% 4.3% 5.0% 5.0%
Throughput 78% 78% 78% 81%
Target Load = 110%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 31,284 29,773 49,297 45,277
Marked 28,429 54,729 60,383 34,622
Loss rate 15.3% 15.2% 21.9% 13.6%
Throughput 97% 96% 96% 94%
Target Load = 125%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 61,433 176,682 214,096 75,612
Marked 44,408 119,728 117,301 49,442
Loss rate 25.4% 51.9% 56.0% 22.3%
Throughput 97% 98% 98% 96%
Target Load = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 130,007 251,856 326,845 133,603
Marked 63,066 146,757 147,239 66,444
Loss rate 42.5% 61.3% 67.3% 31.7%
Throughput 93% 99% 99% 94%
Table 3: Simulations with an average flow size of 3 Kbytes, a 10 Mbps link, RED in packet mode, queue in packets
表3：平均フローサイズが3 kbytes、10 mbpsリンク、パケットモードで赤、パケットのキューを持つシミュレーション
Target Load = 95%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.05 0.18 0.42 0.70 0.86 0.88 0.88 0.88 0.98 0.98
ECN+: 0.00 0.06 0.20 0.45 0.78 0.96 1.00 1.00 1.00 1.00 1.00
Wait: 0.00 0.05 0.18 0.40 0.68 0.84 0.96 1.00 1.00 1.00 1.00
Once: 0.00 0.05 0.18 0.40 0.71 0.88 0.96 0.97 0.97 0.99 0.99
Target Load = 110%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.03 0.13 0.29 0.52 0.66 0.69 0.69 0.69 0.91 0.91
ECN+: 0.00 0.05 0.17 0.36 0.66 0.88 0.98 0.99 1.00 1.00 1.00
Wait: 0.00 0.02 0.08 0.20 0.35 0.47 0.76 0.98 1.00 1.00 1.00
Once: 0.00 0.05 0.15 0.32 0.58 0.75 0.88 0.90 0.90 0.97 0.97
Target Load = 125%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.03 0.10 0.22 0.40 0.52 0.56 0.56 0.57 0.82 0.82
ECN+: 0.00 0.03 0.14 0.27 0.49 0.70 0.96 0.99 0.99 0.99 1.00
Wait: 0.00 0.00 0.03 0.07 0.12 0.18 0.50 0.94 0.99 0.99 1.00
Once: 0.00 0.04 0.13 0.28 0.51 0.66 0.81 0.84 0.84 0.94 0.94
Target Load = 150%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000
------------------------------------------------------
ECN: 0.00 0.02 0.07 0.15 0.28 0.38 0.42 0.42 0.43 0.67 0.68
ECN+: 0.00 0.00 0.00 0.00 0.01 0.05 0.68 0.83 0.95 0.97 0.98
Wait: 0.00 0.00 0.00 0.00 0.00 0.00 0.10 0.62 0.83 0.93 0.97
Once: 0.00 0.03 0.11 0.24 0.42 0.56 0.71 0.75 0.75 0.88 0.88
Table 4: The cumulative distribution function (CDF) for transfer times, for simulations with an average flow size of 3 Kbytes, a 10 Mbps link, RED in packet mode, queue in packets (the graphs are available from "http://www.icir.org/floyd/ecn-syn/")
表4：転送時間の累積分布関数（CDF）、平均フローサイズ3 kbytes、10 mbpsリンク、パケットモードの赤、パケットのキュー（http：// wwwから入手できます）.icir.org/floyd/ecn-syn/"）
Table 5 below shows simulations with RED in byte mode and the queue in bytes. There is no significant increase in aggregate congestion with the use of ECN+, ECN+/Wait, or ECN+/TryOnce.
以下の表5に、バイトモードの赤とバイトのキューを備えたシミュレーションを示しています。ECN、ECN /待機、またはECN /トリオンセを使用して、凝集渋滞に有意な増加はありません。
However, unlike the simulations with RED in packet mode, the simulations with RED in byte mode show little benefit from the use of ECN+ or ECN+/Wait, in that the packet marking rate with ECN+ or ECN+/Wait is not much different than the packet marking rate with Standard ECN. This is because with RED in byte mode, small packets like SYN/ACK packets are rarely dropped or marked -- that is, there is no drawback from the use of ECN+ in these scenarios, but not much need for ECN+ either, in a scenario where small packets are unlikely to be dropped or marked.
ただし、パケットモードで赤のシミュレーションとは異なり、BYTEモードの赤のシミュレーションは、ECNまたはECN /待機でパケットマーキングレートがパケットとは大きく異なるという点で、ECNまたはECN /待機の使用の利点をほとんど示していません。標準ECNを使用したマーキングレート。これは、バイトモードの赤で、syn/ackパケットのような小さなパケットがめったに削除されたりマークされたりすることはほとんどありません。つまり、これらのシナリオではECNの使用からの欠点はありませんが、シナリオでもECNの必要はありません。小さなパケットがドロップまたはマークされる可能性は低い場合。
Target Load = 95%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 766 446 427 408
Marked 32,683 34,289 33,412 31,892
Loss rate 0.05% 0.03% 0.03% 0.03%
Throughput 81% 81% 81% 81%
Target Load = 110%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 2,496 2,110 1,733 2,020
Marked 220,573 258,696 230,955 214,604
Loss rate 0.15% 0.13% 0.11% 0.11%
Throughput 92% 91% 92% 92%
Target Load = 125%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 20,032 13,555 13,979 16,918
Marked 725,165 726,992 726,823 615,235
Loss rate 1.11% 0.76% 0.78% 0.66%
Throughput 95% 95% 95% 96%
Target Load = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 484,251 483,847 507,727 600,737
Marked 865,905 872,254 873,317 818,451
Loss rate 19.09% 19.13% 19.71% 12.66%
Throughput 99% 98% 99% 99%
Table 5: Simulations with an average flow size of 3 Kbytes, a 100 Mbps link, RED in byte mode, queue in bytes
表5：平均フローサイズが3 kbytes、100 mbpsリンク、バイトモードで赤、バイトのキュー
Target Load = 95%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 142 77 103 99
Marked 11,694 11,387 11,604 12,129
Loss rate 0.1% 0.1% 0.1% 0.1%
Throughput 78% 78% 78% 78%
Target Load = 110%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 338 210 247 274
Marked 41,676 40,412 44,173 36,265
Loss rate 0.2% 0.1% 0.1% 0.1%
Throughput 94% 94% 94% 96%
Target Load = 125%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 1,559 951 978 1,723
Marked 74,933 75,499 75,481 59,670
Loss rate 0.8% 0.5% 0.5% 0.6%
Throughput 99% 99% 99% 96%
Target Load = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ----------
Dropped 2,374 1,528 1,515 4,848
Marked 85,739 86,428 86,144 81,350
Loss rate 1.2% 0.8% 0.8% 1.4%
Throughput 99% 98% 98% 98%
Table 6: Simulations with an average flow size of 3 Kbytes, a 10 Mbps link, RED in byte mode, queue in bytes
表6：平均フローサイズが3 kbytes、10 mbpsリンク、赤のバイトモード、バイトのキューのシミュレーション
In order for TCP node B to send a SYN/ACK packet as ECN-Capable, node B must have received an ECN-setup SYN packet from node A. However, it is possible that node A supports ECN, but either ignores the CE codepoint on received SYN/ACK packets, or ignores SYN/ACK packets with the ECT or CE codepoint set. If the TCP initiator ignores the CE codepoint on received SYN/ACK packets, this would mean that the TCP responder would not respond to this congestion indication. However, this seems to us an acceptable cost to pay in the incremental deployment of ECN-Capability for TCP's SYN/ACK packets. It would mean that the responder would not reduce the initial congestion window from two, three, or four segments down to one segment, as it should, and would not sent a non-ECN-Capable SYN/ACK packet to complete the SYN exchange. However, the TCP end nodes would still respond correctly to any subsequent CE indications on data packets later on in the connection.
TCPノードBがECN/ACKパケットをECN対応として送信するために、ノードBはノードAからECNセットアップSynパケットを受信している必要がありますが、ノードAはECNをサポートする可能性がありますが、CODEPOINTを無視する可能性があります。受信したSyn/ACKパケット、またはECTまたはCE CodePointセットでSyn/ACKパケットを無視します。TCPイニシエーターが受信したSYN/ACKパケットのCEコードポイントを無視した場合、これはTCPレスポンダーがこの鬱血指示に応答しないことを意味します。ただし、これは、TCPのSyn/ACKパケットのECNキャピールの増分展開において、受け入れられる費用を支払うための許容コストのようです。それは、レスポンダーが最初の輻輳ウィンドウを2、3、または4つのセグメントから1つのセグメントに削減しないことを意味し、syn Exchangeを完了するために非ECN対応Syn/ACKパケットを送信しません。ただし、TCPエンドノードは、接続の後でデータパケットの後続のCE適応症に正しく応答します。
Figure 4 shows an interchange with the SYN/ACK packet ECN-marked, but with the ECN mark ignored by the TCP originator.
図4は、Syn/ACKパケットECNマークとの交換を示していますが、ECNマークとTCPオリジネーターによって無視されます。
---------------------------------------------------------------
TCP Node A Router TCP Node B
(initiator) (responder)
---------- ------ ----------
ECN-setup SYN packet --->
ECN-setup SYN packet --->
<--- ECN-setup SYN/ACK, ECT <--- Sets CE on SYN/ACK <--- ECN-setup SYN/ACK, CE
<--- ecn-setup syn/ack、ect <--- syn/ackにceを設定<--- ecn-setup syn/ack、ce
Data/ACK, No ECN-Echo --->
Data/ACK --->
<--- Data (up to four packets)
---------------------------------------------------------------
Figure 4: SYN exchange with the SYN/ACK packet marked, but with the ECN mark ignored by the TCP initiator
図4：syn/ackパケットとマークされたsyn交換ですが、TCPイニシエーターによって無視されたECNマークとの交換
Thus, to be explicit, when a TCP connection includes an initiator that supports ECN but *does not* support ECN-Capability for SYN/ACK packets, in combination with a responder that *does* support ECN-Capability for SYN/ACK packets, it is possible that the ECN-Capable SYN/ACK packets will be marked rather than dropped in the network, and that the responder will not learn about the ECN mark on the SYN/ACK packet. This would not be a problem if most packets from the responder supporting ECN for SYN/ACK packets were in long-lived TCP connections, but it would be more problematic if most of the packets were from TCP connections consisting of four data packets, and the TCP responder for these connections was ready to send its data packets immediately after the SYN/ACK exchange. Of course, with *severe* congestion, the SYN/ACK packets would likely be dropped rather than ECN-marked at the congested router, preventing the TCP responder from adding to the congestion by sending its initial window of four data packets.
したがって、明示的であるために、TCP接続にECNをサポートするイニシエーターが含まれているが、Syn/ACKパケットのECNキャピールをサポートしていない場合、Syn/ACKパケットのECNキャピールをサポートする応答者と組み合わせて、ECN対応のSyn/ACKパケットは、ネットワークにドロップされるのではなくマークされ、ResponderがSyn/ACKパケットのECNマークについて学習しない可能性があります。Syn/ACKパケットのECNをサポートするレスポンダーのほとんどのパケットが長命のTCP接続にある場合、これは問題になりませんが、パケットのほとんどが4つのデータパケットから構成されるTCP接続からのものであれば、より問題があります。これらの接続のTCPレスポンダーは、Syn/ACK交換の直後にデータパケットを送信する準備ができていました。もちろん、 *重度の *混雑により、syn/ackパケットは、混雑したルーターでecnマークされているのではなく、削除される可能性が高く、TCPレスポンダーが4つのデータパケットの最初のウィンドウを送信して輻輳に追加するのを防ぎます。
It is also possible that in some older TCP implementation, the initiator would ignore arriving SYN/ACK packets that had the ECT or CE codepoint set. This would result in a delay in connection setup for that TCP connection, with the initiator re-sending the SYN packet after a retransmission timeout. We are not aware of any TCP implementations with this behavior.
一部の古いTCP実装では、イニシエーターは、ECTまたはCE CodePointセットを備えた到着Syn/ACKパケットを無視する可能性があります。これにより、そのTCP接続の接続セットアップが遅延し、再送信時のタイムアウト後にイニシエーターがSynパケットを再配置することになります。この動作を伴うTCPの実装を認識していません。
One possibility for coping with problems of backwards compatibility would be for TCP initiators to use a TCP flag that means "I understand ECN-Capable SYN/ACK packets". If this document were to standardize the use of such an "ECN-SYN" flag, then the TCP responder would only send a SYN/ACK packet as ECN-Capable if the incoming SYN packet had the "ECN-SYN" flag set. An ECN-SYN flag would prevent the backwards compatibility problems described in the paragraphs above.
後方互換性の問題に対処する可能性の1つは、TCPイニシエーターが「ECN対応SYN/ACKパケットを理解している」というTCPフラグを使用することです。このドキュメントがこのような「ECN-Syn」フラグの使用を標準化する場合、TCP Responderは、着信Synパケットに「ECN-Syn」フラグセットがある場合にのみSyn/ACKパケットをECN対応として送信します。ECN-Synフラグは、上記の段落に記載されている後方互換性の問題を防ぎます。
One drawback to the use of an ECN-SYN flag is that it would use one of the four remaining reserved bits in the TCP header for a transient backwards compatibility problem. This drawback is limited by the fact that the "ECN-SYN" flag would be defined only for use with ECN-setup SYN packets; that bit in the TCP header could be defined to have other uses for other kinds of TCP packets.
ECN-Synフラグの使用に対する欠点の1つは、TCPヘッダーに残っている4つの予約ビットのいずれかを使用して、一時的な逆方向の互換性の問題に使用することです。この欠点は、「ECN-Syn」フラグがECNセットアップSynパケットでのみ使用するためにのみ定義されるという事実によって制限されています。TCPヘッダーのそのビットは、他の種類のTCPパケットの他の用途を持つように定義できます。
Factors in deciding not to use an ECN-SYN flag include the following:
ECN-Synフラグを使用しないことを決定する要因には、以下が含まれます。
(1) The limited installed base: At the time that this document was written, the TCP implementations in Microsoft Vista and Mac OS X included ECN, but ECN was not enabled by default [SBT07]. Thus, there was not a large deployed base of ECN-Capable TCP implementations. This limits the scope of any backwards compatibility problems.
(1) 限られたインストールされたベース：このドキュメントが書かれた時点で、Microsoft VistaとMac OS XのTCP実装にはECNが含まれていましたが、ECNはデフォルトでは[SBT07]を有効にしませんでした。したがって、ECN対応TCP実装の大きな展開ベースはありませんでした。これにより、後方互換性の問題の範囲が制限されます。
(2) Limits to the scope of the problem: The backwards compatibility problem would not be serious enough to cause congestion collapse; with severe congestion, the buffer at the congested router will overflow, and the congested router will drop rather than ECN-mark arriving SYN packets. Some active queue management mechanisms might switch from packet-marking to packet-dropping in times of high congestion before buffer overflow, as recommended in Section 19.1 of RFC 3168 [RFC3168]. This helps to prevent congestion collapse problems with the use of ECN.
(2) 問題の範囲への制限：後方互換性の問題は、うっ血の崩壊を引き起こすほど深刻ではありません。深刻な鬱血により、混雑したルーターのバッファーがオーバーフローし、cn-markがsynパケットを到着するのではなく、混雑したルーターがドロップします。RFC 3168 [RFC3168]のセクション19.1で推奨されるように、バッファオーバーフローの前に高い輻輳の時点で、いくつかのアクティブキュー管理メカニズムがパケットマークからパケットドロップに切り替える可能性があります。これは、ECNの使用による輻輳の崩壊の問題を防ぐのに役立ちます。
(3) Detection of and response to backwards-compatibility problems: A TCP responder such as a web server can't differentiate between a SYN/ACK packet that is not ECN-marked in the network, and a SYN/ACK packet that is ECN-marked, but where the ECN mark is ignored by the TCP initiator. However, a TCP responder *can* detect if a SYN/ACK packet is sent as ECN-capable and not reported as ECN-marked, but data packets are dropped or marked from the initial window of data. We will call this scenario "initial-window-congestion". If a web server frequently experienced initial-window-congestion (without SYN/ACK congestion), then the web server *might* be experiencing backwards compatibility problems with ECN-Capable SYN/ACK packets, and could respond by not sending SYN/ACK packets as ECN-Capable.
(3) 後方互換性の問題の検出と応答：WebサーバーなどのTCPレスポンダーは、ネットワークでeCnマークされていないSyn/ACKパケットとECN/ACKパケットをeCN/ACKパケットを区別できません。ただし、ECNマークはTCPイニシエーターによって無視されます。ただし、TCP Responder *は、Syn/ACKパケットがECN対応として送信され、ECNマークとして報告されていないかどうかを検出できますが、データパケットはデータの初期ウィンドウから削除またはマークされています。このシナリオを「初期ウィンドウコンジョン」と呼びます。Webサーバーが頻繁に初期ウィンドウコンジェストを経験した場合（Syn/ACK混雑なし）、Webサーバー *はECN対応Syn/ACKパケットとの逆方向の互換性の問題を経験している可能性があり、Syn/ACKパケットを送信しないことで応答できます。ECN対応として。
Normative References
引用文献
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
Informative References
参考引用
[ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification, SIGCOMM 2005.
[ECN] A. Kuzmanovic、The Power of Lumplicit Musecestion Notification、Sigcomm 2005。
[ECN-SYN] ECN-SYN web page with simulation scripts, http://www.icir.org/floyd/ecn-syn.
[ECN-SYN]シミュレーションスクリプトを備えたECN-Syn Webページhttp://www.icir.org/floyd/ecn-syn。
[F07] S. Floyd, "[BEHAVE] Response of firewalls and middleboxes to TCP SYN packets that are ECN-Capable?", August 2, 2007, email to the BEHAVE mailing list, http://www1.ietf.org/ mail-archive/web/behave/current/msg02644.html.
[F07] S. Floyd、「[beve] ecn対応のTCP synパケットへのファイアウォールとミドルボックスの応答？」、2007年8月2日、beaveメーリングリスト、http：//www1.ietf.org/にメールMail-Archive/web/beave/current/msg02644.html。
[Kelson00] Dax Kelson, "8% of the Internet unreachable!", September 10, 2000, email to the Linux kernel mailing list, http://lkml.indiana.edu/hypermail/linux/kernel/ 0009.1/0329.html.
[Kelson00] Dax Kelson、「インターネットの8％の到達不能！」、2000年9月10日、Linuxカーネルメーリングリストにメール、http：//lkml.indiana.edu/hypermail/linux/kernel/ 0009.1/0329.html。
[L08] A. Landley, "Re: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-06.txt", August 24, 2008, email to the tcpm mailing list, http://www.ietf.org/ mail-archive/web/tcpm/current/msg03988.html.
[L08] A. Landley、 "Re：[TCPM] I-Dアクション：Draft-ITPM-TCPM-ECNSYN-06.TXT"、2008年8月24日、TCPMメーリングリスト、http：//www.ietf.orgにメール/mail-archive/web/tcpm/current/msg03988.html。
[MAF05] A. Medina, M. Allman, and S. Floyd, "Measuring the Evolution of Transport Protocols in the Internet", ACM CCR, April 2005.
[MAF05] A. Medina、M。Allman、およびS. Floyd、「インターネットでの輸送プロトコルの進化の測定」、ACM CCR、2005年4月。
[PI] C. Hollot, V. Misra, W. Gong, and D. Towsley, "On Designing Improved Controllers for AQM Routers Supporting TCP Flows", April 1998.
[Pi] C. Hollot、V。Misra、W。Gong、およびD. Towsley、「TCPフローをサポートするAQMルーターの改良されたコントローラーの設計」、1998年4月。
[RED] Floyd, S., and Jacobson, V., "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, V.1 N.4, August 1993.
[Red] Floyd、S。、およびJacobson、V。、「混雑回避のためのランダムな早期検出ゲートウェイ」、Networkingに関するIEEE/ACMトランザクション、v.1 N.4、1993年8月。
[REM] S. Athuraliya, V. H. Li, S. H. Low and Q. Yin, "REM: Active Queue Management", IEEE Network, May 2001.
[Rem] S. Athuraliya、V。H。Li、S。H。LowおよびQ. Yin、「Rem：Active Keue Management」、IEEE Network、2001年5月。
[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] 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。、およびL. Zhang、「インターネットでのキュー管理と混雑回避に関する推奨事項」、RFC 2309、1998年4月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。、およびW. Stevens、「TCP渋滞制御」、RFC 2581、1999年4月。
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042] Allman、M.、Balakrishnan、H。、およびS. Floyd、「限定送信を使用したTCPの損失回復の強化」、RFC 3042、2001年1月。
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
[RFC3360]フロイド、S。、「不適切なTCPリセットは有害と見なされる」、BCP 60、RFC 3360、2002年8月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390] Allman、M.、Floyd、S。、およびC. Partridge、「TCPの初期ウィンドウの増加」、RFC 3390、2002年10月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987] Eddy、W。、「TCP Syn Flooding Attacks and Common Mitigations」、RFC 4987、2007年8月。
[SCJO01] F. Smith, F. Campos, K. Jeffay, and D. Ott, "What TCP/IP Protocol Headers Can Tell us about the Web", SIGMETRICS, June 2001.
[SCJO01] F. Smith、F。Campos、K。Jeffay、およびD. Ott、「TCP/IPプロトコルヘッダーがWebについて語ることができる」、Sigmetrics、2001年6月。
[SYN-COOK] Dan J. Bernstein, SYN cookies, 1997, see also <http://cr.yp.to/syncookies.html>.
[Syn-Cook] Dan J. Bernstein、Syn Cookies、1997、<http://cr.yp.to/syncookies.html>も参照してください。
[SBT07] M. Sridharan, D. Bansal, and D. Thaler, "Implementation Report on Experiences with Various TCP RFCs", Presentation in the TSVAREA, IETF 68, March 2007. http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld6.htm.
[SBT07] M. Sridharan、D。Bansal、およびD. Thaler、「さまざまなTCP RFCSの経験に関する実装レポート」、TSVAREAでのプレゼンテーション、IETF 68、2007年3月。http：//www3.ietf.org/proceedings/07mar/Slides/tsvarea-3/sld6.htm。
[Tools] S. Floyd, Ed., and E. Kohler, Ed., "Tools for the Evaluation of Simulation and Testbed Scenarios", Work in Progress, February 2008.
[Tools] S. Floyd、ed。、およびE. Kohler、ed。、「シミュレーションとテストベッドシナリオの評価のためのツール」、2008年2月の作業。
Authors' Addresses
著者のアドレス
Aleksandar Kuzmanovic Northwestern University
Aleksandar Kuzmanovic Northwestern University
Phone: +1 (847) 467-5519
EMail: akuzma@northwestern.edu
URL: http://cs.northwestern.edu/~akuzma
Amit Mondal Northwestern University
アミットモンダルノースウェスタン大学
Phone: +1 (847) 467-6455
EMail: a-mondal@northwestern.edu
URL: http://www.cs.northwestern.edu/~akm175/
Sally Floyd ICIR (ICSI Center for Internet Research)
Sally Floyd ICIR（ICSIセンターのインターネット研究）
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
URL: http://www.icir.org/floyd/
K. K. Ramakrishnan AT&T Labs Research Rm. A161 180 Park Ave. Florham Park, NJ 07932
K. K. Ramakrishnan AT＆T Labs Research RM。A161 180 Park Ave. Florham Park、NJ 07932
Phone: +1 (973) 360-8764
EMail: kkrama@research.att.com
URL: http://www.research.att.com/info/kkrama