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
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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はなく、SYNおよびSYN / ACKパケットに、データパケットのECN対応のコードポイントを設定することを指定します。とSYNパケットに応答して送信された場合しかし、SYN / ACKパケットを有するTCP転送に高コストで得られる再送タイムアウトと、ドロップ、この文書は、SYN / ACKパケット自体のECNの使用を記載しています意欲を示すTCPヘッダに設定された2つのECNフラグは、ECNを使用します。 ECN対応として、初期のTCP SYN / ACKパケットを設定すると、まだネットワークに負荷をかけ始めていない接続のための再送タイムアウトの厳しいペナルティを回避、TCP接続に大きな利益となることができます。 TCPの応答（SYN / ACKパケットの送信者は）ECN-できないSYN / ACKパケットを再送することにより、ECN-マークSYN / ACKパケットのレポートに返信しなければなりません。再送SYN / ACKパケットが確認応答された場合、TCPの応答は、それによって、ネットワーク上の接続から後続の負荷を低減すること、2つ、3つ、または4つのセグメントからの1つのセグメントに、その最初の輻輳ウィンドウを減少させます。 TCPの応答者が指定した時間内に確認応答を受信しないSYN / ACKパケットがドロップされる代わりに場合、またはその他の理由で、TCPの応答は、（再送タイマを設定）ドロップ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の採用により、性能をさらに向上させることができます。ルータは、バッファオーバーフローの前に輻輳を検出した場合、ルータはパケットをドロップするか、輻輳経験（CE）を設定することにより、いずれかのIPヘッダ内の明示的輻輳通知（ECN）フィールド[RFC3168]にコードポイントを輻輳表示を提供することができます。 IETFは、輻輳を示すためにルータのIPヘッダに輻輳経験（CE）コードポイントの使用を標準化しました。増分展開と後方互換性のために、ECN [RFC3168]にRFCは、ルータが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コネクションの輻輳ウィンドウが小さいかもしれません。現在のウィンドウが一つだけのパケットが含まれており、そのパケットは廃棄された場合、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.
長いフローがECNを用いて実質的に改善されたスループットが表示されないかもしれないが2）、それらは低損失を経験し得ます。これは、再送信の回避のため、latency-と損失と小文字が区別されます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
RFC 3168 [RFC3168]はTCPデータパケットではなく、TCP SYNおよびSYN / ACKパケットにECN-可能なコードポイントを設定することを指定します。 RFC 3168 [RFC3168]はTCPヘッダ内のフラグを使用して、TCP SYNおよびSYN-ACK交換に2つのTCPエンドポイントとの間のECNの使用のネゴシエーションを指定します。保守的な、RFC 3168 [RFC3168]という側に誤ると、最初のSYN / ACKのためのECNの使用を指定していません
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.
パケット自体。しかし、結果として得られる再送タイムアウトで、SYN / ACKパケットはドロップさを有するのTCP転送に高いコストのため、この文書では、SYN / ACKパケット自体のECNの使用を指定します。これは、まだネットワークに負荷を置く開始していない接続のための再送タイムアウトの厳しいペナルティを回避、TCP接続に大きな利益となることができます。 SYN / ACKパケットの送信者は、非ECN対応を送信することにより、ECN-マークSYN / ACKパケット（IPヘッダのECNフィールドに設定CEコードポイントとSYN / ACKパケット）の報告に応答しなければなりませんSYN / ACKパケットを、ネットワーク上のその接続から後続の負荷を低減すること、一つのセグメントに2つ、3つ、または4つのセグメントから初期輻輳ウィンドウを減少させることによって。
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]に変更を指定します。第4節では、問題のいくつかについて説明し、第5節は、関連する作業について説明しながら、第3節では、変更の仕様が含まれています。第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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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-できるTransportコードポイントの一つ。
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.
入出力ECE：ECN-エコーフラグ。
ECN-setup packets:
ECN-セットアップパケット：
o ECN-setup SYN packet: a SYN packet with the ECE and CWR flags;
O ECN-セットアップSYNパケット：ECEとCWRフラグとSYNパケット。
o ECN-setup SYN-ACK packet: a SYN-ACK packet with ECE but not CWR.
O ECN-セットアップSYN-ACKパケット：ECEではなく、CWRと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.
このセクションでは、TCP SYN / ACKパケットがECN対応できるようにRFC 3168 [RFC3168]に変更を指定します。
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ノードは、SYN / ACKパケットがECN対応であるルータに指示、応答ECN-セットアップSYN / ACKパケットにECTを設定することにより、初期ECN-セットアップSYNパケットに応答することができるように指定します。これは、経路に沿った輻輳ルータが輻輳の指標としてパケットを落とすのではなく、パケットをマークすることを可能にします。
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パケットを送信すると仮定する。 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パケットがネットワーク内でドロップされた場合、応答者（ノードB）は、[RFC2988]を期限切れにする再送タイマを3秒間待つことによって応答します。 ECTコードポイントとSYN / ACKパケットが破棄された場合、レスポンダはECN対応のコードポイントなしで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.
我々は、SYN-Cookieが図1の交換に応答（ノードB）によって使用された場合、応答者が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-可能として送信SYN / ACKパケットとの交流を示し、ECN-マークの代わりに、輻輳ルータでドロップ。この文書では、[ECN +]でECN +の元の提案と異なるECN + / TryOnce、指定します。 TCPの応答者がSYN / ACKは、ECN-マークされたことが通知された場合ECN + / TryOnceで、TCPの応答者は、直ちに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
ACK, ECN-Echo --->
ACK, ECN-Echo --->
Window reduced to one segment.
<--- ECN-setup SYN/ACK, not 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
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）は、CEコードポイントのセットと、輻輳ルータがECN-マークされたSYN / ACKパケットを受信した場合、イニシエータは、再送タイマーを再開する。イニシエータは、応答ACKパケットのTCPヘッダ内のECN-エコーフラグを設定することにより、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-送信済み」から進みません。
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).
応答（ノードB）は、SYN / ACKパケット内の輻輳経験指標を報告ECN-ECHOパケットを受信すると、レスポンダは、一つのセグメントに最初の輻輳ウィンドウを設定し、代わりに二つのセグメントの[RFC2581]によって許容されるよう、または3 [RFC3390]で許可されて4つのセグメント。図2に示すように、応答（ノードB）は、そのSYN / ACKパケットに対して指示を経験輻輳を知らせるECN-ECHOパケットを受信した場合、応答者は、さらに、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のセクション3.4 [RFC793]）。
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.
私たちは、この文書のメカニズムは、「送信TCPは輻輳ウィンドウが1のときECN-エコーパケットを受信する再送タイマを再起動しなければならない」ことを指定するRFC 3168 [RFC3168]、異なることに注意してください。 RFC 3168 [RFC3168]はSYN / ACKパケットがECN-可能にすることはできません。 RFC 3168 [RFC3168]はECN-ECHOパケットに応答して、TCPレスポンダはまた、ECN-エコーフラグにそのの受信との反応を確認するために、送信される次のデータパケットのTCPヘッダにCWRフラグを設定することを指定します。対照的に、ECN対応SYN / ACKパケットの受信を確認ECN-ECHOパケットに応答して、TCPレスポンダはCWRフラグを設定し、単にECN-できないSYN / ACKパケットを送信しません。非ECN対応SYN / ACKパケットを受信すると、TCP開始剤は、パケットを返信に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
ACK, ECN-Echo --->
ACK, ECN-Echo --->
Window reduced to one segment.
<--- 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 / ACKパケットでSYN交換 - 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は、第1のSYN / ACKパケットがECN-マークされ、第二のSYN / ACKパケットがネットワーク内でドロップされた交換を示しています。図2のように、TCPの応答は、第二の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.
このドキュメントの仕様の根拠は以下の通りです。ノードBは、ECN-エコーは、TCPヘッダにビットセットを持つTCP SYNパケットを受信すると、これは、ノードAは、ECN-可能であることを示しています。ノードBはまた、ECN-可能である場合、すぐに応答するTCP SYN / ACKパケットにIPヘッダ内のECN-可能なコードポイントのいずれかを設定するための障害物が存在しません。
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対応のコードポイントが開始TCP SYNパケットのIPヘッダに設定してはいけない理由はいくつかあります。 TCP SYNパケットが送信されると、まず、他のTCPエンドポイント（図2のノードB）は、ECN-可能であること、またはECNのCEコードポイントをすることにより設定された場合、理解し反応することができるであろうという保証はありません混雑ルータ。
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）パケットのための小さなドロップ率を持つルータのバッファ・アーキテクチャの数があります。例えば、各パケットに関係なくパケットサイズのバッファに単一のスロットをとるパケット単位でドロップテールキューのために、小規模および大規模のパケットがドロップされることが等しく可能性があります。しかし、バイト単位のドロップテールキューのために、小さなパケットは大規模なものよりも低下しにくくなります。バイトモードでREDため、落下またはマークされるのパケットのチャンスは、バイト単位のパケットサイズに比例している間、同様に、パケットモードでのランダム早期検出（RED）のために、小規模および大規模のパケットは、廃棄されるか、またはマークされることに等しく可能性があります。
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.
ドロップまたはマークされるのパケットのチャンスは、バイト単位のパケットサイズに比例して、バイトモードでのAQM機構と混雑ルータの場合は、TCP SYN / ACKパケットのドロップまたはマーキング率は一般的に低くあるべきです。この場合には、SYN / ACKのパケットがECN可能な製造の利点は、同様に、中程度であるべきです。しかし、パケット単位またはパケットモードでのAQM機構を備えた、と小さなパケットのための無プライオリティキューイングとドロップテールキューで混雑ルータのため、小規模および大規模なパケットがドロップまたはマークされるのと同じ確率を持つ必要があります。このような場合には、大きな利点であるべきであるSYN / ACKパケットがECN-可能となります。
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を参照）、パケットサイズの関数としてのルータでドロップまたはマーク行動の面で現実世界での行動の広い範囲があると信じています。当社は、上記のこれらの選択肢の全てが（REDキュー管理のためのデフォルトはバイトモードにパケットモードから変更されていながら、ドロップテールキューが、パケット単位で、デフォルトである）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:
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のソースTCPは、パケットのドロップやECN指示のいずれかを含むデータの任意のウィンドウのために輻輳ウィンドウを半分にすることが要求されます。
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は、TCPの輻輳ウィンドウは、単一のパケットで構成され、そのパケットがネットワークにECN-マークされている場合、そのデータの送信者は、ラウンドごとに1つのパケットを下回る送信レートを下げる必要があることを指定します-trip時間によっては、他のパケットを送信する前に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.
保守的な側では、1はSYN / ACKパケットのための1つのパケットの効果的な輻輳ウィンドウを仮定でき、1つのパケットごとに2往復時間を送信する速度を下げることにより、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つのパケットのその許容デフォルト値、一つのパケットに初期の輻輳ウィンドウを設定レスポンダの応答を可能にします。応答者は非ECN対応のSYN / ACKパケットを送信し、そのSYN / ACKパケットの後のラウンドトリップ時間ごとにデータパケットの慎重な送信レートとの進行が認められています。この文書では、このアプローチが輻輳崩壊のか、トラフィックを競合の飢餓の無い危険で、ユーザーに有用であることを主張しています。これは、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 +および+ / TryOnceこの文書で指定された機構のECNとの間の性能の差が依然として存在することに注意してください。それは、他の端から非ECN-マークSYN / ACKパケットを受信したまでは特に、ECN + / TryOnceで、TCPの発信元は、データパケットを送信しません。
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 +]で提案されました。紙がランダム早期検出（RED）[RED]、ランダム指数がマーキング（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-機能の追加は、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パケットの割合が非常に高くなることができます。具体的には、ウェブ・トラフィックによって支配リンク上の測定値は、パケットの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?
SYN / ACKパケットがECNに対応していないとき（1）どのような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パケットのうち、どのような割合ECN-マークの代わりに、SYN / ACKパケットが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.
いくつかのアクティブキュー管理機構の場合、ECN対応のパケットは、これは、つまり、バッファがまだ満杯でない任意の時間に可能な任意の時間を落としたのではなく、マークされています。パケットドロップ/マーク率が所定の閾値を超えた場合に、このような[赤]に推奨されているようにRED機構しかし他のAQM機構については、パケットがドロップされたというよりもマークされている、例えば、10％、パケットがECN-可能であっても。輻輳が高いドロップ/マーク率を引き起こすのに十分に深刻である、そのようなAQM機構を備えたルータについては、いくつかのSYN / ACKパケットがドロップされた代わりに、彼らはECN-可能であったか否かがマークされるでしょう。
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個のセグメントのその可能なデフォルト値を、一つのセグメントに最初の輻輳ウィンドウを設定することにより、ECN-マークされたSYN / ACKパケットのレポートに応答することを指定し、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パケットに他の二つの可能な応答を検討しました。 ECN +、[ECN +]からの元の提案では、エンド・ノードは、1つのセグメントに最初の輻輳ウィンドウを設定し、それを送信するために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を超えるには、パケットのドロップ率を倍増させることができます％。詳細は、以下の付録Aの表1および表3に示されています。 ECN + / TryOnceは高い混雑のシナリオでのパケットドロップ率を増加させません。したがって、ECN + / TryOnceが+ ECNまたはECNに優れている+ /両方の非常に高い混雑のシナリオでのパケットドロップ率を増加させる、待ち。同時に、ECN + / TryOnceはECN +またはECN + /待機（表2及び付録Aの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.
注意：私たちは、ECN +の臨時の混雑関連の問題を発見し、ECNの+ /文書はほとんど標準化プロセスを完了した後、NS-2シミュレータの更新バージョンでシミュレーションを再実行するときに待ちます。
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-能力の測定研究の一つの目標は、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コードポイントを運ぶ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にさかのぼる、ECN-能力[Kelson00] [RFC3360]を交渉するためにTCPヘッダ内のフラグを使用して、TCP SYNパケットに応答して、TCP接続をリセットルータ又は中間装置の小さいが減少数です[ MAF05]。デーブターラーは、ECNを使用してTCP接続によって発生した二つの新しい問題の2007年3月IETFで報告しました。 【SBT07] ECN可能な接続が確立されていることを示し、（1）TCPデータパケットがコードポイントECTとIPヘッダ内のECNフィールドで到着したときに二つの問題の懸念ルータクラッシュの最初（0）またはECT 。
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パケットをドロップするという証拠はないが、そのような挙動は排除できません。 ECTとSYN / ACKパケットならば、第3節で指定されている（、したがって（[MAF05]の図1を参照。）、既知または未知のIPオプションが含まれているTCP SYNパケットをドロップするルータやミドルボックスの数があるようですまたはCEコードポイントがドロップされた、TCPノードは、ECN対応のコードポイントなしでSYN / ACKパケットを再送する必要があります。SYN / ACKがでECN対応やCEコードポイントに到着した任意のルータやミドルボックスクラッシュという証拠もありません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コードポイントを運ぶTCP SYN / ACKパケットがECN-マークの代わりのECN対応ルータでドロップされる可能性があるため、懸念は、これは混雑を呼び出すか、非常に混雑シナリオでのパフォーマンスを悪化させることができますどちらかかどうかです。しかし、SYN / ACKパケットがECN-マークされていたことを知った後、レスポンダはECN対応可能ではありませんSYN / ACKパケットを送信します。このSYN / ACKパケットがドロップされた場合、応答は、次に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 + / TryOnceと大きく異なるものではなく、短いフローや渋滞の高レベルによって支配ミックスという。示ししかし、私たちのシミュレーションでは、我々はECN +またはECNは、+ / ECNやECN + / TryOnce（以下、付録Aで表1、表3）よりも大幅に高いパケット廃棄率で結果を待って1つのシナリオを持っています。
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.
この文書では、TCPノードはECN-できるものとしてSYN / ACKパケットを送信できるようにするためにRFC 3168 [RFC3168]に変更を指定します。 SYN / ACKパケットが結果として再送タイムアウトを回避することにより、混雑ルータによってドロップされたときにECN対応のSYN / ACKパケットを作ることはTCP転送に高いコストを避けることができます。これは、短い接続のスループットを向上させることができます。この文書では、SYN / ACKパケットの送信元が2つ、3つ、または4つのセグメントからの1つのセグメントに、その最初の輻輳ウィンドウを減少させることによって、ECNマークに応答SYN / ACKパケットのECN-能力を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.
私たちは、この文書の以前の草案に関するフィードバックのためのアニルAgarwalさん、マーク・オールマン、レミデニス・Courmont、ウェスリーエディ、ラースEggertの、アルフレッドHoenes、Janardhanアイアンガー、およびパシSarolahtiに感謝します。我々は、Linuxの開発ツリー用のECN + / TryOnceのためのパッチを貢献するためにアダム・ラングレー[L08]を感謝します。
Appendix A. Report on Simulations
シミュレーション上の付録A.報告
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キロバイトの平均ファイルサイズを使用します。他のシミュレーションは5バイト、7バイト、14バイト、および17キロバイトの平均ファイルサイズを使用して実行されました。各グラフのタイトルは、トラフィックジェネレータから目標と平均負荷を与えます。シミュレーションは、ファイルサイズのヘビーテイル分布を使用し、そして（ウォームアップ時間の10秒を含む）のみ85秒間実行されるため、実際の負荷は、多くの場合、目標負荷よりもはるかに小さいです。混雑したリンクは100 Mbpsです。 REDは穏やかモードで実行され、バッファがいっぱいになっている（とルータは選択の余地を持っていない）場合は到着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ノードは、（一つのセグメントの最初の輻輳ウィンドウを用いて）すぐにデータパケットを送信します。 ECN + /待ちで、TCPノードは、データパケットを送信する前に、往復時間を待ちます。応答者は、既にSYN / ACKパケットの確認応答が受信された往復時間の一回の測定を持っています。 ECN + / TryOnce、TCPの応答の返信がECN対応可能ではありませんSYN / 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.
シミュレーションスクリプトは、TCP接続のための応答時間の分布を示すグラフとともに、[ECN-SYN]で入手可能です。
A.1. Simulations with RED in Packet Mode
A.1。パケットモードではREDとシミュレーション
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.
パケットモードでパケット内のキューとREDとシミュレーションは、ECN +は、中程度または高輻輳時に有用であることを示しています。しかし、ECN、ECN +及びECN + / 25％以上のパケットロス率125％の目標負荷とシミュレーション、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は、パケット内のキューと、パケットモードにおけるREDとシミュレーションのための輻輳レベルを示します。最悪のシナリオを検討するために、これらのシミュレーションは、3キロバイトの平均流の大きさで、非現実的な小さなフローサイズ分布を有するトラフィックミックスを使用しています。特定のトラフィック負荷を示す各テーブルには、4つの行は、パケットの数がドロップECNは、マーキングされたパケットの数を示し、集約パケットドロップ率、および総スループット。 4つの列は、標準ECN、ECN +、ECN + /待ち、およびECN + / TryOnceとシミュレーションを示しています。
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.
これらのシミュレーションは、ドロップパケットの代わりに、キューがいっぱいになっていないことの任意の時間をマークするためにREDセットで実行しました。これは、ECN +およびその変種のための最悪のシナリオです。平均キューサイズが設定されたしきい値を超えたNS-2シミュレータ、中REDのデフォルトの実装では、ルータはすべての到着パケットを廃棄します。この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 + / TryOnce：集約パケットドロップ率が一般的に高い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バイトの平均流量サイズのシミュレーション、パケットモードで100Mbpsのリンク、RED、パケット内のキュー
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バイトの平均流量サイズのシミュレーションのため、100Mbpsのリンク、REDパケット・モードでは、パケット内のキュー（グラフはHTTP」から入手可能である：// WWW .icir.org /フロイド/ 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バイトの平均流量サイズのシミュレーション、パケットモードで10Mbpsのリンク、RED、パケット内のキュー
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バイトの平均流量サイズのシミュレーションのために、10 Mbpsリンク、REDパケット・モードでは、パケット内のキュー（グラフはHTTP」から入手可能である：// WWW .icir.org /フロイド/ ECN-SYN / "）
A.2. Simulations with RED in Byte Mode
A.2。バイトモードでREDとシミュレーション
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以下の表は、バイトモードとバイト単位のキューにREDとシミュレーションを示しています。 ECN +、ECN + /待ち、またはECN + / TryOnceを使用した集計の混雑の有意な増加はありません。
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
しかし、パケットモードでREDとシミュレーションとは異なり、バイトモードではREDとシミュレーションは、ECN +または持つパケットマーキング率という点で、ECN +またはECNの使用+ /待ってから少しの利益を示します
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.
ECN + /待ちは標準ECNのパケットマーキング率よりもはるかに違いはありません。シナリオでは、いずれかのECN +のために多くの必要があるということです、これらのシナリオでECN +の使用からの欠点がありませんが、ではない - これはREDとバイトモードでは、SYN / ACKパケットのような小さなパケットはめったに落とさないか、マークされているためであります小さなパケットは廃棄またはマークされにくい場所にあります。
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バイトの平均流量サイズのシミュレーション、バイトモードで100Mbpsのリンク、RED、バイト単位でキュー
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バイトの平均流量サイズのシミュレーション、バイトモードで10Mbpsのリンク、RED、バイト単位でキュー
Appendix B. Issues of Incremental Deployment
インクリメンタル展開の付録B.問題
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.
ECN-できるようにSYN / ACKパケットを送信するTCPノードBために、ノードBはノードAからECN-セットアップSYNパケットを受信している必要がありますしかし、ノードAがECNをサポートすることが可能であるが、いずれかのCEコードポイントを無視受信されたSYN / ACKパケットに対して、またはECTまたはCEコードポイントが設定されたSYN / ACKパケットを無視します。 TCPイニシエータは、受信したSYN / ACKパケットのCEコードポイントを無視した場合、これは、TCPの応答者がこの輻輳指示に応答しないであろうことを意味します。しかし、これは、TCPのSYN / ACKパケットのECN-能力の増分展開に支払うために許容できるコスト私たちには思えます。それは必要があり、SYN交換を完了するために、非ECN対応SYN / ACKパケットを送信しないようにレスポンダが、一つのセグメントまで2つ、3つ、または4つのセグメントから初期の輻輳ウィンドウを減少させないであろうことを意味します。しかし、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-マークとの交換を示しているが、TCP発信元によって無視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
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
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パケットがマークではなく、ネットワークに滴下し、応答者がSYN / ACKパケットのECNマークについて学ぶないことにされる可能性があります。 SYN / ACKパケットのECNをサポートし、レスポンダからほとんどのパケットは長命TCPコネクションにあった場合、これは問題ではないだろうが、パケットの大部分は4個のデータパケットからなるTCPコネクションからのものであった場合には、より問題となる、とこれらの接続のためのTCPの応答者は、SYN / ACK交換した直後にそのデータパケットを送信する準備ができていました。もちろん、*ひどい*混雑で、SYN / ACKパケットは、おそらく4つのデータパケットのその初期ウィンドウを送信することにより、渋滞に追加することからTCPレスポンダを防止し、混雑ルータでECN-マークではなく廃棄されます。
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コードポイントセットを持っていた到着SYN / ACKパケットを無視するということも可能です。これは、再送信する再送タイムアウト後にSYNパケットを開始剤と、そのTCP接続のための接続設定の遅れにつながります。私たちは、この動作を持つ任意の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.
TCP開始剤は「私はECN対応のSYN / ACKパケットを理解する」を意味TCPフラグを使用するための後方互換性の問題に対処するための一つの可能性は次のようになります。この文書は、このような「ECN-SYN」フラグの使用を標準化した場合の着信SYNパケットは、「ECN-SYN」フラグがセットされていた場合、TCPの応答はECN対応としてSYN / ACKパケットを送信します。 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つの予約ビットのうちの1つを使用することです。この欠点は、「ECN-SYN」フラグが唯一のECN-setup 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）限らインストールベース：この文書が書かれた時点で、マイクロソフト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）問題の範囲に制限します：後方互換性の問題は、輻輳崩壊を引き起こすほど深刻ではないでしょう。ひどい渋滞で、混雑ルータのバッファがオーバーフローし、混雑ルータがECN-マーク到着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であるSYN / ACKパケットを区別することができません-markedが、ECNマークは、TCPイニシエータによって無視されています。 SYN / ACKパケットがECN対応として送信され、ECN-マークが、データパケットは、データの初期の窓から落とさまたはマークされていると報告されていない場合は、TCPの応答*は検出することができます。私たちは、「初期画面-混雑」このシナリオを呼び出します。 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]ポステル、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティング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.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
Informative References
参考文献
[ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification, SIGCOMM 2005.
[ECN +] A. Kuzmanovic、明示的輻輳通知のパワー、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.フロイド、 "[BEHAVE] ECN-可能なTCP SYNパケットをファイアウォールやミドルボックスの応答？"、2007年8月2日、BEHAVEメーリングリストへの電子メール、http://www1.ietf.org/メールアーカイブ/ウェブ/振る舞う/現在/ 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]ダックス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、 "再：[tcpm] IDアクション：ドラフト-IETF-tcpm-ecnsyn-06.txt"、2008年8月24日、tcpmメーリングリストへの電子メール、http://www.ietf.org /メールアーカイブ/ウェブ/ tcpm /現在/ 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.メディナ、M.オールマン、及びS.フロイド、「インターネットにおけるトランスポートプロトコルの進化の測定」、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.
、1998年4月 "TCPフローをサポートするAQMルータのための改善されたコントローラの設計について" [PI] C. Hollot、V.ミスラ、W.ゴングとD. Towsley、。
[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]フロイド、S.、およびヤコブソン、V.、 "輻輳回避のためのランダム早期検出・ゲートウェイ"、ネットワーキング、V.1 N.4、1993年8月にIEEE / ACM取引。
[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.リー、S. H.ローとQ.殷、 "REM：アクティブキュー管理"、IEEEネットワーク、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]ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、G.、ヤマウズラ、 C.、ピーターソン、L.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.、およびL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、RFC 2309、1998年4月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "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]オールマン、M.、バラクリシュナン、H.、およびS.フロイド、 "株式会社トランスミットを使用した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]オールマン、M.、フロイド、S.、およびC.ヤマウズラ、 "増加するTCPの初期ウィンドウ"、RFC 3390、2002年10月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987]エディ、W.、 "TCPのSYNフラッド攻撃と共通の軽減策"、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・スミス、F.カンポス、K. Jeffay、およびD.オットは、SIGMETRICS、2001年6月、 "どのようなTCP / IPプロトコルのヘッダは、Webを教えてくださいことができます"。
[SYN-COOK] Dan J. Bernstein, SYN cookies, 1997, see also <http://cr.yp.to/syncookies.html>.
[SYN-COOK]ダンJ.バーンスタイン、SYNクッキー、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.ターラー、 "様々なTCPのRFCとの経験上の実施報告"、TSVAREAでプレゼンテーション、IETF 68、2007年3月http://www3.ietf.org/proceedings/ 07mar /スライド/ 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.
[ツール] S.フロイド、エド。、およびE.コーラー、エド。、「シミュレーションとテストベッドシナリオの評価のためのツール」、進歩、2008年2月に作業。
Authors' Addresses
著者のアドレス
Aleksandar Kuzmanovic Northwestern University
アレクKuzmanovicノースウェスタン大学
Phone: +1 (847) 467-5519 EMail: akuzma@northwestern.edu URL: http://cs.northwestern.edu/~akuzma
電話：+1（847）467-5519 Eメール：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/
電話：+1（847）467-6455 Eメール：a-mondal@northwestern.edu URL：http://www.cs.northwestern.edu/~akm175/
Sally Floyd ICIR (ICSI Center for Internet Research)
サリーフロイドICIR（インターネットリサーチのためのICSIセンター）
Phone: +1 (510) 666-2989 EMail: floyd@icir.org URL: http://www.icir.org/floyd/
電話：+1（510）666-2989 Eメール：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.ラマクリシュナンAT＆T Labsの研究Rmを。 A161 180パークアベニュー。フローラムパーク、NJ 07932
Phone: +1 (973) 360-8764 EMail: kkrama@research.att.com URL: http://www.research.att.com/info/kkrama
電話：+1（973）360-8764 Eメール：kkrama@research.att.com URL：http://www.research.att.com/info/kkrama