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
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（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）は、それぞれ、複製選択的確認応答（DSACKs）と重複送信シーケンス番号（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]、[RFC2883]の重複選択的確認応答（DSACK）を介して重複セグメント受信の通知を提供し、それぞれ、TSN通知が重複しています。再送が誤って送信されたときに、この情報を使用して、TCPまたはSCTP送信者は、一般的に決定することができます。この文書では、重複する通知を使用するための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.
特定の用途のために重複する通知のストレートカウントは十分です。スタックは、単純にすべての重複する通知を数え、（何らかの理由で）誤って再送セグメントの数を知りたい場合例えば、再送されたセグメントは、うまく動作するはずのために。この戦略のもう一つのアプリケーションは、トランスポートがネットワークに偽の大量のデータを送信しないように、トランスポート・アルゴリズムを監視し、適応させることです。例えば、重複通知を監視する高速重複ACK閾値が動作している、またはセグメント並べ替えは、スプリアス再送を引き起こしている場合は通常より低いと[RFC2581]のセグメントを再送するかどうかを決定するために初期再送[AAAB03]アルゴリズムで使用することができます。
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).
(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).
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.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の処理を終了しなければならなくて、輻輳制御状態は、データの現在のウィンドウの間、その前の状態に戻ってはいけません複数回セグメントが再送信された場合。
(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.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
（TCPの場合）[RFC3517]に記載された状態（SCTP用）[RFC2960]を維持することに加えて、このアルゴリズムの実装は、追跡しなければなりません
all sequence numbers or TSNs that have been acknowledged as duplicates.
重複として認知されているすべてのシーケンス番号またはの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.
アイフェル検出アルゴリズム[RFC3522]は、所与の再送信のためのACKは、元の送信または再送信のためのものであるかどうかを決定するためにTCPタイムスタンプオプション[RFC1323]を使用します。より一般的には、[LK00]はスプリアス再送を検出し、タイムスタンプベースのスキーム又はフラグ再送（及び再送のACKの）を「再送信ビットを」使用するメカニズムを使用して、不必要輻輳制御変化から復帰の利点を概説します。アイフェル検出アルゴリズムは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）と、この時間デルタを比較します。時間デルタが* minRTT fより小さい場合、再送信は偽標識されています。 / 2をF =ときにアルゴリズムが不要再送タイムアウトの約59％を識別し、必要識別する時間のわずか2.5％に再送信します。 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ナンス和提案[RFC3540]は、おそらく控えめな拡張子の付いた送信者からの実際の損失を隠すために、受信機の能力を軽減するのに役立つ可能性があります。元の送信機と受信機が重複通知が有効な送信者に「証明する」ことができ、したがって、元の送信からノンスを受信しているであろうスプリアス再送を受信する一般的なケースです。受信機は原稿を受け取っていないと、不適切に不適切に高いレートで送信中に送信者を誘導しようとしている場合には、受信機は、元のセグメントからECN nonceを知らないであろう、したがって、確率的送信者をだますことができません長い間。 [RFC3540]はノンス和がDSACK情報について横たわっ受信機の問題の緩和としての使用に直接適していないことを意味し、重複ACKにノンス和を無効にするための呼び出し。しかし、今後の取り組みは、それが必要とされなければならない保護を構築するための出発点として、[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とライナールートヴィヒはこのドキュメントの以前のバージョンにはいくつかの有用なコメントが寄せられています。第二著者のおかげBBN Technologies社と、この作業を支援するためのNASAのグレンリサーチセンター。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]フロイド、S.、Mahdavi、J.、マティス、M.およびM.ポドルスキー、 "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]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.およびV.パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[AAAB03] Allman, M., Avrachenkov, K., Ayesta, U. and J. Blanton, "Early Retransmit for TCP", Work in Progress, June 2003.
[AAAB03]オールマン、M.、Avrachenkov、K.、Ayesta、U.およびJ.ブラントン、 "TCPのための初期の再送信"、進歩、2003年6月での作業。
[AEO03] Allman, M., Eddy, E. and S. Ostermann, "Estimating Loss Rates With TCP", Work in Progress, August 2003.
[AEO03]オールマン、M.、エディ、E.およびS. Ostermann、 "TCPと推定損失率"、進歩、2003年8月の作業。
[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM 99.
「エンドツーエンドのネットワークパスのプロパティの推定について」[AP99]オールマン、M.およびV.パクソン、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]ブラントン、E.およびM.オールマン。パケットの並べ替えに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]ブラントン、E.、ダイモンド、R.とM.オールマン、「セグメント並べ替えの顔におけるTCP送信者のためのプラクティス」、進歩、2003年2月での作業。
[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]エディ、W.、Ostermann、S.とM.オールマン、「汚職ベースの損失へのトランスポートプロトコルは、堅牢な作りのための新技術」、進歩、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.ルートヴィヒ、R. H.カッツ。アイフェルアルゴリズム：スプリアス再送に対するTCPは、堅牢な作り。 ACMコンピュータコミュニケーションレビュー、30（1）、2000年1月。
[Pax97] V. Paxson. End-to-End Internet Packet Dynamics. In ACM SIGCOMM, September 1997.
【Pax97] V.パクソン。エンドツーエンドのインターネットパケットダイナミクス。 ACM SIGCOMM、1997年9月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのための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]ブラントン、E.、オールマン、M.、秋、K.とL.王、 "保守的な選択的確認応答（SACK）ベースの損失TCPのために回復アルゴリズム"、RFC 3517、2003年4月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP," RFC 3522, April 2003.
[RFC3522]ルートヴィヒ、R.及びM.マイヤー、 "TCPのためのアイフェル検出アルゴリズム"、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]春、N.、Wetherall、D.およびD.イーリー、 "ロバスト明示的輻輳通知（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.とM.古城、 "F-RTO：TCPとSCTPでスプリアス再送タイムアウトを検出するためのアルゴリズム"、進歩、2003年6月での作業。
Ethan Blanton Purdue University Computer Sciences 1398 Computer Science Building West Lafayette, IN 47907
イーサンブラントンパデュー大学47907でコンピュータ・サイエンス1398コンピュータサイエンスビルウェストラファイエット、
EMail: eblanton@cs.purdue.edu
メールアドレス：eblanton@cs.purdue.edu
Mark Allman ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704-1198 Phone: 216-243-7361
216-243-7361：スイート600バークレー、CA 94704から1198電話インターネットリサーチ1947センターストリート、のためのマーク・オールマンICSIセンター
EMail: mallman@icir.org http://www.icir.org/mallman/
メールアドレス：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。