RFC3155 日本語訳

Network Working Group                                         S. Dawkins
Request for Comments: 3155                                 G. Montenegro
BCP: 50                                                          M. Kojo
Category: Best Current Practice                                V. Magret
                                                               N. Vaidya
                                                             August 2001

コメントを求めるワーキンググループS.ダウキンズの要求をネットワークでつないでください: 3155G.モンテネグロBCP: 50M.Kojoカテゴリ: 最も良い現在の練習V.Magret N.Vaidya2001年8月

        End-to-end Performance Implications of Links with Errors

終わりから終わりへの誤りとのリンクのパフォーマンス含意

Status of this Memo

このMemoの状態

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

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

Abstract

要約

   This document discusses the specific TCP mechanisms that are
   problematic in environments with high uncorrected error rates, and
   discusses what can be done to mitigate the problems without
   introducing intermediate devices into the connection.

このドキュメントは、環境で問題が多い特定のTCPメカニズムについて高い非修正の誤り率と議論して、中間的装置を紹介しないで問題を緩和するために何ができるかと接続と議論します。

Table of Contents

目次

   1.0 Introduction .............................................    2
      1.1 Should you be reading this recommendation?  ...........    3
      1.2 Relationship of this recommendation to PEPs ...........    4
      1.3 Relationship of this recommendation to Link Layer
          Mechanisms.............................................    4
   2.0 Errors and Interactions with TCP Mechanisms ..............    5
      2.1 Slow Start and Congestion Avoidance [RFC2581] .........    5
      2.2 Fast Retransmit and Fast Recovery [RFC2581] ...........    6
      2.3 Selective Acknowledgements [RFC2018, RFC2883] .........    7
   3.0 Summary of Recommendations ...............................    8
   4.0 Topics For Further Work ..................................    9
      4.1 Achieving, and maintaining, large windows .............   10
   5.0 Security Considerations ..................................   11
   6.0 IANA Considerations ......................................   11
   7.0 Acknowledgements .........................................   11
   References ...................................................   11
   Authors' Addresses ...........................................   14
   Full Copyright Statement .....................................   16

1.0序論… 2 1.1 あなたはこの推薦を読むことであるべきですか? ........... 3 1.2 PEPsへのこの推薦の関係… 4 1.3 Link Layer Mechanismsへのこの推薦の関係… 4 TCPメカニズムとの2.0回の誤りと相互作用… 5 2.1 始めと輻輳回避[RFC2581]を遅くしてください… 2.2が速く再送する5と速い回復[RFC2581]… 6 2.3 選択している承認[RFC2018、RFC2883]… 7 推薦の3.0概要… 8 さらなる仕事のための4.0の話題… 9 4.1 大きい窓を達成して、維持します… 10 5.0 セキュリティ問題… 11 6.0 IANA問題… 11 7.0の承認… 11の参照箇所… 11人の作者のアドレス… 14 完全な著作権宣言文… 16

Dawkins, et al.          Best Current Practice                  [Page 1]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[1ページ]RFC3155PILC--誤り2001年8月とのリンク

1.0 Introduction

1.0 序論

   The rapidly-growing Internet is being accessed by an increasingly
   wide range of devices over an increasingly wide variety of links.  At
   least some of these links do not provide the degree of reliability
   that hosts expect, and this expansion into unreliable links causes
   some Internet protocols, especially TCP [RFC793], to perform poorly.

急速に成長しているインターネットはますます広いバラエティーのリンクの上にますます広範囲の装置によってアクセスされています。 少なくともこれらのいくつかのリンクはホストが予想する信頼性の度合いを前提としません、そして、頼り無いリンクへのこの拡大で、いくつかのインターネットプロトコル、特にTCP[RFC793]は不十分に働きます。

   Specifically, TCP congestion control [RFC2581], while appropriate for
   connections that lose traffic primarily because of congestion and
   buffer exhaustion, interacts badly with uncorrected errors when TCP
   connections traverse links with high uncorrected error rates.  The
   result is that sending TCPs may spend an excessive amount of time
   waiting for acknowledgement that do not arrive, and then, although
   these losses are not due to congestion-related buffer exhaustion, the
   sending TCP transmits at substantially reduced traffic levels as it
   probes the network to determine "safe" traffic levels.

明確に、主として混雑とバッファ疲労困憊のために交通を失う接続に適切ですが、TCP接続が高い非修正の誤り率とのリンクを横断するとき、TCP輻輳制御[RFC2581]はひどく非修正の誤りと対話します。 結果は「安全な」交通レベルを決定するのを次に、到着しないでください。そうすれば、これらの損失が混雑関連のバッファ疲労困憊のためでないのにもかかわらずの、ネットワークを調べるとき発信しているTCPがかなり減少している交通レベルで伝わるという承認を待っているのに送付TCPsが過度の時間を費やすかもしれないということです。

   This document does not address issues with other transport protocols,
   for example, UDP.

このドキュメントは他のトランスポート・プロトコル、例えば、UDPの問題を記述しません。

   Congestion avoidance in the Internet is based on an assumption that
   most packet losses are due to congestion.  TCP's congestion avoidance
   strategy treats the absence of acknowledgement as a congestion
   signal.  This has worked well since it was introduced in 1988 [VJ-
   DCAC], because most links and subnets have relatively low error rates
   in normal operation, and congestion is the primary cause of loss in
   these environments.  However, links and subnets that do not enjoy low
   uncorrected error rates are becoming more prevalent in parts of the
   Internet.  In particular, these include terrestrial and satellite
   wireless links.  Users relying on traffic traversing these links may
   see poor performance because their TCP connections are spending
   excessive time in congestion avoidance and/or slow start procedures
   triggered by packet losses due to transmission errors.

インターネットの輻輳回避はほとんどのパケット損失が混雑のためであるという仮定に基づいています。 TCPの混雑回避方略は混雑信号として承認の欠如を扱います。 1988年[VJ- DCAC]にそれを導入して以来、これはうまくいっています、ほとんどのリンクとサブネットには通常の操作における比較的低い誤り率があって、混雑がこれらの環境における損失の根本原因であるので。 しかしながら、低非修正の誤り率を楽しまないリンクとサブネットがインターネットの地域で、より一般的になっています。 特に、これらは地球と衛星の無線のリンクを含んでいます。 彼らのTCP接続が手順が伝送エラーによるパケット損失で引き金となった輻輳回避、そして/または、遅れた出発で過度の時間を過ごしているので、これらのリンクを横断する交通に依存するユーザは不十分な性能を見るかもしれません。

   The recommendations in this document aim at improving utilization of
   available path capacity over such high error-rate links in ways that
   do not threaten the stability of the Internet.

推薦は本書ではそのような高い誤り率リンクの上にインターネットの安定性を脅かさない方法で有効な経路容量の利用を改良するのを目的とします。

   Applications use TCP in very different ways, and these have
   interactions with TCP's behavior [RFC2861].  Nevertheless, it is
   possible to make some basic assumptions about TCP flows.
   Accordingly, the mechanisms discussed here are applicable to all uses
   of TCP, albeit in varying degrees according to different scenarios
   (as noted where appropriate).

アプリケーションは非常に異なった方法でTCPを使用します、そして、これらには、TCPの振舞い[RFC2861]との相互作用があります。 それにもかかわらず、TCPに関するいくつかの基本的な仮定を流れようにするのは可能です。 それに従って、ここで議論したメカニズムはTCPのすべての用途に適切です、多かれ少なかれ異なったシナリオによると(適切であるところに述べられるように)。

Dawkins, et al.          Best Current Practice                  [Page 2]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[2ページ]RFC3155PILC--誤り2001年8月とのリンク

   This recommendation is based on the explicit assumption that major
   changes to the entire installed base of routers and hosts are not a
   practical possibility.  This constrains any changes to hosts that are
   directly affected by errored links.

この推薦はルータとホストの全体のインストールされたベースへの大きな変化が実用的な可能性でないという明白な仮定に基づいています。 これはerroredリンクで直接影響を受けるホストへのどんな変化も抑制します。

1.1 Should you be reading this recommendation?

1.1 あなたはこの推薦を読むことであるべきですか?

   All known subnetwork technologies provide an "imperfect" subnetwork
   service - the bit error rate is non-zero.  But there's no obvious way
   for end stations to tell the difference between packets discarded due
   to congestion and losses due to transmission errors.

すべての知られているサブネットワーク技術が「不完全な」サブネットワークサービスを提供します--ビット誤り率は非ゼロです。 しかし、端のステーションがパケットの違いが伝送エラーによる混雑と損失のため捨てられたと言う当たり前の方法が全くありません。

   If a directly-attached subnetwork is reporting transmission errors to
   a host, these reports matter, but we can't rely on explicit
   transmission error reports to both hosts.

直接付属しているサブネットワークが伝送エラーをホストに報告しているなら、これらのレポートは重要ですが、私たちは明白な伝送エラーレポートに両方のホストに頼ることができません。

   Another way of deciding if a subnetwork should be considered to have
   a "high error rate" is by appealing to mathematics.

サブネットワークには「高い誤り率」があると考えられるべきであるかどうか決める別の方法は数学に求めることです。

   An approximate formula for the TCP Reno response function is given in
   [PFTK98]:

[PFTK98]でTCPリノレスポンス関数のための大体の公式を与えます:

                                s
   T = --------------------------------------------------
       RTT*sqrt(2p/3) + tRTO*(3*sqrt(3p/8))*p*(1 + 32p**2)

s T=-------------------------------------------------- RTT*sqrt(2p/3)+tRTO*(3*sqrt(3p/8))*p*(1+32p**2)

   where

どこ

       T = the sending rate in bytes per second
       s = the packet size in bytes
       RTT = round-trip time in seconds
       tRTO = TCP retransmit timeout value in seconds
       p = steady-state packet loss rate

バイトで表現される、秒の往復のRTT=時間のバイトで表現されるパケット2番目のs=サイズあたりの送付T=レートに、tRTO=TCPは定常状態パケット損失秒p=率におけるタイムアウト値を再送します。

   If one plugs in an observed packet loss rate, does the math and then
   sees predicted bandwidth utilization that is greater than the link
   speed, the connection will not benefit from recommendations in this
   document, because the level of packet losses being encountered won't
   affect the ability of TCP to utilize the link.  If, however, the
   predicted bandwidth is less than the link speed, packet losses are
   affecting the ability of TCP to utilize the link.

人が観測されたパケット損失率のプラグを差し込んで、計算して、次に、リンク速度より大きい予測された帯域幅利用を見ると、接続は本書では推薦の利益を得ないでしょう、遭遇するパケット損失のレベルがTCPがリンクを利用する能力に影響しないので。 しかしながら、予測された帯域幅がリンク速度以下であるなら、パケット損失はTCPがリンクを利用する能力に影響しています。

   If further investigation reveals a subnetwork with significant
   transmission error rates, the recommendations in this document will
   improve the ability of TCP to utilize the link.

重大な感染誤り率に従ってさらなる調査がサブネットワークを明らかにすると、推薦は本書ではTCPがリンクを利用する能力を改良するでしょう。

Dawkins, et al.          Best Current Practice                  [Page 3]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[3ページ]RFC3155PILC--誤り2001年8月とのリンク

   A few caveats are in order, when doing this calculation:

この計算をするとき、いくつかの警告が整然としています:

   (1)   the RTT is the end-to-end RTT, not the link RTT.
   (2)   Max(1.0, 4*RTT) can be substituted as a simplification for
         tRTO.
   (3)   losses may be bursty - a loss rate measured over an interval
         that includes multiple bursty loss events may understate the
         impact of these loss events on the sending rate.

(1) RTTはリンクRTTではなく、終わりから終わりへのRTTです。 (2) tRTOのための簡素化としてマックス(1.0、4*RTT)を代入できます。 (3) 損失はburstyであるかもしれません--複数のbursty損失出来事を含んでいる間隔の間に測定された損失率は送付レートでこれらの損失出来事の衝撃を控え目に言うかもしれません。

1.2 Relationship of this recommendation to PEPs

1.2 PEPsへのこの推薦の関係

   This document discusses end-to-end mechanisms that do not require
   TCP-level awareness by intermediate nodes.  This places severe
   limitations on what the end nodes can know about the nature of losses
   that are occurring between the end nodes.  Attempts to apply
   heuristics to distinguish between congestion and transmission error
   have not been successful [BV97, BV98, BV98a].  This restriction is
   relaxed in an informational document on Performance Enhancing Proxies
   (PEPs) [RFC3135]. Because PEPs can be placed on boundaries where
   network characteristics change dramatically, PEPs have an additional
   opportunity to improve performance over links with uncorrected
   errors.

このドキュメントは終わりから終わりへの中間的ノードでTCP-レベル認識を必要としないメカニズムについて議論します。 これはエンドノードがエンドノードの間に発生している損失の自然に関して知ることができることに厳しい制限を置きます。 混雑と伝送エラーを見分けるために発見的教授法を適用する試みはうまくいっていません[BV97、BV98、BV98a]。 この規制はパフォーマンスEnhancing Proxies(PEPs)[RFC3135]の上の情報のドキュメントで緩和されます。 ネットワークの特性が劇的に変化する境界にPEPsを置くことができるので、PEPsには、リンクの上の非修正の誤りによる性能を向上させる追加の機会があります。

   However, generalized use of PEPs contravenes the end-to-end principle
   and is highly undesirable given their deleterious implications, which
   include the following: lack of fate sharing (a PEP adds a third point
   of failure besides the endpoints themselves), end-to-end reliability
   and diagnostics, preventing end-to-end security (particularly network
   layer security such as IPsec), mobility (handoffs are much more
   complex because state must be transferred), asymmetric routing (PEPs
   typically require being on both the forward and reverse paths of a
   connection), scalability (PEPs add more state to maintain), QoS
   transparency and guarantees.

しかしながら、PEPsの一般化された使用は、終わりから終わりへの原則に違反して、以下を含んでいる彼らの有害な含意を考えて、非常に望ましくありません: 運命共有(PEPは終点自体以外に失敗の3番目のポイントを加える)、終わりから終わりへの信頼性、および病気の特徴の不足、終わりから終わりへのセキュリティ(特にIPsecなどのネットワーク層セキュリティ)を防ぐ、移動性(handoffsは状態を移さなければならないので、はるかに複雑である)、非対称のルーティング(PEPsは、接続の両方の前進の、そして、逆の経路にあるのを通常必要とする)、スケーラビリティ(PEPsは維持するより多くの状態を加える)、QoS透明、および保証。

   Not every type of PEP has all the drawbacks listed above.
   Nevertheless, the use of PEPs may have very serious consequences
   which must be weighed carefully.

PEPのすべてのタイプには、上に記載されたすべての欠点があるというわけではありません。 それにもかかわらず、PEPsの使用には、慎重に重さがなければならない非常に重大な結果があるかもしれません。

1.3 Relationship of this recommendation to Link Layer Mechanisms

1.3 Link Layer Mechanismsへのこの推薦の関係

   This recommendation is for use with TCP over subnetwork technologies
   (link layers) that have already been deployed.  Subnetworks that are
   intended to carry Internet protocols, but have not been completely
   specified are the subject of a best common practices (BCP) document
   which has been developed or is under development by the Performance

既に配備されたサブネットワーク技術(リンクレイヤ)の上のTCPと共にこの推薦は使用のためのものです。 インターネットプロトコルを運ぶことを意図するのにもかかわらずの、完全に指定されているのが、開発された(BCP)が記録する中で最も良い一般的な習慣の対象であるということでないかパフォーマンスで開発中であるサブネットワーク

Dawkins, et al.          Best Current Practice                  [Page 4]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[4ページ]RFC3155PILC--誤り2001年8月とのリンク

   Implications of Link Characteristics WG (PILC) [PILC-WEB].  This last
   document is aimed at designers who still have the opportunity to
   reduce the number of uncorrected errors TCP will encounter.

リンク特性のWG(PILC)[PILC-ウェブ]の含意。 この最後のドキュメントはまだTCPが遭遇する非修正の誤りの数を減少させる機会を持っているデザイナーを対象にします。

2.0 Errors and Interactions with TCP Mechanisms

2.0 TCPメカニズムとの誤りと相互作用

   A TCP sender adapts its use of network path capacity based on
   feedback from the TCP receiver.  As TCP is not able to distinguish
   between losses due to congestion and losses due to uncorrected
   errors, it is not able to accurately determine available path
   capacity in the presence of significant uncorrected errors.

TCP送付者はTCP受信機からフィードバックに基づくネットワーク経路容量の使用を適合させます。TCPが非修正の誤りのため混雑による損失と損失を見分けることができないように、それは重要な非修正の誤りがあるとき正確に有効な経路容量を測定できません。

2.1 Slow Start and Congestion Avoidance [RFC2581]

2.1 遅れた出発と輻輳回避[RFC2581]

   Slow Start and Congestion Avoidance [RFC2581] are essential to the
   current stability of the Internet.  These mechanisms were designed to
   accommodate networks that do not provide explicit congestion
   notification.  Although experimental mechanisms such as [RFC2481] are
   moving in the direction of explicit congestion notification, the
   effect of ECN on ECN-aware TCPs is essentially the same as the effect
   of implicit congestion notification through congestion-related loss,
   except that ECN provides this notification before packets are lost,
   and must then be retransmitted.

遅いStartとCongestion Avoidance[RFC2581]はインターネットの現在の安定性に不可欠です。 これらのメカニズムは、明白な混雑通知を提供しないネットワークに対応するように設計されました。 [RFC2481]などの実験メカニズムは動いていますが、明白な混雑通知、パケットが無くなって、そしてときに無くならなければならない前の電子証券取引ネットワーク意識することへの電子証券取引ネットワークがこの通知を提供するのを除いて、TCPsが混雑関連の損失による暗黙の混雑通知の効果と本質的には同じであることを電子証券取引ネットワークの効果の向きに、再送されてください。

   TCP connections experiencing high error rates on their paths interact
   badly with Slow Start and with Congestion Avoidance, because high
   error rates make the interpretation of losses ambiguous - the sender
   cannot know whether detected losses are due to congestion or to data
   corruption.  TCP makes the "safe" choice and assumes that the losses
   are due to congestion.

それらの経路の高い誤り率を経験するTCP接続がSlow StartとCongestion Avoidanceと共にひどく相互作用します、損失の解釈が高い誤り率であいまいになるので--送付者は、混雑かデータの汚染に検出された損失があるかを知ることができません。 TCPは、「安全な」選択をして、損失が混雑のためであると仮定します。

      -  Whenever sending TCPs receive three out-of-order
         acknowledgement, they assume the network is mildly congested
         and invoke fast retransmit/fast recovery (described below).

- 送付TCPsが3の不適切な承認を受けて、彼らが、ネットワークが穏やかに断食を充血して、呼び出すことであると仮定するときはいつも、/速い回復(以下で、説明される)を再送してください。

      -  Whenever TCP's retransmission timer expires, the sender assumes
         that the network is congested and invokes slow start.

- TCPの再送信タイマーが期限が切れるときはいつも、送付者は、ネットワークが混雑していると仮定して、遅れた出発を呼び出します。

      -  Less-reliable link layers often use small link MTUs.  This
         slows the rate of increase in the sender's window size during
         slow start, because the sender's window is increased in units
         of segments.  Small link MTUs alone don't improve reliability.
         Path MTU discovery [RFC1191] must also be used to prevent
         fragmentation.  Path MTU discovery allows the most rapid
         opening of the sender's window size during slow start, but a
         number of round trips may still be required to open the window
         completely.

- それほど信頼できないリンクレイヤはしばしば小さいリンクMTUsを使用します。 これは遅れた出発の間、送付者のウィンドウサイズにおける上昇率を遅くします、送付者の窓がユニットのセグメントで増加するので。 小さいリンクMTUsだけが信頼性を改良しません。 また、断片化を防ぐのに、経路MTU探索[RFC1191]を使用しなければなりません。 経路MTU探索は遅れた出発の間送付者のウィンドウサイズの最も急速な始まりを許容しますが、多くの周遊旅行が、窓を完全に開けるのにまだ必要であるかもしれません。

Dawkins, et al.          Best Current Practice                  [Page 5]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[5ページ]RFC3155PILC--誤り2001年8月とのリンク

   Recommendation: Any standards-conformant TCP will implement Slow
   Start and Congestion Avoidance, which are MUSTs in STD 3 [RFC1122].
   Recommendations in this document will not interfere with these
   mechanisms.

推薦: どんな規格-conformant TCPもSlow StartとCongestion Avoidanceを実行するでしょう。(Congestion AvoidanceはSTD3[RFC1122]のMUSTsです)。 推薦は本書ではこれらのメカニズムを妨げないでしょう。

2.2 Fast Retransmit and Fast Recovery [RFC2581]

断食が再送する2.2と速い回復[RFC2581]

   TCP provides reliable delivery of data as a byte-stream to an
   application, so that when a segment is lost (whether due to either
   congestion or transmission loss), the receiver TCP implementation
   must wait to deliver data to the receiving application until the
   missing data is received.  The receiver TCP implementation detects
   missing segments by segments arriving with out-of-order sequence
   numbers.

TCPはバイト・ストリームとしてデータの信頼できる配信をアプリケーションに提供します、セグメントが無くなるとき(混雑か動作減衰量にかかわらず)、受信機TCP実現が、欠測値が受信されるまで受信アプリケーションにデータを送るのを待たなければならないように。 不適切な一連番号と共に到着するセグメントでセグメントを逃すTCP実現が検出する受信機。

   TCPs should immediately send an acknowledgement when data is received
   out-of-order [RFC2581], providing the next expected sequence number
   with no delay, so that the sender can retransmit the required data as
   quickly as possible and the receiver can resume delivery of data to
   the receiving application.  When an acknowledgement carries the same
   expected sequence number as an acknowledgement that has already been
   sent for the last in-order segment received, these acknowledgement
   are called "duplicate ACKs".

TCPsはすぐに故障していた状態で[RFC2581]データが受信されているときの承認を送るはずです、次の予想された一連番号に遅れを全く提供しないで、送付者ができるだけはやく必要なデータを再送できて、受信機がデータの配送を受信アプリケーションに再開できるように。 承認が既に注文された承認と同じ予想された一連番号を運ぶとき、オーダーにおける受け取られた最後のセグメント、これらの承認は「写しACKs」と呼ばれます。

   Because IP networks are allowed to reorder packets, the receiver may
   send duplicate acknowledgments for segments that arrive out of order
   due to routing changes, link-level retransmission, etc.  When a TCP
   sender receives three duplicate ACKs, fast retransmit [RFC2581]
   allows it to infer that a segment was lost.  The sender retransmits
   what it considers to be this lost segment without waiting for the
   full retransmission timeout, thus saving time.

IPネットワークが追加注文パケットに許容されているので、受信機はルーティングによる変化、リンク平らな「再-トランスミッション」などをセグメントのための故障していた状態で到着する写し承認に送るかもしれません。 [RFC2581]は、TCP送付者がいつ3を受け取るかがACKsをコピーするのを速く再送します。セグメントが失われたと推論するのを許容します。 完全な再送タイムアウトを待たないで、送付者はそれがこの無くなっているセグメントであると考えるものを再送します、その結果、時間を節約します。

   After a fast retransmit, a sender halves its congestion window and
   invokes the fast recovery [RFC2581] algorithm, whereby it invokes
   congestion avoidance from a halved congestion window, but does not
   invoke slow start from a one-segment congestion window as it would do
   after a retransmission timeout.  As the sender is still receiving
   dupacks, it knows the receiver is receiving packets sent, so the full
   reduction after a timeout when no communication has been received is
   not called for.  This relatively safe optimization also saves time.

断食が再送された後に、送付者は、半分にされた混雑ウィンドウから混雑ウィンドウを半分にして、速い回復[RFC2581]アルゴリズムを呼び出しますが、それが再送タイムアウトの後に大丈夫であるように1セグメントの混雑ウィンドウから遅れた出発は呼び出しません。(それはアルゴリズムで輻輳回避を呼び出します)。 送付者がまだdupacksを受け取っているとき、受信機が送られたパケットを受けているのを知っているので、コミュニケーションを全く受け取っていないとき、タイムアウトの後の完全な減少を求めません。 また、この比較的安全な最適化は時間を節約します。

   It is important to be realistic about the maximum throughput that TCP
   can have over a connection that traverses a high error-rate link.  In
   general, TCP will increase its congestion window beyond the delay-
   bandwidth product.  TCP's congestion avoidance strategy is additive-
   increase, multiplicative-decrease, which means that if additional
   errors are encountered before the congestion window recovers
   completely from a 50-percent reduction, the effect can be a "downward

TCPが高い誤り率リンクを横断する接続の上に持つことができる最大のスループットに関して現実的であるのは重要です。 一般に、TCPは遅れ帯域幅生成物を超えて混雑ウィンドウを増加させるでしょう。 TCPの混雑回避方略は添加物増加、混雑ウィンドウが50パーセントの減少から全快する前に追加誤りが遭遇するなら、効果が「下向き」であることができると意味する乗法的な減少です。

Dawkins, et al.          Best Current Practice                  [Page 6]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[6ページ]RFC3155PILC--誤り2001年8月とのリンク

   spiral" of the congestion window due to additional 50-percent
   reductions.  Even using Fast Retransmit/Fast Recovery, the sender
   will halve the congestion window each time a window contains one or
   more segments that are lost, and will re-open the window by one
   additional segment for each congestion window's worth of
   acknowledgement received.

追加50パーセントの減少による混雑ウィンドウの「らせん。」 Fast Retransmit/速いRecoveryを使用さえして、送付者は、窓が1つ以上の無くなっているセグメントを含んでいるたびに混雑ウィンドウを半分にして、それぞれの混雑ウィンドウの承認の価値のための追加セグメントが受け取った1時までに窓を再び開けるでしょう。

   If a connection's path traverses a link that loses one or more
   segments during this recovery period, the one-half reduction takes
   place again, this time on a reduced congestion window - and this
   downward spiral will continue to hold the congestion window below
   path capacity until the connection is able to recover completely by
   additive increase without experiencing loss.

接続の経路がリンクを横断するなら、それはこの回復の期間、1つ以上のセグメントを失います、そして、半分減少は再び、今回減少している混雑ウィンドウの上に起こります、そして、この大幅下落は接続が付加的な増加で損失を経験しないで全快できるまで経路容量より下で混雑ウィンドウを持ち続けるでしょう。

   Of course, no downward spiral occurs if the error rate is constantly
   high and the congestion window always remains small; the
   multiplicative-increase "slow start" will be exited early, and the
   congestion window remains low for the duration of the TCP connection.
   In links with high error rates, the TCP window may remain rather
   small for long periods of time.

もちろん、誤り率が絶えず高いなら、大幅下落は全く起こりません、そして、混雑ウィンドウはいつも小さいままで残っています。 乗法的な増加「遅れた出発」は早く出られるでしょう、そして、混雑ウィンドウはTCP接続の持続時間に低いままで残っています。 高い誤り率とのリンクでは、TCPの窓は長期間の間、かなり小さいままで残るかもしれません。

   Not all causes of small windows are related to errors.  For example,
   HTTP/1.0 commonly closes TCP connections to indicate boundaries
   between requested resources.  This means that these applications are
   constantly closing "trained" TCP connections and opening "untrained"
   TCP connections which will execute slow start, beginning with one or
   two segments.  This can happen even with HTTP/1.1, if webmasters
   configure their HTTP/1.1 servers to close connections instead of
   waiting to see if the connection will be useful again.

小さい窓のすべての原因が誤りに関連するというわけではありません。 例えば、HTTP/1.0は、要求されたリソースの間の境界を示すために一般的にTCP接続を終えます。 これらのアプリケーションが絶えず閉じているこの手段はTCP接続と遅れた出発を実行する初めの「未熟な」TCP接続を「訓練しました」、1か2つのセグメントで始まって。 これはHTTP/1.1があっても起こることができます、ウェブマスターが接続が再び役に立つかどうかを見るのを待つことの代わりに接続を終えるために彼らのHTTP/1.1のサーバを構成するなら。

   A small window - especially a window of less than four segments -
   effectively prevents the sender from taking advantage of Fast
   Retransmits.  Moreover, efficient recovery from multiple losses
   within a single window requires adoption of new proposals (NewReno
   [RFC2582]).

事実上、小さい窓(特に4つ未満のセグメントの窓)は、送付者がFast Retransmitsを利用するのを防ぎます。 そのうえ、単一の窓の中の複数の損失からの効率的な回復は新規案件(NewReno[RFC2582])の採用を必要とします。

   Recommendation: Implement Fast Retransmit and Fast Recovery at this
   time.  This is a widely-implemented optimization and is currently at
   Proposed Standard level.  [RFC2488] recommends implementation of Fast
   Retransmit/Fast Recovery in satellite environments.

推薦: このとき、Fast RetransmitとFast Recoveryを実行してください。 これは、広く実行された最適化であり、現在、Proposed Standardレベルにあります。 [RFC2488]は衛星環境における、Fast Retransmit/速いRecoveryの実現を推薦します。

2.3 Selective Acknowledgements [RFC2018, RFC2883]

2.3 選択している承認[RFC2018、RFC2883]

   Selective Acknowledgements [RFC2018] allow the repair of multiple
   segment losses per window without requiring one (or more) round-trips
   per loss.

1損失あたり1つ(さらに)の周遊旅行を必要としないで、選択しているAcknowledgements[RFC2018]は複数の1窓あたりのセグメントの損失の修理を許します。

Dawkins, et al.          Best Current Practice                  [Page 7]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[7ページ]RFC3155PILC--誤り2001年8月とのリンク

   [RFC2883] proposes a minor extension to SACK that allows receiving
   TCPs to provide more information about the order of delivery of
   segments, allowing "more robust operation in an environment of
   reordered packets, ACK loss, packet replication, and/or early
   retransmit timeouts".  Unless explicitly stated otherwise, in this
   document, "Selective Acknowledgements" (or "SACK") refers to the
   combination of [RFC2018] and [RFC2883].

[RFC2883]はセグメントの配送の注文に関する詳しい情報を提供するためにTCPsを受けさせるSACKに小さい方の拡大を提案して、許容は「再命令されたパケットの環境における、より体力を要している操作、パケット模写の、そして/または、早いACKの損失はタイムアウトを再送します」です。 別の方法で明らかに述べられない場合、本書では、「選択している承認」(または、「袋」)は[RFC2018]と[RFC2883]の組み合わせを示します。

   Selective acknowledgments are most useful in LFNs ("Long Fat
   Networks") because of the long round trip times that may be
   encountered in these environments, according to Section 1.1 of
   [RFC1323], and are especially useful if large windows are required,
   because there is a higher probability of multiple segment losses per
   window.

選択している承認は、[RFC1323]のセクション1.1によると、これらの環境で遭遇するかもしれない長い周遊旅行時間のためにLFNs(「長い太っているネットワーク」)で最も役に立って、大きい窓が必要であるなら、特に役に立ちます、複数の1窓あたりのセグメントの損失の、より高い確率があるので。

   On the other hand, if error rates are generally low but occasionally
   higher due to channel conditions, TCP will have the opportunity to
   increase its window to larger values during periods of improved
   channel conditions between bursts of errors.  When bursts of errors
   occur, multiple losses within a window are likely to occur.  In this
   case, SACK would provide benefits in speeding the recovery and
   preventing unnecessary reduction of the window size.

他方では、誤り率が一般に低いのですが、チャンネル状態のために時折より高いなら、TCPは改良されたチャンネル状態の期間、誤りの炸裂の間により大きい値に窓を増加させる機会を持つでしょう。 誤りの炸裂が起こるとき、窓の中の複数の損失が起こりそうです。 この場合、SACKは回復を促進して、ウィンドウサイズの不要な減少を防ぐのに利益を提供するでしょう。

   Recommendation: Implement SACK as specified in [RFC2018] and updated
   by [RFC2883], both Proposed Standards.  In cases where SACK cannot be
   enabled for both sides of a connection, TCP senders may use NewReno
   [RFC2582] to better handle partial ACKs and multiple losses within a
   single window.

推薦: [RFC2018]で指定されて、[RFC2883]、両方のProposed StandardsによってアップデートされるようにSACKを実行してください。 SACKを接続の両側に有効にすることができない場合では、TCP送付者は、単一の窓の中の部分的なACKsと複数の損失をよりよく扱うのに、NewReno[RFC2582]を使用するかもしれません。

3.0 Summary of Recommendations

3.0 推薦の概要

   The Internet does not provide a widely-available loss feedback
   mechanism that allows TCP to distinguish between congestion loss and
   transmission error.  Because congestion affects all traffic on a path
   while transmission loss affects only the specific traffic
   encountering uncorrected errors, avoiding congestion has to take
   precedence over quickly repairing transmission errors.  This means
   that the best that can be achieved without new feedback mechanisms is
   minimizing the amount of time that is spent unnecessarily in
   congestion avoidance.

インターネットはTCPが混雑の損失と伝送エラーを見分けることができる広く利用可能な損失フィードバック・メカニズムを提供しません。 動作減衰量が特定の交通だけに影響しますが、混雑が非修正の誤りに遭遇しながら経路ですべての交通に影響するので、すぐに伝送エラーを修理する上で混雑を避けるのは優先しなければなりません。 これは、新しいフィードバック・メカニズムなしで達成できるベストが不必要に輻輳回避に費やされる時間を最小にしていることを意味します。

   The Fast Retransmit/Fast Recovery mechanism allows quick repair of
   loss without giving up the safety of congestion avoidance.  In order
   for Fast Retransmit/Fast Recovery to work, the window size must be
   large enough to force the receiver to send three duplicate
   acknowledgments before the retransmission timeout interval expires,
   forcing full TCP slow-start.

輻輳回避の安全をあきらめないで、Fast Retransmit/速いRecoveryメカニズムは損失の迅速な修理を許します。 Fast Retransmit/速いRecoveryが扱って、ウィンドウサイズは再送タイムアウト間隔が期限が切れる前に受信機に3つの写し承認を送らせることができるくらい大きくなければなりません、完全なTCP遅れた出発を強制して。

Dawkins, et al.          Best Current Practice                  [Page 8]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[8ページ]RFC3155PILC--誤り2001年8月とのリンク

   Selective Acknowledgements (SACK) extend the benefit of Fast
   Retransmit/Fast Recovery to situations where multiple segment losses
   in the window need to be repaired more quickly than can be
   accomplished by executing Fast Retransmit for each segment loss, only
   to discover the next segment loss.

選択しているAcknowledgements(SACK)はそれぞれのセグメントの損失でFast Retransmitを実行することによって次のセグメントの損失を発見する達成できるより窓の複数のセグメントの損失がさらにはやく修理される必要がある状況へのFast Retransmit/速いRecoveryの利益を広げています。

   These mechanisms are not limited to wireless environments.  They are
   usable in all environments.

これらのメカニズムは無線の環境に制限されません。 それらはすべての環境で使用可能です。

4.0 Topics For Further Work

4.0 さらなる仕事のための話題

   "Limited Transmit" [RFC3042] has been specified as an optimization
   extending Fast Retransmit/Fast Recovery for TCP connections with
   small congestion windows that will not trigger three duplicate
   acknowledgments.  This specification is deemed safe, and it also
   provides benefits for TCP connections that experience a large amount
   of packet (data or ACK) loss.  Implementors should evaluate this
   standards track specification for TCP in loss environments.

「株式会社Transmit」[RFC3042]は3つの写し承認の引き金とならない小さい混雑ウィンドウとのTCP接続のためにFast Retransmit/速いRecoveryを広げる最適化として指定されました。 この仕様は安全であると考えられます、そして、また、それは多量のパケット(データかACK)の損失を経験するTCP接続に利益を提供します。 作成者は損失環境でTCPのためのこの標準化過程仕様を評価するべきです。

   Delayed Duplicate Acknowledgements [MV97, VMPM99] attempts to prevent
   TCP-level retransmission when link-level retransmission is still in
   progress, adding additional traffic to the network.  This proposal is
   worthy of additional study, but is not recommended at this time,
   because we don't know how to calculate appropriate amounts of delay
   for an arbitrary network topology.

遅れたDuplicate Acknowledgements[MV97、VMPM99]は、リンク・レベル「再-トランスミッション」がまだ進行しているとき、TCP-レベル「再-トランスミッション」を防ぐのを試みます、追加交通をネットワークに追加して。 この提案は、追加研究にふさわしいのですが、このとき推薦されません、私たちが任意のネットワーク形態のために適切な量の遅れについて計算する方法を知らないので。

   It is not possible to use explicit congestion notification [RFC2481]
   as a surrogate for explicit transmission error notification (no
   matter how much we wish it was!).  Some mechanism to provide explicit
   notification of transmission error would be very helpful.  This might
   be more easily provided in a PEP environment, especially when the PEP
   is the "first hop" in a connection path, because current checksum
   mechanisms do not distinguish between transmission error to a payload
   and transmission error to the header.  Furthermore, if the header is
   damaged, sending explicit transmission error notification to the
   right endpoint is problematic.

明白な伝送エラー通知に、代理として明白な混雑通知[RFC2481]を使用するのは可能ではありません(私たちが、それがどんなに多くであることを願ったとしても!)。 伝送エラーの明白な通知を提供する何らかのメカニズムが非常に役立っているでしょう。 より容易にPEP環境にこれを提供するかもしれません、特にPEPが接続道の「最初のホップ」であるときに、現在のチェックサムメカニズムがヘッダーへのペイロードと伝送エラーに見分けないので伝送エラーを。 その上、ヘッダーが破損しているなら、明白な伝送エラー通知を正しい終点に送るのは問題が多いです。

   Losses that take place on the ACK stream, especially while a TCP is
   learning network characteristics, can make the data stream quite
   bursty (resulting in losses on the data stream, as well).  Several
   ways of limiting this burstiness have been proposed, including TCP
   transmit pacing at the sender and ACK rate control within the
   network.

TCPが特にネットワークの特性を学んでいる間にACKの流れのときに起こる損失はデータ・ストリームを全くbursty(データ・ストリームのときに損失をもたらしますまた、)にすることができます。 このburstinessを制限するいくつかの方法が提案されて、TCPが伝える送付者を歩き回る包含とACKはネットワークの中でコントロールを評定します。

   "Appropriate Byte Counting" (ABC) [ALL99], has been proposed as a way
   of opening the congestion window based on the number of bytes that
   have been successfully transfered to the receiver, giving more
   appropriate behavior for application protocols that initiate

「適切なByte Counting」(ABC)[ALL99]は首尾よく受信機にtransferedされたバイト数に基づく混雑ウィンドウを開ける方法として提案されました、アプリケーション・プロトコルのための、より適切な振舞いにその開始を与えて

Dawkins, et al.          Best Current Practice                  [Page 9]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[9ページ]RFC3155PILC--誤り2001年8月とのリンク

   connections with relatively short packets.  For SMTP [RFC2821], for
   instance, the client might send a short HELO packet, a short MAIL
   packet, one or more short RCPT packets, and a short DATA packet -
   followed by the entire mail body sent as maximum-length packets.  An
   ABC TCP sender would not use ACKs for each of these short packets to
   increase the congestion window to allow additional full-length
   packets.  ABC is worthy of additional study, but is not recommended
   at this time, because ABC can lead to increased burstiness when
   acknowledgments are lost.

比較的脆いパケットとの接続。 例えば、SMTP[RFC2821]に関しては、クライアントは脆いHELOパケット、脆いメールパケット、1つ以上以上少ないRCPTパケット、および脆いDATAパケットを送るかもしれません--最大の長さのパケットとして送られた全体のメール本文はあとに続いています。 それぞれのこれらの脆いパケットが追加等身大のパケットを許容するために混雑ウィンドウを増加させるのにABC TCP送付者はACKsを使用しないでしょう。 ABCは追加研究にふさわしいのですが、このとき推薦されません、承認が無くなるとき、ABCが増加するburstinessに通じることができるので。

4.1 Achieving, and maintaining, large windows

4.1 大きい窓を達成して、維持すること。

   The recommendations described in this document will aid TCPs in
   injecting packets into ERRORed connections as fast as possible
   without destabilizing the Internet, and so optimizing the use of
   available bandwidth.

本書では説明された推薦はできるだけ接続で速くインターネットを動揺させないでERRORedにパケットを注ぐので利用可能な帯域幅の使用を最適化する際にTCPsを支援するでしょう。

   In addition to these TCP-level recommendations, there is still
   additional work to do at the application level, especially with the
   dominant application protocol on the World Wide Web, HTTP.

これらのTCP-レベル推薦に加えて、アプリケーションレベルでしなければならない追加仕事がまだあります、特に優位なアプリケーション・プロトコルがWWWにある状態で、HTTP。

   HTTP/1.0 (and earlier versions) closes TCP connections to signal a
   receiver that all of a requested resource had been transmitted.
   Because WWW objects tend to be small in size [MOGUL], TCPs carrying
   HTTP/1.0 traffic experience difficulty in "training" on available
   path capacity (a substantial portion of the transfer has already
   happened by the time TCP exits slow start).

HTTP/1.0(そして、以前のバージョン)は、要求されたリソースのすべてが伝えられたと受信機に合図するためにTCP接続を終えます。 WWW物が、サイズ[ムガール人]が小さい傾向があるので、HTTP/1.0交通を運ぶTCPsが有効な経路容量の「トレーニング」における苦境に陥ります(TCPが遅れた出発を出る時までに転送のかなりの部分が既に起こりました)。

   Several HTTP modifications have been introduced to improve this
   interaction with TCP ("persistent connections" in HTTP/1.0, with
   improvements in HTTP/1.1 [RFC2616]).  For a variety of reasons, many
   HTTP interactions are still HTTP/1.0-style - relatively short-lived.

TCP(HTTP/1.1[RFC2616]における改良を伴うHTTP/1.0における「パーシステントコネクション」)とのこの相互作用を改良するためにいくつかのHTTP変更を導入しました。 さまざまな理由で、それでも、多くのHTTP相互作用が1.0HTTP/スタイルです--比較的短命です。

   Proposals which reuse TCP congestion information across connections,
   like TCP Control Block Interdependence [RFC2140], or the more recent
   Congestion Manager [BS00] proposal, will have the effect of making
   multiple parallel connections impact the network as if they were a
   single connection, "trained" after a single startup transient.  These
   proposals are critical to the long-term stability of the Internet,
   because today's users always have the choice of clicking on the
   "reload" button in their browsers and cutting off TCP's exponential
   backoff - replacing connections which are building knowledge of the
   available bandwidth with connections with no knowledge at all.

TCP Control Block Interdependence[RFC2140]、または、より最近のCongestionマネージャ[BS00]提案には複数の並列接続をまるで彼らが単独結合であるかのようにネットワークに影響を与えさせるという効果があるように接続の向こう側にTCP混雑情報を再利用する提案がただ一つの始動の後に一時的な状態で「訓練されました」。 これらの提案はインターネットの長期の安定性に重要です、今日のユーザには接続と共に全く知識なしで利用可能な帯域幅に関する知識を築き上げている接続を取り替えて、彼らのブラウザで「再び荷を積む」ボタンをクリックして、TCPの指数のbackoffを断ち切ることの選択がいつもあるので。

Dawkins, et al.          Best Current Practice                 [Page 10]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[10ページ]RFC3155PILC--誤り2001年8月とのリンク

5.0 Security Considerations

5.0 セキュリティ問題

   A potential vulnerability introduced by Fast Retransmit/Fast Recovery
   is (as pointed out in [RFC2581]) that an attacker may force TCP
   connections to grind to a halt, or, more dangerously, behave more
   aggressively.  The latter possibility may lead to congestion
   collapse, at least in some regions of the network.

Fast Retransmit/速いRecoveryによって導入された潜在的脆弱性はこと([RFC2581]で指摘されるように)です。攻撃者は、TCP接続をゆっくり止まらせるか、または、より危険により積極的に振る舞うかもしれません。 後者の可能性は少なくともネットワークのいくつかの領域での混雑崩壊に通じるかもしれません。

   Selective acknowledgments is believed to neither strengthen nor
   weaken TCP's current security properties [RFC2018].

TCPの現在のセキュリティの特性[RFC2018]を強化でない、また選択している承認が弱めないと信じられています。

   Given that the recommendations in this document are performed on an
   end-to-end basis, they continue working even in the presence of end-
   to-end IPsec.  This is in direct contrast with mechanisms such as
   PEP's which are implemented in intermediate nodes (section 1.2).

推薦が本書では終わりから終わりへのベースに実行されるなら、それらは、終わりまでの終わりのIPsecの面前でさえ働き続けています。 これは中間的ノード(セクション1.2)で実行されるPEPのものなどのメカニズムに対するダイレクト対照中です。

6.0 IANA Considerations

6.0 IANA問題

   This document is a pointer to other, existing IETF standards.  There
   are no new IANA considerations.

このドキュメントは他の、そして、既存のIETF規格へのポインタです。 どんな新しいIANA問題もありません。

7.0 Acknowledgements

7.0 承認

   This recommendation has grown out of RFC 2757, "Long Thin Networks",
   which was in turn based on work done in the IETF TCPSAT working
   group.  The authors are indebted to the active members of the PILC
   working group.  In particular, Mark Allman and Lloyd Wood gave us
   copious and insightful feedback, and Dan Grossman and Jamshid Mahdavi
   provided text replacements.

RFC2757、「長い薄いネットワーク」からこの推薦は成長しました。(順番に、それは、IETF TCPSATワーキンググループで行われた仕事に基づきました)。 作者はPILCワーキンググループの活動的なメンバーの世話になっています。 特に、マーク・オールマンとロイドWoodは豊富で洞察に満ちたなフィードバックを私たちに与えました、そして、ダン・グロースマンとJamshid Mahdaviはテキスト交換品を提供しました。

References

参照

   [ALL99]    M. Allman, "TCP Byte Counting Refinements," ACM Computer
              Communication Review, Volume 29, Number 3, July 1999.
              http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-
              99.html

[ALL99]M.オールマン、「TCPバイト勘定気品」、ACMコンピュータコミュニケーションレビュー、第29巻、No.3、7月1999日の http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc- 99.html

   [BS00]     Balakrishnan, H. and S. Seshan, "The Congestion Manager",
              RFC 3124, June 2001.

[BS00]BalakrishnanとH.とS.Seshan、「混雑マネージャ」(RFC3124)2001年6月。

   [BV97]     S. Biaz and N. Vaidya, "Using End-to-end Statistics to
              Distinguish Congestion and Corruption Losses: A Negative
              Result," Texas A&M University, Technical Report 97-009,
              August 18, 1997.

[BV97] S.BiazとN.Vaidya、「混雑と不正損失を区別するために統計を終わりに終わらせて、使用してください」 「否定的結果」、テキサスA&M大学、技術報告書97-009、1997年8月18日。

Dawkins, et al.          Best Current Practice                 [Page 11]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[11ページ]RFC3155PILC--誤り2001年8月とのリンク

   [BV98]     S. Biaz and N. Vaidya, "Sender-Based heuristics for
              Distinguishing Congestion Losses from Wireless
              Transmission Losses," Texas A&M University, Technical
              Report 98-013, June 1998.

[BV98] S.BiazとN.Vaidya、「Wireless Transmission LossesからのDistinguishing Congestion Lossesのためのベースの送付者発見的教授法」、テキサスA&M大学、Technical Report98-013(1998年6月)。

   [BV98a]    S. Biaz and N. Vaidya, "Discriminating Congestion Losses
              from Wireless Losses using Inter-Arrival Times at the
              Receiver," Texas A&M University, Technical Report 98-014,
              June 1998.

[BV98a] S.BiazとN.Vaidya、「無線の損失と受信機への相互到着時間を使用することで混雑の損失を区別します」、テキサスA&M大学、技術報告書98-014(1998年6月)。

   [MOGUL]    "The Case for Persistent-Connection HTTP", J. C. Mogul,
              Research Report 95/4, May 1995. Available as
              http://www.research.digital.com/wrl/techreports/abstracts/
              95.4.html

[ムガール人] 「パーシステントコネクションHTTPのためのケース」(J.C.ムガール人、研究レポート95/4)は1995がそうするかもしれません。 http://www.research.digital.com/wrl/techreports/abstracts/ 95.4.htmlとして、利用可能です。

   [MV97]     M. Mehta and N. Vaidya, "Delayed Duplicate-
              Acknowledgements:  A Proposal to Improve Performance of
              TCP on Wireless Links," Texas A&M University, December 24,
              1997.  Available at
              http://www.cs.tamu.edu/faculty/vaidya/mobile.html

[MV97] M.メータとN.Vaidya、「遅らせられて、承認をコピーしてください」 「無線電信におけるTCPの性能を向上させるという提案はリンクする」テキサスA&M大学、1997年12月24日。 http://www.cs.tamu.edu/faculty/vaidya/mobile.html では、利用可能です。

   [PILC-WEB] http://pilc.grc.nasa.gov/

[PILC-ウェブ] http://pilc.grc.nasa.gov/

   [PFTK98]   Padhye, J., Firoiu, V., Towsley, D. and J.Kurose, "TCP
              Throughput: A simple model and its empirical validation",
              SIGCOMM Symposium on Communications Architectures and
              Protocols, August 1998.

[PFTK98] Padhye、J.、Firoiu、V.、Towsley、D.、およびJ.黒瀬、「TCPスループット:」 「単純モデルとその実証的な合法化」、Communications ArchitecturesとプロトコルのSIGCOMM Symposium、8月1998

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

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

   [RFC2821]  Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC
              2821, April 2001.

[RFC2821] Klensin、J.、エディタ、「簡単なメール転送プロトコル」、RFC2821、2001年4月。

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

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

   [RFC1191]  Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
              November 1990.

[RFC1191] ムガール人J.、およびS.デアリング、「経路MTU発見」、RFC1191、1990年11月。

   [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がそうするかもしれません。

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

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

   [RFC2140]  Touch, J., "TCP Control Block Interdependence", RFC 2140,
              April 1997.

[RFC2140] 接触、J.、「TCP制御ブロック相互依存」、RFC2140、1997年4月。

Dawkins, et al.          Best Current Practice                 [Page 12]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[12ページ]RFC3155PILC--誤り2001年8月とのリンク

   [RFC2309]  Braden, B., Clark, D., Crowcrfot, J., Davie, B., Deering,
              S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
              Partridge, C., Peterson, L., Ramakrishnan, K., Shecker,
              S., Wroclawski, J. and L, Zhang, "Recommendations on Queue
              Management and Congestion Avoidance in the Internet", RFC
              2309, April 1998.

[RFC2309]ブレーデン、B.、クラーク、D.、Crowcrfot、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ジェーコブソン、V.、Minshall、G.、ヤマウズラ、C.、ピーターソン、L.、Ramakrishnan、K.、Shecker、S.、Wroclawski、J.、およびL、チャン、「インターネットの待ち行列管理と輻輳回避の推薦」、RFC2309(1998年4月)。

   [RFC2481]  Ramakrishnan K. and S. Floyd, "A Proposal to add Explicit
              Congestion Notification (ECN) to IP", RFC 2481, January
              1999.

1999年1月の[RFC2481]Ramakrishnan K.とS.フロイド、「Explicit Congestion Notification(電子証券取引ネットワーク)をIPに追加するProposal」RFC2481。

   [RFC2488]  Allman, M., Glover, D. and L. Sanchez. "Enhancing TCP Over
              Satellite Channels using Standard Mechanisms", BCP 28, RFC
              2488, January 1999.

[RFC2488] オールマン、M.、手袋製造業者、D.、およびL.サンチェス。 「衛星チャンネルの上に標準のメカニズムを使用することでTCPを高めます」、BCP28、RFC2488、1999年1月。

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

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

   [RFC2582]  Floyd, S. and T. Henderson, "The NewReno Modification to
              TCP's Fast Recovery Algorithm", RFC 2582, April 1999.

[RFC2582] フロイドとS.とT.ヘンダーソン、「TCPの速い回復アルゴリズムへのNewReno変更」、RFC2582、1999年4月。

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach P. and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチP.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。

   [RFC2861]  Handley, H., Padhye, J. and S., Floyd, "TCP Congestion
              Window Validation", RFC 2861, June 2000.

[RFC2861] ハンドレーとH.とPadhyeとJ.とS.、フロイド、「TCP混雑窓の合法化」、RFC2861、2000年6月。

   [RFC2883]  Floyd, S., Mahdavi, M., Mathis, M. and M. Podlosky, "An
              Extension to the Selective Acknowledgement (SACK) Option
              for TCP", RFC 2883, August 1999.

[RFC2883] フロイドとS.とMahdaviとM.とマシスとM.とM.Podlosky、「TCPのための選択している承認(袋)オプションへの拡大」、RFC2883、1999年8月。

   [RFC2923]  Lahey, K., "TCP Problems with Path MTU Discovery", RFC
              2923, September 2000.

[RFC2923] レーヒー、K.、「経路MTU発見に関するTCP問題」、RFC2923、2000年9月。

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

   [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
              Shelby, "Performance Enhancing Proxies Intended to
              Mitigate Link-Related Degradations", RFC 3135, June 2001.

[RFC3135]は接しています、J.、Kojo、M.、Griner、モンテネグロ、G.、およびZ.シエルビイ、J.、「パフォーマンスはリンク関連の転落を緩和することを意図するプロキシを高め」て、RFC3135、2001年6月。

   [VJ-DCAC]  Jacobson, V., "Dynamic Congestion Avoidance / Control" e-
              mail dated February 11, 1988, available from
              http://www.kohala.com/~rstevens/vanj.88feb11.txt

[VJ-DCAC]ジェーコブソン、V.、電子メールが1988年2月11日に日付を入れた http://www.kohala.com/~rstevens/vanj.88feb11.txt から利用可能な「ダイナミックな輻輳回避/コントロール」

Dawkins, et al.          Best Current Practice                 [Page 13]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[13ページ]RFC3155PILC--誤り2001年8月とのリンク

   [VMPM99]   N. Vaidya, M. Mehta, C. Perkins, and G. Montenegro,
              "Delayed Duplicate Acknowledgements: A TCP-Unaware
              Approach to Improve Performance of TCP over Wireless,"
              Technical Report 99-003, Computer Science Dept., Texas A&M
              University, February 1999. Also, to appear in Journal of
              Wireless Communications and Wireless Computing (Special
              Issue on Reliable Transport Protocols for Mobile
              Computing).

[VMPM99] N.Vaidya、M.メータ、C.パーキンス、およびG.モンテネグロ、「遅らせられて、承認をコピーしてください」 「無線電信の上でTCPの性能を向上させるTCP気づかないアプローチ」、技術報告書99-003、コンピュータサイエンス部、テキサスA&M大学(1999年2月) また、Wireless CommunicationsとWireless Computing(モバイルComputingのためのReliable Transportプロトコルの特別なIssue)のJournalに現れるように。

Authors' Addresses

作者のアドレス

   Questions about this document may be directed to:

このドキュメントに関する質問による以下のことよう指示されるかもしれません。

   Spencer Dawkins
   Fujitsu Network Communications
   2801 Telecom Parkway
   Richardson, Texas 75082

パークウェイのリチャードソン、スペンサーダウキンズ富士通ネットワークコミュニケーションズ2801電子通信テキサス 75082

   Phone: +1-972-479-3782
   EMail: spencer.dawkins@fnc.fujitsu.com

以下に電話をしてください。 +1-972-479-3782 メールしてください: spencer.dawkins@fnc.fujitsu.com

   Gabriel E. Montenegro
   Sun Microsystems
   Laboratories, Europe
   29, chemin du Vieux Chene
   38240 Meylan
   FRANCE

ガブリエルE.モンテネグロサン・マイクロシステムズ研究所、ヨーロッパ29、chemin du Vieux Chene38240メラン・フランス

   Phone: +33 476 18 80 45
   EMail: gab@sun.com

以下に電話をしてください。 +33 476 18 80 45はメールされます: gab@sun.com

   Markku Kojo
   Department of Computer Science
   University of Helsinki
   P.O. Box 26 (Teollisuuskatu 23)
   FIN-00014 HELSINKI
   Finland

ヘルシンキ私書箱26(Teollisuuskatu23)フィン-00014ヘルシンキフィンランドのマルックKojoコンピュータサイエンス学部大学

   Phone: +358-9-1914-4179
   EMail: kojo@cs.helsinki.fi

以下に電話をしてください。 +358-9-1914-4179 メールしてください: kojo@cs.helsinki.fi

Dawkins, et al.          Best Current Practice                 [Page 14]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[14ページ]RFC3155PILC--誤り2001年8月とのリンク

   Vincent Magret
   Alcatel Internetworking, Inc.
   26801 W. Agoura road
   Calabasas, CA, 91301

カラバサス、ヴィンセントMagretアルカテルInternetworking Inc.26801W.Agoura道路カリフォルニア 91301

   Phone: +1 818 878 4485
   EMail: vincent.magret@alcatel.com

以下に電話をしてください。 +1 4485年の818 878メール: vincent.magret@alcatel.com

   Nitin H. Vaidya
   458 Coodinated Science Laboratory, MC-228
   1308 West Main Street
   Urbana, IL 61801

Nitin H.Vaidya458Coodinated科学研究所、アーバナ、M.C.-228の1308の西Main Streetイリノイ 61801

   Phone: 217-265-5414
   E-mail: nhv@crhc.uiuc.edu

以下に電話をしてください。 217-265-5414 メールしてください: nhv@crhc.uiuc.edu

Dawkins, et al.          Best Current Practice                 [Page 15]

RFC 3155                PILC - Links with Errors             August 2001

ダウキンズ、他 最も良い現在の習慣[15ページ]RFC3155PILC--誤り2001年8月とのリンク

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Dawkins, et al.          Best Current Practice                 [Page 16]

ダウキンズ、他 最も良い現在の習慣[16ページ]