RFC2760 日本語訳
2760 Ongoing TCP Research Related to Satellites. M. Allman, Ed., S.Dawkins, D. Glover, J. Griner, D. Tran, T. Henderson, J. Heidemann,J. Touch, H. Kruse, S. Ostermann, K. Scott, J. Semke. February 2000. (Format: TXT=111141 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループのM.オールマン、コメントを求めるエディタ要求をネットワークでつないでください: 2760年のNASAグレンリサーチセンタ/BBN技術カテゴリ: 情報のS.ダウキンズノーテルのD.の手袋製造業者のJ.Griner D.チャン・NASAのグレンリサーチセンタのT.ヘンダーソンのカリフォルニア大学バークレイ校J.Heidemann J.は斜め継ぎ社のJ.Semkeピッツバーグスーパーコンピューティングセンター2000年2月に南カリフォルニア/ISI H.クルーゼS.オステルマンオハイオ大学のK.スコット大学に触れます。
Ongoing TCP Research Related to Satellites
衛星に関連する進行中のTCP研究
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
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研究で行われる執筆中の作品と進歩に関して研究者を教育することです。
Allman, et al. Informational [Page 1] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[1ページ]のRFC2760の進行中の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つの序論。 . . . . . . . . . . . . . . . . . . . 2 2の衛星構造. . . . . . . . . . . . . . 3 2.1の非対称の衛星は最後のホップとして.32.2衛星中継をネットワークでつなぎます。 . . . . . . . . . . . . 2.3のハイブリッド衛星は.42.4の二地点間衛星ネットワーク. . . . . . . . . 4 2.5をネットワークでつなぎます。3 複数の衛星が取引のために.4 3の緩和. . . . . . . . . . . . . . . . . . . . 4 3.1のTCPを飛び越します。 . . . . . . . . . . . . . . . 4 3.2は始めを遅くします。 . . . . . . . . . . . . . . . . . . . . 5 3.2 .1 遅い状態で終わる遅れた出発. . . . . . . . . . . 9 3.2.4が始まった後により大きい初期の窓. . . . . . . . . . . . . . . 6 3.2の.2バイトの勘定. . . . . . . . . . . . . . . . . . . 7 3.2.3はACKsを遅らせました。 . . . . . . . . . . . . . . 11 3.3 損失回復. . . . . . . . . . . . . . . . . . . 12 3.3.1非袋はメカニズム. . . . . . . . . . . . . 12 3.3.2の袋のベースのメカニズム. . . . . . . . . . . . . . . 13 3.3.3の明白な混雑通知を基礎づけました。 . . . . . . . . . 16 3.3 .4 不正損失. . . . . . . . . . . . . 18 3.4輻輳回避を検出します。 . . . . . . . . . . . . . . . 21 3.5 TCPセグメント. . . . . . . . . . . . . . . . 24 3.7TCPヘッダー圧縮に歩調を合わせる複数のデータコネクションズ. . . . . . . . . . . . . 22 3.6。 . . . . . . . . . . . . . . 26 3.8 同様のコネクションズ. . . . 29 3.9ACK輻輳制御の中でTCP状態を共有します。 . . . . . . . . . . . . . . 32 3.10 ACKフィルタリング. . . . . . . . . . . . . . . . . . . 34 4結論. . . . . . . . . . . . . . . . . . . . 36 5セキュリティ問題. . . . . . . . . . . . . . 36 6承認. . . . . . . . . . . . . . . . . . 37 7参照。 . . . . . . . . . . . . . . . . . . . . 37 8人の作者のアドレス。 . . . . . . . . . . . . . . . . 43 9 完全な著作権宣言文。 . . . . . . . . . . . . . 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
このドキュメントは通信制御プロトコル(TCP)[Pos81]が長時間の遅延衛星環境によって供給された帯域幅を利用するほうがよいのを助けるかもしれないメカニズムについて概説します。 また、これらのメカニズムは他の環境か他のプロトコルのために助けるかもしれません。 本書では概説された提案は現在、研究団体中で研究されています。 したがって、広範囲の使用のためにIETFによって推薦されるくらいにはこれらのメカニズムは熟していません。 しかしながら、これらのいくつかのメカニズムが今日、安全に使用されるかもしれません。 このドキュメントがさらなる研究を説明されたメカニズムに刺激することが望まれています。
Allman, et al. Informational [Page 2] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[2ページ]のRFC2760の進行中のTCP研究
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.
何らかのポイント、適切な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に持っている影響力はRFC2488[AGS99]に提示されます。 このセクションは衛星中継が世界的なインターネットと統合されるかもしれない数個の可能なtopologiesについて論じます。 セクション3で概説された緩和はメカニズムがどの環境のためになると予想されるかに関する議論を含むでしょう。
2.1 Asymmetric Satellite Networks
2.1 非対称の衛星ネットワーク
Some satellite networks exhibit a bandwidth asymmetry, a larger data rate in one direction than the reverse direction, because of limits on the transmission power and the antenna size at one end of the link. Meanwhile, some other satellite systems are unidirectional and use a non-satellite return path (such as a dialup modem link). The nature of most TCP traffic is asymmetric with data flowing in one direction and acknowledgments in opposite direction. However, the term asymmetric in this document refers to different physical capacities in the forward and return links. Asymmetry has been shown to be a problem for TCP [BPK97,BPK98].
いくつかの衛星ネットワークが帯域幅非対称、反対の方向より大きいデータ信号速度を一方向に示します、トランスミッションパワーにおける限界とリンクの片端におけるアンテナサイズのために。 その間、ある他のサテライト・システムは、単方向であり、非衛星リターンパス(ダイアルアップモデムリンクなどの)を使用します。 データが一方向と承認で逆方向に流れていて、ほとんどのTCP交通の本質は非対称です。 しかしながら、非対称という用語は本書ではフォワードとリターンリンクの異なった物理的な能力について言及します。 非対称は、TCP[BPK97、BPK98]のための問題になるように示されました。
2.2 Satellite Link as Last Hop
2.2 最後のホップとしての衛星中継
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.
ネットワークの中央に位置する衛星中継と対照的に直接エンドユーザに対するサービスを提供する衛星中継、最後のホップの上で使用されるプロトコルの専門化しているデザインを考慮するかもしれません。 いくつかの衛星プロバイダーが共有された高速ダウンリンクとして下側の速度(要求と承認にリターンリンクとして使用される非共有された地球のリンク)でユーザに衛星中継を使用します。 何回も、これは上で議論するように非対称のネットワークを創設します。
Allman, et al. Informational [Page 3] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[3ページ]のRFC2760の進行中のTCP研究
2.3 Hybrid Satellite Networks
2.3 ハイブリッド衛星ネットワーク
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門の間のただのリンクとして作動します。 この環境で、衛星としての井戸がリンクされるとき、地球のリンク(地球の無線電信を含んでいる)の上に与えられた接続を送るかもしれません。 他方では、また、接続は地球のネットワークだけの上、または、ネットワークの衛星部分だけの上を旅行できました。
2.4 Point-to-Point Satellite Networks
2.4 二地点間衛星ネットワーク
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]に概説されているように衛星中継に関連している問題だけを示します。 これが私設のネットワークであるので、いくつかの共用回線網には、適切でない緩和は考えることができます。
2.5 Multiple Satellite Hops
2.5 複数の衛星ホップス
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表面を緩和するための様々なテクニックについて論ずるでしょう。 それぞれの以下のセクションは以下の通り組織化されるでしょう: まず最初に、各緩和は簡潔に概説されるでしょう。 次に、簡潔に問題のメカニズムにかかわる研究について議論するでしょう。 次に、メカニズムの導入問題は提示されるでしょう(特定のメカニズムが何か危険を共用回線網に提示するかどうかを含んでいます)。 そして、上に概説されたtopologiesに関するメカニズムの可能性の議論をします。 最終的に、他のTCPメカニズムとの関係と可能な相互作用は概説されています。 読者が[AGS99]で使用されるTCP用語によく知られさせると予想されます。
3.1 TCP For Transactions
3.1 取引のためのTCP
3.1.1 Mitigation Description
3.1.1 緩和記述
TCP uses a three-way handshake to setup a connection between two hosts [Pos81]. This connection setup requires 1-1.5 round-trip times (RTTs), depending upon whether the data sender started the connection actively or passively. This startup time can be eliminated by using TCP extensions for transactions (T/TCP) [Bra94]. After the first
TCPは、2人のホスト[Pos81]の間の接続をセットアップするのに3方向ハンドシェイクを使用します。 データ送付者が接続を活発か受け身に始めたかどうかによって、この接続設定は1-1.5に、往復の回(RTTs)を必要とします。 取引(T/TCP)[Bra94]にTCP拡張子を使用することによって、この始動時間を排除できます。 1日以降
Allman, et al. Informational [Page 4] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[4ページ]のRFC2760の進行中のTCP研究
connection between a pair of hosts is established, T/TCP is able to bypass the three-way handshake, allowing the data sender to begin transmitting data in the first segment sent (along with the SYN). This is especially helpful for short request/response traffic, as it saves a potentially long setup phase when no useful data is being transmitted.
T/TCPが3方向ハンドシェイクを迂回させることができる、1組のホストの間の接続は確立されて、データ送付者が最初のセグメントでデータを送り始めるのを許容するのが発信しました(SYNと共に)。 短い要求/応答交通において、これは特に役立っています、どんな役に立つデータも送られていないとき、潜在的に長いセットアップフェーズを節約するとき。
3.1.2 Research
3.1.2 研究
T/TCP is outlined and analyzed in [Bra92,Bra94].
T/TCPは[Bra92、Bra94]で概説されていて、分析されます。
3.1.3 Implementation Issues
3.1.3 導入問題
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]。
3.1.4 Topology Considerations
3.1.4 トポロジー問題
It is expected that T/TCP will be equally beneficial in all environments outlined in section 2.
T/TCPがセクション2で概説されたすべての環境で等しく有益になると予想されます。
3.1.5 Possible Interaction and Relationships with Other Research
3.1.5 可能な相互作用と他の研究との関係
T/TCP allows data transfer to start more rapidly, much like using a larger initial congestion window (see section 3.2.1), delayed ACKs after slow start (section 3.2.3) or byte counting (section 3.2.2).
T/TCPはデータ転送をより急速に始めさせます、より大きい初期の混雑ウィンドウを使用するように(セクション3.2.1を見てください)、遅れた出発(セクション3.2.3)か(セクション3.2.2)を数えるバイト後の遅れたACKs。
3.2 Slow Start
3.2遅れた出発
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は遅れた出発段階の間の無駄な容量の別の源です。 RFC1122[Bra89]は、データ受信装置がACKingからのあらゆる受信データセグメントを控えるのを示します。 しかしながら、あらゆる2番目の完全サイズのセグメントがACKedであるべきです。 2番目の完全サイズのセグメントが与えられたタイムアウトの中で到着しないなら、ACKは発生しなければなりません(このタイムアウトは500msを超えることができません)。 送付者が数を減らして、到着ACKsの数に基づくcwndのサイズを増加させるデータ以来
Allman, et al. Informational [Page 5] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[5ページ]のRFC2760の進行中のTCP研究
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.
ACKsはcwnd成長率を遅くします。 TCPが発信し始めるとき、さらに、それは1つのセグメントを送ります。 遅れたACKsを使用するとき、ACKを送る前に2番目のセグメントは到着しなければなりません。 したがって、受信機は、いつも遅れているACKタイマがACKingの前に最初のセグメントを吐き出すのをやむを得ず待ちます。(また、セグメントは転送時間を増加させます)。
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.
いくつかの提案が遅れた出発をより時間がかからないようにする方法を示しました。 これらの提案は以下に簡潔に概説されています、そして、研究の参照は与えた状態で利きます。
3.2.1 Larger Initial Window
3.2.1 より大きい初期の窓
3.2.1.1 Mitigation Description
3.2.1.1 緩和記述
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)
分(4*MSS、(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の初期の値を増加させることによって、より多くのACKsの引き金となるデータ伝送の最初のRTTの間、より多くのパケットを送ります、混雑ウィンドウが、より急速に開くのを許容して。 さらに、初めは少なくとも2つのセグメントを送ることによって、最初のセグメントは、cwndの初期のサイズが1つのセグメント(上で議論するように)であるときに、遅れているACKタイマがそのままでケースを吐き出すのを待つ必要はありません。 したがって、1つのセグメントの初期のcwndと比べると、方程式1で与えられているcwndの値は最大3RTTsと遅れた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.
また、私たちは、RFC2581[APS99](標準化過程文書)がTCPに最大2つのセグメントの初期のcwndを使用させることに注意します。 この変化は衛星ネットワークのために強く推薦されます。
3.2.1.2 Research
3.2.1.2 研究
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
数人の研究者が様々な環境における、より大きい初期の窓の使用を研究しました。 [Nic97]と[KAGT98]は、ハイブリッドファイバーの上の転送時間がそれぞれ(HFC)と衛星中継をおだてるのをWWWページの減少に示します。 その上、4つのセグメントの初期のcwndを使用するのが否定的に少ない数のバッファ[SP98]とのダイアルアップモデムリンクの上に総合的な性能に影響を与えないのが示されました。 16KBのファイルのための転送時間にcwndにより大きい初期の値を使用するとき、[AHO98]はインターネットとダイアルアップモデムリンクの向こう側に改良を示しています。 しかしながら、わずかな増加は中に低下しました。
Allman, et al. Informational [Page 6] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[6ページ]のRFC2760の進行中のTCP研究
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.
また、セグメントは示されました。 最終的に、[PN98]は競争している交通でシミュレーションにおけるWWW交通への改良された転送時間を示しています、低下率の微増に加えて。
3.2.1.3 Implementation Issues
3.2.1.3 導入問題
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スタックへの変化を必要とします。 RFC2581[APS99]は2つのセグメントの初期の混雑ウィンドウを使用させられること。 3か4つのセグメントの初期の混雑ウィンドウを使用するのは、混雑崩壊[AFP98]のどんな危険も提示しないと予想されて、しかしながら、いくつかのネットワークで性能を下げるかもしれません。
3.2.1.4 Topology Considerations
3.2.1.4 トポロジー問題
It is expected that the use of a large initial window would be equally beneficial to all network architectures outlined in section 2.
大きい初期の窓の使用が等しくセクション2で概説されたすべてのネットワークアーキテクチャに有益であると予想されます。
3.2.1.5 Possible Interaction and Relationships with Other Research
3.2.1.5 可能な相互作用と他の研究との関係
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.
また、aの最初のセグメントが移すACKをすぐにへの代替の道に提供して、遅れた出発(セクション3.2.3に概説されているように)が、より急速に混雑ウィンドウを戸外に提供した後にだけ使用はACKsを遅らせました。 最終的に、ポートの数(3.8で議論するように)で共有される何らかのフォームのTCP状態を使用すると、固定より大きい初期の窓を使用することへの代替手段は提供されるかもしれません。
3.2.2 Byte Counting
3.2.2 バイト勘定
3.2.2.1 Mitigation Description
3.2.2.1 緩和記述
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
上で議論するように、遅れたACKsの広範囲の使用は遅れた出発の間、混雑ウィンドウのサイズを増加させるようにTCP送付者によって必要とされた時間を増加させます。 これは長時間の遅延GEO衛星中継を横断する流れに特に有害です。 遅れたACKsによって引き起こされた問題を緩和するために示された1つのメカニズムは[All97a、All98]を数える標準のACKよりむしろ「バイト勘定」の使用です。 標準のACKを使用するのが数えられて、混雑ウィンドウは遅れた出発の間に受け取られた各ACKあたり1つのセグメントによって増加させられます。 しかしながら、混雑窓の増加を数えながらバイトを使用するのは基づいています。
Allman, et al. Informational [Page 7] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[7ページ]のRFC2760の進行中のTCP研究
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.
ACKsの数で受信するよりそれぞれの入って来る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.
バイト勘定の2つの書式が[All98]で研究されます。 1番目は(UBC)を数える無制限なバイトです。 このメカニズムは、ACKが到着するたびに混雑ウィンドウを増加させるのに単に以前に不承認のバイトの数を使用します。 2番目のフォームは(LBC)を数える限られたバイトです。 LBCはcwnd増加の量を2つのセグメントに制限します。 この限界は「伸びACK」[Pax97]に対応して送られたデータの炸裂のサイズを阻止します。 伸びACKsは以前に不承認のデータの2つ以上のセグメントをカバーする承認です。 伸びACKsは実現バグ[All97b、PADHV99]のためかACKの損失のため故意に[Joh95](これは標準がではありませんが)起こることができます。 UBCと比べると、[All98]は、LBCが大きいライン料率炸裂を防ぐのを示します、そして、したがって、申し出はセグメントと、より良い性能を落としませんでした。 さらに、UBCは損失回復の間に到着できる大きい累積しているACKsによるベースの損失回復を遅れた出発の間の大きい炸裂に引き起こします。 損失回復の間の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.
以下に注意してください。 RFC2581[APS99]の標準化過程で、TCPはしかしながら、どんな遅れた出発のときにも輻輳回避の間、cwndを増加させないように重要であるバイトを使用できます。
3.2.2.2 Research
3.2.2.2 研究
Using byte counting, as opposed to standard ACK counting, has been shown to reduce the amount of time needed to increase the value of cwnd to an appropriate size in satellite networks [All97a]. In addition, [All98] presents a simulation comparison of byte counting and the standard cwnd increase algorithm in uncongested networks and networks with competing traffic. This study found that the limited form of byte counting outlined above can improve performance, while also increasing the drop rate slightly.
標準のACK勘定と対照的に重要であるバイトを使用するのは時間を短縮するのが、衛星ネットワーク[All97a]でcwndの値を適切なサイズまで増加させる必要だったのが示されました。 さらに、[All98]は、バイトのシミュレーション比較に勘定を提示して、非充血しているネットワークにおけるアルゴリズムと競争している交通に伴うネットワークを標準のcwnd増加に提示します。 この研究によって、また、低下率をわずかに増加させている間、上に概説されたバイト勘定の限局型が性能を向上させることができるのがわかりました。
[BPK97,BPK98] also investigated unlimited byte counting in conjunction with various ACK filtering algorithms (discussed in section 3.10) in asymmetric networks.
また、[BPK97、BPK98]は様々なACKフィルタリングアルゴリズムに関連して非対称のネットワークで重要である(セクション3.10で、議論します)無制限なバイトを調査しました。
Allman, et al. Informational [Page 8] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[8ページ]のRFC2760の進行中のTCP研究
3.2.2.3 Implementation Issues
3.2.2.3 導入問題
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スタックに釣り銭がいます。 バイト勘定にRFC2581[APS99](遅れた出発の間、混雑窓の成長をより攻撃的にするのによる)に概説された混雑ウィンドウを増加させるためのアルゴリズムに違反して、したがって、共用回線網に使用するべきではありません。
3.2.2.4 Topology Considerations
3.2.2.4 トポロジー問題
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増加を供給できるいくつか(そして、他のものによって丸く批評される)によってそれは示されました、受信機のACKing動きにかかわらず。また、さらに、バイト勘定はリターンリンクの容量のために伸びACKsを発生させる受信機によって供給された発達の遅い窓の成長を緩和します、[BPK97、BPK98]で議論するように。 したがって、この変化が非対称のネットワークに特に有益であると予想されます。
3.2.2.5 Possible Interaction and Relationships with Other Research
3.2.2.5 可能な相互作用と他の研究との関係
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はセグメントのライン料率炸裂の衝撃を少なくする何らかのアルゴリズムの利益を得るかもしれません。 また、遅れた出発(セクション3.2.3に概説されているように)が各ACKが遅れた出発の間、1つのセグメントだけをカバーしているのでアルゴリズムを数える限られたバイトを否定した後にだけ使用がACKsを遅らせたことに注意してください。 したがって、ACK勘定と同じように利回りを数えるバイトの両方がここ(最初のRTTで)に混雑ウィンドウを増やします。
3.2.3 Delayed ACKs After Slow Start
3.2.3 遅れた出発の後の遅れたACKs
3.2.3.1 Mitigation Description
3.2.3.1 緩和記述
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送付者は遅れた出発の間、混雑ウィンドウを増加させるのに入って来るACKsの数を使用します。 そして、遅れたACKsが受信機によって返されたACKsの数をおよそ半分減少させるので、混雑ウィンドウの成長率は低下します。 この問題の提案された解決が使用することになっている1つは遅れた出発(DAASS)フェーズの後にだけACKsを遅らせました。 TCPが定常状態(ネットワーク資源を保存する)にありますが、TCPが混雑ウィンドウと、より少ないACKsを積極的に増加させている間これは、より多くのACKsを提供します。
Allman, et al. Informational [Page 9] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[9ページ]のRFC2760の進行中のTCP研究
3.2.3.2 Research
3.2.3.2 研究
[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)が向上した後に遅れたACKsを使用して、そんなにいつも受信機と比べるとシミュレーションで、転送時間が遅れたACKsを発生させるのを示します。 しかしながら、また、DAASSはcwndの成長の増加するレートのため損失率をわずかに増加させます。
3.2.3.3 Implementation Issues
3.2.3.3 導入問題
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に関する大した問題は実現中です。 受信機は、送付者がいつ遅れた出発アルゴリズムを使用しているかをどうにか知らなければなりません。 受信機はデータ量における変化が受け取られているのを見て、それに従って、ACKingの振舞いを変えるのを試みるヒューリスティックを、実行するかもしれません。 または、送付者はメッセージ(恐らく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]に違反しません。 しかしながら、規格(RFC2581[APS99])は、現在遅れた承認を使用することを勧めます、そして、DAASSはこの推薦に(部分的に)反します。
3.2.3.4 Topology Considerations
3.2.3.4 トポロジー問題
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混雑をいらいらさせるかもしれません、ACKsの増加する数のため(ACK混雑の、より詳細な議論に関してセクション3.9と3.10を見てください)。
3.2.3.5 Possible Interaction and Relationships with Other Research
3.2.3.5 可能な相互作用と他の研究との関係
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
DAASSには、研究団体でする他の提案との数回の可能な相互作用があります。 DAASSは戻っている承認の増加する数のためデータ受信装置とデータ送付者の間の経路で混雑をいらいらさせることができます。 これはACK混雑を経験することの傾向がある非対称のネットワークに特に不利な影響を与えることができます。 セクション3.9と3.10で概説されているように、いくつかの緩和が低バンド幅リターンリンクの上に渡されるACKsの数を減少させるために提案されました。 DAASSを使用すると、受信機によって送られたACKsの数は増加するでしょう。ACKsの数を減少させるためのDAASSと方法との相互作用は未解決の研究問題です。 セクション3.2.1で上の.5、DAASSが、より大きい初期の混雑ウィンドウを使用するのと同じ利益のいくつかを提供して、したがって、両方のメカニズムを一緒に使用するのが望ましくないかもしれないことにまた、注意するので。 しかしながら、これは未決問題のままで残っています。 最終的に、DAASSと限られたバイト勘定は、増加するのにともに使用されます。
Allman, et al. Informational [Page 10] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[10ページ]のRFC2760の進行中のTCP研究
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アルゴリズムは限られたバイト勘定が混雑率窓の増加のときに持っている影響力をかなり減少させます。
3.2.4 Terminating Slow Start
3.2.4 遅れた出発を終えること。
3.2.4.1 Mitigation Description
3.2.4.1 緩和記述
The initial slow start phase is used by TCP to determine an appropriate congestion window size for the given network conditions [Jac88]. Slow start is terminated when TCP detects congestion, or when the size of cwnd reaches the size of the receiver's advertised window. Slow start is also terminated if cwnd grows beyond a certain size. The threshold at which TCP ends slow start and begins using the congestion avoidance algorithm is called "ssthresh" [Jac88]. In most implementations, the initial value for ssthresh is the receiver's advertised window. During slow start, TCP roughly doubles the size of cwnd every RTT and therefore can overwhelm the network with at most twice as many segments as the network can handle. By setting ssthresh to a value less than the receiver's advertised window initially, the sender may avoid overwhelming the network with twice the appropriate number of segments. Hoe [Hoe96] proposes using the packet-pair algorithm [Kes91] and the measured RTT to determine a more appropriate value for ssthresh. The algorithm observes the spacing between the first few returning ACKs to determine the bandwidth of the bottleneck link. Together with the measured RTT, the delay*bandwidth product is determined and ssthresh is set to this value. When TCP's cwnd reaches this reduced ssthresh, slow start is terminated and transmission continues using congestion avoidance, which is a more conservative algorithm for increasing the size of the congestion window.
初期の遅れた出発フェーズは、与えられたネットワーク条件[Jac88]のために適切な混雑ウィンドウサイズを決定するのにTCPによって使用されます。 TCPが混雑を検出するか、またはcwndのサイズが受信機の広告を出している窓のサイズに達するとき、遅れた出発は終えられます。 また、cwndが、あるサイズを超えたところまで成長するなら、遅れた出発は終えられます。 TCPが遅れた出発を終わらせて、輻輳回避アルゴリズムを使用し始める敷居は"ssthresh"[Jac88]と呼ばれます。 ほとんどの実現では、ssthreshのための初期の値は受信機の広告を出している窓です。 遅れた出発の間、TCPはおよそあらゆるRTTとしたがって、缶がネットワークが扱うことができるより最も2倍のセグメントでネットワークを圧倒するcwndのサイズを倍にします。 初めは受信機の広告を出している窓ほど値にssthreshを設定しないことによって、送付者は、セグメントの適切な数の2倍でネットワークを圧倒するのを避けるかもしれません。 くわ[Hoe96]は、ssthreshのために、より適切な値を決定するのにパケット組アルゴリズム[Kes91]と測定RTTを使用するよう提案します。 アルゴリズムはボトルネックリンクの帯域幅を決定するわずかな最初の戻っているACKsの間のスペースを観測します。 測定RTTと共に、遅れ*帯域幅生成物は決定しています、そして、ssthreshはこの値に用意ができています。 TCPのcwndがこの減少しているssthreshに達するとき、遅れた出発は終えられます、そして、トランスミッションは輻輳回避を使用し続けています。(輻輳回避は、混雑ウィンドウのサイズを増加させるための、より保守的なアルゴリズムです)。
3.2.4.2 Research
3.2.4.2 研究
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]をするのを特に試みて。 したがって、このメカニズムが広く配備される前にその他の詳細で帯域幅見積りを研究しなければなりません。
3.2.4.3 Implementation Issues
3.2.4.3 導入問題
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
[Hoe96]に概説されているように、ssthreshを見積もっているのはデータ送付者のTCPスタックへの変化を必要とします。 [AP99]に示されるように、TCP受信機で取ると、帯域幅見積りは、より正確であるかもしれません、そして、したがって、送付者と受信機変化の両方が必要でしょう。 見積もっています。
Allman, et al. Informational [Page 11] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[11ページ]のRFC2760の進行中のTCP研究
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]).
ssthreshは輻輳制御見解から生産ネットワークで実行するために安全です、TCPをRFC2581[APS99]に概説されているより保守的にすることができるだけであるとき(TCP実現を仮定すると、[APS99]によって許容されているように無限の初期のssthreshは使用されています)。
3.2.4.4 Topology Considerations
3.2.4.4 トポロジー問題
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で概説されたすべての左右対称のtopologiesで等しくうまくいくと予想されます。 しかしながら、非対称のリンクは特別な問題を引き起こします、戻っているACKsのレートが順方向へのボトルネック帯域幅でないかもしれないので。 これはあまりに低くssthreshを設定する送付者に通じることができます。 輻輳回避が、より保守的にcwndを開くとき、遅れた出発の未完熟終了は性能に害を与えることができます。 受信機ベースの帯域幅見積り人はこの問題に悩みません。
3.2.4.5 Possible Interaction and Relationships with Other Research
3.2.4.5 可能な相互作用と他の研究との関係
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に概説されているように)を使用すると、複数の無くなっているセグメントThereforeからすぐに回復するTCPの性能を抜本的に改良できて、大きい損失出来事が起こる前の遅れた出発を終えるのは同じくらい重要でないかもしれません。 [AP99]は、遅れた承認[Bra89]を使用すると送付者サイド帯域幅見積りの有効性が減少するのを示します。 したがって、遅れた出発(セクション3.2.3に概説されているように)だけの間遅れたACKsを使用するのに、帯域幅見積りは、より可能になるかもしれません。
3.3 Loss Recovery
3.3 損失回復
3.3.1 Non-SACK Based Mechanisms
3.3.1 非袋のベースのメカニズム
3.3.1.1 Mitigation Description
3.3.1.1 緩和記述
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
一般に、これらのアルゴリズムは、「再-トランスミッション」の引き金となるように「部分的なACKs」によって提供された情報を使用するために速い回復アルゴリズムをアップデートすることによって、利きます。 単独海損出来事が始まると、部分的なACKは未払いのすべてのデータではなく、いくつかの新しいデータをカバーしています。 例えば、セグメントNが速さを使用することで再送されたらケースを考えてください。
Allman, et al. Informational [Page 12] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[12ページ]のRFC2760の進行中のTCP研究
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.
アルゴリズムを再送してください。そうすれば、セグメントMはセグメントNを再送するとき送った最後のセグメントです。 セグメントNが失われた唯一のセグメントであるなら、セグメントNの「再-トランスミッション」によって引き出されたACKはセグメントM.Ifのためのものであるだろう、しかしながら、また、セグメントN+1は失われて、セグメントNの「再-トランスミッション」によって引き出されたACKはNにな+1るでしょう。 セグメントN+1がなくされて、「再-トランスミッション」の引き金となっていたという指示としてこれをみなすことができます。
3.3.1.2 Research
3.3.1.2 研究
Hoe [Hoe95,Hoe96] introduced the idea of using partial ACKs to trigger retransmissions and showed that doing so could improve performance. [FF96] shows that in some cases using partial ACKs to trigger retransmissions reduces the time required to recover from multiple lost segments. However, [FF96] also shows that in some cases (many lost segments) relying on the RTO timer can improve performance over simply using partial ACKs to trigger all retransmissions. [HK99] shows that using partial ACKs to trigger retransmissions, in conjunction with SACK, improves performance when compared to TCP using fast retransmit/fast recovery in a satellite environment. Finally, [FH99] describes several slightly different variants of NewReno.
くわ[Hoe95、Hoe96]は、部分的なACKsを使用するという考えを引き金の「再-トランスミッション」に紹介して、そうするのが性能を向上させることができるのを示しました。 [FF96]は、「再-トランスミッション」の引き金となるのにいくつかの場合部分的なACKsを使用すると複数の無くなっているセグメントから回復するのに必要である時間が短縮されるのを示します。 しかしながら、また、[FF96]は、いくつかの場合RTOタイマを当てにする(多くの無くなっているセグメント)がすべての「再-トランスミッション」の引き金となる単に部分的なACKsを使用する上の性能を向上させることができるのを示します。 「再-トランスミッション」の引き金となるのに部分的なACKsを使用して、TCP使用と比べるとSACKに関連して性能を向上させる[HK99]ショーが速く衛星環境における/速い回復を再送します。 最終的に、[FH99]はNewRenoのいくつかのわずかに異なった異形について説明します。
3.3.1.3 Implementation Issues
3.3.1.3 導入問題
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スタックへの変化を必要とします。 これらの変化は、生産ネットワークで安全に実行できて、RFC2581[APS99]によって許容されています。
3.3.1.4 Topology Considerations
3.3.1.4 トポロジー問題
It is expected that these changes will work well in all environments outlined in section 2.
これらの変化がセクション2で概説されたすべての環境でうまくいくと予想されます。
3.3.1.5 Possible Interaction and Relationships with Other Research
3.3.1.5 可能な相互作用と他の研究との関係
See section 3.3.2.2.5.
セクション3.3を見てください。.2 .2 .5。
3.3.2 SACK Based Mechanisms
3.3.2 袋のベースのメカニズム
3.3.2.1 Fast Recovery with SACK
3.3.2.1 袋がある速い回復
3.3.2.1.1 Mitigation Description
3.3.2.1.1 緩和記述
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
秋とフロイド[FF96]は受信機によって送られた選択している承認(SACKs)[MMFR96]で提供された情報を考慮に入れる速い回復アルゴリズムに保守的な拡大について説明します。始めが後に速く再送するアルゴリズムはaの再送の引き金となります。
Allman, et al. Informational [Page 13] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[13ページ]のRFC2760の進行中のTCP研究
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).
セグメント。 損失が検出されるとき、速いことで再送するように、アルゴリズムは半分にcwndを切ります。 アルゴリズムは「パイプ」と呼ばれる変数を保ちます。(それは、ネットワークにおける、傑出しているセグメントの数の見積りです)。 パイプ変数は新しいSACK情報と共に到着するそれぞれの写しACKあたり1つのセグメントで減少します。 パイプ変数がそれぞれのために新しい状態で1つ増加されたか、または再送されたセグメントは発信しました。 パイプの値がcwnd以下(SACK情報が、いいえが以上が再送する必要であることを示すなら、このセグメントは、SACK情報あたり1個の「再-トランスミッション」か新しいセグメントのどちらかである)であるときに、セグメントを送るかもしれません。
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は損失検出の1RTTの中でデータの窓の複数のセグメントの損失から回復できます。 以下で説明された前進の承認(ファーク)アルゴリズムのように、パイプアルゴリズムはSACK情報で選択の選択からどんなセグメントを送るかをセグメントをいつ送るかを衝撃を吸収できます。
[APS99] allows the use of this algorithm, as it is consistent with the spirit of the fast recovery algorithm.
それが速い回復アルゴリズムの精神と一致しているので、[APS99]はこのアルゴリズムの使用を許します。
3.3.2.1.2 Research
3.3.2.1.2 研究
[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]は、上の説明されたSACKアルゴリズムが1--4 セグメントがデータの窓から失われているとき、数個非SACKが回復アルゴリズムを基礎づけたよりよく働くのを示します。 [AHKO97]は、アルゴリズムが衛星中継の上の性能を向上させるのを示します。 ヘイズ[Hay97]はコネある事情を示していて、SACKアルゴリズムは損失回復が終わりにデータの大きいライン料率炸裂を発生させるのによる性能に害を与えることができます。回復で、一層の損失をもたらします。
3.3.2.1.3 Implementation Issues
3.3.2.1.3 導入問題
This algorithm is implemented in the sender's TCP stack. However, it relies on SACK information generated by the receiver. This algorithm is safe for shared networks and is allowed by RFC 2581 [APS99].
このアルゴリズムは送付者のTCPスタックで実行されます。 しかしながら、それは受信機で発生するSACK情報を当てにします。このアルゴリズムは、共用回線網に安全であり、RFC2581[APS99]によって許容されています。
3.3.2.1.4 Topology Considerations
3.3.2.1.4 トポロジー問題
It is expected that the pipe algorithm will work equally well in all scenarios presented in section 2.
パイプアルゴリズムがセクション2に提示されたすべてのシナリオで等しくうまくいくと予想されます。
3.3.2.1.5 Possible Interaction and Relationships with Other Research
3.3.2.1.5 可能な相互作用と他の研究との関係
See section 3.3.2.2.5.
セクション3.3を見てください。.2 .2 .5。
Allman, et al. Informational [Page 14] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[14ページ]のRFC2760の進行中のTCP研究
3.3.2.2 Forward Acknowledgments
3.3.2.2 前進の承認
3.3.2.2.1 Mitigation Description
3.3.2.2.1 緩和記述
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.
Forward Acknowledgment(ファーク)アルゴリズム[MM96a、MM96b]は、損失回復の間、TCP輻輳制御を改良するために開発されました。 ファークは混雑状態に関する追加情報を収集するのにTCP SACKオプションを使用します、回復の間、ネットワークへのデータの注射により正確なコントロールを加えて。 ファークは、輻輳制御を改良するのに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].
ファークの最新のバージョンはRateを半分にしている[MM96b]です。(そこでは、パケットが回復の間に受け取られた2ACKs毎のために送られます)。 セグメントを伝える、あらゆる、-別、ACKには、1つの周遊旅行で半分のネットワークによって首尾よく扱われた(したがって、cwndはいつ要素以上でそれでまだネットワークが支えることができることの半分まで減少している2で大き過ぎますか)パケットの数に混雑ウィンドウを減少させるという結果があります。 Rate-半分にのファークの別の重要な一面が伝わるので回復の間ACK自己時計を支えるということである、パケット、あらゆる、-別、ACKは、速い回復アルゴリズム[Ste97、APS99]で必要に応じて伝わる前にネットワークから排水するために半分のcwndにデータを要求しません。
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.
さらに、Rateを半分にしている実現のファークはそれぞれの無くなっているセグメントにThresholded Retransmissionを提供します。 "Tcprexmtthresh"によるTCPが断食の引き金とならなければならなかった写しACKsの数が回復を再送して、入るということです。 ファークは、tcprexmtthresh SACKブロックが、セグメントを再送する前に与えられたセグメントがなくなるのを示すまで待つことによって、すべてのセグメントにthresholded retransmissionを適用します。 これはリンクにおける合理的な振舞いにその追加注文セグメントを許容します。 上で説明されるように、ファークは回復の間に受け取られたあらゆる第2ACKのためにセグメントを送ります。 tcprexmtthresh SACKブロックが低下しているセグメントがそのポイントで再送される低下しているセグメントに関して観測された時を除いて、新しいセグメントは伝えられます。
[APS99] allows the use of this algorithm, as it is consistent with the spirit of the fast recovery algorithm.
それが速い回復アルゴリズムの精神と一致しているので、[APS99]はこのアルゴリズムの使用を許します。
3.3.2.2.2 Research
3.3.2.2.2 研究
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
オリジナルのファークアルゴリズムは[MM96a]に概説されています。 アルゴリズムは、後でRateを半分にしている[MM96b]を含むように高められました。 Rate-半分にとのファークの実績が案内された本当の世界はるかに近くにある
Allman, et al. Informational [Page 15] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[15ページ]のRFC2760の進行中のTCP研究
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].
TCPのための理論上の最大である、速い回復概説されたコネセクション3.3.2.1[MSMO97]へのTCPリノかSACKのベースの拡張子のどちらかより。
3.3.2.2.3 Implementation Issues
3.3.2.2.3 導入問題
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].
ファークを使用するために、送付者のTCPスタックを変更しなければなりません。 さらに、受信機は、ファークを使用する完全給付を得るためにSACKオプションを発生させることができなければなりません。 ファークアルゴリズムは、共用回線網に安全であり、RFC2581[APS99]によって許容されています。
3.3.2.2.4 Topology Considerations
3.3.2.2.4 トポロジー問題
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.
ファークがセクション2で概説されたすべての環境における性能を向上させると予想されます。 自己時計をTCPリノよりよく支えることができるので、それは長時間の遅延経路の上でかなり魅力的であるかもしれません。
3.3.2.2.5 Possible Interaction and Relationships with Other Research
3.3.2.2.5 可能な相互作用と他の研究との関係
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のベースの損失回復アルゴリズムは事実上、データの窓から複数の無くなっているセグメントを修理するのを試みるという点において同様です。 使用するSACKベースの損失回復アルゴリズムの未解決の研究問題です。 さらに、これらのアルゴリズムはセクション3.3.1で説明された非SACK NewRenoアルゴリズムと同様です、複数の無くなっているセグメントから再送信タイマーを使用するのに戻らないで回復するのを試みるので。 示されたように、上のSACKベースのアルゴリズムはNewRenoアルゴリズムより強健です。 しかしながら、SACKアルゴリズムは協力関係を持っているTCP受信機を必要とします。(NewRenoアルゴリズムはそれを必要としません)。 合理的なTCP実現が両方を含むかもしれない、SACKベースとa NewRenoベースの損失回復アルゴリズム、送付者が受信機がSACKsを支持するかどうか基づく中で最も適切な損失回復アルゴリズムを使用できるように。 最終的に、速い回復のSACKベースの、そして、非SACKベースの両方のバージョンは損失を回復に残すときのデータの大きい炸裂を伝えるために示されました、いくつかの場合[Hay97]で。 したがって、アルゴリズムは何らかの炸裂抑圧アルゴリズムの利益を得るかもしれません。
3.3.3 Explicit Congestion Notification
3.3.3 明白な混雑通知
3.3.3.1 Mitigation Description
3.3.3.1 緩和記述
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
明白な混雑通知(電子証券取引ネットワーク)で、セグメントを落とさないで、ルータは差し迫っている混雑に関してTCP送付者に知らせることができます。 電子証券取引ネットワークの2つの主要な書式が研究されました。 ルータ、後方に、電子証券取引ネットワーク(BECN)を使って、直接データ創始者にメッセージを送ります。
Allman, et al. Informational [Page 16] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[16ページ]のRFC2760の進行中のTCP研究
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].
混雑についてそれを知らせます。 IPルータはICMP Source Quenchメッセージでこれを達成できます。 BECN信号の到着は、TCPデータ・セグメントが落とされたことを意味するかもしれませんが、それはTCP送付者が送付レート(すなわち、cwndの値)を低下させるべきであるという明確な指示です。 2番目の主要な形式に関する混雑通知は前進の電子証券取引ネットワーク(FECN)です。 FECNルータは、混雑が差し迫っているとき、特別なタグをデータ・セグメントに付けますが、データ・セグメントを進めます。 そして、データ受信装置はACKパケットの送付者に混雑情報をecho backです。 [RF99]でTCP/IPのためのFECNメカニズムの記述を与えます。
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ヘッダーに設定された「電子証券取引ネットワークのできる輸送」ビットでセグメントを伝えます。 ルータであるなら、Random Early Detection(RED)[FJ93、BCC+98]などのように、そうでなければ、アクティブな待ち行列戦略を使うと、このセグメントは低下して、IPヘッダーの「経験された混雑」ビットは代わりに設定されます。 レセプションでは、情報は、TCPヘッダーで少し使用することでTCP送付者にecho backです。 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]の指定されるとしての電子証券取引ネットワークの実現は影響を受けるルータにおける、アクティブな待ち行列管理メカニズムの展開を必要とします。 これで、ルータは多くのセグメントを捨てるよりむしろ、少ない数の「混雑信号」(セグメント低下か電子証券取引ネットワークメッセージ)をTCPに送ることによって、混雑を示すことができます、TCPが低下テールルータ待ち行列を圧倒するとき、起こることができるとき。
Since satellite networks generally have higher bit-error rates than terrestrial networks, determining whether a segment was lost due to congestion or corruption may allow TCP to achieve better performance in high BER environments than currently possible (due to TCP's assumption that all loss is due to congestion). While not a solution to this problem, adding an ECN mechanism to TCP may be a part of a mechanism that will help achieve this goal. See section 3.3.4 for a more detailed discussion of differentiating between corruption and congestion based losses.
衛星ネットワークには地球のネットワークより高いビット誤り率が一般にあるので、セグメントが混雑か不正のため失われたかどうか決定するのに、TCPは高いBER環境における現在可能であるより(すべての損失が混雑のためであるというTCPの仮定による)良い性能を達成できるかもしれません。 この問題の解決でない間、電子証券取引ネットワークメカニズムをTCPに加えるのは、この目標を達成するのを助けるメカニズムの一部であるかもしれません。 不正と混雑の間でベースの損失を微分するより詳細な議論に関してセクション3.3.4を見てください。
3.3.3.2 Research
3.3.3.2 研究
[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]は、電子証券取引ネットワークが特に略してより良い性能と対話的なTCP接続をもたらすセグメント損失率を低下させるのにおいて有効であることを示します。 その上、また、[Flo94]は、電子証券取引ネットワークがいくつかの不要で、高価なTCP再送タイムアウトを避けるのを示します。 また、最終的に、[Flo94]は利点のいくつかと様々な形式の明白な混雑通知の損失を考えます。
Allman, et al. Informational [Page 17] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[17ページ]のRFC2760の進行中のTCP研究
3.3.3.3 Implementation Issues
3.3.3.3 導入問題
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.
電子証券取引ネットワークの展開は送付者と受信機の両方におけるTCP実現への変化を必要とします。さらに、電子証券取引ネットワークの展開はルータにおける、何らかのアクティブな待ち行列管理インフラストラクチャの展開を必要とします。 REDはほとんどの電子証券取引ネットワークの議論で想定されます、REDが低下するために既にセグメントを特定しているので、バッファ領域が疲れ果てる前にさえ。 混雑が経路に沿って起こっているようにまだエンドノードに通知している間、電子証券取引ネットワークは単に「著しい」セグメントの配送を許します。 共用回線網に、電子証券取引ネットワークは安全です(輻輳制御見解からの)、混雑がセグメント低下を通して検出されるとき使用されるのと同じTCP輻輳制御原則を維持するとき。
3.3.3.4 Topology Considerations
3.3.3.4 トポロジー問題
It is expected that none of the environments outlined in section 2 will present a bias towards or against ECN traffic.
セクション2で概説された環境のいずれも交通か電子証券取引ネットワーク交通に対して偏見を提示しないと予想されます。
3.3.3.5 Possible Interaction and Relationships with Other Research
3.3.3.5 可能な相互作用と他の研究との関係
Note that some form of active queueing is necessary to use ECN (e.g., RED queueing).
何らかのフォームのアクティブな待ち行列が電子証券取引ネットワーク(例えば、RED待ち行列)を使用するのに必要であることに注意してください。
3.3.4 Detecting Corruption Loss
3.3.4 不正損失を検出すること。
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
損失が不正よりむしろ混雑のためであるというTCPの仮定は混雑崩壊[Jac88、FF98]を防ぐ保守的なメカニズムです。 しかしながら、衛星ネットワークの上では、多くの無線の環境のように、不正による損失は地球のネットワークより一般的です。 この問題への1つの一般的な部分的解決がそうです。
Allman, et al. Informational [Page 18] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[18ページ]のRFC2760の進行中のTCP研究
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.
衛星/無線電信を移動したデータにForward Error Correction(FEC)を追加するには、リンクしてください。 [AGS99]でFECの利益の、より完全な議論を見つけることができます。 しかしながら、FECをいつも働くことができるというわけではないか、一般に適用できないなら、他のメカニズムは、TCPを混雑ベースの、そして、不正ベースの損失を区別できるようにするのを試みるために研究されました。
TCP segments that have been corrupted are most often dropped by intervening routers when link-level checksum mechanisms detect that an incoming frame has errors. Occasionally, a TCP segment containing an error may survive without detection until it arrives at the TCP receiving host, at which point it will almost always either fail the IP header checksum or the TCP checksum and be discarded as in the link-level error case. Unfortunately, in either of these cases, it's not generally safe for the node detecting the corruption to return information about the corrupt packet to the TCP sender because the sending address itself might have been corrupted.
腐敗しているTCPセグメントはリンク・レベルチェックサムメカニズムがそれを検出するとルータに介入することによってたいてい落とされて、入って来るフレームには誤りがあるということです。 ほとんどいつもIPヘッダーチェックサムかTCPチェックサムに失敗します。リンク・レベル誤り事件のようにそれのポイントでそれは時折、誤りを含むTCPセグメントが検出なしでTCP受信ホストに到着するまで生き残るかもしれなくて、それを捨てるでしょう。 残念ながら、これらのケースのどちらかでは、ノードのための一般に金庫が送付アドレス自体が腐敗しているかもしれないので不正なパケットの情報をTCP送付者に返すために不正を検出して、それはそうしていません。
3.3.4.1 Mitigation Description
3.3.4.1 緩和記述
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が何が起こったかを理解して、適切にこたえることができるような方法で修理をするようにこれらのメカニズムを手に入れることになっているように思えます。
3.3.4.2 Research
3.3.4.2 研究
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
これまでの不正検出の研究は、リンク・レベルが誤りを検出して、次に、リンク・レベル「再-トランスミッション」を実行するのを主として作るのは焦点を合わせました。 この仕事は[BKVP97、BPSK96]にまとめられます。 この有望なテクニックに関する問題の1つはTCP受信機の観点からセグメントの有効な再命令を引き起こすということです。 簡単な例として、騒がしいリンクの向こう側にセグメントA B C Dを送って、セグメントBを崩壊させるなら、リンクでBを再送できる前にセグメントCとDは既にリンクを越えたかもしれません。
Allman, et al. Informational [Page 19] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[19ページ]のRFC2760の進行中のTCP研究
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.
レベル、セグメントCとD.Ifの到着のときにTCP受信機がC D B.Thisセグメント再命令で写しACKsを生成するオーダーAにおけるTCP受信機に到着することを引き起こして、再命令が十分悪かった、送付者は速さの引き金となるでしょう。TCP送付者でアルゴリズムを再送してください、写しACKsに対応して。 [MV98]に提示された研究はこの振舞いを打ち消すために写しACKsを反対の方向に抑圧するか、または遅らせるという考えを提案します。 あるいはまた、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 Source Quenchメッセージで行われる反対の方向にというよりむしろパケットの目的地に向かって。 順方向のエラーメッセージを送るのに、このフィードバックは非対称の経路の上で利きます。 上で述べたように、ソースと送付先アドレスが有効でないかもしれないので、破損しているパケットに対応してエラーメッセージを生成するのは問題が多いです。 ルータに最近のパケットの目的地の小さいキャッシュを維持させることによって、[DMT96]に概説されたメカニズムはこの問題を逃れます。 ルータが何らかの敷居を超えて誤り率になるとき、それはICMPの不正で経験豊富なメッセージをキャッシュにおける目的地のすべてに送ります。 そして、それぞれのTCP受信機はそれぞれのTCP送付者(TCPオプションによる)にこの情報を返さなければなりません。 この「不正で経験豊富な」オプションでACKを受けると、TCP送付者は、2周遊旅行時間(RTT)の混雑よりむしろかそれが追加リンク州の情報(「リンクはダウンする」か、ソース焼き入れ、または「経験された不正」追加メッセージなどの)を受け取るまでパケット損失が不正のためであると仮定します。 2RTTsのためにセグメントの損失を無視すると共用回線網では、混雑が作成TCP無反応でいらいらさせるかもしれないことに注意してください。
3.3.4.3 Implementation Issues
3.3.4.3 導入問題
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送受信スタックへの変化を必要とします、中間的ルータと同様に。 ことによると、混雑信号(すなわち、セグメント低下)を無視することに関する心配のため、上のアルゴリズムは共用回線網における使用のために推薦されません。
3.3.4.4 Topology Considerations
3.3.4.4 トポロジー問題
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で概説されたすべての環境で有益であると予想されます。 それはこれらの誤りが、より一般的であるかもしれない衛星/ワイヤレス環境で特に有益でしょう。
Allman, et al. Informational [Page 20] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[20ページ]のRFC2760の進行中のTCP研究
3.3.4.5 Possible Interaction and Relationships with Other Research
3.3.4.5 可能な相互作用と他の研究との関係
SACK-based loss recovery algorithms (as described in 3.3.2) may reduce the impact of corrupted segments on mostly clean links because recovery will be able to happen more rapidly (and without relying on the retransmission timer). Note that while SACK-based loss recovery helps, throughput will still suffer in the face of non-congestion related packet loss.
SACKベースの損失回復アルゴリズム、(中で説明される、3.3、.2、)、回復が、より急速(そして再送信タイマーを当てにしないで)に起こることができるので、ほとんど清潔なリンクで崩壊したセグメントの影響を減少させるかもしれません。 SACKベースの損失回復が助けている間スループットにそれでも、非混雑の関連するパケット損失に直面して苦しむことに注意してください。
3.4 Congestion Avoidance
3.4 輻輳回避
3.4.1 Mitigation Description
3.4.1 緩和記述
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つのセグメントを加えます。 数人の研究者が、異なったRTTsとの複数の接続が同じボトルネックリンクを横断するとき、この方針が帯域幅の不公平な共有に通じるのを観測しました、長い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つの効果的な解決はネットワークルータ[Sut98]で公正な待ち行列とTCPに優しいバッファ管理を配布することです。 しかしながら、ネットワークからの助けがないとき、他の研究者はTCP送付者で輻輳回避方針への変化を調査しました、[Flo91、HK98]で説明されるように。
3.4.2 Research
3.4.2 研究
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]の両方が長いRTT接続に対して「一定のレート」方針が偏見を主に修正する場合を例証します、[HK98]はそのような方針は操作上のネットワークで増加して配布するのが難しいかもしれないという何らかの証拠を提示しますが。 定数(一定の上昇率のための)の適切な選択は未解決の問題です。
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.
長いRTT接続は異機種混在環境に選択的に「Kによる増加」方針を使用できます。 この方針は単に直線的な増加のスロープを変えます、当然のことのRTT敷居の上の関係が、「K」があらゆるRTTを混雑ウィンドウに区分すると言い足していて、1の代わりに。 [HK98]は「K」の小さい値と共に使用されるとこの方針がリンク利用を高く保っている間、不公平を減少させるのに成功しているかもしれないという証拠を提示します、少ない数の接続がボトルネックリンクを共有するとき。 一定の「K」の選択、多くの流れの下でこの方針、および性能を呼び出すRTT敷居はすべて開いている問題です。
Allman, et al. Informational [Page 21] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[21ページ]のRFC2760の進行中のTCP研究
3.4.3 Implementation Issues
3.4.3 導入問題
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の合理的に正確な見積りがなければなりません。 上に概説されたアルゴリズムを、RFC2581[APS99]に概説されているように輻輳回避アルゴリズムに違反して、したがって、このとき、共用回線網で実装するべきではありません。
3.4.4 Topology Considerations
3.4.4 トポロジー問題
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.
これらのソリューションはすべての地球のネットワークについて統合している衛星ネットワークに適切です。そこでは、衛星接続が同じボトルネックリンクのための陸生の接続と競争しているかもしれません。
3.4.5 Possible Interaction and Relationships with Other Research
3.4.5 可能な相互作用と他の研究との関係
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]に示されるように、複数の1RTTあたりのセグメントで混雑ウィンドウを増強するのは、TCPがTCPのいくつかのバージョンで複数のセグメントを下げて、再送タイムアウトを強制することを引き起こす場合があります。 したがって、輻輳回避アルゴリズムへの上の変化は、すぐに複数の下げられたセグメントを修理できるSACKベースの損失回復アルゴリズムで伴われる必要があるかもしれません。
3.5 Multiple Data Connections
3.5 複数のデータコネクションズ
3.5.1 Mitigation Description
3.5.1 緩和記述
One method that has been used to overcome TCP's inefficiencies in the satellite environment is to use multiple TCP flows to transfer a given file. The use of N TCP connections makes the sender N times more aggressive and therefore can improve throughput in some situations. Using N multiple TCP connections can impact the transfer and the network in a number of ways, which are listed below.
衛星環境におけるTCPの非能率に打ち勝つのに使用された1つのメソッドは与えられたファイルを移すのに複数のTCP流れを使用することです。 N TCP接続の使用は、送付者をN倍より攻撃的にして、したがって、いくつかの状況におけるスループットを改良できます。 N倍数TCP接続を使用すると、多くの方法で転送とネットワークに影響を与えることができます。(方法は以下に記載されています)。
1. The transfer is able to start transmission using an effective
congestion window of N segments, rather than a single segment as
one TCP flow uses. This allows the transfer to more quickly
increase the effective cwnd size to an appropriate size for the
given network. However, in some circumstances an initial window
of N segments is inappropriate for the network conditions. In
this case, a transfer utilizing more than one connection may
aggravate congestion.
1. 転送は、1TCPとしてのただ一つのセグメントよりむしろ流れが使用するNセグメントの有効な混雑ウィンドウを使用することで伝送を始めることができます。 これで、転送は与えられたネットワークのために、より急速に有効なcwndサイズを適切なサイズまで増強できます。 しかしながら、いくつかの事情では、ネットワーク状態に、Nセグメントの初期の窓は不適当です。 この場合、1つ以上の接続を利用する転送は混雑をいらいらさせるかもしれません。
Allman, et al. Informational [Page 22] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[22ページ]のRFC2760の進行中のTCP研究
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)
(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.
明確に、これはaを使用するとTCP接続が選抜される時より有効なcwndサイズがそれほど劇的でない減少です。 そして、cwndは減少させられる量は増加するNによってさらに減少させられます。
The use of multiple data connections can increase the ability of non-SACK TCP implementations to quickly recover from multiple dropped segments without resorting to a timeout, assuming the dropped segments cross connections.
複数のデータ接続の使用は非SACK TCP実装が複数の下げられたセグメントからタイムアウトによく行かないですぐに回復する能力を増強できます、下げられたセグメントが交差接続であると仮定して。
The use of multiple parallel connections makes TCP overly aggressive for many environments and can contribute to congestive collapse in shared networks [FF99]. The advantages provided by using multiple TCP connections are now largely provided by TCP extensions (larger windows, SACKs, etc.). Therefore, the use of a single TCP connection is more "network friendly" than using multiple parallel connections. However, using multiple parallel TCP connections may provide performance improvement in private networks.
複数の並列接続の使用は、TCPを多くの環境にひどく攻撃的にして、共用回線網[FF99]で充血性の崩壊の原因となることができます。 TCP拡張子(より大きい窓、SACKsなど)で現在、複数のTCP接続を使用することによって提供された利点を主に提供します。 したがって、単独のTCP接続の使用は複数の並列接続を使用するより「ネットワーク味方」です。 しかしながら、複数の平行なTCP接続を使用すると、性能改良は私設のネットワークに提供されるかもしれません。
Allman, et al. Informational [Page 23] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[23ページ]のRFC2760の進行中のTCP研究
3.5.2 Research
3.5.2 研究
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接続(大きい窓とSACKと)[AHKO97]より優れることができるのを示しました。 しかしながら、これらの研究は競争しているトラフィックにおける複数のTCP関係を使用する影響を考えませんでした。 [FF99]は、与えられたファイルを移すのに複数の同時接続を使用するのが共用回線網での充血性の崩壊に通じるかもしれないと主張します。
3.5.3 Implementation Issues
3.5.3 導入問題
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接続を使用するのを共用回線網で安全でなく(輻輳制御見解からの)、使用するべきではありません。
3.5.4 Topological Considerations
3.5.4 位相的な問題
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]接続の適切な数を測定するためにいくらかの仕事をしましたが、そのようなメカニズムは全く完全ではありません。
3.5.5 Possible Interaction and Relationships with Other Research
3.5.5 可能な相互作用と他の研究との関係
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を見てください)。
3.6 Pacing TCP Segments
3.6 TCPセグメントに歩調を合わせること。
3.6.1 Mitigation Description
3.6.1 緩和記述
Slow-start takes several round trips to fully open the TCP congestion window over routes with high bandwidth-delay products. For short TCP connections (such as WWW traffic with HTTP/1.0), the slow-start overhead can preclude effective use of the high-bandwidth satellite links. When senders implement slow-start restart after a TCP connection goes idle (suggested by Jacobson and Karels [JK92]),
遅れた出発は高帯域遅れ製品があるルートの上でTCP混雑ウィンドウを完全に開ける旅行を数個持ち回ります。 背の低いTCP接続(HTTP/1.0があるWWWなどのトラフィック)のために、遅れた出発オーバーヘッドは高帯域衛星中継の有効な使用を排除できます。 送付者が遅れた出発を実装するときには、TCP接続が活動していなく(ジェーコブソンとKarels[JK92]によって提案されます)なった後に再開してください。
Allman, et al. Informational [Page 24] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[24ページ]のRFC2760の進行中のTCP研究
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].
性能は長命(しかし、bursty)の接続(HTTP/1.1などの)[Hei97a]で抑えられます。1.1は、複数のWWWページ要素を移すのに永続的なTCP接続を使用します。
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セグメントに歩調を合わせる入って来るACKsが不在のとき使用されるテクニックです。 最初の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は短い転送にさえ高帯域遅れリンクをうまく利用することができるかもしれません。 しかしながら、TCPがそうする最初のRTTの間のセグメントは、標準的でない初期の混雑ウィンドウを使用して、歩調を合わせる新しいメカニズムが外向的なセグメントであったなら歩き回るために背中合わせにそれらを送るよりむしろそうしなければなりません。 初期のcwndのために適切なサイズを決定するのは、未解決の研究問題です。 また、一般に、炸裂を減少させるのにペースを使用できます(バギーのTCPsかバイト勘定のため、議論のためのバイトに関するセクション3.2.2が重要であることを見てください)。
3.6.2 Research
3.6.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にバーストいっぱいに後に怠けている(低下による)[VH98]の上の性能をわずかに向上させます。 より最近、ペースは、ACKが[BPK97]をフィルターにかけているネットワークでburstinessを排除するために示されました。
3.6.3 Implementation Issues
3.6.3 導入問題
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がトランスミッション[VH98]の1RTTのためにこのタイマを必要とするだけであるのでRBPでは、このオーバーヘッドが最小限であると示唆します。 RBPが活動していない期間の後に活動していない期間の後に遅れた出発に先祖帰りをしないホストでデータの炸裂を送る際にTCPをより保守的にすると予想されます。 他方では、RBPは送付者が長い活動していない期間の後にACK時計を始動するのに遅れた出発アルゴリズムを使用するならTCPをより攻撃的にします。
Allman, et al. Informational [Page 25] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[25ページ]のRFC2760の進行中のTCP研究
3.6.4 Topology Considerations
3.6.4 トポロジー問題
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.
セクション2におけるすべてのtopologiesのために無駄なTCP接続を再出発するのにRBPを使用できました。 新しい接続の始めの使用はバンドの外で利用可能な帯域幅を見積もることができるtopologiesに制限されるでしょう。
3.6.5 Possible Interaction and Relationships with Other Research
3.6.5 可能な相互作用と他の研究との関係
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に概説されているように)を見積もっているのは背中合わせのセグメントを送るよりむしろさらに難しくなるかもしれません。
3.7 TCP Header Compression
3.7 TCPヘッダー圧縮
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パケットは1パケットあたりのほんの数バイトのデータを通常運びます、そして、標準のIPv4/TCPヘッダーは少なくとも40バイトをこれに加えます。 IPv6/TCPヘッダーは少なくとも60バイトを加えます。 セッションの過程の上に比較的一定数にとどまっているので、この情報の多くを短いセッション識別子に取り替えることができます。
3.7.1 Mitigation Description
3.7.1 緩和記述
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
圧縮方法が[DNP99、DENP97、Jac90]で説明したTCP/IPヘッダーは、TCPとIPヘッダーの短い「接続番号」に応じて、予測できる方法で一定のままで残っているか、ゆっくり変化するか、または変化するデータを置き換えることによって、TCPセッションのオーバーヘッドを下げます。 このメソッドを使用して、完全なTCP/IPヘッダーは最初に送付者は送られて、それに送付者が含んでいる接続番号を含んでいると、接続は参照に使用されます。 制限からいくつかの分野に記入して、受信機は、完全なヘッダーを保存して、テンプレートとしてそれを使用します。
Allman, et al. Informational [Page 26] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[26ページ]のRFC2760の進行中のTCP研究
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).
より遅くて、圧縮されたヘッダーに含まれた情報。 この圧縮は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.
一般に、圧縮と減圧はIP層の下で起こります、与えられた物理的なリンク(シリアル・ラインによって接続された2つのルータなどの)のエンドポイントで。 物理的なリンクのどちらかの側面のホストはリンクを使用しているTCP接続に関して何らかの状態を維持しなければなりません。
The decompresser must pass complete, uncompressed packets to the IP layer. Thus header compression is transparent to routing, for example, since an incoming packet with compressed headers is expanded before being passed to the IP layer.
decompresserは完全で、解凍されたパケットをIP層に通過しなければなりません。 したがって、例えば、IP層に通過される前に圧縮されたヘッダーがある入って来るパケットが広げられるので、ヘッダー圧縮はルーティングにわかりやすいです。
A variety of methods can be used by the compressor/decompressor to negotiate the use of header compression. For example, the PPP serial line protocol allows for an option exchange, during which time the compressor/decompressor agree on whether or not to use header compression. For older SLIP implementations, [Jac90] describes a mechanism that uses the first bit in the IP packet as a flag.
さまざまなメソッドがコンプレッサー/減圧装置によって使用されて、ヘッダー圧縮の使用を交渉できます。 例えば、シリアル・ラインプロトコルがオプション取引、どの時間コンプレッサー/減圧装置を許容するPPPは、ヘッダー圧縮を使用するかどうか同意します。 より古いSLIP実装のために、[Jac90]は旗としてIPパケットにおける最初のビットを使用するメカニズムについて説明します。
The reduction in overhead is especially useful when the link is bandwidth-limited such as terrestrial wireless and mobile satellite links, where the overhead associated with transmitting the header bits is nontrivial. Header compression has the added advantage that for the case of uniformly distributed bit errors, compressing TCP/IP headers can provide a better quality of service by decreasing the packet error probability. The shorter, compressed packets are less likely to be corrupted, and the reduction in errors increases the connection's throughput.
リンクが地球のワイヤレスの、そして、モバイルの衛星中継(ヘッダービットを伝えると関連しているオーバーヘッドは重要である)などのように帯域幅によって限られるとき、オーバーヘッドの減少は特に役に立ちます。 ヘッダー圧縮には、TCP/IPヘッダーを圧縮する一様に分配された噛み付いている誤りに関するケースにサービスでパケットエラー確率を減少させることによって、より良質のaを供給できる加えられた利点があります。 より短くて、圧縮されたパケットは、より崩壊しそうにはありません、そして、誤りの減少は接続のスループットを増強します。
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
体系をコード化するこのデルタを使用することへの値がデルタとして前のパケットのそれらの値からコード化される不利な立場は単一の圧縮されたパケットが無くなるなら、彼らが無くなっているパケットに依存する分野を含むなら圧縮されたヘッダーがあるその後のパケットが誤り伝えられるようになることができるということです。 圧縮されたヘッダーと増加する一連番号があるパケットの前進のデータ・ストリームを考えてください。 パケットNが無くなると、パケットN+1の完全なヘッダーは、テンプレートとしてパケットN-1の完全なヘッダーを使用することで受信機に再建されるでしょう。 このようにして
Allman, et al. Informational [Page 27] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[27ページ]のRFC2760の進行中のTCP研究
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のヘッダーで計算されるべきであった)は間違うでしょう、そして、チェックサムは失敗するでしょう、そして、パケットは捨てられるでしょう。 いつ、decompresserを再連動させるように完全なヘッダーと共に回を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.
コンプレッサーがどんなタイマも維持しないことに注意するのが重要であり、decompresserは、誤りがいつ発生したかを(受信TCPだけがこれを知っています、TCPチェックサムが失敗すると)知りません。 1ビット、誤りはdecompresserが同時性を失われるでしょう、そして、圧縮されたヘッダーがあるその後のパケットは受信TCPによって下げられるでしょう、彼らが皆、TCPチェックサムに失敗するので。 これが起こるとき、写し承認は全く生成されないでしょう、そして、解凍されたヘッダーと共にパケットを受けるときだけ、decompresserは再連動できます。 これはヘッダー圧縮が使用されているとき、両方が速く再送されて、選択している承認が圧縮されたリンクの上に失われたできる正しいパケットにならないことを意味します。 「二度」という以下で説明されたアルゴリズムはこの問題への部分的解決であるかもしれません。
[DNP99] and [DENP97] describe TCP/IPv4 and TCP/IPv6 compression algorithms including compressing the various IPv6 extension headers as well as methods for compressing non-TCP streams. [DENP97] also augments TCP header compression by introducing the "twice" algorithm. If a particular packet fails to decompress properly, the twice algorithm modifies its assumptions about the inferred fields in the compressed header, assuming that a packet identical to the current one was dropped between the last correctly decoded packet and the current one. Twice then tries to decompress the received packet under the new assumptions and, if the checksum passes, the packet is passed to IP and the decompresser state has been re-synchronized. This procedure can be extended to three or more decoding attempts. Additional robustness can be achieved by caching full copies of packets which don't decompress properly in the hopes that later arrivals will fix the problem. Finally, the performance improvement if the decompresser can explicitly request a full header is discussed. Simulation results show that twice, in conjunction with the full header request mechanism, can improve throughput over uncompressed streams.
[DNP99]と[DENP97]はTCP/IPv4と非TCPストリームを圧縮するためのメソッドと同様に様々なIPv6拡張ヘッダーを圧縮するのを含むTCP/IPv6圧縮アルゴリズムを説明します。また、[DENP97]は、「二度」というアルゴリズムを導入することによって、TCPヘッダー圧縮を増大させます。 特定のパケットが適切に減圧しないなら、2倍アルゴリズムは圧縮されたヘッダーの推論された分野に関する仮定を変更します、現在のものと同じパケットが現在のものの間に下げられたと仮定して。 次に、新しい仮定で容認されたパケットを減圧するトライでありチェックサムが終わるなら、二度、パケットはIPに通過されます、そして、decompresser状態は再同期しました。 試みを解読しながら、この手順を3以上まで広げることができます。 後の到着が問題を修正するという望みで適切に減圧されない完全なコピーのパケットをキャッシュすることによって、追加丈夫さを達成できます。 最終的に、decompresserが明らかに完全なヘッダーを要求できるなら、性能改良について議論します。 シミュレーションの結果は、それが解凍されたストリームの上で二度完全なヘッダー要求メカニズムに関連してスループットを改良できるのを示します。
3.7.2 Research
3.7.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%改良したのを示します。
Allman, et al. Informational [Page 28] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[28ページ]のRFC2760の進行中のTCP研究
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.
この改良の多くがパケットが無くなるときdecompresserを急速に再連動させる2倍アルゴリズムのためであったかもしれません。 これはdecompresserが非連動するようになるとき1回か2回適用された2倍アルゴリズムがケースの83%から99%が調べたdecompresserを再同期させるからです。 これは、2倍がdecompresserを再連動させた後に正しく受け取られたパケットが写し承認を引き起こすことを意味します。 これはヘッダー圧縮に関連して断食が再送する両方とSACKの使用を再可能にします。
3.7.3 Implementation Issues
3.7.3 導入問題
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がヘッダー圧縮であると実装するのが送付(コンプレッサー)と圧縮を使用するそれぞれのリンクの受信(decompresser)端の両方に釣り銭がいます。 2倍アルゴリズムはほとんど圧縮の上と、そして、ヘッダー圧縮を超えて付加的な機械を必要としません、[DENP97]の明白なヘッダー要求メカニズムは発信への、より大幅な変更を必要とします、そして、それぞれのリンクの端を受けて、それはヘッダー圧縮を使いますが。 ヘッダー圧縮は、TCPの混雑制御機構に違反しないで、したがって、共用回線網で安全に実装することができます。
3.7.4 Topology Considerations
3.7.4 トポロジー問題
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倍アルゴリズムを実装して、適切に減圧しないパケットをキャッシュするのは、より重要になります。
3.7.5 Possible Interaction and Relationships with Other Research
3.7.5 可能な相互作用と他の研究との関係
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倍アルゴリズムの有効性は複数の無くなっているセグメントの影響を減少させるのにSACKベースの損失回復アルゴリズムを使用するのに指すかもしれません。 しかしながら、あまりに多くのセグメントが無くなるなら、非常に強健なSACKベースのアルゴリズムさえうまくいかないかもしれません。
3.8 Sharing TCP State Among Similar Connections
3.8 同様のコネクションズの中でTCP状態を共有すること。
Allman, et al. Informational [Page 29] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[29ページ]のRFC2760の進行中のTCP研究
3.8.1 Mitigation Description
3.8.1 緩和記述
Persistent TCP state information can be used to overcome limitations in the configuration of the initial state, and to automatically tune TCP to environments using satellite links and to coordinate multiple TCP connections sharing a satellite link.
初期状態の構成で限界を克服して、衛星中継を使用することで自動的に環境にTCPを調整して、衛星中継を共有している複数のTCP接続を調整するのに永続的なTCP州の情報を使用できます。
TCP includes a variety of parameters, many of which are set to initial values which can severely affect the performance of TCP connections traversing satellite links, even though most TCP parameters are adjusted later after the connection is established. These parameters include initial size of cwnd and initial MSS size. Various suggestions have been made to change these initial conditions, to more effectively support satellite links. However, it is difficult to select any single set of parameters which is effective for all environments.
TCPはさまざまなパラメタを含んでいます、接続が確立された後にほとんどのTCPパラメタが後で調整されますが。その多くが厳しく衛星中継を横断するTCP接続に関する実績に影響できる値に頭文字をつけるように設定されます。 これらのパラメタはcwndと初期のMSSサイズの初期のサイズを含んでいます。 これらの初期条件をより事実上サポート衛星中継に変えるのを様々な提案をしました。 しかしながら、どんなただ一つのセットのすべての環境に、有効なパラメタも選択するのは難しいです。
An alternative to attempting to select these parameters a-priori is sharing state across TCP connections and using this state when initializing a new connection. For example, if all connections to a subnet result in extended congestion windows of 1 megabyte, it is probably more efficient to start new connections with this value, than to rediscover it by requiring the cwnd to increase using slow start over a period of dozens of round-trip times.
先験的にこれらのパラメタを選択するのを試みることへの代替手段は、TCP接続の向こう側に状態を共有して、新しい接続を初期化するとき、この状態を使用することです。 例えば、この値との新しい関係を始めるのは1メガバイトの拡張混雑ウィンドウのサブネット結果とのすべての接続であるなら、たぶんcwndが増加するのを往復の何十回もの期間にわたって遅れた出発を使用することで必要とすることによってそれを再発見するより効率的です、。
3.8.2 Research
3.8.2 研究
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
接続の中で状態を共有すると、どんな情報を共有などだったらよいかなどの多くの質問が持って来られます、だれを共有するか、そして、どのようにそれを共有するか、そして、どのように共有された情報を年をとるかで。 まず最初に、どんな情報がことである共有されるかは決定しているに違いありません。 何らかの情報はTCP接続の中で共有するのが適切であるかもしれませんが、いくつかの情報共有は、不適当であるか、または役に立たないかもしれません。 次に、私たちは、だれを共有するかで情報を決定する必要があります。 与えられたホストと共通路を共有しているTCP接続に、共有は適切であるかもしれません。 情報はホストの中の接続の中、または、異なったホストの間の接続の中でさえ共有されるかもしれません、同じLANのホストなどのように。 しかしながら、同じネットワークを横断しない接続の間の情報交換は適切でないかもしれません。 共有する州とそれを共有するパーティーを考えて、共有のためのメカニズムが必要です。 MSSとRTTのように、簡単な状態は共有しやすいのですが、混雑窓の情報を共有できます。さまざまな道。 共有メカニズムは、接続、およびさまざまな公正評価基準がそうしなければならない共有の中のプライオリティが考えられることを決定します。 また、情報老いるメカニズムはさらなる研究を必要とします。 安全保障問題の議論のための両方のRFC2140が独身のホストの中で状態を共有して、サブネットでホストの中で状態を共有しているのを見てください。 最終的に1つの情報を共有すると関連している関心が必要とするセキュリティ
Allman, et al. Informational [Page 30] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[30ページ]のRFC2760の進行中のTCP研究
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.
そのようなメカニズムを紹介する前に慎重に考えられるために。 以前未解決の研究質問に答えなければならないこれらの多くが、広く共有を配布することができると述べます。
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]に記録されて、重要な平均したRTTsを提供するのに接続インスタンスの向こう側にそこで集合RTT値に使用されます、ほとんどの接続が1RTTだけのために固執すると予想されますが。 また、T/TCPは接続識別子(TCP接続が通常区別される窓の番号とアドレス/ポート組から別々の一連番号)を共有します。 この共有された状態の結果、T/TCPは受信機にSYNセグメントで受信アプリケーションにデータを通過させます、3方向ハンドシェイクの完成の前に、接続の保全に感染しないで。 事実上、この共有された州は前の接続からの部分的な握手をキャッシュします。(それは、TCB共有の、より一般的な問題の異形です)。
Sharing state among connections (including transfers using non-TCP protocols) is further investigated in [BRS99].
接続(非TCPプロトコルを使用することで転送を含んでいる)の中で状態を共有するのは[BRS99]でさらに調査されます。
3.8.3 Implementation Issues
3.8.3 導入問題
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状態を共有するのは安全であるべきです。 州の共有がマルチユーザホストの中の少しの新しい警備上の問題も提示しないことに注意してください。 そのような状況で、州の共有のあるなしにかかわらずユーザはお互いからネットワーク資源を横取りできます。
3.8.4 Topology Considerations
3.8.4 トポロジー問題
It is expected that sharing state across TCP connections may be useful in all network environments presented in section 2.
TCP接続の向こう側に状態を共有するのがセクション2に示されたすべてのネットワーク環境で役に立つかもしれないと予想されます。
Allman, et al. Informational [Page 31] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[31ページ]のRFC2760の進行中のTCP研究
3.8.5 Possible Interaction and Relationships with Other Research
3.8.5 可能な相互作用と他の研究との関係
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.
上に概説された州の共有は1組のホストの間のTCPとUDP流れの両方で混雑制御情報を共有するのを試みるCongestionマネージャ提案[BRS99]と非常に同様です。
3.9 ACK Congestion Control
3.9 ACK輻輳制御
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)であると生成すると、遅れたACKsが使用されていると、逆方向リンクは75:1以上のひずみのためのACKsと共に充血するでしょう、そして、37:1はあらゆるセグメントであるなら承認されます。 1.5Mb/秒、データはリンクして、ACK混雑は20キロビット/秒未満の逆方向リンク速度のために起こるでしょう。 逆方向リンクがそのままな複数の衛星電波受信装置の中で多くのVSAT衛星ネットワークで一般的に共有されると、これらのレベルの非対称は容易に起こるでしょう。 また、地球のモデムリンクが逆方向リンクとして使用されるなら、ACK混雑もありそうです、特に前進のリンクの速度が増強されるように。 現在の混雑制御機構はデータ・セグメントの流れを制御するのを目的とされますが、ACKsの流れに影響しないでください。
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]では、作者は、承認の流れがリンクの帯域幅によって制限される場合があるだけではなく、低速リンクの上にルータの待ち行列の長さによっても制限される場合があると指摘します。 ルータは、バイトではなく、パケットを数えることによって待ち行列の長さを制限して、したがって、帯域幅が彼らを進めることができるくらいあってもACKsを捨て始めるかもしれません。
3.9.1 Mitigation Description
3.9.1 緩和記述
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
ACK Congestion Controlはデータ・セグメントのためにフロー制御の概念について確認応答セグメントに敷衍しています。 [BPK97]で説明されたメソッドで、ルータにおける待ち行列占有がいったん与えられた敷居を超えていると、どんな中間的ルータもExplicit Congestion Notification(電子証券取引ネットワーク)ビットによる承認をマークできます。 データ送付者(承認を受ける)は電子証券取引ネットワークビットをデータ受信装置に「反響して戻さなければならない」(電子証券取引ネットワークの、より詳細な議論に関してセクション3.3.3を見てください)。 電子証券取引ネットワークビットでACKセグメントをマークするための提案されたアルゴリズムはRandom Early Detection(RED)[FJ93]です。 データ・セグメントであるとマークされた電子証券取引ネットワークの領収書に対応して、受信機は、乗法的なbackoffを使用することで承認の速度をダイナミックに低下させるでしょう。 電子証券取引ネットワークのないセグメントがいったん受け取られているようになると、データ受信装置は直線的な増加を使用することで承認を早くします、1のレートまで(
Allman, et al. Informational [Page 32] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[32ページ]のRFC2760の進行中のTCP研究
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.
遅れたACKs) または、1ACKあたり2つ(標準はACKsを遅らせた)のデータ・セグメント。 作者は、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.
データフローのためのRED混雑制御機構のように、ボトルネックゲートウェイは電子証券取引ネットワークビットでそれらをマークするより手当たりしだいにむしろ承認を捨てることができます、待ち行列がいったん与えられた敷居を超えていっぱいになると。
3.9.2 Research
3.9.2 研究
[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 Congestion Control(ACC)の非対称のネットワークの性能への効果を分析します。 彼らは、ACCの使用、および本当に承認の頻度を減少させるどんな体系の使用でも潜在的求められていない副作用があることに注意します。 以来、各ACKは、普通の1か2つのデータ・セグメントよりさらに、データ送付者からのセグメント炸裂の可能性が広げられると認めるでしょう。 さらに、受信機が容認されたACKsを数えることによって窓を育てるなら、混雑窓の成長は妨害されるかもしれません、[Ste97、APS99]によって強制されるように。 したがって、作者はデータ送付者へのTCP Sender Adaptation(SA)と呼ばれた一連の変更にACCを結合します。 SAはウィンドウサイズにかかわらず炸裂で送られたセグメントの数における限界を結合します。 さらに、バイト勘定(ACK勘定と対照的に)は窓の成長に使われます。 バイト勘定がほかの場所で研究されて、また[All98]、副作用を導入できることに注意してください。
The results presented in [BPK97] indicate that using ACC and SA will reduce the bursts produced by ACK losses in unmodified (Reno) TCP. In cases where these bursts would lead to data loss at an intermediate router, the ACC and SA modification significantly improve the throughput for a single data transfer. The results further suggest that the use of ACC and SA significantly improve fairness between two simultaneous transfers.
[BPK97]に提示された結果は、ACCとSAを使用すると(リノ)変更されていないTCPのACKの損失で発生した炸裂が減少するのを示します。 これらの炸裂が中間的ルータでデータの損失を出す場合では、ACCとSA変更はただ一つのデータ転送のためのスループットをかなり改良します。 結果は、ACCとSAの使用が2回の同時の転送の間の公正をかなり改良するのをさらに示します。
ACC is further reported to prevent the increase in round trip time (RTT) that occurs when an unmodified TCP fills the reverse router queue with acknowledgments.
ACCが変更されていないTCPが承認で逆のルータ待ち行列を満たすとき起こる周遊旅行時間(RTT)増加を防ぐとさらに報告されます。
In networks where the forward direction is expected to suffer losses in one of the gateways, due to queue limitations, the authors report at best a very slight improvement in performance for ACC and SA, compared to unmodified Reno TCP.
待ち行列制限による順方向がゲートウェイの1つで損害を被ると予想されるネットワークで、作者はACCとSAのために性能における非常にわずかな改良をせいぜい報告します、変更されていないリノTCPと比べて。
Allman, et al. Informational [Page 33] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[33ページ]のRFC2760の進行中のTCP研究
3.9.3 Implementation Issues
3.9.3 導入問題
Both ACC and SA require modification of the sending and receiving hosts, as well as the bottleneck gateway. The current research suggests that implementing ACC without the SA modifications results in a data sender which generates potentially disruptive segment bursts. It should be noted that ACC does require host modifications if it is implemented in the way proposed in [BPK97]. The authors note that ACC can be implemented by discarding ACKs (which requires only a gateway modification, but no changes in the hosts), as opposed to marking them with ECN. Such an implementation may, however, produce bursty data senders if it is not combined with a burst mitigation technique. ACC requires changes to the standard ACKing behavior of a receiving TCP and therefore is not recommended for use in shared networks.
ACCとSAの両方が発信の変更とボトルネックゲートウェイと同様に受信ホストを必要とします。 現在の研究は、データ送付者のSA変更結果のない潜在的に破壊的なセグメント炸裂を生成するACCを実装しながら、それを示します。 それが[BPK97]で提案された方法で実装されるならACCがホスト変更を必要とすることに注意されるべきです。 作者は、ACKs(ゲートウェイ変更だけを必要としますが、ホストにおけるどんな変化も必要としない)を捨てることによってACCを実装することができることに注意します、電子証券取引ネットワークを彼らに付けることと対照的に。 しかしながら、それが炸裂緩和のテクニックに結合されないなら、そのような実装はburstyデータ送付者を生産するかもしれません。 ACCは受信TCPの標準のACKing動きに釣り銭がいて、したがって、共用回線網における使用のために推薦されません。
3.9.4 Topology Considerations
3.9.4 トポロジー問題
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もゲートウェイでの状態のストレージを必要としません。 すべてのtopologiesに、したがって、これらの体系は適切であるべきです、衛星かハイブリッド回路網を使用しているホストを変更できれば。 しかしながら、これらの変化が非対称の衛星中継を含むネットワークに特に有益であると予想されます。
3.9.5 Possible Interaction and Relationships with Other Research
3.9.5 可能な相互作用と他の研究との関係
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.
電子証券取引ネットワークがACK輻輳制御を使用するためのプレ状態であることに注意してください。 さらに、次のセクションで議論したACK Filteringアルゴリズムは、ACCと同じ問題を解決するのを試みます。 現在、2つのアルゴリズム(または、別のメカニズム)を選ぶのは、未解決の研究問題です。
3.10 ACK Filtering
3.10 ACKフィルタリング
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 Filtering(AF)は、同じACK混雑が3.9で説明された効果であると扱うように設計されています。 しかしながら、ACCとは逆に、AFは、ホスト変更なしで作動するように設計されています。
3.10.1 Mitigation Description
3.10.1 緩和記述
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に含まれている窓の一部を承諾するACKs)のための余分なACKsのために待ち行列をスキャンします。 これらの「以前」のACKsのすべてが、待ち行列から取り除かれて、捨てられます。
Allman, et al. Informational [Page 34] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[34ページ]のRFC2760の進行中のTCP研究
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を受け取り次第待ち行列からセグメントを見つけて、取り除くのに必要である追加処理を実装する必要があります。
3.10.2 Research
3.10.2 研究
[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フィルタリングだけの使用は重要な送付者炸裂を発生させるでしょう、ACKsが以前により不承認のデータを承認するので。 .2が使用されているかもしれない3.9で説明されたSA変更はホスト変更を必要とする費用でそれらの炸裂を防ぎます。 TCPスタックでの変更の必要性を防ぐために、AFはACK Reconstruction(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はリンクを出るACKsを点検します、そして、ACK系列の大きい「ギャップ」を検出するなら、それは、より密接に、データ送付者が導入されなかったACK Filteringを持っているのを見たものに類似している承認流動を再建するために追加ACKsを生成します。 ARは2つのパラメタを必要とします。 1つのパラメタが必要なACK頻度です、秒はスペースを制御しますが、時間内に、連続した再建されたACKsのリリースの間で。
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]では、作者はスループットを増強するためにAFとARの組み合わせを示しています、変更されていないTCPとACC/SA変更の両方の上で研究されたネットワークで。 また、それらの結果は、混雑の損失が予想されるネットワークにおけるAFだけの使用が送付者のはち切れるため性能を減少させるのを(変更されていないTCPリノのレベルの下でさえ)強く示します。
AF delays acknowledgments from arriving at the receiver by dropping earlier ACKs in favor of later ACKs. This process can cause a slight hiccup in the transmission of new data by the TCP sender.
AFは、後のACKsを支持して以前のACKsを下げることによって受信機に到着するので、承認を遅らせます。 このプロセスはTCP送付者による新しいデータの伝達におけるわずかなしゃっくりを引き起こす場合があります。
3.10.3 Implementation Issues
3.10.3 導入問題
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 FilteringとACK Reconstructionの両方がルータ変更だけを必要とします。 しかしながら、ARの実装は出口ルータにおける、州の情報の何らかのストレージを必要とします。 AFは州の情報のストレージを必要としませんが、AR(または、SA)のない使用は望まれない副作用を発生させるかもしれません。 その上、より多くの研究がARで必要であるパラメタに適切な範囲に関して必要です。
Allman, et al. Informational [Page 35] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[35ページ]のRFC2760の進行中のTCP研究
3.10.4 Topology Considerations
3.10.4 トポロジー問題
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はすべてのtopologiesに適切に見えます、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 Filteringは共用回線網(混雑制御点からの)に使用するために安全です、ACKsの数(TCPをより攻撃的でなくする)が減少できるだけであるのに従って。 しかしながら、TCPが、より攻撃的でない間AFが引き起こす(上では、概説されています)遅れがそうでなければ、起こるだろうより大きい炸裂に通じることができることに注意してください。
3.10.5 Possible Interaction and Relationships with Other Research
3.10.5 可能な相互作用と他の研究との関係
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 Filteringは、ACK Congestion Controlと同じ問題を解決するのを試みます(セクション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.
さらに、どんなフォームの無線通信リンクも規格ワイヤが攻撃者が、ネットワークと中で難しく見つけている攻撃者がネットワークをモニターしているのを見ることができる相対的な容易さのためリンクを基礎づけたより盗聴セキュリティー攻撃に影響されやすいです。
Allman, et al. Informational [Page 36] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[36ページ]のRFC2760の進行中のTCP研究
6 Acknowledgments
6つの承認
Our thanks to Aaron Falk and Sally Floyd, who provided very helpful comments on drafts of this document.
アーロン・フォークとサリー・フロイドへの私たちの感謝。(フロイドは、このドキュメントの草稿の非常に役立っているコメントを提供しました)。
7 References
7つの参照箇所
[AFP98] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
Initial Window", RFC 2414, September 1998.
[AFP98] オールマンとM.とフロイドとS.とC.ヤマウズラ、「増加するTCPの初期の窓」、RFC2414、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]のオールマン、M.、手袋製造業者、D.、およびL.サンチェス、「衛星の上の高めるTCPは標準のメカニズムを使用することで精神を集中します」、BCP28、RFC2488、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パフォーマンスはリンクされます。 通信システムにおける第5国際会議の議事、1997年3月に。
[AHO98] Mark Allman, Chris Hayes, Shawn Ostermann. An Evaluation
of TCP with Larger Initial Windows. Computer Communication
Review, 28(3), July 1998.
[AHO98]はオールマン、クリス・ヘイズ、ショーン・オステルマンをマークします。 より大きい初期のWindowsとのTCPの評価。 コンピュータコミュニケーションレビュー、28(3)、1998年7月。
[AKO96] Mark Allman, Hans Kruse, Shawn Ostermann. An Application-
Level Solution to TCP's Satellite Inefficiencies. In
Proceedings of the First International Workshop on
Satellite-based Information Services (WOSBIS), November
1996.
[AKO96]はオールマン、ハンス・クルーゼ、ショーン・オステルマンをマークします。 TCPの衛星非能率のアプリケーションレベル解決。 国際労働者協会の議事では、衛星ベースの情報に関するワークショップは(WOSBIS)、1996年11月を修理します。
[All97a] Mark Allman. Improving TCP Performance Over Satellite
Channels. Master's thesis, Ohio University, June 1997.
[All97a]はオールマンをマークします。 衛星チャンネルの上のTCP性能を向上させます。 修士論文、オハイオ大学、1997年6月。
[All97b] Mark Allman. Fixing Two BSD TCP Bugs. Technical Report
CR-204151, NASA Lewis Research Center, October 1997.
[All97b]はオールマンをマークします。 2BSD 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)にマルチソケット拡張子を使用する衛星回路の上のデータ転送効率。 行為の議事に、コンファレンス、NASAルイス・リサーチセンター、1995年9月は結果として生じています。
[AP99] Mark Allman, Vern Paxson. On Estimating End-to-End Network
Path Properties. ACM SIGCOMM, September 1999.
[AP99]はオールマン、バーン・パクソンをマークします。 終わらせる終わりを見積もっていると、経路の特性をネットワークでつないでください。 1999年9月のACM SIGCOMM。
Allman, et al. Informational [Page 37] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[37ページ]のRFC2760の進行中のTCP研究
[APS99] Allman, M., Paxson, V. and W. Richard Stevens, "TCP
Congestion Control", RFC 2581, April 1999.
[APS99] オールマンとM.とパクソンとV.とW.リチャード・スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[BCC+98] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S.,
Wroclawski, J. and L. Zhang, "Recommendations on Queue
Management and Congestion Avoidance in the Internet", RFC
2309, April 1998.
[BCC+98] ブレーデンとB.とクラークとD.とクロウクロフトとJ.とデイビーとB.とデアリングとS.とEstrinとD.とフロイドとS.とジェーコブソンとV.とMinshallとG.とヤマウズラとC.とピーターソンとL.とRamakrishnanとK.、ShenkerとS.とWroclawskiとJ.とL.チャン、「インターネットの待ち行列管理と輻輳回避の推薦」RFC2309(1998年4月)。
[BKVP97] B. Bakshi and P. Krishna and N. Vaidya and D. Pradham,
"Improving Performance of TCP over Wireless Networks", 17th
International Conference on Distributed Computing Systems
(ICDCS), May 1997.
[BKVP97] B.バクシ、P.クリシュナ、N.Vaidya、およびD.Pradham(「ワイヤレス・ネットワークの上でTCPの性能を向上させます」、分散コンピューティングシステム(ICDCS)に関する第17国際会議)は1997がそうするかもしれません。
[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]ハーリBalakrishnan、Venkata N.Padmanabhan、およびランディ・H.キャッツ。 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] ハーリBalakrishnan、Venkata Padmanabhan、ランディ・H.キャッツ。 TCPパフォーマンスへの非対称の効果。 ACMのモバイルNetworksとApplications(モネ)、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、V.Padmanabhan、S.Sechan、およびR.キャッツ、「ワイヤレスの上のTCP性能を向上させるためのメカニズムの比較はリンクします」、ACM SIGCOMM、1996年8月。
[Bra89] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[Bra89]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[Bra92] Braden, R., "Transaction TCP -- Concepts", RFC 1379,
September 1992.
[Bra92]ブレーデン、R.、「トランザクションTCP--、概念、」、RFC1379、9月1992日
[Bra94] Braden, R., "T/TCP -- TCP Extensions for Transactions:
Functional Specification", RFC 1644, July 1994.
[Bra94]ブレーデン、R.、「T/TCP--トランザクションのためのTCP拡張子:、」 「機能的な仕様」、RFC1644、1994年7月。
[BRS99] Hari Balakrishnan, Hariharan Rahul, and Srinivasan Seshan.
An Integrated Congestion Management Architecture for
Internet Hosts. ACM SIGCOMM, September 1999.
[BRS99]ハーリのBalakrishnan、Hariharan Rahul、およびSrinivasan Seshan。 インターネットホストのための統合混雑管理体系。 1999年9月のACM SIGCOMM。
[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月。
Allman, et al. Informational [Page 38] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[38ページ]のRFC2760の進行中のTCP研究
[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] マイケル・デーゲルマルク、マティアスEngan、ビヨンNordgren、スティーブンPink。 ワイヤレス・ネットワークのための低い損失TCP/IPヘッダー圧縮。 Wireless Networks、vol.3、no.5、pのACM/Baltzer Journal。 375-87.
[DMT96] R. C. Durst and G. J. Miller and E. J. Travis, "TCP
Extensions for Space Communications", Mobicom 96, ACM, USA,
1996.
1996のC.がそうした[DMT96]R.とG.J.ミラーとE.J.トラヴィス、「スペースコミュニケーションズのためのTCP拡張子」、Mobicom96、ACM、米国
[DNP99] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[DNP99] デーゲルマルクとM.とNordgrenとB.とS.ピンク、「IPヘッダー圧縮」、RFC2507、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] ケビンFall、Sallyフロイド。 タホ、リノ、および袋のTCPのシミュレーションベースの比較。 コンピュータCommunication Review、V.26N.3、1996年7月、ページ 5-21.
[FF99] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End
Congestion Control in the Internet, IEEE/ACM Transactions
on Networking, August 1999.
[FF99]はフロイド、ケビンFallを出撃させます。 1999年8月にネットワークのときにインターネットでの終わりからエンドへの輻輳制御の使用、IEEE/ACM取引を促進します。
[FH99] Floyd, S. and T. Henderson, "The NewReno Modification to
TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[FH99] フロイドとS.とT.ヘンダーソン、「TCPの速い回復アルゴリズムへのNewReno変更」、RFC2582、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コンピュータコミュニケーションは1991年10月に21、N.5に対して再検討されます。
[Flo94] Sally Floyd. TCP and Explicit Congestion Notification, ACM
Computer Communication Review, V. 24 N. 5, October 1994.
[Flo94]はフロイドを出撃させます。 TCPと明白な混雑通知、ACMコンピュータコミュニケーションは1994年10月に24に対してN.5を見直します。
[Flo99] Sally Floyd. "Re: TCP and out-of-order delivery", email to
end2end-interest mailing list, February, 1999.
[Flo99]はフロイドを出撃させます。 「Re:」 「TCPと不適切な配送」はend2end-関心メーリングリスト、1999年2月までメールされます。
[Hah94] Jonathan Hahn. MFTP: Recent Enhancements and Performance
Measurements. Technical Report RND-94-006, NASA Ames
Research Center, June 1994.
[Hah94]ジョナサン・ハーン。 MFTP: 最近の増進とパフォーマンス測定。 技術報告書RND-94-006、米航空宇宙局エイムズ研究所、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 Globecom98年のコンファレンス、1998年の議事。
Allman, et al. Informational [Page 39] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[39ページ]のRFC2760の進行中のTCP研究
[HK99] Tim Henderson, Randy Katz. Transport Protocols for
Internet-Compatible Satellite Networks, IEEE Journal on
Selected Areas of Communications, February, 1999.
[HK99] ティム・ヘンダーソン、ランディ・キャッツ。 1999年2月にインターネットコンパチブル衛星ネットワーク、コミュニケーションの選択された領域に関するIEEEジャーナルのためにプロトコルを輸送してください。
[Hoe95] J. Hoe, Startup Dynamics of TCP's Congestion Control and
Avoidance Schemes. Master's Thesis, MIT, 1995.
[Hoe95] J. 鍬を入れてください、そして、TCPの混雑の始動力学は制御されて、回避は計画されます。 マスターの論文、MIT、1995。
[Hoe96] Janey Hoe. Improving the Startup Behavior of a Congestion
Control Scheme for TCP. In ACM SIGCOMM, August 1996.
[Hoe96]Janeyは鍬を入れます。 TCPの輻輳制御計画の始動の振舞いを改良します。 ACM SIGCOMM、1996年8月に。
[IL92] David Iannucci and John Lakashman. MFTP: Virtual TCP
Window Scaling Using Multiple Connections. Technical
Report RND-92-002, NASA Ames Research Center, January 1992.
[IL92] デヴィッドIannucciとジョンLakashman。 MFTP: 複数のコネクションズを使用することで比例する仮想のTCPの窓。 技術報告書RND-92-002、米航空宇宙局エイムズ研究所、1992年1月。
[Jac88] Van Jacobson. Congestion Avoidance and Control. In
Proceedings of the SIGCOMM '88, ACM. August, 1988.
[Jac88]はジェーコブソンをバンに積みます。 輻輳回避とコントロール。 SIGCOMM88年、ACMの議事で。 1988年8月。
[Jac90] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144,
February 1990.
1990年2月の[Jac90]ジェーコブソン対「TCP/IPヘッダーを圧縮すること」でのRFC1144
[JBB92] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992.
[JBB92]ジェーコブソン(V.、ブレーデン、R. and D.ボーマン、「高性能のためのTCP拡張子」、RFC1323)は1992がそうするかもしれません。
[JK92] Van Jacobson and Mike Karels. Congestion Avoidance and
Control. Originally appearing in the proceedings of
SIGCOMM '88 by Jacobson only, this revised version includes
an additional appendix. The revised version is available
at ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. 1992.
[JK92]はジェーコブソンとマイクKarelsをバンに積みます。 輻輳回避とコントロール。 元々ジェーコブソンだけによるSIGCOMM88年の議事に載っていて、この改訂版は追加付録を含んでいます。 改訂版は ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z . 1992で利用可能です。
[Joh95] Stacy Johnson. Increasing TCP Throughput by Using an
Extended Acknowledgment Interval. Master's Thesis, Ohio
University, June 1995.
[Joh95]ステーシー・ジョンソン。 延ばされた承認間隔を費やすことによって、TCPスループットを増加させます。 マスターの論文、オハイオ大学、1995年6月。
[KAGT98] Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran. HTTP
Page Transfer Rates Over Geo-Stationary Satellite Links.
March 1998. Proceedings of the Sixth International
Conference on Telecommunication Systems.
[KAGT98]ハンス・クルーゼ、オールマン、ジムGriner、Diepchiチャンをマークしてください。 HTTPページ転送は静止衛星中継の上で評価します。 1998年3月。 通信システムにおける第6国際会議の議事。
[Kes91] Srinivasan Keshav. A Control Theoretic Approach to Flow
Control. In ACM SIGCOMM, September 1991.
[Kes91]Srinivasan Keshav。 フロー制御へのコントロールの理論的なアプローチ。 ACM SIGCOMM、1991年9月に。
[KM97] S. Keshav, S. Morgan. SMART Retransmission: Performance
with Overload and Random Losses. Proceeding of Infocom.
1997.
[KM97] S.Keshav、S.モーガン。 賢いRetransmission: オーバーロードとのパフォーマンスと無作為の損失。 Infocomの進行。 1997.
Allman, et al. Informational [Page 40] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[40ページ]のRFC2760の進行中のTCP研究
[KVR98] Lampros Kalampoukas, Anujan Varma, and K. K.Ramakrishnan.
Improving TCP Throughput Over Two-Way Asymmetric Links:
Analysis and Solutions. Measurement and Modeling of
Computer Systems, 1998, Pages 78-89.
[KVR98]Lampros Kalampoukas、Anujanバルマー、およびK.K.Ramakrishnan。 ツーウェイの上で非対称のTCPスループットを改良するのはリンクされます: 分析と解答。 コンピュータ・システム、1998、78-89ページの測定とモデル。
[MM96a] M. Mathis, J. Mahdavi, "Forward Acknowledgment: Refining
TCP Congestion Control," Proceedings of SIGCOMM'96, August,
1996, Stanford, CA. Available from
http://www.psc.edu/networking/papers/papers.html
[MM96a] M.マシス、J.Mahdavi、「承認を進めてください」 「TCP輻輳制御を洗練します」、SIGCOMM96年、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.マシス、J.Mahdavi、 http://www.psc.edu/networking/papers/FACKnotes/current から利用可能な「TCPバウンドするレート半分にパラメタ。」
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[MMFR96] マシスとM.とMahdaviとJ.とフロイドとS.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、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.Semke、J.Mahdavi、T.オット、「TCP輻輳回避アルゴリズムの巨視的行動」、コンピュータCommunication Review、第27巻、number3(1997年7月)。 http://www.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.メータと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]キャサリーン・ニコルズ。 フィードバックとのネットワーク・シミュレーションを改良します。 Com21Inc.技術報告書。 http://www.com21.com/pages/papers/068.pdf から、利用可能です。
[PADHV99] Paxson, V., Allman, M., Dawson, S., Heavens, I. and B.
Volz, "Known TCP Implementation Problems", RFC 2525, March
1999.
[PADHV99] パクソンとV.とオールマンとM.とドーソンとS.と天とI.とB.フォルツ、「知られているTCP実現問題」、RFC2525、1999年3月。
[Pax97] Vern Paxson. Automated Packet Trace Analysis of TCP
Implementations. In Proceedings of ACM SIGCOMM, September
1997.
[Pax97]バーン・パクソン。 TCP実現の自動化されたパケット微量成分分析。 ACM SIGCOMM、1997年9月の議事で。
[PN98] Poduri, K. and K. Nichols, "Simulation Studies of Increased
Initial TCP Window Size", RFC 2415, September 1998.
[PN98] PoduriとK.とK.ニコルズ、「増加する初期のTCPウィンドウサイズのシミュレーション研究」、RFC2415、1998年9月。
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[Pos81] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
Allman, et al. Informational [Page 41] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[41ページ]のRFC2760の進行中のTCP研究
[RF99] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481, January
1999.
1999年1月の[RF99]RamakrishnanとK.S.フロイド、「Explicit Congestion Notification(電子証券取引ネットワーク)をIPに追加するProposal」RFC2481。
[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、「Wireless CommunicationのためのTCP誤りRecoveryの補強」、コンピュータCommunication Review、第28巻、No.2、1998年4月。
[SP98] Shepard, T. and C. Partridge, "When TCP Starts Up With Four
Packets Into Only Three Buffers", RFC 2416, September 1998.
[SP98]シェパード、T.とC.ヤマウズラ、「いつTCPは4つのパケットと共に3つのバッファだけに始動する」RFC2416(1998年9月)。
[Ste97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001,
January 1997.
[Ste97] スティーブンスと、W.と、「遅れた出発、輻輳回避が速く再送するTCP、および速い回復アルゴリズム」、RFC2001、1月1997日
[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.チョウドリ。 1流れあたりの待ち行列でTCPを支持するように問題を設計してください。 IEEE Infocom98年のコンファレンス、1998年の議事。
[Tou97] Touch, J., "TCP Control Block Interdependence", RFC 2140,
April 1997.
[Tou97] 接触、J.、「TCP制御ブロック相互依存」、RFC2140、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とジョン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とジョンHeidemann。 レートベースのペースSource Code Distribution、ウェブページ: 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とジョンHeidemann。 活動していないTCPコネクションズ(改訂される)の再開を改良します。 公表のために、提出します。
Allman, et al. Informational [Page 42] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[42ページ]のRFC2760の進行中のTCP研究
8 Authors' Addresses
8人の作者のアドレス
Mark Allman NASA Glenn Research Center/BBN Technologies Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
オールマンNASAグレンリサーチセンタ/BBN技術がルイス分野21000Brookpark通りであるとマークしてください。 MS54-2クリーブランド、OH 44135
EMail: mallman@grc.nasa.gov http://roland.grc.nasa.gov/~mallman
メール: mallman@grc.nasa.gov http://roland.grc.nasa.gov/~mallman
Spencer Dawkins Nortel P.O.Box 833805 Richardson, TX 75083-3805
スペンサーダウキンズノーテルP.O.Box833805リチャードソン、テキサス75083-3805
EMail: Spencer.Dawkins.sdawkins@nt.com
メール: Spencer.Dawkins.sdawkins@nt.com
Dan Glover NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 3-6 Cleveland, OH 44135
ダン手袋製造業者NASAグレンリサーチセンタルイス分野21000Brookpark通り MS3-6クリーブランド、OH 44135
EMail: Daniel.R.Glover@grc.nasa.gov http://roland.grc.nasa.gov/~dglover
メール: Daniel.R.Glover@grc.nasa.gov http://roland.grc.nasa.gov/~dglover
Jim Griner NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
ジムGriner NASAグレンリサーチセンタルイス分野21000Brookpark通り MS54-2クリーブランド、OH 44135
EMail: jgriner@grc.nasa.gov http://roland.grc.nasa.gov/~jgriner
メール: jgriner@grc.nasa.gov http://roland.grc.nasa.gov/~jgriner
Diepchi Tran NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
DiepchiチャンNASAグレンリサーチセンタルイス分野21000Brookpark通り MS54-2クリーブランド、OH 44135
EMail: dtran@grc.nasa.gov
メール: dtran@grc.nasa.gov
Allman, et al. Informational [Page 43] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[43ページ]のRFC2760の進行中のTCP研究
Tom Henderson University of California at Berkeley Phone: +1 (510) 642-8919
トムヘンダーソンカリフォルニア大学バークレイ校Phone: +1 (510) 642-8919
EMail: tomh@cs.berkeley.edu URL: http://www.cs.berkeley.edu/~tomh/
メール: tomh@cs.berkeley.edu URL: http://www.cs.berkeley.edu/~tomh/
John Heidemann University of Southern California/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695
ジョンHeidemann南カリフォルニア大学/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695
EMail: johnh@isi.edu
メール: johnh@isi.edu
Joe Touch University of Southern California/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6601 USA
ジョーTouch南カリフォルニア大学/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6601米国
Phone: +1 310-448-9151 Fax: +1 310-823-6714 URL: http://www.isi.edu/touch EMail: touch@isi.edu
以下に電話をしてください。 +1 310-448-9151Fax: +1 310-823-6714URL: http://www.isi.edu/touch メール: touch@isi.edu
Hans Kruse J. Warren McClure School of Communication Systems Management Ohio University 9 S. College Street Athens, OH 45701
9秒間ハンスクルーゼJ.ウォレンマクルーアコミュニケーションシステム管理学校オハイオ大学大学通りアテネ、OH 45701
Phone: 740-593-4891 Fax: 740-593-4889 EMail: hkruse1@ohiou.edu http://www.csm.ohiou.edu/kruse
以下に電話をしてください。 740-593-4891 Fax: 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
電気工学のショーンオステルマン学校とHallアテネ、コンピュータサイエンスオハイオ大学416モートンOH 45701
Phone: (740) 593-1234 EMail: ostermann@cs.ohiou.edu
以下に電話をしてください。 (740) 593-1234 メールしてください: ostermann@cs.ohiou.edu
Allman, et al. Informational [Page 44] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[44ページ]のRFC2760の進行中のTCP研究
Keith Scott The MITRE Corporation M/S W650 1820 Dolley Madison Blvd. McLean VA 22102-3481
キース・スコット斜め継ぎ社のM/S W650 1820DolleyマディソンBlvd. マクリーン・ヴァージニア22102-3481
EMail: kscott@mitre.org
メール: kscott@mitre.org
Jeffrey Semke Pittsburgh Supercomputing Center 4400 Fifth Ave. Pittsburgh, PA 15213
ジェフリーSemkeピッツバーグSupercomputingは4400黙秘権Aveを中心に置きます。 ピッツバーグ、PA 15213
EMail: semke@psc.edu http://www.psc.edu/~semke
メール: semke@psc.edu http://www.psc.edu/~semke
Allman, et al. Informational [Page 45] RFC 2760 Ongoing TCP Research Related to Satellites February 2000
オールマン、他 衛星2000年2月に関連した情報[45ページ]のRFC2760の進行中のTCP研究
9 Full Copyright Statement
9 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Allman, et al. Informational [Page 46]
オールマン、他 情報[46ページ]
一覧
スポンサーリンク
