RFC813 日本語訳

RFC:  813

RFC: 813

                WINDOW AND ACKNOWLEDGEMENT STRATEGY IN TCP

TCPの窓のAND承認戦略

                             David D. Clark
                  MIT Laboratory for Computer Science
               Computer Systems and Communications Group
                               July, 1982

デヴィッドD.クラークMITコンピュータサイエンス研究所コンピュータシステムズとコミュニケーションは1982年7月に分類されます。

     1.  Introduction

1. 序論

     This  document describes implementation strategies to deal with two

このドキュメントは、2に対処するために実現戦略を説明します。

mechanisms in TCP, the window and the acknowledgement.  These mechanisms

TCPのメカニズム、窓、および承認。 これらのメカニズム

are described in the specification document, but it is  possible,  while

説明されたコネは仕様ドキュメントですが、それは可能です。

complying with the specification, to produce implementations which yield

もたらされる実現を起こすために仕様に従います。

very  bad  performance.    Happily,  the pitfalls possible in window and

非常に悪い性能。 そして幸いにも、中で可能な落とし穴が窓を付ける。

acknowledgement strategies are very easy to avoid.

承認戦略は非常に避けやすいです。

     It is a much more difficult exercise to verify the performance of a

aの性能について確かめるのは、はるかに難しい運動です。

specification than the correctness.  Certainly, we have less  experience

仕様、正当性より。 確かに、私たちには、より少ない経験があります。

in  this  area,  and  we  certainly  lack  any  useful formal technique.

この領域、確かに、私たちはどんな役に立つ正式なテクニックも欠いています。

Nonetheless, it is important to attempt a specification  in  this  area,

それにもかかわらず、この領域で仕様を試みるのは重要です。

because  different  implementors  might  otherwise  choose superficially

異なった作成者が別の方法で表面的に選ぶかもしれないので

reasonable algorithms  which  interact  poorly  with  each  other.  This

互いに不十分に対話する合理的なアルゴリズム。 これ

document  presents  a  particular  set of algorithms which have received

ドキュメントは受信された特定のセットのアルゴリズムを提示します。

testing in the field, and which appear to work properly with each other.

野原、および互いと共に適切に働かせる見えるどれで、テストするか。

With more experience, these algorithms may become  part  of  the  formal

より多くの経験によると、これらのアルゴリズムは正式の一部になるかもしれません。

specification:  until such time their use is recommended.

                                   2

仕様: そのような時間まで、彼らの使用はお勧めです。 2

2.  The Mechanisms

2. メカニズム

     The acknowledgement mechanism is at the heart of TCP.  Very simply,

承認メカニズムがTCPの中心にあります。 非常に単に

when  data  arrives at the recipient, the protocol requires that it send

データが受取人に到着するとき、プロトコルは、それが発信するのを必要とします。

back an acknowledgement of this data.  The protocol specifies  that  the

このデータの承認を支持してください。 プロトコルはそれを指定します。

bytes  of  data  are  sequentially  numbered,  so that the recipient can

バイトのデータは、受取人が付番できるように連続して付番されます。

acknowledge data by naming the highest numbered  byte  of  data  it  has

それが持っているデータの最も高い番号付のバイトを命名するデータを承認してください。

received,  which  also  acknowledges  the  previous  bytes (actually, it

受け取られていて、また、どれが前のバイトを承認するか、(実際にそれ

identifies the first byte of data which it has  not  yet  received,  but

しかしそれがまだ受け取っていないデータの最初のバイトを特定します。

this is a small detail).  The protocol contains only a general assertion

これが小さい詳細である、) プロトコルは一般的な主張だけを含んでいます。

that  data  should  be acknowledged promptly, but gives no more specific

そのデータは、即座に承認されるべきですが、いいえをより特定に与えます。

indication as to how quickly an acknowledgement must  be  sent,  or  how

どれくらいすばやく承認を送らなければならないかに関する指示、またはどのように

much data should be acknowledged in each separate acknowledgement.

多くのデータがそれぞれの別々の承認で承認されるべきです。

     The window mechanism is a flow control tool.  Whenever appropriate,

ウィンドウメカニズムはフロー制御ツールです。 適切であるときはいつも

the  recipient of data returns to the sender a number, which is (more or

よりまたはデータの受取人が送付者a番号に戻って、どれがあるか、(。

less) the size of the buffer which the receiver currently has  available

以下) 受信機が現在利用可能にするバッファのサイズ

for  additional  data.   This number of bytes, called the window, is the

追加データのために。 窓と呼ばれるこのバイト数はそうです。

maximum which the sender is permitted to  transmit  until  the  receiver

送付者が受信機まで伝えることを許可されている最大

returns  some  additional  window.  Sometimes, the receiver will have no

ある追加窓を返します。 受信機には、時々、いいえがあるでしょう。

buffer space available, and will return a window value of zero.    Under

利用可能なスペースをバッファリングしてください、そして、ゼロの窓の値を返すでしょう。 下

these  circumstances,the  protocol  requires  the sender to send a small

これらの事情であり、プロトコルは、送付者が小さくaを送るのを必要とします。

segment to the receiver now and then, to see if more data  is  accepted.

セグメント、受信機に、見るために、時折、以上ならデータを受け入れます。

If  the  window  remains closed at zero for some substantial period, and

そして窓がいつかのかなりの期間、ゼロで閉じられたままで残っているなら。

the sender can obtain  no  response  from  the  receiver,  the  protocol

送付者は受信機、プロトコルから応答を全く得ることができません。

requires  the  sender  to  conclude that the receiver has failed, and to

そして送付者が、受信機が失敗したと結論を下すのが必要である。

close  the  connection.    Again,  there  is  very  little   performance

                                   3

接続を終えてください。 一方、非常に少ない性能3があります。

information  in  the  specification, describing under what circumstances

どんな状況で説明する仕様による情報

the window should be increased, and how the  sender  should  respond  to

窓は増加するべきであり、送付者がどのように応じるべきであるかをそうされます。

such revised information.

そのようなものは情報を改訂しました。

     A  bad implementation of the window algorithm can lead to extremely

窓のアルゴリズムの悪い実現が通じることができる、非常に。

poor performance overall.  The degradations which  occur  in  throughput

全体的に見て不十分な性能。 スループットに起こる転落

and  CPU  utilizations  can easily be several factors of ten, not just a

そして、CPU使用率はaだけではなく、容易に10のいくつかの要素であるかもしれません。

fractional increase.  This particular phenomenon is specific enough that

断片的な増加。 この特定の現象が十分特定である、それ

it has been given the name of Silly Window Syndrome, or  SWS.    Happily

Silly Window Syndrome、またはSWSという名前をそれに与えました。 幸福に

SWS  is  easy  to  avoid  if  a few simple rules are observed.  The most

いくつかの簡単な規則が守られるなら、SWSは避けやすいです。 大部分

important function of this memo is to describe SWS, so that implementors

このメモの重要な機能がSWSについて説明することであり、そうはその作成者です。

will understand the general nature  of  the  problem,  and  to  describe

一般的な問題の性格を理解する、説明します。

algorithms  which  will  prevent  its  occurrence.    This document also

発生を防ぐアルゴリズム。 このドキュメントも

describes   performance   enhancing   algorithms   which    relate    to

関係するアルゴリズムを高める性能について説明します。

acknowledgement,  and  discusses  the  way  acknowledgement  and  window

承認、道について議論する、承認と窓

algorithms interact as part of SWS.

アルゴリズムはSWSの一部として相互作用します。

     3.  SILLY WINDOW SYNDROME

3. 愚かな窓のシンドローム

     In order to understand SWS, we must first  define  two  new  terms.

SWSを理解するために、私たちは最初に、2回の新学期を定義しなければなりません。

Superficially,  the window mechanism is very simple:  there is a number,

表面的に、ウィンドウメカニズムは非常に簡単です: 数があります。

called "the window", which is returned from the receiver to the  sender.

「窓」と呼ばれます。(それは、受信機から送付者まで返されます)。

However,  we  must have a more detailed way of talking about the meaning

しかしながら、私たちには、意味に関して話すより詳細な方法がなければなりません。

of this number.  The receiver of data computes a  value  which  we  will

この数について。 データの受信機は私たちが計算するつもりである値を計算します。

call  the  "offered  window".    In  a  simple  case, the offered window

「提供された窓」に電話をしてください。 簡単なケース、提供された窓で

corresponds to the amount of buffer space  available  in  the  receiver.

受信機で利用可能なバッファ領域の量に対応しています。

This  correspondence  is  not necessarily exact, but is a suitable model

この通信は、必ず正確であるというわけではありませんが、適当なモデルです。

for the discussion to follow.    It  is  the  offered  window  which  is

                                   4

議論が続くように。 それは4である提供された窓です。

actually  transmitted  back from the receiver to the sender.  The sender

実際に受信機から送付者まで伝えられます。 送付者

uses the offered window  to  compute  a  different  value,  the  "usable

異価、「使用可能」を計算するのに提供された窓を使用します。

window",  which  is  the  offered window minus the amount of outstanding

傑出することの量を引いた提供された窓である「窓」

unacknowledged data.  The usable window is less than  or  equal  to  the

不承認のデータ。 使用可能な窓は、よりそう以下です。

offered window, and can be much smaller.

窓を提供して、はるかに小さい場合があります。

     Consider  the  following  simple  example.   The receiver initially

以下の簡単な例を考えてください。 受信機、初めは。

provides an offered window of 1,000.  The sender uses up this window  by

1,000の提供された窓を提供します。 送付者はこの窓を使いきります。

sending  five  segments  of 200 bytes each.  The receiver, on processing

それぞれ200バイトの5つのセグメントを送ります。 処理での受信機

the first of these  segments,  returns  an  acknowledgement  which  also

またこれらのセグメントの1番目、リターン、承認、どの。

contains  an  updated  window value.  Let us assume that the receiver of

アップデートされた窓の値を含んでいます。 それが受信機であると仮定しましょう。

the data has removed the first 200 bytes from the buffer,  so  that  the

データはバッファから最初の200バイトで離れたところで取り除いてあって、そうはそれです。

receiver once again has 1,000 bytes of available buffer.  Therefore, the

受信機には、1,000バイトの利用可能なバッファがもう一度あります。 したがって

receiver would return, as before, an offered window of 1,000 bytes.  The

受信機は従来と同様1,000バイトの提供された窓を返すでしょう。 The

sender,  on  receipt  of  this  first  acknowledgement, now computes the

この最初の承認を受け取り次第、送付者は現在、計算します。

additional number of bytes which may be sent.  In  fact,  of  the  1,000

送られるかもしれない追加バイト数。 事実上、1,000

bytes  which  the recipient is prepared to receive at this time, 800 are

受取人がこのとき受信する用意ができていて、800がそうであるバイト

already in transit, having been sent in response to the previous offered

既に提供された前に対応して送られたトランジットで

window.  In this case, the usable window is only 200 bytes.

窓。 この場合、使用可能な窓は200バイトにすぎません。

     Let us now consider how SWS  arises.    To  continue  the  previous

現在、SWSがどのように起こるか考えましょう。 前を続けるために

example,  assume  that at some point, when the sender computes a useable

例、送付者がuseableを計算するときには何らかのポイントでそれを仮定してください。

window of 200 bytes, it has only 50 bytes to send  until  it  reaches  a

窓、200バイトでは、それは、aに達するまで発信するために50バイトしか持っていません。

"push"  point.   It thus sends 50 bytes in one segment, and 150 bytes in

「プッシュ」ポイント。 その結果、それは中で、あるセグメント、および150バイトを50バイト送ります。

the next segment. Sometime later, this 50-byte segment  will  arrive  at

次のセグメント。 意志が到着するいつかの、より遅くて、これほど50バイトのセグメント

the recipient, which will process and remove the 50 bytes and once again

受取人。(その受取人は、処理して、50バイトともう一度取り外すでしょう)。

return  an  offered window of 1,000 bytes.  However, the sender will now

                                   5

1,000バイトの提供された窓を返してください。 しかしながら、送付者は現在、5を望んでいます。

compute  that there are 950 bytes in transit in the network, so that the

計算、トランジットには950バイトがネットワークにあって、そうはそれです。

useable window is now only 50 bytes.  Thus, the sender will  once  again

現在、useableの窓は50バイトにすぎません。 したがって、送付者はもう一度そうするでしょう。

send  a  50  byte  segment,  even  though  there  is no longer a natural

生まれつきの名手はもういませんが、50バイトのセグメントを送ってください。

boundary to force it.

それを強制する境界。

     In fact, whenever the acknowledgement  of  a  small  segment  comes

事実上小さいセグメントの承認が来るときはいつも

back, the useable window associated with that acknowledgement will cause

後部、承認が引き起こす交際したuseableの窓

another  segment  of  the  same  small  size  to  be  sent,  until  some

いくつかまで送られる同じ小型の別のセグメント

abnormality breaks the pattern.  It is easy to see  how  small  segments

異常はパターンを破ります。 どれくらい小さくセグメントを見るかは簡単です。

arise,  because  natural  boundaries  in the data occasionally cause the

起こってください、データにおける固有の境界は時折引き起こします。

sender to take a computed useable window and divide it  up  between  two

計算されたuseableの窓を取って、2の間でそれを分割する送付者

segments.   Once that division has occurred, there is no natural way for

セグメント。 その分割がいったん現れると、どんな自然な道もありません。

those useable window allocations to be recombined; thus the breaking  up

ものは再結合するために窓の配分をuseableします。 壊れるその結果、

of the useable window into small pieces will persist.

useableの窓では、小片になるまで、意志は持続しています。

     Thus,  SWS  is a degeneration in the throughput which develops over

したがって、SWSが発生するスループットで堕落である、終わっている。

time, during a long data transfer.  If the sender  ever  stops,  as  for

長いデータ転送の間の時間。 送付者が止まるなら

example  when  it runs out of data to send, the receiver will eventually

それであるときに、例は発信するためにデータを使い果たして、受信機は結局、そうするでしょう。

acknowledge all  the  outstanding  data,  so  that  the  useable  window

すべての傑出しているデータ、useableが窓を付けるそうを承認してください。

computed  by  the  sender  will  equal  the  full  offered window of the

送付者によって計算されて、満が窓を提供した同輩を望んでください。

receiver.  At this point the situation will  have  healed,  and  further

受信機ここに、状況はさらに回復してしまうでしょう。

data  transmission  over  the  link will occur efficiently.  However, in

リンクの上のデータ伝送は効率的に起こるでしょう。 しかしながら中

large file transfers, which occur without interruption,  SWS  can  cause

大きいファイル転送であり、SWSは引き起こす場合があります。(ファイル転送は間断ない起こります)。

appalling  performance.  The network between the sender and the receiver

性能を驚かせます。 送付者と受信機の間のネットワーク

becomes clogged with  many  small  segments,  and  an  equal  number  of

多くの小さいセグメント、および等しい数で妨げられるようになります。

acknowledgements,  which  in  turn  causes lost segments, which triggers

承認。(その承認は順番に無くなっているセグメント、その引き金を引き起こします)。

massive retransmission.  Bad cases of SWS have been seen  in  which  the

                                   6

大規模な「再-トランスミッション」。 SWSの悪いケースが見られた、どれ、6

average  segment  size was one-tenth of the size the sender and receiver

平均したセグメントサイズがサイズの1/10であった、送付者と受信機

were prepared to deal with, and the average number of retransmission per

対処するために準備されていて「再-トランスミッション」の平均した数でした。

successful segments sent was five.

送られたうまくいっているセグメントは5でした。

     Happily, SWS is trivial to avoid.  The following sections  describe

幸いにも、SWSは、避けるために些細です。 セクションが説明する以下

two  algorithms,  one  executed  by the sender, and one by the receiver,

2つのアルゴリズム、送付者によって実行されたもの、および受信機による1

which appear to eliminate SWS completely.  Actually, either algorithm by

SWSを完全に排除するように見えます。 実際にどちらかのアルゴリズム

itself is sufficient to prevent SWS, and thus  protect  a  host  from  a

それ自体、SWSを防いで、その結果、aからホストを保護するために、十分です。

foreign  implementation  which  has  failed  to  deal properly with this

適切にこれに対処していない外国実現

problem.  The  two  algorithms  taken  together  produce  an  additional

問題。 一緒に取られた2つのアルゴリズムが作成される、追加

reduction  in  CPU  consumption, observed in practice to be as high as a

実際にはaと同じくらい高いと認められたCPU消費の減少

factor of four.

4の要素。

     4.  Improved Window Algorithms

4. 改良された窓のアルゴリズム

     The receiver of data can take a very simple step to eliminate  SWS.

データの受信機は、SWSを排除するために非常に簡単な方法を採ることができます。

When  it  disposes of a small amount of data, it can artificially reduce

少量のデータを処分するとき、それは人工的に減少できます。

the offered window in subsequent acknowledgements, so that  the  useable

提供が中でその後の承認に窓を付けて、そうがそれである、useable

window computed by the sender does not permit the sending of any further

送付者によって計算された窓はさらにいずれの発信を可能にしません。

data.     At  some  later  time,  when  the  receiver  has  processed  a

データ。 いつかの後の時代に。(その時、受信機はaを処理しました)。

substantially larger amount of incoming data, the artificial  limitation

実質的に多く以上の量の受信データ、人工の制限

on  the  offered  window  can be removed all at once, so that the sender

提供では、窓を一気に取り外すことができて、そうがそれである、送付者

computes a sudden large jump rather than a sequence of  small  jumps  in

中で小さいジャンプの系列よりむしろ突然の大きいジャンプを計算します。

the useable window.

useableの窓。

     At  this  level,  the  algorithm  is  quite simple, but in order to

しかし、このレベルでは、アルゴリズムはかなり簡単です。

determine exactly when the window should  be  opened  up  again,  it  is

ちょうど窓が再び開けられるべきであるとき、それが開けられることを決定してください。

necessary  to  look  at some of the other details of the implementation.

                                   7

実現の他の詳細のいくつかを見るために、必要です。 7

Depending  on whether the window is held artificially closed for a short

窓が人工的に持たれているかどうかによるのはショートのために閉じました。

or long time, two problems will  develop.    The  one  we  have  already

または、長い時間、2つの問題が発生するでしょう。 私たちが既に持っているもの

discussed  -- never closing the window artificially -- will lead to SWS.

--窓を決して人工的に閉じないで、議論して、SWSに通じるでしょう。

On the other hand, if  the  window  is  only  opened  infrequently,  the

他方では、窓がまれに開けられるだけであるなら

pipeline  of data in the network between the sender and the receiver may

送付者と受信機の間のネットワークにおけるデータのパイプラインはそうするかもしれません。

have emptied out while the sender was being held off, so that a delay is

送付者が食い止められていたので遅れがあるように、空にされたアウトを持ってください。

introduced before additional data arrives from the sender.   This  delay

追加データが送付者から到着する前に導入します。 この遅れ

does reduce throughput, but it does not consume network resources or CPU

スループットを減らしなさい、ただし、それはネットワーク資源かCPUを消費しません。

resources  in  the  process, as does SWS.  Thus, it is in this direction

SWSのような過程によるリソース。 したがって、この方向にはそれがあります。

that one ought to overcompensate.  For a simple implementation,  a  rule

その過大に補償されるべきです。 簡単な実現、規則のために

of  thumb  that  seems to work in practice is to artificially reduce the

実際には働いているのが人工的に減少することになっているように思える親指

offered window until the reduction constitutes one half of the available

提供された減少までの窓は利用可能の半分を構成します。

space, at which point increase the window to advertise the entire  space

スペース。(そこでは、ポイントが、全体のスペースの広告を出すために窓を増加させます)。

again.  In any event, one ought to make the chunk by which the window is

再び。 とにかく、窓がそうである塊を作るべきです。

opened  at  least permit one reasonably large segment.  (If the receiver

開かれて、1つの合理的に大きいセグメントを少なくとも可能にしてください。 (受信機です。

is so short of buffers that it can never advertise a large enough buffer

バッファでは、決して十分大きいバッファの広告を出すことができないくらい不足しています。

to permit at least one large segment, it is hopeless to expect any  sort

少なくとも1つの大きいセグメントを可能にするために、どんな種類も予想するのは絶望的です。

of high throughput.)

高生産性について。)

     There  is  an algorithm that the sender can use to achieve the same

送付者が同じくらい達成するのに使用できるアルゴリズムがあります。

effect described above:  a very simple and elegant rule first  described

上で説明された効果: 最初に説明された非常に簡単で上品な規則

by  Michael  Greenwald  at MIT.  The sender of the data uses the offered

MITのマイケル・グリーンワルド。 データの送付者は提供を使用します。

window to compute a useable window, and then compares the useable window

useableを計算する窓は、useableの窓に窓を付けて、次に、比較します。

to the offered window, and refrains from sending anything if  the  ratio

提供された窓、および比率であるなら何でも送るのからのリフレインに

of  useable to offered is less than a certain fraction.  Clearly, if the

提供されることへのuseableにおいて、ある断片以下はそうですか? 明確に

computed useable window is small compared to the  offered  window,  this

提供された窓と比べて、計算されたuseableの窓が小さい、これ

means  that a substantial amount of previously sent information is still

                                   8

それでも、かなりの量の以前に送られた情報が8であることを意味します。

in  the  pipeline  from  the sender to the receiver, which in turn means

送付者から受信機までのパイプラインでどれ、順番に、意味するか。

that the sender can count on being granted a larger  useable  window  in

送付者は、より大きいuseableの窓が与えられるのを頼りにすることができます。

the  future.    Until  the  useable window reaches a certain amount, the

未来。 useableの窓が、ある量に達するまで

sender should simply refuse to send anything.

送付者は、何でも送るのを単に拒否するべきです。

     Simple experiments suggest that the exact value of the ratio is not

簡単な実験は、比率の正確な値がそうでないと示唆します。

very important, but that a value of about 25 percent  is  sufficient  to

非常に重要であることで、およそ25パーセントのそのa値だけが十分です。

avoid  SWS  and  achieve reasonable throughput, even for machines with a

SWSを避けてください、そして、aでマシンさえのための妥当なスループットを達成してください。

small offered window.    An  additional  enhancement  which  might  help

小さい提供された窓。 助けるかもしれない追加増進

throughput  would be to attempt to hold off sending until one can send a

スループットは1つがaを送ることができるまで発信しながら距離を保つのを試みるだろうことです。

maximum size segment.  Another enhancement would be to send anyway, even

最大サイズセグメント。 別の増進は発信するだろうというのさえことです。

if the ratio is small, if the useable window is sufficient to  hold  the

useableの窓が保持するために十分であるなら、比率はわずかです。

data available up to the next "push point".

次の「プッシュポイント」まで利用可能なデータ。

     This algorithm at the sender end is very simple.  Notice that it is

送付者終わりのこのアルゴリズムは非常に簡単です。 通知

not  necessary  to  set  a timer to protect against protocol lockup when

タイマにプロトコル留置所に対していつを保護するように設定するには、必要ではありません。

postponing the  send  operation.    Further  acknowledgements,  as  they

延期、操作を送ってください。 それらでのさらなる承認

arrive,  will  inevitably change the ratio of offered to useable window.

到着してください、そして、必然的に提供される対useableの窓の比率を変えるでしょう。

(To see this, note that when all the data in the  catanet  pipeline  has

(これを見るには、catanetパイプラインのすべてのデータが注意したときには、それに注意してください。

arrived  at  the  receiver,  the resulting acknowledgement must yield an

受信機、承認がもたらさなければならない結果になるのに到着します。

offered window and  useable  window  that  equal  each  other.)  If  the

互いと等しい提供された窓とuseable窓。) the

expected  acknowledgements  do  not arrive, the retransmission mechanism

予想された承認は到着しないで、「再-トランスミッション」はメカニズムです。

will come into play to assure that something finally happens.  Thus,  to

何かが最終的に起こることを保証するために、活動し始めるでしょう。 このようにして

add  this  algorithm  to an existing TCP implementation usually requires

通常、既存のTCP実現へのこのアルゴリズムが必要であると言い足してください。

one line of code.  As part of the send algorithm it is already necessary

コードの1つの行。 離れている、既に必要な状態でアルゴリズムを送ってください。

to compute the useable window from the offered window.  It is  a  simple

提供された窓からuseableの窓を計算するために。 それはa簡単です。

matter  to add a line of code which, if the ratio is less than a certain

                                   9

比率が、ある9より少ないなら、線を加える件はどれをコード化するか。

percent,  sets  the  useable  window to zero.  The results of SWS are so

パーセント、useableがゼロまで窓を付けるセット。 SWSの結果はそうです。

devastating that no sender  should  be  without  this  simple  piece  of

どんな送付者もこの簡単な断片なしでいるべきでない荒らすこと

insurance.

保険。

     5.  Improved Acknowledgement Algorithms

5. 改良された承認アルゴリズム

     In the beginning of this paper, an overly simplistic implementation

この紙の始まり、ひどく安易な実現で

of  TCP  was described, which led to SWS.  One of the characteristics of

TCP(SWSに通じた)は説明されました。 特性の1つ

this implementation was that the  recipient  of  data  sent  a  separate

この実現はデータの受取人が別々の状態でaを送ったということでした。

acknowledgement  for  every  segment  that it received.  This compulsive

それが受けたあらゆるセグメントのための承認。 これほど強制的です。

acknowledgement  was  one  of  the   causes   of   SWS,   because   each

承認がSWSの原因の1つであった、それぞれ

acknowledgement provided some new useable window, but even if one of the

しかし、承認が、ある新しいuseableの窓を提供した、1つ

algorithms  described  above  is  used to eliminate SWS, overly frequent

上で説明されたアルゴリズムは、SWSを排除するのにおいて中古であって、ひどく頻繁です。

acknowledgement still has  a  substantial  problem,  which  is  that  it

承認にはかなりの問題がまだある、(それです)それ

greatly  increases the processing time at the sender's end.  Measurement

送付者の処理時間方で大いに増加します。 測定

of TCP implementations, especially on large operating systems,  indicate

特に大きいオペレーティングシステムでは、TCP実現は示します。

that  most  of  the  overhead  of  dealing  with a segment is not in the

セグメントに対処するオーバーヘッドの大部分がありません。

processing at the TCP or IP level, but simply in the scheduling  of  the

TCPかIPレベルにもかかわらず、単にスケジューリングでは、処理します。

handler which is required to deal with the segment.  A steady dribble of

そうする操作者がセグメントに対処するのが必要です。 台はしたたります。

acknowledgements  causes a high overhead in scheduling, with very little

承認はわずかでスケジューリングにおける高いオーバーヘッドを引き起こします。

to show for it.  This waste is to be avoided if possible.

それのために示すために。 この浪費はできれば、避けられることです。

     There are two reasons  for  prompt  acknowledgement.    One  is  to

迅速な承認の2つの理由があります。 1つがあります。

prevent  retransmission.  We will discuss later how to determine whether

「再-トランスミッション」を防いでください。 私たちは、後で決定するためにその方法について議論するつもりです。

unnecessary  retransmission  is  occurring.    The  other   reason   one

不要な「再-トランスミッション」は現れています。 もう片方の理由1

acknowledges  promptly  is  to permit further data to be sent.  However,

承認、即座に、詳しいデータが送られることを許可することになっています。 しかしながら

the previous section makes quite clear that it is not  always  desirable

セクションがそれがいつも望ましいというわけではないのがかなり明確にする前

to send a little bit of data, even though the receiver may have room for

                                   10

受信機には10の余地があるかもしれませんが、少しのデータを送るために

it.    Therefore,  one  can  state  a  general  rule  that  under normal

それ。 したがって、人は、司令官が標準の下でそれを統治すると述べることができます。

operation, the receiver of data need not,  and  for  efficiency  reasons

操作、データの受信機がそうする必要はない、効率理由

should  not,  acknowledge  the data unless either the acknowledgement is

承認が承認するべきでないなら、データを承認するべきであってください。

intended to produce an increased useable window, is necessary  in  order

生産することを意図して、増加するuseableの窓がオーダーで必要です。

to  prevent  retransmission  or  is  being  sent  as  part  of a reverse

「再-トランスミッション」を防ぐか、または逆の一部として送ります。

direction segment being sent for some other reason.  We will consider an

ある他の理由で送られる指示セグメント。 私たちは考えるつもりです。

algorithm to achieve these goals.

これらの目標を達成するアルゴリズム。

     Only the recipient of  the  data  can  control  the  generation  of

缶が世代を制御するデータの受取人だけ

acknowledgements.    Once  an  acknowledgement  has  been  sent from the

承認。 かつての承認から、発信しました。

receiver back to the sender, the sender must process it.   Although  the

送付者への受信機後部、送付者はそれを処理しなければなりません。 the

extra overhead is incurred at the sender's end, it is entirely under the

余分なオーバーヘッドは送付者の方で被られて、それは完全に下です。

receiver's  control.  Therefore, we must now describe an algorithm which

受信機のコントロール。 したがって、私たちが現在アルゴリズムを説明しなければならない、どれ

occurs at the receiver's end.  Obviously, the algorithm  must  have  the

受信機の終わりに起こります。 明らかに、アルゴリズムは持たなければなりません。

following  general form; sometimes the receiver of data, upon processing

次の一般的なフォーム。 時々処理に関するデータの受信機

a segment, decides not to send an acknowledgement now, but  to  postpone

aは、区分して、現在、承認を送るのではなく、延期すると決めます。

the  acknowledgement until some time in the future, perhaps by setting a

将来、いつか、そして、恐らくaを設定するのによる承認

timer.  The peril of this approach  is  that  on  many  large  operating

タイマ。 多くでは、このアプローチの危険は、作動しながら、そんなに大きいです。

systems  it  is  extremely costly to respond to a timer event, almost as

ほとんどタイマ出来事に反応するのが非常に高価であるシステム

costly as to respond to an incoming segment.  Clearly, if  the  receiver

高価である、入って来るセグメントに反応するために。 明確に受信機です。

of  the data, in order to avoid extra overhead at the sender end, spends

データでは、送付者におけるオーバーヘッドは、エキストラを避けるために終わって、費やされます。

a great deal of time responding to timer interrupts, no overall  benefit

タイマ割込みに応じる時間、多くの総合的な利益がありません。

has been achieved, for efficiency at the sender end is achieved by great

送付者終わりの効率がすばらしいことによって達成されるので、達成されました。

thrashing  at  the  receiver end.  We must find an algorithm that avoids

終わって、受信機を打ってください。 私たちはそれが避けるアルゴリズムを見つけなければなりません。

both of these perils.

これらの危険の両方。

     The following scheme seems a good compromise.  The receiver of data

                                   11

以下の計画は良い妥協に見えます。 データ11の受信機

will   refrain   from   sending   an   acknowledgement   under   certain

承認より負かすのを確かな状態で控えるでしょう。

circumstances, in which case it must set a timer which  will  cause  the

事情であり、その場合、それはタイマを設定しなければなりません(原因を望んでいます)。

acknowledgement  to be sent later.  However, the receiver should do this

後で送られる承認。 しかしながら、受信機はこれをするはずです。

only where it is a reasonable guess that some other event will intervene

ある他の出来事に介入するのが、合理的な推測であるところだけ

and prevent the necessity of the timer  interrupt.    The  most  obvious

そして、タイマ割込みの必要性を防いでください。 最も明白

event  on  which  to depend is the arrival of another segment.  So, if a

よる出来事は別のセグメントの到着です。 そのようにaであるなら

segment arrives, postpone sending an  acknowledgement  if  both  of  the

セグメントは到着して、両方であるなら承認を送るのを延期してください。

following  conditions  hold.    First,  the  push  bit is not set in the

次の状態は成立します。 最初に、プッシュビットは設定されません。

segment, since it is a reasonable assumption that  there  is  more  data

それが、より多くのデータがあるという妥当な想定であることでのセグメント

coming  in  a  subsequent  segment.   Second, there is no revised window

その後のセグメントで登場します。 2番目に、改訂された窓が全くありません。

information to be sent back.

返送される情報。

     This algorithm will insure that the timer, although set, is  seldom

このアルゴリズムは、設定されますが、タイマがめったにそうであることを保障するでしょう。

used.    The  interval  of  the  timer is related to the expected inter-

使用にされる。 タイマの間隔が予想に関連する、相互

segment delay, which is in turn a function  of  the  particular  network

セグメント遅れ。(その遅れは順番に、aが特定のネットワークを機能させるということです)。

through  which  the  data  is  flowing.    For the Arpanet, a reasonable

データは流れています。 Arpanet、妥当なaのために

interval seems to be 200 to 300 milliseconds.  Appendix A  describes  an

間隔は200〜300ミリセカンドであるように思えます。 付録Aは説明します。

adaptive algorithm for measuring this delay.

この遅れを測定するための適応型のアルゴリズム。

     The section on improved window algorithms described both a receiver

改良された窓のアルゴリズムのセクションが両方について説明した、受信機

algorithm  and  a  sender  algorithm,  and suggested that both should be

アルゴリズムと送付者アルゴリズム、両方がそうであるべきであると示唆します。

used.  The reason for this is now clear.  While the sender algorithm  is

使用にされる。 この理由は現在、明確です。 送付者アルゴリズムはそうですが

extremely  simple,  and  useful  as insurance, the receiver algorithm is

保険として非常に簡単であって、役に立って、受信機アルゴリズムはそうです。

required in order that this improved acknowledgement strategy work.   If

これが承認戦略仕事を改良したように、必要です。 if

the  receipt  of every segment causes a new window value to be returned,

あらゆるセグメントの領収書で、新しい窓の値を返します。

then of necessity  an  acknowledgement  will  be  sent  for  every  data

必要なその時、あらゆるデータのために承認を送るでしょう。

segment.    When, according to the strategy of the previous section, the

                                   12

セグメント。 前項、12のものの戦略に従ったいつ

receiver  determines  to artificially reduce the offered window, that is

受信機は、すなわち、提供された窓を人工的に減少させることを決定します。

precisely the circumstance under which an acknowledgement  need  not  be

正確に承認がそうである必要はない状況

sent.      When   the   receiver   window  algorithm  and  the  receiver

送る。 時は、受信機窓のアルゴリズムと受信機です。

acknowledgement algorithm are  used  together,  it  will  be  seen  that

承認アルゴリズムが一緒に使用されて、それが目にふれる、それ

sending  an  acknowledgement  will  be triggered by one of the following

承認を送るのは以下の1つによって引き起こされるでしょう。

events.  First, a push bit has been received.  Second, a temporary pause

出来事。 まず最初に、プッシュビットを受け取りました。 2番目、一服

in the data stream is detected.  Third,  the  offered  window  has  been

データでは、流れは検出されます。 3番目に、提供された窓がありました。

artificially reduced to one-half its actual value.

人工的に、半分への実価を減少させました。

     In the beginning of this section, it was pointed out that there are

初めに、このセクションでは、あると指摘されました。

two  reasons  why  one must acknowledge data.  Our consideration at this

2つの理由1がデータを承認しなければなりません。 これでの私たちの考慮

point has been concerned only with the first,  that  an  acknowledgement

ポイントは1番目だけに関係があって、それは承認です。

must  be  returned as part of triggering the sending of new data.  It is

新しいデータの発信の引き金となる一部として返さなければなりません。 それはそうです。

also necessary to acknowledge  whenever  the  failure  to  do  so  would

また、そうしないことが承認するだろうというときはいつも、承認するために、必要です。

trigger retransmission by the sender.  Since the retransmission interval

送付者で「再-トランスミッション」の引き金となってください。 再送信間隔以来

is  selected  by  the  sender,  the  receiver  of the data cannot make a

送付者によって選択されて、データの受信機がaを作ることができないということです。

precise  determination  of  when  the  acknowledgement  must  be   sent.

承認を送らなければならない時に関する正確な決断。

However,   there   is   a  rough  rule  the  sender  can  use  to  avoid

しかしながら、送付者が避けるのに使用できる荒い規則があります。

retransmission, provided that the receiver is reasonably well behaved.

「再-トランスミッション」受信機が合理的によく反応すれば。

     We will assume that sender of the data uses the optional  algorithm

私たちは、データの送付者が任意のアルゴリズムを使用すると思うつもりです。

described  in  the  TCP  specification,  in which the roundtrip delay is

TCP仕様では、説明されます。そこでは、往復の遅れがそうです。

measured using an exponential decay smoothing algorithm.  Retransmission

指数の腐敗スムージングアルゴリズムを使用することで、測定されます。 Retransmission

of a segment occurs if the measured delay for that segment  exceeds  the

aでは、セグメントがそのセグメントのための測定遅れであるなら起こる、超過

smoothed  average  by  some  factor.  To see how retransmission might be

何らかの要素で平均を整えました。 「再-トランスミッション」がどうあるかもしれないかを見るために

triggered, one must consider the pattern  of  segment  arrivals  at  the

引き金となる、必須がセグメント到着のパターンを考える1

receiver.   The goal of our strategy was that the sender should send off

                                   13

受信機私たちの戦略の目標は送付者が13を送るべきであるということでした。

a  number of segments in close sequence, and receive one acknowledgement

多くのセグメントが、中に系列を閉じて、ある承認を受けます。

for the whole burst.  The  acknowledgement  will  be  generated  by  the

全体には、はち切れてください。 承認は発生するでしょう。

receiver  at  the time that the last segment in the burst arrives at the

当時炸裂における最後のセグメントが到着する受信機

receiver.  (To ensure the prompt  return  of  the  acknowledgement,  the

受信機(承認の迅速な復帰を確実にするために

sender  could  turn on the "push" bit in the last segment of the burst.)

送付者は炸裂の最後のセグメントで「プッシュ」ビットをつけることができました。)

The delay observed at the sender between the initial transmission  of  a

aの初期のトランスミッションの間の送付者で観測された遅れ

segment  and  the  receipt  of the acknowledgement will include both the

承認のセグメントと領収書は両方を含むでしょう。

network transit time, plus the  holding  time  at  the  receiver.    The

受信機でトランジット時間、および把持時間をネットワークでつないでください。

holding  time  will be greatest for the first segments in the burst, and

そして把持時間が炸裂における最初のセグメントを最大級である。

smallest for the last segments  in  the  burst.    Thus,  the  smoothing

炸裂における最後のセグメントにおいて、最も小さいです。 その結果、スムージング

algorithm  will  measure  a  delay  which is roughly proportional to the

アルゴリズムはおよそ比例している遅れを測定するために望んでいます。

average roundtrip delay for all the segments in  the  burst.    Problems

炸裂ですべてのセグメントのための往復の遅れを平均してください。 問題

will  arise  if  the  average  delay  is  substantially smaller than the

平均した遅れが実質的により小さいなら、起こるでしょう。

maximum delay  and  the  smoothing  algorithm  used  has  a  very  small

アルゴリズムが使用した最大の遅れとスムージングで、aは非常に小さくなります。

threshold  for  triggering retransmission.  The widest variation between

「再-トランスミッション」の引き金となるための敷居。 間の最も広い変化

average and maximum delay  will  occur  when  network  transit  time  is

ネットワークトランジット時間が起こるとき、平均して最大の遅れは起こるでしょう。

negligible, and all delay is processing time.  In this case, the maximum

取るにたらなさ、すべての遅れが処理時間です。 この場合最大

will  be  twice  the  average  (by simple algebra) so the threshold that

平均した(簡単な代数による)そうの2倍が敷居であるつもりであった、それ

controls retransmission should be somewhat more than a factor of two.

コントロール「再-トランスミッション」は2の要素よりいくらか多いはずです。

     In practice, retransmission of the first segments of  a  burst  has

実際には、炸裂の最初のセグメントの「再-トランスミッション」はそうしました。

not  been  a  problem because the delay measured consists of the network

測定された遅れがネットワークから成るので問題ではありません。

roundtrip  delay,  as  well  as  the  delay  due  to   withholding   the

往復の遅れ、および源泉徴収による遅れ

acknowledgement,  and the roundtrip tends to dominate except in very low

まさしくその安値を除いて、支配します承認、および往復旅行が、傾向がある。

roundtrip time situations (such as when sending to one's self  for  test

往復の時間状況、(そのようなものテストのために人の自己に発信すると

purposes).    This low roundtrip situation can be covered very simply by

目的) 非常に単にこの低往復の状況をカバーできます。

including a minimum value below which  the  roundtrip  estimate  is  not

往復の見積りがそうでない最小値を含んでいます。

permitted to drop.

                                   14

低下することが許可されています。 14

     In  our  experiments  with  this  algorithm,  retransmission due to

このアルゴリズムがある私たちの実験では、「再-トランスミッション」はそうします。

faulty calculation of the roundtrip delay occurred only once,  when  the

往復の遅れの不完全な計算が一度だけ起こった、いつ

parameters  of  the exponential smoothing algorithm had been misadjusted

指数のスムージングアルゴリズムのパラメタは調整ずれでした。

so that they were only  taking  into  account  the  last  two  or  three

彼らが最後の2か3しか考慮に入れていなかったように

segments  sent.   Clearly, this will cause trouble since the last two or

セグメントは発信しました。 または最後の2以来明確に、これが問題を起こす。

three segments of any burst are the  ones  whose  holding  time  at  the

どんな炸裂の3つのセグメントも把持が調節されるものです。

receiver is minimal, so the resulting total estimate was much lower than

受信機が最小限ので、結果として起こる見積総額ははるかに低かったです。

appropriate.   Once the parameters of the algorithm had been adjusted so

適切。 一度、アルゴリズムのパラメタは非常に調整されたことがありました。

that the number of segments taken into account was  approximately  twice

大体

the  number  of  segments  in  a burst of average size, with a threshold

敷居に従った平均のサイズの炸裂における、セグメントの数

factor of 1.5, no further retransmission has ever been identified due to

1.5の要素、いいえ一層の「再-トランスミッション」が今までに特定されたことがある

this problem, including when sending to ourself and  when  sending  over

この問題、移動しながら自らといつまで発信するかときの包含

high delay nets.

高い遅れは網状になります。

     6.  Conservative Vs. Optimistic Windows

6. 保守的な人 楽観的なWindows

     According  to the TCP specification, the offered window is presumed

TCP仕様に従って、提供された窓は推定されます。

to have some relationship to the amount of data which  the  receiver  is

データ量との受信機がそうである何らかの関係を持つために

actually  prepared  to receive.  However, it is not necessarily an exact

受信するために実際に準備されています。 しかしながら、それが必ずそうであるというわけではない、正確

correspondence.  We will use the term "conservative window" to  describe

通信。 私たちは説明する「保守的な窓」という用語を使用するつもりです。

the case where the offered window is precisely no larger than the actual

ケース、どこで、提供された窓は実際であるより正確に大きくないか。

buffering  available.  The drawback to conservative window algorithms is

利用可能なバッファリング。 保守的な窓のアルゴリズムへの欠点はそうです。

that they can produce very low throughput in long delay situations.   It

彼らは長時間の遅延状況における非常に低いスループットを作り出すことができます。 それ

is easy to see that the maximum input of a conservative window algorithm

最大が窓のアルゴリズムを保守的な人に入力したのを確実にするのは簡単です。

is  one  bufferfull  every  roundtrip  delay  in the net, since the next

次以来1bufferfullがネットのあらゆる往復の遅れですか?

bufferfull cannot be launched until the  updated  window/acknowledgement

アップデートされた窓/承認までbufferfullを始めることができません。

information from the previous transmission has made the roundtrip.

                                   15

前のトランスミッションからの情報は往復旅行をしました。 15

     In  certain  cases,  it  may  be  possible  to increase the overall

ある場合には、総合的を増加させるのは可能であるかもしれません。

throughput of the transmission by increasing the offered window over the

提供された窓を上回るのによるトランスミッションに関するスループット

actual buffer available at the receiver.  Such a strategy we  will  call

利用可能な実際のバッファ. 受信機の私たちが呼ぶつもりであるそのような戦略

an  "optimistic  window" strategy.  The optimistic strategy works if the

「楽観的な窓」戦略。 楽観的な戦略は利きます。

network delivers the data to the recipient sufficiently slowly  that  it

ネットワークが十分ゆっくりデータを受取人に送る、それ、それ

can  process  the  data fast enough to keep the buffer from overflowing.

バッファがあふれるのを妨げることができるくらい速くデータを処理できます。

If the receiver is faster than the sender, one could, with luck,  permit

受信機が送付者より速いなら、運で、1つは可能にするかもしれません。

an infinitely optimistic window, in which the sender is simply permitted

無限に楽観的な窓。(そこでは、送付者が単に受入れられます)。

to send full-speed.  If the sender is faster than the receiver, however,

全速力で送るために。 しかしながら、送付者が受信機より速いなら

and the window is too optimistic, then some segments will cause a buffer

そして、窓が楽観的過ぎる、そして、いくつかのセグメントがバッファを引き起こすでしょう。

overflow,  and  will  be  discarded.  Therefore, the correct strategy to

あふれてください、そして、捨てられてくださいだろう。 したがって、正しい戦略

implement an optimistic window is to  increase  the  window  size  until

楽観的な窓がある道具はウィンドウサイズを増加させます。

segments  start to be lost.  This only works if it is possible to detect

セグメントは失われ始めます。 それが検出するのにおいて可能である場合にだけ、これは働いています。

that the segment has been lost.  In  some  cases,  it  is  easy  to  do,

セグメントは失われました。 いくつかの場合、それはしやすいです。

because  the  segment  is  partially processed inside the receiving host

セグメントが受信ホストの中で部分的に処理されるので

before it is thrown away.  In other cases, overflows may actually  cause

以前、それは捨てられます。 他の場合では、オーバーフローが実際にそうするかもしれない、原因

the network interface to be clogged, which will cause the segments to be

妨げられるべきネットワーク・インターフェース。(意志はセグメントはそのネットワーク・インターフェースを引き起こします)。

lost  elsewhere  in the net.  It is inadvisable to attempt an optimistic

ネットにおけるほかの場所では、失われています。 それが試みるのにおいて勧められない、楽観的

window strategy unless one is certain that the algorithm can detect  the

1つがアルゴリズムが検出されることができるのを確信していない場合、戦略に窓を付けてください。

resulting  lost  segments.  However, the increase in throughput which is

結果になるのはセグメントを失いました。 しかしながら、そうするスループットの増加

possible from optimistic windows is quite substantial.  Any systems with

楽観的であるのから、窓がかなり実質的であることを可能です。 どんなシステム

small buffer space should seriously consider  the  merit  of  optimistic

小さいバッファ領域は真剣に楽観的の長所を考えるべきです。

windows.

窓。

     The  selection  of an appropriate window algorithm is actually more

適切な窓のアルゴリズムの種類は実際により多いです。

complicated than even the above  discussion  suggests.    The  following

複雑である、上の議論さえ示すより。 以下

considerations  are  not  presented  with  the  intention  that  they be

                                   16

それらが16であるという意志は問題に与えられません。

incorporated  in  current  implementations of TCP, but as background for

TCPの現在の実現にもかかわらず、バックグラウンドとして盛込みます。

the sophisticated designer who is attempting to understand how  his  TCP

その方法を理解しているのを試みている洗練されたデザイナー、彼のTCP

will  respond  to  a variety of networks, with different speed and delay

異なった速度と遅れでさまざまなネットワークに応じるでしょう。

characteristics.  The particular pattern of windows and acknowledgements

特性。 窓と承認の特定のパターン

sent from receiver to sender influences two characteristics of the  data

発信して、送付者への受信機はデータの2つの特性に影響を及ぼします。

being  sent.    First, they control the average data rate.  Clearly, the

送ること。 まず最初に、彼らは平均したデータ信号速度を制御します。 明確に

average rate of the  sender  cannot  exceed  the  average  rate  of  the

送付者の平均相場は平均相場を超えることができません。

receiver,  or  long-term  buffer  overflow  will  occur.    Second, they

受信機の、または、長期のバッファオーバーフローは起こるでしょう。 2番目に、それら

influence the burstiness of the data coming from the sender.  Burstiness

送付者から来るデータのburstinessに影響を及ぼしてください。 Burstiness

has both advantages and disadvantages.  The advantage of  burstiness  is

利点と損失の両方を持っています。 burstinessの利点はそうです。

that  it  reduces  the  CPU processing necessary to send the data.  This

それはデータを送るのに必要なCPU処理を抑えます。 これ

follows from the observed fact, especially on large machines, that  most

観察事実から、特に大きいマシンのそれに最も続きます。

of  the  cost  of sending a segment is not the TCP or IP processing, but

発信の費用では、セグメントは、しかし、処理されるTCPでなくて、またIPでもありません。

the scheduling overhead of getting started.

得ることのスケジューリングオーバーヘッドは始まりました。

     On the other hand, the disadvantage of burstiness is  that  it  may

他方では、burstinessの難点はそうするかもしれないということです。

cause  buffers  to overflow, either in the eventual recipient, which was

バッファがどちらか最後の受取人にあふれることを引き起こしてください、そして、どれがありましたか?

discussed above, or in an intermediate gateway,  a  problem  ignored  in

上で議論するか、または中で中間ゲートウェイ、問題で無視されます。

this paper.  The algorithms described above attempts to strike a balance

この紙。 バランスをとる試みを超えて説明されたアルゴリズム

between  excessive  burstiness,  which  in  the  extreme cases can cause

過度のburstinessの間で。極端な場合では、burstinessは引き起こされる場合があります。

delays because a burst is  not  requested  soon  enough,  and  excessive

aがはち切れたので、遅れはすぐ、十分であって、過度で要求されません。

fragmentation   of  the  data  stream  into  small  segments,  which  we

小さいセグメントへのデータ・ストリームの断片化、どれ、私たち

identified as Silly Window Syndrome.

Silly Window Syndromeとして、特定されます。

     Under conditions of extreme delay  in  the  network,  none  of  the

なにものネットワークにおける、極端な遅れの下の状態

algorithms   described   above   will   achieve   adequate   throughput.

上で説明されたアルゴリズムは適切なスループットを実現するでしょう。

Conservative window algorithms  have  a  predictable  throughput  limit,

                                   17

保守的な窓のアルゴリズムには、予測できるスループット限界、17があります。

which  is one windowfull per roundtrip delay.  Attempts to solve this by

往復の遅れあたり1windowfullです。 これを解決する試み

optimistic window strategies may  cause  buffer  overflows  due  to  the

楽観的な窓の戦略はバッファオーバーフローを引き起こすかもしれません。

bursty  nature  of the arriving data.  A very sophisticated way to solve

到着データのbursty本質。 ずっと解決するために非常に洗練にされる

this is for the receiver, having measured by some  means  the  roundtrip

どうでも往復旅行を測定したので、これは受信機のためのものです。

delay  and  intersegment  arrival rate of the actual connection, to open

遅れと実際の接続の戸外へのintersegment到着率

his window, not in one optimistic increment of gigantic proportion,  but

巨大な部分の1つの楽観的な増分でないのにおける彼の窓だけ

in  a number of smaller optimistic increments, which have been carefully

多くの慎重にそうであるよりわずかな楽観的な増分で

spaced using a timer so that the resulting smaller bursts  which  arrive

したがって、タイマを使用することで区切られる、それ、到着する結果として起こるより小さい炸裂

are each sufficiently small to fit into the existing buffers.  One could

それぞれが既存のバッファに収まることができるくらい小さいですか? 1はそうすることができました。

visualize this as a number of requests flowing backwards through the net

ネットを通して後方に流れる多くの要求としてこれを想像してください。

which trigger in return a number of bursts which flow back spaced evenly

どれが代わりに、流れ後部が均等に区切った多くの炸裂の引き金となりますか。

from  the  sender  to  the  receiver.    The  overall result is that the

送付者から受信機まで. 総合的な結果はそれです。

receiver uses the window mechanism to  control  the  burstiness  of  the

受信機はburstinessを制御するウィンドウメカニズムを使用します。

arrivals, and the average rate.

到着、および平均相場。

     To  my knowledge, no such strategy has been implemented in any TCP.

私が知っている限り、どんなそのような戦略もどんなTCPでも実行されていません。

First, we do not normally have delays high enough to require  this  kind

まず最初に、私たちは通常遅れをこの種類を必要とすることができるくらい高くしません。

of  treatment.    Second,  the  strategy described above is probably not

処理について。 2番目に、上で説明された戦略はたぶんそうしていません。

stable unless it is very carefully balanced.  Just as buses on a  single

それがない場合、うまやは非常に慎重にバランスをとりました。 ちょうどシングルのバスとして

bus  route tend to bunch up, bursts which start out equally spaced could

バス道路は、束ねている傾向があって、等しく区切られた状態で始める炸裂はそうすることができました。

well end up piling into each other, and forming the single  large  burst

互いに押し入って、結局、単一の大きい炸裂をよく形成してください。

which  the  receiver was hoping to avoid.  It is important to understand

避けます受信機が、望んでいた。 分かるのは重要です。

this extreme case, however, in order to  understand  the  limits  beyond

しかしながら、この極端は、余っている限界を理解するためにケースに入れます。

which  TCP,  as normally implemented, with either conservative or simple

通常、実行されているとしてのどちらかが保守的であるか、または簡単のどのTCP

optimistic windows can be expected to  deliver  throughput  which  is  a

楽観的な窓がaであるスループットを送ると予想できます。

reasonable percentage of the actual network capacity.

                                   18

実際のネットワーク容量の妥当な割合。 18

     7.  Conclusions

7. 結論

     This  paper  describes  three  simple  algorithms  for  performance

この論文は性能のための3つの簡単なアルゴリズムを説明します。

enhancement in TCP, one at the sender end and two at the receiver.   The

TCP、送付者終わりの1と受信機の2における増進。

sender  algorithm  is  to  refrain from sending if the useable window is

送付者アルゴリズムはuseableの窓が控えるなら発信するのを控えることです。

smaller than 25 percent of the offered window.  The receiver  algorithms

提供された窓の25パーセントより小さいです。 受信機アルゴリズム

are first, to artificially reduce the offered window when processing new

新しい状態で処理するとき、提供された窓を人工的に減少させるためには1番目です。

data  if  the  resulting  reduction  does  not  represent more than some

データは結果として起こる減少であるならいくつか以上を表しません。

fraction, say 50 percent, of the actual space available, and second,  to

たとえば、断片、利用可能な実際のスペース、および2番目の50パーセント

refrain  from  sending an acknowledgment at all if two simple conditions

2つの単純条件であるなら全く承認を送るのを控えてください。

hold.

成立してください。

     Either of these algorithms will prevent the worst aspects of  Silly

これらのアルゴリズムのどちらかがSillyの最も悪い局面を防ぐでしょう。

Window  Syndrome, and when these algorithms are used together, they will

Syndromeに窓を付けてください。そうすれば、これらのアルゴリズムが一緒に使用されるとき、それらは望んでいます。

produce substantial improvement in CPU utilization, by  eliminating  the

排泄することによって、CPU使用率における実質的な改善を起こしてください。

process of excess acknowledgements.

余分な承認の過程。

     Preliminary  experiments  with  these  algorithms suggest that they

これらのアルゴリズムがある予備試験がそれを示す、それら

work, and work very well.  Both the sender and receiver algorithms  have

働いてください、そして、非常によく働いてください。 送付者と受信機アルゴリズムにはある両方

been  shown  to  eliminate  SWS,  even  when  talking  to  fairly  silly

かなり愚かであると話すときさえ、SWSを排除するために、示されます。

algorithms at the other end.  The Multics  mailer,  in  particular,  had

もう片方におけるアルゴリズムは終わります。 郵送者が特定に持っていたMultics

suffered substantial attacks of SWS while sending large mail to a number

大きいメールを数に送る間のSWSの受けているかなりの攻撃

of  hosts.   We believe that implementation of the sender side algorithm

ホストについて。 私たちは送付者サイドアルゴリズムのその実現を信じています。

has  eliminated  every  known  case  of  SWS  detected  in  our  mailer.

私たちの郵送者に検出されたSWSのあらゆる知られているケースを排除しました。

Implementation  of  the  receiver  side  algorithm  produced substantial

実質的に作成された受信機サイドアルゴリズムの実現

improvements of CPU time when Multics was the sending system.    Multics

Multicsが送付システムであったCPU時間の改良。 Multics

is  a  typical  large  operating system, with scheduling costs which are

そうするスケジューリングコストがある典型的な大きいオペレーティングシステムです。

large compared to the actual  processing  time  for  protocol  handlers.

                                   19

多、はプロトコル操作者のための実際の処理時間と比較されました。 19

Tests were done sending from Multics to a host which implemented the SWS

Multicsからホストまでテストに発信しましたSWSを実行した。

suppression  algorithm,  and  which  could  either  refrain  or not from

抑圧アルゴリズムとどれが控えられることができたか。

sending acknowledgements on each segment.  As predicted, suppressing the

各セグメントに承認を送ります。 抑圧して、予測されます。

return acknowledgements did not influence the throughput for large  data

リターン承認は大きいデータのためのスループットに影響を及ぼしませんでした。

transfer  at  all,  since the throttling effect was elsewhere.  However,

阻止効果がほかの場所にあったので、全く移してください。 しかしながら

the CPU time required to process the data at the Multics end was cut  by

CPU時間がMulticsエンドのデータが切られた過程に必要です。

a  factor  of  four  (In  this experiment, the bursts of data which were

4の要素、(この実験、そうするデータの炸裂

being sent were approximately eight  segments.    Thus,  the  number  of

送るのが、およそ8つのセグメントであったということです。 その結果、数

acknowledgements in the two experiments differed by a factor of eight.)

2つの実験における承認は8の要素で異なりました。)

     An  important  consideration in evaluating these algorithms is that

これらのアルゴリズムを評価することにおける重要な考慮すべき事柄はそれです。

they must not cause the protocol implementations to deadlock.    All  of

彼らは行き詰まる実現をプロトコルに引き起こしてはいけません。 すべて

the  recommendations  in this document have the characteristic that they

推薦には特性が本書ではある、それ、それら

suggest one refrain  from  doing  something  even  though  the  protocol

プロトコルですが、何かをするので、1つのリフレインを示してください。

specification  permits one to do it.  The possibility exists that if one

仕様は、1つがそれをすることを許可します。 可能性が存在している、それ、1です。

refrains from doing something now one may never get to do it later,  and

そして現在の何かに1つをするのからのリフレインが、後でそれをし決して始めないかもしれない。

both  ends will halt, even though it would appear superficially that the

表面的に現れるでしょうが、両端が停止する、それ

transaction can continue.

取引は続くことができます。

     Formally, the idea that things continue to work is referred  to  as

正式に、いろいろなことが、働き続けているという考えは示されます。

"liveness".    One  of  the  defects  of ad hoc solutions to performance

「活性。」 性能のその場かぎりの解決の欠陥の1つ

problems is the possibility that two different approaches will  interact

問題は2つの異なるアプローチが相互作用する可能性です。

to  prevent  liveness.   It is believed that the algorithms described in

活性を防ぐために。 アルゴリズムがコネについて説明したと信じられています。

this paper are always live, and that is one of the reasons why there  is

この紙はいつもライブです、そして、それはある理由の1つです。

a strong advantage in uniform use of this particular proposal, except in

この特定の提案のコネ以外の一定の使用での強い利点

cases where it is explicitly demonstrated not to work.

それが働かないように明らかに示されるケース。

     The  argument  for liveness in these solutions proceeds as follows.

                                   20

これらの解決策の活性のための議論は以下の通り続きます。 20

First,  the sender algorithm can only be stopped by one thing, a refusal

まず最初に、1つのもの、拒否で送付者アルゴリズムを止めることができるだけです。

of the receiver to acknowledge sent data.    As  long  as  the  receiver

送られたデータを承認する受信機について。 受信機と同じくらい長いです。

continues  to  acknowledge  data, the ratio of useable window to offered

データ、useableの窓対提供されることの比率を承認し続けています。

window will approach one, and eventually the  sender  must  continue  to

窓は1つにアプローチするでしょう、そして、結局、送付者はアプローチし続けなければなりません。

send.    However,  notice  that the receiver algorithm we have advocated

発信してください。 しかしながら、それに注意してください、私たちが支持した受信機アルゴリズム

involves refraining from acknowledging.  Therefore, we certainly do have

承認するのを控えることを伴います。 したがって、確かに、私たちは持っています。

a situation where improper  operation  of  this  algorithm  can  prevent

このアルゴリズムの不適当な操作が防がれることができる状況

liveness.

活性。

     What  we  must show is that the receiver of the data, if it chooses

私たちが受信機がデータそれであるなら選ばれるということであることを示していなければならないこと

to refrain from acknowledging, will do so only for a short time, and not

そして承認するのを控えるために、短い間だけする。

forever.  The design of the algorithm described above  was  intended  to

いつまでも. 上で説明されたアルゴリズムのデザインは意図します。

achieve  precisely  this  goal:  whenever the receiver of data refrained

正確にこの目標を達成してください: データの受信機が控えたときはいつも

from sending an acknowledgement it was required to set  a  timer.    The

承認を送るので、それがタイマを設定するのに必要でした。 The

only  event  that  was  permitted to clear that timer was the receipt of

そのタイマをきれいにすることが許可された唯一の出来事は領収書でした。

another segment, which essentially reset the timer, and started it going

別のセグメント。(そのセグメントは、本質的にはタイマをリセットして、それを行かせ始めました)。

again.  Thus, an acknowledgement will be sent as soon  as  no  data  has

再び。 したがって、どんなデータも送らないとすぐに、承認を送るでしょう。

been received.  This has precisely the effect desired:  if the data flow

受け取ります。 これで、正確に効果を望んでいます: データが流れるなら

appears to be disrupted for any reason, the receiver responds by sending

いずれのためにも混乱させられて、推論してください、受信機が発信することによって応じるということであるように見えます。

an  up-to-date  acknowledgement.    In  fact,  the receiver algorithm is

最新の承認。 事実上、受信機アルゴリズムはそうです。

designed  to  be  more  robust  than  this,  for  transmission   of   an

これよりトランスミッションには強健になるように、設計されています。

acknowledgment is triggered by two events, either a cessation of data or

または承認が2回の出来事、データの休止で引き起こされる。

a  reduction in the amount of offered window to 50 percent of the actual

実際の50パーセントへの提供された窓の量の減少

value.    This  is  the  condition  which  will  normally  trigger   the

値。 これは状態です(通常、引き金を望んでいます)。

transmission of this acknowledgement.

                                   21

この承認の送信。 21

                               APPENDIX A

付録A

     Dynamic Calculation of Acknowledgement Delay

承認遅れのダイナミックな計算

     The  text  suggested  that  when  setting  a  timer to postpone the

延期するタイマを設定するとき、テキストはそれを示しました。

sending  of  an  acknowledgement,  a  fixed  interval  of  200  to   300

承認の発信、200〜300の固定間隔

milliseconds  would  work  properly  in  practice.    This  has not been

ミリセカンドは実際には適切に働いているでしょう。 これはありませんでした。

verified over a wide variety of network delays, and clearly if there  is

さまざまなネットワーク遅延に関して確かめられて、あれば、明確に確かめられます。

a  very  slow  net  which stretches out the intersegment arrival time, a

intersegment到着時間、aから伸びる非常に遅いネット

fixed interval will fail.  In a sophisticated TCP, which is expected  to

固定間隔は失敗するでしょう。 高性能のTCPで。(TCPは予想されます)。

adjust   dynamically   (rather   than   manually)  to  changing  network

ダイナミックに調整してください、(むしろ、手動)、ネットワークを変えること。

conditions, it would be appropriate to measure this interval and respond

状態であり、この間隔に測定して、応じるのは適切でしょう。

dynamically.  The following algorithm, which has been  relegated  to  an

ダイナミックに。 以下のアルゴリズム。(そのアルゴリズムは左遷されました)。

Appendix,  because  it  has not been tested, seems sensible.  Whenever a

それがテストされていないので、付録は分別があるように思えます。 いつ

segment arrives which does not have the push  bit  on  in  it,  start  a

それでオンにプッシュビットを持っていないセグメントが到着して、始めはaです。

timer,  which  runs  until  the  next  segment  arrives.   Average these

タイマ。(次のセグメントが到着するまで、そのタイマは動きます)。 これらを平均してください。

interarrival intervals, using an exponential  decay  smoothing  function

指数の腐敗スムージング機能を使用するinterarrival間隔

tuned  to take into account perhaps the last ten or twenty segments that

調整されて、恐らく最後の10か20を考慮に入れるのはそれを区分します。

have come in.  Occasionally, there will be a long  interarrival  period,

入りました。 時折、長いinterarrivalの期間があるでしょう。

even  for  a  segment  which is does not terminate a piece of data being

セグメントのためにさえ、どれがあるかが1つのデータ存在を終えません。

pushed, perhaps because a window has gone to zero or some glitch in  the

恐らく窓が中にゼロかいくつかの不調に行ったので、押されます。

sender  or  the  network  has held up the data.  Therefore, examine each

送付者かネットワークがデータを妨げました。 したがって、それぞれを調べてください。

interarrival interval, and discard it from the smoothing algorithm if it

間隔をinterarrivalして、それであるならスムージングアルゴリズムからそれを捨てます。

exceeds the current estimate by some amount, perhaps a ratio of  two  or

またはいくらかの量、恐らく2の比率に応じて現状見積金額を超えている。

four times.  By rejecting the larger intersegment arrival intervals, one

4回。 より大きいintersegment到着間隔、1を拒絶することによって

should obtain a smoothed estimate of the interarrival of segments inside

                                   22

22でセグメントのinterarrivalの平坦な見積りを得るべきです。

a  burst.   The number need not be exact, since the timer which triggers

炸裂。 数はタイマ以来どの引き金を強要するかことである必要はありません。

acknowledgement can add a fairly generous fudge factor to  this  without

承認缶がこれへのかなり寛大なファッジ要素を加える

causing  trouble  with  the  sender's  estimate  of  the  retransmission

送付者の「再-トランスミッション」の見積りで、問題を起こします。

interval, so long as the fudge factor is constant.

間隔はファッジ要素と同じくらい長い間、一定です。