4. PAWS -- Protect Against Wrapped Sequence Numbers (PAWS -- シーケンス番号の折り返しに対する保護)

4. PAWS: Protect Against Wrapped Sequence Numbers (PAWS: シーケンス番号の折り返しに対する保護)

4.1 Introduction (はじめに)

Section 4.2 describes a simple mechanism to reject old duplicate segments that might corrupt an open TCP connection; we call this mechanism PAWS (Protect Against Wrapped Sequence numbers). PAWS operates within a single TCP connection, using state that is saved in the connection control block. Section 4.3 and Appendix C discuss the implications of the PAWS mechanism for avoiding old duplicates from previous incarnations of the same connection.

セクション4.2では、オープンなTCP接続を破壊する可能性のある古い重複セグメントを拒否する簡単なメカニズムについて説明します。このメカニズムをPAWS (Protect Against Wrapped Sequence numbers、シーケンス番号の折り返しに対する保護) と呼びます。PAWSは、接続制御ブロックに保存された状態を使用して、単一のTCP接続内で動作します。セクション4.3および付録Cでは、同じ接続の以前のインカーネーションからの古い重複を回避するためのPAWSメカニズムの影響について説明します。

4.2 The PAWS Mechanism (PAWSメカニズム)

PAWS uses the same TCP Timestamps option as the RTTM mechanism described earlier, and assumes that every received TCP segment (including data and ACK segments) contains a timestamp SEG.TSval whose values are monotone non-decreasing in time. The basic idea is that a segment can be discarded as an old duplicate if it is received with a timestamp SEG.TSval less than some timestamp recently received on this connection.

PAWSは、前述のRTTMメカニズムと同じTCP Timestampsオプションを使用し、受信したすべてのTCPセグメント (データセグメントとACKセグメントを含む) には、時間的に単調非減少なタイムスタンプSEG.TSvalが含まれていると仮定します。基本的な考え方は、この接続で最近受信したタイムスタンプよりも小さいタイムスタンプSEG.TSvalで受信された場合、そのセグメントを古い重複として破棄できるということです。

In both the PAWS and the RTTM mechanism, the "timestamps" are 32-bit unsigned integers in a modular 32-bit space. Thus, "less than" is defined the same way it is for TCP sequence numbers, and the same implementation techniques apply. If s and t are timestamp values, s < t if 0 < (t - s) < 2**31, computed in unsigned 32-bit arithmetic.

PAWSとRTTMメカニズムの両方において、「タイムスタンプ (timestamps)」はモジュラー32ビット空間における32ビット符号なし整数です。したがって、「less than (未満)」はTCPシーケンス番号と同じ方法で定義され、同じ実装技術が適用されます。sとtがタイムスタンプ値である場合、0 < (t - s) < 2**31のときs < tであり、符号なし32ビット算術で計算されます。

The choice of incoming timestamps to be saved for this comparison must guarantee a value that is monotone increasing. For example, we might save the timestamp from the segment that last advanced the left edge of the receive window, i.e., the most recent in-sequence segment. Instead, we choose the value TS.Recent introduced in Section 3.4 for the RTTM mechanism, since using a common value for both PAWS and RTTM simplifies the implementation of both. As Section 3.4 explained, TS.Recent differs from the timestamp from the last in-sequence segment only in the case of delayed ACKs, and therefore by less than one window. Either choice will therefore protect against sequence number wrap-around.

この比較のために保存される着信タイムスタンプの選択は、単調増加する値を保証する必要があります。たとえば、受信ウィンドウの左端を最後に進めたセグメント、つまり最新のシーケンス内セグメントからタイムスタンプを保存する場合があります。代わりに、PAWSとRTTMの両方に共通の値を使用すると両方の実装が簡素化されるため、セクション3.4でRTTMメカニズムのために導入された値TS.Recentを選択します。セクション3.4で説明したように、TS.Recentは遅延ACKの場合にのみ最後のシーケンス内セグメントのタイムスタンプと異なり、したがって1ウィンドウ未満の差です。したがって、どちらの選択もシーケンス番号の折り返しに対して保護します。

RTTM was specified in a symmetrical manner, so that TSval timestamps are carried in both data and ACK segments and are echoed in TSecr fields carried in returning ACK or data segments. PAWS submits all incoming segments to the same test, and therefore protects against duplicate ACK segments as well as data segments. (An alternative un-symmetric algorithm would protect against old duplicate ACKs: the sender of data would reject incoming ACK segments whose TSecr values were less than the TSecr saved from the last segment whose ACK field advanced the left edge of the send window. This algorithm was deemed to lack economy of mechanism and symmetry.)

RTTMは対称的に指定されているため、TSvalタイムスタンプはデータセグメントとACKセグメントの両方で運ばれ、返されるACKまたはデータセグメントで運ばれるTSecrフィールドでエコーされます。PAWSはすべての着信セグメントを同じテストに提出するため、データセグメントだけでなく重複ACKセグメントに対しても保護します。(代替の非対称アルゴリズムは、古い重複ACKに対して保護します。データの送信者は、ACKフィールドが送信ウィンドウの左端を進めた最後のセグメントから保存されたTSecrよりも小さいTSecr値を持つ着信ACKセグメントを拒否します。このアルゴリズムはメカニズムの経済性と対称性に欠けると見なされました。)

TSval timestamps sent on {SYN} and {SYN,ACK} segments are used to initialize PAWS. PAWS protects against old duplicate non-SYN segments, and duplicate SYN segments received while there is a synchronized connection. Duplicate {SYN} and {SYN,ACK} segments received when there is no connection will be discarded by the normal 3-way handshake and sequence number checks of TCP.

{SYN}および{SYN,ACK}セグメントで送信されるTSvalタイムスタンプは、PAWSを初期化するために使用されます。PAWSは、古い重複非SYNセグメント、および同期接続が存在する間に受信された重複SYNセグメントに対して保護します。接続が存在しないときに受信された重複{SYN}および{SYN,ACK}セグメントは、TCPの通常の3ウェイハンドシェイクとシーケンス番号チェックによって破棄されます。

It is recommended that RST segments NOT carry timestamps, and that RST segments be acceptable regardless of their timestamp. Old duplicate RST segments should be exceedingly unlikely, and their cleanup function should take precedence over timestamps.

RSTセグメントはタイムスタンプを運ばないこと、およびタイムスタンプに関係なくRSTセグメントが受け入れられることが推奨されます。古い重複RSTセグメントは極めて可能性が低く、そのクリーンアップ機能はタイムスタンプよりも優先されるべきです。

4.2.1 Basic PAWS Algorithm (基本PAWSアルゴリズム)

The PAWS algorithm requires the following processing to be performed on all incoming segments for a synchronized connection:

PAWSアルゴリズムは、同期接続のすべての着信セグメントに対して次の処理を実行することを要求します。

R1) If there is a Timestamps option in the arriving segment and SEG.TSval < TS.Recent and if TS.Recent is valid (see later discussion), then treat the arriving segment as not acceptable:

到着したセグメントにTimestampsオプションがあり、SEG.TSval < TS.Recentであり、TS.Recentが有効である場合 (後述の議論を参照)、到着したセグメントを受け入れ不可として扱います。

Send an acknowledgement in reply as specified in RFC-793 page 69 and drop the segment.

RFC-793の69ページで指定されているように応答として確認応答を送信し、セグメントを破棄します。

Note: it is necessary to send an ACK segment in order to retain TCP's mechanisms for detecting and recovering from half-open connections. For example, see Figure 10 of RFC-793.

注: ハーフオープン接続の検出と回復のためのTCPのメカニズムを保持するために、ACKセグメントを送信する必要があります。たとえば、RFC-793の図10を参照してください。

R2) If the segment is outside the window, reject it (normal TCP processing)

セグメントがウィンドウの外側にある場合は、それを拒否します (通常のTCP処理)

R3) If an arriving segment satisfies: SEG.SEQ <= Last.ACK.sent (see Section 3.4), then record its timestamp in TS.Recent.

到着したセグメントがSEG.SEQ <= Last.ACK.sent (セクション3.4を参照) を満たす場合、そのタイムスタンプをTS.Recentに記録します。

R4) If an arriving segment is in-sequence (i.e., at the left window edge), then accept it normally.

到着したセグメントがシーケンス内 (つまり、左ウィンドウエッジにある) である場合、それを通常どおり受け入れます。

R5) Otherwise, treat the segment as a normal in-window, out-of-sequence TCP segment (e.g., queue it for later delivery to the user).

それ以外の場合は、セグメントを通常のウィンドウ内、シーケンス外TCPセグメントとして扱います (たとえば、後でユーザーに配信するためにキューに入れます)。

Steps R2, R4, and R5 are the normal TCP processing steps specified by RFC-793.

ステップR2、R4、およびR5は、RFC-793で指定されている通常のTCP処理ステップです。

It is important to note that the timestamp is checked only when a segment first arrives at the receiver, regardless of whether it is in-sequence or it must be queued for later delivery. Consider the following example.

タイムスタンプは、セグメントが受信者に最初に到着したときにのみチェックされることに注意することが重要です。これは、それがシーケンス内であるか、後で配信するためにキューに入れる必要があるかに関係ありません。次の例を考えてみましょう。

Suppose the segment sequence: A.1, B.1, C.1, ..., Z.1 has been sent, where the letter indicates the sequence number and the digit represents the timestamp. Suppose also that segment B.1 has been lost. The timestamp in TS.TStamp is 1 (from A.1), so C.1, ..., Z.1 are considered acceptable and are queued. When B is retransmitted as segment B.2 (using the latest timestamp), it fills the hole and causes all the segments through Z to be acknowledged and passed to the user. The timestamps of the queued segments are not inspected again at this time, since they have already been accepted. When B.2 is accepted, TS.Stamp is set to 2.

セグメントシーケンスA.1、B.1、C.1、...、Z.1が送信されたとします。ここで、文字はシーケンス番号を示し、数字はタイムスタンプを表します。また、セグメントB.1が失われたとします。TS.TStampのタイムスタンプは1 (A.1から) であるため、C.1、...、Z.1は受け入れ可能と見なされ、キューに入れられます。Bが最新のタイムスタンプを使用してセグメントB.2として再送信されると、それは穴を埋め、Zまでのすべてのセグメントが確認されユーザーに渡されます。キューに入れられたセグメントのタイムスタンプは、すでに受け入れられているため、この時点では再度検査されません。B.2が受け入れられると、TS.Stampは2に設定されます。

This rule allows reasonable performance under loss. A full window of data is in transit at all times, and after a loss a full window less one packet will show up out-of-sequence to be queued at the receiver (e.g., up to ~2**30 bytes of data); the timestamp option must not result in discarding this data.

このルールは、損失下での合理的なパフォーマンスを可能にします。完全なデータウィンドウが常に転送中であり、損失後、1パケット少ない完全なウィンドウがシーケンス外として現れ、受信者でキューに入れられます (たとえば、最大〜2**30バイトのデータ)。タイムスタンプオプションは、このデータを破棄する結果になってはなりません。

In certain unlikely circumstances, the algorithm of rules R1-R4 could lead to discarding some segments unnecessarily, as shown in the following example:

特定のありそうもない状況では、ルールR1-R4のアルゴリズムが、次の例に示すように、いくつかのセグメントを不必要に破棄する可能性があります。

Suppose again that segments: A.1, B.1, C.1, ..., Z.1 have been sent in sequence and that segment B.1 has been lost. Furthermore, suppose delivery of some of C.1, ... Z.1 is delayed until AFTER the retransmission B.2 arrives at the receiver. These delayed segments will be discarded unnecessarily when they do arrive, since their timestamps are now out of date.

再び、セグメントA.1、B.1、C.1、...、Z.1が順番に送信され、セグメントB.1が失われたとします。さらに、C.1、...、Z.1の一部の配信が再送信B.2が受信者に到着した後まで遅延されたとします。これらの遅延されたセグメントは、到着したときに不必要に破棄されます。これは、そのタイムスタンプが現在古くなっているためです。

This case is very unlikely to occur. If the retransmission was triggered by a timeout, some of the segments C.1, ... Z.1 must have been delayed longer than the RTO time. This is presumably an unlikely event, or there would be many spurious timeouts and retransmissions. If B's retransmission was triggered by the "fast retransmit" algorithm, i.e., by duplicate ACKs, then the queued segments that caused these ACKs must have been received already.

このケースは発生する可能性が非常に低いです。再送信がタイムアウトによってトリガーされた場合、セグメントC.1、...、Z.1の一部はRTO時間よりも長く遅延されている必要があります。これはおそらくありそうもないイベントであり、そうでなければ多くの偽のタイムアウトと再送信があるでしょう。Bの再送信が「高速再送信 (fast retransmit)」アルゴリズム、つまり重複ACKによってトリガーされた場合、これらのACKを引き起こしたキューに入れられたセグメントはすでに受信されている必要があります。

Even if a segment were delayed past the RTO, the Fast Retransmit mechanism [Jacobson90c] will cause the delayed packets to be retransmitted at the same time as B.2, avoiding an extra RTT and therefore causing a very small performance penalty.

セグメントがRTOを過ぎて遅延された場合でも、高速再送信メカニズム [Jacobson90c] により、遅延されたパケットはB.2と同時に再送信され、余分なRTTを回避するため、非常に小さなパフォーマンスペナルティが発生します。

We know of no case with a significant probability of occurrence in which timestamps will cause performance degradation by unnecessarily discarding segments.

タイムスタンプがセグメントを不必要に破棄することによってパフォーマンス低下を引き起こす、発生確率が高いケースは知られていません。

4.2.2 Timestamp Clock (タイムスタンプクロック)

It is important to understand that the PAWS algorithm does not require clock synchronization between sender and receiver. The sender's timestamp clock is used to stamp the segments, and the sender uses the echoed timestamp to measure RTT's. However, the receiver treats the timestamp as simply a monotone-increasing serial number, without any necessary connection to its clock. From the receiver's viewpoint, the timestamp is acting as a logical extension of the high-order bits of the sequence number.

PAWSアルゴリズムが送信者と受信者の間のクロック同期を必要としないことを理解することが重要です。送信者のタイムスタンプクロックはセグメントにスタンプを押すために使用され、送信者はエコーされたタイムスタンプを使用してRTTを測定します。ただし、受信者はタイムスタンプを単に単調増加するシリアル番号として扱い、そのクロックとの必要な接続はありません。受信者の観点からは、タイムスタンプはシーケンス番号の上位ビットの論理的拡張として機能しています。

The receiver algorithm does place some requirements on the frequency of the timestamp clock.

受信者アルゴリズムは、タイムスタンプクロックの周波数にいくつかの要件を課します。

(a) The timestamp clock must not be "too slow".

タイムスタンプクロックは「遅すぎて」はいけません。

It must tick at least once for each 231 bytes sent. In fact, in order to be useful to the sender for round trip timing, the clock should tick at least once per window's worth of data, and even with the RFC-1072 window extension, 231 bytes must be at least two windows.

送信される231バイトごとに少なくとも1回ティックする必要があります。実際、送信者にとってラウンドトリップタイミングに役立つためには、クロックはウィンドウ分のデータごとに少なくとも1回ティックする必要があり、RFC-1072ウィンドウ拡張を使用しても、231バイトは少なくとも2つのウィンドウである必要があります。

To make this more quantitative, any clock faster than 1 tick/sec will reject old duplicate segments for link speeds of ~8 Gbps. A 1ms timestamp clock will work at link speeds up to 8 Tbps (8*10**12) bps!

これをより定量的にするために、1 tick/secより速いクロックは、約8 Gbpsのリンク速度で古い重複セグメントを拒否します。1msタイムスタンプクロックは、最大8 Tbps (8*10**12) bpsのリンク速度で機能します。

(b) The timestamp clock must not be "too fast".

タイムスタンプクロックは「速すぎて」はいけません。

Its recycling time must be greater than MSL seconds. Since the clock (timestamp) is 32 bits and the worst-case MSL is 255 seconds, the maximum acceptable clock frequency is one tick every 59 ns.

そのリサイクル時間はMSL秒より大きくなければなりません。クロック (タイムスタンプ) は32ビットであり、最悪の場合のMSLは255秒であるため、最大許容クロック周波数は59 nsごとに1ティックです。

However, it is desirable to establish a much longer recycle period, in order to handle outdated timestamps on idle connections (see Section 4.2.3), and to relax the MSL requirement for preventing sequence number wrap-around. With a 1 ms timestamp clock, the 32-bit timestamp will wrap its sign bit in 24.8 days. Thus, it will reject old duplicates on the same connection if MSL is 24.8 days or less. This appears to be a very safe figure; an MSL of 24.8 days or longer can probably be assumed by the gateway system without requiring precise MSL enforcement by the TTL value in the IP layer.

ただし、アイドル接続での古いタイムスタンプを処理するため (セクション4.2.3を参照)、およびシーケンス番号の折り返しを防ぐためのMSL要件を緩和するために、はるかに長いリサイクル期間を確立することが望ましいです。1 msタイムスタンプクロックを使用すると、32ビットタイムスタンプは24.8日で符号ビットを折り返します。したがって、MSLが24.8日以下の場合、同じ接続上の古い重複を拒否します。これは非常に安全な数値であると思われます。ゲートウェイシステムは、IP層のTTL値による正確なMSL実施を必要とせずに、24.8日以上のMSLをおそらく想定できます。

Based upon these considerations, we choose a timestamp clock frequency in the range 1 ms to 1 sec per tick. This range also matches the requirements of the RTTM mechanism, which does not need much more resolution than the granularity of the retransmit timer, e.g., tens or hundreds of milliseconds.

これらの考慮事項に基づいて、1ティックあたり1 msから1秒の範囲のタイムスタンプクロック周波数を選択します。この範囲は、再送信タイマーの粒度、たとえば数十または数百ミリ秒よりもはるかに高い解像度を必要としないRTTMメカニズムの要件にも一致します。

The PAWS mechanism also puts a strong monotonicity requirement on the sender's timestamp clock. The method of implementation of the timestamp clock to meet this requirement depends upon the system hardware and software.

PAWSメカニズムは、送信者のタイムスタンプクロックに強い単調性要件も課します。この要件を満たすためのタイムスタンプクロックの実装方法は、システムのハードウェアとソフトウェアに依存します。

• Some hosts have a hardware clock that is guaranteed to be monotonic between hardware resets.

  一部のホストには、ハードウェアリセット間で単調であることが保証されているハードウェアクロックがあります。

• A clock interrupt may be used to simply increment a binary integer by 1 periodically.

  クロック割り込みを使用して、バイナリ整数を定期的に1ずつインクリメントすることができます。

• The timestamp clock may be derived from a system clock that is subject to being abruptly changed, by adding a variable offset value. This offset is initialized to zero. When a new timestamp clock value is needed, the offset can be adjusted as necessary to make the new value equal to or larger than the previous value (which was saved for this purpose).

  タイムスタンプクロックは、可変オフセット値を追加することによって、突然変更される可能性のあるシステムクロックから派生させることができます。このオフセットはゼロに初期化されます。新しいタイムスタンプクロック値が必要な場合、オフセットは必要に応じて調整され、新しい値が前の値 (この目的のために保存された) 以上になるようにします。

4.2.3 Outdated Timestamps (古いタイムスタンプ)

If a connection remains idle long enough for the timestamp clock of the other TCP to wrap its sign bit, then the value saved in TS.Recent will become too old; as a result, the PAWS mechanism will cause all subsequent segments to be rejected, freezing the connection (until the timestamp clock wraps its sign bit again).

接続が十分に長くアイドル状態のままで、他のTCPのタイムスタンプクロックが符号ビットを折り返す場合、TS.Recentに保存された値は古くなりすぎます。その結果、PAWSメカニズムはすべての後続セグメントを拒否し、接続を凍結します (タイムスタンプクロックが再び符号ビットを折り返すまで)。

With the chosen range of timestamp clock frequencies (1 sec to 1 ms), the time to wrap the sign bit will be between 24.8 days and 24800 days. A TCP connection that is idle for more than 24 days and then comes to life is exceedingly unusual. However, it is undesirable in principle to place any limitation on TCP connection lifetimes.

選択されたタイムスタンプクロック周波数の範囲 (1秒から1 ms) で、符号ビットを折り返す時間は24.8日から24800日の間になります。24日以上アイドル状態であった後に活動するTCP接続は非常に異常です。ただし、原則として、TCP接続のライフタイムに制限を設けることは望ましくありません。

We therefore require that an implementation of PAWS include a mechanism to "invalidate" the TS.Recent value when a connection is idle for more than 24 days. (An alternative solution to the problem of outdated timestamps would be to send keepalive segments at a very low rate, but still more often than the wrap-around time for timestamps, e.g., once a day. This would impose negligible overhead. However, the TCP specification has never included keepalives, so the solution based upon invalidation was chosen.)

したがって、PAWSの実装には、接続が24日以上アイドル状態のときにTS.Recent値を「無効化 (invalidate)」するメカニズムを含める必要があります。(古いタイムスタンプの問題の代替解決策は、非常に低いレートでキープアライブセグメントを送信することですが、それでもタイムスタンプの折り返し時間よりも頻繁に、たとえば1日に1回です。これはごくわずかなオーバーヘッドしか課しません。ただし、TCP仕様にはキープアライブが含まれたことがないため、無効化に基づく解決策が選択されました。)

Note that a TCP does not know the frequency, and therefore, the wraparound time, of the other TCP, so it must assume the worst. The validity of TS.Recent needs to be checked only if the basic PAWS timestamp check fails, i.e., only if SEG.TSval < TS.Recent. If TS.Recent is found to be invalid, then the segment is accepted, regardless of the failure of the timestamp check, and rule R3 updates TS.Recent with the TSval from the new segment.

TCPは他のTCPの周波数、したがって折り返し時間を知らないため、最悪の場合を想定する必要があることに注意してください。TS.Recentの有効性は、基本的なPAWSタイムスタンプチェックが失敗した場合、つまりSEG.TSval < TS.Recentの場合にのみチェックする必要があります。TS.Recentが無効であることがわかった場合、タイムスタンプチェックの失敗に関係なくセグメントが受け入れられ、ルールR3は新しいセグメントのTSvalでTS.Recentを更新します。

To detect how long the connection has been idle, the TCP may update a clock or timestamp value associated with the connection whenever TS.Recent is updated, for example. The details will be implementation-dependent.

接続がアイドル状態であった期間を検出するために、TCPはTS.Recentが更新されるたびに、たとえば接続に関連付けられたクロックまたはタイムスタンプ値を更新できます。詳細は実装に依存します。

4.2.4 Header Prediction (ヘッダー予測)

"Header prediction" [Jacobson90a] is a high-performance transport protocol implementation technique that is most important for high-speed links. This technique optimizes the code for the most common case, receiving a segment correctly and in order. Using header prediction, the receiver asks the question, "Is this segment the next in sequence?" This question can be answered in fewer machine instructions than the question, "Is this segment within the window?"

「ヘッダー予測 (Header prediction)」 [Jacobson90a] は、高速リンクに最も重要な高性能トランスポートプロトコル実装技術です。この技術は、最も一般的なケース、つまりセグメントを正しく順番に受信する場合のコードを最適化します。ヘッダー予測を使用すると、受信者は「このセグメントは次のシーケンスですか?」という質問をします。この質問は、「このセグメントはウィンドウ内にありますか?」という質問よりも少ない機械命令で答えることができます。

Adding header prediction to our timestamp procedure leads to the following recommended sequence for processing an arriving TCP segment:

タイムスタンプ手順にヘッダー予測を追加すると、到着するTCPセグメントを処理するための次の推奨シーケンスになります。

H1) Check timestamp (same as step R1 above)

タイムスタンプをチェックする (上記のステップR1と同じ)

H2) Do header prediction: if segment is next in sequence and if there are no special conditions requiring additional processing, accept the segment, record its timestamp, and skip H3.

ヘッダー予測を実行する。セグメントが次のシーケンスであり、追加の処理を必要とする特別な条件がない場合は、セグメントを受け入れ、そのタイムスタンプを記録し、H3をスキップします。

H3) Process the segment normally, as specified in RFC-793. This includes dropping segments that are outside the window and possibly sending acknowledgments, and queueing in-window, out-of-sequence segments.

RFC-793で指定されているように、セグメントを通常どおり処理します。これには、ウィンドウの外側にあるセグメントを破棄し、おそらく確認応答を送信すること、およびウィンドウ内のシーケンス外セグメントをキューに入れることが含まれます。

Another possibility would be to interchange steps H1 and H2, i.e., to perform the header prediction step H2 FIRST, and perform H1 and H3 only when header prediction fails. This could be a performance improvement, since the timestamp check in step H1 is very unlikely to fail, and it requires interval arithmetic on a finite field, a relatively expensive operation. To perform this check on every single segment is contrary to the philosophy of header prediction. We believe that this change might reduce CPU time for TCP protocol processing by up to 5-10% on high-speed networks.

別の可能性は、ステップH1とH2を入れ替えることです。つまり、ヘッダー予測ステップH2を最初に実行し、ヘッダー予測が失敗した場合にのみH1とH3を実行します。これは、ステップH1のタイムスタンプチェックが失敗する可能性が非常に低く、有限フィールドでの区間演算を必要とする比較的高価な操作であるため、パフォーマンスの向上になる可能性があります。すべてのセグメントに対してこのチェックを実行することは、ヘッダー予測の哲学に反しています。この変更により、高速ネットワークでのTCPプロトコル処理のCPU時間が最大5〜10%削減される可能性があると考えています。

However, putting H2 first would create a hazard: a segment from 2**32 bytes in the past might arrive at exactly the wrong time and be accepted mistakenly by the header-prediction step. The following reasoning has been introduced [Jacobson90b] to show that the probability of this failure is negligible.

ただし、H2を最初に置くと危険が生じます。過去2**32バイトのセグメントが正確に間違った時間に到着し、ヘッダー予測ステップによって誤って受け入れられる可能性があります。次の推論 [Jacobson90b] が導入され、この失敗の確率が無視できることを示しています。

If all segments are equally likely to show up as old duplicates, then the probability of an old duplicate exactly matching the left window edge is the maximum segment size (MSS) divided by the size of the sequence space. This ratio must be less than 2**-16, since MSS must be < 216; for example, it will be (212)/(232) = 2-20 for an FDDI link. However, the older a segment is, the less likely it is to be retained in the Internet, and under any reasonable model of segment lifetime the probability of an old duplicate exactly at the left window edge must be much smaller than 2**-16.

すべてのセグメントが古い重複として現れる可能性が等しい場合、古い重複が左ウィンドウエッジと正確に一致する確率は、最大セグメントサイズ (MSS) をシーケンス空間のサイズで割ったものです。この比率は2**-16未満である必要があります。MSSは216未満である必要があるためです。たとえば、FDDIリンクの場合は (212)/(232) = 2-20になります。ただし、セグメントが古いほど、インターネットに保持される可能性は低くなり、セグメントのライフタイムの合理的なモデルでは、左ウィンドウエッジで正確に古い重複の確率は2**-16よりもはるかに小さくなければなりません。

The 16 bit TCP checksum also allows a basic unreliability of one part in 2**16. A protocol mechanism whose reliability exceeds the reliability of the TCP checksum should be considered "good enough", i.e., it won't contribute significantly to the overall error rate. We therefore believe we can ignore the problem of an old duplicate being accepted by doing header prediction before checking the timestamp.

16ビットTCPチェックサムは、2**16分の1の基本的な信頼性の低さも許容します。信頼性がTCPチェックサムの信頼性を超えるプロトコルメカニズムは、「十分に良い (good enough)」と見なされるべきです。つまり、全体的なエラー率に大きく寄与しません。したがって、タイムスタンプをチェックする前にヘッダー予測を実行することによって古い重複が受け入れられる問題を無視できると考えています。

However, this probabilistic argument is not universally accepted, and the consensus at present is that the performance gain does not justify the hazard in the general case. It is therefore recommended that H2 follow H1.

ただし、この確率的議論は普遍的に受け入れられておらず、現在のコンセンサスは、一般的なケースではパフォーマンスの向上が危険を正当化しないというものです。したがって、H2はH1に従うことが推奨されます。

4.3 Duplicates from Earlier Incarnations of Connection (接続の以前のインカーネーションからの重複)

The PAWS mechanism protects against errors due to sequence number wrap-around on high-speed connection. Segments from an earlier incarnation of the same connection are also a potential cause of old duplicate errors. In both cases, the TCP mechanisms to prevent such errors depend upon the enforcement of a maximum segment lifetime (MSL) by the Internet (IP) layer (see Appendix of RFC-1185 for a detailed discussion). Unlike the case of sequence space wrap-around, the MSL required to prevent old duplicate errors from earlier incarnations does not depend upon the transfer rate. If the IP layer enforces the recommended 2 minute MSL of TCP, and if the TCP rules are followed, TCP connections will be safe from earlier incarnations, no matter how high the network speed. Thus, the PAWS mechanism is not required for this case.

PAWSメカニズムは、高速接続でのシーケンス番号の折り返しによるエラーに対して保護します。同じ接続の以前のインカーネーションからのセグメントも、古い重複エラーの潜在的な原因です。どちらの場合も、このようなエラーを防ぐTCPメカニズムは、インターネット (IP) 層による最大セグメントライフタイム (MSL) の実施に依存します (詳細な議論についてはRFC-1185の付録を参照してください)。シーケンス空間の折り返しの場合とは異なり、以前のインカーネーションからの古い重複エラーを防ぐために必要なMSLは、転送速度に依存しません。IP層がTCPの推奨2分MSLを実施し、TCPルールが守られている場合、ネットワーク速度がどれほど高くても、TCP接続は以前のインカーネーションから安全です。したがって、このケースではPAWSメカニズムは必要ありません。

We may still ask whether the PAWS mechanism can provide additional security against old duplicates from earlier connections, allowing us to relax the enforcement of MSL by the IP layer. Appendix B explores this question, showing that further assumptions and/or mechanisms are required, beyond those of PAWS. This is not part of the current extension.

それでも、PAWSメカニズムが以前の接続からの古い重複に対して追加のセキュリティを提供できるかどうか、つまりIP層によるMSLの実施を緩和できるかどうかを尋ねることができます。付録Bはこの質問を探求し、PAWSを超えたさらなる仮定および/またはメカニズムが必要であることを示しています。これは現在の拡張の一部ではありません。