Network Working Group H. Balakrishnan
Request for Comments: 3449 MIT LCS
BCP: 69 V. N. Padmanabhan
Category: Best Current Practice Microsoft Research
G. Fairhurst
M. Sooriyabandara
University of Aberdeen, U.K.
December 2002
TCP Performance Implications
of Network Path Asymmetry
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender.
この文書では、不斉効果により発生するTCPのパフォーマンスの問題について説明します。これらの問題は別の根本的な理由のために、帯域幅非対称ネットワークとパケット無線サブネットワークを含むいくつかのアクセスネットワーク、中に発生します。しかし、TCPのパフォーマンス上の最終結果はどちらの場合も同じです：パフォーマンスは、多くの場合、受信側から送信側へのACKフィードバックであるため不完全と変動の大幅低下します。
The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link-layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self-clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic. Each technique is described, together with known issues, and recommendations for use. A summary of the recommendations is provided at the end of the document.
文書は、どちらかの提案や文学に評価、あるいは現在のネットワークで展開されてきたこれらの効果にいくつかの緩和策について詳しく説明しています。典型的には、ヘッダ圧縮を使用するか、減少させる、ACKを運ぶ上流のボトルネックリンクのために使用されるチャネルを管理するために、（I）技術：これらのソリューションは、以下からなる、ローカルリンク層技術、サブネットワーク、およびエンドツーエンドのメカニズムの組み合わせを使用しますTCP ACKの頻度は、（ii）の技術は、TCP送信者の確認応答トリガ自己クロッキング両者の存在下での性能を改善するために、逆方向のデータとACKパケットをスケジュールする（iii）の技術を維持するために、この減少ACK周波数を処理します-wayトラフィック。それぞれの技術が使用するために、既知の問題、および推奨事項とともに、記載されています。勧告の概要は、ドキュメントの端部に設けられています。
Table of Contents
目次
1. Conventions used in this Document ...............................3
2. Motivation ....................................................4
2.1 Asymmetry due to Differences in Transmit
and Receive Capacity .........................................4
2.2 Asymmetry due to Shared Media in the Reverse Direction .......5
2.3 The General Problem ..........................................5
3. How does Asymmetry Degrade TCP Performance? .....................5
3.1 Asymmetric Capacity ..........................................5
3.2 MAC Protocol Interactions ....................................7
3.3 Bidirectional Traffic ........................................8
3.4 Loss in Asymmetric Network Paths ............................10
4. Improving TCP Performance using Host Mitigations ...............10
4.1 Modified Delayed ACKs .......................................11
4.2 Use of Large MSS ............................................12
4.3 ACK Congestion Control ......................................13
4.4 Window Prediction Mechanism .................................14
4.5 Acknowledgement based on Cwnd Estimation. ...................14
4.6 TCP Sender Pacing ...........................................14
4.7 TCP Byte Counting ...........................................15
4.8 Backpressure ................................................16
5. Improving TCP performance using Transparent Modifications ......17
5.1 TYPE 0: Header Compression ..................................18
5.1.1 TCP Header Compression ..................................18
5.1.2 Alternate Robust Header Compression Algorithms ..........19
5.2 TYPE 1: Reverse Link Bandwidth Management ...................19
5.2.1 ACK Filtering ...........................................20
5.2.2 ACK Decimation ..........................................21
5.3 TYPE 2: Handling Infrequent ACKs ............................22
5.3.1 ACK Reconstruction ......................................23
5.3.2 ACK Compaction and Companding ...........................25
5.3.3 Mitigating TCP packet bursts generated by
Infrequent ACKs .........................................26
5.4 TYPE 3: Upstream Link Scheduling ............................27
5.4.1 Per-Flow queuing at the Upstream Bottleneck Link ........27
5.4.2 ACKs-first Scheduling ...................................28
6. Security Considerations ........................................29
7. Summary ........................................................30
8. Acknowledgments ................................................32
9. References .....................................................32
10. IANA Considerations ...........................................37
Appendix: Examples of Subnetworks Exhibiting Network Path
Asymmetry ...............................................38
Authors' Addresses ................................................40
Full Copyright Statement ..........................................41
FORWARD DIRECTION: The dominant direction of data transfer over an asymmetric network path. It corresponds to the direction with better characteristics in terms of capacity, latency, error rate, etc. Data transfer in the forward direction is called "forward transfer". Packets travelling in the forward direction follow the forward path through the IP network.
順方向：非対称のネットワーク経路上のデータ転送の支配的な方向。これは順方向のデータ転送が「フォワード転送」と呼ばれている等容量、レイテンシ、エラーレートの点で良好な特性を有する方向に相当します。順方向に移動するパケットは、IPネットワークを介してフォワードパスをたどります。
REVERSE DIRECTION: The direction in which acknowledgments of a forward TCP transfer flow. Data transfer could also happen in this direction (and is termed "reverse transfer"), but it is typically less voluminous than that in the forward direction. The reverse direction typically exhibits worse characteristics than the forward direction. Packets travelling in the reverse direction follow the reverse path through the IP network.
逆方向：前方TCP転送フローの謝辞れる方向。データ転送はまた、この方向に起こる可能性があり（および「逆転送」と呼ばれる）が、それは一般的に順方向のそれよりも少ない膨大です。逆方向は、典型的には、順方向より悪い特性を示します。逆方向に移動するパケットは、IPネットワークを介して逆の経路をたどります。
UPSTREAM LINK: The specific bottleneck link that normally has much less capability than the corresponding downstream link. Congestion is not confined to this link alone, and may also occur at any point along the forward and reverse directions (e.g., due to sharing with other traffic flows).
アップストリームリンク：通常、対応する下りリンクよりはるかに少ない能力を持っている特定のボトルネックリンク。輻輳が単独でこのリンクに限定されず、また前方に沿って任意の点で発生し、方向を逆にしてもよい（これは他のトラフィックと共有し、例えばフロー）。
DOWNSTREAM LINK: A link on the forward path, corresponding to the upstream link.
ダウンストリームLINK：フォワードパス上のリンク、上流のリンクに対応します。
ACK: A cumulative TCP acknowledgment [RFC791]. In this document, this term refers to a TCP segment that carries a cumulative acknowledgement (ACK), but no data.
ACK：累積TCP受信確認[RFC791]。この文書では、この用語は、累積確認応答（ACK）が、データなしを運ぶTCPセグメントを指します。
DELAYED ACK FACTOR, d: The number of TCP data segments acknowledged by a TCP ACK. The minimum value of d is 1, since at most one ACK should be sent for each data packet [RFC1122, RFC2581].
遅延ACK FACTOR、D：TCP ACKによって認めTCPデータセグメントの数。最大1つのACKは、各データパケット[RFC1122、RFC2581]のために送信されなければならないので、Dの最小値は、1です。
STRETCH ACK: Stretch ACKs are acknowledgements that cover more than 2 segments of previously unacknowledged data (d>2) [RFC2581]. Stretch ACKs can occur by design (although this is not standard), due to implementation bugs [All97b, RFC2525], or due to ACK loss [RFC2760].
ストレッチACK：ストレッチACKは以前に未確認データ（D> 2）[RFC2581]の2つの以上のセグメントをカバー確認応答です。 （これは標準ではないが）ストレッチACKは起因し、又は起因ACK損失[RFC2760]に実装バグ[All97b、RFC2525]に、設計によって起こり得ます。
NORMALIZED BANDWIDTH RATIO, k: The ratio of the raw bandwidth (capacity) of the forward direction to the return direction, divided by the ratio of the packet sizes used in the two directions [LMS97].
NORMALIZED帯域比、K：両方向[LMS97]で使用されるパケットサイズの比で割った戻り方向に順方向の生の帯域幅（容量）の比率。
SOFTSTATE: Per-flow state established in a network device that is used by the protocol [Cla88]. The state expires after a period of time (i.e., is not required to be explicitly deleted when a session expires), and is continuously refreshed while a flow continues (i.e., lost state may be reconstructed without needing to exchange additional control messages).
たsoftstate：プロトコル[Cla88]によって使用されるネットワーク機器で確立ごとのフロー状態。状態が一定期間後に満了する（即ち、セッションの有効期限が切れたときに明示的に削除する必要はない）、フローを継続しながら連続的に（追加の制御メッセージを交換することなく、すなわち、失われた状態を再構成することができる）リフレッシュされます。
Asymmetric characteristics are exhibited by several network technologies, including cable data networks, (e.g., DOCSIS cable TV networks [DS00, DS01]), direct broadcast satellite (e.g., an IP service using Digital Video Broadcast, DVB, [EN97] with an interactive return channel), Very Small Aperture satellite Terminals (VSAT), Asymmetric Digital Subscriber Line (ADSL) [ITU02, ANS01], and several packet radio networks. These networks are increasingly being deployed as high-speed Internet access networks, and it is therefore highly desirable to achieve good TCP performance. However, the asymmetry of the network paths often makes this challenging. Examples of some networks that exhibit asymmetry are provided in the Appendix.
非対称特性は、インタラクティブで放送衛星（例えば、デジタルビデオ放送、DVBを使用してIPサービス、[EN97]、ケーブル・データ・ネットワークを含むいくつかのネットワーク技術、（例えば、DOCSISケーブルTVネットワーク[DS00、DS01]）で展示されていますリターンチャンネル）、微小開口衛星端末（VSAT）、非対称デジタル加入者線（ADSL）[ITU02、ANS01]、およびいくつかのパケット無線ネットワーク。これらのネットワークはますます高速インターネットアクセス網として展開されている、そして良いTCPの性能を達成することが非常に望ましいです。しかし、ネットワークパスの非対称性は、多くの場合、この挑戦になります。非対称性を示すいくつかのネットワークの例は、付録で提供されています。
Asymmetry may manifest itself as a difference in transmit and receive capacity, an imbalance in the packet loss rate, or differences between the transmit and receive paths [RFC3077]. For example, when capacity is asymmetric, such that there is reduced capacity on reverse path used by TCP ACKs, slow or infrequent ACK feedback degrades TCP performance in the forward direction. Similarly, asymmetry in the underlying Medium Access Control (MAC) and Physical (PHY) protocols could make it expensive to transmit TCP ACKs (disproportionately to their size), even when capacity is symmetric.
非対称は、送信の差として現れると容量を受信、パケットロス率の不均衡、又は送信の間の差とパス[RFC3077]を受信してもよいです。容量が非対称である場合、例えば、TCPのACKによって使用される逆経路上の低減容量が存在するように、低速または低頻度ACKフィードバックは順方向にTCPの性能を低下させます。同様に、基礎となる媒体アクセス制御（MAC）および物理（PHY）プロトコルの非対称性は、容量が対称である場合でも、それは高価（不相応そのサイズに）TCP ACKを送信するために作ることができます。
Network paths may be asymmetric because the upstream and downstream links operate at different rates and/or are implemented using different technologies.
上流及び下流のリンクが異なる速度で動作し、および/または異なる技術を使用して実装されているので、ネットワークパスは、非対称であってもよいです。
The asymmetry in capacity may be substantially increased when best effort IP flows carrying TCP ACKs share the available upstream capacity with other traffic flows, e.g., telephony, especially flows that have reserved upstream capacity. This includes service guarantees at the IP layer (e.g., the Guaranteed Service [RFC2212]) or at the subnet layer (e.g., support of Voice over IP [ITU01] using the Unsolicited Grant service in DOCSIS [DS01], or CBR virtual connections in ATM over ADSL [ITU02, ANS01]).
IPは、TCP ACKを運ぶ流れ、ベストエフォートが他のトラフィックと利用可能なアップストリーム容量を共有する場合、容量の非対称性は、実質的に増加させることができる、例えば、電話、上流の容量を予約した、特にフローを流れます。これは、DOCSISで送信権割当サービス[DS01]、またはでCBR仮想接続を使用して、[ITU01] IP層（例えば、保証サービス[RFC2212]）で、またはサブネット層（例えば、ボイスオーバーIPのサポートでサービス保証を含みATM ADSL [ITU02、ANS01]以上）。
When multiple upstream links exist the asymmetry may be reduced by dividing upstream traffic between a number of available upstream links.
複数の上流リンクが非対称に存在する場合に使用可能な上りリンクの数との間のアップストリームトラフィックを分割することによって低減することができます。
In networks employing centralized multiple access control, asymmetry may be a fundamental consequence of the hub-and-spokes architecture of the network (i.e., a single base node communicating with multiple downstream nodes). The central node often incurs less transmission overhead and does not incur latency in scheduling its own downstream transmissions. In contrast, upstream transmission is subject to additional overhead and latency (e.g., due to guard times between transmission bursts, and contention intervals). This can produce significant network path asymmetry.
集中型の複数のアクセス制御を採用するネットワークでは、非対称（すなわち、単一のベースノードが複数の下流のノードと通信）ネットワークのハブ・アンド・スポーク・アーキテクチャの基本的な結果であってもよいです。中央ノードは、多くの場合、より少ない伝送オーバーヘッドが発生し、自身の下流送信をスケジュールに遅延が発生しません。対照的に、アップストリーム伝送は、追加のオーバーヘッド及び待ち時間（伝送バーストの間の時間を守るために、例えば、原因、およびコンテンション間隔）を受けます。これは、重要なネットワーク経路の非対称性を生成することができます。
Upstream capacity may be further limited by the requirement that each node must first request per-packet bandwidth using a contention MAC protocol (e.g., DOCSIS 1.0 MAC restricts each node to sending at most a single packet in each upstream time-division interval [DS00]). A satellite network employing dynamic Bandwidth on Demand (BoD), also consumes MAC resources for each packet sent (e.g., [EN00]). In these schemes, the available uplink capacity is a function of the MAC algorithm. The MAC and PHY schemes also introduce overhead per upstream transmission which could be so significant that transmitting short packets (including TCP ACKs) becomes as costly as transmitting MTU-sized data packets.
上流の容量は、さらに、各ノードは、最初の要求パケットごとの帯域幅競合MACプロトコルを使用しなければならないという要件によって制限されてもよい（例えば、DOCSIS 1.0 MACは、各アップストリームの時分割区間[DS00]で最大で単一のパケットを送信し、各ノードを制限します）。要求量（BOD）に動的帯域幅を用いた衛星ネットワークは、また、送信される各パケットのMACリソースを消費する（例えば、[EN00]）。これらの方式では、利用可能なアップリンク容量は、MACアルゴリズムの関数です。 MACおよびPHY方式も（TCP ACKを含む）短いパケットを送信すると、MTUサイズのデータパケットを送信するほど高価になるように重要である可能性がアップストリーム伝送あたりのオーバーヘッドを導入します。
Despite the technological differences between capacity-dependent and MAC-dependent asymmetries, both kinds of network path suffer reduced TCP performance for the same fundamental reason: the imperfection and variability of ACK feedback. This document discusses the problem in detail and describes several techniques that may reduce or eliminate the constraints.
ACKフィードバックの不完全性と変動：容量に依存し、MAC-依存非対称間の技術的な違いにもかかわらず、ネットワーク経路の両方の種類は、同じ基本的な理由のために減少TCP性能を被ります。この文書では詳細に問題を説明し、制約を軽減または除去することができるいくつかの技術を説明しています。
This section describes the implications of network path asymmetry on TCP performance. The reader is referred to [BPK99, Bal98, Pad98, FSS01, Sam99] for more details and experimental results.
このセクションでは、TCPのパフォーマンス上のネットワーク経路非対称の意味を説明しています。読者は詳細について、実験結果を得るために[BPK99、Bal98、Pad98、FSS01、Sam99]と呼ばれます。
The problems that degrade unidirectional transfer performance when the forward and return paths have very different capacities depend on the characteristics of the upstream link. Two types of situations arise for unidirectional traffic over such network paths: when the upstream bottleneck link has sufficient queuing to prevent packet (ACK) losses, and when the upstream bottleneck link has a small buffer. Each is considered in turn.
順方向及び戻り経路が非常に異なる容量を有するときに一方向の転送性能を低下させる問題が上流リンクの特性に依存します。上流のボトルネックリンクパケット（ACK）の損失を防止するのに十分なキューイングを有する場合、上流のボトルネックリンクが小さいバッファを有する場合：状況の二つのタイプは、ネットワーク経路上に一方向トラフィックに生じます。それぞれが順番に考えられています。
If the upstream bottleneck link has deep queues, so that this does not drop ACKs in the reverse direction, then performance is a strong function of the normalized bandwidth ratio, k. For example, for a 10 Mbps downstream link and a 50 Kbps upstream link, the raw capacity ratio is 200. With 1000-byte data packets and 40-byte ACKs, the ratio of the packet sizes is 25. This implies that k is 200/25 = 8. Thus, if the receiver acknowledges more frequently than one ACK every 8 (k) data packets, the upstream link will become saturated before the downstream link, limiting the throughput in the forward direction. Note that, the achieved TCP throughput is determined by the minimum of the receiver advertised window or TCP congestion window, cwnd [RFC2581].
これは逆方向にACKをドロップしないように上流のボトルネックリンクが、深いキューがある場合、性能は、正規化された帯域幅の比、kの強い関数です。例えば、10Mbpsの下流リンクと50 Kbpsの上流のリンクについて、生の容量比が1000バイトのデータ・パケットと40バイトのACKと200で、パケットサイズの比が25であるこれは、kが200であることを意味します受信機は、より頻繁に1よりACK毎に8（k）はデータ・パケットを認識場合/ 25 = 8したがって、上流リンクは、順方向にスループットを制限する、下流のリンクの前に飽和になるであろう。なお、達成TCPスループットは、受信機の最小値によって決定されるウィンドウまたはTCP輻輳ウィンドウCWND [RFC2581]アドバタイズ。
If ACKs are not dropped (at the upstream bottleneck link) and k > 1 or k > 0.5 when delayed ACKs are used [RFC1122], TCP ACK-clocking breaks down. Consider two data packets transmitted by the sender in quick succession. En route to the receiver, these packets get spaced apart according to the capacity of the smallest bottleneck link in the forward direction. The principle of ACK clocking is that the ACKs generated in response to receiving these data packets reflects this temporal spacing all the way back to the sender, enabling it to transmit new data packets that maintain the same spacing [Jac88]. ACK clocking with delayed ACKs, reflects the spacing between data packets that actually trigger ACKs. However, the limited upstream capacity and queuing at the upstream bottleneck router alters the inter-ACK spacing of the reverse path, and hence that observed at the sender. When ACKs arrive at the upstream bottleneck link at a faster rate than the link can support, they get queued behind one another. The spacing between them when they emerge from the link is dilated with respect to their original spacing, and is a function of the upstream bottleneck capacity. Thus the TCP sender clocks out new data packets at a slower rate than if there had been no queuing of ACKs. The performance of the connection is no longer dependent on the downstream bottleneck link alone; instead, it is throttled by the rate of arriving ACKs. As a side effect, the sender's rate of cwnd growth also slows down.
ACKは（上流のボトルネックリンクで）落とされず、K> 1又はK> 0.5遅延ACKはTCP ACKクロッキングブレークダウン、[RFC1122]を使用している。場合立て続けに送信者が送信した2つのデータパケットを考えてみましょう。受信機への途中、これらのパケットは、順方向の最小のボトルネックリンクの容量に応じて離間し得ます。 ACKクロッキングの原理は、これらのデータパケットを受信することに応答して生成ACKが同じ間隔[Jac88]を維持し、新たなデータパケットを送信することを可能にする、すべての方法送信者に、この時間間隔を反映していることです。 ACK遅延ACKでクロッキングは、実際にACKをトリガーするデータパケット間の間隔を反映しています。しかし、限られた上流の容量と上流ボトルネックルータにキューイングは、送信側で観察したがって逆の経路、及びの間のACK間隔を変化させます。 ACKがサポートできるリンクよりも速い速度で上流のボトルネックリンクに到着すると、彼らは互いの後ろにキューに入れられます。彼らはリンクから出てくるそれらの間の間隔は、それらの元の間隔に関して拡張され、上流のボトルネック容量の関数です。したがって、TCPの送信側クロックアウトのACKのないキューイングされていなかった場合よりも遅い速度で、新たなデータパケットを。接続のパフォーマンスは、もはや単独の下流のボトルネックリンクに依存しません。代わりに、それが到着したACKの割合で絞られます。副作用として、cwndの成長の送信者の割合も遅くなります。
A second side effect arises when the upstream bottleneck link on the reverse path is saturated. The saturated link causes persistent queuing of packets, leading to an increasing path Round Trip Time (RTT) [RFC2998] observed by all end hosts using the bottleneck link. This can impact the protocol control loops, and may also trigger false time out (underestimation of the path RTT by the sending host).
逆の経路上の上流のボトルネックリンクが飽和したときに、第2の副作用が生じます。飽和リンクがボトルネックリンクを使用して、全てのエンドホストによって観察増加パスのラウンドトリップ時間（RTT）[RFC2998]に至る、パケットの永続的なキューイングを引き起こします。これは、プロトコル制御ループに影響を与えることができ、また、（送信ホストによって経路RTTの過小評価）を偽時間をトリガすることができます。
A different situation arises when the upstream bottleneck link has a relatively small amount of buffer space to accommodate ACKs. As the transmission window grows, this queue fills, and ACKs are dropped. If the receiver were to acknowledge every packet, only one of every k
上流のボトルネックリンクがACKを収容するバッファ空間の比較的少量を有する場合、異なる状況が生じます。送信ウィンドウが大きくなるにつれて、このキューがいっぱい、とACKが廃棄されます。受信機は、すべてのkの一つだけ、すべてのパケットを確認した場合
ACKs would get through to the sender, and the remaining (k-1) are dropped due to buffer overflow at the upstream link buffer (here k is the normalized bandwidth ratio as before). In this case, the reverse bottleneck link capacity and slow ACK arrival rate are not directly responsible for any degraded performance. However, the infrequency of ACKs leads to three reasons for degraded performance:
ACKは送信者に介して取得し、残りの（K-1）になる（ここで、kは前のように正規化された帯域幅の比である）上流のリンクバッファに起因するバッファオーバーフローに低下しています。この場合、リバースボトルネックリンクの容量と遅いACK到着率は、いずれかの性能低下の直接の原因ではありません。しかし、ACKの低頻度は性能劣化のための3つの理由につながります：
1. The sender transmits data in large bursts of packets, limited only by the available cwnd. If the sender receives only one ACK in k, it transmits data in bursts of k (or more) packets because each ACK shifts the sliding window by at least k (acknowledged) data packets (TCP data segments). This increases the likelihood of data packet loss along the forward path especially when k is large, because routers do not handle large bursts of packets well.
1.送信者にのみ利用可能CWNDによって制限パケットの大バーストでデータを送信します。送信者がKでのみACKを受信した場合、各ACKが少なくともK（確認応答）データパケット（TCPデータセグメント）によってスライディングウィンドウを移動させるので、それはK（またはそれ以上）のパケットのバーストでデータを送信します。ルータはよくパケットの大バーストを処理しないので、これは、kが大きく、特にフォワードパスに沿ったデータパケット損失の可能性を増大させます。
2. Current TCP sender implementations increase their cwnd by counting the number of ACKs they receive and not by how much data is actually acknowledged by each ACK. The later approach, also known as byte counting (section 4.7), is a standard implementation option for cwnd increase during the congestion avoidance period [RFC2581]. Thus fewer ACKs imply a slower rate of growth of the cwnd, which degrades performance over long-delay connections.
2.現在のTCPの送信側の実装は、彼らが実際に各ACKによって承認されるデータの量によって受信していないACKの数をカウントすることにより、彼らののcwndを増加させます。また、バイトカウント（セクション4.7）として知られている後のアプローチは、輻輳回避期間[RFC2581]の間のcwndの増加のための標準的な実装オプションです。したがって、少ないACKが長い遅延接続でのパフォーマンスを低下させるのcwndの成長の遅い速度を、暗示します。
3. The sender TCP's Fast Retransmission and Fast Recovery algorithms [RFC2581] are less effective when ACKs are lost. The sender may possibly not receive the threshold number of duplicate ACKs even if the receiver transmits more than the DupACK threshold (> 3 DupACKs) [RFC2581]. Furthermore, the sender may possibly not receive enough duplicate ACKs to adequately inflate its cwnd during Fast Recovery.
3.送信側TCPの高速再送信および高速リカバリアルゴリズム[RFC2581]のACKが失われたとき、あまり効果的です。送信側は、おそらく受信機がのdupack閾値（> 3 DupACKs）[RFC2581]を超えて送信しても重複ACKのしきい値数を受信することができません。さらに、送信者はおそらく十分に高速リカバリ時にそのにcwndを膨らませるのに十分な重複ACKを受信できない場合があります。
The interaction of TCP with MAC protocols may degrade end-to-end performance. Variable round-trip delays and ACK queuing are the main symptoms of this problem.
MACプロトコルとTCPの相互作用は、エンドツーエンドのパフォーマンスが低下することがあります。可変往復遅延とACKキューイングは、この問題の主な症状です。
One example is the impact on terrestrial wireless networks [Bal98]. A high per-packet overhead may arise from the need for communicating link nodes to first synchronise (e.g., via a Ready To Send / Clear to Send (RTS/CTS) protocol) before communication and the significant turn-around time for the wireless channel. This overhead is variable, since the RTS/CTS exchange may need to back-off exponentially when the remote node is busy (e.g., engaged in a conversation with a different node). This leads to large and variable communication latencies in packet-radio networks.
一例では、地上無線ネットワーク[Bal98]への影響です。高いパケットごとのオーバヘッドが最初同期するためにリンクノードを通信するための必要性から生じ得る（（送信する/クリアを送信する準備を介して、例えば、RTS / CTS）プロトコル）通信前と無線チャネルのための重要なターンアラウンド時間。このオーバーヘッドは、RTS / CTS交換がバックオフするように指数関数的にリモートノードが使用中であるときに必要かもしれないので、可変である（例えば、別のノードとの会話に従事します）。これは、パケットラジオネットワークにおける大規模かつ可変通信の待ち時間につながります。
An asymmetric workload (more downstream than upstream traffic) may cause ACKs to be queued in some wireless nodes (especially in the end host modems), exacerbating the variable latency. Queuing may also occur in other shared media, e.g., cable modem uplinks, BoD access systems often employed on shared satellite channels.
非対称のワークロード（アップストリームトラフィックよりも下流）可変待ち時間を悪化させ、ACKが（特にエンドホストモデムに）いくつかの無線ノードにキューイングさせることができます。キューはまた、他の共有媒体で発生することがあり、例えば、ケーブルモデムのアップリンク、のBODアクセスシステムは、多くの場合、共有衛星チャネル上で使用しました。
Variable latency and ACK queuing reduces the smoothness of the TCP data flow. In particular, ACK traffic can interfere with the flow of data packets, increasing the traffic load of the system.
可変遅延とACKキューイングは、TCPデータフローの滑らかさを低減します。具体的には、ACKトラフィックがシステムのトラフィック負荷を増大させる、データパケットの流れを妨害することができます。
TCP measures the path RTT, and from this calculates a smoothed RTT estimate (srtt) and a linear deviation, rttvar. These are used to estimate a path retransmission timeout (RTO) [RFC2988], set to srtt + 4*rttvar. For most wired TCP connections, the srtt remains constant or has a low linear deviation. The RTO therefore tracks the path RTT, and the TCP sender will respond promptly when multiple losses occur in a window. In contrast, some wireless networks exhibit a high variability in RTT, causing the RTO to significantly increase (e.g., on the order of 10 seconds). Paths traversing multiple wireless hops are especially vulnerable to this effect, because this increases the probability that the intermediate nodes may already be engaged in conversation with other nodes. The overhead in most MAC schemes is a function of both the number and size of packets. However, the MAC contention problem is a significant function of the number of packets (e.g., ACKs) transmitted rather than their size. In other words, there is a significant cost to transmitting a packet regardless of packet size.
TCPは経路RTTを測定し、これより平滑RTT推定（SRTT）と線形偏差、RTTVARを算出します。これらはSRTT + 4 *のRTTVARに設定され、パス再送タイムアウト（RTO）[RFC2988]を推定するために使用されます。ほとんどの有線TCP接続の場合、SRTTは一定のままか低線偏差を持っています。 RTOは、したがって、パスRTTを追跡し、複数の損失がウィンドウ内に発生したときにTCPの送信者は、速やかに対応いたします。対照的に、いくつかの無線ネットワークは、（10秒のオーダーで、例えば）RTOが大幅に増加させる、RTTの高い変動性を示します。これは、中間ノードが既に他のノードとの会話に従事することができる確率を増加させるため、複数の無線ホップを横断する経路は、この効果に対して特に脆弱です。ほとんどのMACスキームにおけるオーバーヘッドは、パケットの数と大きさの両方の関数です。しかし、MAC競合の問題は、それらの大きさではなく、送信されたパケットの数（例えば、ACKの）の有意な関数です。言い換えれば、関係なく、パケットサイズのパケットを送信することに多大なコストがあります。
Experiments conducted on the Ricochet packet radio network in 1996 and 1997 demonstrated the impact of radio turnarounds and the corresponding increased RTT variability, resulting in degraded TCP performance. It was not uncommon for TCP connections to experience timeouts of 9 - 12 seconds, with the result that many connections were idle for a significant fraction of their lifetime (e.g., sometimes 35% of the total transfer time). This leads to under-utilization of the available capacity. These effects may also occur in other wireless subnetworks.
1996年と1997年に跳ね返るパケット無線ネットワーク上で行われた実験が低下TCP性能が得られ、無線ターンアラウンドの影響と対応する増加RTTの変動を示しました。多くの接続が彼らの生涯のかなりの割合（総転送時間の、例えば、時には35％）のためのアイドルだった、その結果、12秒 - TCP接続が9のタイムアウトが発生することは珍しくありませんでした。これは、下の利用可能な容量のにつながります。これらの効果は、他の無線サブネットワークで発生する可能性があります。
Bidirectional traffic arises when there are simultaneous TCP transfers in the forward and reverse directions over an asymmetric network path, e.g., a user who sends an e-mail message in the reverse direction while simultaneously receiving a web page in the forward direction. To simplify the discussion, only one TCP connection in each direction is considered. In many practical cases, several simultaneous connections need to share the available capacity, increasing the level of congestion.
双方向トラフィックが同時TCP転送が前方にあり、例えば、非対称のネットワーク経路上に同時に順方向にウェブページを受信しながら逆方向に電子メールメッセージを送信するユーザを方向を逆転するときに生じます。議論を簡単にするために、各方向に1つのTCP接続だけが考慮されます。多くの実用的な例では、いくつかの同時接続は、輻輳のレベルを高め、利用可能な容量を共有する必要があります。
Bidirectional traffic makes the effects discussed in section 3.1 more pronounced, because part of the upstream link bandwidth is consumed by the reverse transfer. This effectively increases the degree of bandwidth asymmetry. Other effects also arise due to the interaction between data packets of the reverse transfer and ACKs of the forward transfer. Suppose at the time the forward TCP connection is initiated, the reverse TCP connection has already saturated the bottleneck upstream link with data packets. There is then a high probability that many ACKs of the new forward TCP connection will encounter a full upstream link buffer and hence get dropped. Even after these initial problems, ACKs of the forward connection could get queued behind large data packets of the reverse connection. The larger data packets may have correspondingly long transmission times (e.g., it takes about 280 ms to transmit a 1 Kbyte data packet over a 28.8 kbps line). This causes the forward transfer to stall for long periods of time. It is only at times when the reverse connection loses packets (due to a buffer overflow at an intermediate router) and slows down, that the forward connection gets the opportunity to make rapid progress and build up its cwnd.
上流のリンク帯域幅の一部を逆転送によって消費されるため、双方向のトラフィックは、3.1節で述べた効果がより顕著になります。これは、効果的な帯域幅非対称性の度合いを増します。その他の効果はまた、順方向伝達の逆転送とACKのデータパケットの間の相互作用によって生じます。前方のTCP接続が開始された時点で仮定し、逆TCP接続は、すでにデータパケットとボトルネック上流のリンクを飽和しています。新しい前方TCPコネクションの多くのACKが落ちますので、完全な上流のリンクバッファに遭遇してなることを高い確率は、あります。でも、これらの初期の問題の後、前方接続のACKは逆接続の大きなデータパケットの後ろにキューに入れられる可能性があります。大きなデータパケットが（例えば、それは28.8 kbpsのライン上に1キロバイトのデータパケットを送信するために約280ミリ秒を要する）に対応し、長い伝送時間を有していてもよいです。これは、長時間の失速を楽しみに転送が発生します。逆接続は、前方接続が急速な進歩を作り、そのCWNDを構築する機会を得ること、（原因中間ルータでのバッファオーバーフローに対して）パケットを失い、遅くなるときだけ倍です。
When ACKs are queued behind other traffic for appreciable periods of time, the burst nature of TCP traffic and self-synchronizing effects can result in an effect known as ACK Compression [ZSC91], which reduces the throughput of TCP. It occurs when a series of ACKs, in one direction are queued behind a burst of other packets (e.g., data packets traveling in the same direction) and become compressed in time. This results in an intense burst of data packets in the other direction, in response to the burst of compressed ACKs arriving at the server. This phenomenon has been investigated in detail for bidirectional traffic, and recent analytical work [LMS97] has predicted ACK Compression may also result from bi-directional transmission with asymmetry, and was observed in practical asymmetric satellite subnetworks [FSS01]. In the case of extreme asymmetry (k>>1), the inter-ACK spacing can increase due to queuing (section 3.1), resulting in ACK dilation.
ACKが時間のかなりの期間にわたって他のトラフィックの後ろにキューイングされている場合、TCPトラフィックと自己同期効果のバースト性質は、TCPのスループットを低下させるACK圧縮[ZSC91]として知られる効果をもたらすことができます。一方向におけるACKのシリーズは、他のパケットのバーストの背後にキューイングされるときに発生する（例えば、同じ方向に移動するデータパケット）と時間的に圧縮されたなります。これは、サーバに到着圧縮ACKのバーストに応答して、他の方向のデータパケットの強烈なバーストをもたらします。この現象は、双方向トラフィックのために詳細に検討されており、最近の分析作業は、[LMS97] ACK圧縮はまた、非対称性と双方向伝送から生じることが予測している、と実用的な非対称衛星サブネットワーク[FSS01]で観察されました。極端な非対称の場合（K >> 1）、インターACK間隔はACK拡張をもたらす原因（セクション3.1）をキューイングに増加させることができます。
In summary, sharing of the upstream bottleneck link by multiple flows (e.g., IP flows to the same end host, or flows to a number of end hosts sharing a common upstream link) increases the level of ACK Congestion. The presence of bidirectional traffic exacerbates the constraints introduced by bandwidth asymmetry because of the adverse interaction between (large) data packets of a reverse direction connection and the ACKs of a forward direction connection.
要約すると、複数のフローによって、上流のボトルネックリンクの共有（例えば、IPは、同じエンドホストに流れる、または共通の上流リンク共有エンドホストの数に流れる）ACK輻輳のレベルを増加させます。双方向トラフィックの存在が理由（大）データ逆方向接続のパケットと順方向接続のACKの間の有害な相互作用の帯域幅非対称性によって導入制約を悪化させます。
Loss may occur in either the forward or reverse direction. For data transfer in the forward direction this results respectively in loss of data packets and ACK packets. Loss of ACKs is less significant than loss of data packets, because it generally results in stretch ACKs [CR98, FSS01].
損失は、正逆方向のいずれかに発生する可能性があります。順方向のデータ転送の場合、これは、データパケットとACKパケットの損失をそれぞれもたらします。それは一般的にストレッチのACK [CR98、FSS01]をもたらすためのACKの損失は、データパケットの損失よりも少ない重要です。
In the case of long delay paths, a slow upstream link [RFC3150] can lead to another complication when the end host uses TCP large windows [RFC1323] to maximize throughput in the forward direction. Loss of data packets on the forward path, due to congestion, or link loss, common for some wireless links, will generate a large number of back-to-back duplicate ACKs (or TCP SACK packets [RFC2018]), for each correctly received data packet following a loss. The TCP sender employs Fast Retransmission and Recovery [RFC2581] to recover from the loss, but even if this is successful, the ACK to the retransmitted data segment may be significantly delayed by other duplicate ACKs still queued at the upstream link buffer. This can ultimately lead to a timeout [RFC2988] and a premature end to the TCP Slow Start [RFC2581]. This results in poor forward path throughput. Section 5.3 describes some mitigations to counter this.
長い遅延経路の場合には、低速上流リンク[RFC3150]はエンドホストが順方向にスループットを最大化するためにTCP大きな窓[RFC1323]を使用する場合、他の合併症につながる可能性があります。各正しく受信するためのいくつかの無線リンクのための共通の輻輳へのフォワードパス上のデータパケットの損失、またはリンク損失、バックツーバックの重複ACK（またはTCPのSACKパケット[RFC2018]）を大量に生成されます、損失以下のデータパケット。 TCPの送信者は、損失から回復するための高速再送信と回復[RFC2581]を採用し、これが成功した場合でも、再送されたデータ・セグメントにACKを大幅にまだ上流のリンクバッファにキューイングされ、他の重複ACKにより遅れる場合があります。これは最終的にタイムアウト[RFC2988]とTCPスロースタート[RFC2581]に、早期終了につながることができます。これは、貧しい往路スループットになります。 5.3節は、これに対抗するためにいくつかの緩和策について説明します。
There are two key issues that need to be addressed to improve TCP performance over asymmetric networks. The first is to manage the capacity of the upstream bottleneck link, used by ACKs and possibly other traffic. A number of techniques exist which work by reducing the number of ACKs that flow in the reverse direction. This has the side effect of potentially destroying the desirable self-clocking property of the TCP sender where transmission of new data packets is triggered by incoming ACKs. Thus, the second issue is to avoid any adverse impact of infrequent ACKs.
非対称ネットワーク上のTCPの性能を向上させるために対処する必要がある2つの重要な問題があります。最初は、ACKおよびおそらく他のトラフィックによって使用され、上流のボトルネックリンクの容量を、管理することです。多くの技術は、逆方向に流れるACKの数を減らすことによって、その作業存在します。これは、潜在的に新たなデータパケットの送信は、着信のACKによってトリガされるTCP送信者の望ましい自己クロッキング性を破壊する副作用を有します。このように、第二の問題は、まれACKのいずれかの悪影響を避けるためです。
Each of these issues can be handled by local link-layer solutions and/or by end-to-end techniques. This section discusses end-to-end modifications. Some techniques require TCP receiver changes (sections 4.1 4.4, 4.5), some require TCP sender changes (sections 4.6, 4.7), and a pair requires changes to both the TCP sender and receiver (sections 4.2, 4.3). One technique requires a sender modification at the receiving host (section 4.8). The techniques may be used independently, however some sets of techniques are complementary, e.g., pacing (section 4.6) and byte counting (section 4.7) which have been bundled into a single TCP Sender Adaptation scheme [BPK99].
これらの問題の各々は、ローカルリンク層ソリューションによって、および/またはエンド・ツー・エンドの技術によって処理することができます。このセクションでは、エンドツーエンドの変更について説明します。いくつかの技術は、TCPレシーバ変化（セクション4.1 4.4、4.5）、いくつかは（セクション4.6、4.7）TCP送信者が変更を必要とし、一対のTCP送信側と受信側の両方の変更（セクション4.2、4.3）を必要が必要です。一つの技術は、受信ホスト（セクション4.8）で、送信者の修正が必要となります。技術は、単一のTCPセンダ適応方式[BPK99]にバンドルされている（セクション4.6）とバイトカウント（セクション4.7）ペーシング、例えば、しかし技術のいくつかのセットが相補的で、独立して使用することができます。
It is normally envisaged that these changes would occur in the end hosts using the asymmetric path, however they could, and have, been used in a middle-box or Protocol Enhancing Proxy (PEP) [RFC3135] employing split TCP. This document does not discuss the issues concerning PEPs. Section 4 describes several techniques, which do not require end-to-end changes.
通常、しかし、彼らは、そして、ミドルボックスまたはプロトコル強化プロキシ（PEP）[RFC3135]は分割TCPを用いに使用されてきた可能性があり、これらの変更は、非対称パスを使用して、エンドホストに発生することが想定されます。この文書では、のPEPに関する問題について議論しません。第4節では、エンドツーエンドの変更を必要としないいくつかのテクニックについて説明します。
There are two standard methods that can be used by TCP receivers to generate acknowledgments. The method outlined in [RFC793] generates an ACK for each incoming data segment (i.e., d=1). [RFC1122] states that hosts should use "delayed acknowledgments". Using this algorithm, an ACK is generated for at least every second full-sized segment (d=2), or if a second full-sized segment does not arrive within a given timeout (which must not exceed 500 ms [RFC1122], and is typically less than 200 ms). Relaxing the latter constraint (i.e., allowing d>2) may generate Stretch ACKs [RFC2760]. This provides a possible mitigation, which reduces the rate at which ACKs are returned by the receiver. An implementer should only deviate from this requirement after careful consideration of the implications [RFC2581].
確認応答を生成するために、TCP受信機で使用できる2つの標準的な方法があります。 [RFC793]に概説された方法は、各着信データ・セグメントに対するACKを生成する（すなわち、D = 1）。 [RFC1122]はホストが「遅延確認応答を」使用すべきであると述べています。このアルゴリズムを用いて、ACKは、少なくとも毎秒フルサイズのセグメント（D = 2）のために生成され、又は第二フルサイズのセグメントは、500ミリ秒[RFC1122]を超えていなければならない（所与のタイムアウト時間内に到着しない場合、および）200ミリ秒よりも典型的に少ないです。ストレッチのACK [RFC2760]を生成することができる（D> 2許可すなわち、）後者の制約を緩和します。これは、のACKが受信側によって返される速度を低下させる可能緩和を提供します。実装者は、唯一の意義[RFC2581]を慎重に検討した後、この要件から逸脱する必要があります。
Reducing the number of ACKs per received data segment has a number of undesirable effects including:
受信されたデータセグメント当たりACKの数を減少させることを含む、望ましくない影響の数を有します。
(i) Increased path RTT (ii) Increased time for TCP to open the cwnd (iii) Increased TCP sender burst size, since cwnd opens in larger steps
（I）CWND（III）の増加TCPセンダバーストサイズを開くためのTCPに対する増大経路RTT（ii）の増加時、CWNDが大きくステップで開くため
In addition, a TCP receiver is often unable to determine an optimum setting for a large d, since it will normally be unaware of the details of the properties of the links that form the path in the reverse direction.
加えて、TCP受信機は、多くの場合、それは通常、逆方向のパスを形成するリンクの特性の詳細を知らないので、大きなDの最適な設定を決定することができません。
RECOMMENDATION: A TCP receiver must use the standard TCP algorithm for sending ACKs as specified in [RFC2581]. That is, it may delay sending an ACK after it receives a data segment [RFC1122]. When ACKs are delayed, the receiver must generate an ACK within 500 ms and the ACK should be generated for at least every second full sized segment (MSS) of received data [RFC2581]. This will result in an ACK delay factor (d) that does not exceed a value of 2. Changing the algorithm would require a host modification to the TCP receiver and awareness by the receiving host that it is using a connection with an asymmetric path. Such a change has many drawbacks in the general case and is currently not recommended for use within the Internet.
推奨：TCP受信機は、[RFC2581]で指定されるようにACKを送信するための標準的なTCPアルゴリズムを使用しなければなりません。すなわち、それは、データセグメント[RFC1122]を受信した後、ACKを送信遅らせる場合があります。 ACKが遅延している場合、受信機は500ミリ秒以内にACKを生成しなければならず、ACKが受信されたデータ[RFC2581]の少なくとも毎秒フルサイズのセグメント（MSS）のために生成されるべきです。これは、非対称パスとの接続を使用している受信ホストによってTCP受信機と意識へのホストの変更を必要とするアルゴリズムを変更する2の値を超えないACK遅延係数（D）をもたらすであろう。このような変化は、一般的な場合には多くの欠点を持っており、現在、インターネット内での使用は推奨されません。
A TCP sender that uses a large Maximum Segment Size (MSS) reduces the number of ACKs generated per transmitted byte of data.
大きな最大セグメントサイズ（MSS）を使用するTCP送信側はデータの送信バイトごとに生成ACKの数を減少させます。
Although individual subnetworks may support a large MTU, the majority of current Internet links employ an MTU of approx 1500 bytes (that of Ethernet). By setting the Don't Fragment (DF) bit in the IP header, Path MTU (PMTU) discovery [RFC1191] may be used to determine the maximum packet size (and hence MSS) a sender can use on a given network path without being subjected to IP fragmentation, and provides a way to automatically select a suitable MSS for a specific path. This also guarantees that routers will not perform IP fragmentation of normal data packets.
個々のサブネットワークが大きなMTUをサポートするかもしれないが、現在のインターネットリンクの大半は、約1500バイト（イーサネットのこと）のMTUを採用します。 IPヘッダーでないフラグメント（DF）ビットを設定することにより、パスMTU（PMTU）の発見[RFC1191]されることなく所定のネットワークパス上で使用できる送信者を最大パケットサイズを決定する（従ってMSS）するために使用することができますIPフラグメンテーションに供して、自動的に特定の経路に適したMSSを選択するための方法を提供します。また、これはルータが通常のデータパケットのIP断片化を実行しないことが保証されます。
By electing not to use PMTU Discovery, an end host may choose to use IP fragmentation by routers along the path in the forward direction [RFC793]. This allows an MSS larger than smallest MTU along the path. However, this increases the unit of error recovery (TCP segment) above the unit of transmission (IP packet). This is not recommended, since it can increase the number of retransmitted packets following loss of a single IP packet, leading to reduced efficiency, and potentially aggravating network congestion [Ken87]. Choosing an MSS larger than the forward path minimum MTU also permits the sender to transmit more initial packets (a burst of IP fragments for each TCP segment) when a session starts or following RTO expiry, increasing the aggressiveness of the sender compared to standard TCP [RFC2581]. This can adversely impact other standard TCP sessions that share a network path.
PMTU検出を使用しないように選出することによって、エンドホストは、順方向[RFC793]で経路に沿ってルータによってIP断片化を使用することを選択することができます。これは、パスに沿って最小のMTUより大きいMSSができます。しかしながら、これは、送信（IPパケット）の単位上のエラー回復（TCPセグメント）の単位を増加させます。それは効率低下につながる、単一のIPパケットの損失以下再送パケットの数を増加させ、潜在的に悪化ネットワーク輻輳[Ken87]できるので、これは、推奨されません。 MSSを選択往路最小MTUはまた場合、セッションの開始または以下RTOの満了複数の初期パケット（各TCPセグメントのIPフラグメントのバースト）を送信する送信者を許可よりも大きく、標準TCPと比較して、送信者の攻撃性を増加させます[ RFC2581]。これは、悪のネットワークパスを共有する他の標準的なTCPセッションに影響を与えることができます。
RECOMMENDATION:
勧告：
A larger forward path MTU is desirable for paths with bandwidth asymmetry. Network providers may use a large MTU on links in the forward direction. TCP end hosts using Path MTU discovery may be able to take advantage of a large MTU by automatically selecting an appropriate larger MSS, without requiring modification. The use of Path MTU discovery [RFC1191] is therefore recommended.
大きなフォワードパスMTUは、帯域幅非対称を持つパスのが望ましいです。ネットワークプロバイダは、順方向リンク上で大きなMTUを使用することができます。パスMTU探索を使用して、TCPエンドホストは、変更を必要とすることなく、自動的に適切なより大きなMSSを選択することによって、大きなMTUを利用することができるかもしれません。パスMTU探索[RFC1191]の使用は、したがって、推奨されます。
Increasing the unit of error recovery and congestion control (MSS) above the unit of transmission and congestion loss (the IP packet) by using a larger end host MSS and IP fragmentation in routers is not recommended.
ルータにおける大端ホストMSSおよびIP断片化を用いて送信し、輻輳損失（IPパケット）の単位上のエラー回復と輻輳制御（MSS）の単位を増加させることは推奨されません。
ACK Congestion Control (ACC) is an experimental technique that operates end to end. ACC extends congestion control to ACKs, since they may make non-negligible demands on resources (e.g., packet buffers, and MAC transmission overhead) at an upstream bottleneck link. It has two parts: (a) a network mechanism indicating to the receiver that the ACK path is congested, and (b) the receiver's response to such an indication.
ACK輻輳制御（ACC）は、端と端を操作する実験技術です。それらは上流のボトルネックリンクで（例えば、パケットバッファ、およびMAC伝送オーバーヘッド）リソース上で無視できない要求を行うことができるので、ACCは、ACKのに輻輳制御を拡張します。 ACKパスが輻輳していることを受信機に示す（a）は、ネットワーク機構、及びそのような指示に（B）受信機の応答：これは、2つの部分を有しています。
A router feeding an upstream bottleneck link may detect incipient congestion, e.g., using an algorithm based on RED (Random Early Detection) [FJ93]. This may track the average queue size over a time window in the recent past. If the average exceeds a threshold, the router may select a packet at random. If the packet IP header has the Explicit Congestion Notification Capable Transport (ECT) bit set, the router may mark the packet, i.e., sets an Explicit Congestion Notification (ECN) [RFC3168] bit(s) in the IP header, otherwise the packet is normally dropped. The ECN notification received by the end host is reflected back to the sending TCP end host, to trigger congestion avoidance [RFC3168]. Note that routers implementing RED with ECN, do not eliminate packet loss, and may drop a packet (even when the ECT bit is set). It is also possible to use an algorithm other than RED to decide when to set the ECN bit.
上流のボトルネックリンクを供給ルータがRED（ランダム早期検出）に基づくアルゴリズム[FJ93]を用いて、例えば、初期の輻輳を検出することができます。これは、最近の過去の時間ウィンドウにわたって平均キューサイズを追跡することができます。平均値がしきい値を超えた場合、ルータはランダムにパケットを選択することができます。 IPヘッダ内のパケットのIPヘッダは、明示的輻輳通知可能なトランスポート（ECT）ビットが設定されている場合、ルータはパケットをマークすることができる、すなわち、明示的輻輳通知を設定（ECN）[RFC3168]ビット（S）、そうでない場合はパケット通常は廃棄されます。エンドホストで受信されたECN通知は、輻輳回避[RFC3168]をトリガするために、返送TCPエンドホストに反映されます。 ECNとREDを実装するルータは、パケット損失を排除していない、及び（ECTビットが設定されている場合でも）パケットをドロップすることができることに留意されたいです。 ECNビットを設定するタイミングを決定するためにRED以外のアルゴリズムを使用することも可能です。
ACC extends ECN so that both TCP data packets and ACKs set the ECT bit and are thus candidates for being marked with an ECN bit. Therefore, upon receiving an ACK with the ECN bit set [RFC3168], a TCP receiver reduces the rate at which it sends ACKs. It maintains a dynamically varying delayed-ACK factor, d, and sends one ACK for every d data packets received. When it receives a packet with the ECN bit set, it increases d multiplicatively, thereby multiplicatively decreasing the frequency of ACKs. For each subsequent RTT (e.g., determined using the TCP RTTM option [RFC1323]) during which it does not receive an ECN, it linearly decreases the factor d, increasing the frequency of ACKs. Thus, the receiver mimics the standard congestion control behavior of TCP senders in the manner in which it sends ACKs.
両方のTCPデータパケットとACKがECTビットを設定し、これECNビットでマークされているの候補であるように、ACCは、ECNを拡張します。したがって、ECNとACKを受信するとTCP受信機は、ACKを送信する速度を低下させる、[RFC3168]ビットセット。これは、動的に変化する遅延ACK率、Dを維持し、データパケットを受信したすべての日間1つのACKを送信します。それはECNビットを設定してパケットを受信すると、それによって乗算ACKの頻度を減少させる、乗算Dを増加させます。各後続のRTT（例えば、TCP RTTMオプション[RFC1323]を使用して決定される）がECNを受信しない間は、それは直線的にACKの頻度を増加させる、因子Dを減少させます。したがって、受信機を模倣するようにTCP送信者の標準的な輻輳制御動作は、それがACKを送信します。
The maximum value of d is determined by the TCP sender window size, which could be conveyed to the receiver in a new (experimental) TCP option. The receiver should send at least one ACK (preferably more) for each window of data from the sender (i.e., d < (cwnd/mss)) to prevent the sender from stalling until the receiver's delayed ACK timer triggers an ACK to be sent.
Dの最大値は、新しい（実験的な）TCPオプションで受信機に搬送することができるTCP送信ウィンドウサイズによって決定されます。受信機は、受信機の遅延ACKタイマが送信するACKをトリガするまで、ストールから送信者を防ぐために、送信者（すなわち、D <（CWND / MSS））からのデータの各ウインドウための少なくとも一つのACK（好ましくは）を送信すべきです。
RECOMMENDATION: ACK Congestion Control (ACC) is an experimental technique that requires TCP sender and receiver modifications. There is currently little experience of using such techniques in the Internet. Future versions of TCP may evolve to include this or similar techniques. These are the subject of ongoing research. ACC is not recommended for use within the Internet in its current form.
推奨：ACK輻輳制御（ACC）は、TCPの送信者と受信者の変更を必要と実験的手法です。インターネットでのこのような技術を使用しての少し経験が現在あり。 TCPの将来のバージョンでは、このまたは同様の技術を含めるように進化することがあります。これらは、現在進行中の研究の対象となっています。 ACCは、その現在のフォームでインターネット内での使用は推奨されません。
The Window Prediction Mechanism (WPM) is a TCP receiver side mechanism [CLP98] that uses a dynamic ACK delay factor (varying d) resembling the ACC scheme (section 4.3). The TCP receiver reconstructs the congestion control behavior of the TCP sender by predicting a cwnd value. This value is used along with the allowed window to adjust the receiver's value of d. WPM accommodates for unnecessary retransmissions resulting from losses due to link errors.
ウィンドウ予測機構（WPM）は、TCP受信側機構動的ACK遅延因子（変化D）を使用する[CLP98] ACC方式に似（セクション4.3）です。 TCP受信機は、CWNDの値を予測することによって、TCP送信側の輻輳制御動作を再構成します。この値は、Dの受信機の値を調整することができ、ウィンドウと一緒に使用されています。 WPMは、エラーをリンクによる損失から生じる不要な再送信のために適応します。
RECOMMENDATION: Window Prediction Mechanism (WPM) is an experimental TCP receiver side modification. There is currently little experience of using such techniques in the Internet. Future versions of TCP may evolve to include this or similar techniques. These are the subjects of ongoing research. WPM is not recommended for use within the Internet in its current form.
推奨：ウィンドウ予測機構（WPM）は、実験的なTCP受信側修飾です。インターネットでのこのような技術を使用しての少し経験が現在あり。 TCPの将来のバージョンでは、このまたは同様の技術を含めるように進化することがあります。これらは、現在進行中の研究の対象です。 WPMは、その現在のフォームでインターネット内での使用は推奨されません。
Acknowledgement based on Cwnd Estimation (ACE) [MJW00] attempts to measure the cwnd at the TCP receiver and maintain a varying ACK delay factor (d). The cwnd is estimated by counting the number of packets received during a path RTT. The technique may improve accuracy of prediction of a suitable cwnd.
TCP受信機でCWNDを測定し、変化ACK遅延係数（D）を維持するCWND推定（ACE）[MJW00]試みに基づいて肯定応答。 CWNDは経路RTTの間に受信されたパケットの数をカウントすることによって推定されます。技術は、適切なCWNDの予測の精度を向上させることができます。
RECOMMENDATION: Acknowledgement based on Cwnd Estimation (ACE) is an experimental TCP receiver side modification. There is currently little experience of using such techniques in the Internet. Future versions of TCP may evolve to include this or similar techniques. These are the subject of ongoing research. ACE is not recommended for use within the Internet in its current form.
推奨：CWND推定（ACE）に基づいて、肯定応答は、実験TCP受信側修飾です。インターネットでのこのような技術を使用しての少し経験が現在あり。 TCPの将来のバージョンでは、このまたは同様の技術を含めるように進化することがあります。これらは、現在進行中の研究の対象となっています。 ACEは、その現在のフォームでインターネット内での使用は推奨されません。
Reducing the frequency of ACKs may alleviate congestion of the upstream bottleneck link, but can lead to increased size of TCP sender bursts (section 4.1). This may slow the growth of cwnd, and is undesirable when used over shared network paths since it may significantly increase the maximum number of packets in the bottleneck link buffer, potentially resulting in an increase in network congestion. This may also lead to ACK Compression [ZSC91].
ACKの頻度を減らすことは上流のボトルネックリンクの混雑を緩和することができるが、TCP送信バースト（セクション4.1）の大型化につながることができます。これは、CWNDの成長を遅らせる、共有ネットワークパス上で使用するとき、それはかなり可能性、ネットワークの輻輳が増大する、ボトルネックリンクのバッファ内のパケットの最大数を増やす可能性があるため望ましくないことができます。これはまた、ACK圧縮[ZSC91]につながる可能性があります。
TCP Pacing [AST00], generally referred to as TCP Sender pacing, employs an adapted TCP sender to alleviating transmission burstiness. A bound is placed on the maximum number of packets the TCP sender can transmit back-to-back (at local line rate), even if the window(s) allow the transmission of more data. If necessary, more bursts of data packets are scheduled for later points in time computed based on the transmission rate of the TCP connection. The transmission rate may be estimated from the ratio cwnd/srtt. Thus, large bursts of data packets get broken up into smaller bursts spread over time.
一般的にTCPセンダペーシングと呼ばれるTCPペーシング[AST00]は、送信のバースト性を軽減するようになってTCP送信者を採用しています。結合された、ウィンドウ（s）は、より多くのデータの送信を許可した場合でも、TCP送信側はバックツーバック（ローカルラインレートで）送信できるパケットの最大数の上に配置されます。必要に応じて、データパケットの複数のバーストは、TCPコネクションの送信速度に基づいて計算された時間の後の点のために予定されています。伝送速度は比CWND / SRTTから推定することができます。このように、データパケットの大バーストは時間の経過とともに広がっ小さなバーストに分割されます。
A subnetwork may also provide pacing (e.g., Generic Traffic Shaping (GTS)), but implies a significant increase in the per-packet processing overhead and buffer requirement at the router where shaping is performed (section 5.3.3).
サブネットワークはまた、（例えば、汎用トラフィックシェーピング（GTS））、しかしは、シェーピングが行われているルータ（セクション5.3.3）にパケットごとの処理オーバーヘッドとバッファ要件の大幅な増加を意味ペーシング提供することができます。
RECOMMENDATIONS: TCP Sender Pacing requires a change to implementation of the TCP sender. It may be beneficial in the Internet and will significantly reduce the burst size of packets transmitted by a host. This successfully mitigates the impact of receiving Stretch ACKs. TCP Sender Pacing implies increased processing cost per packet, and requires a prediction algorithm to suggest a suitable transmission rate. There are hence performance trade-offs between end host cost and network performance. Specification of efficient algorithms remains an area of ongoing research. Use of TCP Sender Pacing is not expected to introduce new problems. It is an experimental mitigation for TCP hosts that may control the burstiness of transmission (e.g., resulting from Type 1 techniques, section 5.1.2), however it is not currently widely deployed. It is not recommended for use within the Internet in its current form.
提言：TCP送信者のペーシングは、TCPの送信元の実装を変更する必要があります。それはインターネットに有益であり得ると有意にホストによって送信されたパケットのバーストサイズを減少させます。これが成功したストレッチACKを受け取るの影響を軽減します。 TCPの送信者ペーシングは、パケットあたりの処理コストを増加させ、かつ、適切な伝送速度を提案する予測アルゴリズムを必要と示唆しています。エンドホストのコストやネットワークパフォーマンスとの性能のトレードオフが故にあります。効率的なアルゴリズムの仕様は、進行中の研究の分野残ります。 TCP送信者ペーシングの使用は新たな問題を導入することが期待されていません。これは、送信のバースト性（例えば、タイプ1から技術、セクション5.1.2を生じる）、しかし、それは、現在広く展開されていないを制御することができるTCPホストの実験的緩和です。これは、現在の形でのインターネット内での使用は推奨されません。
The TCP sender can avoid slowing growth of cwnd by taking into account the volume of data acknowledged by each ACK, rather than opening the cwnd based on the number of received ACKs. So, if an ACK acknowledges d data packets (or TCP data segments), the cwnd would grow as if d separate ACKs had been received. This is called TCP Byte Counting [RFC2581, RFC2760]. (One could treat the single ACK as being equivalent to d/2, instead of d ACKs, to mimic the effect of the TCP delayed ACK algorithm.) This policy works because cwnd growth is only tied to the available capacity in the forward direction, so the number of ACKs is immaterial.
TCPの送信者は、アカウントに、各ACKによって承認されるデータの量を取るのではなく、受け取ったACKの数に基づいてのcwndを開いてのcwndの成長鈍化を回避することができます。だから、ACKは、Dデータパケット（またはTCPデータセグメントを）認めた場合、cwndのは、Dの別々のACKが受信されていたかのように成長します。これは、TCPのバイトカウント[RFC2581、RFC2760]と呼ばれています。 （一つはACKアルゴリズムを遅らせTCPの効果を模倣するために、代わりにD ACKの、D / 2に相当するものとして、単一のACKを扱うことができます。）cwndの成長は順方向だけで利用可能な容量に結びついているため、このポリシーは、作品そのACKの数は重要ではありません。
This may mitigate the impact of asymmetry when used in combination with other techniques (e.g., a combination of TCP Pacing (section4.6), and ACC (section 4.3) associated with a duplicate ACK threshold at the receiver.)
他の技術と組み合わせて使用される場合、これは非対称性の影響を緩和することができる（例えば、TCPペーシング（section4.6）、及びACC受信機における重複ACK閾値に関連付けられている（セクション4.3）の組合せ。）
The main issue is that TCP byte counting may generate undesirable long bursts of TCP packets at the sender host line rate. An implementation must also consider that data packets in the forward direction and ACKs in the reverse direction may both travel over network paths that perform some amount of packet reordering. Reordering of IP packets is currently common, and may arise from various causes [BPS00].
主な問題は、TCPのバイトカウントが送信者のホストラインレートでTCPパケットの望ましくない長いバーストを発生させることができるということです。両方がパケット並べ替えのいくつかの量を行うネットワーク経路上で移動することができる実装も逆方向にそのデータ順方向のパケットとACKを考慮する必要があります。 IPパケットの並べ替えは、現在一般的であり、種々の原因[BPS00]から生じ得ます。
RECOMMENDATION: TCP Byte Counting requires a small TCP sender modification. In its simplest form, it can generate large bursts of TCP data packets, particularly when Stretch ACKs are received. Unlimited byte counting is therefore not allowed [RFC2581] for use within the Internet.
推奨：TCPバイトカウントは、小さなTCPの送信側の修正が必要です。その最も単純な形態では、それはストレッチのACKが受信される場合は特に、TCPデータパケットの大バーストを生成することができます。無制限のバイトカウントは、したがって、インターネット内で使用するために[RFC2581]を許可されていません。
It is therefore strongly recommended [RFC2581, RFC2760] that any byte counting scheme should include a method to mitigate the potentially large bursts of TCP data packets the algorithm can cause (e.g., TCP Sender Pacing (section 4.6), ABC [abc-ID]). If the burst size or sending rate of the TCP sender can be controlled then the scheme may be beneficial when Stretch ACKs are received. Determining safe algorithms remain an area of ongoing research. Further experimentation will then be required to assess the success of these safeguards, before they can be recommended for use in the Internet.
これは、任意のバイトカウント方式はTCPデータの潜在的に大きなバーストを緩和するための方法は、アルゴリズムは、例えば（（セクション4.6）をペーシングTCPの送信者を引き起こす可能性がありますパケット含めるべきであることが強く推奨[RFC2581、RFC2760]であるABC [ABC-ID] ）。 TCP送信者のバーストサイズ又は送信速度は、その後に制御することができる場合ストレッチのACKを受信したときスキームが有益であり得ます。決定安全なアルゴリズムは、進行中の研究の分野残ります。彼らはインターネットでの使用を推奨することができます前に、さらなる実験は、その後、これらのセーフガードの成功を評価する必要があります。
Backpressure is a technique to enhance the performance of bidirectional traffic for end hosts directly connected to the upstream bottleneck link [KVR98]. A limit is set on how many data packets of upstream transfers can be enqueued at the upstream bottleneck link. In other words, the bottleneck link queue exerts 'backpressure' on the TCP (sender) layer. This requires a modified implementation, compared to that currently deployed in many TCP stacks. Backpressure ensures that ACKs of downstream connections do not get starved at the upstream bottleneck, thereby improving performance of the downstream connections. Similar generic schemes that may be implemented in hosts/routers are discussed in section 5.4.
背圧は、直接上流のボトルネックリンク[KVR98]に接続されたエンドホストの双方向トラフィックの性能を向上させる技術です。制限は、上流の転送のパケットが上流のボトルネックリンクでエンキューすることができますどのように多くのデータに設定されています。つまり、ボトルネックリンクキューは、TCP（送信者）層の上に「背圧」を発揮します。これは、現在、多くのTCPスタックにデプロイされたことに比べて、修正を実装する必要があります。背圧は、ダウンストリーム接続のACKが、それによって下流の接続のパフォーマンスを向上させること、上流のボトルネックに飢えて取得しないことを保証します。ホスト/ルータに実装することができる同様の一般的なスキームは、セクション5.4に記載されています。
Backpressure can be unfair to a reverse direction connection and make its throughput highly sensitive to the dynamics of the forward connection(s).
背圧は、逆方向接続に不当であるとフォワード接続（複数可）のダイナミクスへのスループットが非常に敏感にすることができます。
RECOMMENDATION: Backpressure requires an experimental modification to the sender protocol stack of a host directly connected to an upstream bottleneck link. Use of backpressure is an implementation issue, rather than a network protocol issue. Where backpressure is implemented, the optimizations described in this section could be desirable and can benefit bidirectional traffic for hosts. Specification of safe algorithms for providing backpressure is still a subject of ongoing research. The technique is not recommended for use within the Internet in its current form.
推奨：背圧が直接上流のボトルネックリンクに接続されたホストの送信元プロトコルスタックに実験的な変更を必要とします。背圧の使用は実装の問題ではなく、ネットワークプロトコルの問題です。背圧が実装される場合、このセクションで説明する最適化が望ましいかもしれないし、ホストの双方向トラフィックの利益を得ることができます。背圧を提供するための安全なアルゴリズムの仕様はまだ進行中の研究の対象です。技術は、現在の形でのインターネット内での使用は推奨されません。
Various link and network layer techniques have been suggested to mitigate the effect of an upstream bottleneck link. These techniques may provide benefit without modification to either the TCP sender or receiver, or may alternately be used in conjunction with one or more of the schemes identified in section 4. In this document, these techniques are known as "transparent" [RFC3135], because at the transport layer, the TCP sender and receiver are not necessarily aware of their existence. This does not imply that they do not modify the pattern and timing of packets as observed at the network layer. The techniques are classified here into three types based on the point at which they are introduced.
様々なリンクおよびネットワーク層技術は、上流のボトルネックリンクの影響を緩和するために提案されています。これらの技術は、TCPの送信側または受信側のいずれかに変更することなく利益をもたらすことができる、あるいは交互に本書ではセクション4に同定された方式の1つ以上と組み合わせて使用することができ、これらの技術は、「透明」[RFC3135]として知られており、トランスポート層で、TCPの送信者と受信者は必ずしもその存在を認識しているためではありません。これは、ネットワーク層で観察されるように、彼らはパケットのパターンとタイミングを変更しないことを意味するものではありません。技術は、それらが導入される点に基づいて3種類にここに分類されています。
Most techniques require the individual TCP connections passing over the bottleneck link(s) to be separately identified and imply that some per-flow state is maintained for active TCP connections. A link scheduler may also be employed (section 5.4). The techniques (with one exception, ACK Decimation (section 5.2.2) require:
ほとんどの技術は、個別に識別することがボトルネックリンク（複数可）の上を通過する個々のTCP接続を必要とし、いくつかのフローごとの状態がアクティブなTCP接続のために維持されていることを示唆しています。リンクスケジューラは、（セクション5.4）を使用してもよいです。 1つの例外を除き技術は、（ACKデシメーション（セクション5.2.2）が必要です。
(i) Visibility of an unencrypted IP and TCP packet header (e.g., no use of IPSec with payload encryption [RFC2406]). (ii) Knowledge of IP/TCP options and ability to inspect packets with tunnel encapsulations (e.g., [RFC2784]) or to suspend processing of packets with unknown formats. (iii) Ability to demultiplex flows (by using address/protocol/port number, or an explicit flow-id).
（I）暗号化されていないIPとTCPパケットヘッダの可視性（例えば、ペイロードの暗号化[RFC2406]とのIPSecを用いません）。 （ii）のIP / TCPオプションの知識とトンネルカプセル化のパケットを検査する（例えば、[RFC2784]）または未知のフォーマットを持つパケットの処理を停止する能力。 （III）（アドレス/プロトコル/ポート番号、または明示的なフローIDを使用して）流れを分離する機能。
[RFC3135] describes a class of network device that provides more than forwarding of packets, and which is known as a Protocol Enhancing Proxy (PEP). A large spectrum of PEP devices exists, ranging from simple devices (e.g., ACK filtering) to more sophisticated devices (e.g., stateful devices that split a TCP connection into two separate parts). The techniques described in section 5 of this document belong to the simpler type, and do not inspect or modify any TCP or UDP payload data. They also do not modify port numbers or link addresses. Many of the risks associated with more complex PEPs do not exist for these schemes. Further information about the operation and the risks associated with using PEPs are described in [RFC3135].
[RFC3135]はパケットの転送よりも多くを提供するネットワークデバイスのクラスを記述し、どのプロトコル強化プロキシ（PEP）として知られています。 PEP装置の大スペクトルは、単純なデバイス（例えば、ACKフィルタリング）に対してより洗練されたデバイス（2つの別個の部分にTCPコネクションを分割例えば、ステートフル装置）に至るまで、存在します。このドキュメントのセクション5に記載された技術は、シンプルなタイプに属し、かつ任意のTCPまたはUDPペイロードデータを検査したり変更しないでください。彼らはまた、ポート番号やリンクアドレスを変更しないでください。より複雑なのPEPに伴うリスクの多くは、これらの計画のために存在していません。さらに操作に関する情報とのPEPを使用することに関連するリスクは、[RFC3135]に記載されています。
A client may reduce the volume of bits used to send a single ACK by using compression [RFC3150, RFC3135]. Most modern dial-up modems support ITU-T V.42 bulk compression. In contrast to bulk compression, header compression is known to be very effective at reducing the number of bits sent on the upstream link [RFC1144]. This relies on the observation that most TCP packet headers vary only in a few bit positions between successive packets in a flow, and that the variations can often be predicted.
クライアントは、圧縮[RFC3150、RFC3135]を使用して単一のACKを送信するために使用されるビットの量を減少させることができます。最近のほとんどのダイヤルアップモデムは、ITU-T V.42バルク圧縮をサポートしています。バルク圧縮とは対照的に、ヘッダ圧縮は、上流リンク[RFC1144]に送信されたビットの数を減少させるのに非常に有効であることが知られています。これは、ほとんどのTCPパケットヘッダは、フロー内の連続するパケットの間にいくつかのビット位置にのみ変化観察に依存して、および変更はしばしば予測することができます。
TCP header compression [RFC1144] (sometimes known as V-J compression) is a Proposed Standard describing use over low capacity links running SLIP or PPP [RFC3150]. It greatly reduces the size of ACKs on the reverse link when losses are infrequent (a situation that ensures that the state of the compressor and decompressor are synchronized). However, this alone does not address all of the asymmetry issues:
（時にはV-J圧縮としても知られる）TCPヘッダー圧縮[RFC1144]はSLIPまたはPPP [RFC3150]を実行している低容量リンク上で使用を記述する提案標準です。これは大幅な損失はまれであり、逆方向リンク（コンプレッサとデコンプレッサの状態が同期されることを保証する状況）にACKのサイズを減少させます。しかし、これだけでは、非対称性の問題のすべてを解決しません。
(i) In some (e.g., wireless) subnetworks there is a significant per-packet MAC overhead that is independent of packet size (section 3.2). (ii) A reduction in the size of ACKs does not prevent adverse interaction with large upstream data packets in the presence of bidirectional traffic (section 3.3). (iii) TCP header compression cannot be used with packets that have IP or TCP options (including IPSec [RFC2402, RFC2406], TCP RTTM [RFC1323], TCP SACK [RFC2018], etc.). (iv) The performance of header compression described by RFC1144 is significantly degraded when compressed packets are lost. An improvement, which can still incur significant penalty on long network paths is described in [RFC2507]. This suggests it should only be used on links (or paths) that experience a low level of packet loss [RFC3150]. (v) The normal implementation of Header Compression inhibits compression when IP is used to support tunneling (e.g., L2TP, GRE [RFC2794], IP-in-IP). The tunnel encapsulation complicates locating the appropriate packet headers. Although GRE allows Header Compression on the inner (tunneled) IP header [RFC2784], this is not recommended, since loss of a packet (e.g., due to router congestion along the tunnel path) will result in discard of all packets for one RTT [RFC1144].
いくつかの（例えば、無線）において（i）は、パケットサイズ（セクション3.2）とは無関係である有意なパケットごとのMACオーバーヘッドが存在するサブネットワーク。 （II）ACKのサイズの減少は、双方向トラフィック（セクション3.3）の存在下で大アップストリームデータパケットとの有害な相互作用を妨げません。 （III）TCPヘッダー圧縮は、（IPSecの[RFC2402、RFC2406]、TCP RTTM [RFC1323]、TCP SACK [RFC2018]などを含む）IPまたはTCPオプションを持つパケットで使用することができません。圧縮されたパケットが失われたときに（iv）のRFC1144によって記述ヘッダ圧縮の性能が大幅に劣化します。依然として長いネットワーク経路に大きなペナルティを被ることができる改善は、[RFC2507]に記載されています。これは、それが唯一のパケット損失[RFC3150]のローレベルを経験するリンク（またはパス）上で使用されるべきである示唆する。 IPは、（例えば、L2TP、GRE [RFC2794]、IPインIP）トンネリングをサポートするために使用された場合（V）ヘッダ圧縮の通常の実装では、圧縮を阻害します。トンネルカプセル化は、適当なパケットヘッダを配置する複雑。 GREは、内側（トンネリング）IPヘッダ[RFC2784]にヘッダ圧縮を可能にするが、これは、一つRTT [ための全てのパケットの廃棄をもたらすであろう（これはトンネル経路に沿ったルータの輻輳に、例えば）パケットの損失ので、推奨されませんRFC1144]。
RECOMMENDATION: TCP Header Compression is a transparent modification performed at both ends of the upstream bottleneck link. It offers no benefit for flows employing IPSec [RFC2402, RFC2406], or when additional protocol headers are present (e.g., IP or TCP options, and/or tunnel encapsulation headers). The scheme is widely implemented and deployed and used over Internet links. It is recommended to improve TCP performance for paths that have a low-to-medium bandwidth asymmetry (e.g., k<10).
推奨：TCPヘッダー圧縮は、上流のボトルネックリンクの両端で行わ透明変形例です。これは、IPSec [RFC2402、RFC2406]を用いたフローのための利点を提供しない、または追加のプロトコルヘッダが存在する場合（例えば、IPまたはTCPオプション、及び/又はトンネルカプセル化ヘッダ）。スキームは、広く実装と展開され、インターネットリンク上で使用されています。低〜中帯域幅非対称（例えば、K <10）を有するパスのTCP性能を向上させることが推奨されます。
In the form described in [RFC1144], TCP performance is degraded when used over links (or paths) that may exhibit appreciable rates of packet loss [RFC3150]. It may also not provide significant improvement for upstream links with bidirectional traffic. It is therefore not desirable for paths that have a high bandwidth asymmetry (e.g., k>10).
パケット損失[RFC3150]のかなりの割合を示すことができるリンク（またはパス）を介して使用される場合、[RFC1144]に記載された形態で、TCPの性能が劣化します。また、双方向のトラフィックを持つ上流リンクのための大幅な改善を提供することはできません。これは、高帯域幅の非対称（例えば、K> 10）を有するパスについて、したがって望ましくありません。
TCP header compression [RFC1144] and IP header compression [RFC2507] do not perform well when subject to packet loss. Further, they do not compress packets with TCP option fields (e.g., SACK [RFC2018] and Timestamp (RTTM) [RFC1323]). However, recent work on more robust schemes suggest that a new generation of compression algorithms may be developed which are much more robust. The IETF ROHC working group has specified compression techniques for UDP-based traffic [RFC3095] and is examining a number of schemes that may provide improve TCP header compression. These could be beneficial for asymmetric network paths.
場合パケット損失を受けるTCPヘッダー圧縮[RFC1144]とIPヘッダー圧縮[RFC2507]はうまく機能しません。さらに、彼らはTCPオプションフィールドを持つパケットを圧縮していない（例えば、SACK [RFC2018]とタイムスタンプ（RTTM）[RFC1323]）。しかし、より堅牢なスキームについての最近の仕事は、はるかに堅牢である圧縮アルゴリズムの新世代を開発することができることを示唆しています。 IETF ROHCワーキンググループは、UDPベースのトラフィック[RFC3095]の圧縮技術を指定しており、TCPヘッダ圧縮を改善提供することができる方式の数を検討しています。これらは、非対称のネットワーク経路のために有益である可能性があります。
RECOMMENDATION: Robust header compression is a transparent modification that may be performed at both ends of an upstream bottleneck link. This class of techniques may also be suited to Internet paths that suffer low levels of re-ordering. The techniques benefit paths with a low-to-medium bandwidth asymmetry (e.g., k>10) and may be robust to packet loss.
推奨：ロバストヘッダ圧縮は、上流のボトルネックリンクの両端で行うことができる透明な修飾です。技術のこのクラスはまた、再発注の低レベルを受け、インターネットパスに適していてもよいです。技術は、低〜中帯域幅非対称（例えば、K> 10）でパスの利益およびパケット損失にロバストであってもよいです。
Selection of suitable compression algorithms remains an area of ongoing research. It is possible that schemes may be derived which support IPSec authentication, but not IPSec payload encryption. Such schemes do not alone provide significant improvement in asymmetric networks with a high asymmetry and/or bidirectional traffic.
適切な圧縮アルゴリズムの選択は、進行中の研究の分野残ります。 IPSecペイロード暗号化IPSec認証をサポートしているスキームが導出される可能性があるが、ありません。このようなスキームは、単独の高非対称性および/または双方向のトラフィックが非対称ネットワークにおける有意な改善を提供しません。
Techniques beyond Type 0 header compression are required to address the performance problems caused by appreciable asymmetry (k>>1). One set of techniques is implemented only at one point on the reverse direction path, within the router/host connected to the upstream bottleneck link. These use flow class or per-flow queues at the upstream link interface to manage the queue of packets waiting for transmission on the bottleneck upstream link.
タイプ0ヘッダ圧縮を越え技術はかなりの非対称性（K >> 1）によるパフォーマンスの問題に対処するために必要とされます。技術の一組は、上流のボトルネックリンクに接続されたルータ/ホスト内に、逆方向経路上の一点のみで実現されます。これらは、ボトルネック上流のリンク上で送信待ちパケットのキューを管理するために、上流のリンクインターフェイスでフロークラスまたはフローごとのキューを使用します。
This type of technique bounds the upstream link buffer queue size, and employs an algorithm to remove (discard) excess ACKs from each queue. This relies on the cumulative nature of ACKs (section 4.1). Two approaches are described which employ this type of mitigation.
この種の技術は、上流のリンクバッファキューサイズの境界、各キューから（廃棄）過剰ACKを除去するためのアルゴリズムを採用しています。これはACKの（セクション4.1）の累積的な性質に依存しています。 2つのアプローチが緩和のこのタイプを採用するが記載されています。
ACK Filtering (AF) [DMT96, BPK99] (also known as ACK Suppression [SF98, Sam99, FSS01]) is a TCP-aware link-layer technique that reduces the number of ACKs sent on the upstream link. This technique has been deployed in specific production networks (e.g., asymmetric satellite networks [ASB96]). The challenge is to ensure that the sender does not stall waiting for ACKs, which may happen if ACKs are indiscriminately removed.
ACKフィルタリング（AF）DMT96、BPK99]（また、ACK抑制として知られている[SF98、Sam99、FSS01]）は、アップストリームリンク上で送信されたACKの数を減少させるTCP対応リンク層技術です。この技術は、特定の生産ネットワークに配備されている（例えば、非対称衛星ネットワーク[ASB96]）。課題は、送信側がACKのが無差別に削除された場合に発生する可能性がありACKを、待っているストールしないようにすることです。
When an ACK from the receiver is about to be enqueued at a upstream bottleneck link interface, the router or the end host link layer (if the host is directly connected to the upstream bottleneck link) checks the transmit queue(s) for older ACKs belonging to the same TCP connection. If ACKs are found, some (or all of them) are removed from the queue, reducing the number of ACKs.
受信機からのACKは、上流のボトルネックリンクインタフェースでエンキューされようとしているとき、ルータまたはエンドホストリンク層は、（ホストが直接上流のボトルネックリンクに接続されている場合）に属する古いACKのための送信キュー（複数可）をチェック同じTCP接続に。 ACKのが発見された場合、いくつかの（またはすべて）は、ACKの数を減らし、キューから削除されます。
Some ACKs also have other functions in TCP [RFC1144], and should not be deleted to ensure normal operation. AF should therefore not delete an ACK that has any data or TCP flags set (SYN, RST, URG, and FIN). In addition, it should avoid deleting a series of 3 duplicate ACKs that indicate the need for Fast Retransmission [RFC2581] or ACKs with the Selective ACK option (SACK)[RFC2018] from the queue to avoid causing problems to TCP's data-driven loss recovery mechanisms. Appropriate treatment is also needed to preserve correct operation of ECN feedback (carried in the TCP header) [RFC3168].
いくつかのACKがまた、TCP [RFC1144]で他の機能を持っており、正常な動作を保証するために削除すべきではありません。 AFは、したがって（SYN、RST、URG、およびFIN）設定されたデータまたはTCPフラグを持つACKを削除するべきではありません。また、TCPのデータ駆動型損失回復に問題を引き起こして回避するために、キューから高速再送信の必要性を示す3個の重複ACK [RFC2581]または選択的ACKオプション（SACK）とACKの[RFC2018]の一連の削除を避けるべきですメカニズム。適切な処置はまた、（TCPヘッダで運ば）ECNフィードバック[RFC3168]の正しい動作を維持するために必要とされます。
A range of policies to filter ACKs may be used. These may be either deterministic or random (similar to a random-drop gateway, but should take into consideration the semantics of the items in the queue). Algorithms have also been suggested to ensure a minimum ACK rate to guarantee the TCP sender window is updated [Sam99, FSS01], and to limit the number of data packets (TCP segments) acknowledged by a Stretch ACK. Per-flow state needs to be maintained only for connections with at least one packet in the queue (similar to FRED [LM97]). This state is soft [Cla88], and if necessary, can easily be reconstructed from the contents of the queue.
ACKをフィルタリングするポリシーの範囲を使用することができます。これらは、決定論的またはランダムのいずれであってもよい（ランダムドロップゲートウェイに類似するが、キューに考慮項目の意味を取るべきです）。アルゴリズムはまた、[Sam99、FSS01] TCP送信ウィンドウを保証する最小のACK率が更新されることを保証することが示唆されており、ストレッチACKにより確認応答データパケット（TCPセグメント）の数を制限します。フロー毎の状態のみ（FRED [LM97]と同様に）キュー内の少なくとも1つのパケットとの接続のために維持される必要があります。この状態は、[Cla88]柔らかく、そして必要であれば、容易にキューの内容から再構築することができます。
The undesirable effect of delayed DupACKs (section 3.4) can be reduced by deleting duplicate ACKs above a threshold value [MJW00, CLP98] allowing Fast Retransmission, but avoiding early TCP timeouts, which may otherwise result from excessive queuing of DupACKs.
遅延DupACKs（セクション3.4）の望ましくない効果が閾値[MJW00、CLP98]上記重複ACKを削除高速再送を可能にするが、それ以外DupACKsの過度のキューイングに起因する可能性がある、初期のTCPタイムアウトを回避することによって低減することができます。
Future schemes may include more advanced rules allowing removal of selected SACKs [RFC2018]. Such a scheme could prevent the upstream link queue from becoming filled by back-to-back ACKs with SACK blocks. Since a SACK packet is much larger than an ACK, it would otherwise add significantly to the path delay in the reverse direction. Selection of suitable algorithms remains an ongoing area of research.
将来のスキームは、選択されたサックス[RFC2018]の除去を可能にする、より高度なルールを含んでもよいです。このような方式はSACKブロックとバックツーバックのACKによって埋めになってから上流のリンクキューを防ぐことができます。 SACKパケットがACKよりもはるかに大きいので、それはそうでなければ逆方向のパスの遅延に有意に追加します。適切なアルゴリズムの選択は、研究の継続的な面積のまま。
RECOMMENDATION: ACK Filtering requires a modification to the upstream link interface. The scheme has been deployed in some networks where the extra processing overhead (per ACK) may be compensated for by avoiding the need to modify TCP. ACK Filtering can generate Stretch ACKs resulting in large bursts of TCP data packets. Therefore on its own, it is not recommended for use in the general Internet.
推奨：ACKフィルタリングは、上流のリンクインタフェースに変更する必要があります。スキームは、（ACKあたり）余分な処理オーバーヘッドがTCPを変更する必要性を回避することによって補償することができるいくつかのネットワークに配置されています。 ACKフィルタリングはTCPデータパケットの大バーストが生じストレッチACKを生成することができます。したがって、独自に、それは一般的なインターネットでの使用は推奨されません。
ACK Filtering when used in combination with a scheme to mitigate the effect of Stretch ACKs (i.e., control TCP sender burst size) is recommended for paths with appreciable asymmetry (k>1) and/or with bidirectional traffic. Suitable algorithms to support IPSec authentication, SACK, and ECN remain areas of ongoing research.
ACKフィルタリングはかなりの非対称性（K> 1）および/または双方向トラフィックを有するとパスのために推奨されるストレッチのACK（即ち、制御TCPセンダバーストサイズ）の影響を軽減する方式と組み合わせて使用する場合。 IPSec認証、SACK、およびECNをサポートするための適切なアルゴリズムは、進行中の研究の分野残ります。
ACK Decimation is based on standard router mechanisms. By using an appropriate configuration of (small) per-flow queues and a chosen dropping policy (e.g., Weighted Fair Queuing, WFQ) at the upstream bottleneck link, a similar effect to AF (section 5.2.1) may be obtained, but with less control of the actual packets which are dropped.
ACKデシメーションは、標準のルータメカニズムに基づいています。上流のボトルネックリンクで（小）フローごとのキューと選択された滴下ポリシー（例えば、均等化キューイング、WFQ）の適切な構成を使用することにより、AF（セクション5.2.1）と同様の効果が得られるが、とすることができます廃棄され、実際のパケットの少ないコントロール。
In this scheme, the router/host at the bottleneck upstream link maintains per-flow queues and services them fairly (or with priorities) by queuing and scheduling of ACKs and data packets in the reverse direction. A small queue threshold is maintained to drop excessive ACKs from the tail of each queue, in order to reduce ACK Congestion. The inability to identify special ACK packets (c.f., AF) introduces some major drawbacks to this approach, such as the possibility of losing DupACKs, FIN/ACK, RST packets, or packets carrying ECN information [RFC3168]. Loss of these packets does not significantly impact network congestion, but does adversely impact the performance of the TCP session observing the loss.
この方式では、ボトルネック上流のリンクのルータ/ホストには、キューイングおよび逆方向のACKおよびデータパケットのスケジューリングによって（または優先順位付き）かなりフローごとのキューとサービス、それらを維持しています。小さなキューしきい値は、ACK輻輳を低減するために、各キューの最後尾から過剰なACKをドロップするように維持されます。特別なACKパケット（C.F.、AF）を識別することができないことは、DupACKs、FIN / ACK、RSTパケット、またはECN情報を搬送するパケット[RFC3168]を失う可能性として、このアプローチにはいくつかの大きな欠点を導入します。これらのパケットの損失は大幅にネットワークの混雑に影響を与えませんが、不利な損失を観察するTCPセッションのパフォーマンスに影響を与えません。
A WFQ scheduler may assign a higher priority to interactive traffic (providing it has a mechanism to identify such traffic) and provide a fair share of the remaining capacity to the bulk traffic. In the presence of bidirectional traffic, and with a suitable scheduling policy, this may ensure fairer sharing for ACK and data packets. An increased forward transmission rate is achieved over asymmetric links by an increased ACK Decimation rate, leading to generation of Stretch ACKs. As in AF, TCP sender burst size increases when Stretch ACKs are received unless other techniques are used in combination with this technique.
WFQスケジューラは（そのようなトラフィックを識別するための機構を有して提供）インタラクティブトラフィックに高い優先順位を割り当て、バルクトラフィックに残容量の公正な取り分を提供することができます。双方向トラフィックの存在下で、及び適切なスケジューリング方針で、これはACK及びデータパケットのためのより公平な共有を保証することができます。増加した順方向伝送速度をストレッチACKの生成をもたらす、増加したACKデシメーション・レートによって非対称リンク上で達成されます。他の技術は、この技術と組み合わせて使用されていない限りストレッチのACKを受信したときにAFのように、TCP送信バーストサイズが増加します。
This technique has been deployed in specific networks (e.g., a network with high bandwidth asymmetry supporting high-speed data services to in-transit mobile hosts [Seg00]). Although not optimal, it offered a potential mitigation applicable when the TCP header is difficult to identify or not visible to the link layer (e.g., due to IPSec encryption).
この技術は、特定のネットワークに配備されている（例えば、高帯域幅非対称に高速データサービスをサポートするとともに、ネットワークにおけるトランジットモバイルホスト[SEG00]）。 TCPヘッダは（これはIPSec暗号化に、例えば）を識別することが困難またはリンクレイヤに表示されていない場合に最適ではないが、それは潜在的な緩和が適用提供しました。
RECOMMENDATION: ACK Decimation uses standard router mechanisms at the upstream link interface to constrain the rate at which ACKs are fed to the upstream link. The technique is beneficial with paths having appreciable asymmetry (k>1). It is however suboptimal, in that it may lead to inefficient TCP error recovery (and hence in some cases degraded TCP performance), and provides only crude control of link behavior. It is therefore recommended that where possible, ACK Filtering should be used in preference to ACK Decimation.
推奨：ACKデシメーションはACKを上流リンクに供給される速度を制約するために上流のリンクインタフェースにおける標準ルータ・メカニズムを使用します。技術は、かなりの非対称性（K> 1）を有するパスと有益です。それは非効率的なTCPエラー回復につながる可能性があり、その中で（従って、いくつかの場合においてTCPの性能を低下）、しかし準最適であり、リンクの挙動のみ粗制御を提供します。したがって、可能な場合、ACKフィルタリングACKデシメーションに優先して使用されるべきであることが推奨されます。
When ACK Decimation is used on paths with an appreciable asymmetry (k>1) (or with bidirectional traffic) it increases the burst size of the TCP sender, use of a scheme to mitigate the effect of Stretch ACKs or control burstiness is therefore strongly recommended.
ACKデシメーションは、それがTCP送信者のバーストサイズを増加させるかなりの非対称性（K> 1）（または双方向トラフィックを有する）との経路上で使用される場合、ストレッチのACK又は制御バーストの影響を軽減するためのスキームを使用することは、従って、強く推奨されます。
TYPE 2 mitigations perform TYPE 1 upstream link bandwidth management, but also employ a second active element which mitigates the effect of the reduced ACK rate and burstiness of ACK transmission. This is desirable when end hosts use standard TCP sender implementations (e.g., those not implementing the techniques in sections 4.6, 4.7).
TYPE 2緩和策は、タイプ1の上流リンク帯域幅管理を行うだけでなく、ACK伝送の減少ACKレートとバーストの影響を緩和する第二の能動素子を用います。エンドホスト（例えば、それらは、セクション4.6、4.7における技術を実装していない）標準のTCPセンダの実装を使用する場合、これが望ましいです。
Consider a path where a TYPE 1 scheme forwards a Stretch ACK covering d TCP packets (i.e., where the acknowledgement number is d*MSS larger than the last ACK received by the TCP sender). When the TCP sender receives this ACK, it can send a burst of d (or d+1) TCP data packets. The sender is also constrained by the current cwnd. Received ACKs also serve to increase cwnd (by at most one MSS).
（TCP送信者が受信した最後のACKより大きい確認応答番号がDであり、すなわち、* MSS）TYPE 1スキームがD TCPパケットをカバーストレッチACKを転送するパスを考えます。 TCP送信者は、このACKを受信すると、D（またはd + 1）TCPデータパケットのバーストを送信することができます。送信者は、また、現在のcwndによって制約されます。受信したACKがまた（最大1つのMSSによって）にcwndを増やすのに役立ちます。
A TYPE 2 scheme mitigates the impact of the reduced ACK frequency resulting when a TYPE 1 scheme is used. This is achieved by interspersing additional ACKs before each received Stretch ACK. The additional ACKs, together with the original ACK, provide the TCP sender with sufficient ACKs to allow the TCP cwnd to open in the same way as if each of the original ACKs sent by the TCP receiver had been forwarded by the reverse path. In addition, by attempting to restore the spacing between ACKs, such a scheme can also restore the TCP self-clocking behavior, and reduce the TCP sender burst size. Such schemes need to ensure conservative behavior (i.e., should not introduce more ACKs than were originally sent) and reduce the probability of ACK Compression [ZSC91].
TYPE 2方式は、タイプ1の方式を使用した場合、得られた減少ACK周波数の影響を軽減します。これは、各受信ストレッチACKの前に、追加のACKを点在することにより達成されます。追加のACKは、共に元のACKと、TCP受信機によって送信された元のACKの各々は、逆の経路によって転送されたかのようにTCPのCWNDが同じように開くことができるように、十分なACKを用いてTCPセンダを提供します。また、ACKの間の間隔を復元しようとすることで、そのような方式は、TCPのセルフクロッキングの動作を復元し、TCPの送信者のバーストサイズを小さくすることができます。そのようなスキームは、保守的な動作を保証（すなわち、最初に送信されたよりも多くのACKを導入してはならない）とACK圧縮[ZSC91]の確率を低減する必要があります。
The action is performed at two points on the return path: the upstream link interface (where excess ACKs are removed), and a point further along the reverse path (after the bottleneck upstream link(s)), where replacement ACKs are inserted. This attempts to reconstruct the ACK stream sent by the TCP receiver when used in combination with AF (section 5.2.1), or ACK Decimation (section 5.2.2).
アクションは、戻り経路上の2点で行われる：（過剰ACKが除去される）アップストリームリンクインターフェイス、さらに逆経路に沿って交換のACKが挿入され、（ボトルネック上流のリンク（複数可）の後）ポイント。これは、AF（セクション5.2.1）、またはACKデシメーション（セクション5.2.2）と組み合わせて使用される場合、TCP受信機によって送信されたACKストリームを再構築しようとします。
TYPE 2 mitigations may be performed locally at the receive interface directly following the upstream bottleneck link, or may alternatively be applied at any point further along the reverse path (this is not necessarily on the forward path, since asymmetric routing may employ different forward and reverse internet paths). Since the techniques may generate multiple ACKs upon reception of each individual Stretch ACK, it is strongly recommended that the expander implements a scheme to prevent exploitation as a "packet amplifier" in a Denial-of-Service (DoS) attack (e.g., to verify the originator of the ACK). Identification of the sender could be accomplished by appropriately configured packet filters and/or by tunnel authentication procedures (e.g., [RFC2402, RFC2406]). A limit on the number of reconstructed ACKs that may be generated from a single packet may also be desirable.
TYPE 2緩和策は、非対称ルーティングが前方に異なる使用し、逆かもしれないので、これは、フォワードパス上にある必要はない（直接上流のボトルネックリンクを以下受け取るインタフェースでローカルに実行されてもよい、あるいはさらに逆の経路に沿った任意の点に適用することができますインターネットパス）。技術は、個々のストレッチACKを受信すると、複数のACKを生成することができるので、それは強くパンダはサービス拒否（DoS）攻撃の「パケット増幅器」として悪用を防止するためのスキームを実装することが推奨される（例えば、検証しますACKの創始者）。送信者の識別は、適切に構成されたパケットフィルタによって及び/又はトンネル認証手順によって達成することができる（例えば、[RFC2402、RFC2406]）。単一パケットから生成され得る再構成ACKの数の制限もまた望ましいかもしれません。
ACK Reconstruction (AR) [BPK99] is used in conjunction with AF (section 5.2.1). AR deploys a soft-state [Cla88] agent called an ACK Reconstructor on the reverse path following the upstream bottleneck link. The soft-state can be regenerated if lost, based on received ACKs. When a Stretch ACK is received, AR introduces additional ACKs by filling gaps in the ACK sequence. Some potential Denial-of-Service vulnerabilities may arise (section 6) and need to be addressed by appropriate security techniques.
ACK再構成（AR）[BPK99] AFに関連して使用される（セクション5.2.1）。 ARは、上流のボトルネックリンク次の逆の経路でACKリコンストラクタと呼ばれるソフトステート[Cla88]エージェントを展開します。失われた場合は、ソフト状態が受けたACKに基づいて、再生することができます。ストレッチACKが受信されると、ARは、ACKシーケンスのギャップを充填することによって、追加のACKを導入します。いくつかの潜在的なサービス拒否の脆弱性は、（セクション6）を発生し、適切なセキュリティ技術によって対処する必要があるかもしれません。
The Reconstructor determines the number of additional ACKs, by estimating the number of filtered ACKs. This uses implicit information present in the received ACK stream by observing the ACK sequence number of each received ACK. An example implementation could set an ACK threshold, ackthresh, to twice the MSS (this assumes the chosen MSS is known by the link). The factor of two corresponds to standard TCP delayed-ACK policy (d=2). Thus, if successive ACKs arrive separated by delta, the Reconstructor regenerates a maximum of ((delta/ackthresh) - 2) ACKs.
リコンストラクタを濾過ACKの数を推定することによって、追加のACKの数を決定します。これは、それぞれのACKシーケンス番号がACKを受信し観察することによって受信されたACK流中に存在する暗黙の情報を使用します。実装例では、ACK閾値、ackthreshを設定することができへ倍MSS（これは選択したMSSは、リンクによって知られている前提）。標準のTCP遅延ACKポリシー（D = 2）には、2つの対応の因子。 ACK - 連続ACKがデルタで区切られた到着する場合したがって、リコンストラクタ（2（デルタ/ ackthresh））の最大値を再生します。
To reduce the TCP sender burst size and allow the cwnd to increase at a rate governed by the downstream link, the reconstructed ACKs must be sent at a consistent rate (i.e., temporal spacing between reconstructed ACKs). One method is for the Reconstructor to measure the arrival rate of ACKs using an exponentially weighted moving average estimator. This rate depends on the output rate from the upstream link and on the presence of other traffic sharing the link. The output of the estimator indicates the average temporal spacing for the ACKs (and the average rate at which ACKs would reach the TCP sender if there were no further losses or delays). This may be used by the Reconstructor to set the temporal spacing of reconstructed ACKs. The scheme may also be used in combination with TCP sender adaptation (e.g., a combination of the techniques in sections 4.6 and 4.7).
TCP送信バーストサイズを小さくし、CWNDが、下流リンクによって支配率で増加することを可能にするために、再構成されたACKは一致率（再構成されたACKの間、すなわち、時間間隔）で送信されなければなりません。リコンストラクタが指数関数的加重移動平均推定器を使用してACKの到着率を測定するための一つの方法です。この速度は、上流のリンクからの出力レートにしてリンクを共有する他のトラフィックの存在に依存します。推定器の出力は、ACKのための平均時間間隔（及びさらなる損失や遅延が存在しない場合にACKがTCP送信者に到達することになるでの平均速度）を示しています。これは、再構成されたACKの時間間隔を設定するリコンストラクタによって使用されてもよいです。方式は、TCP送信者適応（例えば、セクション4.6および4.7での技術の組み合わせ）と組み合わせて使用することができます。
The trade-off in AR is between obtaining less TCP sender burstiness, and a better rate of cwnd increase, with a reduction in RTT variation, versus a modest increase in the path RTT. The technique cannot perform reconstruction on connections using IPSec (AH [RFC2402] or ESP [RFC2406]), since it is unable to generate appropriate security information. It also cannot regenerate other packet header information (e.g., the exact pattern of bits carried in the IP packet ECN field [RFC3168] or the TCP RTTM option [RFC1323]).
ARでのトレードオフは、パスRTTで適度な増加に対して、RTTの変動の減少と、より少ないTCP送信者バースト性、およびcwndの増加のよりよい率を求めるとの間にあります。適切なセキュリティ情報を生成することができないための技術は、IPSecの（AH [RFC2402]またはESP [RFC2406]）を使用して接続で再構成を行うことができません。それはまた、他のパケットヘッダ情報を再生することができない（例えば、IPパケットのECNフィールド[RFC3168]またはTCP RTTMオプション[RFC1323]で運ばビットの正確なパターン）。
An ACK Reconstructor operates correctly (i.e., generates no spurious ACKs and preserves the end-to-end semantics of TCP), providing:
ACKリコンストラクタを提供する（すなわち、スプリアスACKを生成せず、TCPのエンドツーエンドのセマンティクスを維持）が正しく動作します。
(i) the TCP receiver uses ACK Delay (d=2) [RFC2581] (ii) the Reconstructor receives only in-order ACKs (iii) all ACKs are routed via the Reconstructor (iv) the Reconstructor correctly determines the TCP MSS used by the session (v) the packets do not carry additional header information (e.g., TCP RTTM option [RFC1323], IPSec using AH [RFC2402]or ESP [RFC2406]).
（I）TCP受信機がACK遅延（D = 2）を使用して、[RFC2581]（ii）のリコンストラクタのみで次のACKを受信すると（iii）の全てのACKがリコンストラクタを介してルーティングされる（iv）のリコンストラクタが正常で使用されるTCP MSSを決定しますセッション（v）は、パケットが（AH [RFC2402]またはESP [RFC2406]を使用するなど、TCP RTTMオプション[RFC1323]、IPSec）の追加のヘッダ情報を運びません。
RECOMMENDATION: ACK Reconstruction is an experimental transparent modification performed on the reverse path following the upstream bottleneck link. It is designed to be used in conjunction with a TYPE 1 mitigation. It reduces the burst size of TCP transmission in the forward direction, which may otherwise increase when TYPE 1 schemes are used alone. It requires modification of equipment after the upstream link (including maintaining per-flow soft state). The scheme introduces implicit assumptions about the network path and has potential Denial-of-Service vulnerabilities (i.e., acting as a packet amplifier); these need to be better understood and addressed by appropriate security techniques.
推奨：ACK再構成は、上流のボトルネックリンク次の逆の経路上で行わ実験透明変形例です。 TYPE 1緩和と組み合わせて使用するように設計されています。これは、タイプ1の方式を単独で使用する場合、さもなければ増大させることができる順方向のTCP伝送のバーストサイズを減少させます。これは、（パーフロー柔らかい状態を維持することを含む）上流のリンクの後に機器の変更を必要とします。スキームは、ネットワークパスに関する暗黙の仮定を導入し、潜在的なサービス拒否の脆弱性を有している（すなわち、パケットアンプとして作用します）。これらは、よりよく理解し、適切なセキュリティ技術によって対処する必要があります。
Selection of appropriate algorithms to pace the ACK traffic remains an open research issue. There is also currently little experience of the implications of using such techniques in the Internet, and therefore it is recommended that this technique should not be used within the Internet in its current form.
ACKトラフィックをペーシングする適切なアルゴリズムの選択は、オープンな研究課題のまま。そこインターネットでこのような技術を使用した場合の影響の現在少し経験もあり、そのためには、この技術は現在の形でインターネットの中で使用すべきではないことをお勧めします。
ACK Compaction and ACK Companding [SAM99, FSS01] are techniques that operate at a point on the reverse path following the constrained ACK bottleneck. Like AR (section 5.3.1), ACK Compaction and ACK Companding are both used in conjunction with an AF technique (section 5.2.1) and regenerate filtered ACKs, restoring the ACK stream. However, they differ from AR in that they use a modified AF (known as a compactor or compressor), in which explicit information is added to all Stretch ACKs generated by the AF. This is used to explicitly synchronize the reconstruction operation (referred to here as expansion).
ACK圧縮及びACK圧伸[SAM99、FSS01]は制約ACKボトルネック以下の逆の経路上の点で動作する技術です。 AR（セクション5.3.1）、ACK圧縮及びACK圧伸ように、両方のAF技術（セクション5.2.1）と組み合わせて使用し、ACKストリームを復元し、濾過ACKを再生しています。しかし、彼らは、明示的な情報は、AFにより生成されたすべてのストレッチのACKに付加されている（コンパクタ又は圧縮機としても知られる）修飾AFを使用することでAR異なります。これは、明示的に（拡張としてここで呼ばれる）再構成動作を同期させるために使用されます。
The modified AF combines two modifications: First, when the compressor deletes an ACK from the upstream bottleneck link queue, it appends explicit information (a prefix) to the remaining ACK (this ACK is marked to ensure it is not subsequently deleted). The additional information contains details the conditions under which ACKs were previously filtered. A variety of information may be encoded in the prefix. This includes the number of ACKs deleted by the AF and the average number of bytes acknowledged. This may subsequently be used by an expander at the remote end of the tunnel. Further timing information may also be added to control the pacing of the regenerated ACKs [FSS01]. The temporal spacing of the filtered ACKs may also be encoded.
修飾されたAFは、2つの修飾を組み合わせ：コンプレッサー上流のボトルネックリンクキューからACKを削除した場合にまず、それは残りのACK（このACKは、それがその後削除されていないことを確認するためにマークされている）への明示的な情報（接頭辞）を付加します。追加情報は、詳細ACKが以前に濾過した条件が含まれています。様々な情報は、プレフィックスで符号化されてもよいです。これは、AFとバイトの平均数が認めによって削除ACKの数を含みます。これは、続いて、トンネルのリモートエンドに膨張して使用してもよいです。さらに、タイミング情報は、再生されたACK [FSS01]のペーシングを制御するために添加されてもよいです。濾過ACKの時間間隔はまた、符号化されてもよいです。
To encode the prefix requires the subsequent expander to recognize a modified ACK header. This would normally limit the expander to link-local operation (at the receive interface of the upstream bottleneck link). If remote expansion is needed further along the reverse path, a tunnel may be used to pass the modified ACKs to the remote expander. The tunnel introduces extra overhead, however networks with asymmetric capacity and symmetric routing frequently already employ such tunnels (e.g., in a UDLR network [RFC3077], the expander may be co-located with the feed router).
接頭語を符号化するためには変性ACKヘッダを認識するように、後続の膨張を必要とします。これは通常、（上流のボトルネックリンクの受信インタフェースで）リンクローカル操作に膨張を制限します。遠隔拡張は逆の経路に沿って、さらに必要な場合、トンネルは、リモート・エキスパンダに変更ACKを渡すために使用されてもよいです。トンネルは、余分なオーバーヘッドを導入し、しかし非対称容量および対称ルーティングとネットワークが頻繁に既に（例えば、UDLRネットワーク[RFC3077]に、エキスパンダは、供給ルータと同じ場所に配置されてもよい）、そのようなトンネルを使用します。
ACK expansion uses a stateless algorithm to expand the ACK (i.e., each received packet is processed independently of previously received packets). It uses the prefix information together with the acknowledgment field in the received ACK, to produce an equivalent number of ACKs to those previously deleted by the compactor. These ACKs are forwarded to the original destination (i.e., the TCP sender), preserving normal TCP ACK clocking. In this way, ACK Compaction, unlike AR, is not reliant on specific ACK policies, nor must it see all ACKs associated with the reverse path (e.g., it may be compatible with schemes such as DAASS [RFC2760]).
ACK膨張がACKを拡張するステートレスアルゴリズムを使用して（すなわち、各受信パケットが以前に受信したパケットとは独立に処理されます）。これは、以前にコンパクタによって削除されるものとACKの等価な数を生成するために、受信したACKに肯定応答フィールドと共にプレフィックス情報を使用します。これらのACKは、正常なTCP ACKクロッキングを維持し、元の宛先（すなわち、TCP送信者）に転送されます。このように、ACK圧縮は、ARとは異なり、特定のACKポリシーに依存しない、またそれは、逆の経路に関連付けられたすべてのACKを見なければならない（例えば、そのようなDAASSよう方式と互換性がある[RFC2760]）。
Some potential Denial-of-Service vulnerabilities may arise (section 6) and need to be addressed by appropriate security techniques. The technique cannot perform reconstruction on connections using IPSec, since they are unable to regenerate appropriate security information. It is possible to explicitly encode IPSec security information from suppressed packets, allowing operation with IPSec AH, however this remains an open research issue, and implies an additional overhead per ACK.
いくつかの潜在的なサービス拒否の脆弱性は、（セクション6）を発生し、適切なセキュリティ技術によって対処する必要があるかもしれません。彼らは、適切なセキュリティ情報を再生成することができないので、この技術は、IPSecを使用して接続で再構築を実行することはできません。しかし、これは、オープンな研究課題のままで、ACKごとに追加のオーバーヘッドを意味し、明示的にIPSecのAHで動作が可能、抑制したパケットからのIPSecのセキュリティ情報を符号化することが可能です。
RECOMMENDATION: ACK Compaction and Companding are experimental transparent modifications performed on the reverse path following the upstream bottleneck link. They are designed to be used in conjunction with a modified TYPE 1 mitigation and reduce the burst size of TCP transmission in the forward direction, which may otherwise increase when TYPE 1 schemes are used alone.
推奨：ACK圧縮及び圧伸上流のボトルネックリンク次の逆の経路上で行わ実験透明変形あります。彼らは、タイプ1の方式を単独で使用する場合、さもなければ増大させることができる、変性タイプ1緩和と組み合わせて使用するように設計され、順方向のTCP伝送のバーストサイズを小さくしています。
The technique is desirable, but requires modification of equipment after the upstream bottleneck link (including processing of a modified ACK header). Selection of appropriate algorithms to pace the ACK traffic also remains an open research issue. Some potential Denial-of-Service vulnerabilities may arise with any device that may act as a packet amplifier. These need to be addressed by appropriate security techniques. There is little experience of using the scheme over Internet paths. This scheme is a subject of ongoing research and is not recommended for use within the Internet in its current form.
技術が望ましいが、（修飾されたACKヘッダの処理を含む）上流のボトルネックリンクの後に機器の変更を必要とします。 ACKトラフィックをペーシングする適切なアルゴリズムの選択はまた、オープンな研究課題のまま。いくつかの潜在的なサービス拒否の脆弱性は、パケットアンプとして動作することができる任意のデバイスで発生する可能性があります。これらは、適切なセキュリティ技術によって対処する必要があります。インターネットの経路上のスキームを使用しての少し経験があります。この方式は、現在進行中の研究の対象であり、その現在のフォームでインターネットの中の使用は推奨されません。
The bursts of data packets generated when a Type 1 scheme is used on the reverse direction path may be mitigated by introducing a router supporting Generic Traffic Shaping (GTS) on the forward path [Seg00]. GTS is a standard router mechanism implemented in many deployed routers. This technique does not eliminate the bursts of data generated by the TCP sender, but attempts to smooth out the bursts by employing scheduling and queuing techniques, producing traffic which resembles that when TCP Pacing is used (section 4.6). These
タイプ1の方式は、逆方向経路上で使用されたときに生成されたデータパケットのバーストは往路[SEG00]にジェネリックトラフィックシェーピング（GTS）をサポートするルータを導入することによって軽減することができます。 GTSは多くの展開ルータに実装され、標準のルータメカニズムです。この技術は、TCP送信者によって生成されたデータのバーストを排除するが、スケジューリングを採用し、技術をキューイング、TCPペーシングが（セクション4.6）を使用する場合に似ているトラフィックを生成することによって、バーストを平滑化しようとしません。これら
techniques require maintaining per-flow soft-state in the router, and increase per-packet processing overhead. Some additional buffer capacity is needed to queue packets being shaped.
技術は、ルータにフロー毎のソフト状態を維持し、パケットごとの処理のオーバーヘッドを増加させる必要。いくつかの追加のバッファ容量は、成形されるパケットをキューイングするために必要とされます。
To perform GTS, the router needs to select appropriate traffic shaping parameters, which require knowledge of the network policy, connection behavior and/or downstream bottleneck characteristics. GTS may also be used to enforce other network policies and promote fairness between competing TCP connections (and also UDP and multicast flows). It also reduces the probability of ACK Compression [ZSC91].
GTSを実行するには、ルータは、ネットワークポリシー、接続動作および/または下流のボトルネックの特性についての知識を必要とする適切なトラフィックシェーピングパラメータを、選択する必要があります。 GTSは、他のネットワークポリシーを適用し、競合するTCPコネクション（ともUDPおよびマルチキャストフロー）間の公平性を促進するために使用することができます。また、[ZSC91] ACK圧縮の可能性を低減します。
The smoothing of packet bursts reduces the impact of the TCP transmission bursts on routers and hosts following the point at which GTS is performed. It is therefore desirable to perform GTS near to the sending host, or at least at a point before the first forward path bottleneck router.
パケットバーストの平滑化は、GTSが実行される点を次のルータとホストのTCP送信バーストの影響を低減します。最初の往路ボトルネックルータの前に、送信側ホストに近い、あるいは少なくとも時点でGTSを実行することが望ましいです。
RECOMMENDATIONS: Generic Traffic Shaping (GTS) is a transparent technique employed at a router on the forward path. The algorithms to implement GTS are available in widely deployed routers and may be used on an Internet link, but do imply significant additional per-packet processing cost.
提言：ジェネリックトラフィックシェーピング（GTS）は、フォワードパス上のルータで使用される透明な技術です。 GTSを実装するためのアルゴリズムが広く採用されているルータで提供され、インターネットリンク上で使用することができるが、重要な追加、パケットあたりの処理コストを意味するものではありません。
Configuration of a GTS is a policy decision of a network service provider. When appropriately configured the technique will reduce size of TCP data packet bursts, mitigating the effects of Type 1 techniques. GTS is recommended for use in the Internet in conjunction with type 1 techniques such as ACK Filtering (section 5.2.1) and ACK Decimation (section 5.2.2).
GTSの設定は、ネットワークサービスプロバイダの政策決定です。適切に構成されたとき技術は、タイプ1の技術の影響を緩和、TCPデータパケットバーストの大きさを減少させます。 GTSは、ACKフィルタリング（セクション5.2.1）とACKデシメーション（セクション5.2.2）のようなタイプ1の技術と組み合わせて、インターネットでの使用のために推奨されます。
Many of the above schemes imply using per flow queues (or per connection queues in the case of TCP) at the upstream bottleneck link. Per-flow queuing (e.g., FQ, CBQ) offers benefit when used on any slow link (where the time to transmit a packet forms an appreciable part of the path RTT) [RFC3150]. Type 3 schemes offer additional benefit when used with one of the above techniques.
上記のスキームの多くは、上流のボトルネックリンクにフローキュー（またはTCPの場合の接続キューあたり）あたり使用を意味します。 [RFC3150]（パケットを送信するための時間は、経路RTTのかなりの部分を形成する）、任意の低速リンク上で使用される場合、フロー毎のキューイング（例えば、FQ、CBQ）は利点を提供します。上記の技術の一つで使用する場合、タイプ3のスキームは、付加的な利点を提供します。
When bidirectional traffic exists in a bandwidth asymmetric network competing ACK and packet data flows along the return path may degrade the performance of both upstream and downstream flows [KVR98]. Therefore, it is highly desirable to use a queuing strategy combined with a scheduling mechanism at the upstream link. This has also been called priority-based multiplexing [RFC3135].
双方向トラフィックがACKとパケットデータを競合帯域幅非対称ネットワークに存在する場合、両方の上流及び下流に流れる[KVR98]の性能を低下させることができる戻り経路に沿って流れます。したがって、上流リンクにおけるスケジューリング機構と組み合わさキューイング戦略を使用することが非常に望ましいです。これはまた、優先順位ベースの多重化[RFC3135]と呼ばれてきました。
On a slow upstream link, appreciable jitter may be introduced by sending large data packets ahead of ACKs [RFC3150]. A simple scheme may be implemented using per-flow queuing with a fair scheduler (e.g., round robin service to all flows, or priority scheduling). A modified scheduler [KVR98] could place a limit on the number of ACKs a host is allowed to transmit upstream before transmitting a data packet (assuming at least one data packet is waiting in the upstream link queue). This guarantees at least a certain minimum share of the capacity to flows in the reverse direction, while enabling flows in the forward direction to improve TCP throughput.
スローアップストリームリンク上で、かなりのジッタが前方のACK [RFC3150]の大きなデータパケットを送信することによって導入することができます。簡単な方式は公平スケジューラ（例えば、ラウンド全てのフローに対してロビンサービス、または優先スケジューリング）とキューイングごとフロー使用して実施することができます。修飾されたスケジューラは、[KVR98】ホストがデータパケット（少なくとも1つのデータパケットが上流のリンクキューに待機していると仮定）を送信する前に、アップストリーム送信を許可されたACKの数に制限を置くことができます。 TCPのスループットを向上させる順方向に流れを可能にしながら、これは、逆方向に流れるの容量の少なくとも特定の最小シェアを保証します。
Bulk (payload) compression, a small MTU, link level transparent fragmentation [RFC1991, RFC2686] or link level suspend/resume capability (where higher priority frames may pre-empt transmission of lower priority frames) may be used to mitigate the impact (jitter) of bidirectional traffic on low speed links [RFC3150]. More advanced schemes (e.g., WFQ) may also be used to improve the performance of transfers with multiple ACK streams such as http [Seg00].
バルク（ペイロード）圧縮、小さなMTU、リンクレベル透明フラグメンテーション[RFC1991、RFC2686]またはリンクレベルサスペンド/レジューム機能は、（ここで、優先度の高いフレームは予め優先使用できる優先度の低いフレームの送信）の影響を軽減するために使用することができる（ジッター）低速リンク[RFC3150]上の双方向トラフィックの。より高度なスキーム（例えば、WFQ）また、HTTP [SEG00]などの複数のACKストリームと転送の性能を向上させるために使用されてもよいです。
RECOMMENDATION: Per-flow queuing is a transparent modification performed at the upstream bottleneck link. Per-flow (or per-class) scheduling does not impact the congestion behavior of the Internet, and may be used on any Internet link. The scheme has particular benefits for slow links. It is widely implemented and widely deployed on links operating at less than 2 Mbps. This is recommended as a mitigation on its own or in combination with one of the other described techniques.
推奨：フローごとのキューイングは、上流のボトルネックリンクで行わ透明変形例です。パー・フロー（またはクラスごとの）スケジューリングは、インターネットの混雑の挙動に影響を与えていない、と任意のインターネットリンク上で使用することができます。スキームは、低速リンクのための特定の利点があります。これは、広く実装され、広く未満2 Mbpsで動作するリンク上に配置されています。これは、それ自体でまたは他の記載された技術のいずれかとの組み合わせで緩和として推奨されています。
ACKs-first Scheduling is an experimental technique to improve performance of bidirectional transfers. In this case data packets and ACKs compete for resources at the upstream bottleneck link [RFC3150]. A single First-In First-Out, FIFO, queue for both data packets and ACKs could impact the performance of forward transfers. For example, if the upstream bottleneck link is a 28.8 kbps dialup line, the transmission of a 1 Kbyte sized data packet would take about 280 ms. So even if just two such data packets get queued ahead of ACKs (not an uncommon occurrence since data packets are sent out in pairs during slow start), they would shut out ACKs for well over half a second. If more than two data packets are queued up ahead of an ACK, the ACKs would be delayed by even more [RFC3150].
ACKを、最初のスケジューリングは、双方向転送の性能を向上するための実験技術です。この場合、データパケットとACKが上流のボトルネックリンク[RFC3150]でリソースの競合します。単一のファーストイン・ファーストアウト、FIFOは、データパケットとACKの両方のための待ち行列は、順方向転送の性能に影響を与える可能性があります。上流のボトルネックリンクが28.8 Kbpsのダイヤルアップ回線である場合、例えば、1Kバイトサイズのデータパケットの送信は、約280ミリ秒かかります。 （データパケットはスロースタート時にペアで送信されますので、珍しくない発生）ちょうど2つのそのようなデータパケットが先にACKのキューに入れられる場合でもだから、彼らはよく半分秒以上ACKをシャットアウトします。二つ以上のデータパケットが先にACKの最大キューイングされている場合は、ACKはさらに、[RFC3150]によって遅延されるだろう。
A possible approach to alleviating this is to schedule data and ACKs differently from FIFO. One algorithm, in particular, is ACKs-first scheduling, which accords a higher priority to ACKs over data packets. The motivation for such scheduling is that it minimizes the idle time for the forward connection by minimizing the time that ACKs spend queued behind data packets at the upstream link. At the same time, with Type 0 techniques such as header compression [RFC1144], the transmission time of ACKs becomes small enough that the impact on subsequent data packets is minimal. (Subnetworks in which the per-packet overhead of the upstream link is large, e.g., packet radio subnetworks, are an exception, section 3.2.) This scheduling scheme does not require the upstream bottleneck router/host to explicitly identify or maintain state for individual TCP connections.
これを軽減する可能性のあるアプローチが異なりFIFOからのデータとACKをスケジュールすることです。一つのアルゴリズムは、特に、データパケット上のACKに高い優先度を応じたACKを、最初のスケジューリングです。このようなスケジューリングのための動機は、それはACKが、上流のリンクでのデータパケットの後ろにキューイングされ費やす時間を最小にすることにより、前方接続のアイドル時間を最小限に抑えることです。同時に、そのようなヘッダ圧縮[RFC1144]としてタイプ0技術と、ACKの送信時間は、後続のデータパケットへの影響が最小限であることが十分に小さくなる。 （アップストリームリンクのパケットごとのオーバーヘッドが大きい、例えば、パケット無線サブネットワークであるサブネットワークは、例外、セクション3.2です。）このスケジューリング方式は、明示的に特定または個々の状態を維持するために、上流のボトルネックルータ/ホストを必要としません。 TCP接続。
ACKs-first scheduling does not help avoid a delay due to a data packet in transmission. Link fragmentation or suspend/resume may be beneficial in this case.
ACK-最初のスケジューリングは、送信中のデータパケットによる遅延を避ける助けにはなりません。リンクフラグメンテーションまたはサスペンド/レジュームは、この場合に有益であり得ます。
RECOMMENDATION: ACKs-first scheduling is an experimental transparent modification performed at the upstream bottleneck link. If it is used without a mechanism (such as ACK Congestion Control (ACC), section 4.3) to regulate the volume of ACKs, it could lead to starvation of data packets. This is a performance penalty experienced by end hosts using the link and does not modify Internet congestion behavior. Experiments indicate that ACKs-first scheduling in combination with ACC is promising. However, there is little experience of using the technique in the wider Internet. Further development of the technique remains an open research issue, and therefore the scheme is not currently recommended for use within the Internet.
推奨：ACKの-最初のスケジューリングは、上流のボトルネックリンクで行われた実験透明変形例です。それはACKの音量を調節する（例えば、ACK輻輳制御（ACC）として、セクション4.3）機構なしで使用される場合、それはデータ・パケットの飢餓につながる可能性があります。これは、リンクを使用して、エンドホストが経験するパフォーマンスペナルティで、インターネットの混雑の動作を変更しません。実験は、ACCとの組み合わせでのACK-最初のスケジューリングが有望であることを示しています。しかし、より広いインターネットでの技術を使用しての少し経験があります。技術のさらなる開発は、オープンな研究課題のまま、そのためのスキームは、現在、インターネット内での使用は推奨されません。
The recommendations contained in this document do not impact the integrity of TCP, introduce new security implications to the TCP protocol, or applications using TCP.
この文書に含まれる勧告は、TCPの整合性に影響を与えるTCPを使用して、新しいセキュリティTCPプロトコルへの影響、またはアプリケーションを導入していません。
Some security considerations in the context of this document arise from the implications of using IPSec by the end hosts or routers operating along the return path. Use of IPSec prevents, or complicates, some of the mitigations. For example:
この文書の文脈でいくつかのセキュリティ上の考慮事項は、リターンパスに沿って操作し、エンドホストまたはルータでIPSecを使用した場合の影響から生じます。 IPSecの使用は妨げ、または、緩和策の一部を複雑にします。例えば：
(i) When IPSec ESP [RFC2406] is used to encrypt the IP payload, the TCP header can neither be read nor modified by intermediate entities. This rules out header compression, ACK Filtering, ACK Reconstruction, and the ACK Compaction.
IPSecのESP [RFC2406]はIPペイロードを暗号化するために使用されている（i）は、TCPヘッダを読み取ることも、中間エンティティによって修飾することができるどちら。これは、ヘッダ圧縮、ACKフィルタリング、ACK再構成、及びACK圧縮を除外する。
(ii) The TCP header information may be visible, when some forms of network layer security are used. For example, using IPSec AH [RFC2402], the TCP header may be read, but not modified, by intermediaries. This may in future allow extensions to support ACK Filtering, but rules out the generation of new packets by intermediaries (e.g., ACK Reconstruction). The enhanced header compression scheme discussed in [RFC2507] would also work with IPSec AH.
（ii）のTCPヘッダ情報は、ネットワーク層のセキュリティのいくつかの形態が使用される場合、可視であってもよいです。例えば、IPSecのAH [RFC2402]を使用して、TCPヘッダを読み取ることができるが、仲介することによって、変更されません。これは、将来の機能拡張は、ACKフィルタリングをサポートすることができますが、仲介者（例えば、ACK再建）して、新しいパケットの生成を除外します。 [RFC2507]で説明した拡張ヘッダ圧縮方式は、IPSecのAHで動作します。
There are potential Denial-of-Service (DoS) implications when using Type 2 schemes. Unless additional security mechanisms are used, a Reconstructor/expander could be exploited as a packet amplifier. A third party may inject unauthorized Stretch ACKs into the reverse path, triggering the generation of additional ACKs. These ACKs would consume capacity on the return path and processing resources at the systems along the path, including the destination host. This provides a potential platform for a DoS attack. The usual precautions must be taken to verify the correct tunnel end point, and to ensure that applications cannot falsely inject packets that expand to generate unwanted traffic. Imposing a rate limit and bound on the delayed ACK factor(d) would also lessen the impact of any undetected exploitation.
タイプ2のスキームを使用した場合の潜在的サービス拒否（DoS）の意味合いがあります。追加のセキュリティ・メカニズムが使用されていない限り、リコンストラクタ/エキスパンダーは、パケットアンプとして悪用される可能性があります。サードパーティは、追加のACKの生成をトリガする、逆の経路に不正ストレッチACKを噴射することができます。これらのACKは、宛先ホストを含むパスに沿ったシステム、でリターンパスおよび処理リソースの容量を消費することになります。これは、DoS攻撃の潜在的なプラットフォームを提供します。通常の注意が正しいトンネルエンドポイントを確認するために、アプリケーションが誤って不要なトラフィックを生成するために、拡張パケットを注入することができないことを保証するために注意しなければなりません。遅延ACK因子（D）のレート制限および結合を課すことも、任意の未検出の開発の影響を軽減するであろう。
This document considers several TCP performance constraints that arise from asymmetry in the properties of the forward and reverse paths across an IP network. Such performance constraints arise, e.g., as a result of both bandwidth (capacity) asymmetry, asymmetric shared media in the reverse direction, and interactions with Media Access Control (MAC) protocols. Asymmetric capacity may cause TCP Acknowledgments (ACKs) to be lost or become inordinately delayed (e.g., when a bottleneck link is shared between many flows, or when there is bidirectional traffic). This effect may be exacerbated with media-access delays (e.g., in certain multi-hop radio subnetworks, satellite Bandwidth on Demand access). Asymmetry, and particular high asymmetry, raises a set of TCP performance issues.
この文書では、前方のプロパティで非対称性に起因するいくつかのTCP性能の制約を考慮し、IPネットワークを介してパスを逆転します。このような性能上の制約は、帯域幅（容量）非対称、逆方向に非対称な共有メディア、およびメディアアクセス制御（MAC）プロトコルとの相互作用の両方の結果として、例えば、生じます。非対称容量が過度に遅れて失われたかになることがTCP謝辞（のACK）が発生することがあり（例えば、ボトルネックリンクが多く流れの間で共有されている場合、または双方向のトラフィックがある場合）。この効果は、媒体アクセス遅延で悪化することもできる（例えば、特定のマルチホップ無線サブネットワーク、オンデマンドアクセスに衛星帯域幅）。非対称、および特定の高非対称性は、TCPのパフォーマンスの問題のセットを発生させます。
A set of techniques providing performance improvement is surveyed. These include techniques to alleviate ACK Congestion and techniques that enable a TCP sender to cope with infrequent ACKs without destroying TCP self-clocking. These techniques include both end-to-end, local link-layer, and subnetwork schemes. Many of these techniques have been evaluated in detail via analysis, simulation, and/or implementation on asymmetric subnetworks forming part of the Internet. There is however as yet insufficient operational experience for some techniques, and these therefore currently remain items of on-going research and experimentation.
性能改善を提供する技術のセットが調査されています。これらは、ACK渋滞やTCPのセルフクロッキングを破壊することなく不定期のACKに対処するためにTCPの送信者を可能にする技術を軽減するための技術を含みます。これらの技術は、エンドツーエンドエンド、ローカルリンク層、及びサブスキームの両方を含みます。これらの技術の多くは、インターネットの一部を形成する非対称サブネットワーク上の解析、シミュレーション、および/または実装を経由して詳細に評価されています。そこにいくつかの技術のための十分な運用経験はまだしかしあり、そしてこれらは、したがって、現在、進行中の研究と実験の項目を残ります。
The following table summarizes the current recommendations. Mechanisms are classified as recommended (REC), not recommended (NOT REC) or experimental (EXP). Experimental techniques may not be well specified. These techniques will require further operational experience before they can be recommended for use in the public Internet.
次の表は、現在の提言をまとめました。 （NOT REC）を推奨または実験（EXP）、（REC）は推奨されているようにメカニズムが分類されています。実験技術は、指定されない場合があります。彼らは公共のインターネットでの使用を推奨することができます前に、これらの技術は、さらに運用経験が必要になります。
The recommendations for end-to-end host modifications are summarized in table 1. This lists each technique, the section in which each technique is discussed, and where it is applied (S denotes the host sending TCP data packets in the forward direction, R denotes the host which receives these data packets).
エンドツーエンドのホスト変更がこれは各技術、各技術が議論されている部分を示しています表1に要約され、そしてそれが適用されるための推奨（SはR、順方向にTCPデータパケットを送信するホストを表しますこれらのデータパケット）を受信するホストを示しています。
+------------------------+-------------+------------+--------+
| Technique | Use | Section | Where |
+------------------------+-------------+------------+--------+
| Modified Delayed ACKs | NOT REC | 4.1 | TCP R |
| Large MSS & NO FRAG | REC | 4.2 | TCP SR |
| Large MSS & IP FRAG | NOT REC | 4.2 | TCP SR |
| ACK Congestion Control | EXP | 4.3 | TCP SR |
| Window Pred. Mech (WPM)| NOT REC | 4.4 | TCP R |
| Window Cwnd. Est. (ACE)| NOT REC | 4.5 | TCP R |
| TCP Sender Pacing | EXP *1 | 4.6 | TCP S |
| Byte Counting | NOT REC *2 | 4.7 | TCP S |
| Backpressure | EXP *1 | 4.8 | TCP R |
+------------------------+-------------+------------+--------+
Table 1: Recommendations concerning host modifications.
表1：ホストの修正に関する勧告。
*1 Implementation of the technique may require changes to the internal design of the protocol stack in end hosts. *2 Dependent on a scheme for preventing excessive TCP transmission burst.
*技術の1つの実装は、エンドホストにおけるプロトコルスタックの内部設計の変更を必要とし得ます。 *過度のTCP送信バーストを防止するためのスキームに2依存性。
The recommendations for techniques that do not require the TCP sender and receiver to be aware of their existence (i.e., transparent techniques) are summarized in table 2. Each technique is listed along with the section in which each mechanism is discussed, and where the technique is applied (S denotes the sending interface prior to the upstream bottleneck link, R denotes receiving interface following the upstream bottleneck link).
その存在を意識するTCP送信側と受信側を必要としない技術のための勧告（すなわち、透明技術）は、各技術は、各機構が議論されている部分と一緒に表示されている表2にまとめ、そしてここで、技術れます（S前上流のボトルネックリンクに送信するインタフェースであり、Rは、上流のボトルネックリンク以下のインターフェイスを受け表す）が印加されます。
+------------------------+-------------+------------+--------+
| Mechanism | Use | Section | Type |
+------------------------+-------------+------------+--------+
| Header Compr. (V-J) | REC *1 | 5.1.1 | 0 SR |
| Header Compr. (ROHC) | REC *1 *2 | 5.1.2 | 0 SR |
+------------------------+-------------+------------+--------+
| ACK Filtering (AF) | EXP *3 | 5.2.1 | 1 S |
| ACK Decimation | EXP *3 | 5.2.2 | 1 S |
+------------------------+-------------+------------+--------+
| ACK Reconstruction (AR)| NOT REC | 5.3.1 | 2 *4 |
| ACK Compaction/Compand.| EXP | 5.3.2 | 2 S *4 |
| Gen. Traff. Shap. (GTS)| REC | 5.3.3 | 2 *5 |
+------------------------+-------------+------------+--------+
| Fair Queueing (FQ) | REC | 5.4.1 | 3 S |
| ACKs-First Scheduling | NOT REC | 5.4.2 | 3 S |
+------------------------+-------------+------------+--------+
Table 2: Recommendations concerning transparent modifications.
表2：透明の修正に関する勧告。
*1 At high asymmetry these schemes may degrade TCP performance, but are not considered harmful to the Internet. *2 Standardisation of new TCP compression protocols is the subject of ongoing work within the ROHC WG, refer to other IETF RFCs on the use of these techniques. *3 Use in the Internet is dependent on a scheme for preventing excessive TCP transmission burst. *4 Performed at a point along the reverse path after the upstream bottleneck link. *5 Performed at a point along the forward path.
* 1高非対称で、これらの方式は、TCPのパフォーマンスが低下する可能性がありますが、インターネットに有害とみなされていません。 *新しいTCP圧縮プロトコルの2標準化は、ROHC WG内で進行中の作業の対象は、これらの技術の使用に他のIETFのRFCを参照してくださいです。 *インターネットでの3の使用は、過剰なTCPの送信バーストを防止するための方式に依存しています。 * 4上流のボトルネックリンクの後に逆の経路に沿った点で実行。 * 5フォワードパスに沿った点に出演。
This document has benefited from comments from the members of the Performance Implications of Links (PILC) Working Group. In particular, the authors would like to thank John Border, Spencer Dawkins, Aaron Falk, Dan Grossman, Randy Katz, Jeff Mandin, Rod Ragland, Ramon Segura, Joe Touch, and Lloyd Wood for their useful comments. They also acknowledge the data provided by Metricom Inc., concerning operation of their packet data network.
この文書は、リンク（PILC）ワーキンググループの業績への影響のメンバーからのコメントの恩恵を受けています。特に、作者は彼らの役に立つコメントをジョンボーダー、スペンサードーキンスアーロンフォーク、ダン・グロスマン、ランディカッツ、ジェフMandin、ロッドRagland、ラモン・セグラ、ジョー・タッチ、およびロイド・ウッドに感謝したいと思います。彼らはまた、パケット・データ・ネットワークの動作に関するMetricomの株式会社によって提供されたデータを、認めます。
References of the form RFCnnnn are Internet Request for Comments (RFC) documents available online at http://www.rfc-editor.org/.
フォームRFCnnnnの参照は、http://www.rfc-editor.org/からオンラインで入手できますコメント（RFC）文書のためのインターネット要求されています。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]ジェーコブソン、V.、 "圧縮TCP /低速シリアルリンクのIPヘッダ"、RFC 1144、1990年2月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191]モーグル、J.およびS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.とP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
[RFC3135]ボーダー、J.、古城、M.、Griner、J.、モンテネグロ、G.およびZ.シェルビー、 "プロキシのパフォーマンスの向上は、リンク関連の劣化を軽減することを目的"、RFC 3135、2001年6月。
[abc-ID] Allman, M., "TCP Congestion Control with Appropriate Byte Counting", Work in Progress.
[ABC-ID]オールマン、M.、 "適切なバイトカウントとTCP輻輳制御"、ProgressのWork。
[All97b] Allman, M., "Fixing Two BSD TCP Bugs", Technical Report CR-204151, NASA Lewis Research Center, October 1997.
"二つのBSDのTCPのバグを修正" [All97b]オールマン、M.、テクニカルレポートCR-204151、NASAルイスリサーチセンター、1997年10月。
[ANS01] ANSI Standard T1.413, "Network to Customer Installation Interfaces - Asymmetric Digital Subscriber Lines (ADSL) Metallic Interface", November 1998.
[ANS01] ANSI規格T1.413、「ネットワークは、お客様のインストールインターフェイスへ - 非対称デジタル加入者線（ADSL）メタリック・インタフェース」、1998年11月。
[ASB96] Arora, V., Suphasindhu, N., Baras, J.S. and D. Dillon, "Asymmetric Internet Access over Satellite-Terrestrial Networks", Proc. AIAA: 16th International Communications Satellite Systems Conference and Exhibit, Part 1, Washington, D.C., February 25-29, 1996, pp.476-482.
【ASB96]アローラ、V.、Suphasindhu、N.、バラス、J.S.そして、D.ディロン、「衛星地上ネットワーク経由非対称インターネットアクセス」、PROC。 AIAA：第16回国際通信衛星システム会議、展示、パート1、ワシントンD.C.、2月25-29、1996、pp.476-482。
[AST00] Aggarwal, A., Savage, S., and T. Anderson, "Understanding the Performance of TCP Pacing", Proc. IEEE INFOCOM, Tel-Aviv, Israel, V.3, March 2000, pp. 1157-1165.
[AST00]アガルワル、A.、サベージ、S.、およびT.アンダーソン、PROC "TCP Pacingのパフォーマンスを理解します"。 IEEE INFOCOM、テルアビブ、イスラエル、V.3、2000年3月、頁。1157年から1165年。
[Bal98] Balakrishnan, H., "Challenges to Reliable Data Transport over Heterogeneous Wireless Networks", Ph.D. Thesis, University of California at Berkeley, USA, August 1998. http://nms.lcs.mit.edu/papers/hari-phd/
[Bal98]バラクリシュナン、H.、「ヘテロジニアス無線ネットワーク上で信頼性の高いデータ転送への挑戦」、博士論文、バークレー、アメリカのカリフォルニア大学、1998年8月http://nms.lcs.mit.edu/papers/hari-phd/
[BPK99] Balakrishnan, H., Padmanabhan, V. N., and R. H. Katz, "The Effects of Asymmetry on TCP Performance", ACM Mobile Networks and Applications (MONET), Vol.4, No.3, 1999, pp. 219-241. An expanded version of a paper published at Proc. ACM/IEEE Mobile Communications Conference (MOBICOM), 1997.
[BPK99]バラクリシュナン、H.、Padmanabhan、VN、およびRHカッツ、 "TCPパフォーマンス上の非対称性の影響"、ACMモバイルネットワークとアプリケーション（MONET）、第4巻、第3号、1999年、頁219から241 。 PROCで発表された論文の拡張バージョン。 ACM / IEEEモバイル通信会議（MOBICOM）、1997。
[BPS00] Bennett, J. C., Partridge, C., and N. Schectman, "Packet Reordering is Not Pathological Network Behaviour", IEEE/ACM Transactions on Networking, Vol. 7, Issue. 6, 2000, pp.789-798.
[BPS00]ベネット、J. C.、ヤマウズラ、C.、およびN. Schectmanは、ネットワーク上のIEEE / ACMトランザクション、VOL "パケットの並べ替えは、病理学的ネットワーク動作ではありません"。 7号。 6、2000、pp.789-798。
[Cla88] Clark, D.D, "The Design Philosophy of the DARPA Internet Protocols", ACM Computer Communications Review (CCR), Vol. 18, Issue 4, 1988, pp.106-114.
[Cla88]クラーク、D.D、 "DARPAインターネットプロトコルの設計理念"、ACMコンピュータコミュニケーションレビュー（CCR）、巻。 18、第4号、1988、pp.106-114。
[CLC99] Clausen, H., Linder, H., and B. Collini-Nocker, "Internet over Broadcast Satellites", IEEE Communications Magazine, Vol. 37, Issue. 6, 1999, pp.146-151.
【CLC99] Clausenの、H.、リンダー、H.、およびB. Collini-Nocker、 "インターネット放送衛星上"、IEEE通信誌、巻。 37号。 6、1999、pp.146-151。
[CLP98] Calveras, A., Linares, J., and J. Paradells, "Window Prediction Mechanism for Improving TCP in Wireless Asymmetric Links". Proc. IEEE Global Communications Conference (GLOBECOM), Sydney Australia, November 1998, pp.533-538.
[CLP98] Calveras、A.、リナレス、J.、およびJ. Paradells、 "無線非対称リンクでTCPを改善するためのウィンドウ予測機構"。 PROC。 IEEEグローバルコミュニケーション会議（GLOBECOM）、オーストラリアのシドニー、1998年11月、pp.533-538。
[CR98] Cohen, R., and Ramanathan, S., "Tuning TCP for High Performance in Hybrid Fiber Coaxial Broad-Band Access Networks", IEEE/ACM Transactions on Networking, Vol.6, No.1, 1998, pp.15-29.
[CR98]コーエン、R.、およびラマナサン、S.、「ハイブリッドファイバー同軸広帯域アクセスネットワークにおけるハイパフォーマンスのチューニングTCP」、ネットワーキング、第6巻、第1号、1998年、頁上のIEEE / ACM取引。 15-29。
[DS00] Cable Television Laboratories, Inc., Data-Over-Cable
Service Interface Specifications---Radio Frequency
Interface Specification SP-RFIv1.1-I04-00407, 2000
[DS01] Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification 1.0, SP-RFI-I05-991105, Cable Television Laboratories, Inc., November 1999.
[DS01]データオーバーケーブルサービスインターフェース仕様、無線周波数インターフェース仕様1.0、SP-RFI-I05-991105、ケーブルテレビラボラトリーズ社、1999年11月。
[DMT96] Durst, R., Miller, G., and E. Travis, "TCP Extensions for Space Communications", ACM/IEEE Mobile Communications Conference (MOBICOM), New York, USA, November 1996, pp.15- 26.
[DMT96]ダースト、R.、ミラー、G.、およびE.トラヴィス、 "宇宙通信のためのTCP拡張機能"、ACM / IEEEモバイルコミュニケーションズ会議（MOBICOM）、ニューヨーク、USA、1996年11月、pp.15- 26。
[EN97] "Digital Video Broadcasting (DVB); DVB Specification for Data Broadcasting", European Standard (Telecommunications series) EN 301 192, 1997.
【EN97 "デジタルビデオ放送（DVB）;データ放送のためのDVB仕様" 301 192、1997 EN、欧州規格（電気通信シリーズ）。
[EN00] "Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems", Draft European Standard (Telecommunications series) ETSI, Draft EN 301 790, v.1.2.1
[EN00] "デジタルビデオ放送（DVB）;衛星配信システムのための対話チャンネル"、ドラフト欧州規格（電気通信シリーズ）ETSI、ドラフトEN 301 790、v.1.2.1
[FJ93] Floyd, S., and V. Jacobson, "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, Vol.1, No.4, 1993, pp.397-413.
[FJ93]フロイド、S.、およびV. Jacobsonの、 "輻輳回避のためのランダム早期検出ゲートウェイ"、ネットワーキング、第1巻、第4号、1993、pp.397-413にIEEE / ACMトランザクション。
[FSS01] Fairhurst, G., Samaraweera, N.K.G, Sooriyabandara, M., Harun, H., Hodson, K., and R. Donardio, "Performance Issues in Asymmetric Service Provision using Broadband Satellite", IEE Proceedings on Communication, Vol.148, No.2, 2001, pp.95-99.
[FSS01] Fairhurst、G.、Samaraweera、NKG、Sooriyabandara、M.、ハルン、H.、ホドソン、K.、およびR. Donardio、 "ブロードバンド衛星を用いた非対称サービス提供におけるパフォーマンスの問題"、コミュニケーション、巻上IEE議事録0.148、第2号、2001年、pp.95-99。
[ITU01] ITU-T Recommendation E.681, "Traffic Engineering Methods For IP Access Networks Based on Hybrid Fiber/Coax System", September 2001.
[ITU01] ITU-T勧告、2001年9月E.681、「ハイブリッドファイバ/同軸システムに基づいて、IPアクセスネットワークのトラフィックエンジニアリング方法」。
[ITU02] ITU-T Recommendation G.992.1, "Asymmetrical Digital Subscriber Line (ADSL) Transceivers", July 1999.
[ITU02] ITU-T勧告G.992.1、 "非対称デジタル加入者線（ADSL）トランシーバ"、1999年7月。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Proc. ACM SIGCOMM, Stanford, CA, ACM Computer Communications Review (CCR), Vol.18, No.4, 1988, pp.314-329.
[Jac88]ジェーコブソン、V.、 "輻輳回避とコントロール"、PROC。 ACM SIGCOMM、スタンフォード大学、カリフォルニア州、ACMコンピュータコミュニケーションレビュー（CCR）、Vol.18、第4号、1988年、pp.314-329。
[Ken87] Kent C.A., and J. C. Mogul, "Fragmentation Considered Harmful", Proc. ACM SIGCOMM, USA, ACM Computer Communications Review (CCR), Vol.17, No.5, 1988, pp.390- 401.
【Ken87]ケントC.A.、およびJ. C.モーグルは、PROCを "断片化は有害であると考えられました"。 ACM SIGCOMM、USA、ACMコンピュータコミュニケーションレビュー（CCR）、Vol.17、第5号、1988、pp.390- 401。
[KSG98] Krout, T., Solsman, M., and J. Goldstein, "The Effects of Asymmetric Satellite Networks on Protocols", Proc. IEEE Military Communications Conference (MILCOM), Bradford, MA, USA, Vol.3, 1998, pp.1072-1076.
【KSG98] Krout、T.、Solsman、M.、およびJ.ゴールドスタイン、 "プロトコル上の不斉衛星ネットワークの影響"、PROC。 IEEE軍事通信会議（MILCOM）、ブラッドフォード、MA、USA、第3巻、1998、pp.1072-1076。
[KVR98] Kalampoukas, L., Varma, A., and Ramakrishnan, K.K., "Improving TCP Throughput over Two-Way Asymmetric Links: Analysis and Solutions", Proc. ACM SIGMETRICS, Medison, USA, 1998, pp.78-89.
[KVR98] Kalampoukas、L.、ヴァルマ、A.、およびラマクリシュナン、K.K.、 "双方向非対称リンク上でTCPスループットを向上させる：分析と解決策"、PROC。 ACM SIGMETRICS、Medison、USA、1998、pp.78-89。
[LM97] Lin, D., and R. Morris, "Dynamics of Random Early Detection", Proc. ACM SIGCOMM, Cannes, France, ACM Computer Communications Review (CCR), Vol.27, No.4, 1997, pp.78-89.
[LM97]林、D.、およびR.モリス、 "ランダム早期検出のダイナミクス"、PROC。 ACM SIGCOMM、カンヌ、フランス、ACMコンピュータコミュニケーションレビュー（CCR）、Vol.27、第4号、1997年、pp.78-89。
[LMS97] Lakshman, T.V., Madhow, U., and B. Suter, "Window-based Error Recovery and Flow Control with a Slow Acknowledgement Channel: A Study of TCP/IP Performance", Proc. IEEE INFOCOM, Vol.3, Kobe, Japan, 1997, pp.1199-1209.
[LMS97]ラクシュマン、T.V.、Madhow、U.、および「スロー肯定応答チャネルを持つウィンドウベースのエラー回復とフロー制御：TCP / IPの性能の研究」B.スーター、PROC。 IEEE INFOCOM、第3巻、神戸、日本、1997、pp.1199-1209。
[MJW00] Ming-Chit, I.T., Jinsong, D., and W. Wang,"Improving TCP Performance Over Asymmetric Networks", ACM SIGCOMM, ACM Computer Communications Review (CCR), Vol.30, No.3, 2000.
[MJW00]明チット、髄腔内、Jinsong、D.、およびW.ワング、 "非対称ネットワークにおけるTCPのパフォーマンスの向上"、ACM SIGCOMM、ACMコンピュータコミュニケーションレビュー（CCR）、Vol.30、第3号、2000年。
[Pad98] Padmanabhan, V.N., "Addressing the Challenges of Web Data Transport", Ph.D. Thesis, University of California at Berkeley, USA, September 1998 (also Tech Report UCB/CSD-98-1016). http://www.cs.berkeley.edu/~padmanab/phd-thesis.html
"Webデータ交通の課題に取り組む" [Pad98] Padmanabhan、V.N.、博士論文、バークレー、USA、1998年9月のカリフォルニア大学（もテックレポートUCB / CSD-98から1016まで）。 http://www.cs.berkeley.edu/~padmanab/phd-thesis.html
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[RFC2018] Mathis, B., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]マティス、B.、Mahdavi、J.、フロイド、S.とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507] Degermark、M.、Nordgren、B.とS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[RFC2525] Paxson, V., Allman, M., Dawson, S., Heavens, I. and B. Volz, "Known TCP Implementation Problems", RFC 2525, March 1999.
[RFC2525]パクソン、V.、オールマン、M.、ドーソン、S.、天、I.およびB.フォルツ、 "既知のTCP実装の問題"、RFC 2525、1999年3月。
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[RFC2686]ボルマン、C.、RFC 2686 "マルチリンクPPPへのマルチクラス拡張"、1999年9月。
[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Henderson, T., Heidemann, J., Kruse, H., Ostermann, S., Scott, K., Semke, J., Touch, J. and D. Tran, "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.
[RFC2760]オールマン、M.、ドーキンス、S.、グローバー、D.、Griner、J.、ヘンダーソン、T.、Heidemann、J.、クルーズ、H.、Ostermann、S.、スコット、K.、Semke、 J.、タッチ、J.とD.トラン、 "継続的なTCPの研究衛星に関連する"、RFC 2760、2000年2月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N. and Y. Zhang, "A link Layer tunneling mechanism for unidirectional links", RFC 3077, March 2001.
[RFC3077] DUROS、E.、Dabbous、W.、Izumiyama、H.、藤井、N.およびY.チャン、 "単方向リンクのためのリンクレイヤトンネリングメカニズム"、RFC 3077、2001年3月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP ESP and uncompressed", RFC 3095, July 2001.
[RFC3095]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、E.、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.とH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP ESPと2001年7月、RFC 3095、」圧縮されていません。
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[RFC3150]ドーキンス、S.、モンテネグロ、G.、古城、M.およびV. Magret、 "低速リンクのエンドツーエンドのパフォーマンスへの影響"、BCP 48、RFC 3150、2001年7月。
[RFC3168] Ramakrishnan K., Floyd, S. and D. Black, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナンK.、フロイド、S.及びD.ブラック、 "IPに明示的輻輳通知（ECN）を追加する提案"、RFC 3168、2001年9月。
[Sam99] Samaraweera, N.K.G, "Return Link Optimization for Internet Service Provision Using DVB-S Networks", ACM Computer Communications Review (CCR), Vol.29, No.3, 1999, pp.4-19.
[Sam99] Samaraweera、N.K.G、 "DVB-Sネットワークを利用したインターネットサービス提供のための戻りリンクの最適化"、ACMコンピュータコミュニケーションレビュー（CCR）、Vol.29、第3号、1999年、pp.4-19。
[Seg00] Segura R., "Asymmetric Networking Techniques For Hybrid Satellite Communications", NC3A, The Hague, Netherlands, NATO Technical Note 810, August 2000, pp.32-37.
[SEG00]セグラR.、 "ハイブリッド衛星通信用非対称ネットワーク技術"、NC3A、ハーグ、オランダ、NATOテクニカルノート810、2000年8月、pp.32-37。
[SF98] Samaraweera, N.K.G., and G. Fairhurst. "High Speed Internet Access using Satellite-based DVB Networks", Proc. IEEE International Networks Conference (INC98), Plymouth, UK, 1998, pp.23-28.
【SF98] Samaraweera、N.K.G.、及びG. Fairhurst。 「高速インターネットアクセス、衛星ベースのDVBネットワークを使用して」、PROC。 IEEE国際ネットワーク会議（INC98）、プリマス、イギリス、1998年、pp.23-28。
[ZSC91] Zhang, L., Shenker, S., and D. D. Clark, "Observations and Dynamics of a Congestion Control Algorithm: The Effects of Two-Way Traffic", Proc. ACM SIGCOMM, ACM Computer Communications Review (CCR), Vol 21, No 4, 1991, pp.133- 147.
[ZSC91]チャン、L.、Shenker、S.、およびD. D.クラーク、「観測と輻輳制御アルゴリズムのダイナミクス：双方向トラフィックの影響」、PROC。 ACM SIGCOMM、ACMコンピュータコミュニケーションレビュー（CCR）、巻21、ノー4、1991、pp.133- 147。
There are no IANA considerations associated with this document.
この文書に関連付けられたIANAの考慮事項はありません。
Appendix - Examples of Subnetworks Exhibiting Network Path Asymmetry
付録 - サブネットワーク出展ネットワークパスの非対称性の例
This appendix provides a list of some subnetworks which are known to experience network path asymmetry. The asymmetry in capacity of these network paths can require mitigations to provide acceptable overall performance. Examples include the following:
この付録では、ネットワーク経路の非対称性を体験することが知られているいくつかのサブネットワークのリストを提供します。これらのネットワーク経路の容量の非対称性は、許容可能な全体的なパフォーマンスを提供するために、緩和策を必要とすることができます。例としては次のものがあります。
- IP service over some wide area and local area wireless networks. In such networks, the predominant network path asymmetry arises from the hub-and-spokes architecture of the network (e.g., a single base station that communicates with multiple mobile stations), this requires a Ready To Send / Clear To Send (RTS/CTS) protocol and a Medium Access Control (MAC) protocol which needs to accommodate the significant turn-around time for the radios. A high per-packet transmission overhead may lead to significant network path asymmetry.
- いくつかのワイドエリアおよびローカルエリア無線ネットワーク上でIPサービス。そのようなネットワークでは、優勢なネットワークパスの非対称性は、ネットワーク（複数の移動局と通信を行う、例えば、単一の基地局）のハブ・アンド・スポーク・アーキテクチャから生じ、これは、（RTS / CTSを送信するように/クリアを送信する準備が必要）プロトコルおよび無線の大幅なターンアラウンドタイムに対応する必要がある媒体アクセス制御（MAC）プロトコル。高いパケットごとの送信オーバーヘッド有意なネットワーク経路非対称につながり得ます。
- IP service over a forward satellite link utilizing Digital Video Broadcast (DVB) transmission [EN97] (e.g., 38-45 Mbps), and a slower upstream link using terrestrial network technology (e.g., dial-up modem, line of sight microwave, cellular radio) [CLC99]. Network path asymmetry arises from a difference in the upstream and downstream link capacities.
- デジタルビデオ放送（DVB）伝送[EN97]（例えば、38から45 Mbpsの）、および地上ネットワーク技術を使用して、より遅い上流のリンク（例えば、ダイヤルアップモデム、視力のマイクロ波のラインを利用し、前方の衛星リンク上でIPサービスセルラー無線）[CLC99]。ネットワーク経路の非対称は、上流と下流のリンク容量の差から生じます。
- Certain military networks [KSG98] providing Internet access to in-transit or isolated hosts [Seg00] using a high capacity downstream satellite link (e.g., 2-3 Mbps) with a narrowband upstream link (e.g., 2.4-9.6 kbps) using either Demand Assigned Multiple Access (DAMA) or fixed rate satellite links. The main factor contributing to network path asymmetry is the difference in the upstream and downstream link capacities. Some differences between forward and reverse paths may arise from the way in which upstream link capacity is allocated.
- 特定の軍事ネットワークは[KSG98] [SEG00]いずれかを使用して狭帯域アップストリームリンク（例えば、2.4から9.6 kbpsの）と高容量下流衛星リンク（例えば、2-3 Mbpsの）を使用して、トランジットまたは単離されたホストへのインターネットアクセスを提供します需要が多元接続（DAMA）または固定金利の衛星リンクを割り当てられました。パス非対称ネットワークに寄与する主な要因は、上流と下流のリンク容量の差です。順方向および逆方向経路間のいくつかの違いは、上流リンク容量が割り当てられている方法から生じ得ます。
- Most data over cable TV networks (e.g., DOCSIS [ITU01, DS00]), where the analogue channels assigned for upstream communication (i.e., in the reverse direction) are narrower and may be more noisy than those assigned for the downstream link. As a consequence, the upstream and downstream links differ in their transmission rate. For example, in DOCSIS 1.0 [DS00], the downstream transmission rate is either 27 or 52 Mbps. Upstream transmission rates may be dynamically selected to be one of a series of rates which range between 166 kbps to 9 Mbps. Operators may assign multiple upstream channels per downstream channel. Physical layer (PHY) overhead (which accompanies upstream transmissions, but is not present in the downstream link) can also increase the network path asymmetry. The Best Effort service, which is typically used to carry TCP, uses a contention/reservation MAC protocol. A cable modem (CM) sending an isolated packet (such as a TCP ACK) on the upstream link must contend with other CMs to request capacity from the central cable modem termination system (CMTS). The CMTS then grants timeslots to a CM for the upstream transmission. The CM may "piggyback" subsequent requests onto upstream packets, avoiding contention cycles; as a result, spacing of TCP ACKs can be dramatically altered due to minor variations in load of the cable data network and inter-arrival times of TCP DATA packets. Numerous other complexities may add to, or mitigate, the asymmetry in rate and access latency experienced by packets sent on the upstream link relative to downstream packets in DOCSIS. The asymmetry experienced by end hosts may also change dynamically (e.g., with network load), and when best effort services share capacity with services that have symmetric reserved capacity (e.g., IP telephony over the Unsolicited Grant service) [ITU01].
- ケーブルテレビネットワーク上でほとんどのデータ（例えば、DOCSIS [ITU01、DS00]）のアナログチャンネルが（逆方向、すなわち）上り通信用に割り当てられた、狭いおよび下流リンクに割り当てられたものよりもノイジーであってもよいです。その結果、上流と下流のリンクは、それらの透過率が異なります。例えば、DOCSIS 1.0 [DS00]で、下り伝送速度は、27または52 Mbpsのいずれかです。アップストリーム伝送レートを動的9 Mbpsに166 kbpsの間の範囲レートのシリーズの一つであるように選択することができます。オペレータは、ダウンストリームチャネルごとに複数のアップストリームチャネルを割り当てることができます。 （アップストリーム送信を伴うが、下流リンクには存在しない）、物理層（PHY）のオーバーヘッドは、ネットワークパスの非対称性を増加させることができます。一般的にTCPを運ぶために使用されているベストエフォートサービスは、競合/予約MACプロトコルを使用しています。アップストリームリンク上で（例えばTCP ACKなど）、単離されたパケットを送信するケーブルモデム（CM）は、中央ケーブルモデム終端システム（CMTS）から容量を要求する他のCMと競合しなければなりません。 CMTSは、その後、アップストリーム送信のためにCMにタイムスロットを付与します。 CMは、競合サイクルを回避する、上流のパケットへの後続の要求を「ピギーバック」することができます。結果として、TCP ACKの間隔が劇的に起因マイナーケーブル・データ・ネットワークの負荷の変動及びTCPデータパケットの到着時間間隔に変更することができます。多くの他の複雑さがDOCSIS下流パケットにアップストリームリンクに対して上で送信されるパケットが経験する速度およびアクセス待ち時間で、非対称性に追加する、または軽減することができます。エンドホストが経験した非対称性は、（ネットワーク負荷で、例えば）動的に変化してもよく、とき対称の予約能力を持っているサービスとベストエフォートサービスを共有容量（例えば、送信権割当サービスオーバーIPテレフォニー）[ITU01]。
- Asymmetric Digital Subscriber Line (ADSL), by definition, offers a downstream link transmission rate that is higher than that of the upstream link. The available rates depend upon channel quality and system configuration. For example, one widely deployed ADSL technology [ITU02, ANS01] operates at rates that are multiples of 32 kbps (up to 6.144 Mbps) in the downstream link, and up to 640 kbps for the upstream link. The network path asymmetry experienced by end hosts may be further increased when best effort services, e.g., Internet access over ADSL, share the available upstream capacity with reserved services (e.g., constant bit rate voice telephony).
- 非対称デジタル加入者線（ADSL）は、定義により、上流のリンクよりも高い下りリンクの伝送速度を提供しています。有効なレートは、チャネル品質およびシステム構成によって異なります。例えば、一つの広く配備ADSL技術[ITU02、ANS01]は下流リンク32 kbpsの（6.144 Mbpsのまで）、の倍数である速度で、上りリンクのための640 kbpsの最大動作します。エンドホストによって経験されるネットワーク経路非対称性は、さらに、ベストエフォートサービスは、例えば、ADSLオーバーインターネットアクセス、予約サービス（例えば、一定のビットレート音声電話）で使用可能なアップストリーム容量を共有する場合に増加することができます。
Authors' Addresses
著者のアドレス
Hari Balakrishnan Laboratory for Computer Science 200 Technology Square Massachusetts Institute of Technology Cambridge, MA 02139 USA
技術のコンピュータサイエンス200技術スクエアマサチューセッツ工科大学、ケンブリッジ、MA 02139 USAのためのハリ・バラクリシュナン研究所
Phone: +1-617-253-8713 EMail: hari@lcs.mit.edu Web: http://nms.lcs.mit.edu/~hari/
電話：+ 1-617-253-8713 Eメール：hari@lcs.mit.eduウェブ：http://nms.lcs.mit.edu/~hari/
Venkata N. Padmanabhan Microsoft Research One Microsoft Way Redmond, WA 98052 USA
98052 USA OFヴェンカタN. Padmanabhanマイクロソフトリサーチ1つのマイクロソフト道、レッドモンド、
Phone: +1-425-705-2790 EMail: padmanab@microsoft.com Web: http://www.research.microsoft.com/~padmanab/
電話：+ 1-425-705-2790 Eメール：padmanab@microsoft.comウェブ：http://www.research.microsoft.com/~padmanab/
Godred Fairhurst Department of Engineering Fraser Noble Building University of Aberdeen Aberdeen AB24 3UE UK
アバディーンAB24 3UE英国のエンジニアリングフレイザーノーブルビル大学のGodred Fairhurst部門
EMail: gorry@erg.abdn.ac.uk Web: http://www.erg.abdn.ac.uk/users/gorry
メールアドレス：gorry@erg.abdn.ac.ukウェブ：http://www.erg.abdn.ac.uk/users/gorry
Mahesh Sooriyabandara Department of Engineering Fraser Noble Building University of Aberdeen Aberdeen AB24 3UE UK
アバディーンAB24 3UE英国のエンジニアリングフレイザーノーブルビル大学のマヘシュSooriyabandara部門
EMail: mahesh@erg.abdn.ac.uk Web: http://www.erg.abdn.ac.uk/users/mahesh
メールアドレス：mahesh@erg.abdn.ac.ukウェブ：http://www.erg.abdn.ac.uk/users/mahesh
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。