Network Working Group M. Allman, Editor
Request for Comments: 2760 NASA Glenn Research Center/BBN Technologies
Category: Informational S. Dawkins
Nortel
D. Glover
J. Griner
D. Tran
NASA Glenn Research Center
T. Henderson
University of California at Berkeley
J. Heidemann
J. Touch
University of Southern California/ISI
H. Kruse
S. Ostermann
Ohio University
K. Scott
The MITRE Corporation
J. Semke
Pittsburgh Supercomputing Center
February 2000
Ongoing TCP Research Related to Satellites
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. The algorithms and mechanisms outlined have not been judged to be mature enough to be recommended by the IETF. The goal of this document is to educate researchers as to the current work and progress being done in TCP research related to satellite networks.
このドキュメントでは、TCPがより良い衛星リンクを含むネットワークにより提供される利用可能な帯域幅を利用できるようにすることも可能TCPの拡張機能の概要を説明します。概説アルゴリズムとメカニズムは、IETFによって推奨されるのに十分に成熟であると判断されていません。このドキュメントの目標は、衛星ネットワークに関連するTCPの研究で行われている現在の仕事と進歩へと研究者を教育することです。
Table of Contents
目次
1 Introduction. . . . . . . . . . . . . . . . . . . . 2
2 Satellite Architectures . . . . . . . . . . . . . . 3
2.1 Asymmetric Satellite Networks . . . . . . . . . . . 3
2.2 Satellite Link as Last Hop. . . . . . . . . . . . . 3
2.3 Hybrid Satellite Networks . . . . . . . . . . . 4
2.4 Point-to-Point Satellite Networks . . . . . . . . . 4
2.5 Multiple Satellite Hops . . . . . . . . . . . . . . 4
3 Mitigations . . . . . . . . . . . . . . . . . . . . 4
3.1 TCP For Transactions. . . . . . . . . . . . . . . . 4
3.2 Slow Start. . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Larger Initial Window . . . . . . . . . . . . . . . 6
3.2.2 Byte Counting . . . . . . . . . . . . . . . . . . . 7
3.2.3 Delayed ACKs After Slow Start . . . . . . . . . . . 9
3.2.4 Terminating Slow Start. . . . . . . . . . . . . . . 11
3.3 Loss Recovery . . . . . . . . . . . . . . . . . . . 12
3.3.1 Non-SACK Based Mechanisms . . . . . . . . . . . . . 12
3.3.2 SACK Based Mechanisms . . . . . . . . . . . . . . . 13
3.3.3 Explicit Congestion Notification. . . . . . . . . . 16
3.3.4 Detecting Corruption Loss . . . . . . . . . . . . . 18
3.4 Congestion Avoidance. . . . . . . . . . . . . . . . 21
3.5 Multiple Data Connections . . . . . . . . . . . . . 22
3.6 Pacing TCP Segments . . . . . . . . . . . . . . . . 24
3.7 TCP Header Compression. . . . . . . . . . . . . . . 26
3.8 Sharing TCP State Among Similar Connections . . . . 29
3.9 ACK Congestion Control. . . . . . . . . . . . . . . 32
3.10 ACK Filtering . . . . . . . . . . . . . . . . . . . 34
4 Conclusions . . . . . . . . . . . . . . . . . . . . 36
5 Security Considerations . . . . . . . . . . . . . . 36
6 Acknowledgments . . . . . . . . . . . . . . . . . . 37
7 References. . . . . . . . . . . . . . . . . . . . . 37
8 Authors' Addresses. . . . . . . . . . . . . . . . . 43
9 Full Copyright Statement. . . . . . . . . . . . . . 46
1 Introduction
1はじめに
This document outlines mechanisms that may help the Transmission Control Protocol (TCP) [Pos81] better utilize the bandwidth provided by long-delay satellite environments. These mechanisms may also help in other environments or for other protocols. The proposals outlined in this document are currently being studied throughout the research community. Therefore, these mechanisms are not mature enough to be recommended for wide-spread use by the IETF. However, some of these mechanisms may be safely used today. It is hoped that this document will stimulate further study into the described mechanisms. If, at some point, the mechanisms discussed in this memo prove to be safe and appropriate to be recommended for general use, the appropriate IETF documents will be written.
この文書は、伝送制御プロトコル（TCP）は[Pos81】良好長い遅延衛星環境によって提供される帯域幅を利用することを助けることができるメカニズムを概説します。これらのメカニズムは、他の環境で、または他のプロトコルのために役立つかもしれません。このドキュメントで概説した提案は、現在、研究コミュニティ全体で検討されています。したがって、これらのメカニズムは、IETFによって広範に使用することは推奨されるのに十分成熟していません。しかし、これらのメカニズムのいくつかは、安全に今日使用することができます。この文書が説明するメカニズムにさらなる研究を刺激することが期待されます。 、いくつかの点で、このメモで述べたメカニズムは、一般的な使用のために推奨されるように、安全かつ適切であることを証明する場合は、適切なIETF文書が書き込まれます。
It should be noted that non-TCP mechanisms that help performance over satellite links do exist (e.g., application-level changes, queueing disciplines, etc.). However, outlining these non-TCP mitigations is beyond the scope of this document and therefore is left as future work. Additionally, there are a number of mitigations to TCP's performance problems that involve very active intervention by gateways along the end-to-end path from the sender to the receiver. Documenting the pros and cons of such solutions is also left as future work.
衛星回線上のパフォーマンスを助ける非TCPメカニズムが（例えば、アプリケーションレベルの変更、キューイング規律など）が存在しないことに留意すべきです。しかし、これらの非TCPの緩和策を概説することは、この文書の範囲外であるため、将来の仕事として残されています。また、送信側から受信側へのエンドツーエンドのパスに沿っゲートウェイによって非常に積極的な介入を伴うTCPのパフォーマンス問題への緩和策がいくつかあります。こうしたソリューションの長所と短所を文書化することも今後の課題として残されています。
2 Satellite Architectures
2つのサテライトアーキテクチャ
Specific characteristics of satellite links and the impact these characteristics have on TCP are presented in RFC 2488 [AGS99]. This section discusses several possible topologies where satellite links may be integrated into the global Internet. The mitigation outlined in section 3 will include a discussion of which environment the mechanism is expected to benefit.
衛星回線やTCP上のこれらの特性が与える影響の具体的な特性は、RFC 2488 [AGS99]に提示されています。このセクションでは、衛星リンクは、グローバルインターネットに一体化することができるいくつかの可能なトポロジについて説明します。セクション3で概説緩和機構が恩恵を受けると予想される環境の説明を含むことになります。
Some satellite networks exhibit a bandwidth asymmetry, a larger data rate in one direction than the reverse direction, because of limits on the transmission power and the antenna size at one end of the link. Meanwhile, some other satellite systems are unidirectional and use a non-satellite return path (such as a dialup modem link). The nature of most TCP traffic is asymmetric with data flowing in one direction and acknowledgments in opposite direction. However, the term asymmetric in this document refers to different physical capacities in the forward and return links. Asymmetry has been shown to be a problem for TCP [BPK97,BPK98].
いくつかの衛星ネットワークがあるため、リンクの一端の送信電力及びアンテナのサイズに制限の帯域幅非対称、逆方向よりも一方向に大きなデータレートを示します。一方、いくつかの他の衛星システムは、一方向であり（例えば、ダイヤルアップモデムリンクのような）非衛星リターンパスを使用します。ほとんどのTCPトラフィックの性質が反対の方向に一方向に流れるデータと確認応答非対称です。しかし、この文書の非対称用語は、前方に別の物理容量を意味し、リンクを返します。非対称性はTCP [BPK97、BPK98]のための問題であることが示されています。
Satellite links that provide service directly to end users, as opposed to satellite links located in the middle of a network, may allow for specialized design of protocols used over the last hop. Some satellite providers use the satellite link as a shared high speed downlink to users with a lower speed, non-shared terrestrial link that is used as a return link for requests and acknowledgments. Many times this creates an asymmetric network, as discussed above.
エンドユーザーに直接サービスを提供する衛星リンクは、ネットワークの中間に位置する衛星リンクとは反対に、最後のホップ上で使用されるプロトコルの専門設計を可能にしてもよいです。いくつかの衛星プロバイダは、要求と確認応答のためのリターンリンクとして使用されている低速、非共有陸上リンクを持つユーザーへの共有高速ダウンリンクとして衛星回線を使用しています。上述したように、多くの時間が、これは、非対称ネットワークを作成します。
In the more general case, satellite links may be located at any point in the network topology. In this case, the satellite link acts as just another link between two gateways. In this environment, a given connection may be sent over terrestrial links (including terrestrial wireless), as well as satellite links. On the other hand, a connection could also travel over only the terrestrial network or only over the satellite portion of the network.
より一般的なケースでは、衛星リンクは、ネットワークトポロジ内の任意の点に位置してもよいです。この場合、衛星リンクは、2つのゲートウェイ間のちょうど別のリンクとして機能します。この環境では、所与の接続は、地上（地上無線含む）リンク、ならびに衛星リンクを介して送信されてもよいです。一方、接続はまた、唯一の地上ネットワーク又は唯一のネットワークの衛星部分上にわたって移動することができました。
In point-to-point satellite networks, the only hop in the network is over the satellite link. This pure satellite environment exhibits only the problems associated with the satellite links, as outlined in [AGS99]. Since this is a private network, some mitigations that are not appropriate for shared networks can be considered.
ポイントツーポイント衛星ネットワークでは、ネットワーク内の唯一のホップは、衛星リンクを介してです。 【AGS99]に概説されるように、この純粋な衛星環境は、衛星リンクに関連付けられている問題のみを示します。これはプライベートなネットワークであるので、共有ネットワークには適していないいくつかの緩和策を考えることができます。
In some situations, network traffic may traverse multiple satellite hops between the source and the destination. Such an environment aggravates the satellite characteristics described in [AGS99].
いくつかの状況では、ネットワーク・トラフィックは、送信元と宛先との間の複数の衛星ホップを横断することができます。そのような環境は、[AGS99]に記載の衛星の特性を悪化させます。
3 Mitigations
3つの軽減策
The following sections will discuss various techniques for mitigating the problems TCP faces in the satellite environment. Each of the following sections will be organized as follows: First, each mitigation will be briefly outlined. Next, research work involving the mechanism in question will be briefly discussed. Next the implementation issues of the mechanism will be presented (including whether or not the particular mechanism presents any dangers to shared networks). Then a discussion of the mechanism's potential with regard to the topologies outlined above is given. Finally, the relationships and possible interactions with other TCP mechanisms are outlined. The reader is expected to be familiar with the TCP terminology used in [AGS99].
次のセクションでは、TCPは、衛星環境に直面している問題を軽減するための様々な技術について説明します。まず、それぞれの緩和について簡単に概要を説明する次のように次の各セクションには、組織化されます。次に、問題のメカニズムに関わる研究活動を簡単に説明します。機構の次のインプリメンテーションの問題が（特定の機構は、共有ネットワークへの危険を提示するか否かを含む）を提示されます。次いで、上記で概説したトポロジに関する機構の電位の議論が与えられます。最後に、他のTCPメカニズムとの関係と相互作用の可能性が概説されています。読者は[AGS99]で使用されるTCPの用語に精通していることが期待されます。
TCP uses a three-way handshake to setup a connection between two hosts [Pos81]. This connection setup requires 1-1.5 round-trip times (RTTs), depending upon whether the data sender started the connection actively or passively. This startup time can be eliminated by using TCP extensions for transactions (T/TCP) [Bra94]. After the first
TCPは、セットアップに二つのホスト[Pos81]との間の接続をスリーウェイハンドシェイクを使用しています。この接続設定は、データの送信者が能動的または受動的な接続を開始したかどうかに応じて、1〜1.5のラウンドトリップ時間（RTTの）が必要です。この起動時間は、トランザクションのTCP拡張（T / TCP）[Bra94]を使用して除去することができます。最初の後
connection between a pair of hosts is established, T/TCP is able to bypass the three-way handshake, allowing the data sender to begin transmitting data in the first segment sent (along with the SYN). This is especially helpful for short request/response traffic, as it saves a potentially long setup phase when no useful data is being transmitted.
ホストのペア間の接続が確立され、T / TCPは、データ送信者が（SYNとともに）送信された最初のセグメント内のデータの送信を開始できるように、スリーウェイハンドシェイクをバイパスすることが可能です。それは有用なデータが送信されていない潜在的に長いセットアップフェーズを保存し、これは、短い要求/応答トラフィックのために特に有用です。
T/TCP is outlined and analyzed in [Bra92,Bra94].
T / TCPは[Bra92、Bra94]に概説され、分析されます。
T/TCP requires changes in the TCP stacks of both the data sender and the data receiver. While T/TCP is safe to implement in shared networks from a congestion control perspective, several security implications of sending data in the first data segment have been identified [ddKI99].
T / TCPは、データ送信元とデータ受信機の両方のTCPスタックの変更を必要とします。 T / TCPが輻輳制御の観点から共有ネットワークに実装しても安全であるが、第1のデータセグメント内のデータを送信するいくつかのセキュリティ上の影響は[ddKI99】同定されています。
It is expected that T/TCP will be equally beneficial in all environments outlined in section 2.
T / TCPは、セクション2に記載されているすべての環境でも同様に有益であることが期待されます。
T/TCP allows data transfer to start more rapidly, much like using a larger initial congestion window (see section 3.2.1), delayed ACKs after slow start (section 3.2.3) or byte counting (section 3.2.2).
T / TCPは、データ転送が非常に大きい初期の輻輳ウィンドウを使用して同様に、より迅速に開始することができ（セクション3.2.1を参照）、（セクション3.2.3）またはバイトカウント（セクション3.2.2）スロースタートの後にACKを遅らせました。
The slow start algorithm is used to gradually increase the size of TCP's congestion window (cwnd) [Jac88,Ste97,APS99]. The algorithm is an important safe-guard against transmitting an inappropriate amount of data into the network when the connection starts up. However, slow start can also waste available network capacity, especially in long-delay networks [All97a,Hay97]. Slow start is particularly inefficient for transfers that are short compared to the delay*bandwidth product of the network (e.g., WWW transfers).
スロースタートアルゴリズムは、徐々にTCPの輻輳ウィンドウ（CWND）[Jac88、Ste97、APS99]のサイズを大きくするために使用されます。このアルゴリズムは、接続の起動時にネットワークへのデータの不適切な量を送信に対する重要なセーフガードです。しかし、スロースタートにも特に長い遅延ネットワーク[All97a、Hay97]で、利用可能なネットワーク容量を無駄にすることができます。スロースタートは、ネットワークの遅延・帯域幅積（例えば、WWW転送）に比べて短い転送のために特に非効率的です。
Delayed ACKs are another source of wasted capacity during the slow start phase. RFC 1122 [Bra89] suggests data receivers refrain from ACKing every incoming data segment. However, every second full-sized segment should be ACKed. If a second full-sized segment does not arrive within a given timeout, an ACK must be generated (this timeout cannot exceed 500 ms). Since the data sender increases the size of cwnd based on the number of arriving ACKs, reducing the number of
遅延ACKはスロースタートフェーズの間に無駄な容量の別のソースです。 RFC 1122 [Bra89】データ受信機は、すべての着信データ・セグメントの肯定応答（ACK）を控えるを示唆しています。しかし、毎秒フルサイズのセグメントがACKされるべきです。第フルサイズのセグメントが与えられたタイムアウト時間内に到着しない場合、ACK（このタイムアウトは500ミリ秒を超えることはできません）が生成されなければなりません。データ送信側は、の数を減らす、到着ACKの数に基づいて輻輳ウィンドウのサイズを増加させるため
ACKs slows the cwnd growth rate. In addition, when TCP starts sending, it sends 1 segment. When using delayed ACKs a second segment must arrive before an ACK is sent. Therefore, the receiver is always forced to wait for the delayed ACK timer to expire before ACKing the first segment, which also increases the transfer time.
ACKはcwndの成長率が遅くなります。 TCPの送信を開始したときに加えて、それは1つのセグメントを送信します。遅延ACKを使用する場合はACKが送信される前に、第2のセグメントが到着しなければなりません。そのため、受信機は、常にも、転送時間が長くなり、最初のセグメントを、肯定応答（ACK）の前に期限切れに遅延ACKタイマを待つことを余儀なくされます。
Several proposals have suggested ways to make slow start less time consuming. These proposals are briefly outlined below and references to the research work given.
いくつかの提案はあまり時間がかかるスロースタートを作る方法を示唆しています。これらの提案は、簡単に与えられた研究活動を以下のとおりと参照されています。
One method that will reduce the amount of time required by slow start (and therefore, the amount of wasted capacity) is to increase the initial value of cwnd. An experimental TCP extension outlined in [AFP98] allows the initial size of cwnd to be increased from 1 segment to that given in equation (1).
スロースタートによって必要とされる時間の量を減少させる一つの方法は、（そのため、無駄な容量の量）CWNDの初期値を増加させることです。 [AFP98]で概説した実験TCP拡張はCWNDの初期サイズは、1つのセグメントから、式（1）で与えられたものに高めることを可能にします。
min (4*MSS, max (2*MSS, 4380 bytes)) (1)
分（4 * MSS、MAX（2 * MSS 4380バイト））（1）
By increasing the initial value of cwnd, more packets are sent during the first RTT of data transmission, which will trigger more ACKs, allowing the congestion window to open more rapidly. In addition, by sending at least 2 segments initially, the first segment does not need to wait for the delayed ACK timer to expire as is the case when the initial size of cwnd is 1 segment (as discussed above). Therefore, the value of cwnd given in equation 1 saves up to 3 RTTs and a delayed ACK timeout when compared to an initial cwnd of 1 segment.
CWNDの初期値を増加させることにより、より多くのパケットが輻輳ウィンドウは、より迅速に開くことができ、より多くのACKをトリガするデータ伝送の最初のRTT、中に送信されます。加えて、最初に、少なくとも2つのセグメントを送信することにより、第一のセグメントは、（上述のように）CWNDの初期サイズは、1つのセグメントである場合のように期限切れに遅延ACKタイマを待つ必要はありません。 1つのセグメントの初期のcwndと比較した場合、したがって、式（1）で与えられたCWNDの値は、3つのRTTと遅延ACKタイムアウトまで保存します。
Also, we note that RFC 2581 [APS99], a standards-track document, allows a TCP to use an initial cwnd of up to 2 segments. This change is highly recommended for satellite networks.
また、我々は、RFC 2581 [APS99]は、標準トラック文書は、TCPは、最大2つのセグメントの初期のcwndを使用することができますことに注意してください。この変更は、高度衛星ネットワークのために推奨されます。
Several researchers have studied the use of a larger initial window in various environments. [Nic97] and [KAGT98] show a reduction in WWW page transfer time over hybrid fiber coax (HFC) and satellite links respectively. Furthermore, it has been shown that using an initial cwnd of 4 segments does not negatively impact overall performance over dialup modem links with a small number of buffers [SP98]. [AHO98] shows an improvement in transfer time for 16 KB files across the Internet and dialup modem links when using a larger initial value for cwnd. However, a slight increase in dropped segments was also shown. Finally, [PN98] shows improved transfer time for WWW traffic in simulations with competing traffic, in addition to a small increase in the drop rate.
いくつかの研究者は、様々な環境での大きな初期ウィンドウの使用を検討しました。 【Nic97]および[KAGT98]は、それぞれ、ハイブリッドファイバ同軸（HFC）や衛星リンクを介してWWWページ転送時間の減少を示します。また、4つのセグメントの初期のcwndを使用して負のバッファ[SP98]少数のダイヤルアップモデムリンクを介して全体的なパフォーマンスに影響を与えないことが示されています。 CWNDのためのより大きな初期値を使用する場合[AHO98] 16個のインターネット経由KBファイルとダイヤルアップモデムリンクの転送時間の改善を示しています。しかし、ドロップされたセグメントのわずかな増加も示しました。最後に、[PN98]は低下率のわずかな増加に加えて、トラフィックを競合とシミュレーションにおけるWWWトラフィックのための改良された転送時間を示しています。
The use of a larger initial cwnd value requires changes to the sender's TCP stack. Using an initial congestion window of 2 segments is allowed by RFC 2581 [APS99]. Using an initial congestion window of 3 or 4 segments is not expected to present any danger of congestion collapse [AFP98], however may degrade performance in some networks.
より大きな初期のcwndの値を使用すると、送信者のTCPスタックを変更する必要があります。 2つのセグメントの最初の輻輳ウィンドウを使用することはRFC 2581 [APS99]で許可されています。 3または4つのセグメントの最初の輻輳ウィンドウを使用する[AFP98]、しかし、いくつかのネットワークにおける性能を低下させることができる輻輳崩壊の危険を提示しないと予想されます。
It is expected that the use of a large initial window would be equally beneficial to all network architectures outlined in section 2.
大きな初期ウィンドウの使用は、セクション2に記載されているすべてのネットワークアーキテクチャにも同様に有益であろうことが予想されます。
Using a fixed larger initial congestion window decreases the impact of a long RTT on transfer time (especially for short transfers) at the cost of bursting data into a network with unknown conditions. A mechanism that mitigates bursts may make the use of a larger initial congestion window more appropriate (e.g., limiting the size of line-rate bursts [FF96] or pacing the segments in a burst [VH97a]).
固定された大きな初期輻輳ウィンドウを使用して、未知の条件を使用してネットワークにデータをバーストの費用で（特に短い転送に）転送時間に長いRTTの影響を減少させます。バーストを緩和機構（ラインレートバーストのサイズ[FF96]を制限したり、バースト[VH97a]でセグメントをペーシング、例えば）より適切な、より大きな初期の輻輳ウィンドウを利用することができます。
Also, using delayed ACKs only after slow start (as outlined in section 3.2.3) offers an alternative way to immediately ACK the first segment of a transfer and open the congestion window more rapidly. Finally, using some form of TCP state sharing among a number of connections (as discussed in 3.8) may provide an alternative to using a fixed larger initial window.
また、（セクション3.2.3に概説されるように）のみスロースタート後に遅延ACKを使用すると直ちに転送の最初のセグメントをACKおよびより迅速に輻輳ウィンドウを開くための別の方法を提供します。最後に、（3.8で説明したように）接続の数の間のTCP状態共有のいくつかのフォームを使用して固定された大きい初期ウィンドウを使用する代替手段を提供することができます。
As discussed above, the wide-spread use of delayed ACKs increases the time needed by a TCP sender to increase the size of the congestion window during slow start. This is especially harmful to flows traversing long-delay GEO satellite links. One mechanism that has been suggested to mitigate the problems caused by delayed ACKs is the use of "byte counting", rather than standard ACK counting [All97a,All98]. Using standard ACK counting, the congestion window is increased by 1 segment for each ACK received during slow start. However, using byte counting the congestion window increase is based on the number of previously unacknowledged bytes covered by each incoming ACK, rather than on the number of ACKs received. This makes the increase relative to the amount of data transmitted, rather than being dependent on the ACK interval used by the receiver.
上述したように、遅延ACKの広範な使用は、スロースタート時の輻輳ウィンドウのサイズを大きくするために、TCP送信者が必要とする時間が長くなります。これは、長い遅延GEO衛星リンクを通過する流れに特に有害です。遅延ACKによって引き起こされる問題を軽減することが提案されている1つの機構は、「バイトカウント」、というよりも標準ACKカウント[All97a、All98]を使用することです。各ACKがスロースタート中に受信するための標準的なACKのカウントを使用して、輻輳ウィンドウは1つのセグメントだけ増加されます。しかし、輻輳ウィンドウの増加をカウント使用バイトがなく、ACKが受信された数に、各着信ACKによって覆わ以前に未確認のバイト数に基づいています。これはむしろ、受信機によって使用されるACK間隔に依存するよりも、送信されるデータの量に対して増加しています。
Two forms of byte counting are studied in [All98]. The first is unlimited byte counting (UBC). This mechanism simply uses the number of previously unacknowledged bytes to increase the congestion window each time an ACK arrives. The second form is limited byte counting (LBC). LBC limits the amount of cwnd increase to 2 segments. This limit throttles the size of the burst of data sent in response to a "stretch ACK" [Pax97]. Stretch ACKs are acknowledgments that cover more than 2 segments of previously unacknowledged data. Stretch ACKs can occur by design [Joh95] (although this is not standard), due to implementation bugs [All97b,PADHV99] or due to ACK loss. [All98] shows that LBC prevents large line-rate bursts when compared to UBC, and therefore offers fewer dropped segments and better performance. In addition, UBC causes large bursts during slow start based loss recovery due to the large cumulative ACKs that can arrive during loss recovery. The behavior of UBC during loss recovery can cause large decreases in performance and [All98] strongly recommends UBC not be deployed without further study into mitigating the large bursts.
バイトカウントの二つの形式は、[All98]で研究されています。最初は、無制限のバイトカウント（UBC）です。このメカニズムは、単に輻輳ウィンドウにACKが到着するたびに増加させるために、以前に認められていないバイト数を使用します。第2の形態は限定されたバイトカウント（LBC）です。 LBCは、2つのセグメントにCWND増加の量を制限します。この制限は、「ストレッチACK」[Pax97]に応答して送信されるデータのバーストの大きさを絞ります。ストレッチACKは以前に未確認データの2つの以上のセグメントをカバー確認応答です。ストレッチACKは起因実装バグ[All97b、PADHV99]またはによるACK損失に、設計[Joh95]（これは標準ではない）により起こり得ます。 【All98は】LBCはUBCと比較した場合、大ラインレートバーストを防ぎ、したがって、より少ないドロップセグメントと良好な性能を提供することを示しています。また、UBCは、損失回復の間に到着することができ、大きな累積のACKによる損失の回復をベーススロースタート時に大きなバーストが発生します。損失回復の間にUBCの挙動は、パフォーマンスと[All98]強くUBCが大バーストを軽減するにはさらに研究なしで展開されていないお勧めしますで大きな減少を引き起こす可能性があります。
Note: The standards track RFC 2581 [APS99] allows a TCP to use byte counting to increase cwnd during congestion avoidance, however not during slow start.
注意：標準はスロースタートの際ただし、RFC 2581 [APS99]は、TCPは輻輳回避の際にcwndを高めるために、バイトカウントを使用することができないトラック。
Using byte counting, as opposed to standard ACK counting, has been shown to reduce the amount of time needed to increase the value of cwnd to an appropriate size in satellite networks [All97a]. In addition, [All98] presents a simulation comparison of byte counting and the standard cwnd increase algorithm in uncongested networks and networks with competing traffic. This study found that the limited form of byte counting outlined above can improve performance, while also increasing the drop rate slightly.
バイトカウントを使用して、標準のACK計数とは対照的に、衛星ネットワーク[All97a]で適当な大きさにCWNDの値を増加させるために必要な時間の量を減少させることが示されています。また、[All98]は、バイトカウントと非輻輳ネットワークとトラフィックを競合とネットワークで標準のcwndの増加アルゴリズムのシミュレーション比較を提示します。この研究はまた少しドロップ率を増加させながら、上記で概説したバイトカウントの限定された形は、パフォーマンスを向上させることができました。
[BPK97,BPK98] also investigated unlimited byte counting in conjunction with various ACK filtering algorithms (discussed in section 3.10) in asymmetric networks.
[BPK97は、BPK98]非対称ネットワークにおいて（セクション3.10に説明する）、様々なACKフィルタリングアルゴリズムに関連して無制限のバイト・カウントを調べました。
Changing from ACK counting to byte counting requires changes to the data sender's TCP stack. Byte counting violates the algorithm for increasing the congestion window outlined in RFC 2581 [APS99] (by making congestion window growth more aggressive during slow start) and therefore should not be used in shared networks.
ACKはバイトカウントを数えてから変更すると、データ送信側のTCPスタックを変更する必要があります。バイトカウントは、（スロースタート時より積極的な輻輳ウィンドウ成長を行うことによって）RFC 2581 [APS99]で概説輻輳ウィンドウを増加させるためのアルゴリズムに違反し、したがって、共有ネットワークで使用すべきではありません。
It has been suggested by some (and roundly criticized by others) that byte counting will allow TCP to provide uniform cwnd increase, regardless of the ACKing behavior of the receiver. In addition, byte counting also mitigates the retarded window growth provided by receivers that generate stretch ACKs because of the capacity of the return link, as discussed in [BPK97,BPK98]. Therefore, this change is expected to be especially beneficial to asymmetric networks.
それは、そのバイトカウントに関係なく、受信機の肯定応答（ACK）の挙動の、TCPが均一にcwndの増加を提供することができますいくつかによって提案された（と丸く他人から批判）されています。また、バイトカウントはまた[BPK97、BPK98]で説明したように、なぜならリターンリンクの容量のストレッチACKを生成する受信機によって提供される遅ウィンドウ成長を軽減します。そのため、この変更は、非対称ネットワークに特に有益であることが期待されています。
Unlimited byte counting should not be used without a method to mitigate the potentially large line-rate bursts the algorithm can cause. Also, LBC may send bursts that are too large for the given network conditions. In this case, LBC may also benefit from some algorithm that would lessen the impact of line-rate bursts of segments. Also note that using delayed ACKs only after slow start (as outlined in section 3.2.3) negates the limited byte counting algorithm because each ACK covers only one segment during slow start. Therefore, both ACK counting and byte counting yield the same increase in the congestion window at this point (in the first RTT).
無制限のバイトカウントは、アルゴリズムが引き起こす可能性が潜在的に大きなラインレートバーストを緩和するために方法なしに使用すべきではありません。また、LBCは、特定のネットワーク条件には大きすぎるバーストを送信することができます。この場合、LBCはまた、セグメントのラインレートのバーストの影響を軽減するであろういくつかのアルゴリズムから利益を得ることができます。また、各ACKがスロースタート時のみつのセグメントをカバーしているため（セクション3.2.3に概説されるように）だけ遅い開始後、遅延ACKを使用すると、限られたバイトのカウントアルゴリズムを否定することに注意してください。したがって、ACKカウントおよびバイトカウントの両方が（最初のRTTで）この時点で、輻輳ウィンドウの同じ増加をもたらします。
As discussed above, TCP senders use the number of incoming ACKs to increase the congestion window during slow start. And, since delayed ACKs reduce the number of ACKs returned by the receiver by roughly half, the rate of growth of the congestion window is reduced. One proposed solution to this problem is to use delayed ACKs only after the slow start (DAASS) phase. This provides more ACKs while TCP is aggressively increasing the congestion window and less ACKs while TCP is in steady state, which conserves network resources.
上述したように、TCP送信者は、スロースタート時の輻輳ウィンドウを増加させるために受信ACKの数を使用します。遅延ACKが約半分で受信側によって返さACKの数を減らすので、輻輳ウィンドウの成長率が低下しています。この問題の一つの提案された解決策は唯一のスロースタート（DAASS）フェーズの後に遅延ACKを使用することです。 TCPは、ネットワークリソースを節約し、定常状態にある間、TCPが積極的に輻輳ウィンドウと少ないACKを増加している間これは、より多くのACKを提供します。
[All98] shows that in simulation, using delayed ACKs after slow start (DAASS) improves transfer time when compared to a receiver that always generates delayed ACKs. However, DAASS also slightly increases the loss rate due to the increased rate of cwnd growth.
【All98】このシミュレーションでは、スロースタート（DAASS）後に遅延ACKを使用すると、常に遅延ACKを生成する受信機と比較して転送時間を改善することを示しています。しかし、DAASSもわずかに起因CWND成長の増加速度に損失率を増加させます。
The major problem with DAASS is in the implementation. The receiver has to somehow know when the sender is using the slow start algorithm. The receiver could implement a heuristic that attempts to watch the change in the amount of data being received and change the ACKing behavior accordingly. Or, the sender could send a message (a flipped bit in the TCP header, perhaps) indicating that it was using slow start. The implementation of DAASS is, therefore, an open issue.
DAASSの大きな問題は、インプリメンテーションです。受信側は送信側がスロースタートアルゴリズムを使用しているとき何とか知っていなければなりません。受信機は、受信されたデータ量の変化を監視し、それに応じて肯定応答（ACK）の動作を変更しようとするヒューリスティックを実装することができました。または、送信者は、スロースタートを使用したことを示す（おそらくTCPヘッダ内の反転ビット）メッセージを送ることができます。 DAASSの実装は、それゆえ、未解決の問題です。
Using DAASS does not violate the TCP congestion control specification [APS99]. However, the standards (RFC 2581 [APS99]) currently recommend using delayed acknowledgments and DAASS goes (partially) against this recommendation.
DAASSを使用すると、TCPの輻輳制御仕様[APS99]に違反していません。ただし、標準（RFC 2581 [APS99]）は現在、遅れて確認応答を使用することをお勧めしてDAASSは（部分的に）この勧告に反します。
DAASS should work equally well in all scenarios presented in section 2. However, in asymmetric networks it may aggravate ACK congestion in the return link, due to the increased number of ACKs (see sections 3.9 and 3.10 for a more detailed discussion of ACK congestion).
DAASSはしかし、非対称のネットワークでは、それが原因ACKの数が増加し、リターンリンクにおけるACKの混雑を悪化させるのセクション2に示すすべてのシナリオでも同様に動作しなければならない（セクション3.9およびACKの混雑のより詳細な議論のための3.10を参照してください） 。
DAASS has several possible interactions with other proposals made in the research community. DAASS can aggravate congestion on the path between the data receiver and the data sender due to the increased number of returning acknowledgments. This can have an especially adverse effect on asymmetric networks that are prone to experiencing ACK congestion. As outlined in sections 3.9 and 3.10, several mitigations have been proposed to reduce the number of ACKs that are passed over a low-bandwidth return link. Using DAASS will increase the number of ACKs sent by the receiver. The interaction between DAASS and the methods for reducing the number of ACKs is an open research question. Also, as noted in section 3.2.1.5 above, DAASS provides some of the same benefits as using a larger initial congestion window and therefore it may not be desirable to use both mechanisms together. However, this remains an open question. Finally, DAASS and limited byte counting are both used to increase the rate at which the congestion window is opened. The DAASS algorithm substantially reduces the impact limited byte counting has on the rate of congestion window increase.
DAASSは、研究コミュニティで行われた他の提案にはいくつかの相互作用の可能性があります。 DAASS起因肯定応答を返す数の増加にデータ受信機及びデータ送信者との間のパス上の輻輳を悪化させることができます。これはACKの混雑を経験する傾向がある非対称ネットワーク上で特に不利な影響を与える可能性があります。セクション3.9と3.10で概説したように、いくつかの緩和策は、低帯域幅のリターン・リンクを介して渡されるACKの数を減らすために提案されてきました。 DAASSを使用すると、受信機によって送信されたACKの数が増加します。 ACKの数を減らすためのDAASSと方法との間の相互作用は、オープン研究課題です。上記セクション3.2.1.5で述べたように、また、DAASSは、より大きな初期輻輳ウィンドウを使用し、したがって、一緒に両方のメカニズムを使用することは望ましくないかもしれないと同じ利点のいくつかを提供します。しかし、これは未解決の問題のまま。最後に、DAASSと限定されたバイトのカウントは、両方の輻輳ウィンドウを開いされる速度を増大させるために使用されています。 DAASSアルゴリズムは、実質的に影響限られたバイトカウントが輻輳ウィンドウの増加率に対して有する低減します。
The initial slow start phase is used by TCP to determine an appropriate congestion window size for the given network conditions [Jac88]. Slow start is terminated when TCP detects congestion, or when the size of cwnd reaches the size of the receiver's advertised window. Slow start is also terminated if cwnd grows beyond a certain size. The threshold at which TCP ends slow start and begins using the congestion avoidance algorithm is called "ssthresh" [Jac88]. In most implementations, the initial value for ssthresh is the receiver's advertised window. During slow start, TCP roughly doubles the size of cwnd every RTT and therefore can overwhelm the network with at most twice as many segments as the network can handle. By setting ssthresh to a value less than the receiver's advertised window initially, the sender may avoid overwhelming the network with twice the appropriate number of segments. Hoe [Hoe96] proposes using the packet-pair algorithm [Kes91] and the measured RTT to determine a more appropriate value for ssthresh. The algorithm observes the spacing between the first few returning ACKs to determine the bandwidth of the bottleneck link. Together with the measured RTT, the delay*bandwidth product is determined and ssthresh is set to this value. When TCP's cwnd reaches this reduced ssthresh, slow start is terminated and transmission continues using congestion avoidance, which is a more conservative algorithm for increasing the size of the congestion window.
初期スロースタートフェーズは、特定のネットワーク条件[Jac88]のための適切な輻輳ウィンドウサイズを決定するために、TCPによって使用されます。スロースタートは、TCPが輻輳を検出したときに終了、またはCWNDのサイズは、受信者の広告ウィンドウのサイズに達するとされます。 CWNDが一定サイズを超えた場合、スロースタートにも終了されます。 TCPはスロースタートを終了し、輻輳回避アルゴリズムを使用して開始するしきい値は、[Jac88]「SSTHRESH」と呼ばれています。ほとんどの実装では、SSTHRESHの初期値は、受信機の広告ウィンドウです。スロースタート時には、TCPは、およそすべてのRTTのcwndのサイズを倍増し、そのために最も倍ネットワークなどの多くのセグメントを扱うことができるようにネットワークを圧倒することができます。最初に受信機の広告ウィンドウよりも小さい値にSSTHRESHを設定することにより、送信者は、セグメントの二倍の適切な数のネットワークを圧倒回避することができます。鍬は[Hoe96] SSTHRESHのためのより適切な値を決定するために、パケット対アルゴリズム[Kes91]と測定されたRTTを使用して提案しています。このアルゴリズムは、ボトルネックリンクの帯域幅を決定するために、最初の数を返すACKの間の間隔を観察します。一緒に測定されたRTTと、遅延*帯域幅積が決定され、SSTHRESHは、この値に設定されています。 TCPのCWNDが、この減少したSSTHRESHに到達すると、スロースタートが終了し、送信が輻輳ウィンドウのサイズを増やすため、より保守的なアルゴリズムである輻輳回避を、使用し続けています。
It has been shown that estimating ssthresh can improve performance and decrease packet loss in simulations [Hoe96]. However, obtaining an accurate estimate of the available bandwidth in a dynamic network is very challenging, especially attempting to do so on the sending side of the TCP connection [AP99]. Therefore, before this mechanism is widely deployed, bandwidth estimation must be studied in a more detail.
SSTHRESHを推定することは、パフォーマンスを向上させ、[Hoe96]シミュレーションにおけるパケット損失を減少させることができることが示されています。しかし、動的なネットワークで利用可能な帯域幅の正確な推定値を得ることは、特にTCPコネクション[AP99]の送信側にそうしようと、非常に困難です。このメカニズムが広く展開される前に、そのため、帯域幅の推定は、より詳細に検討する必要があります。
As outlined in [Hoe96], estimating ssthresh requires changes to the data sender's TCP stack. As suggested in [AP99], bandwidth estimates may be more accurate when taken by the TCP receiver, and therefore both sender and receiver changes would be required. Estimating ssthresh is safe to implement in production networks from a congestion control perspective, as it can only make TCP more conservative than outlined in RFC 2581 [APS99] (assuming the TCP implementation is using an initial ssthresh of infinity as allowed by [APS99]).
[Hoe96]で概説したように、SSTHRESHを推定すると、データ送信側のTCPスタックを変更する必要があります。 [AP99]で示唆したように、TCP受信機によって撮影された場合、帯域幅推定値がより正確であり、従って双方送信側と受信側の変更が必要とされるであろう。 SSTHRESHを推定する（[APS99]によって許容されるようTCP実装は無限の初期SSTHRESHを使用していると仮定して）それが唯一[APS99] RFC 2581に概説さよりTCPは、より保守的作ることができるように、輻輳制御の観点から生産ネットワークに実装しても安全です。
It is expected that this mechanism will work equally well in all symmetric topologies outlined in section 2. However, asymmetric links pose a special problem, as the rate of the returning ACKs may not be the bottleneck bandwidth in the forward direction. This can lead to the sender setting ssthresh too low. Premature termination of slow start can hurt performance, as congestion avoidance opens cwnd more conservatively. Receiver-based bandwidth estimators do not suffer from this problem.
このメカニズムは返すACKの割合は、順方向のボトルネック帯域ではないかもしれないしかし、非対称リンクは、特別な問題を提起部2に記載されているすべての対称トポロジでも同様に動作することが期待されます。これは低すぎる送信者設定SSTHRESHにつながることができます。輻輳回避は、より保守的にcwndを開くとスロースタートの早期終了は、パフォーマンスを傷つけることができます。レシーバベースの帯域幅推定器は、この問題に悩まされません。
Terminating slow start at the right time is useful to avoid multiple dropped segments. However, using a selective acknowledgment-based loss recovery scheme (as outlined in section 3.3.2) can drastically improve TCP's ability to quickly recover from multiple lost segments Therefore, it may not be as important to terminate slow start before a large loss event occurs. [AP99] shows that using delayed acknowledgments [Bra89] reduces the effectiveness of sender-side bandwidth estimation. Therefore, using delayed ACKs only during slow start (as outlined in section 3.2.3) may make bandwidth estimation more feasible.
適切なタイミングでスロースタートを終了すると、複数のドロップされたセグメントを避けるために便利です。しかし、（セクション3.3.2で概説したように）選択的確認応答ベースの損失回復方式を使用すると、大幅に迅速したがって、複数の失われたセグメントから回復するTCPの能力を向上させることができ、大きな損失事象が発生する前に、スロースタートを終了するように重要ではないかもしれません。 [AP99]は遅延確認応答[Bra89]を使用して送信側の帯域幅推定の有効性を減少させることを示しています。したがって、（セクション3.2.3に概説されるように）スロースタート時だけ遅延ACKを使用すると、帯域幅推定をより実現可能にしてもよいです。
Several similar algorithms have been developed and studied that improve TCP's ability to recover from multiple lost segments in a window of data without relying on the (often long) retransmission timeout. These sender-side algorithms, known as NewReno TCP, do not depend on the availability of selective acknowledgments (SACKs) [MMFR96].
いくつかの同様のアルゴリズムが開発され、それは（多くの場合、長い）再送タイムアウトに依存することなく、データのウィンドウに複数の失われたセグメントから回復するTCPの能力を向上させる研究されています。 NewRenoのTCPとして知られているこれらの送信側アルゴリズムは、選択的確認応答（サックス）[MMFR96]の可用性に依存しません。
These algorithms generally work by updating the fast recovery algorithm to use information provided by "partial ACKs" to trigger retransmissions. A partial ACK covers some new data, but not all data outstanding when a particular loss event starts. For instance, consider the case when segment N is retransmitted using the fast retransmit algorithm and segment M is the last segment sent when segment N is resent. If segment N is the only segment lost, the ACK elicited by the retransmission of segment N would be for segment M. If, however, segment N+1 was also lost, the ACK elicited by the retransmission of segment N will be N+1. This can be taken as an indication that segment N+1 was lost and used to trigger a retransmission.
これらのアルゴリズムは、一般的に再送をトリガするために「部分のACK」によって提供される情報を使用する高速回復アルゴリズムを更新することで動作します。パーシャルACKは、いくつかの新しいデータをカバーしていますが、特定の損失事象の開始時にすべてのデータ卓越したません。例えば、セグメントNは、Mは、セグメントNが再送されたときに送られた最後のセグメントである高速再送アルゴリズムとセグメントを使用して再送された場合を考えます。セグメントNはセグメントのみが失われた場合、セグメントNの再送によって誘発ACKセグメントM.場合のためであろう、しかし、セグメントは、N + 1も失われた、セグメントNの再送によって誘発されるACKは、N + 1になり。これは、セグメントN + 1が失われ、再送をトリガするために使用されたことの指標として解釈することができます。
Hoe [Hoe95,Hoe96] introduced the idea of using partial ACKs to trigger retransmissions and showed that doing so could improve performance. [FF96] shows that in some cases using partial ACKs to trigger retransmissions reduces the time required to recover from multiple lost segments. However, [FF96] also shows that in some cases (many lost segments) relying on the RTO timer can improve performance over simply using partial ACKs to trigger all retransmissions. [HK99] shows that using partial ACKs to trigger retransmissions, in conjunction with SACK, improves performance when compared to TCP using fast retransmit/fast recovery in a satellite environment. Finally, [FH99] describes several slightly different variants of NewReno.
鍬[Hoe95、Hoe96]は、再送信をトリガするために、部分的ACKを使用してのアイデアを紹介し、そうすることが、パフォーマンスを向上させることができることを示しました。 【FF96は】再送をトリガするために部分的ACKを使用していくつかのケースでは、複数の失われたセグメントから回復するのに必要な時間を短縮することを示しています。ただし、[FF96]もRTOタイマーに頼ることは、単純にすべての再送をトリガするために、部分的ACKを使用してよりもパフォーマンスを向上させることができますいくつかのケースでは（多くの失われたセグメント）することを示しています。 [HK99]は衛星環境での高速再送/高速回復を使用してTCPと比較すると、SACKと連携して、再送信をトリガするために、部分的ACKを使用すると、パフォーマンスが向上することを示しています。最後に、[FH99]はNewRenoのいくつかのわずかに異なるバリエーションを説明しています。
Implementing these fast recovery enhancements requires changes to the sender-side TCP stack. These changes can safely be implemented in production networks and are allowed by RFC 2581 [APS99].
これらの高速リカバリ機能強化を実現することは、送信者側のTCPスタックを変更する必要があります。これらの変更は、安全生産ネットワークに実装することができ、RFC 2581 [APS99]で許可されています。
It is expected that these changes will work well in all environments outlined in section 2.
これらの変更は、セクション2に記載されているすべての環境ではうまく動作することが期待されます。
See section 3.3.2.2.5.
セクション3.3.2.2.5を参照してください。
Fall and Floyd [FF96] describe a conservative extension to the fast recovery algorithm that takes into account information provided by selective acknowledgments (SACKs) [MMFR96] sent by the receiver. The algorithm starts after fast retransmit triggers the resending of a segment. As with fast retransmit, the algorithm cuts cwnd in half when a loss is detected. The algorithm keeps a variable called "pipe", which is an estimate of the number of outstanding segments in the network. The pipe variable is decremented by 1 segment for each duplicate ACK that arrives with new SACK information. The pipe variable is incremented by 1 for each new or retransmitted segment sent. A segment may be sent when the value of pipe is less than cwnd (this segment is either a retransmission per the SACK information or a new segment if the SACK information indicates that no more retransmits are needed).
【FF96は、受信機によって送信された[MMFR96]アカウントに選択的肯定応答（サック）によって提供される情報を取り、高速回復アルゴリズムに保守的な拡張を記述落下しフロイド。高速再送セグメントの再送をトリガーした後、アルゴリズムが開始されます。損失が検出されたときに高速再送と同じように、アルゴリズムのカットは半分にcwndを。アルゴリズムは、ネットワーク内の未処理のセグメントの数の推定値である「パイプ」と呼ばれる変数を維持します。パイプ変数は新しいSACK情報が到着する各重複ACKのための1つのセグメントだけデクリメントされます。パイプ変数は送信された各新規又は再送セグメントに1だけインクリメントされます。パイプの値が（SACK情報がもはや再送が必要とされないことを示す場合、このセグメントは、SACK情報ごとに再送または新しいセグメントのいずれかである）CWND未満である場合にセグメントが送信されてもよいです。
This algorithm generally allows TCP to recover from multiple segment losses in a window of data within one RTT of loss detection. Like the forward acknowledgment (FACK) algorithm described below, the SACK information allows the pipe algorithm to decouple the choice of when to send a segment from the choice of what segment to send.
このアルゴリズムは、一般的にTCPは、ロス検出のRTT内のデータのウィンドウ内の複数のセグメントの損失から回復することを可能にします。以下に記載するフォワード確認（FACK）アルゴリズムのような、SACK情報がパイプアルゴリズムが送信するものセグメントの選択からのセグメントを送信するときの選択肢を分離することを可能にします。
[APS99] allows the use of this algorithm, as it is consistent with the spirit of the fast recovery algorithm.
それは高速回復アルゴリズムの精神と一致しているとして、[APS99]、このアルゴリズムを使用することができます。
[FF96] shows that the above described SACK algorithm performs better than several non-SACK based recovery algorithms when 1--4 segments are lost from a window of data. [AHKO97] shows that the algorithm improves performance over satellite links. Hayes [Hay97] shows the in certain circumstances, the SACK algorithm can hurt performance by generating a large line-rate burst of data at the end of loss recovery, which causes further loss.
【FF96は】1--4セグメントがデータのウィンドウで失われた場合に、上述のSACKアルゴリズムは、いくつかの非SACKベースのリカバリアルゴリズムよりも良好に機能することを示しています。 [AHKO97]アルゴリズムは、衛星リンクでのパフォーマンスを改善することを示しています。ヘイズは、[Hay97]さらなる損失を引き起こす損失回復の終わりに大量のデータラインレートのバーストを生成することにより、特定の状況において、SACKアルゴリズムを傷つけることができる性能を示しています。
This algorithm is implemented in the sender's TCP stack. However, it relies on SACK information generated by the receiver. This algorithm is safe for shared networks and is allowed by RFC 2581 [APS99].
このアルゴリズムは、送信者のTCPスタックに実装されています。しかし、それは、受信機によって生成されたSACK情報に依存しています。このアルゴリズムは、共有ネットワークのための安全であり、RFC 2581 [APS99]で許可されています。
It is expected that the pipe algorithm will work equally well in all scenarios presented in section 2.
パイプのアルゴリズムは、2節で提示されたすべてのシナリオでも同様に動作することが期待されます。
See section 3.3.2.2.5.
セクション3.3.2.2.5を参照してください。
The Forward Acknowledgment (FACK) algorithm [MM96a,MM96b] was developed to improve TCP congestion control during loss recovery. FACK uses TCP SACK options to glean additional information about the congestion state, adding more precise control to the injection of data into the network during recovery. FACK decouples the congestion control algorithms from the data recovery algorithms to provide a simple and direct way to use SACK to improve congestion control. Due to the separation of these two algorithms, new data may be sent during recovery to sustain TCP's self-clock when there is no further data to retransmit.
回送肯定応答（FACK）アルゴリズム[MM96a、MM96b]は損失回復中のTCP輻輳制御を改善するために開発されました。 FACKは、リカバリ時にネットワークへのデータの注入により正確なコントロールを追加、輻輳状態に関する追加情報を収集するためにTCPのSACKオプションを使用しています。 FACK輻輳制御を改善するためにSACKを使用するためのシンプルで直接的な方法を提供するために、データ復旧アルゴリズムから輻輳制御アルゴリズムを切り離します。再送するそれ以上のデータが存在しない場合に起因するこれら2つのアルゴリズムの分離に、新しいデータは、TCPの自己クロックを維持するために、回復中に送信することができます。
The most recent version of FACK is Rate-Halving [MM96b], in which one packet is sent for every two ACKs received during recovery. Transmitting a segment for every-other ACK has the result of reducing the congestion window in one round trip to half of the number of packets that were successfully handled by the network (so when cwnd is too large by more than a factor of two it still gets reduced to half of what the network can sustain). Another important aspect of FACK with Rate-Halving is that it sustains the ACK self-clock during recovery because transmitting a packet for every-other ACK does not require half a cwnd of data to drain from the network before transmitting, as required by the fast recovery algorithm [Ste97,APS99].
FACKの最新バージョンは、一つのパケットが回復中に受信したすべての2個のACKのために送られたレートを半減[MM96b]、です。すべて、他のためのセグメントを送信するACKのでCWNDは、それがまだ2倍以上大きくなりすぎると（正常にネットワークによって処理されたパケットの数の半分に1つの往復の輻輳ウィンドウを減少させる結果を有します）ネットワークを維持することができるものの半分に減少します。レート-半減とFACKのもう一つの重要な側面は、送信する前に、ネットワークから排出するためのデータの半分のcwndを必要としないおきにACKのためのパケットを送信するので、高速で必要とされるそれは、リカバリ中にACK自己クロックを維持することをあります回復アルゴリズム[Ste97、APS99]。
In addition, the FACK with Rate-Halving implementation provides Thresholded Retransmission to each lost segment. "Tcprexmtthresh" is the number of duplicate ACKs required by TCP to trigger a fast retransmit and enter recovery. FACK applies thresholded retransmission to all segments by waiting until tcprexmtthresh SACK blocks indicate that a given segment is missing before resending the segment. This allows reasonable behavior on links that reorder segments. As described above, FACK sends a segment for every second ACK received during recovery. New segments are transmitted except when tcprexmtthresh SACK blocks have been observed for a dropped segment, at which point the dropped segment is retransmitted.
また、レート半減実装とFACK各失われたセグメントに閾値再送信を提供します。 「Tcprexmtthreshは、」高速再送信をトリガと回復を入力するためにTCPで必要な重複ACKの数です。 FACKはtcprexmtthresh SACKブロックが与えられたセグメントは、セグメントを再送信する前に欠落していることを示すまで待機することにより、全てのセグメントに閾値化再送を適用します。これは、セグメントの順序を変更するリンク上で、合理的な行動を可能にします。上述したように、FACKは回復中に受信毎秒ACKのためのセグメントを送信します。新しいセグメントはtcprexmtthresh SACKブロックがドロップセグメントが再送された時点でドロップセグメントのために観察されている場合を除いて伝送されます。
[APS99] allows the use of this algorithm, as it is consistent with the spirit of the fast recovery algorithm.
それは高速回復アルゴリズムの精神と一致しているとして、[APS99]、このアルゴリズムを使用することができます。
The original FACK algorithm is outlined in [MM96a]. The algorithm was later enhanced to include Rate-Halving [MM96b]. The real-world performance of FACK with Rate-Halving was shown to be much closer to the theoretical maximum for TCP than either TCP Reno or the SACK-based extensions to fast recovery outlined in section 3.3.2.1 [MSMO97].
オリジナルFACKアルゴリズム[MM96a]に概説されています。このアルゴリズムは、後のレートを半減[MM96b]が含まれるように拡張されました。レート-半減とFACKの実世界でのパフォーマンスは、[MSMO97]セクション3.3.2.1で概説した高速復旧へのTCPリノまたはSACKベースの拡張機能のいずれかよりもTCPのための理論上の最大値に非常に近いことが示されました。
In order to use FACK, the sender's TCP stack must be modified. In addition, the receiver must be able to generate SACK options to obtain the full benefit of using FACK. The FACK algorithm is safe for shared networks and is allowed by RFC 2581 [APS99].
FACKを使用するためには、送信者のTCPスタックを変更する必要があります。また、受信機はFACKを使用しての完全な利益を得るために、SACKオプションを生成することができなければなりません。 FACKアルゴリズムは、共有ネットワークのために安全であり、RFC 2581 [APS99]で許可されています。
FACK is expected to improve performance in all environments outlined in section 2. Since it is better able to sustain its self-clock than TCP Reno, it may be considerably more attractive over long delay paths.
FACKは、TCPリノより自己のクロックを維持するより良いことができるので、セクション2で概説したすべての環境での性能を改善することが期待され、それは長い遅延経路上かなり魅力的であってもよいです。
Both SACK based loss recovery algorithms described above (the fast recovery enhancement and the FACK algorithm) are similar in that they attempt to effectively repair multiple lost segments from a window of data. Which of the SACK-based loss recovery algorithms to use is still an open research question. In addition, these algorithms are similar to the non-SACK NewReno algorithm described in section 3.3.1, in that they attempt to recover from multiple lost segments without reverting to using the retransmission timer. As has been shown, the above SACK based algorithms are more robust than the NewReno algorithm. However, the SACK algorithm requires a cooperating TCP receiver, which the NewReno algorithm does not. A reasonable TCP implementation might include both a SACK-based and a NewReno-based loss recovery algorithm such that the sender can use the most appropriate loss recovery algorithm based on whether or not the receiver supports SACKs. Finally, both SACK-based and non-SACK-based versions of fast recovery have been shown to transmit a large burst of data upon leaving loss recovery, in some cases [Hay97]. Therefore, the algorithms may benefit from some burst suppression algorithm.
（高速回復エンハンスメントとFACKアルゴリズム）上述の両方のSACKベースの損失回復アルゴリズムは、それらが効果的にデータのウィンドウから複数の失われたセグメントを修復しようとするという点で類似しています。 SACKベースの損失回復アルゴリズムのどちらを使用するにはまだ開いて研究課題です。加えて、これらのアルゴリズムは、それらが再送タイマを使用して元に戻すことなく、複数の失われたセグメントから回復しようとすると、セクション3.3.1に記載した非SACKのNewRenoのアルゴリズムと同様です。示されているように、上記SACKベースのアルゴリズムは、NewRenoのアルゴリズムよりも頑強です。しかし、SACKアルゴリズムはNewRenoのアルゴリズムにはない協力TCP受信機が必要です。合理的なTCPの実装はSACKベースと送信者が受信機が袋をサポートしているかどうかに基づいて、最も適切な損失回復アルゴリズムを使用することができるようにNewRenoのベースの損失回復アルゴリズムの両方が含まれる場合があります。最後に、高速リカバリのSACKベースおよび非SACKベースのバージョンの両方がある場合[Hay97]において、損失回復を出る際に大量のデータバーストを送信することが示されています。したがって、アルゴリズムは、いくつかのバースト抑制アルゴリズムから利益を得ることができます。
Explicit congestion notification (ECN) allows routers to inform TCP senders about imminent congestion without dropping segments. Two major forms of ECN have been studied. A router employing backward ECN (BECN), transmits messages directly to the data originator informing it of congestion. IP routers can accomplish this with an ICMP Source Quench message. The arrival of a BECN signal may or may not mean that a TCP data segment has been dropped, but it is a clear indication that the TCP sender should reduce its sending rate (i.e., the value of cwnd). The second major form of congestion notification is forward ECN (FECN). FECN routers mark data segments with a special tag when congestion is imminent, but forward the data segment. The data receiver then echos the congestion information back to the sender in the ACK packet. A description of a FECN mechanism for TCP/IP is given in [RF99].
明示的輻輳通知（ECN）はルータがセグメントを落とすことなく、切迫輻輳約TCP送信者に通知することを可能にします。 ECNの2つの主要な形態が検討されています。後方ECN（BECN）を用いたルータは、輻輳を知らせるデータの発信元に直接メッセージを送信します。 IPルータはICMPソースクエンチメッセージでこれを達成することができます。 BECN信号の到着は、またはTCPデータセグメントが削除されたことを意味してもしなくてもよいが、TCP送信者は、その送信速度（CWNDのすなわち値）を減少させるべきであることを明確に示しています。輻輳通知の第二の主要な形態は、前方ECN（FECN）です。 FECNルータは輻輳が差し迫っている特別なタグを有するデータセグメントをマークするが、データのセグメントを転送します。データ受信機は、ACKパケット内の送信元に戻って渋滞情報をエコー表示します。 TCP / IPのためのFECN機構の説明は[RF99]で与えられます。
As described in [RF99], senders transmit segments with an "ECN-Capable Transport" bit set in the IP header of each packet. If a router employing an active queueing strategy, such as Random Early Detection (RED) [FJ93,BCC+98], would otherwise drop this segment, an "Congestion Experienced" bit in the IP header is set instead. Upon reception, the information is echoed back to TCP senders using a bit in the TCP header. The TCP sender adjusts the congestion window just as it would if a segment was dropped.
[RF99]に記載されているように、送信者は、各パケットのIPヘッダに設定されている「ECN-可能な交通」ビットを有するセグメントを送信します。そのようなランダム早期検出（RED）[FJ93、BCC + 98]、などのアクティブキューイング戦略を用いるルータは、そうでなければ、このセグメントをドロップするならば、IPヘッダ内の「輻輳経験」ビットが代わりに設定されています。受信した情報は、TCPヘッダ内のビットを使用して、TCP送信者にエコーバックされます。 TCPの送信者は、それは、セグメントが削除されたかどう同じように輻輳ウィンドウを調整します。
The implementation of ECN as specified in [RF99] requires the deployment of active queue management mechanisms in the affected routers. This allows the routers to signal congestion by sending TCP a small number of "congestion signals" (segment drops or ECN messages), rather than discarding a large number of segments, as can happen when TCP overwhelms a drop-tail router queue.
[RF99]で指定されるようにECNの実装では、影響を受けたルータ内のアクティブキュー管理機構の展開を必要とします。これは、ルータがTCPドロップテイルルータのキューを圧倒する場合に発生することができるように、「混雑信号」の少数（セグメントが低下またはECNメッセージ）TCPの送信ではなく、多数のセグメントを破棄することによって、輻輳をシグナリングすることを可能にします。
Since satellite networks generally have higher bit-error rates than terrestrial networks, determining whether a segment was lost due to congestion or corruption may allow TCP to achieve better performance in high BER environments than currently possible (due to TCP's assumption that all loss is due to congestion). While not a solution to this problem, adding an ECN mechanism to TCP may be a part of a mechanism that will help achieve this goal. See section 3.3.4 for a more detailed discussion of differentiating between corruption and congestion based losses.
衛星ネットワークは、一般的に起因する全ての損失がによるものであることをTCPの仮定に（セグメントが輻輳や破損のために失われたかどうかを決定することは、TCPが現在可能であるよりも高いBER環境で優れた性能を達成することを可能にする、地上ネットワークよりも高いビット・エラー・レートを持っているので、混雑）。この問題の解決策ではないが、TCPにECNメカニズムを追加すると、この目標を達成するのに役立ちますメカニズムの一部であってもよいです。腐敗と輻輳ベースの損失とを区別するのより詳細な議論についてはセクション3.3.4を参照してください。
[Flo94] shows that ECN is effective in reducing the segment loss rate which yields better performance especially for short and interactive TCP connections. Furthermore, [Flo94] also shows that ECN avoids some unnecessary, and costly TCP retransmission timeouts. Finally, [Flo94] also considers some of the advantages and disadvantages of various forms of explicit congestion notification.
【Flo94] ECNは、特に短いと対話TCP接続の良好な性能をもたらすセグメント損失率を低減するのに有効であることを示しています。また、[Flo94]また、ECNは、いくつかの不要な、かつ高価なTCP再送タイムアウトを回避することを示しています。最後に、[Flo94]また、明示的輻輳通知の様々な形態の利点と欠点のいくつかを考慮する。
Deployment of ECN requires changes to the TCP implementation on both sender and receiver. Additionally, deployment of ECN requires deployment of some active queue management infrastructure in routers. RED is assumed in most ECN discussions, because RED is already identifying segments to drop, even before its buffer space is exhausted. ECN simply allows the delivery of "marked" segments while still notifying the end nodes that congestion is occurring along the path. ECN is safe (from a congestion control perspective) for shared networks, as it maintains the same TCP congestion control principles as are used when congestion is detected via segment drops.
ECNの展開は、送信者と受信者の両方でTCPの実装を変更する必要があります。さらに、ECNの配備は、ルータでいくつかのアクティブキュー管理インフラストラクチャを展開する必要があります。 REDはすでにそのバッファ空間が排出される前であっても、ドロップするセグメントを識別しているので、REDは、ほとんどのECNの議論で想定されます。依然として輻輳が経路に沿って発生しているエンド・ノードを通知しつつECNは、単に「マーク」セグメントの送達を可能にします。それはセグメントが低下介して輻輳が検出されたときに使用されるのと同じTCP輻輳制御の原則を維持するようECNは、共有ネットワークのための（輻輳制御の観点から）安全です。
It is expected that none of the environments outlined in section 2 will present a bias towards or against ECN traffic.
セクション2で概説環境のいずれもに向かってまたはECNトラフィックに対してバイアスを提示しないことが予想されます。
Note that some form of active queueing is necessary to use ECN (e.g., RED queueing).
アクティブなキューイングのいくつかの形態がECN（例えば、REDキューイング）を使用する必要があることに留意されたいです。
Differentiating between congestion (loss of segments due to router buffer overflow or imminent buffer overflow) and corruption (loss of segments due to damaged bits) is a difficult problem for TCP. This differentiation is particularly important because the action that TCP should take in the two cases is entirely different. In the case of corruption, TCP should merely retransmit the damaged segment as soon as its loss is detected; there is no need for TCP to adjust its congestion window. On the other hand, as has been widely discussed above, when the TCP sender detects congestion, it should immediately reduce its congestion window to avoid making the congestion worse.
そして破損（損傷ビットによるセグメントの損失）輻輳区別（ルータバッファオーバーフローまたは切迫バッファオーバーフローによるセグメントの損失）は、TCPのために困難な問題です。 TCPは、2つの場合に取るべき行動は完全に異なっているので、この区別は特に重要です。破損の場合には、TCPは、単にすぐに損失が検出されると破損セグメントを再送信すべきです。 TCPはその輻輳ウィンドウを調整するための必要はありません。一方、TCPの送信側が輻輳を検出した場合に、広く、上述したように、それはすぐに渋滞が悪化することを避けるために、その輻輳ウィンドウを減らす必要があります。
TCP's defined behavior, as motivated by [Jac88,Jac90] and defined in [Bra89,Ste97,APS99], is to assume that all loss is due to congestion and to trigger the congestion control algorithms, as defined in [Ste97,APS99]. The loss may be detected using the fast retransmit algorithm, or in the worst case is detected by the expiration of TCP's retransmission timer.
TCPの定義された動作は、[Jac88、Jac90]によって動機付けと[Bra89、Ste97、APS99]で定義されるように、[Ste97、APS99]で定義されるように、すべての損失が輻輳によるものであると仮定すると、輻輳制御アルゴリズムをトリガすることです。損失は、高速再送アルゴリズムを使用して検出することができる、あるいは最悪の場合にはTCPの再送タイマの満了によって検出されます。
TCP's assumption that loss is due to congestion rather than corruption is a conservative mechanism that prevents congestion collapse [Jac88,FF98]. Over satellite networks, however, as in many wireless environments, loss due to corruption is more common than on terrestrial networks. One common partial solution to this problem is to add Forward Error Correction (FEC) to the data that's sent over the satellite/wireless link. A more complete discussion of the benefits of FEC can be found in [AGS99]. However, given that FEC does not always work or cannot be universally applied, other mechanisms have been studied to attempt to make TCP able to differentiate between congestion-based and corruption-based loss.
損失が輻輳なく破損に起因することTCPの仮定は、輻輳崩壊[Jac88、FF98]を防ぐ保存的機構です。衛星ネットワークを介して、しかし、多くの無線環境のように、腐敗による損失は、地上ネットワーク上よりも一般的です。この問題の一つの共通部分的な解決策は、衛星/無線リンクを介して送信されたデータへの前方誤り訂正（FEC）を追加することです。 FECの利点のより完全な議論は[AGS99]で見つけることができます。しかし、FECが常に動作しないか、普遍的に適用できないことを考えると、他のメカニズムは、輻輳ベースと腐敗ベースの損失を区別するTCPができるにしようとして研究されてきました。
TCP segments that have been corrupted are most often dropped by intervening routers when link-level checksum mechanisms detect that an incoming frame has errors. Occasionally, a TCP segment containing an error may survive without detection until it arrives at the TCP receiving host, at which point it will almost always either fail the IP header checksum or the TCP checksum and be discarded as in the link-level error case. Unfortunately, in either of these cases, it's not generally safe for the node detecting the corruption to return information about the corrupt packet to the TCP sender because the sending address itself might have been corrupted.
破損したTCPセグメントは、ほとんどの場合、リンクレベルのチェックサムメカニズムは、着信フレームにエラーがあることを検出したときにルーターを介在によって廃棄されます。それはほとんど常にいずれかのIPヘッダチェックサムまたはTCPチェックサムが失敗し、リンクレベルエラーと同様に廃棄されるこの時点でTCP受信ホストに到達するまで時々、エラーを含むTCPセグメントが検出せずに生き残ることができます。残念ながら、これらのいずれかの場合、それは一般的に、送信アドレス自体が破損している可能性があるため、TCPの送信者に破損したパケットに関する情報を返すために破損を検出したノードのために安全ではありません。
Because the probability of link errors on a satellite link is relatively greater than on a hardwired link, it is particularly important that the TCP sender retransmit these lost segments without reducing its congestion window. Because corrupt segments do not indicate congestion, there is no need for the TCP sender to enter a congestion avoidance phase, which may waste available bandwidth. Simulations performed in [SF98] show a performance improvement when TCP can properly differentiate between between corruption and congestion of wireless links.
衛星リンク上のリンクエラーの確率がハードワイヤードリンク上よりも相対的に大きいので、TCPの送信側がその輻輳ウィンドウを低下させることなく、これらの失われたセグメントを再送信することが特に重要です。破損しているセグメントが輻輳を示すものではありませんので、利用可能な帯域幅を浪費することが輻輳回避フェーズに入るためのTCP送信側、する必要はありません。 【SF98]で行ったシミュレーションでは、TCPが適切に破損及び無線リンクの混雑の間を区別することができ、性能の改善を示します。
Perhaps the greatest research challenge in detecting corruption is getting TCP (a transport-layer protocol) to receive appropriate information from either the network layer (IP) or the link layer. Much of the work done to date has involved link-layer mechanisms that retransmit damaged segments. The challenge seems to be to get these mechanisms to make repairs in such a way that TCP understands what happened and can respond appropriately.
おそらく、破損を検出する際の最大の研究課題は、ネットワーク層（IP）、またはリンク層のいずれかから適切な情報を受け取るためにTCP（トランスポート層プロトコル）を取得しています。これまでに行った作業の多くは、損傷したセグメントを再送リンク層メカニズムを含んでいました。課題は、これらのメカニズムは、TCPは何が起こったのかを理解し、適切に対応できるような方法で修理を行うために取得するためのようです。
Research into corruption detection to date has focused primarily on making the link level detect errors and then perform link-level retransmissions. This work is summarized in [BKVP97,BPSK96]. One of the problems with this promising technique is that it causes an effective reordering of the segments from the TCP receiver's point of view. As a simple example, if segments A B C D are sent across a noisy link and segment B is corrupted, segments C and D may have already crossed the link before B can be retransmitted at the link level, causing them to arrive at the TCP receiver in the order A C D B. This segment reordering would cause the TCP receiver to generate duplicate ACKs upon the arrival of segments C and D. If the reordering was bad enough, the sender would trigger the fast retransmit algorithm in the TCP sender, in response to the duplicate ACKs. Research presented in [MV98] proposes the idea of suppressing or delaying the duplicate ACKs in the reverse direction to counteract this behavior. Alternatively, proposals that make TCP more robust in the face of re-ordered segment arrivals [Flo99] may reduce the side effects of the re-ordering caused by link-layer retransmissions.
現在までの破損の検出の研究は、リンクレベルがエラーを検出してからリンクレベルの再送信を実行することに主に焦点を当てています。この作業は、[BKVP97、BPSK96]に要約されています。この有望な技術の問題点の一つは、それがビューのTCP受信機の視点からのセグメントの効果的な並べ替えを引き起こすことがあります。簡単な例として、セグメントABCDが騒々しいリンクを介して送信され、セグメントBが破損している場合、セグメントCおよびDは、既に有していてもよいBがでTCP受信機に到達するためにそれらを引き起こし、リンクレベルで再送信することができる前に、リンクを横断しましたオーダーACD B.このセグメントの並べ替えは、並べ替えが十分に悪かった場合はTCP受信機はセグメントCおよびDの到着時に重複ACKを生成する原因となる、送信者が重複に応じて、TCP送信側で高速再送アルゴリズムをトリガーしますACKを。 [MV98]で提示研究は、この動作に対抗するために逆方向に重複ACKを抑制または遅延のアイデアを提案しています。また、再注文したセグメントの到着の顔にTCPをより強固にする提案が[Flo99]リンク層再送信によって引き起こされる再発注の副作用を減らすことができます。
A more high-level approach, outlined in the [DMT96], uses a new "corruption experienced" ICMP error message generated by routers that detect corruption. These messages are sent in the forward direction, toward the packet's destination, rather than in the reverse direction as is done with ICMP Source Quench messages. Sending the error messages in the forward direction allows this feedback to work over asymmetric paths. As noted above, generating an error message in response to a damaged packet is problematic because the source and destination addresses may not be valid. The mechanism outlined in [DMT96] gets around this problem by having the routers maintain a small cache of recent packet destinations; when the router experiences an error rate above some threshold, it sends an ICMP corruption-experienced message to all of the destinations in its cache. Each TCP receiver then must return this information to its respective TCP sender (through a TCP option). Upon receiving an ACK with this "corruption-experienced" option, the TCP sender assumes that packet loss is due to corruption rather than congestion for two round trip times (RTT) or until it receives additional link state information (such as "link down", source quench, or additional "corruption experienced" messages). Note that in shared networks, ignoring segment loss for 2 RTTs may aggravate congestion by making TCP unresponsive.
【DMT96]に概説され、より高レベルのアプローチは、新たな破損を検出ルータによって生成されたICMPエラーメッセージを「腐敗が経験」を使用します。これらのメッセージは、むしろICMPソースクエンチメッセージで行われるように逆方向よりも、パケットの宛先に向かって、順方向に送信されます。順方向にエラーメッセージを送信すると、このフィードバックは、非対称パス上で動作することができます。上述したように、送信元と宛先アドレスが有効ではないかもしれないので、破損パケットに応答してエラーメッセージを生成することは問題があります。 [DMT96]で概説したメカニズムは、ルータが、最近のパケットの宛先の小さなキャッシュを維持することによってこの問題を回避して、ルータがある閾値以上のエラー率を経験するとき、それは、そのキャッシュ内の目的地のすべてにICMPの破損-経験メッセージを送信します。各TCP受信機はその後、（TCPオプションを使用して）、それぞれのTCP送信者にこの情報を返す必要があります。この「腐敗-経験豊富」オプションを使用してACKを受信すると、TCPの送信者は、パケットロスが破損によるものであることを前提としてというよりも2往復時間（RTT）のための輻輳や、それは追加のリンク状態情報を受信するまで（例えば、「リンクダウン」など、ソースクエンチ、または追加の）メッセージを「腐敗が経験しました」。共有ネットワークでは、2つのRTTのセグメント損失を無視すると、TCPは応答しないことによって、輻輳を悪化させることができることに留意されたいです。
All of the techniques discussed above require changes to at least the TCP sending and receiving stacks, as well as intermediate routers. Due to the concerns over possibly ignoring congestion signals (i.e., segment drops), the above algorithm is not recommended for use in shared networks.
上述の技術の全ては、少なくともスタックを送受信TCP、ならびに中間ルータの変更を必要とします。おそらく無視混雑信号（すなわち、セグメントが低下）に対する懸念のために、上記のアルゴリズムは、共有ネットワークで使用するために推奨されません。
It is expected that corruption detection, in general would be beneficial in all environments outlined in section 2. It would be particularly beneficial in the satellite/wireless environment over which these errors may be more prevalent.
一般的に破損検出は、セクション2で概説したすべての環境で、これらのエラーはより一般的であってもよいにわたって衛星/無線環境において特に有益であることが有益であろうことが予想されます。
SACK-based loss recovery algorithms (as described in 3.3.2) may reduce the impact of corrupted segments on mostly clean links because recovery will be able to happen more rapidly (and without relying on the retransmission timer). Note that while SACK-based loss recovery helps, throughput will still suffer in the face of non-congestion related packet loss.
回復がより迅速に起こる（再送タイマーに依存せずに）できるようになるので、SACKベースの損失回復アルゴリズムは、（3.3.2に記載したように）ほとんどきれいなリンク上の破損セグメントの影響を低減することができます。 SACKベースの損失回復を助けながら、スループットは依然として非輻輳関連のパケット損失の顔に苦しむことに注意してください。
During congestion avoidance, in the absence of loss, the TCP sender adds approximately one segment to its congestion window during each RTT [Jac88,Ste97,APS99]. Several researchers have observed that this policy leads to unfair sharing of bandwidth when multiple connections with different RTTs traverse the same bottleneck link, with the long RTT connections obtaining only a small fraction of their fair share of the bandwidth.
輻輳回避中、損失の非存在下で、TCP送信側は各RTT [Jac88、Ste97、APS99]中の混雑ウィンドウにほぼ一つのセグメントを追加します。いくつかの研究者が異なるのRTTを持つ複数の接続が同じボトルネックリンクを通過する際に、このポリシーは、帯域幅の公正な取り分のごく一部を取得し、長いRTT接続で、帯域幅の不公平共有につながることを観察しました。
One effective solution to this problem is to deploy fair queueing and TCP-friendly buffer management in network routers [Sut98]. However, in the absence of help from the network, other researchers have investigated changes to the congestion avoidance policy at the TCP sender, as described in [Flo91,HK98].
この問題に対する一つの効果的なソリューションは、ネットワークルータ[Sut98]で公正なキューイングおよびTCPフレンドリーなバッファ管理を展開することです。しかし、ネットワークからの助けがない状態で、他の研究者は、[Flo91、HK98]で説明したように、TCP送信側での輻輳回避ポリシーへの変更を検討してきました。
The "Constant-Rate" increase policy has been studied in [Flo91,HK98]. It attempts to equalize the rate at which TCP senders increase their sending rate during congestion avoidance. Both [Flo91] and [HK98] illustrate cases in which the "Constant-Rate" policy largely corrects the bias against long RTT connections, although [HK98] presents some evidence that such a policy may be difficult to incrementally deploy in an operational network. The proper selection of a constant (for the constant rate of increase) is an open issue.
「定レート」の増加ポリシーは[Flo91、HK98]で研究されてきました。これは、TCPの送信者は輻輳回避中に自分の送信レートを上げる速度を等しくしようとします。両方の[Flo91]および[HK98]は[HK98は、このようなポリシーは、増分運用ネットワークに展開することは困難であるといういくつかの証拠を提示しているが、「恒率」ポリシーが大きく、長いRTT接続に対してバイアスを補正する場合を示しています。 （増加の一定の割合のための）定数を適切に選択するには、未解決の問題です。
The "Increase-by-K" policy can be selectively used by long RTT connections in a heterogeneous environment. This policy simply changes the slope of the linear increase, with connections over a given RTT threshold adding "K" segments to the congestion window every RTT, instead of one. [HK98] presents evidence that this policy, when used with small values of "K", may be successful in reducing the unfairness while keeping the link utilization high, when a small number of connections share a bottleneck link. The selection of the constant "K," the RTT threshold to invoke this policy, and performance under a large number of flows are all open issues.
「増やす-により-K」ポリシーが選択的に異機種環境での長いRTT接続で使用することができます。このポリシーは、単に代わりに1つ、所定のRTTの閾値を超える接続が輻輳ウィンドウごとにRTTに「K」セグメントを追加して、線形増加の傾きを変化させます。 【HK98は、「K」の小さな値で使用される場合、このポリシーは、接続の数が少ないボトルネックリンクを共有する場合、高いリンク利用率を維持しながら不公平を低減するのに成功することができるという証拠を提示します。フローの多数の下で定数「K」このポリシーを起動するRTTしきい値、および性能の選択は、開いているすべての問題です。
Implementation of either the "Constant-Rate" or "Increase-by-K" policies requires a change to the congestion avoidance mechanism at the TCP sender. In the case of "Constant-Rate," such a change must be implemented globally. Additionally, the TCP sender must have a reasonably accurate estimate of the RTT of the connection. The algorithms outlined above violate the congestion avoidance algorithm as outlined in RFC 2581 [APS99] and therefore should not be implemented in shared networks at this time.
「定レート」または「増やす-Kによる」政策のいずれかの実装は、TCPの送信側の輻輳回避メカニズムを変更する必要があります。以下の場合は、「定速、」このような変更は、世界的に実装する必要があります。また、TCPの送信者は、接続のRTTの合理的に正確な見積もりを持っている必要があります。上記で概説したアルゴリズムは、RFC 2581に概説されるように[APS99]輻輳回避アルゴリズムに違反するため、この時点で、共有ネットワークに実装されるべきではありません。
These solutions are applicable to all satellite networks that are integrated with a terrestrial network, in which satellite connections may be competing with terrestrial connections for the same bottleneck link.
これらのソリューションは、衛星接続が同じボトルネックリンクのための地上の接続と競合することが可能な地上ネットワークに統合されているすべての衛星ネットワークにも適用可能です。
As shown in [PADHV99], increasing the congestion window by multiple segments per RTT can cause TCP to drop multiple segments and force a retransmission timeout in some versions of TCP. Therefore, the above changes to the congestion avoidance algorithm may need to be accompanied by a SACK-based loss recovery algorithm that can quickly repair multiple dropped segments.
RTTごとに複数のセグメントによって混雑ウィンドウを増加させる、[PADHV99]に示すように複数のセグメントをドロップし、TCPのいくつかのバージョンでは、再送タイムアウトを強制的にTCPを引き起こす可能性があります。したがって、輻輳回避アルゴリズムに上記の変更はすぐに複数のセグメントをドロップ修復できSACKベースの損失回復アルゴリズムを伴うする必要があるかもしれません。
One method that has been used to overcome TCP's inefficiencies in the satellite environment is to use multiple TCP flows to transfer a given file. The use of N TCP connections makes the sender N times more aggressive and therefore can improve throughput in some situations. Using N multiple TCP connections can impact the transfer and the network in a number of ways, which are listed below.
サテライト環境でのTCPの非効率性を克服するために使用されている1つの方法は、指定されたファイルを転送するために、複数のTCPフローを使用することです。 NのTCP接続の使用は、送信者N倍がより積極的になり、したがって、いくつかの状況でスループットを向上させることができます。 N複数のTCP接続を使用して、以下に記載されている多くの方法で転送し、ネットワークに影響を与えることができます。
1. The transfer is able to start transmission using an effective congestion window of N segments, rather than a single segment as one TCP flow uses. This allows the transfer to more quickly increase the effective cwnd size to an appropriate size for the given network. However, in some circumstances an initial window of N segments is inappropriate for the network conditions. In this case, a transfer utilizing more than one connection may aggravate congestion.
1.転送は、N個のセグメントの有効な混雑ウィンドウではなく、1つのTCPフローの用途として、単一のセグメントを使用して送信を開始することができます。これは、転送がより迅速に特定のネットワークのために適切なサイズに有効なCWNDのサイズを大きくすることを可能にします。しかし、いくつかの状況において、N個のセグメントの最初のウィンドウは、ネットワーク条件のために不適切です。この場合、複数の接続を利用し転送が渋滞を悪化させる可能性があります。
2. During the congestion avoidance phase, the transfer increases the effective cwnd by N segments per RTT, rather than the one segment per RTT increase that a single TCP connection provides. Again, this can aid the transfer by more rapidly increasing the effective cwnd to an appropriate point. However, this rate of increase can also be too aggressive for the network conditions. In this case, the use of multiple data connections can aggravate congestion in the network.
輻輳回避フェーズ2は、転送ではなく、単一のTCP接続が提供RTT増加ごとにセグメントよりも、RTTごとにN個のセグメントによって有効CWNDが増加します。再び、これは、より迅速に適切なポイントに有効にcwndを増加させることにより転写を助けることができます。しかし、増加のこのレートは、ネットワーク条件のために、あまりにも積極的にすることができます。この場合、複数のデータ接続を使用することは、ネットワークの輻輳を悪化させることができます。
3. Using multiple connections can provide a very large overall congestion window. This can be an advantage for TCP implementations that do not support the TCP window scaling extension [JBB92]. However, the aggregate cwnd size across all N connections is equivalent to using a TCP implementation that supports large windows.
3.複数の接続を使用すると、非常に大規模な総合的な輻輳ウィンドウを提供することができます。これは、TCPウィンドウスケーリング拡張[JBB92]をサポートしていないTCP実装の利点することができます。しかし、すべてのN個の接続の集計にcwndサイズが大きな窓をサポートTCPの実装を使用するのと同じです。
4. The overall cwnd decrease in the face of dropped segments is reduced when using N parallel connections. A single TCP connection reduces the effective size of cwnd to half when a single segment loss is detected. When utilizing N connections each using a window of W bytes, a single drop reduces the window to:
N個の並列接続を使用する場合4.ドロップセグメントの顔の全体的なCWNDの低下が低減されます。単一セグメントの損失が検出された場合、単一のTCP接続が半分にCWNDの効果的なサイズを減少させます。各Wバイトのウィンドウを使用してN個の接続を利用する場合、単一のドロップは、ウィンドウへの減少します。
(N * W) - (W / 2)
（N * W） - （W / 2）
Clearly this is a less dramatic reduction in the effective cwnd size than when using a single TCP connection. And, the amount by which the cwnd is decreased is further reduced by increasing N.
これは明らかに、単一のTCP接続を使用する場合より効果的にcwndサイズの小さい劇的な減少です。そして、CWNDを減少させる量はさらに増加N.により低減されます
The use of multiple data connections can increase the ability of non-SACK TCP implementations to quickly recover from multiple dropped segments without resorting to a timeout, assuming the dropped segments cross connections.
複数のデータ接続の使用が急速に複数から回復する非SACKのTCP実装の能力を高めることができるドロップセグメントが接続を横切ると仮定すると、タイムアウトに頼ることなく、セグメントを落としました。
The use of multiple parallel connections makes TCP overly aggressive for many environments and can contribute to congestive collapse in shared networks [FF99]. The advantages provided by using multiple TCP connections are now largely provided by TCP extensions (larger windows, SACKs, etc.). Therefore, the use of a single TCP connection is more "network friendly" than using multiple parallel connections. However, using multiple parallel TCP connections may provide performance improvement in private networks.
複数の並列接続の使用は、多くの環境のためにTCPが過度に攻撃的になり、共有ネットワーク[FF99]でうっ血性崩壊に貢献することができます。複数のTCPコネクションを使用することによって得られる利点は、現在、主にTCP拡張（大きな窓、サックス、など）によって提供されています。したがって、単一のTCP接続を使用すると、複数の並列接続を使用するよりも「やさしいネットワーク」です。しかし、複数の並列TCPコネクションを使用すると、プライベートネットワークでのパフォーマンスの向上を提供することができます。
Research on the use of multiple parallel TCP connections shows improved performance [IL92,Hah94,AOK95,AKO96]. In addition, research has shown that multiple TCP connections can outperform a single modern TCP connection (with large windows and SACK) [AHKO97]. However, these studies did not consider the impact of using multiple TCP connections on competing traffic. [FF99] argues that using multiple simultaneous connections to transfer a given file may lead to congestive collapse in shared networks.
複数の並列TCP接続の使用に関する研究[AKO96、IL92、Hah94、AOK95】改善された性能を示します。また、研究では、複数のTCP接続が[AHKO97]（大きな窓とSACK付き）シングル近代的なTCP接続をアウトパフォームすることができることを示しています。しかし、これらの研究は、競合するトラフィックに複数のTCPコネクションを使用しての影響を考慮していませんでした。 [FF99]は指定されたファイルを転送するために複数の同時接続を使用して、共有ネットワークにおけるうっ血性崩壊をもたらし得ると主張します。
To utilize multiple parallel TCP connections a client application and the corresponding server must be customized. As outlined in [FF99] using multiple parallel TCP connections is not safe (from a congestion control perspective) in shared networks and should not be used.
複数の並列TCPコネクションにクライアントアプリケーションを利用するには、対応するサーバーをカスタマイズする必要があります。複数の並列TCP接続を使用して、[FF99]に概説されるように共有ネットワーク内（輻輳制御の観点から）安全ではなく、使用すべきではありません。
As stated above, [FF99] outlines that the use of multiple parallel connections in a shared network, such as the Internet, may lead to congestive collapse. However, the use of multiple connections may be safe and beneficial in private networks. The specific topology being used will dictate the number of parallel connections required. Some work has been done to determine the appropriate number of connections on the fly [AKO96], but such a mechanism is far from complete.
上述のように、[FF99]は、インターネットなどの共有ネットワーク内の複数の並列接続の使用は、鬱血性崩壊をもたらし得ることを概説します。ただし、複数の接続を使用することは安全でプライベートネットワークにおいて有益であり得ます。使用される特定のトポロジは、必要な並列接続の数を決定するであろう。いくつかの作品は、フライ[AKO96]での接続の適切な数を決定するために行われているが、そのようなメカニズムは完全には程遠いです。
Using multiple concurrent TCP connections enables use of a large congestion window, much like the TCP window scaling option [JBB92]. In addition, a larger initial congestion window is achieved, similar to using [AFP98] or TCB sharing (see section 3.8).
複数の同時TCP接続を使用すると、多くのTCPウィンドウスケーリングオプション[JBB92]のように、大きな輻輳ウィンドウの使用を可能にします。加えて、より大きな初期の輻輳ウィンドウは、（セクション3.8を参照）、[AFP98]またはTCB共有を使用するのと同様に達成されます。
Slow-start takes several round trips to fully open the TCP congestion window over routes with high bandwidth-delay products. For short TCP connections (such as WWW traffic with HTTP/1.0), the slow-start overhead can preclude effective use of the high-bandwidth satellite links. When senders implement slow-start restart after a TCP connection goes idle (suggested by Jacobson and Karels [JK92]),
スロースタートは完全に高帯域幅遅延製品とのルート上のTCP輻輳ウィンドウを開くには、いくつかのラウンドトリップを取ります。 （例えばHTTP / 1.0でのWWWトラフィックなど）の短いTCP接続の場合、スロースタートのオーバーヘッドは、高帯域幅の衛星リンクの有効利用を排除することができます。 TCP接続がアイドル状態になった後、送信者は、スロースタートの再起動を実装する場合（ヤコブソンとKarels [JK92]によって提案されました）、
performance is reduced in long-lived (but bursty) connections (such as HTTP/1.1, which uses persistent TCP connections to transfer multiple WWW page elements) [Hei97a].
性能は[Hei97a（例えば、複数のWWWページ要素を転送するために永続的なTCP接続を使用してHTTP / 1.1など）寿命の長い（ただし、バースト）接続に低減されます。
Rate-based pacing (RBP) is a technique, used in the absence of incoming ACKs, where the data sender temporarily paces TCP segments at a given rate to restart the ACK clock. Upon receipt of the first ACK, pacing is discontinued and normal TCP ACK clocking resumes. The pacing rate may either be known from recent traffic estimates (when restarting an idle connection or from recent prior connections), or may be known through external means (perhaps in a point-to-point or point-to-multipoint satellite network where available bandwidth can be assumed to be large).
レートベースペーシング（RBP）は、データ送信者が一時的にACKクロックを再起動するために、所与の速度でTCPセグメントをペーシング受信ACKの非存在下で使用される技術です。最初のACKを受信すると、ペーシングを中止し、通常のTCP ACKは、履歴書をクロッキングされます。ペーシングレートは、最近のトラフィックの見積もり（アイドル接続を再起動するか、最近前の接続から）から知ることができるか、おそらくポイントツーポイントまたはポイントツーマルチ衛星ネットワークで利用可能な場合（外部手段を介して知ることができます帯域幅）が大であると想定することができます。
In addition, pacing data during the first RTT of a transfer may allow TCP to make effective use of high bandwidth-delay links even for short transfers. However, in order to pace segments during the first RTT a TCP will have to be using a non-standard initial congestion window and a new mechanism to pace outgoing segments rather than send them back-to-back. Determining an appropriate size for the initial cwnd is an open research question. Pacing can also be used to reduce bursts in general (due to buggy TCPs or byte counting, see section 3.2.2 for a discussion on byte counting).
また、転送の最初のRTT中にデータをペーシングすることはTCPが短くても転送用の高帯域幅、遅延リンクを有効に活用することを可能にします。しかし、最初のRTT TCPの間にセグメントをペーシングするために、非標準の初期の輻輳ウィンドウと送信セグメントのペースではなく、背中合わせにそれらを送信するための新しいメカニズムを使用する必要があります。初期のcwndのための適切なサイズを決定することは、オープン研究課題です。ペーシングは、（バイトカウントに関する議論についてはセクション3.2.2を参照して、原因バギーのTCPまたはバイトカウントに）一般的にバーストを減少させるために使用することができます。
Simulation studies of rate-paced pacing for WWW-like traffic have shown reductions in router congestion and drop rates [VH97a]. In this environment, RBP substantially improves performance compared to slow-start-after-idle for intermittent senders, and it slightly improves performance over burst-full-cwnd-after-idle (because of drops) [VH98]. More recently, pacing has been suggested to eliminate burstiness in networks with ACK filtering [BPK97].
WWWのようなトラフィックのレートペースペーシングのシミュレーション研究では、ルータの輻輳やドロップ率[VH97a]の削減を示しています。この環境において、RBPは、実質的に性能間欠送信者のためにスロー後アイドルスタート、それはわずかにバーストフルCWNDアフターアイドル（なぜなら滴）を超える性能を改善する[VH98]と比較して改善されます。さらに最近では、ペーシングが[BPK97] ACKフィルタリングを持つネットワークでのバースト性を排除することが示唆されています。
RBP requires only sender-side changes to TCP. Prototype implementations of RBP are available [VH97b]. RBP requires an additional sender timer for pacing. The overhead of timer-driven data transfer is often considered too high for practical use. Preliminary experiments suggest that in RBP this overhead is minimal because RBP only requires this timer for one RTT of transmission [VH98]. RBP is expected to make TCP more conservative in sending bursts of data after an idle period in hosts that do not revert to slow start after an idle period. On the other hand, RBP makes TCP more aggressive if the sender uses the slow start algorithm to start the ACK clock after a long idle period.
RBPは、TCPにのみ、送信者側の変更が必要です。 RBPのプロトタイプの実装は、[VH97b】利用可能です。 RBPは、ペーシングのための追加の送信者のタイマーが必要です。タイマー駆動型データ転送のオーバーヘッドは、多くの場合、実際の使用には高すぎると考えられています。予備実験は、RBPは送信のみの1 RTT [VH98]のためにこのタイマーを必要とするためRBPでこのオーバーヘッドが最小限であることを示唆しています。 RBPは、アイドル期間の後に開始を遅らせるために戻らないホストでのアイドル期間後にデータのバーストを送信中にTCPはより保守的にするために期待されています。送信者は、長いアイドル期間の後にACKクロックを開始するためにスロースタートアルゴリズムを使用している場合一方、RBPは、TCPは、より積極的になります。
RBP could be used to restart idle TCP connections for all topologies in Section 2. Use at the beginning of new connections would be restricted to topologies where available bandwidth can be estimated out-of-band.
RBPは、利用可能な帯域幅がアウト・オブ・バンドに推定することができるトポロジに制限される新しい接続の開始時に、セクション2.使用中のすべてのトポロジのアイドル状態のTCP接続を再起動するために使用することができます。
Pacing segments may benefit from sharing state amongst various flows between two hosts, due to the time required to determine the needed information. Additionally, pacing segments, rather than sending back-to-back segments, may make estimating the available bandwidth (as outlined in section 3.2.4) more difficult.
ペーシングセグメントにより必要な情報を決定するために必要な時間に、2つのホスト間で様々なフローの間で状態を共有することから利益を得ることができます。 （セクション3.2.4に概説されるように）、さらに、セグメントをペーシング、むしろバックツーバックセグメントを送信するよりも、利用可能な帯域幅を推定するより困難にすることができます。
The TCP and IP header information needed to reliably deliver packets to a remote site across the Internet can add significant overhead, especially for interactive applications. Telnet packets, for example, typically carry only a few bytes of data per packet, and standard IPv4/TCP headers add at least 40 bytes to this; IPv6/TCP headers add at least 60 bytes. Much of this information remains relatively constant over the course of a session and so can be replaced by a short session identifier.
確実に、インターネット経由でリモートサイトにパケットを配信するために必要なTCPおよびIPヘッダ情報は、特に対話型アプリケーションのために、大きなオーバーヘッドを追加することができます。 Telnetパケットは、例えば、典型的には、パケットごとのデータのわずか数バイトを運び、そして標準のIPv4 / TCPヘッダーは、これには、少なくとも40バイトを追加します。 IPv6の/ TCPヘッダは少なくとも60のバイトを追加します。この情報の多くは、セッションにわたって比較的一定に維持し、そう短いセッション識別子で置き換えることができます。
Many fields in the TCP and IP headers either remain constant during the course of a session, change very infrequently, or can be inferred from other sources. For example, the source and destination addresses, as well as the IP version, protocol, and port fields generally do not change during a session. Packet length can be deduced from the length field of the underlying link layer protocol provided that the link layer packet is not padded. Packet sequence numbers in a forward data stream generally change with every packet, but increase in a predictable manner.
TCPおよびIPヘッダのいずれかの多くの分野では非常にまれにしか変化し、セッションの途中で、一定のまま、または他のソースから推測することができます。例えば、送信元と送信先アドレスだけでなく、IPバージョン、プロトコル、およびポートのフィールドは、一般的に、セッション中に変更されません。パケット長は、リンク層パケットがパディングされていないことを条件とする基本的なリンク層プロトコルの長さフィールドから推定することができます。順方向データ・ストリームのパケットシーケンス番号は、一般的にすべてのパケットで変化するが、予測可能な方法で増加します。
The TCP/IP header compression methods described in [DNP99,DENP97,Jac90] reduce the overhead of TCP sessions by replacing the data in the TCP and IP headers that remains constant, changes slowly, or changes in a predictable manner with a short "connection number". Using this method, the sender first sends a full TCP/IP header, including in it a connection number that the sender will use to reference the connection. The receiver stores the full header and uses it as a template, filling in some fields from the limited information contained in later, compressed headers. This compression can reduce the size of an IPv4/TCP headers from 40 to as few as 3 to 5 bytes (3 bytes for some common cases, 5 bytes in general).
[DNP99、DENP97、Jac90]に記載のTCP / IPヘッダ圧縮方法は、一定のままでTCPおよびIPヘッダ内のデータを置換することによって、TCPセッションのオーバーヘッドを低減し、ゆっくりと変化する、または短い「接続で予測可能な方法で変化数"。この方法を使用して、送信者はまずその中に送信者が接続を参照するために使用する接続の数を含む、完全なTCP / IPヘッダを送ります。受信機はフル・ヘッダを格納し、後で、圧縮ヘッダに含まれている限られた情報からいくつかのフィールドに記入し、テンプレートとして使用します。この圧縮は40から3〜5バイト（いくつかの一般的なケースのための3バイト、一般に5バイト）ほどの少数へのIPv4 / TCPヘッダのサイズを小さくすることができます。
Compression and decompression generally happen below the IP layer, at the end-points of a given physical link (such as at two routers connected by a serial line). The hosts on either side of the physical link must maintain some state about the TCP connections that are using the link.
圧縮及び伸張は、一般に、（例えばシリアル回線で接続された2台のルータでのように）指定された物理リンクのエンドポイントで、IP層の下に起こります。物理リンクのいずれかの側のホストは、リンクを使用しているTCP接続に関するいくつかの状態を維持する必要があります。
The decompresser must pass complete, uncompressed packets to the IP layer. Thus header compression is transparent to routing, for example, since an incoming packet with compressed headers is expanded before being passed to the IP layer.
decompresserは、IP層に完全に、圧縮されていないパケットを渡す必要があります。圧縮ヘッダを有する着信パケットがIPレイヤに渡される前に展開されているので、このようにヘッダ圧縮は、例えば、ルーティングに対して透明です。
A variety of methods can be used by the compressor/decompressor to negotiate the use of header compression. For example, the PPP serial line protocol allows for an option exchange, during which time the compressor/decompressor agree on whether or not to use header compression. For older SLIP implementations, [Jac90] describes a mechanism that uses the first bit in the IP packet as a flag.
種々の方法は、ヘッダ圧縮の使用を交渉するコンプレッサ/デコンプレッサにより使用することができます。例えば、PPPシリアル回線プロトコルは、圧縮機が/デコンプレッサヘッダ圧縮を使用するかどうかについて合意その間、オプションの交換を可能にします。古いSLIPの実装のために、[Jac90]フラグとしてIPパケットの最初のビットを使用するメカニズムが記載されています。
The reduction in overhead is especially useful when the link is bandwidth-limited such as terrestrial wireless and mobile satellite links, where the overhead associated with transmitting the header bits is nontrivial. Header compression has the added advantage that for the case of uniformly distributed bit errors, compressing TCP/IP headers can provide a better quality of service by decreasing the packet error probability. The shorter, compressed packets are less likely to be corrupted, and the reduction in errors increases the connection's throughput.
リンクは帯域幅が制限され、地上波無線およびモバイル衛星リンクなど、ヘッダビットを送信することに関連するオーバーヘッドが自明である場合のオーバーヘッドの減少は特に有用です。ヘッダ圧縮は、均一に分布し、ビットエラーの場合のために、TCP / IPヘッダーを圧縮するパケットエラー確率を減少させることによって、サービスの質の向上を提供できることを付加的な利点を有しています。短く、圧縮されたパケットが破損しにくくなる、との誤差の減少は、接続のスループットが向上します。
Extra space is saved by encoding changes in fields that change relatively slowly by sending only their difference from their values in the previous packet instead of their absolute values. In order to decode headers compressed this way, the receiver keeps a copy of each full, reconstructed TCP header after it is decoded, and applies the delta values from the next decoded compressed header to the reconstructed full header template.
余分なスペースは、代わりにその絶対値の前のパケットにそれらの値からのみそれらの差を送信することにより、比較的ゆっくりと変化するフィールドの変化を符号化することによって保存されます。ヘッダがこのように圧縮復号するために、受信機は、デコードされた後に各完全再構成TCPヘッダのコピーを保持し、そして次のデルタ値は、再構成されたフルヘッダーテンプレートに圧縮されたヘッダをデコード適用します。
A disadvantage to using this delta encoding scheme where values are encoded as deltas from their values in the previous packet is that if a single compressed packet is lost, subsequent packets with compressed headers can become garbled if they contain fields which depend on the lost packet. Consider a forward data stream of packets with compressed headers and increasing sequence numbers. If packet N is lost, the full header of packet N+1 will be reconstructed at the receiver using packet N-1's full header as a template. Thus the sequence number, which should have been calculated from packet N's header, will be wrong, the checksum will fail, and the packet will be discarded. When the sending TCP times out and retransmits a packet with a full header is forwarded to re-synchronize the decompresser.
値が以前のパケットにそれらの値から差分として符号化され、この差分符号化方式を使用する欠点は、単一の圧縮されたパケットが失われた場合、彼らは失われたパケットに依存するフィールドが含まれている場合、圧縮されたヘッダを持つ後続パケットが文字化けになることができることです。圧縮されたヘッダと増加するシーケンス番号を持つパケットの順方向データ・ストリームを考えてみましょう。パケットNが失われた場合、パケットN + 1の完全なヘッダをテンプレートとして、パケットN-1のフルヘッダーを使用して、受信機で再構築されるであろう。このように、パケットNのヘッダから計算されているはずのシーケンス番号は、間違っているだろう、チェックサムが失敗し、パケットが破棄されます。送信TCPがタイムアウトと完全なヘッダを持つパケットを再送を展開ツール再同期するために転送された場合。
It is important to note that the compressor does not maintain any timers, nor does the decompresser know when an error occurred (only the receiving TCP knows this, when the TCP checksum fails). A single bit error will cause the decompresser to lose sync, and subsequent packets with compressed headers will be dropped by the receiving TCP, since they will all fail the TCP checksum. When this happens, no duplicate acknowledgments will be generated, and the decompresser can only re-synchronize when it receives a packet with an uncompressed header. This means that when header compression is being used, both fast retransmit and selective acknowledgments will not be able correct packets lost on a compressed link. The "twice" algorithm, described below, may be a partial solution to this problem.
コンプレッサーが任意のタイマーを維持していないことに注意することが重要である、またエラーが（のみ受信側TCPはTCPチェックサムが失敗したときに、このことを知っている）が発生したときにdecompresserは知っているん。シングルビットエラーがdecompresserが同期を失うことになります、そして、彼らはすべてのTCPチェックサムを失敗するので、圧縮ヘッダを持つ後続のパケットは、受信側TCPによって破棄されます。このとき、重複確認応答は生成されません、そして、それは、非圧縮ヘッダを持つパケットを受信したときdecompresserのみ再同期することができます。これは、ヘッダ圧縮が使用されている場合、高速再送信及び選択的肯定応答の両方が圧縮されたリンク上で失われたことが正しいパケットではないことを意味します。後述の「二回」のアルゴリズムは、この問題に対する部分的な解決策かもしれません。
[DNP99] and [DENP97] describe TCP/IPv4 and TCP/IPv6 compression algorithms including compressing the various IPv6 extension headers as well as methods for compressing non-TCP streams. [DENP97] also augments TCP header compression by introducing the "twice" algorithm. If a particular packet fails to decompress properly, the twice algorithm modifies its assumptions about the inferred fields in the compressed header, assuming that a packet identical to the current one was dropped between the last correctly decoded packet and the current one. Twice then tries to decompress the received packet under the new assumptions and, if the checksum passes, the packet is passed to IP and the decompresser state has been re-synchronized. This procedure can be extended to three or more decoding attempts. Additional robustness can be achieved by caching full copies of packets which don't decompress properly in the hopes that later arrivals will fix the problem. Finally, the performance improvement if the decompresser can explicitly request a full header is discussed. Simulation results show that twice, in conjunction with the full header request mechanism, can improve throughput over uncompressed streams.
【DNP99]および[DENP97] TCP / IPv4とIPv6の拡張ヘッダを圧縮するだけでなく、非TCPストリームを圧縮する方法を含むTCP / IPv6の圧縮アルゴリズムを記述する。 【DENP97】また、「倍」アルゴリズムを導入することによって、TCPヘッダ圧縮を増強します。特定のパケットが正しく解凍に失敗した場合、二回アルゴリズムは、現在のものと同じパケットが最後に正しく復号されたパケットと現在の一方との間にドロップされたと仮定すると、圧縮されたヘッダーに推論フィールドについて、その仮定を修正します。二回、新しい仮定の下で、受信したパケットを解凍しようとすると、チェックサムが合格した場合、パケットがIPに渡され、decompresser状態が再同期されています。この手順は、3つの以上の復号の試みに拡張することができます。追加の堅牢性は、後に到着が問題を解決することを期待して適切に解凍しないパケットの完全なコピーをキャッシュすることにより達成することができます。最後に、decompresserが明示的にフル・ヘッダを要求することができる場合、性能の向上が検討されています。シミュレーション結果は、二回、完全なヘッダ要求機構に関連して、非圧縮ストリームを超えるスループットを向上させることができることを示しています。
[Jac90] outlines a simple header compression scheme for TCP/IP.
【Jac90] TCP / IPのための単純なヘッダー圧縮技術を概説します。
In [DENP97] the authors present the results of simulations showing that header compression is advantageous for both low and medium bandwidth links. Simulations show that the twice algorithm, combined with an explicit header request mechanism, improved throughput by 10-15% over uncompressed sessions across a wide range of bit error rates.
【DENP97]において著者らは、ヘッダ圧縮を示すシミュレーション結果を提示する低および中の両方の帯域幅のリンクのために有利です。シミュレーションは、明示的なヘッダ要求メカニズムと組み合わさ回アルゴリズムは、ビット誤り率の広い範囲にわたって非圧縮セッションにわたって10~15％によってスループットを改善することを示しています。
Much of this improvement may have been due to the twice algorithm quickly re-synchronizing the decompresser when a packet is lost. This is because the twice algorithm, applied one or two times when the decompresser becomes unsynchronized, will re-sync the decompresser in between 83% and 99% of the cases examined. This means that packets received correctly after twice has resynchronized the decompresser will cause duplicate acknowledgments. This re-enables the use of both fast retransmit and SACK in conjunction with header compression.
この改善の多くは、再同期パケットが失われたときの展開ツールすばやく二回アルゴリズムが原因であったかもしれません。これを2回アルゴリズムからである、decompresserが非同期となる1回または2回の適用、83％及び検査症例の99％との間での展開ツール同期し直すだろう。これを2回decompresserが重複確認応答を引き起こします再同期された後のパケットが正しく受信することを意味します。このヘッダ圧縮と併せて高速再送信及びSACKの両方の使用を再可能にします。
Implementing TCP/IP header compression requires changes at both the sending (compressor) and receiving (decompresser) ends of each link that uses compression. The twice algorithm requires very little extra machinery over and above header compression, while the explicit header request mechanism of [DENP97] requires more extensive modifications to the sending and receiving ends of each link that employs header compression. Header compression does not violate TCP's congestion control mechanisms and therefore can be safely implemented in shared networks.
TCP / IPヘッダー圧縮を実装する圧縮を使用する各リンクの端部（圧縮機）を送信および受信の両方で変更（展開ツール）が必要です。 【DENP97]の明示的なヘッダ要求機構は、ヘッダ圧縮を採用し、各リンクの送信側と受信側に、より広範な修正を必要とする二回アルゴリズムは、ヘッダ圧縮上及び上記非常に少し余分な機械を必要とします。ヘッダ圧縮は、TCPの輻輳制御メカニズムに違反しないため、安全に共有ネットワークで実現することができます。
TCP/IP header compression is applicable to all of the environments discussed in section 2, but will provide relatively more improvement in situations where packet sizes are small (i.e., overhead is large) and there is medium to low bandwidth and/or higher BER. When TCP's congestion window size is large, implementing the explicit header request mechanism, the twice algorithm, and caching packets which fail to decompress properly becomes more critical.
TCP / IPヘッダー圧縮は、セクション2で説明した環境の全てに適用可能であるが、パケットサイズが小さい（すなわち、オーバーヘッドが大きい）と、低帯域幅および/またはより高いBERに媒体が存在する状況では比較的多くの改善を提供するであろう。 TCPの輻輳ウィンドウサイズが大きい場合、解凍に失敗し、明示的なヘッダー要求メカニズム、二回アルゴリズム、およびキャッシングパケットを実装することは、適切に、より重要になります。
As discussed above, losing synchronization between a sender and receiver can cause many packet drops. The frequency of losing synchronization and the effectiveness of the twice algorithm may point to using a SACK-based loss recovery algorithm to reduce the impact of multiple lost segments. However, even very robust SACK-based algorithms may not work well if too many segments are lost.
上述したように、送信者と受信者との間の同期を失うことは、多くのパケットドロップを引き起こす可能性があります。同期および二回アルゴリズムの有効性を失うの周波数は、複数の失われたセグメントの影響を低減するためにSACKベースの損失回復アルゴリズムを使用してを指してもよいです。あまりにも多くのセグメントが失われた場合しかし、非常に堅牢SACKベースのアルゴリズムがうまく動作しない場合があります。
Persistent TCP state information can be used to overcome limitations in the configuration of the initial state, and to automatically tune TCP to environments using satellite links and to coordinate multiple TCP connections sharing a satellite link.
永続的なTCP状態情報は、初期状態の設定の制限を克服するために、かつ自動的にチューニングTCPは、衛星リンクを使用して環境にするために、衛星リンクを共有する複数のTCP接続を調整するために使用することができます。
TCP includes a variety of parameters, many of which are set to initial values which can severely affect the performance of TCP connections traversing satellite links, even though most TCP parameters are adjusted later after the connection is established. These parameters include initial size of cwnd and initial MSS size. Various suggestions have been made to change these initial conditions, to more effectively support satellite links. However, it is difficult to select any single set of parameters which is effective for all environments.
TCP接続が確立された後、ほとんどのTCPパラメータが、後に調整されているにもかかわらず、深刻な衛星リンクを通過するTCP接続のパフォーマンスに影響を与える可能性が初期値に設定され、その多くのパラメータ、さまざまな含まれています。これらのパラメータは、cwndは、初期MSSサイズの初期サイズが含まれます。様々な提案がより効果的に衛星リンクをサポートするために、これらの初期条件を変更することが行われています。しかし、すべての環境のために有効であるパラメータの任意の単一のセットを選択することは困難です。
An alternative to attempting to select these parameters a-priori is sharing state across TCP connections and using this state when initializing a new connection. For example, if all connections to a subnet result in extended congestion windows of 1 megabyte, it is probably more efficient to start new connections with this value, than to rediscover it by requiring the cwnd to increase using slow start over a period of dozens of round-trip times.
事前にTCPコネクション間で状態を共有して、これらのパラメータを選択しようとすると、新しい接続を初期化するとき、この状態を使用する代わりに。例えば、1メガバイトの拡張輻輳ウィンドウ内のサブネット結果へのすべての接続ならば、数十の期間にわたってスロースタートを使用して増加するのcwndを必要とすることによって、それを再発見するよりも、この値を使用して新しい接続を開始するために、おそらく、より効率的です往復時間。
Sharing state among connections brings up a number of questions such as what information to share, with whom to share, how to share it, and how to age shared information. First, what information is to be shared must be determined. Some information may be appropriate to share among TCP connections, while some information sharing may be inappropriate or not useful. Next, we need to determine with whom to share information. Sharing may be appropriate for TCP connections sharing a common path to a given host. Information may be shared among connections within a host, or even among connections between different hosts, such as hosts on the same LAN. However, sharing information between connections not traversing the same network may not be appropriate. Given the state to share and the parties that share it, a mechanism for the sharing is required. Simple state, like MSS and RTT, is easy to share, but congestion window information can be shared a variety of ways. The sharing mechanism determines priorities among the sharing connections, and a variety of fairness criteria need to be considered. Also, the mechanisms by which information is aged require further study. See RFC 2140 for a discussion of the security issues in both sharing state within a single host and sharing state among hosts on a subnet. Finally, the security concerns associated with sharing a piece of information need to be carefully considered before introducing such a mechanism. Many of these open research questions must be answered before state sharing can be widely deployed.
接続間の状態を共有することで、それを共有する方法、共有する誰と、どのような、そのような情報を共有するように質問の数が表示されます、そしてどのように共有情報を年齢。まず、どのような情報を決定しなければならない共有することです。いくつかの情報の共有が不適切または有用ではないかもしれないが、一部の情報は、TCPコネクション間で共有することが適切です。次に、我々は情報を共有するために誰と判断する必要があります。共有は、特定のホストへの共通パスを共有するTCP接続のために適切かもしれません。情報は、ホスト内の接続の間で、あるいは例えば、同じLAN上のホストとして異なるホスト間の接続の間で共有することができます。しかし、同じネットワークを横断しない接続との間で情報を共有することは適切ではないかもしれません。共有する状態とそれを共有する政党を考えると、共有するためのメカニズムが必要です。単純な状態は、MSSとRTTのように、共有するのは簡単ですが、輻輳ウィンドウの情報は、さまざまな方法を共有することができます。共有メカニズムは、共有接続の中で優先順位を決定し、公平性基準の様々な検討する必要があります。また、情報が熟成されるメカニズムは、さらなる研究が必要です。単一のホスト内の状態を共有し、サブネット上のホスト間で状態を共有する両方のセキュリティ問題の議論については、RFC 2140を参照してください。最後に、情報の一部を共有するに関連付けられているセキュリティ上の懸念は慎重に、このような仕組みを導入する前に検討する必要があります。状態の共有を広く展開することができます前に、これらのオープンな研究の質問の多くは答えなければなりません。
The opportunity for such sharing, both among a sequence of connections, as well as among concurrent connections, is described in more detail in [Tou97]. The state management itself is largely an implementation issue, however what information should be shared and the specific ways in which the information should be shared is an open question.
このような共有のため、両方の接続のシーケンスのうち、ならびに同時接続のうちの機会は、[Tou97]に詳細に記載されています。状態管理自体は共有されるべき情報が、大部分は実装の問題であるとの情報が共有されるべき具体的な方法未解決の問題です。
Sharing parts of the TCB state was originally documented in T/TCP [Bra92], and is used there to aggregate RTT values across connection instances, to provide meaningful average RTTs, even though most connections are expected to persist for only one RTT. T/TCP also shares a connection identifier, a sequence number separate from the window number and address/port pairs by which TCP connections are typically distinguished. As a result of this shared state, T/TCP allows a receiver to pass data in the SYN segment to the receiving application, prior to the completion of the three-way handshake, without compromising the integrity of the connection. In effect, this shared state caches a partial handshake from the previous connection, which is a variant of the more general issue of TCB sharing.
TCBの状態の共有部分は、最も接続が一つだけRTT持続することが期待されていても、もともとT / TCP [Bra92]に記載された、意味のある平均値のRTTを提供するために、接続インスタンス間でRTT値を集計するが用いられます。 T / TCPは、接続識別子、TCP接続は、典型的に区別されるウィンドウの数およびアドレス/ポートのペアから別のシーケンス番号を共有します。この共有状態の結果として、T / TCPは、受信機が、接続の完全性を損なうことなく、従来のスリーウェイハンドシェイクの完了まで、受信側アプリケーションへのSYNセグメントにデータを渡すことができます。実際には、この共有状態は、TCB共有のより一般的な問題の変異体である以前の接続から部分的ハンドシェイクをキャッシュします。
Sharing state among connections (including transfers using non-TCP protocols) is further investigated in [BRS99].
（非TCPプロトコルを使用して転送を含む）接続の間で状態を共有することは、さらに[BRS99]で検討されています。
Sharing TCP state across connections requires changes to the sender's TCP stack, and possibly the receiver's TCP stack (as in the case of T/TCP, for example). Sharing TCP state may make a particular TCP connection more aggressive. However, the aggregate traffic should be more conservative than a group of independent TCP connections. Therefore, sharing TCP state should be safe for use in shared networks. Note that state sharing does not present any new security problems within multiuser hosts. In such a situation, users can steal network resources from one another with or without state sharing.
接続間のTCP状態を共有する（例えば、T / TCPの場合のように）送信者のTCPスタックへの変更、および場合によっては受信側のTCPスタックを必要とします。 TCPの状態を共有することで、より積極的な特定のTCP接続を行うことができます。しかし、集約トラフィックは、独立したTCPコネクションのグループよりも保守的でなければなりません。そのため、TCPの状態を共有する共有ネットワークでの使用のために安全でなければなりません。状態の共有はマルチユーザホスト内の任意の新しいセキュリティ上の問題を提示していないことに注意してください。このような状況では、ユーザーが状態を共有したりすることなく、相互にネットワークリソースを盗むことができます。
It is expected that sharing state across TCP connections may be useful in all network environments presented in section 2.
TCPコネクション間で状態を共有する2章で提示されたすべてのネットワーク環境で有用であることが期待されています。
The state sharing outlined above is very similar to the Congestion Manager proposal [BRS99] that attempts to share congestion control information among both TCP and UDP flows between a pair of hosts.
上記で概説した状態の共有は、TCPとUDPの両方の間で輻輳制御情報は、ホストのペア間を流れる共有しようとする輻輳マネージャ提案[BRS99]と非常に類似しています。
In highly asymmetric networks, a low-speed return link can restrict the performance of the data flow on a high-speed forward link by limiting the flow of acknowledgments returned to the data sender. For example, if the data sender uses 1500 byte segments, and the receiver generates 40 byte acknowledgments (IPv4, TCP without options), the reverse link will congest with ACKs for asymmetries of more than 75:1 if delayed ACKs are used, and 37:1 if every segment is acknowledged. For a 1.5 Mb/second data link, ACK congestion will occur for reverse link speeds below 20 kilobits/sec. These levels of asymmetry will readily occur if the reverse link is shared among multiple satellite receivers, as is common in many VSAT satellite networks. If a terrestrial modem link is used as a reverse link, ACK congestion is also likely, especially as the speed of the forward link is increased. Current congestion control mechanisms are aimed at controlling the flow of data segments, but do not affect the flow of ACKs.
非常に非対称のネットワークでは、低速リターン・リンクは、データの送信者に返送確認応答の流れを制限することで、高速順方向リンク上のデータフローのパフォーマンスを制限することができます。遅延のACKが使用される場合は1、及び37：データ送信側が1500個のバイトのセグメントを使用し、受信機は、40のバイトの肯定応答（IPv4の、オプションなしTCP）を生成する場合、例えば、逆方向リンクは75以上の非対称性のためのACKで混雑します：1、すべてのセグメントが認められている場合。 1.5メガビット/秒のデータリンクのために、ACK輻輳が20人のキロビット/秒以下、逆方向リンク速度のために発生します。逆方向リンクは、複数の衛星受信機間で共有されている場合、多くのVSAT衛星ネットワークにおいて一般的であるように非対称のこれらのレベルは、容易に、発生します。地上モデムのリンクは逆方向リンクとして使用されている場合は、ACKの混雑は、順方向リンクの速度が増加し、特にとして、またそうです。現在の輻輳制御機構は、データ・セグメントの流れを制御することを目的としているが、ACKの流れに影響を与えません。
In [KVR98] the authors point out that the flow of acknowledgments can be restricted on the low-speed link not only by the bandwidth of the link, but also by the queue length of the router. The router may limit its queue length by counting packets, not bytes, and therefore begin discarding ACKs even if there is enough bandwidth to forward them.
[KVR98]では、著者は、確認応答の流れは、リンクの帯域幅によって、だけでなく、ルータのキューの長さによってだけでなく、低速リンクで制限することができると指摘しています。ルータは、パケットではなく、バイトをカウントすることにより、そのキューの長さを制限し、そのためにそれらを転送するのに十分な帯域幅がある場合でも、ACKを捨て始めることができます。
ACK Congestion Control extends the concept of flow control for data segments to acknowledgment segments. In the method described in [BPK97], any intermediate router can mark an acknowledgment with an Explicit Congestion Notification (ECN) bit once the queue occupancy in the router exceeds a given threshold. The data sender (which receives the acknowledgment) must "echo" the ECN bit back to the data receiver (see section 3.3.3 for a more detailed discussion of ECN). The proposed algorithm for marking ACK segments with an ECN bit is Random Early Detection (RED) [FJ93]. In response to the receipt of ECN marked data segments, the receiver will dynamically reduce the rate of acknowledgments using a multiplicative backoff. Once segments without ECN are received, the data receiver speeds up acknowledgments using a linear increase, up to a rate of either 1 (no delayed ACKs) or 2 (normal delayed ACKs) data segments per ACK. The authors suggest that an ACK be generated at least once per window, and ideally a few times per window.
ACK輻輳制御は、肯定応答セグメントにデータセグメントのためのフロー制御の概念を拡張します。ルータのキュー占有率が所定の閾値を超えると[BPK97]に記載された方法では、任意の中間ルータが明示的輻輳通知（ECN）ビットを有する確認応答をマークすることができます。 （確認応答を受信した）データ送信側は（ECNのより詳細な議論についてはセクション3.3.3を参照）バックデータ受信にECNビットを「エコー」しなければなりません。 ECNビットとACKセグメントをマーキングするための提案されたアルゴリズムは、ランダム早期検出（RED）[FJ93]です。 ECNマーキングされたデータセグメントの受信に応答して、受信機は、動的乗法バックオフを使用して肯定応答の速度を低下させます。 ECNなしのセグメントが受信されると、データ受信機はACKあたり1（なし遅延ACK）または2（正常遅延ACK）データセグメントのいずれかの速度まで、直線的な増加を使用して肯定応答をスピードアップ。著者は、ACKが少なくとも一度ウィンドウごとに生成し、ウィンドウごとに理想的に数回することを示唆しています。
As in the RED congestion control mechanism for data flow, the bottleneck gateway can randomly discard acknowledgments, rather than marking them with an ECN bit, once the queue fills beyond a given threshold.
キューが所定の閾値を超えて充填されると、データフローのRED輻輳制御機構のように、ボトルネック・ゲートウェイは、ランダムに肯定応答を破棄することができるではなく、ECNビットでそれらをマークします。
[BPK97] analyze the effect of ACK Congestion Control (ACC) on the performance of an asymmetric network. They note that the use of ACC, and indeed the use of any scheme which reduces the frequency of acknowledgments, has potential unwanted side effects. Since each ACK will acknowledge more than the usual one or two data segments, the likelihood of segment bursts from the data sender is increased. In addition, congestion window growth may be impeded if the receiver grows the window by counting received ACKs, as mandated by [Ste97,APS99]. The authors therefore combine ACC with a series of modifications to the data sender, referred to as TCP Sender Adaptation (SA). SA combines a limit on the number of segments sent in a burst, regardless of window size. In addition, byte counting (as opposed to ACK counting) is employed for window growth. Note that byte counting has been studied elsewhere and can introduce side-effects, as well [All98].
【BPK97】非対称ネットワークの性能に対するACK輻輳制御（ACC）の効果を分析します。彼らは、ACCの使用、そして実際に受信確認の頻度を減少させる任意の方式の使用は、潜在的な望ましくない副作用を持っていることに注意してください。各ACKが通常一つまたは二つのデータセグメントよりも認めるので、データ送信元からセグメントバーストの可能性が増大します。 [Ste97、APS99]によって義務付けとして受信機は、受信されたACKをカウントすることにより、ウィンドウを成長する場合に加えて、輻輳ウィンドウの成長が阻害されてもよいです。著者らは、したがって、データ送信側への変更一連のACCを組み合わせて、TCP送信者適応（SA）と呼びます。 SAは関係なく、ウィンドウサイズのバーストで送信されたセグメントの数の制限を組み合わせます。また、バイトカウントは、（ACK計数とは対照的に）ウィンドウの成長のために使用されます。 [All98]だけでなく、そのバイトカウントは他の場所で研究されており、副作用を導入することができます。
The results presented in [BPK97] indicate that using ACC and SA will reduce the bursts produced by ACK losses in unmodified (Reno) TCP. In cases where these bursts would lead to data loss at an intermediate router, the ACC and SA modification significantly improve the throughput for a single data transfer. The results further suggest that the use of ACC and SA significantly improve fairness between two simultaneous transfers.
【BPK97]に示す結果は、ACCとSAを使用して修飾されていない（リノ）TCPにおけるACK損失によって生成バーストを減少させることを示しています。これらのバーストは、中間ルータでのデータ損失につながる場合には、ACCとSA変形が著しく単一のデータ転送のスループットを向上させます。結果は、ACCとSAの使用が大幅に2つの同時転送間の公平性を改善することを示唆しています。
ACC is further reported to prevent the increase in round trip time (RTT) that occurs when an unmodified TCP fills the reverse router queue with acknowledgments.
ACCはさらに変更されていないTCPが確認応答と逆のルータのキューを満たしたときに発生する往復時間（RTT）の増加を防止することが報告されています。
In networks where the forward direction is expected to suffer losses in one of the gateways, due to queue limitations, the authors report at best a very slight improvement in performance for ACC and SA, compared to unmodified Reno TCP.
制限をキューに起因する順方向は、ゲートウェイのいずれかで損失を被ることが予想されるネットワークでは、著者らは、非改変リノTCPに比べ、せいぜいACCとSAのパフォーマンスが非常にわずかな改善を報告しています。
Both ACC and SA require modification of the sending and receiving hosts, as well as the bottleneck gateway. The current research suggests that implementing ACC without the SA modifications results in a data sender which generates potentially disruptive segment bursts. It should be noted that ACC does require host modifications if it is implemented in the way proposed in [BPK97]. The authors note that ACC can be implemented by discarding ACKs (which requires only a gateway modification, but no changes in the hosts), as opposed to marking them with ECN. Such an implementation may, however, produce bursty data senders if it is not combined with a burst mitigation technique. ACC requires changes to the standard ACKing behavior of a receiving TCP and therefore is not recommended for use in shared networks.
ACCとSAの両方は、送信側と受信側ホストの変更、並びにボトルネックゲートウェイを必要とします。現在の研究は、潜在的に破壊的なセグメントバーストを生成するデータ送信側におけるSAの変更結果なしACCを実装することを示唆しています。 [BPK97]で提案された方法で実装されている場合、ACCは、ホスト変更も必要としないことに留意すべきです。著者らは、ECNでそれらをマーキングとは対照的に、ACCは、（のみゲートウェイの変更を必要とするが、ホストに変更なし）ACKを廃棄することによって実施することができます。それはバースト軽減技術と組み合わされていない場合、そのような実装は、しかし、バーストデータの送信者を生成することができます。 ACCは、受信TCPの標準の肯定応答（ACK）の動作の変更を必要とするため、共有ネットワークでの使用は推奨されません。
Neither ACC nor SA require the storage of state in the gateway. These schemes should therefore be applicable for all topologies, provided that the hosts using the satellite or hybrid network can be modified. However, these changes are expected to be especially beneficial to networks containing asymmetric satellite links.
ACCもSAも、ゲートウェイにおける状態のストレージを必要とします。これらの方式は、従って、すべてのトポロジに適用可能であるべきで、衛星やハイブリッドネットワークを使用して、ホストが変更することができることを条件とします。しかし、これらの変更は、非対称衛星リンクを含むネットワークに特に有益であることが期待されています。
Note that ECN is a pre-condition for using ACK congestion control. Additionally, the ACK Filtering algorithm discussed in the next section attempts to solve the same problem as ACC. Choosing between the two algorithms (or another mechanism) is currently an open research question.
ECNは、ACKの輻輳制御を使用するための前提条件であることに注意してください。また、次のセクションで説明ACKフィルタリングアルゴリズムは、ACCと同様の問題を解決しようとします。 2つのアルゴリズム（または他のメカニズム）の間で選択すると、現在開いている研究課題です。
ACK Filtering (AF) is designed to address the same ACK congestion effects described in 3.9. Contrary to ACC, however, AF is designed to operate without host modifications.
ACKフィルタリング（AF）は、3.9に記載したのと同じACK輻輳の影響に対処するために設計されています。 ACCに反して、しかし、AFは、ホスト変更なしで動作するように設計されています。
AF takes advantage of the cumulative acknowledgment structure of TCP. The bottleneck router in the reverse direction (the low speed link) must be modified to implement AF. Upon receipt of a segment which represents a TCP acknowledgment, the router scans the queue for redundant ACKs for the same connection, i.e. ACKs which acknowledge portions of the window which are included in the most recent ACK. All of these "earlier" ACKs are removed from the queue and discarded.
AFは、TCPの累積確認応答構造を利用しています。逆方向のボトルネックルータ（低速リンク）はAFを実現するように変更されなければなりません。 TCP確認応答を表すセグメントを受信すると、ルータは、同じ接続のための冗長のACK、すなわち最新のACKに含まれているウィンドウの部分をアクノリッジACKのためのキューを走査します。これらの「以前」ACKのすべてをキューから除去し、廃棄されています。
The router does not store state information, but does need to implement the additional processing required to find and remove segments from the queue upon receipt of an ACK.
ルータは、状態情報を格納しませんが、見つけて、ACKを受信すると、キューからセグメントを削除するために必要な追加の処理を実装する必要がありません。
[BPK97] analyzes the effects of AF. As is the case in ACC, the use of ACK filtering alone would produce significant sender bursts, since the ACKs will be acknowledging more previously-unacknowledged data. The SA modifications described in 3.9.2 could be used to prevent those bursts, at the cost of requiring host modifications. To prevent the need for modifications in the TCP stack, AF is more likely to be paired with the ACK Reconstruction (AR) technique, which can be implemented at the router where segments exit the slow reverse link.
【BPK97】AFの効果を分析します。 ACCの場合のようにACKがより以前に未確認データを承認するため、単独でACKフィルタリングの使用は、有意な送信者バーストを生成します。 3.9.2で説明したSAの変更は、ホスト変更を必要とするコストで、これらのバーストを防ぐために使用することができます。 TCPスタックの変更の必要性を防止するために、AFは、セグメントが低速逆方向リンクを終了し、ルータに実装することができるACK再構成（AR）技術、と対にされる可能性が高いです。
AR inspects ACKs exiting the link, and if it detects large "gaps" in the ACK sequence, it generates additional ACKs to reconstruct an acknowledgment flow which more closely resembles what the data sender would have seen had ACK Filtering not been introduced. AR requires two parameters; one parameter is the desired ACK frequency, while the second controls the spacing, in time, between the release of consecutive reconstructed ACKs.
ARは、リンクを終了ACKを検査し、それがACKシーケンスに大きな「ギャップ」を検出した場合、それはより密接にデータ送信側はACKフィルタリングが導入されていなかった見ているだろうか似ている承認の流れを再構築するために、追加のACKを生成します。 ARは、2つのパラメータが必要です。第二は、連続再構成されたACKの放出との間に、時間的に、間隔を制御しながら、1つのパラメータは、所望のACK周波数です。
In [BPK97], the authors show the combination of AF and AR to increase throughput, in the networks studied, over both unmodified TCP and the ACC/SA modifications. Their results also strongly suggest that the use of AF alone, in networks where congestion losses are expected, decreases performance (even below the level of unmodified TCP Reno) due to sender bursting.
【BPK97]において、著者らは、修飾されていないTCPおよびACC / SA修飾両方の上、検討ネットワークにおいて、スループットを向上させるAFとARとの組み合わせを示します。これらの結果は強くのみAFの使用は、渋滞損失が予想されているネットワークでは、原因送信者の破裂に（でもそのままTCPリノのレベル以下）のパフォーマンスが低下することを示唆しています。
AF delays acknowledgments from arriving at the receiver by dropping earlier ACKs in favor of later ACKs. This process can cause a slight hiccup in the transmission of new data by the TCP sender.
AFは後にACKの賛成で、以前のACKをドロップすることによって、受信機に到着から確認応答を遅らせます。このプロセスは、TCP送信することにより、新しいデータの伝送にわずかなしゃっくりを引き起こす可能性があります。
Both ACK Filtering and ACK Reconstruction require only router modification. However, the implementation of AR requires some storage of state information in the exit router. While AF does not require storage of state information, its use without AR (or SA) could produce undesired side effects. Furthermore, more research is required regarding appropriate ranges for the parameters needed in AR.
ACKフィルタリングとACK復興の両方がルータだけ変更が必要になります。しかし、ARの実装では、出口ルータの状態情報の一部のストレージが必要です。 AFは、状態情報の記憶を必要としないが、AR（またはSA）せず、その使用は、望ましくない副作用を生じる可能性があります。さらに、より多くの研究がARに必要なパラメータのための適切な範囲について必要です。
AF and AR appear applicable to all topologies, assuming that the storage of state information in AR does not prove to be prohibitive for routers which handle large numbers of flows. The fact that TCP stack modifications are not required for AF/AR makes this approach attractive for hybrid networks and networks with diverse types of hosts. These modifications, however, are expected to be most beneficial in asymmetric network paths.
AF及びARは、ARの状態情報の記憶が流れの多数を扱うルータの禁止であることを証明しないと仮定すると、すべてのトポロジに適用見えます。 TCPスタックの変更はAF / ARのために必要されていないという事実は、ホストの多様なタイプのハイブリッドネットワークやネットワークのためのこのアプローチは魅力的。これらの修飾は、しかしながら、非対称のネットワーク経路の中で最も有益であると期待されます。
On the other hand, the implementation of AF/AR requires the routers to examine the TCP header, which prohibits their use in secure networks where IPSEC is deployed. In such networks, AF/AR can be effective only inside the security perimeter of a private, or virtual private network, or in private networks where the satellite link is protected only by link-layer encryption (as opposed to IPSEC). ACK Filtering is safe to use in shared networks (from a congestion control point-of-view), as the number of ACKs can only be reduced, which makes TCP less aggressive. However, note that while TCP is less aggressive, the delays that AF induces (outlined above) can lead to larger bursts than would otherwise occur.
一方、AF / ARの実装では、IPSECが配備されている安全なネットワークでの使用を禁止するTCPヘッダを調べるためにルータを必要とします。そのようなネットワークでは、AF / ARは、プライベート、または仮想プライベートネットワークのセキュリティ境界の内側、または（IPSECとは対照的に）、衛星リンクのみリンク層暗号化により保護されているプライベートネットワークで有効であり得ます。 ACKフィルタリングはACKの数だけTCPあまりアグレッシブになりれ、減少させることができるように、（輻輳制御の視点から）共有ネットワークで使用しても安全です。しかし、TCPはあまり積極的であるが、AFの誘発は、（上記に概説）遅延がさもなければ起こるであろうよりも大きなバーストをもたらすことができることに注意してください。
ACK Filtering attempts to solve the same problem as ACK Congestion Control (as outlined in section 3.9). Which of the two algorithms is more appropriate is currently an open research question.
ACKフィルタリングは（セクション3.9に概説されるように）ACK輻輳制御と同様の問題を解決しようとします。 2つのアルゴリズムのどちらが現在開いている研究課題であるより適切です。
4 Conclusions
4つの結論
This document outlines TCP items that may be able to mitigate the performance problems associated with using TCP in networks containing satellite links. These mitigations are not IETF standards track mechanisms and require more study before being recommended by the IETF. The research community is encouraged to examine the above mitigations in an effort to determine which are safe for use in shared networks such as the Internet.
この文書では、衛星リンクを含むネットワークでTCPを使用するとパフォーマンスの問題を軽減することができるかもしれTCPアイテムの概要を説明します。これらの緩和策は、IETF標準のメカニズムを追跡し、IETFによって推奨される前に、より多くの研究を必要としません。研究コミュニティは、インターネットなどの共有ネットワークでの使用のために安全であるかを決定するための努力では上記の緩和策を検討することが推奨されます。
5 Security Considerations
5セキュリティに関する考慮事項
Several of the above sections noted specific security concerns which a given mitigation aggravates.
上記のセクションのいくつかは、与えられた緩和策が悪化特定のセキュリティ上の懸念を指摘しました。
Additionally, any form of wireless communication link is more susceptible to eavesdropping security attacks than standard wire-based links due to the relative ease with which an attacker can watch the network and the difficultly in finding attackers monitoring the network.
また、無線通信リンクの任意の形態は、攻撃者がネットワークを監視する攻撃者を見つけることでネットワークと困難を見ることができる相対的な容易さに起因する標準的なワイヤベースのリンクより盗聴セキュリティ攻撃を受けやすいです。
6 Acknowledgments
6つの謝辞
Our thanks to Aaron Falk and Sally Floyd, who provided very helpful comments on drafts of this document.
この文書の草稿に非常に有用なコメントを提供アーロンフォークとサリーフロイドに私たちのおかげで、。
7 References
7つの参考文献
[AFP98] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
[AFP98]オールマン、M.、フロイド、S.とC.ヤマウズラ、RFC 2414、1998年9月 "TCPの初期ウィンドウを増やします"。
[AGS99] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[AGS99]オールマン、M.、グローバー、D.およびL.サンチェス、BCP 28、RFC 2488、1999年1月、 "標準的なメカニズムを使用してTCP上の衛星テレビの強化"。
[AHKO97] Mark Allman, Chris Hayes, Hans Kruse, Shawn Ostermann. TCP Performance Over Satellite Links. In Proceedings of the 5th International Conference on Telecommunication Systems, March 1997.
[AHKO97]マーク・オールマン、クリス・ヘイズ、ハンス・クルーゼ、ショーンOstermann。衛星リンク上でTCPの性能。通信システム、1997年3月に第5回国際会議の議事録。
[AHO98] Mark Allman, Chris Hayes, Shawn Ostermann. An Evaluation of TCP with Larger Initial Windows. Computer Communication Review, 28(3), July 1998.
[AHO98]マーク・オールマン、クリス・ヘイズ、ショーンOstermann。大きな初期のWindowsでのTCPの評価。コンピュータコミュニケーションレビュー、28（3）、1998年7月。
[AKO96] Mark Allman, Hans Kruse, Shawn Ostermann. An Application-Level Solution to TCP's Satellite Inefficiencies. In Proceedings of the First International Workshop on Satellite-based Information Services (WOSBIS), November 1996.
[AKO96]マーク・オールマン、ハンス・クルーゼ、ショーンOstermann。 TCPのサテライト非効率にアプリケーションレベルのソリューション。上の第一回国際ワークショップの議事録では、衛星ベースの情報サービス（WOSBIS）、1996年11月。
[All97a] Mark Allman. Improving TCP Performance Over Satellite Channels. Master's thesis, Ohio University, June 1997.
[All97a]マークオールマン。衛星チャネル上でTCPの性能を向上させます。修士論文、オハイオ大学、1997年6月。
[All97b] Mark Allman. Fixing Two BSD TCP Bugs. Technical Report CR-204151, NASA Lewis Research Center, October 1997.
[All97b]マークオールマン。二つのBSD TCPのバグを修正。テクニカルレポートCR-204151、NASAルイスリサーチセンター、1997年10月。
[All98] Mark Allman. On the Generation and Use of TCP Acknowledgments. ACM Computer Communication Review, 28(5), October 1998.
[All98]マークオールマン。世代オンとTCP謝辞の使用。 ACMコンピュータコミュニケーションレビュー、28（5）、1998年10月。
[AOK95] Mark Allman, Shawn Ostermann, Hans Kruse. Data Transfer Efficiency Over Satellite Circuits Using a Multi-Socket Extension to the File Transfer Protocol (FTP). In Proceedings of the ACTS Results Conference, NASA Lewis Research Center, September 1995.
[AOK95]マーク・オールマン、ショーンOstermann、ハンス・クルーゼ。ファイル転送プロトコル（FTP）にマルチ・ソケット拡張機能を使用した衛星回線上のデータ転送効率。 ACTSの議事録では会議、NASAルイスリサーチセンター、1995年9月の結果。
[AP99] Mark Allman, Vern Paxson. On Estimating End-to-End Network Path Properties. ACM SIGCOMM, September 1999.
[AP99]マーク・オールマン、バーン・パクソン。推定エンドツーエンドのネットワークパスの性質について。 ACM SIGCOMM、1999年9月。
[APS99] Allman, M., Paxson, V. and W. Richard Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[APS99]オールマン、M.、パクソン、V.とW.リチャードスティーヴンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[BCC+98] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[BCC + 98]ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、G.、ヤマウズラ、C.、ピーターソン、L.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.とL.チャン、 "インターネットの待ち行列管理と輻輳回避に関する提言"、RFC 2309、1998年4月。
[BKVP97] B. Bakshi and P. Krishna and N. Vaidya and D. Pradham, "Improving Performance of TCP over Wireless Networks", 17th International Conference on Distributed Computing Systems (ICDCS), May 1997.
[BKVP97] B.バクシとP.クリシュナとN. VaidyaとD. Pradham、「ワイヤレスネットワーク上のTCPのパフォーマンスの向上」、分散コンピューティングシステム上の第17回国際会議（ICDCS）、1997年5月。
[BPK97] Hari Balakrishnan, Venkata N. Padmanabhan, and Randy H. Katz. The Effects of Asymmetry on TCP Performance. In Proceedings of the ACM/IEEE Mobicom, Budapest, Hungary, ACM. September, 1997.
【BPK97]ハリ・バラクリシュナン、ヴェンカタN. Padmanabhan、およびランディH.カッツ。 TCPの性能上の非対称性の影響。 ACM / IEEEモビコム、ブダペスト、ハンガリー、ACMの議事録。 1997年9月。
[BPK98] Hari Balakrishnan, Venkata Padmanabhan, Randy H. Katz. The Effects of Asymmetry on TCP Performance. ACM Mobile Networks and Applications (MONET), 1998 (to appear).
【BPK98]ハリ・バラクリシュナン、ヴェンカタPadmanabhan、ランディH.カッツ。 TCPの性能上の非対称性の影響。 ACMモバイルネットワークとアプリケーション（MONET）、1998（出現します）。
[BPSK96] H. Balakrishnan and V. Padmanabhan and S. Sechan and R. Katz, "A Comparison of Mechanisms for Improving TCP Performance over Wireless Links", ACM SIGCOMM, August 1996.
[BPSK96] H.バラクリシュナンとV. PadmanabhanとS. SechanとR.カッツ、 "ワイヤレスリンク上でTCPのパフォーマンスを向上させるためのメカニズムの比較"、ACM SIGCOMM、1996年8月。
[Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[Bra89]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[Bra92] Braden, R., "Transaction TCP -- Concepts", RFC 1379, September 1992.
[Bra92]ブレーデン、R.、 "トランザクションTCP - 概念"、RFC 1379、1992年9月。
[Bra94] Braden, R., "T/TCP -- TCP Extensions for Transactions: Functional Specification", RFC 1644, July 1994.
[Bra94]ブレーデン、R.、 "T / TCP - 取引のためのTCP拡張機能：機能仕様"、RFC 1644、1994年7月。
[BRS99] Hari Balakrishnan, Hariharan Rahul, and Srinivasan Seshan. An Integrated Congestion Management Architecture for Internet Hosts. ACM SIGCOMM, September 1999.
【BRS99]ハリ・バラクリシュナン、ハリハーラーンラーフル、およびスリニバサン・セシャン。インターネットホストのための統合された輻輳管理アーキテクチャ。 ACM SIGCOMM、1999年9月。
[ddKI99] M. deVivo, G.O. deVivo, R. Koeneke, G. Isern. Internet Vulnerabilities Related to TCP/IP and T/TCP. Computer Communication Review, 29(1), January 1999.
【ddKI99] M. deVivo、G.O. deVivo、R. Koeneke、G. Isern。 TCP / IPおよびT / TCPに関連するインターネットの脆弱性。コンピュータコミュニケーションレビュー、29（1）、1999年1月。
[DENP97] Mikael Degermark, Mathias Engan, Bjorn Nordgren, Stephen Pink. Low-Loss TCP/IP Header Compression for Wireless Networks. ACM/Baltzer Journal on Wireless Networks, vol.3, no.5, p. 375-87.
[DENP97]ミカエルDegermark、マティアスEngan、ビョルンNordgren、スティーブン・ピンク。低損失のTCP /無線ネットワークのIPヘッダー圧縮。ワイヤレスネットワーク上のACM / Baltzer誌、第3巻、第5号、P。 375から87。
[DMT96] R. C. Durst and G. J. Miller and E. J. Travis, "TCP Extensions for Space Communications", Mobicom 96, ACM, USA, 1996.
【DMT96] R. C.ダーストとG. J.ミラーとE. J.トラビス、 "宇宙通信のためのTCP拡張"、モビコム96、ACM、USA、1996。
[DNP99] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[DNP99] Degermark、M.、Nordgren、B.とS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[FF96] Kevin Fall, Sally Floyd. Simulation-based Comparisons of Tahoe, Reno, and SACK TCP. Computer Communication Review, V. 26 N. 3, July 1996, pp. 5-21.
[FF96]ケビン秋、サリーフロイド。タホ、リノ、およびSACK TCPのシミュレーションベースの比較。コンピュータコミュニケーションレビュー、V. 26 N. 3、1996年7月、頁5-21。
[FF99] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet, IEEE/ACM Transactions on Networking, August 1999.
[FF99]サリー・フロイド、ケビン秋。ネットワーキング、1999年8月にIEEE / ACMの取引は、インターネットでのエンドツーエンドの輻輳制御の利用促進します。
[FH99] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[FH99]フロイド、S.とT.ヘンダーソン、 "TCPの高速回復アルゴリズムにNewRenoの変更"、RFC 2582、1999年4月。
[FJ93] Sally Floyd and Van Jacobson. Random Early Detection Gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, V. 1 N. 4, August 1993.
[FJ93]サリー・フロイドとバン・ジェイコブソン。輻輳回避のためのランダム早期検出ゲートウェイ、ネットワーク上のIEEE / ACM取引、V. 1 N. 4、1993年8月。
[Flo91] Sally Floyd. Connections with Multiple Congested Gateways in Packet-Switched Networks, Part 1: One-way Traffic. ACM Computer Communications Review, V. 21, N. 5, October 1991.
【Flo91]サリー・フロイド。パケット交換ネットワーク、パート1の複数の混雑のゲートウェイとの接続：一方通行。 ACMコンピュータコミュニケーションレビュー、V. 21、N. 5、1991年10月。
[Flo94] Sally Floyd. TCP and Explicit Congestion Notification, ACM Computer Communication Review, V. 24 N. 5, October 1994.
【Flo94]サリー・フロイド。 TCPと明示的輻輳通知、ACMコンピュータコミュニケーションレビュー、V. 24 N. 5、1994年10月。
[Flo99] Sally Floyd. "Re: TCP and out-of-order delivery", email to end2end-interest mailing list, February, 1999.
【Flo99]サリー・フロイド。 「再：TCPとアウトオブオーダー配信」、end2end金利メーリングリストへの電子メール、1999年2月。
[Hah94] Jonathan Hahn. MFTP: Recent Enhancements and Performance Measurements. Technical Report RND-94-006, NASA Ames Research Center, June 1994.
[Hah94]ジョナサン・ハーン。 MFTP：最近の機能強化とパフォーマンスの測定。テクニカルレポートRND-94から006、NASAエイムズ研究センター、1994年6月。
[Hay97] Chris Hayes. Analyzing the Performance of New TCP Extensions Over Satellite Links. Master's Thesis, Ohio University, August 1997.
[Hay97]クリス・ヘイズ。衛星リンク上で新しいTCP拡張機能のパフォーマンスの分析。修士論文、オハイオ大学、1997年8月。
[HK98] Tom Henderson, Randy Katz. On Improving the Fairness of TCP Congestion Avoidance. Proceedings of IEEE Globecom `98 Conference, 1998.
[HK98]トム・ヘンダーソン、ランディカッツ。 TCPの輻輳回避の公平性の改善に関する。 `98の会議、1998 GLOBECOM IEEEの議事録。
[HK99] Tim Henderson, Randy Katz. Transport Protocols for Internet-Compatible Satellite Networks, IEEE Journal on Selected Areas of Communications, February, 1999.
【HK99】ティム・ヘンダーソン、ランディカッツ。コミュニケーションズ、1999年2月の選択領域上のインターネット対応の衛星ネットワーク、IEEEジャーナルのためのトランスポートプロトコル。
[Hoe95] J. Hoe, Startup Dynamics of TCP's Congestion Control and Avoidance Schemes. Master's Thesis, MIT, 1995.
【Hoe95] J.鍬、TCPの輻輳制御と回避スキームの起動ダイナミクス。修士論文、MIT、1995。
[Hoe96] Janey Hoe. Improving the Startup Behavior of a Congestion Control Scheme for TCP. In ACM SIGCOMM, August 1996.
【Hoe96] Janey鍬。 TCP輻輳制御方式の起動時の動作を改善。 ACM SIGCOMM、1996年8月に。
[IL92] David Iannucci and John Lakashman. MFTP: Virtual TCP Window Scaling Using Multiple Connections. Technical Report RND-92-002, NASA Ames Research Center, January 1992.
[IL92]デヴィッド・IannucciとジョンLakashman。 MFTP：複数の接続を使用した仮想TCPウィンドウスケーリング。テクニカルレポートRND-92から002、NASAエイムズ研究センター、1992年1月。
[Jac88] Van Jacobson. Congestion Avoidance and Control. In Proceedings of the SIGCOMM '88, ACM. August, 1988.
【Jac88]バン・ジェイコブソン。輻輳回避とコントロール。 SIGCOMM '88、ACMの議事録。 8月、1988。
[Jac90] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, February 1990.
[Jac90]ジェーコブソン、V.、 "圧縮TCP / IPヘッダ"、RFC 1144、1990年2月。
[JBB92] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[JBB92]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[JK92] Van Jacobson and Mike Karels. Congestion Avoidance and Control. Originally appearing in the proceedings of SIGCOMM '88 by Jacobson only, this revised version includes an additional appendix. The revised version is available at ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. 1992.
[JK92]バン・ジェイコブソンとマイクKarels。輻輳回避とコントロール。もともとヤコブソンによるSIGCOMM '88の議事録に登場するだけで、この改訂版は、追加の付録が含まれています。改訂版はftp://ftp.ee.lbl.gov/papers/congavoid.ps.Zで入手可能です。 1992。
[Joh95] Stacy Johnson. Increasing TCP Throughput by Using an Extended Acknowledgment Interval. Master's Thesis, Ohio University, June 1995.
[Joh95]ステイシー・ジョンソン。拡張謝辞間隔を使用したTCPスループットを増やします。修士論文、オハイオ大学、1995年6月。
[KAGT98] Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran. HTTP Page Transfer Rates Over Geo-Stationary Satellite Links. March 1998. Proceedings of the Sixth International Conference on Telecommunication Systems.
[KAGT98]ハンス・クルーゼ、マーク・オールマン、ジム・Griner、Diepchiトラン。ジオ静止衛星リンク上でHTTPページ転送レート。通信システムの第6回国際会議の1998年3月議事。
[Kes91] Srinivasan Keshav. A Control Theoretic Approach to Flow Control. In ACM SIGCOMM, September 1991.
【Kes91]スリニバサン・ケスハフ。フロー制御するための制御理論的アプローチ。 ACM SIGCOMM、1991年9月。
[KM97] S. Keshav, S. Morgan. SMART Retransmission: Performance with Overload and Random Losses. Proceeding of Infocom. 1997.
[KM97] S. Keshav、S.モーガン。 SMART再送：過負荷とランダム損失によるパフォーマンス。インフォコムの議事録。 1997。
[KVR98] Lampros Kalampoukas, Anujan Varma, and K. K.Ramakrishnan. Improving TCP Throughput Over Two-Way Asymmetric Links: Analysis and Solutions. Measurement and Modeling of Computer Systems, 1998, Pages 78-89.
【KVR98] Lampros Kalampoukas、Anujanヴァルマ、及びK. K.Ramakrishnan。分析と解決策：TCPスループットオーバー双方向非対称リンクを向上させます。測定およびコンピュータシステムのモデル化、1998年、ページ78-89。
[MM96a] M. Mathis, J. Mahdavi, "Forward Acknowledgment: Refining TCP Congestion Control," Proceedings of SIGCOMM'96, August, 1996, Stanford, CA. Available from http://www.psc.edu/networking/papers/papers.html
[MM96a] M.マシス、J. Mahdavi、 "フォワード謝辞：精錬TCP輻輳制御、" SIGCOMM'96の議事録、8月、1996年、スタンフォード大学、カリフォルニアhttp://www.psc.edu/networking/papers/papers.htmlから入手可能
[MM96b] M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding Parameters" Available from http://www.psc.edu/networking/papers/FACKnotes/current.
[MM96b] M.マシス、J. Mahdavi http://www.psc.edu/networking/papers/FACKnotes/currentから利用可能な、 "バウンディングパラメータを使用したTCP率-半減"。
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
【MMFR96]マティス、M.、Mahdavi、J.、フロイド、S.とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[MSMO97] M. Mathis, J. Semke, J. Mahdavi, T. Ott, "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm",Computer Communication Review, volume 27, number3, July 1997. Available from http://www.psc.edu/networking/papers/papers.html
HTTPから利用可能な[MSMO97] M.マシス、J. Semke、J. Mahdavi、T.オット、コンピュータコミュニケーションレビュー、ボリューム27 "TCPの輻輳回避アルゴリズムの巨視的挙動"、number3、1997年7月：// WWW .psc.edu /ネットワーキング/論文/ papers.html
[MV98] Miten N. Mehta and Nitin H. Vaidya. Delayed Duplicate-Acknowledgments: A Proposal to Improve Performance of TCP on Wireless Links. Technical Report 98-006, Department of Computer Science, Texas A&M University, February 1998.
[MV98]マイトンN.メータとニティンH. Vaidya。遅延重複-謝辞：無線リンク上のTCPの性能を向上させるために提案。テクニカルレポート98から006、コンピュータサイエンス学部、テキサスA＆M大学、1998年2月。
[Nic97] Kathleen Nichols. Improving Network Simulation with Feedback. Com21, Inc. Technical Report. Available from http://www.com21.com/pages/papers/068.pdf.
【Nic97]キャサリン・ニコルズ。フィードバックによるネットワークシミュレーションの改善。 COM21、Inc.のテクニカルレポート。 http://www.com21.com/pages/papers/068.pdfから入手できます。
[PADHV99] Paxson, V., Allman, M., Dawson, S., Heavens, I. and B. Volz, "Known TCP Implementation Problems", RFC 2525, March 1999.
[PADHV99]パクソン、V.、オールマン、M.、ドーソン、S.、天、I.およびB.フォルツ、 "既知のTCP実装の問題"、RFC 2525、1999年3月。
[Pax97] Vern Paxson. Automated Packet Trace Analysis of TCP Implementations. In Proceedings of ACM SIGCOMM, September 1997.
【Pax97]バーン・パクソン。 TCP実装の自動化されたパケットトレース解析。 ACM SIGCOMM、1997年9月の議事録。
[PN98] Poduri, K. and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[PN98] Poduri、K.とK.ニコルズ、 "増加した初期のTCPウィンドウサイズのシミュレーション研究"、RFC 2415、1998年9月。
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
【Pos81]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RF99] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[RF99]ラマクリシュナン、K.およびS.フロイド、 "IPに明示的輻輳通知（ECN）を追加する提案"、RFC 2481、1999年1月。
[SF98] Nihal K. G. Samaraweera and Godred Fairhurst, "Reinforcement of TCP error Recovery for Wireless Communication", Computer Communication Review, volume 28, number 2, April 1998.
[SF98]ニハルK. G. SamaraweeraとGodred Fairhurst、 "無線通信のための強化TCPのエラー回復"、コンピュータコミュニケーションレビュー、ボリューム28、ナンバー2、1998年4月。
[SP98] Shepard, T. and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[SP98]シェパード、T.とC.パートリッジ、RFC 2416、1998年9月「TCPは3つしかバッファに4つのパケットで起動」。
[Ste97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
[Ste97]スティーブンス、W.、 "TCPスロースタート、輻輳回避、高速再送、および高速リカバリアルゴリズム"、RFC 2001、1997年1月。
[Sut98] B. Suter, T. Lakshman, D. Stiliadis, and A. Choudhury. Design Considerations for Supporting TCP with Per-flow Queueing. Proceedings of IEEE Infocom `98 Conference, 1998.
【Sut98] B.スーター、T.ラクシュマン、D. Stiliadis、およびA.チョードリー。フローごとのキューイングとTCPをサポートするための設計上の考慮事項。 IEEEインフォコム `98大会、1998年の議事。
[Tou97] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[Tou97]タッチ、J.、 "TCP制御ブロック相互依存"、RFC 2140、1997年4月。
[VH97a] Vikram Visweswaraiah and John Heidemann. Improving Restart of Idle TCP Connections. Technical Report 97-661, University of Southern California, 1997.
[VH97a]ビクラムVisweswaraiahとジョンHeidemann。アイドルTCPコネクションの再起動を向上させます。テクニカルレポート97から661、南カリフォルニア大学、1997。
[VH97b] Vikram Visweswaraiah and John Heidemann. Rate-based pacing Source Code Distribution, Web page: http://www.isi.edu/lsam/publications/rate_based_pacing/README.html November, 1997.
[VH97b]ビクラムVisweswaraiahとジョンHeidemann。レートベースペーシングソースコードの配布、Webページ：http://www.isi.edu/lsam/publications/rate_based_pacing/README.html 11月、1997。
[VH98] Vikram Visweswaraiah and John Heidemann. Improving Restart of Idle TCP Connections (revised). Submitted for publication.
[VH98]ビクラムVisweswaraiahとジョンHeidemann。アイドルTCPコネクションの再起動を改善する（改訂）。出版のために提出されました。
8 Authors' Addresses
8本の著者のアドレス
Mark Allman NASA Glenn Research Center/BBN Technologies Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
マーク・オールマンNASAグレンリサーチセンター/ BBNテクノロジーズルイス・フィールド21000ブルックパークRdを。 MS 54-2クリーブランド、オハイオ州44135
EMail: mallman@grc.nasa.gov http://roland.grc.nasa.gov/~mallman
メールアドレス：mallman@grc.nasa.gov http://roland.grc.nasa.gov/~mallman
Spencer Dawkins Nortel P.O.Box 833805 Richardson, TX 75083-3805
スペンサー・ドーキンスノーテルP.O.Box 833805リチャードソン、テキサス州75083から3805
EMail: Spencer.Dawkins.sdawkins@nt.com
メールアドレス：Spencer.Dawkins.sdawkins@nt.com
Dan Glover NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 3-6 Cleveland, OH 44135
ダン・グローバーNASAグレンリサーチセンタールイス・フィールド21000ブルックパークRdを。 MS 3-6クリーブランド、オハイオ州44135
EMail: Daniel.R.Glover@grc.nasa.gov http://roland.grc.nasa.gov/~dglover
メールアドレス：Daniel.R.Glover@grc.nasa.gov http://roland.grc.nasa.gov/~dglover
Jim Griner NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
ジム・Griner NASAグレンリサーチセンタールイス・フィールド21000ブルックパークRdを。 MS 54-2クリーブランド、オハイオ州44135
EMail: jgriner@grc.nasa.gov http://roland.grc.nasa.gov/~jgriner
メールアドレス：jgriner@grc.nasa.gov http://roland.grc.nasa.gov/~jgriner
Diepchi Tran NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
DiepchiトランNASAグレンリサーチセンタールイス・フィールド21000ブルックパークRdを。 MS 54-2クリーブランド、オハイオ州44135
EMail: dtran@grc.nasa.gov
メールアドレス：dtran@grc.nasa.gov
Tom Henderson University of California at Berkeley Phone: +1 (510) 642-8919
カリフォルニア大学バークレー校のトム・ヘンダーソン大学電話：+1（510）642-8919
EMail: tomh@cs.berkeley.edu URL: http://www.cs.berkeley.edu/~tomh/
メールアドレス：tomh@cs.berkeley.edu URL：http://www.cs.berkeley.edu/~tomh/
John Heidemann University of Southern California/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695
南カリフォルニア/情報科学研究所のジョン・Heidemann大学4676アドミラルティWayマリナデルレイ、カリフォルニア州90292から6695
EMail: johnh@isi.edu
メールアドレス：johnh@isi.edu
Joe Touch University of Southern California/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6601 USA
南カリフォルニア/情報科学研究所のジョー・タッチ大学4676アドミラルティWayマリナデルレイ、カリフォルニア州90292から6601 USA
Phone: +1 310-448-9151 Fax: +1 310-823-6714 URL: http://www.isi.edu/touch EMail: touch@isi.edu
電話：+1 310-448-9151ファックス：+1 310-823-6714 URL：http://www.isi.edu/touch Eメール：touch@isi.edu
Hans Kruse J. Warren McClure School of Communication Systems Management Ohio University 9 S. College Street Athens, OH 45701
通信システムのハンス・クルーゼJ.ウォーレンマクルーア学校管理オハイオ大学9 S.・カレッジ・ストリートアテネ、OH 45701
Phone: 740-593-4891 Fax: 740-593-4889 EMail: hkruse1@ohiou.edu http://www.csm.ohiou.edu/kruse
電話：740-593-4891ファックス：740-593-4889 Eメール：hkruse1@ohiou.edu http://www.csm.ohiou.edu/kruse
Shawn Ostermann School of Electrical Engineering and Computer Science Ohio University 416 Morton Hall Athens, OH 45701
電気工学とコンピュータサイエンスオハイオ大学のショーンOstermann学校416モートンホールアテネ、OH 45701
Phone: (740) 593-1234 EMail: ostermann@cs.ohiou.edu
電話：（740）593-1234 Eメール：ostermann@cs.ohiou.edu
Keith Scott The MITRE Corporation M/S W650 1820 Dolley Madison Blvd. McLean VA 22102-3481
キース・スコット・ザ・MITRE社M / S W650 1820ドリー・マディソンブルバードマクリーンVA 22102-3481
EMail: kscott@mitre.org
メールアドレス：kscott@mitre.org
Jeffrey Semke Pittsburgh Supercomputing Center 4400 Fifth Ave. Pittsburgh, PA 15213
ジェフリーSemkeピッツバーグ・スーパーコンピューティング・センター4400フィフスアベニューピッツバーグ、PA 15213
EMail: semke@psc.edu http://www.psc.edu/~semke
メールアドレス：semke@psc.edu http://www.psc.edu/~semke
9 Full Copyright Statement
9完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。