[要約] RFC 7765は、TCPおよびSCTPのRTO再起動に関するガイドラインを提供しています。このRFCの目的は、ネットワークの異常状態によって引き起こされるRTOの問題を解決し、通信の信頼性とパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) P. Hurtig
Request for Comments: 7765 A. Brunstrom
Category: Experimental Karlstad University
ISSN: 2070-1721 A. Petlund
Simula Research Laboratory AS
M. Welzl
University of Oslo
February 2016
TCP and Stream Control Transmission Protocol (SCTP) RTO Restart
TCPおよびストリーム制御伝送プロトコル（SCTP）RTO再起動
Abstract
概要
This document describes a modified sender-side algorithm for managing the TCP and Stream Control Transmission Protocol (SCTP) retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer using a smaller timeout duration, so that the effective retransmission timeout (RTO) becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short lived or application limited.
このドキュメントでは、TCPとStream Control Transmission Protocol（SCTP）再送信タイマーを管理するための変更された送信側のアルゴリズムについて説明します。変更のRTO再起動（RTOR）により、トランスポートはより短いタイムアウト期間を使用して再送信タイマーを再起動できるため、高速再送信を使用できない状況では、有効な再送信タイムアウト（RTO）がより積極的になります。これにより、有効期間が短い接続やアプリケーションが制限されている接続の損失検出と回復を高速化できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7765.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7765で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. RTO Overview and Rationale for RTOR . . . . . . . . . . . . . 4
4. RTOR Algorithm . . . . . . . . . . . . . . . . . . . . . . . 6
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Spurious Timeouts . . . . . . . . . . . . . . . . . . . . 7
5.3. Tracking Outstanding and Previously Unsent Segments . . . 8
6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 9
7. SCTP Socket API Considerations . . . . . . . . . . . . . . . 10
7.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Socket Option for Controlling the RTO Restart Support
(SCTP_RTO_RESTART) . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
TCP and SCTP use two almost identical mechanisms to detect and recover from data loss, specified in [RFC6298] and [RFC5681] for TCP and [RFC4960] for SCTP. First, if transmitted data is not acknowledged within a certain amount of time, a retransmission timeout (RTO) occurs and the data is retransmitted. While the RTO is based on measured round-trip times (RTTs) between the sender and receiver, it also has a conservative lower bound of 1 second to ensure that delayed data are not mistaken as lost. Second, when a sender receives duplicate acknowledgments or similar information via selective acknowledgments, the fast retransmit algorithm suspects data loss and can trigger a retransmission. Duplicate (and selective) acknowledgments are generated by a receiver when data arrives out of order. As both data loss and data reordering cause out-of-order arrival, fast retransmit waits for three out-of-order notifications before considering the corresponding data as lost. In some situations, however, the amount of outstanding data is not enough to trigger three such acknowledgments, and the sender must rely on lengthy RTOs for loss recovery.
TCPとSCTPは、2つのほぼ同じメカニズムを使用して、データ損失を検出および回復します。TCPの[RFC6298]および[RFC5681]とSCTPの[RFC4960]で指定されています。まず、送信されたデータが特定の時間内に確認応答されない場合、再送信タイムアウト（RTO）が発生し、データが再送信されます。 RTOは送信者と受信者の間の測定された往復時間（RTT）に基づいていますが、遅延データが失われたものと間違われないように、1秒という控えめな下限もあります。第2に、送信者が選択的な確認応答を介して重複する確認応答または同様の情報を受信すると、高速再送信アルゴリズムがデータ損失を疑い、再送信をトリガーできます。データが順不同で到着すると、重複した（そして選択的な）確認応答が受信者によって生成されます。データの損失とデータの並べ替えの両方が順序どおりでない到着を引き起こすため、高速再送信は、対応するデータが失われたと見なす前に、3つの順序が狂った通知を待ちます。ただし、状況によっては、未処理のデータの量が3つのそのような確認応答をトリガーするのに十分ではなく、送信者は損失回復のために長いRTOに依存する必要があります。
The amount of outstanding data can be small for several reasons:
未処理のデータの量は、いくつかの理由で少なくなる可能性があります。
(1) The connection is limited by congestion control when the path has a low total capacity (bandwidth-delay product) or the connection's share of the capacity is small. It is also limited by congestion control in the first few RTTs of a connection or after an RTO when the available capacity is probed using slow-start.
（1）パスの総容量が小さい場合（帯域幅遅延積）、または接続の容量のシェアが小さい場合、接続は輻輳制御によって制限されます。また、接続の最初の数個のRTTでの輻輳制御、またはスロースタートを使用して利用可能な容量がプローブされるときのRTOの後に制限されます。
(2) The connection is limited by the receiver's available buffer space.
（2）接続は、レシーバーの使用可能なバッファースペースによって制限されます。
(3) The connection is limited by the application if the available capacity of the path is not fully utilized (e.g., interactive applications) or is at the end of a transfer.
（3）パスの利用可能な容量が完全に利用されていない場合（インタラクティブアプリケーションなど）、または転送の最後にある場合、接続はアプリケーションによって制限されます。
While the reasons listed above are valid for any flow, the third reason is most common for applications that transmit short flows or use a bursty transmission pattern. A typical example of applications that produce short flows are web-based applications. [RJ10] shows that 70% of all web objects, found at the top 500 sites, are too small for fast retransmit to work. [FDT13] shows that about 77% of all retransmissions sent by a major web service are sent after RTO expiry. Applications with bursty transmission patterns often send data in response to actions or as a reaction to real life events. Typical examples of such applications are stock-trading systems, remote computer operations, online games, and web-based applications using persistent connections. What is special about this class of applications is that they are often time dependent, and extra latency can reduce the application service level [P09].
上記の理由はどのフローにも当てはまりますが、3番目の理由は、短いフローを送信したり、バースト送信パターンを使用したりするアプリケーションで最も一般的です。短いフローを生成するアプリケーションの典型的な例は、Webベースのアプリケーションです。 [RJ10]は、上位500サイトにあるすべてのWebオブジェクトの70％が小さすぎて高速再送信が機能しないことを示しています。 [FDT13]は、主要なWebサービスによって送信されるすべての再送信の約77％がRTOの期限切れ後に送信されることを示しています。バースト性の高い送信パターンを持つアプリケーションは、アクションに応答して、または実際のイベントへの反応として、データを送信することがよくあります。このようなアプリケーションの典型的な例は、株取引システム、リモートコンピューター操作、オンラインゲーム、および永続的な接続を使用するWebベースのアプリケーションです。このクラスのアプリケーションの特別な点は、多くの場合それらが時間に依存することであり、余分なレイテンシがアプリケーションのサービスレベルを低下させる可能性があります[P09]。
The RTO Restart (RTOR) mechanism described in this document makes the effective RTO slightly more aggressive when the amount of outstanding data is too small for fast retransmit to work, in an attempt to enable faster loss recovery while being robust to reordering. While RTOR still conforms to the requirement for when a segment can be retransmitted, specified in [RFC6298] for TCP and [RFC4960] for SCTP, it could increase the risk of spurious timeouts. To determine whether this modification is safe to deploy and enable by default, further experimentation is required. Section 5 discusses experiments still needed, including evaluations in environments where the risk of spurious retransmissions are increased, e.g., mobile networks with highly varying RTTs.
このドキュメントで説明されているRTO再起動（RTOR）メカニズムは、未処理のデータの量が小さすぎて高速再送が機能しない場合に、効果的なRTOを少し積極的にします。 RTORは、TCPの場合は[RFC6298]、SCTPの場合は[RFC4960]で指定されているセグメントをいつ再送信できるかという要件に引き続き準拠していますが、偽のタイムアウトのリスクを高める可能性があります。この変更が安全に展開され、デフォルトで有効になるかどうかを判断するには、さらに実験が必要です。セクション5では、疑似再送信のリスクが高まる環境、たとえばRTTの変動が大きいモバイルネットワークでの評価を含め、依然として必要な実験について説明します。
The remainder of this document describes RTOR and its implementation for TCP only, to make the document easier to read. However, the RTOR algorithm described in Section 4 is applicable also for SCTP. Furthermore, Section 7 details the SCTP socket API needed to control RTOR.
このドキュメントの残りの部分では、ドキュメントを読みやすくするために、RTORとTCPの実装のみについて説明します。ただし、セクション4で説明するRTORアルゴリズムは、SCTPにも適用できます。さらに、セクション7では、RTORを制御するために必要なSCTPソケットAPIについて詳しく説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document introduces the following variables:
このドキュメントでは、次の変数を紹介します。
o The number of previously unsent segments (prevunsnt): The number of segments that a sender has queued for transmission, but has not yet sent.
o 以前に送信されていないセグメントの数（prevunsnt）：送信者が送信のためにキューに入れたが、まだ送信していないセグメントの数。
o RTO Restart threshold (rrthresh): RTOR is enabled whenever the sum of the number of outstanding and previously unsent segments (prevunsnt) is below this threshold.
o RTO再始動しきい値（rrthresh）：RTORは、未解決のセグメントと以前に送信されていないセグメント（prevunsnt）の数の合計がこのしきい値を下回ると有効になります。
The RTO management algorithm described in [RFC6298] recommends that the retransmission timer be restarted when an acknowledgment (ACK) that acknowledges new data is received and there is still outstanding data. The restart is conducted to guarantee that unacknowledged segments will be retransmitted after approximately RTO seconds. The standardized RTO timer management is illustrated in Figure 1, where a TCP sender transmits three segments to a receiver. The arrival of the first and second segment triggers a delayed ACK (delACK) [RFC1122], which restarts the RTO timer at the sender. The RTO is restarted approximately one RTT after the transmission of the third segment. Thus, if the third segment is lost, as indicated in Figure 1, the effective loss detection time becomes "RTO + RTT" seconds. In some situations, the effective loss detection time becomes even longer. Consider a scenario where only two segments are outstanding. If the second segment is lost, the time to expire the delACK timer will also be included in the effective loss detection time.
[RFC6298]で説明されているRTO管理アルゴリズムは、新しいデータを確認する確認（ACK）が受信され、未処理のデータがある場合に、再送信タイマーを再開することを推奨しています。再起動は、約RTO秒後に未確認のセグメントが再送信されることを保証するために行われます。標準化されたRTOタイマー管理を図1に示します。TCP送信側は3つのセグメントを受信側に送信します。最初と2番目のセグメントが到着すると、遅延ACK（delACK）[RFC1122]がトリガーされ、送信側でRTOタイマーが再開されます。 RTOは、3番目のセグメントの送信後、約1 RTTで再開されます。したがって、図1に示すように、3番目のセグメントが失われた場合、有効な損失検出時間は「RTO + RTT」秒になります。状況によっては、有効な損失検出時間がさらに長くなります。 2つのセグメントのみが未処理であるシナリオを考えます。 2番目のセグメントが失われた場合、delACKタイマーの有効期限も有効な損失検出時間に含まれます。
Sender Receiver
...
DATA [SEG 1] ----------------------> (ack delayed)
DATA [SEG 2] ----------------------> (send ack)
DATA [SEG 3] ----X /-------- ACK
(restart RTO) <----------/
...
(RTO expiry)
DATA [SEG 3] ---------------------->
Figure 1: RTO Restart Example
図1：RTO再起動の例
For bulk traffic, the current approach is beneficial -- it is described in [EL04] to act as a "safety margin" that compensates for some of the problems that the authors have identified with the standard RTO calculation. Notably, the authors of [EL04] also state that "this safety margin does not exist for highly interactive applications where often only a single packet is in flight." In general, however, as long as enough segments arrive at a receiver to enable fast retransmit, RTO-based loss recovery should be avoided. RTOs should only be used as a last resort, as they drastically lower the congestion window as compared to fast retransmit.
バルクトラフィックについては、現在のアプローチが有益です。[EL04]では、著者が標準RTO計算で特定した問題のいくつかを補償する「安全マージン」として機能することが説明されています。特に、[EL04]の作成者はまた、「この安全域は、1つのパケットのみが実行されていることが多い高度にインタラクティブなアプリケーションには存在しない」とも述べています。ただし、一般に、高速再送信を可能にするのに十分なセグメントが受信機に到着する限り、RTOベースの損失回復は回避する必要があります。 RTOは、高速再送信と比較して輻輳ウィンドウを大幅に下げるため、最後の手段としてのみ使用する必要があります。
Although fast retransmit is preferable, there are situations where timeouts are appropriate or are the only choice. For example, if the network is severely congested and no segments arrive, RTO-based recovery should be used. In this situation, the time to recover from the loss(es) will not be the performance bottleneck. However, for connections that do not utilize enough capacity to enable fast retransmit, RTO-based loss detection is the only choice, and the time required for this can become a performance bottleneck.
高速な再送信が望ましいですが、タイムアウトが適切であるか、それが唯一の選択肢である状況もあります。たとえば、ネットワークが非常に混雑していて、セグメントが到着しない場合は、RTOベースのリカバリを使用する必要があります。この状況では、損失から回復する時間がパフォーマンスのボトルネックになることはありません。ただし、高速再送信を可能にするのに十分な容量を使用しない接続の場合、RTOベースの損失検出が唯一の選択肢であり、これに必要な時間がパフォーマンスのボトルネックになる可能性があります。
To enable faster loss recovery for connections that are unable to use fast retransmit, RTOR can be used. This section specifies the modifications required to use RTOR. By resetting the timer to "RTO - T_earliest", where T_earliest is the time elapsed since the earliest outstanding segment was transmitted, retransmissions will always occur after exactly RTO seconds.
高速再送信を使用できない接続の損失回復を高速化するには、RTORを使用できます。このセクションでは、RTORを使用するために必要な変更について説明します。タイマーを "RTO-T_earliest"にリセットすることにより、T_earliestは最も古い未解決のセグメントが送信されてからの経過時間であり、正確なRTO秒後に常に再送信が行われます。
This document specifies an OPTIONAL sender-only modification to TCP and SCTP, which updates step 5.3 in Section 5 of [RFC6298] (and a similar update in Section 6.3.2 of [RFC4960] for SCTP). A sender that implements this method MUST follow the algorithm below:
このドキュメントでは、[RFC6298]のセクション5のステップ5.3を更新する、TCPとSCTPに対するオプションの送信側のみの変更を指定します（SCTPについては[RFC4960]のセクション6.3.2の同様の更新）。このメソッドを実装する送信者は、以下のアルゴリズムに従う必要があります。
When an ACK is received that acknowledges new data:
新しいデータを確認するACKを受信すると、次のようになります。
(1) Set T_earliest = 0.
（1）T_earliest = 0に設定します。
(2) If the sum of the number of outstanding and previously unsent segments (prevunsnt) is less than an RTOR threshold (rrthresh), set T_earliest to the time elapsed since the earliest outstanding segment was sent.
（2）未解決のセグメントと以前に送信されていないセグメント（prevunsnt）の数の合計がRTORしきい値（rrthresh）未満の場合、T_earliestを、最も古い未解決のセグメントが送信されてからの経過時間に設定します。
(3) Restart the retransmission timer so that it will expire after (for the current value of RTO):
（3）再送信タイマーを再起動して、（RTOの現在の値に対して）後に期限切れになるようにします。
(a) RTO - T_earliest, if RTO - T_earliest > 0.
（a）RTO-T_earliest> 0の場合、RTO-T_earliest
(b) RTO, otherwise.
（b）RTO、それ以外の場合。
The RECOMMENDED value of rrthresh is four, as this value will ensure that RTOR is only used when fast retransmit cannot be triggered. With this update, TCP implementations MUST track the time elapsed since the transmission of the earliest outstanding segment (T_earliest). As RTOR is only used when the amount of outstanding and previously unsent data is less than rrthresh segments, TCP implementations also need to track whether the amount of outstanding and previously unsent data is more, equal, or less than rrthresh segments. Although some packet-based TCP implementations (e.g., Linux TCP) already track both the transmission times of all segments and also the number of outstanding segments, not all implementations do. Section 5.3 describes how to implement segment tracking for a general TCP implementation. To use RTOR, the calculated expiration time MUST be positive (step 3(a) in the list above); this is required to ensure that RTOR does not trigger retransmissions prematurely when previously retransmitted segments are acknowledged.
rrthreshの推奨値は4です。この値により、高速再送信をトリガーできない場合にのみRTORが使用されるようになります。この更新では、TCP実装は、最も古い未解決のセグメント（T_earliest）の送信からの経過時間を追跡する必要があります。 RTORは未処理で以前に送信されていないデータの量がrrthreshセグメントより少ない場合にのみ使用されるため、TCP実装では、未処理で以前に送信されていないデータの量がrrthreshセグメントより多いか、等しいか、少ないかを追跡する必要もあります。一部のパケットベースのTCP実装（Linux TCPなど）は、すでにすべてのセグメントの送信時間と未処理のセグメントの数の両方を追跡していますが、すべての実装が追跡しているわけではありません。セクション5.3では、一般的なTCP実装のセグメント追跡を実装する方法について説明します。 RTORを使用するには、計算された有効期限が正でなければなりません（上記のリストのステップ3（a））。これは、以前に再送信されたセグメントが確認されたときに、RTORが時期尚早に再送信をトリガーしないようにするために必要です。
Although RTOR conforms to the requirement in [RFC6298] that segments must not be retransmitted earlier than RTO seconds after their original transmission, RTOR makes the effective RTO more aggressive. In this section, we discuss the applicability and the issues related to RTOR.
RTORは[RFC6298]の要件に準拠していますが、セグメントは元の送信からRTO秒よりも前に再送信してはならないという要件がありますが、RTORは効果的なRTOをより積極的にします。このセクションでは、RTORに関連する適用性と問題について説明します。
The currently standardized algorithm has been shown to add at least one RTT to the loss recovery process in TCP [LS00] and SCTP [HB11] [PBP09]. For applications that have strict timing requirements (e.g., interactive web) rather than throughput requirements, using RTOR could be beneficial because the RTT and the delACK timer of receivers are often large components of the effective loss recovery time. Measurements in [HB11] have shown that the total transfer time of a lost segment (including the original transmission time and the loss recovery time) can be reduced by 35% using RTOR. These results match those presented in [PGH06] and [PBP09], where RTOR is shown to significantly reduce retransmission latency.
現在標準化されているアルゴリズムは、TCP [LS00]およびSCTP [HB11] [PBP09]の損失回復プロセスに少なくとも1つのRTTを追加することが示されています。スループット要件ではなく、タイミング要件が厳しいアプリケーション（インタラクティブWebなど）では、レシーバーのRTTとdelACKタイマーが効果的な損失回復時間の大きな要素となることが多いため、RTORを使用すると効果的です。 [HB11]の測定では、RTORを使用すると、失われたセグメントの合計転送時間（元の送信時間と損失回復時間を含む）を35％削減できることが示されています。これらの結果は、[PGH06]と[PBP09]に示されている結果と一致しています。RTORは、再送信の待ち時間を大幅に短縮することが示されています。
There are also traffic types that do not benefit from RTOR. One example of such traffic is bulk transmission. The reason why bulk traffic does not benefit from RTOR is that such traffic flows mostly have four or more segments outstanding, allowing loss recovery by fast retransmit. However, there is no harm in using RTOR for such traffic as the algorithm is only active when the amount of outstanding and unsent segments are less than rrthresh (default 4).
RTORの恩恵を受けないトラフィックタイプもあります。そのようなトラフィックの1つの例は、バルク送信です。バルクトラフィックがRTORの恩恵を受けない理由は、そのようなトラフィックフローには、主に4つ以上の未処理のセグメントがあり、高速再送信による損失回復を可能にするためです。ただし、未処理のセグメントと未送信のセグメントの量がrrthresh（デフォルトは4）未満の場合にのみアルゴリズムがアクティブになるため、このようなトラフィックにRTORを使用しても害はありません。
Given that RTOR is a mostly conservative algorithm, it is suitable for experimentation as a system-wide default for TCP traffic.
RTORはほとんど保守的なアルゴリズムであるため、TCPトラフィックのシステム全体のデフォルトとして実験に適しています。
RTOR can in some situations reduce the loss detection time and thereby increase the risk of spurious timeouts. In theory, the retransmission timer has a lower bound of 1 second [RFC6298], which limits the risk of having spurious timeouts. However, in practice, most implementations use a significantly lower value. Initial measurements show slight increases in the number of spurious timeouts when such lower values are used [RHB15]. However, further experiments, in different environments and with different types of traffic, are encouraged to quantify such increases more reliably.
RTORは、状況によっては損失検出時間を短縮し、それによって偽のタイムアウトのリスクを増大させる可能性があります。理論的には、再送信タイマーの下限は1秒であり[RFC6298]、偽のタイムアウトが発生するリスクを制限します。ただし、実際には、ほとんどの実装で大幅に低い値が使用されます。初期の測定では、このような低い値を使用すると、スプリアスタイムアウトの数がわずかに増加することが示されています[RHB15]。ただし、さまざまな環境でさまざまなタイプのトラフィックを使用するさらなる実験では、そのような増加をより確実に定量化することが推奨されます。
Does a slightly increased risk matter? Generally, spurious timeouts have a negative effect on the network as segments are transmitted needlessly. However, recent experiments do not show a significant increase in network load for a number of realistic scenarios [RHB15]. Another problem with spurious retransmissions is related to the performance of TCP/SCTP, as the congestion window is reduced to one segment when timeouts occur [RFC5681]. This could be a potential problem for applications transmitting multiple bursts of data within a single flow, e.g., web-based HTTP/1.1 and HTTP/2.0 applications. However, results from recent experiments involving persistent web traffic [RHB15] revealed a net gain using RTOR. Other types of flows, e.g., long-lived bulk flows, are not affected as the algorithm is only applied when the amount of outstanding and unsent segments is less than rrthresh. Furthermore, short-lived and application-limited flows are typically not affected as they are too short to experience the effect of congestion control or have a transmission rate that is quickly attainable.
わずかに増加したリスクは重要ですか？一般に、セグメントが不必要に送信されるため、スプリアスタイムアウトはネットワークに悪影響を及ぼします。ただし、最近の実験では、いくつかの現実的なシナリオ[RHB15]のネットワーク負荷の大幅な増加は示されていません。タイムアウトが発生すると輻輳ウィンドウが1つのセグメントに減少するため、偽の再送信に関する別の問題はTCP / SCTPのパフォーマンスに関連しています[RFC5681]。これは、単一のフロー内でデータの複数のバーストを送信するアプリケーション（たとえば、WebベースのHTTP / 1.1およびHTTP / 2.0アプリケーション）の潜在的な問題になる可能性があります。ただし、持続的なWebトラフィックを含む最近の実験[RHB15]の結果は、RTORを使用した正味の増加を明らかにしました。アルゴリズムは、未処理のセグメントと未送信のセグメントの量がrrthresh未満の場合にのみ適用されるため、他のタイプのフロー（たとえば、長期間のバルクフロー）は影響を受けません。さらに、短期間でアプリケーションが制限されたフローは、輻輳制御の効果を体験するには短すぎるか、すぐに達成できる伝送レートを持っているため、通常は影響を受けません。
While a slight increase in spurious timeouts has been observed using RTOR, it is not clear whether or not the effects of this increase mandate any future algorithmic changes -- especially since most modern operating systems already include mechanisms to detect [RFC3522] [RFC3708] [RFC5682] and resolve [RFC4015] possible problems with spurious retransmissions. Further experimentation is needed to determine this and thereby move this specification from Experimental to the Standards Track. For instance, RTOR has not been evaluated in the context of mobile networks. Mobile networks often incur highly variable RTTs (delay spikes), due to e.g., handovers, and would therefore be a useful scenario for further experimentation.
RTORを使用してスプリアスタイムアウトのわずかな増加が観察されていますが、この増加の影響が将来のアルゴリズムの変更を要求するかどうかは明らかではありません。 RFC5682]および[RFC4015]疑似再送信で起こりうる問題を解決します。これを決定し、それによってこの仕様を実験から標準トラックに移すには、さらなる実験が必要です。たとえば、RTORはモバイルネットワークのコンテキストでは評価されていません。モバイルネットワークでは、ハンドオーバーなどにより、非常に変動の大きいRTT（遅延スパイク）が発生することが多いため、今後の実験に役立つシナリオとなります。
The method of tracking outstanding and previously unsent segments will probably differ depending on the actual TCP implementation. For packet-based TCP implementations, tracking outstanding segments is often straightforward and can be implemented using a simple counter. For byte-based TCP stacks, it is a more complex task. Section 3.2 of [RFC5827] outlines a general method of tracking the number of outstanding segments. The same method can be used for RTOR. The implementation will have to track segment boundaries to form an understanding as to how many actual segments have been transmitted but not acknowledged. This can be done by the sender tracking the boundaries of the rrthresh segments on the right side of the current window (which involves tracking rrthresh + 1 sequence numbers in TCP). This could be done by keeping a circular list of the segment boundaries, for instance. Cumulative ACKs that do not fall within this region indicate that at least rrthresh segments are outstanding, and therefore RTOR is not enabled. When the outstanding window becomes small enough that RTOR can be invoked, a full understanding of the number of outstanding segments will be available from the rrthresh + 1 sequence numbers retained. (Note: the implicit sequence number consumed by the TCP FIN bit can also be included in the tracking of segment boundaries.)
未解決のセグメントと以前に送信されていないセグメントを追跡する方法は、実際のTCP実装によって異なる可能性があります。パケットベースのTCP実装の場合、未処理のセグメントの追跡は簡単であることが多く、単純なカウンターを使用して実装できます。バイトベースのTCPスタックの場合、これはより複雑なタスクです。 [RFC5827]のセクション3.2は、未処理のセグメントの数を追跡する一般的な方法の概要を示しています。同じ方法をRTORにも使用できます。実装は、セグメント境界を追跡して、送信されたが確認されていない実際のセグメントの数に関する理解を形成する必要があります。これは、現在のウィンドウの右側にあるrrthreshセグメントの境界を追跡する送信者が実行できます（TCPでrrthresh + 1シーケンス番号を追跡する必要があります）。これは、例えば、セグメント境界の循環リストを保持することで実行できます。この領域に含まれない累積ACKは、少なくともrrthreshセグメントが未解決であるため、RTORが有効になっていないことを示します。未解決のウィンドウが小さくなり、RTORを呼び出せるようになると、保持されているrrthresh + 1シーケンス番号から未解決のセグメントの数を完全に理解できます。 （注：TCP FINビットによって消費される暗黙のシーケンス番号も、セグメント境界の追跡に含めることができます。）
Tracking the number of previously unsent segments depends on the segmentation strategy used by the TCP implementation, not whether it is packet based or byte based. In the case where segments are formed directly on socket writes, the process of determining the number of previously unsent segments should be trivial. In the case that unsent data can be segmented (or resegmented) as long as it is still unsent, a straightforward strategy could be to divide the amount of unsent data (in bytes) with the Sender Maximum Segment Size (SMSS) to obtain an estimate. In some cases, such an estimation could be too simplistic, depending on the segmentation strategy of the TCP implementation. However, this estimation is not critical to RTOR. The tracking of prevunsnt is only made to optimize a corner case in which RTOR was unnecessarily disabled. Implementations can use a simplified method by setting prevunsnt to rrthresh whenever previously unsent data is available, and set prevunsnt to zero when no new data is available. This will disable RTOR in the presence of unsent data and only use the number of outstanding segments to enable/disable RTOR.
以前に送信されなかったセグメントの数の追跡は、TCPベースの実装で使用されるセグメンテーション戦略に依存し、パケットベースかバイトベースかに依存しません。ソケット書き込みでセグメントが直接形成される場合、以前に送信されていないセグメントの数を決定するプロセスは簡単です。未送信データがまだ送信されていない限り、未送信データをセグメント化（または再セグメント化）できる場合、簡単な戦略は、未送信データの量（バイト単位）を送信者最大セグメントサイズ（SMSS）で除算して見積もりを取得することです。 。場合によっては、TCP実装のセグメンテーション戦略によっては、そのような見積もりが単純すぎる場合があります。ただし、この推定はRTORにとって重要ではありません。 prevunsntの追跡は、RTORが不必要に無効にされたコーナーケースを最適化するためにのみ行われます。実装では、以前に送信されていないデータが利用可能な場合は常にprevunsntをrrthreshに設定し、新しいデータが利用できない場合はprevunsntをゼロに設定することで、簡略化された方法を使用できます。これにより、未送信のデータがある場合にRTORが無効になり、未処理のセグメントの数のみを使用してRTORを有効/無効にします。
There are several proposals that address the problem of not having enough ACKs for loss recovery. In what follows, we explain why the mechanism described here is complementary to these approaches:
損失回復のための十分なACKがないという問題に対処するいくつかの提案があります。以下では、ここで説明するメカニズムがこれらのアプローチを補完する理由を説明します。
The limited transmit mechanism [RFC3042] allows a TCP sender to transmit a previously unsent segment for each of the first two duplicate acknowledgements (dupACKs). By transmitting new segments, the sender attempts to generate additional dupACKs to enable fast retransmit. However, limited transmit does not help if no previously unsent data is ready for transmission. [RFC5827] specifies an early retransmit algorithm to enable fast loss recovery in such situations. By dynamically lowering the number of dupACKs needed for fast retransmit (dupthresh), based on the number of outstanding segments, a smaller number of dupACKs is needed to trigger a retransmission. In some situations, however, the algorithm is of no use or might not work properly. First, if a single segment is outstanding and lost, it is impossible to use early retransmit. Second, if ACKs are lost, early retransmit cannot help. Third, if the network path reorders segments, the algorithm might cause more spurious retransmissions than fast retransmit. The recommended value of RTOR's rrthresh variable is based on the dupthresh, but it is possible to adapt to allow tighter integration with other experimental algorithms such as early retransmit.
制限された送信メカニズム[RFC3042]により、TCP送信者は、最初の2つの重複する確認応答（dupACK）のそれぞれについて、以前に送信されていないセグメントを送信できます。新しいセグメントを送信することにより、送信者は追加のdupACKを生成して、高速再送信を可能にします。ただし、以前に送信されていないデータを送信する準備ができていない場合、送信制限は役に立ちません。 [RFC5827]は、そのような状況での高速損失回復を可能にする早期再送信アルゴリズムを指定しています。未処理のセグメントの数に基づいて、高速再送信（dupthresh）に必要なdupACKの数を動的に減らすことにより、再送信をトリガーするために必要なdupACKの数が少なくなります。ただし、状況によっては、アルゴリズムが役に立たないか、正しく機能しない場合があります。まず、1つのセグメントが未処理で失われている場合、早期再送信を使用することはできません。第2に、ACKが失われた場合、早期の再送信は役に立ちません。 3番目に、ネットワークパスがセグメントを並べ替えると、アルゴリズムは高速再送信よりも疑似再送信を引き起こす可能性があります。 RTORのrrthresh変数の推奨値は、dupthreshに基づいていますが、早期再送信などの他の実験的アルゴリズムとのより緊密な統合を可能にするように適合させることは可能です。
Tail Loss Probe [TLP] is a proposal to send up to two "probe segments" when a timer fires that is set to a value smaller than the RTO. A "probe segment" is a new segment if new data is available, else it is a retransmission. The intention is to compensate for sluggish RTO behavior in situations where the RTO greatly exceeds the RTT, which, according to measurements reported in [TLP], is not uncommon. Furthermore, TLP also tries to circumvent the congestion window reset to one segment by instead enabling fast recovery. The probe timeout (PTO) is normally two RTTs, and a spurious PTO is less risky than a spurious RTO because it would not have the same negative effects (clearing the scoreboard and restarting with slow-start). TLP is a more advanced mechanism than RTOR, requiring e.g., SACK to work, and is often able to further reduce loss recovery times. However, it also noticeably increases the amount of spurious retransmissions, as compared to RTOR [RHB15].
テールロスプローブ[TLP]は、タイマーが作動したときに最大2つの「プローブセグメント」を送信する提案であり、RTOより小さい値に設定されています。 「プローブセグメント」は、新しいデータが利用可能な場合は新しいセグメントであり、それ以外の場合は再送信です。その意図は、RTOがRTTを大幅に超える状況でのRTOの緩慢な動作を補償することです。これは、[TLP]で報告された測定によると、珍しいことではありません。さらに、TLPは高速リカバリを有効にすることで、1つのセグメントへの輻輳ウィンドウのリセットを回避しようとします。プローブタイムアウト（PTO）は通常2つのRTTであり、スプリアスPTOはスプリアスRTOよりもリスクが低くなります（スコアボードをクリアしてスロースタートで再起動するため）。 TLPはRTORよりも高度なメカニズムであり、SACKなどが機能する必要があり、多くの場合、損失回復時間をさらに短縮できます。ただし、RTOR [RHB15]と比較して、疑似再送信の量が著しく増加します。
TLP is applicable in situations where RTOR does not apply, and it could overrule (yielding a similar general behavior, but with a lower timeout) RTOR in cases where the number of outstanding segments is smaller than four and no new segments are available for transmission. The PTO has the same inherent problem of restarting the timer on an incoming ACK and could be combined with a strategy similar to RTOR's to offer more consistent timeouts.
TLPは、RTORが適用されず、未解決のセグメントの数が4未満で、送信に使用できる新しいセグメントがない場合に、RTORを無効にする（同様の一般的な動作をもたらすが、タイムアウトがより短い）状況に適用できます。 PTOには、着信ACKでタイマーを再起動するという同じ固有の問題があり、RTORと同様の戦略と組み合わせて、より一貫したタイムアウトを提供できます。
This section describes how the socket API for SCTP defined in [RFC6458] is extended to control the usage of RTO restart for SCTP.
このセクションでは、[RFC6458]で定義されているSCTPのソケットAPIを拡張して、SCTPのRTO再起動の使用を制御する方法について説明します。
Please note that this section is informational only.
このセクションは情報提供のみを目的としています。
This section uses data types from [IEEE.9945]: uintN_t means an unsigned integer of exactly N bits (e.g., uint16_t). This is the same as in [RFC6458].
このセクションでは、[IEEE.9945]のデータ型を使用します。uintN_tは、正確にNビットの符号なし整数を意味します（たとえば、uint16_t）。これは[RFC6458]と同じです。
7.2. Socket Option for Controlling the RTO Restart Support (SCTP_RTO_RESTART)
7.2. RTO再起動サポートを制御するためのソケットオプション（SCTP_RTO_RESTART）
This socket option allows the enabling or disabling of RTO Restart for SCTP associations.
このソケットオプションを使用すると、SCTPアソシエーションのRTO再起動を有効または無効にできます。
Whether or not RTO restart is enabled per default is implementation specific.
RTOの再起動がデフォルトで有効になっているかどうかは、実装によって異なります。
This socket option uses IPPROTO_SCTP as its level and SCTP_RTO_RESTART as its name. It can be used with getsockopt() and setsockopt(). The socket option value uses the following structure defined in [RFC6458]:
このソケットオプションは、レベルとしてIPPROTO_SCTPを使用し、名前としてSCTP_RTO_RESTARTを使用します。 getsockopt()およびsetsockopt()で使用できます。ソケットオプション値は、[RFC6458]で定義されている次の構造を使用します。
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, this parameter indicates upon which association the user is performing an action. The special sctp_assoc_t SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used in assoc_id for setsockopt(). For getsockopt(), the special value SCTP_FUTURE_ASSOC can be used in assoc_id, but it is an error to use SCTP_{CURRENT|ALL}_ASSOC in assoc_id.
assoc_id：このパラメーターは、1対1スタイルのソケットでは無視されます。 1対多スタイルのソケットの場合、このパラメーターは、ユーザーがアクションを実行している関連付けを示します。特別なsctp_assoc_t SCTP_ {FUTURE | CURRENT | ALL} _ASSOCは、setsockopt()のassoc_idでも使用できます。 getsockopt()の場合、assoc_idで特別な値SCTP_FUTURE_ASSOCを使用できますが、assoc_idでSCTP_ {CURRENT | ALL} _ASSOCを使用するとエラーになります。
assoc_value: A non-zero value encodes the enabling of RTO restart whereas a value of 0 encodes the disabling of RTO restart.
assoc_value：ゼロ以外の値はRTO再起動の有効化をエンコードしますが、値0はRTO再起動の無効化をエンコードします。
sctp_opt_info() needs to be extended to support SCTP_RTO_RESTART.
SCTP_RTO_RESTARTをサポートするには、sctp_opt_info()を拡張する必要があります。
This document specifies an experimental sender-only modification to TCP and SCTP. The modification introduces a change in how to set the retransmission timer's value when restarted. Therefore, the security considerations found in [RFC6298] apply to this document. No additional security problems have been identified with RTO Restart at this time.
このドキュメントでは、TCPとSCTPに対する実験的な送信側のみの変更について説明します。この変更により、再起動時に再送信タイマーの値を設定する方法が変更されました。したがって、[RFC6298]にあるセキュリティに関する考慮事項がこのドキュメントに適用されます。現時点では、RTOの再起動による追加のセキュリティ問題は確認されていません。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<http://www.rfc-editor.org/info/ rfc1122>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, DOI 10.17487/RFC3042, January 2001, <http://www.rfc-editor.org/info/rfc3042>.
[RFC3042] Allman、M.、Balakrishnan、H。、およびS. Floyd、「Enhancing TCP's Loss Recovery Using Using Transmit」、RFC 3042、DOI 10.17487 / RFC3042、2001年1月、<http：//www.rfc-editor。 org / info / rfc3042>。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, DOI 10.17487/RFC3522, April 2003, <http://www.rfc-editor.org/info/rfc3522>.
[RFC3522] Ludwig、R.およびM. Meyer、「The Eifel Detection Algorithm for TCP」、RFC 3522、DOI 10.17487 / RFC3522、2003年4月、<http://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, <http://www.rfc-editor.org/info/rfc3708>.
[RFC3708]ブラントン、E。およびM.オールマン、「TCP重複選択的確認応答（DSACK）およびストリーム制御伝送プロトコル（SCTP）重複伝送シーケンス番号（TSN）を使用して偽の再送を検出する」、RFC 3708、DOI 10.17487 / RFC3708、 2004年2月、<http://www.rfc-editor.org/info/rfc3708>。
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, DOI 10.17487/RFC4015, February 2005, <http://www.rfc-editor.org/info/rfc4015>.
[RFC4015] Ludwig、R。およびA. Gurtov、「The Eifel Response Algorithm for TCP」、RFC 4015、DOI 10.17487 / RFC4015、2005年2月、<http://www.rfc-editor.org/info/rfc4015>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<http://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, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<http://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, <http://www.rfc-editor.org/info/rfc5682>.
[RFC5682] Sarolahti、P.、Kojo、M.、Yamamoto、K。、およびM. Hata、「Forward RTO-Recovery（F-RTO）：Detecting for Spurious Retransmission Timeouts with TCP」、RFC 5682、DOI 10.17487 / RFC5682、2009年9月、<http://www.rfc-editor.org/info/rfc5682>。
[RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and P. Hurtig, "Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)", RFC 5827, DOI 10.17487/RFC5827, May 2010, <http://www.rfc-editor.org/info/rfc5827>.
[RFC5827] Allman、M.、Avrachenkov、K.、Ayesta、U.、Blanton、J。、およびP. Hurtig、「TCPおよびStream Control Transmission Protocol（SCTP）の早期再送信」、RFC 5827、DOI 10.17487 / RFC5827 、2010年5月、<http://www.rfc-editor.org/info/rfc5827>。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <http://www.rfc-editor.org/info/rfc6298>.
[RFC6298] Paxson、V.、Allman、M.、Chu、J。、およびM. Sargent、「Computing TCP's Retransmission Timer」、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<http：//www.rfc- editor.org/info/rfc6298>。
[EL04] Ekstroem, H. and R. Ludwig, "The Peak-Hopper: A New End-to-End Retransmission Timer for Reliable Unicast Transport", IEEE INFOCOM 2004, DOI 10.1109/INFCOM.2004.1354671, March 2004.
[EL04] Ekstroem、H。およびR. Ludwig、「The Peak-Hopper：A New End-to-End Retransmission Timer for Reliable Unicast Transport」、IEEE INFOCOM 2004、DOI 10.1109 / INFCOM.2004.1354671、2004年3月。
[FDT13] Flach, T., Dukkipati, N., Terzis, A., Raghavan, B., Cardwell, N., Cheng, Y., Jain, A., Hao, S., Katz-Bassett, E., and R. Govindan, "Reducing Web Latency: the Virtue of Gentle Aggression", Proc. ACM SIGCOMM Conf., DOI 10.1145/2486001.2486014, August 2013.
[FDT13] Flach、T.、Dukkipati、N.、Terzis、A.、Raghavan、B.、Cardwell、N.、Cheng、Y.、Jain、A.、Hao、S.、Katz-Bassett、E。、およびR.ゴビンダン、「Webレイテンシの削減：穏やかな攻撃の美徳」、Proc。 ACM SIGCOMM会議、DOI 10.1145 / 2486001.2486014、2013年8月。
[HB11] Hurtig, P. and A. Brunstrom, "SCTP: designed for timely message delivery?", Springer Telecommunication Systems 47 (3-4), DOI 10.1007/s11235-010-9321-3, August 2011.
[HB11] Hurtig、P。およびA. Brunstrom、「SCTP：タイムリーなメッセージ配信用に設計されていますか？」、Springer Telecommunication Systems 47（3-4）、DOI 10.1007 / s11235-010-9321-3、2011年8月。
[IEEE.9945] IEEE/ISO/IEC, "International Standard - Information technology Portable Operating System Interface (POSIX) Base Specifications, Issue 7", IEEE 9945-2009, <http://standards.ieee.org/findstds/ standard/9945-2009.html>.
[IEEE.9945] IEEE / ISO / IEC、「International Standard-Information technology Portable Operating System Interface（POSIX）Base Specifications、Issue 7」、IEEE 9945-2009、<http://standards.ieee.org/findstds/ standard /9945-2009.html>。
[LS00] Ludwig, R. and K. Sklower, "The Eifel retransmission timer", ACM SIGCOMM Comput. Commun. Rev., 30(3), DOI 10.1145/382179.383014, July 2000.
[LS00] Ludwig、R. and K. Sklower、 "The Eifel retransmission timer"、ACM SIGCOMM Comput。コミュ。 Rev.、30（3）、DOI 10.1145 / 382179.383014、2000年7月。
[P09] Petlund, A., "Improving latency for interactive, thin-stream applications over reliable transport", Unipub PhD Thesis, Oct 2009.
[P09] Petlund、A。、「信頼性の高いトランスポートを介したインタラクティブなシンストリームアプリケーションのレイテンシの改善」、Unipub PhD論文、2009年10月。
[PBP09] Petlund, A., Beskow, P., Pedersen, J., Paaby, E., Griwodz, C., and P. Halvorsen, "Improving SCTP retransmission delays for time-dependent thin streams", Springer Multimedia Tools and Applications, 45(1-3), DOI 10.1007/s11042-009-0286-8, October 2009.
[PBP09] Petlund、A.、Beskow、P.、Pedersen、J.、Paaby、E.、Griwodz、C。、およびP. Halvorsen、「時間に依存するシンストリームのSCTP再送信遅延の改善」、Springerマルチメディアツールおよびアプリケーション、45（1-3）、DOI 10.1007 / s11042-009-0286-8、2009年10月。
[PGH06] Pedersen, J., Griwodz, C., and P. Halvorsen, "Considerations of SCTP Retransmission Delays for Thin Streams", IEEE LCN 2006, DOI 10.1109/LCN.2006.322082, November 2006.
[PGH06] Pedersen、J.、Griwodz、C。、およびP. Halvorsen、「Thin StreamsのSCTP再送信遅延の考慮事項」、IEEE LCN 2006、DOI 10.1109 / LCN.2006.322082、2006年11月。
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011, <http://www.rfc-editor.org/info/rfc6458>.
[RFC6458] Stewart、R.、Tuexen、M.、Poon、K.、Lei、P。、およびV. Yasevich、「Socket Controls Extensions for the Stream Control Transmission Protocol（SCTP）」、RFC 6458、DOI 10.17487 / RFC6458 、2011年12月、<http://www.rfc-editor.org/info/rfc6458>。
[RHB15] Rajiullah, M., Hurtig, P., Brunstrom, A., Petlund, A., and M. Welzl, "An Evaluation of Tail Loss Recovery Mechanisms for TCP", ACM SIGCOMM CCR 45 (1), DOI 10.1145/2717646.2717648, January 2015.
[RHB15] Rajiullah、M.、Hurtig、P.、Brunstrom、A.、Petlund、A。、およびM. Welzl、「TCPのテールロス回復メカニズムの評価」、ACM SIGCOMM CCR 45（1）、DOI 10.1145 /2717646.2717648、2015年1月。
[RJ10] Ramachandran, S., "Web metrics: Size and number of resources", May 2010, <https://goo.gl/0a6Q9A>.
[RJ10] Ramachandran、S。、「Webメトリック：リソースのサイズと数」、2010年5月、<https://goo.gl/0a6Q9A>。
[TLP] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses", Work in Progress, draft-dukkipati-tcpm-tcp-loss-probe-01, February 2013.
[TLP] Dukkipati、N.、Cardwell、N.、Cheng、Y。、およびM. Mathis、「Tail Loss Probe（TLP）：Algorithm for Fast Recovery for Tail Loss」、Work in Progress、draft-dukkipati-tcpm -tcp-loss-probe-01、2013年2月。
Acknowledgements
謝辞
The authors wish to thank Michael Tuexen for contributing the SCTP Socket API considerations and Godred Fairhurst, Yuchung Cheng, Mark Allman, Anantha Ramaiah, Richard Scheffenegger, Nicolas Kuhn, Alexander Zimmermann, and Michael Scharf for commenting on the document and the ideas behind it.
著者は、SCTP Socket APIの考慮事項を提供してくれたMichael Tuexenと、このドキュメントとその背後にあるアイデアについてコメントしてくれたGodred Fairhurst、Yuchung Cheng、Mark Allman、Anantha Ramaiah、Richard Scheffenegger、Nicolas Kuhn、Alexander Zimmermann、Michael Scharfに感謝します。
All the authors are supported by RITE (http://riteproject.eu/), a research project (ICT-317700) funded by the European Community under its Seventh Framework Program. The views expressed here are those of the author(s) only. The European Commission is not liable for any use that may be made of the information in this document.
すべての著者は、その第7フレームワークプログラムに基づいて欧州共同体によって資金提供された研究プロジェクト（ICT-317700）であるRITE（http://riteproject.eu/）によってサポートされています。ここで表明されている見解は著者のみの見解です。欧州委員会は、この文書に記載されている情報のいかなる使用についても責任を負いません。
Authors' Addresses
著者のアドレス
Per Hurtig Karlstad University Universitetsgatan 2 Karlstad 651 88 Sweden
Per Hurtig Karlstad University Universitetsgatan 2 Karlstad 651 88スウェーデン
Phone: +46 54 700 23 35
Email: per.hurtig@kau.se
Anna Brunstrom Karlstad University Universitetsgatan 2 Karlstad 651 88 Sweden
アンナブランストロムカールスタード大学Universitetsgatan 2カールスタード651 88スウェーデン
Phone: +46 54 700 17 95
Email: anna.brunstrom@kau.se
Andreas Petlund Simula Research Laboratory AS P.O. Box 134 Lysaker 1325 Norway
Andreas Petlund Simula Research Laboratory AS P.O. Box 134 Lysaker 1325ノルウェー
Phone: +47 67 82 82 00
Email: apetlund@simula.no
Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway
マイケルウェルズル大学オスロ私書箱1080ブリンデンオスロN-0316ノルウェー
Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no