RFC1106 日本語訳
1106 TCP big window and NAK options. R. Fox. June 1989. (Format: TXT=37105 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Fox
Request for Comments: 1106 Tandem
June 1989
コメントを求めるワーキンググループR.フォックスの要求をネットワークでつないでください: 1106 2人乗り自転車1989年6月
TCP Big Window and Nak Options
TCPの大きい窓とNakオプション
Status of this Memo
このMemoの状態
This memo discusses two extensions to the TCP protocol to provide a more efficient operation over a network with a high bandwidth*delay product. The extensions described in this document have been implemented and shown to work using resources at NASA. This memo describes an Experimental Protocol, these extensions are not proposed as an Internet standard, but as a starting point for further research. Distribution of this memo is unlimited.
このメモは、高帯域*遅れ製品で、より効率的な操作をネットワークの上に提供するために2つの拡大についてTCPプロトコルと議論します。 本書では説明された拡大は、NASAでリソースを使用することで働くために実装されて、示されました。 このメモがExperimentalプロトコルについて説明して、これらの拡大はインターネット標準として提案されるのではなく、さらなる調査のための出発点として提案されます。 このメモの分配は無制限です。
Abstract
要約
Two extensions to the TCP protocol are described in this RFC in order to provide a more efficient operation over a network with a high bandwidth*delay product. The main issue that still needs to be solved is congestion versus noise. This issue is touched on in this memo, but further research is still needed on the applicability of the extensions in the Internet as a whole infrastructure and not just high bandwidth*delay product networks. Even with this outstanding issue, this document does describe the use of these options in the isolated satellite network environment to help facilitate more efficient use of this special medium to help off load bulk data transfers from links needed for interactive use.
2つの拡大が、高帯域*遅れ製品で、より効率的な操作をネットワークの上に提供するためにこのRFCにTCPプロトコルに説明されます。 まだ解決される必要がある本題は混雑対雑音です。 この問題はこのメモで触れられますが、さらなる研究が高帯域*遅れ製品ネットワークだけではなく、全体のインフラストラクチャとしてインターネットで拡大の適用性でまだ必要です。 この未解決の問題があっても、このドキュメントは、リンクからのバルク・データ転送が対話的な使用に必要とした負荷に離れるのを手伝うためにこの特別な媒体の、より効率的な使用を容易にするのを助けるために孤立している衛星ネットワーク環境におけるこれらのオプションの使用について説明します。
1. Introduction
1. 序論
Recent work on TCP has shown great performance gains over a variety of network paths [1]. However, these changes still do not work well over network paths that have a large round trip delay (satellite with a 600 ms round trip delay) or a very large bandwidth (transcontinental DS3 line). These two networks exhibit a higher bandwidth*delay product, over 10**6 bits, than the 10**5 bits that TCP is currently limited to. This high bandwidth*delay product refers to the amount of data that may be unacknowledged so that all of the networks bandwidth is being utilized by TCP. This may also be referred to as "filling the pipe" [2] so that the sender of data can always put data onto the network and the receiver will always have something to read, and neither end of the connection will be forced to wait for the other end.
TCPの上の近作は、かなりの性能がさまざまなネットワーク経路[1]を手懐けるのを示しました。 しかしながら、これらの変化は大きい周遊旅行遅れ(600ms周遊旅行遅れがある衛星)か非常に大きい帯域幅を持っているネットワーク経路の上でまだうまくいっていません(大陸横断のDS3は立ち並んでいます)。 これらの2つのネットワークが10**の上により高い帯域幅*遅れ製品を6ビット示します、TCPが現在制限される10**5ビットより。 この高帯域*遅れ製品が認められないかもしれないデータ量について言及するので、ネットワーク帯域幅のすべてがTCPによって利用されています。 また、これは[2] データの送付者がいつもデータを置くことができるためのネットワークへの「パイプをいっぱいにしています」と呼ばれるかもしれません、そして、受信機には、読むことがいつもあるでしょう、そして、接続のどちらの終わりももう一方の端の間、やむを得ず待たないでしょう。
After the last batch of algorithm improvements to TCP, performance
TCP、性能へのアルゴリズム改良の最後のバッチの後に
Fox [Page 1] RFC 1106 TCP Big Window and Nak Options June 1989
フォックス[1ページ]RFC1106のTCPの大きい窓とNakオプション1989年6月
over high bandwidth*delay networks is still very poor. It appears that no algorithm changes alone will make any significant improvements over high bandwidth*delay networks, but will require an extension to the protocol itself. This RFC discusses two possible options to TCP for this purpose.
高帯域の上では、遅れがネットワークでつなぐ*はまだ非常に貧しいです。 アルゴリズム変化だけが高帯域*遅れネットワークの上でどんなかなりの改善もしますが、プロトコル自体に拡大を必要としないように見えます。 このRFCはこのために2つの可能なオプションについてTCPと議論します。
The two options implemented and discussed in this RFC are:
このRFCで実装されて、議論した2つのオプションは以下の通りです。
1. NAKs
1. NAKs
This extension allows the receiver of data to inform the sender
that a packet of data was not received and needs to be resent.
This option proves to be useful over any network path (both high
and low bandwidth*delay type networks) that experiences periodic
errors such as lost packets, noisy links, or dropped packets due
to congestion. The information conveyed by this option is
advisory and if ignored, does not have any effect on TCP what so
ever.
この拡大で、データの受信機は、データのパケットが、受け取られないで、再送される必要を送付者に知らせることができます。 このオプションは混雑のため無くなっているパケット、騒がしいリンク、または下げられたパケットなどの周期誤差になるどんなネットワーク経路(高いものと同様に低い帯域幅*遅れはネットワークをタイプする)にわたっても役に立つと判明します。 そして、このオプションで伝えられた情報が顧問である、無視されて、したがって、いずれもTCPでことに作用させません。
2. Big Windows
2. 大きいWindows
This option will give a method of expanding the current 16 bit (64
Kbytes) TCP window to 32 bits of which 30 bits (over 1 gigabytes)
are allowed for the receive window. (The maximum window size
allowed in TCP due to the requirement of TCP to detect old data
versus new data. For a good explanation please see [2].) No
changes are required to the standard TCP header [6]. The 16 bit
field in the TCP header that is used to convey the receive window
will remain unchanged. The 32 bit receive window is achieved
through the use of an option that contains the upper half of the
window. It is this option that is necessary to fill large data
pipes such as a satellite link.
このオプションが現在の16ビット(64キロバイト)のTCPの窓を30ビット(1以上ギガバイト)が考慮される32ビットに広げるメソッドを与える、窓を受けてください。 (TCPが新しいデータに対して古いデータを検出するという要件のためTCPに許容された最大のウィンドウサイズ。 良い説明に関しては、[2]を見てください。) 変化は全く標準のTCPヘッダー[6]に必要ではありません。 運ぶのにおいて使用されたTCPヘッダーの16ビットの分野、変わりがない状態で窓の意志の残りを受け取ってください。 32ビットは窓を受けます。窓の上半分を含むオプションの使用で、実現されます。 衛星中継などの大きいデータパイプをいっぱいにするのは、この必要なオプションです。
This RFC is broken up into the following sections: section 2 will discuss the operation of the NAK option in greater detail, section 3 will discuss the big window option in greater detail. Section 4 will discuss other effects of the big windows and nak feature when used together. Included in this section will be a brief discussion on the effects of congestion versus noise to TCP and possible options for satellite networks. Section 5 will be a conclusion with some hints as to what future development may be done at NASA, and then an appendix containing some test results is included.
このRFCは以下のセクションに壊れます: セクション2は、よりすばらしい詳細における、NAKオプションの操作について論じて、セクション3は詳細によりすばらしい大きい窓のオプションについて論ずるでしょう。 一緒に使用されると、セクション4は大きい窓とnakの特徴の他の効果について検討するでしょう。 このセクションに含まれているのは、混雑対TCPへの雑音と衛星ネットワークに、可能なオプションの効果が簡潔な議論でしょう。 セクション5はNASAでどんな今後の開発をするかもしれないかに関するいくつかのヒントで結論になるでしょう、そして、次に、いくつかの試験の成績を含む付録は含まれています。
2. NAK Option
2. NAKオプション
Any packet loss in a high bandwidth*delay network will have a catastrophic effect on throughput because of the simple acknowledgement of TCP. TCP always acks the stream of data that has
高帯域*遅れネットワークのどんなパケット損失もTCPの簡単な承認のために壊滅的な影響をスループットに与えるでしょう。 TCPはいつもそれが持っているデータのストリームをacksします。
Fox [Page 2] RFC 1106 TCP Big Window and Nak Options June 1989
フォックス[2ページ]RFC1106のTCPの大きい窓とNakオプション1989年6月
successfully been received and tells the sender the next byte of data of the stream that is expected. If a packet is lost and succeeding packets arrive the current protocol has no way of telling the sender that it missed one packet but received following packets. TCP currently resends all of the data over again, after a timeout or the sender suspects a lost packet due to a duplicate ack algorithm [1], until the receiver receives the lost packet and can then ack the lost packet as well as succeeding packets received. On a normal low bandwidth*delay network this effect is minimal if the timeout period is set short enough. However, on a long delay network such as a T1 satellite channel this is catastrophic because by the time the lost packet can be sent and the ack returned the TCP window would have been exhausted and both the sender and receiver would be temporarily stalled waiting for the packet and ack to fully travel the data pipe. This causes the pipe to become empty and requires the sender to refill the pipe after the ack is received. This will cause a minimum of 3*X bandwidth loss, where X is the one way delay of the medium and may be much higher depending on the size of the timeout period and bandwidth*delay product. Its 1X for the packet to be resent, 1X for the ack to be received and 1X for the next packet being sent to reach the destination. This calculation assumes that the window size is much smaller than the pipe size (window = 1/2 data pipe or 1X), which is the typical case with the current TCP window limitation over long delay networks such as a T1 satellite link.
首尾よく受け取られて、予想されるストリームに関するデータの次のバイトを送付者に言います。 パケットが無くなって、続くパケットが到着するなら、現在のプロトコルには、1つのパケットを逃しましたが、次のパケットを受けたと送付者に言う方法が全くありません。 TCPは現在再び上にデータのすべてを再送します、無くなっているパケットを受けて、受信機は次にパケットを引き継ぐことと同様に無くなっているパケットが受けたackを受けることができてタイムアウトか送付者が写しackアルゴリズム[1]のため無くなっているパケットを疑った後に。 正常な低い帯域幅*遅れネットワークでは、タイムアウト時間が十分急に決められるなら、この効果は最小限です。 無くなっているパケットを送ることができて、ackが戻る時までにTCPの窓は消耗したでしょう、そして、パケットとackがデータパイプを完全に旅行するのを待ちながら、送付者と受信機の両方は一時止まるでしょう、しかしながら、T1衛星チャンネルなどの長時間の遅延ネットワークでは、したがって、これが壊滅的です。 これは、パイプが空になることを引き起こして、ackが受け取られていた後に送付者がパイプを詰め替えるのを必要とします。 これが、最低3*X帯域幅損失をもたらすでしょう、タイムアウト時間と帯域幅*遅れ製品のサイズによって、Xが媒体の一方通行の遅れであり、はるかに高いかもしれないところで。 次のパケットのための目的地に達するように送られる再送されるパケットのための1X、ackが受け取られる1X、および1X。 この計算は、ウィンドウサイズがパイプサイズ(窓は1/2のデータパイプか1Xと等しい)よりはるかに小さいと仮定します。(サイズはT1衛星中継などの長時間の遅延ネットワークの上に現在のTCP窓の制限がある典型的なケースです)。
An attempt to reduce this wasted bandwidth from 3*X was introduced in [1] by having the sender resend a packet after it notices that a number of consecutively received acks completely acknowledges already acknowledged data. On a typical network this will reduce the lost bandwidth to almost nil, since the packet will be resent before the TCP window is exhausted and with the data pipe being much smaller than the TCP window, the data pipe will not become empty and no bandwidth will be lost. On a high delay network the reduction of lost bandwidth is minimal such that lost bandwidth is still significant. On a very noisy satellite, for instance, the lost bandwidth is very high (see appendix for some performance figures) and performance is very poor.
多くの連続して受け取られたacksが既に承認されたデータを完全に承認するのに気付いた後に送付者にパケットを再送させることによって、[1]で3*Xからのこの無駄な帯域幅を減少させる試みを導入しました。 典型的なネットワークでは、これはほとんど無いことへの無くなっている帯域幅を減少させるでしょう、TCPの窓が消耗している前にパケットを再送して、データパイプがTCPの窓よりはるかに小さい状態で、データパイプが空にならないで、また帯域幅を全く失わないので。 高い遅れネットワークでは、無くなっている帯域幅の減少が最小限ので、無くなっている帯域幅はまだ重要です。 例えば、非常に騒がしい衛星の上では、無くなっている帯域幅は非常に高いです、そして、(何らかの性能のための付録が計算されるのを確実にしてください)性能は非常に不十分です。
There are two methods of informing the sender of lost data. Selective acknowledgements and NAKS. Selective acknowledgements have been the object of research in a number of experimental protocols including VMTP [3], NETBLT [4], and SatFTP [5]. The idea behind selective acks is that the receiver tells the sender which pieces it received so that the sender can resend the data not acked but already sent once. NAKs on the other hand, tell the sender that a particular packet of data needs to be resent.
ロストデータについて送付者に知らせる2つのメソッドがあります。 選択している承認とNAKS。 選択している承認はVMTP[3]、NETBLT[4]、およびSatFTP[5]を含む多くの実験プロトコルにおける研究の目的です。 選択しているacksの後ろの考えは送付者がackedされませんでしたが、一度既に送られたデータを再送できるように受信機が、それがどの断片を受けたかを送付者に言うということです。 NAKs、他方では、データの特定のパケットが、再送される必要であると送付者に言ってください。
There are a couple of disadvantages of selective acks. Namely, in
選択しているacksの2、3の難点があります。 すなわち中
Fox [Page 3] RFC 1106 TCP Big Window and Nak Options June 1989
フォックス[3ページ]RFC1106のTCPの大きい窓とNakオプション1989年6月
some of the protocols mentioned above, the receiver waits a certain time before sending the selective ack so that acks may be bundled up. This delay can cause some wasted bandwidth and requires more complex state information than the simple nak. Even if the receiver doesn't bundle up the selective acks but sends them as it notices that packets have been lost, more complex state information is needed to determine which packets have been acked and which packets need to be resent. With naks, only the immediate data needed to move the left edge of the window is naked, thus almost completely eliminating all state information.
上に言及されたプロトコルのいくつか、acksを包むことができるように選択しているackを送る前に、受信機はある時間を待ちます。 この遅れは、いくらかの無駄な帯域幅を引き起こす場合があって、簡単なnakより複雑な州の情報を必要とします。 受信機が選択しているacksを包みませんが、パケットが失われたのに気付くようにそれらを送っても、より複雑な州の情報が、どのパケットがackedされるか、そして、どのパケットが、再送される必要であるかを決定するのに必要です。 naksと共に、窓の左の縁を動かすのに必要である即値データだけが裸です、その結果、すべての州の情報をほぼ完全に排除します。
The selective ack has one advantage over naks. If the link is very noisy and packets are being lost close together, then the sender will find out about all of the missing data at once and can send all of the missing data out immediately in an attempt to move the left window edge in the acknowledge number of the TCP header, thus keeping the data pipe flowing. Whereas with naks, the sender will be notified of lost packets one at a time and this will cause the sender to process extra packets compared to selective acks. However, empirical studies has shown that most lost packets occur far enough apart that the advantage of selective acks over naks is rarely seen. Also, if naks are sent out as soon as a packet has been determined lost, then the advantage of selective acks becomes no more than possibly a more aesthetic algorithm for handling lost data, but offers no gains over naks as described in this paper. It is this reason that the simplicity of naks was chosen over selective acks for the current implementation.
選択しているackには、naksより1つの利点があります。 リンクが非常に騒がしく、パケットが近くで一緒に失われているなら、送付者は、すぐに、欠測値のすべてを見つけて、流れた状態でTCPヘッダーの数を承認して、その結果、保つことにおけるデータが運ぶ左の窓の縁を動かすすぐ試みで欠測値のすべてを出すことができます。 naksで、送付者は一度に一つ無くなっているパケットについて通知されるでしょう、そして、選択しているacksと比べて、送付者はこれで付加的なパケットを処理するでしょうが。 しかしながら、実証的研究は、ほとんどの無くなっているパケットが十分遠くに離れて起こるのでnaksの上の選択しているacksの利点がめったに見られないのを示しました。 また、パケットが無くなった状態で断固としているとすぐに、naksを出すなら、選択しているacksの利点は、ロストデータを扱うためにことによるとだけより美的なアルゴリズムになりますが、この紙で説明されるように利益を全くnaksに保証しません。 それはnaksの簡単さが現在の実装のための選択しているacksの上で選ばれたこの理由です。
2.1 Implementation details
2.1 実装の詳細
When the receiver of data notices a gap between the expected sequence number and the actual sequence number of the packet received, the receiver can assume that the data between the two sequence numbers is either going to arrive late or is lost forever. Since the receiver can not distinguish between the two events a nak should be sent in the TCP option field. Naking a packet still destined to arrive has the effect of causing the sender to resend the packet, wasting one packets worth of bandwidth. Since this event is fairly rare, the lost bandwidth is insignificant as compared to that of not sending a nak when the packet is not going to arrive. The option will take the form as follows:
予想された一連番号とパケットの実際の一連番号のギャップが受け取ったデータ通知の受信機であるときに、受信機は、2つの一連番号の間のデータが遅く、到着するか、またはいつまでも失われていると仮定できます。受信機が2つのイベントを見分けることができないので、TCPオプション・フィールドでnakを送るべきです。 到着するようにまだ運命づけられていたパケットをNakingするのにおいて、送付者がパケットを再送することを引き起こすという効果があって、むだになっている1つのパケットが帯域幅の価値です。 このイベントがかなりまれであるので、パケットが到着しないときnakを送らないものと比べて、無くなっている帯域幅はわずかです。 オプションは以下の形を取るでしょう:
+========+=========+=========================+================+
+option= + length= + sequence number of + number of +
+ A + 7 + first byte being naked + segments naked +
+========+=========+=========================+================+
+========+=========+=========================+================+ + 裸の+が裸の++を区分するということである+ + + A+7+最初のバイトの数のオプションの=+長さ=+一連番号========+=========+=========================+================+
This option contains the first sequence number not received and a
このオプションは受け取られなかった最初の一連番号とaを含んでいます。
Fox [Page 4] RFC 1106 TCP Big Window and Nak Options June 1989
フォックス[4ページ]RFC1106のTCPの大きい窓とNakオプション1989年6月
count of how many segments of bytes needed to be resent, where segments is the size of the current TCP MSS being used for the connection. Since a nak is an advisory piece of information, the sending of a nak is unreliable and no means for retransmitting a nak is provided at this time.
バイトのいくつのセグメントのカウントは、再送される必要があったか、セグメントが接続に使用される現在のTCP MSSのサイズであるところで。 nakが顧問情報であるので、nakの発信は頼り無いです、そして、このとき、nakを再送するための手段を全く提供しません。
When the sender of data receives the option it may either choose to do nothing or it will resend the missing data immediately and then continue sending data where it left off before receiving the nak. The receiver will keep track of the last nak sent so that it will not repeat the same nak. If it were to repeat the same nak the protocol could get into the mode where on every reception of data the receiver would nak the first missing data frame. Since the data pipe may be very large by the time the first nak is read and responded to by the sender, many naks would have been sent by the receiver. Since the sender does not know that the naks are repetitious it will resend the data each time, thus wasting the network bandwidth with useless retransmissions of the same piece of data. Having an unreliable nak may result in a nak being damaged and not being received by the sender, and in this case, we will let the tcp recover by its normal means. Empirical data has shown that the likelihood of the nak being lost is quite small and thus, this advisory nak option works quite well.
データの送付者がオプションを受け取るとき、何もしないのを選ぶかもしれないか、nakを受ける前に、それは、すぐに、欠測値を再送して、次に、それがやめられたデータを送り続けるでしょう。 受信機はそれが同じnakを繰り返さないように送られた最後のnakの動向をおさえるでしょう。 プロトコルがモードに手に入れることができた同じ反復nakにそれがデータのあらゆるレセプションであるなら、受信機は最初の欠測値が縁どるnakがそうするでしょうに。 送付者が最初のnakに読み込まれて、応じる時までにデータパイプが非常に大きいかもしれないので、受信機は多くのnaksを送ったでしょう。送付者が、naksが反復性であることを知らないので、その都度データを再送するでしょう、その結果、同じデータの役に立たない「再-トランスミッション」でネットワーク回線容量を浪費します。 頼り無いnakを持っていると、破損して、送付者によって受け取られないnakはもたらされるかもしれません、そして、この場合、私たちは正常な手段でtcpを回収するつもりです。 実験によって得られるデータはなくされているnakの見込みがかなり小さく、その結果、この顧問nakオプションがかなりうまくいくのを示しました。
3. Big Window Option
3. 大きい窓のオプション
Currently TCP has a 16 bit window limitation built into the protocol. This limits the amount of outstanding unacknowledged data to 64 Kbytes. We have already seen that some networks have a pipe larger than 64 Kbytes. A T1 satellite channel and a cross country DS3 network with a 30ms delay have data pipes much larger than 64 Kbytes. Thus, even on a perfectly conditioned link with no bandwidth wasted due to errors, the data pipe will not be filled and bandwidth will be wasted. What is needed is the ability to send more unacknowledged data. This is achieved by having bigger windows, bigger than the current limitation of 16 bits. This option to expands the window size to 30 bits or over 1 gigabytes by literally expanding the window size mechanism currently used by TCP. The added option contains the upper 15 bits of the window while the lower 16 bits will continue to go where they normally go [6] in the TCP header.
現在の、TCPはプロトコルを16ビットの窓の制限に組み込ませます。 これは傑出している不承認のデータの量を64キロバイトに制限します。 私たちは、いくつかのネットワークがパイプを64キロバイトより大きくするのを既に見ました。 T1衛星チャンネルと30ms遅れがあるクロスカントリーのDS3ネットワークはデータパイプを64キロバイトよりはるかに大きくします。 誤りのため浪費された帯域幅のない完全に条件としたリンクの上にさえ、データパイプはいっぱいにされないでしょう、そして、帯域幅は浪費されるでしょう。 必要であるものは、より不承認のデータを送る能力です。 これは、16ビットの現在の限界より大きいさらに大きい窓を持っていることによって、達成されます。 30ビットにウィンドウサイズを広げるか、または1ギガバイトの上に文字通り広がることへのウィンドウサイズメカニズムが現在TCPで使用したこのオプション。 低級16ビットは、通常、それらが[6]に入るところに行き続けるでしょうが、加えられたオプションは上側の15ビットの窓を含んでいます。TCPヘッダー。
A TCP session will use the big window options only if both sides agree to use them, otherwise the option is not used and the normal 16 bit windows will be used. Once the 2 sides agree to use the big windows then every packet thereafter will be expected to contain the window option with the current upper 15 bits of the window. The negotiation to decide whether or not to use the bigger windows takes place during the SYN and SYN ACK segments of the TCP connection
両側が、それらを使用するのに同意する場合にだけ、TCPセッションは大きい窓のオプションを使用するでしょう、そして、さもなければ、オプションは使用されていません、そして、16ビットの正常な窓は使用されるでしょう。 一度、2つの側が、大きい窓を使用するのに同意して、次に、その後、あらゆるパケットが窓の現在の上側の15ビットによる窓のオプションを含むと予想されるでしょう。 より大きい窓を使用するかどうか決める交渉はTCP接続のSYNとSYN ACKセグメントの間、行われます。
Fox [Page 5] RFC 1106 TCP Big Window and Nak Options June 1989
フォックス[5ページ]RFC1106のTCPの大きい窓とNakオプション1989年6月
startup process. The originator of the connection will include in the SYN segment the following option:
始動プロセス。 接続の創始者はSYNセグメントで以下のオプションを入れるでしょう:
1 byte 1 byte 4 bytes
+=========+==========+===============+
+option=B + length=6 + 30 bit window +
+=========+==========+===============+
1バイト1バイト4バイト+=========+==========+===============6+30+ + オプション=B+長さ=ビット窓++=========+==========+===============+
If the other end of the connection wants to use big windows it will include the same option back in the SYN ACK segment that it must send. At this point, both sides have agreed to use big windows and the specified windows will be used. It should be noted that the SYN and SYN ACK segments will use the small windows, and once the big window option has been negotiated then the bigger windows will be used.
大きい窓を使用する接続必需品のもう一方の端であるなら、それは送らなければならないSYN ACKセグメントで同じオプションを含むでしょう。 ここに、両側は、大きい窓を使用するのに同意しました、そして、指定された窓は使用されるでしょう。 SYNとSYN ACKセグメントが小さい窓を使用することに注意されるべきであり、大きい窓のオプションがその時いったん交渉されると、より大きい窓は使用されるでしょう。
Once both sides have agreed to use 32 bit windows the protocol will function just as it did before with no difference in operation, even in the event of lost packets. This claim holds true since the rcv_wnd and snd_wnd variables of tcp contain the 16 bit windows until the big window option is negotiated and then they are replaced with the appropriate 32 bit values. Thus, the use of big windows becomes part of the state information kept by TCP.
両側が、32ビットの窓を使用するのにいったん同意すると、ちょうど以前稼働中である違いを全く処理しなかったようにプロトコルは機能するでしょう、無くなっているパケットの場合さえ。 tcpのrcv_wndとsnd_wnd変数が大きい窓のオプションを交渉して、次に、それらを32ビットの適切な値に取り替えるまで16ビットの窓を含んでいるので、このクレームは有効です。 したがって、大きい窓の使用はTCPによって保たれた州の情報の一部になります。
Other methods of expanding the windows have been presented, including a window multiple [2] or streaming [5], but this solution is more elegant in the sense that it is a true extension of the window that one day may easily become part of the protocol and not just be an option to the protocol.
窓の倍数[2]を含んでいるか、または[5]を流して、窓を広げる他のメソッドは提示されましたが、それがある日容易にプロトコルの一部になって、単にオプションでないかもしれない窓の本当の拡大であるという意味でこのソリューションはプロトコルにより上品です。
3.1 How does it work
3.1に、それはどのように働いていますか?
Once a connection has decided to use big windows every succeeding packet must contain the following option:
接続が、大きい窓を使用するといったん決めると、続くあらゆるパケットが以下のオプションを含まなければなりません:
+=========+==========+==========================+
+option=C + length=4 + upper 15 bits of rcv_wnd +
+=========+==========+==========================+
+=========+==========+==========================rcv_wnd++のC+長さの=4+上側の15+ + オプション=ビット=========+==========+==========================+
With all segments sent, the sender supplies the size of its receive window. If the connection is only using 16 bits then this option is not supplied, otherwise the lower 16 bits of the receive window go into the tcp header where it currently resides [6] and the upper 15 bits of the window is put into the data portion of the option C. When the receiver processes the packet it must first reform the window and then process the packet as it would in the absence of the option.
すべてのセグメントを送って、送付者がサイズを供給する、それ、窓を受けてください。 それが現在窓を[6]と上側の15ビット住ませるtcpヘッダーに順調な窓を受けてください。接続が16ビットしか使用していないなら、このオプションは供給されません、そうでなければ、低級16ビット、受信機が処理するオプションC.Whenのデータ部に入れて、それが最初にそうしなければならないパケットが窓を改革するということであり、パケットはその時、オプションがないとき処理するように処理されます。
Fox [Page 6] RFC 1106 TCP Big Window and Nak Options June 1989
フォックス[6ページ]RFC1106のTCPの大きい窓とNakオプション1989年6月
3.2 Impact of changes
3.2 変化の影響
In implementing the first version of the big window option there was very little change required to the source. State information must be added to the protocol to determine if the big window option is to be used and all 16 bit variables that dealt with window information must now become 32 bit quantities. A future document will describe in more detail the changes required to the 4.3 bsd tcp source code. Test results of the window change only are presented in the appendix. When expanding 16 bit quantities to 32 bit quantities in the TCP control block in the source (4.3 bsd source) may cause the structure to become larger than the mbuf used to hold the structure. Care must be taken to insure this doesn't occur with your system or undetermined events may take place.
大きい窓のオプションの最初のバージョンを実装するのにおいて、ほとんどソースに必要でない変化がありました。 大きい窓のオプションが使用されていることであり、現在窓の情報に対処したすべての16のビット変数が32ビットの量にならなければならないかどうか決定するために州の情報をプロトコルに追加しなければなりません。 将来のドキュメントはさらに詳細に4.3bsd tcpソースコードに必要である変化について説明するでしょう。 ウィンドウ変化の試験の成績だけが付録に示されます。 ソースでTCP制御ブロックで16ビットの量を32ビットの量に広げるとき、(4.3bsdソース)によって、構造はmbufが以前はよく構造を保持していたより大きくなるかもしれません。 これがあなたのシステムで起こらないのを保障するために注意しなければならないか、または非決定しているイベントは行われるかもしれません。
4. Effects of Big Windows and Naks when used together
4. Big WindowsとNaksの効果一緒に使用されると
With big windows alone, transfer times over a satellite were quite impressive with the absence of any introduced errors. However, when an error simulator was used to create random errors during transfers, performance went down extremely fast. When the nak option was added to the big window option performance in the face of errors went up some but not to the level that was expected. This section will discuss some issues that were overcome to produce the results given in the appendix.
大きい窓が単独の状態で、衛星の上の転送時間はどんな導入された誤りの欠如でもかなり印象的でした。 しかしながら、誤りシミュレータが転送の間、無作為の誤りを作成するのに使用されたとき、性能は非常に速く落ちました。 nakオプションがいつ誤りに直面して大きい窓のオプション性能に追加されたかは、いくつかを上がりましたが、予想されたレベルに上がったというわけではありません。 このセクションは付録で与えられた結果を生むので打ち勝たれたいくつかの問題について論ずるでしょう。
4.1 Window Size and Nak benefits
4.1 ウィンドウSizeとNak利益
With out errors, the window size required to keep the data pipe full is equal to the round trip delay * throughput desired, or the data pipe bandwidth (called Z from now on). This and other calculations assume that processing time of the hosts is negligible. In the event of an error (without NAKs), the window size needs to become larger than Z in order to keep the data pipe full while the sender is waiting for the ack of the resent packet. If the window size is equaled to Z and we assume that the retransmission timer is equaled to Z, then when a packet is lost, the retransmission timer will go off as the last piece of data in the window is sent. In this case, the lost piece of data can be resent with no delay. The data pipe will empty out because it will take 1/2Z worth of data to get the ack back to the sender, an additional 1/2Z worth of data to get the data pipe refilled with new data. This causes the required window to be 2Z, 1Z to keep the data pipe full during normal operations and 1Z to keep the data pipe full while waiting for a lost packet to be resent and acked.
出ている誤りについて、データパイプをいっぱいに保つのに必要であるウィンドウサイズは望まれていた周遊旅行遅れ*スループット、またはデータパイプ帯域幅(これから先、Zと呼ばれる)と等しいです。 これと他の計算は、ホストの処理時間が取るにたらないと仮定します。 誤り(NAKsのない)の場合、ウィンドウサイズが、送付者がackを待っている間、データパイプを完全に保つためにZより大きくなる必要がある、パケットに憤慨してください。 パケットが無くなるとき、ウィンドウサイズがZと等しく、私たちが、再送信タイマーがZと等しいと思うと、窓のデータの最後の断片を送るのに従って、再送信タイマーは発射されるでしょう。 この場合、遅れなしで無くなっているデータを再送できます。 ackを手に入れるのにデータの価値を1/2Zに要するので、パイプがすっかり空にするデータは新しいデータでデータパイプを詰め替えさせるために送付者、追加1/2Zにデータの価値を支持します。 これは、無くなっているパケットが再送されて、ackedされるのを待っている間、データパイプを完全に保つために必要な窓が2Zと、通常操作の間にデータパイプを完全に保つ1Zと1Zであることを引き起こします。
If the same scenario in the last paragraph is used with the addition of NAKs, the required window size still needs to be 2Z to avoid
最後のパラグラフの同じシナリオがNAKs、スチール写真が2Zになるのに避ける必要がある必要なウィンドウサイズの追加と共に使用されるなら
Fox [Page 7] RFC 1106 TCP Big Window and Nak Options June 1989
フォックス[7ページ]RFC1106のTCPの大きい窓とNakオプション1989年6月
wasting any bandwidth in the event of a dropped packet. This appears to mean that the nak option does not provide any benefits at all. Testing showed that the retransmission timer was larger than the data pipe and in the event of errors became much bigger than the data pipe, because of the retransmission backoff. Thus, the nak option bounds the required window to 2Z such that in the event of an error there is no lost bandwidth, even with the retransmission timer fluctuations. The results in the appendix shows that by using naks, bandwidth waste associated with the retransmission timer facility is eliminated.
下げられたパケットの場合、どんな帯域幅も浪費します。 これはnakオプションが全く少しの利益も提供しないことを意味するように見えます。 テストは、再送信タイマーがデータパイプより大きいのを示して、誤りの場合、データパイプよりはるかに大きくなりました、retransmission backoffのために。 したがって、nakはどんな無くなっている帯域幅も誤りの場合、ないように、2Zへの必要な窓を領域にゆだねます、再送信タイマー変動があっても。 naksを使用することによって、再送信タイマー施設に関連している帯域幅浪費が排除されるという付録ショーにおける結果。
4.2 Congestions vs Noise
4.2 渋滞対雑音
An issue that must be looked at when implementing both the NAKs and big window scheme together is in the area of congestion versus lost packets due to the medium, or noise. In the recent algorithm enhancements [1], slow start was introduced so that whenever a data transfer is being started on a connection or right after a dropped packet, the effective send window would be set to a very small size (typically would equal the MSS being used). This is done so that a new connection would not cause congestion by immediately overloading the network, and so that an existing connection would back off the network if a packet was dropped due to congestion and allow the network to clear up. If a connection using big windows loses a packet due to the medium (a packet corrupted by an error) the last thing that should be done is to close the send window so that the connection can only send 1 packet and must use the slow start algorithm to slowly work itself back up to sending full windows worth of data. This algorithm would quickly limit the usefulness of the big window and nak options over lossy links.
いつに両方が一緒にNAKsと大きい窓の体系であると実装するのが混雑の領域にあるか見なければならない問題は媒体、または雑音のためパケットを失いました。 最近のアルゴリズム増進[1]では、データ転送が接続に始めである、または下げられたパケットの後の右、有効が発信するときはいつも、窓が非常に小さいサイズに設定されるように、遅れた出発を導入しました(使用されるMSSと通常等しいでしょう)。 既存の接続が、新しい接続がすぐにまでにネットワークを積みすぎながら混雑を引き起こさないで、パケットが混雑のため下げられたならネットワークを戻して、ネットワークが解決するのを許容するように、これをします。 するべきである最後のことが大きい窓を使用している接続が媒体のためパケットを失うなら(パケットは誤りで崩壊しました)閉じることである、接続が1つのパケットしか送ることができないで、データの価値を完全な窓に送りながらゆっくりそれ自体をあおり返すのに遅れた出発アルゴリズムを使用しなければならないように、窓を送ってください。 このアルゴリズムはすぐに損失性リンクの上の大きい窓とnakオプションの有用性を制限するでしょう。
On the other hand, if a packet was dropped due to congestion and the sender assumes the packet was dropped because of noise the sender will continue sending large amounts of data. This action will cause the congestion to continue, more packets will be dropped, and that part of the network will collapse. In this instance, the sender would want to back off from sending at the current window limit. Using the current slow start mechanism over a satellite builds up the window too slowly [1]. Possibly a better solution would be for the window to be opened 2*Rlog2(W) instead of R*log2(W) [1] (open window by 2 packets instead of 1 for each acked packet). This will reduce the wasted bandwidth by opening the window much quicker while giving the network a chance to clear up. More experimentation is necessary to find the optimal rate of opening the window, especially when large windows are being used.
他方では、パケットが混雑のため下げられて、送付者が、パケットが雑音のために下げられたと仮定すると、送付者は、多量のデータを送り続けるでしょう。 混雑はこの動作で続くでしょう、そして、より多くのパケットが下げられるでしょう、そして、ネットワークのその部分は崩れるでしょう。 この場合、送付者は現在の窓の限界のときに発信するのから引き返したがっているでしょう。 現在の遅れた出発メカニズムを使用して、衛星の上では、[1]はあまりにゆっくり窓に建てています。 窓はことによるとより良いソリューションがR*log2(W)[1](それぞれのackedパケットあたり1の代わりに2つのパケットによる開いている窓)の代わりに開かれた2*Rlog2(W)であるだろうということです。 これは、晴れる機会をネットワークに与えている間、はるかに迅速に窓を開けることによって、無駄な帯域幅を減少させるでしょう。 より多くの実験が、特に大きい窓が使用されているとき窓を開ける最適のレートを見つけるのに必要です。
The current recommendation for TCP is to use the slow start mechanism in the event of any lost packet. If an application knows that it
TCPのための現在の推薦はどんな無くなっているパケットの場合も、遅れた出発メカニズムを使用することです。 アプリケーションがそれを知っている、それ
Fox [Page 8] RFC 1106 TCP Big Window and Nak Options June 1989
フォックス[8ページ]RFC1106のTCPの大きい窓とNakオプション1989年6月
will be using a satellite with a high error rate, it doesn't make sense to force it to use the slow start mechanism for every dropped packet. Instead, the application should be able to choose what action should happen in the event of a lost packet. In the BSD environment, a setsockopt call should be provided so that the application may inform TCP to handle lost packets in a special way for this particular connection. If the known error rate of a link is known to be small, then by using slow start with modified rate from above, will cause the amount of bandwidth loss to be very small in respect to the amount of bandwidth actually utilized. In this case, the setsockopt call should not be used. What is really needed is a way for a host to determine if a packet or packets are being dropped due to congestion or noise. Then, the host can choose to do the right thing. This will require a mechanism like source quench to be used. For this to happen more experimentation is necessary to determine a solid definition on the use of this mechanism. Now it is believed by some that using source quench to avoid congestion only adds to the problem, not help suppress it.
使用が高い誤り率がある衛星であるつもりであったなら、それはあらゆる下げられたパケットに遅れた出発メカニズムを使用させる意味になりません。 代わりに、アプリケーションは、どんな動作が無くなっているパケットの場合、起こるべきであるかを選ぶことができるべきです。 BSD環境に、アプリケーションがこの特定の接続に、特別な方法で無くなっているパケットを扱うためにTCPに知らせることができるように、setsockopt呼び出しを提供するべきです。 リンクの知られている誤り率が知られていると、そして、上から変更されたレートがある遅れた出発を使用することによって、小さいのは、帯域幅の損失の量が実際に利用された帯域幅の量に関して非常に少であることを引き起こすでしょう。 この場合、setsockopt呼び出しを使用するべきではありません。 本当に必要であるものはホストが、パケットかパケットが混雑か雑音のため下げられるかどうかと決心する方法です。 そして、ホストは、正しいことをするのを選ぶことができます。 これは、ソース焼き入れのようなメカニズムが使用されるのを必要とするでしょう。 より多くの実験が、これが起こるためには、そうです。このメカニズムの使用のときに確実な定義を決定するために、必要です。 現在、それを抑圧するのを助けるのではなく、混雑を避けるのにソース焼き入れを使用するのが問題に加えるだけであるといくつかによって信じられています。
The TCP used to gather the results in the appendix for the big window with nak experiment, assumed that lost packets were the result of noise and not congestion. This assumption was used to show how to make the current TCP work in such an environment. The actual satellite used in the experiment (when the satellite simulator was not used) only experienced an error rate around 10e-10. With this error rate it is suggested that in practice when big windows are used over the link, TCP should use the slow start mechanism for all lost packets with the 2*Rlog2(W) rate discussed above. Under most situations when long delay networks are being used (transcontinental DS3 networks using fiber with very low error rates, or satellite links with low error rates) big windows and naks should be used with the assumption that lost packets are the result of congestion until a better algorithm is devised [7].
nak実験で付録の結果を大きい窓に集めるのにおいて中古のTCP、そんなに無くなると思われて、パケットは混雑ではなく、雑音の結果でした。 この仮定は、現在のTCPをそのような環境でどのように働かせるかを示すのに使用されました。 実験(衛星シミュレータが使用されなかったとき)に使用される実際の衛星は10e-10の周りで誤り率を経験しただけです。 この誤り率で、大きい窓がリンクの上に使用されるときの習慣に、TCPがすべての無くなっているパケットに上で議論する2*Rlog2(W)レートで遅れた出発メカニズムを使用するはずであると示唆されます。 長時間の遅延ネットワークが使用される予定であるほとんどの状況(非常に低い誤り率があるファイバー、または低誤り率との衛星中継を使用する大陸横断のDS3ネットワーク)の下で、大きい窓とnaksは、より良いアルゴリズムが工夫されるまで無くなっているパケットが混雑の結果であるという仮定と共に使用されるべきです。[7]。
Another problem noticed, while testing the affects of slow start over a satellite link, was at times, the retransmission timer was set so restrictive, that milliseconds before a naked packet's ack is received the retransmission timer would go off due to a timed packet within the send window. The timer was set at the round trip delay of the network allowing no time for packet processing. If this timer went off due to congestion then backing off is the right thing to do, otherwise to avoid the scenario discovered by experimentation, the transmit timer should be set a little longer so that the retransmission timer does not go off too early. Care must be taken to make sure the right thing is done in the implementation in question so that a packet isn't retransmitted too soon, and blamed on congestion when in fact, the ack is on its way.
衛星中継の上の遅れた出発の感情をテストしている間に気付かれた別の問題が再送信タイマーがとても制限しているセットであり、裸のパケットのackの前のミリセカンドが受け取られているという時に再送信タイマーが調節されたパケットのため中から発射されるだろうということであった、窓を送ってください。 タイマはパケット処理のための時間を全く許容しないネットワークの周遊旅行遅れでセットでした。 このタイマが混雑のため発射されたなら、引き返すのは、する正しいことです、実験で発見されたシナリオを避けるためにそうでない、設定aが再送信タイマーがあまりに早くほとんど去らないより長いそうであったならタイマを送ってください。 問題の実装で正しいことをするのを確実にするために注意しなければならないので、事実上、ackが行く途中とき、パケットは、あまりに早く再送されて、混雑のせいにされません。
Fox [Page 9] RFC 1106 TCP Big Window and Nak Options June 1989
フォックス[9ページ]RFC1106のTCPの大きい窓とNakオプション1989年6月
4.3 Duplicate Acks
4.3 写しAcks
Another problem found with the 4.3bsd implementation is in the area of duplicate acks. When the sender of data receives a certain number of acks (3 in the current Berkeley release) that acknowledge previously acked data before, it then assumes that a packet has been lost and will resend the one packet assumed lost, and close its send window as if the network is congested and the slow start algorithm mention above will be used to open the send window. This facility is no longer needed since the sender can use the reception of a nak as its indicator that a particular packet was dropped. If the nak packet is lost then the retransmit timer will go off and the packet will be retransmitted by normal means. If a senders algorithm continues to count duplicate acks the sender will find itself possibly receiving many duplicate acks after it has already resent the packet due to a nak being received because of the large size of the data pipe. By receiving all of these duplicate acks the sender may find itself doing nothing but resending the same packet of data unnecessarily while keeping the send window closed for absolutely no reason. By removing this feature of the implementation a user can expect to find a satellite connection working much better in the face of errors and other connections should not see any performance loss, but a slight improvement in performance if anything at all.
4.3bsd実装で見つけられた別の問題は写しacksの領域にあります。 次に、データの送付者が以前以前にackedされたデータを承認するacks(現在のバークレーのリリースにおける3)のある数を受けるときパケットが失われて、無くなって、近いと思われた1つのパケットを再送すると仮定する、それ、まるでネットワークが混雑しているかのように窓を送ってください。そうすれば、遅れた出発アルゴリズム言及上が開くのに使用される、窓を送ってください。 送付者が特定のパケットが下げられたというインディケータとしてnakのレセプションを使用できるので、この施設はもう必要ではありません。 nakパケットが無くなると、再送信タイマは発射されるでしょう、そして、パケットは正常な手段で再送されるでしょう。 送付者アルゴリズムが、写しacksを数え続けていると、データパイプの大判のために受け取られるnakのため既にパケットを再送した後に送付者はことによると気付くと多くの写しacksを受けているでしょう。 保っている間、不必要にデータの同じパケットを再送するだけでありながら送付者が気付くとしているかもしれないこれらの写しacksのすべてを受ける、絶対に理由がないのに閉じられた窓を送ってください。 実装のこの特徴を取り除くことによって、ユーザが、衛星接続が誤りに直面してたくさんうまくいっているのがわかると予想できて、他の接続は少しの性能の損失も見るのではなく、どちらかと言えば、全く性能におけるわずかな改善を見るべきです。
5. Conclusion
5. 結論
This paper has described two new options that if used will make TCP a more efficient protocol in the face of errors and a more efficient protocol over networks that have a high bandwidth*delay product without decreasing performance over more common networks. If a system that implements the options talks with one that does not, the two systems should still be able to communicate with no problems. This assumes that the system doesn't use the option numbers defined in this paper in some other way or doesn't panic when faced with an option that the machine does not implement. Currently at NASA, there are many machines that do not implement either option and communicate just fine with the systems that do implement them.
この論文は、より一般的なネットワークの上で性能を減少させないで高帯域*遅れ製品を持っているネットワークの上で使用されるなら誤りに直面してTCPをより効率的なプロトコルにする2つの新しいオプションと、より効率的なプロトコルについて説明しました。 オプションを実装するシステムがそうしないものと話すなら、2台のシステムが問題なしでまだ交信しているはずであることができます。これは、システムがこの紙である他の方法で定義されたオプション番号を使用しないか、またはマシンが実装しないオプションが直面されている場合慌てないと仮定します。 現在、NASAに、オプションを実装して、問題なくそれらを実装するシステムとコミュニケートしない多くのマシンがあります。
The drive for implementing big windows has been the direct result of trying to make TCP more efficient over large delay networks [2,3,4,5] such as a T1 satellite. However, another practical use of large windows is becoming more apparent as the local area networks being developed are becoming faster and supporting much larger MTU's. Hyperchannel, for instances, has been stated to be able to support 1 Mega bit MTU's in their new line of products. With the current implementation of TCP, efficient use of hyperchannel is not utilized as it should because the physical mediums MTU is larger than the maximum window of the protocol being used. By increasing the TCP
大きい窓を実装するのを求める運動はTCPをT1衛星などの大きい遅れネットワーク[2、3、4、5]の上では、より効率的にしようとする直接の結果です。 しかしながら、発展するローカル・エリア・ネットワークが、より速くなって、はるかに大きいMTUのものをサポートしているとき、大きい窓の別の実用は、より明らかになっています。 インスタンスのためのHyperchannelは、それらの新しい製造品目で1MegaビットがMTUのものであるとサポートすることができるように述べられています。 TCPの現在の実装と共に、「超-チャンネル」の効率的な使用は物理的霊媒MTUが使用されるプロトコルの最大の窓より大きいので利用されるべきであるように利用されていません。 TCPを増強することによって
Fox [Page 10] RFC 1106 TCP Big Window and Nak Options June 1989
フォックス[10ページ]RFC1106のTCPの大きい窓とNakオプション1989年6月
window size, better utilization of networks like hyperchannel will be gained instantly because the sender can send 64 Kbyte packets (IP limitation) but not have to operate in a stop and wait fashion. Future work is being started to increase the IP maximum datagram size so that even better utilization of fast local area networks will be seen by having the TCP/IP protocols being able to send large packets over mediums with very large MTUs. This will hopefully, eliminate the network protocol as the bottleneck in data transfers while workstations and workstation file system technology advances even more so, than it already has.
ウィンドウサイズ、「超-チャンネル」のようなネットワークの、より良い利用は、送付者が64のキロバイトパケット(IP制限)を送ることができるので即座に獲得しますが、停止で作動して、ファッションを待つ必要はありません。 速いローカル・エリア・ネットワークのさらに良い利用がTCP/IPプロトコルを持っていることによって見られるようにIPの最大のデータグラムサイズを増強するために、今後の活動は非常に大きいMTUsの霊媒の上に大きいパケットを送ることができる始めです。 これが希望をいだいてそうするので、ワークステーションとワークステーションがシステム技術をファイルしますが、データ転送によるボトルネックがさらにも進むとき、ネットワーク・プロトコルを排除してください、既にそうするより。
An area of concern when using the big window mechanism is the use of machine resources. When running over a satellite and a packet is dropped such that 2Z (where Z is the round trip delay) worth of data is unacknowledged, both ends of the connection need to be able to buffer the data using machine mbufs (or whatever mechanism the machine uses), usually a valuable and scarce commodity. If the window size is not chosen properly, some machines will crash when the memory is all used up, or it will keep other parts of the system from running. Thus, setting the window to some fairly large arbitrary number is not a good idea, especially on a general purpose machine where many users log on at any time. What is currently being engineered at NASA is the ability for certain programs to use the setsockopt feature or 4.3bsd asking to use big windows such that the average user may not have access to the large windows, thus limiting the use of big windows to applications that absolutely need them and to protect a valuable system resource.
大きいウィンドウメカニズムを使用するとき、気になる所はマシンリソースの使用です。 衛星とパケットをひくのが下げられるのでデータにおいて価値がある2Z(Zが周遊旅行遅れであるところ)が認められないときに、マシンmbufs(マシンがどんなメカニズムも使用しても)、通常貴重で不十分な商品を使用することでデータをバッファリングできる接続の必要性の両端です。 メモリがすっかり使いきられるか、または稼働からシステムの他の部分を控えるとき、ウィンドウサイズが適切に選ばれていないと、いくつかのマシンがダウンするでしょう。 したがって、何らかのかなり大きい特殊活字の数字に窓を設定するのは、名案ではありません、汎用機械で特に上多くのユーザがいつでもログオンする。 現在NASAで設計されていることは、あるプログラムがsetsockoptの特徴を使用する能力か一般ユーザーが大きい窓に近づく手段を持たないように大きい窓を使用して、その結果、大きい窓の使用をそれらを絶対に必要とするアプリケーションに制限して、貴重なシステム資源を保護するように頼む4.3bsdです。
6. References
6. 参照
[1] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM 88,
Stanford, Ca., August 1988.
[1] ジェーコブソンと、V.と、「輻輳回避とコントロール」、SIGCOMM88、スタンフォード、Ca、8月1988日
[2] Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay
Paths", LBL, USC/Information Sciences Institute, RFC 1072,
October 1988.
ジェーコブソン、V.、およびR.ブレーデン、「長時間の遅延経路のためのTCP拡張子」、LBL、USC/情報科学が設ける[2]、RFC1072、1988年10月。
[3] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC
1045, Stanford University, February 1988.
[3]Cheriton、D.、「VMTP:」 「多能なメッセージトランザクションプロトコル」、RFC1045、スタンフォード大学、1988年2月。
[4] Clark, D., M. Lambert, and L. Zhang, "NETBLT: A Bulk Data
Transfer Protocol", RFC 998, MIT, March 1987.
[4] クラーク、D.、M.ランバート、およびL.チャン、「NETBLT:」 「バルク・データ転送プロトコル」、RFC998、MIT、1987年3月。
[5] Fox, R., "Draft of Proposed Solution for High Delay Circuit File
Transfer", GE/NAS Internal Document, March 1988.
[5]フォックス、R.、「高い遅延回路ファイル転送のための提案されたソリューションの草稿」、GE/NAS内部文書、1988年3月。
[6] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September 1981.
[6] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC793、DARPA、1981年9月。
Fox [Page 11] RFC 1106 TCP Big Window and Nak Options June 1989
フォックス[11ページ]RFC1106のTCPの大きい窓とNakオプション1989年6月
[7] Leiner, B., "Critical Issues in High Bandwidth Networking", RFC
1077, DARPA, November 1989.
[7]Leiner、B.、「高帯域ネットワークにおける重要な問題」、RFC1077、DARPA、1989年11月。
7. Appendix
7. 付録
Both options have been implemented and tested. Contained in this section is some performance gathered to support the use of these two options. The satellite channel used was a 1.544 Mbit link with a 580ms round trip delay. All values are given as units of bytes.
両方のオプションは、実装されて、テストされました。 このセクションに含まれているのは、これらの2つのオプションの使用をサポートするために集められた何らかの性能です。 使用される衛星チャンネルは580ms周遊旅行遅れとの1.544メガビットリンクでした。 ユニットのバイトとしてすべての値を与えます。
TCP with Big Windows, No Naks:
大きいWindowsがあるTCP、Naksがありません:
|---------------transfer rates----------------------|
Window Size | no error | 10e-7 error rate | 10e-6 error rate |
-----------------------------------------------------------------
64K | 94K | 53K | 14K |
-----------------------------------------------------------------
72K | 106K | 51K | 15K |
-----------------------------------------------------------------
80K | 115K | 42K | 14K |
-----------------------------------------------------------------
92K | 115K | 43K | 14K |
-----------------------------------------------------------------
100K | 135K | 66K | 15K |
-----------------------------------------------------------------
112K | 126K | 53K | 17K |
-----------------------------------------------------------------
124K | 154K | 45K | 14K |
-----------------------------------------------------------------
136K | 160K | 66K | 15K |
-----------------------------------------------------------------
156K | 167K | 45K | 14K |
-----------------------------------------------------------------
Figure 1.
|---------------転送レート----------------------| ウィンドウサイズ| 誤りがありません。| 10e-7誤り率| 10e-6誤り率| ----------------------------------------------------------------- 64 K| 94 K| 53 K| 14 K| ----------------------------------------------------------------- 72 K| 106 K| 51 K| 15 K| ----------------------------------------------------------------- 80 K| 115 K| 42 K| 14 K| ----------------------------------------------------------------- 92 K| 115 K| 43 K| 14 K| ----------------------------------------------------------------- 100 K| 135 K| 66 K| 15 K| ----------------------------------------------------------------- 112 K| 126 K| 53 K| 17 K| ----------------------------------------------------------------- 124 K| 154 K| 45 K| 14 K| ----------------------------------------------------------------- 136 K| 160 K| 66 K| 15 K| ----------------------------------------------------------------- 156 K| 167 K| 45 K| 14 K| ----------------------------------------------------------------- 図1。
Fox [Page 12] RFC 1106 TCP Big Window and Nak Options June 1989
フォックス[12ページ]RFC1106のTCPの大きい窓とNakオプション1989年6月
TCP with Big Windows, and Naks:
大きいWindowsがあるTCP、およびNaks:
|---------------transfer rates----------------------|
Window Size | no error | 10e-7 error rate | 10e-6 error rate |
-----------------------------------------------------------------
64K | 95K | 83K | 43K |
-----------------------------------------------------------------
72K | 104K | 87K | 49K |
-----------------------------------------------------------------
80K | 117K | 96K | 62K |
-----------------------------------------------------------------
92K | 124K | 119K | 39K |
-----------------------------------------------------------------
100K | 140K | 124K | 35K |
-----------------------------------------------------------------
112K | 151K | 126K | 53K |
-----------------------------------------------------------------
124K | 160K | 140K | 36K |
-----------------------------------------------------------------
136K | 167K | 148K | 38K |
-----------------------------------------------------------------
156K | 167K | 160K | 38K |
-----------------------------------------------------------------
Figure 2.
|---------------転送レート----------------------| ウィンドウサイズ| 誤りがありません。| 10e-7誤り率| 10e-6誤り率| ----------------------------------------------------------------- 64 K| 95 K| 83 K| 43 K| ----------------------------------------------------------------- 72 K| 104 K| 87 K| 49 K| ----------------------------------------------------------------- 80 K| 117 K| 96 K| 62 K| ----------------------------------------------------------------- 92 K| 124 K| 119 K| 39 K| ----------------------------------------------------------------- 100 K| 140 K| 124 K| 35 K| ----------------------------------------------------------------- 112 K| 151 K| 126 K| 53 K| ----------------------------------------------------------------- 124 K| 160 K| 140 K| 36 K| ----------------------------------------------------------------- 136 K| 167 K| 148 K| 38 K| ----------------------------------------------------------------- 156 K| 167 K| 160 K| 38 K| ----------------------------------------------------------------- 図2。
With a 10e-6 error rate, many naks as well as data packets were dropped, causing the wild swing in transfer times. Also, please note that the machines used are SGI Iris 2500 Turbos with the 3.6 OS with the new TCP enhancements. The performance associated with the Irises are slower than a Sun 3/260, but due to some source code restrictions the Iris was used. Initial results on the Sun showed slightly higher performance and less variance.
10e-6誤り率によると、データ・パケットと同様に多くのnaksが下げられました、転送時代に激しい変動を引き起こして。 また、使用されるマシンはSGI Iris2500新しいTCP増進がある3.6OSをもってTurbosです。 Irisesに関連している性能はSun3/260より遅いのですが、いくつかのソースコード制限のため、Irisは使用されました。 太陽の初期の結果はわずかに高い性能と、より少ない変化を示しました。
Author's Address
作者のアドレス
Richard Fox 950 Linden #208 Sunnyvale, Cal, 94086
リチャードフォックス950リンデン#208サニーベル、カル、94086
EMail: rfox@tandem.com
メール: rfox@tandem.com
Fox [Page 13]
フォックス[13ページ]
一覧
スポンサーリンク
