[要約] RFC 2488は、衛星チャネル上でのTCPの性能向上を目指し、標準的なメカニズムを使用する方法についての要約です。このRFCの目的は、衛星通信におけるTCPのパフォーマンスを向上させるためのガイドラインを提供することです。
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
Enhancing TCP Over Satellite Channels using Standard Mechanisms
標準メカニズムを使用した衛星チャネル経由のTCPの拡張
Status of this Memo
本文書の状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントでは、インターネットコミュニティのためのインターネットのベストプラクティスを示し、改善のためのディスカッションと提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
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は衛星チャネル上で機能しますが、TCPがネットワークパスの利用可能な容量をより効果的に利用できるようにするいくつかのIETF標準化メカニズムがあります。このドキュメントでは、これらのTCP緩和策のいくつかについて概説します。現時点では、このドキュメントで説明されているすべての緩和策はIETF標準の追跡メカニズムです（またはIETF標準に準拠しています）。
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 currently well understood and on the IETF standards track (or are compliant with IETF standards).
衛星チャネルの特性は、伝送制御プロトコル（TCP）[Pos81]などのトランスポートプロトコルの動作に影響を与える可能性があります。 TCPなどのプロトコルのパフォーマンスが低い場合、チャネル使用率は低くなります。トランスポートプロトコルのパフォーマンスは重要ですが、衛星リンクを含むネットワークを構築する際の考慮事項はそれだけではありません。たとえば、データリンクプロトコル、アプリケーションプロトコル、ルーターのバッファーサイズ、キューイング規則、プロキシの場所は、考慮に入れなければならない考慮事項の一部です。ただし、このドキュメントはサテライト環境でのTCPの改善に焦点を当てており、TCP以外の考慮事項は別のドキュメントに残されています。最後に、研究コミュニティによって提案され、研究された多くの衛星緩和策がありました。これらの緩和策は将来共有ネットワークにとって有用で安全であると証明されるかもしれませんが、このドキュメントでは、現在よく理解されており、IETF標準トラックにある（またはIETF標準に準拠している）TCPメカニズムのみを考慮します。
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実装に何を含める必要があるかをまとめています。
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.
多くの通信衛星は、静止軌道（GSO）にあり、高度は約36,000 kmです[Sta94]。この高度では、軌道周期は地球の自転周期と同じです。したがって、各地上局は常に空中の同じ位置にある周回衛星を「見る」ことができます。無線信号がその距離の2倍（衛星直下の地上局に対応）移動するための伝搬時間は239.6ミリ秒（ms）です[Mar78]。衛星の視野領域の端にある地上局の場合、移動距離は2 x 41,756 kmであり、合計伝搬遅延は279.0 msです[Mar78]。これらの遅延は、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 likely to use intersatellite links and have variable path delay depending on routing through the network.
低地球軌道（LEO）[Stu95] [Mon98]や中地球軌道（MEO）[Mar78]など、他の軌道を通信衛星で使用することもできます。より低い軌道では、一定のカバレッジのために衛星の星座を使用する必要があります。つまり、1つの衛星が地上局の視界を離れると、別の衛星が地平線上に現れ、チャネルがそれに切り替えられます。 LEO軌道への伝播遅延は、衛星と直接通信する場合の数ミリ秒から、衛星が水平線上にある場合の最大80ミリ秒の範囲です。これらのシステムは、衛星間リンクを使用する可能性が高く、ネットワーク経由のルーティングに応じてパス遅延が変化します。
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.
ノイズ-無線信号の強度は、移動距離の2乗に比例して低下します。衛星リンクの場合、距離が大きいため、目的地に到達する前に信号が弱くなります。これにより、信号対雑音比が低くなります。一部の周波数は、雨の減衰などの大気の影響を特に受けやすくなっています。モバイルアプリケーションの場合、衛星チャネルはマルチパスによる歪みやシャドウイング（建物による妨害など）の影響を特に受けやすくなります。今日の衛星リンクの一般的なビット誤り率（BER）は、1000万ビットあたり1エラー（1 x 10 ^ -7）以下の頻度です。高度なエラー制御コーディング（Reed Solomonなど）は、既存の衛星サービスに追加でき、現在多くのサービスで使用されています。新しいシステムで高度なエラー制御コーディングが使用されるようになると、ファイバーに接近する衛星エラーのパフォーマンスがより一般的になります。ただし、多くの従来の衛星システムは、新しい衛星システムや地上波チャネルよりも高い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.
帯域幅-無線スペクトルは限られた天然資源であるため、衛星システムが使用できる帯域幅には制限があり、通常はライセンスによって制御されます。この不足により、他の設計問題を解決するために帯域幅を交換することが困難になっています。現在のポイントツーポイントの商用衛星サービスの一般的な搬送周波数は、Cバンドとも呼ばれる6 GHz（アップリンク）と4 GHz（ダウンリンク）、および14/12 GHz（Kuバンド）です。 30/20 GHz（Kaバンド）の新しいサービスが今後数年間で出現します。衛星ベースの無線中継器はトランスポンダーとして知られています。従来のCバンドトランスポンダの帯域幅は、1つのカラーテレビチャネル（または1200音声チャネル）に対応するために、通常36 MHzです。 Kuバンドトランスポンダは通常、約50 MHzです。さらに、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.
帯域幅が本質的に制限されるだけでなく、商用通信の割り当ては国際協定によって制限されるため、この希少なリソースを多くの異なるアプリケーションで公平に使用できます。
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).
一部の衛星チャネルの伝搬遅延（静止衛星では約250ミリ秒など）により、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はスライディングウィンドウのサイズを縮小します。ただし、これらのパケットドロップはネットワークの輻輳を示していません。
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つ以上を備えたネットワークに恩恵をもたらすはずです（たとえば、ギガビットネットワークには大きな遅延*帯域幅積があります）。
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 DiscoveryおよびForward Error Correction（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 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再送信とリンクレベル再送信の間の相互作用は、今後の調査の対象となります。
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メッセージは、元のセグメントを断片化せずに送信できなかったことを示し、ゲートウェイが転送できる最大のパケットのサイズも含まれます。パス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はフラグメンテーションおよび再構成のコストを発生させることなく、可能な限り最大のパケットサイズを使用できます。大きなパケットは、オーバーヘッドバイトごとにより多くのデータバイトを送信することにより、パケットオーバーヘッドを削減します。セクション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 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検出の欠点は、TCPがデータの送信を開始する前に遅延が発生する可能性があることです。たとえば、DFビットが設定されたパケットが送信され、中間ゲートウェイ（G1）の1つがセグメントを転送できないことを示すICMPメッセージを返すとします。この時点で、送信ホストはG1から返されたICMPメッセージごとのパケットサイズを縮小し、DFビットが設定された別のパケットを送信します。パケットはG1によって転送されますが、ネットワークパス内の後続のすべてのゲートウェイがセグメントを転送できることは保証されません。 2番目のゲートウェイ（G2）がセグメントを転送できない場合は、送信ホストにICMPメッセージを返し、プロセスが繰り返されます。したがって、パスMTUディスカバリーは、送信側と受信側の間のネットワーク・パス上の最大許容パケット・サイズを決定するのに長い時間を費やす可能性があります。衛星の遅延はこの問題を悪化させる可能性があります（G1とG2の間のチャネルが衛星リンクである場合を考えてください）。ただし、実際には、一般的な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を選択する正確な方法はこのドキュメントの範囲外ですが、TCPが衛星チャネルで最大のMTUを使用できるようにするには、パスMTU検出の使用をお勧めします。
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が効率的に動作するには、ほとんどすべての損失がネットワークの輻輳が原因であるようなチャネル特性でなければなりません。衛星チャネルのビット誤り率（BER）を改善するには、衛星リンクでの前方誤り訂正符号化（FEC）の使用が必要です。衛星環境では、BERの低減が常に可能とは限りません。ただし、衛星リンクによる長い伝播遅延が受信機からのフィードバックを遅らせるため、TCPは失われたパケットからの回復に長い時間がかかるため[PS97]、リンクをできるだけクリーンにして、TCP接続が誤った輻輳信号を受信しないようにする必要があります。このドキュメントでは、TCPのBERをできるだけ低くする必要があることを除いて、特定の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 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がノイズの問題を解決することが期待できないいくつかの状況があります（軍事妨害、深宇宙ミッション、降雨によるノイズなど）。さらに、リンクの停止は、衛星ネットワークで地上ネットワークほど頻繁に発生しない問題を引き起こす可能性があります。最後に、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]。
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つのメカニズムと、そのメカニズムが必要になる理由について説明します。
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 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.
TCP送信側は、2つの状態変数を使用して輻輳制御を実現します。最初の変数は、輻輳ウィンドウ（cwnd）です。これは、送信者が確認（ACK）を受信する前にネットワークに注入できるデータ量の上限です。 cwndの値は、レシーバーのアドバタイズされたウィンドウに制限されます。ネットワークに存在する推定された輻輳の量に基づいて、転送中に輻輳ウィンドウが増減します。 2番目の変数は、スロースタートしきい値（ssthresh）です。この変数は、cwndの値を増やすために使用されるアルゴリズムを決定します。 cwndがssthreshより小さい場合は、スロースタートアルゴリズムを使用してcwndの値を増やします。ただし、cwndがssthresh以上（または一部のTCP実装の場合はそれ以上）の場合は、輻輳回避アルゴリズムが使用されます。 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つの輻輳制御アルゴリズムの概要を以下に示します。その後に、これらのアルゴリズムに対する衛星環境の影響について簡単に説明します。
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]。スロースタートは、cwndを1セグメントに初期化することから始まります（ただし、IETFの実験的なメカニズムにより、初期ウィンドウのサイズは約4 Kバイトに増加します[AFP98]）。レシーバーのアドバタイズされたウィンドウにssthreshします。これにより、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のサイズを増やします。輻輳回避は、追加の容量についてネットワークをゆっくりとプローブするために使用されます。輻輳回避中は、着信ACKごとにcwndが1 / cwndずつ増加します。したがって、データセグメントごとに1つのACKが受信されると、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.
スロースタートおよび輻輳制御アルゴリズムは、長い遅延の衛星ネットワークを使用する場合に、利用可能なチャネル帯域幅の利用率を低下させる可能性があります[All97]。たとえば、送信は1つのセグメントの送信から始まります。最初のセグメントが送信された後、データ送信側は対応するACKを待機するように強制されます。 GSO衛星を使用すると、有効な作業が行われていないときにアイドル時間が約500ミリ秒になります。したがって、スロースタートは、GSO衛星を介した場合、通常の地上波チャネルよりもリアルタイムに時間がかかります。これは、混雑回避にも当てはまります[All97]。これが、パスMTUディスカバリーが重要なアルゴリズムである理由です。送信するセグメントの数は輻輳制御アルゴリズムによって決定されますが、これらのセグメントのサイズは決定されません。
Therefore, using larger packets will enable TCP to send more data per segment which yields better channel utilization.
したがって、より大きなパケットを使用すると、TCPはセグメントごとにより多くのデータを送信できるようになり、チャネル使用率が向上します。
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のデフォルトのメカニズムはタイムアウトです[Pos81]。言い換えると、送信者が所定のパケットに対するACKを予想される時間内に受信しない場合、セグメントは再送信されます。再送信タイムアウト（RTO）は、RTTの観察に基づいています。 RTOが期限切れになったときにセグメントを再送信することに加えて、TCPは失われたセグメントをネットワークの輻輳の指標として使用します。輻輳に応じて、ssthreshの値はcwndの半分に設定され、cwndの値は1セグメントに削減されます。これにより、スロースタートアルゴリズムの使用がトリガーされ、輻輳が検出されたときにcwndの値がその値の半分に達するまでcwndが増加します。スロースタートフェーズの後、輻輳回避アルゴリズムを使用して、ネットワークの追加容量を調べます。
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 ACKは常に、到着した最も高い順序のセグメントを確認します。したがって、セグメントXのACKは、すべてのセグメント<Xよりも効果的にACKします。さらに、セグメントが順序どおりに到着しない場合、トリガーされたACKは、到着したばかりのセグメントではなく、最も高い順序のセグメントに対するものです。たとえば、セグメント11がネットワークのどこかにドロップされ、セグメント12が受信機に到着したとします。レシーバーは、セグメント10（および以前のすべてのセグメント）をカバーする重複ACKを送信します。
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).
高速再送信アルゴリズムは、これらの重複ACKを使用して、失われたセグメントを検出します。 3つの重複したACKがデータ発信元に到着した場合、TCPはセグメントが失われたと見なし、RTOが期限切れになるのを待たずに、失われたセグメントを再送信します。高速再送信を使用してセグメントが再送信された後、高速リカバリーアルゴリズムを使用して輻輳ウィンドウが調整されます。最初に、ssthreshの値はcwndの値の半分に設定されます。次に、cwndの値が半分になります。最後に、cwndの値は、到着した重複ACKごとに1セグメントずつ人為的に増加します。重複した各ACKはネットワークを離れた1つのセグメントを表すため、人工的なインフレーションを行うことができます。 cwndが許可すると、TCPは新しいデータを送信できます。これにより、TCPは、損失が検出されたときの半分の速度でネットワークを流れるデータを維持できます。再送信されたパケットのACKが到着すると、cwndの値はssthresh（輻輳が検出されたときのcwndの値の半分）に戻されます。
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.
一般に、高速再送信では、送信されたデータのウィンドウごとに1つのセグメントしか再送信できません。特定のデータウィンドウで複数のセグメントが失われた場合、セグメントの1つは高速再送信を使用して再送信され、ドロップされた残りのセグメントは通常RTOが期限切れになるまで待機する必要があるため、TCPはスロースタートに戻ります。
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の応答は、輻輳の検出方法によって異なります。再送信タイマーによりパケットが再送信される場合、TCPはssthreshを現在のcwndの半分にドロップし、cwndの値を1セグメントに減らします（これによりスロースタートがトリガーされます）。ただし、セグメントが高速再送信によって再送信される場合、ssthreshとcwndの両方が現在のcwndの値の半分に設定され、新しいデータを送信するために輻輳回避が使用されます。違いは、重複するACKが原因で再送信する場合、TCPはパケットがまだネットワークを流れていることを認識しているため、輻輳がそれほど悪くないと推測できることです。ただし、再送信タイマーの期限切れのためにパケットを再送信する場合、TCPはネットワークの状態について何も推測できないため、スロースタートアルゴリズムを使用して新しいデータを送信することにより、慎重に処理を進める必要があります。
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].
上記のように、高速再送信/高速リカバリアルゴリズムは、データウィンドウごとに複数の高速再送信を可能にする現象を引き起こす可能性があることに注意してください[Flo94]。これにより、単一の「損失イベント」に応答して、輻輳ウィンドウのサイズを複数回縮小できます。この問題は、大きな輻輳ウィンドウを利用する接続で特に顕著です。これらの接続は、回復中に十分な新しいセグメントをネットワークに挿入して、複数の高速再送信をトリガーできるためです。単一の損失イベントでcwndを複数回削減すると、パフォーマンスが低下する可能性があります[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.
高速再送信/高速回復アルゴリズムを改善する最良の方法は、損失回復に選択的確認応答（SACK）ベースのアルゴリズムを使用することです。以下で説明するように、これらのアルゴリズムは一般に、cwndの値を不必要に減らすことなく、複数の失われたセグメントから迅速に回復できます。 SACKがない場合は、高速再送信アルゴリズムと高速リカバリアルゴリズムを使用する必要があります。複数の高速再送信に直面してこれらのアルゴリズムを修正してパフォーマンスを向上させることは、このドキュメントの範囲外です。したがって、TCP実装者は、RFC 2001 [Ste97]で概説されている現在のバージョンの高速再送信/高速リカバリまたはRFC 2001の後続のバージョンを実装することをお勧めします。
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 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.
上記のアルゴリズムは、追加の容量についてネットワークをゆっくりとプローブするため、個々のTCP接続のパフォーマンスに悪影響を及ぼします。これにより、帯域幅が浪費されます。これは、送信者が受信者からフィードバックを取得するために必要な時間が長いため、特に遅延が長い衛星チャネルでは当てはまります[All97] [AHKO97]。ただし、このアルゴリズムは、共有ネットワークでの輻輳による崩壊を防ぐために必要です[Jac88]。したがって、特定の接続への悪影響は、ネットワーク全体へのメリットによって相殺されるだけではありません。
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]:
標準の最大TCPウィンドウサイズ（65,535バイト）では、単一のTCP接続で一部の衛星チャネルで利用可能な帯域幅全体を利用するには不十分です。 TCPスループットは、次の式[Pos81]によって制限されます。
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:
したがって、65,535バイトの最大ウィンドウサイズと560ミリ秒の静止衛星チャネルRTT [Kru95]を使用すると、最大スループットは次のように制限されます。
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).
したがって、単一の標準TCP接続では、たとえばT1レート（約192,000バイト/秒）のGSO衛星チャネルを完全には利用できません。ただし、TCPはより大きなウィンドウをサポートするように拡張されています[JBB92]。 [JBB92]で概説されているウィンドウスケーリングオプションは、衛星環境、およびコンパニオンアルゴリズムPAWS（ラップされたシーケンススペースに対する保護）およびRTTM（ラウンドトリップ時間測定）で使用する必要があります。
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.
多くのフロー間で共有される衛星リンクの場合、大きなウィンドウは必要ない場合があることに注意してください。たとえば、上記の例のように、それぞれが65,535バイトのウィンドウを使用する2つの長命のTCP接続は、T1 GSO衛星チャネルを完全に利用できます。
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.
多くの場合、大きなウィンドウを使用するには、クライアントとサーバーの両方のアプリケーション、またはTCPスタックを（通常は専門家が）手動で調整して、大きなウィンドウを利用する必要があります。現在のネットワークの状態に応じてバッファ容量を調整できるオペレーティングシステムメカニズムの研究が現在進行中です[SMM98]。これにより、標準のTCP実装とアプリケーションが、基盤となるネットワークによって提供される容量をより適切に利用できるようになります。
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 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].
TCP受信者が確認応答を生成するために使用できる2つの標準的な方法があります。 [Pos81]で概説されている方法は、着信セグメントごとにACKを生成します。 [Bra89]は、ホストは「遅延確認応答」を使用する必要があると述べています。このアルゴリズムを使用すると、2番目のフルサイズセグメントごとに、または2番目のフルサイズセグメントが所定のタイムアウト（500ミリ秒を超えてはならない）内に到着しない場合に、ACKが生成されます。輻輳ウィンドウは、着信ACKの数に基づいて増加し、遅延ACKは受信側から送信されるACKの数を減らします。したがって、受信者が各着信セグメントにACKを送信する場合[All98]に比べて、遅延ACKを使用すると、cwndの成長がはるかに遅くなります。
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].
遅延ACKによって引き起こされる問題の魅力的な「修正」は、単にメカニズムをオフにして、受信側に各着信セグメントをACKさせることです。ただし、これはお勧めできません。まず、[Bra89]は、TCPレシーバーが遅延ACKを生成する必要がある（SHOULD）と述べています。さらに、共有ネットワークでACKの数を2倍に増やすと、まだ理解されていない結果が生じる可能性があります。したがって、遅延ACKを無効にすることは依然として研究課題であり、したがって、現時点では[Bra89]に従って、TCP受信者は遅延ACKを生成し続ける必要があります。
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.
選択的確認応答（SACK）[MMFR96]により、TCP受信者はTCP送信者にどのパケットが到着したかを正確に通知できます。 SACKを使用すると、TCPは失われたセグメントからより迅速に回復し、不必要な再送信を回避できます。
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.
高速再送信アルゴリズムは通常、データのウィンドウごとに1つの損失のみを修復できます。複数の損失が発生した場合、送信者は通常、タイムアウトに依存して、次に再送信する必要があるセグメントを決定する必要があります。タイムアウトを待機している間、データセグメントとその確認応答はネットワークから排出されます。ネットワークに新しいセグメントをクロックする着信ACKがない場合、送信側はスロースタートアルゴリズムを使用して送信を再開する必要があります。上記のように、スロースタートアルゴリズムは、衛星チャネルでは時間がかかる場合があります。 SACKが使用される場合、送信者は通常、損失検出後の最初のRTTで再送信する必要のあるセグメントを決定できます。これにより、送信者は適切なレートでセグメント（適切な場合は再送信と新しいセグメント）を送信し続けることができるため、ACKクロックを維持できます。これにより、複数の失われたセグメントに続く、コストのかかる遅い開始期間が回避されます。一般に、SACKは、損失検出後の最初のRTT内でドロップされたすべてのセグメントを再送信できます。 [MM96]と[FF96]は、SACK情報に依存して再送信が必要なセグメントを判断する特定の輻輳制御アルゴリズムと、それらのセグメントを送信するのが適切な場合について説明しています。これらのアルゴリズムは両方とも、[Jac88]で概説されている輻輳制御の基本原理に従い、輻輳が検出されるとウィンドウを半分に縮小します。
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.
表1は、このドキュメントで説明されているメカニズムをまとめたものです。 「Recommended」と表示されているメカニズムは、衛星チャネルを含むネットワークで使用するために作成者が推奨するIETF標準追跡メカニズムです。 「必須」とマークされたメカニズムは、共有インターネット[Bra89]を使用するホストに必要なものとしてIETFによって定義されています。各メカニズムの説明を含むこのドキュメントのセクションとともに、メカニズムを実装する必要がある場所に注意します。コード最後の列にリストされているのは、次のように定義されています。データ送信側は「S」、データ受信側は「R」、衛星リンクは「L」。
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].
サテライトユーザーは、TCPベンダー（実装者）に問い合わせて、推奨されるメカニズムが現在および将来のバージョンのスタックでサポートされていることを確認する必要があります。または、ピッツバーグスーパーコンピューターセンターは、TCP実装とそれらがサポートする拡張機能を追跡し、さまざまなTCP実装のチューニングに関するガイダンスを提供します[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.
衛星チャネルを介したTCPの効率を改善するための研究が進行中であり、衛星ネットワークアーキテクチャなどの他の考慮事項とともに計画されたメモにまとめられます。
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.
著者は、このメモに含まれる推奨事項がTCPのセキュリティへの影響を変更しないと信じています。ただし、衛星リンクなどのブロードキャストメディアを使用してユーザーデータやネットワーク制御トラフィックを転送する場合は、そのようなテクノロジーに固有のセキュリティの影響を認識する必要があります。
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.
物理層またはリンク層、あるいはその両方でのデータ暗号化は、衛星チャネルを介した安全な通信を提供できます。ただし、この場合でも、トラフィックは衛星リンクを通過する前後にネットワーク上で盗聴されやすくなります。したがって、エンドツーエンドのセキュリティメカニズムを検討する必要があります。このドキュメントでは、どのセキュリティメカニズムを採用する必要があるかについては推奨していません。ただし、衛星ネットワークを運用および使用している人は、現在利用可能なネットワークセキュリティメカニズムを調査し、セキュリティ要件を満たすものを選択する必要があります。
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.
このドキュメントは、TCP over Satelliteワーキンググループのメンバーからのコメントを利用しています。特に、このドキュメントに関する有益なコメントを提供してくれたAaron Falk、Matthew Halsey、Hans Kruse、Matt Mathis、Greg Nakanishi、Vern Paxson、Jeff Semke、Bill Sepmeier、およびEric Travisに感謝します。
References
参考文献
[AFP98] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
[AFP98] Allman、M.、Floyd、S。およびC. Partridge、「Increeasing TCP's Initial Window」、RFC 2414、1998年9月。
[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]マークオールマン、クリスヘイズ、ハンスクルーゼ、ショーンオスターマン。衛星リンク上のTCPパフォーマンス。第5回電気通信システムに関する国際会議の議事録、1997年3月。
[All97] Mark Allman. Improving TCP Performance Over Satellite Channels. Master's thesis, Ohio University, June 1997.
[All97]マークオールマン。衛星チャネルでのTCPパフォーマンスの向上。修士論文、オハイオ大学、1997年6月。
[All98] Mark Allman. On the Generation and Use of TCP Acknowledgments. ACM Computer Communication Review, 28(5), October 1998.
[All98]マークオールマン。 TCP確認応答の生成と使用について。 ACM Computer Communication Review、28（5）、1998年10月。
[Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[Bra89] Braden、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[FF96] Kevin Fall and Sally Floyd. Simulation-based Comparisons of Tahoe, Reno and SACK TCP. Computer Communication Review, July 1996.
[FF96]ケビン・フォールとサリー・フロイド。 Tahoe、Reno、SACK TCPのシミュレーションベースの比較。コンピュータ通信レビュー、1996年7月。
[FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet. Submitted to IEEE Transactions on Networking.
[FF98]サリー・フロイド、ケビン・フォール。インターネットにおけるエンドツーエンドの輻輳制御の使用の促進。 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.フロイド、TCPおよび連続高速再送信。テクニカルレポート、1994年10月。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、Amproving TCP of the Performance over the ATM-UBR service、1998。
[Jac90] Van Jacobson. Modified TCP Congestion Avoidance Algorithm. Technical Report, LBL, April 1990.
[Jac90]ヴァンジェイコブソン。変更されたTCP輻輳回避アルゴリズム。テクニカルレポート、LBL、1990年4月。
[JBB92] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[JBB92] Jacobson、V.、Braden、R。およびD. Borman、「高性能のTCP拡張機能」、RFC 1323、1992年5月。
[Jac88] Van Jacobson. Congestion Avoidance and Control. In ACM SIGCOMM, 1988.
[Jac88]ヴァンジェイコブソン。輻輳回避と制御。 ACM SIGCOMM、1988年。
[Kno93] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[Kno93] Knowles、S。、「Path MTU Discoveryの経験からのIESGアドバイス」、RFC 1435、1993年3月。
[Mar78] James Martin. Communications Satellite Systems. Prentice Hall, 1978.
[Mar78] James James Martin。通信衛星システム。プレンティスホール、1978年。
[MD90] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[MD90] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[MM96] Matt Mathis and Jamshid Mahdavi. Forward Acknowledgment: Refining TCP Congestion Control. In ACM SIGCOMM, 1996.
[MM96] Matt MathisとJamshid Mahdavi。 Forward Acknowledgment：TCP輻輳制御の改善。 ACM SIGCOMM、1996年。
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[MMFR96] Mathis、M.、Madhavi、J.、Floyd、S。、およびA. Romanow、「TCP選択的確認応答オプション」、RFC 2018、1996年10月。
[Mon98] M. J. Montpetit. TELEDESIC: Enabling The Global Community Interaccess. In Proc. of the International Wireless Symposium, May 1998.
[Mon98] M. J. Montpetit。 TELEDESIC：グローバルコミュニティの相互アクセスを可能にします。手続き中国際ワイヤレスシンポジウム、1998年5月の。
[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、「TCP輻輳回避アルゴリズムの巨視的動作」、Computer Communication Review、ボリューム27、number3、1997年7月。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、1981年9月。
[PS97] Craig Partridge and Tim Shepard. TCP Performance Over Satellite Links. IEEE Network, 11(5), September/October 1997.
[PS97]クレイグ・パートリッジとティム・シェパード。衛星リンク上のTCPパフォーマンス。 IEEEネットワーク、11（5）、1997年9月/ 10月。
[PSC] Jamshid Mahdavi. Enabling High Performance Data Transfers on Hosts. http://www.psc.edu/networking/perf_tune.html.
[PSC] Jamshid Mahdavi。ホストでの高性能データ転送の有効化。 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、Matt Mathis。自動TCPバッファー調整。 ACM SIGCOMM、1998年8月。表示されます。
[Sta94] William Stallings. Data and Computer Communications. MacMillian, 4th edition, 1994.
[Sta94]ウィリアム・ストールズ。データおよびコンピュータ通信。マクミリアン、第4版、1994年。
[Ste97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001,January 1997.
[Ste97] Stevens、W。、「TCPスロースタート、輻輳回避、高速再送信、および高速回復アルゴリズム」、RFC 2001、1997年1月。
[Stu95] M. A. Sturza. Architecture of the TELEDESIC Satellite System. In Proceedings of the International Mobile Satellite Conference, 1995.
[Stu95] M. A. Sturza。 TELEDESIC衛星システムのアーキテクチャ。国際移動衛星会議の議事録、1995年。
Authors' Addresses
著者のアドレス
Mark Allman NASA Lewis Research Center/Sterling Software 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
マークオールマンNASAルイスリサーチセンター/スターリングソフトウェア21000 Brookpark Rd。 MS 54-2クリーブランド、オハイオ州44135
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
ダニエルR.グローバーNASAルイスリサーチセンター21000 Brookpark Rd。クリーブランド、オハイオ州44135
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
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。