Network Working Group G. Montenegro
Request for Comments: 2757 Sun Microsystems, Inc.
Category: Informational S. Dawkins
Nortel Networks
M. Kojo
University of Helsinki
V. Magret
Alcatel
N. Vaidya
Texas A&M University
January 2000
Long Thin Networks
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
In view of the unpredictable and problematic nature of long thin networks (for example, wireless WANs), arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks.
最適化されたトランスポートに到達する長い薄いネットワーク（例えば、無線WAN）を、の予測できない、問題の性質の観点から困難な作業です。私たちは、今後の研究のアイテムと一緒に、既存の提案を検討しています。この概要に基づいて、我々はまた、長い薄いネットワークの実施のためのメカニズムをお勧めします。
Our goal is to identify a TCP that works for all users, including users of long thin networks. We started from the working recommendations of the IETF TCP Over Satellite Links (tcpsat) working group with this end in mind.
私たちの目標は、長い薄いネットワークのユーザを含むすべてのユーザーのために働くTCPを識別することです。我々は念頭に置いて、この端とIETF TCP以上の衛星リンク（tcpsat）ワーキンググループの作業勧告から始まりました。
We recognize that not every tcpsat recommendation will be required for long thin networks as well, and work toward a set of TCP recommendations that are 'benign' in environments that do not require them.
我々は、すべてのtcpsat勧告が同様に長く細いネットワークのために必要とされるわけではありませんことを認識し、それらを必要としない環境では「良性」であり、TCPの推奨のセットに努めます。
Table of Contents
目次
1 Introduction ................................................. 3
1.1 Network Architecture .................................... 5
1.2 Assumptions about the Radio Link ........................ 6
2 Should it be IP or Not? ..................................... 7
2.1 Underlying Network Error Characteristics ................ 7
2.2 Non-IP Alternatives ..................................... 8
2.2.1 WAP ................................................ 8
2.2.2 Deploying Non-IP Alternatives ...................... 9
2.3 IP-based Considerations ................................. 9
2.3.1 Choosing the MTU [Stevens94, RFC1144] .............. 9
2.3.2 Path MTU Discovery [RFC1191] ....................... 10
2.3.3 Non-TCP Proposals .................................. 10
3 The Case for TCP ............................................. 11
4 Candidate Optimizations ...................................... 12
4.1 TCP: Current Mechanisms ................................. 12
4.1.1 Slow Start and Congestion Avoidance ................ 12
4.1.2 Fast Retransmit and Fast Recovery .................. 12
4.2 Connection Setup with T/TCP [RFC1397, RFC1644] .......... 14
4.3 Slow Start Proposals .................................... 14
4.3.1 Larger Initial Window .............................. 14
4.3.2 Growing the Window during Slow Start ............... 15
4.3.2.1 ACK Counting .................................. 15
4.3.2.2 ACK-every-segment ............................. 16
4.3.3 Terminating Slow Start ............................. 17
4.3.4 Generating ACKs during Slow Start .................. 17
4.4 ACK Spacing ............................................. 17
4.5 Delayed Duplicate Acknowlegements ....................... 18
4.6 Selective Acknowledgements [RFC2018] .................... 18
4.7 Detecting Corruption Loss ............................... 19
4.7.1 Without Explicit Notification ...................... 19
4.7.2 With Explicit Notifications ........................ 20
4.8 Active Queue Management ................................. 21
4.9 Scheduling Algorithms ................................... 21
4.10 Split TCP and Performance-Enhancing Proxies (PEPs) ..... 22
4.10.1 Split TCP Approaches .............................. 23
4.10.2 Application Level Proxies ......................... 26
4.10.3 Snoop and its Derivatives ......................... 27
4.10.4 PEPs to handle Periods of Disconnection ........... 29
4.11 Header Compression Alternatives ........................ 30
4.12 Payload Compression .................................... 31
4.13 TCP Control Block Interdependence [Touch97] ............ 32
5 Summary of Recommended Optimizations ......................... 33
6 Conclusion ................................................... 35
7 Acknowledgements ............................................. 35
8 Security Considerations ...................................... 35
9 References ................................................... 36
Authors' Addresses ............................................. 44
Full Copyright Statement ....................................... 46
1 Introduction
1はじめに
Optimized wireless networking is one of the major hurdles that Mobile Computing must solve if it is to enable ubiquitous access to networking resources. However, current data networking protocols have been optimized primarily for wired networks. Wireless environments have very different characteristics in terms of latency, jitter, and error rate as compared to wired networks. Accordingly, traditional protocols are ill-suited to this medium.
最適化されたワイヤレスネットワークは、ネットワークリソースへのユビキタスなアクセスを可能にするためであれば、モバイルコンピューティングは、解決しなければならない大きなハードルの一つです。しかし、現在のデータ・ネットワーキング・プロトコルは、有線ネットワークのために主に最適化されています。無線環境では、有線ネットワークに比べて待ち時間、ジッター、エラーレートの点で非常に異なる特性を有します。したがって、従来のプロトコルは、この中には不向きです。
Mobile Wireless networks can be grouped in W-LANs (for example, 802.11 compliant networks) and W-WANs (for example, CDPD [CDPD], Ricochet, CDMA [CDMA], PHS, DoCoMo, GSM [GSM] to name a few). W-WANs present the most serious challenge, given that the length of the wireless link (expressed as the delay*bandwidth product) is typically 4 to 5 times as long as that of its W-LAN counterparts. For example, for an 802.11 network, assuming the delay (round-trip time) is about 3 ms. and the bandwidth is 1.5 Mbps, the delay*bandwidth product is 4500 bits. For a W-WAN such as Ricochet, a typical round-trip time may be around 500 ms. (the best is about 230 ms.), and the sustained bandwidth is about 24 Kbps. This yields a delay*bandwidth product roughly equal to 1.5 KB. In the near future, 3rd Generation wireless services will offer 384Kbps and more. Assuming a 200 ms round-trip, the delay*bandwidth product in this case is 76.8 Kbits (9.6 KB). This value is larger than the default 8KB buffer space used by many TCP implementations. This means that, whereas for W-LANs the default buffer space is enough, future W-WANs will operate inefficiently (that is, they will not be able to fill the pipe) unless they override the default value. A 3rd Generation wireless service offering 2 Mbps with 200-millisecond latency requires a 50 KB buffer.
モバイルワイヤレスネットワークは、いくつか例を挙げると（例えば、802.11準拠のネットワーク）W-LANでグループ化され、W-のWAN（例えば、CDPD [CDPD]、跳ね返る、CDMA [CDMA]、PHS、ドコモ、GSM [GSM]することができます）。 W-WANは（遅延*帯域幅積として表される）無線リンクの長さがあれば、そのW-LANの対応のものと典型的には4〜5倍であることを考えると、最も重大な挑戦を提示します。例えば、802.11ネットワークのために、遅延（往復時間）と仮定すると、約3秒です。帯域幅は1.5 Mbpsですと、遅延*帯域幅積は4500ビットです。例えば跳ね返るとしてW-WANのために、典型的なラウンドトリップ時間は約500ミリ秒であってもよいです。 （最良のは約230ミリ秒）、および持続帯域幅は約24 Kbpsです。これは1.5キロバイトとほぼ等しい遅延*帯域幅生成物が得られます。近い将来には、第3世代ワイヤレスサービスは384Kbpsの多くを提供します。 200ミリ秒の往復を仮定すると、この場合の遅延*帯域幅積は、76.8キロビット（9.6キロバイト）です。この値は、多くのTCP実装によって使用されるデフォルトの8KBのバッファ・スペースよりも大きくなっています。これは、W-LANのためのデフォルトのバッファスペースが十分であるのに対し、ということを意味し、W-WANの未来は、彼らは、デフォルト値を上書きしない限り（つまり、彼らはパイプを埋めることができなくなり、ある）非効率的に動作します。 200ミリ秒の待ち時間で2Mbpsの提供第3世代無線サービスは、50キロバイトのバッファを必要とします。
Most importantly, latency across a link adversely affects throughput. For example, [MSMO97] derives an upper bound on TCP throughput. Indeed, the resultant expression is inversely related to the round-trip time.
最も重要なのは、リンクを介してレイテンシは悪のスループットに影響を与えます。例えば、[MSMO97]は、TCPスループットの上限を導出します。確かに、結果として得られる式は往復時間に反比例の関係にあります。
The long latencies also push the limits (and commonly transgress them) for what is acceptable to users of interactive applications.
長い待ち時間も限界に挑戦（と一般的にそれらを犯す）対話型アプリケーションのユーザーに受け入れられるもののために。
As a quick glance to our list of references will reveal, there is a wealth of proposals that attempt to solve the wireless networking problem. In this document, we survey the different solutions available or under investigation, and issue the corresponding recommendations.
参照の私たちのリストに一目で明らかなように、無線ネットワークの問題を解決しようと提案の富があります。この文書では、我々は利用可能か調査中のさまざまなソリューションを調査し、対応する勧告を出します。
There is a large body of work on the subject of improving TCP performance over satellite links. The documents under development by the tcpsat working group of the IETF [AGS98, ADGGHOSSTT98] are very relevant. In both cases, it is essential to start by improving the characteristics of the medium by using forward error correction (FEC) at the link layer to reduce the BER (bit error rate) from values as high as 10-3 to 10-6 or better. This makes the BER manageable. Once in this realm, retransmission schemes like ARQ (automatic repeat request) may be used to bring it down even further. Notice that sometimes it may be desirable to forego ARQ because of the additional delay it implies. In particular, time sensitive traffic (video, audio) must be delivered within a certain time limit beyond which the data is obsolete. Exhaustive retransmissions in this case merely succeed in wasting time in order to deliver data that will be discarded once it arrives at its destination. This indicates the desirability of augmenting the protocol stack implementation on devices such that the upper protocol layers can inform the link and MAC layer when to avoid such costly retransmission schemes.
衛星リンク上のTCP性能を向上させることをテーマとした作品の大きな体があります。 IETF [AGS98、ADGGHOSSTT98]のtcpsatワーキンググループが開発中の文書は非常に関連しています。両方の場合において、10-3 10-6またはほど高い値からBER（ビットエラーレート）を低減するためにリンク層で前方誤り訂正（FEC）を使用して、媒体の特性を改善することにより開始することが不可欠ですより良いです。これは、BERが管理しやすくなります。一度、この分野では、ARQ（自動再送要求）のような再送信方式は、さらにそれをダウンさせるために使用することができます。時には原因で、それが意味するの追加遅延のARQを放棄することが望ましい場合があることに注意してください。具体的には、時間に敏感なトラフィック（ビデオ、オーディオ）データは廃止され、それを超える特定の制限時間内に送達されなければなりません。この場合、徹底的な再送信は、単にそれがその目的地に到着した後に廃棄されるデータを配信するために、時間を無駄にすることに成功します。これは、上位のプロトコル層は、高価な再送信スキームを回避するためのリンクとMAC層に通知することができるように、デバイス上のプロトコルスタックの実装を増強するのが望ましいことを示しています。
Networks that include satellite links are examples of "long fat networks" (LFNs or "elephants"). They are "long" networks because their round-trip time is quite high (for example, 0.5 sec and higher for geosynchronous satellites). Not all satellite links fall within the LFN regime. In particular, round-trip times in a low-earth orbiting (LEO) satellite network may be as little as a few milliseconds (and never extend beyond 160 to 200 ms). W-WANs share the "L" with LFNs. However, satellite networks are also "fat" in the sense that they may have high bandwidth. Satellite networks may often have a delay*bandwidth product above 64 KBytes, in which case they pose additional problems to TCP [TCPHP]. W-WANs do not generally exhibit this behavior. Accordingly, this document only deals with links that are "long thin pipes", and the networks that contain them: "long thin networks". We call these "LTNs".
衛星リンクを含むネットワークスは、「ロングファットネットワーク」（LFNsまたは「象」）の一例です。その往復時間（例えば、0.5秒、静止衛星に対してより高い）かなり高いので、彼らは「長い」ネットワークです。すべての衛星リンクがLFN政権内に入りません。低地球で、特に、往復時間周回（LEO）衛星ネットワークは、数ミリ秒だけ少なくすることができる（160〜200ミリ秒を超えて延びることはありません）。 W-WANはLFNsと "L" を共有しています。しかし、衛星ネットワークはまた、彼らは高い帯域幅を有することができるという意味で、「脂肪」です。衛星ネットワークは、多くの場合、彼らは[TCPHP] TCPへの付加的な問題を提起した場合には64キロバイト以上の遅延*帯域幅積を有していてもよいです。 W-WANは、一般的に、この動作を示しません。 「長い薄いネットワーク」：したがって、このドキュメントでは、「長い細いパイプ」、およびそれらを含むネットワークでリンクを扱っています。我々は、これらの「LTNs」と呼びます。
This document does not give an overview of the API used to access the underlying transport. We believe this is an orthogonal issue, even though some of the proposals below have been put forth assuming a given interface. It is possible, for example, to support the traditional socket semantics without fully relying on TCP/IP transport [MOWGLI].
この文書では、基礎となるトランスポートにアクセスするために使用されるAPIの概要を与えるものではありません。私たちは、以下の提案のいくつかは、指定されたインタフェースを想定し出すされているにもかかわらず、これは直交問題であると考えています。それは完全にTCP / IPトランスポート[MOWGLI]に頼ることなく、従来のソケットのセマンティクスをサポートするために、例えば、可能です。
Our focus is on the on-the-wire protocols. We try to include the most relevant ones and briefly (given that we provide the references needed for further study) mention their most salient points.
私たちの焦点は、オン・ワイヤープロトコルです。私たちは、彼らの最も顕著なポイントに言及（私たちはさらなる研究のために必要な参照を提供することを与えられた）最も関連性の高いものと簡単に含めるようにしてみてください。
One significant difference between LFNs and LTNs is that we assume the W-WAN link is the last hop to the end user. This allows us to assume that a single intermediate node sees all packets transferred between the wireless mobile device and the rest of the Internet. This is only one of the topologies considered by the TCP Satellite community.
LFNsとLTNsとの大きな違いの1つは、我々はW-WANリンクは、エンドユーザーへの最後のホップであると仮定していることです。これは、私たちは、単一の中間ノードが無線モバイルデバイスとインターネットの残りの部分との間で転送されるすべてのパケットを見ていると仮定することができます。これは、TCP衛星コミュニティによって考慮トポロジのうちの1つにすぎません。
Given our focus on mobile wireless applications, we only consider a very specific architecture that includes:
モバイルワイヤレスアプリケーションへの注力を考えると、我々は含まれて非常に特定のアーキテクチャを考慮してください。
- a wireless mobile device, connected via
- 無線モバイルデバイスを介して接続されます
- a wireless link (which may, in fact comprise several hops at the link layer), to
- 無線リンク（実際にはリンク層で、いくつかのホップを含むことができる）、に
- an intermediate node (sometimes referred to as a base station) connected via
- 中間ノードを介して接続される（時には基地局とも呼ばれます）
- a wireline link, which in turn interfaces with
- 有線リンク、順にインターフェイスと
- the landline Internet and millions of legacy servers and web sites.
- 固定電話、インターネットと従来のサーバーとWebサイトの何百万人。
Specifically, we are not as concerned with paths that include two wireless segments separated by a wired one. This may occur, for example, if one mobile device connects across its immediate wireless segment via an intermediate node to the Internet, and then via a second wireless segment to another mobile device. Quite often, mobile devices connect to a legacy server on the wired Internet.
具体的には、我々は、有線1によって分離された2つの無線セグメントを含む経路と同様に懸念はありません。つのモバイルデバイスは、インターネットへの中間ノードを介して、その直接の無線セグメントを横切って接続し、その後、別のモバイルデバイスへの第2無線区間を介し場合、これは、例えば、起こり得ます。かなり頻繁に、モバイルデバイスは、有線インターネット上のレガシーサーバーに接続します。
Typically, the endpoints of the wireless segment are the intermediate node and the mobile device. However, the latter may be a wireless router to a mobile network. This is also important and has applications in, for example, disaster recovery.
典型的には、無線区間の終点は、中間ノードとモバイルデバイスです。しかし、後者は、モバイルネットワークへの無線ルータであってもよいです。また、これは重要であり、例えば、災害復旧、中のアプリケーションを持っています。
Our target architecture has implications which concern the deployability of candidate solutions. In particular, an important requirement is that we cannot alter the networking stack on the legacy servers. It would be preferable to only change the networking stack at the intermediate node, although changing it at the mobile devices is certainly an option and perhaps a necessity.
私たちのターゲットアーキテクチャは、候補ソリューションの展開性に関係する意味を持っています。特に、重要な要件は、我々は従来のサーバー上のネットワークスタックを変更することはできませんということです。モバイルデバイスでそれを変更すると、確かにオプションおそらく必要であるが、唯一の中間ノードのネットワークスタックを変更することが好ましいです。
We envision mobile devices that can use the wireless medium very efficiently, but overcome some of its traditional constraints. That is, full mobility implies that the devices have the flexibility and agility to use whichever happens to be the best network connection available at any given point in time or space. Accordingly, devices could switch from a wired office LAN and hand over their ongoing connections to continue on, say, a wireless WAN. This type of agility also requires Mobile IP [RFC2002].
私たちは非常に効率的に無線媒体を使用していますが、その伝統的な制約の一部を克服することができるモバイルデバイスを想定しています。つまり、完全なモビリティは、デバイスが時間や空間上の任意の時点で入手可能な最善のネットワーク接続であることを起こるどちらを使用するための柔軟性と俊敏性を持っていることを意味します。したがって、デバイスは、たとえば、ワイヤレスWANを続行するために彼らの継続的な接続を介した有線オフィスLANと手から切り替えることができます。敏捷のこのタイプはまた、モバイルIP [RFC2002]を必要とします。
The system architecture described above assumes at most one wireless link (perhaps comprising more than one wireless hop). However, this is not enough to characterize a wireless link. Additional considerations are:
上記のシステムアーキテクチャは、多くても1つの無線リンクに（おそらく複数の無線ホップを含む）を前提としています。しかし、これは、無線リンクを特徴付けるのに十分ではありません。その他の考慮事項は以下のとおりです。
- What are the error characteristics of the wireless medium? The link may present a higher BER than a wireline network due to burst errors and disconnections. The techniques below usually do not address all the types of errors. Accordingly, a complete solution should combine the best of all the proposals. Nevertheless, in this document we are more concerned with (and give preference to solving) the most typical case: (1) higher BER due to random errors (which implies longer and more variable delays due to link-layer error corrections and retransmissions) rather than (2) an interruption in service due to a handoff or a disconnection. The latter are also important and we do include relevant proposals in this survey.
- 無線媒体の誤差特性は何ですか？リンクエラーと切断バーストによる有線ネットワークよりも高いBERを提示することができます。通常、以下の技術は、すべての種類のエラーに対処するものではありません。したがって、完全なソリューションは、すべての提案の最高を組み合わせる必要があります。それにも関わらず、このドキュメント我々が持つ、より懸念している（と解決を優先）最も典型的なケースでは：（1）高いBERによる（より長く、よりリンク層エラー訂正や再送信のために、可変遅延を意味する）ランダムエラーにむしろハンドオフや断線によるサービス（2）割り込みより。後者も重要であり、私たちは、この調査では、関連する提案を含んで行います。
- Is the wireless service datagram oriented, or is it a virtual circuit? Currently, switched virtual circuits are more common, but packet networks are starting to appear, for example, Metricom's Starmode [CB96], CDPD [CDPD] and General Packet Radio Service (GPRS) [GPRS],[BW97] in GSM.
- 無線サービスデータグラムが向いている、またはそれは仮想回線のですか？現在、仮想回路がより一般的であるスイッチが、パケットネットワークは、例えば、出現し始めている、MetricomののStarmode [CB96]、CDPD [CDPD]およびGSMにおける汎用パケット無線サービス（GPRS）[GPRS]、[BW97]。
- What kind of reliability does the link provide? Wireless services typically retransmit a packet (frame) until it has been acknowledged by the target. They may allow the user to turn off this behavior. For example, GSM allows RLP [RLP] (Radio Link Protocol) to be turned off. Metricom has a similar "lightweight" mode. In GSM RLP, a frame is retransmitted until the maximum number of retransmissions (protocol parameter) is reached. What happens when this limit is reached is determined by the telecom operator: the physical link connection is either disconnected or a link reset is enforced where the sequence numbers are resynchronized and the transmit and receive buffers are flushed resulting in lost data. Some wireless services, like CDMA IS95-RLP [CDMA, Karn93], limit the latency on the wireless link by retransmitting a frame only a couple of times. This decreases the residual frame error rate significantly, but does not provide fully reliable link service.
- リンクは、信頼性のどのような種類を提供していますか？それは、ターゲットによって確認されるまで、ワイヤレスサービスは、通常のパケット（フレーム）を再送信します。彼らは、ユーザーがこの動作をオフにすることを可能にします。たとえば、GSMは、RLP [RLP（無線リンクプロトコル）がオフされることを可能にします。 Metricom社は、同様の「軽量」モードがあります。再送の最大数（プロトコル・パラメータ）に到達するまで、GSM RLPにおいて、フレームが再送されます。達して、この制限はテレコムオペレータによって決定されたときに何が起こる：物理リンク接続が切断またはシーケンス番号を再同期化されるリンクリセットが実施され、送信のいずれかであり、バッファが失われたデータが得られるフラッシュされ受け取ります。 CDMA IS95-RLP [CDMA、Karn93]のようないくつかの無線サービスは、時代の夫婦のみのフレームを再送することにより、無線リンク上での待ち時間を制限します。これは、大幅に残留フレーム誤り率を減少するが、完全に信頼性の高いリンクサービスを提供していません。
- Does the mobile device transmit and receive at the same time? Doing so increases the cost of the electronics on the mobile device. Typically, this is not the case. We assume in this document that mobile devices do not transmit and receive simultaneously.
- モバイルデバイスの送信と同時に受信していますか？そうすることで、モバイルデバイス上の電子部品のコストを増加させます。一般的に、これはそうではありません。私たちは、モバイルデバイスが送信と同時に受信しません。この文書で前提としています。
- Does the mobile device directly address more than one peer on the wireless link? Packets to each different peer may traverse spatially distinct wireless paths. Accordingly, the path to each peer may exhibit very different characteristics. Quite commonly, the mobile device addresses only one peer (the intermediate node) at any given point in time. When this is not the case, techniques such as Channel-State Dependent Packet Scheduling come into play (see the section "Packet Scheduling" below).
- モバイルデバイスは、直接無線リンク上に複数のピアに対処していますか？それぞれ異なるピアにパケットが空間的に別個の無線経路を横断することができます。したがって、各ピアへのパスは非常に異なる特性を示すことができます。極めて一般的には、モバイルデバイスは、時間内の任意の所与の時点で唯一のピア（中間ノード）アドレス。そうでない場合には、このようなチャネルステート依存のパケットスケジューリングなどの技術が遊びに来る（以下「パケットスケジューリング」を参照してください）。
2 Should it be IP or Not?
2それはIPすべきかどうかを判断しますか？
The first decision is whether to use IP as the underlying network protocol or not. In particular, some data protocols evolved from wireless telephony are not always -- though at times they may be -- layered on top of IP [MOWGLI, WAP]. These proposals are based on the concept of proxies that provide adaptation services between the wireless and wireline segments.
最初の決定は、基礎となるネットワークプロトコルとしてかIPを使用するかどうかです。具体的には、いくつかのデータプロトコルは、無線電話から進化し、常にではない - 時には彼らはかもしれないが - IP [MOWGLI、WAP]の上に重ね。これらの提案は、無線と有線のセグメント間の適応サービスを提供するプロキシの概念に基づいています。
This is a reasonable model for mobile devices that always communicate through the proxy. However, we expect many wireless mobile devices to utilize wireline networks whenever they are available. This model closely follows current laptop usage patterns: devices typically utilize LANs, and only resort to dial-up access when "out of the office."
これは、常にプロキシを介して通信するモバイルデバイスのための合理的なモデルです。しかし、我々は、彼らが利用可能なときはいつでも、多くの無線モバイル機器は有線ネットワークを利用することを期待しています。このモデルは密接に現在のノートパソコンの使用パターンを、次のとおりです。デバイスは、通常のLANを利用し、唯一のダイヤルアップアクセスを訴えると、「オフィスの外。」
For these devices, an architecture that assumes IP is the best approach, because it will be required for communications that do not traverse the intermediate node (for example, upon reconnection to a W-LAN or a 10BaseT network at the office).
それは（W-LAN又はオフィスでの10BaseTネットワークに再接続の際に、例えば）の中間ノードを通過していない通信のために必要とされるため、これらのデバイスのために、IPを想定アーキテクチャは、最良のアプローチです。
Using IP as the underlying network protocol requires a certain (low) level of link robustness that is expected of wireless links.
基本的なネットワークプロトコルとしてIPを使用する無線リンクの期待されているリンクの堅牢性の特定の（低い）レベルを必要とします。
IP, and the protocols that are carried in IP packets, are protected end-to-end by checksums that are relatively weak [Stevens94, Paxson97] (and, in some cases, optional). For much of the Internet, these checksums are sufficient; in wireless environments, the error characteristics of the raw wireless link are much less robust than the rest of the end-to-end path. Hence for paths that include wireless links, exclusively relying on end-to-end mechanisms to detect and correct transmission errors is undesirable. These should be complemented by local link-level mechanisms. Otherwise, damaged IP packets are propagated through the network only to be discarded at the destination host. For example, intermediate routers are required to check the IP header checksum, but not the UDP or TCP checksums. Accordingly, when the payload of an IP packet is corrupted, this is not detected until the packet arrives at its ultimate destination.
IP、およびIPパケットで運ばれるプロトコルは、比較的弱いチェックサム[Stevens94、Paxson97]によりエンドツーエンドの保護された（そして、いくつかのケースでは、オプション）されています。インターネットの多くの場合、これらのチェックサムは十分です。無線環境では、生の無線リンクの誤差特性はそれほど強力なエンドツーエンドのパスの残りの部分よりもあります。したがって無線リンクを含むパスに対して、排他的に伝送エラーを検出し訂正するために、エンドツーエンドのメカニズムに依存することは望ましくありません。これらは、ローカルリンクレベルのメカニズムによって補完されるべきです。それ以外の場合は、損傷を受けたIPパケットは、宛先ホストで廃棄するネットワークを介して伝播されています。例えば、中間ルータは、IPヘッダのチェックサムを確認する必要はなく、UDPまたはTCPチェックサムれます。 IPパケットのペイロードが破損している場合、パケットがその最終的な目的地に到着するまで、したがって、これは検出されません。
A better approach is to use link-layer mechanisms such as FEC, retransmissions, and so on in order to improve the characteristics of the wireless link and present a much more reliable service to IP. This approach has been taken by CDPD, Ricochet and CDMA.
より良いアプローチは、無線リンクの特性を改善し、IPにはるかに信頼性の高いサービスを提供するためにようにリンク層のようなFECメカニズムとして、再送信、とを使用することです。このアプローチは、CDPD、跳ね返るとCDMAによって撮影されています。
This approach is roughly analogous to the successful deployment of Point-to-Point Protocol (PPP), with robust framing and 16-bit checksumming, on wireline networks as a replacement for the Serial Line Interface Protocol (SLIP), with only a single framing byte and no checksumming.
このアプローチは、単一のフレーミングと、シリアル・ライン・インタフェース・プロトコル（SLIP）の代替として、有線ネットワーク上で、ロバストフレーミングおよび16ビットのチェックサムとポイントツーポイントプロトコル（PPP）の展開を成功にほぼ類似していますバイトなしチェックサム。
[AGS98] recommends the use of FEC in satellite environments.
【AGS98】衛星環境におけるFECを使用することをお勧めします。
Notice that the link-layer could adapt its frame size to the prevalent BER. It would perform its own fragmentation and reassembly so that IP could still enjoy a large enough MTU size [LS98].
リンク層は、流行BERにそのフレームサイズを適応させることができることに注意してください。 IPがまだ十分に大きいMTUサイズ[LS98]を楽しむことができるように、それは、自身の断片化と再構築を実行することになります。
A common concern for using IP as a transport is the header overhead it implies. Typically, the underlying link-layer appears as PPP [RFC1661] to the IP layer above. This allows for header compression schemes [IPHC, IPHC-RTP, IPHC-PPP] which greatly alleviate the problem.
トランスポートとしてIPを使用するための共通の関心事は、それが意味するヘッダオーバヘッドです。典型的には、下層のリンク層は、上記IP層にPPP [RFC1661]として現れます。これは非常に問題を軽減するヘッダ圧縮方式[IPHC、IPHC-RTP、IPHC-PPP]が可能になります。
A number of non-IP alternatives aimed at wireless environments have been proposed. One representative proposal is discussed here.
ワイヤレス環境を目的とした非IP選択肢の数が提案されています。一つの代表的な提案が、ここで議論されています。
The Wireless Application Protocol (WAP) specifies an application framework and network protocols for wireless devices such as mobile telephones, pagers, and PDAs [WAP]. The architecture requires a proxy between the mobile device and the server. The WAP protocol stack is layered over a datagram transport service. Such a service is provided by most wireless networks; for example, IS-136, GSM SMS/USSD, and UDP in IP networks like CDPD and GSM GPRS. The core of the WAP protocols is a binary HTTP/1.1 protocol with additional features such as header caching between requests and a shared state between client and server.
ワイヤレスアプリケーションプロトコル（WAP）は、携帯電話、ページャ、PDAなどの無線デバイスのためのアプリケーション・フレームワークとネットワークプロトコル[WAP]を指定します。アーキテクチャは、モバイルデバイスとサーバー間のプロキシが必要です。 WAPプロトコルスタックは、データグラムの輸送サービスの上に積層されています。このようなサービスは、ほとんどのワイヤレスネットワークで提供されます。例えば、IS-136 CDPDおよびGSM GPRSなどのIPネットワークでは、GSM SMS / USSD、およびUDP。 WAPプロトコルのコアは、要求クライアントとサーバ間の共有状態との間でヘッダ・キャッシングなどの追加機能を持つバイナリHTTP / 1.1プロトコルです。
IP is such a fundamental element of the Internet that non-IP alternatives face substantial obstacles to deployment, because they do not exploit the IP infrastructure. Any non-IP alternative that is used to provide gatewayed access to the Internet must map between IP addresses and non-IP addresses, must terminate IP-level security at a gateway, and cannot use IP-oriented discovery protocols (Dynamic Host Configuration Protocol, Domain Name Services, Lightweight Directory Access Protocol, Service Location Protocol, etc.) without translation at a gateway.
彼らはIPインフラストラクチャを活用していないので、IPは、非IP選択肢が展開にかなりの障害に直面するインターネットのように基本的な要素です。ゲートウェイでIPレベルのセキュリティを終了する必要があり、IPアドレスおよび非IPアドレスの間でマッピングする必要があり、インターネットへのゲートウェイ処理のアクセスを提供するために使用され、そして（動的ホスト構成プロトコルをIP指向の発見プロトコルを使用することはできません任意の非IP代替、ゲートウェイで翻訳せずに、ドメインネームサービス、ライトウェイトディレクトリアクセスプロトコル、サービスロケーションプロトコルなど）。
A further complexity occurs when a device supports both wireless and wireline operation. If the device uses IP for wireless operation, uninterrupted operation when the device is connected to a wireline network is possible (using Mobile IP). If a non-IP alternative is used, this switchover is more difficult to accomplish.
デバイスが動作無線と有線の両方をサポートする場合、さらに複雑さが生じます。装置が無線動作のためのIPを使用している場合、デバイスが有線ネットワークに接続されている中断のない動作（モバイルIPを使用して）ことが可能です。非IPの代替を使用する場合、このスイッチオーバーが実現することはより困難です。
Non-IP alternatives face the burden of proof that IP is so ill-suited to a wireless environment that it is not a viable technology.
非IPの選択肢は、IPは、それが実行可能な技術ではないことを無線環境に非常に不向きであることを立証責任に直面しています。
Given its worldwide deployment, IP is an obvious choice for the underlying network technology. Optimizations implemented at this level benefit traditional Internet application protocols as well as new ones layered on top of IP or UDP.
その世界的な展開を考えると、IPは、基盤となるネットワーク技術のための当然の選択です。このレベルで実装の最適化は、従来のインターネットアプリケーションプロトコルだけでなく、IPやUDPの上に重ね、新しいものに利益をもたらします。
In slow networks, the time required to transmit the largest possible packet may be considerable. Interactive response time should not exceed the well-known human factors limit of 100 to 200 ms. This should be considered the maximum time budget to (1) send a packet and (2) obtain a response. In most networking stack implementations, (1) is highly dependent on the maximum transmission unit (MTU). In the worst case, a small packet from an interactive application may have to wait for a large packet from a bulk transfer application before being sent. Hence, a good rule of thumb is to choose an MTU such that its transmission time is less than (or not much larger than) 200 ms.
遅いネットワークでは、最大可能パケットを送信するために必要な時間は相当であってもよいです。対話式応答時間は100〜200ミリ秒のよく知られた人的要因の制限を超えてはなりません。これは、（1）パケットを送信し、（2）応答を得るために最大の時間予算を考慮すべきです。ほとんどのネットワークスタックの実装では、（1）最大伝送単位（MTU）に大きく依存します。最悪の場合には、対話型アプリケーションからの小さなパケットが送信される前にバルク転送アプリケーションからの大きなパケットを待つ必要があります。したがって、親指の良いルールは、送信時間が200ミリ秒（またはあまりより大きい）よりも小さくなるようにMTUを選択することです。
Of course, compression and type-of-service queuing (whereby interactive data packets are given a higher priority) may alleviate this problem. In particular, the latter may reduce the average wait time to about half the MTU's transmission time.
もちろん、圧縮及びサービス型キューイングは（インタラクティブデータパケットがより高い優先順位が与えられることにより）この問題を軽減することができます。特に、後者は約半分のMTUの送信時間に平均待機時間を減らすことができます。
Path MTU discovery benefits any protocol built on top of IP. It allows a sender to determine what the maximum end-to-end transmission unit is to a given destination. Without Path MTU discovery, the default IPv4 MTU size is 576. The benefits of using a larger MTU are:
パスMTUディスカバリは、IPの上に構築された任意のプロトコルに利益をもたらします。これは、送信者が最大のエンド・ツー・エンド伝送部は、所定の宛先であるかを決定することを可能にします。パスMTUディスカバリがなければ、デフォルトのIPv4 MTUサイズは、より大きなMTUを使用することの利点は576されています。
- Smaller ratio of header overhead to data
- データのヘッダーオーバーヘッドの小さい割合
- Allows TCP to grow its congestion window faster, since it increases in units of segments.
- それは、セグメント単位で増加するため、TCPが速く、その輻輳ウィンドウを成長させることができます。
Of course, for a given BER, a larger MTU has a correspondingly larger probability of error within any given segment. The BER may be reduced using lower level techniques like FEC and link-layer retransmissions. The issue is that now delays may become a problem due to the additional retransmissions, and the fact that packet transmission time increases with a larger MTU.
もちろん、所定のBERのために、より大きなMTUは、任意の所与のセグメント内のエラーの対応する大きな可能性を有しています。 BERは、FECとリンク層再送信のような低レベルの技術を用いて低減することができます。問題は、今の遅れが原因追加の再送信、およびパケットの送信時間は、より大きなMTUとともに増加するという事実のために問題になるかもしれないということです。
Recommendation: Path MTU discovery is recommended. [AGS98] already recommends its use in satellite environments.
推奨事項：パスMTUディスカバリをお勧めします。 [AGS98]すでにサテライト環境での使用を推奨しています。
Other proposals assume an underlying IP datagram service, and implement an optimized transport either directly on top of IP [NETBLT] or on top of UDP [MNCP]. Not relying on TCP is a bold move, given the wealth of experience and research related to it. It could be argued that the Internet has not collapsed because its main protocol, TCP, is very careful in how it uses the network, and generally treats it as a black box assuming all packet losses are due to congestion and prudently backing off. This avoids further congestion.
他の提案は、基礎となるIPデータグラムサービスを想定し、直接[MNCP] [NETBLT] IPの上またはUDPの上に最適化されたトランスポートを実装します。 TCPに頼らないのは、それに関連する経験と研究の富を考えると、大胆な動きです。その主要なプロトコル、TCPは、それがネットワークを使用し、一般的に、すべてのパケットロスが輻輳によるものであり、慎重にバックオフ仮定ブラックボックスとしてそれをどのように扱うかで非常に慎重であるため、インターネットは崩壊していないと主張することができます。これはさらに混雑を避けることができます。
However, in the wireless medium, packet losses may also be due to corruption due to high BER, fading, and so on. Here, the right approach is to try harder, instead of backing off. Alternative transport protocols are:
しかし、無線媒体では、パケットロスはまた、その上高いBER、フェージング、およびに破損に起因する可能性があります。ここでは、正しいアプローチではなく、バックオフのため、難しくしようとすることです。代替トランスポートプロトコルは、以下のとおりです。
- NETBLT [NETBLT, RFC1986, RFC1030]
- NETBLT [NETBLT、RFC1986、RFC1030]
- MNCP [MNCP]
- MNCP [MNCP]
- ESRO [RFC2188]
- ISRO [RFC 2188]
- RDP [RFC908, RFC1151]
- RDP [RFC908、RFC1151]
- VMTP [VMTP]
- VMTP [VMTP]
3 The Case for TCP
TCPのための3ケース
This is one of the most hotly debated issues in the wireless arena. Here are some arguments against it:
これは、ワイヤレス分野で最も熱く議論課題の一つです。ここではそれに対するいくつかの引数は次のとおりです。
- It is generally recognized that TCP does not perform well in the presence of significant levels of non-congestion loss. TCP detractors argue that the wireless medium is one such case, and that it is hard enough to fix TCP. They argue that it is easier to start from scratch.
- 一般的にTCPは、非渋滞損失の有意なレベルの存在下ではうまく行っていないことが認識されています。 TCPの中傷は、無線媒体は、1つのそのようなケースであり、TCPを修正するのに十分なハードであることを主張します。彼らはゼロからスタートすることが容易であると主張しています。
- TCP has too much header overhead.
- TCPは、あまりにも多くのヘッダのオーバーヘッドを持っています。
- By the time the mechanisms are in place to fix it, TCP is very heavy, and ill-suited for use by lightweight, portable devices.
- メカニズムはそれを修正するために整備されている時点で、TCPは非常に重く、軽量、ポータブルデバイスで使用するため不適当です。
and here are some in support of TCP:
そして、ここでいくつかは、TCPのサポートにあります。
- It is preferable to continue using the same protocol that the rest of the Internet uses for compatibility reasons. Any extensions specific to the wireless link may be negotiated.
- インターネットの残りの部分は、互換性の理由のために使用するのと同じプロトコルを使用し続けることが好ましいです。無線リンクに固有の拡張が交渉されることがあります。
- Legacy mechanisms may be reused (for example three-way handshake).
- レガシーメカニズムは、（例えばスリーウェイハンドシェイク）再利用することができます。
- Link-layer FEC and ARQ can reduce the BER such that any losses TCP does see are, in fact, caused by congestion (or a sustained interruption of link connectivity). Modern W-WAN technologies do this (CDPD, US-TDMA, CDMA, GSM), thus improving TCP throughput.
- リンク層FEC及びARQは、TCPが見るん任意の損失が、実際には、輻輳（またはリンク接続の持続的な中断）によって引き起こされるようなBERを減らすことができます。現代のW-WAN技術は、このようにTCPのスループットを向上させること、この（CDPD、US-TDMA、CDMA、GSM）を行います。
- Handoffs among different technologies are made possible by Mobile IP [RFC2002], but only if the same protocols, namely TCP/IP, are used throughout.
- 異なる技術間ハンドオフは、モバイルIP [RFC2002]によって可能となるが、唯一のと同じプロトコル、すなわちTCP / IP場合、全体を通して使用されます。
- Given TCP's wealth of research and experience, alternative protocols are relatively immature, and the full implications of their widespread deployment not clearly understood.
- 研究と経験のTCPの富を考えると、代替のプロトコルは比較的未熟であり、その広範な展開の完全な意味が明確に理解されていません。
Overall, we feel that the performance of TCP over long-thin networks can be improved significantly. Mechanisms to do so are discussed in the next sections.
全体的に、我々は長い薄いネットワーク上のTCPのパフォーマンスが大幅に向上させることができると感じています。そうするメカニズムは、次のセクションで説明されています。
4 Candidate Optimizations
4つの候補の最適化
There is a large volume of work on the subject of optimizing TCP for operation over wireless media. Even though satellite networks generally fall in the LFN regime, our current LTN focus has much to benefit from it. For example, the work of the TCP-over-Satellite working group of the IETF has been extremely helpful in preparing this section [AGS98, ADGGHOSSTT98].
無線メディア上での動作のためのTCPの最適化をテーマとした作品の大ボリュームがあります。衛星ネットワークは、一般的にLFN政権に落ちていても、私たちの現在のLTNの焦点は、その恩恵を受けることがたくさんあります。例えば、IETFのTCPオーバー衛星ワーキンググループの作業は、このセクション[AGS98、ADGGHOSSTT98]を製造するのに非常に役立っています。
A TCP sender adapts its use of bandwidth based on feedback from the receiver. The high latency characteristic of LTNs implies that TCP's adaptation is correspondingly slower than on networks with shorter delays. Similarly, delayed ACKs exacerbate the perceived latency on the link. Given that TCP grows its congestion window in units of segments, small MTUs may slow adaptation even further.
TCPの送信側は受信側からのフィードバックに基づいて、帯域幅の使用を適応させます。 LTNsの高遅延特性は、TCPの適応が短い遅延のネットワークよりも相応に遅くなることを意味します。同様に、遅延ACKは、リンク上の知覚の待ち時間を悪化させます。 TCPは、セグメント単位での輻輳ウィンドウを成長することを考えると、小型のMTUはさらに適応を遅くします。
Slow Start and Congestion Avoidance [RFC2581] are essential the Internet's stability. However there are two reasons why the wireless medium adversely affects them:
スロースタートと輻輳回避[RFC2581]インターネットの安定に不可欠です。しかし、無線媒体が悪それらに影響を与える理由は2つあります。
- Whenever TCP's retransmission timer expires, the sender assumes that the network is congested and invokes slow start. This is why it is important to minimize the losses caused by corruption, leaving only those caused by congestion (as expected by TCP).
- TCPの再送タイマが満了したときはいつでも、送信者は、ネットワークが混雑していることを前提とスロースタートを起動します。 （TCPが期待するよう）輻輳によるもののみを残し、腐敗による損失を最小限に抑えることが重要である理由です。
- The sender increases its window based on the number of ACKs received. Their rate of arrival, of course, is dependent on the RTT (round-trip-time) between sender and receiver, which implies long ramp-up times in high latency links like LTNs. The dependency lasts until the pipe is filled.
- 送信者は、受信したACKの数に基づいて、そのウィンドウを増加させます。到着の彼らの割合は、当然のことながら、LTNsのような高遅延リンクで長いランプアップ時間を意味し、送信者と受信者間のRTT（ラウンドトリップ時間）、に依存しています。パイプが満たされるまで、依存関係が続きます。
- During slow start, the sender increases its window in units of segments. This is why it is important to use an appropriately large MTU which, in turn, requires requires link layers with low loss.
- スロースタート時に、送信者は、セグメントの単位で、そのウィンドウを増加させます。順番に、低損失のリンク層を必要とし必要と適切に大きなMTUを使用することが重要である理由です。
When a TCP sender receives several duplicate ACKs, fast retransmit [RFC2581] allows it to infer that a segment was lost. The sender retransmits what it considers to be this lost segment without waiting for the full timeout, thus saving time.
TCPの送信者は、いくつかの重複ACKを受信すると、高速再送[RFC2581]は、それはセグメントが失われたことを推測することができます。送信者は、それがこのように時間を節約し、完全なタイムアウトを待たずにセグメントを失ったことを考えるもの再送します。
After a fast retransmit, a sender invokes the fast recovery [RFC2581] algorithm. Fast recovery allows the sender to transmit at half its previous rate (regulating the growth of its window based on congestion avoidance), rather than having to begin a slow start. This also saves time.
高速再送後、送信者は高速回復[RFC2581]アルゴリズムを呼び出します。高速回復は、送信者がかなり遅いスタートを開始するより、（輻輳回避に基づいてそのウィンドウの成長を調節する）の半分は前のレートで送信することができます。また、これは時間を節約できます。
In general, TCP can increase its window beyond the delay-bandwidth product. However, in LTN links the congestion window may remain rather small, less than four segments, for long periods of time due to any of the following reasons:
一般的に、TCPは遅延と帯域幅の積を超えてそのウィンドウを増やすことができます。しかし、LTNに輻輳ウィンドウは、次のいずれかの理由に起因する長期間、以下4つのセグメントかなり小さいままであるリンク。
1. Typical "file size" to be transferred over a connection is relatively small (Web requests, Web document objects, email messages, files, etc.) In particular, users of LTNs are not very willing to carry out large transfers as the response time is so long.
接続を介して転送される1.典型的な「ファイルサイズ」は、比較的小さい（Web要求、Webドキュメントオブジェクト、電子メールメッセージ、ファイル、など）。特に、LTNsのユーザーが応答として大規模な転送を行うことは非常に喜んではありません時間はとても長いです。
2. If the link has high BER, the congestion window tends to stay small
2.リンクが高いBERを持っている場合は、輻輳ウィンドウは、小さな滞在する傾向があります
3. When an LTN is combined with a highly congested wireline Internet path, congestion losses on the Internet have the same effect as 2.
LTNが非常に混雑有線インターネット経路と組み合わされる場合3.、インターネット上の混雑の損失は2と同様の効果を有します。
4. Commonly, ISPs/operators configure only a small number of buffers (even as few as for 3 packets) per user in their dial-up routers
4.一般に、ISPは/オペレータは、そのダイヤルアップルータにユーザごとのバッファ（3つのパケット用としてもわずか）のほんの数を設定します
5. Often small socket buffers are recommended with LTNs in order to prevent the RTO from inflating and to diminish the amount of packets with competing traffic.
5.多くの場合、小さなソケットバッファを膨らまからRTOを防ぐために、トラフィックを競合してパケットの量を低減するためにLTNsで推奨されています。
A small window effectively prevents the sender from taking advantage of Fast Retransmits. Moreover, efficient recovery from multiple losses within a single window requires adoption of new proposals (NewReno [RFC2582]). In addition, on slow paths with no packet reordering waiting for three duplicate ACKs to arrive postpones retransmission unnecessarily.
小さなウィンドウが効果的に高速再送信を利用することから、送信者を防ぐことができます。また、単一のウィンドウ内の複数の損失からの効率的な回復が新たな提案の採用を必要とする（NewRenoの[RFC2582]）。また、何のパケットは3つの重複ACKが不必要に延期再送を到着するのを待っている並べ替えないと遅いパスで。
Recommendation: Implement Fast Retransmit and Fast Recovery at this time. This is a widely-implemented optimization and is currently at Proposed Standard level. [AGS98] recommends implementation of Fast Retransmit/Fast Recovery in satellite environments. NewReno [RFC2582] apparently does help a sender better handle partial ACKs and multiple losses in a single window, but at this point is not recommended due to its experimental nature. Instead, SACK [RFC2018] is the preferred mechanism.
推奨事項：この時点では、高速再送と高速リカバリを実装します。これは、広く実装され、最適化され、現在では標準的なレベルを提案しています。 [AGS98]サテライト環境での高速再送/高速回復の実装を推奨しています。 NewRenoの[RFC2582]は明らかに、送信者がより良い1つのウィンドウで部分的ACKおよび複数の損失を扱う助けるんが、この時点では、その実験的な性質のために推奨されません。代わりに、SACK [RFC2018]は、好ましい機構です。
TCP engages in a "three-way handshake" whenever a new connection is set up. Data transfer is only possible after this phase has completed successfully. T/TCP allows data to be exchanged in parallel with the connection set up, saving valuable time for short transactions on long-latency networks.
TCPは、新しい接続が設定されるたびに、「3ウェイハンドシェイク」に取り組んでいます。このフェーズが正常に完了した後のデータ転送のみ可能です。 T / TCPは、長い待ち時間のネットワーク上で短いトランザクションのための貴重な時間を節約し、データを設定し、接続と並列に交換することを可能にします。
Recommendation: T/TCP is not recommended, for these reasons:
推奨：T / TCPはこれらの理由のために、推奨されません。
- It is an Experimental RFC.
- それは実験的なRFCです。
- It is not widely deployed, and it has to be deployed at both ends of a connection.
- それは広く展開され、それは、接続の両端で配備されなければならないれます。
- Security concerns have been raised that T/TCP is more vulnerable to address-spoofing attacks than TCP itself.
- セキュリティ上の懸念は、T / TCPはTCP自体よりも攻撃スプーフィング対処するより脆弱であることを提起されています。
- At least some of the benefits of T/TCP (eliminating three-way handshake on subsequent query-response transactions, for instance) are also available with persistent connections on HTTP/1.1, which is more widely deployed.
- T / TCPの利点の少なくともいくつか（例えば、後続の照会 - 応答トランザクションにスリーウェイハンドシェイクを排除する）は、より広く展開されているHTTP / 1.1で永続的な接続と利用可能です。
[ADGGHOSSTT98] does not have a recommendation on T/TCP in satellite environments.
[ADGGHOSSTT98]サテライト環境でのT / TCP上の勧告を持っていません。
Because slow start dominates the network response seen by interactive users at the beginning of a TCP connection, a number of proposals have been made to modify or eliminate slow start in long latency environments.
スロースタートは、TCPコネクションの開始時に会話型ユーザから見たネットワーク応答を支配しているため、多数の提案は、長い待ち時間環境でスロースタートを変更または除去するために行われています。
Stability of the Internet is paramount, so these proposals must demonstrate that they will not adversely affect Internet congestion levels in significant ways.
インターネットの安定性が最も重要であるので、これらの提案は、彼らが悪の重要な方法で、インターネットの混雑レベルに影響を与えないことを証明しなければなりません。
Traditional slow start, with an initial window of one segment, is a time-consuming bandwidth adaptation procedure over LTNs. Studies on an initial window larger than one segment [RFC2414, AHO98] resulted in the TCP standard supporting a maximum value of 2 [RFC2581]. Higher values are still experimental in nature.
従来のスロースタートは、1つのセグメントの初期ウィンドウで、LTNsオーバー時間のかかる帯域幅の適応手順です。初期画面1つのより大きいセグメント[RFC2414、AHO98]に関する研究2 [RFC2581]の最大値をサポートするTCP規格をもたらしました。値が高いほど、自然の中で、まだ実験的です。
In simulations with an increased initial window of three packets [RFC2415], this proposal does not contribute significantly to packet drop rates, and it has the added benefit of improving initial response times when the peer device delays acknowledgements during slow start (see next proposal).
3個のパケット[RFC2415]の増加最初のウィンドウでのシミュレーションでは、この提案は、パケットのドロップ率に大きく寄与していない、そしてそれは、ピアデバイスはスロースタート時の確認応答を遅らせる時の初期応答時間を改善するという利点もあります（次の提案を参照してください） 。
[RFC2416] addresses situations where the initial window exceeds the number of buffers available to TCP and indicates that this situation is no different from the case where the congestion window grows beyond the number of buffers available.
[RFC2416]は、最初のウィンドウはTCPで使用可能なバッファの数を超えると、この状況は、輻輳ウィンドウが使用可能なバッファの数を超えて成長する場合と変わらないことを示している状況に対応しています。
[RFC2581] now allows an initial congestion window of two segments. A larger initial window, perhaps as many as four segments, might be allowed in the future in environments where this significantly improves performance (LFNs and LTNs).
[RFC2581]は今や二つのセグメントの最初の輻輳ウィンドウを可能にします。大きい初期ウィンドウは、おそらくのような多くの4つのセグメントとして、これはかなりの性能（LFNsとLTNs）を向上させる環境で、将来的に許容されるかもしれません。
Recommendation: Implement this on devices now. The research on this optimization indicates that 3 segments is a safe initial setting, and is centering on choosing between 2, 3, and 4. For now, use 2 (following RFC2581), which at least allows clients running query-response applications to get an initial ACK from unmodified servers without waiting for a typical delayed ACK timeout of 200 milliseconds, and saves two round-trips. An initial window of 3 [RFC2415] looks promising and may be adopted in the future pending further research and experience.
勧告：今のデバイスでこれを実装します。この最適化の研究は3つのセグメントが安全初期設定で、3、2の間の選択を中心にして、今のところ4、（RFC2581以下）2を使用し、少なくともクエリ応答アプリケーションを実行しているクライアントが取得することができたことを示しています最初の200ミリ秒の典型的な遅延ACKタイムアウトを待たずにそのままサーバからのACK、および2つのラウンドトリップを保存します。 3 [RFC2415]の最初のウィンドウが有望に見えるし、さらなる研究と経験保留将来的に採用することができます。
The sender increases its window based on the flow of ACKs coming back from the receiver. Particularly during slow start, this flow is very important. A couple of the proposals that have been studied are (1) ACK counting and (2) ACK-every-segment.
送信側は受信側から戻ってくるACKの流れに基づいて、そのウィンドウを増加させます。特に、スロースタート時に、この流れは非常に重要です。研究されている提案のカップルは、（1）ACK計数及び（2）ACK-あらゆるセグメントです。
The main idea behind ACK counting is:
ACKカウントの背後にある主な考え方は次のとおりです。
- Make each ACK count to its fullest by growing the window based on the data being acknowledged (byte counting) instead of the number of ACKs (ACK counting). This has been shown to cause bursts which lead to congestion. [Allman98] shows that Limited Byte Counting (LBC), in which the window growth is limited to 2 segments, does not lead to as much burstiness, and offers some performance gains.
- 各ACKが代わりにACKの数（ACKカウント）の（バイトカウント）が確認されたデータに基づいて、ウィンドウを成長させることによって最大限にカウントしてください。これは、渋滞につながるバーストを引き起こすことが示されています。 【Allman98]ウィンドウの成長は、2つのセグメントに制限されている限りバースト性につながらない、といくつかのパフォーマンスの向上を提供する、限定バイトは（LBC）をカウントすることを示しています。
Recommendation: Unlimited byte counting is not recommended. Van Jacobson cautions against byte counting [TCPSATMIN] because it leads to burstiness, and recommends ACK spacing [ACKSPACING] instead.
推奨事項：無制限のバイトカウントは推奨されません。ヴァンヤコブソンは、それがバースト性につながるので、[TCPSATMIN]バイトカウントに対して警告し、代わりに[ACKSPACING] ACK間隔を推奨しています。
ACK spacing requires ACKs to consistently pass through a single ACK-spacing router. This requirement works well for W-WAN environments if the ACK-spacing router is also the intermediate node.
ACK間隔は一貫して、単一のACK間隔のルータを通過するようにACKを必要とします。 ACK間隔のルータは、中間ノードである場合、この要件は、W-WAN環境に適しています。
Limited byte counting warrants further investigation before we can recommend this proposal, but it shows promise.
限定バイトカウントは、我々はこの提案をお勧めすることができます前に、さらに調査を保証しますが、約束を示しています。
The main idea behind ACK-every-segment is:
ACK-すべてのセグメントの背後にある主要な考え方は次のとおりです。
- Keep a constant stream of ACKs coming back by turning off delayed ACKs [RFC1122] during slow start. ACK-every-segment must be limited to slow start, in order to avoid penalizing asymmetric-bandwidth configurations. For instance, a low bandwidth link carrying acknowledgements back to the sender, hinders the growth of the congestion window, even if the link toward the client has a greater bandwidth [BPK99].
- スロースタート時に遅延ACK [RFC1122]をオフにすることによって戻ってくるACKの一定の流れを維持。 ACK-すべてのセグメントは、非対称帯域幅の設定を不利避けるために、開始を遅らせるために制限しなければなりません。例えば、送信者に確認応答を運ぶ低帯域幅リンクは、クライアントに向けてリンクが大きな帯域幅[BPK99]を持っている場合でも、輻輳ウィンドウの成長を妨げます。
Even though simulations confirm its promise (it allows receivers to receive the second segment from unmodified senders without waiting for a typical delayed ACK timeout of 200 milliseconds), for this technique to be practical the receiver must acknowledge every segment only when the sender is in slow start. Continuing to do so when the sender is in congestion avoidance may have adverse effects on the mobile device's battery consumption and on traffic in the network.
シミュレーションは、その約束を確認するにもかかわらず、送信者が低速である場合にのみ、受信機は、すべてのセグメントを承認する必要があり実用的であることが、この技術のために、（それは受信機が200ミリ秒の典型的な遅延ACKタイムアウトを待たずに修飾されていない送信者からの第二のセグメントを受信することを可能にします）開始。送信者は輻輳回避のときにそうするように続けると、モバイルデバイスのバッテリ消費で、ネットワーク内のトラフィックに悪影響を与える可能性があり。
This violates a SHOULD in [RFC2581]: delayed acknowledgements SHOULD be used by a TCP receiver.
これは[RFC2581]でSHOULDに違反：遅延確認応答は、TCPレシーバによって使用されるべきです。
"Disabling Delayed ACKs During Slow Start" is technically unimplementable, as the receiver has no way of knowing when the sender crosses ssthresh (the "slow start threshold") and begins using the congestion avoidance algorithm. If receivers follow recommendations for increased initial windows, disabling delayed ACKs during an increased initial window would open the TCP window more rapidly without doubling ACK traffic in general. However, this scheme might double ACK traffic if most connections remain in slow-start.
受信機は、送信者がSSTHRESH（「スロースタート閾値」）を超えたときを知る方法がないと輻輳回避アルゴリズムを使用し始めると「スロースタート時に遅延ACKを無効にする」、技術的unimplementableあります。受信機が増加した初期ウィンドウの推奨事項に従っている場合、増加した初期ウィンドウの間に遅延ACKを無効にすると、一般的にACKのトラフィックを倍増することなく、より迅速にTCPウィンドウを開きます。ほとんどの接続が遅いスタートに残っている場合は、この方式は、ACKトラフィックを倍増することがあります。
Recommendation: ACK only the first segment on a new connection with no delay.
勧告：ACK遅延なしで新しい接続でのみ最初のセグメント。
New mechanisms [ADGGHOSSTT98] are being proposed to improve TCP's adaptive properties such that the available bandwidth is better utilized while reducing the possibility of congesting the network. This results in the closing of the congestion window to 1 segment (which precludes fast retransmit), and the subsequent slow start phase.
新しいメカニズムは、[ADGGHOSSTT98】ネットワークの輻輳の可能性を低減しながら、利用可能な帯域幅をよりよく利用されるようにTCPの適応特性を改善するために提案されています。これは、1つのセグメント（高速再送信を排除）、およびその後のスロースタートフェーズに輻輳ウィンドウの閉鎖をもたらします。
Theoretically, an optimum value for slow-start threshold (ssthresh) allows connection bandwidth utilization to ramp up as aggressively as possible without "overshoot" (using so much bandwidth that packets are lost and congestion avoidance procedures are invoked).
理論的には、スロースタートしきい値（SSTHRESH）の最適値は、接続の帯域幅の使用率が（パケットが失われ、輻輳回避手順が呼び出されるので、多くの帯域幅を使用して）「オーバーシュート」なしとして積極的に可能な限り立ち上げることができます。
Recommendation: Estimating the slow start threshold is not recommended. Although this would be helpful if we knew how to do it, rough consensus on the tcp-impl and tcp-sat mailing lists is that in non-trivial operational networks there is no reliable method to probe during TCP startup and estimate the bandwidth available.
勧告：スロースタートしきい値を推定することは推奨されません。我々はそれを行う方法を知っていたならば、これは参考になるが、TCP-IMPLおよびTCP-土メーリングリスト上の荒いコンセンサスが非自明な運用ネットワークでTCPの起動時に精査し、利用可能な帯域幅を推定するための信頼できる方法がないことです。
Mitigations that inject additional ACKs (whether "ACK-first-segment" or "ACK-every-segment-during-slow-start") beyond what today's conformant TCPs inject are only applicable during the slow-start phases of a connection. After an initial exchange, the connection usually completes slow-start, so TCPs only inject additional ACKs when (1) the connection is closed, and a new connection is opened, or (2) the TCPs handle idle connection restart correctly by performing slow start.
今日の準拠のTCPは、注射ものを超えて、追加のACK（「ACK-最初のセグメント」か「ACK-すべてのセグメント・中・スロースタート」）を注入緩和策は、接続のスロースタートフェーズでのみ適用されます。 （1）接続が閉じているときのTCPが唯一の追加ACKを注入して、新しい接続が開かれ、または（2）のTCPはスロースタートを実行することによって、アイドル状態の接続の再起動を正しく扱えるように、最初の交換の後、接続は通常、スロースタートを完了します。
Item (1) is typical when using HTTP/1.0, in which each request-response transaction requires a new connection. Persistent connections in HTTP/1.1 help in maintaining a connection in congestion avoidance instead of constantly reverting to slow-start. Because of this, these optimizations which are only enabled during slow-start do not get as much of a chance to act. Item (2), of course, is independent of HTTP version.
各要求 - 応答トランザクションが新しい接続を要求するHTTP / 1.0を使用する場合項目（1）一般的です。代わりに、常に開始を遅らせるために元に戻すの輻輳回避で接続を維持する上でHTTP / 1.1ヘルプの持続的な接続。このため、唯一のスロースタート時に有効になっているこれらの最適化は、行動する機会をできるだけ多く得ることはありません。項目（2）は、当然のことながら、HTTPのバージョンとは無関係です。
During slow start, the sender responds to the incoming ACK stream by transmitting N+1 segments for each ACK, where N is the number of new segments acknowledged by the incoming ACK. This results in data being sent at twice the speed at which it can be processed by the network. Accordingly, queues will form, and due to insufficient buffering at the bottleneck router, packets may get dropped before the link's capacity is full.
スロースタート時に、送信者はN着信ACKによって承認新しいセグメント数、各ACKのためのN + 1セグメントを送信することにより、着信ACKストリームに応答します。これは、ネットワークによって処理可能な2倍の速度で送信されたデータになります。したがって、キューが形成され、リンクの容量がいっぱいになる前に、ボトルネックルータでの不十分なバッファリングのために、パケットが廃棄されるかもしれません。
Spacing out the ACKs effectively controls the rate at which the sender will transmit into the network, and may result in little or no queueing at the bottleneck router [ACKSPACING]. Furthermore, ack spacing reduces the size of the bursts.
効果的にACKを行う間隔は、送信者がネットワークに送信し、ボトルネックルータ[ACKSPACING]でほとんどまたは全くキューイングを生じ得る速度を制御します。さらに、ACK間隔は、バーストのサイズを縮小します。
Recommendation: No recommendation at this time. Continue monitoring research in this area.
推奨事項：この時点で勧告なし。この分野での研究を監視し続けます。
As was mentioned above, link-layer retransmissions may decrease the BER enough that congestion accounts for most of packet losses; still, nothing can be done about interruptions due to handoffs, moving beyond wireless coverage, etc. In this scenario, it is imperative to prevent interaction between link-layer retransmission and TCP retransmission as these layers duplicate each other's efforts. In such an environment it may make sense to delay TCP's efforts so as to give the link-layer a chance to recover. With this in mind, the Delayed Dupacks [MV97, Vaidya99] scheme selectively delays duplicate acknowledgements at the receiver. It is preferable to allow a local mechanism to resolve a local problem, instead of invoking TCP's end-to-end mechanism and incurring the associated costs, both in terms of wasted bandwidth and in terms of its effect on TCP's window behavior.
以上述べたように、リンク層の再送信は、パケット損失の大部分のためにその輻輳アカウントに十分なBERを減少させることができます。まだ、何もこのシナリオでなど、無線カバレッジを超えて移動し、ハンドオフのために中断については行われないことができ、これらの層が互いの努力を複製するようリンク層の再送とTCP再送との間の相互作用を防止することが不可欠です。このような環境では、リンク層に回復する機会を得られるようにTCPの努力を遅らせるために意味をなさないことがあります。これを念頭において、遅延Dupacks [MV97、Vaidya99]スキームは、選択受信機で重複確認応答を遅らせます。無駄な帯域幅の面でとTCPのウィンドウの動作に及ぼす影響の両方の観点から、地元のメカニズムではなく、関連するコストをTCPのエンドツーエンドのメカニズムを呼び出すと被るの、地元の問題を解決することを可能にすることが好ましいです。
The Delayed Dupacks scheme can be used despite IP encryption since the intermediate node does not need to examine the TCP headers.
中間ノードは、TCPヘッダを調べる必要がありませんので、遅延Dupacks方式は、IPの暗号化にもかかわらず使用することができます。
Currently, it is not well understood how long the receiver should delay the duplicate acknowledgments. In particular, the impact of wireless medium access control (MAC) protocol on the choice of delay parameter needs to be studied. The MAC protocol may affect the ability to choose the appropriate delay (either statically or dynamically). In general, significant variabilities in link-level retransmission times can have an adverse impact on the performance of the Delayed Dupacks scheme. Furthermore, as discussed later in section 4.10.3, Delayed Dupacks and some other schemes (such as Snoop [SNOOP]) are only beneficial in certain types of network links.
現在のところ、うまく受信機が重複確認応答を遅らせる必要がありますどのくらい理解されていません。具体的には、遅延パラメータの選択に無線媒体アクセス制御（MAC）プロトコルの影響を検討する必要があります。 MACプロトコルは、適切な遅延（静的または動的）を選択する能力に影響を与える可能性があります。一般的には、リンクレベルの再送回数の大幅な変動性は、遅延Dupacksスキームのパフォーマンスに悪影響を及ぼす可能性があります。後のセクション4.10.3に論じたようにまた、遅延Dupacksと（例えば、スヌープ[スヌープ]のような）いくつかの他の方式は、ネットワークリンクの特定のタイプにのみ有益です。
Recommendation: Delaying duplicate acknowledgements may be useful in specific network topologies, but a general recommendation requires further research and experience.
勧告：重複確認応答を遅らせることは、特定のネットワークトポロジに有用であることが、一般的な勧告はさらなる研究と経験を必要とする場合があります。
SACK may not be useful in many LTNs, according to Section 1.1 of [TCPHP]. In particular, SACK is more useful in the LFN regime, especially if large windows are being used, because there is a considerable probability of multiple segment losses per window. In the LTN regime, TCP windows are much smaller, and burst errors must be much longer in duration in order to damage multiple segments.
SACKは[TCPHP]のセクション1.1によると、多くのLTNsにおいて有用ではないかもしれません。ウィンドウごとに複数のセグメント損失のかなりの可能性があるため、特に、SACKは、大きな窓が使用されている場合は特に、LFNレジームにおいてより有用です。 LTN政権では、TCPウィンドウは非常に小さく、そしてエラーは複数のセグメントを損傷するために、はるかに長い期間である必要がありますバースト。
Accordingly, the complexity of SACK may not be justifiable, unless there is a high probability of burst errors and congestion on the wireless link. A desire for compatibility with TCP recommendations for non-LTN environments may dictate LTN support for SACK anyway.
無線リンク上での高バースト誤りの確率及び輻輳がある場合を除きしたがって、SACKの複雑さは、正当ではないかもしれません。非LTN環境のためのTCPの推奨との互換性のための欲求はとにかくSACKのためのLTNサポートを指示することができます。
[AGS98] recommends use of SACK with Large TCP Windows in satellite environments, and notes that this implies support for PAWS (Protection Against Wrapped Sequence space) and RTTM (Round Trip Time Measurement) as well.
[AGS98]サテライト環境での大規模なTCPのWindowsでSACKを使用することを推奨しています、これは、同様PAWSのサポート（包まれた配列スペースに対する保護）とRTTM（往復時間測定）を意味することを指摘しています。
Berkeley's SNOOP protocol research [SNOOP] indicates that SACK does improve throughput for SNOOP when multiple segments are lost per window [BPSK96]. SACK allows SNOOP to recover from multi-segment losses in one round-trip. In this case, the mobile device needs to implement some form of selective acknowledgements. If SACK is not used, TCP may enter congestion avoidance as the time needed to retransmit the lost segments may be greater than the retransmission timer.
バークレーのSNOOPプロトコル研究[SNOOP]は、複数のセグメントが[BPSK96]ウィンドウごとに失われたときにSACKがSNOOPのスループットを向上させないことを示しています。 SACKはSNOOPが1往復でマルチセグメント損失から回復することができます。この場合、モバイルデバイスは、選択的確認応答のいくつかのフォームを実装する必要があります。 SACKを使用しない場合は、失われたセグメントを再送するために必要な時間は、再送タイマよりも大きくすることができるよう、TCPは輻輳回避を入力することもできます。
Recommendation: Implement SACK now for compatibility with other TCPs and improved performance with SNOOP.
推奨事項：他のTCPとSNOOPとパフォーマンスを向上させるとの互換性のために今SACKを実装します。
In the absence of explicit notification from the network, some researchers have suggested statistical methods for congestion avoidance [Jain89, WC91, VEGAS]. A natural extension of these heuristics would enable a sender to distinguish between losses caused by congestion and other causes. The research results on the reliability of sender-based heuristics is unfavorable [BV97, BV98]. [BV98a] reports better results in constrained environments using packet inter-arrival times measured at the receiver, but highly-variable delay - of the type encountered in wireless environments during intercell handoff - confounds these heuristics.
ネットワークからの明示的な通知がない場合には、一部の研究者は、輻輳回避のための統計的手法[Jain89、WC91、VEGAS]を示唆しています。これらのヒューリスティックの自然な拡張は、渋滞や他の原因による損失を区別するために、送信者を可能にします。センダベースのヒューリスティックの信頼性に関する研究結果不利[BV97、BV98]です。 【BV98a受信機で測定されたパケット間到着時間を使用してレポート制約のある環境で良好な結果が、高度に可変遅延 - セル間のハンドオフの間の無線環境に遭遇するタイプの - これらのヒューリスティックを混乱させる。
Recommendation: No recommendation at this time - continue to monitor research results.
推奨事項：この時点で勧告なし - 研究成果を監視し続けます。
With explicit notification from the network it is possible to determine when a loss is due to congestion. Several proposals along these lines include:
ネットワークからの明示的な通知で、損失が輻輳によるものである場合を決定することが可能です。これらの線に沿っていくつかの提案は次のとおりです。
- Explicit Loss Notification (ELN) [BPSK96]
- 明示的な喪失通知（ELN）BPSK96]
- Explicit Bad State Notification (EBSN) [BBKVP96]
- 明示的な悪い状態通知（EBSN）[BBKVP96]
- Explicit Loss Notification to the Receiver (ELNR), and Explicit Delayed Dupack Activation Notification (EDDAN) (notifications to mobile receiver) [MV97]
- レシーバ（ELNR）、および明示的な遅延のdupack起動通知（EDDAN）（移動受信機への通知）への明示的な喪失通知[MV97]
- Explicit Congestion Notification (ECN) [ECN]
- 明示的輻輳通知（ECN）[ECN]
Of these proposals, Explicit Congestion Notification (ECN) seems closest to deployment on the Internet, and will provide some benefit for TCP connections on long thin networks (as well as for all other TCP connections).
これらの提案のうち、明示的輻輳通知（ECN）は、インターネット上の展開に最も近いと思われる、と長い薄いネットワーク上のTCP接続のためのいくつかの利点（だけでなく、他のすべてのTCP接続）を提供します。
Recommendation: No recommendation at this time. Schemes like ELNR and EDDAN [MV97], in which the only systems that need to be modified are the intermediate node and the mobile device, are slated for adoption pending further research. However, this solution has some limitations. Since the intermediate node must have access to the TCP headers, the IP payload must not be encrypted.
推奨事項：この時点で勧告なし。変更する必要がある唯一のシステムは、中間ノードとモバイルデバイスである、ELNRとEDDAN [MV97]、のようなスキームは、さらなる研究を保留中の採用が予定されています。しかし、この解決策はいくつかの制限があります。中間ノードは、TCPヘッダへのアクセス権を持っている必要がありますので、IPペイロードは暗号化されてはなりません。
ECN uses the TOS byte in the IP header to carry congestion information (ECN-capable and Congestion-encountered). This byte is not encrypted in IPSEC, so ECN can be used on TCP connections that are encrypted using IPSEC.
ECNは、渋滞情報（ECN-可能と輻輳に遭遇する）搬送するIPヘッダ内のTOSバイトを使用します。このバイトはIPSECで暗号化されていないため、ECNはIPSECを使用して暗号化されているTCP接続に使用することができます。
Recommendation: Implement ECN. In spite of this, mechanisms for explicit corruption notification are still relevant and should be tracked.
推奨事項：ECNを実装します。これにもかかわらず、明示的な破損通知のメカニズムは、まだ関連して、追跡されるべきです。
Note: ECN provides useful information to avoid deteriorating further a bad situation, but has some limitations for wireless applications. Absence of packets marked with ECN should not be interpreted by ECN-capable TCP connections as a green light for aggressive retransmissions. On the contrary, during periods of extreme network congestion routers may drop packets marked with explicit notification because their buffers are exhausted - exactly the wrong time for a host to begin retransmitting aggressively.
注意：ECNはさらに悪い状況を悪化を避けるために有用な情報を提供していますが、ワイヤレス・アプリケーションのためのいくつかの制限があります。 ECNでマークされたパケットの不在は、積極的な再送信のための緑の光としてECN対応のTCPコネクションによって解釈されるべきものではありません。そのバッファが枯渇しているので、逆に、極端なネットワークの輻輳ルータの期間中に明示的な通知でマークされたパケットをドロップすること - 積極的に再送信を開始するホストのために、正確に間違った時間を。
As has been pointed out above, TCP responds to congestion by closing down the window and invoking slow start. Long-delay networks take a particularly long time to recover from this condition. Accordingly, it is imperative to avoid congestion in LTNs. To remedy this, active queue management techniques have been proposed as enhancements to routers throughout the Internet [RED]. The primary motivation for deployment of these mechanisms is to prevent "congestion collapse" (a severe degradation in service) by controlling the average queue size at the routers. As the average queue length grows, Random Early Detection [RED] increases the possibility of dropping packets.
上で指摘したように、TCPはウィンドウを閉鎖し、スロースタートを呼び出すことによって輻輳に応答します。長い遅延ネットワークは、この状態から回復するために特に長い時間がかかります。したがって、LTNsにおける輻輳を回避することが不可欠です。これを解決するには、アクティブキュー管理技術は、インターネット[RED]を通してルータの機能強化として提案されています。これらのメカニズムの展開のための主要な動機は、ルータにおける平均キューサイズを制御することにより、「輻輳崩壊」（サービスの深刻な劣化）を防止することです。平均キュー長が大きくなるにつれて、ランダム早期検出[RED]はパケットをドロップする可能性が高くなります。
The benefits are:
利点は次のとおりです。
- Reduce packet drops in routers. By dropping a few packets before severe congestion sets in, RED avoids dropping bursts of packets. In other words, the objective is to drop m packets early to prevent n drops later on, where m is less than n.
- ルータでのパケットドロップを削減します。激しい混雑がで設定する前に、いくつかのパケットをドロップすることにより、REDはパケットのバーストを落とす避けることができます。換言すれば、目的は、防止するために、初期のm個のパケットをドロップすることで、N mはnよりも小さい場合、後に低下します。
- Provide lower delays. This follows from the smaller queue sizes, and is particularly important for interactive applications, for which the inherent delays of wireless links already push the user experience to the limits of the non-acceptable.
- 低遅延を提供します。これは、より小さなキューサイズから、次、および無線リンクの固有の遅延は、すでに非許容の限界へのユーザーエクスペリエンスを押している対話型アプリケーション、特に重要です。
- Avoid lock-outs. Lack of resources in a router (and the resultant packet drops) may, in effect, obliterate throughput on certain connections. Because of active queue management, it is more probable for an incoming packet to find available buffer space at the router.
- ロックアウトを避けてください。ルータ（得られたパケットドロップ）内のリソースの不足は、実際には、特定の接続のスループットを消し去ることがあります。そのため、アクティブキュー管理のために、それは、ルータで使用可能なバッファスペースを見つけるために、着信パケットのためのより多くの可能性があります。
Active Queue Management has two components: (1) routers detect congestion before exhausting their resources, and (2) they provide some form of congestion indication. Dropping packets via RED is only one example of the latter. Another way to indicate congestion is to use ECN [ECN] as discussed above under "Detecting Corruption Loss: With Explicit Notifications."
（1）ルータは、そのリソースを消耗する前に輻輳を検出し、（2）彼らは輻輳表示のいくつかのフォームを提供します：アクティブキュー管理は、2つのコンポーネントがあります。 REDを介してパケットをドロップすると、後者の一例に過ぎません。輻輳を示すもう一つの方法は、下に、上述のようにECN [ECN]を使用することです「検出破損の損失：明示的な通知に」
Recommendation: RED is currently being deployed in the Internet, and LTNs should follow suit. ECN deployment should complement RED's.
勧告：REDは現在、インターネットで展開されている、とLTNsはスーツに従ってください。 ECNの配備は、REDの補完すべきです。
Active queue management helps control the length of the queues. Additionally, a general solution requires replacing FIFO with other scheduling algorithms that improve:
アクティブキュー管理は、キューの長さを制御するのに役立ちます。また、一般的な解決策を改善する他のスケジューリングアルゴリズムとFIFOを交換する必要があります。
1. Fairness (by policing how different packet streams utilize the available bandwidth), and
1.公平性（異なるパケット・ストリームが利用可能な帯域幅を利用する方法をポリシングすることにより）、及び
2. Throughput (by improving the transmitter's radio channel utilization).
2.スループット（送信機の無線チャネルの利用率を改善することにより）。
For example, fairness is necessary for interactive applications (like telnet or web browsing) to coexist with bulk transfer sessions. Proposals here include:
たとえば、公平性は、バルク転送セッションと共存する（telnetやウェブブラウジングなど）対話型アプリケーションのために必要です。ここでの提案は、次のとおりです。
- Fair Queueing (FQ) [Demers90]
- フェアキューイング（FQ）Demers90]
- Class-based Queueing (CBQ) [Floyd95]
- クラスベースキューイング（CBQ）[Floyd95]
Even if they are only implemented over the wireless link portion of the communication path, these proposals are attractive in wireless LTN environments, because new connections for interactive applications can have difficulty starting when a bulk TCP transfer has already stabilized using all available bandwidth.
彼らは唯一の通信経路の無線リンク部分の上に実装されている場合であっても、対話型アプリケーション用の新しい接続がバルクTCP転送はすでに、すべての利用可能な帯域幅を使用して安定化したときに起動する難しさを持っている可能性があるため、これらの提案は、無線LTN環境で魅力的です。
In our base architecture described above, the mobile device typically communicates directly with only one wireless peer at a given time: the intermediate node. In some W-WANs, it is possible to directly address other mobiles within the same cell. Direct communication with each such wireless peer may traverse a spatially distinct path, each of which may exhibit statistically independent radio link characteristics. Channel State Dependent Packet Scheduling (CSDP) [BBKT96] tracks the state of the various radio links (as defined by the target devices), and gives preferential treatment to packets destined for radio links in a "good" state. This avoids attempting to transmit to (and expect acknowledgements from) a peer on a "bad" radio link, thus improving throughput.
中間ノード：上述の我々のベースアーキテクチャでは、モバイルデバイスは、典型的には、所与の時間に唯一の無線ピアと直接通信します。いくつかのW-WANのでは、直接、同じセル内の他の移動体に対処することが可能です。このような各無線ピアと直接通信は、統計的に独立した無線リンクの特性を示すことができるそれぞれが、空間的に異なるパスを横断することができます。チャネル状態依存パケットスケジューリング（CSDP）は[BBKT96]（ターゲットデバイスによって定義されるような）種々の無線リンクの状態を追跡し、そして「良好な」状態で無線リンクを宛先とするパケットに優遇を与えます。これにより、「悪い」無線リンク上のピアに送信（及びから肯定応答を期待する）しようとしてスループットを向上させることが回避されます。
A further refinement of this idea suggests that both fairness and throughput can be improved by combining a wireless-enhanced CBQ with CSDP [FSS98].
この概念のさらなる改良は、公平性とスループットの両方がCSDP [FSS98]との無線強化CBQを組み合わせることによって改善することができることを示唆しています。
Recommendation: No recommendation at this time, pending further study.
勧告：さらなる研究保留中のこの時点で勧告なし、。
Given the dramatic differences between the wired and the wireless links, a very common approach is to provide some impedance matching where the two different technologies meet: at the intermediate node.
中間ノードにおいて：有線と無線リンクとの間の劇的な違いを考えると、非常に一般的なアプローチは、2つの異なる技術を満たすいくつかのインピーダンス整合を提供することです。
The idea is to replace an end-to-end TCP connection with two clearly distinct connections: one across the wireless link, the other across its wireline counterpart. Each of the two resulting TCP sessions operates under very different networking characteristics, and may adopt the policies best suited to its particular medium. For example, in a specific LTN topology it may be desirable to modify TCP Fast Retransmit to resend after the first duplicate ack and Fast Recovery to not shrink the congestion window if the LTN link has an extremely long RTT, is known to not reorder packets, and is not subject to congestion. Moreover, on a long-delay link or on a link with a relatively high bandwidth-delay product it may be desirable to "slow-start" with a relatively large initial window, even larger than four segments. While these kinds of TCP modifications can be negotiated to be employed over the LTN link, they would not be deployed end-to-end over the global Internet. In LTN topologies where the underlying link characteristics are known, a various similar types of performance enhancements can be employed without endangering operations over the global Internet.
無線リンクを介して1、その有線対応を介して他：アイデアは、2つの明確に区別される接続で、エンドツーエンドのTCP接続を交換することです。得られた二つのTCPセッションのそれぞれが非常に異なるネットワーク特性の下で動作し、その特定のメディアに最も適したポリシーを採用してもよいです。例えば、特定のLTNトポロジでは、LTNリンクは、パケットの順序を変更しないように知られている非常に長いRTTを持っている場合、輻輳ウィンドウを縮小しないように最初の重複ACKおよび高速リカバリ後に再送信するTCPの高速再送を変更することが望ましい場合があります輻輳の対象ではありません。また、長い遅延リンク上または比較的高い帯域幅遅延積とのリンクには4つのセグメントよりも大きく、比較的大きな初期ウィンドウで、「スロースタート」することが望ましいです。 TCP変更のこれらの種類は、LTNリンク上で採用されるように交渉することができますが、彼らはグローバルなインターネット上でエンドツーエンドを展開することではないでしょう。基礎となるリンクの特性が知られているLTNトポロジでは、パフォーマンスの向上の様々な同様のタイプがグローバルなインターネット上の操作を危険にさらすことなく使用することができます。
In some proposals, in addition to a PEP mechanism at the intermediate node, custom protocols are used on the wireless link (for example, [WAP], [YB94] or [MOWGLI]).
いくつかの提案では、中間ノードにおけるPEP機構に加えて、カスタムプロトコルは、無線リンク（例えば、[WAP]、[YB94]または[MOWGLI]）で使用されています。
Even if the gains from using non-TCP protocols are moderate or better, the wealth of research on optimizing TCP for wireless, and compatibility with the Internet are compelling reasons to adopt TCP on the wireless link (enhanced as suggested in section 5 below).
非TCPプロトコルを使用してからの利益は、中等度以上ある場合でも、インターネットに無線用TCP、および互換性の最適化に関する研究の富は無線リンク上でTCPを採用する説得力のある理由があり（下記のセクション5で提案されているように拡張）。
Split-TCP proposals include schemes like I-TCP [ITCP] and MTCP [YB94] which achieve performance improvements by abandoning end-to-end semantics.
スプリットTCPの提案は、エンドツーエンドのセマンティクスを放棄することにより、パフォーマンスの向上を実現ITCP [ITCP]とMTCP [YB94]のようなスキームが含まれます。
The Mowgli architecture [MOWGLI] proposes a split approach with support for various enhancements at all the protocol layers, not only at the transport layer. Mowgli provides an option to replace the TCP/IP core protocols on the LTN link with a custom protocol that is tuned for LTN links [KRLKA97]. In addition, the protocol provides various features that are useful with LTNs. For example, it provides priority-based multiplexing of concurrent connections together with shared flow control, thus offering link capacity to interactive applications in a timely manner even if there are bandwidth-intensive background transfers. Also with this option, Mowgli preserves the socket semantics on the mobile device so that legacy applications can be run unmodified.
モーグリアーキテクチャ[MOWGLI]はトランスポート層でだけでなく、すべてのプロトコル層での様々な機能強化をサポートする分割手法を提案しています。モーグリはLTNリンク[KRLKA97]用にチューニングされたカスタムプロトコルでLTNリンク上でTCP / IPのコアプロトコルを交換するためのオプションを提供します。また、プロトコルはLTNsで有用である様々な特徴を提供します。例えば、それは、このように帯域幅集約型のバックグラウンド転送があっても適時にインタラクティブなアプリケーションへのリンク容量を提供し、共通流制御とともに同時接続の優先順位ベースの多重化を提供します。レガシーアプリケーションを修正せずに実行できるように、また、このオプションを使用して、モーグリは、モバイルデバイス上のソケットのセマンティクスを保持します。
Employing split TCP approaches have several benefits as well as drawbacks. Benefits related to split TCP approaches include the following:
採用スプリットTCPのアプローチはいくつかの利点だけでなく欠点を有しています。 TCPアプローチを分割するために関連する利点は次のとおりです。
- Splitting the end-to-end TCP connection into two parts is a straightforward way to shield the problems of the wireless link from the wireline Internet path, and vice versa. Thus, a split TCP approach enables applying local solutions to the local problems on the wireless link. For example, it automatically solves the problem of distinguishing congestion related packet losses on the wireline Internet and packet losses due to transmission error on the wireless link as these occur on separate TCP connections. Even if both segments experience congestion, it may be of a different nature and may be treated as such. Moreover, temporary disconnections of the wireless link can be effectively shielded from the wireline Internet.
- 2つの部分に、エンドツーエンドのTCPコネクションを分割する有線インターネット経路から無線リンクの問題を遮蔽するための簡単な方法であり、その逆もまた同様です。このように、スプリットTCPのアプローチは、無線リンク上のローカル問題の局所解を適用できます。これらは別々のTCP接続で発生すると例えば、それは自動的に無線リンク上の伝送エラーによる有線インターネットとパケットロスの区別混雑関連のパケット損失の問題を解決します。両方のセグメントが輻輳を経験する場合であっても、それは異なる性質のものであってもよい、そのように処理されてもよいです。また、無線リンクの一時的切断を効果有線インターネットから遮蔽することができます。
- When one of the TCP connections crosses only a single hop wireless link or a very limited number of hops, some or all link characteristics for the wireless TCP path are known. For example, with a particular link we may know that the link provides reliable delivery of packets, packets are not delivered out of order, or the link is not subject to congestion. Having this information for the TCP path one could expect that defining the TCP mitigations to be employed becomes a significantly easier task. In addition, several mitigations that cannot be employed safely over the global Internet, can be successfully employed over the wireless link.
- TCP接続の1つが単一ホップ無線リンク又はホップの非常に限られた数の交差すると、無線TCPパスの一部またはすべてのリンクの特性が知られています。例えば、特定のリンクに、我々はリンクパケットの信頼できる配信を提供することを知ることができ、パケットが順不同で配信されない、またはリンクが混雑を受けないれます。 1が採用されるTCPの緩和策を定義することは非常に容易タスクになることが期待できるTCPパスのためにこの情報を有します。また、グローバルなインターネット上で安全に使用することはできませんいくつかの緩和策は、成功した無線リンクを介して使用することができます。
- Splitting one TCP connection into two separate ones allows much earlier deployment of various recent proposals to improve TCP performance over wireless links; only the TCP implementations of the mobile device and intermediate node need to be modified, thus allowing the vast number of Internet hosts to continue running the legacy TCP implementations unmodified. Any mitigations that would require modification of TCP in these wireline hosts may take far too long to become widely deployed.
- 二つの別々のものに1つのTCPコネクションを分割すると、無線リンク上のTCP性能を向上させる様々な最近の提案のかなり早い展開することができます。モバイルデバイスと中間ノードの唯一のTCP実装は、このように修飾されていない従来のTCPの実装の実行を継続するために、インターネットホストの膨大な数を可能にする、変更する必要があります。これらの有線ホストにTCPの変更を必要とする任意の緩和策は、広く展開になるためにあまりにも長い時間がかかることがあります。
- Allows exploitation of various application level enhancements which may give significant performance gains (see section 4.10.2).
- 大幅なパフォーマンス向上を（セクション4.10.2を参照）を与えることができる様々なアプリケーション・レベルの拡張機能の利用を許可します。
Drawbacks related to split TCP approaches include the following:
TCPアプローチを分割するために関連する欠点は、次のものがあります。
- One of the main criticisms against the split TCP approaches is that it breaks TCP end-to-end semantics. This has various drawbacks some of which are more severe than others. The most detrimental drawback is probably that splitting the TCP connection disables end-to-end usage of IP layer security mechanisms, precluding the application of IPSec to achieve end-to-end security. Still, IPSec could be employed separately in each of the two parts, thus requiring the intermediate node to become a party to the security association between the mobile device and the remote host. This, however, is an undesirable or unacceptable alternative in most cases. Other security mechanisms above the transport layer, like TLS [RFC2246] or SOCKS [RFC1928], should be employed for end-to-end security.
- スプリットTCPアプローチに対する主な批判の一つは、TCPエンドツーエンドのセマンティクスを破るということです。これは他のものよりも厳しいそのうちのいくつかは、様々な欠点を有しています。最も有害な欠点は、TCP接続はエンドツーエンドのセキュリティを実現するためのIPSecの適用を排除する、IP層のセキュリティメカニズムのエンド・ツー・エンドの使用を無効にし、おそらくその分割です。依然として、IPSecは、従って、モバイルデバイスとリモートホスト間のセキュリティアソシエーションの当事者になるために中間ノードを必要とする、二つの部分のそれぞれに別々に使用することができます。これは、しかし、ほとんどの場合、望ましくない、または容認できない代替手段です。トランスポート層の上の他のセキュリティ機構は、TLS [RFC2246]またはSOCKS [RFC1928]のような、エンドツーエンドのセキュリティのために使用されるべきです。
- Another drawback of breaking end-to-end semantics is that crashes of the intermediate node become unrecoverable resulting in termination of the TCP connections. Whether this should be considered a severe problem depends on the expected frequency of such crashes.
- エンドツーエンドのセマンティクスを破壊する別の欠点は、中間ノードのクラッシュが、TCP接続の終了を生じる回復不能になることです。これは深刻な問題と見なされるべきかどうか、このようなクラッシュの予想される周波数に依存します。
- In many occasions claims have been stated that if TCP end-to-end semantics is broken, applications relying on TCP to provide reliable data delivery become more vulnerable. This, however, is an overstatement as a well-designed application should never fully rely on TCP in achieving end-to-end reliability at the application level. First, current APIs to TCP, such as the Berkeley socket interface, do not allow applications to know when an TCP acknowledgement for previously sent user data arrives at TCP sender. Second, even if the application is informed of the TCP acknowledgements, the sending application cannot know whether the receiving application has received the data: it only knows that the data reached the TCP receive buffer at the receiving end. Finally, in order to achieve end-to-end reliability at the application level an application level acknowledgement is required to confirm that the receiver has taken the appropriate actions on the data it received.
- 。多くの場面での請求は、TCPエンドツーエンドのセマンティクスが壊れている場合は、信頼性の高いデータ配信を提供するために、TCPに依存するアプリケーションはより脆弱になることを述べてきましたうまく設計されたアプリケーションは、完全にアプリケーションレベルでエンドツーエンドの信頼性を達成するためにTCPに頼るべきではありませんので、これは、しかし、誇張です。まず、バークレーのソケットインタフェースとしてTCPの現在のAPIは、以前に送信されたユーザデータのためのTCPの確認応答がTCPの送信側に到着したときにアプリケーションが知ることはできません。第二に、アプリケーションはTCPの確認応答が通知された場合でも、送信側アプリケーションは、受信アプリケーションがデータを受信したかどうかを知ることができない。それだけのデータがTCPは、受信側で受信バッファに達していることを知っています。最後に、アプリケーションレベルでエンドツーエンドの信頼性を達成するために、アプリケーションレベルの肯定応答は、受信機は、受信データに適切な措置を講じたことを確認する必要があります。
- When a mobile device moves, it is subject to handovers by the serving base station. If the base station acts as the intermediate node for the split TCP connection, the state of both TCP endpoints on the previous intermediate node must be transferred to the new intermediate node to ensure continued operation over the split TCP connection. This requires extra work and causes overhead. However, in most of the W-WAN wireless networks, unlike in W-LANs, the W-WAN base station does not provide the mobile device with the connection point to the wireline Internet (such base stations may not even have an IP stack). Instead, the W-WAN network takes care of the mobility and retains the connection point to the wireline Internet unchanged while the mobile device moves. Thus, TCP state handover is not required in most W-WANs.
- モバイルデバイスが移動し、それはサービング基地局によりハンドオーバの対象である場合。基地局は、分割TCP接続のための中間ノードとして動作する場合、前の中間ノードの両方のTCPエンドポイントの状態がスプリットTCP接続を介して継続動作を保証するために、新しい中間ノードに転送されなければなりません。これは、余分な作業を必要とし、オーバーヘッドが発生します。しかし、W-WAN無線ネットワークのほとんどで、W-LANのとは異なり、W-WAN基地局は、有線インターネットへの接続ポイントとモバイルデバイスを提供していない（例えば、基地局があってもIPスタックを有していなくてもよいです） 。代わりに、W-WANネットワークは、モビリティの世話をし、モバイルデバイスが移動しながら、そのまま有線インターネットへの接続ポイントを保持します。このように、TCP状態のハンドオーバーは、ほとんどのW-WANのでは必要ありません。
- The packets traversing through all the protocol layers up to transport layer and again down to the link layer result in extra overhead at the intermediate node. In case of LTNs with low bandwidth, this extra overhead does not cause serious additional performance problems unlike with W-LANs that typically have much higher bandwidth.
- 中間ノードに余分なオーバーヘッドにリンク層これまで再び層とを輸送するまでのすべてのプロトコル層を介して通過するパケット。低帯域幅でのLTNsの場合には、この余分なオーバーヘッドは、一般的にはるかに高い帯域幅を持つW-LANのとは異なり、深刻な追加のパフォーマンスの問題が発生することはありません。
- Split TCP proposals are not applicable to networks with asymmetric routing. Deploying a split TCP approach requires that traffic to and from the mobile device be routed through the intermediate node. With some networks, this cannot be accomplished, or it requires that the intermediate node is located several hops away from the wireless network edge which in turn is unpractical in many cases and may result in non-optimal routing.
- スプリットTCPの提案は、非対称ルーティングとネットワークには適用されません。分裂TCPアプローチを展開するに、モバイルデバイスからのトラフィックは、中間ノードを介してルーティングされることを必要とします。一部のネットワークでは、これは達成することができない、またはそれが中間ノードは、いくつかのホップ離れ今度は多くの場合に実用的であり、非最適なルーティングをもたらすことができるワイヤレスネットワークエッジから配置されることを必要とします。
- Split TCP, as the name implies, does not address problems related to UDP.
- スプリットTCPは、名前が示すように、UDPに関連する問題に対処していません。
It should noted that using split TCP does not necessarily exclude simultaneous usage of IP for end-to-end connectivity. Correct usage of split TCP should be managed per application or per connection and should be under the end-user control so that the user can decide whether a particular TCP connection or application makes use of split TCP or whether it operates end-to-end directly over IP.
それは、スプリットTCPを使用すると、必然的にエンドツーエンドの接続のためのIPの同時使用を排除するものではないことに注意すべきです。スプリットTCPの正しい使用方法は、アプリケーションごとに、または接続ごとに管理されなければならないと、ユーザが特定のTCP接続またはアプリケーションが分割TCPを使用するかどうか、それが直接エンド・ツー・エンドで動作するかどうかを決定できるように、エンドユーザの制御の下でなければなりませんIPオーバー。
Recommendation: Split TCP proposals that alter TCP semantics are not recommended. Deploying custom protocols on the wireless link, such as MOWGLI proposes is not recommended, because this note gives preference to (1) improving TCP instead of designing a custom protocol and (2) allowing end-to-end sessions at all times.
推奨事項：TCPのセマンティクスを変えるスプリットTCPの提案が推奨されていません。このノートは、（1）TCPの改善の代わりに、カスタムプロトコルを設計し、（2）すべての回で、エンドツーエンドのセッションを可能に優先しますので、MOWGLIが提案しているなどの無線リンク上でカスタムプロトコルを展開すると、お勧めしません。
Nowadays, application level proxies are widely used in the Internet. Such proxies include Web proxy caches, relay MTAs (Mail Transfer Agents), and secure transport proxies (e.g., SOCKS). In effect, employing an application level proxy results in a "split TCP connection" with the proxy as the intermediary. Hence, some of the problems present with wireless links, such as combining of a congested wide-area Internet path with a wireless LTN link, are automatically alleviated to some extent.
今日では、アプリケーションレベルのプロキシはインターネットで広く使用されています。そのようなプロキシは、Webプロキシキャッシュ、のMTA（メール転送エージェント）を中継し、セキュアなトランスポートプロキシ（例えば、靴下）が挙げられます。実際には、仲介者としてプロキシと「スプリットTCPコネクション」のアプリケーションレベルのプロキシ結果を用います。したがって、そのような無線LTNリンクに輻輳広域インターネット経路の組み合わせのような無線リンクを有する本問題のいくつかは、自動的にある程度緩和されます。
The application protocols often employ plenty of (unnecessary) round trips, lots of headers and inefficient encoding. Even unnecessary data may get delivered over the wireless link in regular application protocol operation. In many cases a significant amount of this overhead can be reduced by simply running an application level proxy on the intermediate node. With LTN links, significant additional improvement can be achieved by introducing application level proxies with application-specific enhancements. Such a proxy may employ an enhanced version of the application protocol over the wireless link.
アプリケーションプロトコルは、多くの場合、（不要）ラウンドトリップ、ヘッダと非効率的なエンコーディングの多くの多くを採用しています。でも、不要なデータは、通常のアプリケーションプロトコルの動作中に無線リンクを介して配信されるかもしれません。多くの場合、このオーバーヘッドのかなりの量は、単に中間ノード上のアプリケーションレベルのプロキシを実行することによって低減することができます。 LTNリンクで、有意な追加の改善は、アプリケーション固有の機能強化とアプリケーションレベルのプロキシを導入することによって達成することができます。そのようなプロキシは、無線リンクを介してアプリケーション・プロトコルの拡張バージョンを使用してもよいです。
In an LTN environment enhancements at the application layer may provide much more notable performance improvements than any transport level enhancements.
LTN環境では、アプリケーション層での機能強化は、任意のトランスポートレベルの強化よりもはるかに顕著なパフォーマンスの向上を提供することができます。
The Mowgli system provides full support for adding application level agent-proxy pairs between the client and the server, the agent on the mobile device and the proxy on the intermediate node. Such a pair may be either explicit or fully transparent to the applications, but it is, at all times, under the end-user control. Good examples of enhancements achieved with application-specific proxies include Mowgli WWW [LAKLR95], [LHKR96] and WebExpress [HL96], [CTCSM97].
モーグリシステムは、クライアントおよびサーバ、モバイルデバイス上のエージェントと中間ノードのプロキシとの間のアプリケーションレベルのエージェントプロキシペアを追加するための完全なサポートを提供します。そのような対は、アプリケーションへの明示的または完全に透明のいずれであってもよく、それは常に、エンドユーザーの制御下にあります。アプリケーション固有のプロキシで達成強化の良い例は、モーグリWWW [LAKLR95]、[LHKR96]とWebExpress [HL96]、[CTCSM97]を含みます。
Recommendation: Usage of application level proxies is conditionally recommended: an application must be proxy enabled and the decision of employing a proxy for an application must be under the user control at all times.
推奨：アプリケーションレベルプロキシの使用を条件付きで推奨されます：アプリケーションプロキシを有効にする必要があり、アプリケーションのプロキシを使用するの決定は、すべての回でのユーザーコントロールの下でなければなりません。
Berkeley's SNOOP protocol [SNOOP] is a hybrid scheme mixing link-layer reliability mechanisms with the split connection approach. It is an improvement over split TCP approaches in that end-to-end semantics are retained. SNOOP does two things:
バークレーのスヌーププロトコル[スヌープ]は分割接続方式とリンク層の信頼性メカニズムを混合したハイブリッド方式です。これは、エンドツーエンドのセマンティクスで分割TCPのアプローチに比べて改善が保持されています。 SNOOPは、2つのことを行います。
1. Locally (on the wireless link) retransmit lost packets, instead of allowing TCP to do so end-to-end.
1.ローカル（無線リンク上では）の代わりにTCPがそうするエンド・ツー・エンドすることが可能で、失われたパケットを再送します。
2. Suppress the duplicate acks on their way from the receiver back to the sender, thus avoiding fast retransmit and congestion avoidance at the latter.
2.バック受信側から送信側へ向かう途中で重複ACKを抑制しますので、後者では高速再送と輻輳回避を回避することができます。
Thus, the Snoop protocol is designed to avoid unnecessary fast retransmits by the TCP sender, when the wireless link layer retransmits a packet locally. Consider a system that does not use the Snoop agent. Consider a TCP sender S that sends packets to receiver R via an intermediate node IN. Assume that the sender sends packet A, B, C, D, E (in that order) which are forwarded by IN to the wireless receiver R. Assume that the intermediate node then retransmits B subsequently, because the first transmission of packet B is lost due to errors on the wireless link. In this case, receiver R receives packets A, C, D, E and B (in that order). Receipt of packets C, D and E triggers duplicate acknowledgements. When the TCP sender receives three duplicate acknowledgements, it triggers fast retransmit (which results in a retransmission, as well as reduction of congestion window). The fast retransmit occurs despite the link level retransmit on the wireless link, degrading throughput.
このように、スヌーププロトコルは、無線リンク層が局部的にパケットを再送する場合、TCPの送信者が不要な高速な再送を回避するように設計されています。スヌープ・エージェントを使用しないシステムを考えてみましょう。中間ノードINを介してRを受信機にパケットを送信するTCP送信者Sを考えます。 R.がパケットBの最初の送信が失われているため、中間ノードは、次に、続いてBを再送することを前提と無線受信機にによって転送されたを（この順に）送信者がパケットA、B、C、D、Eを送信すると仮定する無線リンク上のエラーに起因します。この場合、受信機Rは、（この順番で）パケットA、C、D、E及びBを受信します。パケットC、D及びEの受信は、重複確認応答をトリガーします。 TCPの送信側が3つの重複確認応答を受信すると、それは速い（再送につながるだけでなく、輻輳ウィンドウの削減）再送信をトリガします。高速再送信は、スループットを低下させる、無線リンク上のリンクレベル再送信にもかかわらず起こります。
SNOOP [SNOOP] deals with this problem by dropping TCP dupacks appropriately (at the intermediate node). The Delayed Dupacks (see section 4.5) attempts to approximate Snoop without requiring modifications at the intermediate node. Such schemes are needed only if the possibility of a fast retransmit due to wireless errors is non-negligible. In particular, if the wireless link uses a stop-and-go protocol (or otherwise delivers packets in-order), then these schemes are not very beneficial. Also, if the bandwidth-delay product of the wireless link is smaller than four segments, the probability that the intermediate node will have an opportunity to send three new packets before a lost packet is retransmitted is small. Since at least three dupacks are needed to trigger a fast retransmit, with a wireless bandwidth-delay product less than four packets, schemes such as Snoop and Delayed Dupacks would not be necessary (unless the link layer is not designed properly). Conversely, when the wireless bandwidth-delay product is large enough, Snoop can provide significant performance improvement (compared with standard TCP). For further discussion on these topics, please refer to [Vaidya99].
（中間ノードで）適切にTCPのdupacksをドロップすることによってこの問題にスヌープ[スヌープ]ディール。遅延Dupacks（セクション4.5を参照）は、中間ノードでの修正を必要とせずに、スヌープを近似しようと試みます。このようなスキームは、無線エラーによる高速再送の可能性は無視できない場合にのみ必要とされています。無線リンクは、ストップ・アンド・ゴープロトコルを使用する（またはそうでなければ、インオーダーパケットを配信する）場合、特に、これらのスキームは非常に有益ではありません。無線リンクの帯域幅遅延積が4つのセグメントよりも小さい場合にも、失われたパケットを再送する前に、中間ノードが3つの新しいパケットを送信する機会を持ってする確率は小さいです。少なくとも三つdupacks無線帯域幅遅延積を用いて、以下の4つのパケットの高速再送信をトリガするために必要とされているので（リンク層が適切に設計されていない場合を除く）、そのようなスヌープ及び遅延Dupacksようなスキームは、必要ではないであろう。無線帯域幅遅延積が十分に大きい場合、逆に、スヌープは、（標準のTCPと比較して）有意な性能向上を提供することができます。これらのトピックに関するさらなる議論については、[Vaidya99]を参照してください。
The Delayed Dupacks scheme tends to provide performance benefit in environments where Snoop performs well. In general, performance improvement achieved by the Delayed Dupacks scheme is a function of packet loss rates due to congestion and transmission errors. When congestion-related losses occur, the Delayed Dupacks scheme unnecessarily delays retransmission. Thus, in the presence of congestion losses, the Delayed Dupacks scheme cannot achieve the same performance improvement as Snoop. However, simulation results [Vaidya99] indicate that the Delayed Dupacks can achieve a significant improvement in performance despite moderate congestion losses.
遅延Dupacks方式は、スヌープがうまく実行環境でのパフォーマンス上の利点を提供する傾向があります。一般に、遅延Dupacks方式によって達成される性能の向上は、輻輳や送信エラーによるパケット損失率の関数です。輻輳関連の損失が発生すると、遅延Dupacks方式は、不必要に再送を遅らせます。したがって、輻輳損失の存在下で、遅延Dupacks方式はスヌープと同じ性能の向上を達成することができません。しかし、シミュレーションの結果は、[Vaidya99]遅延Dupacksは適度な渋滞損失にもかかわらず、パフォーマンスの大幅な改善を達成できることを示しています。
WTCP [WTCP] is similar to SNOOP in that it preserves end-to-end semantics. In WTCP, the intermediate node uses a complex scheme to hide the time it spends recovering from local errors across the wireless link (this typically includes retransmissions due to error recovery, but may also include time spent dealing with congestion). The idea is for the sender to derive a smooth estimate of round-trip time. In order to work effectively, it assumes that the TCP endpoints implement the Timestamps option in RFC 1323 [TCPHP]. Unfortunately, support for RFC 1323 in TCP implementations is not yet widespread. Beyond this, WTCP requires changes only at the intermediate node.
それは、エンドツーエンドのセマンティクスを維持という点でWTCP [WTCP]はスヌープと同様です。 WTCPでは、中間ノードは、それが無線リンクを介してローカルエラー（これは通常、回復エラーのため再送信を含むが、時間は混雑を扱う過ごし含まれる）からの回復に費やす時間を隠すために、複雑なスキームを使用しています。送信者は、往復時間の円滑な推定値を導出するためのアイデアがあります。効果的に機能するためには、TCPエンドポイントはRFC 1323 [TCPHP]でタイムスタンプオプションを実装することを前提としています。残念ながら、TCPの実装では、RFC 1323のサポートはまだ普及していないです。これを越えて、WTCPは、中間ノードでの変更が必要となります。
SNOOP and WTCP require the intermediate node to examine and operate on the traffic between the portable wireless device and the TCP server on the wired Internet. SNOOP and WTCP do not work if the IP traffic is encrypted, unless, of course, the intermediate node shares the security association between the mobile device and its end-to-end peer. They also require that both the data and the corresponding ACKs traverse the same intermediate node. Furthermore, if the intermediate node retransmits packets at the transport layer across the wireless link, this may duplicate efforts by the link-layer. SNOOP has been described by its designers as a TCP-aware link-layer. This is the right approach: the link and network layers can be much more aware of each other than traditional OSI layering suggests.
SNOOPとWTCPは調べ、携帯無線機器と有線インターネット上のTCPサーバー間のトラフィック上で動作する中間ノードが必要です。もちろん、中間ノードは、モバイルデバイスとそのエンド・ツー・エンドのピア間のセキュリティアソシエーションを共有する、しない限り、IPトラフィックは、暗号化されている場合SNOOPとWTCPは動作しません。彼らはまた、データとそれに対応するACKの両方が同じ中間ノードを横断することを必要とします。中間ノードが無線リンクを介してトランスポート層でパケットを再送する場合はさらに、これがリンク層の努力を複製することができます。 SNOOPは、TCP-認識リンク層としてのデザイナーによって記述されています。これは正しいアプローチである：リンクとネットワーク層は、従来のOSIの階層化が示唆よりも、お互いのはるかに知ることができます。
Encryption of IP packets via IPSEC's ESP header (in either transport or tunnel mode) renders the TCP header and payload unintelligible to the intermediate node. This precludes SNOOP (and WTCP) from working, because it needs to examine the TCP headers in both directions. Possible solutions involve:
（トランスポートまたはトンネルモードのいずれかで）IPSECのESPヘッダを介して、IPパケットの暗号化は、中間ノードに不明瞭TCPヘッダとペイロードをレンダリングします。それは両方向でTCPヘッダを調べる必要があるので、これは、作業からSNOOP（およびWTCP）を排除します。考えられる解決策を伴います：
- making the SNOOP (or WTCP) intermediate node a party to the security association between the client and the server
- クライアントとサーバ間のセキュリティアソシエーションにSNOOP（またはWTCP）中間ノードのパーティを作ります
- IPSEC tunneling mode, terminated at the SNOOPing intermediate node
- スヌーピング中間ノードで終端IPSECトンネルモード、
However, these techniques require that users trust intermediate nodes. Users valuing both privacy and performance should use SSL or SOCKS for end-to-end security. These, however, are implemented above the transport layer, and are not as resistant to some security attacks (for example, those based on guessing TCP sequence numbers) as IPSEC.
しかし、これらの技術は、ユーザーが中間ノードを信頼する必要があります。プライバシーとパフォーマンスの両方を大切にユーザーがエンドツーエンドのセキュリティのためにSSLまたはSOCKSを使用する必要があります。これらは、しかし、トランスポート層の上に実装され、そして（例えば、TCPシーケンス番号を推測に基づくもの）は、いくつかのセキュリティ攻撃IPSECのように抵抗性ではありません。
Recommendation: Implement SNOOP on intermediate nodes now. Research results are encouraging, and it is an "invisible" optimization in that neither the client nor the server needs to change, only the intermediate node (for basic SNOOP without SACK). However, as discussed above there is little or no benefit from implementing SNOOP if:
勧告：今中間ノードにSNOOPを実装します。研究結果は有望であり、それは、クライアントとサーバーのいずれも、（SACKなし基本SNOOPのために）、唯一の中間ノードを変更する必要があるという点で、「目に見えない」最適化です。しかしながら、上述したように場合SNOOPを実装するから、ほとんど、あるいは全く利点があります：
1. The wireless link provides reliable, in-order packet delivery, or,
1.無線リンクは、信頼性の高い、インオーダーパケット配信を提供し、または、
2. The bandwidth-delay product of the wireless link is smaller than four segments.
前記無線リンクの帯域幅遅延積は、4つのセグメントよりも小さくなっています。
Periods of disconnection are very common in wireless networks, either during handoff, due to lack of resources (dropped connections) or natural obstacles. During these periods, a TCP sender does not receive the expected acknowledgements. Upon expiration of the retransmit timer, this causes TCP to close its congestion window with all the related drawbacks. Re-transmitting packets is useless since the connection is broken. [M-TCP] aims at enabling TCP to better handle handoffs and periods of disconnection, while preserving end-to-end semantics. M-TCP adds an element: supervisor host (SH-TCP) at the edge of the wireless network.
断線の期間はリソース不足（ドロップ接続）や自然の障害物に、ハンドオフの間のいずれか、ワイヤレスネットワークでは非常に一般的です。これらの期間中は、TCPの送信者が予想される確認応答を受信しません。再送信タイマーが満了すると、これはすべての関連の欠点とその輻輳ウィンドウを閉じるには、TCPの原因となります。再送信パケット接続が切断されたので、無駄です。 [M-TCP]は、エンドツーエンドのセマンティクスを維持しながら、よりよいハンドルハンドオフと断線の期間にTCPを可能にすることを目指しています。無線ネットワークのエッジでスーパバイザホスト（SH-TCP）：M-TCPは、要素を追加します。
This intermediate node monitors the traffic coming from the sender to the mobile device. It does not break end-to-end semantics because the ACKs sent from the intermediate node to the sender are effectively the ones sent by the mobile node. The principle is to generally leave the last byte unacknowledged. Hence, SH-TCP could shut down the sender's window by sending the ACK for the last byte with a window set to zero. Thus the sender will go to persist mode.
この中間ノードは、モバイル・デバイスに送信者からのトラフィックを監視します。送信者に中間ノードから送信されたACKが効果的にモバイルノードによって送信されたものであるため、これは、エンドツーエンドのセマンティクスを破壊しません。原理は、一般的に認められていない最後のバイトを残すことです。したがって、SH-TCPはゼロに設定ウィンドウで、最後のバイトに対してACKを送信することにより、送信者のウィンドウをシャットダウンすることができます。したがって、送信者は、モードを持続するために行くだろう。
The second optimization is done on both the intermediate node and the mobile host. On the latter, TCP is aware of the current state of the connection. In the event of a disconnection, it is capable of freezing all timers. Upon reconnection, the mobile sends a specially marked ACK with the number of the highest byte received. The intermediate node assumes that the mobile is disconnected because it monitors the flow on the wireless link, so in the absence of acknowledgments from the mobile, it will inform SH-TCP, which will send the ACK closing the sender window as described in the previous paragraph. The intermediate node learns that the mobile is again connected when it receives a duplicate acknowledgment marked as reconnected. At this point it sends a duplicate ACK to the sender and grows the window. The sender exits persist mode and resumes transmitting at the same rate as before. It begins by retransmitting any data previously unacknowledged by the mobile node. Non overlapping or non soft handoffs are lightweight because the previous intermediate system can shrink the window, and the new one modifies it as soon as it has received an indication from the mobile.
第2の最適化は、中間ノードとモバイルホストの両方で行われます。後者では、TCP接続の現在の状態を認識しています。断線が発生した場合、それはすべてのタイマーを凍結することができます。再接続すると、移動は受信最上位バイトの数と特別にマークされたACKを送信します。中間ノードは、モバイルからの肯定応答の不在下で、それは前に説明したように、送信者ウィンドウを閉じるACKを送信するSH-TCPを通知するので、それは、無線リンク上のフローを監視するため、移動体が切断されることを前提としてい段落。中間ノードは、それが再接続としてマークされた重複確認応答を受信した場合、移動が再び接続されていることを知ります。この時点では、送信者に重複ACKを送信し、ウィンドウを拡大します。送信者終了モードを持続し、前と同じレートで送信を再開します。これは、モバイルノードによって以前に未確認のすべてのデータを再送信することによって開始されます。前中間システムは、ウィンドウを縮小することができるので、非重複または非ソフトハンドオフは、軽量であり、新しいものはすぐにそれがモバイルからの指示を受信したとして、それを修正します。
Recommendation: M-TCP is not slated for adoption at this moment, because of the highly experimental nature of the proposal, and the uncertainty that TCP/IP implementations handle zero window updates correctly. Continue tracking developments in this space.
推奨：M-TCPは、TCP / IPの実装が正しくゼロウィンドウの更新を処理することを理由提案の非常に実験的な性質、および不確実性のため、この時点で採用が予定されていません。この空間での進展を追跡し続けます。
Because Long Thin Networks are bandwidth-constrained, compressing every byte out of over-the-air segments is worth while.
長く薄いネットワークは、帯域幅の制約があるため、空中のセグメントのうち、すべてのバイトを圧縮することは価値があります。
Mechanisms for TCP and IP header compression defined in [RFC1144, IPHC, IPHC-RTP, IPHC-PPP] provide the following benefits:
TCPとで定義されたIPヘッダー圧縮のための機構[RFC1144、IPHC、IPHC-RTP、IPHC-PPPは、以下の利点を提供します。
- Improve interactive response time
- インタラクティブな応答時間を改善
- Allow using small packets for bulk data with good line efficiency
- 良好なライン効率のバルク・データのための小さなパケットを使用して許可します
- Allow using small packets for delay sensitive low data-rate traffic
- 遅延に敏感な低データレートトラフィックのための小さなパケットを使用して許可します
- Decrease header overhead (for a common TCP segment size of 512 the header overhead of IPv4/TCP within a Mobile IP tunnel can decrease from 11.7 to less than 1 per cent.
- モバイルIPトンネル内のIPv4 / TCPの512ヘッダのオーバーヘッドの一般的なTCPセグメントサイズの減少ヘッダのオーバーヘッドは（1未満パーセントに11.7から減少させることができます。
- Reduce packet loss rate over lossy links (because of the smaller cross-section of compressed packets).
- （なぜなら、圧縮されたパケットのより小さな断面の）損失性リンク上のパケット損失率を減らします。
Van Jacobson (VJ) header compression [RFC1144] describes a Proposed Standard for TCP Header compression that is widely deployed. It uses TCP timeouts to detect a loss of synchronization between the compressor and decompressor. [IPHC] includes an explicit request for transmission of uncompressed headers to allow resynchronization without waiting for a TCP timeout (and executing congestion avoidance procedures).
バン・ジェイコブソン（VJ）ヘッダー圧縮[RFC1144]は、広く展開されているTCPヘッダー圧縮のために提案標準を記載しています。これは、コンプレッサとデコンプレッサの間の同期の損失を検出するために、TCPタイムアウトを使用しています。 [IPHC] TCPタイムアウトを待って（及び輻輳回避手順を実行する）ことなく、再同期を可能にする、非圧縮ヘッダの送信のために明示的な要求を含みます。
Recommendation: Implement [IPHC], in particular as it relates to IP-in-IP [RFC2003] and Minimal Encapsulation [RFC2004] for Mobile IP, as well as TCP header compression for lossy links and links that reorder packets. PPP capable devices should implement [IPHC-PPP]. VJ header compression may optionally be implemented as it is a widely deployed Proposed Standard. However, it should only be enabled when operating over reliable LTNs, because even a single bit error most probably would result in a full TCP window being dropped, followed by a costly recovery via slow-start.
推奨：それはIPインIP [RFC2003]及び最小カプセル化モバイルIPのために[RFC2004]、ならびにパケットを並べ替え、損失性リンク及びリンクのTCPヘッダー圧縮に関連し、特に、[IPHC]を実装します。 PPP可能なデバイスは、[IPHC-PPP]を実装しなければなりません。それは広く展開提案標準であるVJヘッダー圧縮は、必要に応じて実施されてもよいです。信頼性の高いLTNs上で動作している場合でも、単一ビットエラーがおそらくスロースタートを経由して、高価な回復が続くドロップされて、完全なTCPウィンドウ、につながるしかし、それだけで、有効にする必要があります。
Compression of IP payloads is also desirable. "IP Payload Compression Protocol (IPComp)" [IPPCP] defines a framework where common compression algorithms can be applied to arbitrary IP segment payloads. IP payload compression is something of a niche optimization. It is necessary because IP-level security converts IP payloads to random bitstreams, defeating commonly-deployed link-layer compression mechanisms which are faced with payloads that have no redundant "information" that can be more compactly represented.
IPペイロードの圧縮も望ましいです。 「IPペイロード圧縮プロトコル（のIPComp）は、」[IPPCP]一般的な圧縮アルゴリズムは、任意のIPセグメントペイロードに適用することができるフレームワークを定義します。 IPペイロード圧縮は、ニッチの最適化のようなものです。 IPレベルのセキュリティをよりコンパクトに表現することができる冗長「情報」を有していないペイロードに直面している一般的展開リンク層圧縮機構を破り、ランダムビットストリームにIPペイロードを変換するためにそれが必要です。
However, many IP payloads are already compressed (images, audio, video, "zipped" files being FTPed), or are already encrypted above the IP layer (SSL/TLS, etc.). These payloads will not "compress" further, limiting the benefit of this optimization.
しかし、多くのIPペイロードがすでに圧縮されている（FTPedである画像、オーディオ、ビデオ、「zip形式」のファイル）を、またはすでにIPレイヤ（SSL / TLSなど）の上に暗号化されています。これらのペイロードは、この最適化の恩恵を制限する、さらに「圧縮」ではないでしょう。
HTTP/1.1 already supports compression of the message body. For example, to use zlib compression the relevant directives are: "Content-Encoding: deflate" and "Accept-Encoding: deflate" [HTTP-PERF].
HTTP / 1.1は、すでにメッセージ本体の圧縮をサポートしています。たとえば、zlib圧縮を使用するために、関連するディレクティブは、以下のとおりです。「コンテンツエンコード：収縮」と「同意-エンコード：デフレート」[HTTP-PERF]。
HTTP-NG is considering supporting compression of resources at the HTTP level, which would provide equivalent benefits for common compressible MIME types like text/html. This will reduce the need for IPComp. If IPComp is deployed more rapidly than HTTP-NG, IPComp compression of HTML and MIME headers would be beneficial.
HTTP-NGはtext / htmlのような一般的な圧縮可能なMIMEタイプのための同等の利益を提供するHTTPレベルでリソースの圧縮をサポートして検討しています。これは、IPCompのための必要性を軽減します。 IPCompがより急速に展開されている場合はHTTP-NG、HTMLおよびMIMEヘッダののIPComp圧縮は有益であろう。
In general, application-level compression can often outperform IPComp, because of the opportunity to use compression dictionaries based on knowledge of the specific data being compressed.
一般に、アプリケーション・レベルの圧縮はしばしば圧縮される特定のデータについての知識に基づいて、圧縮辞書を使用する機会と、のIPCompを上回ることができます。
Recommendation: IPComp may optionally be implemented. Track HTTP-NG standardization and deployment for now. Implementing HTTP/1.1 compression using zlib SHOULD is recommended.
推奨：のIPCompは、必要に応じて実施されてもよいです。今のHTTP-NGの標準化と展開を追跡します。 zlibのを使用して実装するHTTP / 1.1圧縮が推奨されるべきです。
TCP maintains per-connection information such as connection state, current round-trip time, congestion control or maximum segment size. Sharing information between two consecutive connections or when creating a new connection while the first is still active to the same host may improve performance of the latter connection. The principle could easily be extended to sharing information amongst systems in a LAN not just within a given system. [Touch97] describes cache update for both cases.
TCPは、接続状態、現在のラウンドトリップ時間、輻輳制御または最大セグメントサイズとしてごとの接続情報を維持します。最初は、後者の接続の性能を改善することが依然として同じホストにアクティブである間に新しい接続を作成するときに、2つの連続した接続の間で情報を共有しますか、。原理は簡単ではないだけで、与えられたシステム内LAN内のシステム間で情報を共有するに拡張することができます。 [Touch97]両方のケースのためのキャッシュの更新について説明します。
Users of W-WAN devices frequently request connections to the same servers or set of servers. For example, in order to read their email or to initiate connections to other servers, the devices may be configured to always use the same email server or WWW proxy. The main advantage of this proposal is that it relieves the application of the burden of optimizing the transport layer. In order to improve the performance of TCP connections, this mechanism only requires changes at the wireless device.
W-WANデバイスのユーザーは頻繁に同じサーバーへの接続を要求したり、サーバのセット。例えば、自分の電子メールを読むために、または他のサーバーへの接続を開始するために、デバイスは常に同じ電子メールサーバやWWWプロキシを使用するように構成することができます。この提案の主な利点は、トランスポート層の最適化の負担の適用を緩和ということです。 TCP接続のパフォーマンスを向上させるためには、このメカニズムは、ワイヤレスデバイスでの変更が必要となります。
In general, this scheme should improve the dynamism of connection setup without increasing the cost of the implementation.
一般に、この方式は、実装のコストを増大させることなく、接続設定のダイナミズムを向上させる必要があります。
Recommendation: This mechanism is recommended, although HTTP/1.1 with its persistent connections may partially achieve the same effect without it. Other applications (even HTTP/1.0) may find it useful. Continue monitoring research on this. In particular, work on a "Congestion Manager" [CM] may generalize this concept of sharing information among protocols and applications with a view to making them more adaptable to network conditions.
推奨事項：その持続的な接続とHTTP / 1.1は、部分的にそれなしで同じ効果を達成することができるが、このメカニズムは、推奨されます。他のアプリケーション（でも、HTTP / 1.0）は、それが役に立つかもしれません。この研究の監視を続けます。具体的には、「輻輳管理」[CM]の作業は、ネットワークの状態にそれらをより適応することを視野にプロトコルとアプリケーションの間で情報を共有するこの概念を一般化することがあります。
5 Summary of Recommended Optimizations
推奨最適化の5まとめ
The table below summarizes our recommendations with regards to the main proposals mentioned above.
以下の表は、上記のメインの提案に関して、当社の提言をまとめました。
The first column, "Stability of the Proposal," refers to the maturity of the mechanism in question. Some proposals are being pursued within the IETF in a somewhat open fashion. An IETF proposal is either an Internet Drafts (I-D) or a Request for Comments (RFC). The former is a preliminary version. There are several types of RFCs. A Draft Standards (DS) is standards track, and carries more weight than a Proposed Standard (PS), which may still undergo revisions. Informational or Experimental RFCs do not specify a standard. Other proposals are isolated efforts with little or no public review, and unknown chances of garnering industry backing.
最初の列、「提案の安定性は、」問題のメカニズムの成熟を意味します。いくつかの提案は、ややオープンな方法でIETFの中に追求されています。 IETFの提案は、インターネットドラフト（I-D）または要求のコメント（RFC）のいずれかです。前者は暫定版です。 RFCのいくつかの種類があります。ドラフト規格（DS）が標準化過程であり、さらに修正を受けることが提案された標準（PS）、より多くの重量を運びます。情報や実験的RFCは標準を指定しないでください。他の提案は、ほとんど、あるいはまったく公共口コミを孤立努力、および業界の裏を集めて未知のチャンスです。
"Implemented at" indicates which participant in a TCP session must be modified to implement the proposal. Legacy servers typically cannot be modified, so this column indicates whether implementation happens at either or both of the two nodes under some control: mobile device and intermediate node. The symbols used are: WS (wireless sender, that is, the mobile device's TCP send operation must be modified), WR (wireless receiver, that is, the mobile device's TCP receive operation must be modified), WD (wireless device, that is, modifications at the mobile device are not specific to either TCP send or receive), IN (intermediate node) and NI (network infrastructure). These entities are to be understood within the context of Section 1.1 ("Network Architecture"). NA simply means "not applicable."
「で実装さ」の提案を実施するように変更しなければならないTCPセッション内のどの参加者を示しています。レガシーサーバは、典型的に変更することができないので、この列には、実装は、いくつかの制御下に2つのノードのいずれかまたは両方で起こるかどうかを示す：モバイルデバイスとの中間ノード。使用している記号は、以下のとおりです。WS（無線送信者、それはモバイルデバイスのTCPの送信操作が変更されなければならない）、WR（無線受信機、それは、モバイルデバイスのTCPで操作が修正されなければならない受信）、WD（無線デバイス、つまり、 、モバイルデバイスでの修飾は、TCP送信または受信のいずれかに特異的ではない）、IN（中間ノード）とNI（ネットワークインフラストラクチャ）。これらのエンティティは、セクション1.1（「ネットワークアーキテクチャ」）の文脈の中で理解されるべきです。 NAは、単に「適用できない」を意味します。
The "Recommendation" column captures our suggestions. Some mechanisms are endorsed for immediate adoption, others need more evidence and research, and others are not recommended.
「勧告」の欄には、私たちの提案をキャプチャします。いくつかのメカニズムは、他の人がより多くの証拠と研究を必要とし、即時の採用を推奨している、などが推奨されていません。
Name Stability of Implemented Recommendation
the Proposal at
==================== ============= =========== =================
Increased Initial RFC 2581 (PS) WS Yes Window (initial_window=2)
増加した初期RFC 2581（PS）WSはいウィンドウ（initial_window = 2）
Disable delayed ACKs NA WR When stable during slow start
スロースタート時の場合には安定した遅延ACK NAのWRを無効にします
Byte counting NA WS No instead of ACK counting
バイトカウントNA WSノー代わりのACKカウント
TCP Header RFC 1144 (PS) WD Yes compression for PPP IN (see 4.11)
TCPヘッダRFC 1144（PS）WDはいPPP、INの圧縮（4.11を参照してください）
IP Payload RFC 2393 (PS) WD Yes Compression (simultaneously (IPComp) needed on Server)
IPペイロードRFC 2393（PS）WDはい圧縮（同時に（のIPComp）サーバー上で必要）
Header RFC 2507 (PS), WD Yes Compression RFC 2509 (PS) IN (For IPv4, TCP and Mobile IP, PPP)
ヘッダRFC 2507（PS）、WDはい圧縮RFC 2509（PS）（IPv4の、TCPおよびモバイルIP、PPPの場合）
SNOOP plus SACK In limited use IN Yes WD (for SACK)
SNOOPプラスはいWDの限られた使用ではSACK（SACK用）
Fast retransmit/fast RFC 2581 (PS) WD Yes (should be recovery there already)
高速再送/高速のRFC 2581（PS）WDはい（すでにそこに回復する必要があります）
Transaction/TCP RFC 1644 WD No (Experimental) (simultaneously needed on Server)
トランザクション/ TCPのRFC 1644 WDいいえ（実験）（同時にサーバに必要）
Estimating Slow NA WS No Start Threshold (ssthresh)
スローNA WSノー開始閾値を推定する（SSTHRESH）
Delayed Duplicate Not stable WR When stable Acknowledgements IN (for notifications)
遅延重複安定していないWRときに安定謝辞IN（通知用）
Class-based Queuing NA WD When stable on End Systems
クラスベースキューイングNA WDときエンドシステムに安定しました
Explicit Congestion RFC 2481 (EXP) WD Yes
明示的輻輳RFC 2481（EXP）WDはい
Notification NI
のちふぃかちおん に
TCP Control Block RFC 2140 WD Yes Interdependence (Informational) (Track research)
TCP制御ブロックRFC 2140 WDはい相互依存（情報）（トラック研究）
Of all the optimizations in the table above, only SNOOP plus SACK and Delayed duplicate acknowledgements are currently being proposed only for wireless networks. The others are being considered even for non-wireless applications. Their more general applicability attracts more attention and analysis from the research community.
上記の表のすべての最適化のうち、SNOOPプラスSACKと遅延の重複確認応答のみは現在、ワイヤレスネットワークのために提案されています。他にも非無線アプリケーションのために検討されています。彼らの多くの一般的な適用は、研究コミュニティから多くの注目を集め、分析を魅了しています。
Of the above mechanisms, only Header Compression (for IP and TCP) and "SNOOP plus SACK" cease to work in the presence of IPSec.
上記のメカニズムの中で、唯一の（IPおよびTCPのための）ヘッダ圧縮及び「SNOOPプラスSACK」停戦は、IPSecの存在下で動作します。
6 Conclusion
6おわりに
In view of the unpredictable and problematic nature of long thin networks, arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks (LTNs).
細長いネットワークの予測できないと問題の性質を考慮して、最適化されたトランスポートに到達する困難な作業です。私たちは、今後の研究のアイテムと一緒に、既存の提案を検討しています。この概要に基づいて、我々はまた、長い薄いネットワーク（LTNs）で実装するためのメカニズムをお勧めします。
7 Acknowledgements
7つの謝辞
The authors are deeply indebted to the IETF tcpsat and tcpimpl working groups. The following individuals have also provided valuable feedback: Mark Allman (NASA), Vern Paxson (ACIRI), Raphi Rom (Technion/Sun), Charlie Perkins (Nokia), Peter Stark (Phone.com).
著者は、IETF tcpsatへとワーキンググループtcpimpl大いに感謝しています。マーク・オールマン（NASA）、バーン・パクソン（ACIRI）、Raphiロム（テクニオン/日）、チャーリー・パーキンス（ノキア）、ピーター・スターク（Phone.com）：以下の個人はまた、貴重なフィードバックを提供しています。
8 Security Considerations
8セキュリティについての考慮事項
The mechanisms discussed and recommended in this document have been proposed in previous publications. The security considerations outlined in the original discussions apply here as well. Several security issues are also discussed throughout this document. Additionally, we present below a non-exhaustive list of the most salient issues concerning our recommended mechanisms:
このドキュメントで説明し、推奨されるメカニズムは、以前の出版物に提案されています。オリジナルの議論に概説されたセキュリティ上の考慮事項は、ここにも適用されます。いくつかのセキュリティ上の問題も、この文書を通して議論されています。また、我々は我々の推奨メカニズムに関する最も顕著な問題の非網羅的なリストの下に存在します：
- Larger Initial TCP Window Size
- 大きな初期のTCPウィンドウサイズ
No known security issues [RFC2414, RFC2581].
既知のセキュリティ上の問題はありません[RFC2414、RFC2581]。
- Header Compression
- ヘッダー圧縮
May be open to some denial of service attacks. But any attacker in a position to launch these attacks would have much stronger attacks at his disposal [IPHC, IPHC-RTP].
サービス攻撃のいくつかの否定に開放されていてもよいです。しかし、これらの攻撃を開始する位置にある任意の攻撃者は、彼の処分[IPHC、IPHC - RTP]ではるかに強い攻撃を持っているでしょう。
- Congestion Control, Fast Retransmit/Fast Recovery
- 輻輳制御、高速再送/高速リカバリ
An attacker may force TCP connections to grind to a halt, or, more dangerously, behave more aggressively. The latter possibility may lead to congestion collapse, at least in some regions of the network [RFC2581].
攻撃者は、より積極的に振る舞う、より危険な、停止に挽くためにTCP接続を強制する、またはことがあります。後者の可能性は、少なくともネットワーク[RFC2581]の一部の領域に、輻輳崩壊につながる可能性があります。
- Explicit Congestion Notification
- 明示的輻輳通知
It does not appear to increase the vulnerabilities in the network. On the contrary, it may reduce them by aiding in the identification of flows unresponsive to or non-compliant with TCP congestion control [ECN].
ネットワークの脆弱性を高めるためには表示されません。逆に、それは、TCP輻輳制御[ECN]とに応答しないか、非対応のフローの識別を助けることによって、それらを減少させることができます。
- Sharing of Network Performance Information (TCP Control Block Sharing and Congestion Manager module)
- ネットワークパフォーマンス情報の共有（TCP制御ブロックを共有し、輻輳管理モジュール）
Some information should not be shared. For example, TCP sequence numbers are used to protect against spoofing attacks. Even limiting the sharing to performance values leaves open the possibility of denial-of-service attacks [Touch97].
一部の情報が共有されるべきではありません。たとえば、TCPシーケンス番号は、スプーフィング攻撃から保護するために使用されています。でも、性能値に共有を制限する[Touch97]サービス拒否攻撃の可能性を開いたままに。
- Performance Enhancing Proxies
- パフォーマンス強化プロキシ
These systems are men-in-the-middle from the point of view of their security vulnerabilities. Accordingly, they must be used with extreme care so as to prevent their being hijacked and misused.
これらのシステムは、男性・イン・ザ・ミドル彼らのセキュリティの脆弱性の観点からです。彼らのハイジャックや誤用されているのを防ぐようによって、彼らは細心の注意を払って使用する必要があります。
This last point is not to be underestimated: there is a general security concern whenever an intermediate node performs operations different from those carried out in an end-to-end basis. This is not specific to performance-enhancing proxies. In particular, there may be a tendency to forego IPSEC-based privacy in order to allow, for example, a SNOOP module, header compression (TCP, UDP, RTP, etc), or HTTP proxies to work.
この最後の点はない過小評価されるべき中間ノードは、エンドツーエンドの基準で行ったものとは異なる動作を行うたびに、一般的なセキュリティ上の問題があります。これは、パフォーマンス強化プロキシに固有ではありません。具体的には、動作できるようにするために、IPSecベースのプライバシーを放棄する傾向、例えば、スヌープモジュール、ヘッダ圧縮（TCP、UDP、RTPなど）、またはHTTPプロキシが存在してもよいです。
Adding end-to-end security at higher layers (for example via RTP encryption, or via TLS encryption of the TCP payload) alleviates the problem. However, this still leaves protocol headers in the clear, and these may be exploited for traffic analysis and denial-of-service attacks.
（RTP暗号化を介して、例えば、またはTCPペイロードのTLS暗号化を介して）より高いレイヤでのエンドツーエンドのセキュリティを追加する問題を軽減します。しかし、これはまだ明らかでプロトコルヘッダーを残し、これらはトラフィック分析とサービス拒否攻撃のために利用することができます。
9 References
9つの参考文献
[ACKSPACING] Partridge, C., "ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering", Work in Progress.
[ACKSPACING]ウズラ、C.、「不十分なバッファリングによる高遅延帯域パスのACK間隔」が進行中で働いています。
[ADGGHOSSTT98] Allman, M., Dawkins, S., Glover, D., Griner, J., Henderson, T., Heidemann, J., Kruse, H., Osterman, S., Scott, K., Semke, J., Touch, J. and D. Tran, "Ongoing TCP Research Related to Satellites", Work in Progress.
【ADGGHOSSTT98】オールマン、M.、ドーキンス、S.、グローバー、D.、Griner、J.、ヘンダーソン、T.、Heidemann、J.、クルーズ、H.、オスターマン、S.、スコット、K.、Semke、 J.、タッチ、J.とD.トラン、「継続的なTCPの研究衛星に関連する」が進行中で働いています。
[AGS98] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[AGS98]オールマン、M.、グローバー、D.およびL.サンチェス、BCP 28、RFC 2488、1999年1月、 "標準的なメカニズムを使用してTCP上の衛星テレビの強化"。
[Allman98] Mark Allman. On the Generation and Use of TCP Acknowledgments. ACM Computer Communication Review, 28(5), October 1998.
[Allman98]マークオールマン。世代オンとTCP謝辞の使用。 ACMコンピュータコミュニケーションレビュー、28（5）、1998年10月。
[AHO98] Allman, M., Hayes, C., Ostermann, S., "An Evaluation of TCP with Larger Initial Windows," Computer Communication Review, 28(3), July 1998.
[AHO98]オールマン、M.、ヘイズ、C.、Ostermann、S.、 "大規模な初期のWindowsでのTCPの評価、" コンピュータコミュニケーションレビュー、28（3）、1998年7月。
[BBKT96] Bhagwat, P., Bhattacharya, P., Krishna, A., Tripathi, S., "Enhancing Throughput over Wireless LANs Using Channel State Dependent Packet Scheduling," in Proc. IEEE INFOCOM'96, pp. 1133-40, March 1996.
PROCで[BBKT96] Bhagwat、P.、バッタチャリヤ、P.、クリシュナ、A.、Tripathi、S.、 "チャネル状態依存パケットスケジューリングを使用して無線LANでスループットを高めます"。 IEEE INFOCOM'96、頁。1133年から1140年、1996年3月。
[BBKVP96] Bakshi, B., P., Krishna, N., Vaidya, N., Pradhan, D.K., "Improving Performance of TCP over Wireless Networks," Technical Report 96-014, Texas A&M University, 1996.
[BBKVP96]バクシ、B.、P.、クリシュナ、N.、Vaidya、N.、プラダン、D.K.、 "無線ネットワーク上でTCPのパフォーマンスの向上、" テクニカルレポート96から014、テキサスA＆M大学、1996。
[BPSK96] Balakrishnan, H., Padmanabhan, V., Seshan, S., Katz, R., "A Comparison of Mechanisms for Improving TCP Performance over Wireless Links," in ACM SIGCOMM, Stanford, California, August 1996.
[BPSK96]バラクリシュナン、H.、Padmanabhan、V.、Seshan、S.、カッツ、R.、ACM SIGCOMM、スタンフォード大学、カリフォルニア州、1996年8月の "ワイヤレスリンク上でTCPのパフォーマンスを向上させるためのメカニズムの比較、"。
[BPK99] Balakrishnan, H., Padmanabhan, V., Katz, R., "The effects of asymmetry on TCP performance," ACM Mobile Networks and Applications (MONET), Vol. 4, No. 3, 1999, pp. 219-241.
[BPK99]バラクリシュナン、H.、Padmanabhan、V.、カッツ、R.、 "TCPのパフォーマンス上の非対称性の影響、" ACMモバイルネットワークとアプリケーション（MONET）、巻。図4に示すように、第3号、1999、頁219から241。
[BV97] S. Biaz and N. H. Vaidya, "Distinguishing Congestion Losses from Wireless Transmission Losses: A Negative Result," Seventh International Conference on Computer Communications and Networks (IC3N), New Orleans, October 1998.
[BV97] S. BiazとN. H. Vaidya、「ワイヤレス伝送損失から区別輻輳損失の結果、陰性、」コンピュータ通信とネットワークに関する第7回国際会議（IC3N）、ニューオーリンズ、1998年10月。
[BV98] Biaz, S., Vaidya, N., "Sender-Based heuristics for Distinguishing Congestion Losses from Wireless Transmission Losses," Texas A&M University, Technical Report 98-013, June 1998.
[BV98] Biaz、S.、Vaidya、N.、テキサスA＆M大学、テクニカルレポート98から013、1998年6月 "ワイヤレス伝送損失、区別輻輳損失のための送信者ベースのヒューリスティック"。
[BV98a] Biaz, S., Vaidya, N., "Discriminating Congestion Losses from Wireless Losses using Inter-Arrival Times at the Receiver," Texas A&M University, Technical Report 98-014, June 1998.
[BV98a] Biaz、S.、Vaidya、N.、「レシーバーの間到着時間を使用してワイヤレスの損失と区別輻輳損失、」テキサスA＆M大学、テクニカルレポート98から014、1998年6月。
[BW97] Brasche, G., Walke, B., "Concepts, Services, and Protocols of the New GSM Phase 2+ general Packet Radio Service," IEEE Communications Magazine, Vol. 35, No. 8, August 1997.
[BW97] Brasche、G.、Walke、B.、 "概念、新しいGSMフェーズ2+汎用パケット無線サービスのサービス、およびプロトコル、" IEEEコミュニケーションズマガジン、巻。 35、第8号、1997年8月。
[CB96] Cheshire, S., Baker, M., "Experiences with a Wireless Network in MosquitoNet," IEEE Micro, February 1996. Available online as: http://rescomp.stanford.edu/~cheshire/papers /wireless.ps.
[CB96]チェシャー、S.、ベイカー、M.、 "のMosquitoNetでワイヤレスネットワークを持つ経験、" IEEEマイクロ、1996年2月利用可能なオンラインのように：http://rescomp.stanford.edu/~cheshire/papers /無線。 PS。
[CDMA] Electronic Industry Alliance(EIA)/Telecommunications Industry Association (TIA), IS-95: Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System, 1993.
[CDMA]電子工業会（EIA）/電気通信工業会（TIA）は、IS-95：デュアル・モード広帯域用の移動局 - 基地局互換性規格、1993スペクトラム拡散セルラシステム。
[CDPD] Wireless Data Forum, CDPD System Specification, Release 1.1, 1995.
[CDPD]ワイヤレスデータフォーラム、CDPDシステム仕様、リリース1.1、1995年。
[CM] Hari Balakrishnan and Srinivasan Seshan, "The Congestion Manager," Work in Progress.
[CM]ハリ・バラクリシュナンとスリニバサン・セシャン、「輻輳マネージャ、」進行中の作業。
[CTCSM97] Chang, H., Tait, C., Cohen, N., Shapiro, M., Mastrianni, S., Floyd, R., Housel, B., Lindquist, D., "Web Browsing in a Wireless Environment: Disconnected and Asynchronous Operation in ARTour Web Express," in Proc. MobiCom'97, Budapest, Hungary, September 1997.
【CTCSM97】チャン、H.、テイト、C.、コーエン、N.、シャピロ、M.、Mastrianni、S.、フロイド、R.、Housel、B.、リンドクイスト、D.、「無線環境でのウェブブラウジング：PROCでARTourのWeb Expressで切断し、非同期操作、」。 MobiCom'97、ブダペスト、ハンガリー、1997年9月。
[Demers90] Demers, A., Keshav, S., and Shenker, S., Analysis and Simulation of a Fair Queueing Algorithm, Internetworking: Research and Experience, Vol. 1, 1990, pp. 3-26.
【Demers90]デマーズ、A.、Keshav、S.、およびShenker、S.、分析および均等化キューイングアルゴリズム、インターネットワーキングのシミュレーション：研究と経験、巻。 1、1990、頁3-26。
[ECN] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[ECN]ラマクリシュナン、K.およびS.フロイド、 "IPに明示的輻輳通知（ECN）を追加する提案"、RFC 2481、1999年1月。
[Floyd95] Floyd, S., and Jacobson, V., Link-sharing and Resource Management Models for Packet Networks. IEEE/ACM Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995.
[Floyd95]フロイド、S.、およびヤコブソン、パケットネットワークのためのV.、リンクを共有し、リソース管理モデル。ネットワーキング、巻上のIEEE / ACM取引。 3第4号、頁365から386まで、1995年8月。
[FSS98] Fragouli, C., Sivaraman, V., Srivastava, M., "Controlled Multimedia Wireless Link Sharing via Enhanced Class-Based Queueing with Channel-State-Dependent Packet Scheduling," Proc. IEEE INFOCOM'98, April 1998.
[FSS98] Fragouli、C.、Sivaraman、V.、Srivastava氏、M.、PROC「を、チャネル状態依存パケットスケジューリングとキューイングクラスベースの拡張を経てマルチメディアワイヤレスリンクの共有を制御されました」。 IEEE INFOCOM'98、1998年4月。
[GPRS] ETSI, "General Packet Radio Service (GPRS): Service Description, Stage 2," GSM03.60, v.6.1.1 August 1998.
[GPRS] ETSI、 "汎用パケット無線サービス（GPRS）：サービス説明、ステージ2、" GSM03.60、v.6.1.1 1998年8月。
[GSM] Rahnema, M., "Overview of the GSM system and protocol architecture," IEEE Communications Magazine, vol. 31, pp 92-100, April 1993.
[GSM] Rahnema、M.、「GSMシステム及びプロトコル・アーキテクチャの概要、」IEEEコミュニケーションズマガジン、体積31頁92〜100、1993年4月。
[HL96] Hausel, B., Lindquist, D., "WebExpress: A System for Optimizing Web Browsing in a Wireless Environment," in Proc. MobiCom'96, Rye, New York, USA, November 1996.
[HL96] Hausel、B.、リンドクイスト、D.、 "WebExpress：無線環境におけるウェブブラウジングを最適化するシステム、" PROCです。 MobiCom'96、ライ、ニューヨーク、USA、1996年11月。
[HTTP-PERF] Henrik Frystyk Nielsen (W3C, MIT), Jim Gettys (W3C, Digital), Anselm Baird-Smith (W3C, INRIA), Eric Prud'hommeaux (W3C, MIT), Hon Lie (W3C, INRIA), Chris Lilley (W3C, INRIA), "Network Performance Effects of HTTP/1.1, CSS1, and PNG," ACM SIGCOMM '97, Cannes, France, September 1997. Available at: http://www.w3.org/Protocols/HTTP/Performance /Pipeline.html
[HTTP-PERF]ヘンリック・フリスティック・ニールセン（W3C、MIT）、ジム・ゲティーズ（W3C、デジタル）、アンセルムベアード・スミス（W3C、INRIA）、エリック・プラオモー（W3C、MIT）、ホンリー（W3C、INRIA）、クリス・リレイ（W3C、INRIA）、 "HTTP / 1.1のネットワークパフォーマンスの影響、CSS1、およびPNG、" ACMのSIGCOMM '97、カンヌ、フランス、1997年9月には利用可能で：http://www.w3.org/Protocols/ HTTP /パフォーマンス/Pipeline.html
[IPPCP] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, December 1998.
[IPPCP] Shacham、A.、Monsour、R.、ペレイラ、R.とM.トーマス、 "IPペイロード圧縮プロトコル（IPCompの）"、RFC 2393、1998年12月。
[IPHC] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[IPHC] Degermark、M.、Nordgren、B.とS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[IPHC-RTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[IPHC-RTP] Casner、S.とV.ヤコブソン、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。
[IPHC-PPP] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[IPHC-PPP] Engan、M.、Casner、S.及びC.ボルマン、 "PPP上のIPヘッダー圧縮"、RFC 2509、1999年2月。
[ITCP] Bakre, A., Badrinath, B.R., "Handoff and Systems Support for Indirect TCP/IP. In Proceedings of the Second USENIX Symposium on Mobile and Location-Independent Computing, Ann Arbor, Michigan, April 10- 11, 1995.
[ITCP] Bakre、A.、バドリーナート、B.R.、「間接的なTCP / IPのためのハンドオフ・システムをサポートします。第二にUSENIXシンポジウムでは、移動や場所に依存しないコンピューティング、アナーバー、ミシガン州、4月10〜11、1995年。
[Jain89] Jain, R., "A Delay-Based Approach for Congestion Avoidance in Interconnected Heterogeneous Computer Networks," Digital Equipment Corporation, Technical Report DEC-TR-566, April 1989.
[Jain89]ジャイナ教、R.、「相互接続の異機種コンピュータネットワークにおける輻輳回避のための遅延ベースのアプローチ、」デジタル・イクイップメント・コーポレーション、テクニカルレポートDEC-TR-566、1989年4月。
[Karn93] Karn, P., "The Qualcomm CDMA Digital Cellular System" Proc. USENIX Mobile and Location-Independent Computing Symposium, USENIX Association, August 1993.
[Karn93]カーン、P.、 "クアルコムCDMAデジタルセルラーシステム" PROC。 USENIXモバイルと場所に依存しないコンピューティングシンポジウム、USENIX協会、1993年8月。
[KRLKA97] Kojo, M., Raatikainen, K., Liljeberg, M., Kiiskinen, J., Alanko, T., "An Efficient Transport Service for Slow Wireless Telephone Links," in IEEE Journal on Selected Areas of Communication, volume 15, number 7, September 1997.
コミュニケーション、ボリュームの選択領域に関するIEEEジャーナルで[KRLKA97]古城、M.、Raatikainen、K.、Liljeberg、M.、Kiiskinen、J.、Alanko、T.、 "スロー無線電話リンクのための効率的な輸送サービス、" 15、番号7、1997年9月。
[LAKLR95] Liljeberg, M., Alanko, T., Kojo, M., Laamanen, H., Raatikainen, K., "Optimizing World-Wide Web for Weakly-Connected Mobile Workstations: An Indirect Approach," in Proc. 2nd Int. Workshop on Services in Distributed and Networked Environments, Whistler, Canada, pp. 132-139, June 1995.
【LAKLR95] Liljeberg、M.、Alanko、T.、古城、M.、Laamanen、H.、Raatikainen、K.、 "弱接続されたモバイルワークステーションのための最適化ワールドワイドウェブ：間接アプローチ、" PROCです。第二のInt。分散型でのサービスやネットワーク環境、ウィスラー、カナダ、頁132-139、1995年6月のワークショップ。
[LHKR96] Liljeberg, M., Helin, H., Kojo, M., Raatikainen, K., "Mowgli WWW Software: Improved Usability of WWW in Mobile WAN Environments," in Proc. IEEE Global Internet 1996 Conference, London, UK, November 1996.
【LHKR96] Liljeberg、M.、Helin氏、H.、古城、M.、Raatikainen、K.、：PROCの "モーグリWWWソフトウェア、モバイルWAN環境におけるWWWのユーザビリティ改善"。 IEEEグローバルインターネット1996年大会、ロンドン、イギリス、1996年11月。
[LS98] Lettieri, P., Srivastava, M., "Adaptive Frame Length Control for Improving Wireless Link Throughput, Range, and Energy Efficiency," Proc. IEEE INFOCOM'98, April 1998.
[LS98]アルフレッド・レッティエリ、P.、Srivastava氏、M.、 "ワイヤレスリンクのスループット、範囲、およびエネルギー効率を向上させるための適応フレーム長制御、" PROC。 IEEE INFOCOM'98、1998年4月。
[MNCP] Piscitello, D., Phifer, L., Wang, Y., Hovey, R., "Mobile Network Computing Protocol (MNCP)", Work in Progress.
【MNCP] Piscitello、D.、ファイファー、L.、王、Y.、Hovey、R.、 "モバイル・ネットワーク・コンピューティング・プロトコル（MNCP）"、ProgressのWork。
[MOWGLI] Kojo, M., Raatikainen, K., Alanko, T., "Connecting Mobile Workstations to the Internet over a Digital Cellular Telephone Network," in Proc. Workshop on Mobile and Wireless Information Systems (MOBIDATA), Rutgers University, NJ, November 1994. Available at: http://www.cs.Helsinki.FI/research/mowgli/. Revised version published in Mobile Computing, pp. 253-270, Kluwer, 1996.
PROCの "デジタルセルラー電話ネットワークを介したインターネットへのモバイルワークステーションの接続、" [MOWGLI]古城、M.、Raatikainen、K.、Alanko、T.、。モバイルおよびワイヤレス情報システム（MOBIDATA）、ラトガース大学、ニュージャージー州、11月利用可能な1994年のワークショップ：http://www.cs.Helsinki.FI/research/mowgli/。モバイルコンピューティング、頁253から270、Kluwerの、1996年に出版さ改訂版。
[MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm," in Computer Communications Review, a publication of ACM SIGCOMM, volume 27, number 3, July 1997.
コンピュータコミュニケーションレビュー、ACM SIGCOMM、ボリューム27の出版物における[MSMO97]マティス、M.、Semke、J.、Mahdavi、J.、オット、T.、 "TCP輻輳回避アルゴリズムの巨視的挙動"、番号3、1997年7月。
[MTCP] Brown, K. Singh, S., "A Network Architecture for Mobile Computing," Proc. IEEE INFOCOM'96, pp. 1388- 1396, March 1996. Available at ftp://ftp.ece.orst.edu/pub/singh/papers /transport.ps.gz
[MTCP]ブラウン、K.シン、S.、 "モバイルコンピューティングのためのネットワークアーキテクチャ、" PROC。 ftp://ftp.ece.orst.edu/pub/singh/papersでIEEE INFOCOM'96、頁1388- 1396年、1996年3月には、利用可能な/transport.ps.gz
[M-TCP] Brown, K. Singh, S., "M-TCP: TCP for Mobile Cellular Networks," ACM Computer Communications Review Vol. 27(5), 1997. Available at ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gz
[M-TCP]ブラウン、K.シン、S.、 "M-TCP：モバイルセルラーネットワークのためのTCP、" ACMコンピュータコミュニケーションレビュー集。 27（5）、ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gzの利用可能な1997年
[MV97] Mehta, M., Vaidya, N., "Delayed Duplicate-Acknowledgements: A Proposal to Improve Performance of TCP on Wireless Links," Texas A&M University, December 24, 1997. Available at http://www.cs.tamu.edu/faculty/vaidya/mobile.html
[MV97]メータ、M.、Vaidya、N.、 "重複-謝辞を遅延：無線リンク上のTCPの性能を向上させるための提案、" テキサスA＆M大学、12月24日、HTTPで利用可能な1997年：//www.csを。 tamu.edu/faculty/vaidya/mobile.html
[NETBLT] White, J., "NETBLT (Network Block Transfer Protocol)", Work in Progress.
[NETBLT]ホワイト、J.、 "NETBLT（ネットワークブロック転送プロトコル）"、ProgressのWork。
[Paxson97] V. Paxson, "End-to-End Internet Packet Dynamics," Proc. SIGCOMM '97. Available at ftp://ftp.ee.lbl.gov/papers/vp-pkt-dyn-sigcomm97.ps.Z
[Paxson97] V.パクソンは、「エンドツーエンドインターネットパケットダイナミクス、」PROC。 SIGCOMM '97。 ftp://ftp.ee.lbl.gov/papers/vp-pkt-dyn-sigcomm97.ps.Zで利用可能
[RED] Braden, B., 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.
[赤]ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、G.、ヤマウズラ、 C.、ピーターソン、L.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.とL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、RFC 2309、1998年4月。
[RLP] ETSI, "Radio Link Protocol for Data and Telematic Services on the Mobile Station - Base Station System (MS-BSS) interface and the Base Station System - Mobile Switching Center (BSS-MSC) interface," GSM Specification 04.22, Version 3.7.0, February 1992.
【RLP] ETSI、「移動局にデータおよびテレマティックサービスのための無線リンクプロトコル - 基地局システム（MS-BSS）インターフェース及び基地局システム - 移動交換センター（BSS-MSC）インタフェース、」GSM仕様04.22、バージョン3.7.0、1992年2月。
[RFC908] Velten, D., Hinden, R. and J. Sax, "Reliable Data Protocol", RFC 908, July 1984.
[RFC908] Velten、D.、HindenとR.及びJ.サックス、 "信頼性の高いデータプロトコル"、RFC 908、1984年7月。
[RFC1030] Lambert, M., "On Testing the NETBLT Protocol over Divers Networks", RFC 1030, November 1987.
"ダイバーネットワーク上のNETBLTプロトコルのテストについて" [RFC1030]ランバート、M.、RFC 1030、1987年11月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]ジェーコブソン、V.、 "圧縮TCP /低速シリアルリンクのIPヘッダ"、RFC 1144、1990年2月。
[RFC1151] Partridge, C., Hinden, R., "Version 2 of the Reliable Data Protocol (RDP)", RFC 1151, April 1990.
[RFC1151]ウズラ、C.、HindenとR.、RFC 1151 "信頼性の高いデータプロトコル（RDP）のバージョン2"、1990年4月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191]モーグル、J.およびS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1397] Braden, R., "Extending TCP for Transactions -- Concepts", RFC 1397, November 1992.
[RFC1397]ブレーデン、R.、 "取引のための拡張TCP - 概念"、RFC 1397、1992年11月。
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[RFC1644]ブレーデン、R.、 "T / TCP - 取引機能仕様のためのTCP拡張機能"、RFC 1644、1994年7月。
[RFC1661] Simpson, W., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[RFC1928]リーチ、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.およびL.ジョーンズ、 "SOCKSプロトコルバージョン5"、RFC 1928、1996年3月。
[RFC1986] Polites, W., Wollman, W., Woo, D. and R. Langan, "Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP)", RFC 1986, August 1996.
[RFC1986]ポライト、W.、ウォルマン、W.、ウー、D.とR.ランガン、RFC 1986、1996年8月「拡張簡易ファイル転送プロトコル（ETFTP）を使用して、ラジオリンクのための簡単なファイル転送プロトコルを用いた実験」。
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[RFC2002]パーキンス、C.、 "IPモビリティサポート"、RFC 2002、1996年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004]パーキンス、C.、 "IP内の最小カプセル化"、RFC 2004、1996年10月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]マティス、M.、Mahdavi、J.、フロイド、S.とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[RFC2188] Banan, M., Taylor, M. and J. Cheng, "AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2", RFC 2188, September 1997.
[RFC2188]バナン、M.、テイラー、M.とJ.チェン、 "AT＆T /ネダの効率的なショートリモート操作（ESRO）プロトコル仕様バージョン1.2"、RFC 2188、1997年9月。
[RFC2246] Dierk, T. and E. Allen, "TLS Protocol Version 1", RFC 2246, January 1999.
[RFC2246] Dierk、T.およびE.アレン、 "TLSプロトコルバージョン1"、RFC 2246、1999年1月。
[RFC2414] Allman, M., Floyd, S. and C. Partridge. "Increasing TCP's Initial Window", RFC 2414, September 1998.
[RFC2414]オールマン、M.、フロイド、S.、およびC.ヤマウズラ。 、RFC 2414 "TCPの初期ウィンドウの増加" を、1998年9月。
[RFC2415] Poduri, K.and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[RFC2415] Poduri、K.and K.ニコルズ、 "増加した初期のTCPウィンドウサイズのシミュレーション研究"、RFC 2415、1998年9月。
[RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[RFC2416]シェパード、T.とC.パートリッジ、RFC 2416、1998年9月「TCPは3つしかバッファに4つのパケットで起動」。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[RFC2582]フロイド、S.とT.ヘンダーソン、 "TCPの高速回復アルゴリズムにNewRenoの変更"、RFC 2582、1999年4月。
[SNOOP] Balakrishnan, H., Seshan, S., Amir, E., Katz, R., "Improving TCP/IP Performance over Wireless Networks," Proc. 1st ACM Conf. on Mobile Computing and Networking (Mobicom), Berkeley, CA, November 1995.
[SNOOP]バラクリシュナン、H.、Seshan、S.、アミール、E.、カッツ、R.、PROC "無線ネットワーク上でTCP / IPのパフォーマンスを改善"。第一ACMコンファレンス。モバイルコンピューティングとネットワーキング（モビコム）、バークレー、CA、1995年11月に。
[Stevens94] R. Stevens, "TCP/IP Illustrated, Volume 1," Addison-Wesley, 1994 (section 2.10 for MTU size considerations and section 11.3 for weak checksums).
【Stevens94] R.スティーブンス、 "TCP / IPイラスト、第1巻、" アディソン・ウェズリー、1994（MTUサイズの考慮事項と弱いチェックサムのためのセクション11.3のためのセクション2.10）。
[TCPHP] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[TCPHP]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[TCPSATMIN] TCPSAT Minutes, August, 1997. Available at: http://tcpsat.lerc.nasa.gov/tcpsat/meetings/munich-minutes.txt.
[TCPSATMIN] TCPSAT分、8月、利用可能な1997：http://tcpsat.lerc.nasa.gov/tcpsat/meetings/munich-minutes.txt。
[Touch97] Touch, T., "TCP Control Block Interdependence", RFC 2140, April 1997.
[Touch97]タッチ、T.、 "TCP制御ブロック相互依存"、RFC 2140、1997年4月。
[Vaidya99] N. H. Vaidya, M. Mehta, C. Perkins, G. Montenegro, "Delayed Duplicate Acknowledgements: A TCP-Unaware Approach to Improve Performance of TCP over Wireless," Technical Report 99-003, Computer Science Dept., Texas A&M University, February 1999.
[Vaidya99] NH Vaidya、M.メータ、C.パーキンス、G.モンテネグロ、「遅延重複謝辞：無線上でTCPの性能を向上させるためにTCPを意識しないアプローチ、」テクニカルレポート99から003、コンピュータサイエンス学科、テキサスA＆M大学、1999年2月。
[VEGAS] Brakmo, L., O'Malley, S., "TCP Vegas, New Techniques for Congestion Detection and Avoidance," SIGCOMM'94, London, pp 24-35, October 1994.
[VEGAS] Brakmo、L.、オマリー、S.、 "TCPラスベガス、輻輳検出と回避のための新技術、" SIGCOMM'94、ロンドン、頁24-35、1994年10月。
[VMTP] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC 1045, February 1988.
[VMTP] Cheriton、D.、 "VMTP：多彩なメッセージトランザクションプロトコル"、RFC 1045、1988年2月。
[WAP] Wireless Application Protocol Forum. http://www.wapforum.org/
[WAP]ワイヤレスアプリケーションプロトコルフォーラム。 http://www.wapforum.org/
[WC91] Wang, Z., Crowcroft, J., "A New Congestion Control Scheme: Slow Start and Search," ACM Computer Communication Review, vol 21, pp 32-43, January 1991.
[WC91]王、Z.、クロウクロフト、J.、「新しい輻輳制御方式：スロースタートと検索、」ACMコンピュータコミュニケーションレビュー、巻21頁32から43まで、1991年1月。
[WTCP] Ratnam, K., Matta, I., "WTCP: An Efficient Transmission Control Protocol for Networks with Wireless Links," Technical Report NU-CCS-97-11, Northeastern University, July 1997. Available at: http://www.ece.neu.edu/personal/karu/papers/WTCP-NU.ps.gz
[WTCP]ラトナム、K.、マッタ、I.、 "WTCP：ワイヤレスリンク、とのネットワークの効率的な伝送制御プロトコル"：のhttp：/で利用可能なテクニカルレポートNU-CCS-97から11、ノースイースタン大学、1997年7月/www.ece.neu.edu/personal/karu/papers/WTCP-NU.ps.gz
[YB94] Yavatkar, R., Bhagawat, N., "Improving End-to-End Performance of TCP over Mobile Internetworks," Proc. Workshop on Mobile Computing Systems and Applications, IEEE Computer Society Press, Los Alamitos, California, 1994.
[YB94] Yavatkar、R.、Bhagawat、N.は、PROC "モバイルインターネットワーク上のTCPのエンドツーエンドのパフォーマンスを向上させます"。モバイルコンピューティングシステムおよびアプリケーション、IEEEコンピュータ学会出版、ロスアラミトス、カリフォルニア、1994年ワークショップ。
Authors' Addresses
著者のアドレス
Questions about this document may be directed at:
このドキュメントに関する質問がで向けることができます。
Gabriel E. Montenegro Sun Labs Networking and Security Group Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View, California 94303
ガブリエル・E.モンテネグロ日Labsのネットワークとセキュリティグループのサン・マイクロシステムズ社901サンアントニオの道メールストップUMPK 15から214マウンテンビュー、カリフォルニア94303
Phone: +1-650-786-6288 Fax: +1-650-786-6445 EMail: gab@sun.com
電話：+ 1-650-786-6288ファックス：+ 1-650-786-6445 Eメール：gab@sun.com
Spencer Dawkins Nortel Networks P.O. Box 833805 Richardson, Texas 75083-3805
スペンサー・ドーキンスNortel Networksの私書箱ボックス833805リチャードソン、テキサス州75083から3805
Phone: +1-972-684-4827 Fax: +1-972-685-3292 EMail: sdawkins@nortel.com
電話：+ 1-972-684-4827ファックス：+ 1-972-685-3292 Eメール：sdawkins@nortel.com
Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland
コンピュータサイエンス、ヘルシンキ大学、私書箱のマルック古城部門ボックス26（Teollisuuskatu 23）FIN-00014ヘルシンキ、フィンランド
Phone: +358-9-1914-4179 Fax: +358-9-1914-4441 EMail: kojo@cs.helsinki.fi
電話：+ 358-9-1914-4179ファックス：+ 358-9-1914-4441 Eメール：kojo@cs.helsinki.fi
Vincent Magret Corporate Research Center Alcatel Network Systems, Inc 1201 Campbell Mail stop 446-310 Richardson Texas 75081 USA M/S 446-310
ヴィンセントMagretコーポレート・リサーチ・センターアルカテル・ネットワークシステムズ株式会社1201キャンベルメール停止446から310リチャードソンテキサス75081 USA M / S 446から310
Phone: +1-972-996-2625 Fax: +1-972-996-5902 EMail: vincent.magret@aud.alcatel.com
電話：+ 1-972-996-2625ファックス：+ 1-972-996-5902 Eメール：vincent.magret@aud.alcatel.com
Nitin Vaidya Dept. of Computer Science Texas A&M University College Station, TX 77843-3112
コンピュータサイエンスのニティンVaidya学科テキサスA＆M大学カレッジステーション、TX 77843-3112
Phone: 979-845-0512 Fax: 979-847-8578 EMail: vaidya@cs.tamu.edu
電話：979-845-0512ファックス：979-847-8578 Eメール：vaidya@cs.tamu.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。