RFC3481 日本語訳
3481 TCP over Second (2.5G) and Third (3G) Generation WirelessNetworks. H. Inamura, Ed., G. Montenegro, Ed., R. Ludwig, A. Gurtov,F. Khafizov. February 2003. (Format: TXT=61528 bytes) (Also BCP0071) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Inamura, Ed.
Request for Comments: 3481 NTT DoCoMo, Inc.
BCP: 71 G. Montenegro, Ed.
Category: Best Current Practice Sun Microsystems Laboratories
Europe
R. Ludwig
Ericsson Research
A. Gurtov
Sonera
F. Khafizov
Nortel Networks
February 2003
ワーキンググループH.Inamura、エドをネットワークでつないでください。コメントのために以下を要求してください。 3481株式会社NTTドコモBCP: 71 エドG.モンテネグロ、カテゴリ: 最も良い現在のPracticeのサン・マイクロシステムズ研究所ヨーロッパR.ラドウィグエリクソンは2003年2月にA.GurtovソネラF.Khafizovノーテルネットワークについて研究します。
TCP over Second (2.5G) and Third (3G) Generation Wireless Networks
2番目の(2.5G)と第3(3G)世代ワイヤレス・ネットワークの上の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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet.
このドキュメントが適合するようにTCPを最適化するためのプロフィールについて説明するので、それは2番目の(2.5G)と3(3G)番目の世代ワイヤレス・ネットワークを含む経路を扱います。 それは2.5Gと3Gネットワークの関連特性、およびそのようなネットワークの例の展開の特定の特徴について説明します。 次に、それはそのような経路で出発するか終わるのが知られているノードのためのアルゴリズム選択をTCPに推薦します、そして、また、未解決の問題について議論します。 このドキュメントのお勧めの設定オプションは、近代的なTCPスタックで一般的に見つけられて、共同体が一般的なインターネットにおける使用に安全であると考える広く利用可能な標準化過程メカニズムです。
Inamura, et al. Best Current Practice [Page 1] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[1ページ]RFC3481TCP
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. 2.5G and 3G Link Characteristics. . . . . . . . . . . . . . . 4
2.1 Latency. . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Data Rates . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Asymmetry . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Delay Spikes . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Packet Loss Due to Corruption. . . . . . . . . . . . . . 7
2.6 Intersystem Handovers. . . . . . . . . . . . . . . . . . 7
2.7 Bandwidth Oscillation. . . . . . . . . . . . . . . . . . 7
3. Example 2.5G and 3G Deployments . . . . . . . . . . . . . . . 8
3.1 2.5G Technologies: GPRS, HSCSD and CDMA2000 1XRTT. . . . 8
3.2 A 3G Technology: W-CDMA. . . . . . . . . . . . . . . . . 8
3.3 A 3G Technology: CDMA2000 1X-EV. . . . . . . . . . . . . 10
4. TCP over 2.5G and 3G. . . . . . . . . . . . . . . . . . . . . 10
4.1 Appropriate Window Size (Sender & Receiver). . . . . . . 11
4.2 Increased Initial Window (Sender). . . . . . . . . . . . 11
4.3 Limited Transmit (Sender). . . . . . . . . . . . . . . . 12
4.4 IP MTU Larger than Default . . . . . . . . . . . . . . . 12
4.5 Path MTU Discovery (Sender & Intermediate Routers) . . . 13
4.6 Selective Acknowledgments (Sender & Receiver). . . . . . 13
4.7 Explicit Congestion Notification (Sender, Receiver &
Intermediate Routers). . . . . . . . . . . . . . . . . . 13
4.8 TCP Timestamps Option (Sender & Receiver). . . . . . . . 13
4.9 Disabling RFC 1144 TCP/IP Header Compression (Wireless
Host) . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. Normative References . . . . . . . . . . . . . . . . . . . . . 19
10. Informative References . . . . . . . . . . . . . . . . . . . . 21
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 2.5 Gと3Gは特性をリンクします。 . . . . . . . . . . . . . . 4 2.1 潜在。 . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2のデータ信号速度. . . . . . . . . . . . . . . . . . . . . . . 5 2.3の非対称. . . . . . . . . . . . . . . . . . . . . . . 6 2.4は不正によるスパイクス.62.5パケット損失を遅らせます。 . . . . . . . . . . . . . 7 2.6 項間身柄の引き渡し。 . . . . . . . . . . . . . . . . . 7 2.7 帯域幅振動。 . . . . . . . . . . . . . . . . . 7 3. 例の2.5Gと3G展開. . . . . . . . . . . . . . . 8 3.1 2.5G技術: GPRS、HSCSD、およびCDMA2000 1XRTT。 . . . 8 3.2 3G技術: W-CDMA。 . . . . . . . . . . . . . . . . 8 3.3 3G技術: CDMA2000 1X-ev。 . . . . . . . . . . . . 10 4. 2.5Gと3Gの上のTCP。 . . . . . . . . . . . . . . . . . . . . 10 4.1はウィンドウサイズ(送付者と受信機)を当てます。 . . . . . . 11 4.2は初期の窓(送付者)を増強しました。 . . . . . . . . . . . 4.3が制限した11は(送付者)を伝えます。 . . . . . . . . . . . . . . . 12 4.4 .134.6のデフォルト. . . . . . . . . . . . . . . 12 4.5経路MTU発見(送付者と中間的ルータ)の選択している承認(送付者と受信機)より大きいIP MTU。 . . . . . 13 4.7 明白な混雑通知(送付者、受信機、および中間的ルータ)。 . . . . . . . . . . . . . . . . . 13 4.8 TCPタイムスタンプオプション(送付者と受信機)。 . . . . . . . 13 4.9 RFC1144TCP/IPヘッダー圧縮(ワイヤレスのホスト)が.15 4.10概要. . . . . . . . . . . . . . . . . . . . . . . . . 16 5であると無効にします。 問題. . . . . . . . . . . . . . . . . . . . . . . . . 16 6を開いてください。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 18 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 18 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 19 9。 引用規格. . . . . . . . . . . . . . . . . . . . . 19 10。 有益な参照. . . . . . . . . . . . . . . . . . . . 21 11。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 25 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 26
Inamura, et al. Best Current Practice [Page 2] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[2ページ]RFC3481TCP
1. Introduction
1. 序論
The second generation cellular systems are commonly referred to as 2G. The 2G phase began in the 1990s when digital voice encoding had replaced analog systems (1G). 2G systems are based on various radio technologies including frequency-, code- and time- division multiple access. Examples of 2G systems include GSM (Europe), PDC (Japan), and IS-95 (USA). Data links provided by 2G systems are mostly circuit-switched and have transmission speeds of 10-20 kbps uplink and downlink. Demand for higher data rates, instant availability and data volume-based charging, as well as lack of radio spectrum allocated for 2G led to the introduction of 2.5G (for example, GPRS and PDC-P) and 3G (for example, Wideband CDMA and cdma2000) systems.
二世セルラ方式は一般的に2Gと呼ばれます。 2Gフェーズはデジタル声のコード化がアナログ・システム(1G)を置き換えた1990年代に始まりました。 2Gシステムは頻度、コード、および時間分割倍数アクセサリーを含む様々なラジオ技術に基づいています。 そして、GSM(ヨーロッパ)、PDC(日本)を2Gシステムに関する例が含んでいる、-95である、(米国。) 2Gシステムによって提供されたデータ・リンクは、回路によってほとんど切り換えられて、10-20 キロビット毎秒アップリンクとダウンリンクの伝送速度を持っています。 2Gのために割り当てられた電波スペクトルの、より高いデータ信号速度、即時の有用性、データのボリュームベースの充電、および不足の要求は2.5G(例えば、GPRSとPDC-P)と3G(例えば、Wideband CDMAとcdma2000)システムの導入につながりました。
Radio technology for both Wideband CDMA (W-CDMA) (adopted, for example, in Europe, Japan, etc) and cdma2000 (adopted, for example, in US, South Korea, etc) is based on code division multiple access allowing for higher data rates and more efficient spectrum utilization than 2G systems. 3G systems provide both packet-switched and circuit-switched connectivity in order to address the quality of service requirements of conversational, interactive, streaming, and bulk transfer applications. The transition to 3G is expected to be a gradual process. Initially, 3G will be deployed to introduce high capacity and high speed access in densely populated areas. Mobile users with multimode terminals will be able to utilize existing coverage of 2.5G systems on the rest of territory.
Wideband CDMA(W-CDMA)(例えば、ヨーロッパ、日本などで採用される)とcdma2000(例えば、米国、韓国などで採用される)の両方のためのラジオ技術は、より高いデータ信号速度を考慮する符号分割多重接続と2Gシステムより効率的なスペクトル利用に基づいています。3Gシステムは、サービスの質が会話の、そして、対話的で、ストリーミングの、そして、大量の転送アプリケーションの要件であると扱うためにパケットで切り換えられたものと同様に回路で切り換えられた接続性を提供します。 3Gへの変遷は緩やかなプロセスであると予想されます。 初めは、3Gは、人口密集地域で高容量と高速アクセスを導入するために配布されるでしょう。 マルチモード端末をもっているモバイルユーザは領土の残りのときに2.5Gシステムの既存のサービスエリアを利用できるでしょう。
Much development and deployment activity has centered around 2.5G and 3G technologies. Along with objectives like increased capacity for voice channels, a primary motivation for these is data communication, and, in particular, Internet access. Accordingly, key issues are TCP performance and the several techniques which can be applied to optimize it over different wireless environments [19].
多くの開発と展開活動は2.5Gと3Gの周りの技術を中心に置きました。 音声チャンネルのための増強された容量のような目的と共に、これらに関するプライマリ動機は、データ通信と、特にインターネット・アクセスです。 主要な問題は、それに従って、異なったワイヤレスの環境[19]の上でそれを最適化するために適用できるTCP性能といくつかのテクニックです。
This document proposes a profile of such techniques, (particularly effective for use with 2.5G and 3G wireless networks). The configuration options in this document are commonly found in modern TCP stacks, and are widely available IETF standards-track mechanisms that the community has judged to be safe on the general Internet (that is, even in predominantly non-wireless scenarios). Furthermore, this document makes one set of recommendations that covers both 2.5G and 3G networks. Since both generations of wireless technologies exhibit similar challenges to TCP performance (see Section 2), one common set is warranted.
このドキュメントは(使用には特に2.5Gと3Gワイヤレス・ネットワークによって有効)のそのようなテクニックのプロフィールを提案します。 設定オプションは、近代的なTCPスタックで本書では一般的に見つけられて、共同体が一般的なインターネット(すなわち、支配的に非ワイヤレスのシナリオさえの)で安全であると判断した広く利用可能なIETF標準化過程メカニズムです。 その上、このドキュメントは2.5Gと3Gの両方をカバーする1セットの推薦状をネットワークにします。 両方の世代の無線技術がTCP性能への同様の挑戦を示すので(セクション2を見てください)、一般的な1セットは保証されます。
Inamura, et al. Best Current Practice [Page 3] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[3ページ]RFC3481TCP
Two example applications of the recommendations in this document are:
推薦の2つの例の応用は本書では以下の通りです。
o The WAP Forum [25] (part of the Open Mobile Alliance [26] as of
June 2002) is an industry association that has developed standards
for wireless information and telephony services on digital mobile
phones. In order to address WAP functionality for higher speed
networks such as 2.5G and 3G networks, and to aim at convergence
with Internet standards, the WAP Forum thoroughly revised its
specifications. The resultant version 2.0 [31] adopts TCP as its
transport protocol, and recommends TCP optimization mechanisms
closely aligned with those described in this document.
o WAP Forum[25](2002年6月現在オープンのモバイルAlliance[26]の一部)はデジタル携帯電話の上でワイヤレスの情報と電話サービスの規格を開発した企業団体です。 2.5Gや3Gネットワークなどの、より高い速度ネットワーク、インターネット標準との集合を目的とするためにWAPに機能性を扱うために、WAP Forumは仕様を徹底的に改訂しました。 結果のバージョン2.0[31]は、トランスポート・プロトコルとしてTCPを採用して、TCP最適化メカニズムが密接に本書では説明されるそれらに並んだことを勧めます。
o I-mode [33] is a wireless Internet service deployed on handsets in
Japan. The newer version of i-mode runs on FOMA [34], an
implementation of W-CDMA. I-mode over FOMA deploys the profile of
TCP described in this document.
o iモード[33]は日本の受話器の上で配布されたワイヤレスのインターネットのサービスです。 iモードの、より新しいバージョンはフォーマ[34]、W-CDMAの実装で動きます。 フォーマの上のiモードは本書では説明されたTCPのプロフィールを配布します。
This document is structured as follows: Section 2 reviews the link layer characteristics of 2.5G/3G networks; Section 3 gives a brief overview of some representative 2.5G/3G technologies like W-CDMA, cdma2000 and GPRS; Section 4 recommends mechanisms and configuration options for TCP implementations used in 2.5G/3G networks, including a summary in chart form at the end of the section; finally, Section 5 discusses some open issues.
このドキュメントは以下の通り構造化されます: セクション2は2.5G/3Gネットワークのリンクレイヤの特性について調査します。 セクション3はW-CDMA、cdma2000、およびGPRSのようにいくつかの代表している2.5G/3G技術の簡潔な概要を与えます。 セクション4は2.5G/3Gネットワークに使用されるTCP実装のためのメカニズムと設定オプションを推薦します、図表でセクションの端に概要を含んでいて。 最終的に、セクション5はいくつかの未解決の問題について議論します。
2. 2.5G and 3G Link Characteristics
2. 2.5 Gと3Gは特性をリンクします。
Link layer characteristics of 2.5G/3G networks have significant effects on TCP performance. In this section we present various aspects of link characteristics unique to the 2.5G/3G networks.
2.5G/3Gネットワークのリンクレイヤの特性はTCP性能に重要な影響を与えます。 このセクションでは、私たちは2.5G/3Gネットワークにユニークなリンクの特性の種々相を示します。
2.1 Latency
2.1 潜在
The latency of 2.5G/3G links is high mostly due to the extensive processing required at the physical layer of those networks, e.g., for FEC and interleaving, and due to transmission delays in the radio access network [58] (including link-level retransmissions). A typical RTT varies between a few hundred milliseconds and one second. The associated radio channels suffer from difficult propagation environments. Hence, powerful but complex physical layer techniques need to be applied to provide high capacity in a wide coverage area in a resource efficient way. Hopefully, rapid improvements in all areas of wireless networks ranging from radio layer techniques over signal processing to system architecture will ultimately also lead to reduced delays in 3G wireless systems.
例えば、ほとんどそれらのネットワークの物理的な層で必要である大規模な処理のためと、FECとインターリービングと、トランスミッションのため2.5G/3Gリンクの潜在はラジオアクセスネットワーク[58]の高い遅れ(リンク・レベル「再-トランスミッション」を含んでいて)です。 典型的なRTTは数100ミリセカンドと1秒の間異なります。 関連ラジオチャンネルは難しい伝播環境に悩みます。 したがって、強力な、しかし、複雑な物理的な層のテクニックは、リソースの効率的な方法で広い適用範囲の地域に高容量を提供するために適用される必要があります。 うまくいけば、また信号処理の上のラジオ層のテクニックからシステム構築まで及ぶのが結局通じるワイヤレス・ネットワークのすべての領域での急速な改良は3Gワイヤレスシステムで遅れを縮めました。
Inamura, et al. Best Current Practice [Page 4] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[4ページ]RFC3481TCP
2.2 Data Rates
2.2 データ信号速度
The main incentives for transition from 2G to 2.5G to 3G are the increase in voice capacity and in data rates for the users. 2.5G systems have data rates of 10-20 kbps in uplink and 10-40 kbps in downlink. Initial 3G systems are expected to have bit rates around 64 kbps in uplink and 384 kbps in downlink. Considering the resulting bandwidth-delay product (BDP) of around 1-5 KB for 2.5G and 8-50 KB for 3G, 2.5G links can be considered LTNs (Long Thin Networks [19]), and 3G links approach LFNs (Long Fat Networks [2], as exemplified by some satellite networks [48]). Accordingly, interested readers might find related and potentially relevant issues discussed in RFC 2488 [49]. For good TCP performance both LFNs and LTNs require maintaining a large enough window of outstanding data. For LFNs, utilizing the available network bandwidth is of particular concern. LTNs need a sufficiently large window for efficient loss recovery. In particular, the fast retransmit algorithm cannot be triggered if the window is less than four segments. This leads to a lengthy recovery through retransmission timeouts. The Limited Transmit algorithm RFC 3042 [10] helps avoid the deleterious effects of timeouts on connections with small windows. Nevertheless, making full use of the SACK RFC 2018 [3] information for loss recovery in both LFNs and LTNs may require twice the window otherwise sufficient to utilize the available bandwidth.
3Gへの2Gから2.5Gまでの変遷のための主な誘因は声の容量とユーザのためのデータ信号速度の増加です。 2.5 Gシステムには、アップリンクと10-40キロビット毎秒における、ダウンリンクにおける、10-20 キロビット毎秒のデータ信号速度があります。 初期の3Gシステムにはアップリンクと384キロビット毎秒におけるダウンリンクにおけるビット伝送速度およそ64キロビット毎秒があると予想されます。 Thin Networks[19])、および3GリンクアプローチLFNsを切望してください。3Gのために結果として起こる帯域幅遅れがおよそ1-5KBの製品(BDP)であると2.5Gと8-50KB考える場合、LTNsであると2.5Gリンクを考えることができる、((Fat Networks[2]を切望してください、いくつかの衛星ネットワーク[48])によって例示されるように。 それに従って、興味のある読者はRFC2488[49]で議論した関連して潜在的に関連している問題を見つけるかもしれません。 良いTCP性能のために、LFNsとLTNsの両方が、十分大きい窓を維持するのを傑出しているデータを要求します。 LFNsに関しては、利用可能なネットワーク回線容量を利用するのは、特別の関心のものです。 LTNsは効率的な損失回復に十分大きい窓を必要とします。 特に、速さはアルゴリズムを再送します。窓が4つ未満のセグメントであるなら引き起こすことができません。 これは再送タイムアウトによる長い回復に通じます。 株式会社TransmitアルゴリズムRFC3042[10]は、小さい窓との接続へのタイムアウトの有害な効果を避けるのを助けます。 それにもかかわらず、LFNsとLTNsの両方での損失回復のためのSACK RFC2018[3]情報を完全に利用するのはそうでなければ、利用可能な帯域幅を利用できるくらいの窓の2倍を必要とするかもしれません。
This document recommends only standard mechanisms suitable both for LTNs and LFNs, and to any network in general. However, experimental mechanisms suggested in Section 5 can be targeted either for LTNs [19] or LFNs [48].
このドキュメントは一般に、どんなネットワークにもLTNsとLFNsと、そして、適した標準のメカニズムだけを推薦します。 しかしながら、セクション5に示された実験メカニズムはLTNs[19]かLFNs[48]のために狙うことができます。
Data rates are dynamic due to effects from other users and from mobility. Arriving and departing users can reduce or increase the available bandwidth in a cell. Increasing the distance from the base station decreases the link bandwidth due to reduced link quality. Finally, by simply moving into another cell the user can experience a sudden change in available bandwidth. For example, if upon changing cells a connection experiences a sudden increase in available bandwidth, it can underutilize it, because during congestion avoidance TCP increases the sending rate slowly. Changing from a fast to a slow cell normally is handled well by TCP due to the self- clocking property. However, a sudden increase in RTT in this case can cause a spurious TCP timeout as described in Section 2.7. In addition, a large TCP window used in the fast cell can create congestion resulting in overbuffering in the slow cell.
データ信号速度は他のユーザと移動性からの効果のためにダイナミックです。 到着して、ユーザを去るのは、セルにおける利用可能な帯域幅を減少するか、または増強できます。 基地局から距離を広げるのは減少しているリンク品質によるリンク帯域幅を静まらせます。 最終的に、単に別のセルの中に移行することによって、ユーザは利用可能な帯域幅の急変を経験できます。 例えば、接続が変化セルで急増を経験するなら、利用可能な帯域幅では、TCPが輻輳回避の間、ゆっくり送付レートを増強するので、それはそれをunderutilizeすることができます。 通常、断食から遅いセルに変化するのは、自己のため特性の時間を計りながら、TCPによってよく扱われます。 しかしながら、この場合、RTTの急増はセクション2.7で説明されるように偽りのTCPタイムアウトを引き起こす場合があります。 さらに、速いセルの中で使用された大きいTCPの窓は遅いセルの中の過剰バッファリングをもたらす混雑を作成できます。
Inamura, et al. Best Current Practice [Page 5] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[5ページ]RFC3481TCP
2.3 Asymmetry
2.3 非対称
2.5G/3G systems may run asymmetric uplink and downlink data rates. The uplink data rate is limited by battery power consumption and complexity limitations of mobile terminals. However, the asymmetry does not exceed 3-6 times, and can be tolerated by TCP without the need for techniques like ACK congestion control or ACK filtering [50]. Accordingly, this document does not include recommendations meant for such highly asymmetric networks.
2.5G/3Gシステムは非対称のアップリンクとダウンリンクデータ信号速度を実行するかもしれません。 アップリンクデータ信号速度は移動体端末のバッテリー電力消費量と複雑さ制限で制限されます。 しかしながら、非対称を、3-6回を超えないで、TCPはACK輻輳制御や[50]をフィルターにかけるACKのようなテクニックの必要性なしで許容できます。 それに従って、このドキュメントはそのような非常に非対称のネットワークのために意味された推薦を含んでいません。
2.4 Delay Spikes
2.4 Delayスパイクス
A delay spike is a sudden increase in the latency of the communication path. 2.5G/3G links are likely to experience delay spikes exceeding the typical RTT by several times due to the following reasons.
遅れスパイクは通信路の潜在の急増です。 2.5G/3Gリンクは以下の理由のため何度かで典型的なRTTを超えている遅れスパイクを経験しそうです。
1. A long delay spike can occur during link layer recovery from a
link outage due to temporal loss of radio coverage, for example,
while driving into a tunnel or within an elevator.
1. 例えば、長時間の遅延スパイクはラジオ適用範囲の時の損失によるリンク供給停止からのリンクレイヤ回復の間、起こることができますトンネルの中、または、エレベーターの中で運転している間。
2. During a handover the mobile terminal and the new base station
must exchange messages and perform some other time-consuming
actions before data can be transmitted in a new cell.
2. 引き渡しの間、新しいセルの中でデータを送ることができる前に、移動体端末と新しい基地局は、メッセージを交換して、ある他の手間がかかった動作を実行しなければなりません。
3. Many wide area wireless networks provide seamless mobility by
internally re-routing packets from the old to the new base station
which may cause extra delay.
3. 多くの広い領域ワイヤレス・ネットワークが、老人の基地局から新しい付加的な遅れを引き起こすかもしれない基地局まで内部的にパケットを別ルートで送ることによって、シームレスの移動性を提供します。
4. Blocking by high-priority traffic may occur when an arriving
circuit-switched call or higher priority data temporarily preempts
the radio channel. This happens because most current terminals
are not able to handle a voice call and a data connection
simultaneously and suspend the data connection in this case.
4. 到着の回路で切り換えられた呼び出しか、より高い優先権データが一時ラジオチャンネルを先取りするとき、高優先度トラフィックによるブロッキングは起こるかもしれません。 ほとんどの現在の端末が同時に、音声通話とデータ接続を扱って、この場合データ接続を停学処分にすることができないので、これは起こります。
5. Additionally, a scheduler in the radio network can suspend a low-
priority data transfer to give the radio channel to higher
priority users.
5. さらに、ラジオ放送網におけるスケジューラは、より高い優先権ユーザのラジオチャンネルに与えるために低い優先権データ転送を中断させることができます。
Delay spikes can cause spurious TCP timeouts, unnecessary retransmissions and a multiplicative decrease in the congestion window size.
遅れスパイクは混雑ウィンドウサイズの偽りのTCPタイムアウト、不要な「再-トランスミッション」、および乗法的な減少を引き起こす場合があります。
Inamura, et al. Best Current Practice [Page 6] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[6ページ]RFC3481TCP
2.5 Packet Loss Due to Corruption
2.5 不正によるパケット損失
Even in the face of a high probability of physical layer frame errors, 2.5G/3G systems have a low rate of packet losses thanks to link-level retransmissions. Justification for link layer ARQ is discussed in [23], [22], [44]. In general, link layer ARQ and FEC can provide a packet service with a negligibly small probability of undetected errors (failures of the link CRC), and a low level of loss (non-delivery) for the upper layer traffic, e.g., IP. The loss rate of IP packets is low due to the ARQ, but the recovery at the link layer appears as delay jitter to the higher layers lengthening the computed RTO value.
物理的な層のフレーム誤りの高い確率に直面してさえ、2.5G/3Gシステムには、リンク・レベル「再-トランスミッション」のおかげでパケット損失の低率があります。 [23]、[22]、[44]でリンクレイヤARQのための正当化について議論します。 一般に、リンクレイヤのARQとFECがパケットサービスに提供できる、無視しうる程度にわずかである、わずかな確率、非検出された誤り(リンクCRCの失敗)、および上側の層のトラフィック(例えば、IP)のための低レベルの損失(非配送) IPパケットの損失率はARQのために低いのですが、リンクレイヤでの回復は計算されたRTO値を伸すより高い層への遅れジターとして現れます。
2.6 Intersystem Handovers
2.6 項間身柄の引き渡し
In the initial phase of deployment, 3G systems will be used as a 'hot spot' technology in high population areas, while 2.5G systems will provide lower speed data service elsewhere. This creates an environment where a mobile user can roam between 2.5G and 3G networks while keeping ongoing TCP connections. The inter-system handover is likely to trigger a high delay spike (Section 2.4), and can result in data loss. Additional problems arise because of context transfer, which is out of scope of this document, but is being addressed elsewhere in the IETF in activities addressing seamless mobility [51].
展開の初期位相では、3Gシステムは'ホットスポット'技術として高い人口領域で使用されるでしょう、2.5Gシステムは下側の速度データサービスをほかの場所に提供するでしょうが。 これはモバイルユーザが進行中のTCP接続を保っている間に2.5Gと3Gネットワークの間を歩き回ることができる環境を作成します。 項間引き渡しは、高い遅れスパイク(セクション2.4)の引き金となりそうであって、データの損失をもたらすことができます。 追加問題は文脈転送で起こります。(このドキュメントの範囲の外にありますが、それは、シームレスの移動性が[51]であると扱いながら、IETFのほかの場所で活動で扱われています)。
Intersystem handovers can adversely affect ongoing TCP connections since features may only be negotiated at connection establishment and cannot be changed later. After an intersystem handover, the network characteristics may be radically different, and, in fact, may be negatively affected by the initial configuration. This point argues against premature optimization by the TCP implementation.
項間身柄の引き渡しは、特徴をコネクション確立で交渉するだけであるかもしれなく、後で変えることができないので、進行中のTCP接続に悪影響を与えることができます。 項間引き渡しの後に、ネットワークの特性は、根本的に異なるかもしれなくて、事実上、初期の構成で否定的に影響を受けるかもしれません。 このポイントはTCP実装で時期尚早な最適化について反対の議論をします。
2.7 Bandwidth Oscillation
2.7 帯域幅振動
Given the limited RF spectrum, satisfying the high data rate needs of 2.5G/3G wireless systems requires dynamic resource sharing among concurrent data users. Various scheduling mechanisms can be deployed in order to maximize resource utilization. If multiple users wish to transfer large amounts of data at the same time, the scheduler may have to repeatedly allocate and de-allocate resources for each user. We refer to periodic allocation and release of high-speed channels as Bandwidth Oscillation. Bandwidth Oscillation effects such as spurious retransmissions were identified elsewhere (e.g., [30]) as factors that degrade throughput. There are research studies [52], [54], which show that in some cases Bandwidth Oscillation can be the single most important factor in reducing throughput. For fixed TCP parameters the achievable throughput depends on the pattern of
限られたRFスペクトルを考えて、高いデータ信号速度が必要とする2.5G/3Gワイヤレスシステムを満足させるのは同時発生のデータユーザの中でダイナミックなリソース・シェアリングを必要とします。 リソース利用を最大にするために様々なスケジューリングメカニズムを配布することができます。 複数のユーザが同時に多量のデータを移したいなら、スケジューラは、各ユーザのために繰り返してリソースを割り当てて、反-割り当てなければならないかもしれません。 私たちは高速チャンネルの周期的な配分と解放をBandwidth Oscillationと呼びます。 偽物の「再-トランスミッション」などの帯域幅Oscillation効果はほかの場所で特定されました。(例えば、スループットを下げる要素としての[30])。 いくらかのケースBandwidth Oscillationのそれがスループットを減らす最も重要な要素であるかもしれないことを示す研究研究[52]、[54]があります。 達成可能なスループットがパターンによる固定TCPパラメタのために
Inamura, et al. Best Current Practice [Page 7] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[7ページ]RFC3481TCP
resource allocation. When the frequency of resource allocation and de-allocation is sufficiently high, there is no throughput degradation. However, increasing the frequency of resource allocation/de-allocation may come at the expense of increased signaling, and, therefore, may not be desirable. Standards for 3G wireless technologies provide mechanisms that can be used to combat the adverse effects of Bandwidth Oscillation. It is the consensus of the PILC Working Group that the best approach for avoiding adverse effects of Bandwidth Oscillation is proper wireless sub-network design [23].
資源配分。 資源配分と反-配分の頻度が十分高いときに、スループット退行が全くありません。 しかしながら、反-資源配分/配分の頻度を増強するのは、増強されたシグナリングを犠牲にして来るかもしれなくて、したがって、望ましくないかもしれません。 3G無線技術の規格はBandwidth Oscillationの悪影響と戦うのに使用できるメカニズムを提供します。 それはBandwidth Oscillationの悪影響を避けるための最も良いアプローチが適切なワイヤレスのサブネットワークデザイン[23]であるというPILC作業部会のコンセンサスです。
3. Example 2.5G and 3G Deployments
3. 例の2.5Gと3G展開
This section provides further details on a few example 2.5G/3G technologies. The objective is not completeness, but merely to discuss some representative technologies and the issues that may arise with TCP performance. Other documents discuss the underlying technologies in more detail. For example, ARQ and FEC are discussed in [23], while further justification for link layer ARQ is discussed in [22], [44].
このセクションはいくつかの例の2.5G/3G技術に関する詳細を提供します。 目的は完全性ではありませんが、単にいくつかの代表している技術と問題について議論するために、それはTCP性能で起こるかもしれません。 他のドキュメントはさらに詳細に基本的な技術について議論します。 例えば、[23]でARQとFECについて議論します、[22]でリンクレイヤARQのためのさらなる正当化について議論しますが、[44]。
3.1 2.5G Technologies: GPRS, HSCSD and CDMA2000 1XRTT
3.1 2.5G技術: GPRS、HSCSD、およびCDMA2000 1XRTT
High Speed Circuit-Switched Data (HSCSD) and General Packet Radio Service (GPRS) are extensions of GSM providing high data rates for a user. Both extensions were developed first by ETSI and later by 3GPP. In GSM, a user is assigned one timeslot downlink and one uplink. HSCSD allocates multiple timeslots to a user creating a fast circuit-switched link. GPRS is based on packet-switched technology that allows efficient sharing of radio resources among users and always-on capability. Several terminals can share timeslots. A GPRS network uses an updated base station subsystem of GSM as the access network; the GPRS core network includes Serving GPRS Support Nodes (SGSN) and Gateway GPRS Support Nodes (GGSN). The RLC protocol operating between a base station controller and a terminal provides ARQ capability over the radio link. The Logical Link Control (LLC) protocol between the SGSN and the terminal also has an ARQ capability utilized during handovers.
高いSpeed Circuitによって切り換えられたData(HSCSD)と汎用パケット無線システム(GPRS)は高いデータ信号速度をユーザに提供するGSMの拡大です。 両方の拡大は最初に、ETSI以降によって3GPPによって発生されました。 GSMでは、1つのtimeslotダウンリンクと1つのアップリンクがユーザに割り当てられます。 HSCSDは速い回路で切り換えられたリンクを作成するユーザに複数のtimeslotsを割り当てます。 GPRSはユーザの中でラジオリソースの効率的な共有を許すパケットで切り換えられた技術といつもオンな能力に基づいています。 いくつかの端末がtimeslotsを共有できます。 GPRSネットワークはアクセスネットワークとしてGSMのアップデートされた基地局サブシステムを使用します。 GPRSコアネットワークはServing GPRS Support Nodes(SGSN)とゲートウェイGPRS Support Nodes(GGSN)を含んでいます。 基地局コントローラと端末の間で作動するRLCプロトコルはラジオリンクの上で能力をARQに供給します。 また、SGSNと端末の間のLogical Link Control(LLC)プロトコルで、身柄の引き渡しの間、ARQ能力を利用します。
3.2 A 3G Technology: W-CDMA
3.2 3G技術: W-CDMA
The International Telecommunication Union (ITU) has selected Wideband Code Division Multiple Access (W-CDMA) as one of the global telecom systems for the IMT-2000 3G mobile communications standard. W-CDMA specifications are created in the 3rd Generation Partnership Project (3GPP).
国際電気通信連合(ITU)はIMT-2000 3G移動通信規格のグローバルなテレコムシステムの1つとしてW-CDMA方式(W-CDMA)を選定しました。 W-CDMA仕様は第3Generation Partnership Project(3GPP)で作成されます。
Inamura, et al. Best Current Practice [Page 8] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[8ページ]RFC3481TCP
The link layer characteristics of the 3G network which have the largest effect on TCP performance over the link are error controlling schemes such as layer two ARQ (L2 ARQ) and FEC (forward error correction).
リンクの上のTCP性能に最も大きい影響を与える3Gネットワークのリンクレイヤの特性は層の2ARQ(L2 ARQ)やFEC(前進型誤信号訂正)などの体系を制御する誤りです。
W-CDMA uses RLC (Radio Link Control) [20], a Selective Repeat and sliding window ARQ. RLC uses protocol data units (PDUs) with a 16 bit RLC header. The size of the PDUs may vary. Typically, 336 bit PDUs are implemented [34]. This is the unit for link layer retransmission. The IP packet is fragmented into PDUs for transmission by RLC. (For more fragmentation discussion, see Section 4.4.)
W-CDMAはRLC(ラジオLink Control)[20]、Selective Repeat、および滑っているウィンドウARQを使用します。 RLCは16ビットのRLCヘッダーがあるプロトコルデータ単位(PDUs)を使用します。 PDUsのサイズは異なるかもしれません。 通常、336ビットのPDUsは[34]であると実装されます。 これはリンクレイヤ「再-トランスミッション」のためのユニットです。 IPパケットはトランスミッションのためにRLCによってPDUsに断片化されます。 (より多くの断片化議論に関して、セクション4.4を見てください。)
In W-CDMA, one to twelve PDUs (RLC frames) constitute one FEC frame, the actual size of which depends on link conditions and bandwidth allocation. The FEC frame is the unit of interleaving. This accumulation of PDUs for FEC adds part of the latency mentioned in Section 2.1.
W-CDMAでは、1〜12PDUs(RLCフレーム)が1個のFECフレームを設立します。その実サイズはリンク状態と帯域幅配分に依存します。 FECフレームはインターリービングのユニットです。 FECのためのPDUsのこの蓄積はセクション2.1で言及された潜在の一部を加えます。
For reliable transfer, RLC has an acknowledged mode for PDU retransmission. RLC uses checkpoint ARQ [20] with "status report" type acknowledgments; the poll bit in the header explicitly solicits the peer for a status report containing the sequence number that the peer acknowledges. The use of the poll bit is controlled by timers and by the size of available buffer space in RLC. Also, when the peer detects a gap between sequence numbers in received frames, it can issue a status report to invoke retransmission. RLC preserves the order of packet delivery.
信頼できる転送のために、RLCには、PDU retransmissionのための承認されたモードがあります。 RLCは「現状報告」タイプ承認と共にチェックポイントARQ[20]を使用します。 ヘッダーで明らかに噛み付かれた投票は同輩が承認する一連番号を含む現状報告のために同輩に請求します。 ポール・ビットの使用はタイマとRLCの利用可能なバッファ領域のサイズによって制御されます。 また、同輩が容認されたフレームの一連番号のギャップを検出するとき、それは、「再-トランスミッション」を呼び出すために現状報告を発行できます。 RLCはパケット配信の注文を保存します。
The maximum number of retransmissions is a configurable RLC parameter that is specified by RRC [39] (Radio Resource Controller) through RLC connection initialization. The RRC can set the maximum number of retransmissions (up to a maximum of 40). Therefore, RLC can be described as an ARQ that can be configured for either HIGH- PERSISTENCE or LOW-PERSISTENCE, not PERFECT-PERSISTENCE, according to the terminology in [22].
「再-トランスミッション」の最大数はRLC接続初期化でRRC[39](ラジオResource Controller)によって指定される構成可能なRLCパラメタです。 RRCは「再-トランスミッション」(最大最大40)の最大数を設定できます。 したがって、HIGH- PERSISTENCEかPERFECT-PERSISTENCEではなく、LOW-PERSISTENCEのどちらかのために構成できるARQとしてRLCを記述できます、[22]の用語によると。
Since the RRC manages RLC connection state, Bandwidth Oscillation (Section 2.7) can be eliminated by the RRC's keeping RF resource on an RLC connection with data in its queue. This avoids resource de- allocation in the middle of transferring data.
RRCがRLC接続状態を経営しているので、RRCが、RFが待ち行列におけるデータとのRLC関係に関するリソースであることを保つことによって、Bandwidth Oscillation(セクション2.7)を排除できます。 これはデータを移す中央でリソース反-配分を避けます。
In summary, the link layer ARQ and FEC can provide a packet service with a negligibly small probability of undetected error (failure of the link CRC), and a low level of loss (non-delivery) for the upper layer traffic, i.e., IP. Retransmission of PDUs by ARQ introduces latency and delay jitter to the IP flow. This is why the transport layer sees the underlying W-CDMA network as a network with a
概要、ARQリンクレイヤ、およびFECがパケットサービスを提供できるコネ、無視しうる程度にわずかである、わずかな確率、非検出された誤り(リンクCRCの失敗)、および上側の層のトラフィック(すなわち、IP)のための低レベルの損失(非配送) ARQによるPDUsのRetransmissionは潜在と遅れジターをIP流動に紹介します。 これはトランスポート層が基本的なW-CDMAネットワークをaがあるネットワークであるとみなす理由です。
Inamura, et al. Best Current Practice [Page 9] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[9ページ]RFC3481TCP
relatively large BDP (Bandwidth-Delay Product) of up to 50 KB for the 384 kbps radio bearer.
384キロビット毎秒ラジオ運搬人のための最大50KBの比較的大きいBDP(帯域幅遅れProduct)。
3.3 A 3G Technology: CDMA2000 1X-EV
3.3 3G技術: CDMA2000 1X-ev
One of the Terrestrial Radio Interface standards for 3G wireless systems, proposed under the International Mobile Telecommunications- 2000 umbrella, is cdma2000 [55]. It employs Multi-Carrier Code Division Multiple Access (CDMA) technology with a single-carrier RF bandwidth of 1.25 MHz. cdma2000 evolved from IS-95 [56], a 2G standard based on CDMA technology. The first phase of cdma2000 utilizes a single carrier and is designed to double the voice capacity of existing CDMA (IS-95) networks and to support always-on data transmission speeds of up to 316.8 kbps. As mentioned above, these enhanced capabilities are delivered by cdma2000 1XRTT. 3G speeds of 2 Mbps are offered by cdma2000 1X-EV. At the physical layer, the standard allows transmission in 5,10,20,40 or 80 ms time frames. Various orthogonal (Walsh) codes are used for channel identification and to achieve higher data rates.
国際モバイルTelecommunications2000かさの下で提案された3GワイヤレスシステムのTerrestrial Radio Interface規格の1つはcdma2000[55]です。 1.25MHz cdma2000の独身のキャリヤーRF帯域幅に伴う技術が発展したMulti-キャリヤー符号分割多重アクセス方式(CDMA)を使う、-95である、[56]、2G規格はCDMA技術を基礎づけました。 cdma2000の第1段階が独身のキャリヤーを利用して、既存のCDMAの声の容量を倍にするように設計されている、(-95である、)、最大316.8キロビット毎秒のネットワークとサポートにいつもオンなデータ伝送速度。 以上のように、これらの高められた能力はcdma2000 1XRTTによって提供されます。 2Mbpsの3G速度をcdma2000 1X-eV提供します。 物理的な層では、規格は5、10、20、40または80のms時間枠にトランスミッションを許容します。 様々な直交した(ウォルシュ)コードは、チャネル識別、より高いデータ信号速度を達成するのに使用されます。
Radio Link Protocol Type 3 (RLP) [57] is used with a cdma2000 Traffic Channel to support CDMA data services. RLP provides an octet stream transport service and is unaware of higher layer framing. There are several RLP frame formats. RLP frame formats with higher payload were designed for higher data rates. Depending on the channel speed, one or more RLP frames can be transmitted in a single physical layer frame.
ラジオLinkプロトコルType3(RLP)[57]は、CDMAデータがサービスであるとサポートするのにcdma2000 Traffic Channelと共に使用されます。 RLPは八重奏ストリーム輸送サービスを提供して、より高い層の縁どりに気づきません。 いくつかのRLPフレーム形式があります。 より高いペイロードがあるRLPフレーム形式は、より高いデータ信号速度のために設計されました。 チャンネル速度によって、単一の物理的な層のフレームで1個以上のRLPフレームを送ることができます。
RLP can substantially decrease the error rate exhibited by CDMA traffic channels [53]. When transferring data, RLP is a pure NAK- based finite selective repeat protocol. The receiver does not acknowledge successfully received data frames. If one or more RLP data frames are missing, the receiving RLP makes several attempts (called NAK rounds) to recover them by sending one or more NAK control frames to the transmitter. Each NAK frame must be sent in a separate physical layer frame. When RLP supplies the last NAK control frame of a particular NAK round, a retransmission timer is set. If the missing frame is not received when the timer expires, RLP may try another NAK round. RLP may not recover all missing frames. If after all RLP rounds, a frame is still missing, RLP supplies data with a missing frame to the higher layer protocols.
RLPはCDMAトラフィックチャンネル[53]によって示された誤り率をかなり減少させることができます。 データを移すとき、RLPは純粋なNAKベースの有限選択している反復プロトコルです。 受信機は首尾よく受信データフレームを承認しません。 1個以上のRLPデータフレームがなくなるなら、受信RLPは1NAKを送ることによってそれらを回復するいくつかの試み(NAKにひょっこり立ち寄る)を送信機への制御フレームにします。 別々の物理的な層のフレームでそれぞれのNAKフレームを送らなければなりません。 RLPがぐるりと特定のNAKの最後のNAK制御フレームを供給するとき、再送信タイマーは設定されます。 タイマが期限が切れるとき、なくなったフレームが受け取られていないなら、RLPはぐるりと別のNAKを試みるかもしれません。 RLPはすべてのなくなったフレームを回収するかもしれないというわけではありません。 フレームがすべてのRLPラウンドの後にまだなくなっているなら、RLPはなくなったフレームがあるデータをより高い層のプロトコルに供給します。
4. TCP over 2.5G and 3G
4. 2.5Gと3Gの上のTCP
What follows is a set of recommendations for configuration parameters for protocol stacks which will be used to support TCP connections over 2.5G and 3G wireless networks. Some of these recommendations imply special configuration:
続くことは2.5Gと3Gの上のTCP接続にワイヤレス・ネットワークをサポートするのに使用されるプロトコル・スタックのための設定パラメータのための1セットの推薦です。 これらの推薦のいくつかが特別な構成を含意します:
Inamura, et al. Best Current Practice [Page 10] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[10ページ]RFC3481TCP
o at the data receiver (frequently a stack at or near the wireless
device),
o データ受信装置(頻繁のワイヤレス機器における、または、ワイヤレス機器の近くのスタック)で
o at the data sender (frequently a host in the Internet or possibly
a gateway or proxy at the edge of a wireless network), or
o またはデータ送付者(ことによるとワイヤレス・ネットワークの縁の頻繁のインターネットのホスト、ゲートウェイまたはプロキシ)で。
o at both.
o 両方で。
These configuration options are commonly available IETF standards- track mechanisms considered safe on the general Internet. System administrators are cautioned, however, that increasing the MTU size (Section 4.4) and disabling RFC 1144 header compression (Section 4.9) could affect host efficiency, and that changing such parameters should be done with care.
これらの設定オプションは道のメカニズムが考えた一般的に利用可能なIETF規格です。一般的なインターネットでは、安全です。 しかしながら、システム管理者はMTUサイズ(セクション4.4)を増強して、RFC1144がヘッダー圧縮(セクション4.9)であることを無効にするのがホスト効率に影響するかもしれなくて、そのようなパラメタが慎重に変えられるべきであると警告されます。
4.1 Appropriate Window Size (Sender & Receiver)
4.1 適切なウィンドウサイズ(送付者と受信機)
TCP over 2.5G/3G should support appropriate window sizes based on the Bandwidth Delay Product (BDP) of the end-to-end path (see Section 2.2). The TCP specification [14] limits the receiver window size to 64 KB. If the end-to-end BDP is expected to be larger than 64 KB, the window scale option [2] can be used to overcome that limitation. Many operating systems by default use small TCP receive and send buffers around 16KB. Therefore, even for a BDP below 64 KB, the default buffer size setting should be increased at the sender and at the receiver to allow a large enough window.
2.5G/3Gの上のTCPは終わりから端への経路のBandwidth Delay Product(BDP)に基づく適切なウィンドウサイズをサポートするはずです(セクション2.2を見てください)。 TCP仕様[14]は受信機ウィンドウサイズを64KBに制限します。 終わりから終わりへのBDPが64KBより大きいと予想されるなら、その限界を克服するのに窓のスケールオプション[2]を使用できます。 多くのオペレーティングシステムがデフォルトで小さいTCPを使用します。受信してください、そして、およそ16KBをバッファに送ってください。 64KB未満のBDPに関してはさえ、デフォルトバッファサイズ設定は、十分大きい窓を許容するために送付者において受信機で増強されるべきです。
4.2 Increased Initial Window (Sender)
4.2 増強された初期の窓(送付者)
TCP controls its transmit rate using the congestion window mechanism. The traditional initial window value of one segment, coupled with the delayed ACK mechanism [17] implies unnecessary idle times in the initial phase of the connection, including the delayed ACK timeout (typically 200 ms, but potentially as much as 500 ms) [4]. Senders can avoid this by using a larger initial window of up to four segments (not to exceed roughly 4 KB) [4]. Experiments with increased initial windows and related measurements have shown (1) that it is safe to deploy this mechanism (i.e., it does not lead to congestion collapse), and (2) that it is especially effective for the transmission of a few TCP segments' worth of data (which is the behavior commonly seen in such applications as Internet-enabled mobile wireless devices). For large data transfers, on the other hand, the effect of this mechanism is negligible.
TCPが制御する、それ、混雑ウィンドウメカニズムを使用することでレートを伝えてください。 1つのセグメントの伝統的な初期の窓の値、遅れたACKに結びつけられたメカニズム[17]は接続の初期位相における不要な活動していない時勢を含意します、遅れたACKタイムアウト(しかし、通常200ms、潜在的に最大500ms)[4]を含んでいて。 Sendersは、最大4つのセグメント(およそ4KBを超えない)[4]の、より大きい初期の窓を使用することによって、これを避けることができます。 増強された初期の窓と関連する測定値がある実験は(1) このメカニズムを配布するのが安全であり(すなわち、それは混雑崩壊に通じません)、いくつかのTCPセグメントのデータ(インターネットで可能にされたモバイルワイヤレス機器のようなアプリケーションで一般的に見られた振舞いである)の価値の送信に、(2) それが特に効果的であることを示しました。 他方では、大きいデータ転送において、このメカニズムの効果は取るにたらないです。
TCP over 2.5G/3G SHOULD set the initial CWND (congestion window) according to Equation 1 in [4]:
Equation1によると、2.5G/3G SHOULDの上のTCPは[4]に初期のCWND(混雑ウィンドウ)を設定します:
min (4*MSS, max (2*MSS, 4380 bytes))
分(4*MSS、最大(2*MSS、4380バイト))
Inamura, et al. Best Current Practice [Page 11] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[11ページ]RFC3481TCP
This increases the permitted initial window from one to between two and four segments (not to exceed approximately 4 KB).
これは受入れられた初期の窓を1〜2〜4つのセグメント(およそ4KBを超えない)まで増強します。
4.3 Limited Transmit (Sender)
制限された4.3は伝わります。(送付者)
RFC 3042 [10], Limited Transmit, extends Fast Retransmit/Fast Recovery for TCP connections with small congestion windows that are not likely to generate the three duplicate acknowledgements required to trigger Fast Retransmit [1]. If a sender has previously unsent data queued for transmission, the limited transmit mechanism calls for sending a new data segment in response to each of the first two duplicate acknowledgments that arrive at the sender. This mechanism is effective when the congestion window size is small or if a large number of segments in a window are lost. This may avoid some retransmissions due to TCP timeouts. In particular, some studies [10] have shown that over half of a busy server's retransmissions were due to RTO expiration (as opposed to Fast Retransmit), and that roughly 25% of those could have been avoided using Limited Transmit. Similar to the discussion in Section 4.2, this mechanism is useful for small amounts of data to be transmitted. TCP over 2.5G/3G implementations SHOULD implement Limited Transmit.
RFC3042[10](株式会社Transmit)は3写しがFast Retransmit[1]の引き金となるのに必要である承認であると生成しそうにない小さい混雑ウィンドウとのTCP接続のためにFast Retransmit/速いRecoveryを広げています。 送付者が以前にデータがトランスミッション、制限のために列に並ばせたunsentを持っているなら、送付者に到着するそれぞれの最初の2つの写し承認に対応して新しいデータ・セグメントを送るためのメカニズム呼び出しを伝えてください。 小さいか窓の多くのセグメントが無くなるなら混雑ウィンドウサイズが有効であるときに、このメカニズムは有効です。 これはTCPタイムアウトのためいくらかの「再-トランスミッション」を避けるかもしれません。 特に、いくつかの研究[10]が、忙しいサーバの「再-トランスミッション」の半分以上がRTO満了(Fast Retransmitと対照的に)のためであり、それらのおよそ25%が株式会社Transmitを使用することで避けられたかもしれないのを示しました。 セクション4.2で議論と同様であることで、このメカニズムは、少量のデータが送られるために役に立ちます。 2.5G/3G実装SHOULDの上のTCPは株式会社Transmitを実装します。
4.4 IP MTU Larger than Default
4.4 デフォルトより大きいIP MTU
The maximum size of an IP datagram supported by a link layer is the MTU (Maximum Transfer Unit). The link layer may, in turn, fragment IP datagrams into PDUs. For example, on links with high error rates, a smaller link PDU size increases the chance of successful transmission. With layer two ARQ and transparent link layer fragmentation, the network layer can enjoy a larger MTU even in a relatively high BER (Bit Error Rate) condition. Without these features in the link, a smaller MTU is suggested.
リンクレイヤによって支えられたIPデータグラムの最大サイズはMTU(最大のTransfer Unit)です。 リンクレイヤは順番にIPデータグラムをPDUsに断片化するかもしれません。 例えば、高い誤り率とのリンクでは、より小さいリンクPDUサイズはうまくいっているトランスミッションの可能性を増強します。 層twoのARQとわかりやすいリンクレイヤ断片化で、ネットワーク層は比較的高いBER(ビットError Rate)状態でさえより大きいMTUを楽しむことができます。 リンクのこれらの特徴がなければ、より小さいMTUは示されます。
TCP over 2.5G/3G should allow freedom for designers to choose MTU values ranging from small values (such as 576 bytes) to a large value that is supported by the type of link in use (such as 1500 bytes for IP packets on Ethernet). Given that the window is counted in units of segments, a larger MTU allows TCP to increase the congestion window faster [5]. Hence, designers are generally encouraged to choose larger values. These may exceed the default IP MTU values of 576 bytes for IPv4 RFC 1191 [6] and 1280 bytes for IPv6 [18]. While this recommendation is applicable to 3G networks, operation over 2.5G networks should exercise caution as per the recommendations in RFC 3150 [5].
2.5G/3Gの上のTCPはデザイナーが小さい値(576バイトなどの)から大きい使用中のリンク(イーサネットのIPパケットのための1500バイトなどの)のタイプによってサポートされる値まで及ぶMTU値を選ぶ自由を許容するはずです。 窓がユニットで数えられるなら、セグメント、より大きいMTUが混雑をTCPを増強させるaでは、より速い[5]に窓を付けてください。 したがって、一般に、デザイナーが、より大きい値を選ぶよう奨励されます。 これらはIPv4 RFC1191[6]のための576バイトとIPv6[18]のための1280バイトのデフォルトIP MTU値を超えるかもしれません。 この推薦が3Gネットワークに適切である間、2.5Gネットワークの上の操作はRFC3150[5]の推薦に従って警戒するべきです。
Inamura, et al. Best Current Practice [Page 12] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[12ページ]RFC3481TCP
4.5 Path MTU Discovery (Sender & Intermediate Routers)
4.5 経路MTU発見(送付者と中間的ルータ)
Path MTU discovery allows a sender to determine the maximum end-to- end transmission unit (without IP fragmentation) for a given routing path. RFC 1191 [6] and RFC 1981 [8] describe the MTU discovery procedure for IPv4 and IPv6, respectively. This allows TCP senders to employ larger segment sizes (without causing IP layer fragmentation) instead of assuming the small default MTU. TCP over 2.5G/3G implementations should implement Path MTU Discovery. Path MTU Discovery requires intermediate routers to support the generation of the necessary ICMP messages. RFC 1435 [7] provides recommendations that may be relevant for some router implementations.
経路MTU探索で、送付者は最大の終わりからエンドへのトランスミッション単位(IP断片化のない)を与えられたルーティング経路に測定できます。 RFC1191[6]とRFC1981[8]はIPv4とIPv6のためにそれぞれMTU発見手順について説明します。 これで、小さいデフォルトがMTUであると仮定することの代わりにTCP送付者は、より大きいセグメントサイズを使うことができます(IP層の断片化を引き起こさないで)。 2.5G/3G実装の上のTCPは、Path MTUがディスカバリーであると実装するはずです。 経路MTUディスカバリーは、必要なICMPメッセージの世代をサポートするために中間的ルータを必要とします。 RFC1435[7]はいくつかのルータ実装において、関連するかもしれない推薦を提供します。
4.6 Selective Acknowledgments (Sender & Receiver)
4.6 選択している承認(送付者と受信機)
The selective acknowledgment option (SACK), RFC 2018 [3], is effective when multiple TCP segments are lost in a single TCP window [24]. In particular, if the end-to-end path has a large BDP and a high packet loss rate, the probability of multiple segment losses in a single window of data increases. In such cases, SACK provides robustness beyond TCP-Tahoe and TCP-Reno [21]. TCP over 2.5G/3G SHOULD support SACK.
複数のTCPセグメントが単一のTCPの窓[24]で失われているとき、選択している承認オプション(SACK)(RFC2018[3])は有効です。 終わりから端への経路に大きいBDPと高いパケット損失率があるなら、特に、データの単一の窓の複数のセグメントの損失の確率は増加します。 そのような場合、SACKはTCP-タホとTCP-リノ[21]を超えて丈夫さを提供します。 2.5G/3G SHOULDの上のTCPはSACKをサポートします。
In the absence of SACK feature, the TCP should use NewReno RFC 2582 [15].
SACKの特徴がないとき、TCPはNewReno RFC2582[15]を使用するはずです。
4.7 Explicit Congestion Notification (Sender, Receiver & Intermediate
Routers)
4.7 明白な混雑通知(送付者、受信機、および中間的ルータ)
Explicit Congestion Notification, RFC 3168 [9], allows a TCP receiver to inform the sender of congestion in the network by setting the ECN-Echo flag upon receiving an IP packet marked with the CE bit(s). The TCP sender will then reduce its congestion window. Thus, the use of ECN is believed to provide performance benefits [32], [43]. RFC 3168 [9] also places requirements on intermediate routers (e.g., active queue management and setting of the CE bit(s) in the IP header to indicate congestion). Therefore, the potential improvement in performance can only be achieved when ECN capable routers are deployed along the path. TCP over 2.5G/3G SHOULD support ECN.
明白なCongestion Notification(RFC3168[9])はCEビットでマークされたIPパケットを受けることへ電子証券取引ネットワーク-エコー旗を上に置くことによって、混雑についてTCP受信機を送付者にネットワークで知らせさせます。 そして、TCP送付者は混雑ウィンドウを減少させるでしょう。 したがって、電子証券取引ネットワークの使用が性能利益[32]、[43]を提供すると信じられています。 また、RFC3168[9]は中間的ルータ(混雑を示すIPヘッダーのCEビットの例えば、活発な待ち行列管理と設定)に要件を置きます。 したがって、電子証券取引ネットワークのできるルータが経路に沿って配布されるときだけ、性能における潜在的改良を達成できます。 2.5G/3G SHOULDの上のTCPは電子証券取引ネットワークをサポートします。
4.8 TCP Timestamps Option (Sender & Receiver)
4.8 TCPタイムスタンプオプション(送付者と受信機)
Traditionally, TCPs collect one RTT sample per window of data [14], [17]. This can lead to an underestimation of the RTT, and spurious timeouts on paths in which the packet transmission delay dominates the RTT. This holds despite a conservative retransmit timer such as the one specified in RFC 2988 [11]. TCP connections with large windows may benefit from more frequent RTT samples provided with
伝統的に、TCPsはデータ[14]、[17]の窓あたり1個のRTTのサンプルを集めます。 これはパケット伝送遅延がRTTを支配するRTTの過小評価、および経路における偽りのタイムアウトに通じることができます。 RFC2988[11]で指定されたものなどの保守的な再送信タイマにもかかわらず、これは成立します。 大きい窓とのTCP接続は提供されたより頻繁なRTTのサンプルの利益を得るかもしれません。
Inamura, et al. Best Current Practice [Page 13] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[13ページ]RFC3481TCP
timestamps by adapting quicker to changing network conditions [2]. However, there is some empirical evidence that for TCPs with an RFC 2988 timer [11], timestamps provide little or no benefits on backbone Internet paths [59]. Using the TCP Timestamps option has the advantage that retransmitted segments can be used for RTT measurement, which is otherwise forbidden by Karn's algorithm [17], [11]. Furthermore, the TCP Timestamps option is the basis for detecting spurious retransmits using the Eifel algorithm [30].
より迅速に変化に順応するのによるタイムスタンプは状態[2]をネットワークでつなぎます。 しかしながら、RFC2988タイマ[11]があるTCPsのために、タイムスタンプがバックボーンインターネット経路[59]でまず利益を提供しないという何らかの実証的証拠があります。 再送されたセグメントが利点であるかもしれませんが、別の方法でKarnのアルゴリズム[17]、[11]によって禁じられるRTT測定に使用されて、オプションが持っているTCP Timestampsを使用します。 その上、TCP Timestampsオプションは検出における、偽りの基礎にアイフェル高原アルゴリズム[30]を使用することで再送されるということです。
A 2.5/3G link (layer) is dedicated to a single host. It therefore only experiences a low degree of statistical multiplexing between different flows. Also, the packet transmission and queuing delays of a 2.5/3G link often dominate the path's RTT. This already results in large RTT variations as packets fill the queue while a TCP sender probes for more bandwidth, or as packets drain from the queue while a TCP sender reduces its load in response to a packet loss. In addition, the delay spikes across a 2.5/3G link (see Section 2.4) may often exceed the end-to-end RTT. The thus resulting large variations in the path's RTT may often cause spurious timeouts.
2.5/3Gリンク(層)は独身のホストに捧げられます。 したがって、それは異なった流れの間の低度合いの統計的多重化を経験するだけです。 また、パケット伝送と2.5/3Gリンクの遅れを列に並ばせると、経路のRTTはしばしば支配されます。 TCP送付者はパケット損失に対応して負荷を減少させますが、より多くの帯域幅、またはパケットが待ち行列から排水するとき、TCP送付者は調べますが、パケットが待ち行列をいっぱいにするとき、これは既に大きいRTT変化をもたらします。 さらに、2.5/3Gリンク(セクション2.4を見る)の向こう側の遅れスパイクはしばしば終わりから終わりへのRTTを超えるかもしれません。 経路のRTTのその結果、結果として起こる大きい変化はしばしば偽りのタイムアウトを引き起こすかもしれません。
When running TCP in such an environment, it is therefore advantageous to sample the path's RTT more often than only once per RTT. This allows the TCP sender to track changes in the RTT more closely. In particular, a TCP sender can react more quickly to sudden increases of the RTT by sooner updating the RTO to a more conservative value. The TCP Timestamps option [2] provides this capability, allowing the TCP sender to sample the RTT from every segment that is acknowledged. Using timestamps in the mentioned scenario leads to a more conservative TCP retransmission timer and reduces the risk of triggering spurious timeouts [45], [52], [54], [60].
したがって、そのような環境でTCPを実行するとき、よりしばしば経路のRTTを抽出するのは1RTTあたりの一度だけより有利です。 これで、TCP送付者は、より密接にRTTにおける変化を追うことができます。 特に、TCP送付者は、より早さまでに、より保守的な値にRTOをアップデートしながら、より急速にRTTの急増に反応できます。 TCP Timestampsオプション[2]はこの能力を提供します、TCP送付者が承認されるあらゆるセグメントからRTTを抽出するのを許容して。 言及されたシナリオでタイムスタンプを使用するのは、より保守的なTCP再送信タイマーに通じて、偽りのタイムアウト[45]の引き金となる危険を変えます、[52]、[54]、[60]。
There are two problematic issues with using timestamps:
タイムスタンプを使用する問題の多い2冊があります:
o 12 bytes of overhead are introduced by carrying the TCP Timestamps
option and padding in the TCP header. For a small MTU size, it
can present a considerable overhead. For example, for an MTU of
296 bytes the added overhead is 4%. For an MTU of 1500 bytes, the
added overhead is only 0.8%.
o TCP Timestampsオプションを運んで、TCPヘッダーでそっと歩くことによって、12バイトのオーバーヘッドを導入します。 小さいMTUサイズのために、それはかなりのオーバーヘッドを提示できます。 例えば、296バイトのMTUに関して、加えられたオーバーヘッドは4%です。 1500バイトのMTUに関しては、加えられたオーバーヘッドは0.8%にすぎません。
o Current TCP header compression schemes are limited in their
handling of the TCP options field. For RFC 2507 [13], any change
in the options field (caused by timestamps or SACK, for example)
renders the entire field uncompressible (leaving the TCP/IP header
itself compressible, however). Even worse, for RFC 1144 [40] such
a change in the options field effectively disables TCP/IP header
compression altogether. This is the case when a connection uses
the TCP Timestamps option. That option field is used both in the
data and the ACK path, and its value typically changes from one
o 現在のTCPヘッダー圧縮技術は彼らのTCPオプション分野の取り扱いが制限されます。 RFC2507[13]に関しては、オプション分野(例えば、タイムスタンプかSACKが引き起こされる)のどんな変化も全体の分野uncompressible(しかしながら、それ自体で圧縮性のヘッダーにTCP/IPを残す)をレンダリングします。 さらにひどく、RFC1144[40]に関して、事実上、オプション分野のそのような変化は全体でTCP/IPヘッダー圧縮を無効にします。 接続がTCP Timestampsオプションを使用するとき、これはそうです。 そのオプション・フィールドはデータとACK経路で使用されます、そして、値は1から通常変化します。
Inamura, et al. Best Current Practice [Page 14] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[14ページ]RFC3481TCP
packet to the next. The IETF is currently specifying a robust
TCP/IP header compression scheme with better support for TCP
options [29].
次へのパケット。 IETFは現在、TCPオプション[29]の、より良いサポートで強健なTCP/IPヘッダー圧縮技術を指定しています。
The original definition of the timestamps option [2] specifies that duplicate segments below cumulative ACK do not update the cached timestamp value at the receiver. This may lead to overestimating of RTT for retransmitted segments. A possible solution [47] allows the receiver to use a more recent timestamp from a duplicate segment. However, this suggestion allows for spoofing attacks against the TCP receiver. Therefore, careful consideration is needed in implementing this solution.
タイムスタンプオプション[2]のオリジナルの定義は、累積しているACKの下の写しセグメントが受信機でキャッシュされたタイムスタンプ値をアップデートしないと指定します。これは再送されたセグメントのためにRTTの過大評価に導くかもしれません。 可能なソリューション[47]で、受信機は写しセグメントからの、より最近のタイムスタンプを使用できます。 しかしながら、この提案は、TCP受信機に対して攻撃を偽造すると考慮します。したがって、熟慮がこのソリューションを実現するのにおいて必要です。
Recommendation: TCP SHOULD use the TCP Timestamps option. It allows for better RTT estimation and reduces the risk of spurious timeouts.
推薦: TCP SHOULDはTCP Timestampsオプションを使用します。 それは、より良いRTT見積りを考慮して、偽りのタイムアウトの危険を減少させます。
4.9 Disabling RFC 1144 TCP/IP Header Compression (Wireless Host)
4.9 RFC1144がTCP/IPヘッダー圧縮であると無効にすること。(ワイヤレスのホスト)
It is well known (and has been shown with experimental data) that RFC 1144 [40] TCP header compression does not perform well in the presence of packet losses [43], [52]. If a wireless link error is not recovered, it will cause TCP segment loss between the compressor and decompressor, and then RFC 1144 header compression does not allow TCP to take advantage of Fast Retransmit Fast Recovery mechanism. The RFC 1144 header compression algorithm does not transmit the entire TCP/IP headers, but only the changes in the headers of consecutive segments. Therefore, loss of a single TCP segment on the link causes the transmitting and receiving TCP sequence numbers to fall out of synchronization. Hence, when a TCP segment is lost after the compressor, the decompressor will generate false TCP headers. Consequently, the TCP receiver will discard all remaining packets in the current window because of a checksum error. This continues until the compressor receives the first retransmission which is forwarded uncompressed to synchronize the decompressor [40].
RFC1144[40]TCPヘッダー圧縮がパケット損失[43]([52])の面前でよく振る舞わないのがよく知られています(そして、実験データで、示されました)。 ワイヤレスのリンク誤りが回復されないと、それがコンプレッサーと減圧装置のセグメントの損失をTCPにもたらすでしょう、そして、次に、1144年のRFCヘッダー圧縮はTCPがFast Retransmit Fast Recoveryメカニズムを利用するのを許容しません。 1144年のRFCヘッダー圧縮アルゴリズムは全体のTCP/IPヘッダーを伝えるのではなく、連続したセグメントのヘッダーにおける変化だけを伝えます。 したがって、リンクにおけるただ一つのTCPセグメントの損失で、伝えてTCP一連番号を受けるのは同期から落下します。 TCPセグメントがコンプレッサーの後に失われているとき、したがって、減圧装置は偽のTCPヘッダーを生成するでしょう。 その結果、TCP受信機はチェックサム誤りのために現在の窓のすべての残っているパケットを捨てるでしょう。 コンプレッサーが進められる減圧装置[40]を同期させるように解凍された最初の「再-トランスミッション」を受けるまで、これは続きます。
As previously recommended in RFC 3150 [5], RFC 1144 header compression SHOULD NOT be enabled unless the packet loss probability between the compressor and decompressor is very low. Actually, enabling the Timestamps Option effectively accomplishes the same thing (see Section 4.8). Other header compression schemes like RFC 2507 [13] and Robust Header Compression [12] are meant to address deficiencies in RFC 1144 header compression. At the time of this writing, the IETF was working on multiple extensions to Robust Header Compression (negotiating Robust Header Compression over PPP, compressing TCP options, etc) [16].
同じくらい以前に、RFC3150[5]、RFC1144ヘッダー圧縮SHOULD NOTでコンプレッサーと減圧装置の間のパケット紛失率がそれほど低くない場合可能にされるように勧めました。 実際に、有効にTimestamps Optionを有効にすると、同じものは達成されます(セクション4.8を見てください)。 RFC2507[13]とRobust Header Compression[12]のような他のヘッダー圧縮技術は1144年のRFCヘッダー圧縮における欠乏を扱うことになっています。 この書くこと時点で、IETFはRobust Header Compression(TCPオプションを圧縮して、PPPの上でRobust Header Compressionを交渉しますなど)[16]への複数の拡大に取り組んでいました。
Inamura, et al. Best Current Practice [Page 15] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[15ページ]RFC3481TCP
4.10 Summary
4.10 概要
Items Comments
----------------------------------------------------------------
Appropriate Window Size (sender & receiver)
based on end-to-end BDP
項目コメント---------------------------------------------------------------- 終わりから終わりへのBDPに基づく適切なWindow Size(送付者と受信機)
Window Scale Option (sender & receiver) [RFC1323] Window size > 64KB
窓のScale Option(送付者と受信機)[RFC1323]ウィンドウサイズ>64KB
Increased Initial Window (sender)
[RFC3390] CWND = min (4*MSS,
max (2*MSS, 4380 bytes))
増強されたInitial Window(送付者)[RFC3390]CWND=分(4*MSS、最大(2*MSS、4380バイト))
Limited Transmit (sender) [RFC3042]
制限されて、(送付者)を伝えてください。[RFC3042]
IP MTU larger than more applicable to 3G Default
3G Defaultにより適切であるより大きいIP MTU
Path MTU Discovery (sender & intermediate routers) [RFC1191,RFC1981]
経路MTUディスカバリー(送付者と中間的ルータ)[RFC1191、RFC1981]
Selective Acknowledgment option (SACK) [RFC2018] (sender & receiver)
選択しているAcknowledgmentオプション(SACK)[RFC2018](送付者と受信機)
Explicit Congestion
Notification(ECN)
[RFC3168] (sender, receiver &
intermediate routers)
明白な混雑通知(電子証券取引ネットワーク)[RFC3168](送付者、受信機、および中間的ルータ)
Timestamps Option (sender & receiver) [RFC1323, R.T.Braden's ID]
タイムスタンプOption(送付者と受信機)[RFC1323、R.T.ブレーデンのID]
Disabling RFC1144 TCP/IP Header Compression [RFC1144] (wireless host)
RFC1144がTCP/IPヘッダー圧縮[RFC1144]であると無効にします。(ワイヤレスのホスト)
5. Open Issues
5. 未解決の問題
This section outlines additional mechanisms and parameter settings that may increase end-to-end performance when running TCP across 2.5G/3G networks. Note, that apart from the discussion of the RTO's initial value, those mechanisms and parameter settings are not part of any standards track RFC at the time of this writing. Therefore, they cannot be recommended for the Internet in general.
このセクションは2.5G/3Gネットワークの向こう側にTCPを実行するとき終わりから終わりへの性能を増強するかもしれない追加メカニズムとパラメタ設定について概説します。 注意、それらのRTOの初期の価値の議論は別としてそれ、メカニズム、およびパラメタ設定はこの書くこと時点のどんな標準化過程RFCの一部ではありません。 したがって、一般に、インターネットにそれらを推薦できません。
Inamura, et al. Best Current Practice [Page 16] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[16ページ]RFC3481TCP
Other mechanisms for increasing TCP performance include enhanced TCP/ IP header compression schemes [29], active queue management RFC 2309 [28], link layer retransmission schemes [23], and caching packets during transient link outages to retransmit them locally when the link is restored to operation [23].
増加するTCP性能のための他のメカニズムは、リンクが操作[23]に返されるとき、局所的にそれらを再送するために高められたTCP/IPヘッダー圧縮技術[29]と、アクティブな待ち行列管理RFC2309[28]と、リンクレイヤ「再-トランスミッション」体系[23]と、一時的なリンク供給停止の間、パケットをキャッシュするのを含んでいます。
Shortcomings of existing TCP/IP header compression schemes (RFC 1144 [40], RFC 2507 [13]) are that they do not compress headers of handshaking packets (SYNs and FINs), and that they lack proper handling of TCP option fields (e.g., SACK or timestamps) (see Section 4.8). Although RFC 3095 [12] does not yet address this issue, the IETF is developing improved TCP/IP header compression schemes, including better handling of TCP options such as timestamps and selective acknowledgements. Especially, if many short-lived TCP connections run across the link, the compression of the handshaking packets may greatly improve the overall header compression ratio.
既存のTCP/IPヘッダー圧縮の短所は計画します。(RFC1144[40]、RFC2507[13])によるハンドシェイクパケット(SYNsとFINs)のヘッダーを圧縮しないで、彼らがTCPオプション・フィールド(例えば、SACKかタイムスタンプ)の適切な取り扱いを欠いているという(セクション4.8を見てください)ことです。 RFC3095[12]はまだこの問題を扱っていませんが、IETFは改良されたTCP/IPヘッダー圧縮技術を開発しています、タイムスタンプや選択している承認などのTCPオプションの、より良い取り扱いを含んでいて。 特に、多くの短命なTCP接続がリンクに出くわすなら、ハンドシェイクパケットの圧縮は総合的なヘッダー圧縮比を大いに改良するかもしれません。
Implementing active queue management is attractive for a number of
reasons as outlined in RFC 2309 [28]. One important benefit for
2.5G/ 3G networks, is that it minimizes the amount of potentially
stale data that may be queued in the network ("clicking from page to
page" before the download of the previous page is complete).
Avoiding the transmission of stale data across the 2.5G/3G radio link
saves transmission (battery) power, and increases the ratio of useful
data over total data transmitted. Another important benefit of
active queue management for 2.5G/3G networks, is that it reduces the
risk of a spurious timeout for the first data segment as outlined
below.
活発な待ち行列管理を実装するのは様々な意味でRFC2309[28]に概説されているように魅力的です。 1つの2.5G/ 3Gネットワークに、重要な利益はネットワーク(前のページのダウンロードが完全になる前に「ページからページまでクリックする」)で列に並ばせられるかもしれない潜在的に聞き古したデータの量を最小にするということです。 2.5G/3Gラジオリンクの向こう側に聞き古したデータの伝達を避けるのは、トランスミッション(バッテリー)がパワーであると保存します、そして、総データの上の役に立つデータの比率の増加は伝わりました。 2.5G/3Gネットワークのための活発な待ち行列管理の別の重要な恩恵は最初のデータ・セグメントのために以下に概説されているように偽りのタイムアウトの危険を減少させるということです。
Since 2.5G/3G networks are commonly characterized by high delays, avoiding unecessary round-trip times is particularly attractive. This is specially beneficial for short-lived, transactional (request/ response-style) TCP sessions that typically result from browsing the Web from a smart phone. However, existing solutions such as T/TCP RFC 1644 [27], have not been adopted due to known security concerns [38].
2.5G/3Gネットワークが高い遅れによって一般的に特徴付けられるので、unecessaryの往復の回を避けるのは特に魅力的です。 特に、これは高度自動機能電話からウェブをブラウズするのから通常結果として生じる短命で、取引(応答要求/スタイル)のTCPセッションに有益です。 しかしながら、T/TCP RFC1644[27]などの既存のソリューションは採用された支払われるべきものではありません。知られている安全上の配慮[38]に。
Spurious timeouts, packet re-ordering, and packet duplication may reduce TCP's performance. Thus, making TCP more robust against those events is desirable. Solutions to this problem have been proposed [30], [35], [41], and standardization work within the IETF is ongoing at the time of writing. Those solutions include reverting congestion control state after such an event has been detected, and adapting the retransmission timer and duplicate acknowledgement threshold. The deployment of such solutions may be particularly beneficial when running TCP across wireless networks because wireless access links may often be subject to handovers and resource preemption, or the mobile transmitter may traverse through a radio coverage hole. Such
偽りのタイムアウト、パケット再注文、およびパケット重複はTCPの性能を抑えるかもしれません。 したがって、TCPをそれらのイベントに対して、より強健にするのは望ましいです。 この問題の解決は提案されて、[30]、[35]、[41]、およびIETFの中の標準化仕事が書くこと時点で進行中であるということです。 それらのソリューションは、そのようなイベントが検出された後に輻輳制御状態を振り向けて、再送信タイマーと写し承認敷居を適合させるのを含んでいます。 身柄の引き渡しへの対象と先取り、またはモバイル送信機がそうするリソースがラジオ適用範囲穴を通した横断であったならワイヤレス・アクセスリンクがしばしば実行するのでワイヤレス・ネットワークの向こう側にTCPを実行するとき、そのようなソリューションの展開は特に有益であるかもしれません。 そのようなもの
Inamura, et al. Best Current Practice [Page 17] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[17ページ]RFC3481TCP
disrupting events may easily trigger a spurious timeout despite a conservative retransmission timer. Also, the mobility mechanisms of some wireless networks may cause packet duplication.
保守的な再送信タイマーにもかかわらず、イベントを混乱させるのは容易に偽りのタイムアウトの引き金となるかもしれません。 また、いくつかのワイヤレス・ネットワークの移動性メカニズムはパケット重複を引き起こすかもしれません。
The algorithm for computing TCP's retransmission timer is specified in RFC 2988 [11]. The standard specifies that the initial setting of the retransmission timeout value (RTO) should not be less than 3 seconds. This value might be too low when running TCP across 2.5G/3G networks. In addition to its high latencies, those networks may be run at bit rates of as low as about 10 kb/s which results in large packet transmission delays. In this case, the RTT for the first data segment may easily exceed the initial TCP retransmission timer setting of 3 seconds. This would then cause a spurious timeout for that segment. Hence, in such situations it may be advisable to set TCP's initial RTO to a value larger than 3 seconds. Furthermore, due to the potentially large packet transmission delays, a TCP sender might choose to refrain from initializing its RTO from the RTT measured for the SYN, but instead take the RTT measured for the first data segment.
TCPの再送信タイマーを計算するためのアルゴリズムはRFC2988[11]で指定されます。 規格は、再送タイムアウト価値(RTO)の初期設定が3秒未満であるべきでないと指定します。 2.5G/3Gネットワークの向こう側にTCPを実行するとき、この値は低過ぎるかもしれません。 高い潜在に加えてそれらのネットワークがそう、ビット伝送速度で、大きいパケット伝送遅延をもたらすおよそ10kb/sと同じくらい低く動きます。 この場合、最初のデータ・セグメントのためのRTTは容易に3秒の初期のTCP再送信タイマー設定を超えるかもしれません。 そして、これはそのセグメントのために偽りのタイムアウトを引き起こすでしょう。 したがって、そのような状況で、3秒より大きい値にTCPの初期のRTOを設定するのは賢明であるかもしれません。 その上、潜在的に大きいパケット伝送遅延のため、TCP送付者は、SYNのために測定されたRTTからRTOを初期化するのを控えるのを選ぶかもしれませんが、代わりに最初のデータ・セグメントのために測定されたRTTを取ってください。
Some of the recommendations in RFC 2988 [11] are optional, and are not followed by all TCP implementations. Specifically, some TCP stacks allow a minimum RTO less than the recommended value of 1 second (section 2.4 of [11]), and some implementations do not implement the recommended restart of the RTO timer when an ACK is received (section 5.3 of [11]). Some experiments [52], [54], have shown that in the face of bandwidth oscillation, using the recommended minimum RTO value of 1 sec (along with the also recommended initial RTO of 3 sec) reduces the number of spurious retransmissions as compared to using small minimum RTO values of 200 or 400 ms. Furthermore, TCP stacks that restart the retransmission timer when an ACK is received experience far less spurious retransmissions than implementations that do not restart the RTO timer when an ACK is received. Therefore, at the time of this writing, it seems preferable for TCP implementations used in 3G wireless data transmission to comply with all recommendations of RFC 2988.
RFC2988[11]の推薦のいくつかの任意であり、すべてのTCP実装はあとに続いていません。 [11])について2.4を区分してください。そうすれば、ACKが受け取られているとき、いくつかの実装はRTOタイマのお勧めの再開を実装しません。明確に、いくつかのTCPスタックが1秒の推奨値より最小のRTOを許容しない、((セクション5.3の[11])。 いくつかの実験[52]([54])が帯域幅振動に直面してそれを示して、1秒(3秒のお勧めのも初期のRTOに伴う)の値が減少させるお勧めの最小のRTOを使用して、200か400の小さい最小のRTO値を使用すると比べて、原稿Furthermore、TCPがそれを積み重ねるとき、ACKがACKが受け取られているときRTOタイマを再開しない実装よりはるかに偽物でない容認された経験「再-トランスミッション」であるときに、偽物の「再-トランスミッション」の数は再送信タイマーを再開します。 したがって、この書くこと時点で、RFC2988のすべての推薦に従うのは3Gのワイヤレスのデータ伝送で使用されるTCP実装に望ましく思えます。
6. Security Considerations
6. セキュリティ問題
In 2.5G/3G wireless networks, data is transmitted as ciphertext over the air and as cleartext between the Radio Access Network (RAN) and the core network. IP security RFC 2401 [37] or TLS RFC 2246 [36] can be deployed by user devices for end-to-end security.
2.5G/3Gワイヤレス・ネットワークで、データは空気の上の暗号文としてRadio Access Network(RAN)とコアネットワークの間のcleartextとして送られます。 ユーザデバイスは終わりから終わりへのセキュリティのためにIPセキュリティRFC2401[37]かTLS RFC2246[36]を配布することができます。
7. IANA Considerations
7. IANA問題
This specification requires no IANA actions.
この仕様はIANA動作を全く必要としません。
Inamura, et al. Best Current Practice [Page 18] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[18ページ]RFC3481TCP
8. Acknowledgements
8. 承認
The authors would like to acknowledge contributions to the text from the following individuals:
作者は以下の個人からのテキストへの貢献を承諾したがっています:
Max Hata, NTT DoCoMo, Inc. (hata@mml.yrp.nttdocomo.co.jp)
マックス波田、株式会社NTTドコモ( hata@mml.yrp.nttdocomo.co.jp )
Masahiro Hara, Fujitsu, Inc. (mhara@FLAB.FUJITSU.CO.JP)
正裕ハラ、富士通Inc.( mhara@FLAB.FUJITSU.CO.JP )
Joby James, Motorola, Inc. (joby@MIEL.MOT.COM)
Jobyジェームス、モトローラ( joby@MIEL.MOT.COM )
William Gilliam, Hewlett-Packard Company (wag@cup.hp.com)
ウィリアム・ギリアム、ヒューレット・パッカード会社( wag@cup.hp.com )
Alan Hameed, Fujitsu FNC, Inc. (Alan.Hameed@fnc.fujitsu.com)
アラン・ハミード、富士通FNC Inc.( Alan.Hameed@fnc.fujitsu.com )
Rodrigo Garces, Mobility Network Systems
(rodrigo.garces@mobilitynetworks.com)
ロドリゴ・ガーセズ、移動性ネットワーク・システム( rodrigo.garces@mobilitynetworks.com )
Peter Ford, Microsoft (peterf@Exchange.Microsoft.com)
ピーター・フォード、マイクロソフト( peterf@Exchange.Microsoft.com )
Fergus Wills, Openwave (fergus.wills@openwave.com)
Openwave、ファーガスは望んでいます。( fergus.wills@openwave.com )
Michael Meyer (Michael.Meyer@eed.ericsson.se)
マイケル・マイヤー( Michael.Meyer@eed.ericsson.se )
The authors gratefully acknowledge the valuable advice from the following individuals:
作者は以下の個人から有益な助言を感謝して承諾します:
Gorry Fairhurst (gorry@erg.abdn.ac.uk)
ゴーリーFairhurst( gorry@erg.abdn.ac.uk )
Mark Allman (mallman@grc.nasa.gov)
マーク・オールマン( mallman@grc.nasa.gov )
Aaron Falk (falk@ISI.EDU)
アーロン・フォーク( falk@ISI.EDU )
9. Normative References
9. 引用規格
[1] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control",
RFC 2581, April 1999.
[1] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[2] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High
Performance", RFC 1323, May 1992.
[2] ジェーコブソン(V.、ブレーデン、R. and D.ボーマン、「高性能のためのTCP拡張子」、RFC1323)は1992がそうするかもしれません。
[3] Mathis, M., Mahdavi, J., Floyd, S. and R. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[3] マシスとM.とMahdaviとJ.とフロイドとS.とR.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。
[4] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002.
[4] オールマンとM.とフロイドとS.とC.ヤマウズラ、「増加するTCPの初期の窓」、RFC3390、2002年10月。
Inamura, et al. Best Current Practice [Page 19] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[19ページ]RFC3481TCP
[5] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to-end
Performance Implications of Slow Links", BCP 48, RFC 3150, July
2001.
[5] ダウキンズ、S.、モンテネグロ、G.、Kojo、M.、および「終わりから終わりへの遅いリンクのパフォーマンス含意」、BCP48、RFC3150(2001年7月)対Magret
[6] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[6] ムガール人とJ.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。
[7] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[7] ノウルズ、S.、「経路MTU発見の経験からのIESGアドバイス」、RFC1435、1993年3月。
[8] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP
version 6", RFC 1981, August 1996.
[8] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[9] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[9]RamakrishnanとK.とフロイドとS.とD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168、2001年9月。
[10] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss
Recovery Using Limited Transmit", RFC 3042, January 2001.
[10] オールマンとM.とBalakrishnanとH.とS.フロイド、「株式会社を使用することでTCPの損失回復を機能アップして、伝わってください」、RFC3042、2001年1月。
[11] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[11] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
[12] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-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.
[12] ボルマン、C.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 枠組みと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日
[13] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[13] デーゲルマルクとM.とNordgrenとB.とS.ピンク、「IPヘッダー圧縮」、RFC2507、1999年2月。
[14] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", STD 7, RFC 793, September 1981.
[14] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD7、RFC793、1981年9月。
[15] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's
Fast Recovery Algorithm", RFC 2582, April 1999.
[15] フロイドとS.とT.ヘンダーソン、「TCPの速い回復アルゴリズムへのNewReno変更」、RFC2582、1999年4月。
[16] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC
3241, April 2002.
[16] ボルマン、2002年4月、C.、「pppの上の体力を要しているヘッダー圧縮(ROHC)」RFC3241。
[17] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[17] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[18] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[18] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
Inamura, et al. Best Current Practice [Page 20] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[20ページ]RFC3481TCP
10. Informative References
10. 有益な参照
[19] Montenegro, G., Dawkins, S., Kojo, M., Magret, V. and N.
Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[19] モンテネグロとG.とダウキンズとS.とKojoとM.とMagretとV.とN.Vaidya、「長い薄いネットワーク」、RFC2757、2000年1月。
[20] Third Generation Partnership Project, "RLC Protocol
Specification (3G TS 25.322:)", 1999.
[20] 第三世代パートナーシッププロジェクト、「RLCプロトコル仕様(3G t25.322:)」、1999。
[21] Fall, K. and S. Floyd, "Simulation-based Comparisons of Tahoe,
Reno, and SACK TCP", Computer Communication Review, 26(3) , July
1996.
[21] 秋とK.とS.フロイド、「タホ、リノ、および袋のTCPのシミュレーションベースの比較」、コンピュータコミュニケーションは再検討されます、26(3)、1996年7月。
[22] Fairhurst, G. and L. Wood, "Advice to link designers on link
Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
[22]Fairhurst、G.とL.Wood、「リンクAutomatic Repeat reQuest(ARQ)にデザイナーをリンクするというアドバイス」BCP62、RFC3366(2002年8月)。
[23] Karn, P., "Advice for Internet Subnetwork Designers", Work in
Progress.
[23] P.、「インターネットサブネットワークデザイナーのためのアドバイス」というKarnは進行中で働いています。
[24] Dawkins, S., Montenegro, G., Magret, V., Vaidya, N. and M.
Kojo, "End-to-end Performance Implications of Links with
Errors", BCP 50, RFC 3135, August 2001.
[24] ダウキンズとS.とモンテネグロとG.とMagretとV.、VaidyaとN.とM.Kojo、「終わりから終わりへの誤りとのリンクのパフォーマンス含意」BCP50、RFC3135(2001年8月)。
[25] Wireless Application Protocol, "WAP Specifications", 2002,
<http://www.wapforum.org>.
[25]ワイヤレス・アプリケーション・プロトコル、「WAP仕様。」2002、<http://www.wapforum.org>。
[26] Open Mobile Alliance, "Open Mobile Alliance", 2002,
<http://www.openmobilealliance.org/>.
[26] モバイル同盟、「開いているモバイル同盟」、2002、<http://www.openmobilealliance.org/>を開いてください。
[27] Braden, R., "T/TCP -- TCP Extensions for Transactions", RFC
1644, July 1994.
[27] ブレーデン、R.、「T/TCP--、取引のためのTCP拡張子、」、RFC1644、7月1994日
[28] Braden, R., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J.
and L. Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April 1998.
[28] ブレーデンとR.とクラークとD.とクロウクロフトとJ.とデイビーとB.とデアリングとS.とEstrinとD.とフロイドとS.とジェーコブソンとV.とMinshallとG.とヤマウズラとC.とピーターソンとL.とRamakrishnanとK.、ShenkerとS.とWroclawskiとJ.とL.チャン、「インターネットの待ち行列管理と輻輳回避の推薦」RFC2309(1998年4月)。
[29] IETF, "Robust Header Compression", 2001,
<http://www.ietf.org/html.charters/rohc-charter.html>.
[29]IETF、「体力を要しているヘッダー圧縮」、2001、<http://www.ietf.org/html.charters/rohc-charter.html>。
[30] Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making TCP
Robust Against Spurious Retransmissions", ACM Computer
Communication Review 30(1), January 2000.
[30] ラドウィグ、R.、およびR.H.キャッツ、「アイフェル高原アルゴリズム:」 「偽物のRetransmissionsに対して強健な作成TCP」、ACMコンピュータコミュニケーションレビュー30(1)、2000年1月。
[31] Wireless Application Protocol, "WAP Wireless Profiled TCP",
WAP-225-TCP-20010331-a, April 2001,
<http://www.wapforum.com/what/technical.htm>.
[31] ワイヤレス・アプリケーション・プロトコル、「WAP無線電信はTCPの輪郭を描いた」WAP-225-TCP-20010331-a、2001年4月、<が://www.wapforum.com/をhttpします。何という/technical.htm>。
Inamura, et al. Best Current Practice [Page 21] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[21ページ]RFC3481TCP
[32] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of Explicit
Congestion Notification (ECN) in IP Networks", RFC 2884, July
2000.
[32] ハディ・サリム、J.とU.アフマド、「IPネットワークにおける、明白な混雑通知(電子証券取引ネットワーク)の業績評価」RFC2884(2000年7月)。
[33] NTT DoCoMo Technical Journal, "Special Issue on i-mode Service",
October 1999.
[33]NTTドコモTechnical Journal、「iモードServiceの上の特別なIssue」1999年10月。
[34] NTT DoCoMo Technical Journal, "Special Article on IMT-2000
Services", September 2001.
[34]NTTドコモ専門誌、「IMT-2000サービスの特別な記事」、2001年9月。
[35] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option for
TCP", RFC 2883, July 2000.
[35] フロイドとS.とMahdaviとJ.とマシスとM.とM.ポドルスキー、「TCPのための選択している承認(袋)オプションへの拡大」、RFC2883、2000年7月。
[36] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[36] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[37] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[37] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[38] de Vivo, M., O. de Vivo, G., Koeneke, R. and G. Isern, "Internet
Vulnerabilities Related to TCP/IP and T/TCP", ACM Computer
Communication Review 29(1), January 1999.
[38] de Vivo、M.、O.de Vivo、G.、Koeneke、R.、およびG.Isern、「インターネット脆弱性はTCP/IPとT/TCPに関連しました」、ACMコンピュータCommunication Review 29(1)、1999年1月。
[39] Third Generation Partnership Project, "RRC Protocol
Specification (3GPP TS 25.331:)", September 2001.
[39] 第三世代パートナーシッププロジェクト、「RRCプロトコル仕様(3GPP t25.331:)」、2001年9月。
[40] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial
Links", RFC 1144, February 1990.
[40] ジェーコブソン対RFC1144、「低速連続のリンクへのTCP/IPヘッダーを圧縮すること」での1990年2月
[41] Blanton, E. and M. Allman, "On Making TCP More Robust to Packet
Reordering", ACM Computer Communication Review 32(1), January
2002, <http://roland.grc.nasa.gov/~mallman/papers/tcp-reorder-
ccr.ps>.
[41] ブラントンとE.とM.オールマン、「パケットReorderingにより強健な作成TCP」、ACMコンピュータCommunication Review 32(1)、2002年1月(<http://roland.grc.nasa.gov/~tcp-追加注文mallman/書類/ccr.ps>)。
[42] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates
in Reliable Transport Protocols", ACM SIGCOMM 87, 1987.
[42]Karn、P.とC.ヤマウズラ、「信頼できるトランスポート・プロトコルで往復の時間見積りを改良する」ACM SIGCOMM87、1987。
[43] Ludwig, R., Rathonyi, B., Konrad, A. and A. Joseph, "Multi-layer
tracing of TCP over a reliable wireless link", ACM SIGMETRICS
99, May 1999.
[43] ラドウィグとR.とRathonyiとB.、コンラッドとA.とA.ジョゼフ、「信頼できる無線のリンクの上のTCPをマルチ層のたどる」ACM SIGMETRICS99(1999年5月)。
[44] Ludwig, R., Konrad, A., Joseph, A. and R. Katz, "Optimizing the
End-to-End Performance of Reliable Flows over Wireless Links",
Kluwer/ACM Wireless Networks Journal Vol. 8, Nos. 2/3, pp. 289-
299, March-May 2002.
[44] ラドウィグ、R.、コンラッド、A.、ジョゼフ、A.、およびR.キャッツ、「無線電信の上の信頼できる流れの終わりから終わりへのパフォーマンスを最適化するのはリンクします」、Kluwer/ACM Wireless Networks Journal Vol.8、No.2/3、ページ 289- 299と、2002年3月-5月。
Inamura, et al. Best Current Practice [Page 22] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[22ページ]RFC3481TCP
[45] Gurtov, A., "Making TCP Robust Against Delay Spikes", University
of Helsinki, Department of Computer Science, Series of
Publications C, C-2001-53, Nov 2001,
<http://www.cs.helsinki.fi/u/gurtov/papers/report01.html>.
[45] A. Gurtov、ヘルシンキ大学、コンピュータサイエンス学部、「TCPをDelayスパイクスに対して強健にする」刊行物C、C-2001-53、2001年11月(<http://www.cs.helsinki.fi/u/gurtov/書類/report01.html>)のシリーズ。
[46] Stevens, W., "TCP/IP Illustrated, Volume 1; The Protocols",
Addison Wesley, 1995.
[46] スティーブンス、W.、「例証されたTCP/IP、第1巻」。 「プロトコル」、アディソン・ウエスリー、1995。
[47] Braden, R., "TCP Extensions for High Performance: An Update",
Work in Progress.
[47] ブレーデン、R.、「高性能のためのTCP拡張子:」 「アップデート」、進行中の仕事。
[48] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D.,
Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann,
S., Scott, K. and J. Semke, "Ongoing TCP Research Related to
Satellites", RFC 2760, February 2000.
[48]オールマン、M.、ダウキンズ、S.、手袋製造業者、D.、Griner、J.、チャン、D.、ヘンダーソン、T.、Heidemann、J.、接触、J.、クルーゼ、H.、オステルマン、S.、スコット、K.、およびJ.Semke、「進行中のTCP研究は衛星に関連しました」、RFC2760、2000年2月。
[49] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over
Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488,
January 1999.
[49] オールマン、M.、手袋製造業者、D.、およびL.サンチェス、「衛星の上の高めるTCPは標準のメカニズムを使用することで精神を集中します」、BCP28、RFC2488、1999年1月。
[50] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M.
Sooriyabandara, "TCP Performance Implications of Network
Asymmetry", RFC 3449, December 2002.
[50]BalakrishnanとH.とPadmanabhanとV.とFairhurstとG.とM.Sooriyabandara、「ネットワーク非対称のTCPパフォーマンス含意」、RFC3449、2002年12月。
[51] Kempf, J., "Problem Description: Reasons For Performing Context
Transfers Between Nodes in an IP Access Network", RFC 3374,
September 2002.
[51] ケンフ、J.、「問題記述:」 「IPアクセスネットワークでノードの間の文脈転送を実行する理由」、RFC3374、2002年9月。
[52] Khafizov, F. and M. Yavuz, "Running TCP over IS-2000", Proc. of
IEEE ICC, 2002.
[52]Khafizov、F.、およびM.Yavuz、「TCPをひく、-2000である、」、Proc IEEE ICC、2002年について。
[53] Khafizov, F. and M. Yavuz, "Analytical Model of RLP in IS-2000
CDMA Networks", Proc. of IEEE Vehicular Technology Conference,
September 2002.
[53]Khafizov、F.、およびM.Yavuz、「中のRLPの分析モデル、-2000である、CDMAがネットワークでつなぐ、」、Proc IEEE車両技術部会コンファレンス、2002年9月について。
[54] Yavuz, M. and F. Khafizov, "TCP over Wireless Links with
Variable Bandwidth", Proc. of IEEE Vehicular Technology
Conference, September 2002.
[54]Yavuz、M.とF.Khafizov、「可変帯域幅との無線のリンクの上のTCP」Proc IEEE車両技術部会コンファレンス、2002年9月について。
[55] TIA/EIA/cdma2000, "Mobile Station - Base Station Compatibility
Standard for Dual-Mode Wideband Spread Spectrum Cellular
Systems", Washington: Telecommunication Industry Association,
1999.
[55]TIA/EIA/cdma2000、「移動局--デュアル・モード広帯域の駅の互換性規格を基礎づけるのはスペクトルセルラ方式を広げた」ワシントン: 電気通信企業団体、1999。
[56] TIA/EIA/IS-95 Rev A, "Mobile Station - Base Station
Compatibility Standard for Dual-Mode Wideband Spread Spectrum
Cellular Systems", Washington: Telecommunication Industry
Association, 1995.
[56] TIA/EIA/、-95である、A、「移動局--デュアル・モード広帯域の駅の互換性規格を基礎づけるのはスペクトルセルラ方式を広げた」ワシントンを回転させてください: 電気通信企業団体、1995。
Inamura, et al. Best Current Practice [Page 23] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[23ページ]RFC3481TCP
[57] TIA/EIA/IS-707-A-2.10, "Data Service Options for Spread Spectrum
Systems: Radio Link Protocol Type 3", January 2000.
[57] TIA/EIA/、-、707-A-2.10、「データサービスはスペクトル拡散方式のために以下をゆだねます」。 ラジオリンクプロトコルは3インチと、2000年1月にタイプします。
[58] Dahlman, E., Beming, P., Knutsson, J., Ovesjo, F., Persson, M.
and C. Roobol, "WCDMA - The Radio Interface for Future Mobile
Multimedia Communications", IEEE Trans. on Vehicular Technology,
vol. 47, no. 4, pp. 1105-1118, November 1998.
[58] E.、Beming、P.、Knutsson、J.、Ovesjo、F.、ペルソン、M.、およびC.Roobol、Dahlmanに、「WCDMA--ラジオは将来のモバイルマルチメディアコミュニケーションのために連結します」、IEEE Trans、車両技術部会、vol.47、No.4、ページ 1105-1118と、1998年11月。
[59] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path
Properties", ACM SIGCOMM 99, September 1999.
[59] オールマン、M.、および「終わりから端へのネットワーク経路が土地であると見積もっている」ACM SIGCOMM99、1999年9月対パクソン
[60] Gurtov, A. and R. Ludwig, "Responding to Spurious Timeouts in
TCP", IEEE INFOCOM'03, March 2003.
[60]GurtovとA.とR.ラドウィグ、「TCPの偽りのタイムアウトに応じる」IEEE INFOCOM'03、2003'年3月。
Inamura, et al. Best Current Practice [Page 24] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[24ページ]RFC3481TCP
11. Authors' Addresses
11. 作者のアドレス
Hiroshi Inamura NTT DoCoMo, Inc. 3-5 Hikarinooka Yokosuka Shi, Kanagawa Ken 239-8536 Japan
Hikarinooka横須賀シャイ、Hiroshi Inamura株式会社NTTドコモ3-5ケン239-8536日本神奈川
EMail: inamura@mml.yrp.nttdocomo.co.jp URI: http://www.nttdocomo.co.jp/
メール: inamura@mml.yrp.nttdocomo.co.jp ユリ: http://www.nttdocomo.co.jp/
Gabriel Montenegro Sun Microsystems Laboratories, Europe Avenue de l'Europe ZIRST de Montbonnot 38334 Saint Ismier CEDEX France
ガブリエルモンテネグロサン・マイクロシステムズ研究所、ヨーロッパアベニューde l'Europe ZIRST de Montbonnot38334セイント・Ismier CEDEXフランス
EMail: gab@sun.com
メール: gab@sun.com
Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrath Germany
ライナー・ラドウィグ・エリクソン研究エリクソン並木道1 52134Herzogenrathドイツ
EMail: Reiner.Ludwig@Ericsson.com
メール: Reiner.Ludwig@Ericsson.com
Andrei Gurtov Sonera P.O. Box 970, FIN-00051 Helsinki, Finland
アンドレイGurtovソネラP.O. Box970、ヘルシンキ、フィン-00051フィンランド
EMail: andrei.gurtov@sonera.com URI: http://www.cs.helsinki.fi/u/gurtov/
メール: andrei.gurtov@sonera.com ユリ: http://www.cs.helsinki.fi/u/gurtov/
Farid Khafizov Nortel Networks 2201 Lakeside Blvd Richardson, TX 75082, USA
テキサス 75082、ファリドKhafizovノーテルネットワーク2201湖畔Blvdリチャードソン(米国)
EMail: faridk@nortelnetworks.com
メール: faridk@nortelnetworks.com
Inamura, et al. Best Current Practice [Page 25] RFC 3481 TCP over 2.5G/3G February 2003
Inamura、他 2.5G/3G2003年2月の間の最も良い現在の習慣[25ページ]RFC3481TCP
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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機能のための基金は現在、インターネット協会によって提供されます。
Inamura, et al. Best Current Practice [Page 26]
Inamura、他 最も良い現在の習慣[26ページ]
一覧
スポンサーリンク
