RFC2757 日本語訳
2757 Long Thin Networks. G. Montenegro, S. Dawkins, M. Kojo, V.Magret, N. Vaidya. January 2000. (Format: TXT=112988 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループG.モンテネグロ要求をネットワークでつないでください: 2757年のサン・マイクロシステムズ・インクカテゴリ: 情報のS.ダウキンズノーテルはアルカテルN.VaidyaテキサスA&M大学2000年1月にヘルシンキV.MagretのM.Kojo大学をネットワークでつなぎます。
Long Thin Networks
長い薄いネットワーク
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
Abstract
要約
In view of the unpredictable and problematic nature of long thin networks (for example, wireless WANs), arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks.
長い薄いネットワーク(例えば、ワイヤレスのWAN)の予測できないで問題の多い本質から見て、最適化された輸送に到達するのは、困難な仕事です。 私たちは将来の研究項目に伴う既存の提案を見直しました。また、この概要に基づいて、実装のために長い薄いネットワークでメカニズムを推薦します。
Our goal is to identify a TCP that works for all users, including users of long thin networks. We started from the working recommendations of the IETF TCP Over Satellite Links (tcpsat) working group with this end in mind.
私たちの目標は長い薄いネットワークのユーザを含むすべてのユーザのために働いているTCPを特定することです。 私たちは念頭でこの終わりでIETF TCP Over Satelliteリンクス(tcpsat)ワーキンググループの働く推薦から始めました。
We recognize that not every tcpsat recommendation will be required for long thin networks as well, and work toward a set of TCP recommendations that are 'benign' in environments that do not require them.
私たちは、あらゆるtcpsat推薦がまた、長い薄いネットワークに必要であるというわけではないと認めて、1セットのそれらを必要としない環境で'優しい'TCP推薦に向かって取り組みます。
Montenegro, et al. Informational [Page 1] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[1ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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
1つの序論… 3 1.1ネットワークアーキテクチャ… 5 1.2に、ラジオに関する仮定はリンクされます… 6 2、それは、IPかそれともNotであるべきですか? ..................................... 7 2.1 ネットワーク誤りの特性の基礎となります… 7 2.2 非IP代替手段… 8 2.2 .1ワップ… 8 2.2 .2 非IP代替手段を配布します… 9 2.3のIPベースの問題… 9 2.3 .1 MTU[Stevens94、RFC1144]を選びます… 9 2.3 .2 経路MTU発見[RFC1191]… 10 2.3 .3 非TCP提案… 10 3 TCPのためのケース… 11 4 候補最適化… 12 4.1TCP: 現在のメカニズム… 12 4.1 .1 始めと輻輳回避を遅くしてください… 12 .2が速く再送する4.1と速い回復… 12 T/TCP[RFC1397、RFC1644]との4.2接続設定… 14 4.3 スタート提案を遅くしてください… 14 4.3 .1の、より大きい初期のウィンドウ… 14 4.3 .2 遅れた出発の間、窓を育てます… 15 4.3 .2 .1ACK勘定… 15 4.3 .2、.2、ACK、あらゆるセグメント、… 16 4.3 遅い状態で終わる.3は始まります… 17 4.3 .4 遅れた出発の間、ACKsを生成します… 17 4.4 ACKスペース… 17 4.5は写しAcknowlegementsを遅らせました… 18 4.6 選択している承認[RFC2018]… 18 4.7 不正損失を検出します… 19 4.7 .1 明白な通知なしで… 19 4.7 .2 明白な通知で… 20 4.8 活発な待ち行列管理… 21 4.9のスケジューリングアルゴリズム… 21 4.10 TCPとパフォーマンスを機能アップするプロキシ(元気づける)を分けてください… 22 4.10.1 TCPアプローチを分けてください… 23 4.10.2 アプリケーションレベルプロキシ… 26 4.10.3 スヌープとそのDerivatives… 27 4.10.4 DisconnectionのPeriodsを扱うPEPs… 29 4.11 ヘッダー圧縮代替手段… 30 4.12 有効搭載量圧縮… 31 4.13 TCP制御ブロック相互依存[Touch97]… 32 お勧めの最適化の5概要… 33 6結論… 35 7つの承認… 35 8 セキュリティ問題… 35
Montenegro, et al. Informational [Page 2] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[2ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
9 References ................................................... 36 Authors' Addresses ............................................. 44 Full Copyright Statement ....................................... 46
9つの参照箇所… 36人の作者のアドレス… 44 完全な著作権宣言文… 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.
ネットワークリソースへの遍在しているアクセスを可能にするつもりであるなら、最適化されたワイヤレスのネットワークはモバイルComputingが解決しなければならない主要なハードルの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-LAN(例えば、802.11の言いなりになっているネットワーク)とW-WAN(例えば、CDPD[CDPD]、Ricochet、CDMA[CDMA]、いくつかを命名するPHS DoCoMo、GSM[GSM])でモバイルWirelessネットワークを分類できます。 W-WANは最も重大な挑戦を提示します、通常、ワイヤレスのリンク(遅れ*帯域幅生成物として、言い表される)の長さがW-LAN対応者のものの4〜5倍長いなら。 例えば、802.11ネットワークのために遅れ(往復の時間)がおよそ3原稿であり、帯域幅が1.5Mbpsであると仮定して、遅れ*帯域幅生成物は4500ビットです。 RicochetなどのW-WAN、典型的な往復の時間、500の周りに原稿があるかもしれません、そして、(ベストはおよそ230原稿です)持続している帯域幅はおよそ24Kbpsです。 これはおよそ1.5KBと等しい遅れ*帯域幅生成物をもたらします。 近い将来、3番目のGeneration無線電信便は384Kbpsとその他を提供するでしょう。 200msが往復であると仮定して、この場合、遅れ*帯域幅生成物は76.8キロビット(9.6KB)です。 この値は多くのTCP実装によって使用されるデフォルトの8KBのバッファ領域より大きいです。 これは、W-LANに、デフォルトバッファ領域が十分ですが、デフォルト値をくつがえさないと将来のW-WANが効率悪さに(すなわち、それらはパイプをいっぱいにすることができない)作動することを意味します。 200ミリセカンドの潜在がある2Mbpsを提供する3番目のGeneration無線電信便は50KBのバッファを必要とします。
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.
私たちの参考文献一覧への軽い一瞥が明らかにするように、ワイヤレスのネットワーク問題を解決するのを試みる豊富な提案があります。 本書では、私たちは、利用可能であるか調査中の異なったソリューションについて調査して、対応する推薦を発行します。
Montenegro, et al. Informational [Page 3] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[3ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
There is a large body of work on the subject of improving TCP performance over satellite links. The documents under development by the tcpsat working group of the IETF [AGS98, ADGGHOSSTT98] are very relevant. In both cases, it is essential to start by improving the characteristics of the medium by using forward error correction (FEC) at the link layer to reduce the BER (bit error rate) from values as high as 10-3 to 10-6 or better. This makes the BER manageable. Once in this realm, retransmission schemes like ARQ (automatic repeat request) may be used to bring it down even further. Notice that sometimes it may be desirable to forego ARQ because of the additional delay it implies. In particular, time sensitive traffic (video, audio) must be delivered within a certain time limit beyond which the data is obsolete. Exhaustive retransmissions in this case merely succeed in wasting time in order to deliver data that will be discarded once it arrives at its destination. This indicates the desirability of augmenting the protocol stack implementation on devices such that the upper protocol layers can inform the link and MAC layer when to avoid such costly retransmission schemes.
衛星中継の上にTCP性能を向上させる話題への作業の大きいボディーがあります。 IETF[AGS98、ADGGHOSSTT98]のtcpsatワーキンググループによる開発中のドキュメントは非常に関連しています。 どちらの場合も、それは、値からリンクレイヤで前進型誤信号訂正(FEC)を使用することによって媒体の特性を改良することによってBER(ビット誤り率)を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〜200msを超えて決して広がらないでください)。 W-WANは「L」をLFNsと共有します。 しかしながら、また、衛星ネットワークもそれらには高帯域があるかもしれないという意味で「太っています」。 衛星ネットワークは64KBytesの上にしばしば遅れ*帯域幅生成物を持っているかもしれません、その場合、彼らがTCP[TCPHP]に追加問題を引き起こします。 一般に、W-WANはこの振舞いを示しません。 それに従って、このドキュメントは「長い薄いパイプ」であるリンク、およびそれらを含むネットワークと取り引きするだけです: 「長い間、ネットワークを薄くしてください。」 これらの「LTNs」と、私たちは呼びます。
This document does not give an overview of the API used to access the underlying transport. We believe this is an orthogonal issue, even though some of the proposals below have been put forth assuming a given interface. It is possible, for example, to support the traditional socket semantics without fully relying on TCP/IP transport [MOWGLI].
このドキュメントは基本的な輸送にアクセスするのに使用されるAPIの概要を与えません。 私たちは、これが直交した問題であると信じています、与えられたインタフェースを仮定しながら、以下での提案のいくつかを差し出しましたが。 例えば、完全に、TCP/IP輸送[MOWGLI]に依存するというわけではなくて伝統的なソケット意味論をサポートするのは可能です。
Our focus is on the on-the-wire protocols. We try to include the most relevant ones and briefly (given that we provide the references needed for further study) mention their most salient points.
私たちの焦点がワイヤの上のプロトコルにあります。 私たちは、最も関連しているものを含んで、簡潔にそれらの最も顕著なポイントについて言及しようとします(私たちがさらなる研究に必要である参照を提供するなら)。
Montenegro, et al. Informational [Page 4] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[4ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
1.1 Network Architecture
1.1 ネットワークアーキテクチャ
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 Satellite共同体によって考えられたtopologiesの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.
- 何百万もの地上通信線インターネット、レガシーサーバ、およびウェブサイト。
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.
私たちの目標アーキテクチャには、候補ソリューションのdeployabilityに関する意味があります。 重要な要件は特に、私たちがレガシーサーバでネットワークスタックを変更できないということです。 中間的ノードでネットワークスタックを変えるだけが望ましいでしょう、モバイル機器でそれを変えるのは、確かにオプションと恐らく必要性ですが。
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
私たちは非常に効率的にワイヤレスの媒体を使用しますが、伝統的な規制のいくつかに打ち勝つことができるモバイル機器を思い描きます。 すなわち、完全な移動性は、デバイスには使用する柔軟性と機敏さがどれがたまたま最も良いネットワーク接続であってもさえあるのを含意します。
Montenegro, et al. Informational [Page 5] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[5ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
available at any given point in time or space. Accordingly, devices could switch from a wired office LAN and hand over their ongoing connections to continue on, say, a wireless WAN. This type of agility also requires Mobile IP [RFC2002].
時間内にの任意な与えられた点かスペースでは、利用可能です。 それに従って、デバイスは、たとえば、ワイヤレスのWANで続くように彼らの進行中の接続の上でワイヤードなオフィスLANと手から切り替わることができました。 また、このタイプの機敏さはモバイルIP[RFC2002]を必要とします。
1.2 Assumptions about the Radio Link
1.2に、ラジオに関する仮定はリンクされます。
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個のワイヤレスのリンクを高々仮定します(恐らく1つ以上のワイヤレスのホップを包括して)。 しかしながら、これは、ワイヤレスのリンクを特徴付けるために十分ではありません。 追加問題は以下の通りです。
- What are the error characteristics of the wireless medium? The
link may present a higher BER than a wireline network due to
burst errors and disconnections. The techniques below usually
do not address all the types of errors. Accordingly, a complete
solution should combine the best of all the proposals.
Nevertheless, in this document we are more concerned with (and
give preference to solving) the most typical case: (1) higher
BER due to random errors (which implies longer and more
variable delays due to link-layer error corrections and
retransmissions) rather than (2) an interruption in service due
to a handoff or a disconnection. The latter are also important
and we do include relevant proposals in this survey.
- ワイヤレスの媒体の誤りの特性は何ですか? リンクはバースト誤りと断線のためワイヤーラインネットワークより高いBERを寄贈するかもしれません。 通常、以下のテクニックはすべてのタイプの誤りを扱いません。 それに従って、完全解は提案を最もよく結合するべきです。 それにもかかわらず、本書では私たちは(優先を解決に与えてください)最も典型的なケースにさらに関係があります: (1) (2) 移管か断線のために使用中の中断よりむしろ無作為の誤りへのさらに高いBER支払われるべきもの(リンクレイヤのエラー修正と「再-トランスミッション」のためより長くて、より可変な遅れを含意します)。 また、後者も重要です、そして、私たちはこの調査における関連提案を入れます。
- Is the wireless service datagram oriented, or is it a virtual
circuit? Currently, switched virtual circuits are more common,
but packet networks are starting to appear, for example,
Metricom's Starmode [CB96], CDPD [CDPD] and General Packet
Radio Service (GPRS) [GPRS],[BW97] in GSM.
- 無線電信便データグラムが適応しますか、またはそれは仮想の回路ですか? 現在、交換仮想回路は、より一般的ですが、例えば、パケット網は現れ始めています、MetricomのStarmode[CB96]、CDPD[CDPD]と汎用パケット無線システム(GPRS)[GPRS]、GSMの[BW97。]
- What kind of reliability does the link provide? Wireless
services typically retransmit a packet (frame) until it has
been acknowledged by the target. They may allow the user to
turn off this behavior. For example, GSM allows RLP [RLP]
(Radio Link Protocol) to be turned off. Metricom has a
similar "lightweight" mode. In GSM RLP, a frame is
retransmitted until the maximum number of retransmissions
(protocol parameter) is reached. What happens when this limit
is reached is determined by the telecom operator: the physical
link connection is either disconnected or a link reset is
enforced where the sequence numbers are resynchronized and the
transmit and receive buffers are flushed resulting in lost
data. Some wireless services, like CDMA IS95-RLP [CDMA,
Karn93], limit the latency on the wireless link by
retransmitting a frame only a couple of times. This decreases
the residual frame error rate significantly, but does not
provide fully reliable link service.
- リンクはどういう信頼性を提供しますか? それが目標によって承認されるまで、無線電信便はパケット(フレーム)を通常再送します。 彼らはユーザにこの振舞いをオフにさせるかもしれません。 例えば、GSMはRLP[RLP](ラジオLinkプロトコル)をオフにさせます。 Metricomには、同様の「軽量」のモードがあります。 GSM RLPでは、「再-トランスミッション」(プロトコルパラメタ)の最大数に達するまで、フレームは再送されます。 この限界に達しているとき、何が起こるかはテレコムオペレータによって決定されます: そして、物理的なリンク結合切断されるか、またはリンクリセットが一連番号が再連動するところで励行される、ロストデータをもたらしながら洗い流されたバッファを送受信してください。 CDMA IS95-RLP[CDMA、Karn93]のように、いくつかの無線電信便が、ワイヤレスのリンクの上に一度か二度だけフレームを再送することによって、潜在を制限します。 これは、残りのフレーム誤り率をかなり減少させますが、完全に信頼できるリンクサービスを提供しません。
Montenegro, et al. Informational [Page 6] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[6ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
- 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人以上の同輩に演説しますか? それぞれの異なった同輩へのパケットは空間的に異なったワイヤレスの経路を横断するかもしれません。 それに従って、各同輩への経路は非常に異なった特性を示すかもしれません。 全く一般的に、時間内にのポイントを考えて、モバイル機器はいずれでも(中間的ノード)を1人の同輩だけに扱います。 これがそうでないときに、Dependent Packet Schedulingが入るChannel-状態などのテクニックはプレーします(以下の「パケットスケジューリング」というセクションを見ます)。
2 Should it be IP or Not?
2 それは、IPかそれともNotであるべきですか?
The first decision is whether to use IP as the underlying network protocol or not. In particular, some data protocols evolved from wireless telephony are not always -- though at times they may be -- layered on top of IP [MOWGLI, WAP]. These proposals are based on the concept of proxies that provide adaptation services between the wireless and wireline segments.
最初の決定は基本的なネットワーク・プロトコルとしてIPを使用するかどうかということです。 時には、それらはそうであるというわけではないのにもかかわらずの、無線電信から発展されたいくつかのデータプロトコルがいつも特に、そうであるというわけではありません--IP[MOWGLI、WAP]の上では、層にされます。 これらの提案はワイヤレスとワイヤーラインセグメントの間に適合サービスを提供するプロキシの概念に基づいています。
This is a reasonable model for mobile devices that always communicate through the proxy. However, we expect many wireless mobile devices to utilize wireline networks whenever they are available. This model closely follows current laptop usage patterns: devices typically utilize LANs, and only resort to dial-up access when "out of the office."
これはプロキシを通っていつも交信するモバイル機器のための合理的なモデルです。 しかしながら、それらが利用可能であるときはいつも、私たちは、多くのワイヤレスのモバイル機器がワイヤーラインネットワークを利用すると予想します。 このモデルは密接に現在のラップトップ用法パターンに従います: デバイスは、LANを通常利用して、「オフィス」であるときにだけ、ダイヤルアップアクセスに頼ります。
For these devices, an architecture that assumes IP is the best approach, because it will be required for communications that do not traverse the intermediate node (for example, upon reconnection to a W-LAN or a 10BaseT network at the office).
これらのデバイスのために、IPを仮定するアーキテクチャは最も良いアプローチです、それが中間的ノード(例えばW-LANかオフィスの10BaseTネットワークへの再接続に関して)を横断しないコミュニケーションに必要であるので。
2.1 Underlying Network Error Characteristics
2.1 基本的なネットワーク誤りの特性
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
IP、およびIPパケットで運ばれるプロトコルは、比較的弱く[Stevens94、Paxson97]て(いくつかの場合任意)であるチェックサムによる、保護された終わりから終わりです。 インターネットの大部分では、これらのチェックサムは十分です。 ワイヤレスの環境で、生のワイヤレスのリンクの誤りの特性は終わりから端への経路の残りよりあまり強健ではありません。 したがって、それが含む経路に
Montenegro, et al. Informational [Page 7] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[7ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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パケットはネットワークを通して伝播されますが、あて先ホストでは、捨てられます。 例えば、中間的ルータが、UDPかTCPチェックサムではなく、IPヘッダーチェックサムをチェックするのに必要です。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.
このアプローチはおよそPointからポイントへのプロトコル(PPP)のうまくいっている展開に類似しています、強健な縁どっていて16ビットのchecksummingで、Serial線Interfaceプロトコル(SLIP)との交換としてのワイヤーラインネットワークで、1縁どりバイトにもかかわらず、checksummingででない。
[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]を考慮します。
2.2 Non-IP Alternatives
2.2 非IP代替手段
A number of non-IP alternatives aimed at wireless environments have been proposed. One representative proposal is discussed here.
ワイヤレスの環境が目的とされた多くの非IP選択肢が提案されました。 ここで1つの代表している提案について議論します。
2.2.1 WAP
2.2.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
ワイヤレス・アプリケーション・プロトコル(WAP)は移動電話や、ポケットベルや、PDA[WAP]などのワイヤレス機器にアプリケーションフレームワークとネットワーク・プロトコルを指定します。 アーキテクチャはモバイル機器とサーバの間のプロキシを必要とします。WAPプロトコル・スタックはデータグラム輸送サービスの上で層にされます。 そのようなサービスはほとんどのワイヤレス・ネットワークによって提供されます。 例えば、-136である、GSM SMS/USSD、およびCDPDとGSM GPRSのようなIPネットワークにおけるUDP。 コア
Montenegro, et al. Informational [Page 8] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[8ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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プロトコルは要求の間には、ヘッダーキャッシュなどの付加的な機能があって、クライアントとサーバの間には、共有された状態がある2進のHTTP/1.1プロトコルです。
2.2.2 Deploying Non-IP Alternatives
2.2.2 非IP代替手段を配布すること。
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インフラストラクチャを利用しないので。 インターネットへのgatewayedアクセスを提供するのに使用されるどんな非IP選択肢も、IPアドレスと非IPの間でアドレスを写像しなければならなくて、ゲートウェイでIP-レベルセキュリティを終えなければならなくて、ゲートウェイで翻訳なしでIP指向の発見プロトコル(Dynamic Host Configuration Protocol、Domain Name Services、ライトウェイト・ディレクトリ・アクセス・プロトコル、Service Locationプロトコルなど)を使用できません。
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がとてもワイヤレスの環境に不適当であるからである立証責任に直面しています。
2.3 IP-based Considerations
2.3 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の上で層にされた新しいものと同様に伝統的なインターネットアプリケーション・プロトコルであると実装しました。
2.3.1 Choosing the MTU [Stevens94, RFC1144]
2.3.1 MTUを選ぶこと。[Stevens94、RFC1144]
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原稿のよく知られる人間の要素限界を超えるべきではありません。(2) Thisは(1)への予算がパケットを送る最大の時であると考えられるべきです、そして、応答を得てください。 ほとんどのネットワークスタック実装では、(1)はマキシマム・トランスミッション・ユニット(MTU)に非常に依存しています。 最悪の場合には、送る前に対話型アプリケーションからの小型小包はバルク転送アプリケーションから大きいパケットを待たなければならないかもしれません。 トランスミッション時間がしたがって、良い経験則がMTUを選ぶことであるので、より少ない、(はるかに大きくない、)、200原稿
Montenegro, et al. Informational [Page 9] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[9ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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のトランスミッション時間のおよそ半分に平均した待ち時間を減少させるかもしれません。
2.3.2 Path MTU Discovery [RFC1191]
2.3.2 経路MTU発見[RFC1191]
Path MTU discovery benefits any protocol built on top of IP. It allows a sender to determine what the maximum end-to-end transmission unit is to a given destination. Without Path MTU discovery, the default IPv4 MTU size is 576. The benefits of using a larger MTU are:
経路MTU探索はIPの上で築き上げられたどんなプロトコルもためになります。 それで、送付者は、終わりからエンドへのトランスミッション最大の単位が与えられた目的地へのどのくらいであるかを決心できます。 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はどんな与えられたセグメントの中にも誤りの対応するより大きい確率を持っています。 BERは、FECとリンクレイヤ「再-トランスミッション」のような下のレベルのテクニックを使用することで減少するかもしれません。 問題は今、遅れが追加「再-トランスミッション」、およびパケット伝送時間が、より大きいMTUと共に増加するという事実のため問題になるかもしれないということです。
Recommendation: Path MTU discovery is recommended. [AGS98] already recommends its use in satellite environments.
推薦: 経路MTU探索はお勧めです。 [AGS98]は既に衛星環境における使用を推薦します。
2.3.3 Non-TCP Proposals
2.3.3 非TCP提案
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[NETBLT]の直接上、または、UDP[MNCP]の上で基本的なIPデータグラムサービスを仮定して、最適化された輸送を実行します。 それに関連する経験と研究の富を考えて、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]
Montenegro, et al. Informational [Page 10] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[10ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
- 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中傷者は無線の媒体がそのようにある場合であり、それが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がBERを減少させることができるので、混雑(または、リンクの接続性の持続している中断)で事実上、TCPが見るどんな損失も引き起こされます。 現代のW-WAN技術はこれ(CDPD、米国-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.
- 異なった技術の中のHandoffsは同じプロトコル(すなわち、TCP/IP)があらゆる点で使用される場合にだけモバイルIP[RFC2002]によって可能にされます。
- 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の性能がかなり向上できるのを感じます。 したがって、次のセクションでするメカニズムについて議論します。
Montenegro, et al. Informational [Page 11] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[11ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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過剰Satelliteワーキンググループの仕事はこのセクション[AGS98、ADGGHOSSTT98]を準備する際に非常に役立っています。
4.1 TCP: Current Mechanisms
4.1TCP: 現在のメカニズム
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の適合が、より少しな遅れがあるネットワークより対応する遅いのを含意します。 同様に、遅れたACKsはリンクで知覚された潜在を悪化させます。 TCPがユニットのセグメントで混雑ウィンドウを育てるなら、小さいMTUsはさらにさえ適合を遅くするかもしれません。
4.1.1 Slow Start and Congestion Avoidance
4.1.1 遅れた出発と輻輳回避
Slow Start and Congestion Avoidance [RFC2581] are essential the Internet's stability. However there are two reasons why the wireless medium adversely affects them:
遅いStartとCongestion Avoidance[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.
- 窓がACKsの数に基礎づけた送付者増加は受信されました。 それらの到着の速度はもちろん送付者と受信機の間のRTT(往復の時間)に依存しています。(RTTはLTNsのような高い潜在リンクで長い立ち上げ時間を含意します)。 パイプがいっぱいにされるまで、依存は続きます。
- 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を使用するのが重要である理由である、どれ、順番に、必要である、低い損失に伴うリンクレイヤを必要とするか。
4.1.2 Fast Retransmit and Fast Recovery
4.1.2 速く速く再送してください、回復
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送付者が数個の写しACKsを受け取ったら速く[RFC2581]を再送してください。セグメントが失われたと推論するのを許容します。 完全なタイムアウトを待って、その結果、時間を節約することがなくて、送付者はそれがこの無くなっているセグメントであると考えるものを再送します。
Montenegro, et al. Informational [Page 12] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[12ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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. 接続の上に移されるべき典型的な「ファイルサイズ」は比較的小さいです(ウェブ要求(ウェブドキュメント物)はメッセージ、ファイルなどをメールします)。 特に、LTNsのユーザは応答時間がとても長いときに大きい転送を行うことをそれほど望んでいません。
2. If the link has high BER, the congestion window tends to stay
small
2. リンクに高いBERがあるなら、混雑ウィンドウは、小さいままである傾向があります。
3. When an LTN is combined with a highly congested wireline
Internet path, congestion losses on the Internet have the same
effect as 2.
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. 一般的に、ISP/オペレータはそれらのダイヤルで少ない数の1ユーザあたりのバッファ(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. しばしば小さいソケットバッファは、LTNsと共にRTOがふくらませるのを防いで、競争している交通に応じてパケットの量を減少させることが勧められます。
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.
事実上、小さい窓は、送付者がFast Retransmitsを利用するのを防ぎます。 そのうえ、単一の窓の中の複数の損失からの効率的な回復は新規案件(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.
推薦: このとき、Fast RetransmitとFast Recoveryを実行してください。 これは、広く実行された最適化であり、現在、Proposed Standardレベルにあります。 [AGS98]は衛星環境における、Fast Retransmit/速いRecoveryの実現を推薦します。 NewReno[RFC2582]は送付者が単一の窓の部分的なACKsと複数の損失を扱うほうがよいのを明らかに助けますが、ここに実験本質のため推薦されません。 代わりに、SACK[RFC2018]は都合のよいメカニズムです。
Montenegro, et al. Informational [Page 13] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[13ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
4.2 Connection Setup with T/TCP [RFC1397, RFC1644]
4.2 T/TCPとの接続設定[RFC1397、RFC1644]
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.
- それはExperimental 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に関するパーシステントコネクションで利用可能です。(1.1は、より広く配備されます)。
[ADGGHOSSTT98] does not have a recommendation on T/TCP in satellite environments.
[ADGGHOSSTT98]はT/TCPに衛星環境で推薦を持っていません。
4.3 Slow Start Proposals
4.3 遅れた出発提案
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.
インターネットの安定性が最高のであるので、これらの提案は、重要な方法でインターネット混雑レベルに悪影響を与えないのを示さなければなりません。
4.3.1 Larger Initial Window
4.3.1 より大きい初期の窓
Traditional slow start, with an initial window of one segment, is a time-consuming bandwidth adaptation procedure over LTNs. Studies on an initial window larger than one segment [RFC2414, AHO98] resulted in the TCP standard supporting a maximum value of 2 [RFC2581]. Higher values are still experimental in nature.
1つのセグメントの初期の窓で、伝統的な遅れた出発はLTNsの上の手間がかかった帯域幅適合手順です。 1つのセグメント[RFC2414、AHO98]より大きい初期の窓に関する研究は2[RFC2581]の最大値を支持するTCP規格をもたらしました。 より高い値はまだ現実に実験しています。
Montenegro, et al. Informational [Page 14] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[14ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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つのセグメント)は将来、これが性能(LFNsとLTNs)をかなり向上させる環境で許容されるかもしれません。
Recommendation: Implement this on devices now. The research on this optimization indicates that 3 segments is a safe initial setting, and is centering on choosing between 2, 3, and 4. For now, use 2 (following RFC2581), which at least allows clients running query- response applications to get an initial ACK from unmodified servers without waiting for a typical delayed ACK timeout of 200 milliseconds, and saves two round-trips. An initial window of 3 [RFC2415] looks promising and may be adopted in the future pending further research and experience.
推薦: 今、装置でこれを実行してください。 この最適化の研究は、3つのセグメントが安全な初期設定であることを示して、2、3〜4を選ぶことを中心としています。 当分、旅行する状態で丸い2(次のRFC2581)、質問応答アプリケーションを実行しているクライアントがどれで変更されていないサーバから200ミリセカンドの典型的な遅れたACKタイムアウトを待たないで初期のACKを少なくとも手に入れることができるか、そして、およびセーブtwoを使用してください。 3[RFC2415]の初期の窓は、有望に見えて、さらなる今後の未定の研究と経験で採用されるかもしれません。
4.3.2 Growing the Window during Slow Start
4.3.2 遅れた出発の間、窓を育てること。
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.
送付者は受信機から戻るACKsの流れに基づく窓を増加させます。特に遅れた出発の間、この流れは非常に重要です。 研究された2、3の提案が(1)ACK勘定と(2)である、ACK、あらゆるセグメント
4.3.2.1 ACK Counting
4.3.2.1 ACK勘定
The main idea behind ACK counting is:
ACK勘定の後ろの本旨は以下の通りです。
- Make each ACK count to its fullest by growing the window based
on the data being acknowledged (byte counting) instead of the
number of ACKs (ACK counting). This has been shown to cause
bursts which lead to congestion. [Allman98] shows that Limited
Byte Counting (LBC), in which the window growth is limited to 2
segments, does not lead to as much burstiness, and offers some
performance gains.
- 各ACKに十二分に承認されていて(バイトが重要であることで)、ACKsの数の代わりにデータに基づく窓を育てることによって、数えさせてください(ACKが数えて)。 これは、混雑に通じる炸裂を引き起こすために示されました。 [Allman98]は、株式会社Byte Counting(LBC)が同じくらい多くのburstinessに通じないで、いくつかの性能向上を提供するのを示します。(そこでは、窓の成長が2つのセグメントに制限されます)。
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.
推薦: 無制限なバイト勘定は推薦されません。 代わりに、burstinessに通じて、スペース[ACKSPACING]をACKに推薦するので[TCPSATMIN]を数えるバイトに対してジェーコブソン警告をバンに積んでください。
Montenegro, et al. Informational [Page 15] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[15ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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スペースは、ACKsが一貫してただ一つのACKスペースルータを通り抜けるのを必要とします。 この要件はまた、ACK-スペースルータが中間的ノードであるならW-WAN環境にうまくいきます。
Limited byte counting warrants further investigation before we can recommend this proposal, but it shows promise.
私たちがこの提案を推薦できる前に株式会社バイト勘定証明書は調査を促進しますが、それは見込みを示しています。
4.3.2.2 ACK-every-segment
4.3.2.2、ACK、あらゆるセグメント
The main idea behind ACK-every-segment is:
後ろの本旨、ACK、あらゆるセグメント、あります:
- Keep a constant stream of ACKs coming back by turning off
delayed ACKs [RFC1122] during slow start. ACK-every-segment
must be limited to slow start, in order to avoid penalizing
asymmetric-bandwidth configurations. For instance, a low
bandwidth link carrying acknowledgements back to the sender,
hinders the growth of the congestion window, even if the link
toward the client has a greater bandwidth [BPK99].
- ACKsの一定の流れを遅れた出発の間、遅れたACKs[RFC1122]をオフにすることによって戻らせ続けてください。 ACK、あらゆるセグメント、非対称の帯域幅構成を罰するのを避けるために遅れた出発に制限しなければなりません。 例えば、承認を送付者に戻す低い帯域幅リンクは混雑ウィンドウの成長を妨げます、クライアントに向かったリンクにより大きい帯域幅[BPK99]があっても。
Even though simulations confirm its promise (it allows receivers to receive the second segment from unmodified senders without waiting for a typical delayed ACK timeout of 200 milliseconds), for this technique to be practical the receiver must acknowledge every segment only when the sender is in slow start. Continuing to do so when the sender is in congestion avoidance may have adverse effects on the mobile device's battery consumption and on traffic in the network.
シミュレーションは約束を確認しますが(それで、200ミリセカンドの典型的な遅れたACKタイムアウトを待たないで、受信機は変更されていない送付者から2番目のセグメントを受けることができます)、このテクニックが実用的であるように、送付者が遅れた出発にあるときだけ、受信機はあらゆるセグメントを承認しなければなりません。 送付者が輻輳回避中であるときに、そうし続けているのがモバイル機器のバッテリー消費の上と、そして、ネットワークの交通の上に悪影響を及ぼすかもしれません。
This violates a SHOULD in [RFC2581]: delayed acknowledgements SHOULD be used by a TCP receiver.
これは[RFC2581]でSHOULDに違反します: 承認SHOULDを遅らせる、TCP受信機で、使用されてください。
"Disabling Delayed ACKs During Slow Start" is technically unimplementable, as the receiver has no way of knowing when the sender crosses ssthresh (the "slow start threshold") and begins using the congestion avoidance algorithm. If receivers follow recommendations for increased initial windows, disabling delayed ACKs during an increased initial window would open the TCP window more rapidly without doubling ACK traffic in general. However, this scheme might double ACK traffic if most connections remain in slow- start.
「Delayed ACKs During Slow Startを無効にします」は技術的に非実行可能です、受信機に送付者がいつssthresh(「遅れた出発敷居」)を横断して、輻輳回避アルゴリズムを使用し始めるかを知る方法が全くないとき。 受信機が増加する初期の窓のための推薦に続くなら、一般に、ACK交通を倍にしないで、増加する初期の窓の間、遅れたACKsを無効にすると、TCPの窓は、より急速に開けられるでしょう。 しかしながら、ほとんどの接続が遅い始めに留まっているなら、この計画はACK交通を倍にするかもしれません。
Recommendation: ACK only the first segment on a new connection with no delay.
推薦: ACK、遅れのない新しい接続での最初のセグメントだけ。
Montenegro, et al. Informational [Page 16] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[16ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
4.3.3 Terminating Slow Start
4.3.3 遅れた出発を終えること。
New mechanisms [ADGGHOSSTT98] are being proposed to improve TCP's adaptive properties such that the available bandwidth is better utilized while reducing the possibility of congesting the network. This results in the closing of the congestion window to 1 segment (which precludes fast retransmit), and the subsequent slow start phase.
新しいメカニズム[ADGGHOSSTT98]がTCPの適応型の特性を改良するために提案されているので、利用可能な帯域幅はネットワークを充血させる可能性を減少させている間、利用されるほうがよいです。 これは1つのセグメント(どれが断食を排除するかは再送される)、およびその後の遅れた出発フェーズへの混雑ウィンドウの閉鎖をもたらします。
Theoretically, an optimum value for slow-start threshold (ssthresh) allows connection bandwidth utilization to ramp up as aggressively as possible without "overshoot" (using so much bandwidth that packets are lost and congestion avoidance procedures are invoked).
理論的に、遅れた出発敷居(ssthresh)のための最適値で、接続帯域幅利用は「飛び越えてください」なしでできるだけ積極的に昇ります(パケットが帯域幅ですが、とても多くを使用して、無くなるのと輻輳回避手順は呼び出されます)。
Recommendation: Estimating the slow start threshold is not recommended. Although this would be helpful if we knew how to do it, rough consensus on the tcp-impl and tcp-sat mailing lists is that in non-trivial operational networks there is no reliable method to probe during TCP startup and estimate the bandwidth available.
推薦: 遅れた出発敷居を見積もっているのは推薦されません。 私たちがそれをする方法を知っていれば、これは助かるでしょうにが、tcp-implとtcpによって座ったメーリングリストに関する荒いコンセンサスは重要な操作上のネットワークには、TCP始動の間、調べて、利用可能な帯域幅を見積もる確かな方法が全くないということです。
4.3.4 Generating ACKs during Slow Start
4.3.4 遅れた出発の間、ACKsを発生させること。
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.
または、追加ACKsを注入する緩和、(「ACK最初のセグメント」、「ACK、遅れた出発の間のあらゆるセグメント、」、)、向こうでは、conformant TCPsがどんな今日注入するかが、接続の遅れた出発段階の間、適切であるだけです。 初期の交換の後に接続が通常遅れた出発を終了するので、(1) 接続が終えられて、新しい接続が開かれるか、または(2) TCPsが遅れた出発を実行することによって正しく無駄な接続再開を扱うときだけ、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.
HTTP/1.0(それぞれの要求応答取引は新しい接続を必要とする)を使用するとき、項目(1)は典型的です。 HTTP/1.1におけるパーシステントコネクションは、絶えず遅れた出発に戻ることの代わりに輻輳回避における接続を維持するのを手伝います。 これのために、遅れた出発の間に可能にされるだけであるこれらの最適化は大した行動することにおいて偶然になりません。 項目(2)はもちろんHTTPバージョンから独立しています。
4.4 ACK Spacing
4.4 ACKスペース
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倍で送られるデータをもたらします。 それに従って、待ち行列は形成されるでしょう、そして、ボトルネックルータにおける不十分なバッファリングのため、リンクの容量が完全になる前に、パケットは落とされるかもしれません。
Montenegro, et al. Informational [Page 17] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[17ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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.
有効にACKsの間をおくと、送付者がネットワークに伝わって、ボトルネックルータでまず待ち行列をもたらさないかもしれない速度[ACKSPACING]は制御されます。 その上、ackスペースは炸裂のサイズを減少させます。
Recommendation: No recommendation at this time. Continue monitoring research in this area.
推薦: 今回の推薦がありません。 この領域で監視調査を続けてください。
4.5 Delayed Duplicate Acknowlegements
4.5 遅れた写しAcknowlegements
As was mentioned above, link-layer retransmissions may decrease the BER enough that congestion accounts for most of packet losses; still, nothing can be done about interruptions due to handoffs, moving beyond wireless coverage, etc. In this scenario, it is imperative to prevent interaction between link-layer retransmission and TCP retransmission as these layers duplicate each other's efforts. In such an environment it may make sense to delay TCP's efforts so as to give the link-layer a chance to recover. With this in mind, the Delayed Dupacks [MV97, Vaidya99] scheme selectively delays duplicate acknowledgements at the receiver. It is preferable to allow a local mechanism to resolve a local problem, instead of invoking TCP's end- to-end mechanism and incurring the associated costs, both in terms of wasted bandwidth and in terms of its effect on TCP's window behavior.
上に言及されたように、混雑がパケット損失の大部分の原因になることができるくらいリンクレイヤ「再-トランスミッション」はBERを減少させるかもしれません。 それでも、無線の適用範囲などを超えて動いて、handoffsによる中断に関して何もできません。 このシナリオでは、これらの層が互いの努力をコピーするとき、リンクレイヤの「再-トランスミッション」とTCP retransmissionとの相互作用を防ぐのは必須です。 そのような環境で、それは、回復する機会をリンクレイヤに与えるために遅れTCPの努力に理解できるかもしれません。これが念頭にある状態で、Delayed Dupacks[MV97、Vaidya99]計画は選択的に写し承認を受信機に遅らせます。局所機構がローカルの問題を解決するのを許容するのは望ましいです、TCP終わりの終わりまでのメカニズムを呼び出して、関連コストを被ることの代わりに、TCPの窓の振舞いでの無駄な帯域幅とその効果に関する両方。
The Delayed Dupacks scheme can be used despite IP encryption since the intermediate node does not need to examine the TCP headers.
IP暗号化にもかかわらず、中間的ノードがTCPヘッダーを調べる必要はないので、Delayed Dupacks計画を使用できます。
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プロトコルは適切な遅れ(静的かダイナミックである)を選ぶ能力に影響するかもしれません。 一般に、リンク・レベル「再-トランスミッション」回数で表現される重要な可変性はDelayed Dupacks計画の性能に悪影響を持つことができます。 その上、後でセクション4.10.3で議論するように、Delayed Dupacksとある他の計画(スヌープ[スヌープ]などの)は単にあるタイプのネットワークリンクで有益です。
Recommendation: Delaying duplicate acknowledgements may be useful in specific network topologies, but a general recommendation requires further research and experience.
推薦: 写し承認を遅らせるのは特定のネットワークtopologiesで役に立つかもしれませんが、一般的な推薦はさらなる研究と経験を必要とします。
4.6 Selective Acknowledgements [RFC2018]
4.6 選択している承認[RFC2018]
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
[TCPHP]のセクション1.1によると、SACKは多くのLTNsで役に立たないかもしれません。 SACKはLFN政権で特に、役に立ちます、特に大きい窓が使用されているなら、aがあるので
Montenegro, et al. Informational [Page 18] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[18ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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.
複数の1窓あたりのセグメントの損失のかなりの確率。 LTN政権では、TCPの窓がはるかに小さいです、そして、バースト誤りは、持続時間が、複数のセグメントを破損するためにはるかに長くなければなりません。
Accordingly, the complexity of SACK may not be justifiable, unless there is a high probability of burst errors and congestion on the wireless link. A desire for compatibility with TCP recommendations for non-LTN environments may dictate LTN support for SACK anyway.
それに従って、SACKの複雑さは正当でないかもしれません、無線のリンクの上にバースト誤りと混雑の高い確率がない場合。 非LTN環境のためのTCP推薦との互換性に関する願望はとにかくSACKのLTNサポートを決めるかもしれません。
[AGS98] recommends use of SACK with Large TCP Windows in satellite environments, and notes that this implies support for PAWS (Protection Against Wrapped Sequence space) and RTTM (Round Trip Time Measurement) as well.
また、[AGS98]は衛星環境におけるLarge TCP WindowsとのSACKの使用、およびこれがPAWS(保護Against Wrapped Sequenceスペース)とRTTM(丸いTrip Time Measurement)のサポートを含意するというメモを推薦します。
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.
バークレーのスヌーププロトコル研究[スヌープ]は、複数のセグメントが窓[BPSK96]単位で失われているとき、SACKがスヌープのためにスループットを改良するのを示します。 SACKは1つの周遊旅行におけるマルチセグメントの損失からスヌープを回復させます。 この場合、モバイル機器は、何らかの形式の選択している承認を実行する必要があります。 SACKが使用されていないなら、TCPは再送するのが必要である場合無くなっているセグメントが再送信タイマーよりすばらしいかもしれない時として輻輳回避に入るかもしれません。
Recommendation: Implement SACK now for compatibility with other TCPs and improved performance with SNOOP.
推薦: 今、他のTCPsとの互換性とスヌープとの向上した性能のためにSACKを実行してください。
4.7 Detecting Corruption Loss
4.7 不正損失を検出すること。
4.7.1 Without Explicit Notification
4.7.1 明白な通知なしで
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]は受信機で測定されたパケット相互到着時間を使用することで強制的な環境における、より良い結果を報告しますが、intercell移管の間無線の環境で遭遇するタイプの非常に可変な遅れはこれらの発見的教授法を困惑させます。
Recommendation: No recommendation at this time - continue to monitor research results.
推薦: 今回の推薦がありません--研究結果をモニターし続けてください。
Montenegro, et al. Informational [Page 19] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[19ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
4.7.2 With Explicit Notifications
4.7.2 明白な通知で
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]
- Receiver(ELNR)、およびExplicit Delayed Dupack Activation Notification(EDDAN)(可動の受信機への通知)への明白なLoss Notification[MV97]
- Explicit Congestion Notification (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).
これらの提案では、Explicit Congestion Notification(電子証券取引ネットワーク)はインターネットで展開の最も近くで見えて、長い薄いネットワークで何らかの利益を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.
電子証券取引ネットワークは、混雑情報(電子証券取引ネットワークできてCongestionによって遭遇された)を運ぶのにIPヘッダーでTOSバイトを使用します。 このバイトがIPSECでコード化されないので、IPSECを使用することでコード化されたTCP接続のときに電子証券取引ネットワークを使用できます。
Recommendation: Implement ECN. In spite of this, mechanisms for explicit corruption notification are still relevant and should be tracked.
推薦: 電子証券取引ネットワークを実行してください。 これにもかかわらず、明白な不正通知のためのメカニズムは、まだ関連していて、追跡されるべきです。
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.
以下に注意してください。 電子証券取引ネットワークには、悪い状態をさらに悪化させるのを避けるために役に立つ情報を提供しますが、いくつかの制限が無線機器のためにあります。 電子証券取引ネットワークの有能なTCP接続は攻撃的な「再-トランスミッション」のための許可として電子証券取引ネットワークと共にマークされたパケットの不在を解釈するべきではありません。 これに反して、極端なネットワークの混雑の期間、ルータはそれらのバッファは空になっています--ホストが積極的に再送し始めるまさに間違った時間によって明白な通知でマークされたパケットを下げるかもしれません。
Montenegro, et al. Informational [Page 20] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[20ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
4.8 Active Queue Management
4.8 活発な待ち行列管理
As has been pointed out above, TCP responds to congestion by closing down the window and invoking slow start. Long-delay networks take a particularly long time to recover from this condition. Accordingly, it is imperative to avoid congestion in LTNs. To remedy this, active queue management techniques have been proposed as enhancements to routers throughout the Internet [RED]. The primary motivation for deployment of these mechanisms is to prevent "congestion collapse" (a severe degradation in service) by controlling the average queue size at the routers. As the average queue length grows, Random Early Detection [RED] increases the possibility of dropping packets.
上で指摘されたように、TCPは窓を閉鎖して、遅れた出発を呼び出すことによって、混雑に応じます。 長時間の遅延ネットワークは、この状態から回復するには特に長い時かかります。 それに従って、LTNsで混雑を避けるのは必須です。 これを治すために、アクティブな待ち行列管理技術は増進としてインターネット[RED]中のルータに提案されました。 これらのメカニズムの展開に関するプライマリ動機はルータにおける平均した待ち行列サイズを制御することによって「混雑崩壊」(サービスにおける厳しい退行)を防ぐことです。 平均した待ち行列の長さが成長するのに従って、Random Early Detection[RED]はパケットを下げる可能性を増強します。
The benefits are:
利益は以下の通りです。
- Reduce packet drops in routers. By dropping a few packets
before severe congestion sets in, RED avoids dropping bursts of
packets. In other words, the objective is to drop m packets
early to prevent n drops later on, where m is less than n.
- ルータにおけるパケット滴を減少させてください。 厳しい混雑が始まる前にいくつかのパケットを下げることによって、REDは、パケットの炸裂を下げるのを避けます。 言い換えれば、nを防ぐのにおいて早いパケットが後で下げる低下mには目的があります、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."
アクティブなQueue Managementには、2つのコンポーネントがあります: (1) (2) ルータはあらゆる手段を尽くす前に混雑を検出します、そして、それらは何らかの形式の混雑しるしを供給します。 REDを通してパケットを下げるのが、後者に関する1つの例にすぎません。 混雑を示す別の方法が下を超えて議論するように電子証券取引ネットワーク[電子証券取引ネットワーク]を使用することである、「不正損失を検出します:」 「明白な通知。」
Recommendation: RED is currently being deployed in the Internet, and LTNs should follow suit. ECN deployment should complement RED's.
推薦: REDは現在インターネットで配布されています、そして、LTNsは先例に従うはずです。 電子証券取引ネットワークの展開はREDのものの補足となるべきです。
4.9 Scheduling Algorithms
4.9 スケジューリングアルゴリズム
Active queue management helps control the length of the queues. Additionally, a general solution requires replacing FIFO with other scheduling algorithms that improve:
活発な待ち行列管理は待ち行列の長さのコントロールを助けます。 さらに、一般解は、先入れ先出し法を向上する他のスケジューリングアルゴリズムに取り替えるのを必要とします:
Montenegro, et al. Informational [Page 21] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[21ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
1. Fairness (by policing how different packet streams utilize the
available bandwidth), and
1. そして公正(異なったパケットストリームがどう利用可能な帯域幅を利用するかを取り締まるのによる)である。
2. Throughput (by improving the transmitter's radio channel
utilization).
2. スループット(送信機のラジオチャンネル利用を改良するのによる)。
For example, fairness is necessary for interactive applications (like telnet or web browsing) to coexist with bulk transfer sessions. Proposals here include:
例えば、対話型アプリケーション(telnetやウェブ閲覧のような)がバルク転送セッションと共存するのに公正が必要です。 ここでの提案は:
- Fair Queueing (FQ) [Demers90]
- 公正な待ち行列(FQ)[Demers90]
- Class-based Queueing (CBQ) [Floyd95]
- クラスベースの待ち行列(CBQ)[Floyd95]
Even if they are only implemented over the wireless link portion of the communication path, these proposals are attractive in wireless LTN environments, because new connections for interactive applications can have difficulty starting when a bulk TCP transfer has already stabilized using all available bandwidth.
それらが通信路のワイヤレスのリンク部分の上で実装されるだけであっても、これらの提案はワイヤレスの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-WANでは、同じセルの中で直接他のモバイルを扱うのは可能です。 それぞれのそのようなワイヤレスの同輩とのダイレクトコミュニケーションは空間的に異なった経路を横断するかもしれません。それはそれぞれ統計的に独立しているラジオリンクの特性を示すかもしれません。 チャンネル州Dependent Packet Scheduling(CSDP)[BBKT96]は様々なラジオリンク(対象装置によって定義されるように)の状態を追跡して、「良い」状態のラジオリンクに運命づけられたパケットの優遇を与えます。 そして、これが、伝わるのを試みるのを避ける、(承認を予想する、)、その結果、「悪い」ラジオリンク、向上したスループットの同輩。
A further refinement of this idea suggests that both fairness and throughput can be improved by combining a wireless-enhanced CBQ with CSDP [FSS98].
この考えのさらなる気品は、CSDP[FSS98]にワイヤレスで高められたCBQを結合することによって公正とスループットの両方を改良できるのを示します。
Recommendation: No recommendation at this time, pending further study.
推薦: さらなる研究まで今回の推薦がありません。
4.10 Split TCP and Performance-Enhancing Proxies (PEPs)
4.10 分裂TCPとパフォーマンスを機能アップするプロキシ(元気づけます)
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つの異なった技術が満たされるところに何らかのインピーダンス整合を提供することです: 中間的ノードで。
Montenegro, et al. Informational [Page 22] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[22ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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.
考えは明確に異なった2との終わりから終わりへのTCP関係のために接続を取り替えることです: ワイヤレスのリンクの向こう側の1、ワイヤーライン対応者の向こう側のもう片方。 それぞれの2つの結果として起こるTCPセッションが、非常に異なったネットワークの特性の下で作動して、特定の媒体に最もよく合う方針を採るかもしれません。 例えば、特定のLTNトポロジーでは、LTNリンクは非常に長いRTTを持って、どんな追加注文パケットにも知られていなくて、また混雑を受けることがないなら、混雑ウィンドウを縮小しないように最初の写しの後にackとFast Recoveryを再送するようにTCP Fast Retransmitを変更するのにおいて望ましいかもしれません。 そのうえ、長時間の遅延リンクの上、または、比較的高帯域で延着している製品とのリンクの上では、それは比較的大きい初期の窓による「遅れた出発」に望ましいかもしれません、4つのセグメントよりさらに大きいです。 LTNリンクの上に使われるためにこれらの種類のTCP変更を交渉できる間、終わらせる終わりは世界的なインターネットの上でそれらに配布されないでしょう。 基本的なリンクの特性が知られているLTN topologiesでは、世界的なインターネットの上の操作を危険にさらさないで、様々な同様のタイプのパフォーマンス強化を使うことができます。
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を最適化する研究の富、およびインターネットとの互換性がワイヤレスのリンク(下のセクション5で示されるように、高められる)の上のTCPを採用するやむにやまれない理由であっても。
4.10.1 Split TCP Approaches
4.10.1 分裂TCPアプローチ
Split-TCP proposals include schemes like I-TCP [ITCP] and MTCP [YB94] which achieve performance improvements by abandoning end-to-end semantics.
分裂-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リンク[KRLKA97]に調整されるカスタムプロトコルとのLTNリンクの上にTCP/IPコアプロトコルを置き換えるためにオプションを提供します。 さらに、プロトコルは役に立つ様々な特徴にLTNsを提供します。 例えば、共有されたフロー制御と共に同時接続の優先権ベースのマルチプレクシングを提供します、その結果、帯域幅徹底的なバックグラウンド転送があっても、直ちにリンク容量を対話型アプリケーションに提供します。 このオプションでも、Mowgliは、変更されていなくレガシーアプリケーションを実行されることができるように、モバイル機器にソケット意味論を保存します。
Montenegro, et al. Informational [Page 23] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[23ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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つの部品に分けるのは、ワイヤーラインインターネット経路からワイヤレスのリンクの問題を保護する簡単な方法です、逆もまた同様に。 その結果ワイヤレスのリンクの上の地方の問題の局所解を適用する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接続のひとりが単一のホップワイヤレスリンクか非常に限られた数のホップだけに交差するとき、ワイヤレスのTCP経路へのいくつかかすべてのリンクの特性が知られています。 例えば、特定のリンクで、私たちが、リンクが信頼できるパケットの配信を提供するのを知るかもしれませんか、パケットが故障していた状態で提供されないか、またはリンクは混雑を受けることがありません。 TCP経路1のためのこの情報を持っているのは、使われるために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実装だけが、変更される必要があります、その結果、インターネット・ホストの膨大な数が、変更されていなくレガシー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
- 分裂TCPアプローチに対する主な批評の1つはTCP終わりから終わりへの意味論を破るということです。 これには、それの或るものが他のものより厳しい様々な欠点があります。 最も有害な欠点はTCP接続を分けるとたぶん、IP層のセキュリティー対策の終わりから終わりへの使用法が無効にされるということです、終わらせる終わりを達成するためにIPSecのアプリケーションを排除して
Montenegro, et al. Informational [Page 24] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[24ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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.
セキュリティ。 それでも、別々にそれぞれの2つの部品でIPSecを使うことができました、その結果、中間的ノードがモバイル機器とリモートホストとのセキュリティ仲間に関係するようになるのが必要です。 しかしながら、多くの場合、これは望ましくないか容認できない代替手段です。 TLS[RFC2246]やSOCKS[RFC1928]のように、トランスポート層の上の他のセキュリティー対策は終わりから終わりへのセキュリティに使われるべきです。
- Another drawback of breaking end-to-end semantics is that crashes
of the intermediate node become unrecoverable resulting in
termination of the TCP connections. Whether this should be
considered a severe problem depends on the expected frequency of
such crashes.
- 終わりから終わりへの壊れている意味論の別の欠点は中間的ノードのクラッシュがTCP接続の終了をもたらしながら復しなくなるということです。 これが厳しい問題であると考えられるべきであるかどうかそのようなクラッシュの期待度数によります。
- In many occasions claims have been stated that if TCP end-to-end
semantics is broken, applications relying on TCP to provide
reliable data delivery become more vulnerable. This, however, is
an overstatement as a well-designed application should never fully
rely on TCP in achieving end-to-end reliability at the application
level. First, current APIs to TCP, such as the Berkeley socket
interface, do not allow applications to know when an TCP
acknowledgement for previously sent user data arrives at TCP
sender. Second, even if the application is informed of the TCP
acknowledgements, the sending application cannot know whether the
receiving application has received the data: it only knows that
the data reached the TCP receive buffer at the receiving end.
Finally, in order to achieve end-to-end reliability at the
application level an application level acknowledgement is required
to confirm that the receiver has taken the appropriate actions on
the data it received.
- 多くの時に、クレームは述べられていて、それがTCP終わりから終わりへの意味論であるなら壊れている、確実な資料配送を提供するためにTCPを当てにするアプリケーションが、より被害を受け易くなるということです。 よく設計されたアプリケーションがアプリケーションレベルにおける終わりから終わりへの信頼性を獲得する際にTCPを完全に決して当てにするべきであるというわけではないので、しかしながら、これは誇張です。 まず最初に、バークレーのソケットインタフェースなどのTCPへの現在のAPIで、アプリケーションは、以前に送られた利用者データのためのTCP承認がいつTCP送付者に到着するかを知ることができません。 2番目に、アプリケーションはTCP承認において知識があっても、送付アプリケーションは、受信アプリケーションがデータを受信したかどうかを知ることができません: それは、データが犠牲者にTCP受信バッファに達したのを知っているだけです。 最終的に、アプリケーションレベルにおける終わりから終わりへの信頼性を獲得するために、アプリケーションレベル承認が受信機がそれが受け取ったデータへの適切な行動を取ったと確認するのに必要です。
- When a mobile device moves, it is subject to handovers by the
serving base station. If the base station acts as the intermediate
node for the split TCP connection, the state of both TCP endpoints
on the previous intermediate node must be transferred to the new
intermediate node to ensure continued operation over the split TCP
connection. This requires extra work and causes overhead. However,
in most of the W-WAN wireless networks, unlike in W-LANs, the W-
WAN base station does not provide the mobile device with the
connection point to the wireline Internet (such base stations may
not even have an IP stack). Instead, the W-WAN network takes care
of the mobility and retains the connection point to the wireline
Internet unchanged while the mobile device moves. Thus, TCP state
handover is not required in most W-WANs.
- モバイル機器が移行するとき、それは給仕基地局のそばで身柄の引き渡しを受けることがあります。 基地局が分裂TCP接続への中間的ノードとして機能するなら、分裂TCP接続の上の継続運転を確実にするために前の中間的ノードの上の両方のTCP終点の状態を新しい中間的ノードに移さなければなりません。 これは、時間外労働を必要として、オーバーヘッドを引き起こします。 しかしながら、W-WANワイヤレス・ネットワークの大部分では、W-LANなどと異なって、W WAN基地局はワイヤーラインインターネットへの接続拠点をモバイル機器に提供しません(そのような基地局には、IPスタックがしさえしないかもしれません)。 代わりに、W-WANネットワークは、移動性の世話をして、モバイル機器は移行しますが、ワイヤーラインインターネットに変わりがない状態で接続拠点を保有します。 したがって、TCP州の引き渡しはほとんどのW-WANで必要ではありません。
- The packets traversing through all the protocol layers up to
transport layer and again down to the link layer result in extra
overhead at the intermediate node. In case of LTNs with low
- すべてのプロトコルを通して層をトランスポート層と再びリンクレイヤまで横断するパケットは中間的ノードにおける付加的なオーバーヘッドをもたらします。 安値があるLTNsの場合に
Montenegro, et al. Informational [Page 25] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[25ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
bandwidth, this extra overhead does not cause serious additional
performance problems unlike with W-LANs that typically have much
higher bandwidth.
帯域幅、この付加的なオーバーヘッドははるかに高い帯域幅を通常持っている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が提案するようにそのようなものは推薦されません、この注意がいつも終わりから終わりへのセッションを許容しながら習慣プロトコルと(2)を設計することの代わりにTCPを改良しながら優先を(1)に与えるので。
4.10.2 Application Level Proxies
4.10.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.
この頃は、アプリケーションレベルプロキシはインターネットで広く使用されます。 そのようなプロキシはウェブプロキシキャッシュ、リレーMTAs(メール配達エージェント)、および安全な輸送プロキシ(例えば、SOCKS)を入れます。 事実上、アプリケーションレベルプロキシを雇うと、プロキシとの「分裂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リンクで、アプリケーション特有の増進でアプリケーションレベルプロキシを紹介することによって、顕著な追加改良を達成できます。 そのようなプロキシはワイヤレスのリンクの上にアプリケーション・プロトコルの高められたバージョンを使うかもしれません。
Montenegro, et al. Informational [Page 26] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[26ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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システムはクライアントとサーバ(モバイル機器の上のエージェントと中間的ノードの上のプロキシ)の間でアプリケーションレベルエージェント兼プロキシ組を加える全面的な支援を提供します。 そのような組は、明白であるか、またはアプリケーションに完全に透明であるかもしれませんが、それはいつもエンドユーザコントロールであります。 [CTCSM97]、アプリケーション特有のプロキシと共に達成された増進の好例はMowgli WWW[LAKLR95]、[LHKR96]、およびWebExpress[HL96]を含んでいます。
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.
推薦: アプリケーションレベルプロキシの使用法は条件付きにお勧めです: アプリケーションは可能にされたプロキシであるに違いありません、そして、アプリケーションのためにプロキシを雇う決定がいつもユーザコントロールであるに違いありません。
4.10.3 Snoop and its Derivatives
4.10.3 スヌープとそのDerivatives
Berkeley's SNOOP protocol [SNOOP] is a hybrid scheme mixing link- layer reliability mechanisms with the split connection approach. It is an improvement over split TCP approaches in that end-to-end semantics are retained. SNOOP does two things:
バークレーのスヌーププロトコル[スヌープ]はリンク層の信頼性のメカニズムを分裂接続アプローチに混ぜるハイブリッド体系です。 終わりから終わりへの意味論が保有されるので、それは分裂TCPアプローチの上の改良です。 スヌープは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.
したがって、スヌーププロトコルは設計されていて、不要な断食を避けるのがTCP送付者に再送されます、ワイヤレスのリンクレイヤが局所的にパケットを再送するときことです。 スヌープエージェントを使用しないシステムを考えてください。 TCPが中間的ノードで受信機Rにパケットを送る送付者Sであると考えてください。IN。 送付者がINによってワイヤレスの受信機R.Assumeに送られるユーロ(そのオーダーにおける)をパケットA、B、C、Dに送ると仮定してください。パケットBの最初のトランスミッションがワイヤレスのリンクにおける誤りのため失われているので、次に、中間的ノードは次に、Bを再送します。 この場合、受信機RはパケットA、C、D、E、およびB(そのオーダーにおける)を受けます。 パケットCの領収書、D、およびE引き金は承認をコピーします。 TCP送付者が受信するとき、3は承認をコピーして、それは断食が再送する引き金(「再-トランスミッション」、および混雑ウィンドウの減少におけるどの結果)であるか。 速さは、レベルがワイヤレスのリンクの上に再送するリンクにもかかわらず、起こって、スループットを下げながら、再送されます。
Montenegro, et al. Informational [Page 27] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[27ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
SNOOP [SNOOP] deals with this problem by dropping TCP dupacks appropriately (at the intermediate node). The Delayed Dupacks (see section 4.5) attempts to approximate Snoop without requiring modifications at the intermediate node. Such schemes are needed only if the possibility of a fast retransmit due to wireless errors is non-negligible. In particular, if the wireless link uses a stop-and- go protocol (or otherwise delivers packets in-order), then these schemes are not very beneficial. Also, if the bandwidth-delay product of the wireless link is smaller than four segments, the probability that the intermediate node will have an opportunity to send three new packets before a lost packet is retransmitted is small. Since at least three dupacks are needed to trigger a fast retransmit, with a wireless bandwidth-delay product less than four packets, schemes such as Snoop and Delayed Dupacks would not be necessary (unless the link layer is not designed properly). Conversely, when the wireless bandwidth-delay product is large enough, Snoop can provide significant performance improvement (compared with standard TCP). For further discussion on these topics, please refer to [Vaidya99].
適切(中間的ノードで)にTCP dupacksを下げることによって、スヌープ[スヌープ]はこの問題に対処します。 Delayed Dupacks(セクション4.5を見る)は、中間的ノードで変更を必要としないでスヌープに近似するのを試みます。 断食がワイヤレスの誤りのため再送されるaの可能性が非取るにたらない場合にだけ、そのような体系が必要です。 ワイヤレスのリンクが特に停止を使用する、-、-議定書を作りに行ってください、(そうでなければ、配送する、パケットが中で注文される、)、その時、これらの体系はそれほど有益ではありません。 また、ワイヤレスのリンクの帯域幅遅れ製品が4つのセグメントより小さいなら、中間的ノードには無くなっているパケットが再送される前に3つの新しいパケットを送る機会があるという確率もわずかです。 少なくとも3dupacksが断食の引き金となるのに必要であるので、再送してください、4つのパケット、スヌープやDelayed Dupacksなどの体系であるだろうより少ないワイヤレスの帯域幅遅れ製品が必要な状態で(リンクレイヤが適切に設計される場合)。 ワイヤレスの帯域幅遅れ製品が十分大きいときに、逆に、スヌープは顕著な性能改良(標準のTCPと比べた)を提供できます。 これらの話題のさらなる議論について、[Vaidya99]を参照してください。
The Delayed Dupacks scheme tends to provide performance benefit in environments where Snoop performs well. In general, performance improvement achieved by the Delayed Dupacks scheme is a function of packet loss rates due to congestion and transmission errors. When congestion-related losses occur, the Delayed Dupacks scheme unnecessarily delays retransmission. Thus, in the presence of congestion losses, the Delayed Dupacks scheme cannot achieve the same performance improvement as Snoop. However, simulation results [Vaidya99] indicate that the Delayed Dupacks can achieve a significant improvement in performance despite moderate congestion losses.
Delayed Dupacks体系は、スヌープがよく振る舞う環境に性能利益を提供する傾向があります。 一般に、Delayed Dupacks体系によって達成された性能改良は混雑と伝送エラーによるパケット損失率の関数です。 混雑関連の損失が発生すると、Delayed Dupacks体系は不必要に「再-トランスミッション」を遅らせます。 したがって、混雑の損失の面前で、Delayed Dupacks体系はスヌープと同じ性能改良を実現できません。 しかしながら、シミュレーションの結果[Vaidya99]は、適度の混雑の損失にもかかわらず、Delayed Dupacksが性能におけるかなりの改善を達成できるのを示します。
WTCP [WTCP] is similar to SNOOP in that it preserves end-to-end semantics. In WTCP, the intermediate node uses a complex scheme to hide the time it spends recovering from local errors across the wireless link (this typically includes retransmissions due to error recovery, but may also include time spent dealing with congestion). The idea is for the sender to derive a smooth estimate of round-trip time. In order to work effectively, it assumes that the TCP endpoints implement the Timestamps option in RFC 1323 [TCPHP]. Unfortunately, support for RFC 1323 in TCP implementations is not yet widespread. Beyond this, WTCP requires changes only at the intermediate node.
WTCP[WTCP]は終わりから終わりへの意味論を保存するという点においてスヌープと同様です。 WTCPでは、中間的ノードは、ワイヤレスのリンクの向こう側に地方の誤りから克服しながらそれが過ごす時間を隠すのに複雑な体系を使用します(これは、エラー回復のため「再-トランスミッション」を通常含んでいますが、また、混雑に対処しながら費やされた時間を含むかもしれません)。 考えは送付者が往復の時間の滑らかな見積りを引き出すことです。 力を発揮するために、それは、TCP終点が、TimestampsがRFC1323[TCPHP]のオプションであると実装すると仮定します。 残念ながら、TCP実装におけるRFC1323のサポートはまだ広範囲ではありません。 これを超えて、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
スヌープとWTCPはワイヤードなインターネットで携帯用のワイヤレス機器とTCPサーバの間のトラフィックで調べて、操作する中間的ノードを必要とします。 IPトラフィックが暗号化されていて、中間的ノードがもちろん共有しない場合、スヌープとWTCPは働いていません。
Montenegro, et al. Informational [Page 28] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[28ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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.
モバイル機器と終わりから終わりへのその同輩とのセキュリティ仲間。 また、彼らは、データと対応するACKsの両方が同じ中間的ノードを横断するのを必要とします。 その上、中間的ノードがトランスポート層でワイヤレスのリンクの反対側にパケットを再送するなら、これはリンクレイヤのそばに取り組みをコピーするかもしれません。 スヌープはデザイナーによって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の超能力ヘッダー(輸送かトンネルモードのどちらかによる)を通したIPパケットの暗号化はTCPヘッダーとペイロードを中間的ノードに難解にします。 これは、両方の方向にTCPヘッダーを調べるのが必要であるので働いているので、スヌープ(そして、WTCP)を排除します。 可能なソリューションは以下にかかわります。
- 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
- SNOOPingの中間的ノードで終えられたIPSECトンネリングモード
However, these techniques require that users trust intermediate nodes. Users valuing both privacy and performance should use SSL or SOCKS for end-to-end security. These, however, are implemented above the transport layer, and are not as resistant to some security attacks (for example, those based on guessing TCP sequence numbers) as IPSEC.
しかしながら、これらのテクニックは、ユーザが中間的ノードを信じるのを必要とします。 プライバシーと性能の両方を評価するユーザは終わりから終わりへのセキュリティにSSLかSOCKSを使用するべきです。 これらは、しかしながら、トランスポート層を超えて実装されて、いくつかのセキュリティー攻撃(例えば、ものは一連番号をTCPを推測するのに基礎づけた)にIPSECほど抵抗力がありません。
Recommendation: Implement SNOOP on intermediate nodes now. Research results are encouraging, and it is an "invisible" optimization in that neither the client nor the server needs to change, only the intermediate node (for basic SNOOP without SACK). However, as discussed above there is little or no benefit from implementing SNOOP if:
推薦: 今、中間的ノードの上でスヌープを実装してください。 研究結果は奨励しています、そして、クライアントもサーバも、変化する必要がないので、それは「目に見えません、な」最適化です、中間的ノード(SACKのない基本的なスヌープのために)だけ。 しかしながら、スヌープを実装するのからの利益が上で議論するようにまずない、:
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つのセグメントより小さいです。
4.10.4 PEPs to handle Periods of Disconnection
4.10.4 DisconnectionのPeriodsを扱うPEPs
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
断線の一区切りはワイヤレス・ネットワークで非常に一般的です、財源不足による移管(接続を下げる)か自然な障害の間。 これらの期間、TCP送付者は予想された承認を受けません。 再送信タイマの満了のときに、これで、TCPはすべての関連する欠点で混雑ウィンドウを閉じます。 パケットを再送するのは無駄です。
Montenegro, et al. Informational [Page 29] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[29ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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が断線のhandoffsと一区切りをよりよく扱うのを可能にするのを[M-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.
この中間的ノードは送付者からモバイル機器に来るトラフィックをモニターします。 中間的ノードから送付者に送られたACKsが事実上モバイルノードによって送られたものであるので、それは終わりから終わりへの意味論を破りません。 原則は一般に、最後のバイトを認められない状態でおくことです。 したがって、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に知らせるでしょう。(SH-TCPはACKに前のパラグラフで説明されるように送付者の窓を閉じさせるでしょう)。 中間的ノードは、再接続されるようにマークされた写し承認を受けるとき、モバイルが再び接続されることを学びます。 ここに、それは、写しACKを送付者に送って、窓を育てます。 送付者出口は従来と同様同じレートで伝わるモードと履歴書を固持しています。 それは、以前にモバイルノードによる不承認のどんなデータも再送することによって、始まります。 前の中間システムが窓を縮小できるので、非重なっているか非柔らかいhandoffsは軽量です、そして、モバイルから指示を受けるとすぐに、新しい方はそれを変更します。
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インプリメンテーションが扱う不確実性は正しく窓のアップデートのゼロに合っています。 このスペースで開発を追跡し続けてください。
4.11 Header Compression Alternatives
4.11 ヘッダー圧縮代替手段
Because Long Thin Networks are bandwidth-constrained, compressing every byte out of over-the-air segments is worth while.
Long Thin Networksが帯域幅で抑制して、あらゆるバイトを圧縮している、過剰、空気、セグメント価値があります。
Mechanisms for TCP and IP header compression defined in [RFC1144, IPHC, IPHC-RTP, IPHC-PPP] provide the following benefits:
TCPのためのメカニズムと中で定義されたIPヘッダー圧縮[RFC1144、IPHC、IPHC-RTP、IPHC-PPP]は以下の利益を提供します:
- Improve interactive response time
- 対話的な応答時間を改良してください。
- Allow using small packets for bulk data with good line efficiency
- 大量のデータに良い系列効率で小型小包を使用させてください。
Montenegro, et al. Informational [Page 30] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[30ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
- 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).
ヴァン・ジェーコブソン(VJ)ヘッダー圧縮[RFC1144]は広く配布されるTCP Header圧縮のためにProposed Standardについて説明します。 それは、コンプレッサーと減圧装置の間の同期の損失を検出するのに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のIPにおける[RFC2003]とMinimal Encapsulation[RFC2004]に関連して、TCPヘッダー圧縮に損失性リンクに関連して、その追加注文パケットをリンクするとき。 PPPのできるデバイスは[IPHC-PPP]を実装するはずです。 VJヘッダー圧縮は、それが広く配布しているProposed Standardであるので、任意に実装されるかもしれません。 しかしながら、信頼できるLTNsの上で作動するときだけ、それは可能にされるべきです、ただ一つの噛み付いている誤りさえ最もたぶん下げられる完全なTCPの窓をもたらすでしょう、したがって、高価な回復が遅れた出発であとに続いていて。
4.12 Payload Compression
4.12 有効搭載量圧縮
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有効搭載量Compressionプロトコル(IPComp)」[IPPCP]は任意のIPセグメントペイロードに一般的な圧縮アルゴリズムを適用できるところでフレームワークを定義します。 IPペイロード圧縮はある種の適所最適化です。 IP-レベルセキュリティがIPペイロードを無作為のbitstreamsに変換するので、それが必要です、一般的に配布しているよりコンパクトに表すことができる余分な「情報」がないのを持っているペイロードに直面しているリンクレイヤ圧縮機構を破って。
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圧縮を使用するために、関連指示は以下の通りです。 「以下を内容でコード化します」 そして、「空気を抜いてください」、「コード化を受け入れます:、」 「空気を抜いてください。」[HTTP PERF]
Montenegro, et al. Informational [Page 31] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[31ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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 SHOULDを使用する実装HTTP/1.1する圧縮はお勧めです。
4.13 TCP Control Block Interdependence [Touch97]
4.13 TCP制御ブロック相互依存[Touch97]
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は接続状態、現在の往復の時間、輻輳制御または最大のセグメントサイズなどの1接続あたりの情報を保守します。 同じホストには、第1がまだアクティブである間、新しい接続を創造しながら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デバイスのユーザは頻繁にサーバの同じサーバかセットに接続を要求します。 例えば、それらのメールを読み込むか、または他のサーバに接続を開始するなら、デバイスは、いつも同じEメールサーバか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]に対する仕事は、それらをネットワーク状態により融通がきくようにするようにプロトコルとアプリケーションの中で情報交換のこの概念を広めるかもしれません。
Montenegro, et al. Informational [Page 32] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[32ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
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提案は、インターネットDrafts(I-D)かCommentsのためのRequest(RFC)のどちらかです。 前者は準備段階です。 RFCsのいくつかのタイプがあります。 Draft Standards(DS)は標準化過程であり、まだ改正を受けているかもしれないProposed Standard(PS)より多くの重さを運びます。 または、情報、Experimental RFCsは規格を指定しません。 他の提案は、ほとんど公開レビューがない孤立している取り組みと、産業支援を得るという未知の可能性です。
"Implemented at" indicates which participant in a TCP session must be
modified to implement the proposal. Legacy servers typically cannot
be modified, so this column indicates whether implementation happens
at either or both of the two nodes under some control: mobile device
and intermediate node. The symbols used are: WS (wireless sender,
that is, the mobile device's TCP send operation must be modified), WR
(wireless receiver, that is, the mobile device's TCP receive
operation must be modified), WD (wireless device, that is,
modifications at the mobile device are not specific to either TCP
send or receive), IN (intermediate node) and NI (network
infrastructure). These entities are to be understood within the
context of Section 1.1 ("Network Architecture"). NA simply means "not
applicable."
「実装される、」 提案を実装するようにTCPセッションのどの関係者を変更しなければならないかを示します。 レガシーサーバを通常変更できないので、このコラムは、実装が何らかのコントロールの下における2つのノードのどちらかか両方で起こるかどうかを示します: モバイル機器と中間的ノード。 使用されるシンボルは以下の通りです。 WS(ワイヤレスの送付者、変更されていて、すなわち、モバイル機器のTCPは操作必須を送る)、WR(ワイヤレスの受信機、変更されていて、すなわち、モバイル機器のTCPは操作必須を受ける)、WD(ワイヤレス機器、すなわち、モバイル機器での変更はTCPが送るか、または受けるどちらかに特定でない)、IN(中間的ノード)、およびNI(ネットワークインフラ)。 これらの実体はセクション1.1(「ネットワークアーキテクチャ」)の文脈の中で理解されることです。 NAは、「適切でないこと」を単に意味します。
The "Recommendation" column captures our suggestions. Some mechanisms are endorsed for immediate adoption, others need more evidence and research, and others are not recommended.
「推薦」コラムは私たちの提案を得ます。 いくつかのメカニズムが即座の採用のために是認されます、そして、他のものは、より多くの証拠と研究を必要とします、そして、他のものは推薦されません。
Name Stability of Implemented Recommendation
the Proposal at
==================== ============= =========== =================
実装している推薦の安定性を提案と命名します。==================== ============= =========== =================
Increased Initial RFC 2581 (PS) WS Yes Window (initial_window=2)
増強された初期のRFC2581(PS)WSはいウィンドウ(初期の_の窓=2)
Disable delayed ACKs NA WR When stable during slow start
遅れた出発の間、遅れたACKs NA WR Whenがうまやであると無効にしてください。
Byte counting NA WS No instead of ACK counting
ACK勘定の代わりにNA WSノー、を数えるバイト
Montenegro, et al. Informational [Page 33] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[33ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
TCP Header RFC 1144 (PS) WD Yes compression for PPP IN (see 4.11)
TCP Header RFC1144(PS)WD、はい、PPP INのための圧縮(4.11を見ます)
IP Payload RFC 2393 (PS) WD Yes Compression (simultaneously (IPComp) needed on Server)
IP有効搭載量RFC2393(PS)WDはい圧縮(同時にServerで必要である(IPComp))
Header RFC 2507 (PS), WD Yes
Compression RFC 2509 (PS) IN (For IPv4, TCP and
Mobile IP, PPP)
ヘッダーRFC2507(PS)、WDはい圧縮RFC2509(PS)IN(IPv4、TCP、およびモバイルIPのためのppp)
SNOOP plus SACK In limited use IN Yes
WD (for SACK)
スヌープと制限されたSACK Inははい、IN WDを使用します。(袋のための)
Fast retransmit/fast RFC 2581 (PS) WD Yes (should be recovery there already)
速く/断食RFC2581(PS)WDを再送してください、はい。(既にそこでの回復であるべきです)
Transaction/TCP RFC 1644 WD No
(Experimental) (simultaneously
needed on Server)
1644年のトランザクション/TCP RFC WDノー(実験的な)(同時に、Serverで必要です)
Estimating Slow NA WS No Start Threshold (ssthresh)
遅いNa WSがスタート敷居でないと見積もっています。(ssthresh)
Delayed Duplicate Not stable WR When stable
Acknowledgements IN (for
notifications)
遅れたDuplicate Not安定したWR When安定したAcknowledgements IN(通知のための)
Class-based Queuing NA WD When stable on End Systems
End Systemsの上のクラスベースのQueuing NA WD Whenうまや
Explicit Congestion RFC 2481 (EXP) WD Yes
明白な混雑RFC2481(EXP)WDはい
Notification NI
通知Ni
TCP Control Block RFC 2140 WD Yes Interdependence (Informational) (Track research)
TCP制御ブロックRFC2140WDはい相互依存(情報の)(道の研究)
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.
上に、スヌープ、SACK、およびDelayedだけがコピーするテーブルのすべての最適化では、承認は現在、ワイヤレス・ネットワークのためだけに提案されています。 他のものは非無線機器のためにさえ考えられています。 彼らの、より一般的な適用性は研究団体から、より多くの注意と分析を引き付けます。
Of the above mechanisms, only Header Compression (for IP and TCP) and "SNOOP plus SACK" cease to work in the presence of IPSec.
上のメカニズムでは、Header Compression(IPとTCPのための)、および「スヌープとSACK」だけ、が、IPSecの面前で働くのをやめます。
Montenegro, et al. Informational [Page 34] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[34ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
6 Conclusion
6結論
In view of the unpredictable and problematic nature of long thin networks, arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks (LTNs).
長い薄いネットワークの予測できないで問題の多い本質から見て、最適化された輸送に到達するのは、困難な仕事です。 私たちは将来の研究項目に伴う既存の提案を見直しました。また、この概要に基づいて、長い薄いネットワーク(LTNs)で実装のためにメカニズムを推薦します。
7 Acknowledgements
7つの承認
The authors are deeply indebted to the IETF tcpsat and tcpimpl working groups. The following individuals have also provided valuable feedback: Mark Allman (NASA), Vern Paxson (ACIRI), Raphi Rom (Technion/Sun), Charlie Perkins (Nokia), Peter Stark (Phone.com).
作者は深くIETF tcpsatとtcpimplワーキンググループの世話になっています。 また、以下の個人は有益なフィードバックを提供しました: オールマン(NASA)、バーン・パクソン(ACIRI)、Raphi Rom(Technion/Sun)、Charlieパーキンス(ノキア)、ピーター・スターク(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輻輳制御[電子証券取引ネットワーク]で、不従順です。
Montenegro, et al. Informational [Page 35] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[35ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
- Sharing of Network Performance Information (TCP Control Block
Sharing and Congestion Manager module)
- ネットワークパフォーマンス情報の共有(TCP Control Block SharingとCongestionマネージャモジュール)
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.
この最後のポイントは過小評価されないことです: 中間的ノードが終わりから終わりへの基礎で運び出されたものと異なった操作を実行するときはいつも、総合証券関心があります。 性能を高めるプロキシには、これは特定ではありません。 特に、例えば、スヌープモジュール、ヘッダー圧縮(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] ヤマウズラ、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] 「衛星に関連する進行中のTCP研究」というオールマン、M.、ダウキンズ、S.、手袋製造業者、D.、Griner、J.、ヘンダーソン、T.、Heidemann、J.、クルーゼ、H.、オスターマン、S.、スコット、K.、Semke、J.、接触、J.、およびD.チャンは進行中で働いています。
[AGS98] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP
Over Satellite Channels using Standard Mechanisms",
BCP 28, RFC 2488, January 1999.
[AGS98]のオールマン、M.、手袋製造業者、D.、およびL.サンチェス、「衛星の上の高めるTCPは標準のメカニズムを使用することで精神を集中します」、BCP28、RFC2488、1999年1月。
Montenegro, et al. Informational [Page 36] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[36ページ]のRFC2757は2000年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]オールマン、M.、ヘイズ、C.、オステルマン、S.、「より大きい初期のWindowsとのTCPの評価」、コンピュータコミュニケーションは再検討されます、28(3)、1998年7月。
[BBKT96] Bhagwat, P., Bhattacharya, P., Krishna, A., Tripathi,
S., "Enhancing Throughput over Wireless LANs Using
Channel State Dependent Packet Scheduling," in Proc.
IEEE INFOCOM'96, pp. 1133-40, March 1996.
[BBKT96] Bhagwat、P.、バッタチャリヤ、P.、クリシュナ、A.、Tripathi、Procで「ワイヤレスのLANの上でチャンネルの州の依存するパケットスケジューリングを使用することでスループットを高める」S.。 IEEE INFOCOM96年、ページ 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] N. バクシ、B.、P.、クリシュナ、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.、キャッツ、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.とキャッツとR.と「TCP性能への非対称の効果」とACMのモバイルNetworksとApplications(モネ)、Vol.4、No.3、1999、ページ 219-241.
[BV97] S. Biaz and N. H. Vaidya, "Distinguishing Congestion
Losses from Wireless Transmission Losses: A Negative
Result," Seventh International Conference on Computer
Communications and Networks (IC3N), New Orleans,
October 1998.
[BV97]S.BiazとN.H.Vaidya、「放送の損失と混雑の損失を区別します:」 「否定的結果」とコンピュータコミュニケーションに関する第7国際会議とネットワーク(IC3N)、ニューオリンズ、1998年10月。
[BV98] Biaz, S., Vaidya, N., "Sender-Based heuristics for
Distinguishing Congestion Losses from Wireless
Transmission Losses," Texas A&M University, Technical
Report 98-013, June 1998.
[BV98]Biaz、S.、Vaidya(N.)を「Wireless Transmission LossesからのDistinguishing Congestion Lossesのための発見的教授法を送付者と同じくらい基礎づけさせました」、テキサスA&M大学、Technical Report98-013、1998年6月。
[BV98a] Biaz, S., Vaidya, N., "Discriminating Congestion
Losses from Wireless Losses using Inter-Arrival Times
at the Receiver," Texas A&M University, Technical
Report 98-014, June 1998.
[BV98a] N. Biaz、S.、Vaidya、「ワイヤレスの損失と受信機への相互到着時間を使用することで混雑の損失を区別する」テキサスA&M大学、技術報告書98-014(1998年6月)。
[BW97] Brasche, G., Walke, B., "Concepts, Services, and
Protocols of the New GSM Phase 2+ general Packet Radio
Service," IEEE Communications Magazine, Vol. 35, No.
8, August 1997.
IEEE Communications Magazine、Vol.35、1997年8月No.日8[BW97]Brascheと、G.と、Walkeと、B.と、「New GSM Phase2+一般的なPacket Radio Serviceの概念、Services、およびプロトコル」
Montenegro, et al. Informational [Page 37] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[37ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
[CB96] Cheshire, S., Baker, M., "Experiences with a Wireless
Network in MosquitoNet," IEEE Micro, February 1996.
Available online as:
http://rescomp.stanford.edu/~cheshire/papers
/wireless.ps.
[CB96] チェーシャー州、S.、ベイカー、M.、「MosquitoNetのワイヤレス・ネットワークの経験」、IEEEミクロ、1996年2月。 利用可能である、以下としてのオンライン http://rescomp.stanford.edu/~cheshire/papers /wireless.ps。
[CDMA] Electronic Industry Alliance(EIA)/Telecommunications
Industry Association (TIA), IS-95: Mobile Station-Base
Station Compatibility Standard for Dual-Mode Wideband
Spread Spectrum Cellular System, 1993.
[CDMA]エレクトロニクス産業Alliance(EIA)/電気通信産業連盟(TIA)、-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]のハーリ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] チャン、H.、テート、C.、コーエン、N.、シャピロ、M.、Mastrianni、S.、フロイド、R.、Housel、B.、リンドキスト、D.、「ワイヤレスの環境で以下をブラウズするウェブ」 Procの「ARTourウェブ急行における切断されるのと非同期動作。」 ブダペスト(ハンガリー)1997年9月のMobiCom97年。
[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.と分析と公正な待ち行列アルゴリズムのシミュレーション、インターネットワーキング: 研究とExperience、Vol.1、1990、ページ 3-26.
[ECN] Ramakrishnan, K. and S. Floyd, "A Proposal to add
Explicit Congestion Notification (ECN) to IP", RFC
2481, January 1999.
[電子証券取引ネットワーク] 1999年1月のRamakrishnanとK.S.フロイド、「Explicit Congestion Notification(電子証券取引ネットワーク)をIPに追加するProposal」RFC2481。
[Floyd95] Floyd, S., and Jacobson, V., Link-sharing and Resource
Management Models for Packet Networks. IEEE/ACM
Transactions on Networking, Vol. 3 No. 4, pp. 365-386,
August 1995.
[Floyd95] リンク共有と資源管理がパケット網のためにモデル化するフロイド、S.、およびジェーコブソン、V.。 Networkingの上のIEEE/ACM Transactions、Vol.3No.4、ページ 365-386と、1995年8月。
[FSS98] Fragouli, C., Sivaraman, V., Srivastava, M.,
"Controlled Multimedia Wireless Link Sharing via
Enhanced Class-Based Queueing with Channel-State-
Dependent Packet Scheduling," Proc. IEEE INFOCOM'98,
April 1998.
[FSS98]Fragouli、C.、Sivaraman、V.、Srivastava(M.)は「Channel州の依存するPacket SchedulingとベースのEnhanced Class Queueingを通してMultimedia Wireless Link Sharingを制御しました」、Proc。 1998年4月のIEEE INFOCOM98年。
[GPRS] ETSI, "General Packet Radio Service (GPRS): Service
Description, Stage 2," GSM03.60, v.6.1.1 August 1998.
[GPRS]ETSI、「一般パケットラジオは(GPRS)を修理します」。 「記述、Stage2インチ、GSM03.60、v.6.1.1 8月1998番目を修理してください。
Montenegro, et al. Informational [Page 38] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[38ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
[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、pp92-100、1993年4月。
[HL96] Hausel, B., Lindquist, D., "WebExpress: A System for
Optimizing Web Browsing in a Wireless Environment," in
Proc. MobiCom'96, Rye, New York, USA, November 1996.
[HL96]Hausel、B.、リンドキスト、D.、「WebExpress:」 Procの「ワイヤレスの環境におけるウェブ閲覧を最適化するシステム。」 MobiCom96年、ライ麦、ニューヨーク(米国)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ニールセン(W3C、MIT)、ジムGettys(W3C、Digital)、Anselmベアード-スミス(W3C、INRIA)、エリックPrud'hommeaux(W3C、MIT)(Hon偽り(W3C、INRIA)、クリス・リリー(W3C、INRIA))は「HTTP/1.1のパフォーマンス効果、CSS1、およびPNGをネットワークでつなぎます」、ACM SIGCOMM97年、カンヌ(フランス)1997年9月。 利用可能: http://www.w3.org/Protocols/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.とペレイラとR.とM.トーマス、「IP有効搭載量圧縮プロトコル(IPComp)」、RFC2393 1998年12月。
[IPHC] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[IPHC] デーゲルマルクとM.とNordgrenとB.とS.ピンク、「IPヘッダー圧縮」、RFC2507、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.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン
[IPHC-PPP] Engan, M., Casner, S. and C. Bormann, "IP Header
Compression over PPP", RFC 2509, February 1999.
[IPHC-ppp] EnganとM.とCasnerとS.とC.ボルマン、「pppの上のIPヘッダー圧縮」、RFC2509、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.、バドリーナート、「移管とシステムは間接的なTCP/IPのためにサポートする」B.R.。 モバイルと位置の独立しているコンピューティングにおける第2USENIXシンポジウムの議事、アナーバー(ミシガン)1995年4月10- 11に。
[Jain89] Jain, R., "A Delay-Based Approach for Congestion
Avoidance in Interconnected Heterogeneous Computer
Networks," Digital Equipment Corporation, Technical
Report DEC-TR-566, April 1989.
[Jain89] ジャイナ教徒、R.、「インタコネクトされた異種計算機ネットワークにおける輻輳回避のための遅れベースのアプローチ」、ディジタルイクイップメント社、技術報告書12月-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.、「クアルコムCDMA無線デジタル通信網」Proc。 USENIXのモバイルの、そして、位置から独立しているコンピューティングシンポジウム、USENIX協会、1993年8月。
Montenegro, et al. Informational [Page 39] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[39ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
[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.、「遅い無線電話のための効率的な輸送サービスはリンクします」、CommunicationのSelected Areasの上のIEEE Journalで、第15巻、No.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.、「弱々しく接続されたモバイルワークステーションのためにWWWを最適化します:」 Procの「間接的なアプローチ。」 第2Int。 DistributedとNetworked Environments、ウィスラー、カナダ、ページのServicesに関するワークショップ 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.、ヘリーン、H.、Kojo、M.、Raatikainen、K.、「Mowgli WWWソフトウェア:」 Procの「変わりやすい青白い環境における、WWWの改良されたユーザビリティ。」 1996年のIEEEのグローバルなインターネットコンファレンス、ロンドン、イギリス、1996年11月。
[LS98] Lettieri, P., Srivastava, M., "Adaptive Frame Length
Control for Improving Wireless Link Throughput, Range,
and Energy Efficiency," Proc. IEEE INFOCOM'98, April
1998.
[LS98] レティエリと、P.と、Srivastavaと、M.と、「ワイヤレスのリンクスループットを改良するための適応型のフレーム長さのコントロール、範囲、およびエネルギー効率」、Proc。 1998年4月のIEEE INFOCOM98年。
[MNCP] Piscitello, D., Phifer, L., Wang, Y., Hovey, R.,
"Mobile Network Computing Protocol (MNCP)", Work in
Progress.
D.、Phifer、L.、ワング、Y.、ハービ、R.、「モバイルネットワークコンピューティングプロトコル(MNCP)」という[MNCP]Piscitelloは進行中で働いています。
[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、Procの「デジタル携帯電話の上のインターネットへの接続のモバイルワークステーションはネットワークでつなぐ」T.。 1994年11月のモバイルの、そして、ワイヤレスの情報システム(MOBIDATA)、ラトガース大学、ニュージャージーに関するワークショップ。 利用可能: http://www.cs.Helsinki.FI/research/mowgli/ モバイルComputing、ページで発行された改訂版 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] マシス、M.、Semke、J.、Mahdavi、J.、オット、T.、コンピュータCommunications Review、ACM SIGCOMMの刊行物、第27巻、No.3、1997年7月の「TCP輻輳回避アルゴリズムの巨視的行動。」
[MTCP] Brown, K. Singh, S., "A Network Architecture for
Mobile Computing," Proc. IEEE INFOCOM'96, pp. 1388-
1396, March 1996. Available at
ftp://ftp.ece.orst.edu/pub/singh/papers
/transport.ps.gz
[MTCP]ブラウン、K.シン、S.、「モバイル・コンピューティングのためのネットワークアーキテクチャ」Proc。 IEEE INFOCOM96年、ページ 1388- 1396と、1996年3月。 ftp://ftp.ece.orst.edu/pub/singh/papers /transport.ps.gzでは、利用可能です。
Montenegro, et al. Informational [Page 40] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[40ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
[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
ブラウン、K.シン、[M-TCP]S.、「M-TCP:」 「モバイルセルラー・ネットワークのためのTCP」、ACMコンピュータコミュニケーションレビュー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]メータ、M.、Vaidya、N.、「遅れた写し承認:」 「ワイヤレスにおけるTCPの性能を向上させるという提案はリンクする」、1997年12月24日のテキサスA&M大学。 http://www.cs.tamu.edu/faculty/vaidya/mobile.html では、利用可能です。
[NETBLT] White, J., "NETBLT (Network Block Transfer Protocol)",
Work in Progress.
[NETBLT] ホワイト、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.パクソン、「終わりから終わりへのインターネットパケット力学」、Proc。 SIGCOMM97年。 ftp://ftp.ee.lbl.gov/papers/vp-pkt-dyn-sigcomm97.ps.Z では、利用可能です。
[RED] Braden, B., Clark, D., Crowcroft, J., Davie, B.,
Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
Minshall, G., Partridge, C., Peterson, L.,
Ramakrishnan, K., Shenker, S., Wroclawski, J. and L.
Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April
1998.
[赤]ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ジェーコブソン、V.、Minshall、G.、ヤマウズラ、C.、ピーターソン、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J.、およびL.チャン、「インターネットの待ち行列管理と輻輳回避の推薦」、RFC2309(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、「モバイル駅のDataとTelematic ServicesのためのラジオLinkプロトコル--駅のSystem(MS-BSS)インタフェースと基地の駅のSystemを基礎づけてください--モバイルSwitchingセンター(BSS-MSC)は連結します」、GSM Specification04.22、バージョン、3.7、.0、2月1992日
[RFC908] Velten, D., Hinden, R. and J. Sax, "Reliable Data
Protocol", RFC 908, July 1984.
[RFC908] フェルテンとD.とHindenとR.とJ.サクソフォーン、「確実な資料プロトコル」、RFC908、1984年7月。
[RFC1030] Lambert, M., "On Testing the NETBLT Protocol over
Divers Networks", RFC 1030, November 1987.
M. [RFC1030]ランバート、RFC1030、「幾つかのネットワークの上でNETBLTプロトコルをテストする」ときの1987年11月。
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-
Speed Serial Links", RFC 1144, February 1990.
1990年2月の[RFC1144]ジェーコブソン対「低い速度連続のリンクへのTCP/IPヘッダーを圧縮すること」でのRFC1144
[RFC1151] Partridge, C., Hinden, R., "Version 2 of the Reliable
Data Protocol (RDP)", RFC 1151, April 1990.
[RFC1151]ヤマウズラ、C.、Hinden、R.、「確実な資料プロトコル(RDP)のバージョン2」、RFC1151、1990年4月。
Montenegro, et al. Informational [Page 41] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[41ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC
1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。
[RFC1397] Braden, R., "Extending TCP for Transactions --
Concepts", RFC 1397, November 1992.
R. [RFC1397]ブレーデン、RFC1397、「トランザクション--概念のためにTCPを広げている」11月1992日
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions
Functional Specification", RFC 1644, July 1994.
[RFC1644]ブレーデン、R.、「T/TCP--、トランザクションに、機能的なTCP拡張子、仕様、」、RFC1644、7月1994日
[RFC1661] Simpson, W., "The Point-To-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D.
and L. Jones, "SOCKS Protocol Version 5", RFC 1928,
March 1996.
[RFC1928]のヒル、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.、およびL.ジョーンズ、「ソックスはバージョン5インチについて議定書の中で述べます、RFC1928、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.)が言い寄るW.、D.とR.ランガン、「ラジオリンクスの使用のための簡単なファイル転送プロトコルとの実験はトリビアル・ファイル転送プロトコル(ETFTP)を高めました」、RFC1986、1996年8月。
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October
1996.
[RFC2002] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2003] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC
2004, October 1996.
[RFC2004] パーキンス、C.、「IPの中の最小量のカプセル化」、RFC2004、1996年10月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow,
"TCP Selective Acknowledgment Options", RFC 2018,
October 1996.
[RFC2018] マシスとM.とMahdaviとJ.とフロイドとS.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、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.とテイラーとM.とJ.チェン、「のAT&T/Neda効率的な短いリモート操作(ESRO)は仕様バージョン1.2インチについて議定書の中で述べます、RFC2188、1997インチ年9月。
[RFC2246] Dierk, T. and E. Allen, "TLS Protocol Version 1", RFC
2246, January 1999.
[RFC2246] Dierk、T.、およびE.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[RFC2414] Allman, M., Floyd, S. and C. Partridge. "Increasing
TCP's Initial Window", RFC 2414, September 1998.
[RFC2414] オールマン、M.、フロイド、S.、およびC.ヤマウズラ。 「増加するTCPの初期の窓」、RFC2414、1998年9月。
[RFC2415] Poduri, K.and K. Nichols, "Simulation Studies of
Increased Initial TCP Window Size", RFC 2415,
September 1998.
[RFC2415] PoduriとK.とK.ニコルズ、「増強された初期のTCPウィンドウサイズのシミュレーション研究」、RFC2415、1998年9月。
Montenegro, et al. Informational [Page 42] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[42ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
[RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With
Four Packets Into Only Three Buffers", RFC 2416,
September 1998.
[RFC2416]シェパード、T.とC.ヤマウズラ、「いつTCPは4つのパケットと共に3つのバッファだけに始動する」RFC2416(1998年9月)。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification
to TCP's Fast Recovery Algorithm", RFC 2582, April
1999.
[RFC2582] フロイドとS.とT.ヘンダーソン、「TCPの速い回復アルゴリズムへのNewReno変更」、RFC2582、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.
R. [スヌープ]Balakrishnan、H.、Seshan、S.、アミール、E.、キャッツ、「ワイヤレス・ネットワークの上のTCP/IP性能を向上すること」でのProc。 最初の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.スティーブンス、「TCP/IPは例証しました、第1巻」、アディソン。ウエスリー、1994(MTUサイズ問題のためのセクション2.10と弱いチェックサムのためのセクション11.3)。
[TCPHP] Jacobson, V., Braden, R. and D. Borman, "TCP
Extensions for High Performance", RFC 1323, May 1992.
[TCPHP]ジェーコブソン(V.、ブレーデン、R. and D.ボーマン、「高性能のためのTCP拡張子」、RFC1323)は1992がそうするかもしれません。
[TCPSATMIN] TCPSAT Minutes, August, 1997. Available at:
http://tcpsat.lerc.nasa.gov/tcpsat/meetings/munich-
minutes.txt.
1997年8月の[TCPSATMIN]TCPSAT分。 利用可能: http://tcpsat.lerc.nasa.gov/tcpsat/meetings/munich- minutes.txt。
[Touch97] Touch, T., "TCP Control Block Interdependence", RFC
2140, April 1997.
[Touch97] 接触、T.、「TCP制御ブロック相互依存」、RFC2140、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.メータ、C.パーキンス、G.モンテネグロ、「遅らせられて、承認をコピーしてください」 「ワイヤレスの上でTCPの性能を向上させるTCP気づかないアプローチ」、技術報告書99-003、コンピュータサイエンス部、テキサスA&M大学(1999年2月)
[VEGAS] Brakmo, L., O'Malley, S., "TCP Vegas, New Techniques
for Congestion Detection and Avoidance," SIGCOMM'94,
London, pp 24-35, October 1994.
[ヴェガス]Brakmo、L.、オマリー、S.、「TCPベガ、混雑検出と回避のための新しいやり方」、SIGCOMM94年、ロンドン、pp24-35、10月1994
[VMTP] Cheriton, D., "VMTP: Versatile Message Transaction
Protocol", RFC 1045, February 1988.
[VMTP]Cheriton、D.、「VMTP:」 「多能なメッセージトランザクションプロトコル」、RFC1045、1988年2月。
[WAP] Wireless Application Protocol Forum.
http://www.wapforum.org/
[WAP]ワイヤレス・アプリケーション・プロトコルフォーラム http://www.wapforum.org/
Montenegro, et al. Informational [Page 43] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[43ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
[WC91] Wang, Z., Crowcroft, J., "A New Congestion Control
Scheme: Slow Start and Search," ACM Computer
Communication Review, vol 21, pp 32-43, January 1991.
[WC91] ワング、Z.、クロウクロフト、J.、「新しい輻輳制御は計画します」。 「Startと検索を遅くしてください」、ACMコンピュータCommunication Review、vol21、pp32-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.、マッタ、I.、「WTCP:」 「ワイヤレスのリンクがあるネットワークに、効率的な通信制御プロトコル」、技術報告書ν-CCS-97-11、北東の大学、1997年7月。 利用可能: http://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] N. Yavatkar、R.、Bhagawat、「モバイルインターネットワークの上で終わりから終わりへのTCPの性能を向上すること」でのProc。 モバイルコンピューティング・システムとアプリケーションに関するワークショップ、IEEEコンピュータ社会プレス、ロスアラミトス(カリフォルニア)1994。
Authors' Addresses
作者のアドレス
Questions about this document may be directed at:
このドキュメントに関する質問は以下で指示されるかもしれません。
Gabriel E. Montenegro Sun Labs Networking and Security Group Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View, California 94303
マウンテンビュー、ガブリエルE.モンテネグロSun研究室ネットワークとセキュリティグループサン・マイクロシステムズ・インク901サンアントニオ道路Mailstop UMPK15-214カリフォルニア 94303
Phone: +1-650-786-6288 Fax: +1-650-786-6445 EMail: gab@sun.com
以下に電話をしてください。 +1-650-786-6288 Fax: +1-650-786-6445 メールしてください: gab@sun.com
Spencer Dawkins Nortel Networks P.O. Box 833805 Richardson, Texas 75083-3805
スペンサーダウキンズノーテルネットワークP.O. Box833805リチャードソン、テキサス75083-3805
Phone: +1-972-684-4827 Fax: +1-972-685-3292 EMail: sdawkins@nortel.com
以下に電話をしてください。 +1-972-684-4827 Fax: +1-972-685-3292 メールしてください: sdawkins@nortel.com
Montenegro, et al. Informational [Page 44] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[44ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland
ヘルシンキ私書箱26(Teollisuuskatu23)フィン-00014ヘルシンキフィンランドのマルックKojoコンピュータサイエンス学部大学
Phone: +358-9-1914-4179 Fax: +358-9-1914-4441 EMail: kojo@cs.helsinki.fi
以下に電話をしてください。 +358-9-1914-4179 Fax: +358-9-1914-4441 メールしてください: kojo@cs.helsinki.fi
Vincent Magret Corporate Research Center Alcatel Network Systems, Inc 1201 Campbell Mail stop 446-310 Richardson Texas 75081 USA M/S 446-310
ヴィンセントMagret Corporate ResearchセンターアルカテルNetwork Systems、Inc1201キャンベルメール停止446-310リチャードソン・テキサス75081米国M/S446-310
Phone: +1-972-996-2625 Fax: +1-972-996-5902 EMail: vincent.magret@aud.alcatel.com
以下に電話をしてください。 +1-972-996-2625 Fax: +1-972-996-5902 メールしてください: vincent.magret@aud.alcatel.com
Nitin Vaidya Dept. of Computer Science Texas A&M University College Station, TX 77843-3112
コンピュータサイエンステキサスA&M大学大学駅のNitin Vaidya部、テキサス77843-3112
Phone: 979-845-0512 Fax: 979-847-8578 EMail: vaidya@cs.tamu.edu
以下に電話をしてください。 979-845-0512 Fax: 979-847-8578 メールしてください: vaidya@cs.tamu.edu
Montenegro, et al. Informational [Page 45] RFC 2757 Long Thin Networks January 2000
モンテネグロ、他 情報[45ページ]のRFC2757は2000年1月に長い間、ネットワークを薄くします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Montenegro, et al. Informational [Page 46]
モンテネグロ、他 情報[46ページ]
一覧
スポンサーリンク
