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
TCP over Second (2.5G) and Third (3G) Generation Wireless Networks
セカンド（2.5G）と第3（3G）世代無線ネットワーク上でTCP
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
この文書では、第2（2.5G）と第3（3G）世代無線ネットワークを含むパスを処理するように適合させるためにTCPを最適化するためのプロファイルを記述する。これは、2.5Gおよび3Gネットワークの関連する特性、及びそのようなネットワークの例の展開の具体的な機能について説明します。その後、このようなパスで開始または終了することが知られているノードに対してTCPアルゴリズムの選択肢を推奨しています、そしてそれはまた、未解決の問題について説明します。このドキュメントで推奨設定オプションは、一般的に近代的なTCPスタックで見つかった、とコミュニティが一般的なインターネット上での使用のために安全と考えて広く利用可能な標準化過程メカニズムされています。
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
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と呼ばれます。デジタル音声符号化は、アナログシステム（1G）を交換した場合2G相は1990年代に始まりました。 2Gシステムは、周波数、コード - および時分割多重アクセスを含む種々の無線技術に基づいています。 2Gシステムの例は、GSM（欧州）、PDC（日本）を含む、及びIS-95（USA）。 2Gシステムによって提供されるデータリンクは、主に回線交換であり、10~20 kbpsのアップリンクとダウンリンクの伝送速度を有します。より高いデータレート、インスタント可用性およびデータ量ベース課金、並びに2Gのために割り当てられた無線スペクトルの欠如のために需要が2.5Gの導入につながった（例えば、GPRSとは、PDC-P）および3G（例えば、広帯域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.
両方の広帯域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技術を中心としています。音声チャネルのための大容量化などの目的に加えて、これらの主な動機は、データ通信である、そして、特に、インターネットアクセス。従って、重要な問題は、TCPの性能と異なる無線環境[19]の上にそれを最適化するために適用することができるいくつかの技術です。
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節を参照）。
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.
WAPフォーラム[25] O（2002年6月のようにオープン・モバイル・アライアンスの一部[26]）は、デジタル携帯電話の無線情報と電話サービスのための標準を開発している業界団体です。このよう2.5Gおよび3Gネットワークなどの高速ネットワークのためのWAPの機能に対処するため、およびインターネット標準に収斂を目指すためには、WAPフォーラムは、徹底的にその仕様を修正しました。得られたバージョン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モードの新しいバージョンは、FOMA [34]、W-CDMAの実装で実行されます。 FOMAオーバーI-modeは、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節では、いくつかの未解決の問題について説明します。
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ネットワークへの独自のリンク特性のさまざまな側面を提示します。
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.
リンクレベルなど2.5G / 3Gリンクのレイテンシによるこれらのネットワークの物理層、例えば、必要に広範囲の処理に、FECおよびインタリービングのために、そしてによる無線アクセスネットワークにおける伝送遅延に主に高い[58]（再送信）。典型的なRTTは、数百ミリ秒と1秒の間で変動します。関連する無線チャネルが困難な伝搬環境に苦しんでいます。従って、強力で複雑な物理層技術は、リソースの効率的な方法で広いカバレッジエリアに高い容量を提供するために適用される必要があります。うまくいけば、信号処理上無線レイヤ技術からシステム・アーキテクチャの範囲のワイヤレスネットワークのすべての分野で急速な改善は、最終的にも、3G無線システムにおける遅延低減につながります。
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.
2Gから2.5Gへの3Gへの移行のための主要なインセンティブは、音声容量とユーザーのためのデータレートが増加しています。 2.5Gシステムは、アップリンクで10〜20 kbpsのリンクおよびダウンリンクにおける10-40 kbpsのデータ速度を有します。初期の3Gシステムは、下りリンクにおいてアップリンクでは64kbpsと384kbpsの周りのビットレートを有することが期待されます。 2.5Gおよび3Gのために8〜50キロバイトのために周りに1〜5キロバイトの結果として得られる帯域幅遅延積（BDP）を考慮し、2.5GリンクはLTNs（細長いネットワーク[19]）と考えることができ、そして3GはアプローチLFNsリンク（ロング脂肪ネットワーク[2]、いくつかの衛星ネットワークによって例示されるように[48]）。したがって、関心のある読者は、RFC 2488 [49]で議論関連し、潜在的に関連する問題を見つけるかもしれません。優れたTCPの性能を得るために両方LFNsとLTNsは、優れたデータの十分な大きさの窓を維持する必要。 LFNsのために、利用可能なネットワーク帯域幅を利用すること特に懸念されます。 LTNsは、効率的な損失回復のために十分に大きな窓を必要としています。ウィンドウは以下4つのセグメントである場合、特に、高速再送アルゴリズムがトリガすることはできません。これは、再送タイムアウトによる長い回復につながります。限定送信アルゴリズムRFC 3042 [10]は、小さな窓との接続のタイムアウトの悪影響を避けることができます。それにもかかわらず、両方のLFNsとLTNsにおける損失回復のためのSACKのRFC 2018 [3]の情報を駆使して、利用可能な帯域幅を利用するそうでない場合は、十分な二回窓が必要な場合があります。
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でうまく処理され、低速セルに速いから変更。 2.7節で説明したようにしかし、この場合はRTTの急激な増加は、スプリアスTCPタイムアウトを引き起こす可能性があります。また、高速セルで使用される大規模なTCPウィンドウが遅いセルにoverbufferingその結果混雑を作成することができます。
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倍を超えないこと、およびACK輻輳制御またはACKフィルタリング[50]のような技術を必要とせずにTCPによって許容することができます。したがって、この文書は、このような非常に非対称ネットワークのために意味の勧告が含まれていません。
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のタイムアウト、不必要な再送信と輻輳ウィンドウサイズの乗算減少を引き起こす可能性があります。
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システムは、パケット損失率の低さにリンクレベルの再送信のおかげを持っています。リンク層ARQのための正当化は、[23]、[22]、[44]に記載されています。一般に、リンク層ARQとFECは検出されないエラー（リンクCRCの失敗）の無視できるほどに小さい確率でパケットサービス、及び上層トラフィックの損失（不着）の低レベル、例えば、IPを提供することができます。 IPパケットの損失率は、ARQによる低いが、リンク層での回復は、計算されたRTO値を長く上位層に遅延ジッタとして表示されます。
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].
2.5Gシステムが他の場所より低速のデータサービスを提供する一方、展開の初期段階では、3Gシステムは、高い人口分野での「ホットスポット」の技術として使用されます。これは、現在進行中の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の実装により、時期尚早な最適化に対して主張しています。
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 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].
2.5G / 3G無線システムの高データレートの要求を満たす、制限されたRFスペクトルを与えられるが同時データユーザ間で動的なリソース共有を必要とします。様々なスケジューリングメカニズムは、リソース使用率を最大化するために展開することができます。複数のユーザーが同時に大量のデータを転送したい場合は、スケジューラは、各ユーザのためのリソースを繰り返し割り当て、デ割り当てる必要があります。私たちは、定期的な割り当てと帯域幅の振動などの高速チャネルのリリースを参照してください。このようなスプリアス再送などの帯域発振効果は他の場所で同定された（例えば、[30]）のスループットを低下させる要因として。いくつかのケースでは帯域幅の振動は、スループットを低下させるのに単一の最も重要な要因となり得ることを示した調査研究[52]、[54]は、あります。固定TCPパラメータのために達成可能なスループットは、資源配分のパターンに依存します。リソース割り当てと割り当て解除の周波数が十分に高い場合、いかなるスループットの低下がありません。しかし、リソース割り当て/割り当て解除の頻度を増加させると増加したシグナルを犠牲にして来るかもしれない、そして、したがって、望ましくないかもしれません。 3Gワイヤレス技術の標準化は、帯域幅の振動の悪影響に対抗するために使用することができますメカニズムを提供します。これは、帯域幅の振動の悪影響を避けるための最善のアプローチは、適切な無線サブネットワークの設計[23]であることをPILCワーキンググループのコンセンサスです。
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のパフォーマンスで発生する可能性のある問題を議論することではありません。他の文書は、より詳細に基礎となる技術を議論します。リンク層ARQのためのさらなる正当化は[22]、[44]で説明されている。例えば、ARQ及びFECは、[23]に記載されています
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.
高速回線交換データ（HSCSD）と汎用パケット無線サービス（GPRS）は、ユーザーのために、高いデータレートを提供するGSMの拡張です。どちらの拡張機能は、ETSIによって、後に3GPPによって最初に開発されました。 GSMにおいて、ユーザは、1つのタイムスロットダウンリンクと一つの上りリンクが割り当てられています。 HSCSDは、高速回線交換リンクを作成し、ユーザーに複数のタイムスロットを割り当てます。 GPRSは、ユーザーと常時オン機能の中での無線リソースの効率的な共有を可能にするパケット交換技術に基づいています。いくつかの端末は、タイムスロットを共有することができます。 GPRSネットワークは、アクセスネットワークとしてGSMの更新された基地局サブシステムを使用します。 GPRSコアネットワークは、GPRSサポートノード（SGSN）とゲートウェイGPRSサポートノード（GGSN）をサービング含みます。基地局制御装置と端末との間で動作するRLCプロトコルは、無線リンク上でARQ機能を提供します。 SGSNと端末との間の論理リンク制御（LLC）プロトコルは、ハンドオーバ中に利用ARQ能力を有します。
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モバイル通信規格のグローバル電気通信システムの一つとして、広帯域符号分割に多重アクセス（W-CDMA）を選択しています。 W-CDMAの仕様は、第3世代パートナーシッププロジェクト（3GPP）で作成されます。
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ネットワークのリンク層の特性は、層2 ARQ（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（無線リンク制御）[20]、選択再送とスライディングウィンドウARQを使用します。 RLCは、16ビットのRLCヘッダとプロトコルデータユニット（PDU）を使用します。 PDUのサイズが変化してもよいです。典型的には、336ビットのPDUが実装されている[34]。これは、リンク層の再送のためのユニットです。 IPパケットは、RLCによる送信のためにPDUに断片化されます。 （より多くの断片化の議論については、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、12台のPDUに1（RLCフレーム）に1つのFECフレーム、リンク条件および帯域幅割り当てに依存するの実際のサイズを構成します。 FECフレームは、インターリーブ単位です。 FECのためのPDUのこの蓄積は、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の再送信の肯定応答モードがあります。 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]（無線リソースコントローラ）によって指定された設定RLCパラメータです。 RRCは、（40の最大まで）再送信の最大数を設定することができます。したがって、RLCは、[22]における用語によれば、高永続性または低永続性のいずれか、しないPERFECT永続性のために構成することができるARQとして説明することができます。
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の接続状態を管理するので、帯域幅発振（セクション2.7）は、そのキュー内のデータとRLCコネクションでRRCの保持RFリソースで除去することができます。これは、データ転送の途中でリソース割り当て解除を回避します。
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 relatively large BDP (Bandwidth-Delay Product) of up to 50 KB for the 384 kbps radio bearer.
要約すると、リンク層ARQとFECは、未検出のエラーの無視できるほどに小さい確率（リンクCRCの失敗）、および上層トラフィックの損失（不着）のローレベル、すなわち、IPのパケットサービスを提供することができ。 ARQによるPDUの再送信は、IPフローに遅延と遅延ジッタを紹介しています。トランスポート層は、384 kbpsの無線ベアラのために最大50キロバイトの比較的大きなBDP（帯域幅遅延積）を有するネットワークとして下地のW-CDMAネットワークを見ている理由です。
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.
国際移動体通信-2000の傘の下で提案されている3Gワイヤレスシステム用地上無線インタフェース規格の一つは、CDMA2000 [55]です。これは、1.25MHzでのシングルキャリアRF帯域幅でマルチキャリア符号分割多元接続（CDMA）技術を採用しています。 cdma2000は、IS-95 [56]、CDMA技術に基づく2G標準から進化しました。 CDMA2000の第一段階は、シングルキャリアを利用し、既存のCDMA（IS-95）ネットワークの音声容量を倍増するために、常にオンサポートするために、最大316.8 kbpsのデータ伝送速度に設計されています。前述したように、これらの拡張機能は、CDMA2000 1XRTTによって配信されます。 2Mbpsでの3G速度はCDMA2000 1X-EVによって提供されます。物理層では、標準は、5,10,20,40または80ミリ秒の時間枠での送信を可能にします。様々な直交（ウォルシュ）符号はチャネル識別のために使用され、より高いデータレートを達成します。
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.
無線リンクプロトコルタイプ3（RLP）[57]はCDMAデータサービスをサポートするために、cdma2000のトラフィックチャネルで使用されます。 RLPは、オクテットストリーム転送サービスを提供し、上位層フレーミングを認識しません。いくつかのRLPフレームフォーマットがあります。高いペイロードを持つRLPフレームフォーマットは、より高いデータレートのために設計されていました。チャネル速度に応じて、一つ以上の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ベース有限選択再送プロトコルです。受信機が正常に受信したデータフレームを認識しません。一つ以上のRLPデータフレームが欠落している場合は、受信RLPは（NAKを丸めると呼ばれる）いくつかの試みが、送信機に一つ以上のNAK制御フレームを送信することによって、それらを回収することができます。各NAKフレームは、別個の物理層フレームで送信されなければなりません。 RLPは、特定のNAKラウンドの最後のNAK制御フレームが供給されると、再送タイマが設定されています。タイマーが満了したときに行方不明のフレームが受信されない場合、RLPは、別のNAKラウンドをしようとします。 RLPは、不足しているすべてのフレームを回復しない場合があります。すべてのRLPが丸めた後、フレームがまだ不足している場合、RLPは上位層プロトコルに欠けているフレームでデータを提供します。
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: o at the data receiver (frequently a stack at or near the wireless device),
以下は、2.5Gおよび3Gワイヤレスネットワーク上のTCP接続をサポートするために使用されるプロトコルスタックの構成パラメータに関する推奨事項のセットです。これらの推奨事項のいくつかは特別な設定を意味する：データ受信機（無線デバイスまたはその近く頻繁スタック）における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標準トラックメカニズムです。システム管理者は、（セクション4.4）MTUサイズを増加させ、RFC 1144ヘッダー圧縮（セクション4.9）を無効にするホスト効率に影響を及ぼし、及び変更そのようなパラメータは慎重に行うべきであることができること、しかし、警告されています。
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は、エンドツーエンドのパスの帯域幅遅延積（BDP）（2.2節を参照）に基づいて、適切なウィンドウ・サイズをサポートする必要があります。 TCP仕様[14]は64キロバイトに受信ウィンドウサイズを制限します。エンドツーエンドのBDPが64KBを超えることが予想される場合、ウィンドウスケールオプションは、[2]、その限界を克服するために使用することができます。デフォルトの使用小さなTCPによって、多くのオペレーティング・システムは、受信および16キロバイトの周りにバッファを送信します。このため、64キロバイト以下BDPのために、デフォルトのバッファサイズの設定は、十分に大きな窓を可能にするために、送信側で、かつ、受信機で増加されるべきです。
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は輻輳ウィンドウのメカニズムを使用して、その送信レートを制御します。遅延ACK機構（17）と結合された1つのセグメントの伝統的な初期ウィンドウ値は、遅延ACKタイムアウト（典型的には200ミリ秒が、潜在的にはるかに500ミリ秒）4を含む接続の初期段階において、不要なアイドル時間を意味します]。送信者は、最大4つのセグメント（約4キロバイトを超えない）[4]の大きい初期ウィンドウを使用することによって、これを回避することができます。それはいくつかのTCPセグメントの伝送のために特に有効であることを増加し、初期の窓と関連する測定を用いた実験（すなわち、それは混雑崩壊につながるものではない）、この仕組みを導入しても安全であることを（1）に示されている、および（2） （一般的にインターネット対応の携帯無線機器などのアプリケーションで見られる行動である）データの「価値。大規模なデータ転送のために、他方では、このメカニズムの効果は無視できます。
TCP over 2.5G/3G SHOULD set the initial CWND (congestion window) according to Equation 1 in [4]:
2.5G / 3G上TCP [4]において、式1に従って初期CWND（輻輳ウィンドウ）を設定する必要があります。
min (4*MSS, max (2*MSS, 4380 bytes))
分（4 * MSS、MAX（2 * MSS 4380バイト））
This increases the permitted initial window from one to between two and four segments (not to exceed approximately 4 KB).
これは、2〜4つのセグメント（約4kbを超えない）1つから許可初期ウィンドウを増加させます。
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.
RFC 3042 [10]、リミテッド送信は、[1]高速再送信をトリガするために必要な3つの重複確認応答を生成しにくい小さな輻輳ウィンドウとのTCP接続のための高速再送信/高速リカバリを拡張します。送信者が以前に未送信データが送信のためにキューに入れられた場合、制限された送信機構は、送信側に到着する最初の二つの重複確認応答の各々に応答して新たなデータセグメントを送信するために呼び出します。輻輳ウィンドウサイズが小さい場合や、ウィンドウ内のセグメントの多数が失われた場合である場合、このメカニズムは有効です。これは、TCPのタイムアウトにいくつかの再送信を回避することができます。具体的には、いくつかの研究[10]は忙しいサーバの再送信の半分以上（高速再送信ではなく）によるRTOの満了にした、そしてそれらのおよそ25％が限定ミットを使用して回避されている可能性があることを示しました。セクション4.2で議論と同様に、この機構は、送信するデータの少量のために有用です。 2.5G / 3Gの実装上のTCPは限定送信を実装する必要があります。
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（最大転送単位）です。 PDUにリンク層が、順番に、フラグメントIPデータグラム。例えば、高いエラー率とのリンクの上に、小さなリンクPDUのサイズは、送信成功の可能性が高くなります。層2 ARQと透明リンク層断片化を使用すると、ネットワーク層は、比較的高いBER（ビット・エラー・レート）状態に大きな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は（イーサネット上のIPパケットの1500バイトなど）（例えば576バイトなど）小さい値から使用中のリンクの種類によってサポートされて大きな値に至るまでMTU値を選択する設計者のための自由を可能にしなければなりません。ウィンドウは、セグメント単位でカウントされていることを考えると、大きなMTUは、TCPが速く混雑ウィンドウを増加させることを可能にする[5]。このため、設計者は、一般的に、より大きな値を選択することをお勧めします。これらは、IPv6 [18]のIPv4 RFC 1191 [6] 1280バイトを576バイトのデフォルトIP MTU値を超えてもよいです。この勧告は、3Gネットワークに適用可能であるが、2.5Gネットワーク上の操作は、[5] RFC 3150の推奨どおりに注意を払う必要があります。
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フラグメンテーションなし）最大エンド・ツー・エンド伝送ユニットを決定することを可能にします。 RFC 1191 [6]およびRFC 1981 [8]は、それぞれ、IPv4およびIPv6のMTU発見手順が記載されています。これは、TCP送信者は、代わりに小さなデフォルトMTUを仮定（IP層断片化を引き起こすことなく）大きなセグメントサイズを使用することを可能にします。 2.5G / 3Gの実装上のTCPは、パスMTUディスカバリを実装する必要があります。パスMTUディスカバリは、必要なICMPメッセージの生成をサポートするために、中間ルータが必要です。 RFC 1435 [7]いくつかのルータの実装に関連してもよい勧告を提供します。
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）、RFC 2018 [3]は、有効です。具体的には、エンドツーエンドの経路が大きくBDPと高いパケット損失率、データ増加の単一のウィンドウ内の複数のセグメントの損失の確率を持っている場合。このような場合、SACKは、TCP-タホ及びTCP-リノ[21]を超えてロバスト性を提供します。 2.5G / 3G経由TCPはSACKをサポートする必要があります。
In the absence of SACK feature, the TCP should use NewReno RFC 2582 [15].
SACK機能の非存在下で、TCPは、NewRenoのRFC 2582 [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.
明示的輻輳通知は、RFC 3168 [9]、TCP受信機はCEビット（S）でマークされたIPパケットを受信すると、ECN-エコーフラグを設定することにより、ネットワークの輻輳の送信者に通知することを可能にします。 TCPの送信者は、その輻輳ウィンドウを削減します。したがって、ECNの使用は[32]、[43]の性能上の利点を提供すると考えられます。 RFC 3168 [9]は、中間ルータ（例えば、アクティブキュー管理と輻輳を示すためにIPヘッダのCEビット（単数または複数）の設定）に関する要件を課します。 ECN対応ルータが経路に沿って展開されたときしたがって、性能の潜在的な改善しか達成することができます。 2.5G / 3G以上のTCPは、ECNをサポートする必要があります。
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 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].
伝統的に、TCPはデータ[14]、[17]のウィンドウごとにRTTのサンプルを収集します。これは、パケット伝送遅延RTTを支配する経路上RTT、スプリアスタイムアウトの過小評価につながる可能性があります。これは、RFC 2988 [11]で指定されたもののような保守的な再送信タイマにもかかわらず成立します。大きな窓とのTCP接続が変化するネットワーク条件[2]に迅速に適合させることにより、タイムスタンプを備えたより頻繁なRTTサンプルから利益を得ることができます。しかし、RFC 2988タイマー[11]とのTCPのため、タイムスタンプがバックボーンインターネット・パス[59]にはほとんど、あるいは全く利益をもたらすことを、いくつかの実証的証拠があります。 TCPタイムスタンプオプションを使用すると、再送セグメントが他カーンのアルゴリズム[17]、[11]によって禁止されているRTT測定のために使用することができるという利点を有します。また、TCPタイムスタンプオプションはアイフェルアルゴリズム[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リンクを介して遅延スパイクは、多くの場合、エンドツーエンドのRTTを超えてもよい（セクション2.4を参照します）。パスの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あたりよりパスのRTTをサンプリングすることが有利です。これは、TCPの送信者がより密接にRTTの変化を追跡することができます。具体的には、TCP送信者はより早く、より保守的な値にRTOを更新することにより、RTTの突然の増加に、より迅速に反応することができます。 TCPタイムスタンプオプションは、[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オーバーヘッドの12のバイトはTCPヘッダ内のTCPタイムスタンプオプションとパディングを実施することによって導入されます。小さな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 packet to the next. The IETF is currently specifying a robust TCP/IP header compression scheme with better support for TCP options [29].
O現在のTCPヘッダ圧縮方式は、TCPオプションフィールドの彼らの扱いに限定されています。 RFC 2507 [13]のために、オプションフィールドの任意の変化（例えば、タイムスタンプまたはSACKによって引き起こされる）が非圧縮フィールド全体（但し、圧縮TCP / IPヘッダ自体を残す）をレンダリングします。さらに悪いことには、RFC 1144のオプションフィールドに[40]そのような変化は、効果的に完全にTCP / IPヘッダー圧縮を無効にします。これは、接続がTCPタイムスタンプオプションを使用する場合です。そのオプションフィールドは、データとACKパスの両方で使用され、その値は、典型的には、1つのパケットから次へと変化します。 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はTCPタイムスタンプオプションを使用する必要があります。これは、より良いRTT推定を可能にし、スプリアスタイムアウトのリスクを低減します。
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].
そのRFC 1144 [40] TCPヘッダー圧縮は、パケット損失[43]、[52]の存在下ではうまく機能しないよく知られている（および実験データで示されています）。無線リンクエラーが回復しない場合、それはコンプレッサーと減圧器との間にTCPセグメント損失の原因となり、その後、RFC 1144ヘッダー圧縮は、TCPを高速再送高速リカバリメカニズムを利用することはできません。 RFC 1144ヘッダー圧縮アルゴリズムは、全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].
以前RFC 3150で推奨されているようにコンプレッサとデコンプレッサとの間のパケット損失確率が非常に低い場合を除き、[5]、RFC 1144ヘッダー圧縮を有効にしないでください。実際には、タイムスタンプオプションを有効にすると効果的（4.8節を参照）と同じことを達成します。 RFC 2507 [13]及びロバストヘッダ圧縮[12]のような他のヘッダ圧縮方式はRFC 1144ヘッダー圧縮における欠点に対処することを意味します。この記事の執筆時点では、IETFは、[16]（TCPオプションなどを圧縮、PPP上でロバストヘッダ圧縮を交渉）ロバストヘッダ圧縮に複数の拡張子に取り組んでいました。
Items Comments
----------------------------------------------------------------
Appropriate Window Size (sender & receiver)
based on end-to-end BDP
Window Scale Option (sender & receiver) [RFC1323] Window size > 64KB
ウィンドウスケールオプション（送信＆受信）[RFC1323]ウィンドウサイズ> 64キロバイト
Increased Initial Window (sender) [RFC3390] CWND = min (4*MSS, max (2*MSS, 4380 bytes))
増加した初期ウィンドウ（送信者）[RFC3390] CWND =分（4 * MSS、MAX（2 * MSS、4380バイト））
Limited Transmit (sender) [RFC3042]
リミテッド送信（送信者）[RFC3042]
IP MTU larger than more applicable to 3G Default
IP MTUの3Gデフォルトにより適用より大きい
Path MTU Discovery (sender & intermediate routers) [RFC1191,RFC1981]
パスMTU探索（送信＆中間ルータ）[RFC1191、RFC1981]
Selective Acknowledgment option (SACK) [RFC2018] (sender & receiver)
選択的確認応答オプション（SACK）[RFC2018]（送信＆受信機）
Explicit Congestion Notification(ECN) [RFC3168] (sender, receiver & intermediate routers)
明示的輻輳通知（ECN）[RFC3168]（送信、受信および中間ルータ）
Timestamps Option (sender & receiver) [RFC1323, R.T.Braden's ID]
タイムスタンプオプション（送信者と受信者）[RFC1323、R.T.BradenのID]
Disabling RFC1144 TCP/IP Header Compression [RFC1144] (wireless host)
無効RFC1144 TCP / IPヘッダー圧縮[RFC1144]（ワイヤレスホスト）
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を実行するときに、エンドツーエンドのパフォーマンスを向上させることがあり、追加のメカニズムとパラメータの設定の概要を説明します。この記事の執筆時点でRFCを追跡すること以外RTOの初期値の議論から、それらのメカニズムとパラメータの設定は、どの規格の一部ではない、注意してください。そのため、彼らは一般的には、インターネットには推奨できません。
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性能のための他の機構は、リンクがある場合にローカルに再送信する過渡リンク停止中拡張TCP / IPヘッダ圧縮方式[29]、アクティブキュー管理RFC 2309 [28]、リンクレイヤでの再送方式[23]、及びキャッシング・パケットを含みます[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ヘッダ圧縮方式の欠点（RFC 1144 [40]、RFC 2507 [13]）は、彼らがハンドシェイクパケット（SYNのフィン）のヘッダを圧縮していないことを、彼らはTCPオプションフィールド（たとえばの適切な取り扱いを欠いていることです、SACKまたはタイムスタンプ）（）セクション4.8を参照してください。 RFC 3095 [12]まだこの問題に対処していないが、IETFは、タイムスタンプと選択的肯定応答としてTCPオプションのより良好な取り扱いを含む改善されたTCP / IPヘッダ圧縮スキームを開発しています。多くの短命の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.
アクティブキュー管理を実装するRFC 2309 [28]に概説されるように、いくつかの理由で魅力的です。 2.5G / 3Gネットワークのための1つの重要な利点は、それが（前のページのダウンロードが完了する前に「のページへのページからクリック」）ネットワークのキューに格納することができる潜在的に古いデータの量を最小限に抑えることです。 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ネットワークは、一般的に高遅延によって特徴づけされているので、に、不要なラウンドトリップタイムを回避することは特に魅力的です。これは、一般的にスマートフォンからウェブを閲覧から生じる短命、トランザクション（リクエスト/レスポンス・スタイル）TCPセッションのために特別に有益です。しかしながら、そのようなT / TCPのRFC 1644 [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 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.
スプリアスタイムアウト、パケットの再順序付け、およびパケット重複は、TCPのパフォーマンスを低下させる可能性があります。したがって、これらのイベントに対してTCPをより強固にすることが望ましいです。この問題に対する解決策が提案されている[30]、[35]、[41]、及びIETF内の標準化作業は、執筆時点で進行中です。これらのソリューションは、このようなイベントが検出された後の輻輳制御状態を元に戻すと、再送タイマと重複確認応答のしきい値を適応含まれています。無線ネットワークを介しTCPを実行するとき、無線アクセスリンクは、多くの場合、ハンドオーバおよびリソースプリエンプションを受ける可能性がある、またはモバイルトランスミッタが無線カバレッジホールを通って横断することができるので、このようなソリューションの配備は、特に有益であり得ます。このようなかく乱イベントは、簡単に保守的な再送タイマーにもかかわらず、スプリアスタイムアウトをトリガすることができます。また、いくつかの無線ネットワークのモビリティメカニズムは、パケットの重複が発生することがあります。
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の再送タイマを計算するためのアルゴリズムは、RFC 2988 [11]で指定されています。標準では、再送タイムアウト値（RTO）の初期設定は3秒未満であってはならないことを指定します。 2.5G / 3Gネットワーク間でTCPを実行している場合は、この値が低すぎる可能性があります。高い待ち時間に加えて、これらのネットワークは、大規模なパケット伝送遅延をもたらす約10 KB /秒という低いビットレートで実行されてもよいです。この場合、第1のデータセグメントのための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.
[11] RFC 2988の推奨事項のいくつかはオプションであり、すべてのTCP実装によって従いません。具体的には、いくつかのTCPスタックは以下1秒、及びRTOタイマの推奨再起動を実装していないいくつかの実装は、ACKが受信される（セクション5.3 [11（[11]のセクション2.4）の推奨値より最小RTOを可能にします]）。いくつかの実験[52]、[54]と比較して帯域幅振動の面では、（3秒も推奨される初期RTOと共に）1秒の推奨最小RTO値を使用するスプリアス再送回数を減少させることが示されています200または400ミリ秒の小さな最小RTO値を使用。さらに、ACKはACKを受信したときにRTOタイマを再起動しない実装よりもはるかに少ないスプリアス再送を経験を受信した再送タイマを再起動するTCPスタック。したがって、これを書いている時点で、それはRFC 2988のすべての推奨事項に従うことに3Gワイヤレスデータ伝送に使用されるTCP実装に好適と思われます。
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無線ネットワークでは、データは、空中及び無線アクセスネットワーク（RAN）とコアネットワークとの間のクリアテキストとして暗号文として送信されます。 IPセキュリティRFC 2401 [37]またはTLS RFC 2246 [36]は、エンドツーエンドのセキュリティのためにユーザ装置によって展開することができます。
This specification requires no IANA actions.
この仕様にはIANAのアクションを必要としません。
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)
マックス秦、株式会社エヌ・ティ・ティ・ドコモ（hata@mml.yrp.nttdocomo.co.jp）
Masahiro Hara, Fujitsu, 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社（Alan.Hameed@fnc.fujitsu.com）
Rodrigo Garces, Mobility Network Systems (rodrigo.garces@mobilitynetworks.com)
ロドリゴGarces、モビリティネットワークシステム（rodrigo.garces@mobilitynetworks.com）
Peter Ford, Microsoft (peterf@Exchange.Microsoft.com)
ピーター・フォード、マイクロソフト（peterf@Exchange.Microsoft.com）
Fergus Wills, Openwave (fergus.wills@openwave.com)
ファーガスウィルズ、オープンウェーブ（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)
Gorry Fairhurst（gorry@erg.abdn.ac.uk）
Mark Allman (mallman@grc.nasa.gov)
マーク・オールマン（mallman@grc.nasa.gov）
Aaron Falk (falk@ISI.EDU)
アーロンフォーク（falk@ISI.EDU）
[1] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[1]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[2] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[2]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、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の選択して承認オプション"、RFC 2018、1996年10月。
[4] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[4]オールマン、M.、フロイド、S.とC.ヤマウズラ、 "増加するTCPの初期ウィンドウ"、RFC 3390、2002年10月。
[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.、古城、M.およびV. Magret、 "低速リンクのエンドツーエンドのパフォーマンスへの影響"、BCP 48、RFC 3150、2001年7月。
[6] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[6]モーグル、J.およびS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[7] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
、RFC 1435、1993年3月[7]ノウルズ、S.、 "パスMTUディスカバリの経験からIESGアドバイス"。
[8] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[8]マッキャン、J.、デアリング、S.とJ.ムガール人、RFC 1981 "IPバージョン6のパスMTUディスカバリー"、1996年8月。
[9] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[9]ラマクリシュナン、K.、フロイド、S.及びD.黒、 "IPに明示的輻輳通知（ECN）の添加を"、RFC 3168、2001年9月。
[10] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[10]オールマン、M.、バラクリシュナン、H.とS.フロイド、 "株式会社トランスミットを使用して強化TCPの損失回復"、RFC 3042、2001年1月。
[11] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[11]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、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.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.とH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、ESP 「、および圧縮されていない、RFC 3095、2001年7月。
[13] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[13] Degermark、M.、Nordgren、B.及びS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[14] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, September 1981.
[14]ポステル、J.、 "伝送制御プロトコル - DARPAインターネットプログラムプロトコル仕様"、STD 7、RFC 793、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の変更"、RFC 2582、1999年4月。
[16] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[16]ボルマン、C.、 "PPPオーバーロバストヘッダ圧縮（ROHC）"、RFC 3241、2002年4月。
[17] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[17]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[18] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[18]デアリング、S.とR. Hindenと "インターネットプロトコル、バージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[19] Montenegro, G., Dawkins, S., Kojo, M., Magret, V. and N. Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[19]モンテネグロ、G.、ドーキンス、S.、古城、M.、Magret、V.およびN. Vaidya、 "細長いネットワーク"、RFC 2757、2000年1月。
[20] Third Generation Partnership Project, "RLC Protocol Specification (3G TS 25.322:)", 1999.
[20]第三世代パートナーシッププロジェクト、 "RLCプロトコル仕様（3G TS 25.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.フロイド、 "タホ、リノ、およびSACK 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.ウッド、BCP 62、RFC 3366、2002年8月 "リンク自動再送要求（ARQ）にデザイナーをリンクするためのアドバイス"。
[23] Karn, P., "Advice for Internet Subnetwork Designers", Work in Progress.
[23]カーン、P.、「インターネットサブネットワークデザイナーのためのアドバイス」が進行中で働いています。
[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.古城、 "エラーとのリンクのエンド・ツー・エンドのパフォーマンスへの影響"、BCP 50、RFC 3135、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拡張機能"、RFC 1644、1994年7月。
[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.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.とL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、RFC 2309、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.カッツ、 "アイフェルアルゴリズム：スプリアス再送に対する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-、2001年4月、<http://www.wapforum.com/what/technical.htm>。
[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ネットワークにおける明示的輻輳通知の性能評価（ECN）"、RFC 2884、2000年7月。
[33] NTT DoCoMo Technical Journal, "Special Issue on i-mode Service", October 1999.
[33] NTT DoCoMoテクニカル・ジャーナル、 "iモードサービス特集号"、1999年10月。
[34] NTT DoCoMo Technical Journal, "Special Article on IMT-2000 Services", September 2001.
[34] NTT DoCoMoテクニカル・ジャーナル、 "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のための選択的確認応答（SACK）オプションの拡張"、RFC 2883、2000年7月。
[36] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[36]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[37] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[37]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、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]デ・ビボ、M.、O.・デ・ビボ、G.、Koeneke、R.とG. Isern、 "TCP / IPおよびT / TCPに関連するインターネットの脆弱性"、ACMコンピュータコミュニケーションレビュー29（1）、1月1999。
[39] Third Generation Partnership Project, "RRC Protocol Specification (3GPP TS 25.331:)", September 2001.
[39]第三世代パートナーシッププロジェクト、 "RRCプロトコル仕様（3GPP TS 25.331 :)"、2001年9月。
[40] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[40]ジェーコブソン、V.、 "圧縮TCP /低速シリアルリンクのIPヘッダ"、RFC 1144、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.オールマン、 "パケットの順序変更にTCPはより強固な作りで"、ACMコンピュータコミュニケーションレビュー32（1）、2002年1月、<http://roland.grc.nasa.gov/~mallman > /papers/tcp-reorder-ccr.ps。
[42] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM 87, 1987.
[42]、ACM SIGCOMM 87、1987 "信頼性の高いトランスポートプロトコルでのラウンドトリップ時間の見積りを改善する" カーン、P.とC.パートリッジ、。
[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 SIGMETRICS 99、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ワイヤレスネットワークジャーナル集「無線リンク上での信頼性の高いフローのエンドツーエンドのパフォーマンスの最適化」。 8、番号2/3頁。289- 299、月 - 2002年5月。
[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] Gurtov、A.、ヘルシンキ大学、コンピュータサイエンス学部、出版物C、C-2001から53、2001年11月のシリーズ "遅延スパイクにロバストなTCPを作る"、<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.、Ostermann、 S.、スコット、K.とJ. Semke、 "衛星への継続的なTCPリサーチ関連"、RFC 2760、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.サンチェス、BCP 28、RFC 2488、1999年1月、 "標準的なメカニズムを使用してTCP上の衛星テレビの強化"。
[50] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M. Sooriyabandara, "TCP Performance Implications of Network Asymmetry", RFC 3449, December 2002.
[50]バラクリシュナン、H.、Padmanabhan、V.、Fairhurst、G.およびM. Sooriyabandara、 "ネットワーク非対称のTCPパフォーマンスへの影響"、RFC 3449、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アクセスネットワーク内のノード間のコンテキスト転送を実行した理由」、RFC 3374、2002年9月。
[52] Khafizov, F. and M. Yavuz, "Running TCP over IS-2000", Proc. of IEEE ICC, 2002.
[52] Khafizov、F.及びM.ヤウス、 "IS-2000上で動作するTCP"、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.ヤウス、 "IS-2000のCDMAネットワークにおけるRLPの解析モデル"、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]ヤウス、M.およびF. Khafizov、PROC "可変帯域幅を有する無線リンク上でTCP"。 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.
電気通信工業会、1995： - [56] TIA / EIA / IS-95改訂A、ワシントン「は、移動局デュアルモード広帯域用基地局互換性標準スペクトルセルラーシステムスプレッド」。
[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 / IS-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] Dahlman、E.、Beming、P.、Knutsson、J.、Ovesjo、F.、Perssonの、M.とC. Roobol、 "WCDMA - 将来のモバイルマルチメディア通信のための無線インタフェース"、IEEEトランス。車両用技術、巻上。 47、ありません。 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.およびV.パクソン、「推定に関するエンドツーエンドのネットワークパスのプロパティ」、ACM SIGCOMM 99、1999年9月。
[60] Gurtov, A. and R. Ludwig, "Responding to Spurious Timeouts in TCP", IEEE INFOCOM'03, March 2003.
[60] Gurtov、A.とR.ルートヴィヒ、IEEE INFOCOM'03、2003年3月 "TCPにおけるスプリアスタイムアウトへの対応"。
Hiroshi Inamura NTT DoCoMo, Inc. 3-5 Hikarinooka Yokosuka Shi, Kanagawa Ken 239-8536 Japan
ひろし いなむら んっｔ どこも、 いんｃ。 ３ー５ ひかりのおか よこすか し、 かながわ けん ２３９ー８５３６ じゃぱん
EMail: inamura@mml.yrp.nttdocomo.co.jp URI: http://www.nttdocomo.co.jp/
電子メール：URI 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
ガブリエルモンテネグロSun Microsystemsの研究所、ヨーロッパアベニュードゥヨーロッパZIRSTデMontbonnot 38334サンIsmier CEDEXフランス
EMail: gab@sun.com
メールアドレス：gab@sun.com
Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrath Germany
ライナールートヴィヒ・エリクソン研究エリクソンアリー1 52134 Herzogenrathのドイツ
EMail: Reiner.Ludwig@Ericsson.com
メールアドレス：Reiner.Ludwig@Ericsson.com
Andrei Gurtov Sonera P.O. Box 970, FIN-00051 Helsinki, Finland
アンドレイGurtov Soneraの私書箱私書箱970、FIN-00051ヘルシンキ、フィンランド
EMail: andrei.gurtov@sonera.com URI: http://www.cs.helsinki.fi/u/gurtov/
電子メール：andrei.gurtov@sonera.com URI：http://www.cs.helsinki.fi/u/gurtov/
Farid Khafizov Nortel Networks 2201 Lakeside Blvd Richardson, TX 75082, USA
ファリドKhafizov Nortel Networksの2201レイクサイドブルバード・リチャードソン、TX 75082、USA
EMail: faridk@nortelnetworks.com
メールアドレス：faridk@nortelnetworks.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。