1. Introduction (はじめに)

The TCP protocol [Postel81] was designed to operate reliably over almost any transmission medium regardless of transmission rate, delay, corruption, duplication, or reordering of segments. Production TCP implementations currently adapt to transfer rates in the range of 100 bps to 10**7 bps and round-trip delays in the range 1 ms to 100 seconds. Recent work on TCP performance has shown that TCP can work well over a variety of Internet paths, ranging from 800 Mbit/sec I/O channels to 300 bit/sec dial-up modems [Jacobson88a].

TCPプロトコル [Postel81] は, 伝送速度, 遅延, 破損, 重複, またはセグメントの順序変更に関係なく, ほぼすべての伝送媒体上で確実に動作するように設計されました。現在の本番環境のTCP実装は, 100 bpsから10**7 bpsの範囲の転送速度と, 1 msから100秒の範囲のラウンドトリップ遅延に適応します。TCPのパフォーマンスに関する最近の研究により, TCPは800 Mbit/secのI/Oチャネルから300 bit/secのダイヤルアップモデムまで, さまざまなインターネットパス上で良好に動作できることが示されています [Jacobson88a]。

The introduction of fiber optics is resulting in ever-higher transmission speeds, and the fastest paths are moving out of the domain for which TCP was originally engineered. This memo defines a set of modest extensions to TCP to extend the domain of its application to match this increasing network capability. It is based upon and obsoletes RFC-1072 [Jacobson88b] and RFC-1185 [Jacobson90b].

光ファイバーの導入により, 伝送速度はますます高速化しており, 最速のパスはTCPが元々設計されていた領域を超えて移動しています。このメモは, この増加するネットワーク機能に合わせてそのアプリケーションの領域を拡張するために, TCPに対する一連の控えめな拡張を定義します。これはRFC-1072 [Jacobson88b] とRFC-1185 [Jacobson90b] に基づいており, それらを廃止します。

There is no one-line answer to the question: "How fast can TCP go?". There are two separate kinds of issues, performance and reliability, and each depends upon different parameters. We discuss each in turn.

"TCPはどのくらい速くなれますか?" という質問に対する一行の答えはありません。パフォーマンスと信頼性という2つの異なる種類の問題があり, それぞれが異なるパラメータに依存します。それぞれを順番に説明します。

1.1 TCP Performance (TCPパフォーマンス)

TCP performance depends not upon the transfer rate itself, but rather upon the product of the transfer rate and the round-trip delay. This "bandwidthdelay product" measures the amount of data that would "fill the pipe"; it is the buffer space required at sender and receiver to obtain maximum throughput on the TCP connection over the path, i.e., the amount of unacknowledged data that TCP must handle in order to keep the pipeline full. TCP performance problems arise when the bandwidthdelay product is large. We refer to an Internet path operating in this region as a "long, fat pipe", and a network containing this path as an "LFN" (pronounced "elephan(t)").

TCPのパフォーマンスは, 転送速度自体ではなく, 転送速度とラウンドトリップ遅延の積に依存します。この "bandwidthdelay product (帯域幅遅延積)" は, "パイプを満たす" データ量を測定します; これは, パス上のTCP接続で最大スループットを得るために送信側と受信側で必要なバッファスペース, つまり, パイプラインを満たし続けるためにTCPが処理しなければならない未確認データの量です。bandwidth*delay productが大きい場合, TCPのパフォーマンスの問題が発生します。この領域で動作するインターネットパスを "long, fat pipe (長くて太いパイプ)" と呼び, このパスを含むネットワークを "LFN" (elephan(t) と発音) と呼びます。

High-capacity packet satellite channels (e.g., DARPA's Wideband Net) are LFN's. For example, a DS1-speed satellite channel has a bandwidth*delay product of 106 bits or more; this corresponds to 100 outstanding TCP segments of 1200 bytes each. Terrestrial fiber-optical paths will also fall into the LFN class; for example, a cross-country delay of 30 ms at a DS3 bandwidth (45Mbps) also exceeds 106 bits.

高容量パケット衛星チャネル (例えば, DARPAのワイドバンドネット) はLFNです。たとえば, DS1速度の衛星チャネルは106ビット以上のbandwidth*delay productを持ちます; これは, それぞれ1200バイトの100個の未処理TCPセグメントに相当します。地上の光ファイバーパスもLFNクラスに分類されます; たとえば, DS3帯域幅 (45Mbps) での30 msの大陸横断遅延も106ビットを超えます。

There are three fundamental performance problems with the current TCP over LFN paths:

現在のTCPがLFNパス上で抱える3つの基本的なパフォーマンスの問題があります:

(1) Window Size Limit (ウィンドウサイズの制限)

The TCP header uses a 16 bit field to report the receive window size to the sender. Therefore, the largest window that can be used is 2**16 = 65K bytes.

TCPヘッダーは16ビットフィールドを使用して, 受信ウィンドウサイズを送信側に報告します。したがって, 使用できる最大のウィンドウは2**16 = 65Kバイトです。

To circumvent this problem, Section 2 of this memo defines a new TCP option, "Window Scale", to allow windows larger than 2**16. This option defines an implicit scale factor, which is used to multiply the window size value found in a TCP header to obtain the true window size.

この問題を回避するために, このメモの第2節では, 2**16より大きいウィンドウを許可する新しいTCPオプション "Window Scale (ウィンドウスケール)" を定義します。このオプションは暗黙のスケールファクターを定義し, TCPヘッダーにあるウィンドウサイズ値を乗算して真のウィンドウサイズを取得するために使用されます。

(2) Recovery from Losses (損失からの回復)

Packet losses in an LFN can have a catastrophic effect on throughput. Until recently, properly-operating TCP implementations would cause the data pipeline to drain with every packet loss, and require a slow-start action to recover. Recently, the Fast Retransmit and Fast Recovery algorithms [Jacobson90c] have been introduced. Their combined effect is to recover from one packet loss per window, without draining the pipeline. However, more than one packet loss per window typically results in a retransmission timeout and the resulting pipeline drain and slow start.

LFNでのパケット損失は, スループットに壊滅的な影響を与える可能性があります。最近まで, 正しく動作するTCP実装は, すべてのパケット損失でデータパイプラインを排出させ, 回復するためにスロースタートアクションを必要としていました。最近, 高速再送信 (Fast Retransmit) と高速回復 (Fast Recovery) アルゴリズム [Jacobson90c] が導入されました。それらの組み合わせ効果は, パイプラインを排出することなく, ウィンドウごとに1つのパケット損失から回復することです。ただし, ウィンドウごとに複数のパケット損失が発生すると, 通常は再送信タイムアウトが発生し, その結果としてパイプラインの排出とスロースタートが発生します。

This memo introduces RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences) mechanisms that address these problems through the use of TCP Timestamps option.

このメモは, TCPタイムスタンプオプションの使用を通じてこれらの問題に対処するRTTM (Round Trip Time Measurement, ラウンドトリップ時間測定) とPAWS (Protect Against Wrapped Sequences, シーケンス番号ラップアラウンド防止) メカニズムを導入します。