[要約] RFC 3708は、TCP Duplicate Selective Acknowledgement（DSACKs）とStream Control Transmission Protocol（SCTP）Duplicate Transmission Sequence Numbers（TSNs）を使用して、誤った再送信を検出するための方法を提案しています。このRFCの目的は、ネットワーク上でのパフォーマンス向上と信頼性の向上です。
Network Working Group E. Blanton
Request for Comments: 3708 Purdue University
Category: Experimental M. Allman
ICIR
February 2004
Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions
TCPを使用して、選択的承認（DSACK）およびストリーム制御伝送プロトコル（SCTP）重複伝送シーケンス番号（TSNS）を使用して、スプリアスな再送信を検出します
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate Selective Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number (TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications.
TCPおよびストリーム制御伝送プロトコル（SCTP）は、それぞれ重複選択的承認（DSACK）と重複伝送シーケンス番号（TSN）通知を介して、重複セグメント領収書の通知を提供します。このドキュメントでは、この情報を使用して、さまざまなアプリケーションの不必要な再送信を特定する保守的な方法を示しています。
TCP [RFC793] and SCTP [RFC2960] provide notification of duplicate segment receipt through duplicate selective acknowledgment (DSACK) [RFC2883] and Duplicate TSN notifications, respectively. Using this information, a TCP or SCTP sender can generally determine when a retransmission was sent in error. This document presents two methods for using duplicate notifications. The first method is simple and can be used for accounting applications. The second method is a conservative algorithm to disambiguate unnecessary retransmissions from loss events for the purpose of undoing unnecessary congestion control changes.
TCP [RFC793]およびSCTP [RFC2960]は、それぞれ重複選択的承認（DSACK）[RFC2883]および重複TSN通知を介して、重複セグメント領収書の通知を提供します。この情報を使用して、TCPまたはSCTP送信者は一般に、再送信がいつ誤って送信されたかを判断できます。このドキュメントでは、重複通知を使用する2つの方法を示します。最初の方法はシンプルで、会計アプリケーションに使用できます。2番目の方法は、不必要な輻輳制御の変更を取り消す目的で、損失イベントから不必要な再送信を露出させる保守的なアルゴリズムです。
This document is intended to outline reasonable and safe algorithms for detecting spurious retransmissions and discuss some of the considerations involved. It is not intended to describe the only possible method for achieving the goal, although the guidelines in this document should be taken into consideration when designing alternate algorithms. Additionally, this document does not outline what a TCP or SCTP sender may do after a spurious retransmission is detected. A number of proposals have been developed (e.g., [RFC3522], [SK03], [BDA03]), but it is not yet clear which of these proposals are appropriate. In addition, they all rely on detecting spurious retransmits and so can share the algorithm specified in this document.
このドキュメントは、スプリアスな再送信を検出するための合理的で安全なアルゴリズムを概説し、関連する考慮事項のいくつかを議論することを目的としています。目標を達成するための唯一の可能な方法を説明することは意図されていませんが、このドキュメントのガイドラインは、代替アルゴリズムを設計する際に考慮する必要があります。さらに、このドキュメントでは、偽の再送信が検出された後、TCPまたはSCTP送信者が何をするか概説しません。多くの提案が開発されています（例：[RFC3522]、[SK03]、[BDA03]）が、これらの提案のどれが適切であるかはまだ明らかではありません。さらに、それらはすべて、偽の再送信の検出に依存しているため、このドキュメントで指定されたアルゴリズムを共有できます。
Finally, we note that to simplify the text much of the following discussion is in terms of TCP DSACKs, while applying to both TCP and SCTP.
最後に、テキストを簡素化するために、TCPとSCTPの両方に適用しながら、以下の議論の多くはTCP DSACKSの観点からであることに注意してください。
Terminology
用語
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]で説明されているように解釈されます。
For certain applications a straight count of duplicate notifications will suffice. For instance, if a stack simply wants to know (for some reason) the number of spuriously retransmitted segments, counting all duplicate notifications for retransmitted segments should work well. Another application of this strategy is to monitor and adapt transport algorithms so that the transport is not sending large amounts of spurious data into the network. For instance, monitoring duplicate notifications could be used by the Early Retransmit [AAAB03] algorithm to determine whether fast retransmitting [RFC2581] segments with a lower than normal duplicate ACK threshold is working, or if segment reordering is causing spurious retransmits.
特定のアプリケーションでは、重複通知の直線で十分です。たとえば、スタックが単に（何らかの理由で）スモールで再送信されたセグメントの数を単に知りたい場合、再送信セグメントのすべての重複通知をカウントすることはうまく機能するはずです。この戦略のもう1つのアプリケーションは、輸送がネットワークに大量の偽データを送信しないように、輸送アルゴリズムを監視および適応させることです。たとえば、初期の再送信[AAAB03]アルゴリズムでは、複製通知の監視を使用して、通常の重複よりも低いACKしきい値よりも低いセグメントが機能しているかどうか、またはセグメントの並べ替えが途方もない再送信を引き起こしているかどうかを判断することができます。
More speculatively, duplicate notification has been proposed as an integral part of estimating TCP's total loss rate [AEO03] for the purposes of mitigating the impact of corruption-based losses on transport protocol performance. [EOA03] proposes altering the transport's congestion response to the fraction of losses that are actually due to congestion by requiring the network to provide the corruption-based loss rate and making the transport sender estimate the total loss rate. Duplicate notifications are a key part of estimating the total loss rate accurately [AEO03].
より投機的に、輸送プロトコルのパフォーマンスに対する腐敗ベースの損失の影響を軽減する目的で、TCPの総損失率[AEO03]を推定するための不可欠な部分として、重複通知が提案されています。[EOA03]は、ネットワークに腐敗ベースの損失率を提供し、輸送送信者に総損失率を推定することを要求することにより、実際に渋滞による損失の割合に対する輸送の輻輳応答を変更することを提案しています。重複通知は、総損失率を正確に推定する重要な部分です[AEO03]。
When the purpose of detecting spurious retransmissions is to "undo" unnecessary changes made to the congestion control state, as suggested in [RFC2883], the data sender ideally needs to determine:
疑いのある再送信を検出する目的が、[RFC2883]で示唆されているように、渋滞制御状態に対して不要な変更を「元に戻す」ことである場合、データ送信者は理想的には決定する必要があります。
(a) That spurious retransmissions in a particular window of data do not mask real segment loss (congestion).
(a) データの特定のウィンドウでの偽の再送信は、実際のセグメントの損失を隠していません（輻輳）。
For example, assume segments N and N+1 are retransmitted even though only segment N was dropped by the network (thus, segment N+1 was needlessly retransmitted). When the sender receives the notification that segment N+1 arrived more than once it can conclude that segment N+1 was needlessly resent. However, it cannot conclude that it is appropriate to revert the congestion control state because the window of data contained at least one valid congestion indication (i.e., segment N was lost).
たとえば、セグメントnのみがネットワークによってドロップされた場合でも、セグメントnとn 1が再送信されると仮定します（したがって、セグメントn 1は不必要に再送信されました）。送信者がセグメントn 1が複数回到着したという通知を受け取ると、セグメントn 1が不必要にresしていると結論付けることができます。ただし、データのウィンドウに少なくとも1つの有効な渋滞表示が含まれていたため、輻輳制御状態を元に戻すことは適切であると結論付けることはできません（つまり、セグメントnが失われました）。
(b) That network duplication is not the cause of the duplicate notification.
(b) そのネットワークの複製は、複製通知の原因ではありません。
Determining whether a duplicate notification is caused by network duplication of a packet or a spurious retransmit is a nearly impossible task in theory. Since [Pax97] shows that packet duplication by the network is rare, the algorithm in this section simply ceases to function when network duplication is detected (by receiving a duplication notification for a segment that was not retransmitted by the sender).
重複通知がパケットのネットワークの複製または偽の再送信によって引き起こされるかどうかを判断することは、理論上、ほぼ不可能なタスクです。[Pax97]はネットワークによるパケットの複製がまれであることを示すため、このセクションのアルゴリズムは、ネットワークの複製が検出されたときに機能しなくなります（送信者によって再送信されないセグメントの重複通知を受信することにより）。
The algorithm specified below gives reasonable, but not complete, protection against both of these cases.
以下に指定されたアルゴリズムは、これらの両方のケースに対して合理的な、しかし完全ではない保護を提供します。
We assume the TCP sender has a data structure to hold selective acknowledgment information (e.g., as outlined in [RFC3517]). The following steps require an extension of such a 'scoreboard' to incorporate a slightly longer history of retransmissions than called for in [RFC3517]. The following steps MUST be taken upon the receipt of each DSACK or duplicate TSN notification:
TCP送信者には、選択的な確認情報を保持するためのデータ構造があると仮定します（たとえば、[RFC3517]で概説されているように）。次の手順では、[RFC3517]で求められるよりもわずかに長い再送信の履歴を組み込むために、このような「スコアボード」の拡張が必要です。次の手順は、各DSACKの受領時に実行するか、TSN通知を複製する必要があります。
(A) Check the corresponding sequence range or TSN to determine whether the segment has been retransmitted.
（a）対応するシーケンス範囲またはTSNを確認して、セグメントが再送信されたかどうかを判断します。
(A.1) If the SACK scoreboard is empty (i.e., the TCP sender has received no SACK information from the receiver) and the left edge of the incoming DSACK is equal to SND.UNA, processing of this DSACK MUST be terminated and the congestion control state MUST NOT be reverted during the current window of data. This clause intends to cover the case when an entire window of acknowledgments have been dropped by the network. In such a case, the reverse path seems to be in a congested state and so reducing TCP's sending rate is the conservative approach.
（A.1）サックスコアボードが空の場合（つまり、TCP送信者が受信機からサック情報を受け取っていない場合）、入ってくるDSACKの左端はSND.UNAに等しく、このDSACKの処理は終了する必要があり、輻輳制御状態は、現在のデータウィンドウ中に戻ってはいけません。この条項は、謝辞のウィンドウ全体がネットワークによって削除された場合に、ケースをカバーする予定です。そのような場合、逆の経路は混雑状態にあるようであるため、TCPの送信率を下げることは保守的なアプローチです。
(A.2) If the segment was retransmitted exactly one time, mark it as a duplicate.
（A.2）セグメントが正確に1回再送信された場合、それを複製としてマークします。
(A.3) If the segment was retransmitted more than once processing of this DSACK MUST be terminated and the congestion control state MUST NOT be reverted to its previous state during the current window of data.
（A.3）セグメントがこのDSACKの処理を1回以上再送信した場合、現在のデータウィンドウ中に輻輳制御状態を前の状態に戻さないでください。
(A.4) If the segment was not retransmitted the incoming DSACK indicates that the network duplicated the segment in question. Processing of this DSACK MUST be terminated. In addition, the algorithm specified in this document MUST NOT be used for the remainder of the connection, as future DSACK reports may be indicating network duplication rather than unnecessary retransmission. Note that some techniques to further disambiguate network duplication from unnecessary retransmission (e.g., the TCP timestamp option [RFC1323]) may be used to refine the algorithm in this document further. Using such a technique in conjunction with an algorithm similar to the one presented herein may allow for the continued use of the algorithm in the face of duplicated segments. We do not delve into such an algorithm in this document due the current rarity of network duplication. However, future work should include tackling this problem.
（A.4）セグメントが再送信されなかった場合、着信DSACKは、ネットワークが問題のセグメントを複製したことを示します。このDSACKの処理は終了する必要があります。さらに、このドキュメントで指定されているアルゴリズムは、将来のDSACKレポートが不必要な再送信ではなくネットワークの複製を示している可能性があるため、接続の残りに使用してはなりません。不必要な再送信からネットワークの複製をさらに微分するためのいくつかの手法（たとえば、TCPタイムスタンプオプション[RFC1323]）を使用して、このドキュメントのアルゴリズムをさらに改善することができることに注意してください。このような手法を使用すると、ここで提示されたものと同様のアルゴリズムと組み合わせて、重複したセグメントに直面してアルゴリズムを継続的に使用できる場合があります。ネットワークの複製の現在の希少性のため、このドキュメントでは、このようなアルゴリズムを掘り下げません。ただし、将来の作業には、この問題への取り組みが含まれる必要があります。
(B) Assuming processing is allowed to continue (per the (A) rules), check all retransmitted segments in the previous window of data.
（b）処理が継続できると仮定すると（（a）ルールごとに）、以前のデータウィンドウのすべての再送信セグメントを確認します。
(B.1) If all segments or chunks marked as retransmitted have also been marked as acknowledged and duplicated, we conclude that all retransmissions in the previous window of data were spurious and no loss occurred.
（b.1）再送信としてマークされたすべてのセグメントまたはチャンクが認められて複製されているとマークされている場合、前のデータウィンドウのすべての再送信は偽りであり、損失は発生しなかったと結論付けます。
(B.2) If any segment or chunk is still marked as retransmitted but not marked as duplicate, there are outstanding retransmissions that could indicate loss within this window of data. We can make no conclusions based on this particular DSACK/duplicate TSN notification.
（b.2）任意のセグメントまたはチャンクがまだ再送信としてマークされているが重複としてマークされていない場合、このデータウィンドウ内の損失を示す可能性のある未解決の再送信があります。この特定のDSACK/複製TSN通知に基づいて結論を出すことはできません。
In addition to keeping the state mentioned in [RFC3517] (for TCP) and [RFC2960] (for SCTP), an implementation of this algorithm must track all sequence numbers or TSNs that have been acknowledged as duplicates.
[RFC3517]（TCPの場合）および[RFC2960]（SCTPの場合）で言及された状態を維持することに加えて、このアルゴリズムの実装は、重複として認められているすべてのシーケンス番号またはTSNを追跡する必要があります。
In addition to the mechanism for detecting spurious retransmits outlined in this document, several other proposals for finding needless retransmits have been developed.
このドキュメントで概説されている偽の再送信を検出するためのメカニズムに加えて、不必要な再送信を見つけるための他のいくつかの提案が開発されました。
[BA02] uses the algorithm outlined in this document as the basis for investigating several methods to make TCP more robust to reordered packets.
[BA02]は、このドキュメントで概説されているアルゴリズムを、TCPをより堅牢にするためのいくつかの方法を調査するための基礎として使用します。
The Eifel detection algorithm [RFC3522] uses the TCP timestamp option [RFC1323] to determine whether the ACK for a given retransmit is for the original transmission or a retransmission. More generally, [LK00] outlines the benefits of detecting spurious retransmits and reverting from needless congestion control changes using the timestamp-based scheme or a mechanism that uses a "retransmit bit" to flag retransmits (and ACKs of retransmits). The Eifel detection algorithm can detect spurious retransmits more rapidly than a DSACK-based scheme. However, the tradeoff is that the overhead of the 12- byte timestamp option must be incurred in every packet transmitted for Eifel to function.
EIFEL検出アルゴリズム[RFC3522]は、TCPタイムスタンプオプション[RFC1323]を使用して、特定の再送信のACKが元の送信または再送信用かどうかを判断します。より一般的には、[LK00]は、タイムスタンプベースのスキームを使用して、「再送信ビット」を使用して再応答（および再送信のアクック）を使用して、偽の再送信を検出し、不必要な渋滞制御の変更から戻ることの利点を概説しています。EIFEL検出アルゴリズムは、DSACKベースのスキームよりも迅速に偽の再送信を検出できます。ただし、トレードオフは、12バイトタイムスタンプオプションのオーバーヘッドを、機能するために送信されるすべてのパケットで発生する必要があることです。
The F-RTO scheme [SK03] slightly alters TCP's sending pattern immediately following a retransmission timeout and then observes the pattern of the returning ACKs. This pattern can indicate whether the retransmitted segment was needed. The advantage of F-RTO is that the algorithm only needs to be implemented on the sender side of the TCP connection and that nothing extra needs to cross the network (e.g., DSACKs, timestamps, special flags, etc.). The downside is that the algorithm is a heuristic that can be confused by network pathologies (e.g., duplication or reordering of key packets). Finally, note that F-RTO only works for spurious retransmits triggered by the transport's retransmission timer.
F-RTOスキーム[SK03]は、再送信タイムアウトの直後にTCPの送信パターンをわずかに変更し、戻ってくるACKのパターンを観察します。このパターンは、再送信セグメントが必要かどうかを示します。F-RTOの利点は、アルゴリズムをTCP接続の送信者側にのみ実装する必要があり、ネットワークを横断する必要はないこと（DSACKS、タイムスタンプ、特別なフラグなど）。マイナス面は、アルゴリズムがネットワークの病理（例えば、キーパケットの重複または並べ替え）によって混乱する可能性のあるヒューリスティックであることです。最後に、F-RTOは、トランスポートの再送信タイマーによってトリガーされる偽の再送信にのみ機能することに注意してください。
Finally, [AP99] briefly investigates using the time between retransmitting a segment via the retransmission timeout and the arrival of the next ACK as an indicator of whether the retransmit was needed. The scheme compares this time delta with a fraction (f) of the minimum RTT observed thus far on the connection. If the time delta is less than f*minRTT then the retransmit is labeled spurious. When f=1/2 the algorithm identifies roughly 59% of the needless retransmission timeouts and identifies needed retransmits only 2.5% of the time. As with F-RTO, this scheme only detects spurious retransmits sent by the transport's retransmission timer.
最後に、[AP99]は、再送信タイムアウトを介してセグメントを再送信するまでの時間を使用して、再送信が必要かどうかの指標として次のACKの到着を使用して簡単に調査します。このスキームは、今回のデルタと、これまでに接続で観察された最小RTTの分数（f）を比較します。deltaがf*minrtt未満の場合、再送信にはスプリアスとラベル付けされます。F = 1/2の場合、アルゴリズムは不必要な再送信のタイムアウトの約59％を識別し、必要な再送信を識別します。F-RTOと同様に、このスキームは、トランスポートの再送信タイマーによって送信された偽の再送信のみを検出します。
It is possible for the receiver to falsely indicate spurious retransmissions in the case of actual loss, potentially causing a TCP or SCTP sender to inaccurately conclude that no loss took place (and possibly cause inappropriate changes to the senders congestion control state).
実際の損失の場合、受信者が偽りの再送信を誤って示すことが可能であり、TCPまたはSCTP送信者が潜在的に損失が発生しなかったと不正確に結論付ける可能性があります（そして、おそらく送信者の混雑管理状態に不適切な変更を引き起こす可能性があります）。
Consider the following scenario: A receiver watches every segment or chunk that arrives and acknowledges any segment that arrives out of order by more than some threshold amount as a duplicate, assuming that it is a retransmission. A sender using the above algorithm will assume that the retransmission was spurious.
次のシナリオを考慮してください。レシーバーは、到着するすべてのセグメントまたはチャンクを監視し、再送信であると仮定して、複数のしきい値を超えて到着しているセグメントを複製します。上記のアルゴリズムを使用する送信者は、再送信が偽物であると仮定します。
The ECN nonce sum proposal [RFC3540] could possibly help mitigate the ability of the receiver to hide real losses from the sender with modest extension. In the common case of receiving an original transmission and a spurious retransmit a receiver will have received the nonce from the original transmission and therefore can "prove" to the sender that the duplication notification is valid. In the case when the receiver did not receive the original and is trying to improperly induce the sender into transmitting at an inappropriately high rate, the receiver will not know the ECN nonce from the original segment and therefore will probabilistically not be able to fool the sender for long. [RFC3540] calls for disabling nonce sums on duplicate ACKs, which means that the nonce sum is not directly suitable for use as a mitigation to the problem of receivers lying about DSACK information. However, future efforts may be able to use [RFC3540] as a starting point for building protection should it be needed.
ECN NonCe Sum Proposal [RFC3540]は、控えめな拡張機能で送信者からの実際の損失を隠すレシーバーの能力を軽減するのに役立つ可能性があります。元の伝送と偽の再送信を受信する一般的なケースでは、受信者は元のトランスミッションからNonCEを受信し、したがって、重複通知が有効であることを送信者に「証明」することができます。受信者が元のものを受け取らず、送信者に不適切に高いレートで送信するように不適切に誘導しようとしている場合、受信者は元のセグメントからのECN Nonceを知らず、したがって、送信者を欺くことができないでしょう長い間。[RFC3540]は、重複したAcksの非CEの合計を無効にすることを求めています。つまり、NonCe Sumは、DSACK情報について嘘をついている受信機の問題の緩和として使用するのに直接適していません。ただし、将来の努力により、[RFC3540]が必要に応じて、構築保護の出発点として使用できる場合があります。
Sourabh Ladha and Reiner Ludwig made several useful comments on an earlier version of this document. The second author thanks BBN Technologies and NASA's Glenn Research Center for supporting this work.
Sourabh LadhaとReiner Ludwigは、このドキュメントの以前のバージョンについていくつかの有用なコメントをしました。2番目の著者は、BBN TechnologiesとNASAのグレン研究センターに感謝します。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[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月。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883] Floyd、S.、Mahdavi、J.、Mathis、M。、およびM. Podolsky、「TCPの選択的承認（SACK）オプションの拡張」、RFC 2883、2000年7月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。and V.Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[AAAB03] Allman, M., Avrachenkov, K., Ayesta, U. and J. Blanton, "Early Retransmit for TCP", Work in Progress, June 2003.
[AAAB03] Allman、M.、Avrachenkov、K.、Ayesta、U.およびJ. Blanton、「TCPの早期再送信」、2003年6月、進行中の作業。
[AEO03] Allman, M., Eddy, E. and S. Ostermann, "Estimating Loss Rates With TCP", Work in Progress, August 2003.
[AEO03] Allman、M.、Eddy、E。、およびS. Ostermann、「TCPによる損失率の推定」、2003年8月、進行中の作業。
[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM 99.
[AP99] Allman、M。およびV. Paxson、「エンドツーエンドのネットワークパスプロパティの推定について」、Sigcomm 99。
[BA02] Blanton, E. and M. Allman. On Making TCP More Robust to Packet Reordering. ACM Computer Communication Review, 32(1), January 2002.
[BA02] Blanton、E。およびM. Allman。TCPをパケットの並べ替えに対してより堅牢にすると。ACMコンピューター通信レビュー、32（1）、2002年1月。
[BDA03] Blanton, E., Dimond, R. and M. Allman, "Practices for TCP Senders in the Face of Segment Reordering", Work in Progress, February 2003.
[BDA03] Blanton、E.、Dimond、R。、およびM. Allman、「セグメントの並べ替えに直面したTCP送信者の実践」、2003年2月、Work in Progress。
[EOA03] Eddy, W., Ostermann, S. and M. Allman, "New Techniques for Making Transport Protocols Robust to Corruption-Based Loss", Work in Progress, July 2003.
[EOA03] Eddy、W.、Ostermann、S。、およびM. Allman、「腐敗ベースの損失に輸送プロトコルを堅牢にするための新しい技術」、2003年7月の作業。
[LK00] R. Ludwig, R. H. Katz. The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions. ACM Computer Communication Review, 30(1), January 2000.
[LK00] R. Ludwig、R。H. Katz。EIFELアルゴリズム：スプリアスな再送信に対してTCPを堅牢にする。ACMコンピューター通信レビュー、30（1）、2000年1月。
[Pax97] V. Paxson. End-to-End Internet Packet Dynamics. In ACM SIGCOMM, September 1997.
[Pax97] V. Paxson。エンドツーエンドのインターネットパケットダイナミクス。1997年9月、ACM Sigcommで。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、R。およびD. Borman、「TCP拡張機能のためのTCP拡張」、RFC 1323、1992年5月。
[RFC3517] Blanton, E., Allman, M., Fall, K. and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3517] Blanton、E.、Allman、M.、Fall、K。、およびL. Wang、「保守的な選択的承認（SACK）ベースの損失回復アルゴリズムのTCP」、RFC 3517、2003年4月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP," RFC 3522, April 2003.
[RFC3522] Ludwig、R。およびM. Meyer、「TCPのEIFEL検出アルゴリズム」、RFC 3522、2003年4月。
[RFC3540] Spring, N., Wetherall, D. and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540] Spring、N.、Wetherall、D。and D. Ely、「Noncesによる堅牢な明示的な混雑通知（ECN）シグナル伝達」、RFC 3540、2003年6月。
[SK03] Sarolahti, P. and M. Kojo, "F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP", Work in Progress, June 2003.
[Sk03] Sarolahti、P。and M. Kojo、「F-RTO：TCPおよびSCTPを使用して偽りの再送信タイムアウトを検出するためのアルゴリズム」、2003年6月、進行中の作業。
Ethan Blanton Purdue University Computer Sciences 1398 Computer Science Building West Lafayette, IN 47907
イーサンブラントンパデュー大学コンピューターサイエンス1398コンピューターサイエンスビル、ウェストラファイエット、47907
EMail: eblanton@cs.purdue.edu
Mark Allman ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704-1198 Phone: 216-243-7361
マークオールマンICSIセンターフォーインターネットリサーチ1947センターストリート、スイート600バークレー、カリフォルニア州94704-1198電話：216-243-7361
EMail: mallman@icir.org
http://www.icir.org/mallman/
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。