[要約] RFC 7323は、高性能なTCP拡張に関する規格であり、TCPのパフォーマンス向上を目指しています。要約すると、このRFCはTCPの拡張機能を提案し、ネットワークの効率性とスループットを向上させることを目的としています。
Internet Engineering Task Force (IETF) D. Borman
Request for Comments: 7323 Quantum Corporation
Obsoletes: 1323 B. Braden
Category: Standards Track University of Southern California
ISSN: 2070-1721 V. Jacobson
Google, Inc.
R. Scheffenegger, Ed.
NetApp, Inc.
September 2014
TCP Extensions for High Performance
高性能のためのTCP拡張
Abstract
概要
This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.
このドキュメントでは、帯域幅*遅延積が大きいパスでのパフォーマンスを改善し、非常に高速なパスで信頼性の高い動作を提供するための一連のTCP拡張を指定します。これは、TCPウィンドウスケール（WS）オプションとTCPタイムスタンプ（TS）オプションおよびそれらのセマンティクスを定義します。ウィンドウスケールオプションは、より大きな受信ウィンドウをサポートするために使用されますが、タイムスタンプオプションは、少なくとも2つの異なるメカニズムであるラップされたシーケンスに対する保護（PAWS）およびラウンドトリップ時間測定（RTTM）にも使用できます。
This document obsoletes RFC 1323 and describes changes from it.
このドキュメントはRFC 1323を廃止し、RFC 1323からの変更点を説明しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7323.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7323で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. TCP Performance . . . . . . . . . . . . . . . . . . . . . 4
1.2. TCP Reliability . . . . . . . . . . . . . . . . . . . . . 5
1.3. Using TCP options . . . . . . . . . . . . . . . . . . . . 6
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. TCP Window Scale Option . . . . . . . . . . . . . . . . . . . 8
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Window Scale Option . . . . . . . . . . . . . . . . . . . 8
2.3. Using the Window Scale Option . . . . . . . . . . . . . . 9
2.4. Addressing Window Retraction . . . . . . . . . . . . . . 10
3. TCP Timestamps Option . . . . . . . . . . . . . . . . . . . . 11
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Timestamps Option . . . . . . . . . . . . . . . . . . . . 12
4. The RTTM Mechanism . . . . . . . . . . . . . . . . . . . . . 14
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Updating the RTO Value . . . . . . . . . . . . . . . . . 15
4.3. Which Timestamp to Echo . . . . . . . . . . . . . . . . . 16
5. PAWS - Protection Against Wrapped Sequences . . . . . . . . . 19
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 19
5.2. The PAWS Mechanism . . . . . . . . . . . . . . . . . . . 19
5.3. Basic PAWS Algorithm . . . . . . . . . . . . . . . . . . 20
5.4. Timestamp Clock . . . . . . . . . . . . . . . . . . . . . 22
5.5. Outdated Timestamps . . . . . . . . . . . . . . . . . . . 24
5.6. Header Prediction . . . . . . . . . . . . . . . . . . . . 25
5.7. IP Fragmentation . . . . . . . . . . . . . . . . . . . . 26
5.8. Duplicates from Earlier Incarnations of Connection . . . 26
6. Conclusions and Acknowledgments . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Implementation Suggestions . . . . . . . . . . . . . 34
Appendix B. Duplicates from Earlier Connection Incarnations . . 35
B.1. System Crash with Loss of State . . . . . . . . . . . . . 35
B.2. Closing and Reopening a Connection . . . . . . . . . . . 35
Appendix C. Summary of Notation . . . . . . . . . . . . . . . . 37
Appendix D. Event Processing Summary . . . . . . . . . . . . . . 38
Appendix E. Timestamps Edge Cases . . . . . . . . . . . . . . . 44
Appendix F. Window Retraction Example . . . . . . . . . . . . . 44
Appendix G. RTO Calculation Modification . . . . . . . . . . . . 45
Appendix H. Changes from RFC 1323 . . . . . . . . . . . . . . . 46
The TCP protocol [RFC0793] was designed to operate reliably over almost any transmission medium regardless of transmission rate, delay, corruption, duplication, or reordering of segments. Over the years, advances in networking technology have resulted in ever-higher transmission speeds, and the fastest paths are well beyond the domain for which TCP was originally engineered.
TCPプロトコル[RFC0793]は、セグメントの伝送速度、遅延、破損、複製、または並べ替えに関係なく、ほとんどすべての伝送媒体で確実に動作するように設計されています。長年にわたって、ネットワークテクノロジーの進歩により、伝送速度はかつてないほど高速になり、最速のパスは、TCPが最初に設計されたドメインをはるかに超えています。
This document defines a set of modest extensions to TCP to extend the domain of its application to match the increasing network capability. It is an update to and obsoletes [RFC1323], which in turn is based upon and obsoletes [RFC1072] and [RFC1185].
このドキュメントでは、TCPに対する控えめな拡張機能のセットを定義して、増加するネットワーク機能に対応するようにアプリケーションのドメインを拡張しています。これは、廃止された[RFC1323]のアップデートであり、廃止された[RFC1072]と[RFC1185]に基づいています。
Changes between [RFC1323] and this document are detailed in Appendix H. These changes are partly due to errata in [RFC1323], and partly due to the improved understanding of how the involved components interact.
[RFC1323]とこのドキュメントとの間の変更点については、付録Hで詳しく説明します。これらの変更点の一部は、[RFC1323]のエラッタによるものであり、関連するコンポーネントの相互作用に関する理解の向上によるものです。
For brevity, the full discussions of the merits and history behind the TCP options defined within this document have been omitted. [RFC1323] should be consulted for reference. It is recommended that a modern TCP stack implements and make use of the extensions described in this document.
簡潔にするために、このドキュメントで定義されているTCPオプションの背後にあるメリットと履歴の完全な説明は省略されています。 [RFC1323]を参照してください。最新のTCPスタックを実装して、このドキュメントで説明する拡張機能を利用することをお勧めします。
TCP performance problems arise when the bandwidth * delay product is large. A network having such paths is referred to as a "long, fat network" (LFN).
帯域幅*遅延積が大きい場合、TCPパフォーマンスの問題が発生します。このようなパスを持つネットワークは、「ロングファットネットワーク」（LFN）と呼ばれます。
There are two fundamental performance problems with basic TCP over LFN paths:
LFNパス上の基本的なTCPには、2つの基本的なパフォーマンスの問題があります。
(1) Window Size Limit
（1）ウィンドウサイズ制限
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 = 64 KiB. For LFN paths where the bandwidth * delay product exceeds 64 KiB, the receive window limits the maximum throughput of the TCP connection over the path, i.e., the amount of unacknowledged data that TCP can send in order to keep the pipeline full.
TCPヘッダーは、16ビットフィールドを使用して、受信ウィンドウサイズを送信者に報告します。したがって、使用できる最大のウィンドウは2 ^ 16 = 64 KiBです。帯域幅*遅延積が64 KiBを超えるLFNパスの場合、受信ウィンドウは、パスを介したTCP接続の最大スループット、つまり、パイプラインをフルに保つためにTCPが送信できる未確認データの量を制限します。
To circumvent this problem, Section 2 of this memo defines a 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オプション「ウィンドウスケール」を定義しています。このオプションは、暗黙のスケール係数を定義します。これは、TCPヘッダーにあるウィンドウサイズ値を乗算して、実際のウィンドウサイズを取得するために使用されます。
It must be noted that the use of large receive windows increases the chance of too quickly wrapping sequence numbers, as described below in Section 1.2, (1).
以下のセクション1.2（1）で説明するように、大きな受信ウィンドウを使用すると、シーケンス番号の折り返しが速すぎる可能性があることに注意してください。
(2) Recovery from Losses
（2）損失からの回復
Packet losses in an LFN can have a catastrophic effect on throughput.
LFNでのパケット損失は、スループットに壊滅的な影響を与える可能性があります。
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.
ウィンドウごとにドロップされた複数のパケットを処理するように高速再送信/高速リカバリーメカニズムを一般化するには、選択的確認応答が必要です。 TCPの通常の累積確認応答とは異なり、選択的確認応答は、受信者にキューに入れられていて、まだ到着していないセグメントの完全な状況を送信者に提供します。
Selective Acknowledgments and their use are specified in separate documents, "TCP Selective Acknowledgment Options" [RFC2018], "An Extension to the Selective Acknowledgement (SACK) Option for TCP" [RFC2883], and "A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP" [RFC6675], and are not further discussed in this document.
選択的確認応答とその使用は、「TCP選択的確認応答オプション」[RFC2018]、「TCPの選択的確認応答（SACK）オプションの拡張」[RFC2883]、および「選択的確認応答に基づく保守的な損失回復アルゴリズム」で個別に指定されています。 （SACK）for TCP "[RFC6675]。このドキュメントではこれ以上説明しません。
An especially serious kind of error may result from an accidental reuse of TCP sequence numbers in data segments. TCP reliability depends upon the existence of a bound on the lifetime of a segment: the "Maximum Segment Lifetime" or MSL.
特に重大な種類のエラーは、データセグメント内のTCPシーケンス番号を誤って再利用したために発生する可能性があります。 TCPの信頼性は、セグメントの存続期間に上限があるかどうか（「最大セグメント存続期間」またはMSL）に依存します。
Duplication of sequence numbers might happen in either of two ways:
シーケンス番号の重複は、次の2つの方法のいずれかで発生する可能性があります。
(1) Sequence number wrap-around on the current connection
（1）現在の接続でのシーケンス番号の折り返し
A TCP sequence number contains 32 bits. At a high enough transfer rate of large volumes of data (at least 4 GiB in the same session), the 32-bit sequence space may be "wrapped" (cycled) within the time that a segment is delayed in queues.
TCPシーケンス番号には32ビットが含まれます。大量のデータの転送速度が十分に高い場合（同じセッションで少なくとも4 GiB）、32ビットのシーケンススペースは、セグメントがキューで遅延する時間内に「循環」（循環）する可能性があります。
(2) Earlier incarnation of the connection
（2）接続の初期の化身
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 port numbers) 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 specification, as explained in Section 5.8 and Appendix B. In addition, the randomizing of ephemeral ports can also help to probabilistically reduce the chances of duplicates from earlier connections. However, case (1), avoiding the reuse of sequence numbers within the same connection, requires an upper bound on MSL that depends upon the transfer rate, and at high enough rates, a dedicated mechanism is required.
セクション5.8および付録Bで説明されているように、TCP仕様の現在の固定MSLを適用することで、以前のインカネーション（ケース（2））からの重複を回避します。以前の接続から。ただし、ケース（1）では、同じ接続内でのシーケンス番号の再利用を回避するために、転送速度に依存する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, 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 3.2 to protect against old duplicates from the same connection.
セクション5では、PAWSと呼ばれる別のメカニズムを示し、TCPの信頼性を拡張して、ネットワーク帯域幅の予測可能な上限をはるかに超えて転送速度を上げます。 PAWSは、セクション3.2で定義されているTCP Timestampsオプションを使用して、同じ接続からの古い重複から保護します。
The extensions defined in this document all use TCP options.
このドキュメントで定義されている拡張機能はすべてTCPオプションを使用します。
When [RFC1323] was published, there was concern that some buggy TCP implementation might crash on the first appearance of an option on a non-<SYN> segment. However, bugs like that can lead to denial-of-service (DoS) attacks against a TCP. Research has shown that most TCP implementations will properly handle unknown options on non-<SYN> segments ([Medina04], [Medina05]). But it is still prudent to be conservative in what you send, and avoiding buggy TCP implementation is not the only reason for negotiating TCP options on <SYN> segments.
[RFC1323]が公開されたとき、バグのあるTCP実装が、<SYN>以外のセグメントでオプションが最初に表示されるときにクラッシュする可能性があるという懸念がありました。ただし、そのようなバグは、TCPに対するサービス拒否（DoS）攻撃につながる可能性があります。調査によると、ほとんどのTCP実装では、<SYN>以外のセグメント（[Medina04]、[Medina05]）の不明なオプションが適切に処理されます。ただし、送信する内容を慎重にすることは依然として賢明であり、バグのあるTCP実装を回避することが、<SYN>セグメントでTCPオプションをネゴシエートする唯一の理由ではありません。
The Window Scale option negotiates fundamental parameters of the TCP session. Therefore, it is only sent during the initial handshake. Furthermore, the Window Scale option will be sent in a <SYN,ACK> segment only if the corresponding option was received in the initial <SYN> segment.
ウィンドウスケールオプションは、TCPセッションの基本的なパラメータをネゴシエートします。したがって、最初のハンドシェイク時にのみ送信されます。さらに、ウィンドウスケールオプションは、対応するオプションが最初の<SYN>セグメントで受信された場合にのみ、<SYN、ACK>セグメントで送信されます。
The Timestamps option may appear in any data or <ACK> segment, adding 10 bytes (up to 12 bytes including padding) to the 20-byte TCP header. It is required that this TCP option will be sent on all non-<SYN> segments after an exchange of options on the <SYN> segments has indicated that both sides understand this extension.
Timestampsオプションは、データまたは<ACK>セグメントに表示され、20バイトのTCPヘッダーに10バイト（パディングを含めて最大12バイト）が追加されます。 <SYN>セグメントでのオプションの交換により両側がこの拡張を理解したことが示された後、このTCPオプションはすべての非<SYN>セグメントで送信される必要があります。
Research has shown that the use of the Timestamps option to take additional RTT samples within each RTT has little effect on the ultimate retransmission timeout value [Allman99]. However, there are other uses of the Timestamps option, such as the Eifel mechanism ([RFC3522], [RFC4015]) and PAWS (see Section 5), which improve overall TCP security and performance. The extra header bandwidth used by this option should be evaluated for the gains in performance and security in an actual deployment.
調査によると、各RTT内で追加のRTTサンプルを取得するためのタイムスタンプオプションの使用は、最終的な再送信タイムアウト値[Allman99]にほとんど影響を与えません。ただし、Eifelメカニズム（[RFC3522]、[RFC4015]）やPAWS（セクション5を参照）など、Timestampsオプションには他にも用途があり、全体的なTCPセキュリティとパフォーマンスが向上します。このオプションで使用される追加のヘッダー帯域幅は、実際の展開でのパフォーマンスとセキュリティの向上について評価する必要があります。
Appendix A contains a recommended layout of the options in TCP headers to achieve reasonable data field alignment.
付録Aには、適切なデータフィールドの配置を実現するためのTCPヘッダーのオプションの推奨レイアウトが含まれています。
Finally, we observe that most of the mechanisms defined in this document are important for LFNs 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ベンダーは、低速パスに対してこれらの拡張機能をオフにするか、ユーザーまたはインストールマネージャーがそれらを無効にできるようにすることを検討します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
In this document, these words will appear with that interpretation only when in UPPER CASE. Lower case uses of these words are not to be interpreted as carrying [RFC2119] significance.
このドキュメントでは、これらの単語は、大文字の場合にのみその解釈で表示されます。これらの単語の小文字の使用は、[RFC2119]の意味を持つと解釈されるべきではありません。
The window scale extension expands the definition of the TCP window to 30 bits and then uses an implicit scale factor to carry this 30-bit value in the 16-bit window field of the TCP header (SEG.WND in [RFC0793]). The exponent of the scale factor is carried in a TCP option, Window Scale. This option is sent only in a <SYN> segment (a segment with the SYN bit on), hence the window scale is fixed in each direction when a connection is opened.
ウィンドウスケール拡張は、TCPウィンドウの定義を30ビットに拡張し、暗黙のスケールファクターを使用して、この30ビットの値をTCPヘッダーの16ビットウィンドウフィールド（[RFC0793]のSEG.WND）に入れます。スケールファクターの指数は、TCPオプションであるウィンドウスケールで伝達されます。このオプションは<SYN>セグメント（SYNビットがオンになっているセグメント）でのみ送信されるため、接続が開かれると、ウィンドウスケールは各方向に固定されます。
The maximum receive window, and therefore the scale factor, is determined by the maximum receive buffer space. In a typical modern implementation, this maximum buffer space is set by default but can be overridden by a user program before a TCP connection is opened. This determines the scale factor, and therefore no new user interface is needed for window scaling.
最大受信ウィンドウ、つまりスケール係数は、最大受信バッファースペースによって決まります。典型的な最新の実装では、この最大バッファースペースはデフォルトで設定されていますが、TCP接続が開かれる前にユーザープログラムによってオーバーライドできます。これはスケール係数を決定するため、ウィンドウスケーリングに新しいユーザーインターフェイスは必要ありません。
The three-byte Window Scale option MAY be sent in a <SYN> segment by a TCP. It has two purposes: (1) indicate that the TCP is prepared to both send and receive window scaling, and (2) communicate the exponent of a scale factor to be applied to its receive window. Thus, a TCP that is prepared to scale windows SHOULD send the option, even if its own scale factor is 1 and the exponent 0. The scale factor is limited to a power of two and encoded logarithmically, so it may be implemented by binary shift operations. The maximum scale exponent is limited to 14 for a maximum permissible receive window size of 1 GiB (2^(14+16)).
3バイトのウィンドウスケールオプションは、TCPによって<SYN>セグメントで送信される場合があります。これには2つの目的があります。（1）TCPがウィンドウスケーリングの送信と受信の両方の準備ができていることを示し、（2）受信ウィンドウに適用されるスケール係数の指数を伝えます。したがって、ウィンドウをスケーリングする準備ができているTCPは、独自のスケール係数が1で指数0であっても、オプションを送信する必要があります（SHOULD）。スケール係数は2の累乗に制限され、対数的にエンコードされるため、バイナリシフトによって実装できます。操作。 1 GiBの最大許容受信ウィンドウサイズ（2 ^（14 + 16））の場合、最大スケール指数は14に制限されます。
TCP Window Scale option (WSopt):
TCPウィンドウスケールオプション（WSopt）：
Kind: 3
種類：3
Length: 3 bytes
長さ：3バイト
+---------+---------+---------+
| Kind=3 |Length=3 |shift.cnt|
+---------+---------+---------+
1 1 1
This option is an offer, not a promise; both sides MUST send Window Scale options in their <SYN> segments to enable window scaling in either direction. If window scaling is enabled, then the TCP that sent this option will right-shift its true receive-window values by 'shift.cnt' bits for transmission in SEG.WND. The value 'shift.cnt' MAY be zero (offering to scale, while applying a scale factor of 1 to the receive window).
このオプションは提供ではなく、約束です。どちらの方向でもウィンドウスケーリングを有効にするには、両側が<SYN>セグメントでウィンドウスケールオプションを送信する必要があります。ウィンドウスケーリングが有効になっている場合、このオプションを送信したTCPは、SEG.WNDでの送信用に「shift.cnt」ビットだけ実際の受信ウィンドウ値を右シフトします。値 'shift.cnt'はゼロ（MAYを提供する一方で、受信ウィンドウに1の倍率を適用する）にすることができます。
This option MAY be sent in an initial <SYN> segment (i.e., a segment with the SYN bit on and the ACK bit off). If a Window Scale option was received in the initial <SYN> segment, then this option MAY be sent in the <SYN,ACK> segment. A Window Scale option in a segment without a SYN bit MUST be ignored.
このオプションは、最初の<SYN>セグメント（つまり、SYNビットがオンでACKビットがオフのセグメント）で送信できます（MAY）。ウィンドウスケールオプションが最初の<SYN>セグメントで受信された場合、このオプションは<SYN、ACK>セグメントで送信される場合があります。 SYNビットのないセグメントのウィンドウスケールオプションは無視する必要があります。
The window field in a segment where the SYN bit is set (i.e., a <SYN> or <SYN,ACK>) MUST NOT be scaled.
SYNビットが設定されているセグメント内のウィンドウフィールド（つまり、<SYN>または<SYN、ACK>）はスケーリングしてはいけません。
A model implementation of window scaling is as follows, using the notation of [RFC0793]:
[RFC0793]の表記法を使用した、ウィンドウスケーリングのモデル実装は次のとおりです。
o The connection state is augmented by two window shift counters, Snd.Wind.Shift and Rcv.Wind.Shift, to be applied to the incoming and outgoing window fields, respectively.
o 接続状態は、Snd.Wind.ShiftおよびRcv.Wind.Shiftの2つのウィンドウシフトカウンターによって拡張され、それぞれ着信および発信ウィンドウフィールドに適用されます。
o If a TCP receives a <SYN> segment containing a Window Scale option, it SHOULD send its own Window Scale option in the <SYN,ACK> segment.
o TCPがウィンドウスケールオプションを含む<SYN>セグメントを受信した場合、TCPは独自のウィンドウスケールオプションを<SYN、ACK>セグメントで送信する必要があります（SHOULD）。
o The Window Scale option MUST be sent with shift.cnt = R, where R is the value that the TCP would like to use for its receive window.
o ウィンドウスケールオプションは、shift.cnt = Rで送信する必要があります。Rは、TCPが受信ウィンドウに使用する値です。
o Upon receiving a <SYN> segment with a Window Scale option containing shift.cnt = S, a TCP MUST set Snd.Wind.Shift to S and MUST set Rcv.Wind.Shift to R; otherwise, it MUST set both Snd.Wind.Shift and Rcv.Wind.Shift to zero.
o Shift.cnt = Sを含むウィンドウスケールオプションで<SYN>セグメントを受信すると、TCPはSnd.Wind.ShiftをSに設定し、Rcv.Wind.ShiftをRに設定する必要があります。それ以外の場合は、Snd.Wind.ShiftとRcv.Wind.Shiftの両方をゼロに設定する必要があります。
o The window field (SEG.WND) in the header of every incoming segment, with the exception of <SYN> segments, MUST be left-shifted by Snd.Wind.Shift bits before updating SND.WND:
o すべての着信セグメントのヘッダーにあるウィンドウフィールド（SEG.WND）は、<SYN>セグメントを除き、SND.WNDを更新する前にSnd.Wind.Shiftビットで左シフトする必要があります。
SND.WND = SEG.WND << Snd.Wind.Shift
(assuming the other conditions of [RFC0793] are met, and using the "C" notation "<<" for left-shift).
（[RFC0793]の他の条件が満たされていると仮定し、左シフトに「C」表記「<<」を使用します）。
o The window field (SEG.WND) of every outgoing segment, with the exception of <SYN> segments, MUST be right-shifted by Rcv.Wind.Shift bits:
o <SYN>セグメントを除くすべての発信セグメントのウィンドウフィールド（SET.END）は、Rcv.Wind.Shiftビットによって右シフトされる必要があります。
SEG.WND = RCV.WND >> Rcv.Wind.Shift
TCP determines if a data segment is "old" or "new" by testing whether its sequence number is within 2^31 bytes of the left edge of the window, and if it is not, discarding the data as "old". To insure that new data is never mistakenly considered old and vice versa, the left edge of the sender's window has to be at most 2^31 away from the right edge of the receiver's window. The same is true of the sender's right edge and receiver's left edge. Since the right and left edges of either the sender's or receiver's window differ by the window size, and since the sender and receiver windows can be out of phase by at most the window size, the above constraints imply that two times the maximum window size must be less than 2^31, or
TCPは、シーケンス番号がウィンドウの左端の2 ^ 31バイト以内かどうかをテストすることにより、データセグメントが「古い」か「新しい」かを判断し、そうでない場合は、データを「古い」として破棄します。新しいデータが誤って古いと誤って見なされることのないようにするには、送信者のウィンドウの左端が受信者のウィンドウの右端から最大2 ^ 31離れている必要があります。同じことは、送信側の右端と受信側の左端にも当てはまります。送信者または受信者のウィンドウの右端と左端はウィンドウサイズによって異なり、送信者ウィンドウと受信者ウィンドウは最大でウィンドウサイズだけ位相がずれている可能性があるため、上記の制約は最大ウィンドウサイズの2倍でなければならないことを意味します2 ^ 31未満、または
max window < 2^30
最大ウィンドウ<2 ^ 30
Since the max window is 2^S (where S is the scaling shift count) times at most 2^16 - 1 (the maximum unscaled window), the maximum window is guaranteed to be < 2^30 if S <= 14. Thus, the shift count MUST be limited to 14 (which allows windows of 2^30 = 1 GiB). If a Window Scale option is received with a shift.cnt value larger than 14, the TCP SHOULD log the error but MUST use 14 instead of the specified value. This is safe as a sender can always choose to only partially use any signaled receive window. If the receiver is scaling by a factor larger than 14 and the sender is only scaling by 14, then the receive window used by the sender will appear smaller than it is in reality.
最大ウィンドウは2 ^ S（Sはスケーリングシフト数）の最大2 ^ 16-1（最大の非スケールウィンドウ）なので、S <= 14の場合、最大ウィンドウは<2 ^ 30であることが保証されます。 、シフトカウントは14に制限する必要があります（2 ^ 30 = 1 GiBのウィンドウを許可します）。 14より大きいshift.cnt値でウィンドウスケールオプションを受信した場合、TCPはエラーをログに記録する必要がありますが、指定された値の代わりに14を使用する必要があります。送信者は常に、シグナル受信ウィンドウを部分的にのみ使用することを選択できるため、これは安全です。レシーバーが14より大きい倍率でスケーリングし、センダーが14だけスケーリングしている場合、センダーが使用する受信ウィンドウは実際よりも小さく表示されます。
The scale factor applies only to the window field as transmitted in the TCP header; each TCP using extended windows will maintain the window values locally as 32-bit numbers. For example, the "congestion window" computed by slow start and congestion avoidance (see [RFC5681]) is not affected by the scale factor, so window scaling will not introduce quantization into the congestion window.
スケール係数は、TCPヘッダーで送信されるウィンドウフィールドにのみ適用されます。拡張ウィンドウを使用する各TCPは、ウィンドウ値を32ビットの数値としてローカルに維持します。たとえば、スロースタートと輻輳回避（[RFC5681]を参照）によって計算される「輻輳ウィンドウ」は、スケールファクターの影響を受けないため、ウィンドウスケーリングによって輻輳ウィンドウに量子化が導入されることはありません。
When a non-zero scale factor is in use, there are instances when a retracted window can be offered -- see Appendix F for a detailed example. The end of the window will be on a boundary based on the granularity of the scale factor being used. If the sequence number is then updated by a number of bytes smaller than that granularity, the TCP will have to either advertise a new window that is beyond what it previously advertised (and perhaps beyond the buffer) or will have to advertise a smaller window, which will cause the TCP window to shrink. Implementations MUST ensure that they handle a shrinking window, as specified in Section 4.2.2.16 of [RFC1122].
ゼロ以外の倍率が使用されている場合、格納されたウィンドウを提供できる場合があります。詳細な例については、付録Fを参照してください。ウィンドウの終わりは、使用されているスケールファクターの粒度に基づく境界上になります。その後、シーケンス番号がその粒度よりも小さいバイト数で更新される場合、TCPは、以前にアドバタイズしたものを超えた（そしておそらくバッファを超えた）新しいウィンドウをアドバタイズするか、より小さなウィンドウをアドバタイズする必要があります。これにより、TCPウィンドウが縮小します。 [RFC1122]のセクション4.2.2.16で指定されているように、実装は縮小ウィンドウを確実に処理する必要があります。
For the receiver, this implies that:
受信者にとって、これは次のことを意味します。
1) The receiver MUST honor, as in window, any segment that would have been in window for any <ACK> sent by the receiver.
1）受信機は、ウィンドウと同様に、受信機によって送信された<ACK>のためにウィンドウ内にあったであろうすべてのセグメントを尊重しなければなりません（MUST）。
2) When window scaling is in effect, the receiver SHOULD track the actual maximum window sequence number (which is likely to be greater than the window announced by the most recent <ACK>, if more than one segment has arrived since the application consumed any data in the receive buffer).
2）ウィンドウスケーリングが有効な場合、アプリケーションは実際の最大ウィンドウシーケンス番号を追跡する必要があります（アプリケーションが使用してから複数のセグメントが到着した場合、最新の<ACK>によって通知されたウィンドウよりも大きい可能性があります）受信バッファー内のデータ）。
On the sender side:
送信者側：
3) The initial transmission MUST be within the window announced by the most recent <ACK>.
3）最初の送信は、最新の<ACK>によって通知されたウィンドウ内でなければなりません。
4) On first retransmission, or if the sequence number is out of window by less than 2^Rcv.Wind.Shift, then do normal retransmission(s) without regard to the receiver window as long as the original segment was in window when it was sent.
4）最初の再送信時、またはシーケンス番号がウィンドウの2 ^ Rcv.Wind.Shift未満である場合、元のセグメントがウィンドウ内にあった場合に限り、受信側ウィンドウに関係なく通常の再送信を実行します。送信されました。
5) Subsequent retransmissions MAY only be sent if they are within the window announced by the most recent <ACK>.
5）後続の再送信は、最新の<ACK>によってアナウンスされたウィンドウ内にある場合にのみ送信できます。
The Timestamps option is introduced to address some of the issues mentioned in Sections 1.1 and 1.2. The Timestamps option is specified in a symmetrical manner, so that Timestamp Value (TSval) timestamps are carried in both data and <ACK> segments and are echoed in Timestamp Echo Reply (TSecr) fields carried in returning <ACK> or data segments. Originally used primarily for timestamping individual segments, the properties of the Timestamps option allow for taking time measurements (Section 4) as well as additional uses (Section 5).
タイムスタンプオプションは、セクション1.1および1.2で言及されている問題の一部に対処するために導入されました。 Timestampsオプションは対称的に指定されているため、タイムスタンプ値（TSval）のタイムスタンプはデータセグメントと<ACK>セグメントの両方で伝送され、返される<ACK>またはデータセグメントで伝送されるタイムスタンプエコー応答（TSecr）フィールドにエコーされます。もともとは主に個々のセグメントのタイムスタンプに使用されていたTimestampsオプションのプロパティは、時間測定（セクション4）と追加の使用（セクション5）を可能にします。
It is necessary to remember that there is a distinction between the Timestamps option conveying timestamp information and the use of that information. In particular, the RTTM mechanism must be viewed independently from updating the Retransmission Timeout (RTO) (see Section 4.2). In this case, the sample granularity also needs to be taken into account. Other mechanisms, such as PAWS or Eifel, are not built upon the timestamp information itself but are based on the intrinsic property of monotonically non-decreasing values.
タイムスタンプ情報を伝えるタイムスタンプオプションとその情報の使用には違いがあることを覚えておく必要があります。特に、RTTMメカニズムは、再送信タイムアウト（RTO）の更新とは別に表示する必要があります（セクション4.2を参照）。この場合、サンプルの細分性も考慮する必要があります。 PAWSやEifelなどの他のメカニズムは、タイムスタンプ情報自体に基づいて構築されているのではなく、単調に減少しない値の固有のプロパティに基づいています。
The Timestamps option is important when large receive windows are used to allow the use of the PAWS mechanism (see Section 5).
Timestampsオプションは、大きな受信ウィンドウを使用してPAWSメカニズムを使用できる場合に重要です（セクション5を参照）。
Furthermore, the option may be useful for all TCPs, since it simplifies the sender and allows the use of additional optimizations such as Eifel ([RFC3522], [RFC4015]) and others ([RFC6817], [Kuzmanovic03], [Kuehlewind10]).
さらに、このオプションは、送信者を簡素化し、Eifel（[RFC3522]、[RFC4015]）やその他（[RFC6817]、[Kuzmanovic03]、[Kuehlewind10]）などの追加の最適化を使用できるため、すべての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は対称プロトコルであり、いつでもどちらの方向にもデータを送信できるため、タイムスタンプエコーがどちらの方向にも発生する可能性があります。単純さと対称性のために、タイムスタンプは常に両方向に送信およびエコーされることを指定します。効率を上げるために、タイムスタンプとタイムスタンプ応答フィールドを1つのTCPタイムスタンプオプションに結合します。
TCP Timestamps option (TSopt):
TCPタイムスタンプオプション（TSopt）：
Kind: 8
種類：8
Length: 10 bytes
長さ：10バイト
+-------+-------+---------------------+---------------------+
|Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)|
+-------+-------+---------------------+---------------------+
1 1 4 4
The Timestamps option carries two four-byte timestamp fields. The TSval field contains the current value of the timestamp clock of the TCP sending the option.
Timestampsオプションには、2つの4バイトのタイムスタンプフィールドがあります。 TSvalフィールドには、オプションを送信するTCPのタイムスタンプクロックの現在の値が含まれます。
The TSecr field is valid if the ACK bit is set in the TCP header. If the ACK bit is not set in the outgoing TCP header, the sender of that segment SHOULD set the TSecr field to zero. When the ACK bit is set in an outgoing segment, the sender MUST echo a recently received TSval sent by the remote TCP in the TSval field of a Timestamps option. The exact rules on which TSval MUST be echoed are given in Section 4.3. When the ACK bit is not set, the receiver MUST ignore the value of the TSecr field.
TSecrフィールドは、ACKビットがTCPヘッダーに設定されている場合に有効です。 ACKビットが発信TCPヘッダーに設定されていない場合、そのセグメントの送信者はTSecrフィールドをゼロに設定する必要があります（SHOULD）。 ACKビットが発信セグメントに設定されている場合、送信者は、TimestampsオプションのTSvalフィールドのリモートTCPによって送信された最近受信したTSvalをエコーする必要があります。 TSvalをエコーしなければならない正確な規則は、セクション4.3に記載されています。 ACKビットが設定されていない場合、受信者はTSecrフィールドの値を無視する必要があります。
A TCP MAY send the TSopt in an initial <SYN> segment (i.e., segment containing a SYN bit and no ACK bit), and MAY send a TSopt in <SYN,ACK> only if it received a TSopt in the initial <SYN> segment for the connection.
TCPは、最初の<SYN>セグメント（つまり、SYNビットを含み、ACKビットを含まないセグメント）でTSoptを送信できます。また、最初の<SYN>でTSoptを受信した場合にのみ、<SYN、ACK>でTSoptを送信できます（MAY）。接続のセグメント。
Once TSopt has been successfully negotiated, that is both <SYN> and <SYN,ACK> contain TSopt, the TSopt MUST be sent in every non-<RST> segment for the duration of the connection, and SHOULD be sent in an <RST> segment (see Section 5.2 for details). The TCP SHOULD remember this state by setting a flag, referred to as Snd.TS.OK, to one. If a non-<RST> segment is received without a TSopt, a TCP SHOULD silently drop the segment. A TCP MUST NOT abort a TCP connection because any segment lacks an expected TSopt.
TSoptが正常にネゴシエートされた場合、つまり<SYN>と<SYN、ACK>の両方にTSoptが含まれている場合、接続の間、TSoptはすべての非<RST>セグメントで送信される必要があり、<RSTで送信する必要があります（SHOULD） >セグメント（詳細はセクション5.2を参照）。 TCPは、Snd.TS.OKと呼ばれるフラグを1に設定することにより、この状態を記憶する必要があります（SHOULD）。 TSoptなしで<RST>以外のセグメントを受信した場合、TCPはそのセグメントを通知なしでドロップする必要があります（SHOULD）。どのセグメントにも予期されるTSoptがないため、TCPはTCP接続を中止してはなりません（MUST NOT）。
Implementations are strongly encouraged to follow the above rules for handling a missing Timestamps option and the order of precedence mentioned in Section 5.3 when deciding on the acceptance of a segment.
実装では、セグメントの受け入れを決定する際に、欠落しているタイムスタンプオプションとセクション5.3で説明されている優先順位を処理するための上記のルールに従うことを強くお勧めします。
If a receiver chooses to accept a segment without an expected Timestamps option, it must be clear that undetectable data corruption may occur.
受信者が予期されるタイムスタンプオプションなしでセグメントを受け入れることを選択した場合、検出不可能なデータ破損が発生する可能性があることを明確にする必要があります。
Such a TCP receiver may experience undetectable wrapped-sequence effects, such as data (payload) corruption or session stalls. In order to maintain the integrity of the payload data, in particular on high-speed networks, it is paramount to follow the described processing rules.
このようなTCPレシーバーでは、データ（ペイロード）の破損やセッションの停止など、検出できないラップされたシーケンスの影響が発生する可能性があります。特に高速ネットワークでペイロードデータの整合性を維持するためには、説明されている処理ルールに従うことが最も重要です。
However, it has been mentioned that under some circumstances, the above guidelines are too strict, and some paths sporadically suppress the Timestamps option, while maintaining payload integrity. A path behaving in this manner should be deemed unacceptable, but it has been noted that some implementations relax the acceptance rules as a workaround and allow TCP to run across such paths [RE-1323BIS].
ただし、状況によっては、上記のガイドラインが厳しすぎる場合があり、一部のパスではペイロードの整合性を維持しながら散発的にTimestampsオプションが抑制されることが言及されています。このように動作するパスは受け入れられないと見なされますが、実装によっては、回避策として受け入れルールを緩和し、TCPがそのようなパスを介して実行できるようにすることが指摘されています[RE-1323BIS]。
If a TSopt is received on a connection where TSopt was not negotiated in the initial three-way handshake, the TSopt MUST be ignored and the packet processed normally.
TSoptが最初の3ウェイハンドシェイクでネゴシエートされなかった接続で受信された場合、TSoptは無視され、パケットは正常に処理される必要があります。
In the case of crossing <SYN> segments where one <SYN> contains a TSopt and the other doesn't, both sides MAY send a TSopt in the <SYN,ACK> segment.
1つの<SYN>にTSoptが含まれ、もう1つに含まれていない<SYN>セグメントを交差する場合、両側が<SYN、ACK>セグメントでTSoptを送信できます（MAY）。
TSopt is required for the two mechanisms described in Sections 4 and 5. There are also other mechanisms that rely on the presence of the TSopt, e.g., [RFC3522]. If a TCP stopped sending TSopt at any time during an established session, it interferes with these mechanisms. This update to [RFC1323] describes explicitly the previous assumption (see Section 5.2) that each TCP segment must have a TSopt, once negotiated.
TSoptは、セクション4および5で説明されている2つのメカニズムに必要です。TSoptの存在に依存する他のメカニズムもあります（例：[RFC3522]）。 TCPが確立されたセッション中にTSoptの送信を停止した場合、これらのメカニズムに干渉します。この[RFC1323]への更新は、ネゴシエートされた後、各TCPセグメントにTSoptが必要であるという以前の前提（セクション5.2を参照）を明確に説明しています。
One use of the Timestamps option is to measure the round-trip time (RTT) of virtually every packet acknowledged. The RTTM mechanism requires a Timestamps option in every measured segment, with a TSval that is obtained from a (virtual) "timestamp clock". Values of this clock MUST be at least approximately proportional to real time, in order to measure actual RTT.
Timestampsオプションの用途の1つは、確認されたほぼすべてのパケットの往復時間（RTT）を測定することです。 RTTMメカニズムでは、測定されたすべてのセグメントにTimestampsオプションが必要であり、TSvalは（仮想）「タイムスタンプクロック」から取得されます。このクロックの値は、実際のRTTを測定するために、少なくともほぼリアルタイムに比例している必要があります。
TCP measures the RTT, primarily for the purpose of arriving at a reasonable value for the RTO timer interval. Accurate and current RTT estimates are necessary to adapt to changing traffic conditions, while a conservative estimate of the RTO interval is necessary to minimize spurious RTOs.
TCPは、主にRTOタイマー間隔の妥当な値に到達する目的で、RTTを測定します。トラフィック条件の変化に対応するには、正確で最新のRTT見積もりが必要ですが、偽のRTOを最小限に抑えるには、RTO間隔の控えめな見積もりが必要です。
These TSval values are echoed in TSecr values in the reverse direction. The difference between a received TSecr value and the current timestamp clock value provides an RTT measurement.
これらのTSval値は、TSecr値に逆方向にエコーされます。受信したTSecr値と現在のタイムスタンプクロック値の差により、RTT測定が提供されます。
When timestamps are used, every segment that is received will contain a TSecr value. However, these values cannot all be used to update the measured RTT. The following example illustrates why. It shows 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.
タイムスタンプを使用すると、受信したすべてのセグメントにTSecr値が含まれます。ただし、これらの値すべてを使用して測定されたRTTを更新することはできません。次の例は、その理由を示しています。これは、セグメントが損失なしで順番に到着する一方向のデータフローを示しています。ここで、A、B、C ...はシーケンス番号の連続するブロックを占めるデータブロックを表し、ACK（A）...は対応する累積確認応答を表します。 Timestampsオプションの2つのタイムスタンプフィールドは、<TSval = x、TSecr = y>として記号で示されています。各TSecrフィールドには、TSvalフィールドで最後に受信した値が含まれています。
TCP A TCP B
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時間単位長）を示します。この一時停止によってRTTが増大することに注意してください。RTTは、BがデータセグメントCでTSecr = 131を受信することから推測できます。したがって、一方向のデータフローでは、逆方向のRTTMは、データ送信のギャップによって膨張する値を測定します。ただし、次のルールは、測定されたRTTの結果として生じるインフレを防ぎます。
RTTM Rule: A TSecr value received in a segment MAY be used to update the averaged RTT measurement only if the segment advances the left edge of the send window, i.e., SND.UNA is increased.
RTTMルール：セグメントで受信したTSecr値は、セグメントが送信ウィンドウの左端を進める場合、つまりSND.UNAが増加する場合にのみ、平均RTT測定値を更新するために使用できます（MAY）。
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に到着したときに新しいデータを確認しません。したがって、BのRTTM測定を更新するためにインフレートされたRTTM測定は使用されません。
When [RFC1323] was originally written, it was perceived that taking RTT measurements for each segment, and also during retransmissions, would contribute to reduce spurious RTOs, while maintaining the timeliness of necessary RTOs. At the time, RTO was also the only mechanism to make use of the measured RTT. It has been shown that taking more RTT samples has only a very limited effect to optimize RTOs [Allman99].
[RFC1323]が最初に作成されたとき、各セグメントおよび再送信中にRTT測定を行うと、必要なRTOの適時性を維持しながら、偽のRTOを削減できると考えられていました。当時、RTOは測定されたRTTを利用する唯一のメカニズムでもありました。より多くのRTTサンプルを取得しても、RTOを最適化するには非常に限られた効果しかないことが示されています[Allman99]。
Implementers should note that with timestamps, multiple RTTMs can be taken per RTT. The [RFC6298] RTT estimator has weighting factors, alpha and beta, based on an implicit assumption that at most one RTTM will be sampled per RTT. When multiple RTTMs per RTT are available to update the RTT estimator, an implementation SHOULD try to adhere to the spirit of the history specified in [RFC6298]. An implementation suggestion is detailed in Appendix G.
実装者は、タイムスタンプを使用すると、RTTごとに複数のRTTMを取得できることに注意する必要があります。 [RFC6298] RTT推定器には、RTTごとに最大で1つのRTTMがサンプリングされるという暗黙の仮定に基づいて、アルファとベータの重み係数があります。 RTT推定器を更新するためにRTTごとに複数のRTTMが利用可能な場合、実装は[RFC6298]で指定された履歴の精神を遵守するようにすべきです（SHOULD）。実装の提案については、付録Gで詳しく説明しています。
[Ludwig00] and [Floyd05] have highlighted the problem that an unmodified RTO calculation, which is updated with per-packet RTT samples, will truncate the path history too soon. This can lead to an increase in spurious retransmissions, when the path properties vary in the order of a few RTTs, but a high number of RTT samples are taken on a much shorter timescale.
[Ludwig00]と[Floyd05]は、パケットごとのRTTサンプルで更新される未変更のRTO計算がパス履歴を切り捨てるのが早すぎるという問題を強調しています。これにより、パスのプロパティが数RTTのオーダーで変化する場合に、疑似再送信が増加する可能性がありますが、非常に短いタイムスケールで多数のRTTサンプルが取得されます。
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を無視する必要があります。レシーバーに保持される状態（つまり、未処理のTSvalの数）を最小限に抑えるには、レシーバーは接続制御ブロックに最大で1つのタイムスタンプを保持する必要があります。
There are three situations to consider:
考慮すべき3つの状況があります。
(A) Delayed ACKs.
（A）遅延ACK。
Many TCPs acknowledge only every second 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は、短い時間間隔で到着するセグメントのグループのうち、1秒ごとのセグメントのみを確認します。このポリシーは一般に「遅延ACK」と呼ばれます。データ送信側TCPは、遅延ACKによる追加の時間を含め、有効なRTTを測定する必要があります。そうしないと、不必要に再送信されます。したがって、遅延ACKが使用されている場合、受信者は最も古い未確認のセグメントからのTSvalフィールドで応答する必要があります（SHOULD）。
(B) A hole in the sequence space (segment(s) has been lost).
（B）シーケンス空間の穴（セグメントが失われた）。
The sender will continue sending until the window is filled, and the receiver may be generating <ACK>s as these out-of-order segments arrive (e.g., to aid "Fast Retransmit").
送信者はウィンドウがいっぱいになるまで送信を継続し、受信者はこれらの順序の乱れたセグメントが到着したときに<ACK>を生成している可能性があります（たとえば、「高速再送信」を支援するため）。
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 RCV.NXT.
失われたセグメントはおそらく輻輳の兆候であり、そのような状況では、送信者は再送信について保守的である必要があります。さらに、RTTを過小評価するよりも過大評価することをお勧めします。したがって、順不同セグメントの<ACK>には、RCV.NXTを進めた最新のセグメントのタイムスタンプが含まれる必要があります（SHOULD）。
The same situation occurs if segments are reordered by the network.
ネットワークによってセグメントが並べ替えられた場合も、同じ状況が発生します。
(C) A filled hole in the sequence space.
（C）シーケンス空間の塗りつぶされた穴。
The segment that fills the hole and advances the window represents the most recent measurement of the network characteristics. An RTT computed from an earlier segment would probably include the sender's retransmit timeout, 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つのケースすべてをカバーするアルゴリズムは、同期接続でのタイムスタンプオプション処理に関する次のルールで説明されています。
(1) The connection state is augmented with two 32-bit slots:
（1）接続状態は2つの32ビットスロットで拡張されます。
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 <ACK>s have been delayed.
TS.Recentは、セグメントが送信されるたびにTSecrにエコーされるタイムスタンプを保持し、Last.ACK.sentは、最後に送信されたセグメントのACKフィールドを保持します。 Last.ACK.sentは、<ACK>が遅延した場合を除き、RCV.NXTと等しくなります。
(2) If:
（2）以下の場合：
SEG.TSval >= TS.Recent and SEG.SEQ <= Last.ACK.sent
then SEG.TSval is copied to TS.Recent; otherwise, it is ignored.
次にSEG.TSvalがTS.Recentにコピーされます。それ以外の場合は無視されます。
(3) When a TSopt is sent, its TSecr field is set to the current TS.Recent value.
（3）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 Segments arrive in sequence, and some of the <ACK>s are delayed.
o セグメントが順番に到着し、一部の<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 Segments arrive out of order, and every segment is acknowledged.
o セグメントは順不同で到着し、すべてのセグメントが確認されます。
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.)
Another use for the Timestamps option is the PAWS mechanism. Section 5.2 describes a simple mechanism to reject old duplicate segments that might corrupt an open TCP connection. PAWS operates within a single TCP connection, using state that is saved in the connection control block. Section 5.8 and Appendix H discuss the implications of the PAWS mechanism for avoiding old duplicates from previous incarnations of the same connection.
Timestampsオプションのもう1つの用途は、PAWSメカニズムです。セクション5.2では、開いているTCP接続を破壊する可能性のある古い重複セグメントを拒否する簡単なメカニズムについて説明します。 PAWSは、接続制御ブロックに保存されている状態を使用して、単一のTCP接続内で動作します。セクション5.8と付録Hでは、同じ接続の以前の具体化による古い重複を回避するためのPAWSメカニズムの影響について説明します。
PAWS uses the TCP Timestamps option described earlier and assumes that every received TCP segment (including data and <ACK> segments) contains a timestamp SEG.TSval whose values are monotonically 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 timestamps recently received on this connection.
PAWSは、前述のTCPタイムスタンプオプションを使用し、受信したすべてのTCPセグメント（データおよび<ACK>セグメントを含む）にタイムスタンプSEG.TSvalが含まれ、その値が単調に非減少することを前提としています。基本的な考え方は、セグメントが、この接続で最近受信された一部のタイムスタンプよりも小さいタイムスタンプSEG.TSvalで受信された場合、古い複製として破棄できるということです。
In the PAWS 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,
PAWSメカニズムでは、「タイムスタンプ」はモジュラー32ビット空間の32ビット符号なし整数です。したがって、「未満」は、TCPシーケンス番号の場合と同じ方法で定義され、同じ実装手法が適用されます。 sとtがタイムスタンプ値の場合、
s < t if 0 < (t - s) < 2^31,
s <t、0 <（t-s）<2 ^ 31の場合、
computed in unsigned 32-bit arithmetic.
符号なし32ビット演算で計算されます。
The choice of incoming timestamps to be saved for this comparison MUST guarantee a value that is monotonically non-decreasing. For example, an implementation 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. For simplicity, the value TS.Recent introduced in Section 4.3 is used instead, as using a common value for both PAWS and RTTM simplifies the implementation. As Section 4.3 explained, TS.Recent differs from the timestamp from the last in-sequence segment only in the case of delayed <ACK>s, and therefore by less than one window. Either choice will, therefore, protect against sequence number wrap-around.
この比較のために保存される着信タイムスタンプの選択は、単調に減少しない値を保証する必要があります。たとえば、実装では、受信ウィンドウの左端を最後に進めたセグメント、つまり最新のシーケンス内のセグメントのタイムスタンプを保存する場合があります。単純にするために、PAWSとRTTMの両方に共通の値を使用すると実装が簡略化されるため、セクション4.3で導入された値TS.Recentが代わりに使用されます。セクション4.3で説明したように、TS.Recentは、遅延した<ACK>の場合にのみ最後のシーケンス内のセグメントのタイムスタンプと異なるため、1ウィンドウ未満しか異なりません。したがって、どちらを選択しても、シーケンス番号の折り返しから保護されます。
PAWS submits all incoming segments to the same test, and therefore protects against duplicate <ACK> segments as well as data segments. (An alternative non-symmetric algorithm would protect against old duplicate <ACK>s: 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.)
PAWSはすべての受信セグメントを同じテストに送信するため、データセグメントだけでなく、重複する<ACK>セグメントから保護します。 （別の非対称アルゴリズムは、古い重複した<ACK>から保護します：データの送信者は、TSecr値が、ACKフィールドが左端に進んだ最後のセグメントから保存された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ウェイハンドシェイクおよびシーケンス番号チェックによって破棄されます。
[RFC1323] recommended that <RST> segments NOT carry timestamps and that they be acceptable regardless of their timestamp. At that time, the thinking was that old duplicate <RST> segments should be exceedingly unlikely, and their cleanup function should take precedence over timestamps. More recently, discussions about various blind attacks on TCP connections have raised the suggestion that if the Timestamps option is present, SEG.TSecr could be used to provide stricter acceptance tests for <RST> segments.
[RFC1323]は、<RST>セグメントがタイムスタンプを持たないこと、およびタイムスタンプに関係なく受け入れ可能であることを推奨しました。当時は、重複する古い<RST>セグメントはほとんどあり得ないはずであり、それらのクリーンアップ機能はタイムスタンプよりも優先されるべきであると考えていました。最近では、TCP接続に対するさまざまなブラインド攻撃についての議論により、Timestampsオプションが存在する場合、SEG.TSecrを使用して<RST>セグメントのより厳密な受け入れテストを提供できるという提案が出されました。
While still under discussion, to enable research into this area it is now RECOMMENDED that when generating an <RST>, if the segment causing the <RST> to be generated contains a Timestamps option, the <RST> should also contain a Timestamps option. In the <RST> segment, SEG.TSecr SHOULD be set to SEG.TSval from the incoming segment and SEG.TSval SHOULD be set to zero. If an <RST> is being generated because of a user abort, and Snd.TS.OK is set, then a Timestamps option SHOULD be included in the <RST>. When an <RST> segment is received, it MUST NOT be subjected to the PAWS check by verifying an acceptable value in SEG.TSval, and information from the Timestamps option MUST NOT be used to update connection state information. SEG.TSecr MAY be used to provide stricter <RST> acceptance checks.
まだ議論中ですが、この領域の調査を可能にするために、<RST>を生成するときに、<RST>の生成を引き起こすセグメントにTimestampsオプションが含まれている場合、<RST>にもTimestampsオプションを含めることをお勧めします。 <RST>セグメントでは、SEG.TSecrは着信セグメントからのSEG.TSvalに設定する必要があり（SHOULD）、SEG.TSvalはゼロに設定する必要があります（SHOULD）。ユーザーによる中止のために<RST>が生成されていて、Snd.TS.OKが設定されている場合は、Timestampsオプションを<RST>に含める必要があります（SHOULD）。 <RST>セグメントを受信した場合、SEG.TSvalの許容値を確認してPAWSチェックを受けてはならず、Timestampsオプションからの情報を使用して接続状態情報を更新してはなりません（MUST NOT）。 SEG.TSecrを使用して、より厳密な<RST>受け入れチェックを提供できます。
If the PAWS algorithm is used, the following processing MUST be performed on all incoming segments for a synchronized connection. Also, PAWS processing MUST take precedence over the regular TCP acceptability check (Section 3.3 in [RFC0793]), which is performed after verification of the received Timestamps option:
PAWSアルゴリズムを使用する場合、同期接続のすべての着信セグメントで次の処理を実行する必要があります。また、PAWS処理は、受信したTimestampsオプションの確認後に実行される通常のTCP受け入れ可能性チェック（[RFC0793]のセクション3.3）に優先する必要があります。
R1) If there is a Timestamps option in the arriving segment, SEG.TSval < TS.Recent, TS.Recent is valid (see later discussion), and if the RST bit is not set, then treat the arriving segment as not acceptable:
R1）到着セグメントにタイムスタンプオプションがある場合、SEG.TSval <TS.Recent、TS.Recentは有効であり（後述の説明を参照）、RSTビットが設定されていない場合は、到着セグメントを受け入れられないものとして扱います。
Send an acknowledgment in reply as specified in Section 3.9 of [RFC0793], page 69, and drop the segment.
[RFC0793]のセクション3.9、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 an example, see Figure 10 of [RFC0793].
注：ハーフオープン接続を検出して回復するためのTCPのメカニズムを保持するには、<ACK>セグメントを送信する必要があります。例については、[RFC0793]の図10を参照してください。
R2) If the segment is outside the window, reject it (normal TCP processing).
R2）セグメントがウィンドウの外にある場合は、それを拒否します（通常のTCP処理）。
R3) If an arriving segment satisfies SEG.TSval >= TS.Recent and SEG.SEQ <= Last.ACK.sent (see Section 4.3), then record its timestamp in TS.Recent.
R3）到着するセグメントがSEG.TSval> = TS.RecentおよびSEG.SEQ <= Last.ACK.sent（セクション4.3を参照）を満たす場合、そのタイムスタンプをTS.Recentに記録します。
R4) If an arriving segment is in sequence (i.e., at the left window edge), then accept it normally.
R4）到着するセグメントが連続している（つまり、ウィンドウの左端にある）場合は、通常どおり受け入れます。
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).
R5）それ以外の場合は、セグメントを通常のウィンドウ内、シーケンス外のTCPセグメントとして扱います（後でユーザーに配信するためにキューに入れるなど）。
Steps R2, R4, and R5 are the normal TCP processing steps specified by [RFC0793].
ステップR2、R4、およびR5は、[RFC0793]で指定されている通常のTCP処理ステップです。
It is important to note that the timestamp MUST be 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.Recent 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.Recent is set to 2.
セグメントシーケンスA.1、B.1、C.1、...、Z.1が送信されたとします。ここで、文字はシーケンス番号を示し、数字はタイムスタンプを表します。また、セグメントB.1が失われたとします。 TS.Recentのタイムスタンプは1（A.1から）であるため、C.1、...、Z.1は受け入れ可能と見なされ、キューに入れられます。 Bが（最新のタイムスタンプを使用して）セグメントB.2として再送信されると、穴が埋められ、Zまでのすべてのセグメントが確認されてユーザーに渡されます。キューに入れられたセグメントのタイムスタンプは、すでに受け入れられているため、現時点では再度検査されません。 B.2が受け入れられると、TS.Recentは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 segment will show up out of sequence to be queued at the receiver (e.g., up to ~2^30 bytes of data); the Timestamps option must not result in discarding this data.
このルールにより、損失が発生しても妥当なパフォーマンスが得られます。データのフルウィンドウは常に転送中です。損失後、フルウィンドウが1つ少なくなると、レシーバーでキューに入れられるシーケンスが1つ少なくなります（たとえば、最大2 ^ 30バイトのデータ）。 Timestampsオプションを指定しても、このデータは破棄されません。
In certain unlikely circumstances, the algorithm of rules R1-R5 could lead to discarding some segments unnecessarily, as shown in the following example:
次の例に示すように、特定のまれな状況では、ルールR1〜R5のアルゴリズムにより、一部のセグメントが不必要に破棄される可能性があります。
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 <ACK>s, then the queued segments that caused these <ACK>s must have been received already.
このケースが発生することはほとんどありません。タイムアウトによって再送信がトリガーされた場合、一部のセグメントC.1、... Z.1はRTO時間よりも長く遅延している必要があります。これはおそらく起こりそうもないイベントであるか、または多くの偽のタイムアウトと再送信があります。 Bの再送信が「高速再送信」アルゴリズムによって、つまり<ACK>の重複によってトリガーされた場合、これらの<ACK>の原因となったキューに入れられたセグメントはすでに受信されているはずです。
Even if a segment were delayed past the RTO, the Fast Retransmit mechanism [Jacobson90c] will cause the delayed segments 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.
タイムスタンプが不必要にセグメントを破棄することによりパフォーマンスの低下を引き起こす、発生の可能性が高いケースはありません。
It is important to understand that the PAWS algorithm does not require clock synchronization between the sender and receiver. The sender's timestamp clock is used as a source of monotonic non-decreasing values to stamp the segments. The receiver treats the timestamp value as simply a monotonically non-decreasing serial number, without any connection to time. From the receiver's viewpoint, the timestamp is acting as a logical extension of the high-order bits of the sequence number.
PAWSアルゴリズムは送信側と受信側の間のクロック同期を必要としないことを理解することが重要です。送信者のタイムスタンプクロックは、セグメントをスタンプするための単調な非減少値のソースとして使用されます。レシーバーはタイムスタンプ値を、時間に関係なく、単調に減少しないシリアル番号として扱います。受信者の観点から見ると、タイムスタンプはシーケンス番号の上位ビットの論理的な拡張として機能しています。
The receiver algorithm does place some requirements on the frequency of the timestamp clock.
受信機アルゴリズムは、タイムスタンプクロックの周波数にいくつかの要件を課します。
(a) The timestamp clock must not be "too slow".
（a）タイムスタンプクロックは「遅すぎてはいけません」。
It MUST tick at least once for each 2^31 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 window extension defined in Section 2.2, 2^31 bytes must be at least two windows.
送信される2 ^ 31バイトごとに少なくとも1回はチェックする必要があります。実際、ラウンドトリップのタイミングで送信者に役立つために、クロックは、ウィンドウの価値のあるデータごとに少なくとも1回チェックする必要があり、セクション2.2で定義されているウィンドウ拡張でも、2 ^ 31バイトは少なくとも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 1 ms timestamp clock will work at link speeds up to 8 Tbps
(8*10^12) bps!
(b) The timestamp clock must not be "too fast".
（b）タイムスタンプクロックは「速すぎ」てはなりません。
The recycling time of the timestamp clock 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 5.5), 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 in the Internet without requiring precise MSL enforcement.
ただし、アイドル接続（セクション5.5を参照）で古いタイムスタンプを処理し、シーケンス番号の折り返しを防ぐためのMSL要件を緩和するために、はるかに長いリサイクル期間を確立することが望ましいです。 1 msのタイムスタンプクロックでは、32ビットのタイムスタンプは24.8日でその符号ビットをラップします。したがって、MSLが24.8日以下の場合、同じ接続で古い重複を拒否します。これは非常に安全な図のようです。 24.8日以上のMSLは、正確な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メカニズムの要件にも一致します。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メカニズムは、送信者のタイムスタンプクロックにも強い単調性要件を課します。この要件を満たすためのタイムスタンプクロックの実装方法は、システムのハードウェアとソフトウェアによって異なります。
o Some hosts have a hardware clock that is guaranteed to be monotonic between hardware resets.
o 一部のホストには、ハードウェアリセット間で単調であることが保証されているハードウェアクロックがあります。
o A clock interrupt may be used to simply increment a binary integer by 1 periodically.
o クロック割り込みを使用して、2進整数を定期的に1だけインクリメントできます。
o 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).
o タイムスタンプクロックは、可変オフセット値を追加することによって突然変更される可能性のあるシステムクロックから取得できます。このオフセットはゼロに初期化されます。新しいタイムスタンプクロック値が必要な場合は、必要に応じてオフセットを調整して、新しい値を以前の値（この目的で保存された値）以上にすることができます。
o A random offset may be added to the timestamp clock on a per-connection basis. See [RFC6528], Section 3, on randomizing the initial sequence number (ISN). The same function with a different secret key can be used to generate the per-connection timestamp offset.
o ランダムなオフセットは、接続ごとにタイムスタンプクロックに追加できます。初期シーケンス番号（ISN）のランダム化については、[RFC6528]のセクション3をご覧ください。異なる秘密鍵を持つ同じ関数を使用して、接続ごとのタイムスタンプオフセットを生成できます。
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ミリ秒）、符号ビットをラップする時間は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 keep-alive 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 keep-alives, so the solution based upon invalidation was chosen.)
したがって、PAWSの実装には、接続が24日を超えてアイドル状態である場合にTS.Recent値を「無効にする」メカニズムを含める必要があります。 （古いタイムスタンプの問題に対する別の解決策は、キープアライブセグメントを非常に低い速度で送信することですが、1日1回など、タイムスタンプのラップアラウンドタイムよりも頻繁です。これは無視できるオーバーヘッドを課します。しかし、 、TCP仕様にはキープアライブが含まれていないため、無効化に基づくソリューションが選択されました。）
Note that a TCP does not know the frequency, and therefore the wrap-around 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はTS.Recentを新しいセグメントのTSvalで更新します。
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が更新されるたびに、接続に関連付けられたクロックまたはタイムスタンプの値を更新する場合があります。詳細は実装に依存します。
"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?"
「ヘッダー予測」[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).
H1）タイムスタンプを確認します（上記のステップR1と同じ）。
H2) Do header prediction: if the segment is next in sequence and if there are no special conditions requiring additional processing, accept the segment, record its timestamp, and skip H3.
H2）ヘッダー予測を実行します。セグメントが次のシーケンスで、追加の処理が必要な特別な条件がない場合は、セグメントを受け入れ、そのタイムスタンプを記録して、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 queuing in-window, out-of-sequence segments.
H3）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 unsigned modulo arithmetic. To perform this check on every single segment is contrary to the philosophy of header prediction. We believe that this change might produce a measurable reduction in CPU time for TCP protocol processing on high-speed networks.
別の可能性は、ステップH1とH2を交換すること、すなわち、ヘッダー予測ステップH2を*最初に*実行し、ヘッダー予測が失敗した場合にのみH1とH3を実行することです。ステップH1のタイムスタンプチェックが失敗する可能性はほとんどなく、符号なしのモジュロ演算が必要であるため、これはパフォーマンスの改善になる可能性があります。すべてのセグメントでこのチェックを実行することは、ヘッダー予測の哲学に反します。この変更により、高速ネットワークでのTCPプロトコル処理のCPU時間を大幅に削減できる可能性があります。
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 in [RFC1185] to show that the probability of this failure is negligible.
ただし、H2を最初に配置するとハザードが発生します。過去の2 ^ 32バイトのセグメントが正確に間違った時間に到着し、ヘッダー予測ステップで誤って受け入れられる可能性があります。この失敗の確率が無視できることを示すために、次の推論が[RFC1185]に導入されました。
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 < 2^16; for example, it will be (2^12)/(2^32) = 2^-20 for [a 100 Mbit/s] 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）をシーケンススペースのサイズで割った値です。 MSSは2 ^ 16未満でなければならないため、この比率は2 ^ -16未満でなければなりません。たとえば、[100 Mbit / s]リンクの場合、（2 ^ 12）/（2 ^ 32）= 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. [Note: the notation for exponentiation has been changed from how it appeared in RFC 1185.]
16ビットTCPチェックサムは、2 ^ 16の一部の基本的な信頼性の欠如も可能にします。信頼性がTCPチェックサムの信頼性を超えるプロトコルメカニズムは、「十分に良い」と見なす必要があります。つまり、全体的なエラー率に大きく影響することはありません。したがって、タイムスタンプをチェックする前にヘッダー予測を行うことで、古い重複が受け入れられる問題を無視できると考えています。 [注：べき乗の表記は、RFC 1185での表記から変更されています。]
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の後に続くことが推奨されます。
At high data rates, the protection against old segments provided by PAWS can be circumvented by errors in IP fragment reassembly (see [RFC4963]). The only way to protect against incorrect IP fragment reassembly is to not allow the segments to be fragmented. This is done by setting the Don't Fragment (DF) bit in the IP header.
データレートが高い場合、PAWSによって提供される古いセグメントに対する保護は、IPフラグメントの再構成のエラーによって回避できます（[RFC4963]を参照）。不正なIPフラグメントの再構成から保護する唯一の方法は、セグメントのフラグメント化を許可しないことです。これは、IPヘッダーのDo n't Fragment（DF）ビットを設定することによって行われます。
Setting the DF bit implies the use of Path MTU Discovery as described in [RFC1191], [RFC1981], and [RFC4821]; thus, any TCP implementation that implements PAWS MUST also implement Path MTU Discovery.
DFビットを設定すると、[RFC1191]、[RFC1981]、および[RFC4821]で説明されているように、パスMTUディスカバリが使用されます。したがって、PAWSを実装するすべてのTCP実装は、Path MTU Discoveryも実装する必要があります。
The PAWS mechanism protects against errors due to sequence number wrap-around on high-speed connections. 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 an MSL by the Internet (IP) layer (see the 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の前提条件やメカニズムを超えて、さらに前提条件やメカニズムが必要であることを示しています。これは現在の拡張機能の一部ではありません。
This memo presented a set of extensions to TCP to provide efficient operation over large bandwidth * delay product paths and reliable operation over very high-speed paths. These extensions are designed to provide compatible interworking with TCP stacks that do not implement the extensions.
このメモは、広い帯域幅*遅延積パスでの効率的な操作と非常に高速なパスでの信頼できる操作を提供するためのTCPへの拡張セットを示しました。これらの拡張機能は、拡張機能を実装しないTCPスタックとの互換性のあるインターワーキングを提供するように設計されています。
These mechanisms are implemented using TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms: RTTM and PAWS.
これらのメカニズムは、スケーリングされたウィンドウとタイムスタンプのTCPオプションを使用して実装されます。タイムスタンプは、RTTMとPAWSの2つの異なるメカニズムに使用されます。
The Window Scale option was originally suggested by Mike St. Johns of USAF/DCA. The present form of the option was suggested by Mike Karels of UC Berkeley in response to a more cumbersome scheme defined by Van Jacobson. Lixia Zhang helped formulate the PAWS mechanism description in [RFC1185].
Window Scaleオプションは、もともとUSAF / DCAのMike St. Johnsによって提案されました。オプションの現在の形式は、Van Jacobsonによって定義されたより厄介なスキームに応じて、カリフォルニア大学バークレー校のMike Karelsによって提案されました。 Lixia Zhangは、[RFC1185]でPAWSメカニズムの説明を作成するのに役立ちました。
Finally, much of this work originated as the result of discussions within the End-to-End Task Force on the theoretical limitations of transport protocols in general and TCP in particular. Task force members and others on the end2end-interest list have made valuable contributions by pointing out flaws in the algorithms and the documentation. Continued discussion and development since the publication of [RFC1323] originally occurred in the IETF TCP Large Windows Working Group, later on in the End-to-End Task Force, and most recently in the IETF TCP Maintenance Working Group. The authors are grateful for all these contributions.
最後に、この作業の多くは、一般的なトランスポートプロトコル、特にTCPの理論上の制限に関するエンドツーエンドタスクフォース内での議論の結果として生まれました。 end2end-interestリストのタスクフォースメンバーやその他のメンバーは、アルゴリズムとドキュメントの欠陥を指摘することで、貴重な貢献をしてくれました。 [RFC1323]の公開以来、継続的に議論と開発が行われたのは、もともとはIETF TCP Large Windowsワーキンググループ、その後はエンドツーエンドタスクフォース、そして最近ではIETF TCPメンテナンスワーキンググループで行われました。著者はこれらすべての貢献に感謝しています。
The TCP sequence space is a fixed size, and as the window becomes larger, it becomes easier for an attacker to generate forged packets that can fall within the TCP window and be accepted as valid segments. While use of timestamps and PAWS can help to mitigate this, when using PAWS, if an attacker is able to forge a packet that is acceptable to the TCP connection, a timestamp that is in the future would cause valid segments to be dropped due to PAWS checks. Hence, implementers should take care to not open the TCP window drastically beyond the requirements of the connection.
TCPシーケンススペースは固定サイズであり、ウィンドウが大きくなると、攻撃者がTCPウィンドウ内に収まり、有効なセグメントとして受け入れることができる偽造パケットを生成しやすくなります。タイムスタンプとPAWSの使用はこれを軽減するのに役立ちますが、PAWSを使用する場合、攻撃者がTCP接続に受け入れ可能なパケットを偽造できる場合、将来のタイムスタンプはPAWSにより有効なセグメントがドロップされる原因になりますチェック。したがって、実装者は、接続の要件を大幅に超えてTCPウィンドウを開かないように注意する必要があります。
See [RFC5961] for mitigation strategies to blind in-window attacks.
ウィンドウ内攻撃をブラインドする緩和策については、[RFC5961]を参照してください。
A naive implementation that derives the timestamp clock value directly from a system uptime clock may unintentionally leak this information to an attacker. This does not directly compromise any of the mechanisms described in this document. However, this may be valuable information to a potential attacker. It is therefore RECOMMENDED to generate a random, per-connection offset to be used with the clock source when generating the Timestamps option value (see Section 5.4). By carefully choosing this random offset, further improvements as described in [RFC6191] are possible.
タイムスタンプクロック値をシステムの稼働時間クロックから直接取得する単純な実装では、この情報が意図せずに攻撃者に漏洩する可能性があります。これにより、このドキュメントで説明されているメカニズムが直接侵害されることはありません。ただし、これは潜在的な攻撃者にとって貴重な情報になる可能性があります。したがって、Timestampsオプション値を生成するときに、クロックソースで使用するランダムな接続ごとのオフセットを生成することをお勧めします（セクション5.4を参照）。このランダムなオフセットを注意深く選択することにより、[RFC6191]で説明されているように、さらなる改善が可能です。
Expanding the TCP window beyond 64 KiB for IPv6 allows Jumbograms [RFC2675] to be used when the local network supports packets larger than 64 KiB. When larger TCP segments are used, the TCP checksum becomes weaker.
IPv6の64 KiBを超えてTCPウィンドウを拡張すると、ローカルネットワークが64 KiBより大きいパケットをサポートする場合、ジャンボグラム[RFC2675]を使用できます。より大きなTCPセグメントを使用すると、TCPチェックサムが弱くなります。
Mechanisms to protect the TCP header from modification should also protect the TCP options.
TCPヘッダーを変更から保護するメカニズムは、TCPオプションも保護する必要があります。
Middleboxes and TCP options:
ミドルボックスとTCPオプション：
Some middleboxes have been known to remove the TCP options described in this document from TCP segments [Honda11]. Middleboxes that remove TCP options described in this document from the <SYN> segment interfere with the selection of parameters appropriate for the session. Removing any of these options in a <SYN,ACK> segment will leave the end hosts in a state that destroys the proper operation of the protocol.
一部のミドルボックスは、このドキュメントで説明されているTCPオプションをTCPセグメントから削除することが知られています[Honda11]。このドキュメントで説明されているTCPオプションを<SYN>セグメントから削除するミドルボックスは、セッションに適したパラメーターの選択を妨害します。 <SYN、ACK>セグメントでこれらのオプションのいずれかを削除すると、エンドホストはプロトコルの適切な動作を破壊する状態のままになります。
* If a Window Scale option is removed from a <SYN,ACK> segment, the end hosts will not negotiate the window scaling factor correctly. Middleboxes must not remove or modify the Window Scale option from <SYN,ACK> segments.
* ウィンドウスケールオプションが<SYN、ACK>セグメントから削除されると、エンドホストはウィンドウスケールファクターを正しくネゴシエートしません。 Middleboxは、<SYN、ACK>セグメントからWindow Scaleオプションを削除または変更してはなりません。
* If a stateful firewall uses the window field to detect whether a received segment is inside the current window, and does not support the Window Scale option, it will not be able to correctly determine whether or not a packet is in the window. These middle boxes must also support the Window Scale option and apply the scale factor when processing segments. If the window scale factor cannot be determined, it must not do window-based processing.
* ステートフルファイアウォールがウィンドウフィールドを使用して、受信したセグメントが現在のウィンドウ内にあるかどうかを検出し、ウィンドウスケールオプションをサポートしていない場合、パケットがウィンドウ内にあるかどうかを正しく判断できません。これらの中央のボックスは、ウィンドウスケールオプションもサポートし、セグメントの処理時にスケール係数を適用する必要があります。ウィンドウスケール係数を決定できない場合は、ウィンドウベースの処理を実行してはなりません。
* If the Timestamps option is removed from the <SYN> or <SYN,ACK> segments, high speed connections that need PAWS would not have that protection. Successful negotiation of the Timestamps option enforces a stricter verification of incoming segments at the receiver. If the Timestamps option was removed from a subsequent data segment after a successful negotiation (e.g., as part of resegmentation), the segment is discarded by the receiver without further processing. Middleboxes should not remove the Timestamps option.
* Timestampsオプションが<SYN>または<SYN、ACK>セグメントから削除されている場合、PAWSを必要とする高速接続にはその保護がありません。 Timestampsオプションのネゴシエーションが成功すると、受信側で着信セグメントの検証がより厳密になります。ネゴシエーションが成功した後（たとえば、再分割の一部として）、Timestampsオプションが後続のデータセグメントから削除された場合、そのセグメントは、それ以上処理せずにレシーバーによって破棄されます。 MiddleboxesはTimestampsオプションを削除してはなりません。
* It must be noted that [RFC1323] doesn't address the case of the Timestamps option being dropped or selectively omitted after being negotiated, and that the update in this document may cause some broken middlebox behavior to be detected (potentially unresponsive TCP sessions).
* [RFC1323]は、ネゴシエーション後にTimestampsオプションが削除されたり選択的に省略されたりするケースに対処していないこと、およびこのドキュメントの更新により、ミドルボックスの動作が壊れている可能性があることに注意してください（潜在的に応答しないTCPセッション）。
Implementations that depend on PAWS could provide a mechanism for the application to determine whether or not PAWS is in use on the connection and choose to terminate the connection if that protection doesn't exist. This is not just to protect the connection against middleboxes that might remove the Timestamps option, but also against remote hosts that do not have Timestamp support.
PAWSに依存する実装は、アプリケーションが接続でPAWSが使用されているかどうかを判断し、保護が存在しない場合に接続を終了することを選択するメカニズムを提供できます。これは、Timestampsオプションを削除する可能性があるミドルボックスから接続を保護するだけでなく、Timestampをサポートしていないリモートホストからも保護します。
The TCP options described in this document do not expose individual user's data. However, a naive implementation simply using the system clock as a source for the Timestamps option will reveal characteristics of the TCP, potentially allowing more targeted attacks. It is therefore RECOMMENDED to generate a random, per-connection offset to be used with the clock source when generating the Timestamps option value (see Section 5.4).
このドキュメントで説明するTCPオプションは、個々のユーザーのデータを公開しません。ただし、単純にシステムクロックをタイムスタンプオプションのソースとして使用する単純な実装では、TCPの特性が明らかになり、より標的を絞った攻撃が可能になる場合があります。したがって、Timestampsオプション値を生成するときに、クロックソースで使用するランダムな接続ごとのオフセットを生成することをお勧めします（セクション5.4を参照）。
Furthermore, the combination, relative ordering, and padding of the TCP options described in Sections 2.2 and 3.2 will reveal additional clues to allow the fingerprinting of the system.
さらに、セクション2.2と3.2で説明されているTCPオプションの組み合わせ、相対的な順序、およびパディングは、システムのフィンガープリントを可能にする追加の手がかりを明らかにします。
The described TCP options are well known from the superceded [RFC1323]. IANA has updated the "TCP Option Kind Numbers" table under "TCP Parameters" to list this document (RFC 7323) as the reference for "Window Scale" and "Timestamps".
説明されているTCPオプションは、置き換えられた[RFC1323]からよく知られています。 IANAは、「TCPパラメータ」の「TCPオプションの種類番号」の表を更新して、このドキュメント（RFC 7323）を「ウィンドウスケール」と「タイムスタンプ」のリファレンスとしてリストしました。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、1990年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[Allman99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", Proceedings of the ACM SIGCOMM Technical Symposium, Cambridge, MA, September 1999, <http://aciri.org/mallman/papers/estimation-la.pdf>.
[Allman99] Allman、M。およびV. Paxson、「On-Estimating End-to-End Network Path Properties」、Proceedings of the ACM SIGCOMM Technical Symposium、Cambridge、MA、1999年9月、<http://aciri.org/mallman /papers/estimation-la.pdf>。
[Floyd05] Floyd, S., "Subject: Re: [tcpm] RFC 1323: Timestamps option", message to the TCPM mailing list, 26 January 2007, <http://www.ietf.org/mail-archive/web/tcpm/current/ msg02508.html>.
[Floyd05] Floyd、S。、「Subject：Re：[tcpm] RFC 1323：Timestamps option」、TCPMメーリングリストへのメッセージ、2007年1月26日、<http://www.ietf.org/mail-archive/web / tcpm / current / msg02508.html>。
[Garlick77] Garlick, L., Rom, R., and J. Postel, "Issues in Reliable Host-to-Host Protocols", Proceedings of the Second Berkeley Workshop on Distributed Data Management and Computer Networks, March 1977, <http://www.rfc-editor.org/ien/ien12.txt>.
[Garlick77] Garlick、L.、Rom、R。、およびJ. Postel、「Issues in Reliable Host-to-Host Protocols」、Proceedings of the Second Berkeley Workshop on Distributed Data Management and Computer Networks、1977年3月、<http： //www.rfc-editor.org/ien/ien12.txt>。
[Honda11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., and H. Tokuda, "Is it Still Possible to Extend TCP?", Proceedings of the ACM Internet Measurement Conference (IMC) '11, November 2011.
[Honda11]本田雅夫、西田康夫、ライチウC、グリーンハルグA.、ハンドラリーM.、徳田H.「TCPを拡張することはまだ可能か？」、ACMインターネット測定のプロシーディングス会議（IMC）'11、2011年11月。
[Jacobson88a] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM '88, Stanford, CA, August 1988, <http://ee.lbl.gov/papers/congavoid.pdf>.
[Jacobson88a] Jacobson、V。、「輻輳回避と制御」、SIGCOMM '88、スタンフォード、カリフォルニア、1988年8月、<http://ee.lbl.gov/papers/congavoid.pdf>。
[Jacobson90a] Jacobson, V., "4BSD Header Prediction", ACM Computer Communication Review, April 1990.
[Jacobson90a] Jacobson、V。、「4BSDヘッダー予測」、ACM Computer Communication Review、1990年4月。
[Jacobson90c] Jacobson, V., "Subject: modified TCP congestion avoidance algorithm", message to the End2End-Interest mailing list, 30 April 1990, <ftp://ftp.isi.edu/end2end/ end2end-interest-1990.mail>.
[Jacobson90c] Jacobson、V。、「件名：変更されたTCP輻輳回避アルゴリズム」、End2End-Interestメーリングリストへのメッセージ、1990年4月30日、<ftp://ftp.isi.edu/end2end/ end2end-interest-1990。メール>。
[Karn87] Karn, P. and C. Partridge, "Estimating Round-Trip Times in Reliable Transport Protocols", Proceedings of SIGCOMM '87, August 1987.
[Karn87] Karn、P.およびC. Partridge、「Estimating Round-Trip Times in Reliable Transport Protocols」、Proceedings of SIGCOMM '87、August 1987。
[Kuehlewind10] Kuehlewind, M. and B. Briscoe, "Chirping for Congestion Control - Implementation Feasibility", November 2010, <http://bobbriscoe.net/projects/netsvc_i-f/ chirp_pfldnet10.pdf>.
[Kuehlewind10] Kuehlewind、M。、およびB. Briscoe、「輻輳制御のためのチャーピング-実装の実現可能性」、2010年11月、<http://bobbriscoe.net/projects/netsvc_i-f/chirp_pfldnet10.pdf>。
[Kuzmanovic03] Kuzmanovic, A. and E. Knightly, "TCP-LP: Low-Priority Service via End-Point Congestion Control", 2003, <www.cs.northwestern.edu/~akuzma/doc/TCP-LP-ToN.pdf>.
[Kuzmanovic03] Kuzmanovic、A。およびE. Knightly、「TCP-LP：End-Point Congestion Control via Low-Priority Service via End-Point Congestion Control」、2003、<www.cs.northwestern.edu/~akuzma/doc/TCP-LP-ToN .pdf>。
[Ludwig00] Ludwig, R. and K. Sklower, "The Eifel Retransmission Timer", ACM SIGCOMM Computer Communication Review Volume 30 Issue 3, July 2000, <http://ccr.sigcomm.org/archive/2000/july00/ LudwigFinal.pdf>.
[Ludwig00] Ludwig、R. and K. Sklower、 "The Eifel Retransmission Timer"、ACM SIGCOMM Computer Communication Review Volume 30 Issue 3、July 2000、<http://ccr.sigcomm.org/archive/2000/july00/ LudwigFinal .pdf>。
[Martin03] Martin, D., "Subject: [Tsvwg] RFC 1323.bis", message to the TSVWG mailing list, 30 September 2003, <http://www.ietf.org/mail-archive/web/tsvwg/current/ msg04435.html>.
[Martin03] Martin、D。、「Subject：[Tsvwg] RFC 1323.bis」、TSVWGメーリングリストへのメッセージ、2003年9月30日、<http://www.ietf.org/mail-archive/web/tsvwg/ current / msg04435.html>。
[Medina04] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", Proceedings of the ACM SIGCOMM/USENIX Internet Measurement Conference, October 2004, <http://www.icir.net/tbit/tbit-Aug2004.pdf>.
[Medina04] Medina、A.、Allman、M。、およびS. Floyd、「Measuring Interactions between Transport Protocols and Middleboxes」、Proceedings of the ACM SIGCOMM / USENIX Internet Measurement Conference、2004年10月、<http：//www.icir .net / tbit / tbit-Aug2004.pdf>。
[Medina05] Medina, A., Allman, M., and S. Floyd, "Measuring the Evolution of Transport Protocols in the Internet", ACM Computer Communication Review Volume 35, No. 2, April 2005, <http://icir.net/floyd/papers/TCPevolution-Mar2005.pdf>.
[Medina05] Medina、A.、Allman、M。、およびS. Floyd、「インターネットにおけるトランスポートプロトコルの進化の測定」、ACM Computer Communication Review Volume 35、No。2、2005年4月、<http：// icir .net / floyd / papers / TCPevolution-Mar2005.pdf>。
[RE-1323BIS] Oppermann, A., "Subject: Re: [tcpm] I-D Action: draft-ietf.tcpm-1323bis-13.txt", message to the TCPM mailing list, 01 June 2013, <http://www.ietf.org/ mail-archive/web/tcpm/current/msg08001.html>.
[RE-1323BIS] Oppermann、A。、「件名：Re：[tcpm] IDアクション：draft-ietf.tcpm-1323bis-13.txt」、TCPMメーリングリストへのメッセージ、2013年6月1日、<http：// www.ietf.org/ mail-archive / web / tcpm / current / msg08001.html>。
[RFC1072] Jacobson, V. and R. Braden, "TCP extensions for long-delay paths", RFC 1072, October 1988.
[RFC1072] Jacobson、V。およびR. Braden、「長い遅延パスのTCP拡張機能」、RFC 1072、1988年10月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[RFC1185] Jacobson, V., Braden, B., and L. Zhang, "TCP Extension for High-Speed Paths", RFC 1185, October 1990.
[RFC1185] Jacobson、V.、Braden、B。、およびL. Zhang、「高速パス用のTCP拡張」、RFC 1185、1990年10月。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、B。、およびD. Borman、「TCP Extensions for High Performance」、RFC 1323、1992年5月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「Path MTU Discovery for IP version 6」、RFC 1981、1996年8月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018] Mathis、M.、Madhavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Acknowledgement Options」、RFC 2018、1996年10月。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC2675] Borman、D.、Deering、S。、およびR. Hinden、「IPv6 Jumbograms」、RFC 2675、1999年8月。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883]フロイド、S。、マハビ、J。、マティス、M。、およびM.ポドルスキー、「TCPの選択的確認応答（SACK）オプションの拡張」、RFC 2883、2000年7月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[RFC3522] Ludwig、R。およびM. Meyer、「TCPのEifel検出アルゴリズム」、RFC 3522、2003年4月。
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, February 2005.
[RFC4015] Ludwig、R.およびA. Gurtov、「The Eifel Response Algorithm for TCP」、RFC 4015、2005年2月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.
[RFC4963] Heffner、J.、Matis、M。、およびB. Chandler、「高データレートでのIPv4再構成エラー」、RFC 4963、2007年7月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、2009年9月。
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
[RFC5961]ラマイア、A。、スチュワート、R。、およびM.ダラル、「ウィンドウ内のブラインド攻撃に対するTCPの堅牢性の向上」、RFC 5961、2010年8月。
[RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP Timestamps", BCP 159, RFC 6191, April 2011.
[RFC6191] Gont、F。、「TCPタイムスタンプを使用したTIME-WAIT状態の削減」、BCP 159、RFC 6191、2011年4月。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
[RFC6298] Paxson、V.、Allman、M.、Chu、J。、およびM. Sargent、「Computing TCP's Retransmission Timer」、RFC 6298、2011年6月。
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012.
[RFC6528] Gont、F。、およびS. Bellovin、「シーケンス番号攻撃に対する防御」、RFC 6528、2012年2月。
[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., and Y. Nishida, "A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP", RFC 6675, August 2012.
[RFC6675] Blanton、E.、Allman、M.、Wang、L.、Jarvinen、I.、Kojo、M。、およびY. Nishida、「TCPの選択的確認応答（SACK）に基づく保守的な損失回復アルゴリズム」、 RFC 6675、2012年8月。
[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", RFC 6691, July 2012.
[RFC6691] Borman、D。、「TCPオプションと最大セグメントサイズ（MSS）」、RFC 6691、2012年7月。
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, December 2012.
[RFC6817] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、RFC 6817、2012年12月。
TCP Option Layout
TCPオプションのレイアウト
The following layout is recommended for sending options on non-<SYN> segments to achieve maximum feasible alignment of 32-bit and 64-bit machines.
次のレイアウトは、<SYN>以外のセグメントでオプションを送信して、32ビットおよび64ビットマシンの実現可能な最大の配置を実現するために推奨されます。
+--------+--------+--------+--------+
| NOP | NOP | TSopt | 10 |
+--------+--------+--------+--------+
| TSval timestamp |
+--------+--------+--------+--------+
| TSecr timestamp |
+--------+--------+--------+--------+
Interaction with the TCP Urgent Pointer
TCP緊急ポインターとの相互作用
The TCP Urgent Pointer, like the TCP window, is a 16-bit value. Some of the original discussion for the TCP Window Scale option included proposals to increase the Urgent Pointer to 32 bits. As it turns out, this is unnecessary. There are two observations that should be made:
TCPウィンドウと同様に、TCP緊急ポインタは16ビット値です。 TCPウィンドウスケールオプションの元の説明には、緊急ポインタを32ビットに増やす提案が含まれていました。結局のところ、これは不要です。行う必要がある2つの観察があります。
(1) With IP version 4, the largest amount of TCP data that can be sent in a single packet is 65495 bytes (64 KiB - 1 - size of fixed IP and TCP headers).
（1）IPバージョン4では、1つのパケットで送信できるTCPデータの最大量は65495バイト（64 KiB-1-固定IPおよびTCPヘッダーのサイズ）です。
(2) Updates to the Urgent Pointer while the user is in "urgent mode" are invisible to the user.
（2）ユーザーが「緊急モード」にある間の緊急ポインターへの更新は、ユーザーには見えません。
This means that if the Urgent Pointer points beyond the end of the TCP data in the current segment, then the user will remain in urgent mode until the next TCP segment arrives. That segment will update the Urgent Pointer to a new offset, and the user will never have left urgent mode.
これは、緊急ポインターが現在のセグメントのTCPデータの終わりを超えている場合、ユーザーは次のTCPセグメントが到着するまで緊急モードのままであることを意味します。そのセグメントは緊急ポインターを新しいオフセットに更新し、ユーザーは緊急モードを終了したことはありません。
Thus, to properly implement the Urgent Pointer, the sending TCP only has to check for overflow of the 16-bit Urgent Pointer field before filling it in. If it does overflow, than a value of 65535 should be inserted into the Urgent Pointer.
したがって、緊急ポインタを適切に実装するために、送信TCPは、16ビットの緊急ポインタフィールドのオーバーフローをチェックするだけで入力できます。オーバーフローする場合は、65535の値を緊急ポインタに挿入する必要があります。
The same technique applies to IP version 6, except in the case of IPv6 Jumbograms. When IPv6 Jumbograms are supported, [RFC2675] requires additional steps for dealing with the Urgent Pointer; these steps are described in Section 5.2 of [RFC2675].
IPv6ジャンボグラムの場合を除いて、同じ手法がIPバージョン6に適用されます。 IPv6ジャンボグラムがサポートされている場合、[RFC2675]は緊急ポインタを処理するための追加の手順を必要とします。これらの手順については、[RFC2675]のセクション5.2で説明しています。
There are two cases to be considered: (1) a system crashing (and losing connection state) and restarting, and (2) the same connection being closed and reopened without a loss of host state. These will be described in the following two sections.
考慮すべきケースは2つあります。（1）システムのクラッシュ（および接続状態の喪失）と再起動、および（2）ホストの状態を失うことなく同じ接続が閉じられ、再度開かれた場合。これらについては、次の2つのセクションで説明します。
TCP's quiet time of one MSL upon system startup handles the loss of connection state in a system crash/restart. For an explanation, see, for example, "Knowing When to Keep Quiet" in the TCP protocol specification [RFC0793]. The MSL that is required here does not depend upon the transfer speed. The current TCP MSL of 2 minutes seemed acceptable as an operational compromise, when many host systems used to take this long to boot after a crash. Current host systems can boot considerably faster.
システムの起動時の1つのMSLのTCPの待機時間は、システムのクラッシュ/再起動における接続状態の損失を処理します。説明については、たとえば、TCPプロトコル仕様[RFC0793]の「いつ静かにするかを知る」を参照してください。ここで必要なMSLは転送速度に依存しません。現在のTCP MSLである2分は、多くのホストシステムがクラッシュ後の起動にこれほど長い時間を要していたため、運用上の妥協点として受け入れられるように思われました。現在のホストシステムはかなり速く起動できます。
The Timestamps option may be used to ease the MSL requirements (or to provide additional security against data corruption). If timestamps are being used and if the timestamp clock can be guaranteed to be monotonic over a system crash/restart, i.e., if the first value of the sender's timestamp clock after a crash/restart can be guaranteed to be greater than the last value before the restart, then a quiet time is unnecessary.
Timestampsオプションは、MSL要件を緩和する（またはデータ破損に対する追加のセキュリティを提供する）ために使用できます。タイムスタンプが使用されており、タイムスタンプクロックがシステムのクラッシュ/再起動に対して単調であることが保証できる場合、つまり、クラッシュ/再起動後の送信者のタイムスタンプクロックの最初の値が前の最後の値より大きいことが保証できる場合再起動すると、静かな時間が不要になります。
To dispense totally with the quiet time would require that the host clock be synchronized to a time source that is stable over the crash/ restart period, with an accuracy of one timestamp clock tick or better. We can back off from this strict requirement to take advantage of approximate clock synchronization. Suppose that the clock is always resynchronized to within N timestamp clock ticks and that booting (extended with a quiet time, if necessary) takes more than N ticks. This will guarantee monotonicity of the timestamps, which can then be used to reject old duplicates even without an enforced MSL.
完全に静かな時間を省くには、ホストクロックを、クラッシュ/再起動期間にわたって安定しているタイムソースに同期させ、タイムスタンプクロックの精度を1以上にする必要があります。おおよそのクロック同期を利用するために、この厳密な要件から後退することができます。クロックが常にNタイムスタンプクロックティック以内に再同期され、起動（必要に応じて待機時間で拡張）にNティック以上かかると仮定します。これにより、タイムスタンプの単調性が保証され、MSLが適用されていなくても古い重複を拒否できます。
When a TCP connection is closed, a delay of 2*MSL in TIME-WAIT state ties up the socket pair for 4 minutes (see Section 3.5 of [RFC0793]). Applications built upon TCP that close one connection and open a new one (e.g., an FTP data transfer connection using Stream mode) must choose a new socket pair each time. The TIME-WAIT delay serves two different purposes: (a) Implement the full-duplex reliable close handshake of TCP.
TCP接続が閉じられると、TIME-WAIT状態の2 * MSLの遅延により、ソケットペアが4分間拘束されます（[RFC0793]のセクション3.5を参照）。 1つの接続を閉じて新しい接続を開くTCPで構築されたアプリケーション（たとえば、ストリームモードを使用したFTPデータ転送接続）は、毎回新しいソケットペアを選択する必要があります。 TIME-WAIT遅延には、2つの異なる目的があります。（a）TCPの全二重信頼性の高いクローズハンドシェイクを実装します。
The proper time to delay the final close step is not really related to the MSL; it depends instead upon the RTO for the FIN segments and, therefore, upon the RTT of the path. (It could be argued that the side that is sending a FIN knows what degree of reliability it needs, and therefore it should be able to determine the length of the TIME-WAIT delay for the FIN's recipient. This could be accomplished with an appropriate TCP option in FIN segments.)
最後のクローズステップを遅らせる適切な時間は、MSLとは関係ありません。代わりに、FINセグメントのRTOに依存するため、パスのRTTに依存します。 （FINを送信する側は、必要な信頼性の程度を知っているため、FINの受信者のTIME-WAIT遅延の長さを判別できるはずです。これは、適切なTCPで実現できます。 FINセグメントのオプション）。
Although there is no formal upper bound on RTT, common network engineering practice makes an RTT greater than 1 minute very unlikely. Thus, the 4-minute delay in TIME-WAIT state works satisfactorily to provide a reliable full-duplex TCP close. Note again that this is independent of MSL enforcement and network speed.
RTTには正式な上限はありませんが、一般的なネットワークエンジニアリングの慣習により、RTTが1分を超えることはほとんどありません。したがって、TIME-WAIT状態の4分の遅延は、信頼できる全二重TCPクローズを提供するために十分に機能します。これは、MSLの実施やネットワーク速度とは無関係であることに再度注意してください。
The TIME-WAIT state could cause an indirect performance problem if an application needed to repeatedly close one connection and open another at a very high frequency, since the number of available TCP ports on a host is less than 2^16. However, high network speeds are not the major contributor to this problem; the RTT is the limiting factor in how quickly connections can be opened and closed. Therefore, this problem will be no worse at high transfer speeds.
ホストで使用可能なTCPポートの数が2 ^ 16未満であるため、アプリケーションが非常に高い頻度で1つの接続を繰り返し閉じて別の接続を開く必要がある場合、TIME-WAIT状態は間接的なパフォーマンスの問題を引き起こす可能性があります。ただし、高速ネットワークはこの問題の主な原因ではありません。 RTTは、接続を開いたり閉じたりする速度を制限する要因です。したがって、この問題は、高速転送速度でも悪化しません。
(b) Allow old duplicate segments to expire.
（b）古い重複セグメントが期限切れになるのを許可します。
To replace this function of TIME-WAIT state, a mechanism would have to operate across connections. PAWS is defined strictly within a single connection; the last timestamp (TS.Recent) is kept in the connection control block and discarded when a connection is closed.
このTIME-WAIT状態の機能を置き換えるには、メカニズムが複数の接続にわたって動作する必要があります。 PAWSは単一の接続内で厳密に定義されています。最後のタイムスタンプ（TS.Recent）は接続制御ブロックに保持され、接続が閉じられると破棄されます。
An additional mechanism could be added to the TCP, a per-host cache of the last timestamp received from any connection. This value could then be used in the PAWS mechanism to reject old duplicate segments from earlier incarnations of the connection, if the timestamp clock can be guaranteed to have ticked at least once since the old connection was open. This would require that the TIME-WAIT delay plus the RTT together must be at least one tick of the sender's timestamp clock. Such an extension is not part of the proposal of this RFC.
TCPに追加のメカニズムを追加できます。これは、接続から受信した最後のタイムスタンプのホストごとのキャッシュです。次に、この値をPAWSメカニズムで使用して、古い接続が開いてからタイムスタンプクロックが少なくとも1回ティックされていることが保証できる場合、接続の以前のインカネーションからの古い重複セグメントを拒否できます。これには、TIME-WAIT遅延とRTTを合わせて、送信者のタイムスタンプクロックの少なくとも1ティックが必要です。このような拡張は、このRFCの提案の一部ではありません。
Note that this is a variant on the mechanism proposed by Garlick, Rom, and Postel [Garlick77], which required each host to maintain connection records containing the highest sequence numbers on every connection. Using timestamps instead, it is only necessary to keep one quantity per remote host, regardless of the number of simultaneous connections to that host.
これはGarlick、Rom、およびPostel [Garlick77]によって提案されたメカニズムのバリアントであり、各ホストがすべての接続で最高のシーケンス番号を含む接続レコードを維持する必要があることに注意してください。代わりにタイムスタンプを使用すると、そのホストへの同時接続数に関係なく、リモートホストごとに1つの量を保持するだけで済みます。
The following notation has been used in this document.
このドキュメントでは、次の表記が使用されています。
Options
オプション
WSopt: TCP Window Scale option TSopt: TCP Timestamps option
WSopt：TCPウィンドウスケールオプションTSopt：TCPタイムスタンプオプション
Option Fields
オプションフィールド
shift.cnt: Window scale byte in WSopt TSval: 32-bit Timestamp Value field in TSopt TSecr: 32-bit Timestamp Reply field in TSopt
shift.cnt：WSoptのウィンドウスケールバイトTSval：TSoptの32ビットのタイムスタンプ値フィールドTSecr：TSoptの32ビットのタイムスタンプ応答フィールド
Option Fields in Current Segment
現在のセグメントのオプションフィールド
SEG.TSval: TSval field from TSopt in current segment SEG.TSecr: TSecr field from TSopt in current segment SEG.WSopt: 8-bit value in WSopt
SEG.TSval：現在のセグメントのTSoptからのTSvalフィールドSEG.TSecr：現在のセグメントのTSoptからのTSecrフィールドSEG.WSopt：WSoptの8ビット値
Clock Values
クロック値
my.TSclock: System-wide source of 32-bit timestamp values my.TSclock.rate: Period of my.TSclock (1 ms to 1 sec) Snd.TSoffset: An offset for randomizing Snd.TSclock Snd.TSclock: my.TSclock + Snd.TSoffset
my.TSclock：32ビットのタイムスタンプ値のシステム全体のソースmy.TSclock.rate：my.TSclockの周期（1 ms〜1秒）Snd.TSoffset：Snd.TSclockをランダム化するためのオフセットSnd.TSclock：my.TSclock + Snd.TSoffset
Per-Connection State Variables
接続ごとの状態変数
TS.Recent: Latest received Timestamp Last.ACK.sent: Last ACK field sent Snd.TS.OK: 1-bit flag Snd.WS.OK: 1-bit flag Rcv.Wind.Shift: Receive window scale exponent Snd.Wind.Shift: Send window scale exponent Start.Time: Snd.TSclock value when the segment being timed was sent (used by code from before RFC 1323).
TS.Recent：最後に受信したタイムスタンプLast.ACK.sent：最後に送信されたACKフィールドSnd.TS.OK：1ビットフラグSnd.WS.OK：1ビットフラグRcv.Wind.Shift：受信ウィンドウスケール指数Snd.Wind .Shift：送信ウィンドウスケール指数Start.Time：計時中のセグメントが送信されたときのSnd.TSclock値（RFC 1323以前のコードで使用）。
Procedure
手順
Update_SRTT(m) Procedure to update the smoothed RTT and RTT variance estimates, using the rules of [Jacobson88a], given m, a new RTT measurement
Update_SRTT（m）[Jacobson88a]のルールを使用して、平滑化されたRTTとRTTの分散の推定値を更新する手順。
Send Sequence Variables
シーケンス変数を送信する
SND.UNA: Send unacknowledged SND.NXT: Send next SND.WND: Send window ISS: Initial send sequence number
SND.UNA：確認応答なしで送信SND.NXT：次のSND.ANDを送信：AND送信ウィンドウISS：最初の送信シーケンス番号
Receive Sequence Variables
受信シーケンス変数
RCV.NXT: Receive next RCV.WND: Receive window IRS: Initial receive sequence number
RCV.NXT：次のRCV.ANDの受信：ウィンドウの受信IRS：初期受信シーケンス番号
This appendix attempts to specify the algorithms unambiguously by presenting modifications to the Event Processing rules in Section 3.9 of RFC 793. The change bars ("|") indicate lines that are different from RFC 793.
この付録では、RFC 793のセクション3.9のイベント処理ルールに変更を加えて、アルゴリズムを明確に指定しようとしています。変更バー（「|」）は、RFC 793とは異なる行を示しています。
OPEN Call
OPENコール
...
。。。
An initial send sequence number (ISS) is selected. Send a <SYN>
| segment of the form:
|
| <SEQ=ISS><CTL=SYN><TSval=Snd.TSclock><WSopt=Rcv.Wind.Shift>
...
。。。
SEND Call
通話を送信
CLOSED STATE (i.e., TCB does not exist)
CLOSED STATE（つまり、TCBは存在しません）
...
。。。
LISTEN STATE
待ち受け状態
If active and the foreign socket is specified, then change the connection from passive to active, select an ISS. Send a SYN | segment containing the options: <TSval=Snd.TSclock> and | <WSopt=Rcv.Wind.Shift>. Set SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT state. ...
アクティブで外部ソケットが指定されている場合は、接続をパッシブからアクティブに変更して、ISSを選択します。 SYNを送信する|オプションを含むセグメント：<TSval = Snd.TSclock>および| <WSopt = Rcv.Wind.Shift>。 SND.UNAをISSに、SND.NXTをISS + 1に設定します。 SYN-SENT状態に入ります。 ...
SYN-SENT STATE SYN-RECEIVED STATE
SYN-SENT状態SYN-RECEIVED状態
...
。。。
ESTABLISHED STATE CLOSE-WAIT STATE
確立された状態のクローズ待機状態
Segmentize the buffer and send it with a piggybacked acknowledgment (acknowledgment value = RCV.NXT). ...
バッファをセグメント化し、ピギーバックされた確認応答（確認応答値= RCV.NXT）で送信します。 ...
If the urgent flag is set ...
緊急フラグが設定されていると......
| If the Snd.TS.OK flag is set, then include the TCP Timestamps
| option <TSval=Snd.TSclock,TSecr=TS.Recent> in each data
| segment.
|
| Scale the receive window for transmission in the segment
| header:
|
| SEG.WND = (RCV.WND >> Rcv.Wind.Shift).
SEGMENT ARRIVES
セグメント到着
...
。。。
If the state is LISTEN then
状態がLISTENの場合
first check for an RST
最初にRSTを確認します
...
。。。
second check for an ACK
ACKの2番目のチェック
...
。。。
third check for a SYN
SYNの3番目のチェック
If the SYN bit is set, check the security. If the ...
SYNビットが設定されている場合は、セキュリティを確認してください。もし...
...
。。。
If the SEG.PRC is less than the TCB.PRC then continue.
SEG.PRCがTCB.PRCより小さい場合は、続行します。
| Check for a Window Scale option (WSopt); if one is found,
| save SEG.WSopt in Snd.Wind.Shift and set Snd.WS.OK flag on.
| Otherwise, set both Snd.Wind.Shift and Rcv.Wind.Shift to
| zero and clear Snd.WS.OK flag.
|
| Check for a TSopt option; if one is found, save SEG.TSval in
| the variable TS.Recent and turn on the Snd.TS.OK bit.
Set RCV.NXT to SEG.SEQ+1, IRS is set to SEG.SEQ and any other control or text should be queued for processing later. ISS should be selected and a SYN segment sent of the form:
RCV.NXTをSEG.SEQ + 1に設定し、IRSをSEG.SEQに設定します。他のコントロールまたはテキストは、後で処理するためにキューに入れる必要があります。 ISSが選択され、SYNセグメントが次の形式で送信されます。
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
| If the Snd.WS.OK bit is on, include a WSopt
| <WSopt=Rcv.Wind.Shift> in this segment. If the Snd.TS.OK
| bit is on, include a TSopt <TSval=Snd.TSclock,
| TSecr=TS.Recent> in this segment. Last.ACK.sent is set to
| RCV.NXT.
SND.NXT is set to ISS+1 and SND.UNA to ISS. The connection state should be changed to SYN-RECEIVED. Note that any other incoming control or data (combined with SYN) will be processed in the SYN-RECEIVED state, but processing of SYN and ACK should not be repeated. If the listen was not fully specified (i.e., the foreign socket was not fully specified), then the unspecified fields should be filled in now.
SND.NXTはISS + 1に、SND.UNAはISSに設定されています。接続状態をSYN-RECEIVEDに変更する必要があります。他の着信制御またはデータ（SYNと結合）はSYN-RECEIVED状態で処理されますが、SYNおよびACKの処理は繰り返さないでください。リッスンが完全に指定されていない場合（つまり、外部ソケットが完全に指定されていない場合）、指定されていないフィールドに入力する必要があります。
fourth other text or control
4番目の他のテキストまたはコントロール
...
。。。
If the state is SYN-SENT then
状態がSYN-SENTの場合
first check the ACK bit
最初にACKビットを確認します
...
。。。
...
。。。
fourth check the SYN bit
4番目にSYNビットをチェックします
...
。。。
If the SYN bit is on and the security/compartment and precedence are acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to SEG.SEQ. SND.UNA should be advanced to equal SEG.ACK (if there is an ACK), and any segments on the retransmission queue which are thereby acknowledged should be removed.
SYNビットがオンで、セキュリティ/コンパートメントと優先順位が許容できる場合、RCV.NXTはSEG.SEQ + 1に設定され、IRSはSEG.SEQに設定されます。 SND.UNAはSEG.ACK（ACKがある場合）に等しくなるように進められる必要があり、それによって確認応答される再送信キューのセグメントは削除する必要があります。
| Check for a Window Scale option (WSopt); if it is found,
| save SEG.WSopt in Snd.Wind.Shift; otherwise, set both
| Snd.Wind.Shift and Rcv.Wind.Shift to zero.
|
| Check for a TSopt option; if one is found, save SEG.TSval in
| variable TS.Recent and turn on the Snd.TS.OK bit in the
| connection control block. If the ACK bit is set, use
| Snd.TSclock - SEG.TSecr as the initial RTT estimate.
If SND.UNA > ISS (our SYN has been ACKed), change the connection state to ESTABLISHED, form an <ACK> segment:
SND.UNA> ISS（SYNがACKされている）の場合、接続状態をESTABLISHEDに変更し、<ACK>セグメントを形成します。
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
| and send it. If the Snd.TS.OK bit is on, include a TSopt
| option <TSval=Snd.TSclock,TSecr=TS.Recent> in this <ACK>
| segment. Last.ACK.sent is set to RCV.NXT.
Data or controls that were queued for transmission may be included. If there are other controls or text in the segment, then continue processing at the sixth step below where the URG bit is checked; otherwise, return.
送信のためにキューに入れられたデータまたはコントロールが含まれる場合があります。セグメントに他のコントロールまたはテキストがある場合は、次の6番目のステップで処理を続行し、URGビットをチェックします。それ以外の場合は戻ります。
Otherwise, enter SYN-RECEIVED, form a <SYN,ACK> segment:
それ以外の場合は、SYN-RECEIVEDと入力し、<SYN、ACK>セグメントを形成します。
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
| and send it. If the Snd.TS.OK bit is on, include a TSopt
| option <TSval=Snd.TSclock,TSecr=TS.Recent> in this segment.
| If the Snd.WS.OK bit is on, include a WSopt option
| <WSopt=Rcv.Wind.Shift> in this segment. Last.ACK.sent is
| set to RCV.NXT.
If there are other controls or text in the segment, queue them for processing after the ESTABLISHED state has been reached, return.
セグメントに他のコントロールまたはテキストがある場合は、ESTABLISHED状態に達した後、それらを処理のためにキューに入れ、戻ります。
fifth, if neither of the SYN or RST bits is set then drop the segment and return.
5番目に、SYNビットもRSTビットも設定されていない場合は、セグメントを削除して戻ります。
Otherwise
さもないと
first check the sequence number
最初にシーケンス番号を確認します
SYN-RECEIVED STATE ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE CLOSE-WAIT STATE CLOSING STATE LAST-ACK STATE TIME-WAIT STATE
SYN受信状態確立状態FIN-WAIT-1状態FIN-WAIT-2状態CLOSE-WAIT状態終了状態LAST-ACK状態TIME-WAIT状態
Segments are processed in sequence. Initial tests on arrival are used to discard old duplicates, but further processing is done in SEG.SEQ order. If a segment's contents straddle the boundary between old and new, only the new parts should be processed.
セグメントは順番に処理されます。到着時の最初のテストは古い重複を破棄するために使用されますが、それ以降の処理はSEG.SEQの順序で行われます。セグメントのコンテンツが古いものと新しいものの境界にまたがる場合、新しい部分のみを処理する必要があります。
| Rescale the received window field:
|
| TrueWindow = SEG.WND << Snd.Wind.Shift,
|
| and use "TrueWindow" in place of SEG.WND in the following
| steps.
|
| Check whether the segment contains a Timestamps option and
| if bit Snd.TS.OK is on. If so:
|
| If SEG.TSval < TS.Recent and the RST bit is off:
|
| If the connection has been idle more than 24 days,
| save SEG.TSval in variable TS.Recent, else the segment
| is not acceptable; follow the steps below for an
| unacceptable segment.
|
| If SEG.TSval >= TS.Recent and SEG.SEQ <= Last.ACK.sent,
| then save SEG.TSval in variable TS.Recent.
There are four cases for the acceptability test for an incoming segment:
着信セグメントの許容性テストには4つのケースがあります。
...
。。。
If an incoming segment is not acceptable, an acknowledgment should be sent in reply (unless the RST bit is set; if so drop the segment and return):
着信セグメントが受け入れられない場合は、応答で確認応答を送信する必要があります（RSTビットが設定されていない限り、そうであればセグメントをドロップして戻ります）。
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
| Last.ACK.sent is set to SEG.ACK of the acknowledgment. If
| the Snd.TS.OK bit is on, include the Timestamps option
| <TSval=Snd.TSclock,TSecr=TS.Recent> in this <ACK> segment.
Set Last.ACK.sent to SEG.ACK and send the <ACK> segment.
After sending the acknowledgment, drop the unacceptable
segment and return.
...
。。。
fifth check the ACK field,
5番目に、ACKフィールドを確認します。
if the ACK bit is off drop the segment and return
ACKビットがオフの場合、セグメントをドロップして返します。
if the ACK bit is on
ACKビットがオンの場合
...
。。。
ESTABLISHED STATE
設立国
If SND.UNA < SEG.ACK <= SND.NXT then, set SND.UNA <-
| SEG.ACK. Also compute a new estimate of round-trip time.
| If Snd.TS.OK bit is on, use Snd.TSclock - SEG.TSecr;
| otherwise, use the elapsed time since the first segment
| in the retransmission queue was sent. Any segments on
the retransmission queue that are thereby entirely
acknowledged...
...
。。。
seventh, process the segment text,
7番目に、セグメントテキストを処理します。
ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE
ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE
...
。。。
Send an acknowledgment of the form:
フォームの確認を送信します。
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
| If the Snd.TS.OK bit is on, include the Timestamps option
| <TSval=Snd.TSclock,TSecr=TS.Recent> in this <ACK> segment.
| Set Last.ACK.sent to SEG.ACK of the acknowledgment, and send
| it. This acknowledgment should be piggybacked on a segment
being transmitted if possible without incurring undue delay.
...
。。。
While the rules laid out for when to calculate RTTM produce the correct results most of the time, there are some edge cases where an incorrect RTTM can be calculated. All of these situations involve the loss of segments. It is felt that these scenarios are rare, and that if they should happen, they will cause a single RTTM measurement to be inflated, which mitigates its effects on RTO calculations.
RTTMを計算するタイミングについて定められた規則は、ほとんどの場合正しい結果を生成しますが、誤ったRTTMが計算される可能性があるいくつかのエッジケースがあります。これらの状況はすべて、セグメントの損失を伴います。これらのシナリオはまれであり、それらが発生した場合、1つのRTTM測定が増大し、RTO計算への影響が軽減されると考えられています。
[Martin03] cites two similar cases when the returning <ACK> is lost, and before the retransmission timer fires, another returning <ACK> segment arrives, which acknowledges the data. In this case, the RTTM calculated will be inflated:
[Martin03]は、返される<ACK>が失われ、再送信タイマーが起動する前に別の返される<ACK>セグメントが到着し、データを確認する2つの類似のケースを引用しています。この場合、計算されるRTTMは増大します。
clock
tc=1 <A, TSval=1> ------------------->
tc=2 (lost) <---- <ACK(A), TSecr=1, win=n>
(RTTM would have been 1)
(receive window opens, window update is sent)
tc=5 <---- <ACK(A), TSecr=1, win=m>
(RTTM is calculated at 4)
One thing to note about this situation is that it is somewhat bounded by RTO + RTT, limiting how far off the RTTM calculation will be. While more complex scenarios can be constructed that produce larger inflations (e.g., retransmissions are lost), those scenarios involve multiple segment losses, and the connection will have other more serious operational problems than using an inflated RTTM in the RTO calculation.
この状況について注意する必要があるのは、RTO + RTTによってある程度制限されており、RTTM計算からの距離が制限されることです。より大きなインフレを生成するより複雑なシナリオを構築できますが（たとえば、再送信が失われるなど）、これらのシナリオには複数のセグメントの損失が含まれ、RTO計算でインフレートされたRTTMを使用するよりも接続に他のより深刻な運用上の問題があります。
Consider an established TCP connection using a scale factor of 128, Snd.Wind.Shift=7 and Rcv.Wind.Shift=7, that is running with a very small window because the receiver is bottlenecked and both ends are doing small reads and writes.
スケールファクター128、Snd.Wind.Shift = 7およびRcv.Wind.Shift = 7を使用して確立されたTCP接続を考えてみます。これは、レシーバーがボトルネックになっていて両端が小さな読み取りと書き込みを行っているため、非常に小さなウィンドウで実行されています。 。
Consider the ACKs coming back:
戻ってくるACKについて考えてみましょう。
SEG.ACK SEG.WIN computed SND.WIN receiver's actual window 1000 2 1256 1300
SEG.ACK SEG.WIN計算されたSND.WINレシーバーの実際のウィンドウ1000 2 1256 1300
The sender writes 40 bytes and receiver ACKs:
送信側は40バイトと受信側ACKを書き込みます。
1040 2 1296 1300 The sender writes 5 additional bytes and the receiver has a problem. Two choices:
1040 2 1296 1300送信側がさらに5バイトを書き込み、受信側に問題があります。 2つの選択肢：
1045 2 1301 1300 - BEYOND BUFFER
1045 2 1301 1300-バッファーを超えて
1045 1 1173 1300 - RETRACTED WINDOW
1045 1 1173 1300-引き込みウィンドウ
This is a general problem and can happen any time the sender does a write, which is smaller than the window scale factor.
これは一般的な問題であり、送信者が書き込みを行うたびに発生する可能性があります。これはウィンドウスケールファクターよりも小さくなります。
In most stacks, it is at least partially obscured when the window size is larger than some small number of segments because the stacks prefer to announce windows that are an integral number of segments, rounded up to the next scale factor. This plus silly window suppression tends to cause less frequent, larger window updates. If the window was rounded down to a segment size, there is more opportunity to advance the window, the BEYOND BUFFER case above, rather than retracting it.
ほとんどのスタックでは、ウィンドウサイズがいくつかの少数のセグメントよりも大きい場合、スタックは整数のセグメントであるウィンドウをアナウンスし、次のスケールファクターに切り上げられるため、少なくとも部分的に隠されます。これに加えて、ばかげたウィンドウ抑制により、ウィンドウ更新の頻度が低くなり、大きな更新が発生する傾向があります。ウィンドウがセグメントサイズに切り捨てられた場合、ウィンドウを撤回するよりも、ウィンドウを上に移動する機会が多くなります（上記のBEYOND BUFFERの場合）。
Appendix G. RTO Calculation Modification
付録G. RTO計算の変更
Taking multiple RTT samples per window would shorten the history calculated by the RTO mechanism in [RFC6298], and the below algorithm aims to maintain a similar history as originally intended by [RFC6298].
ウィンドウごとに複数のRTTサンプルを取得すると、[RFC6298]のRTOメカニズムによって計算された履歴が短くなります。以下のアルゴリズムは、[RFC6298]が当初意図していたのと同様の履歴を維持することを目的としています。
It is roughly known how many samples a congestion window worth of data will yield, not accounting for ACK compression, and ACK losses. Such events will result in more history of the path being reflected in the final value for RTO, and are uncritical. This modification will ensure that a similar amount of time is taken into account for the RTO estimation, regardless of how many samples are taken per window:
ACK圧縮とACK損失を考慮せずに、輻輳ウィンドウ相当のデータが生成するサンプル数はおおよそわかっています。このようなイベントは、RTOの最終的な値に反映されるパスの履歴を増やすことになり、重要ではありません。この変更により、ウィンドウごとに取得されるサンプルの数に関係なく、RTOの見積もりに同様の時間が考慮されます。
ExpectedSamples = ceiling(FlightSize / (SMSS * 2))
alpha' = alpha / ExpectedSamples
alpha '= alpha / ExpectedSamples
beta' = beta / ExpectedSamples
beta '= beta / ExpectedSamples
Note that the factor 2 in ExpectedSamples is due to "Delayed ACKs".
ExpectedSamplesの係数2は「遅延ACK」が原因であることに注意してください。
Instead of using alpha and beta in the algorithm of [RFC6298], use alpha' and beta' instead:
[RFC6298]のアルゴリズムでアルファとベータを使用する代わりに、代わりにアルファとベータを使用します。
RTTVAR <- (1 - beta') * RTTVAR + beta' * |SRTT - R'|
SRTT <- (1 - alpha') * SRTT + alpha' * R'
(for each sample R')
（各サンプルR '）
Appendix H. Changes from RFC 1323
付録H.RFC 1323からの変更
Several important updates and clarifications to the specification in RFC 1323 are made in this document. The technical changes are summarized below:
このドキュメントでは、RFC 1323の仕様に対するいくつかの重要な更新と明確化が行われています。技術的な変更の概要を以下に示します。
(a) A wrong reference to SND.WND was corrected to SEG.WND in Section 2.3.
（a）AND.ENDへの誤った参照は、セクション2.3でSET.ENDに修正されました。
(b) Section 2.4 was added describing the unavoidable window retraction issue and explicitly describing the mitigation steps necessary.
（b）セクション2.4が追加され、不可避のウィンドウリトラクトの問題について説明し、必要な緩和手順を明示的に説明しました。
(c) In Section 3.2, the wording how the Timestamps option negotiation is to be performed was updated with RFC2119 wording. Further, a number of paragraphs were added to clarify the expected behavior with a compliant implementation using TSopt, as RFC 1323 left room for interpretation -- e.g., potential late enablement of TSopt.
（c）セクション3.2では、タイムスタンプオプションのネゴシエーションがどのように実行されるかについての表現がRFC2119の表現で更新されました。さらに、RFC 1323が解釈の余地を残したため、TSoptを使用した準拠実装で予想される動作を明確にするために、いくつかの段落が追加されました。
(d) The description of which TSecr values can be used to update the measured RTT has been clarified. Specifically, with timestamps, the Karn algorithm [Karn87] is disabled. The Karn algorithm disables all RTT measurements during retransmission, since it is ambiguous whether the <ACK> is for the original segment, or the retransmitted segment. With timestamps, that ambiguity is removed since the TSecr in the <ACK> will contain the TSval from whichever data segment made it to the destination.
（d）測定されたRTTを更新するために使用できるTSecr値の説明が明確になりました。具体的には、タイムスタンプでは、Karnアルゴリズム[Karn87]が無効になっています。 <ACK>が元のセグメントに対するものか、再送信されたセグメントに対するものかは不明確であるため、Karnアルゴリズムは再送信中にすべてのRTT測定を無効にします。タイムスタンプを使用すると、<ACK>のTSecrに、宛先に到達したデータセグメントからのTSvalが含まれるため、あいまいさが取り除かれます。
(e) RTTM update processing explicitly excludes segments not updating SND.UNA. The original text could be interpreted to allow taking RTT samples when SACK acknowledges some new, non-continuous data.
（e）RTTM更新処理は、SND.UNAを更新しないセグメントを明示的に除外します。元のテキストを解釈して、SACKが新しい非連続データを確認したときにRTTサンプルを取得できるようにすることができます。
(f) In RFC 1323, Section 3.4, step (2) of the algorithm to control which timestamp is echoed was incorrect in two regards:
（f）RFC 1323のセクション3.4で、どのタイムスタンプをエコーするかを制御するアルゴリズムのステップ（2）は、2つの点で正しくありませんでした。
(1) It failed to update TS.Recent for a retransmitted segment that resulted from a lost <ACK>.
（1）<ACK>が失われたために再送信されたセグメントのTS.Recentを更新できませんでした。
(2) It failed if SEG.LEN = 0.
（2）SEG.LEN = 0の場合は失敗しました。
In the new algorithm, the case of SEG.TSval >= TS.Recent is included for consistency with the PAWS test.
新しいアルゴリズムでは、SEG.TSval> = TS.RecentのケースがPAWSテストとの一貫性のために含まれています。
(g) It is now recommended that the Timestamps option is included in <RST> segments if the incoming segment contained a Timestamps option.
（g）着信セグメントにTimestampsオプションが含まれていた場合、Timestampsオプションを<RST>セグメントに含めることをお勧めします。
(h) <RST> segments are explicitly excluded from PAWS processing.
（h）<RST>セグメントは、明示的にPAWS処理から除外されます。
(i) Added text to clarify the precedence between regular TCP [RFC0793] and this document's Timestamps option / PAWS processing. Discussion about combined acceptability checks are ongoing.
（i）通常のTCP [RFC0793]とこのドキュメントのTimestampsオプション/ PAWS処理の間の優先順位を明確にするためにテキストを追加しました。複合許容性チェックについての議論が進行中です。
(j) Snd.TSoffset and Snd.TSclock variables have been added. Snd.TSclock is the sum of my.TSclock and Snd.TSoffset. This allows the starting points for timestamp values to be randomized on a per-connection basis. Setting Snd.TSoffset to zero yields the same results as [RFC1323]. Text was added to guide implementers to the proper selection of these offsets, as entirely random offsets for each new connection will conflict with PAWS.
（j）Snd.TSoffsetおよびSnd.TSclock変数が追加されました。 Snd.TSclockは、my.TSclockとSnd.TSoffsetの合計です。これにより、タイムスタンプ値の開始点を接続ごとにランダム化できます。 Snd.TSoffsetをゼロに設定すると、[RFC1323]と同じ結果になります。新しい接続ごとに完全にランダムなオフセットがPAWSと競合するため、実装者がこれらのオフセットを適切に選択するためのテキストが追加されました。
(k) Appendix A has been expanded with information about the TCP Urgent Pointer. An earlier revision contained text around the TCP MSS option, which was split off into [RFC6691].
（k）付録Aは、TCP緊急ポインターに関する情報で拡張されました。以前のリビジョンには、TCP MSSオプションに関するテキストが含まれていましたが、[RFC6691]に分割されました。
(l) One correction was made to the Event Processing Summary in Appendix D. In SEND CALL/ESTABLISHED STATE, RCV.WND is used to fill in the SEG.WND value, not SND.WND.
（l）付録Dのイベント処理の概要に1つの修正が行われました。SENDCALL / ESTABLISHED STATEでは、RCV.WNDはSND.WNDではなくSEG.WND値の入力に使用されます。
(m) Appendix G was added to exemplify how an RTO calculation might be updated to properly take the much higher RTT sampling frequency enabled by the Timestamps option into account.
（m）タイムスタンプオプションによって有効化されたはるかに高いRTTサンプリング周波数を適切に考慮するためにRTO計算がどのように更新されるかを例示するために、付録Gが追加されました。
Editorial changes to the document, that don't impact the implementation or function of the mechanisms described in this document, include:
このドキュメントで説明されているメカニズムの実装や機能に影響を与えない、ドキュメントに対する編集上の変更には、次のものが含まれます。
(a) Removed much of the discussion in Section 1 to streamline the document. However, detailed examples and discussions in Sections 2, 3, and 5 are kept as guidelines for implementers.
（a）セクション1の議論の大部分を削除して、ドキュメントを簡素化しました。ただし、セクション2、3、および5の詳細な例と説明は、実装者向けのガイドラインとして保持されます。
(b) Added short text that the use of WS increases the chances of sequence number wrap, thus the PAWS mechanism is required in certain environments.
（b）WSを使用するとシーケンス番号が折り返される可能性が高くなるため、特定の環境ではPAWSメカニズムが必要であるという短いテキストを追加しました。
(c) Removed references to "new" options, as the options were introduced in [RFC1323] already. Changed the text in Section 1.3 to specifically address TS and WS options.
（c）オプションは[RFC1323]ですでに導入されているため、「新しい」オプションへの参照を削除しました。セクション1.3のテキストを変更して、特にTSおよびWSオプションに対応しました。
(d) Section 1.4 was added for [RFC2119] wording. Normative text was updated with the appropriate phrases.
（d）セクション1.4は、[RFC2119]表現のために追加されました。規範的なテキストが適切なフレーズで更新されました。
(e) Added < > brackets to mark specific types of segments, and replaced most occurrences of "packet" with "segment", where TCP segments are referred to.
（e）特定のタイプのセグメントをマークするために<>ブラケットを追加し、ほとんどの「packet」を「segment」に置き換えました。TCPセグメントが参照されています。
(f) Updated the text in Section 3 to take into account what has been learned since [RFC1323].
（f）セクション3のテキストを更新して、[RFC1323]以降に学んだことを考慮に入れました。
(g) Removed some unused references.
（g）未使用の参照をいくつか削除しました。
(h) Removed the list of changes between [RFC1323] and prior versions. These changes are mentioned in Appendix C of [RFC1323].
（h）[RFC1323]と以前のバージョンの間の変更のリストを削除しました。これらの変更は、[RFC1323]の付録Cで言及されています。
(i) Moved "Changes from RFC 1323" to the end of the appendices for easier lookup. In addition, the entries were split into a technical and an editorial part, and sorted to roughly correspond with the sections in the text where they apply.
（i）「RFC 1323からの変更点」を付録の最後に移動して、検索を容易にしました。さらに、エントリは技術部分と編集部分に分けられ、適用されるテキストのセクションにほぼ対応するようにソートされました。
Authors' Addresses
著者のアドレス
David Borman Quantum Corporation Mendota Heights, MN 55120 USA
David Borman Quantum Corporation Mendota Heights、MN 55120 USA
EMail: david.borman@quantum.com
Bob Braden University of Southern California 4676 Admiralty Way Marina del Rey, CA 90292 USA
ボブ・ブレーデン南カリフォルニア大学4676アドミラルティ・ウェイマリーナ・デル・レイ、カリフォルニア州90292アメリカ
EMail: braden@isi.edu
Van Jacobson Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
Van Jacobson Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043 USA
EMail: vanj@google.com
Richard Scheffenegger (editor) NetApp, Inc. Am Euro Platz 2 Vienna, 1120 Austria
Richard Scheffenegger（編集者）NetApp、Inc. Am Euro Platz 2ウィーン、1120オーストリア
EMail: rs@netapp.com