[要約] RFC 2757は、長くて細いネットワークに関する情報を提供するものであり、その目的は、この種のネットワークの特性と課題を理解し、効果的な設計と運用を支援することです。
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.
Copyright（c）The Internet Society（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.
長い薄いネットワーク（たとえば、ワイヤレスワン）の予測不可能で問題のある性質を考慮すると、最適化された輸送に到達することは困難な作業です。 将来の研究項目とともに既存の提案をレビューしました。 この概要に基づいて、長い薄いネットワークでの実装のメカニズムもお勧めします。
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を特定することです。この目的を念頭に置いて、衛星リンク（TCPSAT）ワーキンググループを介したIETF TCPの実用的な推奨事項から始めました。
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.
最適化されたワイヤレスネットワーキングは、ネットワークリソースへのユビキタスなアクセスを可能にするために、モバイルコンピューティングが解決しなければならない主要なハードルの1つです。ただし、現在のデータネットワーキングプロトコルは、主に有線ネットワーク向けに最適化されています。ワイヤレス環境は、有線ネットワークと比較して、レイテンシ、ジッター、エラー率の点で非常に異なる特性を持っています。したがって、従来のプロトコルはこの媒体に適していません。
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.
モバイルワイヤレスネットワークは、W-LANS（たとえば、802.11準拠ネットワーク）およびW-Wans（たとえば、CDPD [CDPD]、Ricochet、CDMA [CDMA]、PHS、Docomo、GSM [GSM]にグループ化できます。）。W-wansは、ワイヤレスリンクの長さ（遅延*帯域幅製品として表される）が、通常、W-LANの対応物の長さの場合の4〜5倍であることを考えると、最も深刻な課題を提示します。たとえば、802.11ネットワークの場合、遅延（往復時間）が約3ミリ秒であると仮定します。帯域幅は1.5 Mbps、遅延*帯域幅製品は4500ビットです。リコチェットなどのW-WANの場合、典型的な往復時間は約500ミリ秒です。（最高は約230ミリ秒です。）、持続的な帯域幅は約24 kbpsです。これにより、遅延*帯域幅製品が1.5 kbに等しくなります。近い将来、第3世代のワイヤレスサービスは384kbps以上を提供します。200ミリ秒の往復を想定すると、この場合の遅延*帯域幅製品は76.8 kbit（9.6 kb）です。この値は、多くのTCP実装で使用されるデフォルトの8kbバッファースペースよりも大きいです。これは、W-LANSの場合、デフォルトのバッファスペースで十分であるのに対し、将来のW-WANはデフォルト値をオーバーライドしない限り非効率的に動作します（つまり、パイプを埋めることはできません）。200ミリ秒のレイテンシを備えた2 Mbpsを提供する第3世代のワイヤレスサービスには、50 kBのバッファーが必要です。
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、ADGGHOSSTTT98]のTCPSATワーキンググループによる開発中の文書は非常に関連性があります。どちらの場合も、リンク層でフォワードエラー補正（FEC）を使用して、10-3から10-6の値（ビットエラー率）を低下させることにより、媒体の特性を改善することから始めることが不可欠です。より良い。これにより、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-wansは「L」をLFNと共有します。ただし、衛星ネットワークは、帯域幅が高いという意味でも「脂肪」です。衛星ネットワークには、64 kバイトを超える遅延*帯域幅製品があることがよくあります。その場合、TCP [TCPHP]に追加の問題を提起します。W-wansは通常、この動作を示しません。したがって、このドキュメントは、「長い薄いパイプ」であるリンクと、「長い薄いネットワーク」を含むネットワークを扱います。これらを「LTN」と呼びます。
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.
具体的には、有線のセグメントで区切られた2つのワイヤレスセグメントを含むパスには関心がありません。これは、たとえば、1つのモバイルデバイスがインターネットへの中間ノードを介して、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].
ワイヤレスメディアを非常に効率的に使用できるが、従来の制約の一部を克服できるモバイルデバイスを想定しています。つまり、完全なモビリティは、デバイスが、特定の時点またはスペースで利用可能な最高のネットワーク接続である場合に使用する柔軟性と俊敏性を備えていることを意味します。したがって、デバイスは有線オフィスLANから切り替えて、進行中の接続を引き渡して、たとえばワイヤレスWANを継続できます。このタイプの俊敏性には、モバイル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を提示する場合があります。以下の手法は通常、すべてのタイプのエラーに対処するわけではありません。したがって、完全なソリューションは、すべての提案の中で最高のものを組み合わせる必要があります。それにもかかわらず、このドキュメントでは、最も典型的なケースをより懸念しています（そして解決を優先します）。（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.
- ワイヤレスサービスデータグラム志向ですか、それとも仮想回路ですか？現在、スイッチされた仮想回路の方が一般的ですが、Packet Networksが表示され始めています。たとえば、MetricomのStarMode [CB96]、CDPD [CDPD]、およびGeneral Packet Radio Service（GPRS）[GPRS]、[BW97]、[GPRS]、[BW97]はGSMです。
- 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).
- モバイルデバイスは、ワイヤレスリンクで複数のピアを直接扱っていますか？それぞれのピアへのパケットは、空間的に異なるワイヤレスパスを横断する可能性があります。したがって、各ピアへのパスは、非常に異なる特性を示す場合があります。一般的に、モバイルデバイスは、特定の時点で1つのピア（中間ノード）のみをアドレス指定します。そうでない場合、チャネル状態に依存するパケットスケジューリングなどの手法が機能します（以下のセクション「パケットスケジューリング」を参照）。
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."
これは、プロキシを通じて常に通信するモバイルデバイスの合理的なモデルです。ただし、多くのワイヤレスモバイルデバイスがWirelineネットワークが利用可能になるたびに利用することを期待しています。このモデルは、現在のラップトップの使用パターンに密接に従います。通常、デバイスは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).
これらのデバイスでは、IPが中間ノードを通過しない通信に必要なため、IPが最良のアプローチであると仮定するアーキテクチャです（たとえば、OfficeのW-LANまたは10BASETネットワークへの再接続時に）。
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、Ricochet、および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.
このアプローチは、シリアルラインインターフェイスプロトコル（スリップ）の代替として、ワイヤーラインネットワーク上の堅牢なフレーミングと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代替品が提案されています。ここでは、1つの代表的な提案について説明します。
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プロトコルスタックは、データグラムのトランスポートサービスに階層化されています。このようなサービスは、ほとんどのワイヤレスネットワークによって提供されます。たとえば、CDPDやGSM GPRSなどのIPネットワークのIS-136、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ミリ秒未満（またはそれほど大きくない）を選択することです。
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:
PATH MTU Discoveryは、IPの上に構築されたプロトコルに利益をもたらします。これにより、送信者は、最大エンドツーエンドの送信ユニットが特定の宛先にあるものを判断できます。PATH MTU発見がなければ、デフォルトのIPv4 MTUサイズは576です。より大きなMTUを使用することの利点は次のとおりです。
- 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は、特定のセグメント内でそれに応じてより大きなエラーの確率があります。FECやリンク層の再送信などの低レベルの手法を使用して、BERは削減される場合があります。問題は、追加の再送信により遅延が問題になる可能性があることと、より大きなMTUとともにパケット送信時間が増加するという事実が原因であることです。
Recommendation: Path MTU discovery is recommended. [AGS98] already recommends its use in satellite environments.
推奨事項：Path 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データグラムサービスを想定しており、IP [NetBLT]またはUDP [MNCP]の上に直接最適化されたトランスポートを実装します。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]
- ESRO [RFC2188]
- RDP [RFC908, RFC1151]
- RDP [RFC908、RFC1151]
- VMTP [VMTP]
- vmtp [vmtp]
3 The Case for TCP
3 TCPの場合
This is one of the most hotly debated issues in the wireless arena. Here are some arguments against it:
これは、ワイヤレスアリーナで最も熱く議論されている問題の1つです。それに対するいくつかの議論は次のとおりです。
- 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).
- レガシーメカニズムは再利用される場合があります（たとえば、3方向の握手）。
- 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テクノロジーはこれを行い（CDPD、US-TDMA、CDMA、GSM）、TCPスループットを改善します。
- 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、ADGGHOSSTTT98]の準備に非常に役立ちました。
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の数に基づいてウィンドウを増やします。もちろん、到着率は、送信者と受信機の間の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ドキュメントオブジェクト、電子メールメッセージ、ファイルなど）、特にLTNのユーザーは、応答時間があるため、大規模な転送を実行する意思はありません。さよなら。
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.
3. LTNが非常に混雑しているワイヤーラインインターネットパスと組み合わされると、インターネット上の混雑損失は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. 一般的に、ISPS/オペレーターは、ダイヤルアップルーターのユーザーごとに少数のバッファ（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が膨張しないようにし、競合するトラフィックでパケットの量を減らすために、LTNで小さなソケットバッファーが推奨されます。
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つの重複したAcksが郵便の再送信を不必要に到着するのを待つパケットの並べ替えのない遅いパスで。
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]は、明らかに、送信者が単一のウィンドウで部分的なアックと複数の損失をよりよく処理するのに役立ちますが、この時点では、その実験的性質のために推奨されません。代わりに、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の少なくともいくつかの利点（たとえば、その後のクエリ応答トランザクションの3方向の握手を排除する）も、HTTP/1.1の永続的な接続で利用できます。これはより広く展開されています。
[ADGGHOSSTT98] does not have a recommendation on T/TCP in satellite environments.
[ADGGHOSSTTT98]は、衛星環境で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つのセグメントの初期ウィンドウを備えた従来のスロースタートは、LTNを介した時間のかかる帯域幅の適応手順です。1つのセグメント[RFC2414、AHO98]を超える初期ウィンドウの研究により、TCP標準が最大値2 [RFC2581]をサポートしました。より高い値は、本質的にまだ実験的です。
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]により、2つのセグメントの初期輻輳ウィンドウが許可されます。おそらく4つのセグメントが最大4つのセグメントである環境では、パフォーマンスが大幅に向上する（LFNとLTN）。
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つのセグメントが安全な初期設定であり、2、3、および4の選択に焦点を合わせていることを示しています。今のところ、2つ（RFC2581をフォローしている）を使用しています。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-Every-Segmentです。
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.
推奨事項：無制限のバイトカウントは推奨されません。Van Jacobsonは、Byte Counting [Tcpsatmin]をカウントすることに対して警告を発し、それが破裂につながり、代わりにACK間隔[Ackspacing]を推奨しています。
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-Every-Segmentの背後にある主なアイデアは次のとおりです。
- 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-Every-Segmentは、非対称の帯域幅構成の罰則を避けるために、スロースタートに制限する必要があります。たとえば、クライアントへのリンクがより大きな帯域幅を持っている場合でも、確認者に承認を運ぶ低帯域幅リンクは、渋滞ウィンドウの成長を妨げます[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タイムアウトを待つことなく、未修飾の送信者から2番目のセグメントを受け取ることができます）。始める。送信者が混雑しているときにそうし続けると、回避はモバイルデバイスのバッテリー消費とネットワークのトラフィックに悪影響を与える可能性があります。
This violates a SHOULD in [RFC2581]: delayed acknowledgements SHOULD be used by a TCP receiver.
これは、[RFC2581]でSefsに違反します：遅延承認は、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.
「スロースタート中の遅延ACKの無効化」は技術的には実装できません。受信者は、送信者がSSTHRESH（「スロースタートしきい値」）を交差させ、混雑回避アルゴリズムの使用を開始するタイミングを知る方法がないためです。受信機が初期ウィンドウの増加の推奨事項に従う場合、初期ウィンドウの増加中に遅延ACKを無効にすると、一般的にACKトラフィックを2倍にすることなくTCPウィンドウをより迅速に開きます。ただし、ほとんどの接続がスロースタートのままである場合、このスキームはACKトラフィックを2倍にする可能性があります。
Recommendation: ACK only the first segment on a new connection with no delay.
推奨事項：遅延なしで新しい接続に関する最初のセグメントのみ。
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-SATメーリングリストの大まかなコンセンサスは、非自明の運用ネットワークでは、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.
追加のACKを注入する軽減（「ACK-First-Segment」または「ACK-Every-Segment-During-Slow-Start」）は、今日の適合性TCPS注入が接続のスロースタートフェーズでのみ適用可能です。初期交換の後、接続は通常スロースタートが完了するため、（1）接続が閉じられ、新しい接続が開かれた場合、TCPSは追加のAcksのみを注入します。。
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.
項目（1）は、HTTP/1.0を使用する場合に典型的です。各リクエスト応答トランザクションには新しい接続が必要です。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.
スロースタート中、送信者は各ACKのn 1セグメントを送信することにより、着信ACKストリームに応答します。ここで、Nは着信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の間隔は、送信者がネットワークに送信する速度を効果的に制御し、Bottleneckルーターでのキューイングがほとんどまたはまったく行われない可能性があります[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.
上記のように、リンク層の再送信は、ほとんどのパケット損失を考慮して渋滞が説明するほど十分に減少する可能性があります。それでも、ハンドオフ、ワイヤレスカバレッジを超えて移動することなどによる中断については何もできません。このシナリオでは、これらのレイヤーが互いの取り組みを複製するため、リンク層の再送信とTCPの再送信との相互作用を防ぐことが不可欠です。このような環境では、リンク層に回復する機会を与えるために、TCPの努力を遅らせることは理にかなっているかもしれません。これを念頭に置いて、遅延デュパック[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ヘッダーを調べる必要がないため、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プロトコルは、適切な遅延を選択する機能に影響を与える可能性があります（静的または動的に）。一般に、リンクレベルの再送信時間の大幅な変動は、遅延デュパックスキームのパフォーマンスに悪影響を与える可能性があります。さらに、セクション4.10.3で説明したように、遅延デュパックやその他のいくつかのスキーム（Snoop [Snoop]など）は、特定のタイプのネットワークリンクでのみ有益です。
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.
[TCPHP]のセクション1.1によると、サックは多くのLTNで役に立たない場合があります。特に、LFNレジームでは、特に大きなウィンドウが使用されている場合は、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.
したがって、ワイヤレスリンクにバーストエラーとうっ血の可能性が高い場合を除き、サックの複雑さは正当化できない場合があります。非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ウィンドウを備えたサックの使用を推奨し、これが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.
Berkeleyの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でのパフォーマンスの向上のために、今すぐサックを実装してください。
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、ベガス]。これらのヒューリスティックの自然な拡張により、送信者は輻輳によって引き起こされる損失とその他の原因を区別できます。送信者ベースのヒューリスティックの信頼性に関する研究結果は不利です[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）、および明示的な遅延デュパックアクティベーション通知（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は、IPヘッダーのTOSバイトを使用して、混雑情報（ECN対応および渋滞が発生する）を運びます。このバイトはIPSECで暗号化されていないため、IPSECを使用して暗号化されたTCP接続でECNを使用できます。
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は窓を閉じてスロースタートを呼び出すことにより、混雑に応答します。長距離ネットワークは、この状態から回復するのに特に長い時間がかかります。したがって、LTNの輻輳を回避することが不可欠です。これを改善するために、インターネット全体のルーターの強化として、アクティブキュー管理手法が提案されています[赤]。これらのメカニズムの展開の主な動機は、ルーターの平均キューサイズを制御することにより、「輻輳崩壊」（サービスの深刻な分解）を防ぐことです。平均キューの長さが増加すると、ランダムな早期検出[赤]は、パケットを削除する可能性を高めます。
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.
- ルーターのパケットドロップを削減します。重度の混雑が始まる前にいくつかのパケットを落とすことにより、赤はパケットのバーストを落とすことを避けます。言い換えれば、目的は、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."
アクティブキュー管理には、2つのコンポーネントがあります。（1）ルーターがリソースを使い果たす前に混雑を検出し、（2）何らかの渋滞表示を提供します。赤のドロップパケットは、後者の一例にすぎません。混雑を示す別の方法は、「腐敗の損失の検出：明示的な通知」で上記で説明したように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やWebブラウジングなど）がバルク転送セッションと共存するには、公平性が必要です。ここに提案が含まれます。
- 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.
通信パスのワイヤレスリンク部分にのみ実装されていても、これらの提案はワイヤレスLTN環境で魅力的です。これは、インタラクティブアプリケーションの新しい接続が、利用可能なすべての帯域幅を使用してバルクTCP転送がすでに安定しているときに開始するのが難しい可能性があるためです。
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.
上記のベースアーキテクチャでは、モバイルデバイスは通常、特定の時間に1つのワイヤレスピア、つまり中間ノードと直接通信します。一部のW-wansでは、同じセル内の他の携帯電話に直接対処することができます。このようなワイヤレスピアとの直接通信は、空間的に異なるパスを横断する可能性があり、それぞれが統計的に独立した無線リンク特性を示す場合があります。チャネル状態依存パケットスケジューリング（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].
このアイデアのさらなる改良は、ワイヤレス強化CBQとCSDP [FSS98]を組み合わせることで、公平性とスループットの両方を改善できることを示唆しています。
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.
アイデアは、エンドツーエンドのTCP接続を2つのはっきりと区別する接続に置き換えることです。1つはワイヤレスリンク全体、もう1つはワイヤーラインのカウンターパートにあります。結果として得られる2つの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.
Split-TCPの提案には、エンドツーエンドのセマンティクスを放棄することでパフォーマンスの改善を達成するI-TCP [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アーキテクチャ[Mowgli]は、輸送層だけでなく、すべてのプロトコル層でさまざまな強化をサポートするスプリットアプローチを提案しています。Mowgliは、LTNリンク上のTCP/IPコアプロトコルをLTNリンク[krlka97]用に調整されたカスタムプロトコルに置き換えるオプションを提供します。さらに、プロトコルはLTNSに役立つさまざまな機能を提供します。たとえば、共有フロー制御とともに同時接続の優先ベースの多重化を提供するため、帯域幅の集約的な背景転送がある場合でも、インタラクティブなアプリケーションへのリンク容量をタイムリーに提供します。また、このオプションを使用して、Mowgliはモバイルデバイスにソケットセマンティクスを保存して、レガシーアプリケーションを修正していないことを実行できます。
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.
- エンドツーエンドのTCP接続を2つの部分に分割することは、Wirelineインターネットパスからワイヤレスリンクの問題を保護する簡単な方法です。したがって、分割された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パスの一部またはすべてのリンク特性がわかっています。たとえば、特定のリンクを使用すると、リンクがパケットの信頼できる配信、パケットが順番に配信されないこと、またはリンクが混雑の対象ではないことがわかっている場合があります。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接続を2つの別々の接続に分割すると、ワイヤレスリンク上のTCPパフォーマンスを改善するために、さまざまな最近の提案を早期に展開できます。モバイルデバイスと中間ノードのTCP実装のみを変更する必要があるため、膨大な数のインターネットホストが変更されていないLegacy 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アプローチに対する主な批判の1つは、TCPエンドツーエンドのセマンティクスを破ることです。これには、他のものよりも深刻なさまざまな欠点があります。最も有害な欠点は、おそらくTCP接続を分割すると、IPレイヤーセキュリティメカニズムのエンドツーエンドの使用が無効になり、エンドツーエンドのセキュリティを実現するためにIPSECの適用を排除することです。それでも、IPSECは2つの部分のそれぞれで個別に使用できるため、中間ノードがモバイルデバイスとリモートホストの間のセキュリティ協会のパーティーになることを要求します。ただし、これは、ほとんどの場合、望ましくないまたは容認できない代替品です。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.
- エンドツーエンドのセマンティクスを破ることのもう1つの欠点は、中間ノードのクラッシュが回復できなくなり、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に完全に依存すべきではないため、誇張です。まず、Berkeleyソケットインターフェイスなどの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-LANSとは異なり、W-WANベースステーションは、モバイルデバイスにWirelineインターネットへの接続ポイントを提供していません（このようなベースステーションにはIPスタックさえない場合があります）。代わりに、W-WANネットワークはモビリティを処理し、モバイルデバイスが移動している間は変更されていないワイヤーラインインターネットへの接続ポイントを保持します。したがって、ほとんどのW-wansでは、TCP状態のハンドオーバーは必要ありません。
- 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提案を分割することは推奨されません。MowGliが提案するなど、ワイヤレスリンクにカスタムプロトコルを展開することは推奨されません。このメモは、（1）カスタムプロトコルを設計する代わりにTCPを改善し、（2）エンドツーエンドセッションを常に許可することを好むためです。
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].
MowGliシステムは、クライアントとサーバー、モバイルデバイスのエージェント、および中間ノードのプロキシの間にアプリケーションレベルのエージェントプロキシペアを追加するための完全なサポートを提供します。このようなペアは、アプリケーションに対して明示的または完全に透過的である可能性がありますが、常にエンドユーザー制御の下でです。アプリケーション固有のプロキシで達成された強化の良い例には、Mowgli 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:
BerkeleyのSnoopプロトコル[Snoop]は、リンク層の信頼性メカニズムを分割接続アプローチと混合するハイブリッドスキームです。エンドツーエンドのセマンティクスが保持されているという点で、スプリットTCPアプローチよりも改善されています。スヌープは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. レシーバーから送信者に戻る途中の重複したAcksを抑制し、後者での迅速な再送信と混雑回避を回避します。
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.
したがって、SNoopプロトコルは、ワイヤレスリンクレイヤーがローカルにパケットを再送信するときに、TCP送信者による不必要な高速再送信を避けるように設計されています。Snoopエージェントを使用しないシステムを検討してください。中間ノードを介してレシーバーRにパケットを送信するTCP送信者を検討してください。送信者がワイヤレスレシーバーRに転送されるパケット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].
Snoop [Snoop]は、TCP Dupacksを適切に（中間ノードで）ドロップすることにより、この問題を扱います。遅延デュパック（セクション4.5を参照）は、中間ノードでの変更を必要とせずにスヌープを近似しようとします。このようなスキームは、ワイヤレスエラーによる急速な再送信の可能性が緩和できない場合にのみ必要です。特に、ワイヤレスリンクがストップアンドゴープロトコルを使用している場合（またはそれ以外の場合はパケットを注文する）、これらのスキームはあまり有益ではありません。また、ワイヤレスリンクの帯域幅遅延製品が4つのセグメントよりも小さい場合、中間ノードが失われたパケットが再送信される前に3つの新しいパケットを送信する可能性が小さい場合が少なくなります。4つのパケット未満のワイヤレス帯域幅遅延製品を使用して、高速再送信をトリガーするには少なくとも3つのデュパックが必要であるため、スヌープや遅延デュパックなどのスキームは必要ありません（リンク層が適切に設計されていない限り）。逆に、ワイヤレス帯域幅遅延製品が十分に大きい場合、Snoopは大幅なパフォーマンス改善を提供できます（標準の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スキームは、Snoopがうまく機能する環境でパフォーマンスの利点を提供する傾向があります。一般に、遅延Dupacksスキームによって達成されるパフォーマンスの改善は、混雑と伝送エラーによるパケット損失率の関数です。輻輳関連の損失が発生すると、遅延デュパックスキームは不必要に再送信を遅らせます。したがって、輻輳損失が存在する場合、遅延デュパックスキームはスヌープと同じパフォーマンス改善を達成することはできません。ただし、シミュレーション結果[Vaidya99]は、遅延したデュパックが中程度の混雑損失にもかかわらず、パフォーマンスの大幅な改善を達成できることを示しています。
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]は、エンドツーエンドのセマンティクスを保持するという点で、Snoopに似ています。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ヘッダーとペイロードが中間ノードに理解できません。これにより、Snoop（およびWTCP）は、TCPヘッダーを両方向に調べる必要があるため、動作を妨げています。可能なソリューションには次のことが含まれます。
- making the SNOOP (or WTCP) intermediate node a party to the security association between the client and the server
- スヌープ（または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を使用する必要があります。ただし、これらは輸送層の上に実装されており、IPSECほど一部のセキュリティ攻撃（たとえば、TCPシーケンス番号を推測することに基づくもの）に耐性はありません。
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を実装してください。研究結果は勇気づけられ、クライアントもサーバーも変更する必要がなく、中間ノードのみ（袋のない基本的なスヌープ用）を変更する必要がないという点で「目に見えない」最適化です。ただし、上記で説明したように、スヌープを実装することではほとんどまたはまったくありません。
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.
2. ワイヤレスリンクの帯域幅遅延積は、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がハンドオフと切断期間をより適切に処理できるようにすることを目指しています。M-TCPは、ワイヤレスネットワークの端にある要素：スーパーバイザーホスト（SH-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を送信します。中間ノードは、ワイヤレスリンクのフローを監視するため、モバイルが切断されていると想定しているため、モバイルからの確認がない場合、前の記載されているように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:
[RFC1144、IPHC、IPHC-RTP、IPHC-PPP]で定義されたTCPおよびIPヘッダー圧縮のメカニズムは、次の利点を提供します。
- 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.
- ヘッダーのオーバーヘッドを減少させます（512の一般的なTCPセグメントサイズの場合、モバイルIPトンネル内のIPv4/TCPのヘッダーオーバーヘッドは11.7から1％未満に減少する可能性があります。
- 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).
Van Jacobson（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.
推奨事項：特に[IPHC]は、モバイルIPのIP-in-IP [RFC2003]および最小限のカプセル化[RFC2004]、およびパケットを再注文する損失リンクおよびリンク用のTCPヘッダー圧縮に関連するため、実装します。PPP有能なデバイスは[IPHC-PPP]を実装する必要があります。VJヘッダー圧縮は、広く展開されている提案標準であるため、オプションで実装できます。ただし、信頼できるLTNを操作する場合にのみ有効にする必要があります。単一のビットエラーでさえ、完全な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の「ジップ」ファイル）、またはすでに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圧縮を使用するには、関連するディレクティブが「コンテンツエンコード：DEFLATE」および「Accept-Encoding：DEFLATE」[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は、HTTPレベルでのリソースの圧縮をサポートすることを検討しています。これは、テキスト/HTMLなどの一般的な圧縮性MIMEタイプに同等の利点を提供します。これにより、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（ワイヤレスデバイス、つまり、モバイルデバイスでの変更は、（中間ノード）およびNi（ネットワークインフラストラクチャ）で、TCP送信または受信）に固有のものではありません。これらのエンティティは、セクション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 YESウィンドウ（Initial_Window = 2）の増加
Disable delayed ACKs NA WR When stable
during slow start
Byte counting NA WS No
instead of ACK
counting
TCP Header RFC 1144 (PS) WD Yes
compression for PPP IN (see 4.11)
IP Payload RFC 2393 (PS) WD Yes
Compression (simultaneously
(IPComp) needed on Server)
Header RFC 2507 (PS), WD Yes
Compression RFC 2509 (PS) IN (For IPv4, TCP and
Mobile IP, PPP)
SNOOP plus SACK In limited use IN Yes WD (for SACK)
はいwdで限られた使用のスヌーププラスサック（袋用）
Fast retransmit/fast RFC 2581 (PS) WD Yes (should be
recovery there already)
Transaction/TCP RFC 1644 WD No (Experimental) (simultaneously needed on Server)
トランザクション/TCP RFC 1644 WD NO（実験）（同時にサーバーで必要です）
Estimating Slow NA WS No
Start Threshold
(ssthresh)
Delayed Duplicate Not stable WR When stable
Acknowledgements IN (for
notifications)
Class-based Queuing NA WD When stable
on End Systems
Explicit Congestion RFC 2481 (EXP) WD Yes
明示的な混雑RFC 2481（EXP）WDはい
Notification NI
通知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 Plus 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 Plus 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ワーキンググループに深く感謝しています。次の個人も貴重なフィードバックを提供しています：Mark Allman（NASA）、Vern Paxson（Aciri）、Raphi Rom（Technion/Sun）、Charlie Perkins（Nokia）、Peter Stark（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.
この最後のポイントは過小評価されることではありません。中間ノードがエンドツーエンドベースで実行されたものとは異なる操作を実行する場合はいつでも、一般的なセキュリティ上の懸念があります。これは、パフォーマンスを向上させるプロキシに固有のものではありません。特に、Snoopモジュール、ヘッダー圧縮（TCP、UDP、RTPなど）、またはHTTPプロキシを機能させるために、IPSECベースのプライバシーを控える傾向がある場合があります。
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] Partridge、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] Allman、M.、Dawkins、S.、Glover、D.、Griner、J.、Henderson、T.、Heidemann、J.、Kruse、H.、Osterman、S.、Scott、K.、Semke、J.、Touch、J。およびD. Tran、「衛星に関連する進行中のTCP研究」、進行中の作業。
[AGS98] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[AGS98] Allman、M.、Glover、D。およびL. Sanchez、「標準メカニズムを使用した衛星チャネル上のTCPの強化」、BCP 28、RFC 2488、1999年1月。
[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] Allman、M.、Hayes、C.、Ostermann、S。、「より大きな初期ウィンドウを備えたTCPの評価」、Computer Communication Review、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.
[BBKT96] Bhagwat、P.、Bhattacharya、P.、Krishna、A.、Tripathi、S。、「チャネル状態に従ったパケットスケジューリングを使用して、ワイヤレスLANのスループットを強化する」、Proc。IEEE Infocom'96、pp。1133-40、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] Bakshi、B.、P.、Krishna、N.、Vaidya、N.、Pradhan、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] Balakrishnan、H.、Padmanabhan、V.、Seshan、S.、Katz、R。、「ワイヤレスリンク上のTCPパフォーマンスを改善するためのメカニズムの比較」、ACM Sigcomm、カリフォルニア州スタンフォード、1996年8月。
[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] Balakrishnan、H.、Padmanabhan、V.、Katz、R。、「TCPパフォーマンスに対する非対称性の影響」、ACMモバイルネットワークおよびアプリケーション（MONET）、Vol。4、No。3、1999、pp。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回コンピューター通信およびネットワークに関する第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大学、1998年6月、テクニカルレポート98-013。
[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大学、1998年6月、テクニカルレポート98-014。
[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] Brashe、G.、Walke、B。、「新しいGSMフェーズ2一般パケットラジオサービスの概念、サービス、およびプロトコル」、IEEE Communications Magazine、vol。35、No。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] Cheshire、S.、Baker、M。、「蚊のワイヤレスネットワークの経験」、1996年2月。詩
[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] Electronic Industry Alliance（EIA）/Telecommunications Industry Association（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] Hari BalakrishnanとSrinivasan Seshan、「渋滞マネージャー」、作業中の作業。
[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] Chang、H.、Tait、C.、Cohen、N.、Shapiro、M.、Mastrianni、S.、Floyd、R.、Housel、B.、Lindquist、D。、 "Web Browinging in a Wireless環境：Artour Web Expressでの切断および非同期操作」、Proc。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] Demers、A.、Keshav、S。、およびShenker、S。、公正なキューイングアルゴリズムの分析とシミュレーション、インターネットワーキング：研究と経験、Vol。1、1990、pp。3-26。
[ECN] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[ECN] Ramakrishnan、K。およびS. Floyd、「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] Floyd、S。、およびJacobson、V。、パケットネットワークのリンク共有およびリソース管理モデル。IEEE/ACM Transactions on Networking、vol。3 No. 4、pp。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。、 "Controld Multimedia Wireless Link Sharing Sharingを制御しました。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 Communications Magazine、Vol。 31、pp 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.、Lindquist、D。、「WebExpress：ワイヤレス環境でのWebブラウジングを最適化するシステム」、Proc。Mobicom'96、ライ麦、ニューヨーク、米国、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] 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）、「HTTP/1.1、CSS1、およびPNGのネットワークパフォーマンス効果」、ACM SIGCOMM '97、1997年9月、カンヌ、フランス。http /performance /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.、Pereira、R。、およびM. Thomas、「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. Pink、「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. Jacobson、「低速シリアルリンクのIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[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. Bormann、「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.、Badrinath、B.R。、「ハンドオフとシステムのサポート間接TCP/IP。
[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] Jain、R。、「相互接続された不均一なコンピューターネットワークにおける混雑回避のための遅延ベースのアプローチ」、Digital Equipment Corporation、テクニカルレポート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] Karn、P。、「The Qualcomm CDMA Digital Cellular System」Proc。 USENIXモバイルおよびロケーションに依存しないコンピューティングシンポジウム、USENIX Association、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.
[Krlka97] Kojo、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.、Kojo、M.、Laamanen、H.、Raatikainen、K。、「弱く接続されたモバイルワークステーション用の世界的なWebを最適化：間接的アプローチ」、Proc。2nd int。分散環境およびネットワーク環境でのサービスに関するワークショップ、カナダ、ウィスラー、pp。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.、Kojo、M.、Raatikainen、K。、「Mowgli WWWソフトウェア：モバイルWAN環境でのWWWの使いやすさの改善」IEEE Global Internet 1996 Conference、ロンドン、英国、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] Lettieri、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.、Phifer、L.、Wang、Y.、Hovey、R。、「モバイルネットワークコンピューティングプロトコル（MNCP）」、進行中の作業。
[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.
[Mowgli] Kojo、M.、Raatikainen、K.、Alanko、T。、「デジタルセルラー電話ネットワーク上でモバイルワークステーションをインターネットに接続する」、Proc。1994年11月、ニュージャージー州ラトガース大学のモバイルおよびワイヤレス情報システム（Mobidata）に関するワークショップ。Mobile Computing、pp。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.
[MSMO97] Mathis、M.、Semke、J.、Mahdavi、J.、Ott、T。、「TCP輻輳回避アルゴリズムの巨視的挙動」、ACM Sigcomm、Volume 27、Numb3、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] Brown、K。Singh、S。、「モバイルコンピューティングのためのネットワークアーキテクチャ」、Proc。IEEE INFOCOM'96、pp。1388-1396、1996年3月。ftp：//ftp.ece.orst.edu/pub/singh/papers/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] Brown、K。Singh、S。、「M-TCP：Mobile Cellular NetworksのTCP」、ACM Computer Communications Review Vol。27（5）、1997。ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gzで入手可能
[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] Mehta、M.、Vaidya、N。、「Delayded Delaped Deplicate-cooknowledgements：ワイヤレスリンクでのTCPのパフォーマンスを改善する提案」、テキサスA＆M大学、1997年12月24日。http：//www.csで入手可能。tamu.edu/faculty/vaidya/mobile.html
[NETBLT] White, J., "NETBLT (Network Block Transfer Protocol)", Work in Progress.
[NetBlt] White、J。、「NetBlt（ネットワークブロック転送プロトコル）」、進行中の作業。
[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. Paxson、「エンドツーエンドのインターネットパケットダイナミクス」、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.
[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、「インターネットでのキュー管理と混雑回避に関する推奨事項」、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. Sax、「信頼できるデータプロトコル」、RFC 908、1984年7月。
[RFC1030] Lambert, M., "On Testing the NETBLT Protocol over Divers Networks", RFC 1030, November 1987.
[RFC1030] Lambert、M。、「ダイバーネットワークを介したNetBltプロトコルのテストについて」、RFC 1030、1987年11月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144] Jacobson、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] Partridge、C.、Hinden、R。、「信頼できるデータプロトコル（RDP）のバージョン2」、RFC 1151、1990年4月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1397] Braden, R., "Extending TCP for Transactions -- Concepts", RFC 1397, November 1992.
[RFC1397] Braden、R。、「トランザクションのTCPの拡張 - 概念」、RFC 1397、1992年11月。
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[RFC1644] Braden、R。、「T/TCP -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] Leech、M.、Ganis、M.、Lee、Y.、Kuris、R.、Koblas、D。、およびL. Jones、「Socks Protocolバージョン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] Polites、W.、Wollman、W.、Woo、D。、およびR. Langan、「拡張された些細なファイル転送プロトコル（ETFTP）を使用した無線リンクの単純なファイル転送プロトコルを実験する」、RFC 1986、1996年8月。
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[RFC2002] Perkins、C。、「IP Mobility Support」、RFC 2002、1996年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004] Perkins、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] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Aumponredcement Options」、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] Banan、M.、Taylor、M。、およびJ. Cheng、「AT＆T/NEDAの効率的な短いリモート操作（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. Allen、「TLSプロトコルバージョン1」、RFC 2246、1999年1月。
[RFC2414] Allman, M., Floyd, S. and C. Partridge. "Increasing TCP's Initial Window", RFC 2414, September 1998.
[RFC2414] Allman、M.、Floyd、S。、およびC. Partridge。「TCPの最初のウィンドウの増加」、RFC 2414、1998年9月。
[RFC2415] Poduri, K.and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[RFC2415] Poduri、K.およびK. Nichols、「初期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] Shepard、T。およびC. Partridge、「TCPが4つのパケットから3つのバッファーに始まるとき」、RFC 2416、1998年9月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。and W. Stevens、「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] Floyd、S。およびT. Henderson、「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] Balakrishnan、H.、Seshan、S.、Amir、E.、Katz、R。、「ワイヤレスネットワーク上のTCP/IPパフォーマンスの改善」、Proc。1st ACM Conf。1995年11月、カリフォルニア州バークレーのモバイルコンピューティングとネットワーキング（MOBICOM）について。
[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. Stevens、「TCP/IP Illustrated、Volume 1」、Addison-Wesley、1994（MTUサイズの考慮事項についてはセクション2.10、弱いチェックサムのセクション11.3）。
[TCPHP] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[TCPHP] Jacobson、V.、Braden、R。、およびD. Borman、「TCP拡張のためのTCP拡張」、RFC 1323、1992年5月。
[TCPSATMIN] TCPSAT Minutes, August, 1997. Available at: http://tcpsat.lerc.nasa.gov/tcpsat/meetings/munich-minutes.txt.
[TCPSATMIN] TCPSAT議事録、1997年8月。http：//tcpsat.lerc.nasa.gov/tcpsat/meetings/munich-minutes.txtで入手可能。
[Touch97] Touch, T., "TCP Control Block Interdependence", RFC 2140, April 1997.
[Touch97] Touch、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] N. H. Vaidya、M。Mehta、C。Perkins、G。Montenegro、「重複謝辞の遅延：ワイヤレスよりも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.
[ベガス] Brakmo、L.、O'Malley、S。、「TCP Vegas、comming渋面検出と回避のための新しい技術」、Sigcomm'94、London、PP 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] Wang、Z.、Crowcroft、J。、「新しい混雑制御スキーム：スロースタートと検索」、ACMコンピューター通信レビュー、Vol 21、PP 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] Ratnam、K.、Matta、I。、「WTCP：ワイヤレスリンクを備えたネットワークの効率的な伝送制御プロトコル」、テクニカルレポートNU-CCS-97-11、Northeastern University、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。、「モバイルインターネットワーク上のTCPのエンドツーエンドのパフォーマンスの向上」、Proc。モバイルコンピューティングシステムとアプリケーションに関するワークショップ、IEEE Computer Society Press、ロスアラミトス、カリフォルニア、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.モンテネグロサンラボネットワーキングおよびセキュリティグループSun Microsystems、Inc。901 San Antonio Road Mailstop Umpk 15-214 Mountain View、California 94303
Phone: +1-650-786-6288
Fax: +1-650-786-6445
EMail: gab@sun.com
Spencer Dawkins Nortel Networks P.O. Box 833805 Richardson, Texas 75083-3805
スペンサー・ドーキンス・ノーテル・ネットワークP.O.ボックス833805テキサス州リチャードソン75083-3805
Phone: +1-972-684-4827 Fax: +1-972-685-3292 EMail: sdawkins@nortel.com Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland
電話：1-972-684-4827 FAX：1-972-685-3292メール：sdawkins@nortel.comBox 26（Teollisuuskatu 23）Fin-00014 Helsinki Finland
Phone: +358-9-1914-4179
Fax: +358-9-1914-4441
EMail: 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
Vincent Magret Corporate Research Center Alcatel Network Systems、Inc 1201 Campbell Mail Stop 446-310 Richardson Texas 75081 USA M/S 446-310
Phone: +1-972-996-2625
Fax: +1-972-996-5902
EMail: vincent.magret@aud.alcatel.com
Nitin Vaidya Dept. of Computer Science Texas A&M University College Station, TX 77843-3112
コンピュータサイエンスのNitin Vaidya Dept.
Phone: 979-845-0512 Fax: 979-847-8578 EMail: vaidya@cs.tamu.edu
電話：979-845-0512ファックス：979-847-8578メール：vaidya@cs.tamu.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。