[要約] RFC 3155は、エラーを含むリンクのエンドツーエンドのパフォーマンスに関する情報を提供するものであり、その目的は、エラーの影響を理解し、ネットワークのパフォーマンスを向上させるためのガイドラインを提供することです。
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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 RENO応答関数の近似式は[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
T = 1秒あたりのバイトの送信レートs =バイト単位のパケットサイズrtt =秒単位のラウンドトリップ時間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がリンクを利用する能力が向上します。
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）最大（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を配置できるため、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.
ただし、PEPの一般化された使用は、エンドツーエンドの原理に違反し、以下を含む有害な意味を考えると非常に望ましくありません：運命共有の欠如（PEPはエンドポイント自体に加えて3番目の失敗ポイントを追加します）、エンドツー-ENDの信頼性と診断、エンドツーエンドのセキュリティ（特に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 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.
この推奨事項は、既に展開されているサブネットワークテクノロジー（リンクレイヤー）を介してTCPで使用するためです。インターネットプロトコルを携帯することを目的としたが、完全に指定されていないサブネットワークは、リンク特性WG（PILC）[PILC-WEBのパフォーマンスの影響によって開発された、または開発されている最良の共通プラクティス（BCP）ドキュメントの主題の主題です。]。この最後のドキュメントは、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を認識したTCPに対するECNの効果は、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).
- 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.
- 信頼性の低いリンクレイヤーは、多くの場合、小さなリンクMTUを使用します。これにより、セグメントの単位で送信者のウィンドウが増加するため、スロースタート中に送信者のウィンドウサイズの増加率が遅くなります。小さなリンクMTUだけでは、信頼性を向上させません。Path MTU Discovery [RFC1191]は、断片化を防ぐためにも使用する必要があります。PATH 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実装は、順序外のシーケンス番号で到着するセグメントごとに欠落しているセグメントを検出します。
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ネットワークはパケットを並べ替えることが許可されているため、受信者は、ルーティングの変更、リンクレベルの再送信などにより、順番に到着するセグメントの重複謝辞を送信する場合があります。TCP送信者が3つの重複アクセスを受信した場合、高速再送信[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つ以上のセグメントが含まれるたびに輻輳ウィンドウを半分にし、各輻輳ウィンドウの承認相当の各輻輳ウィンドウの追加セグメントでウィンドウを再び開きます。
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つのセグメントから始まるスロースタートを実行することを意味します。Webマスターが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」）は[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によると、これらの環境で遭遇する可能性のある長い往復時間のため、選択的承認はLFN（「長脂肪ネットワーク」）で最も役立ちます。ウィンドウごとに複数のセグメント損失の可能性が高いことです。
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送信者はNewReno [RFC2582]を使用して、単一のウィンドウ内の部分的なAckと複数の損失をより適切に処理できます。
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.
迅速な再送信/高速回復メカニズムにより、混雑回避の安全性を放棄することなく、損失を迅速に修復できます。迅速な再送信/迅速な回復を機能させるためには、再送信タイムアウト間隔が期限切れになる前にレシーバーに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.
「Limited送信」[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が接続パスの「ファーストホップ」である場合、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.
ACKストリームで発生する損失は、特にTCPがネットワークの特性を学習している間、データストリームを非常に破裂させる可能性があります（データストリームの損失も発生します）。この破裂を制限するいくつかの方法が提案されています。これには、送信者での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 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パケット、短いメールパケット、1つ以上の短いRCPTパケット、および短いデータパケットを送信する場合があります。ABC TCP送信者は、これらの短いパケットのそれぞれにAcksを使用して、混雑ウィンドウを増やして追加のフルレングスパケットを許可しません。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.
このドキュメントで説明されている推奨事項は、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レベルの推奨事項に加えて、特に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オブジェクトのサイズ[モーグル]は小さい傾向があるため、HTTP/1.0のトラフィックエクスペリエンスエクスペリエンスの困難を抱えるTCPは、利用可能なパス容量での「トレーニング」の困難です（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変更が導入されています（HTTP/1.0の「永続的な接続」、HTTP/1.1 [RFC2616]の改善）。さまざまな理由で、多くの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.
速い再送信/高速回復によって導入される潜在的な脆弱性は（[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の存在下でも作業を続けています。これは、中間ノードに実装されているPEPなどのメカニズムとは直接対照的です（セクション1.2）。
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.
この推奨事項は、RFC 2757「Long Thin Networks」から成長しました。これは、IETF TCPSATワーキンググループで行われた作業に基づいています。著者は、PILCワーキンググループのアクティブなメンバーに感謝しています。特に、マーク・オルマンとロイド・ウッドは私たちに豊富で洞察に満ちたフィードバックを与えてくれました。そして、ダン・グロスマンとジャムシッド・マハダビはテキストの代替品を提供しました。
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. Allman、「TCP BYTE Counting Refinments」、ACM Computer Communication Review、Volume 29、Number 3、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、「The Commestion Manager」、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大学、1998年6月、テクニカルレポート98-013。
[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大学、1998年6月、テクニカルレポート98-014。
[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] "Persistent-Connection HTTPのケース"、J。C。Mogul、Research Report 95/4、1995年5月。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. MehtaおよびN. Vaidya、「重複した廃棄物の遅延：ワイヤレスリンクでのTCPのパフォーマンスを改善する提案」、テキサスA＆M大学、1997年12月24日。Edu/Faculty/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 Sultput：A Simple Model and Its Empirical Validation」、Communications Architectures and Protocolsに関するSigcommシンポジウム、1998年8月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC2821] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、編集者、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1191] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191] Mogul J.、およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman. "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、R。およびD. Borman。「高性能のためのTCP拡張機能」、RFC 1323、1992年5月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow「TCP選択的承認オプション」、RFC 2018、1996年10月。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[RFC2140] Touch、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] 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、「インターネットにおけるキュー管理と混雑回避に関する推奨事項」、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] Ramakrishnan K.およびS. Floyd、「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] Allman、M.、Glover、D。およびL. Sanchez。「標準メカニズムを使用した衛星チャネル上のTCPの強化」、BCP 28、RFC 2488、1999年1月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。and W. Stevens、「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] Floyd、S。およびT. Henderson、「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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach P.およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC2616、1999年6月。
[RFC2861] Handley, H., Padhye, J. and S., Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861] Handley、H.、Padhye、J。and S.、Floyd、「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] Floyd、S.、Mahdavi、M.、Mathis、M。、およびM. Podlosky、「TCPの選択的承認（SACK）オプションの拡張」、RFC 2883、1999年8月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU Discoveryの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] Allman、M.、Balakrishnan、H。およびS. Floyd、「限定送信を使用した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] Border、J.、Kojo、M.、Griner、J.、Montenegro、G。、およびZ. Shelby、「リンク関連の劣化を緩和することを目的としたプロキシを向上させるパフォーマンス」、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] Jacobson、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。Mehta、C。Perkins、およびG. Montenegro、「重複した謝辞の遅延：ワイヤレスよりもTCPのパフォーマンスを改善するためのTCP-ユナウェアアプローチ」、テクニカルレポート99-003、コンピューターサイエンスデプトTexas A＆M University、1999年2月。また、Journal of Wireless Communications and Wireless Computing（モバイルコンピューティング用の信頼できる輸送プロトコルに関する特別号）に掲載されています。
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
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
ガブリエルE.モンテネグロサンマイクロシステムズラボラトリーズ、ヨーロッパ29、ケミンデュヴィューチェーン38240メイランフランス
Phone: +33 476 18 80 45
EMail: gab@sun.com
Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland
ヘルシンキP.O.コンピュータサイエンス大学マルクコホ科Box 26（Teollisuuskatu 23）Fin-00014 Helsinki Finland
Phone: +358-9-1914-4179 EMail: kojo@cs.helsinki.fi Vincent Magret Alcatel Internetworking, Inc. 26801 W. Agoura road Calabasas, CA, 91301
電話：358-9-1914-4179メール：kojo@cs.helsinki.fi vincent magret alcatelインターネットワーキング、Inc。26801 W. Agoura Road Calabasas、CA、91301
Phone: +1 818 878 4485
EMail: vincent.magret@alcatel.com
Nitin H. Vaidya 458 Coodinated Science Laboratory, MC-228 1308 West Main Street Urbana, IL 61801
Nitin H. Vaidya 458 Coodinated Science Laboratory、MC-228 1308 West Main Street Urbana、IL 61801
Phone: 217-265-5414 E-mail: nhv@crhc.uiuc.edu
電話：217-265-5414電子メール：nhv@crhc.uiuc.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。