[要約] RFC 5682は、TCPのスパリアスな再送タイムアウトを検出するためのアルゴリズムである。その目的は、ネットワークの遅延やパケットのロスによる誤った再送タイムアウトを避け、TCPのパフォーマンスを向上させることである。
Network Working Group P. Sarolahti
Request for Comments: 5682 Nokia Research Center
Updates: 4138 M. Kojo
Category: Standards Track University of Helsinki
K. Yamamoto
M. Hata
NTT Docomo
September 2009
Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP
Forward RTO-Recovery（F-RTO）：TCPで偽りの再送信タイムアウトを検出するためのアルゴリズム
Abstract
概要
The purpose of this document is to move the F-RTO (Forward RTO-Recovery) functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F-RTO support for Stream Control Transmission Protocol (SCTP) in RFC 4138 remains with Experimental status. See Appendix B for the differences between this document and RFC 4138.
このドキュメントの目的は、RFC 4138のTCPのF-RTO（Forward RTO-Recovery）機能を実験から標準の追跡ステータスに移動することです。RFC 4138のストリーム制御伝送プロトコル（SCTP）のF-RTOサポートは、実験的状態のままです。このドキュメントとRFC 4138の違いについては、付録Bを参照してください。
Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout.
偽りの再送信タイムアウトは、最適ではないTCPパフォーマンスを引き起こします。これは、データの最後のウィンドウの不必要な再送信を引き起こすことが多いためです。このドキュメントでは、偽のTCP再送信タイムアウトを検出するためのF-RTO検出アルゴリズムについて説明します。F-RTOは、操作にはTCPオプションを必要としないTCP Senderのみのアルゴリズムです。タイムアウトによってトリガーされた最初の未承認セグメントを再送信した後、TCP送信者のF-RTOアルゴリズムは、タイムアウトがスプリアスであるかどうかを判断するために、着信謝辞を監視します。次に、新しいセグメントを送信するか、未装填セグメントを再送信するかどうかを決定します。このアルゴリズムは、追加の不必要な再送信を回避するのに効果的に役立ち、それにより、偽のタイムアウトの場合にTCPパフォーマンスが向上します。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright and License Notice
著作権とライセンス通知
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 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 BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions and Terminology ................................5
2. Basic F-RTO Algorithm ...........................................5
2.1. The Algorithm ..............................................5
2.2. Discussion .................................................7
3. SACK-Enhanced Version of the F-RTO Algorithm ....................9
3.1. The Algorithm ..............................................9
3.2. Discussion ................................................11
4. Taking Actions after Detecting Spurious RTO ....................11
5. Evaluation of RFC 4138 .........................................12
6. Security Considerations ........................................13
7. Acknowledgments ................................................14
Appendix A. Discussion of Window-Limited Cases ....................15
Appendix B. Changes since RFC 4138 ................................16
References ........................................................16
Normative References ...........................................16
Informative References .........................................17
The Transmission Control Protocol (TCP) [Pos81] has two methods for triggering retransmissions. First, the TCP sender relies on incoming duplicate acknowledgments (ACKs), which indicate that the receiver is missing some of the data. After a required number of successive duplicate ACKs have arrived at the sender, it retransmits the first unacknowledged segment [APB09] and continues with a loss recovery algorithm such as NewReno [FHG04] or SACK-based (Selective Acknowledgment) loss recovery [BAFW03]. Second, the TCP sender maintains a retransmission timer that triggers retransmission of segments, if they have not been acknowledged before the retransmission timeout (RTO) occurs. When the retransmission timeout occurs, the TCP sender enters the RTO recovery where the congestion window is initialized to one segment and unacknowledged segments are retransmitted using the slow-start algorithm. The retransmission timer is adjusted dynamically, based on the measured round-trip times [PA00].
トランスミッションコントロールプロトコル（TCP）[POS81]には、再送信をトリガーする2つの方法があります。まず、TCP送信者は、受信機にデータの一部が欠落していることを示す、着信重複謝辞（ACK）に依存しています。必要な数の連続した重複ACKが送信者に到着した後、最初の未吸収セグメント[APB09]を再送信し、NewReno [FHG04]やSACKベースの（選択的承認）損失回復[BAFW03]などの損失回復アルゴリズムを継続します。第二に、TCP送信者は、再送信タイムアウト（RTO）が発生する前に認められていない場合、セグメントの再送信をトリガーする再送信タイマーを維持します。再送信タイムアウトが発生すると、TCP送信者はRTO回復に入り、そこでは輻輳ウィンドウが1つのセグメントに初期化され、スロースタートアルゴリズムを使用して再刻まれていないセグメントが再送信されます。再送信タイマーは、測定された往復時間[PA00]に基づいて動的に調整されます。
It has been pointed out that the retransmission timer can expire spuriously and cause unnecessary retransmissions when no segments have been lost [LK00, GL02, LM03]. After a spurious retransmission timeout, the late acknowledgments of the original segments arrive at the sender, usually triggering unnecessary retransmissions of a whole window of segments during the RTO recovery. Furthermore, after a spurious retransmission timeout, a conventional TCP sender increases the congestion window on each late acknowledgment in slow start. This injects a large number of data segments into the network within one round-trip time, thus violating the packet conservation principle [Jac88].
再送信タイマーは、セグメントが失われていない場合、再送信タイマーが微妙に期限切れになり、不必要な再送信を引き起こす可能性があることが指摘されています[LK00、GL02、LM03]。偽りの再送信タイムアウトの後、元のセグメントの遅い謝辞が送信者に到着し、通常、RTO回復中にセグメントのウィンドウ全体の不必要な再送信をトリガーします。さらに、偽りの再送信タイムアウトの後、従来のTCP送信者は、遅いスタートで各遅い謝辞の輻輳ウィンドウを増やします。これにより、1回の往復時間内に多数のデータセグメントがネットワークに注入されるため、パケット保存原則[JAC88]に違反します。
There are a number of potential reasons for spurious retransmission timeouts. First, some mobile networking technologies involve sudden delay spikes on transmission because of actions taken during a hand-off. Second, a hand-off may take place from a low latency path to a high latency path, suddenly increasing the round-trip time beyond the current RTO value. Third, on a low-bandwidth link the arrival of competing traffic (possibly with higher priority), or some other change in available bandwidth, can cause a sudden increase of the round-trip time. This may trigger a spurious retransmission timeout. A persistently reliable link layer can also cause a sudden delay when a data frame and several retransmissions of it are lost for some reason. This document does not distinguish between the different causes of such a delay spike. Rather, it discusses the spurious retransmission timeouts caused by a delay spike in general.
偽りの再送信タイムアウトには潜在的な理由がいくつかあります。第一に、一部のモバイルネットワーキングテクノロジーには、ハンドオフ中に行われたアクションのために、伝送に対する突然の遅延スパイクが含まれます。第二に、ハンドオフは、低レイテンシパスから高いレイテンシパスまでのパスまで行われ、現在のRTO値を超えて往復時間を突然増加させることができます。第三に、低帯域幅リンクでは、競合するトラフィックの到着（優先度が高い可能性が高い）、または利用可能な帯域幅のその他の変化は、往復時間の突然の増加を引き起こす可能性があります。これにより、偽りの再送信タイムアウトがトリガーされる場合があります。持続的に信頼性の高いリンク層は、データフレームとその複数の再送信が何らかの理由で失われると、突然の遅延を引き起こす可能性があります。このドキュメントでは、このような遅延スパイクのさまざまな原因を区別しません。むしろ、一般的な遅延スパイクによって引き起こされる偽の再送信のタイムアウトについて説明します。
This document describes the F-RTO detection algorithm for TCP. It is based on the detection mechanism of the "Forward RTO-Recovery" (F-RTO) algorithm [SKR03] that is used for detecting spurious retransmission timeouts and thus avoids unnecessary retransmissions following the retransmission timeout. When the timeout is not spurious, the F-RTO algorithm reverts back to the conventional RTO recovery algorithm, and therefore has similar behavior and performance. In contrast to alternative algorithms proposed for detecting unnecessary retransmissions (Eifel [LK00, LM03] and DSACK-based (Duplicate SACK) algorithms [BA04]), F-RTO does not require any TCP options for its operation, and it can be implemented by modifying only the TCP sender. The Eifel algorithm uses TCP timestamps [BBJ92] for detecting a spurious timeout upon arrival of the first acknowledgment after the retransmission. The DSACK-based algorithms require that the TCP Selective Acknowledgment Option [MMFR96], with the DSACK extension [FMMP00], is in use. With DSACK, the TCP receiver can report if it has received a duplicate segment, enabling the sender to detect afterwards whether it has retransmitted segments unnecessarily. The F-RTO algorithm only attempts to detect and avoid unnecessary retransmissions after an RTO. Eifel and DSACK can also be used for detecting unnecessary retransmissions caused by other events, such as packet reordering.
このドキュメントでは、TCPのF-RTO検出アルゴリズムについて説明します。これは、「フォワードRTO回復」（F-RTO）アルゴリズム[SKR03]の検出メカニズムに基づいており、偽りの再送信のタイムアウトを検出するために使用され、したがって、再送信のタイムアウト後の不必要な再送信を回避します。タイムアウトがスプリアスでない場合、F-RTOアルゴリズムは従来のRTO回復アルゴリズムに戻るため、同様の動作とパフォーマンスがあります。不必要な再送信（EIFEL [LK00、LM03]およびDSACKベースの（重複したサック）アルゴリズム[BA04]）を検出するために提案された代替アルゴリズムとは対照的に、F-RTOはその動作にTCPオプションを必要としません。TCP送信者のみを変更します。EIFELアルゴリズムは、TCPタイムスタンプ[BBJ92]を使用して、再送信後の最初の承認の到着時に偽のタイムアウトを検出します。DSACKベースのアルゴリズムでは、DSACK拡張[FMMP00]を使用して、TCP選択的確認オプション[MMFR96]が使用されていることが必要です。DSACKを使用すると、TCPレシーバーが重複セグメントを受け取ったかどうかを報告でき、送信者が不必要に再送信されたセグメントを再送信したかどうかを検出できます。F-RTOアルゴリズムは、RTOの後に不必要な再送信を検出し、回避しようとします。EifelとDSACKは、パケットの並べ替えなど、他のイベントによって引き起こされる不必要な再送信を検出するためにも使用できます。
When the retransmission timer expires, the F-RTO sender retransmits the first unacknowledged segment as usual [APB09]. Deviating from the normal operation after a timeout, it then tries to transmit new, previously unsent data for the first acknowledgment that arrives after the timeout, given that the acknowledgment advances the window. If the second acknowledgment that arrives after the timeout advances the window (i.e., acknowledges data that was not retransmitted), the F-RTO sender declares the timeout spurious and exits the RTO recovery. However, if either of these two acknowledgments is a duplicate ACK, there will not be sufficient evidence of a spurious timeout. Therefore, the F-RTO sender retransmits the unacknowledged segments in slow start similar to the traditional algorithm. With a SACK-enhanced version of the F-RTO algorithm, spurious timeouts may be detected even if duplicate ACKs arrive after an RTO retransmission.
再送信タイマーの有効期限が切れると、F-RTO送信者は通常のように最初の未承認セグメントを再送信します[APB09]。タイムアウト後の通常の操作から逸脱して、その後、承認がウィンドウを進歩させることを考えると、タイムアウト後に到着する最初の承認のために、以前に安全でない新しいデータを送信しようとします。タイムアウトの後に到着する2番目の承認がウィンドウを進行した場合（つまり、再送信されていないデータを認めます）、F-RTO送信者はタイムアウトのスプリアスを宣言し、RTO回復を終了します。ただし、これら2つの謝辞のいずれかが重複したACKである場合、偽のタイムアウトの十分な証拠はありません。したがって、F-RTO送信者は、従来のアルゴリズムと同様に、スロースタートで未吸合のセグメントを再送信します。F-RTOアルゴリズムのサック強化バージョンでは、RTOの再送信後に重複したAcksが到着した場合でも、偽のタイムアウトが検出される場合があります。
This document specifies the F-RTO algorithm for TCP only, replacing the F-RTO functionality with TCP in RFC 4138 [SK05] and moving it from Experimental to Standards Track status. The algorithm can also be applied to the Stream Control Transmission Protocol (SCTP) [Ste07] that has acknowledgment and packet retransmission concepts similar to TCP. The considerations on applying F-RTO to SCTP are discussed in RFC 4138, but the F-RTO support for SCTP remains with Experimental status.
このドキュメントは、TCPのF-RTOアルゴリズムのみを指定し、F-RTO機能をRFC 4138 [SK05]のTCPに置き換え、実験的なものから標準トラックステータスに移動します。アルゴリズムは、TCPと同様の認識とパケット再送信の概念を持つストリーム制御伝送プロトコル（SCTP）[STE07]にも適用できます。F-RTOをSCTPに適用することに関する考慮事項はRFC 4138で説明されていますが、SCTPのF-RTOサポートは実験的状態のままです。
This document is organized as follows. Section 2 describes the basic F-RTO algorithm, and the SACK-enhanced F-RTO algorithm is given in Section 3. Section 4 discusses the possible actions to be taken after detecting a spurious RTO. Section 5 summarizes the experience with F-RTO implementations and the experimental results, and Section 6 discusses the security considerations.
このドキュメントは次のように整理されています。セクション2では、基本的なF-RTOアルゴリズムについて説明し、Sackが強化したF-RTOアルゴリズムについては、セクション3で説明します。セクション4では、偽のRTOを検出した後に実行される可能性のあるアクションについて説明します。セクション5では、F-RTOの実装と実験結果のエクスペリエンスをまとめ、セクション6でセキュリティに関する考慮事項について説明します。
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 BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for protocols.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈され、プロトコルの要件レベルを示します。
A timeout is considered spurious if it would have been avoided had the sender waited longer for an acknowledgment to arrive [LM03]. F-RTO affects the TCP sender behavior only after a retransmission timeout. Otherwise, the TCP behavior remains the same. When the retransmission timer expires, the F-RTO algorithm monitors incoming acknowledgments, and if the TCP sender gets an acknowledgment for a segment that was not retransmitted due to the timeout, the F-RTO algorithm declares a timeout spurious. The actions taken in response to a spurious timeout are not specified in this document, but we discuss some alternatives in Section 4. This section introduces the algorithm and then discusses the different steps of the algorithm in more detail.
承認が到着するのをより長く待っていれば、タイムアウトは避けられていれば偽りと見なされます[LM03]。F-RTOは、再送信タイムアウト後にのみTCP送信者の動作に影響します。それ以外の場合、TCPの動作は同じままです。再送信タイマーの有効期限が切れると、F-RTOアルゴリズムは着信謝辞を監視し、TCP送信者がタイムアウトのために再送信されなかったセグメントの承認を取得した場合、F-RTOアルゴリズムはタイムアウトスモリスを宣言します。スプリアスタイムアウトに対応して行われたアクションは、このドキュメントでは指定されていませんが、セクション4でいくつかの代替案について説明します。このセクションでは、アルゴリズムを紹介し、アルゴリズムのさまざまな手順についてさらに詳しく説明します。
Following the practice used with the Eifel Detection algorithm [LM03], we use the "SpuriousRecovery" variable to indicate whether the retransmission is declared spurious by the sender. This variable can be used as an input for a corresponding response algorithm. With F-RTO, the value of SpuriousRecovery can be either SPUR_TO (indicating a spurious retransmission timeout) or FALSE (indicating that the timeout is not declared spurious and the TCP sender should follow the conventional RTO recovery algorithm). In addition, we use the "recover" variable specified in the NewReno algorithm [FHG04].
EIFEL検出アルゴリズム[LM03]で使用されたプラクティスに続いて、「SpouriousRecovery」変数を使用して、送信が送信者によって偽物と宣言されているかどうかを示します。この変数は、対応する応答アルゴリズムの入力として使用できます。F-RTOを使用すると、SpuriousRecoveryの値は、SPUR_TO（スプリアス再送信タイムアウトを示す）またはfalse（タイムアウトがスプリアスと宣言されておらず、TCP送信者が従来のRTO回復アルゴリズムに従う必要があることを示します）です。さらに、NewRenoアルゴリズム[FHG04]で指定された「回復」変数を使用します。
A TCP sender implementing the basic F-RTO algorithm MUST take the following steps after the retransmission timer expires. If the retransmission timer expires again during the execution of the F-RTO algorithm, the TCP sender MUST re-start the algorithm processing from step 1. If the sender implements some loss recovery algorithm other than Reno or NewReno [FHG04], the F-RTO algorithm SHOULD NOT be entered when earlier fast recovery is underway.
基本的なF-RTOアルゴリズムを実装するTCP送信者は、再送信タイマーの有効期限が切れた後、次の手順を実行する必要があります。F-RTOアルゴリズムの実行中に再送信タイマーが再度期限切れになった場合、TCP送信者はステップ1からアルゴリズム処理を再起動する必要があります。RTOアルゴリズムは、以前の迅速な回復が進行中のときに入力しないでください。
The F-RTO algorithm takes different actions based on whether an incoming acknowledgment advances the cumulative acknowledgment point for a received in-order segment, or whether it is a duplicate acknowledgment to indicate an out-of-order segment. Duplicate acknowledgment is defined in [APB09]. The F-RTO algorithm does not specify actions for receiving a segment that neither acknowledges new data nor is a duplicate acknowledgment. The TCP sender SHOULD ignore such segments and wait for a segment that either acknowledges new data or is a duplicate acknowledgment.
F-RTOアルゴリズムは、受信した注文のセグメントの累積承認ポイントを進めるかどうか、またはオーバーアウトオブセグメントを示すための重複した承認であるかどうかに基づいて、異なるアクションを実行します。重複する確認は[APB09]で定義されています。F-RTOアルゴリズムは、新しいデータを認識しておらず、概念の重複もないセグメントを受信するためのアクションを指定していません。TCP送信者は、そのようなセグメントを無視し、新しいデータを認めるか、重複する謝辞であるセグメントを待つ必要があります。
1) When the retransmission timer expires, retransmit the first unacknowledged segment and set SpuriousRecovery to FALSE. If the TCP sender is already in RTO recovery AND "recover" is larger than or equal to SND.UNA (the oldest unacknowledged sequence number [Pos81]), do not enter step 2 of this algorithm. Instead, store the highest sequence number transmitted so far in variable "recover" and continue with slow-start retransmissions following the conventional RTO recovery algorithm.
1) 再送信タイマーの有効期限が切れると、最初の未承認のセグメントを再送信し、偽の回収をfalseに設定します。TCP送信者がすでにRTO回復中であり、「回復」がSND.UNA（最も古い非採取されていないシーケンス番号[POS81]）以上である場合、このアルゴリズムのステップ2を入力しないでください。代わりに、これまでに送信された最高のシーケンス番号を変数「回復」に保存し、従来のRTO回復アルゴリズムに従ってスロースタート再送信を続行します。
2) When the first acknowledgment after the RTO retransmission arrives at the TCP sender, store the highest sequence number transmitted so far in variable "recover". The TCP sender chooses one of the following actions, depending on whether the ACK advances the window or whether it is a duplicate ACK.
2) RTOの再送信後の最初の謝辞がTCP送信者に到着した場合、これまでに「回復」に送信された最高のシーケンス番号を保存します。TCP送信者は、ACKがウィンドウを進めるかどうか、またはそれが重複したACKであるかどうかに応じて、次のアクションのいずれかを選択します。
a) If the acknowledgment is a duplicate ACK, OR the Acknowledgment field covers "recover" but not more than "recover", OR the acknowledgment does not acknowledge all of the data that was retransmitted in step 1, revert to the conventional RTO recovery and continue by retransmitting unacknowledged data in slow start. Do not enter step 3 of this algorithm. The SpuriousRecovery variable remains as FALSE.
a) 謝辞が重複したACKである、または確認フィールドが「回復」をカバーしているが「回復」以外ではない場合、または謝辞がステップ1で再送信されたすべてのデータを認めない場合、従来のRTO回復に戻り、継続する場合スロースタートで未装備のデータを再送信します。このアルゴリズムのステップ3を入力しないでください。SpouriousRecovery変数は虚偽のままです。
b) Else, if the acknowledgment advances the window AND the Acknowledgment field does not cover "recover", transmit up to two new (previously unsent) segments and enter step 3 of this algorithm. If the TCP sender does not have enough unsent data, it can send only one segment. In addition, the TCP sender MAY override the Nagle algorithm [Nag84] and immediately send a segment if needed. Note that sending two segments in this step is allowed by TCP congestion control requirements [APB09]: an F-RTO TCP sender simply chooses different segments to transmit.
b) それ以外の場合、謝辞がウィンドウを進め、承認フィールドが「回復」をカバーしない場合、最大2つの新しい（以前に安全でない）セグメントを送信し、このアルゴリズムのステップ3を入力します。TCP送信者に十分な不明なデータがない場合、1つのセグメントのみを送信できます。さらに、TCP送信者は、Nagleアルゴリズム[Nag84]をオーバーライドし、必要に応じてすぐにセグメントを送信する場合があります。このステップで2つのセグメントを送信することは、TCP混雑制御要件[APB09]によって許可されることに注意してください。F-RTO TCP Senderは、送信するさまざまなセグメントを選択するだけです。
If the TCP sender does not have any new data to send, or the advertised window prohibits new transmissions, the recommended action is to skip step 3 of this algorithm and continue with slow-start retransmissions, following the conventional RTO recovery algorithm. However, alternative ways of handling the window-limited cases that could result in better performance are discussed in Appendix A.
TCP送信者に送信する新しいデータがない場合、または広告されたウィンドウが新しい送信を禁止している場合、推奨されるアクションは、このアルゴリズムのステップ3をスキップし、従来のRTO回復アルゴリズムに従ってスロースタート再送信を続行することです。ただし、パフォーマンスが向上する可能性のある窓に制限されたケースを処理する別の方法については、付録Aで説明します。
3) When the second acknowledgment after the RTO retransmission arrives at the TCP sender, the TCP sender either declares the timeout spurious, or starts retransmitting the unacknowledged segments.
3) RTOの再送信後の2回目の謝辞がTCP送信者に到着すると、TCP送信者はタイムアウトのスプリアスを宣言するか、未承認のセグメントを再送信し始めます。
a) If the acknowledgment is a duplicate ACK, set the congestion window to no more than 3 * MSS (where MSS indicates Maximum Segment Size), and continue with the slow-start algorithm retransmitting unacknowledged segments. The congestion window can be set to 3 * MSS, because two round-trip times have elapsed since the RTO, and a conventional TCP sender would have increased cwnd to 3 during the same time. Leave SpuriousRecovery set to FALSE.
a) 確認が重複している場合、輻輳ウィンドウを3 * MSS以下（MSSが最大セグメントサイズを示します）を超えて設定し、スロースタートアルゴリズムを継続しないセグメントを再送信することを続行します。RTO以来2つの往復時間が経過しており、従来のTCP送信者が同時にCWNDを3に増加させるため、輻輳ウィンドウは3 * MSSに設定できます。SpuariousRecoveryをFalseに設定したままにします。
b) If the acknowledgment advances the window (i.e., if it acknowledges data that was not retransmitted after the timeout), declare the timeout spurious, set SpuriousRecovery to SPUR_TO, and set the value of the "recover" variable to SND.UNA (the oldest unacknowledged sequence number [Pos81]).
b) 承認がウィンドウを進歩させた場合（つまり、タイムアウト後に再送信されなかったデータを確認した場合）、タイムアウトのスプリアスを宣言し、Spur_TOに偽のレリケーションを設定し、「回復」変数の値をsnd.una（最も古い未解決のものに設定するシーケンス番号[POS81]）。
The F-RTO sender takes cautious actions when it receives duplicate acknowledgments after a retransmission timeout. Because duplicate ACKs may indicate that segments have been lost, reliably detecting a spurious timeout is difficult due to the lack of additional information. Therefore, it is prudent to follow the conventional TCP recovery in those cases.
F-RTO送信者は、再送信タイムアウト後に重複する謝辞を受け取ったときに慎重なアクションを実行します。重複するACKは、セグメントが失われたことを示している可能性があるため、追加情報がないために偽のタイムアウトを確実に検出することは困難です。したがって、これらの場合の従来のTCP回復に従うことは賢明です。
The condition in step 1 prevents the execution of the F-RTO algorithm in case a previous RTO recovery is underway when the retransmission timer expires, except in case the retransmission timer expires multiple times for the same segment. If the retransmission timer expires during an earlier RTO-based loss recovery, acknowledgments for retransmitted segments may falsely lead the TCP sender to declare the timeout spurious.
ステップ1の条件は、再送信タイマーが失効したときに以前のRTO回復が進行している場合に備えて、F-RTOアルゴリズムの実行を防ぎます。以前のRTOベースの損失回復中に再送信タイマーが期限切れになった場合、再送信セグメントの謝辞は、TCP送信者がタイムアウトスプリアスを宣言するように誤って導く可能性があります。
If the first acknowledgment after the RTO retransmission covers the "recover" point at algorithm step (2a), there is not enough evidence that a non-retransmitted segment has arrived at the receiver after the timeout. This is a common case when a fast retransmission is lost and has been retransmitted again after an RTO, while the rest of the unacknowledged segments were successfully delivered to the TCP receiver before the retransmission timeout. Therefore, the timeout cannot be declared spurious in this case.
RTOの再送信後の最初の承認がアルゴリズムステップ（2A）の「回復」ポイントをカバーしている場合、タイムアウト後に再送信されていないセグメントが受信機に到着したという十分な証拠がありません。これは、迅速な再送信が失われ、RTOの後に再び再送信された場合の一般的なケースであり、一方、残りの承認されていないセグメントは、再送信タイムアウトの前にTCPレシーバーに正常に配信されました。したがって、この場合、タイムアウトを偽物と宣言することはできません。
If the first acknowledgment after the RTO retransmission does not acknowledge all of the data that was retransmitted in step 1, the TCP sender reverts to the conventional RTO recovery. Otherwise, a malicious receiver acknowledging partial segments could cause the sender to declare the timeout spurious in a case where data was lost.
RTOの再送信後の最初の謝辞がステップ1で再送信されたすべてのデータを認めていない場合、TCP送信者は従来のRTO回復に戻ります。それ以外の場合、部分的なセグメントを認める悪意のある受信機により、データが失われた場合に、送信者がタイムアウトの偽物を宣言する可能性があります。
The TCP sender is allowed to send two new segments in algorithm branch (2b) because the conventional TCP sender would transmit two segments when the first new ACK arrives after the RTO retransmission. If sending new data is not possible in algorithm branch (2b), or if the receiver window limits the transmission, the TCP sender has to send something in order to prevent the TCP transfer from stalling. If no segments were sent, the pipe between sender and receiver might run out of segments, and no further acknowledgments would arrive. Therefore, in the window-limited case, the recommendation is to revert to the conventional RTO recovery with slow-start retransmissions. Appendix A discusses some alternative solutions for window-limited situations.
TCP送信者は、従来のTCP送信者がRTOの再送信後に最初の新しいACKが到着したときに2つのセグメントを送信するため、アルゴリズムブランチ（2B）に2つの新しいセグメントを送信できます。アルゴリズムブランチ（2B）で新しいデータを送信しない場合、または受信機ウィンドウが送信を制限する場合、TCP送信者はTCP転送が失速しないように何かを送信する必要があります。セグメントが送信されなかった場合、送信者とレシーバーの間のパイプがセグメントを使い果たす可能性があり、それ以上の謝辞が届きません。したがって、ウィンドウが制限された場合、推奨は、スロースタートの再送信で従来のRTO回復に戻ることです。付録Aでは、窓に制限された状況に関するいくつかの代替ソリューションについて説明します。
If the retransmission timeout is declared spurious, the TCP sender sets the value of the "recover" variable to SND.UNA in order to allow fast retransmit [FHG04]. The "recover" variable was proposed for avoiding unnecessary, multiple fast retransmits when the retransmission timer expires during fast recovery with NewReno TCP. Because the F-RTO sender retransmits only the segment that triggered the timeout, the problem of unnecessary multiple fast retransmits [FHG04] cannot occur. Therefore, if three duplicate ACKs arrive at the sender after the timeout, they probably indicate a packet loss, and thus fast retransmit should be used to allow efficient recovery. If there are not enough duplicate ACKs arriving at the sender after a packet loss, the retransmission timer expires again and the sender enters step 1 of this algorithm.
再送信タイムアウトが偽物と宣言されている場合、TCP送信者は、高速再送信[FHG04]を許可するために、snd.unaに「回復」変数の値を設定します。「回復」変数は、NewReno TCPでの迅速な回復中に再送信タイマーが期限切れになったときに不必要な複数の高速再送信を回避するために提案されました。F-RTO送信者はタイムアウトをトリガーしたセグメントのみを再送信するため、不必要な複数の高速再送信[FHG04]の問題は発生できません。したがって、タイムアウト後に3つの重複したACKが送信者に到着する場合、おそらくパケットの損失を示しているため、効率的な回復を可能にするために高速な再送信を使用する必要があります。パケットの損失後に送信者に到着する十分な重複ACKがない場合、再送信タイマーは再び期限切れになり、送信者はこのアルゴリズムのステップ1に入ります。
When the timeout is declared spurious, the TCP sender cannot detect whether the unnecessary RTO retransmission was lost. In principle, the loss of the RTO retransmission should be taken as a congestion signal. Thus, there is a small possibility that the F-RTO sender will violate the congestion control rules, if it chooses to fully revert congestion control parameters after detecting a spurious timeout. The Eifel Detection algorithm has a similar property, while the DSACK option can be used to detect whether the retransmitted segment was successfully delivered to the receiver.
タイムアウトが偽りと宣言されると、TCP送信者は不必要なRTOの再送信が失われたかどうかを検出できません。原則として、RTOの再送信の喪失は輻輳信号と見なされるべきです。したがって、偽りのタイムアウトを検出した後に混雑制御パラメーターを完全に戻すことを選択した場合、F-RTO送信者が混雑制御ルールに違反する可能性が少しあります。EIFEL検出アルゴリズムには同様のプロパティがありますが、DSACKオプションを使用して、再送信セグメントが正常に受信機に配信されたかどうかを検出できます。
The F-RTO algorithm has a side effect on the TCP round-trip time measurement. Because the TCP sender can avoid most of the unnecessary retransmissions after detecting a spurious timeout, the sender is able to take round-trip time samples on the delayed segments. If the regular RTO recovery was used without TCP timestamps, this would not be possible due to the retransmission ambiguity. As a result, the RTO is likely to have more accurate and larger values with F-RTO than with the regular TCP after a spurious timeout that was triggered due to delayed segments. We believe this is an advantage in networks that are prone to delay spikes.
F-RTOアルゴリズムは、TCPの往復時間測定に副作用があります。TCP送信者は、偽のタイムアウトを検出した後、不必要な再送信のほとんどを回避できるため、送信者は遅延セグメントで往復時間サンプルを採取することができます。TCPタイムスタンプなしで通常のRTO回復を使用した場合、再送信のあいまいさのためにこれは不可能です。その結果、RTOは、セグメントが遅れたためにトリガーされたスプリアスタイムアウトの後、通常のTCPよりもF-RTOよりも正確で大きな値を持つ可能性があります。これは、スパイクを遅らせる傾向があるネットワークの利点であると考えています。
There are some situations where the F-RTO algorithm may not avoid unnecessary retransmissions after a spurious timeout. If packet reordering or packet duplication occurs on the segment that triggered the spurious timeout, the F-RTO algorithm may not detect the spurious timeout due to incoming duplicate ACKs. Additionally, if a spurious timeout occurs during fast recovery, the F-RTO algorithm often cannot detect the spurious timeout because the segments that were transmitted before the fast recovery trigger duplicate ACKs. However, we consider these cases rare, and note that in cases where F-RTO fails to detect the spurious timeout, it retransmits the unacknowledged segments in slow start, and thus performs the same as the regular RTO recovery.
F-RTOアルゴリズムが偽りのタイムアウト後に不必要な再送信を回避できない場合があります。スプリアスタイムアウトをトリガーしたセグメントでパケットの並べ替えまたはパケットの複製が発生した場合、F-RTOアルゴリズムは、補充されたACKの到着によりスプリアスタイムアウトを検出しない場合があります。さらに、高速回復中にスプリアスタイムアウトが発生した場合、F-RTOアルゴリズムは、高速回復の前に送信されたセグメントが複製アックを引き起こすため、スプリアスタイムアウトを検出できないことがよくあります。ただし、これらのケースはまれであると考えており、F-RTOがスプリアスタイムアウトの検出に失敗した場合、未充填のセグメントを遅いスタートで再送信し、通常のRTO回復と同じように実行することに注意してください。
This section describes an alternative version of the F-RTO algorithm that uses the TCP Selective Acknowledgment Option [MMFR96]. By using the SACK option, the TCP sender detects spurious timeouts in most of the cases when packet reordering or packet duplication is present. If the SACK information acknowledges new data that was not transmitted after the RTO retransmission, the sender may declare the timeout spurious, even when duplicate ACKs follow the RTO.
このセクションでは、TCP選択的承認オプション[MMFR96]を使用するF-RTOアルゴリズムの代替バージョンについて説明します。SACKオプションを使用することにより、TCP Senderは、パケットの並べ替えまたはパケットの複製が存在する場合に、スプリアスタイムアウトを検出します。SACK情報がRTOの再送信後に送信されなかった新しいデータを認めた場合、送信者は、AcksがRTOに続く場合でも、タイムアウトの偽りを宣言することができます。
Given that the TCP Selective Acknowledgment Option [MMFR96] is enabled for a TCP connection, a TCP sender MAY apply the SACK-enhanced F-RTO algorithm. If the sender applies the SACK-enhanced F-RTO algorithm, it MUST follow the steps below. This algorithm SHOULD NOT be applied if the TCP sender is already in loss recovery when a retransmission timeout occurs.
TCP接続に対してTCP選択的確認オプション[MMFR96]が有効になっていることを考えると、TCP送信者はSack強化F-RTOアルゴリズムを適用できます。送信者がサック強化F-RTOアルゴリズムを適用する場合、以下の手順に従う必要があります。再送信タイムアウトが発生したときにTCP送信者がすでに損失回復中である場合、このアルゴリズムは適用されないでください。
The steps of the SACK-enhanced version of the F-RTO algorithm are as follows. If the retransmission timer expires again during the execution of the SACK-enhanced F-RTO algorithm, the TCP sender MUST re-start the algorithm processing from step 1.
F-RTOアルゴリズムのサック強化バージョンの手順は次のとおりです。Sackが強化したF-RTOアルゴリズムの実行中に再送信タイマーが再度期限切れになった場合、TCP送信者はステップ1からアルゴリズム処理を再起動する必要があります。
1) When the retransmission timer expires, retransmit the first unacknowledged segment and set SpuriousRecovery to FALSE. Following the recommendation in the SACK specification [MMFR96], reset the SACK scoreboard. If "RecoveryPoint" is larger than or equal to SND.UNA, do not enter step 2 of this algorithm. Instead, set variable "RecoveryPoint" to indicate the highest sequence number transmitted so far and continue with slow-start retransmissions following the conventional RTO recovery algorithm.
1) 再送信タイマーの有効期限が切れると、最初の未承認のセグメントを再送信し、偽の回収をfalseに設定します。SACK仕様[MMFR96]の推奨に従って、サックスコアボードをリセットします。「RecoveryPoint」がSND.UNA以上の場合、このアルゴリズムのステップ2を入力しないでください。代わりに、変数「RecoveryPoint」を設定して、これまでに送信された最高のシーケンス数を示し、従来のRTO回復アルゴリズムに続いてスロースタートの再送信を続行します。
2) Wait until the acknowledgment of the data retransmitted due to the timeout arrives at the sender. If duplicate ACKs arrive before the cumulative acknowledgment for retransmitted data, adjust the scoreboard according to the incoming SACK information. Stay in step 2 and wait for the next new acknowledgment. If the retransmission timeout expires again, go to step 1 of the algorithm. When a new acknowledgment arrives, set variable "RecoveryPoint" to indicate the highest sequence number transmitted so far.
2) タイムアウトが送信者に到着したために再送信されたデータの承認が遅くなるまで待ちます。再送信データの累積確認の前に重複したACKが到着した場合は、着信サック情報に従ってスコアボードを調整します。ステップ2にとどまり、次の新しい謝辞を待ちます。再送信タイムアウトが再度有効になった場合は、アルゴリズムのステップ1に移動します。新しい確認が届くと、変数「RecoveryPoint」を設定して、これまでに送信された最高のシーケンス数を示します。
a) If the Cumulative Acknowledgment field covers "RecoveryPoint" but not more than "RecoveryPoint", revert to the conventional RTO recovery and set the congestion window to no more than 2 * MSS, like a regular TCP would do. Do not enter step 3 of this algorithm.
a) 累積確認フィールドが「回復ポイント」をカバーしているが「回復ポイント」以上の場合は、従来のRTO回復に戻り、通常のTCPが行うように、輻輳ウィンドウを2 * MSSにすぎません。このアルゴリズムのステップ3を入力しないでください。
b) Else, if the Cumulative Acknowledgment field does not cover "RecoveryPoint" but is larger than SND.UNA, transmit up to two new (previously unsent) segments and proceed to step 3. If the TCP sender is not able to transmit any previously unsent data -- either due to receiver window limitation or because it does not have any new data to send -- the recommended action is to refrain from entering step 3 of this algorithm. Rather, continue with slow-start retransmissions following the conventional RTO recovery algorithm.
b) それ以外の場合、累積認識フィールドが「回復ポイント」をカバーせず、SND.UNAよりも大きい場合、最大2つの新しい（以前に安全でない）セグメントを送信し、ステップ3に進みます。 - 受信機のウィンドウの制限のため、または送信する新しいデータがないため、推奨されるアクションは、このアルゴリズムのステップ3の入力を控えることです。むしろ、従来のRTO回復アルゴリズムに続いて、スロースタートの再送信を続けます。
It is also possible to apply some of the alternatives for handling window-limited cases discussed in Appendix A.
また、付録Aで説明したウィンドウ制限ケースを処理するための代替案のいくつかを適用することもできます。
3) The next acknowledgment arrives at the sender. Either a duplicate ACK or a new cumulative ACK (advancing the window) applies in this step. Other types of ACKs are ignored without any action.
3) 次の謝辞は送信者に到着します。このステップでは、重複したACKまたは新しい累積ACK（ウィンドウを進める）が適用されます。他のタイプのACKは、何のアクションなしでも無視されます。
a) If the Cumulative Acknowledgment field or the SACK information covers more than "RecoveryPoint", set the congestion window to no more than 3 * MSS and proceed with the conventional RTO recovery, retransmitting unacknowledged segments. Take this branch also when the acknowledgment is a duplicate ACK and it does not acknowledge any new, previously unacknowledged data below "RecoveryPoint" in the SACK information. Leave SpuriousRecovery set to FALSE.
a) 累積確認フィールドまたはSack情報が「RecoveryPoint」以上のものをカバーしている場合は、輻輳ウィンドウを3 * MSS以下に設定し、従来のRTO回復を進めて、未把握されていないセグメントを再送信します。謝辞が重複したACKであり、サック情報の「RecoverPoint」の下にある以前の未承認の新しいデータを認めていない場合にも、このブランチを取ります。SpuariousRecoveryをFalseに設定したままにします。
b) If the Cumulative Acknowledgment field or a SACK information in the ACK does not cover more than "RecoveryPoint" AND it acknowledges data that was not acknowledged earlier (either with cumulative acknowledgment or using SACK information), declare the timeout spurious and set SpuriousRecovery to SPUR_TO. The retransmission timeout can be declared spurious, because the segment acknowledged with this ACK was transmitted before the timeout.
b) 累積確認フィールドまたはACKのサック情報が「RecoveryPoint」以上のものをカバーしておらず、以前に認められなかったデータを認めている場合（累積的な確認情報を使用するか、SACK情報を使用してください）、タイムアウトをSPUR_TOにSpuriousRecoveryに設定します。再送信タイムアウトは、このACKで認められているセグメントがタイムアウト前に送信されたため、偽りと宣言できます。
If there are unacknowledged holes between the received SACK information, those segments are retransmitted similarly to the conventional SACK recovery algorithm [BAFW03]. If the algorithm exits with SpuriousRecovery set to SPUR_TO, "RecoveryPoint" is set to SND.UNA, thus allowing fast recovery on incoming duplicate acknowledgments.
受信したサック情報の間に概要のない穴がある場合、これらのセグメントは、従来のサックリカバリアルゴリズム[BAFW03]と同様に再送信されます。SpuriousRecoveryがspur_TOに設定されたSpuriousRecoveryでアルゴリズムが終了すると、「RecoveryPoint」がSND.UNAに設定されているため、着信の重複謝辞の迅速な回復が可能になります。
The SACK-enhanced algorithm works on the same principle as the basic algorithm, but by utilizing the additional information from the SACK option. When a genuine retransmission timeout occurs during a steady state of a connection, it can be assumed that there are no segments left in the pipe. Otherwise, the acknowledgments triggered by these segments would have triggered the SACK loss recovery or transmission of new segments. Therefore, if the F-RTO sender receives acknowledgments for segments transmitted before the retransmission timeout in response to the two new segments sent at the algorithm step 2, the normal operation of TCP has been just delayed, and the retransmission timeout is considered spurious. Note that this reasoning works only when the TCP sender is not in loss recovery at the time the retransmission timeout occurs. The condition in step 1 checking that "RecoveryPoint" is larger than or equal to SND.UNA prevents the execution of the F-RTO algorithm in case a previous loss recovery, either RTO recovery or SACK loss recovery, is underway when the retransmission timer expires. It, however, allows the execution of the F-RTO algorithm, if the retransmission timer expires multiple times for the same segment.
Sack強化アルゴリズムは、基本的なアルゴリズムと同じ原理で機能しますが、SACKオプションから追加情報を利用します。接続の定常状態中に本物の再送信タイムアウトが発生すると、パイプにセグメントが残っていないと想定できます。それ以外の場合、これらのセグメントによってトリガーされた謝辞は、新しいセグメントの袋損失回収または送信をトリガーしました。したがって、F-RTO送信者が、アルゴリズムのステップ2で送信された2つの新しいセグメントに応じて再送信タイムアウトの前に送信されたセグメントの謝辞を受け取った場合、TCPの通常の動作が遅れており、再送信タイムアウトは偽りと見なされます。この推論は、再送信タイムアウトが発生した時点でTCP送信者が損失回復にない場合にのみ機能することに注意してください。「RecoveryPoint」がSND.UNA以前の損失回復、RTO回復またはサック損失回復のいずれかのいずれかの場合にFRTOアルゴリズムの実行を防ぐ「RecoveryPoint」がSND.UNA以上であることを確認するステップ1の条件は、再送信タイマーが期限切れになったときに進行中です。ただし、再送信タイマーが同じセグメントに対して複数回有効期限が切れる場合、F-RTOアルゴリズムの実行が可能になります。
Upon a retransmission timeout, a conventional TCP sender assumes that outstanding segments are lost and starts retransmitting the unacknowledged segments. When the retransmission timeout is detected to be spurious, the TCP sender should not continue retransmitting based on the timeout. For example, if the sender was in congestion avoidance phase transmitting new, previously unsent segments, it should continue transmitting previously unsent segments in congestion avoidance.
再送信のタイムアウトで、従来のTCP送信者は、優れたセグメントが失われていると想定し、未承認のセグメントを再送信し始めます。再送信タイムアウトが偽物であると検出された場合、TCP送信者はタイムアウトに基づいて再送信を続けてはなりません。たとえば、送信者が新しい以前に確かでないセグメントを送信する混雑回避段階にある場合、混雑回避で以前に安全でないセグメントを送信し続ける必要があります。
There are currently two alternatives specified for a spurious timeout response algorithm, the Eifel Response Algorithm [LG05], and an algorithm for adapting the retransmission timeout after a spurious RTO [BBA06]. If no specific response algorithm is implemented, the TCP SHOULD respond to spurious timeout conservatively, applying the TCP congestion control specification [APB09]. Different response algorithms for spurious retransmission timeouts have been analyzed in some research papers [GL03, Sar03] and IETF documents [SL03].
現在、スプリアスタイムアウト応答アルゴリズム、EIFEL応答アルゴリズム[LG05]、および偽のRTO [BBA06]の後に再送信タイムアウトを適応させるためのアルゴリズムが2つの選択肢が指定されています。特定の応答アルゴリズムが実装されていない場合、TCPはTCP輻輳制御仕様[APB09]を適用して、Spourious Timeoutに控えめに応答する必要があります。偽りの再送信タイムアウトのさまざまな応答アルゴリズムは、いくつかの研究論文[GL03、SAR03]およびIETFドキュメント[SL03]で分析されています。
F-RTO was first specified in an Experimental RFC (RFC 4138) that has been implemented in a number of operating systems since it was published. Gained experience has been documented in a separate document [KYHS07], and can be summarized as follows.
F-RTOは、公開されてから多くのオペレーティングシステムで実装されている実験RFC（RFC 4138）で最初に指定されました。得られた経験は別の文書[KYHS07]に文書化されており、次のように要約できます。
If the TCP sender employs F-RTO, it is able to detect spurious RTOs and avoid the unnecessary retransmission of the whole window of data. Because F-RTO avoids the unnecessary retransmissions after a spurious RTO, it is able to adhere to the packet conservation principle, unlike a regular TCP that enters the slow-start recovery unnecessarily and inappropriately restarts the ACK clock while there are segments outstanding in the network. When a spurious RTO has been detected, a sender can select an appropriate congestion control response instead of setting the congestion window to one segment. Because F-RTO avoids unnecessary retransmissions, it is able to take the round-trip time of the delayed segments into account when calculating the RTO estimate, which may help in avoiding further spurious retransmission timeouts.
TCP送信者がF-RTOを使用している場合、偽のRTOを検出し、データのウィンドウ全体の不必要な再送信を回避できます。F-RTOは、偽のRTOの後に不必要な再送信を回避するため、ネットワークに優れたセグメントがありますが、ACKクロックを不必要にかつ不適切に再起動する通常のTCPとは異なり、パケット保存の原則に準拠することができます。。偽のRTOが検出された場合、送信者は、輻輳ウィンドウを1つのセグメントに設定する代わりに、適切な輻輳制御応答を選択できます。F-RTOは不必要な再送信を回避するため、RTOの推定値を計算する際に遅延セグメントの往復時間を考慮することができます。
Experimental results with the basic F-RTO have been reported in an emulated network using a Linux implementation [SKR03]. Also, different congestion control responses along with the SACK-enhanced version of F-RTO were tested in a similar environment [Sar03]. There are publications analyzing F-RTO performance over commercial Wideband Code Division Multiple Access (W-CDMA) networks, and in an emulated High-Speed Downlink Packet Access (HSDPA) network [Yam05, Hok05]. Also, Microsoft reported positive experiences with their implementation of F-RTO at the IETF-68 meeting.
基本的なF-RTOを使用した実験結果は、Linux実装[SKR03]を使用してエミュレートネットワークで報告されています。また、異なる混雑制御応答とF-RTOのサック強化バージョンは、同様の環境でテストされました[SAR03]。商業用ワイドバンドコードディビジョンマルチアクセス（W-CDMA）ネットワークを介したF-RTOパフォーマンスを分析する出版物があり、エミュレートされた高速ダウンリンクパケットアクセス（HSDPA）ネットワーク[YAM05、HOK05]で分析されています。また、Microsoftは、IETF-68会議でのF-RTOの実装に関する肯定的な経験を報告しました。
It is known that some spurious RTOs may remain undetected by F-RTO if duplicate acknowledgments arrive at the sender immediately after the spurious RTO, for example due to packet reordering or packet loss. There are rare corner cases where F-RTO could "hide" a packet loss and therefore lead to inappropriate behavior with non-conservative congestion control response: first, if a massive packet reordering occurred so that the acknowledgment of RTO retransmission arrived at the sender before the acknowledgments of original transmissions, the sender might not detect the loss of the segment that triggered the RTO. Second, a malicious receiver could lead F-RTO to make a wrong conclusion after an RTO by acknowledging segments it has not received. Such a receiver would, however, risk breaking the consistency of the TCP state between the sender and receiver, causing the connection to become unusable, which cannot be of any benefit to the receiver. Therefore, we believe it is not likely that receivers would start employing such tricks on a significant scale. Finally, loss of the unnecessary RTO retransmission cannot be detected without using some explicit acknowledgment scheme such as DSACK. This is common to the other mechanisms for detecting spurious RTO, as well as to regular TCP that does not use DSACK. We note that if the congestion control response to spurious RTO is conservative enough, the above corner cases do not cause problems due to increased congestion.
たとえば、パケットの並べ替えやパケットの損失など、偽の謝辞が偽のRTOの直後に送信者に到着した場合、いくつかの偽のRTOがF-RTOによって検出されない場合があることが知られています。F-RTOがパケットの損失を「隠す」ことができるまれなコーナーケースがあり、したがって、非保守的な混雑制御応答で不適切な動作につながる可能性があります。まず、RTOの再送信の承認が以前に送信者に到着するように、大規模なパケットの並べ替えが発生した場合元の送信の承認、送信者は、RTOを引き起こしたセグメントの損失を検出しない場合があります。第二に、悪意のあるレシーバーは、RTOが受け取っていないセグメントを確認することにより、RTOの後にF-RTOを導いて間違った結論を出すことができます。ただし、このようなレシーバーは、送信者と受信機の間のTCP状態の一貫性を破るリスクを冒して、接続が使用できなくなり、受信者にとって利益はありません。したがって、受信者がそのようなトリックを重要な規模で採用し始める可能性は低いと考えています。最後に、DSACKなどの明示的な確認スキームを使用せずに、不必要なRTOの再送信の喪失は検出できません。これは、偽のRTOを検出するための他のメカニズムと、DSACKを使用していない通常のTCPに共通しています。偽のRTOに対する混雑制御応答が十分に保守的である場合、上記のコーナーケースは混雑の増加により問題を引き起こさないことに注意してください。
The main security threat regarding F-RTO is the possibility that a receiver could mislead the sender into setting too large a congestion window after an RTO. There are two possible ways a malicious receiver could trigger a wrong output from the F-RTO algorithm. First, the receiver can acknowledge data that it has not received. Second, it can delay acknowledgment of a segment it has received earlier, and acknowledge the segment after the TCP sender has been deluded to enter algorithm step 3.
F-RTOに関する主なセキュリティの脅威は、受信者がRTOの後に渋滞ウィンドウを大きすぎる設定に送信者を誤解させる可能性があることです。悪意のある受信機がF-RTOアルゴリズムからの間違った出力をトリガーできる2つの可能な方法があります。まず、受信者は受信していないデータを確認できます。第二に、以前に受け取ったセグメントの承認を遅らせることができ、TCP送信者がアルゴリズムのステップ3に入ることを惑わされた後にセグメントを認めることができます。
If the receiver acknowledges a segment it has not really received, the sender can be led to declare spurious timeout in the F-RTO algorithm, step 3. However, because the sender will have an incorrect state, it cannot retransmit the segment that has never reached the receiver. Therefore, this attack is unlikely to be useful for the receiver to maliciously gain a larger congestion window.
受信者が実際に受け取っていないセグメントを認めている場合、送信者はF-RTOアルゴリズムでスプリアスタイムアウトを宣言することができます。ステップ3は、送信者が間違った状態を持つため、受信機に到達しました。したがって、この攻撃は、受信者が悪意を持ってより大きな混雑ウィンドウを獲得するのに役立つ可能性は低いです。
A common case for a retransmission timeout is that a fast retransmission of a segment is lost. If all other segments have been received, the RTO retransmission causes the whole window to be acknowledged at once. This case is recognized in F-RTO algorithm branch (2a). However, if the receiver only acknowledges one segment after receiving the RTO retransmission, and then the rest of the segments, it could cause the timeout to be declared spurious when it is not. Therefore, it is suggested that, when an RTO occurs during the fast recovery phase, the sender would not fully revert the congestion window even if the timeout was declared spurious. Instead, the sender would reduce the congestion window to 1.
再送信タイムアウトの一般的なケースは、セグメントの迅速な再送信が失われることです。他のすべてのセグメントを受け取った場合、RTOの再送信により、ウィンドウ全体が一度に確認されます。このケースは、F-RTOアルゴリズム分岐（2A）で認識されています。ただし、RTOの再送信を受信した後、レシーバーが1つのセグメントのみを認め、残りのセグメントを認識している場合、タイムアウトがそうでない場合は偽りと宣言される可能性があります。したがって、高速回復段階でRTOが発生した場合、タイムアウトがスプリアスと宣言された場合でも、送信者は混雑ウィンドウを完全に戻さないことが示唆されています。代わりに、送信者は混雑ウィンドウを1に減らします。
If there is more than one segment missing at the time of a retransmission timeout, the receiver does not benefit from misleading the sender to declare a spurious timeout because the sender would have to go through another recovery period to retransmit the missing segments, usually after an RTO has elapsed.
再送信タイムアウトの時点で複数のセグメントがない場合、受信者は、送信者が失われたセグメントを再送信するために別の回復期間を経る必要があるため、偽のタイムアウトを宣言するために送信者を誤解させることから利益を得ません。RTOが経過しました。
The authors would like to thank Alfred Hoenes, Ilpo Jarvinen, and Murari Sridharan for the comments on this document.
著者は、この文書に関するコメントについて、Alfred Hoenes、Ilpo Jarvinen、Murari Sridharanに感謝したいと思います。
We are also thankful to Reiner Ludwig, Andrei Gurtov, Josh Blanton, Mark Allman, Sally Floyd, Yogesh Swami, Mika Liljeberg, Ivan Arias Rodriguez, Sourabh Ladha, Martin Duke, Motoharu Miyake, Ted Faber, Samu Kontinen, and Kostas Pentikousis who gave valuable feedback during the preparation of RFC 4138, the precursor of this document.
また、Reiner Ludwig、Andrei Gurtov、Josh Blanton、Mark Allman、Sally Floyd、Yogesh Swami、Mika Liljeberg、Ivan Arias Rodriguez、Sourabh Ladha、Martin Duke、Motoharu Miyake、Ted Faber、Samu Kontinen、Kostinen、Kostinen、Kostinen、Kostinen、Kostinenを与えました。このドキュメントの前駆体であるRFC 4138の準備中の貴重なフィードバック。
When the advertised window limits the transmission of two new previously unsent segments, or there are no new data to send, it is recommended in F-RTO algorithm step (2b) that the TCP sender continue with the conventional RTO recovery algorithm. The disadvantage is that the sender may continue unnecessary retransmissions due to possible spurious timeout. This section briefly discusses the options that can potentially improve performance when transmitting previously unsent data is not possible.
広告ウィンドウが2つの新しい以前に確信していないセグメントの送信を制限する場合、または送信する新しいデータがない場合、F-RTOアルゴリズムステップ（2B）では、TCP送信者が従来のRTO回復アルゴリズムを継続することをお勧めします。不利な点は、偽のタイムアウトの可能性があるため、送信者が不必要な再送信を継続できることです。このセクションでは、以前に安全でないデータを送信することが不可能なときにパフォーマンスを改善できる可能性のあるオプションについて簡単に説明します。
- The TCP sender could reserve an unused space of a size of one or two segments in the advertised window to ensure the use of algorithms such as F-RTO or Limited Transmit [ABF01] in receiver window-limited situations. On the other hand, while doing this, the TCP sender should ensure that the window of outstanding segments is large enough for proper utilization of the available pipe.
- TCP送信者は、広告ウィンドウ内の1つまたは2つのセグメントのサイズの未使用スペースを予約して、F-RTOやLimited送信[ABF01]などのアルゴリズムの使用を受信機ウィンドウ制限状況で確実に使用できます。一方、これを行っている間、TCP送信者は、優れたセグメントのウィンドウが利用可能なパイプを適切に利用するのに十分な大きさであることを確認する必要があります。
- Use additional information if available, e.g., TCP timestamps with the Eifel Detection algorithm, for detecting a spurious timeout. However, Eifel detection may yield different results from F-RTO when ACK losses and an RTO occur within the same round-trip time [SKR03].
- 利用可能な場合は、eifel検出アルゴリズムを備えたTCPタイムスタンプを使用して、偽のタイムアウトを検出するための追加情報を使用してください。ただし、ACKの損失とRTOが同じ往復時間内に発生すると、EIFEL検出がF-RTOから異なる結果をもたらす可能性があります[SKR03]。
- Retransmit data from the tail of the retransmission queue and continue with step 3 of the F-RTO algorithm. It is possible that the retransmission will be made unnecessarily. Furthermore, the operation of the SACK-based F-RTO algorithm would need to consider this case separately, to not use the retransmitted segment to indicate spurious timeout. Given these considerations, this option is not recommended.
- 再送信キューの尾からデータを再送信し、F-RTOアルゴリズムのステップ3で続行します。再送信が不必要に行われる可能性があります。さらに、SACKベースのF-RTOアルゴリズムの動作は、再送信セグメントを使用してスプリアスタイムアウトを示すために、このケースを個別に考慮する必要があります。これらの考慮事項を考えると、このオプションは推奨されません。
- Send a zero-sized segment below SND.UNA, similar to a TCP Keep-Alive probe, and continue with step 3 of the F-RTO algorithm. Because the receiver replies with a duplicate ACK, the sender is able to detect whether the timeout was spurious from the incoming acknowledgment. This method does not send data unnecessarily, but it delays the recovery by one round-trip time in cases where the timeout was not spurious. Therefore, this method is not encouraged.
- TCP Keep-Aliveプローブと同様に、SND.UNAの下にゼロサイズのセグメントを送信し、F-RTOアルゴリズムのステップ3を続行します。受信者は重複したACKで返信するため、送信者はタイムアウトが着信の謝辞から偽物であるかどうかを検出できます。この方法では不必要にデータを送信しませんが、タイムアウトがスプリアスではない場合に、回復を1回の往復時間で遅らせます。したがって、この方法は奨励されていません。
- In receiver-limited cases, send one octet of new data, regardless of the advertised window limit, and continue with step 3 of the F-RTO algorithm. It is possible that the receiver will have free buffer space to receive the data by the time the segment has propagated through the network, in which case no harm is done. If the receiver is not capable of receiving the segment, it rejects the segment and sends a duplicate ACK.
- レシーバーが制限されたケースでは、広告されたウィンドウの制限に関係なく、新しいデータの1オクテットを送信し、F-RTOアルゴリズムのステップ3を続行します。セグメントがネットワークを介して伝播するまでにデータを受信するための無料バッファースペースがある可能性があります。その場合、害はありません。受信機がセグメントを受信できない場合、セグメントを拒否し、重複したACKを送信します。
Changes from RFC 4138 are summarized below, apart from minor editing and language improvements.
RFC 4138からの変更は、マイナーな編集と言語の改善とは別に、以下に要約されています。
* Modified the basic F-RTO algorithm and the SACK-enhanced F-RTO algorithm to prevent the TCP sender from applying the F-RTO algorithm if the retransmission timer expires when an earlier RTO recovery is underway, except when the retransmission timer expires multiple times for the same segment.
* 基本的なF-RTOアルゴリズムとサック強化F-RTOアルゴリズムを変更して、再送信タイマーが進行中のときに再送信タイマーが期限切れになった場合、TCP送信者がF-RTOアルゴリズムの適用を防ぐために、再送信タイマーが複数回期限切れになる場合を除きます。同じセグメント。
* Clarified behavior on multiple timeouts.
* 複数のタイムアウトでの明確な動作。
* Added a paragraph on acknowledgments that do not acknowledge new data but are not duplicate acknowledgments.
* 新しいデータを認めていないが重複した謝辞ではない謝辞に段落を追加しました。
* Clarified the SACK-algorithm a bit, and added one paragraph of description of the basic idea of the algorithm.
* サックアルゴリズムを少し明確にし、アルゴリズムの基本的なアイデアの説明の段落を1つ追加しました。
* Removed SCTP considerations.
* SCTPの考慮事項を削除しました。
* Removed earlier Appendix sections, except Appendix C from RFC 4138, which is now Appendix A.
* RFC 4138の付録Cを除く以前の付録セクションを削除しました。現在、付録Aになります。
* Clarified text about the possible response algorithms.
* 可能な応答アルゴリズムに関するテキストを明確にしました。
* Added section that summarizes the evaluation of RFC 4138.
* RFC 4138の評価をまとめたセクションを追加しました。
References
参考文献
Normative References
引用文献
[APB09] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[APB09] Allman、M.、Paxson、V。、およびE. Blanton、「TCP混雑制御」、RFC 5681、2009年9月。
[BAFW03] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[BAFW03] Blanton、E.、Allman、M.、Fall、K。、およびL. Wang、「TCPの保守的な選択的承認（SACK）ベースの損失回復アルゴリズム」、RFC 3517、2003年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[FHG04] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 3782, April 2004.
[FHG04] Floyd、S.、Henderson、T。、およびA. Gurtov、「TCPの高速回復アルゴリズムへのNewreno修正」、RFC 3782、2004年4月。
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[MMFR96] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Auncedcement Options」、RFC 2018、1996年10月。
[PA00] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[PA00] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[POS81] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
Informative References
参考引用
[ABF01] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[ABF01] Allman、M.、Balakrishnan、H。、およびS. Floyd、「限られた送信を使用したTCPの損失回復の強化」、RFC 3042、2001年1月。
[BA04] 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, February 2004.
[BA04] Blanton、E。およびM. Allman、「TCPを使用して、選択的承認（DSACK）およびストリーム制御伝送プロトコル（SCTP）の重複透過シーケンス番号（TSN）を使用して、Spurious Recransisionsを検出します。
[BBA06] Blanton, J., Blanton, E., and M. Allman, "Using Spurious Retransmissions to Adapt the Retransmission Timeout", Work in Progress, December 2006.
[BBA06] Blanton、J.、Blanton、E。、およびM. Allman、「偽りの再送信を使用して再送信タイムアウトを適応させる」、2006年12月、進行中の作業。
[BBJ92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[BBJ92] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のためのTCP拡張」、RFC 1323、1992年5月。
[FMMP00] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[FMMP00] Floyd、S.、Mahdavi、J.、Mathis、M。、およびM. Podolsky、「TCPの選択的承認（SACK）オプションの拡張」、RFC 2883、2000年7月。
[GL02] Gurtov A. and R. Ludwig, "Evaluating the Eifel Algorithm for TCP in a GPRS Network", In Proc. European Wireless, Florence, Italy, February 2002.
[GL02] Gurtov A.およびR. Ludwig、「GPRSネットワークでのTCPのEIFELアルゴリズムの評価」、Proc。ヨーロッパワイヤレス、フィレンツェ、イタリア、2002年2月。
[GL03] Gurtov A. and R. Ludwig, "Responding to Spurious Timeouts in TCP", In Proc. IEEE INFOCOM 03, San Francisco, CA, USA, March 2003.
[GL03] Gurtov A.およびR. Ludwig、「TCPでのスプリアスタイムアウトへの対応」、Proc。IEEE Infocom 03、米国カリフォルニア州サンフランシスコ、2003年3月。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", In Proc. ACM SIGCOMM 88.
[Jac88] Jacobson、V。、「混雑の回避と制御」、Proc。ACM SIGCOMM 88。
[Hok05] Hokamura, A., et al., "Performance Evaluation of F-RTO and Eifel Response Algorithms over W-CDMA packet network", In Proc. Wireless Personal Multimedia Communications (WPMC'05), Sept. 2005.
[HOK05]北村、A。、他、「W-CDMAパケットネットワーク上のF-RTOおよびEIFEL応答アルゴリズムのパフォーマンス評価」、Proc。ワイヤレスパーソナルマルチメディアコミュニケーション（WPMC'05）、2005年9月。
[KYHS07] Kojo, M., Yamamoto, K., Hata, M., and P. Sarolahti, "Evaluation of RFC 4138", Work in Progress, November 2007.
[Kyhs07] Kojo、M.、Yamamoto、K.、Hata、M.、およびP. Sarolahti、「RFC 4138の評価」、2007年11月、作業進行中。
[LG05] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, February 2005.
[LG05] Ludwig、R。およびA. Gurtov、「TCPのEIFEL応答アルゴリズム」、RFC 4015、2005年2月。
[LK00] Ludwig R. and R.H. Katz, "The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions", ACM SIGCOMM Computer Communication Review, 30(1), January 2000.
[LK00] Ludwig R.およびR.H. Katz、「アイフェルアルゴリズム：スプリアスレトランミッションに対してTCPを堅牢にする」、ACM Sigcomm Computer Communication Review、30（1）、2000年1月。
[LM03] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[LM03] Ludwig、R。およびM. Meyer、「TCPのEIFEL検出アルゴリズム」、RFC 3522、2003年4月。
[Nag84] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[Nag84] Nagle、J。、「IP/TCPインターネットワークスの混雑制御」、RFC 896、1984年1月。
[SK05] Sarolahti, P. and M. Kojo, "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)", RFC 4138, August 2005.
[Sk05] Sarolahti、P。and M. Kojo、「Forward RTO-Recovery（F-RTO）：TCPおよびTCPおよびThe Stream Control Transmission Protocol（SCTP）を使用した偽の再送信タイムアウトを検出するためのアルゴリズム」、RFC 4138、2005年8月。
[SKR03] Sarolahti, P., Kojo, M., and K. Raatikainen, "F-RTO: An Enhanced Recovery Algorithm for TCP Retransmission Timeouts", ACM SIGCOMM Computer Communication Review, 33(2), April 2003.
[SKR03] Sarolahti、P.、Kojo、M。、およびK. Raatikainen、「F-RTO：TCP再送信タイムアウトの拡張回復アルゴリズム」、ACM Sigcomm Computer Communication Review、33（2）、2003年4月。
[Sar03] Sarolahti, P., "Congestion Control on Spurious TCP Retransmission Timeouts", In Proc. of IEEE Globecom 2003, San Francisco, CA, USA. December 2003.
[SAR03] Sarolahti、P。、「偽のTCP再送信タイムアウトに関する混雑制御」、Proc。IEEE Globecom 2003、米国カリフォルニア州サンフランシスコ。2003年12月。
[SL03] Swami Y. and K. Le, "DCLOR: De-correlated Loss Recovery using SACK Option for spurious timeouts", Work in Progress, September 2003.
[SL03] Swami Y. and K. Le、「Dclor：Spourious TimeoutにSackオプションを使用した相関損失の回復」、2003年9月、進行中の作業。
[Ste07] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[Ste07] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[Yam05] Yamamoto, K., et al., "Effects of F-RTO and Eifel Response Algorithms for W-CDMA and HSDPA networks", In Proc. Wireless Personal Multimedia Communications (WPMC'05), September 2005.
[Yam05] Yamamoto、K.、et al。、「W-CDMAおよびHSDPAネットワークのF-RTOおよびEIFEL応答アルゴリズムの効果」、Proc。ワイヤレスパーソナルマルチメディアコミュニケーション（WPMC'05）、2005年9月。
Authors' Addresses
著者のアドレス
Pasi Sarolahti Nokia Research Center P.O. Box 407 FI-00045 NOKIA GROUP Finland Phone: +358 50 4876607 EMail: pasi.sarolahti@iki.fi
Pasi Sarolahti Nokia Research Center P.O.Box 407 Fi-00045 Nokia Group Finland電話：358 50 4876607メール：pasi.sarolahti@iki.fi
Markku Kojo University of Helsinki P.O. Box 68 FI-00014 UNIVERSITY OF HELSINKI Finland Phone: +358 9 19151305 EMail: kojo@cs.helsinki.fi
ヘルシンキ大学マルクコホ大学P.O.ボックス68 FI-00014ヘルシンキ大学フィンランド大学電話：358 9 19151305メール：kojo@cs.helsinki.fi
Kazunori Yamamoto NTT Docomo, Inc. 3-5 Hikarinooka, Yokosuka, Kanagawa, 239-8536, Japan Phone: +81-46-840-3812 EMail: yamamotokaz@nttdocomo.co.jp
kazunori yamamoto ntt docomo、Inc。3-5 Hikarinooka、Yokosuka、Kanagawa、239-8536、日本電話：81-46-840-3812電子メール：yamamotokaz@nttdocomo.co.jp
Max Hata NTT Docomo, Inc. 3-5 Hikarinooka, Yokosuka, Kanagawa, 239-8536, Japan Phone: +81-46-840-3812 EMail: hatama@s1.nttdocomo.co.jp
Max Hata Ntt Docomo、Inc。3-5 Hikarinooka、Yokosuka、Kanagawa、239-8536、日本電話：81-46-840-3812メール：hatama@s1.nttdocomo.co.jp