[要約] RFC 8961は、時間ベースの損失検出に関する要件を定義しています。この文書の目的は、ネットワーク内でのデータパケットの損失をより効率的に検出し、対処するためのガイドラインを提供することです。主に、高速で信頼性の高いインターネット通信を必要とするアプリケーションやシステムで利用されます。
Internet Engineering Task Force (IETF) M. Allman
Request for Comments: 8961 ICSI
BCP: 233 November 2020
Category: Best Current Practice
ISSN: 2070-1721
Requirements for Time-Based Loss Detection
時間ベースの損失検出の要件
Abstract
概要
Many protocols must detect packet loss for various reasons (e.g., to ensure reliability using retransmissions or to understand the level of congestion along a network path). While many mechanisms have been designed to detect loss, ultimately, protocols can only count on the passage of time without delivery confirmation to declare a packet "lost". Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness; therefore, no implementation suits all situations. This document provides high-level requirements for time-based loss detectors appropriate for general use in unicast communication across the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation.
多くのプロトコルはさまざまな理由でパケット損失を検出しなければなりません（例えば、再送信を使用して信頼性を確保するため、またはネットワーク経路に沿った輻輳のレベルを理解するために）。多くのメカニズムは損失を検出するように設計されていますが、最終的には、プロトコルは、パケット「失われた」を宣言するための配達確認なしで時間の経過を数えることができます。時間ベースの損失検出メカニズムの各実装は、正確さと適時性のバランスを表します。したがって、実装はすべての状況に合っていません。この文書は、インターネット全体のユニキャスト通信における一般的な使用に適した時間ベースの損失検出器のための高レベルの要件を提供します。要件の中で、実装には各状況を最もよくアドレス指定する特定のものを定義するための緯度があります。
Status of This Memo
本文書の位置付け
This memo documents an Internet Best Current Practice.
このメモはインターネットの最高の現在の練習を文書化しています。
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 BCPs is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。BCPの詳細情報は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/rfc8961.
この文書の現在のステータス、任意のエラータ、およびフィードバックの提供方法は、https://www.rfc-editor.org/info/rfc8961で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 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
1.1. Terminology
2. Context
3. Scope
4. Requirements
5. Discussion
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Author's Address
As a network of networks, the Internet consists of a large variety of links and systems that support a wide variety of tasks and workloads. The service provided by the network varies from best-effort delivery among loosely connected components to highly predictable delivery within controlled environments (e.g., between physically connected nodes, within a tightly controlled data center). Each path through the network has a set of path properties, e.g., available capacity, delay, and packet loss. Given the range of networks that make up the Internet, these properties range from largely static to highly dynamic.
ネットワークのネットワークとして、インターネットは多種多様なタスクやワークロードをサポートする多種多様なリンクとシステムで構成されています。ネットワークによって提供されるサービスは、疎結合されたコンポーネント間のベストエフォート配信によって、制御された環境内の非常に予測可能な配達（例えば、厳密に制御されたデータセンター内の物理的に接続されたノード間）に変わる。ネットワークを通る各経路は、例えば、利用可能な容量、遅延、およびパケット損失の一組の経路特性を有する。インターネットを構成するネットワークの範囲を考えると、これらのプロパティは大部分静的から非常に動的に及びます。
This document provides guidelines for developing an understanding of one path property: packet loss. In particular, we offer guidelines for developing and implementing time-based loss detectors that have been gradually learned over the last several decades. We focus on the general case where the loss properties of a path are (a) unknown a priori and (b) dynamically varying over time. Further, while there are numerous root causes of packet loss, we leverage the conservative notion that loss is an implicit indication of congestion [RFC5681]. While this stance is not always correct, as a general assumption it has historically served us well [Jac88]. As we discuss further in Section 2, the guidelines in this document should be viewed as a general default for unicast communication across best-effort networks and not as optimal -- or even applicable -- for all situations.
この文書では、1つのパスプロパティの理解を開発するためのガイドラインを示します。パケット損失。特に、ここ数十年にわたって徐々に学習された時間ベースの損失検出器の開発と実施のためのガイドラインを提供しています。経路の損失特性が（a）未知のPRISINAと（B）経時的な経時的な経時的な（B）経路の損失特性が焦点を当てています。さらに、パケット損失の多数の根本原因があるが、損失が渋滞の暗黙の表示であるという保守的な概念を活用しています[RFC5681]。このスタンスは必ずしも正しいとは限りませんが、歴史的に私たちによく奉仕されています[JAC88]。セクション2でさらに議論するように、この文書のガイドラインは、最適なネットワーク間でユニキャスト通信の一般的なデフォルトと見なされるべきです。
Given that packet loss is routine in best-effort networks, loss detection is a crucial activity for many protocols and applications and is generally undertaken for two major reasons:
パケット損失がベストエフォートネットワークでルーチンであることを考えると、損失検出は多くのプロトコルやアプリケーションにとって重要な活動であり、一般的に2つの主な理由で行われています。
(1) Ensuring reliable data delivery
(1) 信頼できるデータ配信を確実にする
This requires a data sender to develop an understanding of which transmitted packets have not arrived at the receiver. This knowledge allows the sender to retransmit missing data.
これには、データ送信者が受信機に到着していない送信パケットが理解を深めることが必要です。この知識により、送信者は欠落データを再送信することができます。
(2) Congestion control
(2) 渋滞管理
As we mention above, packet loss is often taken as an implicit indication that the sender is transmitting too fast and is overwhelming some portion of the network path. Data senders can therefore use loss to trigger transmission rate reductions.
上述したように、パケット損失は、送信者が速く送信している暗黙の表示として、ネットワークパスの一部を圧倒していることを暗黙的に表示することが多い。したがって、データ送信者は損失を使用して伝送速度の削減を引き起こす可能性があります。
Various mechanisms are used to detect losses in a packet stream. Often, we use continuous or periodic acknowledgments from the recipient to inform the sender's notion of which pieces of data are missing. However, despite our best intentions and most robust mechanisms, we cannot place ultimate faith in receiving such acknowledgments but can only truly depend on the passage of time. Therefore, our ultimate backstop to ensuring that we detect all loss is a timeout. That is, the sender sets some expectation for how long to wait for confirmation of delivery for a given piece of data. When this time period passes without delivery confirmation, the sender concludes the data was lost in transit.
パケットストリーム内の損失を検出するために様々なメカニズムが使用される。多くの場合、私たちは受信者から継続的または定期的な承認を使用して、送信者の概念にどのデータが見つからないかを知らせる。しかし、私たちの最善の意図と最も堅牢なメカニズムにもかかわらず、私たちはそのような謝辞を受け取ることに究極の信仰を出すことはできませんが、時間の経過には真に依存することができます。したがって、すべての損失を検出することを確実にするための私たちの究極のバックストップはタイムアウトです。つまり、送信者は、特定のデータの配信確認を待つ時間に対する期待をいくつか設定します。この期間が配達確認なしで経過すると、送信者はデータが輸送中に失われたと結論付けられます。
The specifics of time-based loss detection schemes represent a tradeoff between correctness and responsiveness. In other words, we wish to simultaneously:
時間ベースの損失検出方式の詳細は、正当性と応答性の間のトレードオフを表しています。言い換えれば、同時に望みます。
* wait long enough to ensure the detection of loss is correct, and
* 損失の検出が正しいことを保証するのに十分な長さを待つ
* minimize the amount of delay we impose on applications (before repairing loss) and the network (before we reduce the congestion).
* 遅延量を最小限に抑える（損失を修復する前）、ネットワーク（渋滞を減らす前に）に課す遅延量を最小限に抑えます。
Serving both of these goals is difficult, as they pull in opposite directions [AP99]. By not waiting long enough to accurately determine a packet has been lost, we may provide a needed retransmission in a timely manner but risk both sending unnecessary ("spurious") retransmissions and needlessly lowering the transmission rate. By waiting long enough that we are unambiguously certain a packet has been lost, we cannot repair losses in a timely manner and we risk prolonging network congestion.
これらの目標の両方を提供することは困難である[AP99]。パケットを正確に判断するのに十分な長さを待っていないことで、必要な再送信をタイムリーに提供することができますが、不要な（「スプリアス」）再送と、送信速度を不必要に低下させる危険性があります。十分に長く待つことで、パケットが紛失していますが、タイムリーな方法で損失を修復することはできず、ネットワークの輻輳を延長するリスクがかかります。
Many protocols and applications -- such as TCP [RFC6298], SCTP [RFC4960], and SIP [RFC3261] -- use their own time-based loss detection mechanisms. At this point, our experience leads to a recognition that often specific tweaks that deviate from standardized time-based loss detectors do not materially impact network safety with respect to congestion control [AP99]. Therefore, in this document we outline a set of high-level, protocol-agnostic requirements for time-based loss detection. The intent is to provide a safe foundation on which implementations have the flexibility to instantiate mechanisms that best realize their specific goals.
TCP [RFC6298]、SCTP [RFC4960]、およびSIP [RFC3261]のような多くのプロトコルとアプリケーション - 独自の時間ベースの損失検出メカニズムを使用してください。この時点で、私たちの経験は、標準化された時間ベースの損失検出器から逸脱する頻繁な調整が輻輳制御に関するネットワークの安全性に大きな影響を与えないという認識につながります[AP99]。したがって、この文書では、時間ベースの損失検出のための高レベルのプロトコルアンジネック要件のセットを概説します。意図は、その実装がそれらの特定の目標を最もよく実現するメカニズムをインスタンス化するための柔軟性を持つ安全な基礎を提供することです。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document is different from the way we ideally like to engineer systems. Usually, we strive to understand high-level requirements as a starting point. We then methodically engineer specific protocols, algorithms, and systems that meet these requirements. Within the IETF standards process, we have derived many time-based loss detection schemes without the benefit of some over-arching requirements document -- because we had no idea how to write such a document! Therefore, we made the best specific decisions we could in response to specific needs.
この文書は、エンジニアシステムを理想的にする方法とは異なります。通常、私たちは高水準の要件を出発点として理解するよう努めています。その後、これらの要件を満たす特定のプロトコル、アルゴリズム、およびシステムが専門的にエンジニアリングされます。IETF規格プロセス内では、いくつかのオーバーアーチリング要件文書の利点を持たずに多くの時間ベースの損失検出スキームを導き出しました - そのような文書を書く方法はわかりませんでした！したがって、私たちは特定のニーズに応えて、私たちが可能な限り最高の特定の決定を下しました。
At this point, however, the community's experience has matured to the point where we can define a set of general, high-level requirements for time-based loss detection schemes. We now understand how to separate the strategies these mechanisms use that are crucial for network safety from those small details that do not materially impact network safety. The requirements in this document may not be appropriate in all cases. In particular, the guidelines in Section 4 are concerned with the general case, but specific situations may allow for more flexibility in terms of loss detection because specific facets of the environment are known (e.g., when operating over a single physical link or within a tightly controlled data center). Therefore, variants, deviations, or wholly different time-based loss detectors may be necessary or useful in some cases. The correct way to view this document is as the default case and not as one-size-fits-all guidance that is optimal in all cases.
しかしながら、この時点で、コミュニティの経験は、時間ベースの損失検出方式の一般的な一連の高レベルの要件を定義できるという点に成熟しました。ネットワークの安全性に大きな影響を与えない小さな詳細からネットワークの安全性を得るために重要なこれらのメカニズムを使用しているこれらのメカニズムを使用する方法を分離する方法を理解しています。この文書の要件はすべての場合において適切ではないかもしれません。特に、セクション4のガイドラインは一般的な場合に関係しているが、具体的な状況は損失検出の観点からより柔軟性が高くなる可能性がある（例えば、単一の物理的リンクを介してまたはしっかりと越えて操作するとき）。制御データセンター）。したがって、変形、偏差、または全く異なる時間ベースの損失検出器が必要または有用であり得る場合がある。このドキュメントを表示する正しい方法は、デフォルトの場合であり、すべての場合に最適なすべてのガイダンスではありません。
Adding a requirements umbrella to a body of existing specifications is inherently messy and we run the risk of creating inconsistencies with both past and future mechanisms. Therefore, we make the following statements about the relationship of this document to past and future specifications:
既存の仕様の体に要件傘を追加することは本質的に厄介であり、過去と将来の両方のメカニズムとの矛盾を生み出すリスクを実行します。したがって、この文書の過去と将来の仕様について次のような記述を行います。
* This document does not update or obsolete any existing RFC. These previous specifications -- while generally consistent with the requirements in this document -- reflect community consensus, and this document does not change that consensus.
* この文書は既存のRFCを更新または時代遅れにしません。これらの以前の仕様は、一般的にこの文書の要件と一致していますが、コミュニティコンセンサスを反映しており、この文書はそのコンセンサスを変更しません。
* The requirements in this document are meant to provide for network safety and, as such, SHOULD be used by all future time-based loss detection mechanisms.
* この文書の要件は、ネットワークの安全性を提供することを意図しており、そのように、すべての将来の時間ベースの損失検出メカニズムによって使用されるべきである。
* The requirements in this document may not be appropriate in all cases; therefore, deviations and variants may be necessary in the future (hence the "SHOULD" in the last bullet). However, inconsistencies MUST be (a) explained and (b) gather consensus.
* この文書の要件はすべての場合において適切ではないかもしれません。したがって、将来的には逸脱や変形が必要になる可能性があります（したがって、「最後の箇条書き」の「「はるい」）。ただし、矛盾は説明されている（a）、（b）コンセンサスを集める必要があります。
The principles we outline in this document are protocol-agnostic and widely applicable. We make the following scope statements about the application of the requirements discussed in Section 4:
この文書で概説する原則は、プロトコルが不具合で広く適用されています。セクション4で説明した要件の適用について、次の範囲の記述を行います。
(S.1) While there are a bevy of uses for timers in protocols -- from rate-based pacing to connection failure detection and beyond -- this document is focused only on loss detection.
（S.1）レートベースのペーシングから接続障害検出までのタイマーの使用頻度があるが、この文書は損失検出にのみ焦点を当てている。
(S.2) The requirements for time-based loss detection mechanisms in this document are for the primary or "last resort" loss detection mechanism, whether the mechanism is the sole loss repair strategy or works in concert with other mechanisms.
（S.2）この文書における時間ベースの損失検出メカニズムの要件は、メカニズムが唯一の損失修理戦略であるか他のメカニズムと協調して作品であるかどうか、プライマリまたは「最後のリゾート」損失検出メカニズムです。
While a straightforward time-based loss detector is sufficient for simple protocols like DNS [RFC1034] [RFC1035], more complex protocols often use more advanced loss detectors to aid performance. For instance, TCP and SCTP have methods to detect (and repair) loss based on explicit endpoint state sharing [RFC2018] [RFC4960] [RFC6675]. Such mechanisms often provide more timely and precise loss detection than time-based loss detectors. However, these mechanisms do not obviate the need for a "retransmission timeout" or "RTO" because, as we discuss in Section 1, only the passage of time can ultimately be relied upon to detect loss. In other words, we ultimately cannot count on acknowledgments to arrive at the data sender to indicate which packets never arrived at the receiver. In cases such as these, we need a time-based loss detector to function as a "last resort".
DNS [RFC1034] [RFC1035]のような単純なプロトコルには、直接的な時間ベースの損失検出器が十分であるが、より複雑なプロトコルは、パフォーマンスを支援するためにより高度な損失検出器を使用することが多い。たとえば、TCPとSCTPは、明示的なエンドポイント状態の共有[RFC2018] [RFC4960] [RFC6675]に基づいて損失を検出（および修理）する方法を持っています。そのようなメカニズムは、時間ベースの損失検出器よりもタイムリーで正確な損失検出を提供することが多い。しかしながら、これらのメカニズムは「再送信タイムアウト」または「RTO」の必要性を排除するものではないので、セクション1で説明したので、時間の経過のみが最終的に損失を検出することに頼ることができるからである。言い換えれば、我々は最終的にはデータ送信者に到着するために承認を頼りにすることはできません。これらのような場合には、「最後のリゾート」として機能する時間ベースの損失検出器が必要です。
Also, note that some recent proposals have incorporated time as a component of advanced loss detection methods either as an aggressive first loss detector in certain situations or in conjunction with endpoint state sharing [DCCM13] [CCDJ20] [IS20]. While these mechanisms can aid timely loss recovery, the protocol ultimately leans on another more conservative timer to ensure reliability when these mechanisms break down. The requirements in this document are only directly applicable to last-resort loss detection. However, we expect that many of the requirements can serve as useful guidelines for more aggressive non-last-resort timers as well.
また、いくつかの最近の提案は、特定の状況での積極的な第1の損失検出器として、またはエンドポイント状態の共有[DCDJ20] [IS20]と共に、高度な損失検出方法の構成要素として時間を組み込んでいます。これらのメカニズムはタイムリーな損失回復を助けることができるが、プロトコルは最終的には別のより保守的なタイマーに陥りながら、これらのメカニズムが故障したときに信頼性を確保する。この文書の要件は、最後のリゾート損失検出にのみ直接適用されます。しかし、多くの要件は、より積極的な非最後のリゾートタイマーのための有用なガイドラインとして役立つことがあります。
(S.3) The requirements in this document apply only to endpoint-to-endpoint unicast communication. Reliable multicast (e.g., [RFC5740]) protocols are explicitly outside the scope of this document.
（S.3）この文書の要件は、エンドポイント間のユニキャスト通信にのみ適用されます。信頼できるマルチキャスト（例えば、[RFC5740]）プロトコルはこの文書の範囲外で明示的に外側にあります。
Protocols such as SCTP [RFC4960] and Multipath TCP (MP-TCP) [RFC6182] that communicate in a unicast fashion with multiple specific endpoints can leverage the requirements in this document provided they track state and follow the requirements for each endpoint independently. That is, if host A communicates with addresses B and C, A needs to use independent time-based loss detector instances for traffic sent to B and C.
複数の特定のエンドポイントとユニキャストファッションで通信するSCTP [RFC4960]とマルチパスTCP（MP-TCP）[RFC6182]などのプロトコルは、この文書内の要件を活用し、それらが状態を追跡し、各エンドポイントの要件に応じて独立して要件を守ることができます。すなわち、ホストAがアドレスBおよびCと通信する場合、AおよびCに送信されたトラフィックに対して独立した時間ベースの損失検出器インスタンスを使用する必要がある。
(S.4) There are cases where state is shared across connections or flows (e.g., [RFC2140] and [RFC3124]). State pertaining to time-based loss detection is often discussed as sharable. These situations raise issues that the simple flow-oriented time-based loss detection mechanism discussed in this document does not consider (e.g., how long to preserve state between connections). Therefore, while the general principles given in Section 4 are likely applicable, sharing time-based loss detection information across flows is outside the scope of this document.
（S.4）接続やフロー間で状態が共有されている場合（例えば、[RFC2140]、[RFC3124]）。時間ベースの損失検出に関する状態は、しばしば共有可能であるとしばしば議論されます。このような状況は、この文書で説明されている単純なフロー指向の時間損失検出メカニズムが考慮されていない（例えば、接続間の状態を保存する期間）という問題を提起します。したがって、セクション4で示す一般的な原則は適用可能性がありますが、フロー間に時間ベースの損失検出情報を共有することはこの文書の範囲外です。
We now list the requirements that apply when designing primary or last-resort time-based loss detection mechanisms. For historical reasons and ease of exposition, we refer to the time between sending a packet and determining the packet has been lost due to lack of delivery confirmation as the "retransmission timeout" or "RTO". After the RTO passes without delivery confirmation, the sender may safely assume the packet is lost. However, as discussed above, the detected loss need not be repaired (i.e., the loss could be detected only for congestion control and not reliability purposes).
一次または最後のリゾートの時間ベースの損失検出メカニズムを設計する際に適用される要件をまとめました。歴史的な理由と博覧会のために、我々はパケットの送信との間の時間を参照し、「再送タイムアウト」または「RTO」としての配信確認の欠如のためにパケットを失うことの時間を指す。RTOが配達確認なしで通過した後、送信者は安全にパケットが失われると仮定することがあります。しかしながら、上述したように、検出された損失は修復される必要はない（すなわち、損失は輻輳制御のためだけに検出され、信頼性の目的で検出され得る）。
(1) As we note above, loss detection happens when a sender does not receive delivery confirmation within some expected period of time. In the absence of any knowledge about the latency of a path, the initial RTO MUST be conservatively set to no less than 1 second.
(1) 上記に注意しても、損失検知は、送信者が期待された期間内に配達確認を受けない場合に発生します。パスの待ち時間に関する知識がない場合、初期RTOは10秒以上に保守的に設定されている必要があります。
Correctness is of the utmost importance when transmitting into a network with unknown properties because:
正当性は、未知のプロパティを持つネットワークに送信するときに最も重要なことです。
* Premature loss detection can trigger spurious retransmits that could cause issues when a network is already congested.
* 早期損失検出は、ネットワークがすでに混雑しているときに問題を引き起こす可能性があるスプリアス再送信を引き起こす可能性があります。
* Premature loss detection can needlessly cause congestion control to dramatically lower the sender's allowed transmission rate, especially since the rate is already likely low at this stage of the communication. Recovering from such a rate change can take a relatively long time.
* 早期損失検出は、特にこの通信段階でレートがすでに低いほど低い伝送速度を劇的に低下させることが不必要に輻輳制御を劇的に低下させる可能性があります。そのようなレート変化からの回復は比較的長い時間をかける可能性があります。
* Finally, as discussed below, sometimes using time-based loss detection and retransmissions can cause ambiguities in assessing the latency of a network path. Therefore, it is especially important for the first latency sample to be free of ambiguities such that there is a baseline for the remainder of the communication.
* 最後に、以下で論じるように、時には時間ベースの損失検出を使用し、再送信を使用すると、ネットワーク経路の待ち時間を評価する際にあいまいさが発生する可能性があります。したがって、第1の待ち時間サンプルが、残りの通信のためのベースラインがあるように、曖昧さをなくすことが特に重要である。
The specific constant (1 second) comes from the analysis of Internet round-trip times (RTTs) found in Appendix A of [RFC6298].
特定の定数（1秒）は、[RFC6298]の付録Aにあるインターネットラウンドトリップタイム（RTTS）の分析からのものです。
(2) We now specify four requirements that pertain to setting an expected time interval for delivery confirmation.
(2) 配信確認の期待時間間隔を設定するための4つの要件を指定しました。
Often, measuring the time required for delivery confirmation is framed as assessing the RTT of the network path. The RTT is the minimum amount of time required to receive delivery confirmation and also often follows protocol behavior whereby acknowledgments are generated quickly after data arrives. For instance, this is the case for the RTO used by TCP [RFC6298] and SCTP [RFC4960]. However, this is somewhat misleading, and the expected latency is better framed as the "feedback time" (FT). In other words, the expectation is not always simply a network property; it can include additional time before a sender should reasonably expect a response.
多くの場合、配達確認に必要な時間を測定することは、ネットワーク経路のRTTを評価するものとして囲まれています。RTTは、配送確認を受信するのに必要な最小時間、またデータが到着した後に承認が迅速に生成されるプロトコル動作に従うことが多い。たとえば、これはTCP [RFC6298]とSCTP [RFC4960]で使用されるRTOの場合です。ただし、これはやや誤解を招くようなもので、期待された待ち時間は「フィードバック時間」（FT）と同じように囲まれています。言い換えれば、期待は必ずしも単にネットワークプロパティではありません。送信者が応答を合理的に期待する必要がある前の追加の時間を含めることができます。
For instance, consider a UDP-based DNS request from a client to a recursive resolver [RFC1035]. When the request can be served from the resolver's cache, the feedback time (FT) likely well approximates the network RTT between the client and resolver. However, on a cache miss, the resolver will request the needed information from one or more authoritative DNS servers, which will non-trivially increase the FT compared to the network RTT between the client and resolver.
たとえば、クライアントから再帰リゾルバ[RFC1035]へのUDPベースのDNS要求を検討してください。リクエストをリゾルバのキャッシュから提供できる場合、フィードバック時間（FT）はクライアントとレゾルバの間のネットワークRTTによく近似します。ただし、キャッシュミスでは、リゾルバは1つ以上の権限のあるDNSサーバーから必要な情報を要求します。
Therefore, we express the requirements in terms of FT. Again, for ease of exposition, we use "RTO" to indicate the interval between a packet transmission and the decision that the packet has been lost, regardless of whether the packet will be retransmitted.
したがって、FTの観点から要件を表します。また、博覧会を使用して、パケット送信とパケットが再送信されるかどうかにかかわらず、パケット送信とパケットが失われたという決定を示すために "RTO"を使用します。
(a) The RTO SHOULD be set based on multiple observations of the FT when available.
(a) RTOは、利用可能なときのFTの複数の観測値に基づいて設定する必要があります。
In other words, the RTO should represent an empirically derived reasonable amount of time that the sender should wait for delivery confirmation before deciding the given data is lost. Network paths are inherently dynamic; therefore, it is crucial to incorporate multiple recent FT samples in the RTO to take into account the delay variation across time.
言い換えれば、RTOは、与えられたデータを決定する前に、送信者が配達確認を待つべき経験的に導出された合理的な時間を表すべきである。ネットワークパスは本質的に動的です。したがって、時間を越えた遅延変動を考慮に入れるために、RTO内に複数の最近のFTサンプルを組み込むことが重要です。
For example, TCP's RTO [RFC6298] would satisfy this requirement due to its use of an exponentially weighted moving average (EWMA) to combine multiple FT samples into a "smoothed RTT". In the name of conservativeness, TCP goes further to also include an explicit variance term when computing the RTO.
たとえば、TCPのRTO [RFC6298]は、指数関数的に重み付けされた移動平均（EWMA）を使用して、複数のFTサンプルを「平滑化されたRTT」に組み合わせることで、この要件を満たします。保守性の名数では、TCPはさらにRTOを計算するときに明示的な分散用語を含むようになります。
While multiple FT samples are crucial for capturing the delay dynamics of a path, we explicitly do not tightly specify the process -- including the number of FT samples to use and how/when to age samples out of the RTO calculation -- as the particulars could depend on the situation and/or goals of each specific loss detector.
パスの遅延ダイナミクスをキャプチャするために複数のFTサンプルが重要であるが、使用するFTサンプルの数およびRTO計算からのサンプルを使用する方法を含むプロセスを明示的に指定しないでください。各特定の損失検出器の状況や目標に依存する可能性があります。
Finally, FT samples come from packet exchanges between peers. We encourage protocol designers -- especially for new protocols -- to strive to ensure the feedback is not easily spoofable by on- or off-path attackers such that they can perturb a host's notion of the FT. Ideally, all messages would be cryptographically secure, but given that this is not always possible -- especially in legacy protocols -- using a healthy amount of randomness in the packets is encouraged.
最後に、FTサンプルはピア間のパケット交換から来ます。プロトコル設計者 - 特に新しいプロトコルのために、フィードバックが、FTのホストの概念を乱すことができるようにフィードバックが容易になりやすいことを保証することを努める。理想的には、すべてのメッセージは暗号的に安全であると考えられますが、これは必ずしも可能ではないことを考えると、特にレガシープロトコルでは - パケット内の健全な量のランダム性を使用することが奨励されます。
(b) FT observations SHOULD be taken and incorporated into the RTO at least once per RTT or as frequently as data is exchanged in cases where that happens less frequently than once per RTT.
(b) FT観測は、少なくともRTTに1回、またはデータが頻繁に発生した場合にはRTOに1回、または頻繁に頻繁に行われる必要があります。
Internet measurements show that taking only a single FT sample per TCP connection results in a relatively poorly performing RTO mechanism [AP99], hence this requirement that the FT be sampled continuously throughout the lifetime of communication.
インターネット測定値は、TCP接続ごとに単一のFTサンプルのみを取ることが比較的不十分なRTOメカニズム[AP99]になることを示しているので、この要件は、コミュニケーションの寿命を通して連続的にサンプリングされることを要求します。
As an example, TCP takes an FT sample roughly once per RTT, or, if using the timestamp option [RFC7323], on each acknowledgment arrival. [AP99] shows that both these approaches result in roughly equivalent performance for the RTO estimator.
例として、TCPはRTTに1回、またはタイムスタンプオプション[RFC7323]を使用している場合は、各確認応答到着でFTサンプルを取ります。[AP99]は、これらのアプローチの両方がRTO推定器に対してほぼ同等の性能をもたらすことを示しています。
(c) FT observations MAY be taken from non-data exchanges.
(c) FT観察は、非データ交換から取られることがあります。
Some protocols use non-data exchanges for various reasons, e.g., keepalives, heartbeats, and control messages. To the extent that the latency of these exchanges mirrors data exchange, they can be leveraged to take FT samples within the RTO mechanism. Such samples can help protocols keep their RTO accurate during lulls in data transmission. However, given that these messages may not be subject to the same delays as data transmission, we do not take a general view on whether this is useful or not.
いくつかのプロトコルは、例えばキープアライブ、ハートビート、および制御メッセージのために、さまざまな理由で非データ交換を使用します。これらの交換の待ち時間がデータ交換を乱す範囲では、RTOメカニズム内でFTサンプルを取り込むように活用することができます。そのようなサンプルは、データ伝送の子句中にプロトコルを正確に正確に保持するのに役立ちます。ただし、これらのメッセージがデータ送信と同じ遅延を受けることができない場合は、これが有用であるかどうかについて一般的なビューを使用しません。
(d) An RTO mechanism MUST NOT use ambiguous FT samples.
(d) RTOメカニズムは、あいまいなFTサンプルを使用してはいけません。
Assume two copies of some packet X are transmitted at times t0 and t1. Then, at time t2, the sender receives confirmation that X in fact arrived. In some cases, it is not clear which copy of X triggered the confirmation; hence, the actual FT is either t2-t1 or t2-t0, but which is a mystery. Therefore, in this situation, an implementation MUST NOT use either version of the FT sample and hence not update the RTO (as discussed in [KP87] and [RFC6298]).
時刻t0およびt1で2つのパケットxが送信されると仮定する。そして、時刻t2において、送信者は実際にXが到着した確認を受信する。場合によっては、Xのコピーが確認をトリガーしたのは明確ではありません。したがって、実際のFTはT2-T1またはT2-T0ですが、これは謎です。したがって、この状況では、実装はどちらのバージョンのFTサンプルを使用してはいけません。したがって、RTOを更新しません（[KP87]と[RFC6298]で説明しているように）。
There are cases where two copies of some data are transmitted in a way whereby the sender can tell which is being acknowledged by an incoming ACK. For example, TCP's timestamp option [RFC7323] allows for packets to be uniquely identified and hence avoid the ambiguity. In such cases, there is no ambiguity and the resulting samples can update the RTO.
何らかのデータの2つのコピーが送信されることによって送信されることができることを知らせることができるような方法で送信されることがある場合があります。たとえば、TCPのタイムスタンプオプション[RFC7323]は、パケットを一意に識別することができ、したがってあいまいさを回避できます。そのような場合、あいまいさはありません、そして結果として得られるサンプルはRTOを更新することができます。
(3) Loss detected by the RTO mechanism MUST be taken as an indication of network congestion and the sending rate adapted using a standard mechanism (e.g., TCP collapses the congestion window to one packet [RFC5681]).
(3) RTOメカニズムによって検出された損失は、ネットワークの輻輳の表示と標準的なメカニズム（例えば、TCPが輻輳ウィンドウを1つのパケット（RFC5681]に崩壊させる）として適応された送信速度ととして取らなければなりません。
This ensures network safety.
これにより、ネットワークの安全性が保証されます。
An exception to this rule is if an IETF standardized mechanism determines that a particular loss is due to a non-congestion event (e.g., packet corruption). In such a case, a congestion control action is not required. Additionally, congestion control actions taken based on time-based loss detection could be reversed when a standard mechanism post facto determines that the cause of the loss was not congestion (e.g., [RFC5682]).
この規則の例外は、IETF標準化されたメカニズムが、特定の損失が非輻輳イベント（例えば、パケット破損）によるものであると判断した場合である。このような場合、輻輳制御動作は不要です。さらに、標準的な損失検出に基づく輻輳制御動作は、標準的なメカニズムが損失の原因が輻輳ではないと判断したときに逆にすることができます（例えば、[RFC5682]）。
(4) Each time the RTO is used to detect a loss, the value of the RTO MUST be exponentially backed off such that the next firing requires a longer interval. The backoff SHOULD be removed after either (a) the subsequent successful transmission of non-retransmitted data, or (b) an RTO passes without detecting additional losses. The former will generally be quicker. The latter covers cases where loss is detected but not repaired.
(4) RTOが損失を検出するために使用されるたびに、RTOの値は次の発射が長い間隔を必要とするように指数関数的に後退させる必要があります。バックオフは（a）後に再送信されていないデータの送信を成功させた後、または（b）追加の損失を検出せずにパスを通過する（a）の後に除去する必要があります。前者は一般的に速くなります。後者は損失が検出されたが修復されない場合をカバーする。
A maximum value MAY be placed on the RTO. The maximum RTO MUST NOT be less than 60 seconds (as specified in [RFC6298]).
最大値をRTOに配置することができます。最大RTOは60秒未満にしてはいけません（[RFC6298]で指定）。
This ensures network safety.
これにより、ネットワークの安全性が保証されます。
As with guideline (3), an exception to this rule exists if an IETF standardized mechanism determines that a particular loss is not due to congestion.
ガイドライン（3）と同様に、IETF標準化されたメカニズムが特定の損失が輻輳によるものではないと判断した場合、この規則に対する例外が存在します。
We note that research has shown the tension between the responsiveness and correctness of time-based loss detection seems to be a fundamental tradeoff in the context of TCP [AP99]. That is, making the RTO more aggressive (e.g., via changing TCP's exponentially weighted moving average (EWMA) gains, lowering the minimum RTO, etc.) can reduce the time required to detect actual loss. However, at the same time, such aggressiveness leads to more cases of mistakenly declaring packets lost that ultimately arrived at the receiver. Therefore, being as aggressive as the requirements given in the previous section allow in any particular situation may not be the best course of action because detecting loss, even if falsely, carries a requirement to invoke a congestion response that will ultimately reduce the transmission rate.
研究は、TCP [AP99]の文脈では、時間ベースの損失検出の応答性と正確さの間の緊張を示していることに注意しています。すなわち、RTOをより積極的にする（例えば、TCPの指数関数的に重み付け移動平均（EWMA）利得を介して、最小RTOなどを介して）、実際の損失を検出するのに必要な時間を短縮することができる。しかしながら、同時に、そのような攻撃性は、最終的に受信者に到着したパケットが誤って宣言されている誤って宣言された場合のより多くのケースをもたらす。したがって、前のセクションで与えられた要件が、誤って特定の状況で与えられた要件を考慮して、最終的に伝送速度を短縮するための輻輳応答を呼び出す必要があるため、特定の状況では最高の行動方針ではない可能性があります。
While the tradeoff between responsiveness and correctness seems fundamental, the tradeoff can be made less relevant if the sender can detect and recover from mistaken loss detection. Several mechanisms have been proposed for this purpose, such as Eifel [RFC3522], Forward RTO-Recovery (F-RTO) [RFC5682], and Duplicate Selective Acknowledgement (DSACK) [RFC2883] [RFC3708]. Using such mechanisms may allow a data originator to tip towards being more responsive without incurring (as much of) the attendant costs of mistakenly declaring packets to be lost.
応答性と正当性の間のトレードオフは基本的に思われますが、送信者が誤った損失の検出から検出して回復できる場合、トレードオフは関連性が低くなります。EIFEL [RFC3522]、前方RTO回復（F-RTO）[RFC5682]、および重複選択確認（DSACK）[RFC2883] [RFC2883]のようないくつかのメカニズムが提案されています。そのようなメカニズムを使用することは、誤って宣言されるべきパケットを誤って宣言することの偶然のコストが存在することなく、データ発信者がより敏感であることをより答えることを可能にし得る。
Also, note that, in addition to the experiments discussed in [AP99], the Linux TCP implementation has been using various non-standard RTO mechanisms for many years seemingly without large-scale problems (e.g., using different EWMA gains than specified in [RFC6298]). Further, a number of TCP implementations use a steady-state minimum RTO that is less than the 1 second specified in [RFC6298]. While the implication of these deviations from the standard may be more spurious retransmits (per [AP99]), we are aware of no large-scale network safety issues caused by this change to the minimum RTO. This informs the guidelines in the last section (e.g., there is no minimum RTO specified).
また、[AP99]で説明した実験に加えて、Linux TCP実装は、大規模な問題なしに、さまざまな数年間、さまざまな非標準RTOメカニズムを使用しています（たとえば、[RFC6298）。]）。さらに、いくつかのTCP実装は、[RFC6298]で指定された1秒未満の定常状態最小RTOを使用する。これらの偏差を標準からの影響を受けている可能性があるが、よりスプリアスの再送信（AP99）は、この変更によって最小RTOへの変更によって引き起こされる大規模なネットワークの安全性の問題を認識しています。これにより、最後のセクション（例えば、最小RTOが指定されていない）のガイドラインに通知します。
Finally, we note that while allowing implementations to be more aggressive could in fact increase the number of needless retransmissions, the above requirements fail safely in that they insist on exponential backoff and a transmission rate reduction. Therefore, providing implementers more latitude than they have traditionally been given in IETF specifications of RTO mechanisms does not somehow open the flood gates to aggressive behavior. Since there is a downside to being aggressive, the incentives for proper behavior are retained in the mechanism.
最後に、実際には不要な再送信の数を増やす可能性があることを可能にする可能性があることを可能にするように、上記の要件は、彼らが指数関数的なバックオフと伝送速度の低下を主張するという点で上記の要件が安全に失敗することに注意してください。したがって、実装者が伝統的にRTOメカニズムのIETF仕様に記載されているよりもっと緯度を提供することは、洪水の門を積極的な行動に開放していません。積極的であることに欠点があるので、適切な行動のためのインセンティブはメカニズムに保持されます。
This document does not alter the security properties of time-based loss detection mechanisms. See [RFC6298] for a discussion of these within the context of TCP.
この文書は、時間ベースの損失検出メカニズムのセキュリティ特性を変更しません。TCPのコンテキスト内のこれらの議論については、[RFC6298]を参照してください。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[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>。
[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>。
[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", Proceedings of the ACM SIGCOMM Technical Symposium, September 1999.
[AP99] Allman、M.およびV. Paxson、「エンドツーエンドネットワークパスのプロパティの見積もり」、1999年9月のACM SIGMOMM技術シンポジウムの手続き。
[CCDJ20] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The RACK-TLP loss detection algorithm for TCP", Work in Progress, Internet-Draft, draft-ietf-tcpm-rack-13, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-tcpm-rack-13>.
[CCDJ20] Cheng、Y.、Cardwell、N.、Dukkipati、N.、およびP.JHA、「TCP用ラック-TLP損失検出アルゴリズム」、進行中の作業、インターネットドラフト、ドラフト-TCPMラック2020年11月2日、<https://tools.ietf.org/html/draft-ietf-tcpm-rack-13>。
[DCCM13] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses", Work in Progress, Internet-Draft, draft-dukkipati-tcpm-tcp-loss-probe-01, 25 February 2013, <https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01>.
[DCCM13] Dukkipati、N.、Cardwell、N.、Cheng、Y.、およびM Mathis、「テールロスプローブ（TLP）：テールロスの迅速な回復のためのアルゴリズム」、進行中、インターネットドラフト、ドラフト-dukkipati-tcpm-tcp-loss-probe-01,2013、<https：//tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01>。
[IS20] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", Work in Progress, Internet-Draft, draft-ietf-quic-recovery-32, 20 October 2020, <https://tools.ietf.org/html/draft-ietf-quic-recovery-32>.
[IS20] Iyengar、J.、ED。そしてI.Swett、Ed。、「QUICの喪失検知と輻輳制御」、進行中の作業、インターネットドラフト、ドラフト - IETF-QUIC-Recovery-32,20、<https://tools.ietf.org/html / froms-ietf-quic-recovery-32>。
[Jac88] Jacobson, V., "Congestion avoidance and control", ACM SIGCOMM, DOI 10.1145/52325.52356, August 1988, <https://doi.org/10.1145/52325.52356>.
[JAC88] Jacobson、V.、「輻輳回避・制御」、ACM SIGCOMM、DOI 10.1145 / 52325.52356、<https：//doi.org/10.1145/52325.52356>。
[KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM 87.
[KP87]カーン、P.およびC.パーリッジ、「信頼できる輸送プロトコルにおける往復時間推定の改善」、SIGCOMM87。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P.、「ドメイン名 - コンセプトと施設」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https：//www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P.、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https：//www.rfc-editor.org/info/rfc1035>。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/info/rfc2018>.
[RFC2018] Mathis、M.、Mahdavi、J.、Floyd、S.、およびA. Romanow、「TCP選択認証オプション」、RFC 2018、DOI 10.17487 / RFC2018、<https：///www.rfc-editor.org/info/rfc2018>
[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>。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, DOI 10.17487/RFC2883, July 2000, <https://www.rfc-editor.org/info/rfc2883>.
[RFC2883] Floyd、S.、Mahdavi、J.、Mathis、M.、およびM. Podolsky、「TCPのための延長」、RFC 2883、DOI 10.17487 / RFC2883、2000年7月、<https://www.rfc-editor.org/info/rfc2883>。
[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>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, DOI 10.17487/RFC3522, April 2003, <https://www.rfc-editor.org/info/rfc3522>.
[RFC3522] Ludwig、R.およびM.Meyer、「TCPのためのeipel検出アルゴリズム」、RFC 3522、DOI 10.17487 / RFC3522、2003年4月、<https：//www.rfc-editor.org/info/rfc3522>。
[RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions", RFC 3708, DOI 10.17487/RFC3708, February 2004, <https://www.rfc-editor.org/info/rfc3708>.
[RFC3708] Blanton、E.およびM. Allman、「TCP複製選択確認応答（DSACKS）およびストリーム制御伝送プロトコル（SCTP）の重複伝送シーケンス番号（TSNS）の再送信シーケンス番号（TSNS）、RFC 3708、DOI 10.17487 / RFC3708、2004年2月、<https://www.rfc-editor.org/info/rfc3708>。
[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>。
[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>。
[RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP", RFC 5682, DOI 10.17487/RFC5682, September 2009, <https://www.rfc-editor.org/info/rfc5682>.
[RFC5682] Sarolahti、P.、Kojo、M.、Yamamoto、K.、およびM. HATA、「前方RTO回復（F-RTO）：TCPでのスプリアス再送タイムアウトを検出するためのアルゴリズム、RFC 5682、DOI 10.17487/ RFC5682、2009年9月、<https：//www.rfc-editor.org/info/rfc5682>。
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, <https://www.rfc-editor.org/info/rfc5740>.
[RFC5740] Adamson、B.、Bormann、C.、Handley、M.、およびJ. Macker、「NACK-志向の信頼できるマルチキャスト（NORT）トランスポートプロトコル」、RFC 5740、DOI 10.17487 / RFC5740、2009年11月、<https：//www.rfc-editor.org/info/rfc5740>。
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, <https://www.rfc-editor.org/info/rfc6182>.
[RFC6182]フォード、A.、RaiCy、C.、Handley、M.、Barre、S.、およびJ.Iyengar、「マルチパスTCP開発のための建築ガイドライン」、RFC 6182、DOI 10.17487 / RFC6182、2011年3月、<HTTPS//www.rfc-editor.org/info/rfc6182>。
[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>。
[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, DOI 10.17487/RFC6675, August 2012, <https://www.rfc-editor.org/info/rfc6675>.
[RFC6675] Blanton、E.、Allman、M.、Wang、L.、Jarvinen、I.、Kojo、M.、Y. Nishida、「TCPのための選択認識（SACK）に基づく保守的な損失回復アルゴリズム」RFC 6675、DOI 10.17487 / RFC6675、2012年8月、<https：//www.rfc-editor.org/info/rfc6675>。
[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>。
Acknowledgments
謝辞
This document benefits from years of discussions with Ethan Blanton, Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson, and the members of the TCPM and TCPIMPL Working Groups. Ran Atkinson, Yuchung Cheng, David Black, Stewart Bryant, Martin Duke, Wesley Eddy, Gorry Fairhurst, Rahul Arvind Jadhav, Benjamin Kaduk, Mirja Kühlewind, Nicolas Kuhn, Jonathan Looney, and Michael Scharf provided useful comments on previous draft versions of this document.
この文書は、Ethan Blanton、Sally Floyd、Jana Iyengar、Shawn Ostermann、Vern Paxson、およびTCPMおよびTCPIMPLワーキンググループのメンバーとの議論の年々の恩恵を受けています。Ran Atkinson、Yuchung Cheng、David Black、Stewart Bryant、Martin Duke、Wesley Eddy、Gorry FairHurst、Rahul Arvind Jadhav、Benjamin Kuhlewind、Nicolas Kuhn、Jonathan Looney、Michael Scharfはこの文書の以前のドラフト。
Author's Address
著者の住所
Mark Allman International Computer Science Institute 2150 Shattuck Ave., Suite 1100 Berkeley, CA 94704 United States of America
Mark Allman International Computer Science Institute 2150 Shattuck Ave.、Suite 1100 Berkeley、CA 94704アメリカ合衆国
Email: mallman@icir.org
URI: https://www.icir.org/mallman