RFC3708 日本語訳

Network Working Group                                         E. Blanton
Request for Comments: 3708                             Purdue University
Category: Experimental                                         M. Allman
                                                                    ICIR
                                                           February 2004

コメントを求めるワーキンググループE.ブラントン要求をネットワークでつないでください: 3708年のパデュー大学カテゴリ: 実験的なM.オールマンICIR2004年2月

      Using TCP Duplicate Selective Acknowledgement (DSACKs) and
         Stream Control Transmission Protocol (SCTP) Duplicate
        Transmission Sequence Numbers (TSNs) to Detect Spurious
                            Retransmissions

TCPの写しの選択している承認(DSACKs)を使用して、流れの制御伝動プロトコル(SCTP)は、偽物のRetransmissionsを検出するために、トランスミッション一連番号(TSNs)をコピーします。

Status of this Memo

この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.

Copyright(C)インターネット協会(2004)。 All rights reserved。

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とStream Control Transmissionプロトコル(SCTP)はそれぞれ写しセグメント領収書のDuplicate Selective Acknowledgement(DSACKs)とDuplicate Transmission Sequence Number(TSN)通知による通知を提供します。 このドキュメントは様々なアプリケーションのために不要な「再-トランスミッション」を特定するこの情報を使用する保守的な方法を提示します。

1.  Introduction

1. 序論

   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]とDuplicate TSNを通した写しセグメント領収書の通知に通知を提供します。 一般に、この情報、TCPまたはSCTP送付者を使用するのは、「再-トランスミッション」がいつ間違って送られたかを決定できます。 このドキュメントは写し通知を使用するための2つの方法を提示します。 最初の方法は、簡単であり、会計アプリケーションに使用できます。 2番目の方法は不要な輻輳制御変化を元に戻す目的のために損失出来事から不要な「再-トランスミッション」のあいまいさを除く保守的なアルゴリズムです。

Blanton & Allman              Experimental                      [Page 1]

RFC 3708           TCP DSACKs and SCTP Duplicate TSNs      February 2004

ブラントン、オールマン実験的な[1ページ]RFC3708TCP DSACKs、およびSCTPは2004年2月にTSNsをコピーします。

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?

2.  Counting Duplicate Notifications

2. 写し通知を数えます。

   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]セグメントを再送するのが働いているかどうか、またはセグメント再命令が引き起こす偽りであるかどうか決定するEarly Retransmit[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]です。

Blanton & Allman              Experimental                      [Page 2]

RFC 3708           TCP DSACKs and SCTP Duplicate TSNs      February 2004

ブラントン、オールマン実験的な[2ページ]RFC3708TCP DSACKs、およびSCTPは2004年2月にTSNsをコピーします。

3.  Congestion/Duplicate Disambiguation Algorithm

3. 混雑/写し曖昧さの解消アルゴリズム

   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+1は不必要に再送されました)、セグメントNとN+1が再送されると仮定してください。 送付者が受信するとき、セグメントN+1が一度それより到着したという通知は、セグメントN+1が不必要に再送されたと結論を下すことができます。 しかしながら、データの窓が少なくとも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).

写し通知がパケットのネットワーク複製で引き起こされて、a偽りであるか否かに関係なく、再送するように決定するのは、理論上ほとんど不可能なタスクです。 [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

(A.1) SACKスコアボードが空であり(すなわち、TCP送付者は受信機からSACK情報を全く受け取っていません)、入って来るDSACKの左の縁がSND.UNAと等しいなら、このDSACK MUSTの処理を、終えて、データの現在の窓の間、振り向けてはいけません輻輳制御が、述べる。 この節は覆うつもりです。

Blanton & Allman              Experimental                      [Page 3]

RFC 3708           TCP DSACKs and SCTP Duplicate TSNs      February 2004

ブラントン、オールマン実験的な[3ページ]RFC3708TCP DSACKs、およびSCTPは2004年2月にTSNsをコピーします。

             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.

承認の全体の窓がケースに入れたとき、ネットワークによって落とされて、ケースに入れます。 このような場合には、逆の経路は混雑している状態にあるように思えます、そして、したがって、TCPの送付レートを低下させるのは、保守的なアプローチです。

       (A.2) If the segment was retransmitted exactly one time, mark it
             as a duplicate.

(A.2) セグメントがあるときまさに再送されたなら、写しとしてそれをマークしてください。

       (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 MUSTでは、終えてください。そうすれば、データの現在の窓の間、輻輳制御状態を先に振り向けてはいけません。

       (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 MUSTでは、終えられて、処理してください。 さらに、接続の残りに本書では指定されたアルゴリズムを使用してはいけません、今後の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

[RFC3517](TCPのための)と[RFC2960](SCTPのための)で状態に言及し続けることに加えて、このアルゴリズムの実現は追跡されなければなりません。

Blanton & Allman              Experimental                      [Page 4]

RFC 3708           TCP DSACKs and SCTP Duplicate TSNs      February 2004

ブラントン、オールマン実験的な[4ページ]RFC3708TCP DSACKs、およびSCTPは2004年2月にTSNsをコピーします。

   all sequence numbers or TSNs that have been acknowledged as
   duplicates.

写しとして承認されたすべての一連番号かTSNs。

4.  Related Work

4. 関連仕事

   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]アウトラインと不必要な混雑から戻るのがタイムスタンプベースの計画を使用することで変化を制御するか、または弛むのに「噛み付かれた状態で、再送してください」を使用するメカニズムが再送される、(ACKs、再送、) アイフェル高原検出アルゴリズムが検出できる、偽り、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の送付パターンをわずかに変更して、次に、戻っているACKsのパターンを観測します。 このパターンは、再送されたセグメントが必要であったかどうかを示すことができます。 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)とこの時間デルタを比べます。 再送してください。時間デルタがそしてf*minRTTより少ないかどうか、偽りであるとラベルされます。 必要であることで、アルゴリズムが不必要な再送タイムアウトをおよそ59%特定して、特定するf=1/2が2.5%だけの割合で再送されるとき。 F-RTO、この計画だけ、検出、偽り、輸送の再送信タイマーで送って、再送します。

Blanton & Allman              Experimental                      [Page 5]

RFC 3708           TCP DSACKs and SCTP Duplicate TSNs      February 2004

ブラントン、オールマン実験的な[5ページ]RFC3708TCP DSACKs、およびSCTPは2004年2月にTSNsをコピーします。

5.  Security Considerations

5. セキュリティ問題

   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.

電子証券取引ネットワークの一回だけの合計提案[RFC3540]は、受信機が穏やかな拡大で本当の損失を送付者から隠す能力を緩和するのを助けるかもしれません。 オリジナルのトランスミッションでa偽りであることで受信するよくある例では、有効な状態で複製通知が送付者へのオリジナルのトランスミッションとしたがって、「立証缶の」からの一回だけですが、意志が受けた受信機を再送してください。 受信機がオリジナルを受け取らないで、不適切に不適当に高いレートで伝わるのに送付者を引き起こそうとしているときの場合では、受信機は、オリジナルのセグメントから電子証券取引ネットワーク一回だけを知らないで、したがって、長い間、probabilisticallyに送付者をだますことができないでしょう。 [RFC3540]は、写しACKsの上の一回だけの合計を無効にするためにころがっているのをDSACK情報と呼びます。ACKsは一回だけの合計が受信機の問題への緩和として直接使用に適していないことを意味します。 しかしながら、今後の努力は、それが必要であるなら保護を組み込むのに出発点として[RFC3540]を使用できるかもしれません。

6.  Acknowledgments

6. 承認

   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とライナー・ラドウィグはこのドキュメントの以前のバージョンのいくつかの役に立つコメントをしました。 第2代作者は、この仕事を支持して頂いて、BBN TechnologiesとNASAのグレンリサーチセンタに感謝します。

7. References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [RFC793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
             793, September 1981.

[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

Blanton & Allman              Experimental                      [Page 6]

RFC 3708           TCP DSACKs and SCTP Duplicate TSNs      February 2004

ブラントン、オールマン実験的な[6ページ]RFC3708TCP DSACKs、およびSCTPは2004年2月にTSNsをコピーします。

   [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のための選択している承認(袋)オプションへの拡大」、RFC2883、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.パクソンは「制御伝動プロトコルを流します」、RFC2960、2000年10月。

7.2.  Informative References

7.2. 有益な参照

   [AAAB03]  Allman, M., Avrachenkov, K., Ayesta, U. and J. Blanton,
             "Early Retransmit for TCP", Work in Progress, June 2003.

[AAAB03] 「TCPのために早く再送してください」というオールマン、M.、Avrachenkov、K.、Ayesta、U.、およびJ.ブラントンは進歩、2003年6月に働いています。

   [AEO03]   Allman, M., Eddy, E. and S. Ostermann, "Estimating Loss
             Rates With TCP", Work in Progress, August 2003.

[AEO03] 「TCPがある損失率を見積もってい」て、オールマン、M.、渦巻、E.、およびS.オステルマンは進歩、2003年8月に働いています。

   [AP99]    Allman, M. and V. Paxson, "On Estimating End-to-End Network
             Path Properties", SIGCOMM 99.

[AP99] オールマン、M.、および「終わりから端へのネットワーク経路が土地であると見積もっている」SIGCOMM99対パクソン

   [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をパケットReorderingにより強健にすることに関して。 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] 「セグメントReorderingに直面してTCP Sendersのための習慣」というブラントン、E.、ダイモンド、R.、およびM.オールマンは進行中(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.、オステルマン、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を偽物のRetransmissionsに対して強健にします。 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. and D.ボーマン、「高性能のためのTCP拡張子」、RFC1323)は1992がそうするかもしれません。

   [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.ワング、「TCPに、保守的な選択している承認(袋)ベースの損失回復アルゴリズム」、RFC3517、2003年4月。

   [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for
             TCP," RFC 3522, April 2003.

[RFC3522] ラドウィグとR.とM.マイヤー、「TCPのためのアイフェル高原検出アルゴリズム」、RFC3522、2003年4月。

Blanton & Allman              Experimental                      [Page 7]

RFC 3708           TCP DSACKs and SCTP Duplicate TSNs      February 2004

ブラントン、オールマン実験的な[7ページ]RFC3708TCP DSACKs、およびSCTPは2004年2月にTSNsをコピーします。

   [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.イーリー、「一回だけで合図する体力を要している明白な混雑通知(電子証券取引ネットワーク)」、RFC3540、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.Kojo、「F-RTO:」 「TCPとSCTPがある偽りの再送タイムアウトを検出するためのアルゴリズム」、処理中の作業、2003年6月。

8.  Authors' Addresses

8. 作者のアドレス

   Ethan Blanton
   Purdue University Computer Sciences
   1398 Computer Science Building
   West Lafayette, IN  47907

47907におけるイーサン・ブラントン・パデュー大学コンピューターサイエンシズ1398コンピュータサイエンスBuildingウェストラフィエット

   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

マークオールマンICSIは1947Center通り、Suite600バークレー、カリフォルニア94704-1198が電話をする研究をインターネットの中心に置きます: 216-243-7361

   EMail: mallman@icir.org
   http://www.icir.org/mallman/

メール: mallman@icir.org http://www.icir.org/mallman/

Blanton & Allman              Experimental                      [Page 8]

RFC 3708           TCP DSACKs and SCTP Duplicate TSNs      February 2004

ブラントン、オールマン実験的な[8ページ]RFC3708TCP DSACKs、およびSCTPは2004年2月にTSNsをコピーします。

9.  Full Copyright Statement

9. 完全な著作権宣言文

   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.

Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Blanton & Allman              Experimental                      [Page 9]

ブラントンとオールマンExperimentalです。[9ページ]