RFC2488 日本語訳
2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms.M. Allman, D. Glover, L. Sanchez. January 1999. (Format: TXT=47857 bytes) (Also BCP0028) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Allman
Request for Comments: 2488 NASA Lewis/Sterling Software
BCP: 28 D. Glover
Category: Best Current Practice NASA Lewis
L. Sanchez
BBN
January 1999
コメントを求めるワーキンググループM.オールマン要求をネットワークでつないでください: 2488のNASAのルイス/英貨のソフトウェアBCP: 28D.手袋製造業者カテゴリ: 最も良い現在の練習のNASAルイスL.サンチェスBBN1999年1月
Enhancing TCP Over Satellite Channels
using Standard Mechanisms
衛星チャンネルの上に標準のメカニズムを使用することでTCPを高めます。
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. At this time, all mitigations discussed in this document are IETF standards track mechanisms (or are compliant with IETF standards).
通信制御プロトコル(TCP)は衛星チャンネルを含むネットワーク経路を含むどんなネットワーク経路の向こう側にもデータの信頼できる配信を提供します。 TCPはある衛星チャンネルの上に数個を扱いますが、IETFはTCPが、より効果的にネットワーク経路の有効な容量を利用するのを可能にするメカニズムを標準化しました。 このドキュメントはこれらのTCP緩和のいくつかについて概説します。 このとき、本書では議論したすべての緩和がIETF標準化過程メカニズム(または、IETF規格で、言いなりになる)です。
1. Introduction
1. 序論
Satellite channel characteristics may have an effect on the way transport protocols, such as the Transmission Control Protocol (TCP) [Pos81], behave. When protocols, such as TCP, perform poorly, channel utilization is low. While the performance of a transport protocol is important, it is not the only consideration when constructing a network containing satellite links. For example, data link protocol, application protocol, router buffer size, queueing discipline and proxy location are some of the considerations that must be taken into account. However, this document focuses on improving TCP in the satellite environment and non-TCP considerations are left for another document. Finally, there have been many satellite mitigations proposed and studied by the research community. While these mitigations may prove useful and safe for shared networks in the future, this document only considers TCP mechanisms which are
衛星チャネル特性は通信制御プロトコルなどのトランスポート・プロトコル(TCP)[Pos81]が振る舞う方法に影響を与えるかもしれません。 TCPなどのプロトコルが不十分に働くとき、チャンネル利用は低いです。 トランスポート・プロトコルの性能は重要ですが、衛星中継を含むネットワークを構成するとき、それは唯一の考慮ではありません。 例えば、データリンクプロトコル、アプリケーション・プロトコル、ルータバッファサイズ、待ち行列規律、およびプロキシ位置は考慮に入れなければならない問題のいくつかです。 しかしながら、このドキュメントは、衛星環境でTCPを改良するのは焦点を合わせます、そして、非TCP問題は別のドキュメントに残されます。 最終的に、研究団体によって提案されて、研究された多くの衛星緩和がありました。 これらの緩和は将来このドキュメントがそうするTCPメカニズムであると考えるだけである共用回線網に役に立って安全であると判明するかもしれませんが
Allman, et. al. Best Current Practice [Page 1] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
etオールマン、アル。 1999年1月に衛星チャンネルの上にTCPを高める最も良い現在の習慣[1ページ]RFC2488
currently well understood and on the IETF standards track (or are compliant with IETF standards).
現在、よく理解されていてIETFでは、規格は追跡されます(または、IETF規格で、言いなりになります)。
This document is divided up as follows: Section 2 provides a brief outline of the characteristics of satellite networks. Section 3 outlines two non-TCP mechanisms that enable TCP to more effectively utilize the available bandwidth. Section 4 outlines the TCP mechanisms defined by the IETF that may benefit satellite networks. Finally, Section 5 provides a summary of what modern TCP implementations should include to be considered "satellite friendly".
このドキュメントは以下の通りに分割されます: セクション2は衛星ネットワークの特性の簡潔なアウトラインを提供します。 セクション3はTCPが、より効果的に利用可能な帯域幅を利用するのを可能にする2つの非TCPメカニズムについて概説します。 セクション4は衛星ネットワークのためになるかもしれないIETFによって定義されたTCPメカニズムについて概説します。 最終的に、セクション5は、「衛星好意的である」と考えられるために現代のTCP実現が含むべきであることの概要を提供します。
2. Satellite Characteristics
2. 衛星の特性
There is an inherent delay in the delivery of a message over a satellite link due to the finite speed of light and the altitude of communications satellites.
衛星中継の上にメッセージの配送の固有の遅れが有限光速と通信衛星の高度のためにあります。
Many communications satellites are located at Geostationary Orbit (GSO) with an altitude of approximately 36,000 km [Sta94]. At this altitude the orbit period is the same as the Earth's rotation period. Therefore, each ground station is always able to "see" the orbiting satellite at the same position in the sky. The propagation time for a radio signal to travel twice that distance (corresponding to a ground station directly below the satellite) is 239.6 milliseconds (ms) [Mar78]. For ground stations at the edge of the view area of the satellite, the distance traveled is 2 x 41,756 km for a total propagation delay of 279.0 ms [Mar78]. These delays are for one ground station-to-satellite-to-ground station route (or "hop"). Therefore, the propagation delay for a message and the corresponding reply (one round-trip time or RTT) could be at least 558 ms. The RTT is not based solely on satellite propagation time. The RTT will be increased by other factors in the network, such as the transmission time and propagation time of other links in the network path and queueing delay in gateways. Furthermore, the satellite propagation delay will be longer if the link includes multiple hops or if intersatellite links are used. As satellites become more complex and include on-board processing of signals, additional delay may be added.
多くの通信衛星がおよそ3万6000km[Sta94]の高度があるGeostationary Orbit(GSO)に位置しています。 この高度では、軌道の期間は地球の回転周期と同じです。 したがって、それぞれの地上局は空で同じ位置でいつも地球を周回する人工衛星を「見ることができます」。 無線信号がその距離(衛星の直接下の地上局に対応する)の2倍移動する伝播時間は239.6ミリセカンド(ms)[Mar78]です。 衛星の視点区域の縁の地上局において、旅行された距離は279.0ms[Mar78]の総伝播遅延のための2x4万1756kmです。 1つの地上局への衛星への地上ステーションルートにはこれらの遅れがあります(「跳んでください」)。 したがって、メッセージのための伝播遅延と対応する回答(1往復の時間かRTT)は少なくとも558が原稿であるなら基づくことができるでしょうに。RTTは唯一衛星伝播時間に基づいていません。 RTTはネットワークのゲートウェイのネットワーク経路と待ち行列遅れにおける、トランスミッション時間や他のリンクの伝播時間などの他の要素によって増加させられるでしょう。 その上、リンクが複数のホップを含んでいるか、または衛星間リンクが使用されているなら、衛星伝播遅延は、より長くなるでしょう。 衛星が、より複雑になって、信号の車載処理を含めて、追加遅れは加えられるかもしれません。
Other orbits are possible for use by communications satellites including Low Earth Orbit (LEO) [Stu95] [Mon98] and Medium Earth Orbit (MEO) [Mar78]. The lower orbits require the use of constellations of satellites for constant coverage. In other words, as one satellite leaves the ground station's sight, another satellite appears on the horizon and the channel is switched to it. The propagation delay to a LEO orbit ranges from several milliseconds when communicating with a satellite directly overhead, to as much as 80 ms when the satellite is on the horizon. These systems are more
使用に、他の軌道はLow地球Orbit(LEO)[Stu95][Mon98]とMedium地球Orbit(MEO)[Mar78]を含む通信衛星で可能です。 下側の軌道は衛星の星座の一定の適用範囲の使用を必要とします。 言い換えれば、1つの衛星が地上局の光景を出るのに従って、別の衛星は地平線に現れます、そして、チャンネルはそれに切り換えられます。 いつ、衛星が地平線にあるかを最大80msへの直接頭上の衛星と伝えるとき、LEO軌道への伝播遅延は数ミリセカンドから変化します。 これらのシステムは、より多いです。
Allman, et. al. Best Current Practice [Page 2] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
etオールマン、アル。 1999年1月に衛星チャンネルの上にTCPを高める最も良い現在の習慣[2ページ]RFC2488
likely to use intersatellite links and have variable path delay depending on routing through the network.
衛星間リンクを使用して、ネットワークを通してルーティングによる可変経路遅れを持っていそうです。
Satellite channels are dominated by two fundamental characteristics, as described below:
衛星チャンネルは以下で説明されるように2つの基本的な特性によって支配されます:
NOISE - The strength of a radio signal falls in proportion to the
square of the distance traveled. For a satellite link the
distance is large and so the signal becomes weak before reaching
its destination. This results in a low signal-to-noise ratio.
Some frequencies are particularly susceptible to atmospheric
effects such as rain attenuation. For mobile applications,
satellite channels are especially susceptible to multi-path
distortion and shadowing (e.g., blockage by buildings). Typical
bit error rates (BER) for a satellite link today are on the order
of 1 error per 10 million bits (1 x 10^-7) or less frequent.
Advanced error control coding (e.g., Reed Solomon) can be added to
existing satellite services and is currently being used by many
services. Satellite error performance approaching fiber will
become more common as advanced error control coding is used in new
systems. However, many legacy satellite systems will continue to
exhibit higher BER than newer satellite systems and terrestrial
channels.
NOISE--無線信号の強さは旅行された距離の二乗に比例して下がります。 衛星中継に関しては、距離が大きいので、信号は目的地に到着する前に、弱くなります。 これは低SN比をもたらします。 いくつかの頻度が特に雨の減衰などのぼかし効果に影響されやすいです。 モバイルアプリケーションのために、衛星チャンネルは、マルチ経路ひずみに特に影響されやすい、そして、(例えば、ビルのそばでの封鎖)を影でおおいます。 衛星中継への典型的なビット誤り率(BER)は、今日、1000万ビット(1x10^-7)あたり1つの誤りの注文にはあるか、またはそれほど頻繁ではありません。 高度な誤り制御コード化(例えば、リード・ソロモン)は、既存の衛星サービスに加えることができて、現在、多くのサービスで使用されています。 高度な誤り制御コード化が新しいシステムで使用されるとき、衛星誤り性能アプローチファイバーは、より一般的になるでしょう。しかしながら、多くの遺産サテライト・システムが、より新しいサテライト・システムと陸生のチャンネルより高いBERを示し続けるでしょう。
BANDWIDTH - The radio spectrum is a limited natural resource,
hence there is a restricted amount of bandwidth available to
satellite systems which is typically controlled by licenses. This
scarcity makes it difficult to trade bandwidth to solve other
design problems. Typical carrier frequencies for current, point-
to-point, commercial, satellite services are 6 GHz (uplink) and 4
GHz (downlink), also known as C band, and 14/12 GHz (Ku band). A
new service at 30/20 GHz (Ka band) will be emerging over the next
few years. Satellite-based radio repeaters are known as
transponders. Traditional C band transponder bandwidth is
typically 36 MHz to accommodate one color television channel (or
1200 voice channels). Ku band transponders are typically around
50 MHz. Furthermore, one satellite may carry a few dozen
transponders.
BANDWIDTH--電波スペクトルが限られた天然資源である、したがって、ライセンスによって通常制御されるサテライト・システムに利用可能な制限された量の帯域幅があります。 この不足で他の設計上の問題を解決するために帯域幅を取り引きするのは難しくなります。電流のための典型的なキャリヤー頻度、ポイントのポイントの、そして、商業の衛星サービスは、6ギガヘルツ(アップリンク)と4ギガヘルツ(ダウンリンク)です、また、Cバンド、および14/12ギガヘルツとして知られていて(Kuは組になります)。 30/20ギガヘルツ(kaバンド)における新しいサービスはこの数年間にわたって現れているでしょう。 衛星ベースのラジオリピータはトランスポンダーとして知られています。 通常、伝統的なCバンドトランスポンダー帯域幅は1個のカラーテレビチャンネル(または、1200個の音声チャンネル)を収容する36MHzです。 通常、Kuバンドトランスポンダーはおよそ50MHzです。 その上、1つの衛星がいくつかのダースのトランスポンダーを運ぶかもしれません。
Not only is bandwidth limited by nature, but the allocations for commercial communications are limited by international agreements so that this scarce resource can be used fairly by many different applications.
生来、帯域幅が制限されるだけではなく、商業コミュニケーションのための配分は、多くの異なったアプリケーションでこの不十分なリソースを公正に使用できるように国際協定で制限されます。
Allman, et. al. Best Current Practice [Page 3] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
etオールマン、アル。 1999年1月に衛星チャンネルの上にTCPを高める最も良い現在の習慣[3ページ]RFC2488
Although satellites have certain disadvantages when compared to fiber channels (e.g., cannot be easily repaired, rain fades, etc.), they also have certain advantages over terrestrial links. First, satellites have a natural broadcast capability. This gives satellites an advantage for multicast applications. Next, satellites can reach geographically remote areas or countries that have little terrestrial infrastructure. A related advantage is the ability of satellite links to reach mobile users.
衛星には、ファイバーチャネル(例えば、容易に修理された雨のフェードであることができませんなど)と比べると、ある損失がありますが、それらでは、また、地球のリンクよりある利点があります。 まず最初に、衛星には、生まれながらの放送能力があります。 これはマルチキャストアプリケーションのために利点を衛星に与えます。 次に、衛星は地理的にほとんど地球のインフラストラクチャを持っていない遠隔地か国に達することができます。 関連する利点は衛星中継が可動のユーザに届く能力です。
Satellite channels have several characteristics that differ from most terrestrial channels. These characteristics may degrade the performance of TCP. These characteristics include:
衛星チャンネルには、ほとんどの陸生のチャンネルと異なっているいくつかの特性があります。 これらの特性はTCPの性能を下げるかもしれません。 これらの特性は:
Long feedback loop
長いフィードバックループ
Due to the propagation delay of some satellite channels (e.g.,
approximately 250 ms over a geosynchronous satellite) it may take
a long time for a TCP sender to determine whether or not a packet
has been successfully received at the final destination. This
delay hurts interactive applications such as telnet, as well as
some of the TCP congestion control algorithms (see section 4).
何人かの衛星チャンネル(例えば、静止衛星の上のおよそ250ms)の伝播遅延のため、それは最終的な目的地に首尾よくパケットを受け取ったか否かに関係なく、決定するTCP送付者のために長くかかるかもしれません。 この遅れはtelnetなどの対話型アプリケーションに害を与えます、TCP輻輳制御アルゴリズムのいくつかと同様に(セクション4を見てください)。
Large delay*bandwidth product
大きい遅れ*帯域幅生成物
The delay*bandwidth product (DBP) defines the amount of data a
protocol should have "in flight" (data that has been transmitted,
but not yet acknowledged) at any one time to fully utilize the
available channel capacity. The delay used in this equation is
the RTT and the bandwidth is the capacity of the bottleneck link
in the network path. Because the delay in some satellite
environments is large, TCP will need to keep a large number of
packets "in flight" (that is, sent but not yet acknowledged) .
遅れ*帯域幅生成物(DBP)は有効なチャネル容量を完全に利用するどんな時にもプロトコルが「飛行」で持つべきであるデータ量(伝えられますが、まだ承認されていないデータ)を定義します。 この方程式で使用される遅れはRTTです、そして、帯域幅はネットワーク経路のボトルネックリンクの容量です。 いくつかの衛星環境の遅れが大きいので、TCPは、「飛行」で多くのパケットを保つ(すなわち、送りますが、まだ承認していません)必要があるでしょう。
Transmission errors
伝送エラー
Satellite channels exhibit a higher bit-error rate (BER) than
typical terrestrial networks. TCP uses all packet drops as
signals of network congestion and reduces its window size in an
attempt to alleviate the congestion. In the absence of knowledge
about why a packet was dropped (congestion or corruption), TCP
must assume the drop was due to network congestion to avoid
congestion collapse [Jac88] [FF98]. Therefore, packets dropped
due to corruption cause TCP to reduce the size of its sliding
window, even though these packet drops do not signal congestion in
the network.
衛星チャンネルは典型的な地球のネットワークより高いビット誤り率(BER)を示します。 TCPはネットワークの混雑に関する信号としてすべてのパケット滴を使用して、混雑を軽減する試みでウィンドウサイズを減少させます。 パケットが落とされた理由(混雑か不正)に関する知識がないとき、TCPは、低下がネットワークの混雑の混雑崩壊[Jac88][FF98]を避けるためにはためであったと仮定しなければなりません。 したがって、パケットは引窓のサイズを減少させる不正原因TCPのため低下しました、これらのパケット滴はネットワークでは混雑に合図しませんが。
Allman, et. al. Best Current Practice [Page 4] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
etオールマン、アル。 1999年1月に衛星チャンネルの上にTCPを高める最も良い現在の習慣[4ページ]RFC2488
Asymmetric use
非対称の使用
Due to the expense of the equipment used to send data to
satellites, asymmetric satellite networks are often constructed.
For example, a host connected to a satellite network will send all
outgoing traffic over a slow terrestrial link (such as a dialup
modem channel) and receive incoming traffic via the satellite
channel. Another common situation arises when both the incoming
and outgoing traffic are sent using a satellite link, but the
uplink has less available capacity than the downlink due to the
expense of the transmitter required to provide a high bandwidth
back channel. This asymmetry may have an impact on TCP
performance.
データを衛星に送るのに使用される設備の費用のため、非対称の衛星ネットワークはしばしば構成されます。 例えば、衛星ネットワークに接続されたホストは、遅い地球のリンク(ダイアルアップモデムチャンネルなどの)の上にすべての外向的な交通を送って、衛星チャンネルで入って来る交通を受けるでしょう。 両方の送受信の交通に衛星中継を使用させるとき、別の日常の状況は起こりますが、アップリンクには、有効な容量より高帯域の戻っているチャンネルを提供するのに必要である送信機の費用によるダウンリンクがあります。 この非対称はTCP性能に影響を与えるかもしれません。
Variable Round Trip Times
可変周遊旅行時間
In some satellite environments, such as low-Earth orbit (LEO)
constellations, the propagation delay to and from the satellite
varies over time. Whether or not this will have an impact on TCP
performance is currently an open question.
低い地球の軌道(LEO)星座などのいくつかの衛星環境では、衛星と衛星からの伝播遅延は時間がたつにつれて、異なります。 現在、これがTCP性能に影響を与えるかどうかが、未決問題です。
Intermittent connectivity
間欠接続性
In non-GSO satellite orbit configurations, TCP connections must be
transferred from one satellite to another or from one ground
station to another from time to time. This handoff may cause
packet loss if not properly performed.
非GSO衛星軌道構成では、TCP接続を時々1つの衛星から別のものまで1つの地上局から別のものまで移さなければなりません。 適切に実行されないなら、この移管はパケット損失を引き起こすかもしれません。
Most satellite channels only exhibit a subset of the above characteristics. Furthermore, satellite networks are not the only environments where the above characteristics are found. However, satellite networks do tend to exhibit more of the above problems or the above problems are aggravated in the satellite environment. The mechanisms outlined in this document should benefit most networks, especially those with one or more of the above characteristics (e.g., gigabit networks have large delay*bandwidth products).
ほとんどの衛星チャンネルが上の特性の部分集合を示すだけです。 その上、衛星ネットワークは上の特性が見つけられる唯一の環境ではありません。 しかしながら、衛星ネットワークが、一層の上の問題を示す傾向があるか、または上の問題は衛星環境でいらいらさせられます。 本書では概説されたメカニズムはほとんどのネットワーク(特に上の特性(例えば、ギガビットネットワークには、大きい遅れ*帯域幅生成物がある)の1つ以上があるそれら)のためになるはずです。
3. Lower Level Mitigations
3. 下のレベル緩和
It is recommended that those utilizing satellite channels in their networks should use the following two non-TCP mechanisms which can increase TCP performance. These mechanisms are Path MTU Discovery and forward error correction (FEC) and are outlined in the following two sections.
彼らのネットワークで衛星チャンネルを利用する人がTCP性能を向上させることができる以下の2つの非TCPメカニズムを使用するのは、お勧めです。 これらのメカニズムは、Path MTUディスカバリーと前進型誤信号訂正(FEC)であり、以下の2つのセクションで概説されています。
The data link layer protocol employed over a satellite channel can have a large impact on performance of higher layer protocols. While beyond the scope of this document, those constructing satellite
衛星チャンネルの上に使われたデータリンク層プロトコルは、より高い層のプロトコルの性能に大きい影響力を持つことができます。 このドキュメント、それらの組み立てることの範囲を超えて衛星をゆったり過ごしてください。
Allman, et. al. Best Current Practice [Page 5] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
etオールマン、アル。 1999年1月に衛星チャンネルの上にTCPを高める最も良い現在の習慣[5ページ]RFC2488
networks should tune these protocols in an appropriate manner to ensure that the data link protocol does not limit TCP performance. In particular, data link layer protocols often implement a flow control window and retransmission mechanisms. When the link level window size is too small, performance will suffer just as when the TCP window size is too small (see section 4.3 for a discussion of appropriate window sizes). The impact that link level retransmissions have on TCP transfers is not currently well understood. The interaction between TCP retransmissions and link level retransmissions is a subject for further research.
ネットワークは、データリンクプロトコルがTCP性能を制限しないのを保証するために適切な方法でこれらのプロトコルを調整するべきです。 特に、データリンク層プロトコルはフロー制御ウィンドウと「再-トランスミッション」メカニズムをしばしば実行します。リンク・レベルウィンドウサイズが小さ過ぎるときに、性能にちょうどTCPウィンドウサイズが小さ過ぎる(適切なウィンドウサイズの議論に関してセクション4.3を見てください)時として苦しむでしょう。 リンク・レベル「再-トランスミッション」がTCP転送のときに持っている影響力は現在、よく理解されていません。 TCP retransmissionsとリンク・レベル「再-トランスミッション」との相互作用はさらなる調査のための対象です。
3.1 Path MTU Discovery
3.1 経路MTU発見
Path MTU discovery [MD90] is used to determine the maximum packet size a connection can use on a given network path without being subjected to IP fragmentation. The sender transmits a packet that is the appropriate size for the local network to which it is connected (e.g., 1500 bytes on an Ethernet) and sets the IP "don't fragment" (DF) bit. If the packet is too large to be forwarded without being fragmented to a given channel along the network path, the gateway that would normally fragment the packet and forward the fragments will instead return an ICMP message to the originator of the packet. The ICMP message will indicate that the original segment could not be transmitted without being fragmented and will also contain the size of the largest packet that can be forwarded by the gateway. Additional information from the IESG regarding Path MTU discovery is available in [Kno93].
経路MTU探索[MD90]は、接続が与えられたネットワーク経路でIP断片化にかけられないで使用できる最大のパケットサイズを決定するのに使用されます。 送付者は、それが関連している企業内情報通信網(例えば、イーサネットの1500バイト)のために適切なサイズであるパケットを伝えて、「断片化しないでください」というIP(DF)ビットを設定します。 パケットがネットワーク経路に沿った与えられたチャンネルに断片化されないで進めることができないくらい大きいなら、通常、パケットを断片化して、断片を進めるゲートウェイは代わりにICMPメッセージをパケットの生成元に返すでしょう。 ICMPメッセージは、断片化されないでオリジナルのセグメントを伝えることができなかったのを示して、また、ゲートウェイで進めることができる中で最も大きいパケットのサイズを含むでしょう。 Path MTU発見に関するIESGからの追加情報は[Kno93]で利用可能です。
Path MTU Discovery allows TCP to use the largest possible packet size, without incurring the cost of fragmentation and reassembly. Large packets reduce the packet overhead by sending more data bytes per overhead byte. As outlined in section 4, increasing TCP's congestion window is segment based, rather than byte based and therefore, larger segments enable TCP senders to increase the congestion window more rapidly, in terms of bytes, than smaller segments.
経路MTUディスカバリーで、TCPは断片化の費用を被らないで可能な限り大きいパケットサイズを使用して、再アセンブリされます。 大きいパケットは、より多くの1オーバーヘッドバイトあたりのデータ・バイト発信することによって、パケットオーバーヘッドを下げます。 セクション4で概説されているように、増加するTCPの混雑ウィンドウは基づくバイトよりむしろ基づくセグメントです、そして、したがって、より大きいセグメントはTCP送付者が混雑ウィンドウをより急速に増加させるのを可能にします、バイトに関して、より小さいセグメントより。
The disadvantage of Path MTU Discovery is that it may cause a delay before TCP is able to start sending data. For example, assume a packet is sent with the DF bit set and one of the intervening gateways (G1) returns an ICMP message indicating that it cannot forward the segment. At this point, the sending host reduces the packet size per the ICMP message returned by G1 and sends another packet with the DF bit set. The packet will be forwarded by G1, however this does not ensure all subsequent gateways in the network path will be able to forward the segment. If a second gateway (G2) cannot forward the segment it will return an ICMP message to the transmitting host and the process will be repeated. Therefore, path
Path MTUディスカバリーの不都合はTCPが、データを送り始めることができる前に遅れを引き起こすかもしれないということです。 例えば、DFビットがセットした状態でパケットを送って、介入しているゲートウェイ(G1)の1つがセグメントを進めることができないのを示すICMPメッセージを返すと仮定してください。 ここに、送付ホストは、G1によって返されたICMPメッセージ単位でパケットサイズを減少させて、DFビットがセットした状態で、別のパケットを送ります。 パケットはG1によって進められて、しかしながら、これは、ネットワーク経路のすべてのその後のゲートウェイがセグメントを進めることができるのを確実にしません。 2番目のゲートウェイ(G2)がセグメントを進めることができないと、ICMPメッセージを伝わっているホストに返すでしょう、そして、過程は繰り返されるでしょう。 したがって、経路
Allman, et. al. Best Current Practice [Page 6] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
etオールマン、アル。 1999年1月に衛星チャンネルの上にTCPを高める最も良い現在の習慣[6ページ]RFC2488
MTU discovery can spend a large amount of time determining the maximum allowable packet size on the network path between the sender and receiver. Satellite delays can aggravate this problem (consider the case when the channel between G1 and G2 is a satellite link). However, in practice, Path MTU Discovery does not consume a large amount of time due to wide support of common MTU values. Additionally, caching MTU values may be able to eliminate discovery time in many instances, although the exact implementation of this and the aging of cached values remains an open problem.
MTU発見は送付者と受信機の間のネットワーク経路の最大の許容できるパケットサイズを決定するのに多量の時間を費やすことができます。衛星遅れはこの問題をいらいらさせることができます(G1とG2の間のチャンネルであるときに、ケースが衛星中継であると考えてください)。 しかしながら、実際には、Path MTUディスカバリーは一般的なMTU値の幅広い支持のため多量の時間を費やしません。 さらに、MTU値をキャッシュすると、多くの例で火災発見所要時間を排除できるかもしれません、この正確な実現とキャッシュされた値の年をとることは開いている問題のままで残っていますが。
The relationship between BER and segment size is likely to vary depending on the error characteristics of the given channel. This relationship deserves further study, however with the use of good forward error correction (see section 3.2) larger segments should provide better performance, as with any network [MSMO97]. While the exact method for choosing the best MTU for a satellite link is outside the scope of this document, the use of Path MTU Discovery is recommended to allow TCP to use the largest possible MTU over the satellite channel.
与えられたチャンネルの誤りの特性によって、BERとセグメントサイズとの関係は異なりそうです。 しかしながら、この関係はさらなる研究に値して、良い前進型誤信号訂正(セクション3.2を見る)の使用に、より大きいセグメントは、より良い性能を提供するべきです、どんなネットワーク[MSMO97]のようにも。 このドキュメントの範囲の外に衛星中継への最も良いMTUを選ぶための正確な方法がある間、Path MTUディスカバリーの使用が、TCPが衛星チャンネルの上に可能な限り大きいMTUを使用するのを許容することが勧められます。
3.2 Forward Error Correction
3.2 前進型誤信号訂正
A loss event in TCP is always interpreted as an indication of congestion and always causes TCP to reduce its congestion window size. Since the congestion window grows based on returning acknowledgments (see section 4), TCP spends a long time recovering from loss when operating in satellite networks. When packet loss is due to corruption, rather than congestion, TCP does not need to reduce its congestion window size. However, at the present time detecting corruption loss is a research issue.
TCPの損失出来事で、混雑のしるしとしていつも解釈されて、TCPは混雑ウィンドウサイズをいつも減少させます。 混雑ウィンドウが戻っている承認に基づくようになるので(セクション4を見てください)、TCPは長い間衛星ネットワークで作動するとき、損失から回復しながら、費やします。 パケット損失が混雑よりむしろ不正のためであるときに、TCPは混雑ウィンドウサイズを減少させる必要はありません。 しかしながら、現在では、不正損失を検出するのは、研究課題です。
Therefore, for TCP to operate efficiently, the channel characteristics should be such that nearly all loss is due to network congestion. The use of forward error correction coding (FEC) on a satellite link should be used to improve the bit-error rate (BER) of the satellite channel. Reducing the BER is not always possible in satellite environments. However, since TCP takes a long time to recover from lost packets because the long propagation delay imposed by a satellite link delays feedback from the receiver [PS97], the link should be made as clean as possible to prevent TCP connections from receiving false congestion signals. This document does not make a specific BER recommendation for TCP other than it should be as low as possible.
したがって、TCPが効率的に作動するように、チャネル特性はほとんどすべての損失がネットワークの混雑のためであるようにものであるべきです。 衛星中継における前進型誤信号訂正コード化(FEC)の使用は、衛星チャンネルのビット誤り率(BER)を改良するのに使用されるべきです。 BERを減少させるのは衛星環境でいつも可能であるというわけではありません。 しかしながら、TCPが衛星中継によって課された長い伝播遅延が受信機[PS97]からフィードバックを遅らせるので無くなっているパケットから回復するには長い時かかるので、リンクをTCP接続が偽の混雑信号を受け取るのを防ぐためにできるだけきれいにするべきです。 このドキュメントは、それ以外のTCPができるだけ低いはずであるので、特定のBER推薦状をしません。
FEC should not be expected to fix all problems associated with noisy satellite links. There are some situations where FEC cannot be expected to solve the noise problem (such as military jamming, deep space missions, noise caused by rain fade, etc.). In addition, link
FECが騒がしい衛星中継に関連しているすべての問題を修正するというわけではないと予想されるべきです。 いくつかの状況が雑音問題(軍事のジャム、深い宇宙ミッション、雨のフェードによって引き起こされた雑音などの)を解決することをFECを期待できないところにあります。 さらに、リンクしてください。
Allman, et. al. Best Current Practice [Page 7] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
etオールマン、アル。 1999年1月に衛星チャンネルの上にTCPを高める最も良い現在の習慣[7ページ]RFC2488
outages can also cause problems in satellite systems that do not occur as frequently in terrestrial networks. Finally, FEC is not without cost. FEC requires additional hardware and uses some of the available bandwidth. It can add delay and timing jitter due to the processing time of the coder/decoder.
また、供給停止は頻繁な地球のネットワークのように現れないサテライト・システムで問題を起こすことができます。 最終的に、FECが費用と共にあります。 FECは追加ハードウェアを必要として、いくらかの利用可能な帯域幅を使用します。 それは符号化器/デコーダの処理時間による遅れとタイミングジターを加えることができます。
Further research is needed into mechanisms that allow TCP to differentiate between congestion induced drops and those caused by corruption. Such a mechanism would allow TCP to respond to congestion in an appropriate manner, as well as repairing corruption induced loss without reducing the transmission rate. However, in the absence of such a mechanism packet loss must be assumed to indicate congestion to preserve network stability. Incorrectly interpreting loss as caused by corruption and not reducing the transmission rate accordingly can lead to congestive collapse [Jac88] [FF98].
さらなる研究がTCPが混雑の誘発された低下と不正で引き起こされたものを区別できるメカニズムに必要です。 そのようなメカニズムで、TCPは通信速度を減少させないで不正誘発された損失を修理することと同様に適切な方法で混雑に応じることができるでしょう。 しかしながら、そのようなメカニズムがないとき、ネットワークの安定性を保存するために混雑を示すとパケット損失を思わなければなりません。 不正で引き起こされて、通信速度を減少させないと不当に損失を解釈するのはそれに従って、充血性の崩壊[Jac88][FF98]に通じることができます。
4. Standard TCP Mechanisms
4. 標準のTCPメカニズム
This section outlines TCP mechanisms that may be necessary in satellite or hybrid satellite/terrestrial networks to better utilize the available capacity of the link. These mechanisms may also be needed to fully utilize fast terrestrial channels. Furthermore, these mechanisms do not fundamentally hurt performance in a shared terrestrial network. Each of the following sections outlines one mechanism and why that mechanism may be needed.
このセクションはリンクの有効な容量をよりよく利用するのに衛星かハイブリッド衛星/地球のネットワークで必要であるかもしれないTCPメカニズムについて概説します。 また、これらのメカニズムが速い陸生のチャンネルを完全に利用するのが必要であるかもしれません。 その上、これらのメカニズムは共有された地球のネットワークで基本的に痛んでいない性能をします。 それぞれの以下のセクションは1つのメカニズムとそのメカニズムが必要であるかもしれない理由について概説します。
4.1 Congestion Control
4.1 輻輳制御
To avoid generating an inappropriate amount of network traffic for the current network conditions, during a connection TCP employs four congestion control mechanisms [Jac88] [Jac90] [Ste97]. These algorithms are slow start, congestion avoidance, fast retransmit and fast recovery. These algorithms are used to adjust the amount of unacknowledged data that can be injected into the network and to retransmit segments dropped by the network.
現在のネットワーク状態のために接続の間、不適当な量のネットワークトラフィックを発生させるのを避けるために、TCPは4つの輻輳制御メカニズム[Jac88][Jac90][Ste97]を使います。 これらのアルゴリズムは遅れた出発、輻輳回避に速く再送されるということであり、断食は回復です。 これらのアルゴリズムは、ネットワークに注ぐことができる不承認のデータの量を調整して、ネットワークによって落とされたセグメントを再送するのに使用されます。
TCP senders use two state variables to accomplish congestion control. The first variable is the congestion window (cwnd). This is an upper bound on the amount of data the sender can inject into the network before receiving an acknowledgment (ACK). The value of cwnd is limited to the receiver's advertised window. The congestion window is increased or decreased during the transfer based on the inferred amount of congestion present in the network. The second variable is the slow start threshold (ssthresh). This variable determines which algorithm is used to increase the value of cwnd. If cwnd is less than ssthresh the slow start algorithm is used to increase the value of cwnd. However, if cwnd is greater than or equal to (or just greater than in some TCP implementations) ssthresh the congestion
TCP送付者は、輻輳制御を実行するのに2つの州の変数を使用します。 最初の変数は混雑ウィンドウ(cwnd)です。 承認(ACK)を受ける前に、これは送付者がネットワークを注ぐことができるデータ量に関する上限です。 cwndの値は受信機の広告を出している窓に制限されます。 混雑ウィンドウは、ネットワークにおける現在の混雑の推論された量に基づく転送の間、増加するか、または減少します。 2番目の変数は遅れた出発敷居(ssthresh)です。 この変数は、どのアルゴリズムがcwndの値を増加させるのに使用されるかを決定します。 cwndがssthresh以下であるなら、遅れた出発アルゴリズムは、cwndの値を増加させるのに使用されます。 しかしながら、cwndは混雑をよりssthreshする(または、まさしくいくらかのTCPより大きい実現)ことです。
Allman, et. al. Best Current Practice [Page 8] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
etオールマン、アル。 1999年1月に衛星チャンネルの上にTCPを高める最も良い現在の習慣[8ページ]RFC2488
avoidance algorithm is used. The initial value of ssthresh is the receiver's advertised window size. Furthermore, the value of ssthresh is set when congestion is detected.
回避アルゴリズムは使用されています。 ssthreshの初期の値は受信機の広告を出しているウィンドウサイズです。 混雑が検出されるとき、その上、ssthreshの値は設定されます。
The four congestion control algorithms are outlined below, followed by a brief discussion of the impact of satellite environments on these algorithms.
4つの輻輳制御アルゴリズムが以下に概説されています、これらのアルゴリズムについての衛星環境の影響の簡潔な議論があとに続いていて。
4.1.1 Slow Start and Congestion Avoidance
4.1.1 遅れた出発と輻輳回避
When a host begins sending data on a TCP connection the host has no knowledge of the current state of the network between itself and the data receiver. In order to avoid transmitting an inappropriately large burst of traffic, the data sender is required to use the slow start algorithm at the beginning of a transfer [Jac88] [Bra89] [Ste97]. Slow start begins by initializing cwnd to 1 segment (although an IETF experimental mechanism would increase the size of the initial window to roughly 4 Kbytes [AFP98]) and ssthresh to the receiver's advertised window. This forces TCP to transmit one segment and wait for the corresponding ACK. For each ACK that is received during slow start, the value of cwnd is increased by 1 segment. For example, after the first ACK is received cwnd will be 2 segments and the sender will be allowed to transmit 2 data packets. This continues until cwnd meets or exceeds ssthresh (or, in some implementations when cwnd equals ssthresh), or loss is detected.
ホストがTCP接続にデータを送り始める場合、ホストはそれ自体とデータ受信装置の間にネットワークの現状に関する知識を全く持っていません。交通の不適当に大きい炸裂を伝えるのを避けるために、データ送付者は転送[Jac88][Bra89][Ste97]の始めに遅れた出発アルゴリズムを使用しなければなりません。 遅れた出発は、1セグメント(IETFの実験メカニズムは初期の窓のサイズをおよそ4キロバイト[AFP98]まで増加させるでしょうが)とssthreshにcwndを初期化することによって、受信機の広告を出している窓に始まります。 これは、TCPが1つのセグメントを伝えて、対応するACKを待つのを強制します。 遅れた出発の間に受け取られる各ACKに関しては、cwndの値は1つのセグメントによって増加させられます。 例えば、最初のACKが受け取られていた後にcwndは2つのセグメントになるでしょう、そして、送付者は2つのデータ・パケットを伝えることができるでしょう。 cwndがssthresh(またはcwndがssthreshと等しくいくつかの実現で)を会うか、超えている、または損失が検出されるまで、これは続きます。
When the value of cwnd is greater than or equal to (or equal to in certain implementations) ssthresh the congestion avoidance algorithm is used to increase cwnd [Jac88] [Bra89] [Ste97]. This algorithm increases the size of cwnd more slowly than does slow start. Congestion avoidance is used to slowly probe the network for additional capacity. During congestion avoidance, cwnd is increased by 1/cwnd for each incoming ACK. Therefore, if one ACK is received for every data segment, cwnd will increase by roughly 1 segment per round-trip time (RTT).
cwndの値がそう以上ときに、ssthreshに、輻輳回避アルゴリズムは、cwnd[Jac88][Bra89][Ste97]を増加させるのに使用されます。 このアルゴリズムはcwndのサイズを遅れた出発よりゆっくり増加させます。 輻輳回避は、追加容量のためにゆっくりネットワークを調べるのに使用されます。 輻輳回避の間、1/cwndはそれぞれの入って来るACKのためにcwndを増加させます。 したがって、あらゆるデータ・セグメントのために1ACKを受け取ると、cwndは往復の時間(RTT)あたりおよそ1つのセグメントで増加するでしょう。
The slow start and congestion control algorithms can force poor utilization of the available channel bandwidth when using long-delay satellite networks [All97]. For example, transmission begins with the transmission of one segment. After the first segment is transmitted the data sender is forced to wait for the corresponding ACK. When using a GSO satellite this leads to an idle time of roughly 500 ms when no useful work is being accomplished. Therefore, slow start takes more real time over GSO satellites than on typical terrestrial channels. This holds for congestion avoidance, as well [All97]. This is precisely why Path MTU Discovery is an important algorithm. While the number of segments we transmit is determined by the congestion control algorithms, the size of these segments is not.
The slow start and congestion control algorithms can force poor utilization of the available channel bandwidth when using long-delay satellite networks [All97]. For example, transmission begins with the transmission of one segment. After the first segment is transmitted the data sender is forced to wait for the corresponding ACK. When using a GSO satellite this leads to an idle time of roughly 500 ms when no useful work is being accomplished. Therefore, slow start takes more real time over GSO satellites than on typical terrestrial channels. This holds for congestion avoidance, as well [All97]. This is precisely why Path MTU Discovery is an important algorithm. While the number of segments we transmit is determined by the congestion control algorithms, the size of these segments is not.
Allman, et. al. Best Current Practice [Page 9] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Allman, et. al. Best Current Practice [Page 9] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Therefore, using larger packets will enable TCP to send more data per segment which yields better channel utilization.
Therefore, using larger packets will enable TCP to send more data per segment which yields better channel utilization.
4.1.2 Fast Retransmit and Fast Recovery
4.1.2 Fast Retransmit and Fast Recovery
TCP's default mechanism to detect dropped segments is a timeout [Pos81]. In other words, if the sender does not receive an ACK for a given packet within the expected amount of time the segment will be retransmitted. The retransmission timeout (RTO) is based on observations of the RTT. In addition to retransmitting a segment when the RTO expires, TCP also uses the lost segment as an indication of congestion in the network. In response to the congestion, the value of ssthresh is set to half of the cwnd and the value of cwnd is then reduced to 1 segment. This triggers the use of the slow start algorithm to increase cwnd until the value of cwnd reaches half of its value when congestion was detected. After the slow start phase, the congestion avoidance algorithm is used to probe the network for additional capacity.
TCP's default mechanism to detect dropped segments is a timeout [Pos81]. In other words, if the sender does not receive an ACK for a given packet within the expected amount of time the segment will be retransmitted. The retransmission timeout (RTO) is based on observations of the RTT. In addition to retransmitting a segment when the RTO expires, TCP also uses the lost segment as an indication of congestion in the network. In response to the congestion, the value of ssthresh is set to half of the cwnd and the value of cwnd is then reduced to 1 segment. This triggers the use of the slow start algorithm to increase cwnd until the value of cwnd reaches half of its value when congestion was detected. After the slow start phase, the congestion avoidance algorithm is used to probe the network for additional capacity.
TCP ACKs always acknowledge the highest in-order segment that has arrived. Therefore an ACK for segment X also effectively ACKs all segments < X. Furthermore, if a segment arrives out-of-order the ACK triggered will be for the highest in-order segment, rather than the segment that just arrived. For example, assume segment 11 has been dropped somewhere in the network and segment 12 arrives at the receiver. The receiver is going to send a duplicate ACK covering segment 10 (and all previous segments).
TCP ACKs always acknowledge the highest in-order segment that has arrived. Therefore an ACK for segment X also effectively ACKs all segments < X. Furthermore, if a segment arrives out-of-order the ACK triggered will be for the highest in-order segment, rather than the segment that just arrived. For example, assume segment 11 has been dropped somewhere in the network and segment 12 arrives at the receiver. The receiver is going to send a duplicate ACK covering segment 10 (and all previous segments).
The fast retransmit algorithm uses these duplicate ACKs to detect lost segments. If 3 duplicate ACKs arrive at the data originator, TCP assumes that a segment has been lost and retransmits the missing segment without waiting for the RTO to expire. After a segment is resent using fast retransmit, the fast recovery algorithm is used to adjust the congestion window. First, the value of ssthresh is set to half of the value of cwnd. Next, the value of cwnd is halved. Finally, the value of cwnd is artificially increased by 1 segment for each duplicate ACK that has arrived. The artificial inflation can be done because each duplicate ACK represents 1 segment that has left the network. When the cwnd permits, TCP is able to transmit new data. This allows TCP to keep data flowing through the network at half the rate it was when loss was detected. When an ACK for the retransmitted packet arrives, the value of cwnd is reduced back to ssthresh (half the value of cwnd when the congestion was detected).
The fast retransmit algorithm uses these duplicate ACKs to detect lost segments. If 3 duplicate ACKs arrive at the data originator, TCP assumes that a segment has been lost and retransmits the missing segment without waiting for the RTO to expire. After a segment is resent using fast retransmit, the fast recovery algorithm is used to adjust the congestion window. First, the value of ssthresh is set to half of the value of cwnd. Next, the value of cwnd is halved. Finally, the value of cwnd is artificially increased by 1 segment for each duplicate ACK that has arrived. The artificial inflation can be done because each duplicate ACK represents 1 segment that has left the network. When the cwnd permits, TCP is able to transmit new data. This allows TCP to keep data flowing through the network at half the rate it was when loss was detected. When an ACK for the retransmitted packet arrives, the value of cwnd is reduced back to ssthresh (half the value of cwnd when the congestion was detected).
Allman, et. al. Best Current Practice [Page 10] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Allman, et. al. Best Current Practice [Page 10] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Generally, fast retransmit can resend only one segment per window of data sent. When multiple segments are lost in a given window of data, one of the segments will be resent using fast retransmit and the rest of the dropped segments must usually wait for the RTO to expire, which causes TCP to revert to slow start.
Generally, fast retransmit can resend only one segment per window of data sent. When multiple segments are lost in a given window of data, one of the segments will be resent using fast retransmit and the rest of the dropped segments must usually wait for the RTO to expire, which causes TCP to revert to slow start.
TCP's response to congestion differs based on the way the congestion is detected. If the retransmission timer causes a packet to be resent, TCP drops ssthresh to half the current cwnd and reduces the value of cwnd to 1 segment (thus triggering slow start). However, if a segment is resent via fast retransmit both ssthresh and cwnd are set to half the current value of cwnd and congestion avoidance is used to send new data. The difference is that when retransmitting due to duplicate ACKs, TCP knows that packets are still flowing through the network and can therefore infer that the congestion is not that bad. However, when resending a packet due to the expiration of the retransmission timer, TCP cannot infer anything about the state of the network and therefore must proceed conservatively by sending new data using the slow start algorithm.
TCP's response to congestion differs based on the way the congestion is detected. If the retransmission timer causes a packet to be resent, TCP drops ssthresh to half the current cwnd and reduces the value of cwnd to 1 segment (thus triggering slow start). However, if a segment is resent via fast retransmit both ssthresh and cwnd are set to half the current value of cwnd and congestion avoidance is used to send new data. The difference is that when retransmitting due to duplicate ACKs, TCP knows that packets are still flowing through the network and can therefore infer that the congestion is not that bad. However, when resending a packet due to the expiration of the retransmission timer, TCP cannot infer anything about the state of the network and therefore must proceed conservatively by sending new data using the slow start algorithm.
Note that the fast retransmit/fast recovery algorithms, as discussed above can lead to a phenomenon that allows multiple fast retransmits per window of data [Flo94]. This can reduce the size of the congestion window multiple times in response to a single "loss event". The problem is particularly noticeable in connections that utilize large congestion windows, since these connections are able to inject enough new segments into the network during recovery to trigger the multiple fast retransmits. Reducing cwnd multiple times for a single loss event may hurt performance [GJKFV98].
Note that the fast retransmit/fast recovery algorithms, as discussed above can lead to a phenomenon that allows multiple fast retransmits per window of data [Flo94]. This can reduce the size of the congestion window multiple times in response to a single "loss event". The problem is particularly noticeable in connections that utilize large congestion windows, since these connections are able to inject enough new segments into the network during recovery to trigger the multiple fast retransmits. Reducing cwnd multiple times for a single loss event may hurt performance [GJKFV98].
The best way to improve the fast retransmit/fast recovery algorithms is to use a selective acknowledgment (SACK) based algorithm for loss recovery. As discussed below, these algorithms are generally able to quickly recover from multiple lost segments without needlessly reducing the value of cwnd. In the absence of SACKs, the fast retransmit and fast recovery algorithms should be used. Fixing these algorithms to achieve better performance in the face of multiple fast retransmissions is beyond the scope of this document. Therefore, TCP implementers are advised to implement the current version of fast retransmit/fast recovery outlined in RFC 2001 [Ste97] or subsequent versions of RFC 2001.
The best way to improve the fast retransmit/fast recovery algorithms is to use a selective acknowledgment (SACK) based algorithm for loss recovery. As discussed below, these algorithms are generally able to quickly recover from multiple lost segments without needlessly reducing the value of cwnd. In the absence of SACKs, the fast retransmit and fast recovery algorithms should be used. Fixing these algorithms to achieve better performance in the face of multiple fast retransmissions is beyond the scope of this document. Therefore, TCP implementers are advised to implement the current version of fast retransmit/fast recovery outlined in RFC 2001 [Ste97] or subsequent versions of RFC 2001.
4.1.3 Congestion Control in Satellite Environment
4.1.3 Congestion Control in Satellite Environment
The above algorithms have a negative impact on the performance of individual TCP connection's performance because the algorithms slowly probe the network for additional capacity, which in turn wastes bandwidth. This is especially true over long-delay satellite
The above algorithms have a negative impact on the performance of individual TCP connection's performance because the algorithms slowly probe the network for additional capacity, which in turn wastes bandwidth. This is especially true over long-delay satellite
Allman, et. al. Best Current Practice [Page 11] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Allman, et. al. Best Current Practice [Page 11] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
channels because of the large amount of time required for the sender to obtain feedback from the receiver [All97] [AHKO97]. However, the algorithms are necessary to prevent congestive collapse in a shared network [Jac88]. Therefore, the negative impact on a given connection is more than offset by the benefit to the entire network.
channels because of the large amount of time required for the sender to obtain feedback from the receiver [All97] [AHKO97]. However, the algorithms are necessary to prevent congestive collapse in a shared network [Jac88]. Therefore, the negative impact on a given connection is more than offset by the benefit to the entire network.
4.2 Large TCP Windows
4.2 Large TCP Windows
The standard maximum TCP window size (65,535 bytes) is not adequate to allow a single TCP connection to utilize the entire bandwidth available on some satellite channels. TCP throughput is limited by the following formula [Pos81]:
The standard maximum TCP window size (65,535 bytes) is not adequate to allow a single TCP connection to utilize the entire bandwidth available on some satellite channels. TCP throughput is limited by the following formula [Pos81]:
throughput = window size / RTT
throughput = window size / RTT
Therefore, using the maximum window size of 65,535 bytes and a geosynchronous satellite channel RTT of 560 ms [Kru95] the maximum throughput is limited to:
Therefore, using the maximum window size of 65,535 bytes and a geosynchronous satellite channel RTT of 560 ms [Kru95] the maximum throughput is limited to:
throughput = 65,535 bytes / 560 ms = 117,027 bytes/second
throughput = 65,535 bytes / 560 ms = 117,027 bytes/second
Therefore, a single standard TCP connection cannot fully utilize, for example, T1 rate (approximately 192,000 bytes/second) GSO satellite channels. However, TCP has been extended to support larger windows [JBB92]. The window scaling options outlined in [JBB92] should be used in satellite environments, as well as the companion algorithms PAWS (Protection Against Wrapped Sequence space) and RTTM (Round-Trip Time Measurements).
Therefore, a single standard TCP connection cannot fully utilize, for example, T1 rate (approximately 192,000 bytes/second) GSO satellite channels. However, TCP has been extended to support larger windows [JBB92]. The window scaling options outlined in [JBB92] should be used in satellite environments, as well as the companion algorithms PAWS (Protection Against Wrapped Sequence space) and RTTM (Round-Trip Time Measurements).
It should be noted that for a satellite link shared among many flows, large windows may not be necessary. For instance, two long-lived TCP connections each using a window of 65,535 bytes, as in the above example, can fully utilize a T1 GSO satellite channel.
It should be noted that for a satellite link shared among many flows, large windows may not be necessary. For instance, two long-lived TCP connections each using a window of 65,535 bytes, as in the above example, can fully utilize a T1 GSO satellite channel.
Using large windows often requires both client and server applications or TCP stacks to be hand tuned (usually by an expert) to utilize large windows. Research into operating system mechanisms that are able to adjust the buffer capacity as dictated by the current network conditions is currently underway [SMM98]. This will allow stock TCP implementations and applications to better utilize the capacity provided by the underlying network.
Using large windows often requires both client and server applications or TCP stacks to be hand tuned (usually by an expert) to utilize large windows. Research into operating system mechanisms that are able to adjust the buffer capacity as dictated by the current network conditions is currently underway [SMM98]. This will allow stock TCP implementations and applications to better utilize the capacity provided by the underlying network.
4.3 Acknowledgment Strategies
4.3 Acknowledgment Strategies
There are two standard methods that can be used by TCP receivers to generated acknowledgments. The method outlined in [Pos81] generates an ACK for each incoming segment. [Bra89] states that hosts SHOULD use "delayed acknowledgments". Using this algorithm, an ACK is
There are two standard methods that can be used by TCP receivers to generated acknowledgments. The method outlined in [Pos81] generates an ACK for each incoming segment. [Bra89] states that hosts SHOULD use "delayed acknowledgments". Using this algorithm, an ACK is
Allman, et. al. Best Current Practice [Page 12] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Allman, et. al. Best Current Practice [Page 12] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
generated for every second full-sized segment, or if a second full- size segment does not arrive within a given timeout (which must not exceed 500 ms). The congestion window is increased based on the number of incoming ACKs and delayed ACKs reduce the number of ACKs being sent by the receiver. Therefore, cwnd growth occurs much more slowly when using delayed ACKs compared to the case when the receiver ACKs each incoming segment [All98].
generated for every second full-sized segment, or if a second full- size segment does not arrive within a given timeout (which must not exceed 500 ms). The congestion window is increased based on the number of incoming ACKs and delayed ACKs reduce the number of ACKs being sent by the receiver. Therefore, cwnd growth occurs much more slowly when using delayed ACKs compared to the case when the receiver ACKs each incoming segment [All98].
A tempting "fix" to the problem caused by delayed ACKs is to simply turn the mechanism off and let the receiver ACK each incoming segment. However, this is not recommended. First, [Bra89] says that a TCP receiver SHOULD generate delayed ACKs. And, second, increasing the number of ACKs by a factor of two in a shared network may have consequences that are not yet understood. Therefore, disabling delayed ACKs is still a research issue and thus, at this time TCP receivers should continue to generate delayed ACKs, per [Bra89].
A tempting "fix" to the problem caused by delayed ACKs is to simply turn the mechanism off and let the receiver ACK each incoming segment. However, this is not recommended. First, [Bra89] says that a TCP receiver SHOULD generate delayed ACKs. And, second, increasing the number of ACKs by a factor of two in a shared network may have consequences that are not yet understood. Therefore, disabling delayed ACKs is still a research issue and thus, at this time TCP receivers should continue to generate delayed ACKs, per [Bra89].
4.4 Selective Acknowledgments
4.4 Selective Acknowledgments
Selective acknowledgments (SACKs) [MMFR96] allow TCP receivers to inform TCP senders exactly which packets have arrived. SACKs allow TCP to recover more quickly from lost segments, as well as avoiding needless retransmissions.
Selective acknowledgments (SACKs) [MMFR96] allow TCP receivers to inform TCP senders exactly which packets have arrived. SACKs allow TCP to recover more quickly from lost segments, as well as avoiding needless retransmissions.
The fast retransmit algorithm can generally only repair one loss per window of data. When multiple losses occur, the sender generally must rely on a timeout to determine which segment needs to be retransmitted next. While waiting for a timeout, the data segments and their acknowledgments drain from the network. In the absence of incoming ACKs to clock new segments into the network, the sender must use the slow start algorithm to restart transmission. As discussed above, the slow start algorithm can be time consuming over satellite channels. When SACKs are employed, the sender is generally able to determine which segments need to be retransmitted in the first RTT following loss detection. This allows the sender to continue to transmit segments (retransmissions and new segments, if appropriate) at an appropriate rate and therefore sustain the ACK clock. This avoids a costly slow start period following multiple lost segments. Generally SACK is able to retransmit all dropped segments within the first RTT following the loss detection. [MM96] and [FF96] discuss specific congestion control algorithms that rely on SACK information to determine which segments need to be retransmitted and when it is appropriate to transmit those segments. Both these algorithms follow the basic principles of congestion control outlined in [Jac88] and reduce the window by half when congestion is detected.
The fast retransmit algorithm can generally only repair one loss per window of data. When multiple losses occur, the sender generally must rely on a timeout to determine which segment needs to be retransmitted next. While waiting for a timeout, the data segments and their acknowledgments drain from the network. In the absence of incoming ACKs to clock new segments into the network, the sender must use the slow start algorithm to restart transmission. As discussed above, the slow start algorithm can be time consuming over satellite channels. When SACKs are employed, the sender is generally able to determine which segments need to be retransmitted in the first RTT following loss detection. This allows the sender to continue to transmit segments (retransmissions and new segments, if appropriate) at an appropriate rate and therefore sustain the ACK clock. This avoids a costly slow start period following multiple lost segments. Generally SACK is able to retransmit all dropped segments within the first RTT following the loss detection. [MM96] and [FF96] discuss specific congestion control algorithms that rely on SACK information to determine which segments need to be retransmitted and when it is appropriate to transmit those segments. Both these algorithms follow the basic principles of congestion control outlined in [Jac88] and reduce the window by half when congestion is detected.
Allman, et. al. Best Current Practice [Page 13] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Allman, et. al. Best Current Practice [Page 13] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
5. Mitigation Summary
5. Mitigation Summary
Table 1 summarizes the mechanisms that have been discussed in this document. Those mechanisms denoted "Recommended" are IETF standards track mechanisms that are recommended by the authors for use in networks containing satellite channels. Those mechanisms marked "Required' have been defined by the IETF as required for hosts using the shared Internet [Bra89]. Along with the section of this document containing the discussion of each mechanism, we note where the mechanism needs to be implemented. The codes listed in the last column are defined as follows: "S" for the data sender, "R" for the data receiver and "L" for the satellite link.
Table 1 summarizes the mechanisms that have been discussed in this document. Those mechanisms denoted "Recommended" are IETF standards track mechanisms that are recommended by the authors for use in networks containing satellite channels. Those mechanisms marked "Required' have been defined by the IETF as required for hosts using the shared Internet [Bra89]. Along with the section of this document containing the discussion of each mechanism, we note where the mechanism needs to be implemented. The codes listed in the last column are defined as follows: "S" for the data sender, "R" for the data receiver and "L" for the satellite link.
Mechanism Use Section Where
+------------------------+-------------+------------+--------+
| Path-MTU Discovery | Recommended | 3.1 | S |
| FEC | Recommended | 3.2 | L |
| TCP Congestion Control | | | |
| Slow Start | Required | 4.1.1 | S |
| Congestion Avoidance | Required | 4.1.1 | S |
| Fast Retransmit | Recommended | 4.1.2 | S |
| Fast Recovery | Recommended | 4.1.2 | S |
| TCP Large Windows | | | |
| Window Scaling | Recommended | 4.2 | S,R |
| PAWS | Recommended | 4.2 | S,R |
| RTTM | Recommended | 4.2 | S,R |
| TCP SACKs | Recommended | 4.4 | S,R |
+------------------------+-------------+------------+--------+
Table 1
Mechanism Use Section Where +------------------------+-------------+------------+--------+ | Path-MTU Discovery | Recommended | 3.1 | S | | FEC | Recommended | 3.2 | L | | TCP Congestion Control | | | | | Slow Start | Required | 4.1.1 | S | | Congestion Avoidance | Required | 4.1.1 | S | | Fast Retransmit | Recommended | 4.1.2 | S | | Fast Recovery | Recommended | 4.1.2 | S | | TCP Large Windows | | | | | Window Scaling | Recommended | 4.2 | S,R | | PAWS | Recommended | 4.2 | S,R | | RTTM | Recommended | 4.2 | S,R | | TCP SACKs | Recommended | 4.4 | S,R | +------------------------+-------------+------------+--------+ Table 1
Satellite users should check with their TCP vendors (implementors) to ensure the recommended mechanisms are supported in their stack in current and/or future versions. Alternatively, the Pittsburgh Supercomputer Center tracks TCP implementations and which extensions they support, as well as providing guidance on tuning various TCP implementations [PSC].
Satellite users should check with their TCP vendors (implementors) to ensure the recommended mechanisms are supported in their stack in current and/or future versions. Alternatively, the Pittsburgh Supercomputer Center tracks TCP implementations and which extensions they support, as well as providing guidance on tuning various TCP implementations [PSC].
Research into improving the efficiency of TCP over satellite channels is ongoing and will be summarized in a planned memo along with other considerations, such as satellite network architectures.
Research into improving the efficiency of TCP over satellite channels is ongoing and will be summarized in a planned memo along with other considerations, such as satellite network architectures.
6. Security Considerations
6. Security Considerations
The authors believe that the recommendations contained in this memo do not alter the security implications of TCP. However, when using a broadcast medium such as satellites links to transfer user data and/or network control traffic, one should be aware of the intrinsic security implications of such technology.
The authors believe that the recommendations contained in this memo do not alter the security implications of TCP. However, when using a broadcast medium such as satellites links to transfer user data and/or network control traffic, one should be aware of the intrinsic security implications of such technology.
Allman, et. al. Best Current Practice [Page 14] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Allman, et. al. Best Current Practice [Page 14] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Eavesdropping on network links is a form of passive attack that, if performed successfully, could reveal critical traffic control information that would jeopardize the proper functioning of the network. These attacks could reduce the ability of the network to provide data transmission services efficiently. Eavesdroppers could also compromise the privacy of user data, especially if end-to-end security mechanisms are not in use. While passive monitoring can occur on any network, the wireless broadcast nature of satellite links allows reception of signals without physical connection to the network which enables monitoring to be conducted without detection. However, it should be noted that the resources needed to monitor a satellite link are non-trivial.
Eavesdropping on network links is a form of passive attack that, if performed successfully, could reveal critical traffic control information that would jeopardize the proper functioning of the network. These attacks could reduce the ability of the network to provide data transmission services efficiently. Eavesdroppers could also compromise the privacy of user data, especially if end-to-end security mechanisms are not in use. While passive monitoring can occur on any network, the wireless broadcast nature of satellite links allows reception of signals without physical connection to the network which enables monitoring to be conducted without detection. However, it should be noted that the resources needed to monitor a satellite link are non-trivial.
Data encryption at the physical and/or link layers can provide secure communication over satellite channels. However, this still leaves traffic vulnerable to eavesdropping on networks before and after traversing the satellite link. Therefore, end-to-end security mechanisms should be considered. This document does not make any recommendations as to which security mechanisms should be employed. However, those operating and using satellite networks should survey the currently available network security mechanisms and choose those that meet their security requirements.
Data encryption at the physical and/or link layers can provide secure communication over satellite channels. However, this still leaves traffic vulnerable to eavesdropping on networks before and after traversing the satellite link. Therefore, end-to-end security mechanisms should be considered. This document does not make any recommendations as to which security mechanisms should be employed. However, those operating and using satellite networks should survey the currently available network security mechanisms and choose those that meet their security requirements.
Acknowledgments
Acknowledgments
This document has benefited from comments from the members of the TCP Over Satellite Working Group. In particular, we would like to thank Aaron Falk, Matthew Halsey, Hans Kruse, Matt Mathis, Greg Nakanishi, Vern Paxson, Jeff Semke, Bill Sepmeier and Eric Travis for their useful comments about this document.
This document has benefited from comments from the members of the TCP Over Satellite Working Group. In particular, we would like to thank Aaron Falk, Matthew Halsey, Hans Kruse, Matt Mathis, Greg Nakanishi, Vern Paxson, Jeff Semke, Bill Sepmeier and Eric Travis for their useful comments about this document.
References
References
[AFP98] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
Initial Window", RFC 2414, September 1998.
[AFP98] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
[AHKO97] Mark Allman, Chris Hayes, Hans Kruse, and Shawn Ostermann.
TCP Performance Over Satellite Links. In Proceedings of
the 5th International Conference on Telecommunication
Systems, March 1997.
[AHKO97] Mark Allman, Chris Hayes, Hans Kruse, and Shawn Ostermann. TCP Performance Over Satellite Links. In Proceedings of the 5th International Conference on Telecommunication Systems, March 1997.
[All97] Mark Allman. Improving TCP Performance Over Satellite
Channels. Master's thesis, Ohio University, June 1997.
[All97] Mark Allman. Improving TCP Performance Over Satellite Channels. Master's thesis, Ohio University, June 1997.
[All98] Mark Allman. On the Generation and Use of TCP
Acknowledgments. ACM Computer Communication Review, 28(5),
October 1998.
[All98] Mark Allman. On the Generation and Use of TCP Acknowledgments. ACM Computer Communication Review, 28(5), October 1998.
Allman, et. al. Best Current Practice [Page 15] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Allman, et. al. Best Current Practice [Page 15] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
[Bra89] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[FF96] Kevin Fall and Sally Floyd. Simulation-based Comparisons
of Tahoe, Reno and SACK TCP. Computer Communication
Review, July 1996.
[FF96] Kevin Fall and Sally Floyd. Simulation-based Comparisons of Tahoe, Reno and SACK TCP. Computer Communication Review, July 1996.
[FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End
Congestion Control in the Internet. Submitted to IEEE
Transactions on Networking.
[FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet. Submitted to IEEE Transactions on Networking.
[Flo94] S. Floyd, TCP and Successive Fast Retransmits. Technical
report, October 1994.
ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.
[Flo94] S. Floyd, TCP and Successive Fast Retransmits. Technical report, October 1994. ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.
[GJKFV98] Rohit Goyal, Raj Jain, Shiv Kalyanaraman, Sonia Fahmy,
Bobby Vandalore, Improving the Performance of TCP over the
ATM-UBR service, 1998. Sumbitted to Computer
Communications.
[GJKFV98] Rohit Goyal, Raj Jain, Shiv Kalyanaraman, Sonia Fahmy, Bobby Vandalore, Improving the Performance of TCP over the ATM-UBR service, 1998. Sumbitted to Computer Communications.
[Jac90] Van Jacobson. Modified TCP Congestion Avoidance Algorithm.
Technical Report, LBL, April 1990.
[Jac90] Van Jacobson. Modified TCP Congestion Avoidance Algorithm. Technical Report, LBL, April 1990.
[JBB92] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992.
[JBB92] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[Jac88] Van Jacobson. Congestion Avoidance and Control. In ACM
SIGCOMM, 1988.
[Jac88] Van Jacobson. Congestion Avoidance and Control. In ACM SIGCOMM, 1988.
[Kno93] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[Kno93] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[Mar78] James Martin. Communications Satellite Systems. Prentice
Hall, 1978.
[Mar78] James Martin. Communications Satellite Systems. Prentice Hall, 1978.
[MD90] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[MD90] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[MM96] Matt Mathis and Jamshid Mahdavi. Forward Acknowledgment:
Refining TCP Congestion Control. In ACM SIGCOMM, 1996.
[MM96] Matt Mathis and Jamshid Mahdavi. Forward Acknowledgment: Refining TCP Congestion Control. In ACM SIGCOMM, 1996.
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[Mon98] M. J. Montpetit. TELEDESIC: Enabling The Global Community
Interaccess. In Proc. of the International Wireless
Symposium, May 1998.
[Mon98] M. J. Montpetit. TELEDESIC: Enabling The Global Community Interaccess. In Proc. of the International Wireless Symposium, May 1998.
Allman, et. al. Best Current Practice [Page 16] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Allman, et. al. Best Current Practice [Page 16] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
[MSMO97] M. Mathis, J. Semke, J. Mahdavi, T. Ott, "The Macroscopic
Behavior of the TCP Congestion Avoidance Algorithm",
Computer Communication Review, volume 27, number3, July
1997. available from
http://www.psc.edu/networking/papers/papers.html.
[MSMO97] M. Mathis, J. Semke, J. Mahdavi, T. Ott, "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", Computer Communication Review, volume 27, number3, July 1997. available from http://www.psc.edu/networking/papers/papers.html.
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[PS97] Craig Partridge and Tim Shepard. TCP Performance Over
Satellite Links. IEEE Network, 11(5), September/October
1997.
[PS97] Craig Partridge and Tim Shepard. TCP Performance Over Satellite Links. IEEE Network, 11(5), September/October 1997.
[PSC] Jamshid Mahdavi. Enabling High Performance Data Transfers
on Hosts. http://www.psc.edu/networking/perf_tune.html.
[PSC] Jamshid Mahdavi. Enabling High Performance Data Transfers on Hosts. http://www.psc.edu/networking/perf_tune.html.
[SMM98] Jeff Semke, Jamshid Mahdavi and Matt Mathis. Automatic TCP
Buffer Tuning. In ACM SIGCOMM, August 1998. To appear.
[SMM98] Jeff Semke, Jamshid Mahdavi and Matt Mathis. Automatic TCP Buffer Tuning. In ACM SIGCOMM, August 1998. To appear.
[Sta94] William Stallings. Data and Computer Communications.
MacMillian, 4th edition, 1994.
[Sta94] William Stallings. Data and Computer Communications. MacMillian, 4th edition, 1994.
[Ste97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001,January
1997.
[Ste97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001,January 1997.
[Stu95] M. A. Sturza. Architecture of the TELEDESIC Satellite
System. In Proceedings of the International Mobile
Satellite Conference, 1995.
[Stu95] M. A. Sturza. Architecture of the TELEDESIC Satellite System. In Proceedings of the International Mobile Satellite Conference, 1995.
Allman, et. al. Best Current Practice [Page 17] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Allman, et. al. Best Current Practice [Page 17] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Authors' Addresses
Authors' Addresses
Mark Allman NASA Lewis Research Center/Sterling Software 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
Mark Allman NASA Lewis Research Center/Sterling Software 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
Phone: +1 216 433 6586 EMail: mallman@lerc.nasa.gov http://roland.lerc.nasa.gov/~mallman
Phone: +1 216 433 6586 EMail: mallman@lerc.nasa.gov http://roland.lerc.nasa.gov/~mallman
Daniel R. Glover NASA Lewis Research Center 21000 Brookpark Rd. Cleveland, OH 44135
Daniel R. Glover NASA Lewis Research Center 21000 Brookpark Rd. Cleveland, OH 44135
Phone: +1 216 433 2847 EMail: Daniel.R.Glover@lerc.nasa.gov
Phone: +1 216 433 2847 EMail: Daniel.R.Glover@lerc.nasa.gov
Luis A. Sanchez BBN Technologies GTE Internetworking 10 Moulton Street Cambridge, MA 02140 USA
Luis A. Sanchez BBN Technologies GTE Internetworking 10 Moulton Street Cambridge, MA 02140 USA
Phone: +1 617 873 3351 EMail: lsanchez@ir.bbn.com
Phone: +1 617 873 3351 EMail: lsanchez@ir.bbn.com
Allman, et. al. Best Current Practice [Page 18] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Allman, et. al. Best Current Practice [Page 18] RFC 2488 Enhancing TCP Over Satellite Channels January 1999
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright (C) The Internet Society (1999). 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.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
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.
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.
Allman, et. al. Best Current Practice [Page 19]
Allman, et. al. Best Current Practice [Page 19]
一覧
スポンサーリンク
