[要約] 要約：RFC 3481は、第2世代（2.5G）および第3世代（3G）の無線ネットワーク上でのTCP通信に関するガイドラインを提供しています。 目的：このRFCの目的は、2.5Gおよび3Gネットワーク上でのTCPパフォーマンスの向上と、ネットワークの特性に適したTCP拡張機能の提案です。
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番目（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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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.
このドキュメントでは、TCPを最適化して適応するためのプロファイルについて説明し、2番目（2.5g）および3番目（3G）のワイヤレスネットワークを含むパスを処理するようにします。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.
第2世代のセルラーシステムは、一般に2Gと呼ばれます。2Gフェーズは、1990年代にデジタル音声エンコーディングがアナログシステム（1G）に取って代わったときに始まりました。2Gシステムは、周波数、コード、および時間分割の複数アクセスなど、さまざまな無線技術に基づいています。2Gシステムの例には、GSM（ヨーロッパ）、PDC（日本）、およびIS-95（米国）が含まれます。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標準トラックメカニズム（つまり、主に非wirelessシナリオであっても）です。さらに、このドキュメントは、2.5Gと3Gの両方のネットワークをカバーする1つの推奨事項を作成します。両方の世代のワイヤレステクノロジーは、TCPパフォーマンスと同様の課題を示すため（セクション2を参照）、1つの一般的なセットが必要です。
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フォーラム[25]（2002年6月現在のOpen Mobile Alliance [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-mode [33]は、日本の携帯電話に展開されているワイヤレスインターネットサービスです。I-Modeの新しいバージョンは、W-CDMAの実装であるFoma [34]で実行されます。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システムには、アップリンクで約64 kbps、ダウンリンクで384 kbpsのビットレートがあると予想されます。2.5gで約1〜5 kbの帯域幅遅延積（BDP）、3Gで8-50 kbの帯域幅遅延積（BDP）を考慮すると、2.5gリンクはLTNS（長い薄いネットワーク[19]）と3GリンクアプローチLFN（長い薄いネットワーク[19]）と見なすことができます。脂肪ネットワーク[2]、いくつかの衛星ネットワーク[48]によって例示されるように。したがって、関心のある読者は、RFC 2488で議論されている関連する潜在的に関連する問題を見つけるかもしれません[49]。優れたTCPパフォーマンスのために、LFNとLTNの両方が、優れたデータの十分な大きなウィンドウを維持する必要があります。LFNの場合、利用可能なネットワーク帯域幅を利用することは特に懸念されます。LTNSには、効率的な損失回復のために十分に大きなウィンドウが必要です。特に、ウィンドウが4つのセグメント未満である場合、高速再送信アルゴリズムはトリガーできません。これにより、再送信のタイムアウトを通じて長い回復が行われます。限られた送信アルゴリズムRFC 3042 [10]は、小さなウィンドウとの接続に対するタイムアウトの有害な影響を回避するのに役立ちます。それにもかかわらず、LFNとLTNの両方で損失回復のためのSack RFC 2018 [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].
このドキュメントは、LTNとLFNの両方に適した標準メカニズムのみ、および一般的なネットワークに適していることを推奨しています。ただし、セクション5で提案されている実験メカニズムは、LTN [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が送信速度をゆっくりと増加させるため、それを十分に活用できます。通常、高速から遅いセルに変更されると、自己融合プロパティのためにTCPによって適切に処理されます。ただし、この場合のRTTが突然増加すると、セクション2.7で説明されているように、偽のTCPタイムアウトが発生する可能性があります。さらに、高速セルで使用される大きなTCPウィンドウは、うっ血を引き起こし、ゆっくりとしたセルで過剰に増加する可能性があります。
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フィルタリングなどの技術を必要とせずにTCPによって容認できます[50]。したがって、このドキュメントには、このような非常に非対称ネットワーク向けの推奨事項は含まれていません。
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の低レベルの損失（非配信）を提供できます。ARQのためにIPパケットの損失率は低くなりますが、リンク層での回復は、計算された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].
展開の初期段階では、3Gシステムが高母集団エリアで「ホットスポット」テクノロジーとして使用され、2.5Gシステムは他の場所でより低い速度データサービスを提供します。これにより、進行中のTCP接続を維持しながら、モバイルユーザーが2.5Gと3Gのネットワークをローミングできる環境が作成されます。システム間のハンドオーバーは、高い遅延スパイクをトリガーする可能性が高く（セクション2.4）、データの損失をもたらす可能性があります。このドキュメントの範囲外であるコンテキスト転送のために追加の問題が発生しますが、シームレスなモビリティに対処するアクティビティのIETFの他の場所で対処されています[51]。
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].
限られたRFスペクトルを考えると、2.5G/3Gワイヤレスシステムの高いデータレートのニーズを満たすには、同時データユーザー間で動的なリソース共有が必要です。リソースの利用を最大化するために、さまざまなスケジューリングメカニズムを展開できます。複数のユーザーが大量のデータを同時に転送したい場合、スケジューラは各ユーザーにリソースを繰り返し割り当てて解釈する必要がある場合があります。定期的な割り当てと高速チャネルのリリースを帯域幅振動と呼びます。スループットを分解する因子として、偽の再送信などの帯域幅振動効果が他の場所で特定されました（[30]）。調査研究[52]、[54]があります。これは、場合によっては帯域幅の振動がスループットを減らす上で最も重要な要因になる可能性があることを示しています。固定されたTCPパラメーターの場合、達成可能なスループットはリソース割り当てのパターンに依存します。リソースの割り当てと脱アロケーションの頻度が十分に高い場合、スループットの劣化はありません。ただし、リソースの割り当て/脱アラケーションの頻度を増やすと、シグナル伝達が増加する可能性があるため、望ましくない場合があります。3Gワイヤレステクノロジーの標準は、帯域幅振動の悪影響と戦うために使用できるメカニズムを提供します。帯域幅振動の悪影響を回避するための最良のアプローチは、適切なワイヤレスサブネットワーク設計です[23]。
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とFECは[23]で説明されていますが、リンク層ARQのさらなる正当化については[22]、[44]で説明しています。
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つのタイムスロットダウンリンクと1つのアップリンクが割り当てられます。HSCSDは、高速サーキットスイッチのリンクを作成するユーザーに複数のタイムスロットを割り当てます。GPRSは、ユーザー間でラジオリソースを効率的に共有できるパケットスイッチテクノロジーに基づいています。いくつかの端子がタイムスロットを共有できます。GPRSネットワークは、GSMの更新されたベースステーションサブシステムをアクセスネットワークとして使用します。GPRSコアネットワークには、GPRSサポートノード（SGSN）およびGATEWAY 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).
International Telecommunication Union（ITU）は、IMT-2000 3Gモバイルコミュニケーション標準のグローバルテレコムシステムの1つとして、ワイドバンドコード部門マルチアクセス（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では、1〜12個のPDU（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は、「ステータスレポート」タイプの謝辞でCheckPoint 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]の用語に従って、完全な患者ではなく、高度または低存在のいずれかのために構成できる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の再送信は、LATENCYを導入し、JitterをIPフローに遅らせます。これが、輸送層が、384 kbpsの無線ベアラーに対して最大50 kbの比較的大きな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.
国際的なモバイル電気通信200000の傘下で提案されている3Gワイヤレスシステムの陸生無線インターフェイス標準の1つは、CDMA2000です[55]。1.25 MHzのシングルキャリアRF帯域幅を備えたマルチキャリアコードディビジョンマルチアクセス（CDMA）テクノロジーを採用しています。CDMA2000は、CDMAテクノロジーに基づく2G標準であるIS-95 [56]から進化しました。CDMA2000の最初のフェーズでは、単一のキャリアを使用しており、既存のCDMA（IS-95）ネットワークの音声容量を2倍にし、最大316.8 kbpsの常にオンにしたデータ送信速度をサポートするように設計されています。上記のように、これらの強化された機能はCDMA2000 1XRTTによって提供されます。2 Mbpsの3G速度は、CDMA2000 1X-EVによって提供されます。物理層では、標準では、5,10、20、40または80ミリ秒の時間枠で伝送が可能になります。さまざまな直交（WALSH）コードは、チャネル識別とより高いデータレートを達成するために使用されます。
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.
Radio Link Protocol Type 3（RLP）[57]は、CDMAデータサービスをサポートするためにCDMA2000トラフィックチャネルで使用されます。RLPはOctet Stream Transport Serviceを提供し、より高い層のフレーミングに気付いていません。いくつかの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は、1つ以上の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標準トラックメカニズムであり、一般的なインターネットで安全であると考えられています。ただし、システム管理者は、MTUサイズを増やし（セクション4.4）、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 kbに制限します。エンドツーエンドのBDPが64 kBを超えると予想される場合、ウィンドウスケールオプション[2]を使用してその制限を克服できます。デフォルトでは、多くのオペレーティングシステムが小さなTCPを使用して、16kb前後のバッファーを受信および送信します。したがって、64 kb未満の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つのセグメントの従来の初期ウィンドウ値は、接続の初期フェーズで不必要なアイドル時間を意味します。]。送信者は、最大4つのセグメントのより大きな初期ウィンドウを使用することでこれを回避できます（約4 kbを超えない）[4]。初期ウィンドウと関連測定の増加を伴う実験により、（1）このメカニズムを展開することが安全であることが示されています（すなわち、混雑の崩壊につながることはありません）。「データの価値（インターネット対応のモバイルワイヤレスデバイスなどのアプリケーションで一般的に見られる動作）。一方、大規模なデータ転送の場合、このメカニズムの効果は無視できます。
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))
min（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).
これにより、許可された初期ウィンドウが1つから2〜4つのセグメントから4つのセグメントから4つのセグメントを増やします（約4 kbを超えない）。
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]、限られた送信は、高速再送信をトリガーするために必要な3つの重複した謝辞を生成する可能性が低い小さな渋滞ウィンドウとのTCP接続の高速再送信/高速回復を拡張します[1]。送信者が以前に送信のためにキューにキューになった場合、限られた送信メカニズムは、送信者に到達する最初の2つの重複謝辞のそれぞれに応じて新しいデータセグメントを送信することを要求します。このメカニズムは、輻輳ウィンドウサイズが小さい場合、またはウィンドウ内の多数のセグメントが失われた場合に効果的です。これにより、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（最大転送単位）です。リンクレイヤーは、IPデータグラムをPDUにフラグメントする場合があります。たとえば、エラー率が高いリンクでは、リンク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]。したがって、デザイナーは一般に、より大きな値を選択することをお勧めします。これらは、IPv4 RFC 1191 [6]の場合は576バイトのデフォルトIP MTU値を超え、IPv6 [18]で1280バイトを超えている可能性があります。この推奨事項は3Gネットワークに適用されますが、2.5Gを超えるネットワークを超える操作は、RFC 3150の推奨に従って注意する必要があります[5]。
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.
Path MTU Discoveryを使用すると、送信者は、特定のルーティングパスの最大エンドツーエンドの伝送ユニット（IPフラグメンテーションなし）を決定できます。RFC 1191 [6]およびRFC 1981 [8]は、それぞれIPv4とIPv6のMTU発見手順を説明しています。これにより、TCP送信者は、小さなデフォルトのMTUを想定する代わりに、より大きなセグメントサイズ（IPレイヤーの断片化を引き起こすことなく）を使用することができます。2.5g/3Gを超えるTCP実装は、PATH MTU発見を実装する必要があります。Path MTU Discoveryでは、必要な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.
選択的承認オプション（SACK）、RFC 2018 [3]は、単一のTCPウィンドウ[24]で複数のTCPセグメントが失われた場合に効果的です。特に、エンドツーエンドのパスが大きなBDPと高いパケット損失率を持っている場合、単一のデータウィンドウで複数のセグメント損失の確率が増加します。そのような場合、SACKはTCP-TahoeおよびTCP-Renoを超えて堅牢性を提供します[21]。2.5g/3gを超えるTCPは、サックをサポートする必要があります。
In the absence of SACK feature, the TCP should use NewReno RFC 2582 [15].
SACK機能がない場合、TCPはNewReno RFC 2582 [15]を使用する必要があります。
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]により、CEビットでマークされたIPパケットを受信したときにECNエコーフラグを設定することにより、TCPレシーバーがネットワーク内の輻輳を通知することができます。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はデータのウィンドウごとに1つのRTTサンプルを収集します[14]、[17]。これにより、RTTが過小評価され、パケット伝送遅延がRTTを支配するパス上のスプリアスタイムアウトにつながる可能性があります。これは、RFC 2988 [11]で指定されているような保守的な再送信タイマーにもかかわらず、保持されます。大きなウィンドウとのTCP接続は、ネットワーク条件の変化に迅速に適応することにより、タイムスタンプで提供されるより頻繁なRTTサンプルの恩恵を受ける可能性があります[2]。ただし、RFC 2988タイマー[11]を備えたTCPSには、バックボーンインターネットパス[59]にはほとんどまたはまったく利点がないという経験的証拠がいくつかあります。TCPタイムスタンプを使用するオプションは、再送信セグメントをRTT測定に使用できるという利点があります。これは、カーンのアルゴリズム[17]、[11]によって禁止されています。さらに、TCPタイムスタンプオプションは、eifelアルゴリズム[30]を使用して、偽の再nsmitを検出するための基礎です。
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ごとに1回だけパスの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]の場合、オプションフィールドの変更は（たとえば、タイムスタンプやサックによって引き起こされる）フィールド全体を圧縮できません（ただし、TCP/IPヘッダー自体を圧縮可能にします）。さらに悪いことに、RFC 1144 [40]の場合、オプションフィールドのこのような変更は、TCP/IPヘッダー圧縮を完全に無効にします。これは、接続がTCPタイムスタンプオプションを使用する場合です。そのオプションフィールドは、データとACKパスの両方で使用され、その値は通常、パケットから次のパケットに変わります。IETFは現在、TCPオプションをより適切にサポートして、堅牢なTCP/IPヘッダー圧縮スキームを指定しています[29]。
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レシーバーは、チェックサムエラーのため、現在のウィンドウ内のすべての残りのパケットを破棄します。これは、コンプレッサーが転送されない最初の再送信を受信するまで続きます。
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は複数の拡張機能に取り組んでおり、堅牢なヘッダー圧縮（PPP上の堅牢なヘッダー圧縮の交渉、TCPオプションの圧縮など）[16]。
Items Comments
----------------------------------------------------------------
Appropriate Window Size (sender & receiver)
based on end-to-end BDP
Window Scale Option (sender & receiver) [RFC1323] Window size > 64KB
ウィンドウスケールオプション（送信者＆レシーバー）[RFC1323]ウィンドウサイズ> 64kb
Increased Initial Window (sender) [RFC3390] CWND = min (4*MSS, max (2*MSS, 4380 bytes))
初期ウィンドウ（送信者）[RFC3390] cwnd = min（4*mss、max（2*mss、4380バイト））の増加
Limited Transmit (sender) [RFC3042]
限定送信（送信者）[RFC3042]
IP MTU larger than more applicable to 3G Default
3Gのデフォルトに適用できるよりも大きいIP MTU
Path MTU Discovery (sender & intermediate routers) [RFC1191,RFC1981]
Path MTU Discovery（送信者および中級ルーター）[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's 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を実行するときにエンドツーエンドのパフォーマンスを向上させる可能性のある追加のメカニズムとパラメーター設定の概要を説明します。RTOの初期値の議論とは別に、これらのメカニズムとパラメーター設定は、この執筆時点でRFCを追跡する標準の一部ではないことに注意してください。したがって、インターネット全般に推奨することはできません。
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とFins）のヘッダーを圧縮せず、TCPオプションフィールドの適切な取り扱いがないことです（例えば、袋またはタイムスタンプ）（セクション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ネットワークのアクティブキュー管理のもう1つの重要な利点は、以下に概説するように、最初のデータセグメントのスプリアスタイムアウトのリスクを減らすことです。
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ネットワークは一般的に高い遅延によって特徴付けられるため、不必要な往復時間を回避することは特に魅力的です。これは、スマートフォンからWebを閲覧することから通常生じる短命のトランザクション（リクエスト/応答スタイル）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/sという低いビットレートで実行される可能性があり、パケット伝送の遅延が大きくなります。この場合、最初のデータセグメントのRTTは、3秒の初期TCP再送信タイマー設定を簡単に超える場合があります。これにより、そのセグメントのスプリアスタイムアウトが発生します。したがって、そのような状況では、TCPの最初のRTOを3秒を超える値に設定することをお勧めします。さらに、潜在的に大きなパケット送信の遅延により、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.
RFC 2988 [11]の推奨事項の一部はオプションであり、すべてのTCP実装が続くことはありません。具体的には、一部のTCPスタックでは、推奨値の1秒（[11]のセクション2.4）未満の最小RTOを許可し、ACKを受信したときにRTOタイマーの推奨再起動を実装していません（[11のセクション5.3）]）。いくつかの実験[52]、[54]は、帯域幅振動に直面して、推奨最小RTO値の1秒を使用して（3秒の推奨される初期RTOとともに）、スプリアスリトランミッションの数が減少することを示しています。200または400ミリ秒の小さな最小RTO値を使用します。さらに、ACKが受信されたときにRTOタイマーを再起動しない実装よりも、ACKを受け取ったときに再送信タイマーを再起動するTCPスタックを再発することを実装します。したがって、この執筆時点では、3Gワイヤレスデータ送信で使用されるTCP実装がRFC 2988のすべての推奨事項に準拠することが望ましいと思われます。
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)
Max Hata、NTT Docomo、Inc。（hat@mml.yrp.nttdocomo.co.jp）
Masahiro Hara, Fujitsu, Inc. (mhara@FLAB.FUJITSU.CO.JP)
富士通りの井田正義（mhara@flab.fujitsu.co.jp）
Joby James, Motorola, Inc. (joby@MIEL.MOT.COM)
Joby James、Motorola、Inc。（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)
Alan Hameed、Fujitsu FNC、Inc。（alan.hameed@fnc.fujitsu.com）
Rodrigo Garces, Mobility Network Systems (rodrigo.garces@mobilitynetworks.com)
Rodrigo Garces、モビリティネットワークシステム（rodrigo.garces@mobilitynetworks.com）
Peter Ford, Microsoft (peterf@Exchange.Microsoft.com)
Peter Ford、Microsoft（peterf@exchange.microsoft.com）
Fergus Wills, Openwave (fergus.wills@openwave.com)
Fergus Wills、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)
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] Allman、M.、Paxson、V。and W. Stevens、「TCP輻輳制御」、RFC 2581、1999年4月。
[2] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[2] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のためのTCP拡張」、RFC 1323、1992年5月。
[3] Mathis, M., Mahdavi, J., Floyd, S. and R. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[3] Mathis、M.、Mahdavi、J.、Floyd、S。、およびR. Romanow、「TCP Selective Auncoundective Options」、RFC 2018、1996年10月。
[4] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[4] Allman、M.、Floyd、S。、およびC. Partridge、「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] Dawkins、S.、Montenegro、G.、Kojo、M。、およびV. Magret、「スローリンクのエンドツーエンドのパフォーマンスへの影響」、BCP 48、RFC 3150、2001年7月。
[6] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[6] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[7] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[7] Knowles、S。、「Path MTU Discoveryの経験からのIESGアドバイス」、RFC 1435、1993年3月。
[8] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[8] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、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.、Floyd、S。and D. Black、「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] Allman、M.、Balakrishnan、H。およびS. Floyd、「限られた送信を使用したTCPの損失回復の強化」、RFC 3042、2001年1月。
[11] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[11] Paxson、V。およびM. Allman、「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] 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。、およびH. Zheng、 "堅牢なヘッダー圧縮（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. Pink、「IPヘッダー圧縮」、RFC 2507、1999年2月。
[14] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, September 1981.
[14] Postel、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] Floyd、S。およびT. Henderson、「TCPの高速回復アルゴリズムへのNewreno修正」、RFC 2582、1999年4月。
[16] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[16] Bormann、C。、「PPP上の堅牢なヘッダー圧縮（ROHC）」、RFC 3241、2002年4月。
[17] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[17] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[18] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[18] Deering、S。and 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] Montenegro、G.、Dawkins、S.、Kojo、M.、Magret、V。and N. Vaidya、「Long Thin Networks」、RFC 2757、2000年1月。
[20] Third Generation Partnership Project, "RLC Protocol Specification (3G TS 25.322:)", 1999.
[20] 第3世代パートナーシッププロジェクト、「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] Fall、K。およびS. Floyd、「Tahoe、Reno、およびSack TCPのシミュレーションベースの比較」、Computer Communication Review、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、「リンク自動リピートリクエスト（ARQ）でデザイナーをリンクするアドバイス」、BCP 62、RFC 3366、2002年8月。
[23] Karn, P., "Advice for Internet Subnetwork Designers", Work in Progress.
[23] Karn、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] Dawkins、S.、Montenegro、G.、Magret、V.、Vaidya、N。and M. Kojo、「エラーによるリンクのエンドツーエンドのパフォーマンスへの影響」、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] Open Mobile Alliance、「Open Mobile Alliance」、2002、<http://www.openmobilealliance.org/>。
[27] Braden, R., "T/TCP -- TCP Extensions for Transactions", RFC 1644, July 1994.
[27] Braden、R。、「T/TCP -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] 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、「インターネットでのキュー管理と混雑回避に関する推奨事項」、RFC 2309、1998年4月。
[29] IETF, "Robust Header Compression", 2001, <http://www.ietf.org/html.charters/rohc-charter.html>.
[29] IETF、「Robust Header Compression」、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] Ludwig、R。and R. H. Katz、「Eifelアルゴリズム：偽りの再送信に対して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月、<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] Hadi Salim、J。およびU. Ahmed、「IPネットワークにおける明示的な混雑通知（ECN）のパフォーマンス評価」、RFC 2884、2000年7月。
[33] NTT DoCoMo Technical Journal, "Special Issue on i-mode Service", October 1999.
[33] NTT Docomo Technical Journal、「I-Mode Serviceの特別号」、1999年10月。
[34] NTT DoCoMo Technical Journal, "Special Article on IMT-2000 Services", September 2001.
[34] NTT Docomo Technical Journal、「IMT-2000 Servicesに関する特別記事」、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] Floyd、S.、Mahdavi、J.、Mathis、M。、およびM. Podolsky、「TCPの選択的承認（SACK）オプションの拡張」、RFC 2883、2000年7月。
[36] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[36] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[37] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[37] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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] De Vivo、M.、O。DeVivo、G.、Koeneke、R。、およびG. Isern、「TCP/IPおよびT/TCPに関連するインターネットの脆弱性」、ACMコンピューター通信レビュー29（1）、1999年1月。
[39] Third Generation Partnership Project, "RRC Protocol Specification (3GPP TS 25.331:)", September 2001.
[39] 第3世代パートナーシッププロジェクト、「RRCプロトコル仕様（3GPP TS 25.331 :)」、2001年9月。
[40] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[40] Jacobson、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] Blanton、E。and M. Allman、「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] Karn、P。およびC. Partridge、「信頼できる輸送プロトコルにおける往復時間推定の改善」、ACM Sigcomm 87、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] Ludwig、R.、Rathonyi、B.、Konrad、A。、およびA. Joseph、「信頼できるワイヤレスリンク上の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] Ludwig、R.、Konrad、A.、Joseph、A。、およびR. Katz、「ワイヤレスリンクを介した信頼できるフローのエンドツーエンドパフォーマンスの最適化」、Kluwer/ACM Wireless Networks Journal Vol。8、Nos。2/3、pp。289-299、2002年3月 - 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。、「Delay Spikesに対してTCPを堅牢にする」、ヘルシンキ大学、コンピューターサイエンス学科、出版物シリーズC、C-2001-53、2001年11月、<http://www.cs.helsinki.fi/u/gurtov/papers/report01.html>。
[46] Stevens, W., "TCP/IP Illustrated, Volume 1; The Protocols", Addison Wesley, 1995.
[46] スティーブンス、W。、「TCP/IP Illustrated、Volume 1; The Protocols」、Addison Wesley、1995。
[47] Braden, R., "TCP Extensions for High Performance: An Update", Work in Progress.
[47] Braden、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] Allman、M.、Dawkins、S.、Glover、D.、Griner、J.、Tran、D.、Henderson、T.、Heidemann、J.、Touch、J.、Kruse、H.、Ostermann、S.、Scott、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] Allman、M.、Glover、D。、およびL. Sanchez、「標準メカニズムを使用した衛星チャネル上のTCPの強化」、BCP 28、RFC 2488、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パフォーマンスのネットワーク非対称性」、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] Kempf、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. Yavuz、「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. Yavuz、「IS-2000 CDMAネットワークにおけるRLPの分析モデル」、Proc。2002年9月、IEEE車両技術会議の。
[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。2002年9月、IEEE車両技術会議の。
[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/IS-95 Rev A、「モバイルステーション - デュアルモード広帯域スプレッドスペクトルセルラーシステムの基地ステーション互換性標準」、ワシントン：Telecommunication Industry Association、1995。
[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、「Spread Spectrum Systemsのデータサービスオプション：Radio Link Protocol Type 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 Trans。車両技術について、Vol。47、いいえ。4、pp。1105-1118、1998年11月。
[59] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", ACM SIGCOMM 99, September 1999.
[59] Allman、M。and V. Paxson、「エンドツーエンドのネットワークパスプロパティの推定について」、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. Ludwig、「TCPでのスプリアスタイムアウトへの応答」、IEEE Infocom'03、2003年3月。
Hiroshi Inamura NTT DoCoMo, Inc. 3-5 Hikarinooka Yokosuka Shi, Kanagawa Ken 239-8536 Japan
田村ntt docomo、Inc。3-5 hikarinooka yokosuka shi、kanagawa ken 239-8536日本
EMail: inamura@mml.yrp.nttdocomo.co.jp
URI: http://www.nttdocomo.co.jp/
Gabriel Montenegro Sun Microsystems Laboratories, Europe Avenue de l'Europe ZIRST de Montbonnot 38334 Saint Ismier CEDEX France
ガブリエルモンテネグロサンマイクロシステムズラボラトリーズ、ヨーロッパアベニューデルヨーロッパZirst de Montbonnot 38334 Saint Ismier Cedex France
EMail: gab@sun.com
Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrath Germany
Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrathドイツ
EMail: Reiner.Ludwig@Ericsson.com
Andrei Gurtov Sonera P.O. Box 970, FIN-00051 Helsinki, Finland
アンドレイ・ガルトフ・ソネラP.O.Box 970、Fin-00051 Helsinki、フィンランド
EMail: andrei.gurtov@sonera.com
URI: http://www.cs.helsinki.fi/u/gurtov/
Farid Khafizov Nortel Networks 2201 Lakeside Blvd Richardson, TX 75082, USA
Farid Khafizov Nortel Networks 2201 Lakeside Blvd Richardson、TX 75082、USA
EMail: faridk@nortelnetworks.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。