[要約] 要約： RFC 3449は、ネットワークパスの非対称性がTCPのパフォーマンスに与える影響について説明しています。目的： このRFCの目的は、ネットワークパスの非対称性がTCPのパフォーマンスに与える影響を理解し、ネットワーク設計やプロトコルの改善に役立つ情報を提供することです。
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
ネットワークパスの非対称性のTCPパフォーマンスへの影響
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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.
このドキュメントは、これらの効果のいくつかの緩和を詳述しています。これらの効果は、文献で提案または評価されているか、現在ネットワークに展開されています。これらのソリューションは、以下で構成されるローカルリンク層技術、サブネットワーク、およびエンドツーエンドのメカニズムの組み合わせを使用します。TCP ACKの頻度、（ii）この削減されたACK頻度を処理する手法TCP送信者の確認誘導性セルフクロックを維持し、（iii）2つの存在下でパフォーマンスを改善するためにデータとACKパケットを逆方向にスケジュールする（iii）テクニック - ウェイトラフィック。各手法は、既知の問題と使用に関する推奨事項とともに説明されています。推奨事項の概要は、ドキュメントの最後に提供されます。
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.
ダウンストリームリンク：アップストリームリンクに対応するフォワードパス上のリンク。
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係数の遅延、D：TCP ACKによって認められるTCPデータセグメントの数。Dの最小値は1です。最大で1つのACKを各データパケット[RFC1122、RFC2581]に送信する必要があるためです。
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は、以前に採用されていないデータの2つ以上のセグメント（D> 2）[RFC2581]をカバーする謝辞です。ストレッチACKは、実装バグ[ALL97B、RFC2525]のため、またはACK損失[RFC2760]により、設計により（これは標準ではありません）（これは標準ではありません）。
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].
正規化された帯域幅比、K：前方方向の生の帯域幅（容量）の比率は、2つの方向で使用されるパケットサイズの比で割った[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.
非対称の特性は、ケーブルデータネットワーク（例：DocsisケーブルTVネットワーク[DS00、DS01]）、ダイレクトブロードキャスト衛星（例：デジタルビデオブロードキャスト、DVB、[EN97]を使用したIPサービス[EN97]をインタラクティブとともに含むいくつかのネットワークテクノロジー）によって展示されています。リターンチャネル）、非常に小さな開口衛星端子（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 Acksで使用される逆パスで容量が低下するように、ACKフィードバックが遅くなるかまれなACKフィードバックがTCPパフォーマンスを順方向に分解します。同様に、容量が対称であっても、基礎となる中程度のアクセス制御（MAC）および物理的（PHY）プロトコルの非対称性により、TCP Acks（サイズに不均衡に）を送信するのに費用がかかる可能性があります。
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]).
TCP Acksを運ぶベスト努力のIPフローが他のトラフィックフロー、特に上流の容量を予約するフローと利用可能なアップストリーム容量を共有する場合、容量の非対称性が大幅に増加する可能性があります。これには、IPレイヤー（たとえば、保証されたサービス[RFC2212]）またはサブネットレイヤー（例えば、DOCSIS [DS01]の未承諾助成金サービスを使用したIP上の音声のサポート[ITU01]）でのサービス保証が含まれます。ATM上のATM [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は、各ノードを各アップストリーム時間分割間隔の最大1つのパケットで送信することを制限します[DS00]）。ダイナミック帯域幅オンデマンド（BOD）を使用する衛星ネットワークは、送信される各パケットのMACリソースも消費します（[EN00]など）。これらのスキームでは、利用可能なアップリンク容量はMACアルゴリズムの関数です。MacおよびPhyスキームはまた、上流の伝送ごとのオーバーヘッドを導入しますが、これは非常に重要である可能性があるため、短いパケット（TCP Acksを含む）を送信することは、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.
容量依存性とMAC依存の非対称性の技術的な違いにもかかわらず、同じ基本的な理由でTCPパフォーマンスを低下させる両方の種類のネットワークパスは、ACKフィードバックの不完全性と変動性です。このドキュメントでは、問題を詳細に説明し、制約を削減または排除する可能性のあるいくつかの手法について説明します。
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.
フォワードパスとリターンパスの容量が非常に異なる場合に一方向転送パフォーマンスを低下させる問題は、上流のリンクの特性に依存します。このようなネットワークパス上の単方向トラフィックに対して2種類の状況が発生します。上流のボトルネックリンクがパケット（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].
上流のボトルネックリンクに深いキューがあるため、これが逆方向にAcksを落とさない場合、パフォーマンスは正規化された帯域幅比kの強い関数です。たとえば、10 Mbps下流リンクと50 kbpsの上流リンクの場合、生の容量比は200です。1000バイトのデータパケットと40バイトのAckを使用すると、パケットサイズの比率は25です。これはkが200であることを意味します。/25 = 8。したがって、レシーバーが8（k）データパケットごとに1つのACKよりも頻繁に認めている場合、上流のリンクの前に上流のリンクが飽和状態になり、スループットが前方方向に制限されます。達成された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を使用している場合[RFC1122]、TCP ACK-Clockingが崩壊します。送信者によって送信された2つのデータパケットをすばやく連続して検討してください。受信機への途中で、これらのパケットは、前方向の最小のボトルネックリンクの容量に応じて間隔を空けます。ACKクロッキングの原則は、これらのデータパケットの受信に応じて生成されたACKがこの時間間隔を送信者にずっと反映し、同じ間隔を維持する新しいデータパケットを送信できるようにすることです[JAC88]。ACKクロッキングが遅れたACKは、実際にACKをトリガーするデータパケット間の間隔を反映しています。ただし、上流のボトルネックルーターでの制限された上流容量とキューイングは、逆パスの間隔間間隔を変えるため、送信者で観察されたものです。Acksがリンクがサポートできるよりも速い速度で上流のボトルネックリンクに到着すると、互いに並んでいます。リンクから出現したときの間の間隔は、元の間隔に対して拡張され、上流のボトルネック容量の関数です。したがって、TCP送信者は、ACKのキューイングがなかった場合よりも遅い速度で新しいデータパケットをクロックします。接続のパフォーマンスは、下流のボトルネックリンクのみに依存しなくなります。代わりに、ACKSの到着率によってスロットルされます。副作用として、送信者の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 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に対応するためのバッファースペースが比較的少ない場合に異なる状況が生じます。トランスミッションウィンドウが成長すると、このキューが埋められ、Acksがドロップされます。受信者がすべてのパケットを認めた場合、すべてのkアクックの1つだけが送信者に到達し、上流のリンクバッファーでのバッファオーバーフローのために残りの（k-1）がドロップされます（ここでは、kは正規化された帯域幅比です。前に）。この場合、逆のボトルネックリンク容量とACKの到着率の遅い容量は、劣化したパフォーマンスについて直接責任を負いません。ただし、ACKの頻度は低下していることにつながります。
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で1つの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）とも呼ばれる後のアプローチは、混雑回避期間中のCWND増加の標準的な実装オプションです[RFC2581]。したがって、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. Sender TCPの高速回復および高速回復アルゴリズム[RFC2581]は、ACKが失われると効果が低くなります。送信者は、レシーバーがデュパックのしきい値（> 3デュパック）を超えて送信された場合でも、重複するAcksのしきい値を受け取っていない可能性があります[RFC2581]。さらに、送信者は、迅速な回復中に適切に膨張するのに十分な複製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.
TCPとMACプロトコルとの相互作用は、エンドツーエンドのパフォーマンスを低下させる可能性があります。この問題の主な症状は、さまざまな往復遅延と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.
1つの例は、陸生ワイヤレスネットワーク[BAL98]への影響です。パケットあたりのオーバーヘッドが高い場合、リンクノードを通信して最初に同期する必要があることから生じる可能性があります（たとえば、通信前に送信 /クリア（RTS / CTS）プロトコルを送信 /クリア（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送信者はウィンドウで複数の損失が発生すると迅速に応答します。対照的に、一部のワイヤレスネットワークはRTTで高いばらつきを示し、RTOが大幅に増加します（たとえば、10秒程度）。複数のワイヤレスホップを通過するパスは、この効果に対して特に脆弱です。これにより、中間ノードがすでに他のノードと会話している可能性が増加するためです。ほとんどの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年にRicochet Packet Radio Networkで実施された実験では、無線ターンアラウンドの影響と、RTTの変動が増加し、TCPのパフォーマンスが低下しました。TCP接続が9〜12秒のタイムアウトを体験することは珍しくありませんでした。その結果、多くの接続が生涯のかなりの部分でアイドル状態になりました（たとえば、総転送時間の35％）。これにより、利用可能な容量が過小評価されます。これらの効果は、他のワイヤレスサブネットワークでも発生する可能性があります。
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で説明されている効果をさらに顕著にします。これにより、帯域幅の非対称性の程度が効果的に増加します。逆転送のデータパケットと順方向転送のアクセス間の相互作用により、他の効果も発生します。フォワードTCP接続が開始された時点で、逆TCP接続がデータパケットとのボトルネックの上流リンクをすでに飽和させているとします。その後、新しいフォワードTCP接続の多くのACKが完全な上流のリンクバッファーに遭遇し、したがって削除される可能性が高くなります。これらの最初の問題の後でも、順方向接続のAcksは、逆接続の大きなデータパケットの後ろにキューに入る可能性があります。大規模なデータパケットには、それに応じて長い送信時間がある場合があります（たとえば、28.8 kbpsラインで1 kbyteデータパケットを送信するには約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トラフィックのバースト性と自己同期効果は、ACK圧縮[ZSC91]として知られる効果をもたらし、TCPのスループットを減少させる可能性があります。一方の方向の一連のAcksが、他のパケットのバースト（たとえば、同じ方向に移動するデータパケット）の後ろに列が並び、時間内に圧縮されるときに発生します。これにより、サーバーに到着する圧縮ACKのバーストに応じて、他の方向にデータパケットが激しくバーストされます。この現象は双方向の交通について詳細に調査されており、最近の分析研究[LMS97]は、ACK圧縮が非対称性を伴う双方向伝達にも起因する可能性があると予測しており、実用的な衛星サブネットワーク[FSS01]で観察されたと予測しています。極端な非対称性（k >> 1）の場合、キューイング（セクション3.1）のために吸引間隔が増加する可能性があり、ACK拡張が生じます。
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の損失は、一般的にストレッチACK [CR98、FSS01]をもたらすため、データパケットの損失よりも有意ではありません。
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.
長い遅延パスの場合、エンドホストがTCPの大きなウィンドウ[RFC1323]を使用してスループットを最大化すると、遅い上流リンク[RFC3150]が別の合併症につながる可能性があります。いくつかのワイヤレスリンクで一般的な輻輳またはリンク損失により、フォワードパスでのデータパケットの損失は、多数の連続した重複ACK（またはTCPサックパケット[RFC2018]）を生成します。損失後のデータパケット。TCP送信者は、急速な再送信と回復[RFC2581]を採用して損失から回復しますが、これが成功したとしても、再送信されたデータセグメントへのACKは、上流のリンクバッファーでまだQueedが依然として並べられています。これにより、最終的にタイムアウト[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つの重要な問題があります。1つ目は、ACKやその他のトラフィックで使用されるアップストリームボトルネックリンクの容量を管理することです。逆方向に流れるアクックの数を減らすことで機能する多くの手法が存在します。これには、新しいデータパケットの送信が着信ACKによってトリガーされる、TCP送信者の望ましい自己閉鎖プロパティを潜在的に破壊する可能性のある副作用があります。したがって、2番目の問題は、まれなAcksの悪影響を回避することです。
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）、一部の手法ではTCP送信者の変更が必要であり（セクション4.6、4.7）、ペアではTCP送信者とレシーバーの両方に変更が必要です（セクション4.2、4.3）。1つの手法では、受信ホストでの送信者の変更が必要です（セクション4.8）。技術は独立して使用できますが、一部の手法は補完的です。たとえば、ペーシング（セクション4.6）およびバイトカウント（セクション4.7）は、単一のTCP送信者適応スキーム[BPK99]にバンドルされています。
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.
通常、これらの変更は非対称パスを使用して最終ホストで発生することが想定されていますが、スプリットTCPを使用してミドルボックスまたはプロトコルのプロキシ（PEP）[RFC3135]で使用できます。このドキュメントでは、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]で概説されているメソッドは、各着信データセグメント（つまり、d = 1）のACKを生成します。[RFC1122]ホストは「遅延承認」を使用する必要があると述べています。このアルゴリズムを使用して、ACKは少なくとも2秒ごとのフルサイズのセグメント（d = 2）で生成されます（d = 2）、または2番目のフルサイズのセグメントが特定のタイムアウト内に到着しない場合（これは500ミリ秒を超えてはなりません[RFC1122]、および通常、200ミリ秒未満です）。後者の制約を緩和する（つまり、d> 2を許可する）ストレッチアクックを生成する可能性があります[RFC2760]。これにより、可能な緩和が提供され、受信機が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) パスRTTの増加（II）CWNDがより大きなステップで開くため、TCPがCWND（III）を開く時間の増加（III）TCP送信者バーストサイズの増加
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を生成する必要があり、受信したデータの少なくとも2秒のフルサイズセグメント（MSS）のACKを生成する必要があります[RFC2581]。これにより、2の値を超えないACK遅延係数（d）が発生します。アルゴリズムを変更するには、非対称パスとの接続を使用している受信ホストによるTCPレシーバーのホスト変更と認識が必要です。このような変更には、一般的なケースでは多くの欠点があり、現在、インターネット内での使用をお勧めしていません。
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（イーサネットのMTU）を採用しています。IPヘッダーにdot fragment（df）ビットを設定することにより、Path 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ディスカバリーを使用しないことを選択することにより、エンドホストは、前方向のパスに沿ってルーターによるIPフラグメンテーションを使用することを選択できます[RFC793]。これにより、パスに沿った最小のMTUよりも大きいMSSが可能になります。ただし、これにより、エラー回復単位（TCPセグメント）が送信単位（IPパケット）を上回ります。これは推奨されません。これは、単一のIPパケットの損失に続いて再送信されたパケットの数を増やし、効率の低下につながり、ネットワークの混雑を悪化させる可能性があるためです[Ken87]。フォワードパスの最小MTUよりも大きいMSSを選択すると、セッションが開始またはRTOの有効期限に続いて、より多くの初期パケット（各TCPセグメントのIPフラグメントのバースト）を送信することもできます。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を使用できます。PATH MTUディスカバリーを使用したTCPエンドホストは、変更を必要とせずに適切な大きなMSSを自動的に選択することにより、大きなMTUを利用できる場合があります。したがって、Path MTU Discovery [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）は、端から端まで動作する実験的手法です。ACCは、上流のBottleNeckリンクでリソース（パケットバッファーやMACトランスミッションのオーバーヘッドなど）に対して無視できない要求を行う可能性があるため、混雑制御をACKに拡張します。（a）ACKパスが雑然としていることを受信者に示すネットワークメカニズム、および（b）そのような適応に対する受信者の応答。
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.
上流のボトルネックリンクに供給するルーターは、赤（ランダム早期検出）[FJ93]に基づいたアルゴリズムを使用して、初期の混雑を検出する場合があります。これは、最近の過去のタイムウィンドウで平均キューサイズを追跡する可能性があります。平均がしきい値を超える場合、ルーターはランダムにパケットを選択できます。パケットIPヘッダーに明示的な混雑通知能力輸送（ECT）ビットセットがある場合、ルーターはパケットをマークする場合があります。通常はドロップされます。エンドホストが受信したECN通知は、輻輳回避をトリガーするために、送信TCPエンドホストに反映されます[RFC3168]。ECNで赤を実装するルーターは、パケットの損失を排除せず、パケットをドロップする可能性があることに注意してください（ECTビットが設定されている場合でも）。また、赤以外のアルゴリズムを使用して、ECNビットをいつ設定するかを決定することもできます。
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.
ACCはECNを拡張して、TCPデータパケットとACKの両方がECTビットを設定するため、ECNビットでマークされる候補です。したがって、ECNビットセット[RFC3168]を使用してACKを受信すると、TCPレシーバーはACKを送信する速度を減らします。動的に変化する遅延FACK因子Dを維持し、受信したDデータパケットごとに1つのACKを送信します。ECNビットセットでパケットを受信すると、Dが増加して増加し、それによりACKの周波数が増加します。ECNを受け取らない間に、後続の各RTT（たとえば、TCP RTTMオプション[RFC1323]を使用して決定）について、因子Dを直線的に減少させ、ACKの周波数を増加させます。したがって、受信機は、ACKを送信する方法でTCP送信者の標準的な輻輳制御挙動を模倣します。
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オプションで受信機に伝えることができます。受信者は、送信者からのデータの各ウィンドウ（つまり、D <（CWND/MSS））に少なくとも1つのACK（できればそれ以上）を送信して、受信者の遅延ACKタイマーが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）は、ACCスキームに似た動的なACK遅延係数（DINALING D）を使用するTCPレシーバーサイドメカニズム[CLP98]です（セクション4.3）。TCPレシーバーは、CWND値を予測することにより、TCP送信者の輻輳制御挙動を再構築します。この値は、許可されたウィンドウとともに使用され、受信者の値を調整します。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は、現在の形式でインターネット内で使用することをお勧めしません。
4.5 Acknowledgement based on Cwnd Estimation.
4.5 CWND推定に基づく謝辞。
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.
CWND推定（ACE）[MJW00]に基づく謝辞は、TCPレシーバーでCWNDを測定し、さまざまなACK遅延係数（D）を維持しようとします。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送信者を採用しています。ウィンドウがより多くのデータを送信できる場合でも、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送信者の実装に変更が必要です。インターネットでは有益である可能性があり、ホストが送信するパケットのバーストサイズを大幅に削減します。これにより、ストレッチアクックを受信することの影響が正常に軽減されます。TCP送信者のペーシングは、パケットごとの処理コストの増加を意味し、適切な伝送速度を示唆する予測アルゴリズムが必要です。したがって、エンドホストコストとネットワークパフォーマンスの間にはパフォーマンストレードオフがあります。効率的なアルゴリズムの仕様は、継続的な研究の分野であり続けています。TCP送信者ペーシングの使用は、新しい問題を導入することは期待されていません。これは、TCPホストの実験的緩和であり、伝送の乱暴さを制御する可能性があります（たとえば、タイプ1の手法、セクション5.1.2の結果）が、現在広く展開されていません。インターネット内で現在の形式で使用することはお勧めしません。
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の数に基づいてCWNDを開くのではなく、各ACKによって認められるデータの量を考慮して、CWNDの成長を遅らせることを避けることができます。したがって、ACKがDデータパケット（またはTCPデータセグメント）を認識した場合、CWNDはD個のACKを受信したかのように成長します。これは、[RFC2581、RFC2760]をカウントするTCPバイトと呼ばれます。（単一のACKを、D ACKの代わりにD/2に相当するものとして扱うことができ、TCP遅延ACKアルゴリズムの効果を模倣できます。）このポリシーは、CWND成長が前方方向の利用可能な容量にのみ結び付けられるためだけに機能します。したがって、Acksの数は重要ではありません。
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.) 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ペーシング（セクション4.6）、およびACC（セクション4.3）の組み合わせが、受信者の重複ACKしきい値に関連しています）。主な問題は、主な問題は、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送信者の変更が必要です。最も単純な形式では、特にストレッチアクックを受信した場合、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.
したがって、[RFC2581、RFC2760]を強くお勧めします。バイトカウントスキームには、アルゴリズムが引き起こす可能性のあるTCPデータパケットの潜在的に大きなバーストを緩和する方法を含める必要があります（たとえば、TCPセンダーペーシング（セクション4.6）、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]に直接接続されたエンドホストの双方向トラフィックの性能を高めるための手法です。アップストリーム転送のデータパケットの数に制限が設定されています。言い換えれば、BottleNeckリンクキューは、TCP（送信者）層に「逆圧力」を行います。これには、現在多くのTCPスタックに展開されているものと比較して、変更された実装が必要です。バックプレッシャーにより、下流の接続のアックが上流のボトルネックに飢えないようにし、それにより下流の接続のパフォーマンスが向上します。ホスト/ルーターに実装される可能性のある同様の一般的なスキームについては、セクション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接続がBottleneckリンクを通過するために個別に識別される必要があり、アクティブな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）として知られています。単純なデバイス（ACKフィルタリングなど）から、より洗練されたデバイス（TCP接続を2つの別々のパーツに分割するステートフルデバイスなど）に至るまで、大量のPEPデバイスが存在します。このドキュメントのセクション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:
TCPヘッダー圧縮[RFC1144]（V-J圧縮と呼ばれることもあります）は、スリップまたは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) 一部の（例：ワイヤレス）サブネットワークでは、パケットサイズに依存しない重要なパケットごとのMacオーバーヘッドがあります（セクション3.2）。（ii）ACKのサイズの減少は、双方向トラフィックの存在下での大きな上流のデータパケットとの不利な相互作用を妨げません（セクション3.3）。（iii）TCPヘッダー圧縮は、IPまたはTCPオプション（IPSEC [RFC2402、RFC2406]、TCP RTTM [RFC1323]、TCP SACK [RFC2018]などを備えたパケットでは使用できません。（iv）RFC1144によって記述されたヘッダー圧縮のパフォーマンスは、圧縮パケットが失われると大幅に分解されます。長いネットワークパスで依然として大きなペナルティが発生する可能性のある改善は、[RFC2507]に記載されています。これは、低レベルのパケット損失[RFC3150]を経験するリンク（またはパス）でのみ使用する必要があることを示唆しています。（v）ヘッダー圧縮の正常な実装は、IPを使用してトンネリングをサポートするために圧縮を阻害します（例：L2TP、GRE [RFC2794]、IP-in-IP）。トンネルのカプセル化は、適切なパケットヘッダーを見つけて複雑にします。GREは内側（トンネリング）IPヘッダー[RFC2784]でヘッダー圧縮を許可しますが、パケットの損失（トンネルパスに沿ったルーターの輻輳のため）の損失は、1つの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オプション、および/またはトンネルカプセル化ヘッダーなど）。スキームは広く実装および展開され、インターネットリンクを介して使用されています。低から中程度の帯域幅の非対称性を持つパスのTCPパフォーマンスを改善することをお勧めします（例：K <10）。
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).
[RFC1144]で説明されている形式では、パケット損失のかなりの割合を示す可能性のあるリンク（またはパス）で使用されると、TCPパフォーマンスが低下します[RFC3150]。また、双方向トラフィックと上流のリンクを大幅に改善しない場合があります。したがって、帯域幅の非対称性が高いパス（例：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）。1つのテクニックセットは、上流のボトルネックリンクに接続されたルーター/ホスト内で、逆方向パス上の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は、データまたはTCPフラグが設定されているACK（Syn、RST、URG、およびFIN）を削除してはなりません。さらに、TCPのデータ駆動型損失回復回収の問題を引き起こすことを避けるために、キューから選択的ACKオプション（sack）[RFC2018]を使用して、高速再送信[RFC2581]またはACKを使用して、一連の3つの重複アクセスを削除することを避ける必要があります。メカニズム。また、ECNフィードバックの正しい動作（TCPヘッダーで運ばれる）[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をフィルタリングするためのさまざまなポリシーを使用できます。これらは、決定論的またはランダムなものである場合があります（ランダムドロップゲートウェイに似ていますが、キュー内のアイテムのセマンティクスを考慮する必要があります）。アルゴリズムは、TCP送信者ウィンドウが更新されることを保証する最小ACKレートを確保し、ストレッチACKによって認められるデータパケット（TCPセグメント）の数を制限するために提案されています。流量あたりの状態は、キュー内に少なくとも1つのパケット（Fred [LM97]に類似）を含む接続に対してのみ維持する必要があります。この状態は柔らかい[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.
遅延デュパックの望ましくない効果（セクション3.4）は、しきい値[MJW00、CLP98]を超える重複アクセスを削除することで減少させることができます。
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]。このようなスキームは、上流のリンクキューがサックブロックを備えた連続したAcksによって満たされるのを防ぐことができます。サックパケットは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フィルタリングには、アップストリームリンクインターフェイスの変更が必要です。スキームは、TCPを変更する必要性を回避することにより、追加の処理オーバーヘッド（ACKごと）が補償される場合があるいくつかのネットワークに展開されています。ACKフィルタリングは、ストレッチACKを生成し、TCPデータパケットの大きなバーストをもたらす可能性があります。したがって、それだけでは、一般的なインターネットでの使用をお勧めしません。
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フィルタリングは、ストレッチアクックの効果（つまり、コントロールTCPセンダーバーストサイズ）の効果を緩和するスキームと組み合わせて使用すると、かなりの非対称性（k> 1）および/または双方向トラフィックを伴うパスに推奨されます。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デシメーションは、標準のルーターメカニズムに基づいています。上流のBottleNeckリンクで（小さい）（小）（小）（小）（小）一人のドロップポリシー）を使用することにより、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の生成につながります。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 Decimationは、アップストリームリンクインターフェイスで標準のルーターメカニズムを使用して、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デシメーションがかなりの非対称性（k> 1）（または双方向トラフィック）のパスで使用される場合、TCP送信者のバーストサイズが増加し、ストレッチアクックまたはコントロールバーストの効果を軽減するスキームを使用することが強く推奨されます。。
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).
タイプ2の緩和は、タイプ1のアップストリームリンク帯域幅管理を実行しますが、ACK伝送のACKレートの低下と爆発の効果を軽減する2番目のアクティブな要素も採用しています。これは、エンドホストが標準のTCP送信者実装を使用する場合に望ましいことです（たとえば、セクション4.6、4.7の手法を実装していないもの）。
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).
タイプ1スキームがD TCPパケットをカバーするストレッチACKを転送するパス（つまり、確認番号がTCP送信者が受信した最後のACKよりもD*MSSが大きい場合）を考えてください。TCP送信者がこのACKを受信すると、D（またはD 1）TCPデータパケットのバーストを送信できます。送信者は、現在のCWNDによっても制約されています。受信したACKSは、CWNDを増やすのにも役立ちます（最大で1つのMSSによって）。
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].
タイプ2スキームは、タイプ1スキームが使用されたときに生じるACK周波数の減少の影響を軽減します。これは、それぞれがストレッチACKを受信する前に追加のACKを散在させることによって達成されます。追加のACKは、元のACKとともに、TCP CWNDがTCPレシーバーによって送信された元のACKのそれぞれがリバースパスによって転送されたかのように、TCP CWNDが同じ方法で開くことができるほど十分なACKをTCP送信者に提供します。さらに、ACK間の間隔を復元しようとすることにより、このようなスキームはTCPセルフクロック動作を復元し、TCP送信者バーストサイズを縮小することもできます。このようなスキームは、保守的な行動を確保する必要があります（つまり、元々送信されたよりも多くのACKを導入するべきではありません）。
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つのポイントで実行されます。アップストリームリンクインターフェイス（過剰なアックが削除される場所）と、交換用アックが挿入される逆パス（ボトルネックアップストリームリンクの後）に沿ってさらにポイントが挿入されます。これにより、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.
タイプ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は、上流のBottleNeckリンクに続く逆パスに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しきい値ACKTHRESHをMSSの2倍に設定することができます（これにより、選択したMSSがリンクで知られていると想定しています）。2つの係数は、標準のTCP遅延FACポリシー（d = 2）に対応しています。したがって、連続したACKがデルタによって分離されて到着すると、再構築者は最大（Delta/Ackthresh）-2）Ackを再生します。
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間の時間間隔）で送信する必要があります。1つの方法は、再構築者が指数関数的に重み付けされた移動平均推定器を使用して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のトレードオフは、PATH RTTのわずかな増加に対して、RTT変動の減少とともに、TCP送信者の爆発性を減らし、CWNDの増加率を高めることと、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再構成者は正しく動作します（つまり、偽のAcksを生成せず、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）を介してルーティングされます。v）パケットには追加のヘッダー情報が含まれていません（例：TCP RTTMオプション[RFC1323]、AH [RFC2402]またはESP [RFC2406]を使用した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再構成は、上流のボトルネックリンクに続く逆パスで実行される実験的な透明な変更です。タイプ1の緩和と組み合わせて使用するように設計されています。TCP伝送のバーストサイズを前方方向に削減します。これは、タイプ1のスキームが単独で使用されると増加する可能性があります。上流のリンク後の機器の変更が必要です（流量あたりのソフトステートの維持を含む）。このスキームは、ネットワークパスに関する暗黙の仮定を導入し、潜在的なサービス拒否の脆弱性（つまり、パケットアンプとして機能する）を持っています。これらは、適切なセキュリティテクニックによってよりよく理解され、対処される必要があります。
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を再生します。ただし、ARとは異なり、修正されたAF（コンパクターまたはコンプレッサーと呼ばれる）を使用しており、AFによって生成されたすべてのストレッチACKに明示的な情報が追加されます。これは、再構成操作を明示的に同期するために使用されます（ここでは拡張と呼ばれます）。
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送信者）に転送され、通常のTCP ACKクロックを保存します。このようにして、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を使用して接続の再構成を実行できません。抑制されたパケットからIPSECセキュリティ情報を明示的にエンコードすることができ、IPSEC AHで動作を可能にしますが、これは未解決の研究問題のままであり、ACKごとに追加のオーバーヘッドを意味します。
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の緩和と組み合わせて使用され、TCP伝送のバーストサイズを順方向に削減するように設計されています。これは、タイプ1のスキームが単独で使用されると増加する可能性があります。
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 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.
タイプ1スキームが逆方向パスで使用されるときに生成されるデータパケットのバーストは、フォワードパス[SEG00]で一般的なトラフィックシェーピング（GTS）をサポートするルーターを導入することにより緩和される場合があります。GTSは、多くの展開されたルーターに実装される標準のルーターメカニズムです。この手法は、TCP送信者によって生成されたデータのバーストを排除するのではなく、スケジューリングとキューイングのテクニックを使用してバーストをスムーズにしようとし、TCPペーシングが使用されるときに似たトラフィックを生成します（セクション4.6）。これらの手法では、ルーターに流入あたりのソフトステートを維持し、パケットごとの処理オーバーヘッドを増やす必要があります。形状のパケットをキューにするには、いくつかの追加のバッファ容量が必要です。
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およびマルチキャストフロー）間の公平性を促進するためにも使用できます。また、ACK圧縮の確率も低下します[ZSC91]。
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を実行するか、少なくとも最初のフォワードパスボトルネックルーターの前に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の構成は、ネットワークサービスプロバイダーのポリシー決定です。適切に構成された場合、手法はTCPデータパケットバーストのサイズを縮小し、タイプ1の手法の効果を軽減します。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の場合の接続キューごと）を使用することを意味します。フローごとのキューイング（FQ、CBQなど）は、スローリンク（パケットを送信する時間がパスRTTのかなりの部分を形成する場合）で使用すると利益を提供します[RFC3150]。タイプ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つのデータパケットがアップストリームリンクキューで待機していると仮定します）。これにより、少なくとも逆方向に流れる能力の一定の最小シェアが保証され、前方向に流れが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]。HTTP [SEG00]などの複数のACKストリームを使用して、より高度なスキーム（WFQなど）を使用するためにも使用できます。
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].
Acks-Firstスケジューリングは、双方向転送のパフォーマンスを改善するための実験的手法です。この場合、データパケットとACKは、上流のボトルネックリンク[RFC3150]でリソースを競います。データパケットとACKの両方の最初の最初のファーストアウト、FIFO、キューは、フォワード転送のパフォーマンスに影響を与える可能性があります。たとえば、上流のボトルネックリンクが28.8 kbpsダイヤルアップラインの場合、1 kbyteサイズのデータパケットの送信には約280ミリ秒かかります。したがって、そのようなデータパケットが2つだけAcksに先んじてキューに入っていたとしても（データパケットがスロースタート中にペアで送信されるため、珍しいことではありません）、彼らはACKをかなり半秒以上シャットアウトします。ACKの前に2つ以上のデータパケットがキューに登録されている場合、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をスケジュールすることです。特に、1つのアルゴリズムはACKSファーストスケジューリングです。これは、データパケットよりも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.
ACKSファーストスケジューリングは、送信のデータパケットによる遅延を回避するのに役立ちません。この場合、リンクの断片化または一時停止/履歴書が有益である場合があります。
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.
推奨事項：Acks-Firstスケジューリングは、上流のBottleNeckリンクで実行される実験的な透明な変更です。ACKの量を調節するためにメカニズム（ACK輻輳制御（ACC）、セクション4.3など）なしで使用されると、データパケットの飢vにつながる可能性があります。これは、リンクを使用してエンドホストが経験するパフォーマンスペナルティであり、インターネットの混雑行動を変更しません。実験は、ACKファーストスケジューリングとACCと組み合わせて有望であることを示しています。ただし、より広いインターネットでこの手法を使用する経験はほとんどありません。この手法のさらなる開発は依然としてオープンな研究問題であるため、インターネット内での使用は現在推奨されていません。
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.
(i) IPSEC ESP [RFC2406]を使用してIPペイロードを暗号化する場合、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は、宛先ホストを含む、パスに沿ったシステムのリターンパスおよび処理リソースの容量を消費します。これにより、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.
このドキュメントでは、IPネットワークを介した前方パスと逆パスのプロパティの非対称性から生じるいくつかのTCPパフォーマンス制約を考慮します。このようなパフォーマンスの制約は、たとえば、帯域幅（容量）非対称性、非対称共有メディアの逆方向に、メディアアクセス制御（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.
パフォーマンスの改善を提供する一連の手法が調査されます。これらには、TCPセルフクロックを破壊することなくTCP送信者が頻繁にACKに対処できるようにするACKの混雑とテクニックを軽減する手法が含まれます。これらの手法には、エンドツーエンド、ローカルリンク層、およびサブネットワークスキームの両方が含まれます。これらの手法の多くは、インターネットの一部を形成する非対称サブネットワークの分析、シミュレーション、および/または実装によって詳細に評価されています。ただし、いくつかのテクニックにはまだ不十分な運用経験があります。したがって、これらは現在、進行中の研究と実験の項目のままです。
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.
次の表は、現在の推奨事項をまとめたものです。メカニズムは、推奨される（rec）に分類され、推奨されない（recではなく）または実験的（exp）。実験手法はよく指定されていない場合があります。これらの手法では、パブリックインターネットでの使用をお勧めする前に、さらなる運用エクスペリエンスが必要になります。
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は、順方向に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手法の実装では、エンドホストのプロトコルスタックの内部設計の変更が必要になる場合があります。*2過剰なTCP伝送バーストを防ぐためのスキームに依存します。
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のパフォーマンスを低下させる可能性がありますが、インターネットに有害とは見なされません。*2新しいTCP圧縮プロトコルの標準化は、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）ワーキンググループのパフォーマンスへの影響のメンバーからのコメントの恩恵を受けています。特に、著者は、ジョン・ボーダー、スペンサー・ドーキンス、アーロン・フォーク、ダン・グロスマン、ランディ・カッツ、ジェフ・マンディン、ロッド・ラグランド、ラモン・セグラ、ジョー・タッチ、ロイド・ウッドに有用なコメントに感謝したいと思います。また、Packet Data Networkの操作に関して、Metricom Inc.が提供するデータも認めています。
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] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144] Jacobson、V。、「低速シリアルリンクのTCP/IPヘッダーの圧縮」、RFC 1144、1990年2月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。and W. Stevens、「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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。およびP. Traina、「Generic Routing Cancapstulation（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] Border、J.、Kojo、M.、Griner、J.、Montenegro、G。、およびZ. Shelby、「リンク関連の分解を緩和することを目的としたプロキシを向上させるパフォーマンス」、RFC 3135、2001年6月。
[abc-ID] Allman, M., "TCP Congestion Control with Appropriate Byte Counting", Work in Progress.
[ABC-ID] Allman、M。、「適切なバイトカウントを伴うTCP混雑制御」、進行中の作業。
[All97b] Allman, M., "Fixing Two BSD TCP Bugs", Technical Report CR-204151, NASA Lewis Research Center, October 1997.
[All97b] Allman、M。、「2つのBSD TCPバグの修正」、テクニカルレポートCR-204151、NASA Lewis Research Center、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] Arora、V.、Suphasindhu、N.、Baras、J.S。D. Dillon、「衛星 - 地球上のネットワークを介した非対称インターネットアクセス」、Proc。AIAA：第16回国際通信衛星システム会議と展示、パート1、ワシントンD.C.、1996年2月25〜29日、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] Aggarwal、A.、Savage、S。、およびT. Anderson、「TCPペーシングのパフォーマンスの理解」、Proc。IEEE Infocom、Tel-Aviv、イスラエル、v.3、2000年3月、pp。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] Balakrishnan、H。、「不均一なワイヤレスネットワークを介した信頼できるデータ輸送への課題」、Ph.D。論文、カリフォルニア大学バークレー校、米国、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] Balakrishnan、H.、Padmanabhan、V。N.、およびR. H. Katz、「TCPパフォーマンスに対する非対称性の影響」、ACMモバイルネットワークとアプリケーション（MONET）、Vol.4、No.3、1999、pp。219-241。Procで公開された論文の拡張バージョン。ACM/IEEE Mobile Communications Conference（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] Bennett、J。C.、Partridge、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] Clark、D.D、「DARPAインターネットプロトコルの設計哲学」、ACM Computer Communications Review（CCR）、Vol。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.、Linder、H。、およびB. Collini-Nocker、「インターネットオーバーブロードキャスト衛星」、IEEE Communications Magazine、Vol。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.、Linares、J。、およびJ. Paradells、「ワイヤレス非対称リンクでTCPを改善するためのウィンドウ予測メカニズム」。Proc。IEEE Global Communications Conference（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] Cohen、R。、およびRamanathan、S。、「ハイブリッドファイバーの同軸ブロードバンドアクセスネットワークの高性能のTCPの調整」、IEEE/ACMトランザクション、Vol.6、No.1、1998、pp。15-29。
[DS00] Cable Television Laboratories, Inc., Data-Over-Cable Service Interface Specifications---Radio Frequency Interface Specification SP-RFIv1.1-I04-00407, 2000
[DS00] Cable Television Laboratories、Inc.、Data-Over-Cable Cable Service Interface仕様---無線周波数インターフェイス仕様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、Cable Television Laboratories、Inc.、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] Durst、R.、Miller、G。、およびE. Travis、「TCP拡張のための宇宙通信」、ACM/IEEEモバイルコミュニケーション会議（MOBICOM）、ニューヨーク、米国、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仕様」、European Standard（Telecommunications Series）EN 301 192、1997。
[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] Floyd、S。、およびV. Jacobson、「混雑回避のためのランダムな早期検出ゲートウェイ」、IEEE/ACMトランザクション、Vol.1、No.4、1993、pp.397-413。
[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、N.K.G、Sooriyabandara、M.、Harun、H.、Hodson、K。、およびR. Donardio、「ブロードバンド衛星を使用した非対称サービス提供におけるパフォーマンスの問題」.148、No.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推奨e.681、「ハイブリッドファイバー/同軸システムに基づくIPアクセスネットワークのトラフィックエンジニアリング方法」、2001年9月。
[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] Jacobson、V。、「混雑の回避と管理」、Proc。ACM SIGCOMM、カリフォルニア州スタンフォード、ACMコンピューターコミュニケーションレビュー（CCR）、Vol.18、No.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] Kent C.A.、およびJ. C. Mogul、「断片化は有害と考えられている」、Proc。ACM SigComm、米国、ACMコンピューターコミュニケーションレビュー（CCR）、Vol.17、No.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. Goldstein、「プロトコルに対する非対称衛星ネットワークの効果」、Proc。IEEE軍事コミュニケーション会議（MILCOM）、米国マサチューセッツ州ブラッドフォード、Vol.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.、Varma、A。、およびRamakrishnan、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] Lin、D。、およびR. Morris、「ランダムアーリー検出のダイナミクス」、Proc。ACM SIGCOMM、カンヌ、フランス、ACMコンピューターコミュニケーションレビュー（CCR）、Vol.27、No.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] Lakshman、T.V.、Madhow、U。、およびB. Suter、「ゆっくりとした確認チャネルによるウィンドウベースのエラー回復とフロー制御：TCP/IPパフォーマンスの研究」、Proc。IEEE Infocom、Vol.3、Kobe、Japan、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] Ming-Chit、I.T.、Jinsong、D。、およびW. Wang、「非対称ネットワーク上のTCPパフォーマンスの改善」、ACM Sigcomm、ACM Computer Communications Review（CCR）、Vol.30、No.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
[PAD98] Padmanabhan、V.N。、「Webデータトランスポートの課題への対処」、博士号論文、カリフォルニア大学バークレー校、米国、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] Jacobson、V.、Braden、R。およびD. Borman、「TCP拡張機能のためのTCP拡張」、RFC 1323、1992年5月。
[RFC2018] Mathis, B., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018] Mathis、B.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Auncement Options」、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] Kent、S。およびR. Atkinson、「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. Pink、「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] Paxson、V.、Allman、M.、Dawson、S.、Heavens、I.およびB. Volz、「既知のTCP実装問題」、RFC 2525、1999年3月。
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[RFC2686] Bormann、C。、「マルチリンクPPPへのマルチクラス拡張」、RFC 2686、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] Allman、M.、Dawkins、S.、Glover、D.、Griner、J.、Henderson、T.、Heidemann、J.、Kruse、H.、Ostermann、S.、Scott、K.、Semke、J.、Touch、J。およびD. Tran、「衛星に関連する進行中のTCP研究」、RFC 2760、2000年2月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[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.、Fujii、N。およびY. Zhang、「単方向リンクのためのリンク層トンネルメカニズム」、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] 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。、およびH. Zheng、 "堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP ESPおよび非圧縮」、RFC 3095、2001年7月。
[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] Dawkins、S.、Montenegro、G.、Kojo、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] Ramakrishnan K.、Floyd、S。およびD. Black、「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 Computer Communications Review（CCR）、Vol.29、No.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] Segura 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 International Networks Conference（INC98）、Plymouth、UK、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] Zhang、L.、Shenker、S。、およびD. D. Clark、「渋滞制御アルゴリズムの観察とダイナミクス：双方向トラフィックの影響」、Proc。ACM Sigcomm、ACM Computer Communications Review（CCR）、Vol 21、No 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サービス。このようなネットワークでは、ネットワークのハブアンドスポークアーキテクチャ（たとえば、複数のモバイルステーションと通信する単一のベースステーション）から、主なネットワークパスの非対称性が生じます。）ラジオの重要なターンアラウンド時間に対応する必要があるプロトコルと中程度のアクセス制御（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]は、いずれかの需要を使用して、狭帯域の上流リンク（2.4〜9.6 kbpsなど）を備えた大容量の下流の衛星リンク（2〜3 Mbpsなど）を使用して、輸送中または孤立したホスト[SEG00]へのインターネットアクセスを提供します。マルチアクセス（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].
- ケーブルテレビネットワーク上のほとんどのデータ（例：DocSI [ITU01、DS00]）。上流通信に割り当てられたアナログチャネル（つまり、逆方向）は狭く、ダウンストリームリンクに割り当てられたものよりも騒がしい場合があります。結果として、上流と下流のリンクの伝達速度が異なります。たとえば、DOCSIS 1.0 [DS00]では、下流の透過率は27または52 Mbpsです。上流の伝送速度は、166 kbps〜9 Mbpsの範囲の一連のレートの1つに動的に選択できます。オペレーターは、下流チャネルごとに複数の上流チャネルを割り当てることができます。物理層（PHY）オーバーヘッド（上流の送信に伴うが、下流のリンクには存在しない）も、ネットワークパスの非対称性を増加させる可能性があります。通常、TCPを運ぶために使用される最良の努力サービスは、競合/予約MACプロトコルを使用します。上流のリンクに孤立したパケット（TCP ACKなど）を送信するケーブルモデム（CM）は、中央ケーブルモデム終端システム（CMTS）から容量を要求するために他のCMSと争う必要があります。その後、CMTSは、アップストリームトランスミッションのためにタイムスロットをCMに付与します。CMは、その後のリクエストを上流パケットに「ピギーバック」する場合があり、競合サイクルを回避します。その結果、ケーブルデータネットワークの負荷とTCPデータパケットの攻撃時間の間でのわずかな変動により、TCP ACKの間隔を劇的に変更できます。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テクノロジースクエアマサチューセッツテクノロジーケンブリッジ、マサチューセッツ州02139 USA
Phone: +1-617-253-8713
EMail: hari@lcs.mit.edu
Web: http://nms.lcs.mit.edu/~hari/
Venkata N. Padmanabhan Microsoft Research One Microsoft Way Redmond, WA 98052 USA
Venkata N. Padmanabhan Microsoft Research One Microsoft Way Redmond、WA 98052 USA
Phone: +1-425-705-2790
EMail: padmanab@microsoft.com
Web: http://www.research.microsoft.com/~padmanab/
Godred Fairhurst Department of Engineering Fraser Noble Building University of Aberdeen Aberdeen AB24 3UE UK
GodRed Fairhurst Engineering Department Fraser Noble Building Aberdeen University of Aberdeen AB24 3UE UK
EMail: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/gorry
Mahesh Sooriyabandara Department of Engineering Fraser Noble Building University of Aberdeen Aberdeen AB24 3UE UK
Mahesh Sooriyabandara工学部Fraser Noble Building of Aberdeen University Aberdeen AB24 3UE UK
EMail: mahesh@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/mahesh
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。