[要約] 要約： RFC 2760は、衛星に関連するTCPの継続的な研究についての文書であり、衛星通信におけるTCPのパフォーマンスと改善に焦点を当てています。目的： 1. 衛星通信におけるTCPのパフォーマンスの理解を深める。 2. 衛星通信環境でのTCPの改善策を提案する。 3. 衛星通信におけるTCPの実装と運用に関するガイドラインを提供する。
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
衛星に関連する継続的なTCP研究
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.
Copyright（c）The Internet Society（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].
一部の衛星ネットワークは、リンクの一方の端に伝送力とアンテナサイズの制限があるため、帯域幅の非対称性を示します。一方、他の衛星システムの一部は単方向であり、非衛星リターンパス（Dialup Modemリンクなど）を使用しています。ほとんどの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 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.
TCPは、3方向の握手を使用して、2つのホスト[POS81]間の接続をセットアップします。この接続セットアップには、データ送信者が接続を積極的に開始するか受動的に開始したかに応じて、1〜1.5の往復時間（RTT）が必要です。この起動時間は、TCP拡張機能をトランザクション（T/TCP）[BRA94]を使用して排除できます。ホストのペア間の最初の接続が確立された後、T/TCPは3方向の握手をバイパスすることができ、データ送信者は送信された最初のセグメントでデータの送信を開始できます（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は、混雑制御の観点から共有ネットワークに実装するのが安全ですが、最初のデータセグメントでデータを送信することのいくつかのセキュリティの意味が特定されています[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.3）またはバイトカウント（セクション3.2.2）の後に、より大きな初期輻輳ウィンドウ（セクション3.2.1を参照）、遅延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 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は、スロースタートフェーズ中の無駄な容量のもう1つのソースです。RFC 1122 [BRA89]は、データ受信機がすべての着信データセグメントを控えることを控えることを提案しています。ただし、2秒ごとのフルサイズのセグメントをAckedする必要があります。2番目のフルサイズのセグメントが特定のタイムアウト内で到着しない場合、ACKを生成する必要があります（このタイムアウトは500ミリ秒を超えることはできません）。データ送信者は、到着ACKの数に基づいてCWNDのサイズを増加させるため、ACKの数を減らすとCWND成長率が遅くなります。さらに、TCPが送信を開始すると、1つのセグメントが送信されます。遅延ACKを使用する場合、ACKが送信される前に2番目のセグメントが到着する必要があります。したがって、レシーバーは常に、遅延した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).
スロースタート（したがって、無駄な容量の量）で必要な時間を短縮する1つの方法は、CWNDの初期値を増やすことです。[AFP98]で概説されている実験的なTCP拡張により、CWNDの初期サイズを1つのセグメントから式（1）で与えられたセグメントに増やすことができます。
min (4*MSS, max (2*MSS, 4380 bytes)) (1)
min（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の初期値を増やすことにより、データ送信の最初のRTTでより多くのパケットが送信され、より多くのACKがトリガーされ、輻輳ウィンドウがより迅速に開くことができます。さらに、最初に少なくとも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]。 [AHO98]は、CWNDに大きな初期値を使用する場合、インターネット上の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スタックの変更が必要です。RFC 2581 [APS99]により、2つのセグメントの初期輻輳ウィンドウを使用することが許可されています。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.
また、遅延スタート後にのみ遅延ACKSを使用する（セクション3.2.3で概説されているように）、転送の最初のセグメントをすぐにACKし、輻輳ウィンドウをより迅速に開くための代替方法を提供します。最後に、いくつかの形式のTCP状態共有を使用すると、（3.8で説明されているように）、固定された大きな初期ウィンドウを使用する代替手段が提供される場合があります。
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送信者が必要とする時間を増加させます。これは、長距離ジオ衛星リンクを横断するフローに特に有害です。ACKの遅延によって引き起こされる問題を軽減するために提案されている1つのメカニズムは、標準のACKカウント[ALL97A、ALL98]ではなく、「バイトカウント」の使用です。標準のACKカウントを使用して、スロースタート中に受信した各ACKに対して1セグメントごとに輻輳ウィンドウが増加します。ただし、輻輳ウィンドウの増加をカウントするBYTEを使用すると、受信した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]では、2つの形式のバイトカウントが研究されています。1つ目は、無制限のバイトカウント（UBC）です。このメカニズムは、ACKが到着するたびに、以前に未把握されていないバイトの数を使用して、渋滞ウィンドウを増やすだけです。2番目のフォームは、制限されたバイトカウント（LBC）です。LBCは、CWNDの増加の量を2つのセグメントに制限します。この制限は、「ストレッチACK」[Pax97]に応じて送信されたデータのバーストのサイズを調整します。Stretch Acksは、以前に未知のデータの2つ以上のセグメントをカバーする謝辞です。ストレッチアクックは、実装バグ[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は緩和回避中にbyteカウントを使用して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カウントとは対照的に、BYTEカウントを使用して、衛星ネットワークの適切なサイズにCWNDの値を増やすために必要な時間を短縮することが示されています[All97a]。さらに、[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]は、非対称ネットワークのさまざまなACKフィルタリングアルゴリズム（セクション3.10で説明）と組み合わせて、無制限のBYTEカウントを調査しました。
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.
一部の人から（および他の人に既に批判された）バイトカウントにより、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はスロースタート中に1つのセグメントのみをカバーするため、スロースタート後（セクション3.2.3で概説されている）が制限されたバイトカウントアルゴリズムを無効にすると、遅延ACKSを使用することで。したがって、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の数を使用して、スロースタート中に混雑ウィンドウを増やします。また、遅延ACKSがレシーバーによって返されるACKの数を約半分に減らすため、輻輳ウィンドウの成長率は減少します。この問題の提案された解決策の1つは、遅延スタート（DAASS）フェーズ後にのみ遅延ACKSを使用することです。これにより、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の主要な問題は、実装です。受信者は、送信者がいつスロースタートアルゴリズムを使用しているかを何らかの形で知る必要があります。受信者は、受信中のデータの量の変更を監視し、それに応じてアクチキング動作を変更しようとするヒューリスティックを実装できます。または、送信者は、遅いスタートを使用していることを示すメッセージ（おそらく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はセクション2に示されているすべてのシナリオで等しく機能する必要がありますが、非対称ネットワークでは、ACKの数が増加しているため、リンクリンクでACKの混雑を悪化させる可能性があります（ACK輻輳の詳細については、セクション3.9および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の数が増加します。DAASSとACKの数を減らす方法との相互作用は、オープンな研究の質問です。また、上記のセクション3.2.1.5で述べたように、DAASSは、より大きな初期輻輳ウィンドウを使用するのと同じ利点を提供するため、両方のメカニズムを一緒に使用することは望ましくない場合があります。ただし、これは未解決の問題のままです。最後に、DaassとLimited Byte Countingは、どちらも混雑ウィンドウが開く速度を上げるために使用されます。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.
初期のスロースタートフェーズは、TCPによって使用され、特定のネットワーク条件の適切な輻輳ウィンドウサイズを決定します[JAC88]。TCPが混雑を検出したとき、またはCWNDのサイズが受信機の宣伝されたウィンドウのサイズに達すると、スロースタートが終了します。CWNDが特定のサイズを超えて成長した場合、スロースタートも終了します。TCPが終了するしきい値は、スロースタートを遅くし、混雑回避アルゴリズムの使用を開始します。ほとんどの実装では、SSthreshの初期値はレシーバーの宣伝ウィンドウです。スロースタート中、TCPはRTTごとにCWNDのサイズをほぼ2倍にし、したがって、ネットワークの最大2倍のセグメントでネットワークを圧倒することができます。SSThreshを最初にレシーバーの宣伝されたウィンドウよりも小さい値に設定することにより、送信者は適切なセグメントの2倍の数でネットワークを圧倒することを避けることができます。hoe [hoe96]は、パケットペアアルゴリズム[KES91]と測定されたRTTを使用して、SSTHRESHのより適切な値を決定することを提案しています。このアルゴリズムは、最初の数枚の戻ってくるアックの間の間隔を観察して、ボトルネックリンクの帯域幅を決定します。測定された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の推定は、RFC 2581 [APS99]で概説されているよりもTCPをより保守的にすることができるため、輻輳制御の観点から生産ネットワークに実装するのが安全です（TCP実装は[APS99]で許可されているインフィニティの初期SSSHRESHを使用していると仮定します）。
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.
このメカニズムは、セクション2で概説されているすべての対称的なトポロジで等しく機能することが予想されます。ただし、非対称リンクは、戻ってくるAcksの速度が前方方向のボトルネックの帯域幅ではない可能性があるため、特別な問題を引き起こします。これにより、送信者が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]を使用すると、送信者側の帯域幅推定の有効性が低下することを示しています。 したがって、遅延スタート中にのみ遅延ACKSを使用すると（セクション3.2.3で概説されているように）、帯域幅の推定がより実現可能になる場合があります。
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として知られるこれらの送信者側のアルゴリズムは、選択的承認（SACKS）[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がresしているときに送信される最後のセグメントである場合を検討してください。セグメント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.
Hoe [Hoe95、Hoe96]は、部分的なAcksを使用して再送信をトリガーするというアイデアを紹介し、そうすることでパフォーマンスを改善できることを示しました。[FF96]は、部分的なAcksを使用して再送信をトリガーすることで、複数の失われたセグメントから回復するのに必要な時間を短縮する場合があることを示しています。ただし、[FF96]は、RTOタイマーに依存することで（多くの失われたセグメント）がパフォーマンスを向上させることができることを示しています。パルティアルACKを使用してすべての再送信をトリガーするだけです。[HK99]は、部分的なAcksを使用して再送信をトリガーするために、サックと組み合わせて再送信をトリガーすると、衛星環境での高速再送信/高速回復を使用してTCPと比較するとパフォーマンスが向上することを示しています。最後に、[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).
Fall and Floyd [FF96]は、受信者が送信した選択的謝辞（SACKS）[MMFR96]によって提供される情報を考慮した高速回復アルゴリズムの保守的な拡張を説明しています。Algorithmは、高速再送信がセグメントの控えめをトリガーした後に開始します。高速再送信と同様に、アルゴリズムは損失が検出されたときにCWNDを半分に削減します。このアルゴリズムは、「パイプ」と呼ばれる変数を保持します。これは、ネットワーク内の発行済みセグメントの数の推定値です。パイプ変数は、新しいサック情報に到達する各重複ACKの1つのセグメントによって減少します。パイプ変数は、送信された新規または再送信セグメントごとに1で増分されます。パイプの値が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は、損失検出の1つのRTT内のデータウィンドウ内の複数のセグメント損失から回復できます。以下で説明するForward Ancountment（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セグメントが失われた場合、いくつかの非サックベースの回復アルゴリズムよりも優れたパフォーマンスを発揮することを示しています。[Ahko97]は、アルゴリズムが衛星リンク上のパフォーマンスを改善することを示しています。Hayes [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スタックに実装されています。ただし、受信機によって生成されたサック情報に依存しています。このアルゴリズムは共有ネットワークに安全であり、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.
喪失回復中にTCPの輻輳制御を改善するために、フォワード認識（FACK）アルゴリズム[MM96A、MM96B]が開発されました。FackはTCP Sackオプションを使用して、うっ血状態に関する追加情報を収集し、回復中にネットワークへのデータの注入をより正確に制御します。Fackは、Data Recovery Algorithmsの混雑制御アルゴリズムを切り離し、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の最新バージョンは、レートハービング[MM96B]で、回復中に受信した2つのACKごとに1つのパケットが送信されます。すべての人のACKのセグメントを送信することは、ネットワークによって正常に処理されたパケットの数の半分に1回の往復で混雑ウィンドウを減らすことの結果です（したがって、CWNDが2倍以上大きすぎる場合はまだ2倍以上ですネットワークが維持できるものの半分に減少します）。レートハービングを備えたFACKのもう1つの重要な側面は、すべての他のACKのパケットを送信すると、FASTで要求されるように、送信前にネットワークから排出するためにデータの半分のデータを必要としないため、回復中に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サックブロックがセグメントを留保する前に特定のセグメントが欠落していることを示すまで待機することにより、すべてのセグメントへのしきい値の再送信を適用します。これにより、セグメントを並べ替えるリンクでの合理的な動作が可能になります。上記のように、Fackは、回復中に受信した2秒ごとにセグメントを送信します。TCPREXMTTHRESHサックブロックがドロップされたセグメントで観察された場合を除き、新しいセグメントは送信され、その時点でドロップされたセグメントが再送信されます。
[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の実際のパフォーマンスは、TCP RENOまたはセクション3.3.2.1 [MSMO97]で概説されている高速回復への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は、セクション2で概説されているすべての環境でパフォーマンスを向上させることが期待されています。TCPRENOよりも自己詰まった状態を維持できるため、長い遅延パスでかなり魅力的である可能性があります。
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.
上記のSACKベースの損失回復アルゴリズム（高速回復強化とFACKアルゴリズム）の両方は、データのウィンドウから複数の失われたセグメントを効果的に修復しようとするという点で類似しています。使用するサックベースの損失回復アルゴリズムのどれが依然としてオープンな研究の質問です。さらに、これらのアルゴリズムは、セクション3.3.1で説明した非サックNewRenoアルゴリズムに似ており、再送信タイマーを使用することなく複数の失われたセグメントから回復しようとします。示されているように、上記のサックベースのアルゴリズムは、NewRenoアルゴリズムよりも堅牢です。ただし、Sackアルゴリズムには、NewRenoアルゴリズムには協力するTCPレシーバーが必要です。合理的なTCP実装には、SACKベースとNewRenoベースの損失回復アルゴリズムの両方が含まれる場合があり、送信者は受信機がサックをサポートするかどうかに基づいて最も適切な損失回復アルゴリズムを使用できます。最後に、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の値）を下げる必要があることは明らかです。輻輳通知の2番目の主要な形式は、フォワード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がドロップテールルーターキューを圧倒したときに起こるように、多数のセグメントを破棄するのではなく、TCPに少数の「渋滞信号」（セグメントドロップまたはECNメッセージ）を送信することにより、ルーターがうっ血を信号することができます。
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の仮定により混雑）。この問題の解決策ではありませんが、ECNメカニズムをTCPに追加することは、この目標を達成するのに役立つメカニズムの一部である可能性があります。腐敗と輻輳ベースの損失を区別する詳細な議論については、セクション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の展開には、ルーターにアクティブキュー管理インフラストラクチャを展開する必要があります。赤は、バッファースペースが使い果たされる前であっても、赤が既にドロップするセグメントを識別しているため、ほとんどのECNディスカッションで想定されています。ECNは、パスに沿ってうっ血が発生していることをエンドノードに通知しながら、「マークされた」セグメントの配信を単に可能にします。ECNは、セグメントドロップを介して輻輳を検出したときに使用されるのと同じTCP混雑制御原則を維持するため、共有ネットワークのために（混雑制御の観点から）安全です。
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を使用するには、何らかの形のアクティブキューイングが必要であることに注意してください（たとえば、赤いキューイング）。
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.
[JAC88、JAC90]によって動機付けられ、[BRA89、STE97、APS99]で定義されているTCPの定義された動作は、すべての損失がうっ血によるものであり、[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]。ただし、衛星ネットワークでは、多くのワイヤレス環境と同様に、腐敗による損失は地上ネットワークよりも一般的です。この問題の一般的な部分的な解決策の1つは、衛星/ワイヤレスリンクを介して送信されたデータに転送エラー補正（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セグメントは、リンクレベルのチェックサムメカニズムが、着信フレームにエラーがあることを検出すると、介在するルーターによって最も多くの場合落とされます。時々、エラーを含むTCPセグメントは、TCP受信ホストに到着するまで検出せずに生き残ることがあります。その時点で、ほとんどの場合、IPヘッダーチェックサムまたは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.
おそらく、腐敗の検出における最大の研究の課題は、TCP（輸送層プロトコル）を取得して、ネットワークレイヤー（IP）またはリンクレイヤーから適切な情報を受け取ることです。これまでに行われた作業の多くには、損傷したセグメントを再送信するリンク層メカニズムが含まれています。課題は、これらのメカニズムを取得して、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]に要約されています。この有望な手法の問題の1つは、TCPレシーバーの視点からセグメントを効果的に並べ替えることです。簡単な例として、セグメントA b c dが騒々しいリンクで送信され、セグメントBが破損している場合、セグメントCとDがリンクレベルで再送信される前にリンクを既に通過している可能性があります。A C D Bを注文します。このセグメントの並べ替えにより、TCPレシーバーはセグメントCとDの到着時に重複したAcksを生成します。Acks。[MV98]で提示された研究は、この動作に対抗するために、重複したAckを逆方向に抑制または遅延させるという考えを提案しています。あるいは、再注文セグメントの到着[FLO99]に直面して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.
サックベースの損失回復アルゴリズム（3.3.2に記載されているように）は、回復がより迅速に発生する可能性があるため（そして再送信タイマーに依存せずに）、ほとんどクリーンリンクに対する破損したセグメントの影響を減らす可能性があります。サックベースの損失回収は役立ちますが、スループットは、非合成関連のパケット損失に直面しても引き続き苦しむことに注意してください。
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]の間に約1つのセグメントを輻輳ウィンドウに追加します。いくつかの研究者は、このポリシーが異なる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].
この問題の効果的な解決策の1つは、ネットワークルーターに公正なキューイングとTCPに優しいバッファ管理を展開することです[SUT98]。しかし、ネットワークからのヘルプがない場合、他の研究者は、[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]がそのようなポリシーを運用ネットワークに段階的に展開することが困難である可能性があるという証拠を提示しているが、[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接続によって選択的に使用できます。このポリシーは、特定のRTTしきい値の接続が、1つではなく、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.
[PADHV99]に示されているように、RTTごとに複数のセグメントによって輻輳ウィンドウを増やすと、TCPが複数のセグメントをドロップし、TCPの一部のバージョンで再送信タイムアウトを強制する可能性があります。したがって、上記の混雑回避アルゴリズムの変更には、複数のドロップされたセグメントを迅速に修復できるサックベースの損失回復アルゴリズムを添付する必要がある場合があります。
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複数の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. 1つのTCPフローが使用するように、単一のセグメントではなく、Nセグメントの効果的な輻輳ウィンドウを使用して伝送を開始できます。これにより、転送により、有効な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ごとに1つのセグメントではなく、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:
4. n並列接続を使用すると、セグメントの落下に直面して全体的なCWNDの減少が減少します。単一のTCP接続により、単一のセグメントの損失が検出されると、有効なサイズのCWNDが半分に減少します。Wバイトのウィンドウを使用してそれぞれn接続を使用する場合、単一のドロップがウィンドウを次のように削減します。
(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.
複数のデータ接続を使用すると、非サック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接続の使用に関する研究は、パフォーマンスの向上を示しています[IL92、HAH94、AOK95、AKO96]。さらに、研究により、複数のTCP接続が単一の最新のTCP接続（大きな窓と袋を使用して）を上回ることができることが示されています[Ahko97]。ただし、これらの研究では、競合するトラフィックに対する複数の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接続を使用するには、クライアントアプリケーションを使用し、対応するサーバーをカスタマイズする必要があります。[FF99]で概説されているように、複数の並列TCP接続を使用することは、共有ネットワークでは（混雑制御の観点から）安全ではなく、使用しないでください。
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]と同様に、大きな輻輳ウィンドウを使用できます。さらに、[AFP98]またはTCB共有を使用するのと同様に、より大きな初期輻輳ウィンドウが達成されます（セクション3.8を参照）。
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]), 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].
Slow-Startは、高帯域幅遅延製品を備えたルート上にTCP輻輳ウィンドウを完全に開くために、数回往復します。短いTCP接続（HTTP/1.0を使用したWWWトラフィックなど）の場合、スロースタートオーバーヘッドは、高帯域幅衛星リンクの効果的な使用を妨げる可能性があります。送信者がTCP接続がアイドル状態になった後にスロースタートの再起動を実装すると（JacobsonとKarels [JK92]）、パフォーマンスは長寿命（ただし、Bursty）接続（HTTP/1.1など、永続的なTCP接続を使用して転送を使用します。複数のWWWページ要素）[HEI97A]。
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の適切なサイズを決定することは、オープンな研究の質問です。ペーシングは、一般的にバーストを減らすために使用できます（バグのTCPまたはバイトカウントにより、バイトカウントに関する議論についてはセクション3.2.2を参照してください）。
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-After-Idle（ドロップのため）のパフォーマンスをわずかに改善します[VH98]。より最近では、ACKフィルタリング[BPK97]を使用して、ネットワークの破裂を排除することがペーシングが提案されています。
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では、RBPが1つのRTTの伝送[VH98]に対してこのタイマーのみを必要とするため、このオーバーヘッドは最小限であることが示唆されています[VH98]。RBPは、ホストのアイドル期間の後にデータのバーストを送信する際にTCPをより保守的にすることが期待されています。一方、RBPは、長いアイドル期間後に送信者がスロースタートアルゴリズムを使用してACKクロックを起動する場合、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ヘッダーとIPヘッダーのデータを置き換えることにより、TCPセッションのオーバーヘッドを減らします。番号"。この方法を使用して、送信者は最初に完全なTCP/IPヘッダーを送信します。これには、送信者が接続を参照するために使用する接続番号を含みます。レシーバーはフルヘッダーを保存し、テンプレートとして使用し、後の圧縮ヘッダーに含まれる限られた情報からいくつかのフィールドを埋めます。この圧縮により、IPv4/TCPヘッダーのサイズが40からわずか3〜5バイト（一部の一般的なケースでは3バイト、一般的に5バイト）を削減できます。
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.
減圧器は、完全で圧縮されていないパケットを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シリアルラインプロトコルはオプション交換を可能にします。その間、コンプレッサー/分解器はヘッダー圧縮を使用するかどうかに同意します。古いスリップ実装の場合、[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チェックサムが失敗したとき）。単一のビットエラーにより、減圧剤が同期を失い、圧縮ヘッダーを使用した後続のパケットは、TCPチェックサムにすべて失敗するため、受信TCPによってドロップされます。これが発生すると、重複する謝辞は生成されず、非圧縮者は、圧縮されていないヘッダーでパケットを受信した場合にのみ再同期することができます。これは、ヘッダー圧縮が使用されている場合、高速再送信と選択的承認の両方が、圧縮リンクで失われた正しいパケットになり得ないことを意味します。以下で説明する「2回」アルゴリズムは、この問題の部分的な解決策である可能性があります。
[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]は、さまざまなIPv6拡張ヘッダーの圧縮や非TCPストリームを圧縮する方法を含むTCP/IPv4およびTCP/IPv6圧縮アルゴリズムを説明しています。[DENP97]は、「2回」アルゴリズムを導入することにより、TCPヘッダー圧縮を増強します。特定のパケットが適切に解凍できない場合、2回のアルゴリズムは、圧縮ヘッダーの推定されたフィールドに関する仮定を変更します。その後、2回は新しい仮定の下で受信したパケットを減圧しようとします。チェックサムが通過すると、パケットがIPに渡され、減圧状態が再同期されています。この手順は、3つ以上のデコード試行に拡張できます。後の到着が問題を解決することを期待して適切に減圧されないパケットの完全なコピーをキャッシュすることで、追加の堅牢性を実現できます。最後に、減圧剤が完全なヘッダーを明示的に要求できる場合のパフォーマンスの改善について説明します。シミュレーション結果は、完全なヘッダー要求メカニズムと2回、非圧縮ストリームよりもスループットを改善できることを示しています。
[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]では、著者は、ヘッダー圧縮が低帯域幅リンクと中程度の両方のリンクで有利であることを示すシミュレーションの結果を提示します。シミュレーションは、明示的なヘッダー要求メカニズムと組み合わせた2回のアルゴリズムが、広範囲のビットエラー率にわたって非圧縮セッションで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回のアルゴリズムが減圧器を迅速に再同期するためのものである可能性があります。これは、減圧剤が非色素化されたときに1〜2回適用された2回のアルゴリズムが、調査された症例の83％から99％の間に減圧器を再シンクするためです。これは、2回再同期を変更した後にパケットを正しく受信したことを意味します。これにより、ヘッダー圧縮と組み合わせて、高速再送信とサックの両方の使用が再び可能になります。
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ヘッダー圧縮の実装には、圧縮を使用する各リンクの送信（コンプレッサー）と受信（減圧剤）端の両方で変更が必要です。2回のアルゴリズムは、ヘッダー圧縮以上の余分な機械をほとんど必要としませんが、[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の混雑ウィンドウサイズが大きい場合、明示的なヘッダー要求メカニズムを実装するには、2回のアルゴリズムと適切に減圧できないキャッシュパケットがより重要になります。
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.
上記で説明したように、送信者と受信機の間で同期を失うと、多くのパケットドロップが発生する可能性があります。同期を失う頻度と2回のアルゴリズムの有効性は、サックベースの損失回復アルゴリズムを使用して、複数の失われたセグメントの影響を減らすことを指している可能性があります。ただし、非常に堅牢なサックベースのアルゴリズムでさえ、あまりにも多くのセグメントが失われた場合、うまく機能しない場合があります。
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.
これらのパラメーターを選択しようとする代わりに、A-PrioriはTCP接続全体で状態を共有し、新しい接続を初期化するときにこの状態を使用しています。たとえば、サブネットへのすべての接続の結果、1メガバイトの輻輳窓が拡張された場合、この値での新しい接続を開始する方がおそらくより効率的です。往復時間。
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のようなSimple Stateは共有しやすいですが、渋滞ウィンドウ情報はさまざまな方法で共有できます。共有メカニズムは、共有接続の優先順位を決定し、さまざまな公平性基準を考慮する必要があります。また、情報が高齢化されているメカニズムには、さらなる研究が必要です。単一のホスト内で状態を共有し、サブネットのホスト間で状態を共有することの両方のセキュリティ問題の議論については、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状態の一部を共有することは、もともとT/TCP [BRA92]で文書化されており、接続インスタンス全体でRTT値を集約し、意味のある平均RTTを提供するために使用されます。T/TCPは、TCP接続が通常区別されるウィンドウ番号とアドレス/ポートペアとは別のシーケンス番号である接続識別子も共有します。この共有状態の結果として、T/TCPは、接続の完全性を損なうことなく、3方向の握手が完了する前に、Synセグメント内のSynセグメント内のデータを受信アプリケーションに渡すことができます。実際、この共有状態は、TCB共有のより一般的な問題のバリアントである以前の接続からの部分的な握手をキャッシュします。
Sharing state among connections (including transfers using non-TCP protocols) is further investigated in [BRS99].
[BRS99]では、接続（非TCPプロトコルを使用した転送を含む）間で状態を共有することをさらに調査します。
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状態を共有するには、送信者のTCPスタック、およびおそらくレシーバーのTCPスタック（たとえばT/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.
非常に非対称ネットワークでは、低速リターンリンクは、データ送信者に返される確認のフローを制限することにより、高速前方リンクでのデータフローのパフォーマンスを制限できます。たとえば、データ送信者が1500バイトセグメントを使用し、受信機が40バイトの謝辞（オプションのないIPv4、TCP）を生成する場合、逆リンクは、遅延ACKを使用した場合、75：1を超える非対称性のACKとAcksとうっかり、37：1すべてのセグメントが確認されている場合。1.5 MB/秒のデータリンクの場合、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をデータ受信機に「エコー」する必要があります（ECNの詳細については、セクション3.3.3を参照）。ACKセグメントをECNビットでマークするための提案されたアルゴリズムは、ランダムな早期検出（RED）[FJ93]です。ECNマークされたデータセグメントの受領に応じて、受信機は乗法バックオフを使用して謝辞率を動的に減らします。ECNのないセグメントが受信されると、データ受信機は線形増加を使用して謝辞を高速化します。これは、ACKあたり1（遅延ACKなし）または2（通常の遅延ACK）データセグメントの速度を最大速度にします。著者は、ACKをウィンドウごとに少なくとも1回、理想的にはウィンドウごとに数回生成することを示唆しています。
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.
データフローの赤い輻輳制御メカニズムと同様に、ボトルネックゲートウェイは、特定のしきい値を超えてキューが埋めると、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は通常の1つまたは2つのデータセグメントを超えることを認めているため、データ送信者からのセグメントバーストの可能性が増加します。さらに、[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を使用すると、変更されていない（RENO）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.
キューの制限により、ゲートウェイの1つで前方方向が損失を被ると予想されるネットワークでは、著者は、変更されていないリノ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の両方で、Bottleneck Gatewayと同様に、送信および受信ホストの変更が必要です。現在の研究では、SA修正なしでACCを実装すると、潜在的に破壊的なセグメントバーストを生成するデータ送信者が生じることが示唆されています。[BPK97]で提案された方法で実装されている場合、ACCはホストの変更を必要とすることに注意する必要があります。著者らは、ACKをACKS（ゲートウェイの変更のみが必要であるが、ホストには変更はない）を破棄することで実装できることに注意してください。ただし、このような実装は、バースト緩和手法と組み合わされていない場合、バーストデータ送信者を生成する場合があります。ACCには、受信TCPの標準的なアッキング動作の変更が必要であるため、共有ネットワークでの使用には推奨されません。
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つのパラメーターが必要です。1つのパラメーターは目的のACK周波数ですが、2番目のパラメーターは、連続した再構成された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単独の使用が、送信者が破裂しているためにパフォーマンスを低下させることを強く示唆しています。
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は、以前のAcksを後のAcksを支持してドロップすることにより、受信機に到着することを承認します。このプロセスは、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の実装では、ルーターがTCPヘッダーを調べる必要があります。これにより、IPSECが展開される安全なネットワークでの使用が禁止されています。このようなネットワークでは、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フィルタリングは、ACK混雑制御と同じ問題を解決しようとします（セクション3.9で概説されています）。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] Allman、M.、Floyd、S。、およびC. Partridge、「TCPの最初のウィンドウの増加」、RFC 2414、1998年9月。
[AGS99] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[AGS99] Allman、M.、Glover、D。およびL. Sanchez、「標準メカニズムを使用した衛星チャネル上のTCPの強化」、BCP 28、RFC 2488、1999年1月。
[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]マーク・オールマン、クリス・ヘイズ、ハンス・クルーゼ、ショーン・オスターマン。衛星リンク上の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]マーク・オールマン、クリス・ヘイズ、ショーン・オスターマン。より大きな初期ウィンドウを持つ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]マーク・オールマン、ハンス・クルーゼ、ショーン・オスターマン。TCPの衛星非効率性に対するアプリケーションレベルのソリューション。1996年11月、衛星ベースの情報サービス（WOSBIS）に関する最初の国際ワークショップの議事録。
[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]マーク・オールマン。2つの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]マーク・オールマン、ショーン・オスターマン、ハンス・クルーゼ。ファイル転送プロトコル（FTP）へのマルチソケット拡張を使用した衛星回路上のデータ転送効率。1995年9月、NASAルイスリサーチセンターのACTS Results Conferenceの議事録。
[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] Allman、M.、Paxson、V。and W. Richard Stevens、「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] 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、「インターネットでのキュー管理と混雑回避に関する推奨事項」、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. BakshiおよびP. Krishna and N. Vaidya and D. Pradham、「ワイヤレスネットワーク上のTCPのパフォーマンスの向上」、1997年5月、分散コンピューティングシステム（ICDCS）に関する第17回国際会議（ICDCS）。
[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] Hari Balakrishnan、Venkata N. Padmanabhan、およびRandy H. Katz。TCPパフォーマンスに対する非対称性の影響。ACM/IEEE Mobicomの議事録、ブダペスト、ハンガリー、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] Hari Balakrishnan、Venkata Padmanabhan、Randy H. Katz。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. Balakrishnan and V. Padmanabhan and S. Sechan and R. Katz、「ワイヤレスリンク上のTCPパフォーマンスを改善するためのメカニズムの比較」、ACM Sigcomm、1996年8月。
[Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[BRA89] Braden、R。、「インターネットホストの要件 - 通信層」、STD 3、RFC 1122、1989年10月。
[Bra92] Braden, R., "Transaction TCP -- Concepts", RFC 1379, September 1992.
[Bra92] Braden、R。、「Transaction TCP -Concepts」、RFC 1379、1992年9月。
[Bra94] Braden, R., "T/TCP -- TCP Extensions for Transactions: Functional Specification", RFC 1644, July 1994.
[Bra94] Braden、R。、「T/TCP -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] Hari Balakrishnan、Hariharan Rahul、およびSrinivasan Seshan。インターネットホスト向けの統合渋滞管理アーキテクチャ。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] Mikael Degermark、Mathias Engan、Bjorn Nordgren、Stephen Pink。ワイヤレスネットワーク用の低損失TCP/IPヘッダー圧縮。ACM/Baltzer Journal on Wireless Networks、Vol.3、No.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. DurstおよびG. J. MillerおよびE. J. Travis、「宇宙通信のためのTCP拡張」、Mobicom 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. Pink、「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]ケビンフォール、サリーフロイド。Tahoe、Reno、およびSack TCPのシミュレーションベースの比較。コンピューターコミュニケーションレビュー、V。26N. 3、1996年7月、pp。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] Floyd、S。およびT. Henderson、「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。1N. 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 Computer Communications Review、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。24N. 5、1994年10月。
[Flo99] Sally Floyd. "Re: TCP and out-of-order delivery", email to end2end-interest mailing list, February, 1999.
[flo99]サリー・フロイド。「Re：TCPおよびOut-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Obs-Onterestメーリングリスト、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 AMES Research Center、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混雑回避の公平性を改善すること。IEEE Globecom `98 Conference、1998の議事録。
[HK99] Tim Henderson, Randy Katz. Transport Protocols for Internet-Compatible Satellite Networks, IEEE Journal on Selected Areas of Communications, February, 1999.
[HK99]ティム・ヘンダーソン、ランディ・カッツ。インターネット互換衛星ネットワーク用の輸送プロトコル、Communicationsの選択された領域に関するIEEEジャーナル、1999年2月。
[Hoe95] J. Hoe, Startup Dynamics of TCP's Congestion Control and Avoidance Schemes. Master's Thesis, MIT, 1995.
[Hoe95] J. Hoe、TCPの混雑制御と回避スキームのスタートアップダイナミクス。修士論文、MIT、1995。
[Hoe96] Janey Hoe. Improving the Startup Behavior of a Congestion Control Scheme for TCP. In ACM SIGCOMM, August 1996.
[Hoe96] Janey Hoe。TCPの混雑制御スキームのスタートアップ動作の改善。1996年8月、ACM Sigcommで。
[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] David IannucciとJohn Lakashman。MFTP：複数の接続を使用した仮想TCPウィンドウスケーリング。テクニカルレポートRND-92-002、NASA AMES Research Center、1992年1月。
[Jac88] Van Jacobson. Congestion Avoidance and Control. In Proceedings of the SIGCOMM '88, ACM. August, 1988.
[Jac88]ヴァンジェイコブソン。混雑の回避と制御。Sigcomm '88、ACMの議事録。1988年8月。
[Jac90] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, February 1990.
[Jac90] Jacobson、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] Jacobson、V.、Braden、R。およびD. Borman、「TCP拡張機能のための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]ヴァンジェイコブソンとマイクカレル。混雑の回避と制御。もともと、Jacobsonのみが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]ハンス・クルーゼ、マーク・オールマン、ジム・グリナー、ディプチ・トラン。HTTPページ転送速度地理衛星リンク上の転送率。1998年3月。電気通信システムに関する第6回国際会議の議事録。
[Kes91] Srinivasan Keshav. A Control Theoretic Approach to Flow Control. In ACM SIGCOMM, September 1991.
[Kes91] Srinivasan Keshav。フロー制御への制御理論的アプローチ。1991年9月、ACM SIGCOMMで。
[KM97] S. Keshav, S. Morgan. SMART Retransmission: Performance with Overload and Random Losses. Proceeding of Infocom. 1997.
[KM97] S. Keshav、S。Morgan。スマートな再送信：過負荷とランダム損失によるパフォーマンス。Infocomの手続き。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 Varma、および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. Mathis、J。Mahdavi、「フォワード謝辞：TCP混雑制御の改良」、Sigcomm'96の議事録、1996年8月、カリフォルニア州スタンフォード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. Mathis、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] Mathis、M.、Mahdavi、J.、Floyd、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
[MSMO97] M.マティス、J。セムケ、J。マフダヴィ、T。.psc.edu/networking/papers/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] Miten N. MehtaとNitin 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] Paxson、V.、Allman、M.、Dawson、S.、Heavens、I.およびB. Volz、「既知のTCP実装問題」、RFC 2525、1999年3月。
[Pax97] Vern Paxson. Automated Packet Trace Analysis of TCP Implementations. In Proceedings of ACM SIGCOMM, September 1997.
[Pax97] Vern Paxson。TCP実装の自動パケットトレース分析。1997年9月、ACMシグコムの議事録。
[PN98] Poduri, K. and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[PN98] Poduri、K。およびK. Nichols、「初期TCPウィンドウサイズの増加に関するシミュレーション研究」、RFC 2415、1998年9月。
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[POS81] Postel、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] Ramakrishnan、K。およびS. Floyd、「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] Nihal K. G. SamaraweeraとGodRed Fairhurst、「ワイヤレス通信のためのTCPエラー回復の強化」、コンピューターコミュニケーションレビュー、第28巻、28番、1998年4月。
[SP98] Shepard, T. and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[SP98] Shepard、T。およびC. Partridge、「TCPが3つのバッファーに4つのパケットから始まるとき」、RFC 2416、1998年9月。
[Ste97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
[Ste97] Stevens、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. Suter、T。Lakshman、D。Stiliadis、およびA. Choudhury。Flow QueuingでTCPをサポートするための設計上の考慮事項。IEEE INFOCOM `98 Conference、1998の議事録。
[Tou97] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[Tou97] Touch、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] Vikram VisweswaraiahとJohn 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] Vikram VisweswaraiahとJohn Heidemann。レートベースのペーシングソースコード配布、Webページ：http：//www.isi.edu/lsam/publications/rate_based_pacing/readme.html 1997年11月。
[VH98] Vikram Visweswaraiah and John Heidemann. Improving Restart of Idle TCP Connections (revised). Submitted for publication.
[VH98] Vikram VisweswaraiahとJohn 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
マークオールマンナサグレンリサーチセンター/BBNテクノロジーズルイスフィールド21000 Brookpark Rd。MS 54-2クリーブランド、OH 44135
EMail: mallman@grc.nasa.gov
http://roland.grc.nasa.gov/~mallman
Spencer Dawkins Nortel P.O.Box 833805 Richardson, TX 75083-3805
Spencer Dawkins Nortel P.O.Box 833805リチャードソン、TX 75083-3805
EMail: Spencer.Dawkins.sdawkins@nt.com
Dan Glover NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 3-6 Cleveland, OH 44135
ダングローバーナサグレンリサーチセンタールイスフィールド21000ブルックパークロード。MS 3-6クリーブランド、OH 44135
EMail: 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
ジムグリナーナサグレンリサーチセンタールイスフィールド21000ブルックパークロード。MS 54-2クリーブランド、OH 44135
EMail: 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 Tran Nasa Glenn Research Center Lewis Field 21000 Brookpark Rd。MS 54-2クリーブランド、OH 44135
EMail: dtran@grc.nasa.gov
Tom Henderson
University of California at Berkeley
Phone: +1 (510) 642-8919
EMail: 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
ジョンハイデマン南カリフォルニア大学/情報科学研究所4676アドミラルティウェイマリーナデルレイ、カリフォルニア90292-6695
EMail: johnh@isi.edu
Joe Touch University of Southern California/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6601 USA
ジョータッチ大学南カリフォルニア大学/情報科学研究所4676アドミラルティウェイマリーナデルレイ、カリフォルニア90292-6601 USA
Phone: +1 310-448-9151
Fax: +1 310-823-6714
URL: http://www.isi.edu/touch
EMail: touch@isi.edu
Hans Kruse J. Warren McClure School of Communication Systems Management Ohio University 9 S. College Street Athens, OH 45701
Hans Kruse J. Warren McClure Communication Systems Management Ohio University 9 S. College Street Athens、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メール：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
ショーンオスターマン電気工学およびコンピューターサイエンス学校オハイオ大学416モートンホールアテネ、オハイオ州45701
Phone: (740) 593-1234 EMail: ostermann@cs.ohiou.edu Keith Scott The MITRE Corporation M/S W650 1820 Dolley Madison Blvd. McLean VA 22102-3481
電話：（740）593-1234メール：ostermann@cs.ohiou.eduキーススコットマイターコーポレーションM/S W650 1820 Dolley Madison Blvd.マクリーンVA 22102-3481
EMail: kscott@mitre.org
Jeffrey Semke Pittsburgh Supercomputing Center 4400 Fifth Ave. Pittsburgh, PA 15213
ジェフリー・セムケ・ピッツバーグ・スーパーコンピューティング・センター4400フィフス・アベニュー・ピッツバーグ、ペンシルバニア州15213
EMail: semke@psc.edu
http://www.psc.edu/~semke
9 Full Copyright Statement
9完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。