RFC3449 日本語訳
3449 TCP Performance Implications of Network Path Asymmetry. H.Balakrishnan, V. Padmanabhan, G. Fairhurst, M. Sooriyabandara. December 2002. (Format: TXT=108839 bytes) (Also BCP0069) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
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
Balakrishnanがコメントのために要求するワーキンググループH.をネットワークでつないでください: 3449MIT LCS BCP: 69V.N.Padmanabhanカテゴリ: アバディーンの最も良い現在の習慣の研究G.Fairhurst M.Sooriyabandaraマイクロソフト大学、イギリスの2002年12月
TCP Performance Implications
of Network Path Asymmetry
ネットワーク経路非対称のTCPパフォーマンス含意
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
ドキュメントはいくつかの緩和をこれらの効果に詳しく述べます。(文学で提案されるか、評価される、または効果は現在、ネットワークで配布されました)。 以下から成って、これらのソリューションはローカルのリンクレイヤのテクニック、サブネットワーク、および終わりから終わりへのメカニズムの組み合わせを使用します。 (i) 上流のボトルネックに使用されるチャンネルを管理するテクニックはACKsを運びながら、リンクされます、ヘッダー圧縮を通常使用するか、またはTCP ACKs(反対の方向へのデータとACKパケットが両面交通があるとき性能を向上させる計画をするようにTCP送付者の承認で引き起こされた自己時計と(iii)のテクニックを保有するためにこの減少しているACK頻度に扱う(ii)のテクニック)の頻度を減少させて 各テクニックは知られている問題、および使用のための推薦と共に説明されます。 ドキュメントの端で推薦の概要を提供します。
Balakrishnan et. al. Best Current Practice [Page 1] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[1ページ]RFC3449PILC--非対称のリンクス2002年12月
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
1. このDocumentで中古のコンベンション…3 2. 動機…4 TransmitとReceive CapacityのDifferencesへの2.1非対称支払われるべきもの…4 Reverse DirectionのSharedメディアへの2.2非対称支払われるべきもの…5 2.3 一般的問題…5 3. Asymmetry Degrade TCPパフォーマンスはどのようにそうしますか? .....................5 3.1 非対称の容量…5 3.2 MACは相互作用について議定書の中で述べます…7 3.3 双方向のトラフィック…8 非対称のネットワーク経路の3.4の損失…10 4. TCPパフォーマンス使用を改良して、緩和を主催してください…4.1が変更した10はACKsを遅らせました…11 4.2 大きいMSSの使用…12 4.3 ACK輻輳制御…13 4.4ウィンドウ予測メカニズム…14 4.5 承認はCwnd Estimationを基礎づけました。 ...................14 4.6 TCP送付者ペース…14 4.7TCPバイト勘定…15 4.8背圧…16 5. Transparent Modificationsを使用することでTCP性能を向上させます…17 5.1 0はタイプします: ヘッダー圧縮…18 5.1 .1 TCPヘッダー圧縮…18 5.1 .2 強健なヘッダー圧縮アルゴリズムを交替してください…19 5.2は1をタイプします: リンク帯域幅管理を逆にしてください…19 5.2 .1ACKフィルタリング…20 5.2 .2 ACK大量殺害…21 5.3 2はタイプします: 取り扱いの珍しいACKs…22 5.3 .1 ACK再建…23 5.3 .2のACK圧縮と圧伸…25 5.3 .3 Infrequent ACKsによって生成されたTCPパケット炸裂を緩和します…26 5.4 3はタイプします: 上流のリンクスケジューリング…27 5.4 .1 Upstream Bottleneck Linkに列を作る流れ…27 5.4 .2 ACKs-最初のスケジューリング…28 6. セキュリティ問題…29 7. 概要…30 8. 承認…32 9. 参照…32 10. IANA問題…37付録: ネットワーク経路非対称を示すサブネットワークに関する例…38人の作者のアドレス…40 完全な著作権宣言文…41
Balakrishnan et. al. Best Current Practice [Page 2] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[2ページ]RFC3449PILC--非対称のリンクス2002年12月
1. Conventions used in this Document
1. このDocumentで使用されるコンベンション
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].
DELAYED ACK FACTOR、d: TCP ACKによって承認されたTCPデータ・セグメントの数。 dの最小値は1です、各データ・パケット[RFC1122、RFC2581]のために最も1つでACKを送るべきであるので。
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を伸ばしてください: 伸びACKsは以前に不承認のデータ(d>2)[RFC2581]の2つ以上のセグメントをカバーする承認です。 伸びACKsは実装バグ[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].
NORMALIZED BANDWIDTH RATIO、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
SOFTSTATE: プロトコル[Cla88]によって使用されるネットワークデバイスに設置された1流れあたりの状態。 すなわち、状態が期間の後に期限が切れる、(セッションであるときに、明らかに削除されるのが必要ではありません。
Balakrishnan et. al. Best Current Practice [Page 3] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[3ページ]RFC3449PILC--非対称のリンクス2002年12月
expires), and is continuously refreshed while a flow continues (i.e., lost state may be reconstructed without needing to exchange additional control messages).
期限が切れる、)、流れが続いている間(追加コントロールメッセージを交換する必要はなくて、すなわち、無くなっている状態は再建されるかもしれません)、絶え間なくリフレッシュされます。
2. Motivation
2. 動機
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ケーブルテレビネットワーク[DS00、DS01])、直接放送衛星(例えば、対話的な帰路チャンネルでDigital Video Broadcast、DVB[EN97]を使用するIPサービス)、Very Small Aperture衛星Terminals(VSAT)、非対称デジタル加入者線伝送方式(ADSL)[ITU02、ANS01]、およびいくつかのパケット無線ネットワークを含んでいて。 これらのネットワークはますます高速インターネット・アクセスネットワークとして配布されています、そして、したがって、良いTCP性能を達成するのは非常に望ましいです。 しかしながら、ネットワーク経路の非対称はしばしばこの挑戦を作ります。 非対称を示すいくつかのネットワークに関する例をAppendixに提供します。
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フィードバックはTCP性能を順方向に下げます。 基本的なMedium Access Control(MAC)とPhysical(PHY)プロトコルにおける非対称で同様に、TCP ACKsを伝えるのが高価になるかもしれない、(不均衡である、彼らのサイズ) 容量が左右対称であると、同等です。
2.1 Asymmetry due to Differences in Transmit and Receive Capacity
2.1 TransmitとReceive CapacityのDifferencesによる非対称
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層(例えば、Guaranteed Service[RFC2212])において、または、サブネット層(例えば、ADSLの上でDOCSIS[DS01]でのUnsolicitedグラントのサービス、またはATMのCBR仮想接続を利用するボイス・オーバー IP[ITU01]のサポート[ITU02、ANS01])にサービス保証を含んでいます。
When multiple upstream links exist the asymmetry may be reduced by dividing upstream traffic between a number of available upstream links.
複数の上流のリンクが存在するとき、非対称は多くの利用可能な上流のリンクの間の分割の上流のトラフィックによって減少させられるかもしれません。
Balakrishnan et. al. Best Current Practice [Page 4] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[4ページ]RFC3449PILC--非対称のリンクス2002年12月
2.2 Asymmetry due to Shared Media in the Reverse Direction
2.2 Reverse DirectionのSharedメディアによる非対称
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プロトコルを使用することで1パケットあたりの帯域幅を要求しなければならないという(例えば、DOCSIS1.0MACは各ノードをそれぞれの上流の時間分割間隔[DS00]で単一のパケットを高々送るのに制限します)要件によって上流の容量はさらに制限されるかもしれません。 衛星は、Demand(BoD)に雇用のダイナミックなBandwidthをネットワークでつないで、また、各パケットのためのリソースが送ったMAC(例えば、[EN00])を消費します。 これらの体系では、有効なアップリンク容量はMACアルゴリズムの機能です。 また、MACとPHY体系は脆いパケット(TCP ACKsを含んでいる)を伝えるのがMTUサイズのデータ・パケットを伝えるのと同じくらい高価になるほど重要であるかもしれない上流のトランスミッションあたりのオーバーヘッドを導入します。
2.3 The General Problem
2.3 一般的問題
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フィードバックの欠点と可変性。 このドキュメントは、詳細に問題について議論して、規制を抑えるか、または取り除くかもしれないいくつかのテクニックについて説明します。
3. How does Asymmetry Degrade TCP Performance?
3. Asymmetry Degrade TCPパフォーマンスはどのようにそうしますか?
This section describes the implications of network path asymmetry on TCP performance. The reader is referred to [BPK99, Bal98, Pad98, FSS01, Sam99] for more details and experimental results.
このセクションはTCP性能のときにネットワーク経路非対称の含意について説明します。 読者はその他の詳細と実験結果について言及されます[BPK99、Bal98、Pad98、FSS01、Sam99]。
3.1 Asymmetric Capacity
3.1 非対称の容量
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)の損失を防ぐことができるくらいの列を作るのがあって、上流のボトルネックリンクに小さいバッファがあるとき。 それぞれが順番に考えられます。
Balakrishnan et. al. Best Current Practice [Page 5] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[5ページ]RFC3449PILC--非対称のリンクス2002年12月
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)の強い関数です。 例えば、川下のリンクと50Kbps上流がリンクする10Mbpsに関して、生の容量比は200です。 1000年のバイトのデータ・パケットと40バイトのACKsと共に、パケットサイズの比率は25です。 これは、kが200/25 = 8であることを含意します。 したがって、受信機が、1ACKより頻繁に8つの(k)データ・パケット毎、上流のリンクがそうすると認めるなら、川下のリンクの前で飽和するようになってください、順方向のスループットを制限して。 達成された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.
ACKsが下げられないか、そして、(上流のボトルネックリンクで)k>1か遅れたACKsが使用されているときのk>0.5[RFC1122]、TCP ACK-時計中断がダウンします。 2つのデータが送付者によって間断なく伝えられたパケットであると考えてください。 受信機への途中で、最も小さいボトルネックリンクの順方向への容量に従って、これらのパケットは離れて区切られます。 ACK時計の原則はこれらのデータ・パケットを受けることに対応して生成されたACKsがこの時のスペースを送付者にいっぱいに映し出すということです、同じスペース[Jac88]を維持する新しいデータ・パケットを伝えるのを可能にして。 ACK、遅れることでACKsの時間を計って、実際にACKsの引き金となるデータ・パケットの間のスペースを反映します。 しかしながら、上流のボトルネックルータにおける限られた上流の容量と列を作りは、逆の経路の相互ACKスペースを変わらせて、したがって、送付者で観測されたそれを変わらせます。 ACKsがリンクがサポートすることができるより速いレートで上流のボトルネックリンクに到着するとき、彼らはお互いの後ろに列に並ばせられます。 リンクから現れるとき、それらの間のスペースは、それらの元のスペースに関して膨張させられて、上流のボトルネック容量の関数です。 その結果、TCP送付者が、より遅いレートで新しいデータ・パケットの仕事を終える、ACKsの列を作りがなかったなら。 接続の実績はもう川下のボトルネックリンクだけに依存していません。 代わりに、それは到着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番目の副作用は起こります。 飽和したリンクはパケットの永続的な列を作りを引き起こします、ボトルネックリンクを使用することですべての終わりのホストによって観測された増加する経路Round Trip Time(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を収容する比較的少な量のバッファ領域があるとき、異なった状況は起こります。 トランスミッションウィンドウが成長するとき、この待ち行列はいっぱいになります、そして、ACKsは下げられます。 受信機があらゆるパケット、あらゆるkの1つだけを承認するつもりであったなら
Balakrishnan et. al. Best Current Practice [Page 6] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[6ページ]RFC3449PILC--非対称のリンクス2002年12月
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:
ACKsは送付者に通じるでしょう、そして、残っている(k-1)はバッファオーバーフローのため上流のリンクバッファで下げられます(ここで、kは従来と同様正常にされた帯域幅比です)。 この場合、逆のボトルネックリンク容量の、そして、遅いACK到着率は直接どんな降格している性能にも原因となりません。 しかしながら、ACKsのまれなことは降格している性能の3つの理由に通じます:
1. The sender transmits data in large bursts of packets, limited only
by the available cwnd. If the sender receives only one ACK in k,
it transmits data in bursts of k (or more) packets because each
ACK shifts the sliding window by at least k (acknowledged) data
packets (TCP data segments). This increases the likelihood of
data packet loss along the forward path especially when k is
large, because routers do not handle large bursts of packets well.
1. 送付者は単に利用可能なcwndによって制限されたパケットの大きい炸裂でデータを送ります。 少なくともk(承認される)のデータ・パケット(TCPデータ・セグメント)で各ACKが引窓を移動させるので、送付者がkに1ACKだけを受け取るなら、それは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によって承認されるかによって増強するのではなく、彼らが受けるACKsの数を数えることによって、それらのcwndを増強します。 後のまた、(セクション4.7)を数えるバイトとして知られているアプローチは輻輳回避の期間[RFC2581]のcwnd増加のための標準の実装オプションです。 したがって、より少ないACKsが長時間の遅延接続の上で性能を下げる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. ACKsが無くなるとき、TCPの送付者Fast RetransmissionとFast Recoveryアルゴリズム[RFC2581]はそれほど効果的ではありません。 受信機がDupACK敷居(>3DupACKs)[RFC2581]よりもう少し伝わっても、送付者はことによると写しACKsの敷居番号を受け取らないかもしれません。 その上、送付者はことによるとFast Recoveryの間、適切にcwndをふくらませることができるくらいの写しACKsを受け取らないかもしれません。
3.2 MAC Protocol Interactions
3.2 MACプロトコル相互作用
The interaction of TCP with MAC protocols may degrade end-to-end performance. Variable round-trip delays and ACK queuing are the main symptoms of this problem.
MACプロトコルとのTCPの相互作用は終わりから終わりへの性能を下げるかもしれません。 可変往復の遅れとACKの列を作りはこの問題の主な症状です。
One example is the impact on terrestrial wireless networks [Bal98]. A high per-packet overhead may arise from the need for communicating link nodes to first synchronise (e.g., via a Ready To Send / Clear to Send (RTS/CTS) protocol) before communication and the significant turn-around time for the wireless channel. This overhead is variable, since the RTS/CTS exchange may need to back-off exponentially when the remote node is busy (e.g., engaged in a conversation with a different node). This leads to large and variable communication latencies in packet-radio networks.
1つの例が地球のワイヤレス・ネットワーク[Bal98]の影響です。 1パケットあたり1つの高いオーバーヘッドがコミュニケーションの前に最初に連動する(例えば、Ready To Send/Sendに明確な(RTS/CTS)プロトコルで)リンクノードを伝える必要性とワイヤレスのチャンネルに、重要なターンアラウンドタイムから起こるかもしれません。 このオーバーヘッドは可変です、RTS/CTS交換が、遠隔ノードが忙しいときに(例えば、異なったノードとの会話に従事しています)、指数関数的に引き返す必要があるかもしれないので。 これはパケット無線ネットワークで大きくて変化するコミュニケーション潜在に通じます。
Balakrishnan et. al. Best Current Practice [Page 7] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[7ページ]RFC3449PILC--非対称のリンクス2002年12月
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.
非対称のワークロード(上流のトラフィックより川下の多くの)でいくつかのワイヤレスのノード(結局特にホストモデム)にACKsを列に並ばせるかもしれません、変化する潜在を悪化させて。 また、列を作りは他の共有されたメディア、例えば、ケーブルモデムアップリンク(共有された衛星チャンネルの上にしばしば使われた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主張問題は彼らのサイズよりむしろ伝えられたパケット(例えば、ACKs)の数の重要な関数です。 言い換えれば、パケットサイズにかかわらずパケットを伝えることへの多大な費用があります。
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年にRicochetパケット無線ネットワークで伝導しました、そして、1997はラジオターンアラウンドの影響を示しました、そして、対応はRTTの可変性を増強しました、降格しているTCP性能をもたらして。 TCP接続が9--12秒のタイムアウトを経験するのが、珍しくなかった、その結果、多くの接続が彼らの生涯(例えば、時々総転送時間の35%)の重要な部分の間、無駄でした。 これは有効な容量の下の利用に通じます。 また、これらの効果は他のワイヤレスのサブネットワークに起こるかもしれません。
3.3 Bidirectional Traffic
3.3 双方向のトラフィック
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接続だけが考えられます。 多くの実用的な場合では、混雑のレベルを増強して、いくつかの同時接続が、有効な容量を共有する必要があります。
Balakrishnan et. al. Best Current Practice [Page 8] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[8ページ]RFC3449PILC--非対称のリンクス2002年12月
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で検討された効果を作ります、上流のリンク帯域幅の一部が逆の転送で消費されるので。 事実上、これは帯域幅非対称の度合いを増強します。 また、他の効果は逆の転送のデータ・パケットと前進の転送のACKsとの相互作用のため起こります。 前進のTCP接続が開始されるとき逆のTCP接続が既にボトルネック上流のリンクをデータ・パケットに浸したと仮定してください。 その時、新しい前進のTCP接続の多くのACKsが完全な上流のリンクバッファに遭遇して、したがって、下げられるという高い確率があります。 これらが問題に頭文字をつけた後にさえ、逆の接続の大きいデータ・パケットの後ろに前進の接続のACKsを列に並ばせることができました。 より大きいデータ・パケットは対応する長いトランスミッション時を過すかもしれません(例えば、28.8キロビット毎秒系列の上に1つのキロバイトデータ・パケットを伝えるのにおよそ280msを要します)。 これで、前進の転送は長期間の間、遅らせられます。 単に前進の接続が急速に進歩して、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.
ACKsがかなりの期間に他の交通の後ろに列に並ばせられるとき、TCP交通と自己を連動させる効果の炸裂本質はACK Compression[ZSC91]として知られている効果をもたらすことができます。ACK CompressionはTCPに関するスループットを減らします。 それは、時間内に、一連のACKsであるときに、起こって、他のパケット(例えば同じ方向に移動するデータ・パケット)の炸裂の後ろに一方向へ列に並ばせられて、圧縮されるようになります。 これはもう片方の方向へのデータ・パケットの激しい炸裂をもたらします、サーバに到着する圧縮されたACKsの炸裂に対応して。詳細に双方向の交通にこの現象を調査してあって、最近の分析作業[LMS97]は、また、ACK Compressionが非対称に伴う双方向のトランスミッションから生じるかもしれないと予測して、実用的な非対称の衛星サブネットワーク[FSS01]に認められました。 極端な非対称(k>>1)の場合では、相互ACKスペースは列を作り(セクション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 Congestionのレベルを増加させます。 双方向の交通の存在は逆の指示接続の(大きい)のデータ・パケットと順方向接続のACKsとの不利な相互作用のために帯域幅非対称によって導入された規制を悪化させます。
Balakrishnan et. al. Best Current Practice [Page 9] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[9ページ]RFC3449PILC--非対称のリンクス2002年12月
3.4 Loss in Asymmetric Network Paths
3.4 非対称のネットワーク経路の損失
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パケットをもたらします。 一般に、伸びACKs[CR98、FSS01]をもたらすので、ACKsの損失はデータの喪失パケットほど重要ではありません。
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]は別の複雑さに通じることができます。 混雑、またはリンクの損失によるフォワードパスのいくつかの無線のリンクに、一般的なデータの喪失パケットは多くの背中合わせの写しACKs(または、TCP SACKパケット[RFC2018])を発生させるでしょう、損失に続くそれぞれの正しく容認されたデータ・パケットのために。 TCP送付者は損失から回復するのに、Fast RetransmissionとRecovery[RFC2581]を使いますが、これがうまくいっても、再送されたデータ・セグメントへのACKは上流のリンクバッファにまだ列に並ばせられていた他の写しACKsでかなり遅れるかもしれません。 これは結局、タイムアウト[RFC2988]とTCP Slow Startの時期尚早な端[RFC2581]に通じることができます。 これは不十分なフォワードパススループットをもたらします。 セクション5.3は、これを打ち返すためにいくつかの緩和について説明します。
4. Improving TCP Performance using Host Mitigations
4. ホスト緩和を使用することでTCP性能を向上させます。
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番目はACKsとことによると他の交通で使用される上流のボトルネックリンクの容量を管理することです。 反対の方向に流れるACKsの数を減少させることによって利く多くのテクニックが存在しています。 これには、潜在的に新しいデータ・パケットのトランスミッションが入って来るACKsによって引き起こされる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)を求めます、そして、1組はTCP送付者と受信機(セクション4.2、4.3)の両方への変化を求めます。 1つのテクニックが受信ホスト(セクション4.8)で送付者変更を必要とします。 しかしながら、テクニックは独自に使用されるかもしれなくて、数セットのテクニックは補足的です、ただ一つのTCP Sender Adaptation計画[BPK99]に投げ込まれた例えば、ペース(セクション4.6)とバイトが重要であることで(セクション4.7)。
Balakrishnan et. al. Best Current Practice [Page 10] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[10ページ]RFC3449PILC--非対称のリンクス2002年12月
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を使う中央箱かプロトコルEnhancing Proxyで中古(PEP)の[RFC3135]はそうです。 このドキュメントはPEPsに関して問題に取り組みません。 セクション4はいくつかのテクニックについて説明します。(テクニックは終わりから終わりへの変化を必要としません)。
4.1 Modified Delayed ACKs
4.1 変更された遅れたACKs
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]州は「承認を遅らせました」。 このアルゴリズムを使用して、2番目の完全サイズのセグメントが与えられたタイムアウト(500ms[RFC1122]を超えてはいけなくて、通常、200未満msである)の中で到着しないなら、ACKは少なくともあらゆる2番目の完全サイズのセグメント(d=2)のために発生します。 後者の規制(すなわち、d>2を許容する)を弛緩すると、Stretch ACKs[RFC2760]は発生するかもしれません。 これは可能な緩和を提供します。(緩和はACKsが受信機によって返されるレートを低下させます)。implementerは含意[RFC2581]の熟慮の後にこの要件から逸れるだけであるはずです。
Reducing the number of ACKs per received data segment has a number of undesirable effects including:
持っていて、:容認されたデータ・セグメントあたりのACKsについて数を減らすのにおいて多くの望ましくない効果があります。
(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) TCPがcwnd(iii)を開く増加する経路RTT(ii)増加する時間はTCP送付者放出量を増加させました、cwndが、より大きいステップで開くので
In addition, a TCP receiver is often unable to determine an optimum setting for a large d, since it will normally be unaware of the details of the properties of the links that form the path in the reverse direction.
通常気づかなくなるので、反対の方向に経路を形成するリンクの特性の細部にさらに、TCP受信機が大きいdのためにしばしば最適な設定を決定できないのを気づきませんいてください。
RECOMMENDATION: A TCP receiver must use the standard TCP algorithm for sending ACKs as specified in [RFC2581]. That is, it may delay sending an ACK after it receives a data segment [RFC1122]. When ACKs are delayed, the receiver must generate an ACK within 500 ms and the ACK should be generated for at least every second full sized segment (MSS) of received data [RFC2581]. This will result in an ACK delay factor (d) that does not exceed a value of 2. Changing the algorithm would require a host modification to the TCP receiver and awareness by the receiving host that it is using a connection with an asymmetric path. Such a change has many drawbacks in the general case and is currently not recommended for use within the Internet.
推薦: TCP受信機は指定されるとしてのACKsを送るための標準のTCPアルゴリズム[RFC2581]を使用しなければなりません。 すなわち、それは、データ・セグメント[RFC1122]を受けた後にACKを送るのを遅らせるかもしれません。 ACKsが遅れるとき、受信機は500msの中でACKを発生させなければなりません、そして、ACKは受信データ[RFC2581]の少なくともあらゆる2番目の完全な大きさで分けられたセグメント(MSS)のために発生するべきです。 これは2の値を超えていないACK遅れ要素(d)をもたらすでしょう。 それがTCP受信機へのホスト変更と受信ホストによる認識ですが、アルゴリズムが非対称の経路との関係を使用することで必要とする変化。 そのような変化は、一般的な場合で多くの欠点を持って、現在、インターネットの中の使用のために推薦されません。
Balakrishnan et. al. Best Current Practice [Page 11] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[11ページ]RFC3449PILC--非対称のリンクス2002年12月
4.2 Use of Large MSS
4.2 大きいMSSの使用
A TCP sender that uses a large Maximum Segment Size (MSS) reduces the number of ACKs generated per transmitted byte of data.
大きいMaximum Segment Size(MSS)を使用するTCP送付者は1データの伝えられたバイト単位で発生するACKsの数を減少させます。
Although individual subnetworks may support a large MTU, the majority of current Internet links employ an MTU of approx 1500 bytes (that of Ethernet). By setting the Don't Fragment (DF) bit in the IP header, Path MTU (PMTU) discovery [RFC1191] may be used to determine the maximum packet size (and hence MSS) a sender can use on a given network path without being subjected to IP fragmentation, and provides a way to automatically select a suitable MSS for a specific path. This also guarantees that routers will not perform IP fragmentation of normal data packets.
個々のサブネットワークは大きいMTUを支持するかもしれませんが、現在のインターネットリンクの大部分が約1500バイト(イーサネットのもの)のMTUを使います。 IPヘッダーで噛み付かれたFragment(DF)ではなく、ドンを設定することによって、Path MTU(PMTU)発見[RFC1191]は、送付者が与えられたネットワーク経路でIP断片化にかけられないで使用できる最大のパケットサイズ(そして、したがって、MSS)を決定するのに使用されるかもしれなくて、自動的に適当なMSSを特定の経路に選択する方法を提供します。 また、これは、ルータが正常なデータ・パケットのIP断片化を実行しないのを保証します。
By electing not to use PMTU Discovery, an end host may choose to use IP fragmentation by routers along the path in the forward direction [RFC793]. This allows an MSS larger than smallest MTU along the path. However, this increases the unit of error recovery (TCP segment) above the unit of transmission (IP packet). This is not recommended, since it can increase the number of retransmitted packets following loss of a single IP packet, leading to reduced efficiency, and potentially aggravating network congestion [Ken87]. Choosing an MSS larger than the forward path minimum MTU also permits the sender to transmit more initial packets (a burst of IP fragments for each TCP segment) when a session starts or following RTO expiry, increasing the aggressiveness of the sender compared to standard TCP [RFC2581]. This can adversely impact other standard TCP sessions that share a network path.
PMTUディスカバリーを使用しないのを選ぶことによって、終わりのホストは、経路に沿ったルータで順方向[RFC793]にIP断片化を使用するのを選ぶかもしれません。 これは経路に沿って、最も小さいMTUより大きいMSSを許容します。 しかしながら、これはトランスミッション(IPパケット)のユニットより上での誤り回復(TCPセグメント)のユニットを増加させます。 これは推薦されません、単一のIPパケットについて損失に続いて、再送されたパケットの数を増加させることができるので、減退した能率に通じて、潜在的に、ネットワークの混雑[Ken87]をいらいらさせて。 また、セッションが始まるとき、フォワードパスの最小のMTUより大きいMSSを選ぶのが、送付者が、より初期のパケット(それぞれのTCPセグメントのためのIP断片の炸裂)を伝えることを許可するか、または次のRTO満期に、送付者の攻撃性を増加させるのは標準のTCP[RFC2581]と比較されました。 これは逆にネットワーク経路を共有する他の標準のTCPセッションに影響を与えることができます。
RECOMMENDATION:
推薦:
A larger forward path MTU is desirable for paths with bandwidth asymmetry. Network providers may use a large MTU on links in the forward direction. TCP end hosts using Path MTU discovery may be able to take advantage of a large MTU by automatically selecting an appropriate larger MSS, without requiring modification. The use of Path MTU discovery [RFC1191] is therefore recommended.
経路に、より大きいフォワードパスMTUは帯域幅非対称に望ましいです。 ネットワーク内の提供者はリンクの上の大きいMTUを順方向に使用するかもしれません。 Path MTU発見を使用しているTCP終わりのホストは自動的に適切なより大きいMSSを選択することによって、大きいMTUを利用できるかもしれません、変更を必要としないで。 したがって、Path MTU発見[RFC1191]の使用はお勧めです。
Increasing the unit of error recovery and congestion control (MSS) above the unit of transmission and congestion loss (the IP packet) by using a larger end host MSS and IP fragmentation in routers is not recommended.
より大きい終わりのホストMSSを使用することによって誤り回復とトランスミッションと混雑の損失(IPパケット)のユニットより上での輻輳制御(MSS)のユニットを増加させて、ルータにおけるIP断片化は推薦されません。
Balakrishnan et. al. Best Current Practice [Page 12] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[12ページ]RFC3449PILC--非対称のリンクス2002年12月
4.3 ACK Congestion Control
4.3 ACK輻輳制御
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 Congestion Control(ACC)は終わるために端を操作する実験技術です。 ACCは輻輳制御をACKsに与えます、彼らが上流のボトルネックリンクでリソースにおける非取るにたらない要求を(例えば、パケットバッファ、およびMACトランスミッションオーバーヘッド)にするかもしれないので。 それには、2つの部品があります: (a) (b) ACK経路が混雑しているのを受信機に示すネットワークメカニズム、およびそのような指示への受信機の応答。
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]はRED(無作為のEarly Detection)に基づきました。 これはタイムウィンドウの上で最近において平均した待ち行列サイズを追跡するかもしれません。 平均が敷居を超えているなら、ルータは無作為にパケットを選択するかもしれません。 パケットIPヘッダーがExplicit Congestion Notification Capable Transport(ECT)ビットを設定させるなら、ルータはパケットをマークするかもしれません。すなわち、セットExplicit Congestion Notification(電子証券取引ネットワーク)[RFC3168]はIPヘッダーで(s)に噛み付きました。さもなければ、通常、パケットは落とされます。 終わりのホストによって受け取られた電子証券取引ネットワークの通知は、輻輳回避[RFC3168]の引き金となるように送付TCP終わりのホストに映し出されます。 ルータが電子証券取引ネットワークと共にREDを実行して、パケット損失を排除しないでください、パケットを落としてもよいことに注意してください(ECTビットが設定さえされるとき)。 また、いつ電子証券取引ネットワークビットを設定するかを決めるのにRED以外のアルゴリズムを使用するのも可能です。
ACC extends ECN so that both TCP data packets and ACKs set the ECT bit and are thus candidates for being marked with an ECN bit. Therefore, upon receiving an ACK with the ECN bit set [RFC3168], a TCP receiver reduces the rate at which it sends ACKs. It maintains a dynamically varying delayed-ACK factor, d, and sends one ACK for every d data packets received. When it receives a packet with the ECN bit set, it increases d multiplicatively, thereby multiplicatively decreasing the frequency of ACKs. For each subsequent RTT (e.g., determined using the TCP RTTM option [RFC1323]) during which it does not receive an ECN, it linearly decreases the factor d, increasing the frequency of ACKs. Thus, the receiver mimics the standard congestion control behavior of TCP senders in the manner in which it sends ACKs.
ACCが電子証券取引ネットワークを広げるので、TCPデータ・パケットとACKsの両方が、ECTビットを設定して、その結果、電子証券取引ネットワークビットでマークされる候補です。 したがって、電子証券取引ネットワークビットセット[RFC3168]でACKを受けるとき、TCP受信機はそれがACKsを送るレートを低下させます。 それは、ダイナミックに異なった遅れたACK要素、dを維持して、パケットが受け取った各dデータあたり1ACKを送ります。 電子証券取引ネットワークビットがセットした状態でパケットを受けるとき、d乗法的を増加させます、その結果、乗法的に、ACKsの頻度を減少させます。 電子証券取引ネットワークを受けないそれぞれのその後のRTT(例えば、TCP RTTMオプション[RFC1323]を使用することで、決定する)に関しては、要素dを直線的に減少させます、ACKsの頻度を増加させて。 したがって、受信機はそれがACKsを送る方法における、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))からのデータの各窓が、送るために受信機の遅れているACKタイマがACKの引き金となるまで送付者が失速するのを防ぐように、受信機は少なくとも1ACKを送るはずです(望ましくはより多くの)。
Balakrishnan et. al. Best Current Practice [Page 13] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[13ページ]RFC3449PILC--非対称のリンクス2002年12月
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 Congestion Control(ACC)はTCP送付者と受信機変更を必要とする実験技術です。 現在、インターネットでそのようなテクニックを使用する経験がほとんどありません。 TCPの将来のバージョンは、これか同様のテクニックを含むように発展するかもしれません。 これらは継続中の研究の対象です。 ACCは使用のために現在のフォームでインターネットの中で推薦されません。
4.4 Window Prediction Mechanism
4.4 ウィンドウ予測メカニズム
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.
Window Prediction Mechanism(WPM)はACC計画(セクション4.3)に類似しながらダイナミックなACK遅れ要素(異なったd)を使用するTCP受信機サイドメカニズム[CLP98]です。 TCP受信機は、cwnd値を予測することによって、TCP送付者の輻輳制御の振舞いを再建します。 この値は、受信機のdの値を調整するのに許容窓と共に使用されます。 WPMは不要な「再-トランスミッション」のために誤りをリンクすることにおける支払い満期の損失からの結果になることを収容します。
RECOMMENDATION: Window Prediction Mechanism (WPM) is an experimental TCP receiver side modification. There is currently little experience of using such techniques in the Internet. Future versions of TCP may evolve to include this or similar techniques. These are the subjects of ongoing research. WPM is not recommended for use within the Internet in its current form.
推薦: 窓のPrediction Mechanism(WPM)は実験的なTCP受信機サイド変更です。 現在、インターネットでそのようなテクニックを使用する経験がほとんどありません。 TCPの将来のバージョンは、これか同様のテクニックを含むように発展するかもしれません。 これらは継続中の研究の対象です。 WPMは使用のために現在のフォームでインターネットの中で推薦されません。
4.5 Acknowledgement based on Cwnd Estimation.
4.5 承認はCwnd Estimationを基礎づけました。
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 Estimation(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 Estimation(ACE)に基づく承認は実験的なTCP受信機サイド変更です。 現在、インターネットでそのようなテクニックを使用する経験がほとんどありません。 TCPの将来のバージョンは、これか同様のテクニックを含むように発展するかもしれません。 これらは継続中の研究の対象です。 ACEは使用のために現在のフォームでインターネットの中で推薦されません。
4.6 TCP Sender Pacing
4.6 TCP送付者ペース
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].
ACKsの頻度を減少させるのは、上流のボトルネックリンクの混雑を軽減するかもしれませんが、TCP送付者炸裂(セクション4.1)の増加するサイズに通じることができます。 これは、cwndの成長を遅くするかもしれなくて、ボトルネックリンクバッファのパケットの最大数をかなり増加させるかもしれないので共用回線網経路の上で使用されると、望ましくありません、潜在的にネットワークの混雑の増加をもたらして。 また、これはACK Compression[ZSC91]に通じるかもしれません。
Balakrishnan et. al. Best Current Practice [Page 14] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[14ページ]RFC3449PILC--非対称のリンクス2002年12月
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 Senderペースと呼ばれたTCP Pacing[AST00]は適合しているTCP送付者をトランスミッションburstinessを軽減するのに雇います。 バウンドはパケットの最大数に置かれて、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).
サブネットワークは、形成が実行される(セクション5.3.3)ところでまた、(例えば、Generic Traffic Shaping(GTS))に歩調を合わせながら提供するかもしれませんが、ルータで1パケットあたりの処理オーバヘッドとバッファ要件のかなりの増加を含意します。
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 Sender PacingはTCP送付者の実現への変化を必要とします。 それは、インターネットで有益であるかもしれなく、ホストによって伝えられたパケットの放出量をかなり減少させるでしょう。 これは首尾よくStretch ACKsを受ける衝撃を緩和します。 TCP Sender Pacingは、1パケットあたりの増加する加工費を含意して、適当な通信速度を示すために予測アルゴリズムを必要とします。 したがって、終わりのホスト費用とネットワーク性能の間には、性能トレードオフがあります。 効率的なアルゴリズムの仕様は継続中の研究の領域のままで残っています。 TCP Sender Pacingの使用が新しい問題を紹介しないと予想されます。トランスミッション(例えば、Type1のテクニックから生じるセクション5.1.2)のburstinessを制御するかもしれないTCPホストのための実験的な緩和である、しかしながら、それは現在、広く配備されません。 それは使用のために現在のフォームでインターネットの中で推薦されません。
4.7 TCP Byte Counting
4.7 TCPバイト勘定
The TCP sender can avoid slowing growth of cwnd by taking into account the volume of data acknowledged by each ACK, rather than opening the cwnd based on the number of received ACKs. So, if an ACK acknowledges d data packets (or TCP data segments), the cwnd would grow as if d separate ACKs had been received. This is called TCP Byte Counting [RFC2581, RFC2760]. (One could treat the single ACK as being equivalent to d/2, instead of d ACKs, to mimic the effect of the TCP delayed ACK algorithm.) This policy works because cwnd growth is only tied to the available capacity in the forward direction, so the number of ACKs is immaterial.
TCP送付者は、容認されたACKsの数に基づくcwndを開くより各ACKによってむしろ承認されたデータ量を考慮に入れることによってcwndの成長を遅くするのを避けることができます。 それで、ACKがdデータ・パケット(または、TCPデータ・セグメント)を承認するなら、cwndはまるでd別々のACKsを受け取ったかのように成長するでしょう。 これはTCP Byte Counting[RFC2581、RFC2760]と呼ばれます。 (人はd/2に同等であるとして独身のACKを扱うことができました、d ACKsの代わりに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.)
他のテクニックと組み合わせて使用されると、これは非対称の影響を緩和するかもしれません。(例えば、TCP Pacingの組み合わせ(section4.6)、および受信機の写しACK敷居に関連しているACC(セクション4.3)。)
Balakrishnan et. al. Best Current Practice [Page 15] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[15ページ]RFC3449PILC--非対称のリンクス2002年12月
The main issue is that TCP byte counting may generate undesirable long bursts of TCP packets at the sender host line rate. An implementation must also consider that data packets in the forward direction and ACKs in the reverse direction may both travel over network paths that perform some amount of packet reordering. Reordering of IP packets is currently common, and may arise from various causes [BPS00].
本題はTCPバイト勘定が送付者ホストライン料率でTCPパケットの望ましくない長い炸裂を発生させるかもしれないということです。 また、実現は、順方向へのデータ・パケットと反対の方向へのACKsがいくらかの量のパケット再命令を実行するネットワーク経路の上をともに旅行するかもしれないと考えなければなりません。 IPパケットのReorderingは現在、一般的であり、いろいろな理由で起こるかもしれません[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 Byte Countingは小さいTCP送付者変更を必要とします。 特にStretch ACKsが受け取られているとき、最も簡単なフォームでは、それは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 Sender Pacing(セクション4.6)、ABC[abc-ID])の潜在的に大きい炸裂を緩和する方法を含むべきであることが強く勧められます。 Stretch ACKsが受け取られているとき、TCP送付者の放出量か送付レートを制御できるなら、計画は有益であるかもしれません。 安全なアルゴリズムが継続中の研究の領域のままで残っていることを決定します。 次に、さらなる実験がこれらの安全装置の成功を評価するのに必要でしょう、インターネットでの使用のためにそれらを推薦できる前に。
4.8 Backpressure
4.8 背圧
Backpressure is a technique to enhance the performance of bidirectional traffic for end hosts directly connected to the upstream bottleneck link [KVR98]. A limit is set on how many data packets of upstream transfers can be enqueued at the upstream bottleneck link. In other words, the bottleneck link queue exerts 'backpressure' on the TCP (sender) layer. This requires a modified implementation, compared to that currently deployed in many TCP stacks. Backpressure ensures that ACKs of downstream connections do not get starved at the upstream bottleneck, thereby improving performance of the downstream connections. Similar generic schemes that may be implemented in hosts/routers are discussed in section 5.4.
背圧は直接上流のボトルネックリンク[KVR98]に接続された終わりのホストのための双方向の交通の性能を高めるテクニックです。 限界は上流のボトルネックリンクで上流の転送のいくつのデータ・パケットを待ち行列に入れることができるかに関して設定されます。 言い換えれば、ボトルネックリンク待ち行列はTCP(送付者)層に'背圧'を出します。 現在多くのTCPスタックで配備されているそれと比べて、これは変更された実現を必要とします。 背圧は、川下の接続のACKsが上流のボトルネックで飢えていないのを確実にします、その結果、川下の接続の性能を向上させます。 セクション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
推薦: 背圧は直接上流のボトルネックリンクに接続されたホストの送付者プロトコル・スタックへの実験的な変更を必要とします。 背圧の使用はネットワーク・プロトコル問題よりむしろ導入問題です。 背圧が実行されるところでは、このセクションで説明された最適化は実行されるかもしれません。
Balakrishnan et. al. Best Current Practice [Page 16] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[16ページ]RFC3449PILC--非対称のリンクス2002年12月
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.
ホストのための望ましくて缶の利益双方向の交通。 それでも、背圧を提供するための安全なアルゴリズムの仕様は継続中の研究の対象です。 テクニックは使用のために現在のフォームでインターネットの中で推薦されません。
5. Improving TCP performance using Transparent Modifications
5. Transparent Modificationsを使用することでTCP性能を向上させます。
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接続が、別々に特定されて、何らかの1流れあたりの状態が活発なTCP接続のために維持されると暗示するのを必要とします。 また、リンクスケジューラは使われるかもしれません(セクション5.4)。 テクニック、(ただ1つを例外として、ACK Decimation(セクション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) 「反-マルチプレックス」への能力は流れます(アドレス/プロトコル/ポートナンバー、または明白な流れイドを使用することによって)。
[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]はパケットの推進より提供して、プロトコルEnhancing Proxy(PEP)として知られているネットワーク装置のクラスについて説明します。 PEP装置の大きいスペクトルは存在しています、簡単な装置(例えば、ACKフィルタリング)から、より精巧な装置(例えば、TCP接続を2つの別々の部分に分けたstateful装置)まで及んで。 このドキュメントのセクション5で説明されたテクニックは、少しのTCPやUDPペイロードデータもより純真なタイプの所有て、点検するか、または変更しません。 また、彼らはポートナンバーかリンクアドレスを変更しません。 より複雑なPEPsに関連しているリスクの多くがこれらの計画のために存在していません。 操作に関する詳細とPEPsを使用すると関連している危険は[RFC3135]で説明されます。
Balakrishnan et. al. Best Current Practice [Page 17] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[17ページ]RFC3449PILC--非対称のリンクス2002年12月
5.1 TYPE 0: Header Compression
5.1 0はタイプします: ヘッダー圧縮
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パケットのヘッダーが連続したパケットの間のいくつかのビット位置だけで流れで異なって、しばしば変化は予測できるという観測に依存します。
5.1.1 TCP Header Compression
5.1.1 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圧縮として時々知られている)はSLIPかPPP[RFC3150]を走らせながら低い容量リンクの上に使用について説明するProposed Standardです。 損失が珍しいときに(コンプレッサーと減圧装置の状態が同期するのを確実にする状況)、それは逆方向リンクの上のACKsのサイズを大いに減少させます。 しかしながら、これだけが非対称問題のすべてを記述しません:
(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].
1パケットあたりそこのいくつかの(例えば、無線電信)サブネットワークの(i)は1つのパケットサイズ(セクション3.2)から独立している重要なMACオーバーヘッドです。 (ii) ACKsのサイズの減少は双方向の交通(セクション3.3)があるとき大きい上流のデータ・パケットとの不利な相互作用を防ぎません。 (iii) IPを持っているパケットかTCPオプションと共にTCPヘッダー圧縮を使用できません(IPSec[RFC2402、RFC2406]、TCP RTTM[RFC1323]、TCP SACK[RFC2018]などを含んでいて)。 (iv) 圧縮されたパケットが無くなるとき、RFC1144によって説明されたヘッダー圧縮の性能はかなり下げられます。 改良であり、どれが長いネットワーク経路でまだ重要な刑罰を被ることができるかは[RFC2507]で説明されます。 これは、それが低レベルのパケット損失[RFC3150]を経験するリンク(または、経路)の上に使用されるだけであるべきであると示唆します。 (v) IPが(例えば、L2TP、GRE[RFC2794]、IPにおけるIP)にトンネルを堀るのを支持するのに使用されるとき、Header Compressionの通常の実現は圧縮を抑制します。 適切なパケットのヘッダーの居場所を見つけるカプセル化が複雑にするトンネル。 GREは内側(トンネルを堀られる)のIPヘッダー[RFC2784]のHeader Compressionを許容しますが、これは推薦されません、パケット(例えば、トンネル経路に沿ったルータ混雑による)の損失が1RTT[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,
推薦: TCP Header Compressionは上流のボトルネックリンクの両端で実行されたわかりやすい変更です。 IPSec[RFC2402、RFC2406]を使うか、または追加議定書ヘッダーが出席しているとき、それは流れのために利益を全く提供しません。(例えば、IPかTCPがゆだねます。
Balakrishnan et. al. Best Current Practice [Page 18] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[18ページ]RFC3449PILC--非対称のリンクス2002年12月
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).
トンネルカプセル化ヘッダー) 計画は、インターネットリンクの上に広く実行されて、配備されて、使用されます。 安値から媒体への帯域幅非対称(例えば、k<10)を持っている経路にTCP性能を向上させるのはお勧めです。
In the form described in [RFC1144], TCP performance is degraded when used over links (or paths) that may exhibit appreciable rates of packet loss [RFC3150]. It may also not provide significant improvement for upstream links with bidirectional traffic. It is therefore not desirable for paths that have a high bandwidth asymmetry (e.g., k>10).
[RFC1144]で説明されたフォームでは、パケット損失[RFC3150]のかなりの速度を示すかもしれないリンク(または、経路)の上に使用されると、TCP性能は降格しています。 また、それは上流のリンクのためのかなりの改善に双方向の交通を提供しないかもしれません。 したがって、高帯域非対称(例えば、k>10)を持っている経路には、それは望ましくはありません。
5.1.2 Alternate Robust Header Compression Algorithms
5.1.2 交互の強健なヘッダー圧縮アルゴリズム
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]とTimestamp(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認証を支持する計画が引き出されるのは、可能です。 計画が単独でそうしないそのようなものは高い非対称、そして/または、双方向の交通を非対称のネットワークにおけるかなりの改善に提供します。
5.2 TYPE 1: Reverse Link Bandwidth Management
5.2は1をタイプします: 逆方向リンク帯域幅管理
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.
Type0ヘッダー圧縮を超えたテクニックが、かなりの非対称(k>>1)で引き起こされたその性能問題を訴えるのに必要です。 1セットのテクニックは単に逆の指示経路の1ポイントで実行されます、上流のボトルネックリンクに接続されたルータ/ホストの中で。 これらが流れのクラスを使用するか、またはパケットがボトルネック上流でトランスミッションを待つ待ち行列を管理する上流のリンクインタフェースにおける1流れあたりの待ち行列はリンクされます。
Balakrishnan et. al. Best Current Practice [Page 19] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[19ページ]RFC3449PILC--非対称のリンクス2002年12月
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.
上流のリンクがバッファリングするテクニック領域のこのタイプは、各待ち行列から過剰ACKsを取り外すこと(捨てる)にサイズを列に並ばせて、アルゴリズムを使います。 これはACKs(セクション4.1)の累積している自然を当てにします。 このタイプの緩和を使う2つのアプローチが説明されます。
5.2.1 ACK Filtering
5.2.1 ACKフィルタリング
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 Filtering(AF)[DMT96、BPK99](また、ACK Suppression[SF98、Sam99、FSS01]として、知られている)はTCP意識しているACKsの数を減少させるリンクレイヤのテクニックが上流を転送したのをリンクです。 このテクニックは特定の生産ネットワーク(例えば、非対称の衛星ネットワーク[ASB96])で配備されました。 挑戦は送付者がACKsが無差別に取り外されるなら起こるかもしれないACKsを待ちながら失速しないのを保証することです。
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が上流のボトルネックリンクインタフェースで待ち行列に入れられようとしているとき、ルータか終わりのホストリンクレイヤ(ホストが直接上流のボトルネックリンクに接続されるなら)がチェックする、同じTCP接続のものであるより古いACKsのために待ち行列を伝えてください。 ACKsを見つけるなら、ACKsの数を減少させて、待ち行列から或るもの(または、彼らのすべて)を取り除きます。
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].
いくつかのACKsをもTCP[RFC1144]に他の機能を持って、通常の操作を確実にするために削除するべきではありません。 したがって、AFはどんなデータやTCP旗も設定させるACK(SYN、RST、URG、およびFIN)を削除するはずがありません。 さらに、それは、待ち行列からのSelective ACKオプション(SACK)[RFC2018]があるFast Retransmission[RFC2581]かACKsがTCPのデータ駆動型損失回収機構に問題を起こすのを避ける必要性を示す一連の3写しACKsを削除するのを避けるべきです。また、適切な処理が、電子証券取引ネットワークフィードバック(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.
ACKsをフィルターにかけるさまざまな方針が使用されるかもしれません。 これらが決定論的であるか、または無作為であるかもしれない、(同様である、待ち行列で項目の意味論を考慮に入れるべきであるのを除いた無作為の低下ゲートウェイ また、アルゴリズムは、ACKがTCP送付者の窓をアップデートするのを[Sam99、FSS01]保証して、Stretch ACKによって承認されたデータ・パケット(TCPセグメント)の数を制限すると評定する最小限を確実にするために示されました。 1流れあたりの州は、接続のためだけに少なくとも1つのパケットで待ち行列(フレッド[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.
遅れたDupACKs(セクション3.4)がFast Retransmissionを許容しながら閾値[MJW00、CLP98]を超えて写しACKsを削除することによって減少できますが、早いTCPタイムアウトを避けるという望ましくない効果。(そうでなければ、タイムアウトはDupACKsの過度の列を作りから生じるかもしれません)。
Balakrishnan et. al. Best Current Practice [Page 20] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[20ページ]RFC3449PILC--非対称のリンクス2002年12月
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.
将来の計画は選択されたSACKs[RFC2018]の解任を許すより高度な規則を含むかもしれません。 そのような計画は、上流のリンク待ち行列がSACKブロックがある背中合わせのACKsでいっぱいにされるようになるのを防ぐかもしれません。 SACKパケットがACKよりはるかに大きいので、それは別の方法で反対の方向の経路遅れにかなり加えるでしょう。 適当なアルゴリズムの品揃えは研究の進行中の領域のままで残っています。
RECOMMENDATION: ACK Filtering requires a modification to the upstream link interface. The scheme has been deployed in some networks where the extra processing overhead (per ACK) may be compensated for by avoiding the need to modify TCP. ACK Filtering can generate Stretch ACKs resulting in large bursts of TCP data packets. Therefore on its own, it is not recommended for use in the general Internet.
推薦: ACK Filteringは上流のリンクインタフェースへの変更を必要とします。 計画は余分な処理オーバヘッド(1ACKあたりの)がTCPを変更する必要性を避けることによって補われるかもしれないいくつかのネットワークで配備されました。 ACK FilteringはTCPデータ・パケットの大きい炸裂をもたらすStretch ACKsを発生させることができます。 したがって、それ自身のところでは、それが一般的なインターネットでの使用のために推薦されません。
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.
計画と組み合わせてStretch ACKs(すなわち、コントロールTCP送付者放出量)の効果を緩和するのに使用されると、ACK Filteringはかなりの非対称(k>1)双方向の交通で経路に推薦されます。 IPSec認証、SACK、および電子証券取引ネットワークを支持する適当なアルゴリズムは継続中の研究の領域のままで残っています。
5.2.2 ACK Decimation
5.2.2 ACK大量殺害
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 Decimationは標準のルータメカニズムに基づいています。上流のボトルネックリンクで1流れあたりの(小さい)の待ち行列の適切な構成と選ばれた低下方針(例えば、Weighted Fair Queuing、WFQ)を使用することによって、AF(セクション5.2.1)への同様の効果が得ますが、落とされる実際のパケットの、より少ないコントロールであるかもしれません。
In this scheme, the router/host at the bottleneck upstream link maintains per-flow queues and services them fairly (or with priorities) by queuing and scheduling of ACKs and data packets in the reverse direction. A small queue threshold is maintained to drop excessive ACKs from the tail of each queue, in order to reduce ACK Congestion. The inability to identify special ACK packets (c.f., AF) introduces some major drawbacks to this approach, such as the possibility of losing DupACKs, FIN/ACK, RST packets, or packets carrying ECN information [RFC3168]. Loss of these packets does not significantly impact network congestion, but does adversely impact the performance of the TCP session observing the loss.
この計画では、上流のリンクが流れであることを支持するボトルネックのルータ/ホストは、ACKsとデータ・パケットの列を作りとスケジューリングで反対の方向にそれらを公正(またはプライオリティで)に列に並ばせて、修理します。 小さい待ち行列敷居はそれぞれの待ち行列のテールから過度のACKsを落とすために維持されます、ACK Congestionを減少させるために。 特別なACKパケット(c.f.、AF)を特定できないことはいくつかの主要な欠点をこのアプローチに紹介します、電子証券取引ネットワーク情報[RFC3168]を運ぶDupACKs、FIN/ACK、RSTパケット、またはパケットをなくす可能性などのように。 これらのパケットの損失はネットワークの混雑にかなり影響を与えませんが、損失を観測する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
WFQスケジューラは、対話的な通信(それにそのような交通を特定するメカニズムがあるなら)の、より高い優先度を割り当てて、残存容量の正当な分け前を大量の交通に提供するかもしれません。 双方向の交通があるとき適当なスケジューリング方針で、これはACKとデータ・パケットのための、より公正な共有を確実にするかもしれません。 増加する前進の通信速度は非対称のリンクの上に達成されます。
Balakrishnan et. al. Best Current Practice [Page 21] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[21ページ]RFC3449PILC--非対称のリンクス2002年12月
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.
増加するACK Decimationで、Stretch ACKsの世代に通じて、評価してください。 他のテクニックがこのテクニックと組み合わせて使用されない場合Stretch ACKsが受け取られているとき、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は、ACKsが上流のリンクに与えられているレートを抑制するのに上流のリンクインタフェースで標準のルータメカニズムを使用します。 テクニックはかなりの非対称(k>1)を持っている経路によって有利です。 どんなに準最適であってもそれはそうです、効率の悪いTCPエラー回復(そして、したがって、いくつかの場合、TCP性能を下げる)に通じるかもしれなくて、リンクの振舞いの粗雑なコントロールだけを提供するので。 したがって、可能であるところでは、ACK FilteringがACK Decimationに優先して使用されるのが、お勧めです。
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 Decimationが経路でかなりの非対称(k>1)(または双方向の交通で)で使用されるとき、TCP送付者の放出量を増加させます、したがって、Stretch ACKsかコントロールburstinessの効果を緩和する計画の使用は強く推薦されます。
5.3 TYPE 2: Handling Infrequent ACKs
5.3 2はタイプします: 取り扱いの珍しいACKs
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).
TYPE2緩和は、TYPE1の上流のリンク帯域幅管理を実行しますが、減少しているACKレートの効果とACKトランスミッションのburstinessを緩和する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).
TYPE1計画がd TCPパケットを覆うStretch ACKを進める(すなわち、どこで、承認番号は最後のACKがTCP送付者のそばで受信したより大きいd*MSSですか)経路を考えてください。 TCP送付者がこのACKを受け取るとき、それはd(または、d+1)TCPデータ・パケットの炸裂を送ることができます。 また、送付者は現在のcwndによって抑制されます。 また、容認されたACKsは、cwnd(高々1MSSによる)を増加させるのに役立ちます。
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
TYPE2計画はTYPE1計画が使用されているとき結果として生じる減少しているACK頻度の影響を緩和します。 これは、それぞれがStretch ACKを受ける前に追加ACKsを点在させることによって、達成されます。 追加ACKsはオリジナルのACKと共にまるで逆の経路でTCP受信機によって送られたそれぞれのオリジナルのACKsを進めたかのように同様に、TCP cwndが開くのを許容できるくらいのACKsをTCP送付者に提供します。 回復する試みによる添加で
Balakrishnan et. al. Best Current Practice [Page 22] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[22ページ]RFC3449PILC--非対称のリンクス2002年12月
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].
ACKsの間のスペース、そのような計画はまた、自己の時間を計るTCP振舞いを復元して、TCP送付者放出量を減少させることができます。 そのような計画は、保守的な振舞い(すなわち、元々送ったより多くのACKsを導入するべきでない)を確実にして、ACK Compression[ZSC91]の確率を減少させる必要があります。
The action is performed at two points on the return path: the upstream link interface (where excess ACKs are removed), and a point further along the reverse path (after the bottleneck upstream link(s)), where replacement ACKs are inserted. This attempts to reconstruct the ACK stream sent by the TCP receiver when used in combination with AF (section 5.2.1), or ACK Decimation (section 5.2.2).
動作はリターンパスの2ポイントで実行されます: 上流はインタフェース(過剰ACKsが取り外されるところ)、およびポイントを逆の経路に沿って、より遠くにリンクします。(ボトルネック上流の後に、(s))をリンクしてください。そこでは、交換ACKsが挿入されます。 これは、AF(セクション5.2.1)、またはACK Decimation(セクション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.
TYPE2緩和が局所的に実行されるかもしれない、直接上流のボトルネックリンクに続いて、インタフェースを受けてください、またはあるいはまた、さらに逆の経路に沿った任意な点で適用されるかもしれません(これは必ずフォワードパスにあるというわけではありません、非対称のルーティングが前方で異なって逆のインターネット経路を使うかもしれないので)。 テクニックがそれぞれの個々のStretch ACKのレセプションの複数のACKsを発生させるかもしれないので、エキスパンダが「パケットアンプ」としてDenialで開発を防ぐために計画を実行するのは、強くお勧めです。-サービス(DoS)では、攻撃してください(例えばACKの創始者について確かめる)。 適切に構成されたパケットフィルタトンネル認証手順(例えば、[RFC2402、RFC2406])で送付者の識別を実行できるでしょう。 また、単一のパケットから発生するかもしれない再建されたACKsの数における限界も望ましいかもしれません。
5.3.1 ACK Reconstruction
5.3.1 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 Reconstruction(AR)[BPK99]はAF(セクション5.2.1)に関連して使用されます。 ARは上流のボトルネックリンクに続いて、逆の経路のACK Reconstructorと呼ばれる軟性国家[Cla88]エージェントを配備します。 容認されたACKsに基づいて失われているなら、軟性国家を作り直すことができます。 Stretch ACKが受け取られているとき、ARは、ACK系列の不足をいっぱいにすることによって、追加ACKsを導入します。 -何らかの可能性Denialに、脆弱性は、Serviceにおいて、起こって(セクション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
Reconstructorは、フィルターにかけることのACKsの数を見積もっていることによって、追加ACKsの数を測定します。 これはそれぞれのACK一連番号がACKを受けたのを観測するのによる容認されたACKの流れにおける現在の暗黙の情報を使用します。 例の実現はACK敷居を設定するかもしれません、ackthresh、MSSの2倍に(これは、選ばれたMSSがリンクによって知られていると仮定します)。 2の要素は対応しています。
Balakrishnan et. al. Best Current Practice [Page 23] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[23ページ]RFC3449PILC--非対称のリンクス2002年12月
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.
標準のTCP遅れたACK方針(d=2)に。 したがって、デルタのそばで切り離されて、連続したACKsが到着するなら、Reconstructorは最大デルタ/ackthresh()(--2)ACKsを作り直します。
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が川下のリンクによって決定されたレートで増加するのを許容するために、一貫したレート(すなわち、再建されたACKsの間の時のスペース)で再建されたACKsを送らなければなりません。 1つの方法はReconstructorが指数加重移動平均見積り人を使用することでACKsの到着率を測定することです。 このレートは、リンクを共有しながら、上流のリンクと他の交通の存在の上で出力率に依存します。 見積り人の出力はACKs(そして、損失か遅れがそれ以上なければACKsがTCP送付者に届く平均相場)のために平均した時のスペースを示します。 これは、再建されたACKsの時のスペースを設定するのにReconstructorによって使用されるかもしれません。 また、計画は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]).
より少ないTCP送付者burstiness、およびcwnd増加のより良いレートを入手するとき、ARのトレードオフがあります、RTT変化の減少で、経路RTTの穏やかな増加に対して。 テクニックはIPSec(AH[RFC2402]か超能力[RFC2406])を使用することで接続に再建を実行できません、適切なセキュリティ情報を発生させることができないので。 また、それは他のパケットヘッダー情報を作り直すことができません(例えばビットの正確なパターンはIPパケット電子証券取引ネットワーク分野[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 Reconstructorは正しさ(すなわち、どんな偽物の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 Delay(d=2)[RFC2581](ii)ReconstructorはオーダーだけにおけるACKs(iii)を受けます。すべてのACKsによるReconstructor(iv)を通して発送されて、Reconstructorが正しく(v) パケットが追加ヘッダー情報(例えば、TCP RTTMオプション[RFC1323]、AHを使用するIPSec[RFC2402]または超能力[RFC2406])を運ばないセッションで使用されるTCP MSSを決定するということです。
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
推薦: ACK Reconstructionは上流のボトルネックリンクに続いて、逆の経路に実行された実験的なわかりやすい変更です。 それは、TYPE1緩和に関連して使用されるように設計されています。 それはTCPトランスミッションの順方向への放出量を減少させます。(そうでなければ、TYPE1計画が単独で使用されるとき、順方向は増加するかもしれません)。 それは上流のリンクの後に設備の変更を必要とします(1流れあたりの軟性国家を維持するのを含んでいて)。 計画がネットワーク経路に関する暗黙の仮定を紹介する、有
Balakrishnan et. al. Best Current Practice [Page 24] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[24ページ]RFC3449PILC--非対称のリンクス2002年12月
potential Denial-of-Service vulnerabilities (i.e., acting as a packet amplifier); these need to be better understood and addressed by appropriate security techniques.
サービスの弱点の潜在的Denial(すなわち、パケットアンプとして、機能します)。 これらは、適切なセキュリティのテクニックで理解されるほうがよくて、記述される必要があります。
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交通の残りには失礼ですが開いている研究課題に適切なアルゴリズムの品揃え。 現在も、インターネットでそのようなテクニックを使用する含意の経験がほとんどありません、そして、したがって、現在のフォームでインターネットの中でこのテクニックを使用しないのはお勧めです。
5.3.2 ACK Compaction and Companding
5.3.2 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 CompactionとACK Companding[SAM99、FSS01]はポイントで裏面に強制的なACKが妨害する経路追従を操作するテクニックです。 AR(セクション5.3.1)のように、ACK CompactionとACK CompandingはAFのテクニック(セクション5.2.1)に関連して使用されて、フィルターにかけることのACKsを作り直します、ACKの流れを復元して。 しかしながら、彼らは彼らが明示的な情報がAFによって発生したすべてのStretch ACKsに加えられる変更されたAF(コンパクターかコンプレッサーとして、知られている)を使用するという点においてARと異なっています。 これは、再建操作(拡大としてここに言及される)を明らかに、同時にさせるのに使用されます。
The modified AF combines two modifications: First, when the compressor deletes an ACK from the upstream bottleneck link queue, it appends explicit information (a prefix) to the remaining ACK (this ACK is marked to ensure it is not subsequently deleted). The additional information contains details the conditions under which ACKs were previously filtered. A variety of information may be encoded in the prefix. This includes the number of ACKs deleted by the AF and the average number of bytes acknowledged. This may subsequently be used by an expander at the remote end of the tunnel. Further timing information may also be added to control the pacing of the regenerated ACKs [FSS01]. The temporal spacing of the filtered ACKs may also be encoded.
変更されたAFは2つの変更を結合します: コンプレッサーが上流のボトルネックリンク待ち行列からACKを削除するとき、まず最初に、それは明示的な情報(接頭語)を残っているACKに追加します(このACKはそれが次に削除されないのを保証するためにマークされます)。 追加情報は状態が以前にどのACKsの下でフィルターにかけられたかという詳細を含んでいます。 さまざまな情報が接頭語でコード化されるかもしれません。 これはAFによって削除されたACKsの数と承認された平均したバイト数を含んでいます。 これは次に、トンネルのリモートエンドにおけるエキスパンダによって使用されるかもしれません。 また、さらなるタイミング情報は、作り直されたACKs[FSS01]のペースを制御するために加えられるかもしれません。 また、フィルターにかけることのACKsの時のスペースはコード化されるかもしれません。
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ヘッダーを見分けるためにその後のエキスパンダを必要とします。 通常、これがエキスパンダをリンク地方の操作に制限するだろう、(受信、上流のボトルネックリンクのインタフェース) リモート拡大が逆の経路に沿って、より遠くに必要であるなら、トンネルは、変更されたACKsをリモートエキスパンダに渡すのに使用されるかもしれません。 トンネルは余分なオーバーヘッドを導入して、しかしながら、非対称の容量と左右対称のルーティングがあるネットワークは頻繁に既にそのようなトンネルを使います(例えば、UDLRネットワーク[RFC3077]では、エキスパンダは給送ルータで共同位置するかもしれません)。
Balakrishnan et. al. Best Current Practice [Page 25] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[25ページ]RFC3449PILC--非対称のリンクス2002年12月
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を広げるのに国がないアルゴリズムを使用します(すなわちそれぞれの容認されたパケットは以前に容認されたパケットの如何にかかわらず処理されます)。 それは、以前にコンパクターによって削除されたものにACKsの同等な数を生産するのに容認されたACKの承認分野と共に接頭語情報を使用します。 通常のTCP ACK時計を保存して、元の目的地(すなわち、TCP送付者)にこれらのACKsを送ります。 このように、ACK CompactionはARと異なって特定のACK方針に頼っていません、そして、それはすべてのACKsが逆の経路に関連しているのを見てはいけません(例えば、それは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.
サービスの弱点のいくらかの潜在的Denialが、起こって(セクション6)、適切なセキュリティのテクニックで記述される必要があるかもしれません。 彼らが適切なセキュリティ情報を作り直すことができないので、テクニックはIPSecを使用することで接続に再建を実行できません。 明らかに抑圧されたパケットからのIPSecセキュリティ情報をコード化するのが可能であり、IPSec AHとの操作を許して、しかしながら、これは、開いている研究課題のままで残っていて、1ACKあたり1つの追加オーバーヘッドを含意します。
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 CompactionとCompandingは上流のボトルネックリンクに続いて、逆の経路に実行された実験的なわかりやすい変更です。 それらは、順方向に変更されたTYPE1緩和に関連して使用されて、TCPトランスミッションの放出量を減少させるように設計されています。(そうでなければ、TYPE1計画が単独で使用されるとき、順方向は増加するかもしれません)。
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交通を歩測するのが適切であるアルゴリズムの品揃えは開いている研究課題のままで残っています。 サービスの弱点のいくらかの潜在的Denialがパケットアンプとして作動するどんな装置でも起こるかもしれません。 これらは、適切なセキュリティのテクニックで記述される必要があります。 インターネット経路の上で計画を使用する経験がほとんどありません。 この計画は、継続中の研究の対象であり、使用のために現在のフォームでインターネットの中で推薦されません。
5.3.3 Mitigating TCP packet bursts generated by Infrequent ACKs
5.3.3 Infrequent ACKsによって発生したTCPパケット炸裂を緩和すること。
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
Type1計画が逆の指示経路で使用されるとき発生するデータ・パケットの炸裂は、フォワードパス[Seg00]でGeneric Traffic Shaping(GTS)を支持するルータを導入することによって、緩和されるかもしれません。 GTSは多くの配備されたルータで実行された標準のルータメカニズムです。 このテクニックは、TCP送付者によって発生したデータの炸裂を排除しませんが、スケジューリングを使って、テクニックを列に並ばせることによって炸裂を取り除くのを試みます、TCP Pacingが使用されているときそれに類似している交通(セクション4.6)を作成して。 これら
Balakrishnan et. al. Best Current Practice [Page 26] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[26ページ]RFC3449PILC--非対称のリンクス2002年12月
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流れあたりの軟性国家を維持するのが必要であり、1パケットあたりの処理オーバヘッドを上げます。 何らかの追加緩衝能が、形成されていて、パケットを列に並ばせるのに必要です。
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 Compression[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を実行するのは望ましいです。
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.
推薦: 一般的なTraffic Shaping(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の構成はネットワークサービスプロバイダーの政策決定です。 適切に構成されると、Type1のテクニックの効果を緩和すると、テクニックはTCPデータ・パケット炸裂のサイズを減少させるでしょう。 GTSはインターネットでの使用のためにACK Filtering(セクション5.2.1)やACK Decimation(セクション5.2.2)などのタイプ1のテクニックに関連して推薦されます。
5.4 TYPE 3: Upstream Link Scheduling
5.4 3はタイプします: 上流のリンクスケジューリング
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の場合における接続待ち行列単位で)あたりの使用を含意します。 どんな遅いリンク(パケットを伝える時間が経路RTTのかなりの部分を形成するところ)[RFC3150]の上にも使用されると、1流れあたりの列を作り(例えば、FQ、CBQ)は利益を提供します。 上のテクニックの1つで使用されると、タイプ3計画は追加利益を提供します。
5.4.1 Per-Flow queuing at the Upstream Bottleneck Link
5.4.1 Upstream Bottleneck Linkに列を作る流れ
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]と呼ばれました。
Balakrishnan et. al. Best Current Practice [Page 27] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[27ページ]RFC3449PILC--非対称のリンクス2002年12月
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.
遅い上流のリンクの上では、かなりのジターは送付の大きいデータ・パケットによってACKs[RFC3150]の前に紹介されるかもしれません。 簡単な計画は、公正なスケジューラ(例えば、すべての流れ、または優先度スケジュールに対する連続サービス)で列を作りながら流れを使用することで実行されるかもしれません。 変更されたスケジューラ[KVR98]はデータ・パケットを伝える前にホストが上流へ伝えることができるACKsの数に限度を設けることができました(少なくとも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]の双方向の交通の衝撃(ジター)を緩和するのに使用されるかもしれません。 また、より高度な計画(例えば、WFQ)は、http[Seg00]などの複数のACKの流れで転送の性能を向上させるのに使用されるかもしれません。
RECOMMENDATION: Per-flow queuing is a transparent modification performed at the upstream bottleneck link. Per-flow (or per-class) scheduling does not impact the congestion behavior of the Internet, and may be used on any Internet link. The scheme has particular benefits for slow links. It is widely implemented and widely deployed on links operating at less than 2 Mbps. This is recommended as a mitigation on its own or in combination with one of the other described techniques.
推薦: 1流れあたりの列を作りは上流のボトルネックリンクで実行されたわかりやすい変更です。 流れ(またはクラス単位で)あたりのスケジューリングは、インターネットの混雑の振舞いに影響を与えないで、どんなインターネットリンクの上にも使用されるかもしれません。 計画には、遅いリンクへの特別の利益があります。 それは、2Mbpsで作動しながら、広く実行されて、リンクの上に広く配備されます。 それ自身かもう片方の1つと組み合わせた緩和がテクニックについて説明したので、これはお勧めです。
5.4.2 ACKs-first Scheduling
5.4.2 ACKs-最初のスケジューリング
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 Schedulingは双方向の転送の性能を向上させる実験技術です。 この場合、データ・パケットとACKsは上流のボトルネックリンク[RFC3150]でリソースを競争します。 ただ一つの先入れ先出し、先入れ先出し法は両方のデータ・パケットのために列を作ります、そして、ACKsは前進の転送の性能に影響を与えるかもしれません。 例えば、1つのキロバイトの大きさで分けられたデータ・パケットのトランスミッションは上流のボトルネックリンクが28.8キロビット毎秒ダイヤルアップ回線であるなら、そのようなちょうど2つのデータ・パケットがACKs(遅れた出発の間、組でデータ・パケットを出して以来のまれな出来事でない)の前に列に並ばせられてもおよそ280原稿Soを持って行って、彼らは半分1秒の上で井戸にACKs入らないようにするでしょう。 2つ以上のデータ・パケットがACKの前に列を作られるなら、ACKsはさらに多くの[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
これを軽減することへの可能なアプローチはデータとACKsの先入れ先出し法と異なって計画をすることです。 1つのアルゴリズムは特にACKs-最初のスケジューリングです。(そのスケジューリングはデータ・パケットの上のACKsの、より高い優先度と一致します)。 そのようなスケジューリングに関する動機が時間を最小にすることによって前進の接続のための遊休時間を最小にするということである、そのACKs
Balakrishnan et. al. Best Current Practice [Page 28] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[28ページ]RFC3449PILC--非対称のリンクス2002年12月
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.
上流のリンクのデータ・パケットの後ろに列に並ばせられた状態で、費やしてください。 同時に、ヘッダー圧縮[RFC1144]などのType0のテクニックで、ACKsのトランスミッション時間は順次データパケットへの影響が最小限ほど小さくなります。 上流のリンクのパケットオーバーヘッドは大きくて、例えば、パケットラジオサブネットワークが例外であるということです、セクション。(中のサブネットワーク、どれ、-、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-最初のスケジューリングは上流のボトルネックリンクで実行された実験的なわかりやすい変更です。 ACKsのボリュームを規制するのにメカニズム(ACK Congestion Control(ACC)、セクション4.3などの)なしで使用されるなら、それはデータ・パケットの飢餓に通じるかもしれません。 これは、リンクを使用することで終わりのホストによって経験されたパフォーマンスに不利な条件であり、インターネット混雑の振舞いを変更しません。 実験は、ACCと組み合わせたACKs-最初のスケジューリングが有望であることを示します。 しかしながら、より広いインターネットでテクニックを使用する経験がほとんどありません。 テクニックのさらなる開発は開いている研究課題のままで残っています、そして、したがって、計画は現在、インターネットの中の使用のために推薦されません。
6. Security Considerations
6. セキュリティ問題
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であるときに、超能力[RFC2406]はIPペイロードをコード化するのに使用されます、どちらも読むことができないで、中間的実体によって変更されたTCPヘッダー。 これはヘッダー圧縮、ACK Filtering、ACK Reconstruction、およびACK Compactionを除外します。
(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
(ii) いくつかのフォームのネットワーク層セキュリティが使用されているとき、TCPヘッダー情報は目に見えるかもしれません。 例えば、IPSec AH[RFC2402]を使用して、TCPヘッダーは、仲介者によって読みますが、変更されないかもしれません。 これは、これから拡大がACK Filteringを支持するのを許容するかもしれませんが、新しいことの世代を除外します。
Balakrishnan et. al. Best Current Practice [Page 29] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[29ページ]RFC3449PILC--非対称のリンクス2002年12月
packets by intermediaries (e.g., ACK Reconstruction). The
enhanced header compression scheme discussed in [RFC2507] would
also work with IPSec AH.
仲介者(例えば、ACK Reconstruction)によるパケット。 また、[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.
Type2計画を使用するとき、潜在的サービスのDenial(DoS)含意があります。 追加担保メカニズムが使用されていない場合、Reconstructor/エキスパンダはパケットアンプとして利用されるかもしれません。 追加ACKsの世代の引き金となって、第三者は逆の経路に権限のないStretch ACKsを注ぐかもしれません。 これらのACKsはリターンパスの容量と経路に沿ったシステムの処理リソースを消費するでしょう、あて先ホストを含んでいて。 これは潜在的プラットホームをDoS攻撃に提供します。 正しいトンネルエンドポイントについて確かめて、アプリケーションが間違って求められていない交通を発生させるように広がるパケットを注入できないのを保証するために普通の注意を払わなければなりません。 また、遅れたACK要素(d)にレート限界とバウンドを課すと、どんな非検出された開発の影響も少なくなるでしょう。
7. Summary
7. 概要
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性能規制を考えます。 そのような性能規制は起こります、例えば、帯域幅(容量)非対称、反対の方向への非対称の共有されたメディアとメディアAccess Control(MAC)プロトコルとの相互作用の両方の結果、。 非対称の容量は、TCP Acknowledgments(ACKs)が失われているか、または過度に遅れるようになることを(例えば、ボトルネックリンクがいつ多くの流れの間で共有されるか、そして、またはいつ、双方向の交通がありますか)引き起こすかもしれません。 この効果はメディアアクセス遅延(例えば、あるマルチホップラジオサブネットワークのDemandアクセスでの衛星Bandwidth)で悪化させられるかもしれません。 非対称、および特定の高い非対称は1セットの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.
性能改良を提供する1セットのテクニックが調査されます。 これらは、TCP送付者がTCP自己時計を破壊しないで珍しいACKsを切り抜けるのを可能にするACK Congestionとテクニックを軽減するためにテクニックを含んでいます。 これらのテクニックは終わり、地方のリンクレイヤ、および終わりからサブネットワークへの両方の計画を含んでいます。 これらのテクニックの多くが、インターネットの一部を形成しながら、非対称のサブネットワークの上で分析、シミュレーション、そして/または、実現で詳細に評価されました。 しかしながら、まだ、いくつかのテクニックのための不十分な運用経験があります、そして、したがって、これらは現在、継続している研究と実験の項目のままで残っています。
Balakrishnan et. al. Best Current Practice [Page 30] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[30ページ]RFC3449PILC--非対称のリンクス2002年12月
The following table summarizes the current recommendations. Mechanisms are classified as recommended (REC), not recommended (NOT REC) or experimental (EXP). Experimental techniques may not be well specified. These techniques will require further operational experience before they can be recommended for use in the public Internet.
以下のテーブルは現在の推薦をまとめます。 メカニズムはお勧め(NOT REC)か実験的(EXP)ではなく、お勧め(REC)として分類されます。 実験技術はよく指定されないかもしれません。 公共のインターネットでの使用のためにそれらを推薦できる前にこれらのテクニックはさらなる運用経験を必要とするでしょう。
The recommendations for end-to-end host modifications are summarized in table 1. This lists each technique, the section in which each technique is discussed, and where it is applied (S denotes the host sending TCP data packets in the forward direction, R denotes the host which receives these data packets).
終わりから終わりへのホスト変更のための推薦はテーブル1にまとめられます。 これは各テクニック(各テクニックが論じられて、それが適用されている(Sはホスト送付TCPデータ・パケットを順方向に指示して、Rはホストを指示します(これらのデータ・パケットを受けます))セクション)を記載します。
+------------------------+-------------+------------+--------+
| 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 |
+------------------------+-------------+------------+--------+
+------------------------+-------------+------------+--------+ | テクニック| 使用| セクション| どこ| +------------------------+-------------+------------+--------+ | 変更された遅れたACKs| RECでない| 4.1 | TCP R| | 大きいMSSといいえは破片手榴弾で殺傷されます。| REC| 4.2 | TCP SR| | 大きいMSSとIPは破片手榴弾で殺傷されます。| RECでない| 4.2 | TCP SR| | ACK輻輳制御| EXP| 4.3 | TCP SR| | ウィンドウPred。 Mech(wpm)| RECでない| 4.4 | TCP R| | ウィンドウCwnd。 エスト。 (ACE)| RECでない| 4.5 | TCP R| | TCP送付者ペース| EXP*1| 4.6 | TCP S| | バイト勘定| REC*2でない| 4.7 | TCP S| | 背圧| 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は上流のボトルネックリンクに続いて、インタフェースを受けながら、指示します)。
Balakrishnan et. al. Best Current Practice [Page 31] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[31ページ]RFC3449PILC--非対称のリンクス2002年12月
+------------------------+-------------+------------+--------+
| 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 |
+------------------------+-------------+------------+--------+
+------------------------+-------------+------------+--------+ | メカニズム| 使用| セクション| タイプ| +------------------------+-------------+------------+--------+ | ヘッダーCompr。 (V-J) | REC*1| 5.1.1 | 0 SR| | ヘッダーCompr。 (ROHC) | REC*1*2| 5.1.2 | 0 SR| +------------------------+-------------+------------+--------+ | (AF)をフィルターにかけるACK| EXP*3| 5.2.1 | 1秒間| | ACK大量殺害| EXP*3| 5.2.2 | 1秒間| +------------------------+-------------+------------+--------+ | ACK再建(AR)| RECでない| 5.3.1 | 2 *4 | | ACK圧縮/Compand| EXP| 5.3.2 | 2秒間*4| | Traff司令官。 Shap。 (GTS)| REC| 5.3.3 | 2 *5 | +------------------------+-------------+------------+--------+ | 公正な待ち行列(FQ)| REC| 5.4.1 | 3秒間| | 最初にACKsスケジューリング| RECでない| 5.4.2 | 3秒間| +------------------------+-------------+------------+--------+
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 他のIETF RFCsは、これらのテクニックの使用のときに新しいTCP圧縮プロトコルの規格化がROHC WGの中の進行中の仕事の対象であると言及します。 *3 インターネットでの使用はトランスミッションが押し破いた過度のTCPを防ぐことの計画に依存しています。 *4 逆の経路に沿ったポイントでは、上流のボトルネックリンクの後に実行されます。 *5 フォワードパスに沿ったポイントでは、実行されます。
8. Acknowledgments
8. 承認
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)作業部会のパフォーマンスImplicationsのメンバーからコメントの利益を得ました。 特に、作者は彼らの役に立つコメントについてジョンBorder、スペンサー・ダウキンズ、アーロン・フォーク、ダン・グロースマン、ランディ・キャッツ、ジェフMandin、Rod Ragland、ラモン・セグーラ、ジョーTouch、およびロイドWoodに感謝したがっています。 また、彼らはそれらのパケットデータ網の操作に関してMetricom Inc.によって提供されたデータを承認します。
9. References
9. 参照
References of the form RFCnnnn are Internet Request for Comments (RFC) documents available online at http://www.rfc-editor.org/.
フォームRFCnnnnの参照はオンラインで利用可能なComments(RFC)ドキュメントのための http://www.rfc-editor.org/ のインターネットRequestです。
Balakrishnan et. al. Best Current Practice [Page 32] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[32ページ]RFC3449PILC--非対称のリンクス2002年12月
9.1 Normative References
9.1 標準の参照
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] ブレーデン、R.、エド、「インターネットホストのための要件--コミュニケーションは層にする」、STD3、RFC1122、10月1989日
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
1990年2月の[RFC1144]ジェーコブソン対「低速連続のリンクへのTCP/IPヘッダーを圧縮すること」でのRFC1144
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March
2000.
[RFC2784] ファリナッチとD.と李とT.とハンクスとS.とマイヤーとD.と2000年のP.Traina、「一般ルーティングのカプセル化(GRE)」、RFC2784行進。
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
Shelby, "Performance Enhancing Proxies Intended to Mitigate
Link-Related Degradations", RFC 3135, June 2001.
[RFC3135]は接しています、J.、Kojo、M.、Griner、モンテネグロ、G.、およびZ.シエルビイ、J.、「パフォーマンスはリンク関連の転落を緩和することを意図するプロキシを高め」て、RFC3135、2001年6月。
9.2 Informative References
9.2 有益な参照
[abc-ID] Allman, M., "TCP Congestion Control with Appropriate Byte
Counting", Work in Progress.
[abc-ID] オールマン、M.、「適切なバイトが重要であることのTCP輻輳制御」が進行中で働いています。
[All97b] Allman, M., "Fixing Two BSD TCP Bugs", Technical Report
CR-204151, NASA Lewis Research Center, October 1997.
[All97b] オールマン、M.、「BSD TCPが悩ます修理Two」、技術報告書CR-204151、NASAルイス・リサーチセンター、1997年10月。
[ANS01] ANSI Standard T1.413, "Network to Customer Installation
Interfaces - Asymmetric Digital Subscriber Lines (ADSL)
Metallic Interface", November 1998.
[ANS01]ANSIの標準のT1.413、「顧客インストールにインタフェースをネットワークでつないでください--非対称のデジタル加入者は(ADSL)金属インタフェースを裏打ちする」1998年11月。
[ASB96] Arora, V., Suphasindhu, N., Baras, J.S. and D. Dillon,
"Asymmetric Internet Access over Satellite-Terrestrial
Networks", Proc. AIAA: 16th International Communications
Satellite Systems Conference and Exhibit, Part 1,
Washington, D.C., February 25-29, 1996, pp.476-482.
[ASB96] AroraとV.とSuphasindhuとN.とBarasとJ.S.とD.ディロン、「衛星地球のネットワークの上の非対称のインターネットアクセス」、Proc。 AIAA: 第16国際交流のSatellite SystemsコンファレンスとExhibit、Part1、1996年2月25日〜29日の間のワシントンDC 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.、サヴェージ、S.、およびT.アンダーソン、「TCPペースのパフォーマンスを理解しています」、Proc。 IEEE INFOCOM、Tel- Aviv、イスラエルV.3、2000年3月、ページ 1157-1165.
Balakrishnan et. al. Best Current Practice [Page 33] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[33ページ]RFC3449PILC--非対称のリンクス2002年12月
[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/
Balakrishnan(H.)が「種々雑多なワイヤレス・ネットワークの上の確実な資料輸送に挑戦する」[Bal98]、博士Thesis、カリフォルニア大学バークレイ校、米国(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.キャッツと「TCPパフォーマンスへの非対称の効果」とACMのモバイルNetworksとApplications(モネ)、Vol.4、No.3、1999、ページ 219-241. Procで発行された論文の拡張バージョン。 ACM/IEEE移動通信コンファレンス(MOBICOM)、1997。
[BPS00] Bennett, J. C., Partridge, C., and N. Schectman, "Packet
Reordering is Not Pathological Network Behaviour", IEEE/ACM
Transactions on Networking, Vol. 7, Issue. 6, 2000,
pp.789-798.
[BPS00]ベネット、Networking、Vol.7(Issue)のJ.C.とPartridge、C.とN.Schectman、「パケットReorderingはNot Pathological Network Behaviourである」IEEE/ACM Transactions。 6 2000、pp.789-798。
[Cla88] Clark, D.D, "The Design Philosophy of the DARPA Internet
Protocols", ACM Computer Communications Review (CCR), Vol.
18, Issue 4, 1988, pp.106-114.
[Cla88]クラーク、D.D、「DARPAインターネットプロトコルの設計理念」、ACMコンピュータCommunications Review(CCR)、Vol.18、Issue4、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] IEEEコミュニケーション雑誌(Vol.37)は、クローゼン、H.、ランデール、H.、およびB.Collini-ノッカー、「放送衛星の上のインターネット」と発行します。 6 1999、pp.146-151。
[CLP98] Calveras, A., Linares, J., and J. Paradells, "Window
Prediction Mechanism for Improving TCP in Wireless
Asymmetric Links". Proc. IEEE Global Communications
Conference (GLOBECOM), Sydney Australia, November 1998,
pp.533-538.
[CLP98] Calveras、A.、リナレス、J.、およびJ.Paradells、「無線の非対称のリンクでTCPを改良するためのウィンドウ予測メカニズム。」 Proc。 IEEE Global Communicationsコンファレンス(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.
Networking、Vol.6、No.1、1998(pp.15-29)の[CR98]コーエン、R.とRamanathan、S.、「ハイブリッドファイバー同軸広帯域アクセスネットワークにおける高性能のための調律TCP」IEEE/ACM Transactions。
[DS00] Cable Television Laboratories, Inc., Data-Over-Cable
Service Interface Specifications---Radio Frequency
Interface Specification SP-RFIv1.1-I04-00407, 2000
[DS00]ケーブルテレビ研究所Inc.、データ過剰ケーブルサービスインターフェース仕様---無線周波数インターフェース仕様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、ケーブルテレビ研究所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]はあえてそうしました、R.、ミラー、G.とE.トラヴィス、「スペースコミュニケーションズのためのTCP拡張子」ACM/IEEEのモバイルCommunicationsコンファレンス(MOBICOM)、ニューヨーク(米国)1996年11月、pp.15 26。
Balakrishnan et. al. Best Current Practice [Page 34] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[34ページ]RFC3449PILC--非対称のリンクス2002年12月
[EN97] "Digital Video Broadcasting (DVB); DVB Specification for
Data Broadcasting", European Standard (Telecommunications
series) EN 301 192, 1997.
[EN97] 「(DVB)を放送するデジタルビデオ」。 「Data BroadcastingのためのDVB Specification」、ヨーロッパのStandard(テレコミュニケーションシリーズ)EN301 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)を放送するデジタルビデオ」。 「Satellite Distribution Systemsのための相互作用Channel」、DraftのヨーロッパのStandard(テレコミュニケーションシリーズ)ETSI、Draft EN301 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.
Networking、Vol.1、No.4、1993(pp.397-413)の[FJ93]フロイド、S.とV.ジェーコブソン、「Congestion Avoidanceのための無作為のEarly Detectionゲートウェイ」IEEE/ACM Transactions。
[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.、ホドソン、K.、およびR.Donardio、「パフォーマンスは非対称のサービスで広帯域の衛星を使用することで支給を発行します」、Communicationの上のIEE Proceedings、Vol.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] ジェーコブソンと、V.と、「輻輳回避とコントロール」、Proc。 ACM SIGCOMM、スタンフォード、カリフォルニア、ACMコンピュータCommunications Review(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]ケントC.A.、およびJ.C.ムガール人、「有害であると考えられた断片化」、Proc。 ACM SIGCOMM、米国ACMコンピュータCommunications Review(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.ゴールドスティーン、「非対称の衛星ネットワークのプロトコルへの効果」、Proc。 IEEE Military Communicationsコンファレンス(MILCOM)、ブラッドフォード、MA(米国)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.とバルマー、A.とRamakrishnan、K.K.、「両用非対称のリンクの上にTCPスループットを改良します:」 「分析と解答」、Proc。 ACM SIGMETRICS、Medison、米国1998、pp.78-89。
[LM97] Lin, D., and R. Morris, "Dynamics of Random Early
Detection", Proc. ACM SIGCOMM, Cannes, France, ACM Computer
Communications Review (CCR), Vol.27, No.4, 1997, pp.78-89.
[LM97]リン、D.とR.モリス、「無作為の早期発見の力学」Proc。 ACM SIGCOMM、カンヌ(フランス)ACMコンピュータCommunications Review(CCR)、Vol.27、No.4、1997、pp.78-89。
Balakrishnan et. al. Best Current Practice [Page 35] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[35ページ]RFC3449PILC--非対称のリンクス2002年12月
[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、日本神戸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]明-子供とI.T.とJinsong、D.とW.ワング、「非対称のネットワークの上のTCP性能を向上させます」、ACM SIGCOMM、ACMコンピュータコミュニケーションは(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.、「ウェブデータの挑戦が輸送するアドレシング」、博士号Thesis、カリフォルニア大学バークレイ校、米国(1998(Tech Report UCB/CSD98-1016も)年9月) http://www.cs.berkeley.edu/~padmanab/phd- thesis.html
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン(V.、ブレーデン、R. and D.ボーマン、「高性能のためのTCP拡張子」、RFC1323)は1992がそうするかもしれません。
[RFC2018] Mathis, B., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018] マシスとB.とMahdaviとJ.とフロイドとS.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC2507] デーゲルマルクとM.とNordgrenとB.とS.ピンク、「IPヘッダー圧縮」、RFC2507、1999年2月。
[RFC2525] Paxson, V., Allman, M., Dawson, S., Heavens, I. and B.
Volz, "Known TCP Implementation Problems", RFC 2525, March
1999.
[RFC2525] パクソンとV.とオールマンとM.とドーソンとS.と天とI.とB.フォルツ、「知られているTCP実現問題」、RFC2525、1999年3月。
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link PPP",
RFC 2686, September 1999.
[RFC2686] ボルマン、C.、「マルチリンクpppへのマルチのクラス拡大」、RFC2686、1999年9月。
[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Henderson,
T., Heidemann, J., Kruse, H., Ostermann, S., Scott, K.,
Semke, J., Touch, J. and D. Tran, "Ongoing TCP Research
Related to Satellites", RFC 2760, February 2000.
[RFC2760] オールマン、M.、ダウキンズ、S.、手袋製造業者、D.、Griner、J.、ヘンダーソン、T.、Heidemann、J.、クルーゼ、H.、オステルマン、S.、スコット、K.、Semke、J.、接触、J.、およびD.チャン、「進行中のTCP研究は衛星に関連しました」、RFC2760、2000年2月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N. and Y.
Zhang, "A link Layer tunneling mechanism for unidirectional
links", RFC 3077, March 2001.
[RFC3077] Duros、E.、Dabbous、W.、Izumiyama、H.、藤井、N.、およびY.チャン、「単方向の間のリンクLayerトンネリングメカニズムはリンクします」、RFC3077、2001年3月。
Balakrishnan et. al. Best Current Practice [Page 36] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[36ページ]RFC3449PILC--非対称のリンクス2002年12月
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, E., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,
T., Yoshimura, T. and H. Zheng, "RObust Header Compression
(ROHC): Framework and four profiles: RTP, UDP ESP and
uncompressed", RFC 3095, July 2001.
[RFC3095] ボルマン、C.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 枠組みと4個のプロフィール: 「UDP ESPであって解凍されたRTP」、RFC3095、7月2001日
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-
to-end Performance Implications of Slow Links", BCP 48, RFC
3150, July 2001.
[RFC3150]ダウキンズ、S.、モンテネグロ、G.、Kojo(M.とV.Magret)は「Slowリンクスの終わりまでのパフォーマンスImplicationsを終わります」、BCP48、RFC3150、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.、フロイド、S.とD.Black、「Explicit Congestion Notification(電子証券取引ネットワーク)をIPに追加するProposal」RFC3168(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コンピュータ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]セグーラR.、「ハイブリッド衛星通信のための非対称のネットワークのテクニック」、NC3A、ハーグ(オランダ)NATO Technical Note810、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の国際Networksコンファレンス(INC98)、プリマスイギリス、1998、pp.23-28。
[ZSC91] Zhang, L., Shenker, S., and D. D. Clark, "Observations and
Dynamics of a Congestion Control Algorithm: The Effects of
Two-Way Traffic", Proc. ACM SIGCOMM, ACM Computer
Communications Review (CCR), Vol 21, No 4, 1991, pp.133-
147.
[ZSC91] チャン、L.、Shenker、S.、およびD.D.クラーク、「輻輳制御アルゴリズムの観測と力学:」 「両面交通の効果」、Proc。 ACM SIGCOMM、ACMコンピュータCommunications Review(CCR)、Vol21、いいえ4、1991、pp.133 147。
10. IANA Considerations
10. IANA問題
There are no IANA considerations associated with this document.
このドキュメントに関連しているどんなIANA問題もありません。
Balakrishnan et. al. Best Current Practice [Page 37] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[37ページ]RFC3449PILC--非対称のリンクス2002年12月
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のサービスオーバーの何らかの広い領域の、そして、ローカルの領域ワイヤレス・ネットワーク。 そのようなネットワークでは、支配的なネットワーク経路非対称はネットワーク(例えば、複数の移動局とコミュニケートする単独ベースステーション)のハブとスポーク構造から起こって、これはラジオのためにReady To Send/明確なTo Send(RTS/CTS)プロトコルと重要なターンアラウンドタイムを収容する必要があるMedium Access Control(MAC)プロトコルを必要とします。 1パケット伝送あたり1つの高いオーバーヘッドが重要なネットワーク経路非対称につながるかもしれません。
- 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.
- Digital Video Broadcast(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.
- 狭帯域上流との高容量川下の衛星中継(2-3 例えば、Mbps)を使用することでトランジットの、または、孤立しているホスト[Seg00]へのインターネット・アクセスを提供するあるミリタリー・ネットワーク[KSG98]が、Demand Assigned Multiple Access(DAMA)か定率衛星中継のどちらかを使用することで(2.4-9.6 例えば、キロビット毎秒)をリンクします。 ネットワーク経路非対称に貢献する主な要因は上流の、そして、川下のリンク能力の違いです。 前進の、そして、逆の経路のいくつかの違いが上流のリンク容量が割り当てられる方法から起こるかもしれません。
- 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
- ケーブルテレビの上のほとんどのデータが(例えば、DOCSIS[ITU01、DS00])をネットワークでつなぎます、上流のコミュニケーション(すなわち、反対の方向への)のために選任されたアナログチャンネルが、より細長く、川下のリンクに割り当てられたものより騒がしいかもしれないところで。 結果として、上流の、そして、川下のリンクはそれらの通信速度において異なります。 例えば、DOCSIS1.0[DS00]では、川下の通信速度は27か52Mbpsです。 上流の通信速度は166キロビット毎秒の間で9Mbpsに及ぶ一連のレートの1つであることがダイナミックに選択されるかもしれません。 オペレータは複数の川下のチャンネルあたりの上流のチャンネルを選任するかもしれません。 また、物理的な層(PHY)のオーバーヘッド(上流のトランスミッションに伴いますが、川下のリンクに存在していない)はネットワーク経路非対称を増加させることができます。 Best Effortサービス(TCPを運ぶのに通常利用される)はaを使用します。
Balakrishnan et. al. Best Current Practice [Page 38] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[38ページ]RFC3449PILC--非対称のリンクス2002年12月
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].
主張/予約MACは議定書を作ります。 孤立しているパケット(TCP ACKなどの)を上流のリンクに送るケーブルモデム(CM)は、主要なケーブルモデム終了システム(CMTS)から容量を要求するために他のCMを競争しなければなりません。 そして、CMTSは上流のトランスミッションのためにtimeslotsをCMに与えます。 主張サイクルを避けて、CMはその後の要求を上流のパケットに「便乗するかもしれません」。 その結果、ケーブルデータ網の荷重とTCP DATAパケットの相互到着時間の小さい方の変化のためTCP ACKsのスペースを劇的に変更できます。 他の多数の複雑さが加えるか、または緩和するかもしれない、潜在がパケットでなったレートとアクセスにおける非対称はDOCSISの川下のパケットに比例して上流のリンクを転送しました。 また、終わりのホストによって経験された非対称はダイナミック(例えば、ネットワーク負荷で)、ベストエフォート型サービスが左右対称の予約された容量(例えば、Unsolicitedグラントのサービスの上の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)は定義上上流のリンクのものより高い川下のリンク通信速度を提供します。 有効なレートはチャンネル品質とシステム構成に依存します。 例えば、1つの広く配備されたADSL技術[ITU02、ANS01]が川下のリンクの32キロビット毎秒(最大6.144Mbps)、および上流のリンクへの最大640キロビット毎秒の倍数であるレートで作動します。 ベストエフォート型サービス(例えば、ADSLの上のインターネット・アクセス)が予約されたサービス(例えば、固定ビットレート音声電話技術)と有効な上流の容量を共有するとき、終わりのホストによって経験されたネットワーク経路非対称はさらに増加するかもしれません。
Balakrishnan et. al. Best Current Practice [Page 39] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[39ページ]RFC3449PILC--非対称のリンクス2002年12月
Authors' Addresses
作者のアドレス
Hari Balakrishnan Laboratory for Computer Science 200 Technology Square Massachusetts Institute of Technology Cambridge, MA 02139 USA
Balakrishnanコンピュータ科学研究所200の技術の正方形のハーリマサチューセッツ工科大学MA02139ケンブリッジ(米国)
Phone: +1-617-253-8713 EMail: hari@lcs.mit.edu Web: http://nms.lcs.mit.edu/~hari/
以下に電話をしてください。 +1-617-253-8713 メールしてください: hari@lcs.mit.edu ウェブ: http://nms.lcs.mit.edu/~hari/
Venkata N. Padmanabhan Microsoft Research One Microsoft Way Redmond, WA 98052 USA
Venkata N.Padmanabhanマイクロソフトは1つのマイクロソフト方法でワシントン98052レッドモンド(米国)について研究します。
Phone: +1-425-705-2790 EMail: padmanab@microsoft.com Web: http://www.research.microsoft.com/~padmanab/
以下に電話をしてください。 +1-425-705-2790 メールしてください: padmanab@microsoft.com ウェブ: http://www.research.microsoft.com/~padmanab/
Godred Fairhurst Department of Engineering Fraser Noble Building University of Aberdeen Aberdeen AB24 3UE UK
アバディーンアバディーンAB24 3UEイギリスのGodred Fairhurst工学部フレーザ素晴らしい建築物大学
EMail: gorry@erg.abdn.ac.uk Web: http://www.erg.abdn.ac.uk/users/gorry
メール: gorry@erg.abdn.ac.uk ウェブ: http://www.erg.abdn.ac.uk/users/gorry
Mahesh Sooriyabandara Department of Engineering Fraser Noble Building University of Aberdeen Aberdeen AB24 3UE UK
アバディーンアバディーンAB24 3UEイギリスのマヘシュSooriyabandara工学部フレーザ素晴らしい建築物大学
EMail: mahesh@erg.abdn.ac.uk Web: http://www.erg.abdn.ac.uk/users/mahesh
メール: mahesh@erg.abdn.ac.uk ウェブ: http://www.erg.abdn.ac.uk/users/mahesh
Balakrishnan et. al. Best Current Practice [Page 40] RFC 3449 PILC - Asymmetric Links December 2002
Balakrishnan etアル。 最も良い現在の習慣[40ページ]RFC3449PILC--非対称のリンクス2002年12月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Balakrishnan et. al. Best Current Practice [Page 41]
Balakrishnan etアル。 最も良い現在の習慣[41ページ]
一覧
スポンサーリンク
