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
End-to-end Performance Implications of Links with Errors
Status of this 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.
著作権（C）インターネット協会（2001）。全著作権所有。
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
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輻輳制御[RFC2581]は、主に渋滞のトラフィックを失い、バッファ枯渇の接続に適しているが、未修正のエラー高い未訂正誤り率とのTCP接続トラバースリンクと悪い相互作用します。結果は、プローブとしてのこれらの損失は、輻輳に関するバッファ枯渇によるものではないもののたTCPは、次に到着しない肯定応答を待っている時間の過剰量を費やし、そしてよい送信、送信側TCPは、実質的に減少トラフィックレベルで送信することです「安全な」トラフィックレベルを決定するためのネットワーク。
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のすべての使用に適用可能です。
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.
この勧告は、ルータとホストの全体のインストールベースに大きな変化が実用可能ではないことを明示的な仮定に基づいています。これは、直接、エラーが発生したリンクの影響を受けているホストへの変更を制限します。
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]:
TCPリノ応答関数の近似式は[PFTK98]で与えられます。
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
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.
1が観測されたパケット損失率に差し込む場合は、数学を行い、その後、リンク速度よりも大きくなると予測帯域幅の使用率を見て遭遇されたパケットロスのレベルは影響しませんので、接続は、このドキュメントの推奨事項の恩恵を受けないであろうリンクを利用する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の能力を向上させます。
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）MAX（1.0、4 * RTT）はtRTOための簡略化のように置換することができます。 （3）損失がバースト的であり得る - 送信速度に対するこれらの損失事象の影響を過小評価することができる複数のバースト損失事象を含む間隔にわたって測定損失率。
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]されていません。この制限は、パフォーマンス強化プロキシ上の情報のドキュメント（のPEP）[RFC3135]に緩和されています。 PEPは、ネットワークの特性が劇的に変化する境界に配置することができますので、PEPには訂正されていないエラーが発生しているリンク上でのパフォーマンスを改善するための追加の機会を持っています。
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.
しかし、のPEPの一般使用は、エンド・ツー・エンドの原則に違反し、以下を含むそれらの有害な影響、与えられた非常に望ましくない。運命の共有の欠如を、エンド・ツー（PEPは、エンドポイント自体のほか、障害の第三の点を追加します）末端信頼性および診断、エンドツーエンドのセキュリティ（IPsecなど、特にネットワーク層セキュリティ）を予防、移動度（状態が転送されなければならないので、ハンドオフがはるかに複雑である）、非対称ルーティング（のPEPは、典型的には、順方向および逆方向の両方の上にある必要接続の経路）、スケーラビリティ（のPEPを維持するために、より多くの状態を追加する）、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のではないすべての種類は、上記のすべての欠点を有しています。それにもかかわらず、のPEPの使用は慎重に検討する必要があり、非常に深刻な結果をもたらす可能性があります。
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）ドキュメントの対象であります
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-WEB]。この最後の文書は、まだ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は輻輳し、補正誤差による損失による損失とを区別することができないように、正確に補正されていない重大なエラーの存在下での利用可能なパスの能力を決定することができません。
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.
スロースタートと輻輳回避[RFC2581]はインターネットの現在の安定に不可欠です。これらのメカニズムは、明示的輻輳通知を提供しないネットワークに対応するように設計されました。このような[RFC2481]などの実験メカニズムは明示的輻輳通知の方向に移動されているが、そのECNは、この通知を提供する以外、ECN対応のTCPに対するECNの効果は、本質的に輻輳に関する損失を介して暗黙的輻輳通知の効果と同じです前にパケットが失われ、その後、再送信する必要があります。
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接続は、スロースタートと輻輳回避とひどく対話 - 送信者が検出された損失は輻輳やデータの破損によるものであるかどうかを知ることはできません。 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).
- 送信のTCPが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.
- あまり信頼性の高いリンク層は、多くの場合、小さなリンクのMTUを使用します。送信者のウィンドウは、セグメント単位で増加しているので、これは、スロースタート時に送信者のウィンドウサイズの増加率が遅くなります。小さなリンクのMTUだけでは信頼性を向上させることはありません。パスMTU探索[RFC1191]も断片化を防ぐために使用しなければなりません。パスMTUディスカバリは、スロースタート時に送信者のウィンドウサイズの最も急速な開放を許可しますが、ラウンドトリップ数は、まだ完全にウィンドウを開くために必要な場合があります。
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.
推奨事項：任意の標準規格に準拠したTCPは、STD 3 [RFC1122]でマストである、スロースタートと輻輳回避を実装します。このドキュメントの推奨事項は、これらのメカニズムとは干渉しません。
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".
データは、アウトオブオーダー[RFC2581]を受信したときにTCPは直ちに送信者が可能な限り迅速に必要なデータを再送信することができるように、遅延なしで次の予想されるシーケンス番号を提供し、肯定応答を送信すると、受信機は、データの配信を再開することができます受信アプリケーションへ。肯定応答が既に最後に次のセグメントを受信するために送信された確認応答と同じ期待シーケンス番号を有する場合、これらの肯定応答は、「重複ACK」と呼ばれます。
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ネットワークはパケットの順序を変更することが許可されているため、受信機が原因ルーティングの変更、リンクレベルの再送信などのTCPセンダ三個の重複ACK、高速再送信を受信した場合に順序が狂って到着したセグメントの重複確認応答を送信することができる[RFC2581]は、それを可能にしますセグメントが失われたことを推測します。送信者は、それがこのように時間を節約し、完全な再送タイムアウトを待たずにセグメントを失ったことを考えるもの再送します。
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]アルゴリズムを呼び出しますが、それは後に行うようにワンセグ輻輳ウィンドウからスロースタートを起動しません再送タイムアウト。送信者がまだ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 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.
TCPが高いエラーレートのリンクを横断接続を介して持つことができる最大のスループットについて現実的にすることが重要です。一般的に、TCPは遅延と帯域幅の積を超えてその輻輳ウィンドウが増加します。 TCPの輻輳回避戦略は、輻輳ウィンドウが50％削減から完全に回復する前に、追加のエラーが発生した場合、効果が原因の追加に輻輳ウィンドウの「下方スパイラル」ことができることを意味し、添加剤の増加、乗法-の減少であり、 50％の削減。でも高速再送/高速リカバリを使用して、送信側は、輻輳ウィンドウにウィンドウが失われている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接続し、1つのまたは2つのセグメントで始まる、スロースタートを実行しますオープニング「訓練を受けていない」TCP接続を閉じていることを意味します。ウェブマスターはなく、接続が再び有用であろうかどうかを確認するために待っているの接続を閉じるように彼らの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つのセグメントの特に窓は - 効果的に高速再送信を利用することから、送信者を防ぐことができます。また、単一のウィンドウ内の複数の損失からの効率的な回復が新たな提案の採用を必要とする（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.
推奨事項：この時点では、高速再送と高速リカバリを実装します。これは、広く実装され、最適化され、現在では標準的なレベルを提案しています。 [RFC2488]は衛星環境における高速再送/高速回復の実装を推奨しています。
Selective Acknowledgements [RFC2018] allow the repair of multiple segment losses per window without requiring one (or more) round-trips per loss.
選択謝辞[RFC2018]は損失につき1つ（またはそれ以上）のラウンドトリップを必要とせずに、ウィンドウごとに複数のセグメント損失の修復を可能にします。
[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]はそれが受信のTCPが可能セグメントの配信のため、「並べ替えパケットの環境でより堅牢な動作を、ACK損失、パケットの複製、および/または早期再送タイムアウト」の詳細情報を提供することを可能にするSACKするマイナーな拡張を提案しています。特に明記しない限り、本書では、「選択謝辞」（または「SACK」）は[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（「ロングファットネットワーク」）の中で最も有用であり、大きな窓が必要な場合に、特に便利ですが理由ウィンドウごとに複数のセグメント損失の高い確率です。
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]で更新され、両方の基準案をSACKを実装します。 SACKは、接続の両側に対して有効にすることができない場合には、TCP送信者は、より良好な単一のウィンドウ内に部分的ACKおよび複数の損失を処理するために、NewRenoの[RFC2582]を使用することができます。
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.
高速再送/高速リカバリメカニズムは、輻輳回避の安全をあきらめることなく、損失の迅速な修復を可能にします。仕事への高速再送/高速回復のためのためには、ウィンドウサイズは、フルTCPスロースタートを強制的に、再送タイムアウト間隔の有効期限が切れる前に3つの重複確認応答を送信するために受信機を強制するのに十分な大きさでなければなりません。
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.
選択的確認応答（SACK）は、ウィンドウ内の複数のセグメントの損失がより迅速にのみ、次のセグメントの損失を検出するために、各セグメントの損失のための高速再送信を実行することによって達成することができるよりも修復する必要がある状況に高速再送/高速回復の利点を拡張します。
These mechanisms are not limited to wireless environments. They are usable in all environments.
これらのメカニズムは、無線環境に限定されるものではありません。彼らはすべての環境で使用可能です。
"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.
「リミテッド送信」[RFC3042]は3つの重複確認応答をトリガしません輻輳ウィンドウが小さいとのTCP接続の高速再送信/高速リカバリを拡張する最適化として指定されています。この仕様は、安全とみなされ、それはまた、パケット（データまたは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.
遅延重複謝辞[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は、接続経路の「第1のホップ」である場合は特に、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ストリーム上で行わ損失は、データストリームはかなりバースト性（だけでなく、データストリーム上の損失を生じる）ことができます。このバースト性を制限するいくつかの方法は、ネットワーク内の送信者とACKレート制御で、TCP送信ペーシングを含め、提案されています。
"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 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.
「適切なバイトカウント」（ABC）ALL99]は、正常に比較的との接続を開始するアプリケーションプロトコルのためのより適切な行動を与え、受信機に転送されたバイト数に基づいて輻輳ウィンドウを開く方法として提案されていますショートパケット。最大長パケットとして送信される全体のメール本文に続く - SMTP [RFC2821]のために、例えば、クライアントは、短いHELOパケット、ショートメールパケット、一つ以上の短いRCPTパケット、および短いデータ・パケットを送るかもしれません。 ABC TCPの送信者は、追加の完全長のパケットを許可するように輻輳ウィンドウを高めるために、これらの短いパケットごとにACKを使用することはありません。 ABCは、追加の研究の価値があるが、確認応答が失われたときにABCが増加バースト性につながる可能性があるため、現時点では推奨されません。
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.
この文書で説明する推奨事項は、インターネットを不安定にし、その利用可能な帯域幅の使用を最適化することなく、可能な限り迅速にエラーが発生した接続にパケットを注入でのTCPを支援します。
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レベルの推奨事項に加えて、特にWorld Wide Web上の支配的なアプリケーションプロトコル、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オブジェクトがサイズ[MOGUL]で小さくなる傾向があるので、TCPが使用可能なパス容量の「トレーニング」でHTTP / 1.0トラフィック経験の難易度（転送のかなりの部分、既に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.
いくつかのHTTP修飾は、（HTTP / 1.1の改良[RFC2616]と、HTTP / 1.0の「永続的な接続」）TCPとのこの相互作用を改善するために導入されています。様々な理由から、多くのHTTPの相互作用は、まだHTTPです/ 1.0スタイル - 比較的短命。
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制御ブロック相互依存[RFC2140]、またはより最近の輻輳マネージャ[BS00]の提案のように、接続間のTCP輻輳情報を再利用する提案は、「彼らは、単一の接続であるかのようにネットワークを複数の並列接続の影響を作る効果があります単一起動過渡の後に」訓練を受けました。これらの提案は、インターネットの長期安定性に不可欠な今日のユーザーは、常に自分のブラウザの「再読み込み」ボタンをクリックすると、TCPの指数バックオフを切断の選択があるので - で利用可能な帯域幅の知識を構築している接続を交換しますまったく知識との接続。
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.
高速再送/高速回復により導入された潜在的な脆弱性により、攻撃者はより積極的に振る舞う、より危険な、停止に挽くためにTCP接続を強制する、またはこと（[RFC2581]で指摘したように）です。後者の可能性は、少なくともネットワークの一部領域に、輻輳崩壊につながる可能性があります。
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のようなメカニズムと正反対です。
This document is a pointer to other, existing IETF standards. There are no new IANA considerations.
この文書は、他の既存のIETF標準へのポインタです。新しいIANAの考慮事項はありません。
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.
この勧告は、順番にIETF TCPSATワーキンググループで行われた作業に基づいていたRFC 2757、「ロング・シン・ネットワーク」、の外に成長してきました。著者は、PILCワーキンググループのアクティブメンバーにお世話になっています。特に、マーク・オールマンとロイド・ウッドは私達に豊富な洞察力のフィードバックを与え、そしてダン・グロスマンとジャムシード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巻、第3号、1999年7月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]バラクリシュナン、H.とS. Seshan、 "輻輳管理"、RFC 3124、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日。
[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、テキサスA＆M大学、テクニカルレポート98から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
[MOGUL]「永続的接続のHTTP用ケース」、J. C.モーグル、研究報告書4分の95、利用可能な月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大学、12月24日、HTTPで利用可能な1997年：//www.cs.tamuを。 EDU /教員/ vaidya / mobile.html
[PILC-WEB] http://pilc.grc.nasa.gov/
[PILC-WEB] 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.Kurose、 "TCPスループット：単純なモデルとその実証的検証" 通信アーキテクチャ及びプロトコル、1998年8月に、SIGCOMMシンポジウム。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2821] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J.、エディタ、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1191] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191]モーグルJ.、およびS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman. "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、R.、およびD.ボーマン。 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[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選択確認応答オプション"、RFC 2018、1996年10月。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[RFC2140]タッチ、J.、 "TCP制御ブロック相互依存"、RFC 2140、1997年4月。
[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.、ラマクリシュナン、K.、Shecker、S.、Wroclawski、J.およびL、張、 "インターネットの待ち行列管理と輻輳回避に関する提言"、RFC 2309、1998年4月。
[RFC2481] Ramakrishnan K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[RFC2481]ラマクリシュナンK.及びS.フロイド、 "IPに明示的輻輳通知（ECN）を追加する提案"、RFC 2481、1999年1月。
[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.サンチェス。 、BCP 28、RFC 2488 "標準的なメカニズムを使用してTCP上の衛星テレビの強化"、1999年1月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、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の変更"、RFC 2582、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.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチP.およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2616年、1999年6月。
[RFC2861] Handley, H., Padhye, J. and S., Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861]ハンドレー、H.、Padhye、J.及びS.、フロイド、 "TCPの輻輳ウィンドウ検証"、RFC 2861、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のための選択的確認応答（SACK）オプションの拡張"、RFC 2883、1999年8月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]レイヒー、K.、 "パスMTUディスカバリとTCPの問題"、RFC 2923、2000年9月。
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January, 2001.
[RFC3042]オールマン、M.、バラクリシュナン、H.とS.フロイド、 "株式会社トランスミットを使用したTCPの損失回復の強化"、RFC 3042、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.、古城、M.、Griner、J.、モンテネグロ、G.およびZ.シェルビー、 "プロキシのパフォーマンスの向上は、リンク関連の劣化を軽減することを目的"、RFC 3135、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
[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月には、無線通信およびワイヤレスコンピューティング（モバイルコンピューティングのための信頼性の高いトランスポートプロトコル特集）誌に登場します。
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 Eメール：spencer.dawkins@fnc.fujitsu.com
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
ガブリエル・E.モンテネグロSun Microsystemsの研究所、欧州29、CHEMINドゥヴューシュヌ38240メランFRANCE
Phone: +33 476 18 80 45 EMail: gab@sun.com
電話：+33 476 18 80 45 Eメール：gab@sun.com
Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland
コンピュータサイエンス、ヘルシンキ大学、私書箱のマルック古城部門ボックス26（Teollisuuskatu 23）FIN-00014ヘルシンキ、フィンランド
Phone: +358-9-1914-4179 EMail: kojo@cs.helsinki.fi
電話：+ 358-9-1914-4179 Eメール：kojo@cs.helsinki.fi
Vincent Magret Alcatel Internetworking, Inc. 26801 W. Agoura road Calabasas, CA, 91301
ヴィンセントMagretアルカテル・インターネット、Inc.の26801のW.アゴーラ道路カラバサス、CA、91301
Phone: +1 818 878 4485 EMail: vincent.magret@alcatel.com
電話：+1 818 878 4485 Eメール：vincent.magret@alcatel.com
Nitin H. Vaidya 458 Coodinated Science Laboratory, MC-228 1308 West Main Street Urbana, IL 61801
ニティンH. Vaidya 458 Coodinated科学研究所、MC-228 1308西のメインストリートアーバナ、IL 61801
Phone: 217-265-5414 E-mail: nhv@crhc.uiuc.edu
電話番号：217-265-5414 Eメール：nhv@crhc.uiuc.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。