RFC4653 日本語訳

Network Working Group                                      S. Bhandarkar
Request for Comments: 4653                                A. L. N. Reddy
Category: Experimental                              Texas A&M University
                                                               M. Allman
                                                               ICIR/ICSI
                                                              E. Blanton
                                                       Purdue University
                                                             August 2006

Bhandarkarがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4653年のA.L.N.レディカテゴリ: 実験的なテキサスA&M大学のオールマンICIR/ICSI E.ブラントンパデュー大学M.2006年8月

        Improving the Robustness of TCP to Non-Congestion Events

非混雑出来事にTCPの丈夫さを改良します。

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 (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   This document specifies Non-Congestion Robustness (NCR) for TCP.  In
   the absence of explicit congestion notification from the network, TCP
   uses loss as an indication of congestion.  One of the ways TCP
   detects loss is using the arrival of three duplicate acknowledgments.
   However, this heuristic is not always correct, notably in the case
   when network paths reorder segments (for whatever reason), resulting
   in degraded performance.  TCP-NCR is designed to mitigate this
   degraded performance by increasing the number of duplicate
   acknowledgments required to trigger loss recovery, based on the
   current state of the connection, in an effort to better disambiguate
   true segment loss from segment reordering.  This document specifies
   the changes to TCP, as well as the costs and benefits of these
   modifications.

このドキュメントはNon-混雑Robustness(NCR)をTCPに指定します。 ネットワークからの明白な混雑通知がないとき、TCPは混雑のしるしとして損失を使用します。 TCPが損失を検出する方法の1つは3つの写し承認の到着を使用することです。 しかしながら、このヒューリスティックはいつも正しいというわけではなく、なって、ネットワーク経路追加注文セグメント(いかなる理由によるも)であることの場合では、著しく、性能は中から退行しました。 TCP-NCRは損失回復の引き金となるのに必要である写し承認の数を増加させるのによるこの降格している性能を緩和するように設計されています、接続の現状に基づいて、よりセグメント再命令からの本当のセグメントの損失のあいまいさを除くための努力で。 このドキュメントはこれらの変更のTCPへの変化、コスト、および恩恵を指定します。

Bhandarkar, et al.            Experimental                      [Page 1]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[1ページ]RFC4653

Table of Contents

目次

   1. Introduction ....................................................2
      1.1. Terminology ................................................4
   2. NCR Description .................................................5
   3. Algorithm .......................................................6
      3.1. Initialization .............................................8
      3.2. Terminating Extended Limited Transmit and
           Preventing Bursts ..........................................9
      3.3. Extended Limited Transmit .................................10
      3.4. Entering Loss Recovery ....................................11
   4. Advantages .....................................................12
   5. Disadvantages ..................................................12
   6. Related Work ...................................................13
   7. Security Considerations ........................................14
   8. Acknowledgments ................................................14
   9. IANA Considerations ............................................14
   10. References ....................................................14
      10.1. Normative References .....................................14
      10.2. Informative References ...................................15

1. 序論…2 1.1. 用語…4 2. NCR記述…5 3. アルゴリズム…6 3.1. 初期設定…8 3.2. 終わりは伝わって、炸裂を防ぐ株式会社を広げました…9 3.3. 制限されていた状態で広げられて、伝わってください…10 3.4. 損失回復に入ります…11 4. 利点…12 5. 損失…12 6. 仕事を関係づけます…13 7. セキュリティ問題…14 8. 承認…14 9. IANA問題…14 10. 参照…14 10.1. 標準の参照…14 10.2. 有益な参照…15

1.  Introduction

1. 序論

   One strength of TCP [RFC793] lies in its ability to adjust its
   sending rate according to the perceived congestion in the network
   [Jac88, RFC2581].  In the absence of explicit notification of
   congestion from the network, TCP uses segment loss as an indication
   of congestion (i.e., assuming queue overflow).  TCP receivers send
   cumulative acknowledgments (ACKs) indicating the next sequence number
   expected from the sender for arriving segments [RFC793].  When
   segments arrive out of order, duplicate ACKs are generated.  As
   specified in [RFC2581], a TCP sender uses the arrival of three
   duplicate ACKs as an indication of segment loss.  The TCP sender
   retransmits the lost segment and reduces the load imposed on the
   network, assuming the segment loss was caused by resource contention
   within the network path.  The TCP sender does not assume loss on the
   first or second duplicate ACK, but waits for three duplicate ACKs to
   account for minor packet reordering.  However, the use of this
   constant threshold of duplicate ACKs has several problems that can be
   mitigated with a dynamic threshold.

知覚された混雑に応じてネットワーク[Jac88、RFC2581]で送付レートを調整する性能にはTCP[RFC793]の1つの強さがあります。 ネットワークからの混雑の明白な通知がないとき、TCPは混雑(すなわち、待ち行列オーバーフローを仮定する)のしるしとしてセグメントの損失を使用します。 TCP受信機で、累積している承認(ACKs)は到着セグメント[RFC793]のために送付者から予想された次の一連番号を示します。 セグメントが故障していた状態で到着するとき、写しACKsは発生します。 [RFC2581]で指定されるように、TCP送付者はセグメントの損失のしるしとして3写しACKsの到着を使用します。 TCP送付者は、無くなっているセグメントを再送して、ネットワークに課された負荷を減少させます、セグメントの損失がネットワーク経路の中のリソース主張で引き起こされたと仮定して。 TCP送付者は、1番目か第2写しACKで損失を仮定しませんが、3写しACKsが小さい方のパケット再命令を説明するのを待ちます。 しかしながら、写しACKsのこの一定の敷居の使用には、ダイナミックな敷居で緩和できるいくつかの問題があります。

   The following is an example of TCP's behavior:

↓これはTCPの振舞いに関する例です:

     + TCP A is the data sender, and TCP B is the data receiver.

+ TCP Aはデータ送付者です、そして、TCP Bはデータ受信装置です。

     + TCP A sends 10 segments, each consisting of a single data byte
       (i.e., transmits bytes 1-10 in segments 1-10).

1データ・バイト(すなわち、セグメント1-10でバイト1-10を伝える)からそれぞれ成って、+ TCP Aは10のセグメントを送ります。

Bhandarkar, et al.            Experimental                      [Page 2]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[2ページ]RFC4653

     + Assume segment 3 is dropped in the network.

+は、セグメント3がネットワークで落とされると仮定します。

     + TCP B cumulatively acknowledges segments 1 and 2, making the
       cumulative ACK transmitted to the sender 3 (the next expected
       sequence number).  (Note: TCP B may generate one or two ACKs,
       depending on whether delayed ACKs [RFC1122, RFC2581] are
       employed.)

+ TCP Bは累積的にセグメント1と2を承認します、送付者3(次の予想された一連番号)に伝えられた累積しているACKを作って。 (注意: 遅れたACKs[RFC1122、RFC2581]が採用しているかどうかによって、TCP Bは1か2ACKsを発生させるかもしれません。)

     + The arrival of segments 4-10 at TCP B will each trigger the
       transmission of a cumulative ACK for sequence number 3.  (Note:
       [RFC2581] recommends that delayed ACKs not be used when the ACK
       is triggered by an out-of-order segment.)

+ セグメント4-10の到着はTCP Bでそれぞれ一連番号3のための累積しているACKのトランスミッションの引き金となるでしょう。 (注意: [RFC2581]は、ACKが不適切なセグメントによって引き起こされるとき、遅れたACKsが使用されないことを勧めます。)

     + When TCP A receives the third duplicate ACK (or fourth ACK
       overall) for sequence number 3, TCP A will retransmit
       segment 3 and reduce the sending rate by roughly half (see
       [RFC2581] for specifics on the congestion control state
       adjustments).

TCP Aが一連番号3のために、第3写しACK(または、全体的に見て第4ACK)を受ける+、TCP Aはおよそ半分セグメント3を再送して、送付レートを低下させるでしょう(詳細に関して輻輳制御州の調整に[RFC2581]を見てください)。

   Alternatively, suppose segment 3 was not dropped by the network, but
   rather delayed such that segment 3 arrives at TCP B after segment 10.
   The above scenario will play out in precisely the same manner
   insomuch as a retransmission of segment 3 will be triggered.  In
   other words, TCP is not capable of disambiguating this reordering
   event from a segment loss, resulting in an unnecessary retransmission
   and rate reduction.

あるいはまた、セグメント3が10次々とTCP Bに到着するように、セグメント3がネットワークによって落とされませんが、むしろ遅れたと仮定してください。 セグメント3の「再-トランスミッション」が引き起こされるとき、上のシナリオは正確に同じ方法で程度まで展開するでしょう。 言い換えれば、TCPはセグメントの損失からこの再命令出来事のあいまいさを除くことができません、不要な「再-トランスミッション」とレート減少をもたらして。

   The following is the specific motivation behind making TCP robust to
   reordered segments:

↓これはTCPを再命令されたセグメントに強健にする後ろの特定の動機です:

     * A number of Internet measurement studies have shown that packet
       reordering is not a rare phenomenon [Pax97, BPS99, JIDKT03,
       GPL04].  Further, the reordering can be well beyond that required
       for fast retransmit to be falsely triggered.

* 多くのインターネット測定研究が、パケット再命令がまれな現象[Pax97、BPS99、JIDKT03、GPL04]でないことを示しました。 さらに、断食に必要であることで、間違って引き起こされるために再送される再命令がよく向こうにあることができます。

     * [BA02, ZKFP03] show the negative performance implications that
       packet reordering has on current TCP.

* [BA02、ZKFP03]はパケット再命令が現在のTCPに持っている否定的性能意味を示しています。

     * The requirement imposed by TCP for almost in-order packet
       delivery places a constraint on the design of future technology.
       Novel routing algorithms, network components, link-layer
       retransmission mechanisms, and applications could all be looked
       at with a fresh perspective if TCP were to be more robust to
       segment reordering.  For instance, high-speed packet switches
       could cause resequencing of packets if TCP were more robust.
       There has been work proposed in the literature explicitly to
       ensure that packet ordering is maintained in such switches (e.g.,
       [KM02]).  Also, link-layer mechanisms that attempt to recover

* ほとんどオーダーにおけるパケット配信のためにTCPによって課された要件は未来の技術のデザインに規制を置きます。 TCPがセグメント再命令により強健であるなら、新鮮な見解で目新しいルーティング・アルゴリズム、ネットワーク要素、リンクレイヤ「再-トランスミッション」メカニズム、およびアプリケーションをすべて見ることができるでしょう。 例えば、TCPが、より強健であるなら、高速パケット交換機はパケットの再配列を引き起こす場合があるでしょうに。 パケット注文がそのようなスイッチ(例えば、[KM02])で維持されるのを保証するために、文学で明らかに提案された仕事がありました。 回復するのを試みるリンクレイヤメカニズムも

Bhandarkar, et al.            Experimental                      [Page 3]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[3ページ]RFC4653

       from packet corruption by retransmitting could be allowed to
       reorder packets, and thus increase the chances of local loss
       repair rather than rely on TCP to repair the loss (and,
       needlessly reduce its sending rate).  Additional examples include
       multi-path routing, high-delay satellite links, and some of the
       schemes proposed for a differentiated services architecture.  By
       making TCP more robust to non-congestion events, TCP-NCR may open
       the design space of the future Internet components.

再送するのによるパケット不正から、損失を修理するためにTCPを当てにするよりむしろ追加注文パケットに許容されていて、その結果、局所的消失修理の可能性を高めるかもしれません(送付レートを不必要に低下させてください)。 追加例は微分されたサービス構造のために提案された計画のマルチ経路ルーティング、高遅れ衛星中継、およびいくつかを含んでいます。 TCPを非混雑出来事により強健にすることによって、TCP-NCRは将来のインターネットコンポーネントのデザインスペースを開くかもしれません。

   In this document, we specify a set of TCP sender modifications to
   provide Non-Congestion Robustness (NCR) to TCP.  In particular, these
   changes are built on top of TCP with selective acknowledgments
   (SACKs) [RFC2018] and the SACK-based loss recovery scheme given in
   [RFC3517], since SACK is widely deployed at this point ([MAF05]
   indicates that 68% of web servers and 88% of web clients utilize SACK
   as of spring 2004).

本書では、私たちは、Non-混雑Robustness(NCR)をTCPに供給するために1セットのTCP送付者変更を指定します。 特に、これらの変化は[RFC3517]で選択している承認(SACKs)[RFC2018]とSACKベースの損失回復計画を与えているTCPの上に建てられます、SACKがここに広く配備されるので([MAF05]は、68%のウェブサーバーと88%のウェブクライアントが2004年春現在SACKを利用するのを示します)。

   Note that the TCP-NCR algorithm provided in this document could be
   easily adapted to SCTP [RFC2960] since SCTP uses congestion control
   algorithms similar to TCP's (and thus has the same reordering
   robustness issues).

SCTPがTCPのもの(そして、その結果、丈夫さ問題を再命令しながら、同じくらい持っている)と同様の輻輳制御アルゴリズムを使用するので容易に本書では提供されたTCP-NCRアルゴリズムはSCTP[RFC2960]に適合させることができたことに注意してください。

   As noted in several places in the remainder of this document, we
   consider TCP-NCR experimental in that more experience with the
   techniques is required before TCP-NCR should be used on a large scale
   on the Internet.  We encourage implementation and experimentation
   with TCP-NCR in the hopes of gaining an understanding of its
   suitability for wide-scale deployment.

方々にこのドキュメントの残りで注意されるように、TCP-NCRが大規模にインターネットで使用されるべき前にテクニックの、より多くの経験が必要であるので、私たちは、TCP-NCRが実験的であると考えます。 私たちはTCP-NCRと共に適合の理解を獲得するという広いスケール展開の望みで実現と実験を奨励します。

   The remainder of this document is organized as follows.  Section 2
   provides a high-level description of the TCP-NCR mechanisms.  In
   Section 3, we specify the TCP-NCR algorithm.  Section 4 provides a
   brief overview of the benefits of TCP-NCR, while Section 5 discusses
   the drawbacks.  Section 6 discusses related work.  Section 7
   discusses security concerns.

このドキュメントの残りは以下の通り組織化されます。 セクション2はTCP-NCRメカニズムのハイレベルの記述を提供します。セクション3では、私たちはTCP-NCRアルゴリズムを指定します。 セクション4はTCP-NCRの利益の簡潔な概観を提供しますが、セクション5は欠点について議論します。 セクション6は関連する仕事について論じます。 セクション7は安全上の配慮について論じます。

1.1.  Terminology

1.1. 用語

   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 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

   Readers should be familiar with the TCP terminology (e.g.,
   FlightSize, Pipe) given in [RFC2581] and [RFC3517].

読者は[RFC2581]と[RFC3517]で与えるTCP用語(例えば、FlightSize、Pipe)に詳しいはずです。

Bhandarkar, et al.            Experimental                      [Page 4]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[4ページ]RFC4653

2.  NCR Description

2. NCR記述

   As discussed above, in the face of packet reordering, three duplicate
   ACKs may not be enough to disambiguate loss from reordering.  In this
   section we provide a non-normative sketch of TCP-NCR.  The detailed
   algorithms for implementing Non-Congestion Robustness for TCP are
   presented in the next section.

パケット再命令に直面して上で議論するように、3写しACKsは再命令からの損失のあいまいさを除くために十分でないかもしれません。 このセクションに、私たちはTCP-NCRの非標準のスケッチを供給します。 TCPのためにNon-混雑Robustnessを実行するための詳細なアルゴリズムは次のセクションに提示されます。

   The general idea behind TCP-NCR is to increase the threshold used to
   trigger a fast retransmission from the current fixed value of three
   duplicate ACKs [RFC2581] to approximately a congestion window of data
   having left the network (but not less than the currently standardized
   value of three duplicate ACKs).  Since cwnd represents the amount of
   data a TCP flow can transmit in one round-trip time (RTT), waiting to
   receive notice that cwnd bytes have left the network before deciding
   whether the root cause is loss or reordering imposes a delay of
   roughly one RTT on both the retransmission and the congestion control
   response.  The appropriate choice for a new value of the threshold is
   essentially a trade-off between making the best decision regarding
   the cause of the duplicate ACKs and responsiveness.  The choice to
   trigger a retransmission only after a cwnd's worth of data is known
   to have left the network represents roughly the largest amount of
   time a TCP can wait before the (often costly) retransmission timeout
   may be triggered.  Therefore, the algorithm described in this
   document attempts to make the best decision possible at the expense
   of timeliness.

TCP-NCRの後ろの概念は3写しACKs[RFC2581]の現在の一定の価値から左にネットワークを持っているデータ(しかし、少なくとも3写しACKsの現在標準化された値)の混雑およそウィンドウまで速い「再-トランスミッション」の引き金となるのに使用される敷居を増加させることです。 cwndがデータ量を表すので、TCP流動は往復の1回(RTT)で伝わることができます、根本的原因が損失かそれとも再命令であるかを決めるのがおよそ1RTTの遅れを「再-トランスミッション」と混雑操舵応答の両方に課す前にcwndバイトがネットワークを出た通知を受け取るのを待っていて。 敷居の新しい値のための適当な選択は本質的には写しの原因に関する最も良い決定をACKsと反応性にすることの間のトレードオフです。 cwndのデータの価値がネットワークを出たのが知られた後にだけ「再-トランスミッション」の引き金となる選択はおよそ(しばしば高価)の再送タイムアウトが引き起こされるかもしれない前にTCPが待つことができる最も大きい時間を表します。 したがって、本書では説明されたアルゴリズムは、最も良い決定をタイムリーを犠牲にして可能にするのを試みます。

   Simply increasing the threshold before retransmitting a segment can
   make TCP brittle to packet loss or ACK loss since such loss reduces
   the number of duplicate ACKs that will arrive at the sender from the
   receiver.  For instance, if the cwnd is 10 segments and one segment
   is lost, a duplicate ACK threshold of 10 will never be met because
   duplicate ACKs corresponding to at most 9 segments will arrive at the
   sender.  To offset the issue of loss, we extend TCP's Limited
   Transmit [RFC3042] scheme to allow for the sending of new data during
   the period when the TCP sender is disambiguating loss and reordering.
   This new data serves to increase the likelihood that enough duplicate
   ACKs arrive at the sender to trigger loss recovery if it is
   appropriate.

そのような損失が受信機から送付者に到着する写しACKsの数を減少させるので、セグメントを再送する前に敷居を単に増加させるのにTCPはパケット損失かACKの損失にもろくなる場合があります。例えば、cwndが10のセグメントであり、1つのセグメントが無くなると、高々9つのセグメントしか対応しない写しACKsが送付者に到着するので、10の写しACK敷居は決して満たされないでしょう。 損失の問題を相殺するなら、私たちは、TCP送付者が損失のあいまいさを除いて、再命令する期間、新しいデータの発信を考慮するためにTCPの株式会社Transmit[RFC3042]計画を広げます。 この新しいデータは、それが適切であるなら十分な写しACKsが損失回復の引き金となるように送付者に到着する可能性を広げるのに役立ちます。

   Note that TCP tightly couples reliability and congestion control:
   when a segment is declared lost, a retransmission is triggered, and a
   change to the sending rate is also made on the assumption that the
   drop is due to resource contention [RFC2581].  Therefore, simply by
   changing the retransmission trigger, the congestion control response
   is also changed.  However, we lack experience on the Internet as to
   whether delaying the point that a rate reduction takes place is

TCPがしっかり信頼性と輻輳制御を結合することに注意してください: セグメントが無くなると宣言されるとき、「再-トランスミッション」は引き起こされます、そして、また、送付レートへの変更は低下がリソース主張[RFC2581]のためであるという前提で行われます。 したがって、また、単に「再-トランスミッション」引き金を変えることによって、混雑操舵応答を変えます。 しかしながら、レート減少が起こるというポイントを遅らせるのが、そうかどうかに関して、私たちはインターネットで経験を欠いています。

Bhandarkar, et al.            Experimental                      [Page 5]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[5ページ]RFC4653

   appropriate for wide-scale deployment.  Therefore, the Extended
   Limited Transmit mechanism proposed in this document offers two
   variants for experimentation.

広いスケール展開において、適切です。 したがって、本書では提案されたExtended株式会社Transmitメカニズムは実験のために2つの異形を提供します。

   The first Extended Limited Transmit variant, Careful Limited
   Transmit, calls for the transmission of one previously unsent
   segment, in response to duplicate acknowledgments, for every two
   segments that are known to have left the network.  This effectively
   halves the sending rate, since normal TCP operation calls for the
   sending of one segment for every segment that has left the network.
   Further, the halving starts immediately and is not delayed until a
   retransmission is triggered.  In the case of packet reordering (i.e.,
   not segment loss), the congestion control state is restored to its
   previous state when reordering is determined.

最初のExtended株式会社Transmit異形、Careful株式会社Transmit、1のトランスミッションのための以前に写し承認に対応した知られている2つのセグメント毎のためにunsentセグメントがネットワークを出たという要求。 事実上、これは送付レートを半分にします、通常のTCP操作がネットワークを出た各セグメントあたり1つのセグメントの発信を求めるので。 さらに、「再-トランスミッション」が引き起こされるまで、半分には、すぐに、始まって、遅れません。 パケット再命令(すなわち、セグメントの損失でない)の場合では、再命令が決定しているとき、輻輳制御状態は先に回復します。

   The second variant, Aggressive Limited Transmit, calls for
   transmitting one previously unsent data segment, in response to
   duplicate acknowledgments, for every segment known to have left the
   network.  With this variant, while waiting to disambiguate the loss
   from a reordering event, ACK-clocked transmission continues at
   roughly the same rate as before the event started.  Retransmission
   and the sending rate reduction happen per [RFC2581, RFC3517], albeit
   with the delayed threshold described above.  Although this approach
   delays legitimate rate reductions (possibly slightly and temporarily
   aggravating overall congestion on the network), the scheme has the
   advantage of not reducing the transmission rate in the face of
   segment reordering.

2番目の異形、Aggressive株式会社Transmitは、以前に1を伝えるためにunsentをデータ・セグメントと呼びます、写し承認に対応して、ネットワークを出たのが知られているあらゆるセグメントのために。 この異形で、再命令出来事からの損失のあいまいさを除くのを待っている間、ACKによって時間を計られたトランスミッションは従来と同様出来事が始めたおよそ同じレートで続きます。 上で遅れた敷居で説明されますが、Retransmissionと送付レート減少は[RFC2581、RFC3517]単位で起こります。 このアプローチは正統のレート減少(ことによるとわずかに一時、ネットワークで総合的な混雑をいらいらさせる)を遅らせますが、計画には、セグメント再命令に直面して通信速度を減少させない利点があります。

   Which of the two Extended Limited Transmit variants is best for use
   on the Internet is an open question.

インターネットにおける使用に、2つのExtended株式会社Transmit異形のどれが最も良いかは、未決問題です。

3.  Algorithm

3. アルゴリズム

   The TCP-NCR modifications make two fundamental changes to the way
   [RFC3517] currently operates, as follows.

TCP-NCR変更は[RFC3517]が現在以下の通り作動する方法への2回の根本的変化を作ります。

   First, the trigger for retransmitting a segment is changed from three
   duplicate ACKs [RFC2581, RFC3517] to indications that a congestion
   window's worth of data has left the network.  Second, TCP-NCR
   decouples initial congestion control decisions from retransmission
   decisions, in some cases delaying congestion control changes relative
   to TCP's current behavior as defined in [RFC2581].  The algorithm
   provides two alternatives for extending Limited Transmit.  The two
   variants of extended Limited Transmit are:

まず最初に、セグメントを再送するための引き金は3写しACKs[RFC2581、RFC3517]から混雑ウィンドウのデータの価値がネットワークを出たという指摘に変わります。 2番目に、TCP-NCRは「再-トランスミッション」決定から初期の輻輳制御決定の衝撃を吸収します、いくつかの場合、[RFC2581]で定義されるようにTCPの現在の振舞いに比例して輻輳制御変化を遅らせて。 アルゴリズムは株式会社Transmitを広げるための2つの選択肢を提供します。 拡張株式会社Transmitの2つの異形は以下の通りです。

Bhandarkar, et al.            Experimental                      [Page 6]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[6ページ]RFC4653

       Careful Limited Transmit

慎重な株式会社は伝わります。

        This variant calls for reducing the sending rate at
        approximately the same time [RFC2581] implementations reduce
        the congestion window, while at the same time withholding a
        retransmission (and the final congestion determination) for
        approximately one RTT.

この異形は、同時におよそ1RTTのために、「再-トランスミッション」(そして、最終的な混雑決断)を差し控える間、実現が混雑ウィンドウを減少させるほとんど同時代[RFC2581]に送付レートを低下させるように求めます。

       Aggressive Limited Transmit

攻撃的な株式会社は伝わります。

        This variant calls for maintaining the sending rate in the
        face of duplicate ACKs until TCP concludes that a segment is
        lost and needs to be retransmitted (which TCP-NCR delays by
        one RTT when compared with current loss recovery schemes).

この異形は、TCPが、セグメントが無くなると結論を下して、再送される必要があるまで(当期損失回復計画と比べるとTCP-NCRが1RTTで遅らせる)写しACKsに直面して送付レートを維持するように求めます。

   A TCP-NCR implementation MUST use either Careful Limited Transmit or
   Aggressive Limited Transmit.

TCP-NCR実現はCareful株式会社TransmitかAggressive株式会社Transmitのどちらかを使用しなければなりません。

   A constant MUST be set, depending on which variant of extended
   Limited Transmit is used, as follows:

拡張株式会社Transmitのどの異形が以下の通り使用されるかによって、定数を設定しなければなりません:

       Careful Limited Transmit

慎重な株式会社は伝わります。

        LT_F = 2/3

LT_Fは2/3と等しいです。

       Aggressive Limited Transmit

攻撃的な株式会社は伝わります。

        LT_F = 1/2

LT_Fは1/2と等しいです。

   This constant reflects the fraction of outstanding data (including
   data sent during Extended Limited Transmit) that must be SACKed
   before a retransmission is triggered.  Since Aggressive Limited
   Transmit sends a new segment for every segment known to have left the
   network, a total of roughly cwnd segments will be sent during
   Aggressive Limited Transmit, and therefore ideally a total of roughly
   2*cwnd segments will be outstanding when a retransmission is
   triggered.  The duplicate ACK threshold is then set to LT_F = 1/2 of
   2*cwnd (or about 1 RTT worth of data).  The factor is different for
   Careful Limited Transmit because the sender only transmits one new
   segment for every two segments that are SACKed and therefore will
   ideally have a total of 1.5*cwnd segments outstanding when the
   retransmission is to be triggered.  Hence, the required threshold is
   LT_F=2/3 of 1.5*cwnd to delay the retransmission by roughly 1 RTT.

この定数は「再-トランスミッション」が引き起こされる前にSACKedであるに違いない傑出しているデータ(Extended株式会社Transmitの間に送られたデータを含んでいる)の部分を反映します。 Aggressive株式会社Transmitがネットワークを出たのが知られているあらゆるセグメントのために新しいセグメントを送るので、Aggressive株式会社Transmitの間、およそcwndセグメントの合計を送るでしょう、そして、したがって、理想的に、「再-トランスミッション」が引き起こされるとき、合計およそ2つの*cwndセグメントが傑出するでしょう。 そして、写しACK敷居は1/2 2*cwnd(または、データにおいて価値があるおよそ1RTT)へのLT_F=セットです。 要素は、送付者がSACKedである2つのセグメントあたり1つの新しいセグメントしか伝えないのでCareful株式会社Transmitにおいて異なって、したがって、「再-トランスミッション」が引き起こされることになっているとき、理想的に未払いの合計1.5の*cwndセグメントを持つでしょう。 したがって、必要な敷居はおよそ1RTTで「再-トランスミッション」を遅らせる2/3 1.5*cwndですLT_F=。

   There are situations whereby the sender cannot transmit new data
   during Extended Limited Transmit (e.g., lack of data from the
   application, receiver's advertised window limit).  These situations
   can lead to the problems discussed in the last section when a TCP

送付者がExtended株式会社Transmit(例えば、アプリケーションからの資料不足、受信機の広告を出している窓の限界)の間に新しいデータを送ることができない状況があります。 これらの状況はTCPであるときに最後のセクションで議論した問題を引き起こすことができます。

Bhandarkar, et al.            Experimental                      [Page 7]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[7ページ]RFC4653

   does not employ Extended Limited Transmit and is starved for ACKs.
   Therefore, TCP-NCR adapts the duplicate ACK threshold on each SACK
   arrival to be as robust as possible given the actual amount of data
   that has been transmitted, or roughly LT_F times the number of
   outstanding segments.

Extended株式会社Transmitを使わないで、ACKsに飢えています。 したがって、伝えられた実際のデータ量を考えて、TCP-NCRができるだけ強健になるようにそれぞれのSACK到着の写しACK敷居を適合させるか、またはおよそLT_F回は傑出しているセグメントの数を適合させます。

   The TCP-NCR modifications specified in this document lend themselves
   to incremental deployment.  Only the TCP implementation on the sender
   side requires modification (assuming both hosts support SACK).  The
   changes themselves are modest.  However, as will be discussed below,
   availability of additional buffer space at the receiver will help
   maximize the benefits of using TCP-NCR but is not strictly necessary.

本書では指定されたTCP-NCR変更は増加の展開に自分たちを与えます。 送付者側におけるTCP実現だけが変更を必要とします(両方のホストがサポートSACKであると仮定して)。 変化自体は穏やかです。 しかしながら、以下で議論するように、受信機の追加バッファ領域の有用性は、TCP-NCRを使用する利益を最大にするのを助けますが、厳密に必要ではありません。

   The following algorithms depend on the notions provided by [RFC3517],
   and we assume the reader is familiar with the terminology given in
   [RFC3517].  The TCP-NCR algorithm can be adapted to alternate SACK-
   based loss recovery schemes.  [BR04, BSRV04] outline non-SACK-based
   algorithms; however, we do not specify those algorithms in this
   document and do not recommend them due to both the complexity and
   security implications of having only a gross understanding of the
   number of outstanding segments in the network.

以下のアルゴリズムは[RFC3517]によって提供された概念を当てにされます、そして、私たちは読者が[RFC3517]で与える用語に詳しいと思います。 SACKのベースの損失回復計画を交替するためにTCP-NCRアルゴリズムを適合させることができます。 [BR04、BSRV04]は非SACKベースのアルゴリズムを概説します。 しかしながら、私たちは、本書ではそれらのアルゴリズムを指定しないで、また複雑さとネットワークにおける、傑出しているセグメントの数の総計の理解しか持たないセキュリティ含意の両方のためそれらを推薦しません。

   A TCP connection using the Nagle algorithm [RFC896, RFC1122] MAY
   employ the TCP-NCR algorithm.  If a TCP implementation does implement
   TCP-NCR, the implementation MUST follow the various specifications
   provided in Sections 3.1 - 3.4.  If the Nagle algorithm is not being
   used, there is no way to accurately calculate the number of
   outstanding segments in the network (and, therefore, no good way to
   derive an appropriate duplicate ACK threshold) without adding state
   to the TCP sender.  A TCP connection that does not employ the Nagle
   algorithm SHOULD NOT use TCP-NCR.  We envision that NCR could be
   adapted to an implementation that carefully tracks the sequence
   numbers transmitted in each segment.  However, we leave this as
   future work.

ネーグルアルゴリズム[RFC896、RFC1122]を使用しているTCP接続はTCP-NCRアルゴリズムを使うかもしれません。 TCP実現がTCP-NCRを実行するなら、実現は3.1--3.4にセクションに提供された様々な仕様に従わなければなりません。 ネーグルアルゴリズムが使用されていないなら、付加状態なしでネットワーク(したがって、適切な写しACK敷居を引き出す早道がない)における、傑出しているセグメントの数についてTCP送付者に正確に計算する方法が全くありません。 ネーグルアルゴリズムSHOULD NOTを使わないTCP接続はTCP-NCRを使用します。 私たちはそれを思い描きます。各セグメントで伝えられて、慎重に一連番号を追跡する実現にNCRは適合させることができました。 しかしながら、私たちは今後の活動としてこれを残します。

3.1.  Initialization

3.1. 初期設定

   When entering a period of loss/reordering detection and Extended
   Limited Transmit, a TCP-NCR MUST initialize several state variables.
   A TCP MUST enter Extended Limited Transmit upon receiving the first
   ACK with a SACK block after the reception of an ACK that (a) did not
   contain SACK information and (b) did increase the connection's
   cumulative ACK point.  The initializations are:

検出とExtended株式会社Transmit、TCP-NCR MUSTが初期化する損失/再命令の期間に入るとき、数個が変数を述べます。 (a)がしたACKのレセプションがSACK情報を含んでいなくて、(b)が接続の累積しているACKポイントを増加させた後にSACKブロックがある最初のACKを受けるとき、TCP MUSTはExtended株式会社Transmitに入ります。 初期化処理は以下の通りです。

   (I.1) The TCP MUST save the current FlightSize.

(I.1) TCP MUSTは現在のFlightSizeを取っておきます。

         FlightSizePrev = FlightSize

FlightSizePrevはFlightSizeと等しいです。

Bhandarkar, et al.            Experimental                      [Page 8]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[8ページ]RFC4653

   (I.2) The TCP MUST set a variable for tracking the number of
         segments for which an ACK does not trigger a transmission
         during Careful Limited Transmit.

(I.2) TCP MUSTはACKがCareful株式会社Transmitの間にトランスミッションの引き金とならないセグメントの数を追跡するのに変数を設定します。

         Skipped = 0

スキップされた=0

         (Note: Skipped is not used during Aggressive Limited
         Transmit.)

スキップされて、以下に注意してください。(Aggressive株式会社Transmitの間、使用されない、)

   (I.3) The TCP MUST set DupThresh (from [RFC3517]) based on the
         current FlightSize.

(I.3) TCP MUSTは現在のFlightSizeに基づくDupThresh([RFC3517]からの)を設定します。

         DupThresh = max (LT_F * (FlightSize / SMSS),3)

DupThresh=最大(LT_F*(FlightSize / SMSS)、3)

         Note: We keep the lower bound of DupThresh = 3 from
         [RFC2581, RFC3517].

以下に注意してください。 私たちは[RFC2581、RFC3517]からDupThresh=3の下界を保ちます。

   In addition to the above steps, the incoming ACK MUST be processed
   with the E series of steps in Section 3.3.

上記は踏まれます、入って来るACK MUST。に加えてステップのEシリーズがセクション3.3にある状態で、処理されます。

3.2.  Terminating Extended Limited Transmit and Preventing Bursts

3.2. 終わりは伝わって、炸裂を防ぐ株式会社を広げました。

   Extended Limited Transmit MUST be terminated at the start of loss
   recovery as outlined in Section 3.4.

セクション3.4での概説されるとしての損失回復の始めで拡張株式会社Transmitを終えなければなりません。

   The arrival of an ACK that advances the cumulative ACK point while in
   Extended Limited Transmit, but before loss recovery is triggered,
   signals that a series of duplicate ACKs was caused by reordering and
   not congestion.  Therefore, the receipt of an ACK that extends the
   cumulative ACK point MUST terminate Extended Limited Transmit.  As
   described below (in (T.4)), an ACK that extends the cumulative ACK
   point and *also* contains SACK information will also trigger the
   beginning of a new Extended Limited Transmit phase.

混雑ではなく、損失回復がExtended株式会社Transmitにもかかわらず、以前引き起こされる間の累積しているACK時点を進めるACK、一連の写しACKsが再命令することによって引き起こされたという信号の到着。 したがって、累積しているACKポイントを広げるACKの領収書はExtended株式会社Transmitを終えなければなりません。 また、説明されて、*が(コネ(T.4))、累積しているACKポイントと*も広げるACKの下にSACKを含むとき、情報は新しいExtended株式会社Transmitフェーズの始まりの引き金となるでしょう。

   Upon the termination of Extended Limited Transmit, and especially
   when using the Careful variant, TCP-NCR may be in a situation where
   the entire cwnd is not being utilized, and therefore TCP-NCR will be
   prone to transmitting a burst of segments into the network.
   Therefore, to mitigate this bursting when a TCP-NCR in the Extended
   Limited Transmit phase receives an ACK that updates the cumulative
   ACK point (regardless of whether the ACK contains SACK information),
   the following steps MUST be taken:

Careful異形を使用するとき、Extended株式会社Transmitの終了と、特に、TCP-NCRが全体のcwndが利用されていなくて、したがって、TCP-NCRがセグメントの炸裂をネットワークに伝えることの傾向があるようになるところに状況にあるかもしれません。 したがって、Extended株式会社TransmitフェーズにおけるTCP-NCRが累積しているACKポイント(ACKがSACK情報を含んでいるかどうかにかかわらず)をアップデートするACKを受けるとき、このはち切れることを緩和するために、以下の方法を取らなければなりません:

Bhandarkar, et al.            Experimental                      [Page 9]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[9ページ]RFC4653

   (T.1) A TCP MUST reset cwnd to:

(T.1) TCP MUSTは以下のことのためにcwndをリセットしました。

         cwnd = min (FlightSize + SMSS,FlightSizePrev)

cwnd=分(FlightSize+SMSS、FlightSizePrev)

         This step ensures that cwnd is not grossly larger than the
         amount of data outstanding, a situation that would cause a
         line rate burst.

このステップはcwndが確実に未払いのデータ量よりはなはだしく大きくなくなるようにします、ライン料率炸裂を引き起こす状況。

   (T.2) A TCP MUST set ssthresh to:

(T.2) TCP MUSTは、ssthreshに以下のことように設定しました。

         ssthresh = FlightSizePrev

ssthreshはFlightSizePrevと等しいです。

         This step provides TCP-NCR with a sense of "history".  If step
         (T.1) reduces cwnd below FlightSizePrev, this step ensures that
         TCP-NCR will slow start back to the operating point in effect
         before Extended Limited Transmit.

このステップは「歴史」の感覚をTCP-NCRに提供します。 ステップ(T.1)がFlightSizePrevの下のcwndを減少させるなら、このステップは、事実上、TCP-NCRがExtended株式会社Transmitの前で操作ポイントに始めを遅くして戻すのを確実にします。

   (T.3) A TCP is now permitted to transmit previously unsent data as
         allowed by cwnd, FlightSize, application data availability, and
         the receiver's advertised window.

(T.3) 現在、cwnd、FlightSize、アプリケーションデータの有効性、および受信機の広告を出している窓によって許容されているようにTCPが以前にunsentなデータを送ることが許可されます。

   (T.4) When an incoming ACK extends the cumulative ACK point and also
         contains SACK information, the initializations in steps (I.2)
         and (I.3) from Section 3.1 MUST be taken (but step (I.1) MUST
         NOT be executed) to re-start Extended Limited Transmit.  In
         addition, the series of steps in Section 3.3 (the "E" steps)
         MUST be taken.

(T.4) 入って来るACKが累積しているACKポイントを広げていて、また、SACK情報を含んでいると、Extended株式会社Transmitを再開するためにセクション3.1からのステップ(I.2)と(I.3)における初期化処理を取らなければなりません(ステップ(I.1)を実行してはいけません)。 さらに、セクション3.3(「E」ステップ)のステップのシリーズを取らなければなりません。

3.3.  Extended Limited Transmit

3.3. 制限されていた状態で広げられて、伝わってください。

   On each ACK containing SACK information that arrives after TCP-NCR
   has entered the Extended Limited Transmit phase (as outlined in
   Section 3.1) and before Extended Limited Transmit terminates, the
   sender MUST use the following procedure.

TCP-NCRがExtended株式会社Transmitフェーズに入った(セクション3.1に概説されているように)後とExtended株式会社Transmitが終わる前に到着するSACK情報を含む各ACKでは、送付者は以下の手順を用いなければなりません。

   (E.1) The SetPipe () procedure from [RFC3517] MUST be used to set
         the "pipe" variable (which represents the number of bytes
         still considered "in the network").  Note: the current value
         of DupThresh MUST be used by SetPipe () to produce an accurate
         assessment of the amount of data still considered in the
         network.

(E.1) 「パイプ」変数(「ネットワーク」であるとまだ考えられていたバイト数を表す)を設定するのに[RFC3517]からのSetPipe()手順を用いなければなりません。 以下に注意してください。 SetPipe()は、ネットワークでまだ考えられていたデータ量の正確な査定を起こすのにDupThreshの現行価値を使用しなければなりません。

   (E.2) If the comparison in equation (1), below, holds and there are
         SMSS bytes of previously unsent data available for
         transmission, then the sender MUST transmit one segment of SMSS
         bytes.

(E.2) 方程式(1)における比較が以下で成立して、トランスミッションに利用可能な以前にunsentなデータのSMSSバイトがあれば、送付者はSMSSバイトのあるセグメントを伝えなければなりません。

           (pipe + Skipped) <= (FlightSizePrev - SMSS)              (1)

(運ぶか、またはスキップします) <=(FlightSizePrev--SMSS)(1)

Bhandarkar, et al.            Experimental                     [Page 10]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[10ページ]RFC4653

         If the comparison in equation (1) does not hold or no new data
         can be transmitted (due to lack of data from the application
         or the advertised window limit), skip to step (E.6).

方程式(1)における比較が成立しないことができないか、どんな新しいデータも送ることができないなら(アプリケーションか広告を出している窓の限界からの資料不足のため)、スキップして、(E.6)を踏んでください。

   (E.3) Pipe MUST be incremented by SMSS bytes.

(E.3)パイプをSMSSバイト増加しなければなりません。

   (E.4) If using Careful Limited Transmit, Skipped MUST be incremented
         by SMSS bytes to ensure that the next SMSS bytes of SACKed data
         processed does not trigger a Limited Transmit transmission
         (since the goal of Careful Limited Transmit is to send upon
         receipt of every second duplicate ACK).

(E.4) Careful株式会社Transmitを使用するなら、バイトのSACKedデータが処理した次のSMSSが株式会社Transmitトランスミッションの引き金とならないのを保証するためにSkippedをSMSSバイト増加しなければなりません(Careful株式会社Transmitの目標があらゆる第2写しACKを受け取り次第発信することであるので)。

   (E.5) A TCP MUST return to step (E.2) to ensure that as many bytes
         as are appropriate are transmitted.  This provides robustness
         to ACK loss that can be (largely) compensated for using SACK
         information.

(E.5) 適切であるのと同じくらい多くのバイトが伝えられるのを保証するために(E.2)を踏むTCP MUSTリターン。 これはSACK情報を使用することで(主に)補うことができるACKの損失に丈夫さを提供します。

   (E.6) DupThresh MUST be reset via:

以下を通って(E.6)DupThreshをリセットしなければなりません。

           DupThresh = max (LT_F * (FlightSize / SMSS),3)

DupThresh=最大(LT_F*(FlightSize / SMSS)、3)

         where FlightSize is the total number of bytes that have not
         been cumulatively acknowledged (which is different from
         "pipe").

FlightSizeが累積的に承認されていないバイト(「パイプ」と異なっている)の総数であるところ。

3.4.  Entering Loss Recovery

3.4. 損失回復に入ります。

   When a segment is deemed lost via the algorithms in [RFC3517],
   Extended Limited Transmit MUST be terminated, leaving the algorithms
   in [RFC3517] to govern TCP's behavior.  One slight change to
   [RFC3517] MUST be made, however.  In Section 5, step (2) of [RFC3517]
   MUST be changed to:

セグメントが[RFC3517]のアルゴリズムで無くなると考えられるとき、Extended株式会社Transmitを終えなければなりません、[RFC3517]のアルゴリズムがTCPの振舞いを治めるのを残して。 しかしながら、[RFC3517]への1回の小変化を作らなければなりません。セクション5では、以下のことのために[RFC3517]のステップ(2)を変えなければなりません。

       (2) ssthresh = cwnd = (FlightSizePrev / 2)

(2) ssthreshはcwnd=と等しいです。(FlightSizePrev / 2)

   This ensures that the congestion control modifications are made with
   respect to the amount of data in the network before FlightSize was
   increased by Extended Limited Transmit.

これは、Extended株式会社TransmitがFlightSizeを増加させる前に、データ量に関してネットワークで輻輳制御変更をするのを確実にします。

   Note: Once the algorithm in [RFC3517] takes over from Extended
   Limited Transmit, the DupThresh value MUST be held constant until the
   loss recovery phase is terminated.

以下に注意してください。 [RFC3517]のアルゴリズムがExtended株式会社Transmitからいったん引き継ぐと、損失回収段階が終えられるまで、DupThresh値を一定に保たなければなりません。

Bhandarkar, et al.            Experimental                     [Page 11]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[11ページ]RFC4653

4.  Advantages

4. 利点

   The major advantages of TCP-NCR are twofold.  As discussed in Section
   1, TCP-NCR will open up the design space for network applications and
   components that are currently constrained by TCP's lack of robustness
   to packet reordering.  The second advantage is in terms of an
   increase in TCP performance.

TCP-NCRの主要な利点は二つです。 セクション1で議論するように、TCP-NCRは現在TCPの丈夫さの不足でパケット再命令に抑制されるネットワーク応用とコンポーネントのためにデザインスペースを開けるでしょう。 2番目の利点がTCP性能の増加であります。

   [BR04] presents ns-2 [NS-2] simulations of a pre-cursor to the TCP-
   NCR algorithm specified in this document, called TCP-DCR (Delayed
   Congestion Response).  The paper shows that TCP-DCR aids performance
   in comparison to unmodified TCP in the presence of packet reordering.
   In addition, the extended version of [BR04] presents results based on
   emulations involving Linux (kernel 2.4.24).  These results show that
   the performance of TCP-DCR is similar to Linux's native
   implementation that seeks to "undo" wrong decisions according to
   duplicate-SACK (DSACK) [RFC2883] feedback (similar to the schemes
   outlined in [ZKFP03]), when packets are reordered by less than one
   RTT.  The advantage of using TCP-DCR over the DSACK-based scheme is
   that the DSACK-based scheme tries to estimate the exact amount of
   reordering in the network using fairly complex algorithms, whereas
   TCP-DCR achieves similar results with less complicated modifications.

TCP-DCR(Congestion Responseを遅らせる)は、[BR04]が先駆のナノ秒-2つ[NS-2]のシミュレーションを本書では指定されたTCP- NCRアルゴリズムに提示すると呼びました。 論文は、TCP-DCRがパケット再命令の面前で変更されていないTCPに比較における性能を支援するのを示します。 さらに、[BR04]の拡張版がリナックスにかかわる模倣に基づく結果を提示する、(カーネル、2.4、.24、) これらの結果は、TCP-DCRの性能が写し-SACK(DSACK)[RFC2883]フィードバックに応じて間違った決定を「元に戻そうとする」リナックスのネイティブの実現と同様であることを([ZKFP03]に概説された計画と同様の)示します、パケットが1RTTによって再命令されると。 DSACKベースの計画の上でTCP-DCRを使用する利点はDSACKベースの計画が複雑なアルゴリズムを公正に使用することでネットワークにおける正確な量の再命令を見積もっていようとしますが、TCP-DCRがそれほど複雑でない変更で同様の結果を獲得するということです。

   In addition, [BR04,BSRV04] illustrate the ability of TCP-DCR to allow
   for the improvement of other parts of the system.  For example, these
   papers show that increasing TCP's robustness to packet reordering
   allows a novel wireless ARQ mechanism to be added at the link-layer.
   The added robustness of the link-layer to channel errors, in turn,
   increases TCP performance by not requiring TCP to retransmit packets
   that were dropped due to corruption (and thus also prevents TCP from
   needlessly reducing the sending rate when retransmitting these
   segments).

さらに、[BR04、BSRV04]はTCP-DCRがシステムの他の部分の改良を考慮する能力を例証します。 例えば、これらの論文は、目新しい無線のARQメカニズムがリンクレイヤでパケット再命令への増加するTCPの丈夫さで加えるのを示します。 チャンネル誤りへのリンクレイヤの加えられた丈夫さはTCPが不正(そして、その結果、また、これらのセグメントを再送するとき、TCPが送付レートを不必要に低下させるのを防ぐ)のため落とされたパケットを再送するのを必要としないのによるTCP性能を順番に向上させます。

5.  Disadvantages

5. 不都合

   Although all the changes outlined above are implemented in the
   sender, the receiver also potentially has a part to play.  In
   particular, TCP-NCR increases the receiver's buffering requirement by
   up to an extra cwnd -- in the case of the TCP sender using Aggressive
   Limited Transmit and actual loss occurring in the network.
   Therefore, to maximize the benefits from TCP-NCR, receivers should
   advertise a large window to absorb the extra out-of-order traffic.
   In the case that the additional buffer requirements are not met, the
   use of the above algorithm takes into account the reduced advertised
   window -- with a corresponding loss in robustness to packet
   reordering.

上に概説されたすべての変化が送付者で実行されますが、また、受信機には演じる役割が潜在的にあります。 特に、TCP-NCRは、受信機がAggressive株式会社Transmitを使用しているTCP送付者とネットワークで発生する実際の損失の場合で要件を余分なcwndまでバッファリングするのを増加させます。 したがって、TCP-NCRから利益を最大にするなら、受信機は、余分な不適切な交通を吸収するために大きい窓の広告を出すはずです。 追加バッファ必要条件が満たされないで、上のアルゴリズムの使用は丈夫さにおける対応する損失を伴う減少している広告を出している窓をパケット再命令に考慮に入れます。

Bhandarkar, et al.            Experimental                     [Page 12]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[12ページ]RFC4653

   In addition, using TCP-NCR could delay the delivery of data to the
   application by up to one RTT because the fast retransmission point is
   delayed by roughly one RTT in TCP-NCR.  Applications that are
   sensitive to such delays should turn off the TCP-NCR option.  For
   instance, a socket option could be introduced to allow applications
   to control whether NCR would be used for a particular connection.

さらに、TCP-NCRを使用すると、速い「再-トランスミッション」ポイントがTCP-NCRのおよそ1RTTで遅れるので、データの配送は最大1RTTによるアプリケーションに遅れるかもしれません。 そのような遅れに敏感なアプリケーションはTCP-NCRオプションをオフにするべきです。 例えば、アプリケーションが、NCRが特定の接続に使用されるかどうかを制御するのを許容するためにソケットオプションを紹介できました。

   Finally, the use of TCP-NCR makes the recovery from congestion events
   sluggish in comparison to the standard reaction in [RFC2581].  [BR04,
   BSRV04] show (via simulation) that the delay in congestion response
   has minimal impact on the connection itself and the traffic sharing a
   bottleneck.  [BBFS01] also indicates (again, via simulation) that
   "slowly responsive" congestion control may be safe for deployment in
   the Internet.  These studies suggest that schemes that slightly delay
   congestion control decisions may be reasonable; however, further
   experimentation on the Internet is required to verify these results.

最終的に、TCP-NCRの使用は[RFC2581]で比較でのろい混雑出来事から平均的な反応まで回復します。 [BR04、BSRV04]は、混雑応答の遅れが接続自体とボトルネックを共有する交通に最小量の影響力を持っているのを示します(シミュレーションで)。 シミュレーション) それを通してまた、[BBFS01]が示す、(再び、「ゆっくり、敏感である、」 インターネットでの展開に、輻輳制御は安全であるかもしれません。 これらの研究は、輻輳制御決定をわずかに遅らせる計画が妥当であるかもしれないと示唆します。 しかしながら、インターネットにおけるさらなる実験が、これらの結果について確かめるのに必要です。

6.  Related Work

6. 関連仕事

   Over the past few years, several solutions have been proposed to
   improve the performance of TCP in the face of segment reordering.
   These schemes generally fall into one of two categories (with some
   overlap): mechanisms that try to prevent spurious retransmits from
   happening and mechanisms that try to detect spurious retransmits and
   "undo" the needless congestion control state changes that have been
   taken.

過去数年間にわたって、いくつかの解決策が、セグメント再命令に直面してTCPの性能を向上させるために提案されています。 一般に、これらの計画は2つのカテゴリ(何らかのオーバラップがある)の1つになります: それが防ごうとするメカニズム、偽り、出来事とメカニズムから検出するそのトライを再送する、偽り、再送、そして、取られた不必要な輻輳制御が述べる「アンドゥ」変化。

   [BA02,ZKFP03] attempt to prevent segment reordering from triggering
   spurious retransmits by using various algorithms to approximate the
   duplicate ACK threshold required to disambiguate loss and reordering
   over a given network path at a given time.  TCP-NCR similarly tries
   to prevent spurious retransmits.  However, TCP-NCR takes a simplified
   approach compared to those in [BA02, ZKFP03], in that TCP-NCR simply
   delays retransmission by an amount based on the current cwnd (in
   comparison to standard TCP), while the other schemes use relatively
   complex algorithms in an attempt to derive a more precise value for
   DupThresh that depends on the current patterns of packet reordering.
   While TCP-NCR offers simplicity, the other schemes may offer more
   precision such that applications would not be forced to wait as long
   for their retransmissions.  Future work could be undertaken to
   achieve robustness without needless delay.

[BA02、ZKFP03]は、引き金となるのによる偽りの再命令が写しACK敷居に近似するのに様々なアルゴリズムを使用することによって再送するセグメントが一時に損失のあいまいさを除くのが必要であり、与えられたネットワーク経路の上で再命令されるのを防ぐのを試みます。 TCP-NCRが同様に防ごうとする、偽り、再送します。 しかしながら、[BA02、ZKFP03]でそれらと比べて、TCP-NCRは簡単なアプローチを取ります、現在のcwnd(標準のTCPとの比較における)に基づく量に従ってTCP-NCRが単に「再-トランスミッション」を遅らせるので、他の計画はパケット再命令の現在のパターンによるDupThreshのために、より正確な値を引き出す試みに比較的複雑なアルゴリズムを使用しますが。 TCP-NCRが簡単さを提供している間、他の計画は、アプリケーションがそれらの「再-トランスミッション」に長いとしてやむを得ず待たないように、より多くの精度を提供するかもしれません。 不必要な遅れなしで丈夫さを達成するために今後の活動を引き受けることができました。

   On the other hand, several schemes have been developed to detect and
   mitigate needless retransmissions after the fact.  [RFC3522, RFC3708,
   BA02, RFC4015, RFC4138] present algorithms to detect spurious
   retransmits and mitigate the changes these events made to the
   congestion control state.  TCP-NCR could be used in conjunction with
   these algorithms, with TCP-NCR attempting to prevent spurious

他方では、事実の後に不必要な「再-トランスミッション」を検出して、緩和するためにいくつかの計画を開発してあります。 [RFC3522、RFC3708、BA02、RFC4015、RFC4138]が検出するアルゴリズムを提示する、偽り、これらの出来事が輻輳制御状態にした変更を再送して、緩和してください。 防ぐTCP-NCRの試みでこれらのアルゴリズムに関連してTCP-NCRを使用できた、偽り

Bhandarkar, et al.            Experimental                     [Page 13]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[13ページ]RFC4653

   retransmits and some other scheme kicking in if the prevention
   failed.  In addition, note that TCP-NCR is concentrated on preventing
   spurious fast retransmits; some of the above algorithms also attempt
   to detect and mitigate spurious timeout-based retransmits.

再送、そして、防止が失敗したなら始まるある他の計画。 さらに、TCP-NCRが速く防止偽りに集結されるというメモは再送されます。 検出して、緩和する、また、上のアルゴリズムのいくつかが、試みる偽り、タイムアウトベース、再送します。

7.  Security Considerations

7. セキュリティ問題

   General attacks against the congestion control of TCP are described
   in [RFC2581].  SACK-based loss recovery for TCP [RFC3517] mitigates
   some of the duplicate ACK attacks against TCP's congestion control.
   This document builds upon that work, and the Extended Limited
   Transmit algorithms specified in this document have been designed to
   thwart the ACK division problems that are described in [RFC3465].

総攻撃は[RFC2581]にTCPの輻輳制御に対して説明されます。 TCP[RFC3517]のためのSACKベースの損失回復はTCPの輻輳制御に対して写しACK攻撃のいくつかを緩和します。 このドキュメントはその仕事を当てにします、そして、本書では指定されたExtended株式会社Transmitアルゴリズムは、[RFC3465]で説明されるACK分割問題を阻むように設計されています。

8.  Acknowledgments

8. 承認

   Feedback from Lars Eggert, Ted Faber, Wesley Eddy, Gorry Fairhurst,
   Sally Floyd, Sara Landstrom, Nauzad Sadry, Pasi Sarolahti, Joe Touch,
   Nitin Vaidya, and the TCPM working group have contributed
   significantly to this document.  Our thanks to all!

ラース・エッゲルトからのフィードバック、テッド・フェーバー、ウエスリーEddy、ゴーリーFairhurst、サリー・フロイド、サラ・ランドストローム、Nauzad Sadry、パシSarolahti、ジョーTouch、Nitin Vaidya、およびTCPMワーキンググループはこのドキュメントにかなり貢献しました。 すべてへの私たちのありがとう!

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

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

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

   [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
             Selective Acknowledgement Options", RFC 2018, October 1996.

[RFC2018] マシスとM.とMahdaviとJ.とフロイド、S.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。

   [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月。

   [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
             Control", RFC 2581, April 1999.

[RFC2581] オールマンとM.とパクソン、V.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。

   [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
             TCP's Loss Recovery Using Limited Transmit", RFC 3042,
             January 2001.

[RFC3042] オールマン、M.、Balakrishnan、H.、およびS.フロイド、「株式会社を使用することでTCPの損失回復を機能アップして、伝わってください」、RFC3042、2001年1月。

   [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月)。

Bhandarkar, et al.            Experimental                     [Page 14]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[14ページ]RFC4653

9.2.  Informative References

9.2. 有益な参照

   [BA02]    E. Blanton and M. Allman, "On Making TCP More Robust to
             Packet Reordering," ACM Computer Communication Review,
             January 2002.

[BA02] E.ブラントンとM.オールマン、「パケットReorderingにより強健な作成TCP」、ACMコンピュータコミュニケーションレビュー、2002年1月。

   [BBFS01]  D. Bansal, H. Balakrishnan, S. Floyd and S. Shenker,
             "Dynamic Behavior of Slowly Responsive Congestion Control
             Algorithms", Proceedings of ACM SIGCOMM, Sep. 2001.

[BBFS01] D.Bansal、H.Balakrishnan、S.フロイド、およびS.Shenker、「動的挙動、ゆっくり、敏感な混雑がアルゴリズムを制御する、」、ACM SIGCOMM(2001年9月)の議事

   [BPS99]   J. Bennett, C. Partridge, and N. Shectman, "Packet
             reordering is not pathological network behavior," IEEE/ACM
             Transactions on Networking, December 1999.

[BPS99]J.ベネット、C.Partridge、およびN.Shectman、「パケット再命令は病理学的なネットワークの振舞いではありません」、Networkingの上のIEEE/ACM Transactions、1999年12月。

   [BR04]    Sumitha Bhandarkar and A. L. Narasimha Reddy, "TCP-DCR:
             Making TCP Robust to Non-Congestion Events", In the
             Proceedings of Networking 2004 conference, May 2004.
             Extended version available as tech report TAMU-ECE-2003-04.

[BR04]Sumitha BhandarkarとA.L.ナラシマ・レディ、「TCP-DCR:」 「Non-混雑Eventsへの作成TCP Robust」、2004年のNetworking会議、2004年5月のIn Proceedings。 科学技術のレポートTAMU-ECE-2003-04として利用可能な拡張版。

   [BSRV04]  Sumitha Bhandarkar, Nauzad Sadry, A. L. Narasimha Reddy and
             Nitin Vaidya, "TCP-DCR: A Novel Protocol for Tolerating
             Wireless Channel Errors", to appear in IEEE Transactions on
             Mobile Computing.

[BSRV04] Sumitha Bhandarkar、Nauzad Sadry、A.L.ナラシマ・レディ、およびNitin Vaidya、「TCP-DCR:」 「Tolerating Wireless Channel ErrorsのためのNovelプロトコル」、モバイルComputingの上のIEEE Transactionsに現れるように。

   [GPL04]   Ladan Gharai, Colin Perkins and Tom Lehman, "Packet
             Reordering, High Speed Networks and Transport Protocol
             Performance", ICCCN 2004, October 2004.

[GPL04]Ladan Gharai、コリン・パーキンス、およびトム・レイマン、「パケットReordering、高速ネットワーク、および輸送はパフォーマンスについて議定書の中で述べます」、ICCCN2004、2004年10月。

   [Jac88]   V. Jacobson, "Congestion Avoidance and Control", Computer
             Communication Review, vol. 18, no. 4, pp. 314-329, Aug.
             1988.  ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

ジェーコブソンと、「輻輳回避とコントロール」に対する[Jac88]、コンピュータCommunication Review、vol.18、No.4、ページ 314-329、8月1988日の ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z 。

   [JIDKT03] S. Jaiswal, G. Iannaccone, C. Diot, J. Kurose, and D.
             Towsley, "Measurement and Classification of Out-of-Sequence
             Packets in a Tier-1 IP Backbone," Proceedings of IEEE
             INFOCOM, 2003.

[JIDKT03] S.Jaiswal、G.Iannaccone、C.Diot、J.黒瀬、D.Towsley、および「測定と系列の外の分類パケットコネa層-1IP背骨」、IEEE INFOCOM、2003年の議事

   [KM02]    I. Keslassy and N. McKeown, "Maintaining packet order in
             twostage switches," Proceedings of the IEEE Infocom, June
             2002

[KM02] I.KeslassyとN.マキューン、「twostageスイッチでパケットオーダーを維持します」、IEEE Infocom、2002年6月のProceedings

   [MAF05]   A. Medina, M. Allman, S. Floyd.  Measuring the Evolution of
             Transport Protocols in the Internet.  ACM Computer
             Communication Review, 35(2), April 2005.

[MAF05] A.メディナ、M.オールマン、S.フロイド。 インターネットでのトランスポート・プロトコルの発展を測定します。 ACMコンピュータコミュニケーションレビュー、35(2)、2005年4月。

   [NS-2]    ns-2 Network Simulator. http://www.isi.edu/nsnam/

[NS-2]ナノ秒-2Network Simulator http://www.isi.edu/nsnam/

Bhandarkar, et al.            Experimental                     [Page 15]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[15ページ]RFC4653

   [Pax97]   V. Paxson, "End-to-End Internet Packet Dynamics,"
             Proceedings of ACM SIGCOMM, September 1997.

[Pax97]V.パクソン、「終わりから終わりへのインターネットパケット力学」、ACM SIGCOMM、1997年9月の議事。

   [RFC896]  Nagle, J., "Congestion control in IP/TCP internetworks",
             RFC 896, January 1984.

[RFC896] ネーグル、J.、「IP/TCPインターネットワークにおける輻輳制御」、RFC896、1984年1月。

   [RFC1122] Braden, R., "Requirements for Internet Hosts -
             Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日

   [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] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H.
             Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V.
             Paxson.  Stream Control Transmission Protocol.  October
             2000.

[RFC2960] R.スチュワート、Q.シェ、K.Morneault、鋭いC.H.Schwarzbauer、T.テイラー、I.Rytina、M.カッラL.チャン(V.パクソン)。 制御伝動プロトコルを流してください。 2000年10月。

   [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte
             Counting (ABC)", RFC 3465, February 2003.

[RFC3465]オールマン、M.、「適切なバイト勘定(ABC)とのTCP輻輳制御」、RFC3465、2003年2月。

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

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

   [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective
             Acknowledgement (DSACKs) and Stream Control Transmission
             Protocol (SCTP) Duplicate Transmission Sequence Numbers
             (TSNs) to Detect Spurious Retransmissions", RFC 3708,
             February 2004.

[RFC3708] ブラントン、E.、およびM.オールマン、「TCPの写しの選択している承認(DSACKs)を使用して、流れの制御伝動プロトコル(SCTP)は偽物のRetransmissionsを検出するために、トランスミッション一連番号(TSNs)をコピーします」、RFC3708、2004年2月。

   [RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for
             TCP", RFC 4015, February 2005.

[RFC4015] ラドウィグとR.とA.Gurtov、「TCPのためのアイフェル高原応答アルゴリズム」、RFC4015、2005年2月。

   [RFC4138] 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.

[RFC4138] Sarolahti、P.、およびM.Kojo、「RTO-回復(F-RTO)を進めてください」 「TCPがある偽りの再送タイムアウトを検出するためのアルゴリズムと流れの制御伝動は(SCTP)について議定書の中で述べる」RFC4138、2005年8月。

   [ZKFP03]  M. Zhang, B. Karp, S. Floyd, L. Peterson, "RR-TCP: A
             Reordering-Robust TCP with DSACK", in Proceedings of the
             Eleventh IEEE International Conference on Networking
             Protocols (ICNP 2003), Atlanta, GA, November, 2003.

[ZKFP03]M.チャン、B.カープ、S.フロイド、L.ピーターソン、「RR-TCP:」 (ICNP2003)、ネットワーク・プロトコルアトランタ(ジョージア)(2003年11月)における第11IEEE国際会議の議事における「DSACKとReordering強健なTCP。」

Bhandarkar, et al.            Experimental                     [Page 16]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[16ページ]RFC4653

Authors' Addresses

作者のアドレス

   Sumitha Bhandarkar
   Dept. of Elec. Engg.
   214 ZACH
   College Station, TX 77843-3128

ElecのSumitha Bhandarkar部。 Engg。 214ザック大学駅、テキサス77843-3128

   Phone: (512) 468-8078
   EMail: sumitha@tamu.edu
   URL: http://students.cs.tamu.edu/sumitha/

以下に電話をしてください。 (512) 468-8078 メールしてください: sumitha@tamu.edu URL: http://students.cs.tamu.edu/sumitha/

   A. L. Narasimha Reddy
   Professor
   Dept. of Elec. Engg.
   315C WERC
   College Station, TX 77843-3128

ElecのA.L.ナラシマレディ教授部。 Engg。 315C WERC大学駅、テキサス77843-3128

   Phone: (979) 845-7598
   EMail: reddy@ee.tamu.edu
   URL: http://ee.tamu.edu/~reddy/

以下に電話をしてください。 (979) 845-7598 メールしてください: reddy@ee.tamu.edu URL: http://ee.tamu.edu/~reddy/

   Mark Allman
   ICSI Center for Internet Research
   1947 Center Street, Suite 600
   Berkeley, CA 94704-1198

Internet Research1947Center通り、Suite600バークレー、カリフォルニア94704-1198へのマークオールマンICSIセンター

   Phone: (440) 235-1792
   EMail: mallman@icir.org
   URL: http://www.icir.org/mallman/

以下に電話をしてください。 (440) 235-1792 メールしてください: mallman@icir.org URL: http://www.icir.org/mallman/

   Ethan Blanton
   Purdue University Computer Science
   305 North University Street
   West Lafayette, IN  47907

47907におけるイーサンブラントンパデュー大学コンピュータサイエンス305の北の大学通りウェストラフィエット

   EMail: eblanton@cs.purdue.edu

メール: eblanton@cs.purdue.edu

Bhandarkar, et al.            Experimental                     [Page 17]

RFC 4653            Improving the Robustness of TCP          August 2006

Bhandarkar、他 2006年8月にTCPの丈夫さを改良する実験的な[17ページ]RFC4653

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   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.

このドキュメントは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 provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Bhandarkar, et al.            Experimental                     [Page 18]

Bhandarkar、他 実験的[18ページ]