3. RTTM -- Round-Trip Time Measurement (RTTM -- ラウンドトリップ時間測定)

3. RTTM: Round-Trip Time Measurement (RTTM: ラウンドトリップ時間測定)

3.1 Introduction (はじめに)

Accurate and current RTT estimates are necessary to adapt to changing traffic conditions and to avoid an instability known as "congestion collapse" [Nagle84] in a busy network. However, accurate measurement of RTT may be difficult both in theory and in implementation.

正確かつ現在のRTT推定値は、変化するトラフィック条件に適応し、ビジーなネットワークで「輻輳崩壊 (congestion collapse)」[Nagle84]として知られる不安定性を回避するために必要です。しかし、RTTの正確な測定は、理論的にも実装的にも困難な場合があります。

Many TCP implementations base their RTT measurements upon a sample of only one packet per window. While this yields an adequate approximation to the RTT for small windows, it results in an unacceptably poor RTT estimate for an LFN. If we look at RTT estimation as a signal processing problem (which it is), a data signal at some frequency, the packet rate, is being sampled at a lower frequency, the window rate. This lower sampling frequency violates Nyquist's criteria and may therefore introduce "aliasing" artifacts into the estimated RTT [Hamming77].

多くのTCP実装は、ウィンドウあたり1つのパケットのみのサンプルに基づいてRTT測定を行います。これは小さなウィンドウに対してはRTTの十分な近似を生成しますが、LFNに対しては許容できないほど不十分なRTT推定をもたらします。RTT推定を信号処理問題として見る場合（実際そうです）、ある周波数のデータ信号（パケットレート）が、より低い周波数（ウィンドウレート）でサンプリングされています。この低いサンプリング周波数はナイキストの基準に違反し、したがって推定RTTに「エイリアシング (aliasing)」アーチファクトを導入する可能性があります[Hamming77]。

A good RTT estimator with a conservative retransmission timeout calculation can tolerate aliasing when the sampling frequency is "close" to the data frequency. For example, with a window of 8 packets, the sample rate is 1/8 the data frequency -- less than an order of magnitude different. However, when the window is tens or hundreds of packets, the RTT estimator may be seriously in error, resulting in spurious retransmissions.

保守的な再送タイムアウト計算を持つ優れたRTT推定器は、サンプリング周波数がデータ周波数に「近い」場合、エイリアシングを許容できます。たとえば、8パケットのウィンドウの場合、サンプルレートはデータ周波数の1/8であり、桁違いの差未満です。しかし、ウィンドウが数十または数百のパケットである場合、RTT推定器は深刻なエラーを起こし、スプリアス再送を引き起こす可能性があります。

If there are dropped packets, the problem becomes worse. Zhang [Zhang86], Jain [Jain86] and Karn [Karn87] have shown that it is not possible to accumulate reliable RTT estimates if retransmitted segments are included in the estimate. Since a full window of data will have been transmitted prior to a retransmission, all of the segments in that window will have to be ACKed before the next RTT sample can be taken. This means at least an additional window's worth of time between RTT measurements and, as the error rate approaches one per window of data (e.g., 10**-6 errors per bit for the Wideband satellite network), it becomes effectively impossible to obtain a valid RTT measurement.

パケットがドロップされると、問題はさらに悪化します。Zhang [Zhang86]、Jain [Jain86]、およびKarn [Karn87]は、再送セグメントが推定に含まれている場合、信頼性の高いRTT推定値を蓄積することは不可能であることを示しました。再送の前にデータの完全なウィンドウが送信されているため、次のRTTサンプルを取得する前に、そのウィンドウ内のすべてのセグメントをACKする必要があります。これは、RTT測定間に少なくとも追加のウィンドウ分の時間を意味し、エラー率がデータのウィンドウあたり1つに近づくと（たとえば、広帯域衛星ネットワークのビットあたり10**-6エラー）、有効なRTT測定を取得することが事実上不可能になります。

A solution to these problems, which actually simplifies the sender substantially, is as follows: using TCP options, the sender places a timestamp in each data segment, and the receiver reflects these timestamps back in ACK segments. Then a single subtract gives the sender an accurate RTT measurement for every ACK segment (which will correspond to every other data segment, with a sensible receiver). We call this the RTTM (Round-Trip Time Measurement, ラウンドトリップ時間測定) mechanism.

これらの問題の解決策（実際には送信者を大幅に簡素化します）は次のとおりです。TCPオプションを使用して、送信者は各データセグメントにタイムスタンプを配置し、受信者はこれらのタイムスタンプをACKセグメントで反射します。その後、単一の減算により、送信者はすべてのACKセグメントの正確なRTT測定値を取得します（これは、賢明な受信者を使用すると、他のすべてのデータセグメントに対応します）。これをRTTM (Round-Trip Time Measurement) メカニズムと呼びます。

It is vitally important to use the RTTM mechanism with big windows; otherwise, the door is opened to some dangerous instabilities due to aliasing. Furthermore, the option is probably useful for all TCP's, since it simplifies the sender.

大きなウィンドウでRTTMメカニズムを使用することは非常に重要です。そうしないと、エイリアシングによる危険な不安定性への扉が開かれます。さらに、このオプションは送信者を簡素化するため、すべてのTCPに役立つ可能性があります。

3.2 TCP Timestamps Option (TCP タイムスタンプオプション)

TCP is a symmetric protocol, allowing data to be sent at any time in either direction, and therefore timestamp echoing may occur in either direction. For simplicity and symmetry, we specify that timestamps always be sent and echoed in both directions. For efficiency, we combine the timestamp and timestamp reply fields into a single TCP Timestamps Option.

TCPは対称プロトコルであり、どちらの方向でもいつでもデータを送信でき、したがってタイムスタンプエコーはどちらの方向でも発生する可能性があります。簡単性と対称性のために、タイムスタンプは常に両方向で送信およびエコーされることを指定します。効率のために、タイムスタンプとタイムスタンプ応答フィールドを単一のTCP Timestampsオプションに結合します。

TCP Timestamps Option (TSopt):

Kind: 8

Length: 10 bytes

 +-------+-------+---------------------+---------------------+
 |Kind=8 |  10   |   TS Value (TSval)  |TS Echo Reply (TSecr)|
 +-------+-------+---------------------+---------------------+
     1       1              4                     4

The Timestamps option carries two four-byte timestamp fields. The Timestamp Value field (TSval) contains the current value of the timestamp clock of the TCP sending the option.

Timestampsオプションは、2つの4バイトのタイムスタンプフィールドを運びます。Timestamp Valueフィールド (TSval) には、オプションを送信するTCPのタイムスタンプクロックの現在の値が含まれています。

The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is set in the TCP header; if it is valid, it echos a timestamp value that was sent by the remote TCP in the TSval field of a Timestamps option. When TSecr is not valid, its value must be zero. The TSecr value will generally be from the most recent Timestamp option that was received; however, there are exceptions that are explained below.

Timestamp Echo Replyフィールド (TSecr) は、TCPヘッダーでACKビットが設定されている場合にのみ有効です。有効な場合、TimestampsオプションのTSvalフィールドでリモートTCPによって送信されたタイムスタンプ値をエコーします。TSecrが無効な場合、その値はゼロでなければなりません。TSecr値は通常、受信した最新のTimestampオプションからのものです。ただし、以下で説明する例外があります。

A TCP may send the Timestamps option (TSopt) in an initial `<SYN>` segment (i.e., segment containing a SYN bit and no ACK bit), and may send a TSopt in other segments only if it received a TSopt in the initial `<SYN>` segment for the connection.

TCPは、初期`<SYN>`セグメント（つまり、SYNビットを含み、ACKビットを含まないセグメント）でTimestampsオプション (TSopt) を送信でき、接続の初期`<SYN>`セグメントでTSoptを受信した場合にのみ、他のセグメントでTSoptを送信できます。

3.3 The RTTM Mechanism (RTTM メカニズム)

The timestamp value to be sent in TSval is to be obtained from a (virtual) clock that we call the "timestamp clock". Its values must be at least approximately proportional to real time, in order to measure actual RTT.

TSvalで送信されるタイムスタンプ値は、「タイムスタンプクロック (timestamp clock)」と呼ばれる（仮想）クロックから取得されます。実際のRTTを測定するために、その値は少なくともおおよそ実時間に比例している必要があります。

The following example illustrates a one-way data flow with segments arriving in sequence without loss. Here A, B, C... represent data blocks occupying successive blocks of sequence numbers, and ACK(A),... represent the corresponding cumulative acknowledgments. The two timestamp fields of the Timestamps option are shown symbolically as `<TSval= x,TSecr=y>`. Each TSecr field contains the value most recently received in a TSval field.

次の例は、セグメントが損失なく順番に到着する一方向のデータフローを示しています。ここで、A、B、C...は連続するシーケンス番号のブロックを占めるデータブロックを表し、ACK(A)、...は対応する累積確認応答を表します。Timestampsオプションの2つのタイムスタンプフィールドは、`<TSval= x,TSecr=y>`として象徴的に示されています。各TSecrフィールドには、TSvalフィールドで最近受信した値が含まれています。

    TCP  A                                          TCP B

               <A,TSval=1,TSecr=120> ------>

    <---- <ACK(A),TSval=127,TSecr=1>

               <B,TSval=5,TSecr=127> ------>

    <---- <ACK(B),TSval=131,TSecr=5>

    . . . . . . . . . . . . . . . . . . . . . .

               <C,TSval=65,TSecr=131> ------>

    <---- <ACK(C),TSval=191,TSecr=65>

               (etc)

The dotted line marks a pause (60 time units long) in which A had nothing to send. Note that this pause inflates the RTT which B could infer from receiving TSecr=131 in data segment C. Thus, in one-way data flows, RTTM in the reverse direction measures a value that is inflated by gaps in sending data. However, the following rule prevents a resulting inflation of the measured RTT:

点線は、Aが送信するものがなかった一時停止（60時間単位の長さ）を示しています。この一時停止は、データセグメントCでTSecr=131を受信することからBが推測できるRTTを膨張させることに注意してください。したがって、一方向のデータフローでは、逆方向のRTTMは、送信データのギャップによって膨張した値を測定します。ただし、次のルールは、測定されたRTTの結果としての膨張を防ぎます。

A TSecr value received in a segment is used to update the averaged RTT measurement only if the segment acknowledges some new data, i.e., only if it advances the left edge of the send window.

セグメントで受信したTSecr値は、セグメントが何らかの新しいデータを確認応答する場合、つまり送信ウィンドウの左端を進める場合にのみ、平均RTT測定の更新に使用されます。

Since TCP B is not sending data, the data segment C does not acknowledge any new data when it arrives at B. Thus, the inflated RTTM measurement is not used to update B's RTTM measurement.

TCP Bはデータを送信していないため、データセグメントCがBに到着したときに新しいデータを確認応答しません。したがって、膨張したRTTM測定は、BのRTTM測定の更新には使用されません。

3.4 Which Timestamp to Echo (エコーするタイムスタンプの選択)

If more than one Timestamps option is received before a reply segment is sent, the TCP must choose only one of the TSvals to echo, ignoring the others. To minimize the state kept in the receiver (i.e., the number of unprocessed TSvals), the receiver should be required to retain at most one timestamp in the connection control block.

応答セグメントが送信される前に複数のTimestampsオプションが受信された場合、TCPは他のものを無視して、エコーするTSvalを1つだけ選択する必要があります。受信者に保持される状態（つまり、未処理のTSvalの数）を最小化するために、受信者は接続制御ブロックに最大1つのタイムスタンプを保持する必要があります。

There are three situations to consider:

考慮すべき3つの状況があります。

(A) Delayed ACKs. (遅延ACK)

Many TCP's acknowledge only every Kth segment out of a group of segments arriving within a short time interval; this policy is known generally as "delayed ACKs". The data-sender TCP must measure the effective RTT, including the additional time due to delayed ACKs, or else it will retransmit unnecessarily. Thus, when delayed ACKs are in use, the receiver should reply with the TSval field from the earliest unacknowledged segment.

多くのTCPは、短い時間間隔内に到着するセグメントのグループの中からK番目のセグメントのみを確認応答します。このポリシーは一般に「遅延ACK (delayed ACKs)」として知られています。データ送信者TCPは、遅延ACKによる追加時間を含む有効なRTTを測定する必要があります。そうしないと、不必要に再送信します。したがって、遅延ACKが使用されている場合、受信者は最も古い未確認セグメントからのTSvalフィールドで応答する必要があります。

(B) A hole in the sequence space (segment(s) have been lost). (シーケンス空間の穴（セグメントが失われた）)

The sender will continue sending until the window is filled, and the receiver may be generating ACKs as these out-of-order segments arrive (e.g., to aid "fast retransmit").

送信者はウィンドウが埋まるまで送信を続け、受信者はこれらの順序外セグメントが到着するとACKを生成する場合があります（たとえば、「高速再送 (fast retransmit)」を支援するため）。

The lost segment is probably a sign of congestion, and in that situation the sender should be conservative about retransmission. Furthermore, it is better to overestimate than underestimate the RTT. An ACK for an out-of-order segment should therefore contain the timestamp from the most recent segment that advanced the window.

失われたセグメントはおそらく輻輳の兆候であり、その状況では送信者は再送信について保守的であるべきです。さらに、RTTを過小評価するよりも過大評価する方が良いです。したがって、順序外セグメントのACKには、ウィンドウを進めた最新のセグメントからのタイムスタンプが含まれている必要があります。

The same situation occurs if segments are re-ordered by the network.

セグメントがネットワークによって再配置された場合、同じ状況が発生します。

(C) A filled hole in the sequence space. (シーケンス空間の埋められた穴)

The segment that fills the hole represents the most recent measurement of the network characteristics. On the other hand, an RTT computed from an earlier segment would probably include the sender's retransmit time-out, badly biasing the sender's average RTT estimate. Thus, the timestamp from the latest segment (which filled the hole) must be echoed.

穴を埋めるセグメントは、ネットワーク特性の最新の測定を表します。一方、以前のセグメントから計算されたRTTには、送信者の再送タイムアウトが含まれる可能性があり、送信者の平均RTT推定に大きく偏っています。したがって、最新のセグメント（穴を埋めたもの）からのタイムスタンプをエコーする必要があります。

An algorithm that covers all three cases is described in the following rules for Timestamps option processing on a synchronized connection:

これら3つのケースすべてをカバーするアルゴリズムは、同期接続でのTimestampsオプション処理の次のルールで説明されています。

(1) The connection state is augmented with two 32-bit slots: TS.Recent holds a timestamp to be echoed in TSecr whenever a segment is sent, and Last.ACK.sent holds the ACK field from the last segment sent. Last.ACK.sent will equal RCV.NXT except when ACKs have been delayed.

接続状態は、2つの32ビットスロットで拡張されます。TS.Recentは、セグメントが送信されるたびにTSecrでエコーされるタイムスタンプを保持し、Last.ACK.sentは最後に送信されたセグメントからのACKフィールドを保持します。Last.ACK.sentは、ACKが遅延している場合を除き、RCV.NXTと等しくなります。

(2) If Last.ACK.sent falls within the range of sequence numbers of an incoming segment:

Last.ACK.sentが着信セグメントのシーケンス番号の範囲内にある場合:

SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN

then the TSval from the segment is copied to TS.Recent; otherwise, the TSval is ignored.

その場合、セグメントからのTSvalがTS.Recentにコピーされます。それ以外の場合、TSvalは無視されます。

(3) When a TSopt is sent, its TSecr field is set to the current TS.Recent value.

TSoptが送信される場合、そのTSecrフィールドは現在のTS.Recent値に設定されます。

The following examples illustrate these rules. Here A, B, C... represent data segments occupying successive blocks of sequence numbers, and ACK(A),... represent the corresponding acknowledgment segments. Note that ACK(A) has the same sequence number as B. We show only one direction of timestamp echoing, for clarity.

次の例は、これらのルールを示しています。ここで、A、B、C...は連続するシーケンス番号のブロックを占めるデータセグメントを表し、ACK(A)、...は対応する確認応答セグメントを表します。ACK(A)はBと同じシーケンス番号を持っていることに注意してください。明確性のため、タイムスタンプエコーの1つの方向のみを示します。

o Packets arrive in sequence, and some of the ACKs are delayed.

パケットが順番に到着し、一部のACKが遅延します。

By Case (A), the timestamp from the oldest unacknowledged segment is echoed.

ケース(A)により、最も古い未確認セグメントからのタイムスタンプがエコーされます。

                                              TS.Recent
            <A, TSval=1> ------------------->
                                                  1
            <B, TSval=2> ------------------->
                                                  1
            <C, TSval=3> ------------------->
                                                  1
                     <---- <ACK(C), TSecr=1>
            (etc)

o Packets arrive out of order, and every packet is acknowledged.

パケットが順序外で到着し、すべてのパケットが確認応答されます。

By Case (B), the timestamp from the last segment that advanced the left window edge is echoed, until the missing segment arrives; it is echoed according to Case (C). The same sequence would occur if segments B and D were lost and retransmitted.

ケース(B)により、欠落しているセグメントが到着するまで、左ウィンドウエッジを進めた最後のセグメントからのタイムスタンプがエコーされます。ケース(C)に従ってエコーされます。セグメントBとDが失われて再送信された場合、同じシーケンスが発生します。

                                              TS.Recent
            <A, TSval=1> ------------------->
                                                  1
                     <---- <ACK(A), TSecr=1>
                                                  1
            <C, TSval=3> ------------------->
                                                  1
                     <---- <ACK(A), TSecr=1>
                                                  1
            <B, TSval=2> ------------------->
                                                  2
                     <---- <ACK(C), TSecr=2>
                                                  2
            <E, TSval=5> ------------------->
                                                  2
                     <---- <ACK(C), TSecr=2>
                                                  2
            <D, TSval=4> ------------------->
                                                  4
                     <---- <ACK(E), TSecr=4>
            (etc)