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つのパケット損失から回復することです。ただし, ウィンドウごとに複数のパケット損失が発生すると, 通常は再送信タイムアウトが発生し, その結果としてパイプラインの排出とスロースタートが発生します。

Expanding the window size to match the capacity of an LFN results in a corresponding increase of the probability of more than one packet per window being dropped. This could have a devastating effect upon the throughput of TCP over an LFN. In addition, if a congestion control mechanism based upon some form of random dropping were introduced into gateways, randomly spaced packet drops would become common, possible increasing the probability of dropping more than one packet per window.

LFNの容量に合わせてウィンドウサイズを拡大すると, ウィンドウごとに複数のパケットがドロップされる確率が相応に増加します。これは, LFN上のTCPのスループットに壊滅的な影響を与える可能性があります。さらに, 何らかの形式のランダムドロップに基づく輻輳制御メカニズムがゲートウェイに導入された場合, ランダムな間隔でのパケットドロップが一般的になり, ウィンドウごとに複数のパケットをドロップする確率が増加する可能性があります。

To generalize the Fast Retransmit/Fast Recovery mechanism to handle multiple packets dropped per window, selective acknowledgments are required. Unlike the normal cumulative acknowledgments of TCP, selective acknowledgments give the sender a complete picture of which segments are queued at the receiver and which have not yet arrived. Some evidence in favor of selective acknowledgments has been published [NBS85], and selective acknowledgments have been included in a number of experimental Internet protocols -- VMTP [Cheriton88], NETBLT [Clark87], and RDP [Velten84], and proposed for OSI TP4 [NBS85]. However, in the non-LFN regime, selective acknowledgments reduce the number of packets retransmitted but do not otherwise improve performance, making their complexity of questionable value. However, selective acknowledgments are expected to become much more important in the LFN regime.

ウィンドウごとに複数のパケットがドロップされる状況を扱えるようにFast Retransmit/Fast Recoveryメカニズムを一般化するには, 選択的確認応答 (selective acknowledgments) が必要です。TCPの通常の累積確認応答とは異なり, 選択的確認応答は, どのセグメントが受信側でキューに入れられ, どのセグメントがまだ到着していないかについての完全な状況を送信側に与えます。選択的確認応答を支持するいくつかの証拠が公表されており [NBS85], 選択的確認応答は多数の実験的インターネットプロトコル -- VMTP [Cheriton88], NETBLT [Clark87], RDP [Velten84] -- に含まれ, OSI TP4に対して提案されています [NBS85]。ただし, 非LFN領域では, 選択的確認応答は再送されるパケット数を削減しますが, それ以外にパフォーマンスを改善するわけではないため, その複雑さの価値には疑問が残ります。しかし, LFN領域では選択的確認応答がはるかに重要になると予想されます。

RFC-1072 defined a new TCP "SACK" option to send a selective acknowledgment. However, there are important technical issues to be worked out concerning both the format and semantics of the SACK option. Therefore, SACK has been omitted from this package of extensions. It is hoped that SACK can "catch up" during the standardization process.

RFC-1072は, 選択的確認応答を送信するための新しいTCP "SACK" オプションを定義しました。しかし, SACKオプションのフォーマットとセマンティクスの両方に関して, 解決すべき重要な技術的課題があります。したがって, SACKはこの拡張パッケージから除外されました。SACKが標準化プロセスの中で "追いつく" ことができると期待されています。

(3) Round-Trip Measurement (ラウンドトリップ測定)

TCP implements reliable data delivery by retransmitting segments that are not acknowledged within some retransmission timeout (RTO) interval. Accurate dynamic determination of an appropriate RTO is essential to TCP performance. RTO is determined by estimating the mean and variance of the measured round-trip time (RTT), i.e., the time interval between sending a segment and receiving an acknowledgment for it [Jacobson88a].

TCPは, ある再送タイムアウト (RTO) 間隔内に確認応答されなかったセグメントを再送することによって, 信頼性のあるデータ配信を実装します。適切なRTOを正確に動的に決定することは, TCPのパフォーマンスにとって不可欠です。RTOは, 測定されたラウンドトリップ時間 (RTT), つまりセグメントを送信してからその確認応答を受信するまでの時間間隔の平均と分散を推定することによって決定されます [Jacobson88a]。

Section 4 introduces a new TCP option, "Timestamps", and then defines a mechanism using this option that allows nearly every segment, including retransmissions, to be timed at negligible computational cost. We use the mnemonic RTTM (Round Trip Time Measurement) for this mechanism, to distinguish it from other uses of the Timestamps option.

第4節では, 新しいTCPオプション "Timestamps (タイムスタンプ)" を導入し, このオプションを使用して, 再送を含むほぼすべてのセグメントを無視できる計算コストで計時できるメカニズムを定義します。このメカニズムには, Timestampsオプションの他の用途と区別するために, RTTM (Round Trip Time Measurement, ラウンドトリップ時間測定) というニーモニックを使用します。

1.2 TCP Reliability (TCPの信頼性)

Now we turn from performance to reliability. High transfer rate enters TCP performance through the bandwidth*delay product. However, high transfer rate alone can threaten TCP reliability by violating the assumptions behind the TCP mechanism for duplicate detection and sequencing.

ここでパフォーマンスから信頼性に話を移します。高い転送速度は, bandwidth*delay productを通じてTCPのパフォーマンスに影響します。しかし, 高い転送速度は, それ単独でも重複検出とシーケンス処理に関するTCPメカニズムの前提を破ることによって, TCPの信頼性を脅かす可能性があります。

An especially serious kind of error may result from an accidental reuse of TCP sequence numbers in data segments. Suppose that an "old duplicate segment", e.g., a duplicate data segment that was delayed in Internet queues, is delivered to the receiver at the wrong moment, so that its sequence numbers falls somewhere within the current window. There would be no checksum failure to warn of the error, and the result could be an undetected corruption of the data. Reception of an old duplicate ACK segment at the transmitter could be only slightly less serious: it is likely to lock up the connection so that no further progress can be made, forcing an RST on the connection.

特に深刻な種類のエラーは, データセグメント内のTCPシーケンス番号が偶発的に再利用されることから生じる可能性があります。"古い重複セグメント", 例えばインターネットのキュー内で遅延した重複データセグメントが, 誤ったタイミングで受信側に配信され, そのシーケンス番号が現在のウィンドウ内のどこかに収まるとします。エラーを警告するチェックサム失敗は発生せず, その結果, 検出されないデータの破損が生じる可能性があります。送信側での古い重複ACKセグメントの受信は, わずかに深刻さが低い程度です: それは接続をロックアップさせ, それ以上の進行ができなくなり, 接続に対してRSTを強制する可能性があります。

TCP reliability depends upon the existence of a bound on the lifetime of a segment: the "Maximum Segment Lifetime" or MSL. An MSL is generally required by any reliable transport protocol, since every sequence number field must be finite, and therefore any sequence number may eventually be reused. In the Internet protocol suite, the MSL bound is enforced by an IP-layer mechanism, the "Time-to-Live" or TTL field.

TCPの信頼性は, セグメントの生存期間に上限が存在すること, すなわち "Maximum Segment Lifetime (最大セグメント生存時間)" またはMSLに依存します。すべてのシーケンス番号フィールドは有限でなければならず, したがっていかなるシーケンス番号も最終的には再利用される可能性があるため, MSLは一般にあらゆる信頼性のあるトランスポートプロトコルで必要とされます。インターネットプロトコルスイートでは, MSLの上限はIP層のメカニズムである "Time-to-Live" またはTTLフィールドによって強制されます。

Duplication of sequence numbers might happen in either of two ways:

シーケンス番号の重複は, 次の2つのいずれかの方法で発生する可能性があります:

(1) Sequence number wrap-around on the current connection (現在の接続でのシーケンス番号のラップアラウンド)

A TCP sequence number contains 32 bits. At a high enough transfer rate, the 32-bit sequence space may be "wrapped" (cycled) within the time that a segment is delayed in queues.

TCPシーケンス番号は32ビットを含みます。十分に高い転送速度では, 32ビットのシーケンス空間が, セグメントがキュー内で遅延する時間の間に "ラップ" (一巡) する可能性があります。

(2) Earlier incarnation of the connection (接続の以前のインカネーション)

Suppose that a connection terminates, either by a proper close sequence or due to a host crash, and the same connection (i.e., using the same pair of sockets) is immediately reopened. A delayed segment from the terminated connection could fall within the current window for the new incarnation and be accepted as valid.

適切なクローズシーケンスによって, またはホストのクラッシュによって接続が終了し, 同じ接続 (つまり, 同じソケットのペアを使用する接続) がただちに再オープンされるとします。終了した接続からの遅延セグメントが, 新しいインカネーションの現在のウィンドウ内に収まり, 有効なものとして受け入れられる可能性があります。

Duplicates from earlier incarnations, Case (2), are avoided by enforcing the current fixed MSL of the TCP spec, as explained in Section 5.3 and Appendix B. However, case (1), avoiding the reuse of sequence numbers within the same connection, requires an MSL bound that depends upon the transfer rate, and at high enough rates, a new mechanism is required.

以前のインカネーションからの重複, つまりケース (2) は, 第5.3節と付録Bで説明するように, TCP仕様の現在の固定MSLを強制することによって回避されます。しかし, ケース (1), すなわち同一接続内でのシーケンス番号の再利用を回避することには, 転送速度に依存するMSLの上限が必要であり, 十分に高い速度では新しいメカニズムが必要になります。

More specifically, if the maximum effective bandwidth at which TCP is able to transmit over a particular path is B bytes per second, then the following constraint must be satisfied for error-free operation:

より具体的には, TCPが特定のパス上で送信できる最大実効帯域幅が毎秒Bバイトである場合, エラーのない動作のために次の制約が満たされなければなりません:

2**31 / B  > MSL (secs)                     [1]

The following table shows the value for Twrap = 2**31/B in seconds, for some important values of the bandwidth B:

次の表は, 帯域幅Bのいくつかの重要な値について, Twrap = 2**31/Bの値を秒単位で示しています:

Network	B*8 bits/sec	B bytes/sec	Twrap secs
ARPANET	56kbps	7KBps	310*5 (~3.6 days)
DS1	1.5Mbps	190KBps	10**4 (~3 hours)
Ethernet	10Mbps	1.25MBps	1700 (~30 mins)
DS3	45Mbps	5.6MBps	380
FDDI	100Mbps	12.5MBps	170
Gigabit	1Gbps	125MBps	17

It is clear that wrap-around of the sequence space is not a problem for 56kbps packet switching or even 10Mbps Ethernets. On the other hand, at DS3 and FDDI speeds, Twrap is comparable to the 2 minute MSL assumed by the TCP specification [Postel81]. Moving towards gigabit speeds, Twrap becomes too small for reliable enforcement by the Internet TTL mechanism.

56kbpsのパケット交換や, さらには10Mbpsのイーサネットにとっても, シーケンス空間のラップアラウンドが問題にならないことは明らかです。一方, DS3およびFDDIの速度では, TwrapはTCP仕様 [Postel81] が想定する2分のMSLに匹敵します。ギガビット速度に向かうと, TwrapはインターネットのTTLメカニズムによる確実な強制には小さすぎるものになります。

The 16-bit window field of TCP limits the effective bandwidth B to 2**16/RTT, where RTT is the round-trip time in seconds [McKenzie89]. If the RTT is large enough, this limits B to a value that meets the constraint [1] for a large MSL value. For example, consider a transcontinental backbone with an RTT of 60ms (set by the laws of physics). With the bandwidth*delay product limited to 64KB by the TCP window size, B is then limited to 1.1MBps, no matter how high the theoretical transfer rate of the path. This corresponds to cycling the sequence number space in Twrap= 2000 secs, which is safe in today's Internet.

TCPの16ビットウィンドウフィールドは, 実効帯域幅Bを2**16/RTTに制限します。ここでRTTは秒単位のラウンドトリップ時間です [McKenzie89]。RTTが十分に大きい場合, これはBを, 大きなMSL値に対して制約 [1] を満たす値に制限します。例えば, (物理法則によって定まる) 60msのRTTを持つ大陸横断バックボーンを考えます。bandwidth*delay productがTCPウィンドウサイズによって64KBに制限されると, パスの理論上の転送速度がどれほど高くても, Bは1.1MBpsに制限されます。これは, Twrap = 2000秒でシーケンス番号空間が一巡することに相当し, 今日のインターネットでは安全です。

It is important to understand that the culprit is not the larger window but rather the high bandwidth. For example, consider a (very large) FDDI LAN with a diameter of 10km. Using the speed of light, we can compute the RTT across the ring as (210**4)/(310**8) = 67 microseconds, and the delay*bandwidth product is then 833 bytes. A TCP connection across this LAN using a window of only 833 bytes will run at the full 100mbps and can wrap the sequence space in about 3 minutes, very close to the MSL of TCP. Thus, high speed alone can cause a reliability problem with sequence number wrap-around, even without extended windows.

問題の原因は大きなウィンドウではなく, むしろ高い帯域幅であることを理解することが重要です。例えば, 直径10kmの (非常に大きな) FDDI LANを考えます。光速を用いると, リング上のRTTは (210**4)/(310**8) = 67マイクロ秒と計算でき, delay*bandwidth productは833バイトとなります。わずか833バイトのウィンドウを使用するこのLAN上のTCP接続は, 100mbpsをフルに使って動作し, 約3分でシーケンス空間をラップする可能性があり, これはTCPのMSLに非常に近い値です。したがって, 拡張ウィンドウがなくても, 高速性だけでシーケンス番号のラップアラウンドによる信頼性の問題が発生し得ます。

Watson's Delta-T protocol [Watson81] includes network-layer mechanisms for precise enforcement of an MSL. In contrast, the IP mechanism for MSL enforcement is loosely defined and even more loosely implemented in the Internet. Therefore, it is unwise to depend upon active enforcement of MSL for TCP connections, and it is unrealistic to imagine setting MSL's smaller than the current values (e.g., 120 seconds specified for TCP).

WatsonのDelta-Tプロトコル [Watson81] は, MSLを正確に強制するためのネットワーク層メカニズムを含んでいます。対照的に, MSL強制のためのIPメカニズムは緩やかに定義されており, インターネットにおける実装はさらに緩やかです。したがって, TCP接続に対してMSLの能動的な強制に依存するのは賢明ではなく, 現在の値 (例えばTCPに対して規定されている120秒) より小さいMSLを設定することを想定するのは非現実的です。

A possible fix for the problem of cycling the sequence space would be to increase the size of the TCP sequence number field. For example, the sequence number field (and also the acknowledgment field) could be expanded to 64 bits. This could be done either by changing the TCP header or by means of an additional option.

シーケンス空間が一巡する問題に対する考えられる修正は, TCPシーケンス番号フィールドのサイズを大きくすることです。例えば, シーケンス番号フィールド (および確認応答フィールド) を64ビットに拡張することができます。これは, TCPヘッダーを変更するか, または追加のオプションによって実現できます。

Section 5 presents a different mechanism, which we call PAWS (Protect Against Wrapped Sequence numbers), to extend TCP reliability to transfer rates well beyond the foreseeable upper limit of network bandwidths. PAWS uses the TCP Timestamps option defined in Section 4 to protect against old duplicates from the same connection.

第5節では, ネットワーク帯域幅の予見可能な上限をはるかに超える転送速度までTCPの信頼性を拡張するための, PAWS (Protect Against Wrapped Sequence numbers, シーケンス番号ラップアラウンド防止) と呼ぶ別のメカニズムを提示します。PAWSは, 同一接続からの古い重複を防ぐために, 第4節で定義されるTCP Timestampsオプションを使用します。

1.3 Using TCP options (TCPオプションの使用)

The extensions defined in this memo all use new TCP options. We must address two possible issues concerning the use of TCP options: (1) compatibility and (2) overhead.

このメモで定義される拡張は, すべて新しいTCPオプションを使用します。TCPオプションの使用に関して考えられる2つの問題, すなわち (1) 互換性と (2) オーバーヘッドに対処しなければなりません。

We must pay careful attention to compatibility, i.e., to interoperation with existing implementations. The only TCP option defined previously, MSS, may appear only on a SYN segment. Every implementation should (and we expect that most will) ignore unknown options on SYN segments. However, some buggy TCP implementation might be crashed by the first appearance of an option on a non-SYN segment. Therefore, for each of the extensions defined below, TCP options will be sent on non-SYN segments only when an exchange of options on the SYN segments has indicated that both sides understand the extension. Furthermore, an extension option will be sent in a <SYN,ACK> segment only if the corresponding option was received in the initial <SYN> segment.

互換性, すなわち既存の実装との相互運用には細心の注意を払わなければなりません。以前に定義された唯一のTCPオプションであるMSSは, SYNセグメント上にのみ出現し得ます。すべての実装はSYNセグメント上の未知のオプションを無視すべきです (そして大半がそうすると予想されます)。しかし, 一部のバグのあるTCP実装は, 非SYNセグメント上にオプションが初めて出現したことでクラッシュする可能性があります。したがって, 以下で定義される各拡張については, SYNセグメント上でのオプション交換によって双方がその拡張を理解していることが示された場合にのみ, 非SYNセグメント上でTCPオプションが送信されます。さらに, 拡張オプションが <SYN,ACK> セグメントで送信されるのは, 対応するオプションが初期の <SYN> セグメントで受信された場合に限られます。

A question may be raised about the bandwidth and processing overhead for TCP options. Those options that occur on SYN segments are not likely to cause a performance concern. Opening a TCP connection requires execution of significant special-case code, and the processing of options is unlikely to increase that cost significantly.

TCPオプションの帯域幅と処理オーバーヘッドについて疑問が生じるかもしれません。SYNセグメント上に出現するオプションは, パフォーマンス上の懸念を引き起こす可能性は低いです。TCP接続のオープンには相当量の特殊ケースコードの実行が必要であり, オプションの処理がそのコストを大幅に増加させることはまずありません。

On the other hand, a Timestamps option may appear in any data or ACK segment, adding 12 bytes to the 20-byte TCP header. We believe that the bandwidth saved by reducing unnecessary retransmissions will more than pay for the extra header bandwidth.

一方, Timestampsオプションは任意のデータセグメントまたはACKセグメントに出現する可能性があり, 20バイトのTCPヘッダーに12バイトを追加します。不要な再送を削減することによって節約される帯域幅は, 追加のヘッダー帯域幅を十分に補って余りあると考えます。

There is also an issue about the processing overhead for parsing the variable byte-aligned format of options, particularly with a RISC-architecture CPU. To meet this concern, Appendix A contains a recommended layout of the options in TCP headers to achieve reasonable data field alignment. In the spirit of Header Prediction, a TCP can quickly test for this layout and if it is verified then use a fast path. Hosts that use this canonical layout will effectively use the options as a set of fixed-format fields appended to the TCP header. However, to retain the philosophical and protocol framework of TCP options, a TCP must be prepared to parse an arbitrary options field, albeit with less efficiency.

特にRISCアーキテクチャのCPUにおいて, 可変のバイト整列フォーマットのオプションを解析する処理オーバーヘッドについての問題もあります。この懸念に対応するため, 付録Aには, 妥当なデータフィールド整列を実現するためのTCPヘッダー内のオプションの推奨レイアウトが含まれています。Header Predictionの精神に則り, TCPはこのレイアウトを迅速にテストし, 検証できた場合には高速パスを使用できます。この正準レイアウトを使用するホストは, 事実上, オプションをTCPヘッダーに追加された固定フォーマットフィールドの集合として使用することになります。ただし, TCPオプションの思想的およびプロトコル的枠組みを維持するため, TCPは効率は落ちるとしても任意のオプションフィールドを解析できるよう備えていなければなりません。

Finally, we observe that most of the mechanisms defined in this memo are important for LFN's and/or very high-speed networks. For low-speed networks, it might be a performance optimization to NOT use these mechanisms. A TCP vendor concerned about optimal performance over low-speed paths might consider turning these extensions off for low-speed paths, or allow a user or installation manager to disable them.

最後に, このメモで定義されるメカニズムの大半は, LFNおよび/または非常に高速なネットワークにとって重要であることを指摘しておきます。低速なネットワークでは, これらのメカニズムを使用しないことがパフォーマンス上の最適化になる可能性があります。低速パス上での最適なパフォーマンスを懸念するTCPベンダーは, 低速パスに対してこれらの拡張をオフにすること, またはユーザーやインストール管理者がそれらを無効化できるようにすることを検討してもよいでしょう。