[要約] RFC 9040は、TCP制御ブロック間の相互依存性に関する文書です。この文書の目的は、TCP接続の効率と性能を向上させるために、異なるTCP接続間で情報を共有する方法について説明することです。主に、ネットワークの混雑制御や回復メカニズムの改善に利用されます。
Internet Engineering Task Force (IETF) J. Touch
Request for Comments: 9040 Independent
Obsoletes: 2140 M. Welzl
Category: Informational S. Islam
ISSN: 2070-1721 University of Oslo
July 2021
TCP Control Block Interdependence
TCPコントロールブロック相互依存
Abstract
概要
This memo provides guidance to TCP implementers that is intended to help improve connection convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of sharing TCP state, as typically represented in TCP Control Blocks, among similar concurrent or consecutive connections.
このメモは、相互運用性に影響を与えることなく、接続収束を定常状態にするのを助けることを目的としたTCP実装者へのガイダンスを提供します。類似の同時接続または連続した接続のうち、TCP制御ブロックで表現されているように、TCP状態の共有の共有の説明および置換を更新および置き換える。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9040.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9040で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
3. Terminology
4. The TCP Control Block (TCB)
5. TCB Interdependence
6. Temporal Sharing
6.1. Initialization of a New TCB
6.2. Updates to the TCB Cache
6.3. Discussion
7. Ensemble Sharing
7.1. Initialization of a New TCB
7.2. Updates to the TCB Cache
7.3. Discussion
8. Issues with TCB Information Sharing
8.1. Traversing the Same Network Path
8.2. State Dependence
8.3. Problems with Sharing Based on IP Address
9. Implications
9.1. Layering
9.2. Other Possibilities
10. Implementation Observations
11. Changes Compared to RFC 2140
12. Security Considerations
13. IANA Considerations
14. References
14.1. Normative References
14.2. Informative References
Appendix A. TCB Sharing History
Appendix B. TCP Option Sharing and Caching
Appendix C. Automating the Initial Window in TCP over Long
Timescales
C.1. Introduction
C.2. Design Considerations
C.3. Proposed IW Algorithm
C.4. Discussion
C.5. Observations
Acknowledgments
Authors' Addresses
TCP is a connection-oriented reliable transport protocol layered over IP [RFC0793]. Each TCP connection maintains state, usually in a data structure called the "TCP Control Block (TCB)". The TCB contains information about the connection state, its associated local process, and feedback parameters about the connection's transmission properties. As originally specified and usually implemented, most TCB information is maintained on a per-connection basis. Some implementations share certain TCB information across connections to the same host [RFC2140]. Such sharing is intended to lead to better overall transient performance, especially for numerous short-lived and simultaneous connections, as can be used in the World Wide Web and other applications [Be94] [Br02]. This sharing of state is intended to help TCP connections converge to long-term behavior (assuming stable application load, i.e., so-called "steady-state") more quickly without affecting TCP interoperability.
TCPはIP上の接続指向の信頼できるトランスポートプロトコルです[RFC0793]。各TCP接続は、通常、「TCP制御ブロック（TCB）」と呼ばれるデータ構造内に状態を維持します。TCBには、接続状態、関連するローカルプロセス、および接続の送信プロパティに関するフィードバックパラメータに関する情報が含まれています。最初に指定されているように、通常は実装されているように、ほとんどのTCB情報は接続ごとに維持されます。一部の実装は、同じホスト[RFC2140]への接続にわたって特定のTCB情報を共有しています。そのような共有は、世界的なWIDE Webおよび他のアプリケーションで使用できるように、特に多数の短寿命および同時接続のための全体的な過渡性能をもたらすことを意図しています[BE94] [BR02]。この状態の共有は、TCPの相互運用性に影響を与えずに、TCP接続が長期的な動作に収束するのを助けることを目的としています（安定したアプリケーション負荷、すなわち、いわゆる「定常状態」）をより迅速にするのを想定することを目的としています。
This document updates RFC 2140's discussion of TCB state sharing and provides a complete replacement for that document. This state sharing affects only TCB initialization [RFC2140] and thus has no effect on the long-term behavior of TCP after a connection has been established or on interoperability. Path information shared across SYN destination port numbers assumes that TCP segments having the same host-pair experience the same path properties, i.e., that traffic is not routed differently based on port numbers or other connection parameters (also addressed further in Section 8.1). The observations about TCB sharing in this document apply similarly to any protocol with congestion state, including the Stream Control Transmission Protocol (SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP) [RFC4340], as well as to individual subflows in Multipath TCP [RFC8684].
この文書は、RFC 2140のTCB状態共有に関する議論を更新し、その文書の完全な交換を提供します。この状態の共有はTCB初期化のみです[RFC2140]は、接続が確立された後のTCPの長期的な動作に影響を与えないか、相互運用性に影響しません。SYN宛先ポート番号で共有されているパス情報は、同じホストペアを持つTCPセグメントと同じパスプロパティ、すなわちトラフィックがポート番号または他の接続パラメータに基づいて変更されないことを示している（セクション8.1ではさらにアドレス指定されています）。この文書でのTCB共有に関する観測は、ストリーム制御伝送プロトコル（SCTP）[RFC4960]およびデータグラム輻輳制御プロトコル（DCCP）[RFC4340]、ならびにマルチパス内の個々のサブフローを含む輻輳状態と同様に適用されます。TCP [RFC8684]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The core of this document describes behavior that is already permitted by TCP standards. As a result, this document provides informative guidance but does not use normative language except when quoting other documents. Normative language is used in Appendix C as examples of requirements for future consideration.
このドキュメントの中核は、TCP規格によってすでに許可されている動作について説明しています。その結果、この文書は有益なガイダンスを提供しますが、他の文書を引用するときを除いて規範的な言語を使用しません。将来の考慮事項の要件の例としては、規範的な言語が付録Cで使用されています。
The following terminology is used frequently in this document. Items preceded with a "+" may be part of the state maintained as TCP connection state in the TCB of associated connections and are the focus of sharing as described in this document. Note that terms are used as originally introduced where possible; in some cases, direction is indicated with a suffix (_S for send, _R for receive) and in other cases spelled out (sendcwnd).
この文書では、次の用語が頻繁に使用されます。「」という先行する項目は、関連する接続のTCBのTCP接続状態として維持されている状態の一部であり得、この文書に記載されているように共有の焦点である。可能であれば、もともと紹介されたものとして使用されます。場合によっては、方向は接尾辞（SEND、受信用_R）で表示され、その他の場合（SendCWND）が表示されます。
+cwnd: TCP congestion window size [RFC5681]
CWND：TCP輻輳ウィンドウサイズ[RFC5681]
host: a source or sink of TCP segments associated with a single IP address
ホスト：単一のIPアドレスに関連付けられているTCPセグメントのソースまたはシンク
host-pair: a pair of hosts and their corresponding IP addresses
ホストペア：ホストのペアとそれに対応するIPアドレス
ISN: Initial Sequence Number
ISN：初期シーケンス番号
+MMS_R: maximum message size that can be received, the largest received transport payload of an IP datagram [RFC1122]
MMS_R：受信可能な最大メッセージサイズ、IPデータグラムの最大受信トランスポートペイロード[RFC1122]
+MMS_S: maximum message size that can be sent, the largest transmitted transport payload of an IP datagram [RFC1122]
MMS_S：IPデータグラムの最大の送信転送ペイロード[RFC1122]の最大送信転送サイズ
path: an Internet path between the IP addresses of two hosts
パス：2つのホストのIPアドレス間のインターネットパス
PCB: protocol control block, the data associated with a protocol as maintained by an endpoint; a TCP PCB is called a "TCB"
PCB：プロトコル制御ブロック、エンドポイントによって維持されるようなプロトコルに関連するデータ。TCP PCBを「TCB」と呼ばれます。
PLPMTUD: packetization-layer path MTU discovery, a mechanism that uses transport packets to discover the Path Maximum Transmission Unit (PMTU) [RFC4821]
PLPMTUD：パケット化層のパスMTUディスカバリ、トランスポートパケットを使用してパス最大伝送ユニット（PMTU）を発見するメカニズム[RFC4821]
+PMTU: largest IP datagram that can traverse a path [RFC1191] [RFC8201]
PMTU：パスを通過できる最大のIPデータグラム[RFC1191] [RFC8201]
PMTUD: path-layer MTU discovery, a mechanism that relies on ICMP error messages to discover the PMTU [RFC1191] [RFC8201]
PMTUD：PATUのエラーメッセージに依存してPMTU [RFC1191] [RFC8201]を検出するメカニズム
+RTT: round-trip time of a TCP packet exchange [RFC0793]
RTT：TCPパケット交換の往復時間[RFC0793]
+RTTVAR: variation of round-trip times of a TCP packet exchange [RFC6298]
RTTVAR：TCPパケット交換の往復回数の変動[RFC6298]
+rwnd: TCP receive window size [RFC5681]
RWND：TCP受信ウィンドウサイズ[RFC5681]
+sendcwnd: TCP send-side congestion window (cwnd) size [RFC5681]
SENDCWND：TCP送信側輻輳ウィンドウ（CWND）サイズ[RFC5681]
+sendMSS: TCP maximum segment size, a value transmitted in a TCP option that represents the largest TCP user data payload that can be received [RFC6691]
SENDMSS：TCP最大セグメントサイズ、受信可能な最大のTCPユーザーデータペイロードを表すTCPオプションで送信された値[RFC6691]
+ssthresh: TCP slow-start threshold [RFC5681]
SSTHRESH：TCPスロースタートしきい値[RFC5681]
TCB: TCP Control Block, the data associated with a TCP connection as maintained by an endpoint
TCB：TCP制御ブロック、エンドポイントによって維持されるようにTCP接続に関連付けられたデータ
TCP-AO: TCP Authentication Option [RFC5925]
TCP-AO：TCP認証オプション[RFC5925]
TFO: TCP Fast Open option [RFC7413]
TFO：TCPファストオープンオプション[RFC7413]
+TFO_cookie: TCP Fast Open cookie, state that is used as part of the TFO mechanism, when TFO is supported [RFC7413]
TFO_COOKIE：TFOがサポートされている場合、TFOメカニズムの一部として使用される状態、TCPファストオープンクッキー、State [RFC7413]
+TFO_failure: an indication of when TFO option negotiation failed, when TFO is supported
TFO_FAILURE：TFOがサポートされている場合、TFOオプションネゴシエーションが失敗したときの表示
+TFOinfo: information cached when a TFO connection is established, which includes the TFO_cookie [RFC7413]
TFOINFO：TFO接続が確立されたときにキャッシュされ、TFO_COOKIE [RFC7413]
A TCB describes the data associated with each connection, i.e., with each association of a pair of applications across the network. The TCB contains at least the following information [RFC0793]:
TCBは、各接続に関連付けられたデータ、すなわちネットワーク全体のアプリケーションの各対応付けに関連するデータを記述する。TCBには少なくとも次の情報が含まれています[RFC0793]：
Local process state
ローカルプロセスの状態
pointers to send and receive buffers pointers to retransmission queue and current segment pointers to Internet Protocol (IP) PCB
再送キューと現在のセグメントポインタへのバッファーポインタとインターネットプロトコル（IP）PCBへのポインタを送受信するためのポインタ
Per-connection shared state
接続ごとの共有状態
macro-state
connection state
timers
flags
local and remote host numbers and ports
TCP option state
micro-state
send and receive window state (size*, current number)
congestion window size (sendcwnd)*
congestion window size threshold (ssthresh)*
max window size seen*
sendMSS#
MMS_S#
MMS_R#
PMTU#
round-trip time and its variation#
The per-connection information is shown as split into macro-state and micro-state, terminology borrowed from [Co91]. Macro-state describes the protocol for establishing the initial shared state about the connection; we include the endpoint numbers and components (timers, flags) required upon commencement that are later used to help maintain that state. Micro-state describes the protocol after a connection has been established, to maintain the reliability and congestion control of the data transferred in the connection.
接続ごとの情報は、[CO91]から借りた用語のマクロ状態とマイクロ状態に分割されて表示されています。マクロ状態は、接続に関する初期共有状態を確立するためのプロトコルを記述します。その状態を維持するために後で使用される開始時に必要なエンドポイント番号とコンポーネント（タイマー、フラグ）を含みます。マイクロステートは、接続に転送されたデータの信頼性と輻輳制御を維持するために、接続が確立された後のプロトコルを表します。
We distinguish two other classes of shared micro-state that are associated more with host-pairs than with application pairs. One class is clearly host-pair dependent (shown above as "#", e.g., sendMSS, MMS_R, MMS_S, PMTU, RTT), because these parameters are defined by the endpoint or endpoint pair (of the given example: sendMSS, MMS_R, MMS_S, RTT) or are already cached and shared on that basis (of the given example: PMTU [RFC1191] [RFC4821]). The other is host-pair dependent in its aggregate (shown above as "*", e.g., congestion window information, current window sizes, etc.) because they depend on the total capacity between the two endpoints.
私たちは、アプリケーションペアよりもホストペアで関連する他の2つのクラスの共有マイクロステートを区別します。1つのクラスは明らかにホストペアに依存しています（上記のように、 "＃"、例えばSendms、MMS_R、MMS_S、PMTU、RTT）。MMS_S、RTT）または既にキャッシュされており（与えられた例の）。（PMTU [RFC1191] [RFC4821]）。もう1つは、ホストペアがその集合体に依存しています（上記の場合は「*」、輻輳ウィンドウ情報、現在のウィンドウサイズなど）、2つのエンドポイント間の総容量に依存するためです。
Not all of the TCB state is necessarily shareable. In particular, some TCP options are negotiated only upon request by the application layer, so their use may not be correlated across connections. Other options negotiate connection-specific parameters, which are similarly not shareable. These are discussed further in Appendix B.
TCB状態のすべてが必ずしも共有可能ではありません。特に、いくつかのTCPオプションはアプリケーション層による要求に応じてのみ交渉されるため、接続間で相関していない可能性があります。その他のオプションは接続固有のパラメータをネゴシエートします。これは同様に共有できません。これらは付録Bでさらに議論されています。
Finally, we exclude rwnd from further discussion because its value should depend on the send window size, so it is already addressed by send window sharing and is not independently affected by sharing.
最後に、その値がウィンドウサイズのサイズに依存する必要があるため、RWNDをさらなるディスカッションから除外しているため、送信ウィンドウの共有によってすでに対処されており、共有の影響を受けることは独立していません。
There are two cases of TCB interdependence. Temporal sharing occurs when the TCB of an earlier (now CLOSED) connection to a host is used to initialize some parameters of a new connection to that same host, i.e., in sequence. Ensemble sharing occurs when a currently active connection to a host is used to initialize another (concurrent) connection to that host.
TCB相互依存の2つのケースがあります。時間的な共有は、Hostへの旧正常な接続のTCBを使用して、同じホストへの新しい接続のいくつかのパラメータ、すなわちシーケンスを初期化するときに発生します。Hostへの現在アクティブな接続を使用してそのホストへの別の（同時）接続を初期化するために使用されると、Ensemble Sharingが発生します。
The TCB data cache is accessed in two ways: it is read to initialize new TCBs and written when more current per-host state is available.
TCBデータキャッシュは2つの方法でアクセスされます。新しいTCBを初期化して、ホストごとのステートごとのより多くの電流が発生したときに書き込まれます。
TCBs for new connections can be initialized using cached context from past connections as follows:
新しい接続のためのTCBは、次のように過去の接続からキャッシュされたコンテキストを使用して初期化できます。
+==============+=============================+
| Cached TCB | New TCB |
+==============+=============================+
| old_MMS_S | old_MMS_S or not cached (2) |
+--------------+-----------------------------+
| old_MMS_R | old_MMS_R or not cached (2) |
+--------------+-----------------------------+
| old_sendMSS | old_sendMSS |
+--------------+-----------------------------+
| old_PMTU | old_PMTU (1) |
+--------------+-----------------------------+
| old_RTT | old_RTT |
+--------------+-----------------------------+
| old_RTTVAR | old_RTTVAR |
+--------------+-----------------------------+
| old_option | (option specific) |
+--------------+-----------------------------+
| old_ssthresh | old_ssthresh |
+--------------+-----------------------------+
| old_sendcwnd | old_sendcwnd |
+--------------+-----------------------------+
Table 1: Temporal Sharing - TCB Initialization
表1：時間的共有 - TCB初期化
(1) Note that PMTU is cached at the IP layer [RFC1191] [RFC4821].
(1) なお、PMTUはIP層[RFC1191] [RFC4821]にキャッシュされています。
(2) Note that some values are not cached when they are computed locally (MMS_R) or indicated in the connection itself (MMS_S in the SYN).
(2) いくつかの値は、ローカル（MMS_R）を計算するか、接続自体（SYN内のMMS_S）に表示されている場合には、一部の値がキャッシュされません。
Table 2 gives an overview of option-specific information that can be shared. Additional information on some specific TCP options and sharing is provided in Appendix B.
表2に、共有できるオプション固有の情報の概要を示します。特定のTCPオプションと共有に関する追加情報は、付録Bに記載されています。
+=================+=================+
| Cached | New |
+=================+=================+
| old_TFO_cookie | old_TFO_cookie |
+-----------------+-----------------+
| old_TFO_failure | old_TFO_failure |
+-----------------+-----------------+
Table 2: Temporal Sharing - Option Info Initialization
表2：一時的な共有 - オプション情報初期化
During a connection, the TCB cache can be updated based on events of current connections and their TCBs as they progress over time, as shown in Table 3.
接続中に、TCBキャッシュは、表3に示すように、現在の接続のイベントとそれらのTCBSに基づいて更新できます。
+==============+===============+=============+=================+
| Cached TCB | Current TCB | When? | New Cached TCB |
+==============+===============+=============+=================+
| old_MMS_S | curr_MMS_S | OPEN | curr_MMS_S |
+--------------+---------------+-------------+-----------------+
| old_MMS_R | curr_MMS_R | OPEN | curr_MMS_R |
+--------------+---------------+-------------+-----------------+
| old_sendMSS | curr_sendMSS | MSSopt | curr_sendMSS |
+--------------+---------------+-------------+-----------------+
| old_PMTU | curr_PMTU | PMTUD (1) / | curr_PMTU |
| | | PLPMTUD (1) | |
+--------------+---------------+-------------+-----------------+
| old_RTT | curr_RTT | CLOSE | merge(curr,old) |
+--------------+---------------+-------------+-----------------+
| old_RTTVAR | curr_RTTVAR | CLOSE | merge(curr,old) |
+--------------+---------------+-------------+-----------------+
| old_option | curr_option | ESTAB | (depends on |
| | | | option) |
+--------------+---------------+-------------+-----------------+
| old_ssthresh | curr_ssthresh | CLOSE | merge(curr,old) |
+--------------+---------------+-------------+-----------------+
| old_sendcwnd | curr_sendcwnd | CLOSE | merge(curr,old) |
+--------------+---------------+-------------+-----------------+
Table 3: Temporal Sharing - Cache Updates
表3：時間的な共有 - キャッシュアップデート
(1) Note that PMTU is cached at the IP layer [RFC1191] [RFC4821].
(1) なお、PMTUはIP層[RFC1191] [RFC4821]にキャッシュされています。
Merge() is the function that combines the current and previous (old)
values and may vary for each parameter of the TCB cache. The
particular function is not specified in this document; examples
include windowed averages (mean of the past N values, for some N) and
exponential decay (new = (1-alpha)*old + alpha *new, where alpha is
in the range [0..1]).
Table 4 gives an overview of option-specific information that can be similarly shared. The TFO cookie is maintained until the client explicitly requests it be updated as a separate event.
表4に同様に共有できるオプション固有の情報の概要を表4に示します。TFO Cookieは、クライアントが明示的にそれが個別のイベントとして更新されるまで維持されます。
+=================+=================+=======+=================+
| Cached | Current | When? | New Cached |
+=================+=================+=======+=================+
| old_TFO_cookie | old_TFO_cookie | ESTAB | old_TFO_cookie |
+-----------------+-----------------+-------+-----------------+
| old_TFO_failure | old_TFO_failure | ESTAB | old_TFO_failure |
+-----------------+-----------------+-------+-----------------+
Table 4: Temporal Sharing - Option Info Updates
表4：一時的な共有 - オプション情報アップデート
As noted, there is no particular benefit to caching MMS_S and MMS_R as these are reported by the local IP stack. Caching sendMSS and PMTU is trivial; reported values are cached (PMTU at the IP layer), and the most recent values are used. The cache is updated when the MSS option is received in a SYN or after PMTUD (i.e., when an ICMPv4 Fragmentation Needed [RFC1191] or ICMPv6 Packet Too Big message is received [RFC8201] or the equivalent is inferred, e.g., as from PLPMTUD [RFC4821]), respectively, so the cache always has the most recent values from any connection. For sendMSS, the cache is consulted only at connection establishment and not otherwise updated, which means that MSS options do not affect current connections. The default sendMSS is never saved; only reported MSS values update the cache, so an explicit override is required to reduce the sendMSS. Cached sendMSS affects only data sent in the SYN segment, i.e., during client connection initiation or during simultaneous open; the MSS of all other segments are constrained by the value updated as included in the SYN.
述べたように、これらはローカルIPスタックによって報告されるように、MMS_SとMMS_Rをキャッシュすることに特に利点はありません。 Caching SendmsとPMTUは簡単です。報告された値がキャッシュされ（IP層のPMTU）、最新の値が使用されます。 MSSオプションがSYNまたはPMTUDで受信されたとき（すなわち、[RFC1191]またはICMPv6パケットが必要な場合には、例えばPLPMTUDからのICMPv4フラグメンテーションが必要な場合は[RFC8201]、または同等のICMPv6パケットが受信された場合、または同等のICMPV6パケットが受信されたとき、または同等のICMPV6パケットが受信されたとき、そのため、それぞれRFC4821]）、キャッシュは常に任意の接続から最新の値を持ちます。 SENDMSの場合、キャッシュは接続確立時にのみ相談され、他に更新されていません。つまり、MSSオプションは現在の接続に影響しません。デフォルトのSendmsは保存されません。報告されたMSS値のみがキャッシュを更新するだけなので、SENDMSを縮小するために明示的なオーバーライドが必要です。キャッシュされたSENDMSは、SYNセグメント、すなわちクライアント接続開始中または同時OPENの間に送信されたデータのみに影響を与える。他のすべてのセグメントのMSは、SYNに含まれているように更新された値によって制約されています。
RTT values are updated by formulae that merge the old and new values, as noted in Section 6.2. Dynamic RTT estimation requires a sequence of RTT measurements. As a result, the cached RTT (and its variation) is an average of its previous value with the contents of the currently active TCB for that host, when a TCB is closed. RTT values are updated only when a connection is closed. The method for merging old and current values needs to attempt to reduce the transient effects of the new connections.
RTT値は、セクション6.2に記載されているように、古い値と新しい値をマージする式によって更新されます。動的RTT推定には、一連のRTT測定が必要です。その結果、キャッシュされたRTT（およびその変化）は、TCBが閉じられたときに、そのホストの現在アクティブなTCBの内容を持つ、その前の値の平均です。RTT値は、接続が閉じられたときにのみ更新されます。古い値と現在の値をマージする方法は、新しい接続の一時的な影響を減らすことを試みる必要があります。
The updates for RTT, RTTVAR, and ssthresh rely on existing information, i.e., old values. Should no such values exist, the current values are cached instead.
RTT、RTTVAR、およびSSTHRESHの更新は、既存の情報、すなわち古い値に依存しています。そのような値が存在しない場合は、現在の値は代わりにキャッシュされます。
TCP options are copied or merged depending on the details of each option. For example, TFO state is updated when a connection is established and read before establishing a new connection.
TCPオプションは、各オプションの詳細に応じてコピーまたはマージされます。たとえば、新しい接続を確立する前に、接続が確立されて読み取られたときにTFO状態が更新されます。
Sections 8 and 9 discuss compatibility issues and implications of sharing the specific information listed above. Section 10 gives an overview of known implementations.
セクション8および9は、互換性の問題を説明し、上記の特定の情報を共有することの意味を説明します。セクション10は既知の実装の概要を説明する。
Most cached TCB values are updated when a connection closes. The exceptions are MMS_R and MMS_S, which are reported by IP [RFC1122]; PMTU, which is updated after Path MTU Discovery and also reported by IP [RFC1191] [RFC4821] [RFC8201]; and sendMSS, which is updated if the MSS option is received in the TCP SYN header.
接続が閉じると、ほとんどのキャッシュされたTCB値が更新されます。例外は、IP [RFC1122]によって報告されているMMS_RおよびMMS_Sです。PMTUは、PATH MTUディスカバリーの後に更新され、IP [RFC1191] [RFC4821] [RFC8201]で報告されます。MSSオプションがTCP SYNヘッダーで受信された場合に更新されるSENDMSS。
Sharing sendMSS information affects only data in the SYN of the next connection, because sendMSS information is typically included in most TCP SYN segments. Caching PMTU can accelerate the efficiency of PMTUD but can also result in black-holing until corrected if in error. Caching MMS_R and MMS_S may be of little direct value as they are reported by the local IP stack anyway.
SENDMSS情報は、Sendms情報がほとんどのTCP SYNセグメントに含まれるため、SendMSS情報のシェア情報は次の接続のSYN内のデータのみに影響します。Caching PMTUはPMTUDの効率を高速化することができますが、誤って誤って修正されるまでブラックホールをもたらします。MMS_RとMMS_Sのキャッシングは、とにかくローカルIPスタックによって報告されているため、直接値がほとんどない場合があります。
The way in which state related to other TCP options can be shared depends on the details of that option. For example, TFO state includes the TCP Fast Open cookie [RFC7413] or, in case TFO fails, a negative TCP Fast Open response. RFC 7413 states,
他のTCPオプションに関連する状態を共有できる方法は、そのオプションの詳細によって異なります。たとえば、TFO状態にはTCP Fast Open Cookie [RFC7413]が含まれているか、またはTFOが失敗した場合は、負のTCPの高速オープンレスポンスを含みます。RFC 7413、
| The client MUST cache negative responses from the server in order
| to avoid potential connection failures. Negative responses
| include the server not acknowledging the data in the SYN, ICMP
| error messages, and (most importantly) no response (SYN-ACK) from
| the server at all, i.e., connection timeout.
TFOinfo is cached when a connection is established.
接続が確立されたときにTFOINFOがキャッシュされます。
State related to other TCP options might not be as readily cached. For example, TCP-AO [RFC5925] success or failure between a host-pair for a single SYN destination port might be usefully cached. TCP-AO success or failure to other SYN destination ports on that host-pair is never useful to cache because TCP-AO security parameters can vary per service.
他のTCPオプションに関連する州は、容易にキャッシュされていない可能性があります。たとえば、TCP-AO [RFC5925]単一のSYN宛先ポートのホストペア間の成功または障害が有効にキャッシュされる可能性があります。TCP-AOセキュリティパラメータがサービスごとに異なる可能性があるため、TCP-AOそのホストペアの他のSYN宛先ポートの成功または失敗はキャッシュするのに役立ちません。
Sharing cached TCB data across concurrent connections requires attention to the aggregate nature of some of the shared state. For example, although MSS and RTT values can be shared by copying, it may not be appropriate to simply copy congestion window or ssthresh information; instead, the new values can be a function (f) of the cumulative values and the number of connections (N).
キャッシュされたTCBデータを同時接続にわたって共有するには、一部の共有状態の集計性に注意が必要です。たとえば、MSSとRTTの値はコピーによって共有できますが、単に輻輳ウィンドウやSSTHRESH情報を簡単にコピーするのに適していない可能性があります。代わりに、新しい値は累積値と接続数（n）の関数（f）にすることができます。
TCBs for new connections can be initialized using cached context from concurrent connections as follows:
新しい接続のためのTCBは、次のように同時接続からキャッシュされたコンテキストを使用して初期化できます。
+===================+=========================+
| Cached TCB | New TCB |
+===================+=========================+
| old_MMS_S | old_MMS_S |
+-------------------+-------------------------+
| old_MMS_R | old_MMS_R |
+-------------------+-------------------------+
| old_sendMSS | old_sendMSS |
+-------------------+-------------------------+
| old_PMTU | old_PMTU (1) |
+-------------------+-------------------------+
| old_RTT | old_RTT |
+-------------------+-------------------------+
| old_RTTVAR | old_RTTVAR |
+-------------------+-------------------------+
| sum(old_ssthresh) | f(sum(old_ssthresh), N) |
+-------------------+-------------------------+
| sum(old_sendcwnd) | f(sum(old_sendcwnd), N) |
+-------------------+-------------------------+
| old_option | (option specific) |
+-------------------+-------------------------+
Table 5: Ensemble Sharing - TCB Initialization
表5：Ensemble Sharing - TCB初期化
(1) Note that PMTU is cached at the IP layer [RFC1191] [RFC4821].
(1) なお、PMTUはIP層[RFC1191] [RFC4821]にキャッシュされています。
In Table 5, the cached sum() is a total across all active connections because these parameters act in aggregate; similarly, f() is a function that updates that sum based on the new connection's values, represented as "N".
表5では、キャッシュされたSUM（）はすべてのアクティブ接続にわたって合計であり、これらのパラメータは集約にあります。同様に、f（）は、 "n"として表される新しい接続の値に基づいてその合計を更新する関数です。
Table 6 gives an overview of option-specific information that can be similarly shared. Again, the TFO_cookie is updated upon explicit client request, which is a separate event.
表6は、同様に共有できるオプション固有の情報の概要を示しています。繰り返しますが、TFO_COOKIEは明示的なクライアント要求で更新されます。これは別のイベントです。
+=================+=================+
| Cached | New |
+=================+=================+
| old_TFO_cookie | old_TFO_cookie |
+-----------------+-----------------+
| old_TFO_failure | old_TFO_failure |
+-----------------+-----------------+
Table 6: Ensemble Sharing - Option Info Initialization
表6：Ensemble Sharing - オプション情報初期化
During a connection, the TCB cache can be updated based on changes to concurrent connections and their TCBs, as shown below:
接続中に、TCBキャッシュは、以下のように、同時接続とそのTCBへの変更に基づいて更新できます。
+==============+===============+===========+=================+
| Cached TCB | Current TCB | When? | New Cached TCB |
+==============+===============+===========+=================+
| old_MMS_S | curr_MMS_S | OPEN | curr_MMS_S |
+--------------+---------------+-----------+-----------------+
| old_MMS_R | curr_MMS_R | OPEN | curr_MMS_R |
+--------------+---------------+-----------+-----------------+
| old_sendMSS | curr_sendMSS | MSSopt | curr_sendMSS |
+--------------+---------------+-----------+-----------------+
| old_PMTU | curr_PMTU | PMTUD+ / | curr_PMTU |
| | | PLPMTUD+ | |
+--------------+---------------+-----------+-----------------+
| old_RTT | curr_RTT | update | rtt_update(old, |
| | | | curr) |
+--------------+---------------+-----------+-----------------+
| old_RTTVAR | curr_RTTVAR | update | rtt_update(old, |
| | | | curr) |
+--------------+---------------+-----------+-----------------+
| old_ssthresh | curr_ssthresh | update | adjust sum as |
| | | | appropriate |
+--------------+---------------+-----------+-----------------+
| old_sendcwnd | curr_sendcwnd | update | adjust sum as |
| | | | appropriate |
+--------------+---------------+-----------+-----------------+
| old_option | curr_option | (depends) | (option |
| | | | specific) |
+--------------+---------------+-----------+-----------------+
Table 7: Ensemble Sharing - Cache Updates
表7：Ensemble Sharing - キャッシュアップデート
+ Note that the PMTU is cached at the IP layer [RFC1191] [RFC4821].
+ なお、PMTUはIP層[RFC1191] [RFC4821]にキャッシュされていることに注意してください。
In Table 7, rtt_update() is the function used to combine old and current values, e.g., as a windowed average or exponentially decayed average.
表7では、RTT_UPDATE（）は、古い値と現在の値を組み合わせるために使用される関数、例えば、ウィンドウ付き平均または指数関数的に衰弱した平均です。
Table 8 gives an overview of option-specific information that can be similarly shared.
表8に、同様に共有できるオプション固有の情報の概要を示します。
+=================+=================+=======+=================+
| Cached | Current | When? | New Cached |
+=================+=================+=======+=================+
| old_TFO_cookie | old_TFO_cookie | ESTAB | old_TFO_cookie |
+-----------------+-----------------+-------+-----------------+
| old_TFO_failure | old_TFO_failure | ESTAB | old_TFO_failure |
+-----------------+-----------------+-------+-----------------+
Table 8: Ensemble Sharing - Option Info Updates
表8：Ensemble Sharing - オプション情報アップデート
For ensemble sharing, TCB information should be cached as early as possible, sometimes before a connection is closed. Otherwise, opening multiple concurrent connections may not result in TCB data sharing if no connection closes before others open. The amount of work involved in updating the aggregate average should be minimized, but the resulting value should be equivalent to having all values measured within a single connection. The function "rtt_update" in Table 7 indicates this operation, which occurs whenever the RTT would have been updated in the individual TCP connection. As a result, the cache contains the shared RTT variables, which no longer need to reside in the TCB.
アンサンブル共有の場合、TCB情報はできるだけ早くキャッシュされるべきであり、時には接続が閉じる前に。それ以外の場合は、複数の同時接続を開くと、接続が開いても接続がなくなると、TCBデータの共有が発生しない場合があります。集約平均の更新に関わる作業の量は最小限に抑える必要がありますが、結果の値は単一の接続内で測定されたすべての値を持つことと同じです。表7の関数 "RTT_UPDATE"はこの操作を示し、これはRTTが個々のTCP接続で更新されたときに発生します。その結果、キャッシュには共有RTT変数が含まれています。これはTCBに存在する必要はもうありません。
Congestion window size and ssthresh aggregation are more complicated in the concurrent case. When there is an ensemble of connections, we need to decide how that ensemble would have shared these variables, in order to derive initial values for new TCBs.
輻輳ウィンドウサイズとSSTHRESH集約は、並行例ではより複雑です。接続のアンサンブルがある場合は、新しいTCBの初期値を導き出すために、アンサンブルがこれらの変数を共有していることを決定する必要があります。
Sections 8 and 9 discuss compatibility issues and implications of sharing the specific information listed above.
セクション8および9は、互換性の問題を説明し、上記の特定の情報を共有することの意味を説明します。
There are several ways to initialize the congestion window in a new TCB among an ensemble of current connections to a host. Current TCP implementations initialize it to 4 segments as standard [RFC3390] and 10 segments experimentally [RFC6928]. These approaches assume that new connections should behave as conservatively as possible. The algorithm described in [Ba12] adjusts the initial cwnd depending on the cwnd values of ongoing connections. It is also possible to use sharing mechanisms over long timescales to adapt TCP's initial window automatically, as described further in Appendix C.
ホストへの現在の接続のアンサンブルの中で新しいTCBの輻輳ウィンドウを初期化する方法はいくつかあります。現在のTCP実装は、標準[RFC3390]および10セグメントとして4セグメントに初期化します[RFC6928]。これらのアプローチは、新しい接続が可能な限り控えめに動作するべきであると仮定します。[BA12]に記載されているアルゴリズムは、進行中の接続のCWND値に応じて初期CWNDを調整します。また、付録Cで説明されているように、TCPの初期ウィンドウを自動的に適応させるために、長いタイムスケールにわたって共有メカニズムを使用することも可能です。
Here, we discuss various types of problems that may arise with TCB information sharing.
ここでは、TCB情報共有で発生する可能性があるさまざまな種類の問題について説明します。
For the congestion and current window information, the initial values computed by TCB interdependence may not be consistent with the long-term aggregate behavior of a set of concurrent connections between the same endpoints. Under conventional TCP congestion control, if the congestion window of a single existing connection has converged to 40 segments, two newly joining concurrent connections will assume initial windows of 10 segments [RFC6928] and the existing connection's window will not decrease to accommodate this additional load. As a consequence, the three connections can mutually interfere. One example of this is seen on low-bandwidth, high-delay links, where concurrent connections supporting Web traffic can collide because their initial windows were too large, even when set at 1 segment.
輻輳および現在のウィンドウ情報の場合、TCB相互依存によって計算された初期値は、同じエンドポイント間の同時接続のセットの長期集計動作と一致しない可能性があります。従来のTCP輻輳制御の下で、単一の既存の接続の輻輳ウィンドウが40のセグメントに収束した場合、2つの新たに結合された同時接続は10セグメントの初期ウィンドウを上げます[RFC6928]と既存の接続のウィンドウはこの追加負荷に対応するために減少しないでしょう。結果として、3つの接続は相互に干渉することができます。この一例は、低帯域幅、高遅延リンクで見られます。ここで、1セグメントに設定しても、Webトラフィックをサポートする同時接続は衝突できます。
The authors of [Hu12] recommend caching ssthresh for temporal sharing only when flows are long. Some studies suggest that sharing ssthresh between short flows can deteriorate the performance of individual connections [Hu12] [Du16], although this may benefit aggregate network performance.
[HU12]の著者は、フローが長い場合にのみ時間的共有のためにSSTHRESHをキャッシュすることをお勧めします。いくつかの研究は、短い流れの間のSSTHRESHを共有することが個々の接続の性能を低下させることができるが、これは統合ネットワーク性能に利益をもたらす可能性がある。
TCP is sometimes used in situations where packets of the same host-pair do not always take the same path, such as when connection-specific parameters are used for routing (e.g., for load balancing). Multipath routing that relies on examining transport headers, such as ECMP and Link Aggregation Group (LAG) [RFC7424], may not result in repeatable path selection when TCP segments are encapsulated, encrypted, or altered -- for example, in some Virtual Private Network (VPN) tunnels that rely on proprietary encapsulation. Similarly, such approaches cannot operate deterministically when the TCP header is encrypted, e.g., when using IPsec Encapsulating Security Payload (ESP) (although TCB interdependence among the entire set sharing the same endpoint IP addresses should work without problems when the TCP header is encrypted). Measures to increase the probability that connections use the same path could be applied; for example, the connections could be given the same IPv6 flow label [RFC6437]. TCB interdependence can also be extended to sets of host IP address pairs that share the same network path conditions, such as when a group of addresses is on the same LAN (see Section 9).
TCPは、接続固有のパラメータがルーティングに使用されるとき（例えば、ロードバランシングのために）同じホストペアのパケットが必ずしも同じパスを取り込むわけではありません。 ECMPおよびLink Aggregation Group（LAG）[RFC7424]などのトランスポートヘッダーの検証に依存するマルチパスルーティングは、TCPセグメントがカプセル化、暗号化、または変更されたときの再現可能なパス選択をもたらすことができます。たとえば、いくつかの仮想プライベートネットワークでは独自のカプセル化に依存する（VPN）トンネル。同様に、そのようなアプローチは、例えば、TCPヘッダを暗号化したときに、例えばセキュリティペイロード（ESP）を使用する場合には、TCPヘッダが暗号化されている場合には決定的に動作することはできません（TCPヘッダーが暗号化されているときに同じエンドポイントIPアドレス全体のTCB相互依存は問題なく動作する必要があります） 。接続が同じ経路を使用する可能性を高めるための対策を適用することができます。たとえば、接続に同じIPv6フローラベル[RFC6437]が与えられます。 TCB相互依存関係は、アドレスのグループが同じLAN上にあるときなど、同じネットワークパス条件を共有するホストIPアドレスペアのセットに拡張することもできます（セクション9を参照）。
Traversing the same path is not important for host-specific information (e.g., rwnd), TCP option state (e.g., TFOinfo), or for information that is already cached per-host (e.g., path MTU). When TCB information is shared across different SYN destination ports, path-related information can be incorrect; however, the impact of this error is potentially diminished if (as discussed here) TCB sharing affects only the transient event of a connection start or if TCB information is shared only within connections to the same SYN destination port.
同じ経路を通過することは、ホスト固有の情報（例えば、RWND）、TCPオプションの状態（例えば、TFOInfo）、またはすでにホストごとにキャッシュされている情報（例えば、経路MTU）にとって重要ではない。TCB情報が異なるSYN宛先ポート間で共有されると、パス関連の情報が正しくありません。ただし、このエラーの影響は（ここで説明しているように）TCB共有が接続開始の一時的なイベントのみに影響を与える場合、またはTCB情報が同じSYN宛先ポートへの接続内でのみ共有されている場合に潜在的に減少します。
In the case of temporal sharing, TCB information could also become invalid over time, i.e., indicating that although the path remains the same, path properties have changed. Because this is similar to the case when a connection becomes idle, mechanisms that address idle TCP connections (e.g., [RFC7661]) could also be applied to TCB cache management, especially when TCP Fast Open is used [RFC7413].
時間的共有の場合、TCB情報は時間の経過とともに無効になる可能性があり、すなわち経路は同じままであるが、経路特性が変更されたことを示す。これは、接続がアイドル状態になる場合と似ているので、特にTCP Fast Openが使用されている場合は、IDLE TCP接続をアドレス指定するメカニズム（例えば、[RFC7661]）をTCBキャッシュ管理に適用することもできます[RFC7413]。
There may be additional considerations to the way in which TCB interdependence rebalances congestion feedback among the current connections. For example, it may be appropriate to consider the impact of a connection being in Fast Recovery [RFC5681] or some other similar unusual feedback state that could inhibit or affect the calculations described herein.
現在の接続の間のTCB相互依存関係の輻輳のフィードバックがどのような輻輳のフィードバックを再バックするかに追加の考慮事項があるかもしれません。例えば、本明細書に記載の計算に阻害または影響を及ぼし得る、迅速な回復[RFC5681]または他の同様の異常なフィードバック状態であることの影響を考慮することが適切であり得る。
It can be wrong to share TCB information between TCP connections on the same host as identified by the IP address if an IP address is assigned to a new host (e.g., IP address spinning, as is used by ISPs to inhibit running servers). It can be wrong if Network Address Translation (NAT) [RFC2663], Network Address and Port Translation (NAPT) [RFC2663], or any other IP sharing mechanism is used. Such mechanisms are less likely to be used with IPv6. Other methods to identify a host could also be considered to make correct TCB sharing more likely. Moreover, some TCB information is about dominant path properties rather than the specific host. IP addresses may differ, yet the relevant part of the path may be the same.
IPアドレスが新しいホストに割り当てられている場合と同じホスト上のTCP接続間でTCB情報を共有するのは間違っている可能性があります（例えば、ISPSで使用されるように、実行中のサーバーを禁止するように）。ネットワークアドレス変換（NAT）[RFC2663]、ネットワークアドレス、ポート変換（NAPT）[RFC2663]、またはその他のIP共有メカニズムが使用されている場合は間違っている可能性があります。そのようなメカニズムはIPv6と共に使用される可能性が低いです。ホストを識別するための他の方法は、正しいTCB共有をより可能性が高いと考えることもできます。さらに、いくつかのTCB情報は、特定のホストではなく支配的なパスプロパティに関するものです。IPアドレスは異なる場合がありますが、パスの関連部分は同じです。
There are several implications to incorporating TCB interdependence in TCP implementations. First, it may reduce the need for application-layer multiplexing for performance enhancement [RFC7231]. Protocols like HTTP/2 [RFC7540] avoid connection re-establishment costs by serializing or multiplexing a set of per-host connections across a single TCP connection. This avoids TCP's per-connection OPEN handshake and also avoids recomputing the MSS, RTT, and congestion window values. By avoiding the so-called "slow-start restart", performance can be optimized [Hu01]. TCB interdependence can provide the "slow-start restart avoidance" of multiplexing, without requiring a multiplexing mechanism at the application layer.
TCP実装におけるTCB相互依存関係を組み込むことにはいくつかの影響があります。まず、性能向上のためのアプリケーション層多重化の必要性を低減することができる[RFC7231]。HTTP / 2 [RFC7540]のようなプロトコルは、単一のTCP接続にまたがって、ホストごとの接続ごとの接続をシリアル化または多重化することによって接続の再確立コストを避けます。これにより、TCPの接続ごとのオープンハンドシェイクを回避し、MSS、RTT、および輻輳ウィンドウの値を再計算することもできます。いわゆる「スロースタート再起動」を回避することで、性能を最適化することができます[HU01]。TCB相互依存関係は、アプリケーション層に多重化機構を必要とせずに、多重化の「スロースタート再起動回避」を提供することができる。
Like the initial version of this document [RFC2140], this update's approach to TCB interdependence focuses on sharing a set of TCBs by updating the TCB state to reduce the impact of transients when connections begin, end, or otherwise significantly change state. Other mechanisms have since been proposed to continuously share information between all ongoing communication (including connectionless protocols) and update the congestion state during any congestion-related event (e.g., timeout, loss confirmation, etc.) [RFC3124]. By dealing exclusively with transients, the approach in this document is more likely to exhibit the "steady-state" behavior as unmodified, independent TCP connections.
このドキュメント[RFC2140]の初期バージョンと同様に、このアップデートのTCB相互依存のアプローチは、接続が開始されたときのトランジェントの影響を減らすためにTCBの状態を更新することによってTCBのセットを共有することに焦点を当てています。その他のメカニズムは、すべての進行中の通信（コネクションレスプロトコルを含む）の間で情報を共有し、あらゆる輻輳関連のイベント（例えば、タイムアウト、損失確認など）[RFC3124]の間で輻輳状態を更新することを提案しています。過渡的に過渡的に対処することによって、この文書のアプローチは、変更されていない独立したTCP接続として「定常状態」の動作を示す可能性が高いです。
TCB interdependence pushes some of the TCP implementation from its typical placement solely within the transport layer (in the ISO model) to the network layer. This acknowledges that some components of state are, in fact, per-host-pair or can be per-path as indicated solely by that host-pair. Transport protocols typically manage per-application-pair associations (per stream), and network protocols manage per-host-pair and path associations (routing). Round-trip time, MSS, and congestion information could be more appropriately handled at the network layer, aggregated among concurrent connections, and shared across connection instances [RFC3124].
TCB相互依存関係は、TCP実装のいくつかをその標準的な配置から（ISOモデル内）内のネットワーク層にプッシュします。これは、状態のいくつかのコンポーネントが、実際にはホストペアごとに、またはそのホストペアのみで示されるようにパスごとにできることを認識しています。トランスポートプロトコルは通常、アプリケーションごとの関連付け（ストリームごと）、およびネットワークプロトコルがホストペアとパスの関連付け（ルーティング）を管理します。ラウンドトリップタイム、MSS、および輻輳情報は、ネットワーク層でより適切に処理され、同時接続の間で集約され、接続インスタンス[RFC3124]で共有されます。
An earlier version of RTT sharing suggested implementing RTT state at the IP layer rather than at the TCP layer. Our observations describe sharing state among TCP connections, which avoids some of the difficulties in an IP-layer solution. One such problem of an IP-layer solution is determining the correspondence between packet exchanges using IP header information alone, where such correspondence is needed to compute RTT. Because TCB sharing computes RTTs inside the TCP layer using TCP header information, it can be implemented more directly and simply than at the IP layer. This is a case where information should be computed at the transport layer but could be shared at the network layer.
RTT共有の以前のバージョンは、TCPレイヤではなくIP層でRTT状態を実装することを推奨しています。私たちの観察結果は、IP層ソリューションのいくつかの困難を回避するTCP接続間の共有状態を説明しています。IP層解の1つの問題の1つは、そのような対応がRTTを計算するのに必要とされる場合、そのような対応が必要とされる場合、そのようなIPヘッダ情報のみを使用してパケット交換間の対応を決定することである。TCB共有はTCPヘッダ情報を使用してTCPレイヤ内のRTTSを計算するため、IPレイヤよりも直接的で単に実装できます。これは、情報がトランスポート層で計算されるべきであるが、ネットワーク層で共有される可能性がある場合である。
Per-host-pair associations are not the limit of these techniques. It is possible that TCBs could be similarly shared between hosts on a subnet or within a cluster, because the predominant path can be subnet-subnet rather than host-host. Additionally, TCB interdependence can be applied to any protocol with congestion state, including SCTP [RFC4960] and DCCP [RFC4340], as well as to individual subflows in Multipath TCP [RFC8684].
ホストペアの関連付けは、これらの技術の限界ではありません。主なパスは、ホストホストではなくサブネットサブネットである可能性があるため、TCBSがサブネット上のホスト間でも同様に共有できる可能性があります。さらに、TCB相互依存関係は、SCTP [RFC4960]およびDCCP [RFC4340]、およびマルチパスTCP [RFC8684]の個々のサブフローを含む輻輳状態を持つ任意のプロトコルに適用できます。
There may be other information that can be shared between concurrent connections. For example, knowing that another connection has just tried to expand its window size and failed, a connection may not attempt to do the same for some period. The idea is that existing TCP implementations infer the behavior of all competing connections, including those within the same host or subnet. One possible optimization is to make that implicit feedback explicit, via extended information associated with the endpoint IP address and its TCP implementation, rather than per-connection state in the TCB.
同時接続間で共有できる他の情報があるかもしれません。たとえば、別の接続がウィンドウサイズの拡大と失敗したばかりであることを知っていることを知って、接続は何らかの期間で同じことを実行しようとしない可能性があります。このアイデアは、既存のTCP実装が、同じホストまたはサブネット内のそれらを含むすべての競合接続の動作を推測することです。1つの可能な最適化は、TCB内の接続ごとの状態ではなく、エンドポイントIPアドレスおよびそのTCP実装に関連付けられた拡張情報を介して、その暗黙のフィードバックを明示的にすることです。
This document focuses on sharing TCB information at connection initialization. Subsequent to RFC 2140, there have been numerous approaches that attempt to coordinate ongoing state across concurrent connections, both within TCP and other congestion-reactive protocols, which are summarized in [Is18]. These approaches are more complex to implement, and their comparison to steady-state TCP equivalence can be more difficult to establish, sometimes intentionally (i.e., they sometimes intend to provide a different kind of "fairness" than emerges from TCP operation).
この文書は、接続初期化時のTCB情報の共有に焦点を当てています。RFC 2140に続く、TCPおよび他の輻輳反応性プロトコル内の両方で継続的な状態を調整しようとしている多数のアプローチがあり、これは[IS18]で要約されている。これらのアプローチは実装がより複雑であり、定常状態TCP等価性との比較は、時には意図的に確立することがより困難であり得る（すなわち、それらはTCP操作からのeMergesよりも異なる種類の「公平性」を提供するつもりであることがある）。
The observation that some TCB state is host-pair specific rather than application-pair dependent is not new and is a common engineering decision in layered protocol implementations. Although now deprecated, T/TCP [RFC1644] was the first to propose using caches in order to maintain TCB states (see Appendix A).
いくつかのTCB状態がアプリケーション対に依存するのではなく、ホストペア固有のものであるという観察は、新しいものではなく、階層化プロトコル実装における一般的な工学的決定です。現在廃止予定では、TCB状態を維持するためにキャッシュを使用する最初の提案していました（付録Aを参照）。
Table 9 describes the current implementation status for TCB temporal sharing in Windows as of December 2020, Apple variants (macOS, iOS, iPadOS, tvOS, and watchOS) as of January 2021, Linux kernel version 5.10.3, and FreeBSD 12. Ensemble sharing is not yet implemented.
表9は、2021年1月、Linuxカーネルバージョン5.10.3、およびFreeBSD 12の現在、2020年12月現在、WindowsでのTCB時間共有の現在の実装状況（MacOS、IOS、IPADOS、TVOS、およびWatchos）を示しています。まだ実装されていません。
+==============+=========================================+
| TCB data | Status |
+==============+=========================================+
| old_MMS_S | Not shared |
+--------------+-----------------------------------------+
| old_MMS_R | Not shared |
+--------------+-----------------------------------------+
| old_sendMSS | Cached and shared in Apple, Linux (MSS) |
+--------------+-----------------------------------------+
| old_PMTU | Cached and shared in Apple, FreeBSD, |
| | Windows (PMTU) |
+--------------+-----------------------------------------+
| old_RTT | Cached and shared in Apple, FreeBSD, |
| | Linux, Windows |
+--------------+-----------------------------------------+
| old_RTTVAR | Cached and shared in Apple, FreeBSD, |
| | Windows |
+--------------+-----------------------------------------+
| old_TFOinfo | Cached and shared in Apple, Linux, |
| | Windows |
+--------------+-----------------------------------------+
| old_sendcwnd | Not shared |
+--------------+-----------------------------------------+
| old_ssthresh | Cached and shared in Apple, FreeBSD*, |
| | Linux* |
+--------------+-----------------------------------------+
| TFO failure | Cached and shared in Apple |
+--------------+-----------------------------------------+
Table 9: KNOWN IMPLEMENTATION STATUS
表9：既知の実装状況
* Note: In FreeBSD, new ssthresh is the mean of curr_ssthresh and its previous value if a previous value exists; in Linux, the calculation depends on state and is max(curr_cwnd/2, old_ssthresh) in most cases.
* 注：FreeBSDでは、新しいSSTHRESHはCURR_SSTHRESHと前の値が存在する場合の前の値の平均です。Linuxでは、計算は状態によって異なり、ほとんどの場合、MAX（CURR_CWND / 2、OLD_SSTHRESH）です。
In Table 9, "Apple" refers to all Apple OSes, i.e., macOS (desktop/ laptop), iOS (phone), iPadOS (tablet), tvOS (video player), and watchOS (smart watch), which all share the same Internet protocol stack.
表9に、「Apple」は、すべてのApple OS、すなわち、MacOS（デスクトップ/ラップトップ）、iOS（電話）、IPados（Tablet）、TVOS（ビデオプレーヤー）、およびWatchos（Smart Watch）を指しています。インターネットプロトコルスタック。
This document updates the description of TCB sharing in RFC 2140 and its associated impact on existing and new connection state, providing a complete replacement for that document [RFC2140]. It clarifies the previous description and terminology and extends the mechanism to its impact on new protocols and mechanisms, including multipath TCP, Fast Open, PLPMTUD, NAT, and the TCP Authentication Option.
このドキュメントは、RFC 2140のTCB共有の説明と既存の接続状態と新しい接続状態への関連する影響を更新し、その文書の完全な置き換えを提供します[RFC2140]。これ以前の説明と用語を明確にし、マルチパスTCP、高速オープン、PLPMTUD、NAT、およびTCP認証オプションを含む、メカニズムを新しいプロトコルやメカニズムに影響を与えます。
The detailed impact on TCB state addresses TCB parameters with greater specificity. It separates the way MSS is used in both send and receive directions, it separates the way both of these MSS values differ from sendMSS, it adds both path MTU and ssthresh, and it addresses the impact on state associated with TCP options.
TCB状態への詳細な影響は、より大きな特異性を持つTCBパラメータに対処します。それはMSSが送受信方向の両方で使用される方法を分離し、それはこれらのMSS値の両方がSENDMSと異なる方法を分離し、それはパスMTUとSSTHRESHの両方を追加し、TCPオプションに関連付けられた状態の影響を取ります。
New sections have been added to address compatibility issues and implementation observations. The relation of this work to T/TCP has been moved to Appendix A (which describes the history to TCB sharing) partly to reflect the deprecation of that protocol.
互換性の問題と実装の観測には、新しいセクションが追加されました。この作業のT / TCPの関係は、そのプロトコルの非推奨を反映するように、付録A（履歴をTCB共有に記述する）に移動されました。
Appendix C has been added to discuss the potential to use temporal sharing over long timescales to adapt TCP's initial window automatically, avoiding the need to periodically revise a single global constant value.
TCPの初期ウィンドウを自動的に適応させるために、長いタイムスケールを使用してTCPの最初のウィンドウを自動的に適応させる可能性を議論するために、付録Cが追加されました。
Finally, this document updates and significantly expands the referenced literature.
最後に、この文書は更新され、参照されている文献を大幅に拡大します。
These presented implementation methods do not have additional ramifications for direct (connection-aborting or information-injecting) attacks on individual connections. Individual connections, whether using sharing or not, also may be susceptible to denial-of-service attacks that reduce performance or completely deny connections and transfers if not otherwise secured.
これらの提示された実施方法は、個々の接続に対する直接的（接続中止または情報注入）攻撃に対する追加の影響を与えない。共有を使用するかどうかにかかわらず、個々の接続は、パフォーマンスを低下させるサービス拒否攻撃や、そうでなければ確保されていない場合は接続や転送を拒否する可能性があります。
TCB sharing may create additional denial-of-service attacks that affect the performance of other connections by polluting the cached information. This can occur across any set of connections in which the TCB is shared, between connections in a single host, or between hosts if TCB sharing is implemented within a subnet (see "Implications" (Section 9)). Some shared TCB parameters are used only to create new TCBs; others are shared among the TCBs of ongoing connections. New connections can join the ongoing set, e.g., to optimize send window size among a set of connections to the same host. PMTU is defined as shared at the IP layer and is already susceptible in this way.
TCB共有は、キャッシュされた情報を汚染することによって他の接続のパフォーマンスに影響を与える追加のサービス拒否攻撃を作成することがあります。これは、TCBが共有されている接続のセット、単一のホスト内の接続間、またはTCB共有がサブネット内で実装されている場合（「含意」（セクション9）を参照）。いくつかの共有TCBパラメータは新しいTCBを作成するためにのみ使用されます。他の人は進行中の接続のTCB間で共有されています。新しい接続は、同じホストへの接続セット間で送信ウィンドウサイズを最適化するために、進行中のセットを参加させることができます。PMTUはIP層で共有されていると定義されており、すでにこの方法で影響を受けにくいです。
Options in client SYNs can be easier to forge than complete, two-way connections. As a result, their values may not be safely incorporated in shared values until after the three-way handshake completes.
クライアントSYNのオプションは、完全な双方向接続よりも偽造が容易になる可能性があります。その結果、3方向ハンドシェイクが完了するまで、それらの値は共有値に安全に組み込まれない可能性があります。
Attacks on parameters used only for initialization affect only the transient performance of a TCP connection. For short connections, the performance ramification can approach that of a denial-of-service attack. For example, if an application changes its TCB to have a false and small window size, subsequent connections will experience performance degradation until their window grows appropriately.
初期化にのみ使用されるパラメータに対する攻撃は、TCP接続の一時的なパフォーマンスのみに影響します。短い接続のために、性能の影響はサービス拒否攻撃のそれに近づくことができます。たとえば、アプリケーションがfalseと小さなウィンドウサイズを持つようにアプリケーションが変更された場合、その後の接続は、ウィンドウが適切に成長するまでパフォーマンスの低下を経験します。
TCB sharing reuses and mixes information from past and current connections. Although reusing information could create a potential for fingerprinting to identify hosts, the mixing reduces that potential. There has been no evidence of fingerprinting based on this technique, and it is currently considered safe in that regard. Further, information about the performance of a TCP connection has not been considered as private.
TCB共有再利用と過去の接続と現在の接続から情報をミックスします。情報を再利用することは、ホストを識別するための指紋の可能性を生み出す可能性があるが、混合はその可能性を減少させる。この技術に基づく指紋の証拠はありませんでした、そしてそれは現在その点で安全であると考えられています。さらに、TCP接続の性能に関する情報はプライベートと見なされていません。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J.、 "Transmission Control Protocol"、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R.、ED。、「インターネットホストの要求 - 通信層の要求」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https：//www.rfc-editor.org/info/RFC1122>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J.およびS.Theering、 "Path Mtu Discovery"、RFC 1191、DOI 10.17487 / RFC1191、1990年11月、<https：//www.rfc-editor.org/info/rfc1191>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[RFC4821] Mathis、M.およびJ.Heffner、 "Packetization Layer Path MTU Discovery"、RFC 4821、DOI 10.17487 / RFC4821、2007年3月、<https：//www.rfc-editor.org/info/rfc4821>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V.およびE.Blanton、「TCP輻輳制御」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<https：//www.rfc-editor.org/info/RFC5681>。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[RFC6298] Paxson、V.、Allman、M.、Chu、J.、およびM.Sargent、「コンピューティングTCPの再送信タイマー」、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<https：///www.rfc-editor.org/info/rfc6298>。
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[RFC7413] Cheng、Y.、Chu、J.、Radhakrishnan、S.、A. Jain、 "TCP Fast Open"、RFC 7413、DOI 10.17487 / RFC7413、2014年12月、<https：///www.rfc-編集者.ORG / INFO / RFC7413>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[RFC8201] McCann、J.、Theer、S.、Mogul、J.、およびR. Hinden、Ed。、「IPバージョン6のためのパスMTUディスカバリー」、STD 87、RFC 8201、DOI 10.17487 / RFC8201、2017年7月、<https://www.rfc-editor.org/info/rfc8201>。
[Al10] Allman, M., "Initial Congestion Window Specification", Work in Progress, Internet-Draft, draft-allman-tcpm-bump-initcwnd-00, 15 November 2010, <https://datatracker.ietf.org/doc/html/draft-allman-tcpm-bump-initcwnd-00>.
[AL10] Allman、M。、「初期輻輳ウィンドウ仕様」、進行中の作業、インターネットドラフト、ドラフトALLMAN-TCPM-BUMP-INITCWND-00,15 11月15日、<https：//datatracker.ietf.org/doc / html / draft-allman-tcpm-bump-initcwnd-00>。
[Ba12] Barik, R., Welzl, M., Ferlin, S., and O. Alay, "LISA: A linked slow-start algorithm for MPTCP", IEEE ICC, DOI 10.1109/ICC.2016.7510786, May 2016, <https://doi.org/10.1109/ICC.2016.7510786>.
[BA12] Barik、R.、Welzl、M.、Ferlin、S.、およびO.Alay、「Lisa：MPTCPのためのリンクされたスロースタートアルゴリズム」、IEEE ICC、DOI 10.1109 / ICC.2016.7510786、<https://doi.org/10.1109/icc.2016.7510786>。
[Ba20] Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets", Work in Progress, Internet-Draft, draft-ietf-tcpm-generalized-ecn-07, 16 February 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-07>.
[BA20] Bagnulo、M.およびB. Brisco、 "ECN：明示的輻輳通知（ECN）への明示的な輻輳通知（ECN）へのTCP制御パケットの追加"、進行中の作業、インターネットドラフト、ドラフト-TCPM - 一般化 - ECN-07,22月16日2021、<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-07>。
[Be94] Berners-Lee, T., Cailliau, C., Luotonen, A., Nielsen, H., and A. Secret, "The World-Wide Web", Communications of the ACM V37, pp. 76-82, DOI 10.1145/179606.179671, August 1994, <https://doi.org/10.1145/179606.179671>.
[BE94]ベルナー - イ・リー、T.、Cailliau、C.、Luotonen、A.、Nielsen、H.、A.秘密、「ワールドワイドウェブ」、ACM V37、PP。76-82、Doi 10.1145 / 179606.179671、1994年8月、<https://doi.org/10.1145/179606.179671>。
[Br02] Brownlee, N. and KC. Claffy, "Understanding Internet traffic streams: dragonflies and tortoises", IEEE Communications Magazine, pp. 110-117, DOI 10.1109/MCOM.2002.1039865, 2002, <https://doi.org/10.1109/MCOM.2002.1039865>.
[BRO2]ブラウンリー、N.およびKC。Claffy、「インターネットトラフィックストリームの理解：トンボチャとカメ」、IEEE Communications Magazine、PP。110-117、DOI 10.1109 / MCOM.2002.1039865,2002、<https://doi.org/10.1109/mcom.2002.1039865>。
[Br94] Braden, B., "T/TCP -- Transaction TCP: Source Changes for Sun OS 4.1.3", USC/ISI Release 1.0, September 1994.
[BR94] Braden、B.、「T / TCP - トランザクションTCP：Sun OS 4.1.3のソース変更4.1.3」、USC / ISIリリース1.0、1994年9月。
[Co91] Comer, D. and D. Stevens, "Internetworking with TCP/IP", ISBN 10: 0134685059, ISBN 13: 9780134685052, 1991.
[CO91]コマーシャン、D.およびD.スティーブンズ、「TCP / IPによるインターネットワーキング」、ISBN 10：0134685059、ISBN 13：9780134685052,1971。
[Du16] Dukkipati, N., Cheng, Y., and A. Vahdat, "Research Impacting the Practice of Congestion Control", Computer Communication Review, The ACM SIGCOMM newsletter, July 2016.
[DU16] Dukkipati、N.、Cheng、Y.、A. Vahdat、「輻輳制御の実践に影響を与える研究」、Computer Communication Reviews、2016年7月のACM SIGMOMMニュースレター。
[FreeBSD] FreeBSD, "The FreeBSD Project", <https://www.freebsd.org/>.
[FreeBSD] FreeBSD、「FreeBSDプロジェクト」、<https：//www.freebsd.org/>。
[Hu01] Hughes, A., Touch, J., and J. Heidemann, "Issues in TCP Slow-Start Restart After Idle", Work in Progress, Internet-Draft, draft-hughes-restart-00, December 2001, <https://datatracker.ietf.org/doc/html/draft-hughes-restart-00>.
[HU01]ヒューズ、A.、Touch、J.、J.Heidemann、「アイドル後のTCPスロースタート再起動の問題」、進行中の作業、インターネットドラフト、ドラフト - Restart-00、2001年12月、<https://datatracker.ietf.org/doc/html/draft-hughes-restart-00>
[Hu12] Hurtig, P. and A. Brunstrom, "Enhanced metric caching for short TCP flows", IEEE International Conference on Communications, DOI 10.1109/ICC.2012.6364516, 2012, <https://doi.org/10.1109/ICC.2012.6364516>.
[HU12] HUTIG、P.およびA.Brunstrom、「短いTCPフローのための強化されたメトリックキャッシング」、IEEE国際コミュニケーション、DOI 10.1109 / ICC.2012.6364516,2012、<https：//doi.org/10.1109/109/102012.6364516>。
[IANA] IANA, "Transmission Control Protocol (TCP) Parameters", <https://www.iana.org/assignments/tcp-parameters>.
[IANA] IANA、「伝送制御プロトコル（TCP）パラメータ」、<https：//www.iana.org/assignments/tcp-parameters>。
[Is18] Islam, S., Welzl, M., Hiorth, K., Hayes, D., Armitage, G., and S. Gjessing, "ctrlTCP: Reducing latency through coupled, heterogeneous multi-flow TCP congestion control", IEEE INFOCOM 2018 - IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), DOI 10.1109/INFCOMW.2018.8406887, April 2018, <https://doi.org/10.1109/INFCOMW.2018.8406887>.
[IS18]イスラム、S.、Welzl、M.、HiSorth、K.、Hayes、D.、Armitage、G.、およびS.Gjessing、「CTRLTCP：結合された不均一マルチフローTCP輻輳制御」、IEEE Infocom 2018 - IEEE Computer Communicationsワークショップ（Infocom Wkshps）、DOI 10.1109 / INFCOMW.2018.8406887、<https：//doi.org/10.1109/infcomw.2018.8406887>。
[Ja88] Jacobson, V. and M. Karels, "Congestion Avoidance and Control", SIGCOMM Symposium proceedings on Communications architectures and protocols, November 1988.
[JA88] Jacobson、V.およびM.カレール、「輻輳回避・管理」、Communicationsアーキテクチャおよびプロトコル、1988年11月のコミュニケーションアーキテクチャおよびプロトコルに関するSIGCOMMシンポジウム手続。
[RFC1379] Braden, R., "Extending TCP for Transactions -- Concepts", RFC 1379, DOI 10.17487/RFC1379, November 1992, <https://www.rfc-editor.org/info/rfc1379>.
[RFC1379] Braden、R.、「トランザクションのためのTCPの拡張 - 概念」、RFC 1379、DOI 10.17487 / RFC1379、1992年11月、<https：//www.rfc-editor.org/info/rfc1379>。
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, DOI 10.17487/RFC1644, July 1994, <https://www.rfc-editor.org/info/rfc1644>.
[RFC1644] Braden、R.、「TCP - TCP拡張機能」、RFC 1644、DOI 10.17487 / RFC1644、1994年7月、<https：//www.rfc-editor.org/info/rfc1644>。
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, DOI 10.17487/RFC2001, January 1997, <https://www.rfc-editor.org/info/rfc2001>.
[RFC2001] Stevens、W。、「TCPスロースタート、輻輳回避、高速再送アルゴリズム」、RFC 2001、DOI 10.17487 / RFC2001、1997年1月、<https：//www.rfc-editor.org/info/ RFC2001>。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, DOI 10.17487/RFC2140, April 1997, <https://www.rfc-editor.org/info/rfc2140>.
[RFC2140] Touch、J.、 "TCP Control Block InterDependence"、RFC 2140、DOI 10.17487 / RFC2140、1997年4月、<https://www.rfc-editor.org/info/rfc2140>。
[RFC2414] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, DOI 10.17487/RFC2414, September 1998, <https://www.rfc-editor.org/info/rfc2414>.
[RFC2414] Allman、M.、Floyd、S.、およびC.パーリッジ、「TCPの初期ウィンドウの増加」、RFC 2414、DOI 10.17487 / RFC2414、1998年9月、<https：//www.rfc-editor.org/info/ RFC2414>。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <https://www.rfc-editor.org/info/rfc2663>.
[RFC2663] SRISERSH、P.およびM.OLSREGE、「IPネットワークアドレストランスレータ（NAT）用語と考慮事項」、RFC 2663、DOI 10.17487 / RFC2663、1999年8月、<https：//www.rfc-editor.org/info/ RFC2663>。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, DOI 10.17487/RFC3124, June 2001, <https://www.rfc-editor.org/info/rfc3124>.
[RFC3124] Balakrishnan、H.およびS.Seshan、「渋滞マネージャー」、RFC 3124、DOI 10.17487 / RFC3124、2001年6月、<https://www.rfc-editor.org/info/rfc3124>。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, DOI 10.17487/RFC3390, October 2002, <https://www.rfc-editor.org/info/rfc3390>.
[RFC3390] Allman、M.、Floyd、S.、C.パーリッジ、「TCPの初期ウィンドウの増加」、RFC 3390、DOI 10.17487 / RFC3390、2002年10月、<https：//www.rfc-editor.org/info/ RFC3390>。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <https://www.rfc-editor.org/info/rfc4340>.
[RFC4340] Kohler、E.、Handley、M.、S. Floyd、「データグラム輻輳制御プロトコル（DCCP）」、RFC 4340、DOI 10.17487 / RFC4340、2006年3月、<https：//www.rfc-編集者。ORG / INFO / RFC4340>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「ストリーム制御伝送プロトコル」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https：//www.rfc-editor.org/info/rfc4960>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A.、R.ボニカ、「TCP認証オプション」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<https://www.rfc-editor.org/info/ RFC5925>。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S.、およびJ.Rajahalme、「IPv6フローラベル仕様」、RFC 6437、DOI 10.17487 / RFC6437、2011年11月、<https：//www.rfc-editor.org/info/rfc6437>。
[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", RFC 6691, DOI 10.17487/RFC6691, July 2012, <https://www.rfc-editor.org/info/rfc6691>.
[RFC6691] Borman、D.、「TCPオプションと最大セグメントサイズ（MSS）」、RFC 6691、DOI 10.17487 / RFC6691、2012年7月、<https://www.rfc-editor.org/info/rfc6691>。
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/RFC6928, April 2013, <https://www.rfc-editor.org/info/rfc6928>.
[RFC6928] Chu、J.、Dukkipati、N.、Cheng、Y.、およびM. Mathis、「TCPの初期ウィンドウの増加」、RFC 6928、DOI 10.17487 / RFC6928、2013年4月、<https：//www.rfc-editor.org/info/rfc6928>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、Ed。J. Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：セマンティクスとコンテンツ」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231>。
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.
[RFC7323] Borman、D.、Braden、B.、Jacobson、V.、およびR.Scheffenegger、ED。、「高性能のためのTCP拡張」、RFC 7323、DOI 10.17487 / RFC7323、2014年9月、<https：//www.rfc-editor.org/info/rfc7323>。
[RFC7424] Krishnan, R., Yong, L., Ghanwani, A., So, N., and B. Khasnabish, "Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks", RFC 7424, DOI 10.17487/RFC7424, January 2015, <https://www.rfc-editor.org/info/rfc7424>.
[RFC7424]クリシュナン、R.、Yong、L.、Ghanwani、A.、SO、N.、B.Khasnabish、「リンクアグリゲーショングループ（LAG）および等価マルチパス（ECMP）コンポーネントリンク利用のためのメカニズム2015年1月、<https://www.rfc-editor.org/info/rfc7424>。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R.およびM.Thomson、Ed。、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<https：//www.rfc-editor.org/info/rfc7540>。
[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating TCP to Support Rate-Limited Traffic", RFC 7661, DOI 10.17487/RFC7661, October 2015, <https://www.rfc-editor.org/info/rfc7661>.
[RFC7661] FairHurst、G.、SathiaseLan、A.、R.Secchi、RFC 7661、DOI 10.17487 / RFC7661、2015年10月、<https：///www.rfc-編集者.ORG / INFO / RFC7661>。
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, <https://www.rfc-editor.org/info/rfc8684>.
[RFC8684]フォード、A.、RaiCyu、C.、Handley、M.、Bonaventure、O.、およびC. PaaSch、RFC 8684、DOI 10.17487 / RFC8684、2020年3月、<https://www.rfc-editor.org/info/rfc8684>。
T/TCP proposed using caches to maintain TCB information across instances (temporal sharing), e.g., smoothed RTT, RTT variation, congestion-avoidance threshold, and MSS [RFC1644]. These values were in addition to connection counts used by T/TCP to accelerate data delivery prior to the full three-way handshake during an OPEN. The goal was to aggregate TCB components where they reflect one association -- that of the host-pair rather than artificially separating those components by connection.
T / TCPは、インスタンス全体にわたってTCB情報を維持するためにキャッシュを使用して、例えばスムージングRTT、RTT変動、輻輳回避しきい値、およびMSS [RFC1644]。これらの値は、開いている間にフル3方向ハンドシェイクの前にデータ配信を加速するためにT / TCPによって使用される接続数に加えていました。目標は、それらのコンポーネントを人為的に接続によって人工的に分離するのではなく、ホストペアのそれを反映するTCBコンポーネントを集約することでした。
At least one T/TCP implementation saved the MSS and aggregated the RTT parameters across multiple connections but omitted caching the congestion window information [Br94], as originally specified in [RFC1379]. Some T/TCP implementations immediately updated MSS when the TCP MSS header option was received [Br94], although this was not addressed specifically in the concepts or functional specification [RFC1379] [RFC1644]. In later T/TCP implementations, RTT values were updated only after a CLOSE, which does not benefit concurrent sessions.
少なくとも1つのT / TCP実装はMSSを保存し、複数の接続にわたってRTTパラメータを集約したが、RFC1379で最初に指定されたように、輻輳ウィンドウ情報[BR94]のキャッシュを省略した。TCP MSSヘッダオプションが受信されたときには、T / TCP実装によってはMSSがすぐに更新されました[BR94]は、概念や機能仕様[RFC1379] [RFC1644]では特に対処されていません。後のT / TCP実装では、RTT値は閉じた後にのみ更新されました。これは、同時セッションに恩恵を受けません。
Temporal sharing of cached TCB data was originally implemented in the Sun OS 4.1.3 T/TCP extensions [Br94] and the FreeBSD port of same [FreeBSD]. As mentioned before, only the MSS and RTT parameters were cached, as originally specified in [RFC1379]. Later discussion of T/ TCP suggested including congestion control parameters in this cache; for example, Section 3.1 of [RFC1644] hints at initializing the congestion window to the old window size.
キャッシュされたTCBデータの時間的共有は、もともとSun OS 4.1.3 T / TCP拡張[BR94]と同じ[FreeBSD]のFreeBSDポートに実装されました。前述のように、[RFC1379]で最初に指定されているように、MSSとRTTパラメータのみがキャッシュされました。このキャッシュ内の輻輳制御パラメータを含むT / TCPの後の説明。たとえば、[RFC1644]のセクション3.1は、輻輳ウィンドウを古いウィンドウサイズに初期化するときにヒントします。
In addition to the options that can be cached and shared, this memo also lists known TCP options [IANA] for which state is unsafe to be kept. This list is not intended to be authoritative or exhaustive.
キャッシュされ共有できるオプションに加えて、このメモは既知のTCPオプション[IANA]もリストされていない状態にあります。このリストは権威あるか徹底的になることを意図していません。
Obsolete (unsafe to keep state):
廃止された（状態を維持するための危険）：
Echo
エコー
Echo Reply
echo応答
Partial Order Connection Permitted
部分順序接続が許可されています
Partial Order Service Profile
部分順序サービスプロファイル
CC
CC
CC.NEW
CC.ECHO
cc.echo.
TCP Alternate Checksum Request
TCP代替チェックサムリクエスト
TCP Alternate Checksum Data
TCP代替チェックサムデータ
No state to keep:
続ける状態はありません：
End of Option List (EOL)
オプションリストの終わり（EOL）
No-Operation (NOP)
ノーオペレーション（NOP）
Window Scale (WS)
ウィンドウスケール（WS）
SACK
袋
Timestamps (TS)
タイムスタンプ（TS）
MD5 Signature Option
MD5署名オプション
TCP Authentication Option (TCP-AO)
TCP認証オプション（TCP-AO）
RFC3692-style Experiment 1
RFC3692スタイル実験1
RFC3692-style Experiment 2
RFC3692スタイルの実験2.
Unsafe to keep state:
状態を維持するための安全ではありません：
Skeeter (DH exchange, known to be vulnerable)
Skeeter（DH交換、脆弱であることが知られている）
Bubba (DH exchange, known to be vulnerable)
Bubba（DH交換、脆弱なことが知られている）
Trailer Checksum Option
トレーラーチェックサムオプション
SCPS capabilities
SCPS機能
Selective Negative Acknowledgements (S-NACK)
選択的否定応答（S-NACK）
Records Boundaries
境界を記録します
Corruption experienced
腐敗
SNAP
スナップ
TCP Compression Filter
TCP圧縮フィルタ
Quick-Start Response
クイックスタート応答
User Timeout Option (UTO)
ユーザータイムアウトオプション（UTO）
Multipath TCP (MPTCP) negotiation success (see below for negotiation failure)
マルチパスTCP（MPTCP）ネゴシエーション成功（ネゴシエーションの失敗については下記参照）
TCP Fast Open (TFO) negotiation success (see below for negotiation failure)
TCP Fast Open（TFO）ネゴシエーション成功（下記のネゴシエーションの失敗を参照）
Safe but optional to keep state:
安全だが状態を保つためにオプション：
Multipath TCP (MPTCP) negotiation failure (to avoid negotiation retries)
マルチパスTCP（MPTCP）ネゴシエーションの失敗（交渉の再試行を回避するため）
Maximum Segment Size (MSS)
最大セグメントサイズ（MSS）
TCP Fast Open (TFO) negotiation failure (to avoid negotiation retries)
TCP高速オープン（TFO）ネゴシエーションの失敗（交渉後の再試行を回避するため）
Safe and necessary to keep state:
安全で、状態を保つために必要です。
TCP Fast Open (TFO) Cookie (if TFO succeeded in the past)
TCPファストオープン（TFO）クッキー（TFOが過去に成功した場合）
Temporal sharing, as described earlier in this document, builds on the assumption that multiple consecutive connections between the same host-pair are somewhat likely to be exposed to similar environment characteristics. The stored information can become less accurate over time and suitable precautions should take this aging into consideration (this is discussed further in Section 8.1). However, there are also cases where it can make sense to track these values over longer periods, observing properties of TCP connections to gradually influence evolving trends in TCP parameters. This appendix describes an example of such a case.
この文書で前述したように、一時的な共有は、同じホストペア間の複数の連続した接続が多少類似の環境特性にさらされる可能性があるという仮定を基にしています。記憶された情報は時間の経過とともに正確になる可能性があり、適切な予防措置を考慮に入れるべきである（これはセクション8.1でさらに議論される）。ただし、これらの値を長期間にわたって追跡することを理解することができる場合もあり、TCP接続の特性を徐々にTCPパラメータの進化する傾向に徐々に影響を与えることができる場合もあります。この付録では、そのような場合の例について説明します。
TCP's congestion control algorithm uses an initial window value (IW) both as a starting point for new connections and as an upper limit for restarting after an idle period [RFC5681] [RFC7661]. This value has evolved over time; it was originally 1 maximum segment size (MSS) and increased to the lesser of 4 MSSs or 4,380 bytes [RFC3390] [RFC5681]. For a typical Internet connection with a maximum transmission unit (MTU) of 1500 bytes, this permits 3 segments of 1,460 bytes each.
TCPの輻輳制御アルゴリズムは、新しい接続の出発点として、およびアイドル期間[RFC5681] [RFC7661]の後の上限として初期ウィンドウ値（IW）を使用します。この値は時間の経過とともに進化しました。それはもともと1つの最大セグメントサイズ（MSS）であり、4msssまたは4,380バイトのより少ないものに増加しました[RFC3390] [RFC5681]。1500バイトの最大伝送ユニット（MTU）を有する典型的なインターネット接続の場合、これはそれぞれ1,460バイトの3セグメントを可能にする。
The IW value was originally implied in the original TCP congestion control description and documented as a standard in 1997 [RFC2001] [Ja88]. The value was updated in 1998 experimentally and moved to the Standards Track in 2002 [RFC2414] [RFC3390]. In 2013, it was experimentally increased to 10 [RFC6928].
IW値はもともとオリジナルのTCP輻輳制御記述に暗示され、1997年の標準として文書化された[RFC2001] [JA88]。この値は1998年に実験的に更新され、2002年の標準トラックに移動しました[RFC2414] [RFC3390]。2013年には、10 [RFC6928]に実験的に増加しました。
This appendix discusses how TCP can objectively measure when an IW is too large and that such feedback should be used over long timescales to adjust the IW automatically. The result should be safer to deploy and might avoid the need to repeatedly revisit IW over time.
この付録では、iWが大きすぎるとTCPが客観的に測定できるか、そしてそのようなフィードバックを長いタイムスケールで使用してIWを自動的に調整する必要があるかについて説明します。結果は展開するのが安全であり、時間の経過とともにIWを繰り返し再訪する必要があります。
Note that this mechanism attempts to make the IW more adaptive over time. It can increase the IW beyond that which is currently recommended for wide-scale deployment, so its use should be carefully monitored.
このメカニズムは、IWを時間の経過とともにより適応的にしようとします。これを超えてIWを広範囲の展開に推奨していることを超えて増やすことができるので、その使用は慎重に監視されるべきです。
TCP's IW value has existed statically for over two decades, so any solution to adjusting the IW dynamically should have similarly stable, non-invasive effects on the performance and complexity of TCP. In order to be fair, the IW should be similar for most machines on the public Internet. Finally, a desirable goal is to develop a self-correcting algorithm so that IW values that cause network problems can be avoided. To that end, we propose the following design goals:
TCPのIW値は20年以上にわたって静的に存在しているので、IWを動的に調整するための解決策は、TCPの性能と複雑さにも同様に安定していない影響を与えるはずです。公平になるためには、公共のインターネット上のほとんどのマシンでIWが似ているはずです。最後に、ネットワークの問題を引き起こすIW値を回避できるように、自己補正アルゴリズムを開発することです。そのために、以下の設計目標を提案します。
* Impart little to no impact to TCP in the absence of loss, i.e., it should not increase the complexity of default packet processing in the normal case.
* 損失がない場合は、TCPへの影響はほとんど付与されない、すなわち通常の場合ではデフォルトのパケット処理の複雑さを高めるべきではない。
* Adapt to network feedback over long timescales, avoiding values that persistently cause network problems.
* 長いタイムスケールでネットワークフィードバックに適応し、永続的にネットワークの問題を引き起こす値を回避します。
* Decrease the IW in the presence of sustained loss of IW segments, as determined over a number of different connections.
* 多数の異なる接続にわたって決定されたように、IWセグメントの持続的な損失の存在下でIWを減らします。
* Increase the IW in the absence of sustained loss of IW segments, as determined over a number of different connections.
* 多数の異なる接続にわたって決定されるように、IWセグメントが損なわれていない場合は、IWを増やします。
* Operate conservatively, i.e., tend towards leaving the IW the same in the absence of sufficient information, and give greater consideration to IW segment loss than IW segment success.
* 保守的に動作する、すなわち、十分な情報がない場合にIWを同じにする傾向があり、IWセグメントの成功よりもIWセグメント損失に大きく考慮される傾向がある。
We expect that, without other context, a good IW algorithm will converge to a single value, but this is not required. An endpoint with additional context or information, or deployed in a constrained environment, can always use a different value. In particular, information from previous connections, or sets of connections with a similar path, can already be used as context for such decisions (as noted in the core of this document).
他のコンテキストがなければ、良いIWアルゴリズムが単一の値に収束することを期待していますが、これは必須ではありません。追加のコンテキストまたは情報を持つエンドポイント、または制約付き環境にデプロイされている場合は、常に別の値を使用できます。特に、以前の接続からの情報、または類似の経路を持つ接続のセットは、（この文書の中核に記載されているように）そのような決定のためにコンテキストとしてすでに使用できます。
However, if a given IW value persistently causes packet loss during the initial burst of packets, it is clearly inappropriate and could be inducing unnecessary loss in other competing connections. This might happen for sites behind very slow boxes with small buffers, which may or may not be the first hop.
ただし、所与のIW値がパケットの初期バーストの間にパケット損失を永続的に引き起こす場合、それは明らかに不適切であり、他の競合する接続で不要な損失を誘発する可能性があります。これは、小さなバッファを持つ非常に遅いボックスの背後にあるサイトに対して起こる可能性があります。これは、最初のホップでもない場合があります。
Below is a simple description of the proposed IW algorithm. It relies on the following parameters:
以下は提案されたIWアルゴリズムの簡単な説明です。次のパラメータに依存しています。
* MinIW = 3 MSS or 4,380 bytes (as per [RFC3390])
* MINIW = 3ミリ秒または4,380バイト（RFC3390のように）
* MaxIW = 10 MSS (as per [RFC6928])
* MAXIW = 10ミリ秒（[RFC6928]）
* MulDecr = 0.5
* MULDECR = 0.5
* AddIncr = 2 MSS
* ADDINCR = 2ミリ秒
* Threshold = 0.05
* しきい値= 0.05
We assume that the minimum IW (MinIW) should be as currently specified as standard [RFC3390]. The maximum IW (MaxIW) can be set to a fixed value (we suggest using the experimental and now somewhat de facto standard in [RFC6928]) or set based on a schedule if trusted time references are available [Al10]; here, we prefer a fixed value. We also propose to use an Additive Increase Multiplicative Decrease (AIMD) algorithm, with increase and decreases as noted.
最小IW（MiniW）は、現在標準の[RFC3390]と同じであるべきであると仮定します。最大IW（MAXIW）は固定値に設定できます（[RFC6928]の[実験]と[現実の事実標準]の[RFC6928]の標準を使用することをお勧めします）、または信頼された時間参照が利用可能である場合はスケジュールに基づいて設定できます[AL10]。ここでは、固定値を好みます。また、添付のように増減して減少して、添加剤増加多重減少（AIMD）アルゴリズムを使用することも提案します。
Although these parameters are somewhat arbitrary, their initial values are not important except that the algorithm is AIMD and the MaxIW should not exceed that recommended for other systems on the Internet (here, we selected the current de facto standard rather than the actual standard). Current proposals, including default current operation, are degenerate cases of the algorithm below for given parameters, notably MulDec = 1.0 and AddIncr = 0 MSS, thus disabling the automatic part of the algorithm.
これらのパラメータはやや恣意的ですが、アルゴリズムがAIMDであり、MAXIWはインターネット上の他のシステムに推奨されるものを超えてはならないことを除いて、その初期値は重要ではありません（ここでは、実際の規格ではなく現在の定数標準を選択しました）。デフォルトの電流動作を含む現在の提案は、与えられたパラメータについて、以下のアルゴリズムの縮退ケース、特にmuldec = 1.0およびaddIncr = 0mssであるため、アルゴリズムの自動部分を無効にします。
The proposed algorithm is as follows:
提案されたアルゴリズムは次のとおりです。
1. On boot:
1. 起動時に：
IW = MaxIW; # assume this is in bytes and indicates an integer
# multiple of 2 MSS (an even number to support
# ACK compression)
2. Upon starting a new connection:
2. 新しい接続を開始すると：
CWND = IW;
conncount++;
IWnotchecked = 1; # true
3. During a connection's SYN-ACK processing, if SYN-ACK includes ECN (as similarly addressed in Section 5 of ECN++ for TCP [Ba20]), treat as if the IW is too large:
3. 接続の間、接続のSYN-ACK処理中に、SYN-ACKがECNを含む場合（TCP [BA20]の場合もECNのセクション5でアドレス指定されているように）、IWが大きすぎるかのように扱います。
if (IWnotchecked && (synackecn == 1)) {
losscount++;
IWnotchecked = 0; # never check again
}
4. During a connection, if retransmission occurs, check the seqno of the outgoing packet (in bytes) to see if the re-sent segment fixes an IW loss:
4. 接続中に再送信が発生した場合は、送信パケットのSEQNO（バイト単位）を確認して、再送信セグメントがIW損失を修正しているかどうかを確認してください。
if (Retransmitting && IWnotchecked && ((seqno - ISN) < IW))) {
losscount++;
IWnotchecked = 0; # never do this entire "if" again
} else {
IWnotchecked = 0; # you're beyond the IW so stop checking
}
5. Once every 1000 connections, as a separate process (i.e., not as part of processing a given connection):
5. 1000個の接続ごとに、別のプロセスとして（すなわち、特定の接続を処理する部分として）：
if (conncount > 1000) {
if (losscount/conncount > threshold) {
# the number of connections with errors is too high
IW = IW * MulDecr;
} else {
IW = IW + AddIncr;
}
}
As presented, this algorithm can yield a false positive when the sequence number wraps around, e.g., the code might increment losscount in step 4 when no loss occurred or fail to increment losscount when a loss did occur. This can be avoided using either Protection Against Wrapped Sequences (PAWS) [RFC7323] context or internal extended sequence number representations (as in TCP Authentication Option (TCP-AO) [RFC5925]). Alternately, false positives can be tolerated because they are expected to be infrequent and thus will not significantly impact the algorithm.
提示されているように、このアルゴリズムは、シーケンス番号が折り返し、例えば、損失が発生しなかったときにロスカウントを増加させない場合には、ステップ4において、ステップ4でロスカウントを増加させる可能性がある場合、このアルゴリズムは偽陽性を生じる可能性がある。これは、ラップされたシーケンスに対する保護（PAWS）[RFC7323]コンテキストまたは内部拡張シーケンス番号表現（TCP認証オプション（TCP-AO）[RFC5925]）を使用することを回避できます。あるいは、偽の陽性は、それらがまれであると予想されるので許容され、したがってアルゴリズムに大きな影響を与えないであろう。
A number of additional constraints need to be imposed if this mechanism is implemented to ensure that it defaults to values that comply with current Internet standards, is conservative in how it extends those values, and returns to those values in the absence of positive feedback (i.e., success). To that end, we recommend the following list of example constraints:
このメカニズムが現在のインターネット規格に準拠した値にデフォルトであることを確認するためにこのメカニズムが実装されている場合には、いくつかの追加の制約を課す必要があります。、 成功）。そのために、以下の例の例のリストをお勧めします。
* The automatic IW algorithm MUST initialize MaxIW a value no larger than the currently recommended Internet default in the absence of other context information.
* 自動IWアルゴリズムは、他のコンテキスト情報がない場合に、現在推奨されるインターネットのデフォルト以外の値のMAXIWを初期化する必要があります。
Thus, if there are too few connections to make a decision or if there is otherwise insufficient information to increase the IW, then the MaxIW defaults to the current recommended value.
したがって、決定を下すための接続が少なすぎる場合、またはIWを増やすための情報が不十分な場合は、MAXIWはデフォルトで現在の推奨値になります。
* An implementation MAY allow the MaxIW to grow beyond the currently recommended Internet default but not more than 2 segments per calendar year.
* 実装により、MAXIWが現在推奨されているインターネットデフォルトを超えて、暦年ごとに2つのセグメントを超えて拡大できます。
Thus, if an endpoint has a persistent history of successfully transmitting IW segments without loss, then it is allowed to probe the Internet to determine if larger IW values have similar success. This probing is limited and requires a trusted time source; otherwise, the MaxIW remains constant.
したがって、エンドポイントが損失なしでIWセグメントを正常に送信する永続的な履歴を持つ場合、それはインターネットをプローブして、より大きなIW値が同様の成功を収めるかどうかを判断することを許可されます。このプロービングは制限され、信頼できる時間源が必要です。それ以外の場合、MAXIWは一定のままです。
* An implementation MUST adjust the IW based on loss statistics at least once every 1000 connections.
* 実装は、1000個の接続ごとに少なくとも1回の損失統計に基づいてIWを調整する必要があります。
An endpoint needs to be sufficiently reactive to IW loss.
エンドポイントは、IWの損失に対して十分に反応性である必要があります。
* An implementation MUST decrease the IW by at least 1 MSS when indicated during an evaluation interval.
* 評価間隔中に示されている場合、実装はIWを少なくとも1msだけ減少させなければならない。
An endpoint that detects loss needs to decrease its IW by at least 1 MSS; otherwise, it is not participating in an automatic reactive algorithm.
損失を検出するエンドポイントは、そのIWを少なくとも1ミリ秒だけ減少させる必要があります。それ以外の場合は、自動無効アルゴリズムに参加していません。
* An implementation MUST increase by no more than 2 MSSs per evaluation interval.
* 評価間隔ごとに2ms以下の実装が増加する必要があります。
An endpoint that does not experience IW loss needs to probe the network incrementally.
IW損失を経験しないエンドポイントは、ネットワークを徐々に調べる必要があります。
* An implementation SHOULD use an IW that is an integer multiple of 2 MSSs.
* 実装は、2ミリ秒の整数倍のIWを使用する必要があります。
The IW should remain a multiple of 2 MSS segments to enable efficient ACK compression without incurring unnecessary timeouts.
不要なタイムアウトを発生させることなく効率的なACK圧縮を可能にするために、IWは2ミリ秒セグメントの倍数のままです。
* An implementation MUST decrease the IW if more than 95% of connections have IW losses.
* 95％以上の接続がIW損失がある場合、実装はIWを減らす必要があります。
Again, this is to ensure an implementation is sufficiently reactive.
繰り返しますが、これは実装が十分に反応的であることを保証するためです。
* An implementation MAY group IW values and statistics within subsets of connections. Such grouping MAY use any information about connections to form groups except loss statistics.
* 実装は、接続のサブセット内のIW値と統計をグループ化することができます。そのようなグループ化は、損失統計を除くグループのフォームに接続に関する情報を使用することができます。
There are some TCP connections that might not be counted at all, such as those to/from loopback addresses or those within the same subnet as that of a local interface (for which congestion control is sometimes disabled anyway). This may also include connections that terminate before the IW is full, i.e., as a separate check at the time of the connection closing.
ループバックアドレスやローカルインタフェースと同じサブネット内のものなど、全くカウントされない可能性があるTCP接続がいくつかあります（とにかく輻輳制御が無効になっている場合があります）。これはまた、IWがフルで終了する接続、すなわち接続終了時の別個のチェックとしても含み得る。
The period over which the IW is updated is intended to be a long timescale, e.g., a month or so, or 1,000 connections, whichever is longer. An implementation might check the IW once a month and simply not update the IW or clear the connection counts in months where the number of connections is too small.
IWが更新される期間は、長いタイムスケール、例えば1ヶ月またはSO、または1,000個の接続、どちらか長いものであることを目的としています。実装は月に1回IWをチェックし、単にIWを更新することも、接続数が小さすぎる月に接続数をクリアしてください。
There are numerous parameters to the above algorithm that are compliant with the given requirements; this is intended to allow variation in configuration and implementation while ensuring that all such algorithms are reactive and safe.
与えられた要件に準拠している上記のアルゴリズムには多数のパラメータがあります。これは、すべてのそのようなアルゴリズムが反応性があり安全であることを確認しながら、構成と実装の変動を可能にすることを目的としています。
This algorithm continues to assume segments because that is the basis of most TCP implementations. It might be useful to consider revising the specifications to allow byte-based congestion given sufficient experience.
このアルゴリズムは、それがほとんどのTCP実装の基礎となるため、セグメントを仮定し続けます。十分な経験を考慮して、バイトベースの輻輳を許可するための仕様を修正することを検討することが有用かもしれません。
The algorithm checks for IW losses only during the first IW after a connection start; it does not check for IW losses elsewhere the IW is used, e.g., during slow-start restarts.
このアルゴリズムは、接続開始後の最初のIWの間にのみIW損失をチェックします。IWが使用されている場所、例えばスロースタート再起動中にIWの損失を確認しません。
* An implementation MAY detect IW losses during slow-start restarts in addition to losses during the first IW of a connection. In this case, the implementation MUST count each restart as a "connection" for the purposes of connection counts and periodic rechecking of the IW value.
* 実装は、接続の最初のIWの損失に加えて、スロースタート再起動中にIW損失を検出することができます。この場合、実装は接続カウントの目的とIW値の定期的な再検査の目的のための「接続」としての各再始動を数える必要があります。
False positives can occur during some kinds of segment reordering, e.g., that might trigger spurious retransmissions even without a true segment loss. These are not expected to be sufficiently common to dominate the algorithm and its conclusions.
偽陽性は、例えば、真のセグメント損失なしでもスプリアスの再送信を引き起こす可能性がある。これらはアルゴリズムとその結論を支配するのに十分に一般的であるとは予想されません。
This mechanism does require additional per-connection state, which is currently common in some implementations and is useful for other reasons (e.g., the ISN is used in TCP-AO [RFC5925]). The mechanism in this appendix also benefits from persistent state kept across reboots, which would also be useful to other state sharing mechanisms (e.g., TCP Control Block Sharing per the main body of this document).
このメカニズムは、いくつかの実装形態では現在一般的な追加の接続状態を必要とし、他の理由で有用である（例えば、ISNがTCP-AO [RFC5925]で使用されている）。この付録のメカニズムはまた、再起動中に保存されている永続状態からの利益をもたらし、これは他の状態共有メカニズム（例えば、この文書の本体ごとのTCP制御ブロック共有）にも役立ちます。
The receive window (rwnd) is not involved in this calculation. The size of rwnd is determined by receiver resources and provides space to accommodate segment reordering. Also, rwnd is not involved with congestion control, which is the focus of the way this appendix manages the IW.
受信ウィンドウ（RWND）はこの計算に含まれていません。RWNDのサイズは受信側リソースによって決まり、セグメントの並べ替えに対応するためのスペースを提供します。また、RWNDは輻輳制御に関与していません。これはこの付録がIWを管理する方法の焦点です。
The IW may not converge to a single global value. It also may not converge at all but rather may oscillate by a few MSSs as it repeatedly probes the Internet for larger IWs and fails. Both properties are consistent with TCP behavior during each individual connection.
IWは単一のグローバル値に収束しない場合があります。それはまたまったく収束しないかもしれませんが、それがより大きなIWSのためにインターネットを繰り返しプローブしているので、数量のMSSによって振動するかもしれません。両方のプロパティは、個々の接続ごとにTCPの動作と一致しています。
This mechanism assumes that losses during the IW are due to IW size. Persistent errors that drop packets for other reasons, e.g., OS bugs, can cause false positives. Again, this is consistent with TCP's basic assumption that loss is caused by congestion and requires backoff. This algorithm treats the IW of new connections as a long-timescale backoff system.
このメカニズムは、IWの損失がIWサイズによるものです。他の理由でパケットをドロップする永続的なエラー、例えばOSのバグは誤検知を引き起こす可能性があります。繰り返しになると、これはTCPの基本的な仮定と一致していますが、損失は輻輳によって引き起こされ、バックオフが必要です。このアルゴリズムは、新しい接続のIWを長時間のスケールバックオフシステムとして扱います。
Acknowledgments
謝辞
The authors would like to thank Praveen Balasubramanian for information regarding TCB sharing in Windows; Christoph Paasch for information regarding TCB sharing in Apple OSs; Yuchung Cheng, Lars Eggert, Ilpo Jarvinen, and Michael Scharf for comments on earlier draft versions of this document; as well as members of the TCPM WG. Earlier revisions of this work received funding from a collaborative research project between the University of Oslo and Huawei Technologies Co., Ltd. and were partly supported by USC/ISI's Postel Center.
WindowsでのTCB共有に関する情報については、Praveen Balasubramanianに感謝します。Apple OSSにおけるTCB共有に関する情報のためのChristoph Paasch。この文書の早いドラフトバージョンについてのコメントについては、Yuchung Cheng、Lars Egger、Ilpo Jarvinen、Michael Scharf。TCPM WGのメンバーと同様に。この作品の初期の改訂は、オスロ大学とHuawei Technologies Co.、Ltd。の間の共同研究プロジェクトからの資金を受け、USC / ISIのPostel Centerによって一部支持されました。
Authors' Addresses
著者の住所
Joe Touch Manhattan Beach, CA 90266 United States of America
Joe Touch Manhattan Beach、CA 90266アメリカ合衆国
Phone: +1 (310) 560-0334
Email: touch@strayalpha.com
Michael Welzl University of Oslo PO Box 1080 Blindern N-0316 Oslo Norway
マイケルウェルズルオスロ大学POボックス1080ブルインバーニーN-0316オスロノルウェー
Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no
Safiqul Islam University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway
Safiqulイスラム教大学オブ・オスロ・オブ・ボックス1080 Blindnoslo N-0316ノルウェー
Phone: +47 22 84 08 37
Email: safiquli@ifi.uio.no