RFC1016 日本語訳

Network Working Group                                            W. Prue
Request for Comments:  1016                                    J. Postel
                                                                     ISI
                                                               July 1987

Prueがコメントのために要求するワーキンググループW.をネットワークでつないでください: 1016 J.ポステルISI1987年7月

             Something a Host Could Do with Source Quench:

ホストがソース焼き入れでできたことが:

               The Source Quench Introduced Delay (SQuID)

ソース焼き入れは遅れを導入しました。(イカ)

Status of this Memo

このMemoの状態

   This memo is intended to explore the issue of what a host could do
   with a source quench.  The proposal is for each source host IP module
   to introduce some delay between datagrams sent to the same
   destination host.  This is an "crazy idea paper" and discussion is
   essential.  Distribution of this memo is unlimited.

このメモがホストがソース焼き入れでできたことが問題を探ることを意図します。 提案はそれぞれの送信元ホストIPモジュールが同じあて先ホストに送られたデータグラムの間に何らかの遅れを導入することです。 これは「気が狂った考え紙」です、そして、議論は不可欠です。 このメモの分配は無制限です。

Introduction

序論

   A gateway may discard Internet datagrams if it does not have the
   buffer space needed to queue the datagrams for output to the next
   network on the route to the destination network.  If a gateway
   discards a datagram, it may send a source quench message to the
   Internet source host of the datagram.  A destination host may also
   send a source quench message if datagrams arrive too fast to be
   processed.  The source quench message is a request to the host to cut
   back the rate at which it is sending traffic to the Internet
   destination.  The gateway may send a source quench message for every
   message that it discards.  On receipt of a source quench message, the
   source host should cut back the rate at which it is sending traffic
   to the specified destination until it no longer receives source
   quench messages from the gateway.  The source host can then gradually
   increase the rate at which it sends traffic to the destination until
   it again receives source quench messages [1,2].

ルートの上の次のネットワークへ出力のためのデータグラムを列に並ばせるのに必要であるバッファ領域を送信先ネットワークに持っていないなら、ゲートウェイはインターネットデータグラムを捨てるかもしれません。 ゲートウェイがデータグラムを捨てるなら、それはソース焼き入れメッセージをデータグラムのインターネット送信元ホストに送るかもしれません。 また、データグラムが処理できないくらい速く届くなら、あて先ホストはソース焼き入れメッセージを送るかもしれません。 ソース焼き入れメッセージはそれがインターネットの目的地に交通を送るレートを削るホストへの要求です。 ゲートウェイは捨てるというあらゆるメッセージへのソース焼き入れメッセージを送るかもしれません。 ソース焼き入れメッセージを受け取り次第、それがもうゲートウェイからソース焼き入れメッセージを受け取らないまで、送信元ホストはそれが指定された目的地に交通を送るレートを減らすべきです。 そして、送信元ホストはそれが再びソース焼き入れメッセージ[1、2]を受け取るまで交通を目的地に送るレートを徐々に、増加させることができます。

   The gateway or host may send the source quench message when it
   approaches its capacity limit rather than waiting until the capacity
   is exceeded.  This means that the data datagram which triggered the
   source quench message may be delivered.

それが容量が超えられるまで待っているよりむしろ容量限界にアプローチするとき、ゲートウェイかホストがソース焼き入れメッセージを送るかもしれません。 これは、ソース焼き入れメッセージの引き金となったデータデータグラムが届けられるかもしれないことを意味します。

The SQuID Concept

イカ概念

   Suppose the IP module at the datagram source has a queue of datagrams
   to send, and the IP module has a parameter "D".  D is the introduced
   delay between sending datagrams from the queue to the network.  That
   is, when the IP module discovers a datagram waiting to be sent to the
   network, it sends it to the network then waits time D before even
   looking at the datagram queue again.  Normally, the value of D is

データグラムソースのIPモジュールには送るデータグラムの待ち行列があると仮定してください。そうすれば、IPモジュールはパラメタ「D」を持っています。 Dは待ち行列からネットワークにデータグラムを送ることの間の導入された遅れです。 すなわち、IPモジュールが、データグラムが、ネットワークに送られるのを待っていると発見するとき、それはその時が再びデータグラム待ち行列を見る前の時Dに待つネットワークにそれを送ります。 通常、Dの値はそうです。

Prue & Postel                                                   [Page 1]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[1ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   zero.

ゼロ。

   Imagine that when a source quench is received (or any other signal is
   received that the host should slow down its transmissions to the
   network), the value of D is increased.  As time goes by, the value of
   D is decreased.

ソース焼き入れが受け取られているとき(ホストがトランスミッションをネットワークに減速させるべきであるといういかなる他の信号も受信されています)、Dの値が増加されていると想像してください。 時間が過ぎるのに従って、Dの値は減少します。

The SQuID Algorithm

イカアルゴリズム

          on increase event:

出来事は増加します:

               D <-- maximum (D + K, I)
                                        (where K = .020 second,
                                               I = .075 second)

D<--最大(D+K、I)(Kが.020秒、.075私=2番目と等しいところ)

          on decrease event:

減少出来事に関して:

               D <-- maximum (D - J, 0)
                                        (where J = .001 second)

D<--最大(D--J、0)(Jが.001 2番目と等しいところ)

   An increase event is receipt of one or more source quenches in a
   event period E, (where E is 2.000 seconds).

増加してください。出来事が1つ以上のソースの領収書がイベント時代にEを冷却するということである、(Eが2.000秒であるところ。)

   A decrease event is when S time has passed since D was decreased and
   there is a datagram to send (where S is 1.000 seconds).

減少出来事はDが減少して、送る(Sが1.000秒であるところ)データグラムがあるのでS時間が経過した時です。

   A cache of D's is kept for the last M hosts communicated with.

Dのキャッシュはホストが交信した最後のMのために保たれます。

   Note that when no datagrams are sent to a destination for some time
   the D for that destination is not decreased, but, if a destination is
   not used for a long time that D for that destination may fall out of
   the cache.

しばらくデータグラムを全く目的地に送らないとき、その目的地へのDを減少させませんが、目的地が長い間使用されないならその目的地へのそのDがキャッシュから落下するかもしれないことに注意してください。

Possible Refinements

可能な気品

   Keep a separate outgoing queue of datagrams for each destination
   host, local subnet, or network.

各あて先ホスト、地方のサブネット、またはネットワークのためにデータグラムの別々の外向的な待ち行列を保ってください。

   Keep the cache of D's per network or local subnet, instead of per
   host.

ホストの代わりに1ネットワークあたりのDか地方のサブネットのキャッシュを保ってください。

   "I" could be based upon the basic speed of the slowest intervening
   network (see Appendix A).

「私」は最も遅い介入しているネットワークの基本的な速度に基づくことができました(Appendix Aを見てください)。

   "D" could be limited to never go below "I" if the above refinement
   were implemented.

上の気品が実行されるなら、「私」を決して下に降りさせないように「D」を制限できるでしょうに。

   "S" could be based upon the round trip time.

「S」は周遊旅行時間に基づくことができました。

Prue & Postel                                                   [Page 2]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[2ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   "D" could be adjusted datagram by datagram based upon the length of
   the datagrams.  Wait longer after a long datagram.

「D」はデータグラムであるかもしれませんごとに調整される。より長い間、長いデータグラムの後に待ってください。

   The delay algorithm could be implemented such that if a source
   doesn't send a datagram when it is next allowed (the introduced delay
   interval) or for N such intervals that the source gets a credit for
   one and only one free (no delay) datagram.

遅れアルゴリズムがソースであるならそれが許容されていた状態で(導入された遅れ間隔)次であるか、時そのようなN間隔の間にデータグラムを送らない実行されたそのようなものであるかもしれないので、ソースは1個の唯一無二の無料(遅れがない)のデータグラムのためにクレジットを得ます。

Implementation Ideas

実現考え

   Since IP does not normally keep much state information about things,
   we want the default or idle IP to have no state about these D values.
   Since the default D value is zero, let us propose that the IP will
   keep a list of only those destinations with non zero D's.

IPが、多くの状態がものの情報であることを通常保たないので、私たちは、これらのD値に関してデフォルトか活動していないIPには状態が全くなくて欲しいと思います。 デフォルトD価値がゼロであるので、IPが非ゼロDのものと共にそれらの目的地だけのリストを保つよう提案しましょう。

   When the IP wants to send a datagram, it searches the D-list to see
   if the destination is noted.  If it is not, the D value is zero, so
   the IP sends the datagram at once.  If the destination is listed, the
   IP must wait D time indicated before sending that particular
   datagram.  It could look at a datagram addressed to a different
   destination, and possibly send it in the mean time.

IPがデータグラムを送りたがっているとき、それは、目的地が注意されるかどうかを見るためにD-リストを捜します。 D値がそれがそうでないなら、ゼロであるので、IPはすぐに、データグラムを送ります。 目的地が記載されているなら、IPはその特定のデータグラムを送る前に示されたD時間を待たなければなりません。 それは、異なった目的地に記述されたデータグラムを見て、その間にそれを送るかもしれません。

   When the IP receives a source quench, it checks to see if the
   destination in the datagram that caused the source quench is on the
   list.  If so, it adds K to the D value.  If not, it appends the
   destination to the list with the D value set to "I".

IPがソース焼き入れを受けるとき、それは、ソース焼き入れを引き起こしたデータグラムの目的地がリストにあるかを確認するためにチェックします。 そうだとすれば、それはD値にKを加えます。 そうでなければ、それは「私」へのD選択値群があるリストに目的地を追加します。

A Closer Look At the Problem

問題への、より近い一見

   Some implementations of IP send one SQ for every N datagrams they
   discard (for example, N=20) so the SQ messages will not make the
   congestion problem much worse [3].  In such situations any of the
   sources of the 20 datagrams may get the SQ not necessarily the one
   causing the most traffic.  However if a host continues to send
   datagrams at a high rate it has a high probability of receiving a SQ
   message sooner or later.  It is much like a speeder on a highway.
   Not all speeders get speeding tickets but the ones who speed most
   often or most excessively are most likely to be ticketed.  In this
   case they will get a ticket and their car may be destroyed.

IPのいくつかの実現が、あるシンガポール航空の便名を送る、あらゆる、シンガポール航空の便名メッセージが混雑問題をはるかに悪い[3]にしないようにそれらが捨てる(例えば、N=20)Nデータグラム。 そのような状況で、20個のデータグラムの源のいずれでも、必ずものではなく、シンガポール航空の便名が最も多くの交通を引き起こすかもしれません。 しかしながら、ホストが、高価でデータグラムを送り続けているなら、それには、遅かれ早かれシンガポール航空の便名メッセージを受け取るという高い確率があります。 それは高速道路の上のスピーダに似ています。 すべてのスピーダがスピード違反を手に入れるというわけではありませんが、最も疾走する人は過度に最もレッテルをはられそうです。 この場合、彼らはチケットを入手するでしょう、そして、それらの車は破壊されるかもしれません。

   With memory becoming so inexpensive many IP nodes put an artificially
   low limit on the size of their queues so that through node delay will
   not be excessive [4].  For example, if one megabyte of data is
   buffered to be sent over a 56 kb/s line the last datagram will wait
   over 2 minutes before being sent.

メモリがとても安価になっていて、多くのIPノードが人工的に低限界を彼らの待ち行列のサイズに置くので、ノード遅れを通したそれは過度の[4]にならないでしょう。 例えば、1メガバイトのデータが56kb/s線で送るためにバッファリングされるなら、送る前に最後のデータグラムは2分の上待っています。

   One problem with SQ is that the IP or ICMP specification does not
   have a well defined event to indicate receipt of SQ to higher level

シンガポール航空の便名に関する1つの問題はIPかICMP仕様にはシンガポール航空の便名の領収書をより高いレベルに示すよく定義された出来事がないということです。

Prue & Postel                                                   [Page 3]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[3ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   protocols.  Therefore many TCP implementations do not get notified
   about SQ events and thus do not react to SQ.  TCP is not the only
   source of IP datagrams either.  Other protocols should also respond
   to SQ events in some appropriate way.  TCP and other protocols at
   that level should do something about a source quench, however,
   discussion of their behavior is beyond the scope of this memo.  Note
   that implementation of SQ processing at one level of protocol should
   not interfere with the behavior of higher level protocols.  This
   however, is difficult to do.

プロトコル。 したがって、多くのTCP実現は、シンガポール航空の便名出来事に関して通知されないで、またその結果、シンガポール航空の便名に反応しません。 TCPはIPデータグラムの唯一の源ではありません。 また、他のプロトコルは何らかの適切な方法的にシンガポール航空の便名出来事に応じるべきです。 そのレベルにおけるTCPと他のプロトコルはソース焼き入れに関して何かをするべきであり、しかしながら、彼らの振舞いの議論はこのメモの範囲を超えています。 プロトコルの1つのレベルにおけるシンガポール航空の便名処理の実現が、より高い平らなプロトコルの振舞いを妨げるべきでないことに注意してください。 しかしながら、このするのは難しいです。

   For protocols using IP which are trying to transfer large amounts of
   data the data flow is most typically very bursty.  TCP for example,
   might send 5-10 segments into a window of 5-10 K bytes then wait for
   the acknowledgment of the data which opens the window again.  NETBLT
   as defined by RFC-998 is a rate based protocol which has parameters
   for burst size and burst rate.

多量のデータを移そうとしているIPを使用するプロトコルのために、データフローは最も通常まさしくそのburstyです。 例えば、TCP、力は5-10 再び窓を開けるデータの承認のためのKバイトの当時の待ちの窓に5-10 セグメントを送ります。 RFC-998によって定義されるNETBLTは放出量のためのパラメタを持っているベースのプロトコルと炸裂が評定するレートです。

   One purpose of the bursts is to allow the source computer to generate
   several datagrams at once to provide more efficient scheduling.  An
   other reason is to keep the network busy accepting data to maximize
   effective throughput in spite of a potentially large network round
   trip delay.  To send a datagram then wait for an acknowledgment is a
   simple but not efficient protocol on a large wide area network.

炸裂の1つの目的はソースコンピュータがすぐにより効率的なスケジューリングを提供するために数個のデータグラムを発生させるのを許容することです。 他の理由は潜在的に大きいネットワーク周遊旅行遅れにもかかわらず、有効なスループットを最大にするためにデータを受け入れることで忙しくネットワークを維持することです。 承認のためのデータグラムの当時の待ちを送るのは、大きい広域ネットワークに関する簡単な、しかし、効率的でないプロトコルです。

   The reasons for efficiencies obtained at the source node by
   generating many datagrams at once are not as applicable in an
   intermediate IP node.  Since each datagram is potentially from a
   different node they must all be treated individually.  Datagrams
   received in a burst may also overload the queue of an intermediate
   node losing datagrams and causing SQs to be generated.  If the queue
   is near a threshold and a burst comes, possibly all of the datagrams
   will be lost.  When datagrams arrive evenly spaced, less datagrams
   are likely to be lost because the inter-arrival time allows the queue
   a little time to empty out.  Therefore datagrams spaced with some
   delay between them may be better for intermediate IP nodes.

ソースノードですぐに多くのデータグラムを発生させることによって得られた効率の理由は中間的IPノードで適切ではありません。 各データグラムが潜在的にそうので、異なったノードから、それらをすべて個別に扱わなければなりません。 また、炸裂で受け取られたデータグラムはデータグラムをなくして、SQsを発生させる中間的ノードの待ち行列を積みすぎるかもしれません。 待ち行列が敷居の近くにあって、炸裂が来ると、ことによるとデータグラムのすべてが失われるでしょう。 データグラムが均等に区切られた状態で届くとき、相互到着時間がすっかり空にする少しの時間を待ち行列に許容するので、より少ないデータグラムが失われそうです。 したがって、中間的IPノードには、それらの間には、何らかの遅れがある状態で区切られたデータグラムは、より良いかもしれません。

   Congestion is most likely to occur at IP nodes which are gateways
   between a slower network and a faster one.  The congestion will be in
   the send queue from the slow network to the fast network.  An SQ
   being returned to the sender will return on the faster network.  (See
   diagram below.)

混雑は、より遅いネットワークと、より速いものの間のゲートウェイであるIPノードに最も起こりそうです。 遅いネットワークから速いネットワークまでの送信キューに混雑があるでしょう。 送付者に返されるシンガポール航空の便名は、より速いネットワークで戻るでしょう。 (以下のダイヤグラムを見てください。)

A Gateway Source Quench Concept

ゲートウェイソース焼き入れ概念

   In order for the SQuID algorithm to work we rely upon the gateways to
   send SQs to us to tell us how we are doing.  Because the loss of a
   single datagram affects data flow so much (see lost datagram
   discussion in Observed Results below) it would be much better for the

SQuIDアルゴリズムが扱って、私たちは、私たちの調子がどうであるか私たちに言うためにSQsを私たちに送るためにゲートウェイを当てにします。 単一のデータグラムの損失はデータフローにとても(以下のObserved Resultsの無くなっているデータグラム議論を見る)いろいろな事が、より良かったのでそうするために影響します。

Prue & Postel                                                   [Page 4]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[4ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   source IP node if it got a warning before datagrams were discarded.

データグラムの前で警告を得たなら、ソースIPノードは捨てられました。

   We propose gateway IP nodes start SQing before the node is flooded at
   a level we call SQ Keep (SQK) but forward the datagram.  If the queue
   level reaches a critical level, SQ Toss level (SQT), the gateway
   should toss datagrams to resolve the problem unless the datagram is
   an ICMP message.  Even ICMP messages will be tossed if the MaxQ level
   is reached.  Once the gateway starts sending SQs it should continue
   to do so until the queue level goes below a low water mark level
   (SQLW) as shown below.  This is analogous to methods some operating
   systems use to handle memory space management.

私たちは、ノードが私たちがシンガポール航空の便名Keep(SQK)と呼ぶレベルで水につかっている前にゲートウェイIPノードスタートSQingを提案しますが、データグラムを進めます。 待ち行列レベルが危機的なレベルに達するなら、シンガポール航空の便名Tossは(SQT)を平らにして、ゲートウェイは、データグラムがICMPメッセージでないなら問題を解決するためにデータグラムを投げるはずです。 MaxQレベルに達していると、ICMPメッセージさえ投げられるでしょう。 一度、ゲートウェイは、待ち行列レベルが干潮標レベル(SQLW)を以下に示すように、下に降りさせるまでそうするために、それが続けるべきであるSQsを送り始めます。 これはいくつかのオペレーティングシステムがメモリスペース管理を扱うのに使用する方法に類似しています。

   The gateway should try to send SQ to as many of the contributors of
   the congestion as possible but only once per contributor per second
   or two.

ゲートウェイは2番目か2あたりの貢献者に一度だけ混雑のできるだけ多くの貢献者にシンガポール航空の便名を送ろうとするはずです。

   Source Quench Queue Levels

ソース焼き入れ待ち行列レベル

         +--------------+ MaxQ level
         |              |> datagrams tossed & SQed (but not ICMP msgs.)
         +--------------+ SQT level (95%)
         |              |\
         |              | > datagrams SQed but forwarded
         |              |/
         +--------------+ SQK level (70%)
         |              |\
         |              | \ datagrams SQed but forwarded if SQK level
         |              | / exceeded & SQLW or lower not yet reached
         |              |/
         +--------------+ SQLW level (50%)
         |              |\
         |              | \
         |              |  \
         |              |   \ datagrams forwarded
         |              |   /
         |              |  /
         |              | /
         |              |/
         +--------------+

+--------------+ MaxQレベル| |データグラムが投げた>とSQed(しかし、ICMP msgsでない。) +--------------+ SQTレベル(95%)| |\ | | >データグラムSQedにもかかわらず、進めます。| |/ +--------------+ SQKレベル(70%)| |\ | | \データグラムSQed、SQKレベルであるなら、進めます。| | 超えられていた/とSQLW、まだ達していなく、下ろしてください。| |/ +--------------+ SQLWレベル(50%)| |\ | | \ | | \ | | データグラムが進めた\| | / | | / | | / | |/ +--------------+

Description of the Test Model

テストモデルの記述

   We needed some way of testing our algorithm and its various
   parameters.  It was important to check the interaction between IP
   with the SQuID algorithm and TCP.  We also wanted to try various
   combinations of retransmission strategy and source quench strategy
   which required control of the entire test network.  We therefore
   decided to build an Internet model.

私たちは私たちのアルゴリズムとその様々なパラメタをテストする何らかの方法を必要としました。 SQuIDアルゴリズムとTCPにIPの間の相互作用について問い合わせるのは重要でした。 また、私たちは全体のテストネットワークのコントロールを必要とした「再-トランスミッション」戦略とソース焼き入れ戦略の様々な組み合わせを試みたかったです。 したがって、私たちは、インターネットモデルを造ると決めました。

Prue & Postel                                                   [Page 5]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[5ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   Using this example configuration for illustration:

イラストにこの例の構成を使用します:

 _______    LAN       _______     WAN      _______     LAN      _______
|   1   |            |   2   |            |   3   |            |   4   |
|TCP/IP |---10 Mb/s--|  IP   |---56 kb/s--|  IP   |---10 Mb/s--|TCP/IP |
|_______|            |_______|            |_______|            |_______|

_______ LAN_______ WAN_______ LAN_______ | 1 | | 2 | | 3 | | 4 | |TCP/IP|---10Mb/s--| IP|---56kb/s--| IP|---10Mb/s--|TCP/IP| |_______| |_______| |_______| |_______|

   A program was written in C which created queues and structures to put
   on the queues representing datagrams carrying data, acknowledgments
   and SQs.  The program moved datagrams from one queue to the next
   based upon rules defined below

プログラムは、待ち行列を置くためにデータ、承認、およびSQsを運ぶデータグラムを表しながら、待ち行列を作成したCと構造に書かれました。 プログラムは1つの待ち行列から以下で定義された規則に基づく次へデータグラムを移しました。

   A client fed the TCP in node 1 data at the rate it would accept.  The
   TCP function in node 1 would chop the data up into fixed 512 byte
   datagrams for transmission to the IP in node 1.  When the datagrams
   were given to IP for transmission, a timestamp was put on it and a
   copy of it was put on a TCP ack-wait queue (data sent but not yet
   acknowledged).  In particular TCP assumed that once it handed data to
   IP, the data was sent immediately for purposes of retransmission
   timeouts even though our algorithm has IP add delay before
   transmission.

クライアントはノード1データでそれが受け入れるレートでTCPに食べさせました。 ノード1でのTCP機能はノード1のIPへの伝送のため512バイトの固定データグラムにデータを細かく切るでしょう。 トランスミッションのためにデータグラムをIPに与えたとき、タイムスタンプをそれに置きました、そして、TCP ack-待ち待ち行列(送りましたが、まだ承認していなかったデータ)にそれのコピーを置きました。 特に、TCPは、IPがトランスミッションの前に私たちのアルゴリズムで遅れを加えますが、それがいったんIPにデータを手渡すと、データがすぐ再送タイムアウトの目的のために送られたと仮定しました。

   Each IP node had one queue in each direction (left and right).  For
   each IP in the model IP would forward datagrams at the rate of the
   communications line going to the next node.  Thus the fifth datagram
   on IP 2's queue going right would take 5 X 73 msec or 365 msec before
   it would appear at the end of IP 3's queue.  The time to process each
   datagram was considered to be less than the time it took for the data
   to be sent over the 56 kb/s lines and therefore done during those
   transmission times and not included in the model.  For the LAN
   communications this is not the case but since they were not at the
   bottleneck of the path this processing time was ignored.  However
   because LAN communications are typically shared band width, the LAN
   band width available to each IP instance was considered to be 1 Mb/s,
   a crude approximation.

それぞれのIPノードには、各指示(左右)に基づく1つの待ち行列がありました。 モデルの各IPに関しては、IPは次のノードに達するコミュニケーション線のレートでデータグラムを進めるでしょう。 したがって、うまく行くIP2の待ち行列の5番目のデータグラムはそれの前のX73msecか365msecがIP3の待ち行列の終わりに見える5を取るでしょう。 各データグラムを処理する時間がわざわざデータを56のkb/s線で送って、したがって、それらのトランスミッション時間して、それがモデルに含んでいなかった少ないと考えられました。 LANコミュニケーションに関しては、これはそうではありませんが、それらが経路のボトルネックになかったので、この処理時間は無視されました。 しかしながら、LANコミュニケーションが通常共有されたバンド幅であるので、それぞれのIP例に有効なLANバンド幅は1Mb/s(粗雑な近似)であると考えられました。

   When the data arrived at node 4 the data was immediately given to the
   TCP receive function which validated the sequence number.  If the
   datagram was in sequence the datagram was turned into an ack datagram
   and sent back to the source.  An ack datagram carries no data and
   will move the right edge of the window, the window size past the just
   acked data sequence number.  The ack datagram is assumed to be 1/8 of
   the length of a data datagram and thus can be transmitted from one
   node to the next 8 times faster.  If the sequence number is less than
   expected (a retransmission due to a missed ack) then it too is turned
   into an ack.  A larger sequence number datagram is queued
   indefinitely until the missing datagrams are received.

データがノード4に到着したとき、データはすぐに考えて、TCPに、一連番号を有効にした機能に受信されているということでした。 系列にデータグラムがあったなら、データグラムは、ackデータグラムに変えられて、ソースを送り返しました。 ackデータグラムは、データを全く運ばないで、窓の正しい縁を動かして、ただackedされているところのウィンドウサイズはデータ一連番号です。 ackデータグラムをデータデータグラムの1/8の長さであると思って、その結果、1つのノードから次の8倍より速くなるまで送ることができます。 一連番号が予想されるより(逃されたackによる「再-トランスミッション」)少ないなら、それもackに変えられます。 なくなったデータグラムが受け取られているまで、より大きい一連番号データグラムは無期限に列に並ばせられます。

Prue & Postel                                                   [Page 6]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[6ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   We also modeled the gateway source quench algorithm.  When a datagram
   was put on an IP queue the number on the queue was compared to an SQ
   keep level (SQK).  If it was greater, an SQ was generated and
   returned to the sender. If it was larger than the SQ toss (SQT) level
   it was also discarded.  Once SQs were generated they would continue
   to be sent until the queue level went below SQ Low Water (SQLW) level
   which was below the original SQK level.  These percentages were
   modifiable as were many parameters.  An SQ could be lost if it
   exceeded the maximum queue size (MaxQ), but a source quench was never
   sent about tossing a source quench.

また、私たちはゲートウェイソース焼き入れアルゴリズムをモデル化しました。 データグラムが待ち行列の数がたとえられたIP待ち行列のときに置かれたとき、シンガポール航空の便名はレベル(SQK)を保ちます。 それが、より大きかったなら、シンガポール航空の便名を送付者に発生して、返しました。 また、シンガポール航空の便名トス(SQT)レベルより大きかったなら、それは捨てられました。 SQsがいったん発生すると、彼らは、待ち行列レベルが元のSQKレベルの下にあったシンガポール航空の便名Low Water(SQLW)レベルを下に降りさせるまで送られ続けているでしょうに。 これらの割合は多くのパラメタのように修正できました。 最大の待ち行列サイズ(MaxQ)を超えているなら、シンガポール航空の便名を失う場合がありますが、ソース焼き入れを投げることに関してソース焼き入れを決して送りませんでした。

   Upon each transition from one node to the next, the datagram was
   vulnerable to datagram loss due to errors.  The loss rate could be
   set as M losses out of N datagrams sent, thus the model allowed for
   multi-datagram loss bursts or single datagram losses.  We used a
   single datagram loss rate of 1 lost datagram per 300 datagrams sent
   for much of our testing.  While this may seem low for Internet
   simulation, remember it does not include losses due to congestion.

各1つのノードから次までの変遷のときに、データグラムは誤りのためにデータグラムの損失に傷つきやすかったです。 Nデータグラムからの損失が送ったMとして損失率を設定できました、その結果、モデルはマルチデータグラム損失炸裂か単一のデータグラムの損失を考慮しました。 私たちは非常に呼びにやられた私たちがテストする300個のデータグラムあたり1個の無くなっているデータグラムのただ一つのデータグラム損失率を使用しました。 これがインターネットシミュレーションに低く見えているかもしれない間、それが混雑による損失を含んでいないのを覚えていてください。

   Some network parameters we used were a maximum queue length of 15
   datagrams per IP direction left and right.  We started sending SQ if
   the queue was 70% full, SQK level, tossed data datagrams, but not SQ
   datagrams, if 95% of the queue was reached, SQT level, and stopped
   SQing when a 50% SQLW level was reached (see above).

私たちが使用したいくつかの回路パラメータが左と右IP指示あたり15個のデータグラムの最大の待ち行列の長さでした。 私たちは、待ち行列がいっぱいに、SQKが平らにする70%であったならシンガポール航空の便名を送り始めて、SQTレベルを待ち行列の95%に達したならシンガポール航空の便名データグラムではなく、データデータグラムに投げて、50%のSQLWレベルに達したとき(上を見てください)、SQingを止めました。

   We ignored additional SQs for 2 seconds after receipt of one SQ.
   This was done because some Internet nodes only send one SQ for every
   20 datagrams they discard even though our model sent SQs for every
   datagram discarded.  Other IP node may send one SQ per discarded
   packet. The SQuID algorithm needed a way to handle both types of SQ
   generation.  We therefore treated one or a burst of SQs as a single
   event and incremented our D by a larger amount than would be
   appropriate for responding individually to the multiple SQs of the
   verbose nodes.

私たちは1つのシンガポール航空の便名の領収書の後の2秒間、追加SQsを無視しました。 あらゆるデータグラムのための私たちのモデルの送られたSQsが捨てましたが、いくつかのインターネット接続装置がそれらが捨てる20個のデータグラムあたり1つのシンガポール航空の便名しか送らないので、これをしました。 他のIPノードは捨てられたパケットあたりのシンガポール航空の便名を1つに送るかもしれません。 SQuIDアルゴリズムは両方のタイプのシンガポール航空の便名世代を扱う方法を必要としました。 私たちは、したがって、SQsの1か炸裂を単一の出来事として扱って、冗長なノードの複数のSQsにDを個別に応じるのに適切であるだろうより多くの量で増加しました。

   The simulation did not do any fragmenting of datagrams.  Silly window
   syndrome was avoided.  The model did not implement nor simulate the
   TTL (time-to-live) function.

シミュレーションはデータグラムのどんな断片化もしませんでした。愚かな窓のシンドロームは避けられました。 モデルは、TTL(生きる時間)機能を実行して、シミュレートしませんでした。

   The model allowed for a flexible topology definition with many TCP
   source/destination pairs on host IP nodes or gateway IP nodes with
   various windows allowed.  An IP node could have any number of TCPs
   assigned to it.  Each line could have an individually set speed.  Any
   TCP could send to any other TCP.  The routing from one location to
   another was fixed.  Therefore datagrams did not arrive out of
   sequence.  However, datagrams arrived in ascending order, but not
   consecutively, on a regular basis because of datagram losses.
   Datagrams going "left" through a node did not affect the queue size,

モデルはホストIPノードの上の多くのTCPのソース/目的地組か様々な窓があるゲートウェイIPノードが許容されているフレキシブルなトポロジー定義を考慮しました。 IPノードで、いろいろなTCPsをそれに割り当てるかもしれません。 各線には、個別に設定された速度があるかもしれません。 どんなTCPもいかなる他のTCPにも発信できました。 1つの位置からもう1つの位置までのルーティングは修理されました。 したがって、データグラムは順序が狂って届きませんでした。 しかしながら、データグラムは、データグラムの損失のために昇順に到着しましたが、連続して、そして、定期的に到着したというわけではありません。 「左に」ノードを調べるデータグラムが待ち行列サイズに影響しませんでした。

Prue & Postel                                                   [Page 7]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[7ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   or SQ chances, of data going "right" through the node.

または、シンガポール航空の便名はデータがノードを「まさしく」調べるのをやってみます。

   The TCP retransmission timer algorithm used an Alpha of .15 and a
   Beta of 1.5.  The test was run without the benefit of the more
   sophisticated retransmission timer algorithm proposed by Van Jacobson
   [5].

TCP再送信タイマーアルゴリズムは.15人のアルファーと1.5のBetaを使用しました。 テストはヴァン・ジェーコブソン[5]によって提案されたより高度な再送信タイマーアルゴリズムの利益なしで走りました。

   The program would display either the queue sizes of the various IP
   nodes and the TCP under test as time passed or do a crude plot of
   various parameters of interest including SRTT, perceived round trip
   time, throughput, and the critical queue size.

プログラムは、時間が経過したのでテストで様々なIPノードとTCPの待ち行列サイズを表示するか、または周遊旅行時間、スループットであると知覚されたSRTTを含む興味がある様々なパラメタの粗雑な陰謀と重要な待ち行列サイズをするでしょう。

   As we observed the effects of various algorithms for responding to SQ
   we adapted our model to better react to SQ.  Initial tests showed if
   we incremented slowly and decremented quickly we observed
   oscillations around the correct value but more of the time was spent
   over driving the network, thus losing datagrams, than at a value
   which helped the congestion situation.

シンガポール航空の便名に応じるための様々なアルゴリズムの効果を観測したとき、私たちは、シンガポール航空の便名によりよく反応するためにモデルを適合させました。 初期のテストは、ゆっくり増加されて、急速に減少して、私たちが、私たちであるならネットワークを運転する上で振動だけが費やされるのを観測したのを示しました、その結果、データグラムをなくします、混雑状況を助けた値より。

   A significant problem is the delay between when some intermediate
   node starts dropping datagrams and sending source quenches to the
   time when the source quenches arrive at the source host and can begin
   to effect the behavior at the data source.  Because of this and the
   possibility that a IP might send only one SQ for each 20 datagrams
   lost, we decided that the increase in D per source quench should be
   substantial (for example, D should increase by 20 msec for every
   source quench), and the decrease with time should be very slow (for
   example, D should decrease 1 msec every second).  Note that this is
   the opposite behavior than suggested in an early draft by one of the
   authors.

重大な問題は何らかの中間的ノードがソース焼き入れが送信元ホストに到着して、データ送信端末で振舞いに作用し始めることができる時にデータグラムと送付ソース焼き入れを落とし始める時の間の遅れです。 これとIPが各20個のデータグラムのためのシンガポール航空の便名が失ったものだけを送るかもしれない可能性のために、私たちはソース焼き入れあたりのDの増加が実質的であるべきであり(例えば、Dはあらゆるソース焼き入れのために20msecで増加するべきです)、時間がある減少が非常に遅いはずであると決めました(例えば、Dは毎秒あたりの減少1msecにそうするべきです)。 これが早めの草稿で作者のひとりによって示されるより逆行動であることに注意してください。

   However, when many source quenches are received (for example, when a
   source quench is received for every datagram dropped) in a short time
   period the D value is increased excessively.  To prevent D from
   growing too large, we decided to ignore subsequent source quenches
   for a time (for example, 2 seconds) once we had increased D.

しかしながら、短い期間に多くのソース焼き入れを受け取るとき(例えば、いつあらゆるデータグラムのためにソース焼き入れを受け取るかは低下しました)、D値を過度に増加させます。 Dが大きくなり過ぎるのを防ぐために、私たちは、私たちがDをいったん増加させると時間(例えば、2秒)その後のソース焼き入れを無視すると決めました。

   Tests were run with only one TCP sending data to learn as much as
   possible how an unperturbed session might run.  Other test runs would
   introduce and eliminate competing traffic dynamically between other
   TCP instances on the various nodes to see how the algorithms reacted
   to changes in network load.  A potential flaw in the model is that
   the defined TCPs with open windows always tried to forward data.
   Their clients feeding them data never paused to think what they were
   going to type nor got swapped out in favor of other applications nor
   turned the session around logically to listen to the other end for
   more user commands.  In other words all of the simulated TCP sessions
   were doing file transfers.

テストは1TCPだけが平静なセッションがどう行われるかもしれないかをできるだけ学ぶためにデータを送る走行でした。 他の試運転は、アルゴリズムがどうネットワーク負荷における変化に反応したかを見るために様々なノードの上で他のTCP例の間でダイナミックに競争している交通を導入して、排除するでしょう。 モデルの潜在的欠点は開いている窓がある定義されたTCPsがいつもデータを転送しようとしたということです。 データを彼らに与える彼らのクライアントは、より多くのユーザコマンドに関してもう一方の端を聞くために論理的に決して止まって、それらが何をタイプするつもりであるかを考えたことがなくて、他のアプリケーションを支持して外で交換されて、セッションを変えました。 言い換えれば、シミュレートされたTCPセッションのすべてがファイル転送をしていました。

Prue & Postel                                                   [Page 8]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[8ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   The model was defined to allow many mixes of competing algorithms for
   responding to SQ.  It allowed comparing effective throughput between
   TCPs with small windows and large windows and those whose IP would
   introduce inter-datagram delays and those who totally ignored SQ.  It
   also allowed comparisons with various inter-datagram increment
   amounts and decrement amounts.  Because of the number of possible
   configurations and parameter combinations only a few combinations of
   parameters were tested. It is hoped they were the most appropriate
   ones upon which to concentrate.

モデルは、シンガポール航空の便名に応じるための競争しているアルゴリズムの多くのミックスを許すために定義されました。 それは、小さい窓と大きい窓があるTCPsの間の有効なスループットを比較に許容して、だれのIPが相互データグラム遅れを導入するだろうか、そして、シンガポール航空の便名を完全に無視した人をそれらに許容しました。 また、それは様々な相互データグラム増分の量と減少量との比較を許しました。 可能な構成とパラメタ組み合わせの数のために、パラメタのほんのいくつかの組み合わせがテストされました。 それらが集中するのが最も適切であるものであったことが望まれています。

Observed Results

観測された結果

   All of our algorithms oscillate, some worse than others.

私たちのアルゴリズムのすべてが他のものよりひどくいくつか振動します。

   If we put in just the right amount of introduced delay we seem to get
   the best throughput.  But finding the right amount is not easy.

導入された遅れの正しい量を入れるなら、私たちは、最も良い効率を得るように思えます。 しかし、正しい量を見つけるのは簡単ではありません。

   Throughput is adversely affected, heavily, by a single lost datagram
   at least for the short time.  Examine what happens when a window is
   35 datagrams wide with an average round trip delay of 2500 msec using
   512 byte datagrams when a single datagram is lost at the beginning.
   Thirty five datagrams are given by TCP to IP and a timer is started
   on the first datagram.  Since the first datagram is missing, the
   receiving TCP will not sent an acknowledgment but will buffer all 34
   of the out-of-sequence datagrams.  After 1.5 X 2500 msec, or 3750
   msec, have elapsed the datagram times out and is resent.  It arrives
   and is acked, along with the other 34, 2500 msec later.  Before the
   lost datagram we might have been sending at the average rate a 56
   kb/s line could accept, about one every 75 msec.  After loss of the
   datagram we send at the rate of one in 6250 msec over 83 times
   slower.

スループットは少なくとも短い間の単一の無くなっているデータグラムでずっしりと悪影響を受けます。 窓が起こるとき、何が起こるか調べてください、35個のデータグラム、広さ、平均で、単一のデータグラムが始めになくされているとき、512バイトのデータグラムを使用することで2500年のmsecの旅行遅れを一周させてください。 35個のデータグラムがTCPによってIPに与えられています、そして、タイマは最初のデータグラムを始動します。 以来、最初のデータグラムはなくなって、受信は意志が外で系列のすべての34のアウトデータグラム1.5のX後2500msec、または3750年のmsecが経過するようにするバッファにデータグラム回を望んでいるのを除いて、承認を送って、再送されないTCPです。 それは、到着して、後でもう片方の34、2500msecと共にackedされます。 無くなっているデータグラムで私たちが56kb/s線が受け入れることができた平均相場、1つに関するあらゆる75のときにmsecを送ったかもしれない前。 データグラムの損失の後に、私たちは6250年の1のレートで83倍以上より遅くmsecを送ります。

   If the lost datagram in the above example is other than the first
   datagram the situation becomes the same when all of the datagrams
   before the lost datagram are acknowledged.  The example holds true
   then for any single lost datagram in the window.

無くなっているデータグラムの前のデータグラムのすべてが承認されるとき、最初のデータグラムを除いて、上記の例の無くなっているデータグラムがあるなら、状況は同じになります。 例はその時、窓のどんな単一の無くなっているデータグラムのためにも有効です。

   When SQ doesn't always cause datagram loss the sender continues to
   send too fast (queue size oscillates a lot).  It is important for the
   SQ to cause feed-back into the sending system as soon as possible,
   therefore when the source host IP receives an SQ it must make
   adjustments to the send rate for the datagrams still on the send
   queue not just datagrams IP is requested to send after the SQ.

シンガポール航空の便名がいつもデータグラムの損失をもたらすというわけではないとき、送付者は、あまりに速く発信し続けています(待ち行列サイズは大いに振動します)。 シンガポール航空の便名ができるだけ早く送付システムにフィードバックを引き起こすのは、重要です、したがって、送信元ホストIPがそれが合わせなければならないシンガポール航空の便名を受ける、まだシンガポール航空の便名の後に送ってくださいまさしくどんなデータグラムIPも要求されていない送信キューにデータグラムのレートを送ってください。

   Through network delay goes up as the network queue lengths go up.

ネットワークを通して、ネットワーク待ち行列の長さが上がるのに応じて、遅れは上がります。

   Window size affect the chance of getting SQed.  Look at our model
   above using a queue level of 15 for node 2 before SQs are generated

ウィンドウサイズはSQedを手に入れるという機会に影響します。 SQsが発生する前にノード2に15の待ち行列レベルを使用する上で私たちのモデルを見てください。

Prue & Postel                                                   [Page 9]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[9ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   and a window size of 20 datagrams.  We assumed that we could send
   data over the LAN at a sustained average rate of 1 Mb/s or about 18
   times as fast as over the WAN.  When TCP sends a burst of 20
   datagrams to node 1 they make it to node 2 in 81 msec.  The
   transition time from node 2 to node 3 is 73 msec, therefore, in 81
   msec, only one datagram is forwarded to node 3.  Thus the 17th, 18th,
   19th, and 20th datagram are lost every time we send a whole window.
   More are lost when the queue is not empty.  If a sequence of acks
   come back in response to the sent data, the acks tend to return at
   the rate at which data can traverse the net thus pacing new send data
   by opening the window at the rate which the network can accept it.
   However as soon as one datagram is lost all of the subsequent acks
   are deferred and batched until receipt of the missing data block
   which acks all of the datagrams and opens the window to 20 again.
   This causes the max queue size to be exceeded again.

そして、私たちが1Mb/sの持続している平均相場においてWANのおよそ18倍速くLANの上のデータを送ることができた. 私たちが仮定した20個のデータグラムのウィンドウサイズ。 TCPが20個のデータグラムの炸裂をノード1に送るとき、それらは81msecでノード2に行きます。 ノード2からノード3までのトランジッションタイムが73msecである、したがって、81msecでは、1個のデータグラムだけをノード3に送ります。 したがって、私たちが全体の窓を送るときはいつも、17番目、18番目、19番目、および20番目のデータグラムは無くなっています。 待ち行列が空でないときに、以上は無くなっています。 acksの系列が送られたデータに対応して戻るなら、acksは、データがネットを横断できるレートで戻る傾向があります、その結果、ネットワークがそうすることができるレートに窓を開けることによって新しい送信データに歩調を合わせると、それは受け入れられます。 しかしながら、あるデータグラムが無くなるとすぐに、その後のacksのすべてが、データグラムのすべてをacksして、再び窓を20まで開ける欠測値ブロックの領収書まで延期されて、batchedされます。 これで、再び最大待ち行列サイズを超えています。

   If we assume a window smaller than the max queue size in the
   bottleneck node, any time we send a window's worth of data, it is
   done independently of the current size of the queue.  The larger the
   send window, the larger a percentage of the stressed queue we send.
   If we send 50% of the stressed queue size any time that queue is more
   than 50% we threaten to overflow the queue.  Evenly spaced single
   datagram bursts have the least chance of overflowing the queue since
   they represent the minimum percentage of the max queue one may send.

私たちが、窓がボトルネックノードの最大待ち行列サイズより小さいと思うなら、私たちが窓のデータの価値を送る何時でも、待ち行列の現在のサイズの如何にかかわらずそれをします。 より大きい、私たちが送る圧力を加えられた待ち行列の割合を窓、より大きく送ってください。 50%発信するなら、圧力を加えられた待ち行列サイズでは、私たちは、その待ち行列が50%以上であるどんな時にも待ち行列からはみ出すと脅かします。 均等に区切られた単一のデータグラム炸裂には、彼らが送るかもしれない最大待ち行列の最小の百分率を表すので待ち行列からはみ出すという最少の機会があります。

   When a big window opens up (that is, a missing datagram at the head
   of a 40 datagram send queue gets retransmitted and acked), the
   perceived round trip time for datagrams subsequently sent hits a
   minimum value then goes up linearly.  The SRTT goes down then back up
   in a nice smooth curve.  This is caused by the fact IP will not add
   delay if the queue is empty and IP has not sent any datagrams to the
   destination for our introduced delay time.  But as many datagrams are
   added to the IP pre-staged send queue in bursts all have the same
   send time as far as TCP is concerned.  IP will delay each datagram on
   the head of the queue by the introduced delay amount.  The first may
   be undelayed as just described but all of the others are delayed by
   their ordinal number on the queue times the introduced delay amount.

大きい窓が開くと(すなわち、送信キューが手に入れる40データグラムのヘッドのなくなったデータグラムは、再送して、ackedされました)、データグラムがその時次に最小値をヒットに送ったので、知覚された周遊旅行時間は直線的に上がります。 SRTTはその時、良い滑らかなカーブで逆落ちます。 待ち行列が空であり、IPが私たちの導入された遅延時間の間、どんなデータグラムも目的地に送らないとIPが遅れを加えないという事実によってこれは引き起こされます。 しかし、多くのデータグラムがIPに追加されるとき、すべてが同じくらいにTCPと同じくらい遠くに時間を送らせる炸裂におけるあらかじめ上演された送信キューは関係があります。 導入された遅れ量に従って、IPは待ち行列のヘッドの上の各データグラムを遅らせるでしょう。 1番目はただ説明されているとして非猶予されるかもしれませんが、他のもののすべてが導入された遅れが達するという待ち行列時間の彼らの序数詞で遅れます。

   It seems as though in a race between a TCP session which delays
   sending to IP and one who does not, the delayer will get better
   throughput because less datagrams are lost.  The send window may also
   be increased to keep the pipeline full.  If however the non delayer
   uses windowing to reduce the chance of SQ datagram loss his
   throughput may possibly be better because no fair queuing algorithm
   is in place.

より少ないデータグラムが無くなるので「反-層」がIPに発信するのを遅らせるTCPセッションとそうしないものの間のレースでより良い効率を得るように思えます。 窓を送ってください。また、パイプラインを完全に保つために増加してもよいです。 しかしながら、非「反-層」がシンガポール航空の便名データグラムの損失の可能性を小さくするのにウインドーを使用するなら、どんな公正な待ち行列アルゴリズムも適所にないので、彼の効率はことによるとより良いかもしれません。

   If gateways send SQs early and don't toss data until its critical and
   keep sending SQs until a low water mark is hit, effective throughput

ゲートウェイが早くSQsを送って、それが批判的になるまでデータを投げないで、発信し続けるなら、干潮標までのSQsは打たれます、有効なスループット

Prue & Postel                                                  [Page 10]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[10ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   seems to go up.

上がるように思えます。

   At the startup of our tests throughput was very high, then dropped
   off quickly as the last of the window got clobbered.  Our model
   should have used a slow start up algorithm to minimize the startup
   shock.  However the learning curve to estimate the proper value for D
   was probably quicker.

私たちのテストの始動では、窓の最終が打ち負かされたとき、スループットは、非常に高く、次に、すばやく落ちました。 私たちのモデルは、始動ショックを最小にするのに遅い始動アルゴリズムを使用するべきでした。 しかしながら、Dのために固有値を見積もるラーニングカーブはたぶんより迅速でした。

   A large part of the perceived RTT is due to the delay getting off the
   TCP2IP (TCP transitional) queue when we used large windows.  If IP
   would invoke some back-pressure to TCP in a real implementation this
   can be significantly reduced.  Reducing the window would do this for
   us at the expense of throughput.

知覚されたRTTのかなりの部分は私たちが大きい窓を使用したときTCP2IPの(TCP過渡的)の待ち行列を離す遅れのためです。 IPが本当の実現でTCPへの何らかの逆圧を呼び出すなら、これはかなり減少できます。 窓を減少させると、これは私たちのためにスループットを犠牲にしてするでしょう。

   After an SQ burst which tosses datagrams the sender gets in a mode
   where TCP may only send one or two datagrams per RTT until the queued
   but not acked segments fall into sequence and are acked.  This
   assumes only the head of the retransmission queue is retransmitted on
   a timeout.  We can send one datagram upon timeout.  When the ack for
   the retransmission is received the window opens allowing sending a
   second.  We then wait for the next lost datagram to time out.

シンガポール航空の便名がはち切れた後に、どれが送付者をデータグラムに投げるかが列に並ばせられましたが、ackedされなかったセグメントが系列になって、ackedされるまでTCPが1RTTあたり1か2個のデータグラムしか送らないかもしれないモードに入ります。 これは、再送キューのヘッドだけがタイムアウトで再送されると仮定します。 私たちは1個のデータグラムをタイムアウトに送ることができます。 「再-トランスミッション」のためのackが受け取られているとき、窓は、1秒を発信に許容しながら、開きます。 そして、私たちは次の無くなっているデータグラムをタイムアウトに待ちます。

   If we stop sending data for a while but allow D to be decreased, our
   algorithm causes the introduced delay to dwindle away.  We would thus
   go through a new startup learning curve and network oscillation
   sequence.

私たちがしばらくデータを送るのを止めますが、Dを減少させるなら、私たちのアルゴリズムで、導入された遅れは遠くでやせ細ります。 その結果、私たちは新しい始動ラーニングカーブとネットワーク振動系列に直面しているでしょう。

   One thing not observed often was TCP timing out a segment before the
   source IP even sent the datagram the first time.  As discussed above
   the first datagram on the queue of a large burst is delayed minimally
   and succeeding datagrams have linearly increasing delays.  The
   smoothed round trip delay algorithm has a chance to adapt to the
   perceived increasing round trip times.

ソースIPが1回目にデータグラムを送る前にさえしばしば観測されなかったあることがセグメントからのTCPタイミングでした。 上で議論するように、大きい炸裂の待ち行列の最初のデータグラムは最少量で遅れます、そして、続くデータグラムで、直線的は遅れを増加させます。 平坦な周遊旅行遅れアルゴリズムには、知覚された増加する周遊旅行時間に順応する機会があります。

Unstructured Thoughts and Comments

不統一な考えとコメント

   The further down a route a datagram traverses before being clobbered
   the greater the waste of network resources.  SQs which do not destroy
   the datagram referred to are better than ones that do if return path
   resources are available.

打ち負かされる前にデータグラムが横断するルートの下側により遠くに、ネットワーク資源の浪費は、より大きいです。 言及されたデータグラムを破壊しないSQsはリターンパスリソースが利用可能であるならすることより良いです。

   Any fix must be implementable piecemeal.  A fix can not be installed
   in all or most nodes at one time.  The SQuID algorithm fulfills this
   requirement.  It could be implemented, installed in one location, and
   used effectively.

どんなフィックスも少しずつ実行可能でなければなりません。 ひところ、すべてかほとんどのノードにフィックスをインストールできません。 SQuIDアルゴリズムはこの要件を実現させます。 それを実行して、一箇所でインストールされて、有効に使用できました。

   If it can be shown that by using the new algorithm effective
   throughput can be increased over implementations which do not

新しいアルゴリズム有効なスループットを使用するのによるそれが実現の上で増加できるのをどれがそうしないか示すことができるなら

Prue & Postel                                                  [Page 11]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[11ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   implement it that may well be effective impetus to get vendors to
   implement it.

それを実行してください。たぶん、それは業者に実行させる有効な起動力がそれであったならそうするでしょう。

   Once a source host has an established average minimum inter-datagram
   delay to a destination (see Appendix A), this information should be
   stored across system restarts.  This value might be used each time
   data is sent to the given host as a minimum inter-datagram delay
   value.

送信元ホストがいったん確立した平均した最小の相互データグラム遅れを目的地に持っていると(Appendix Aを見てください)、この情報はシステムリスタートの向こう側に格納されるべきです。 この値は使用されて、最小の相互データグラム遅れ価値としてそれぞれの時間データを与えられたホストに送るということであるかもしれません。

   Window closing algorithms reduce the average inter-datagram delay and
   the burst size but do not affect the minimum inter-datagram spacing
   by TCP.

窓の閉鎖アルゴリズムは、平均した相互データグラム遅れと放出量を減少させますが、TCPで最小の相互データグラムスペースに影響しません。

   Currently an IP gateway node can know if it is in a critical path
   because its queues stay high or keep building up.  Its optimum queue
   size is one because it always has something to do and the through
   node delay is at a minimum.  It is very important that the gateway at
   the critical path not so discourage data flow that its queue size
   drops to zero.  If the gateway tosses datagrams this stops data flow
   for TCP for a while (as described in Observed Results above).  This
   argues for the gateway algorithm described above which SQs but does
   not toss datagrams unless necessary.  Optimally we should try to have
   a queue size somewhat larger than 1 but less than say 50% of the max
   queue size.  Large queues lead to large delay.

現在の、IPゲートウェイノードは、待ち行列が高いままである、または増し続けるので、クリティカルパスでそれがあるかを知ることができます。 いつも用事があるので、最適な待ち行列サイズは1です、そして、ノードが遅らせる突き抜けるのが最小限であります。 したがって、クリティカルパスにおけるゲートウェイが待ち行列サイズがゼロまで落とすデータフローに水をさしていないのは、非常に重要です。 ゲートウェイがデータグラムを投げるなら、これはしばらく、TCPのためのデータフローを止めます(上のObserved Resultsで説明されるように)。 これは、どのSQsの上で説明されたゲートウェイアルゴリズムの賛成の議論をしますが、必要でない場合、データグラムを投げません。 私たちは最大待ち行列サイズの50%を言うより待ち行列サイズを1にもかかわらず、以下よりいくらか大きく最適に、しようとするべきです。 大きい待ち行列は大きい遅れにつながります。

   TCP's SRTT is made artificially large by introducing delay at IP but
   the perceived round trip time variance is probably smaller allowing a
   smaller Beta value for the timeout value.

IPで遅れを導入することによって、TCPのSRTTを人工的に大きくしますが、知覚された周遊旅行時間変化はたぶんタイムアウト値のための、より小さいBeta値を許容しながら、より小さいです。

   So that a decrease timer is not needed for the "D" decrease function,
   upon the next sent datagram to a delayed destination just decrease
   the delay by the amount of time since we last did this divided by the
   decrease timer interval.  An alternate algorithm would be to decrease
   it by only one decrease unit amount if more than the timer interval
   has gone by.  This eliminates the problem caused by the delay, "D",
   dwindling away if we stop sending for a while.  The longer we send
   using this "D", the more likely it is that it is too large a delay
   and the more we should decrease it.

減少タイマは「D」減少機能に必要でない遅れた目的地への次の送られたデータグラムでは、私たちが最後に減少タイマ間隔が割られたこれをして以来の時間までに遅れをただ減少させてください。 交互のアルゴリズムはタイマ間隔以上が過ぎたなら1つの減少ユニット量だけに従ってそれを減少させるだろうことです。 これはしばらく発信することにおける私たちが止まるなら遠くでやせ細って、遅れ、「D」によって引き起こされた問題を解決します。 それは大き過ぎる遅れです、そして、この「D」を使用することで、より長く発信すれば発信するほど、私たちはさらにそれをより減少させるべきでありそうです。

   It is better for the network and the sender for our introduced delay
   to be a little on the high side.  It minimizes the chances of getting
   a datagram clobbered by sending it into a congested gateway.  A lost
   datagram scenario described above showed that one lost datagram can
   reduce our effective delay by one to two orders of magnitude
   temporarily.  Also if the delay is a little high, the net is less
   stressed and the queues get smaller, reducing through network delay.

私たちの導入された遅れが少しであるネットワークと送付者には、高い側では、それが、より良いです。 それは混雑しているゲートウェイにそれを送ることによってデータグラムを打ち負かさせるという可能性を最小にします。 上で説明された無くなっているデータグラムシナリオは、1個の無くなっているデータグラムが私たちの有効な遅れを1〜2桁一時減少させることができるのを示しました。 また、遅れが少し高いなら、ネットはそれほど強調されません、そして、待ち行列は、より小さくなります、ネットワーク遅延を通して減少して。

   The RTT experienced at a given time verses the minimum RTT possible

一時に経験されたRTTは可能な最小のRTTの作詩をします。

Prue & Postel                                                  [Page 12]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[12ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   for the given route does give a good measure of congestion.  If we
   ever get congestion control working RTT may have little to do with
   the amount of congestion.  Effective throughput when compared with
   the possible throughput (or some other measure) is the only real
   measure of congestion.

与えられたルートが混雑の良い手段を与えるので。 私たちが輻輳制御を働かせるなら、RTTは混雑の量にほとんど無関係であるかもしれません。 可能なスループット(または、ある他の測定)と比べると、有効なスループットは混雑の唯一の実物的尺度です。

   Slow startup of TCP is a good thing and should be encouraged as an
   additional mechanism for alleviating network overload.

TCPの遅い始動は、良いものであり、ネットワークオーバーロードを軽減するための追加メカニズムとして奨励されるべきです。

   The network dynamics tends to bunch datagrams.  If we properly space
   data instead of bunching it like windowing techniques to control
   overflow of queues then greater throughput is accomplished because
   the absolute rate we can send is pacing our sending not the RTT.  We
   eliminate "stochastic bunching" [6].

ネットワーク力学は、データグラムを束ねる傾向があります。私たちであるなら、私たちが送ることができる絶対レートが、私たちがいずれのRTTも送らないのに歩調を合わせているので、適切に、オーバーフローを制御するウインドーのテクニックが当時の、より大きいスループットを列に並ばせるようにそれを束ねることの代わりにスペースデータは優れています。 私たちは「推計的な束になる」[6]を排除します。

   The longer the RTT the more network resources the data takes to
   traverse the net.

RTTが長ければ長いほど、データがネットを横断するために取るネットワーク資源は、より多いです。

   Should "fair queuing" say that a longer route data transfer should
   get less band width than a shorter one (since it consumes more of the
   net)?  Being fair locally on each node may be unfair overall to
   datagrams traversing many nodes.

「公正な列を作り」は、より長いルートデータ転送が、より短いものより少ないバンド幅を得るべきであると言うべきですか?(一層のネットを消費するので) 各ノードで局所的に公正であるのは多くのノードを横断するデータグラムのに対し全体的に見てフェアでないかもしれません。

   If we solve congestion problems today, we will start loading up the
   net with more data tomorrow.  When this causes congestion in a year
   will that type of congestion be harder to solve than todays or is it
   not our problem?  John Nagle suggests "In a large net, we may well
   try to force congestion out to the fringes and keep the interior of
   the net uncongested by controlling entry to the net.  The IMP-based
   systems work that way, or at least used to.  This has the effect of
   concentrating congestion at the entrance to the long-haul system.
   That's where we want it; the Source Quench / congestion window / fair
   queuing set of strategies are able to handle congestion at the LAN to
   WAN bottleneck [7].  Our algorithm should try to push the network
   congestion out to the extremities and keep the interior network
   congestion free.

今日混雑問題を解決すると、私たちは明日、より多くのデータにネットをロードし始めるでしょう。 これが1年後に混雑を引き起こすとき、そのタイプの混雑は今日よりさらに解決しにくいようになるでしょうか、それが私たちの問題ではありませんか? ジョン・ネーグルは、「大きいネットでは、ネットにエントリーを制御することによって、混雑をフリンジに追い出して、私たちは、たぶんネットの内部を非充血させ続けようとするでしょう。」と提案します。 IMPベースのシステムは、そのように働いていたか、または以前はよく少なくとも働いていました。 これには、入り口に長期システムに混雑を集結するという効果があります。 それは私たちがそれが欲しいところです。 Source Quench/混雑ウィンドウ/公正な列を作り戦略はLANでWANボトルネック[7]に混雑を扱うことができます。 私たちのアルゴリズムは、窮境にネットワークの混雑を押し出して、内部のネットワークの混雑を自由に保とうとするべきです。

   Use of the algorithm is aesthetically appealing because the data is
   sitting in our local queue instead of consuming resources inside the
   net.  We give data to the network only when it is ready to accept it.

データがネットでリソースを消費することの代わりに地元の待ち行列で座っているので、アルゴリズムの使用は美しく魅力的です。 それがそれを受け入れる準備ができているときだけ、私たちはデータをネットワークに与えます。

   An averaged minimum inter-datagram arrival value will give a measure
   of the network bottleneck speed at the receiver.  If the receiver
   does not defer or batch together acks the same would be learned from
   the inter-datagram arrival time of the acks.  A problem is that IP
   doesn't have knowledge of the datagram contents.  However IP does
   know from which host a datagram comes.

一緒にバッチは同じようにacksされます。または、平均した最小の相互データグラム到着価値が受信機でネットワークボトルネック速度の基準を与える、受信機が延期しない、acksの相互データグラム到着時間から、学習されるでしょう。 問題はIPにはデータグラムコンテンツに関する知識がないということです。 しかしながら、IPは、データグラムがどのホストから来るかを知っています。

Prue & Postel                                                  [Page 13]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[13ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   If SQuID limits the size of its pre-net buffering properly (causes
   back-pressure to TCP) then artificially high RTT measurements would
   not occur.

SQuIDが適切に(TCPに対する逆圧力の原因)をバッファリングしながらプレネットのサイズを制限するなら、人工的に高いRTT測定値は現れないでしょう。

   TCP might, in the future, get a way to query IP for the current
   introduced delay, D, for a given destination and if the value is too
   excessive abort or not start a session.

TCPは電流が与えられた目的地に遅れ、Dを導入して、値が過度過ぎるアボートであるか何か始めもセッションでないなら将来、IPについて質問する方法を得るかもしれません。

   With the new algorithm TCP could have an arbitrarily large window to
   send into without fear of over running queue sizes in intermediate
   nodes (not that any TCP ever considered having this fear before).
   Thus it could have a window size which would allow it to always be
   sending; keeping the pipe full and seldom getting in the stop-and-
   wait mode of sending.  This presupposes that the local IP is able to
   cause some sort of back pressure so that the local IPs queues are not
   over run.  TCP would still be operating in the burst mode of sending
   but the local IP would be sending a datagram for the TCP as often as
   the network could accept it keeping the data flow continuous though
   potentially slow.

TCPが走行の上に恐怖なしで発信する任意に大きい窓を持つことができた新しいアルゴリズムで、中間的ノードのサイズを列に並ばせてください(どんなTCPも、今までに以前この恐怖を持っていると考えたということでない)。 したがって、それがいつも発信するウィンドウサイズがあるかもしれません。 そして、パイプを完全に保って、めったに停止に入らない、-、-発信のモードを待ってください。 これが、ローカルアイピーがある種の逆圧を引き起こすことができるのを予想するので、走行の上にローカルアイピー待ち行列がありません。 TCPは発信のバーストモードでまだ作動しているでしょうが、ローカルアイピーはTCPのためにネットワークがもっとも、データフローが連続しているのに潜在的に遅いままでありながらそれを受け入れることができたのと同じくらい頻繁にデータグラムを送るでしょう。

   Experience implementing protocols suggests avoiding timers in
   protocols whenever possible.  IP, as currently defined, does not use
   timers. The SQuID algorithm uses two at the IP level.  A way to
   eliminate the introduced delay decrease timer is to decrease the D
   value when we check the send queue for data to send.  We would
   decrease "D" by one "J" unit if "S" time, or more, has elapsed.  The
   other timer is not so easily eliminated.  If the IP implementation is
   periodically awakened to check for work to do, it could check the
   time stamps of the head of the queues to see if any datagrams have
   waited long enough.  This would mean we would necessarily wait too
   long before sending, but it may not be too large of a variance from
   our desired rates.  The additional delay would help congestion and
   reduce our chances of SQ.  Another option is setting a real timer
   which is say 25-50% too large and hope that our periodic work in IP
   will allow us to notice a datagram is delayed enough, and send it.
   Upon sending the datagram we would cancel the timer, avoiding the
   timer interrupt and environment swap.  In other implementations the
   communications interface or the link level protocol may be able to
   provide the timing needed without interrupts to the main processor.

プロトコルを実行するという経験は、可能であるときはいつも、プロトコルでタイマを避けるのを示します。 現在定義されているとして、IPはタイマを使用しません。 SQuIDアルゴリズムはIPレベルに2を使用します。 導入された遅れ減少タイマを排除する方法は私たちがデータが送る送信キューをチェックするとき、D値を減少させることです。 「S」時間、または以上が経過したなら、私たちは1「J」ユニットで「D」を減少させるでしょう。 もう片方のタイマはそれほど容易に排除されません。 IP実現はしなければならない仕事がないかどうかチェックするために定期的に目を覚まさされるなら、それが、何かデータグラムが十分長い間待っているかどうか確認するために待ち行列のヘッドのタイムスタンプをチェックするかもしれません。 これは、私たちが必ずまた、ずっと前に発信しながら待つことを意味するでしょうが、それは私たちの必要なレートからの変化ではそれほど大きくないかもしれません。 追加遅れは、混雑を助けて、私たちのシンガポール航空の便名の可能性を小さくするでしょう。 別のオプションは大き過ぎる状態で25-50%を言って、IPにおける私たちの周期的な仕事が私たちを許容することを望むことである実際のタイマにデータグラムが十分遅れるのに気付いて、それを送るように設定することです。 データグラムを送ると、タイマ割込みと環境スワップを避けて、私たちはタイマを取り消すでしょう。 他の実現では、コミュニケーションインタフェースかリンク・レベルプロトコルが中断なしでメインプロセッサに必要であるタイミングを提供できるかもしれません。

   Background tasks like some file transfers could query IP for the
   latest delay characteristics for a given destination to determine if
   it is appropriate to consume network resources now or if it would be
   better to wait until later.

与えられた目的地が、現在ネットワーク資源を消費するのが適切であるかどうか、またはもっとあとまで待つほうがよいかどうか決定するように、いくつかのファイル転送のようなバックグラウンドタスクは最新の遅れの特性のためのIPについて質問するかもしれません。

   We should consider what would happen if IP, using the SQuID
   algorithm, and TCP both introduced delay between the datagrams.  If
   TCPs delay was greater than IP's, then when IP got the datagrams it

私たちは、IPと、SQuIDアルゴリズムを使用して、TCPの両方がデータグラムの間に遅れを導入するなら何が起こるかを考えるべきです。TCPs遅れがIPのより大きかったならいつIPがデータグラムを手に入れたか、それ

Prue & Postel                                                  [Page 14]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[14ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   would forward them immediately as described in the algorithm above.
   This is because when the IP send queue is empty and it has been at
   least as long as IP wants the higher level protocol, TCP, gets one
   free (no delay) send.  Note also that IP will be decreasing the
   amount of delay it wants introduced because of the successful
   transmissions without SQs.  This would affect other protocols who
   might also send to the same destination.  If TCP sends too quickly
   then IP will protect the network from its indiscretion as described
   in the basic algorithm however TCPs round trip time estimates will be
   much closer to reality.  A lost datagram will thus be detected more
   quickly.  If TCP also uses windowing to limit its sending rate, it
   might, because of its success with a smaller window, increase the
   window size increasing TCPs efficiency.

すぐ上のアルゴリズムで説明されるようにそれらを進めるでしょう。 これがIPであるときに、送信キューが空であるからであるそれは、より高い平らなプロトコル(TCP)が自由な1つ(遅れがない)を得るIP必需品が発信するのと少なくとも同じくらい長いです。 また、IPがそれがうまくいっているトランスミッションのためにSQsなしで導入して欲しい遅れの量を減少させることに注意してください。 これはまた、同じ目的地に発信するかもしれない他のプロトコルに影響するでしょう。 TCPがあまりにすばやく発信すると、IPはTCPs周遊旅行時間見積りが現実のはるかに近くにどのようにあっても基本的なアルゴリズムで説明されるように軽率からネットワークを保護するでしょう。 その結果、無くなっているデータグラムは、よりはやく検出されるでしょう。 より小さい窓がある成功のために、また、TCPが送付レートを制限するのにウインドーを使用するなら、それはウィンドウサイズの増加するTCPs効率を増加させるかもしれません。

   As this algorithm is implemented everywhere, the SQ Keep (SQK) and SQ
   Low Water (SQLW) queue level percentages should be dropped to reduce
   queue sizes and thus the through net delay.  The percentage we lower
   SQK and SQLW to should be adjusted based upon the percentage of time
   the queue is empty.  The more the queue is empty the more likely it
   is that the node is discouraging data flow too much.  The more time
   the queue is not empty but not too full, the more likely it is the
   node is not excessively discouraging data flow.  How uniform the
   queue size is, is a measure of how well the network citizens are
   behaved.

このアルゴリズムがいたる所で実行されるのに従って、シンガポール航空の便名Keep(SQK)とシンガポール航空の便名Low Water(SQLW)待ち行列レベル割合は、待ち行列サイズを減少させて、その結果、突き抜けるのをネットが遅らせる減少させるために落とされるべきです。 私たちがSQKとSQLWを下ろす割合は待ち行列が空である時の割合に基づいた状態で調整されるべきです。 待ち行列が空であれば空であるほど、ノードががっかりしているデータフローであり過ぎることは、よりありそうです。 待ち行列が空であるのではなく、それほど完全でないより多くの時代に、過度にがっかりしているデータフローはそれがノードであるより傾向があります。 どのようにが制服であるか。待ち行列サイズは、あって、ネットワーク市民がどれくらいよく振る舞うかに関する測定です。

   As the congestion is pushed to the sources, gateways which are
   bottlenecks can more easily detect someone not playing by the rules
   (sending datagrams in bursts) and deal with the offender.

混雑がソースに押されるとき、ボトルネックであるゲートウェイは、だれかがルールに従って行動しないのを(データグラムを送るのははち切れます)より容易に検出して、犯罪者に対応できます。

Prue & Postel                                                  [Page 15]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[15ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

Appendix A -- Determination of the Value for the Parameter "I"

付録A--「私」というパラメタのための価値の決断

   To get to the correct value for the delay needed quickly, when an
   event occurred and the currently used delay was minimal, the
   transmission time for an average sized datagram across the slowest
   communications link was used for a first value.  How a real IP node
   is to guess this value is discussed below.  In our example the
   transition between node 2 and node 3 is the bottleneck. Using the 56
   kb/s line, a 512 byte datagram would take 73 msec with no queuing or
   processing time is considered.  This value is defined to be the
   minimum inter-datagram arrival time (MIAT).  Assuming a perfect
   network, ignoring factors other than transmission speed, this is the
   minimum time one could expect between receipt of datagrams at the
   destination, because of the slowed data rate through the bottleneck.
   This won't hold true if the datagrams do not follow the same path.

出来事が起こって、現在中古の遅れが最小限であったときにすぐに必要である遅れのための正しい値を始めるために、最も遅いコミュニケーションリンクの向こう側の平均した大きさで分けられたデータグラムのためのトランスミッション時間は最初の値に使用されました。 以下で本当のIPノードがどうこの値を推測するかことであるのについて議論します。 私たちの例では、ノード2とノード3の間の変遷はボトルネックです。 56kb/s線を使用して、512バイトのデータグラムが列を作りなしで73msecを取るだろうか、または処理時間は考えられます。 この値は、最小の相互データグラム到着時間(MIAT)になるように定義されます。 伝送速度以外の要素を無視して、完全なネットワークを仮定して、これはものが目的地でデータグラムの領収書の間で予想できた最小の時間です、ボトルネックを通した遅くされたデータ信号速度のために。 データグラムが同じ経路に続かないと、これは有効でないでしょう。

   The MIAT, minimum inter-datagram arrival time, may be guessed at by
   comparing the arrival timestamps of consecutive datagrams from a
   source of data.  Each value to be considered needs to be adjusted up
   or down based upon the size between the second datagram received and
   the typical datagram size.  More simply stated, a datagram which is
   half the size of the average datagram can be transmitted across a
   line in half the time.  Therefore, double its IAT before considering
   it for an MIAT.  If the timestamp of a datagrams is taken based upon
   an event caused by the start of the datagram arriving, not the
   completion of the datagram arriving, then the first datagram's size
   is the limiting length and should be used to adjust its IAT.  In
   order to keep the algorithm simple, arrival times for short datagram
   could be ignored as could IATs which were orders of magnitude too
   large (see below).

MIAT(最小の相互データグラム到着時間)は、データの源から連続したデータグラムに関する到着タイムスタンプを比較することによって、推測されるかもしれません。 考えられる各値は、受け取られた2番目のデータグラムと典型的なデータグラムサイズの間のサイズで調整されているか、または下に基づく必要があります。 単により述べられていて、時間の半分線の向こう側に平均したデータグラムのサイズの半分であるデータグラムは送ることができます。 したがって、MIATのためにそれを考える前に、IATを倍にしてください。 データグラム到着の完成ではなく、データグラム到着の始まりで引き起こされた出来事に基づいた状態でデータグラムに関するタイムスタンプを取るなら、最初のデータグラムのサイズを制限の長さであり、IATを調整するのに使用するべきです。 アルゴリズムを簡単に保つためにまた、桁であったIATsであることができたことのように短いデータグラムのための到着時間を無視できました。多大(以下を見ます)。

   Once a minimal value is found based upon looking for small values
   over a minute or more, the value might be time averaged with a value
   kept like TCP's SRTT in order to reduce the effects of a false MIAT.
   We could assume the limiting facility would be a 9.6 kb/s line, a
   56-64 kb/s line, or a 1.5 Mb/s line.  These facilities would provide
   a MIAT of 427 msec, 73-64 msec, or 3 msec respectively, for a
   datagram 512 bytes long.  These are almost orders of magnitude in
   differences.  If the MIAT a node measures is not in this range but
   close, the value it is closest to may be used for its MIAT from that
   source.

かつて、最小量の値が小さい値を1分の上探すのに基づいているのがわかるか、値はさらに、値がTCPのSRTTのように保たれている状態で偽のMIATの効果を減少させるために平均された時間であるかもしれません。 私たちは、制限施設が9.6kb/s線、56-64kb/s線、または1.5Mb/sの線であると思うことができました。 これらの施設はそれぞれ427msec、73-64msec、または3msecのMIATを提供するでしょう、長さ512バイトのデータグラムのために。 これらは違いにおいてほとんど桁です。 ノードが測定するMIATがこの範囲にあるのではなく、近くにあるなら、それが最も近くにある値はMIATにそのソースから使用されるかもしれません。

   One of the good things about this measurement is that it is an
   entirely passive measurement.  No additional traffic is needed to
   measure it.  If a source is not sending data continuously then the
   longer measured values won't be validated as minimal values.  The
   assumption is that at least sometimes the source will send multiple
   datagrams at a time.

この測定の周りの良いものの1つはそれが完全に受け身の測定であるということです。 どんな追加交通も、それを測定するのに必要ではありません。 ソースが絶え間なくデータを送らないと、より長い測定値は最小量の値として有効にされないでしょう。 仮定は少なくとも時々、ソースが一度に複数のデータグラムを送るということです。

Prue & Postel                                                  [Page 16]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[16ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

   The MIAT measurement is totally unaffected by satellite delay
   characteristics of any intervening facilities.  The chance of getting
   a valid minimal reading is affected by the number of nodes traversed,
   but the value measured if it is valid will not be affected by the
   number of nodes traversed.  Stated another way, when a pair of
   datagrams traverse from one node to the next the datagrams are
   susceptible to being separated by a datagram from another source.
   Both of these factors affect SRTT. The value obtained requires no
   topological knowledge of the route.

MIAT測定はどんな介入している施設の衛星遅れの特性でも完全に影響を受けないです。 有効な最小量の読み始めるという機会は横断されたノードの数で影響を受けますが、それが有効であるなら測定された値は横断されたノードの数で影響を受けないでしょう。 述べられた別の方法、1組の1つのノードから次までのデータグラム横断であるときに、データグラムはデータグラムによって別のソースと切り離されるのに影響されやすいです。 これらの要素の両方がSRTTに影響します。 得られた値はルートに関するどんな位相的な知識も必要としません。

   A potential problem with the measurement is, it will not be the
   proper value for some forms of alternate routes.  If a T1 link is the
   bottleneck route some times and other times it is a 56 kb/s link our
   first guess for inter-datagram delay would be too small for the 56
   kb/s line route.  Another problem is that if one datagram goes via
   one route and the next goes via another, their inter-datagram arrival
   difference could lead to a small false measurement.  If intervening
   networks fragment datagrams then the measured IAT between segments
   could be misleading.  A solution to this problem is to ignore
   fragmented datagram IATs.

測定の潜在的な問題があって、それはいくつかの形式の代替経路への固有値でなくなるでしょう。 T1リンクが数回ボトルネックルートであり、それが56kb/sである他の回がリンクされるなら、56kb/s線ルートには、相互データグラム遅れのための私たちの最初の推測は小さ過ぎるでしょう。 別の問題は1個のデータグラムが1つのルートで動いていて、次が別のもので行くなら、それらの相互データグラム到着差が小さい誤った測定につながるかもしれないということです。 介入しているネットワークがデータグラムを断片化するなら、セグメントの間の測定IATは紛らわしいかもしれません。 この問題の解決は断片化しているデータグラムIATsを無視することです。

   This number represents the minimum inter-datagram delay the sending
   IP should use to send to us, the measuring site, for the given
   datagram size.  If we assume that the return path will be through the
   same facilities or the same type, then as described above this value
   can be the first guess for inter-datagram introduced delay, "D" (in
   the algorithm).  It represents the "I" parameter.

この数は送付IPが私たちに発信するのに使用するべきである最小の相互データグラム遅れを表します、測定サイト、与えられたデータグラムサイズのために。 私たちが、リターンパスが同じ施設か同じタイプであると思うなら、上で説明されるように、この値は相互データグラムの導入された遅れ、「D」(アルゴリズムによる)のための最初の推測であるかもしれません。 それは「私」パラメタを表します。

   These MIATs may be cached on a host, subnet, or network basis.  The
   last "n" hosts MIATs could be kept.  For infrequent destinations an
   entry per destination network would be applicable to many
   destinations.  If the local net is in fact a subnet, then the other
   local subnet MIATs could be kept.

これらのMIATsはホスト、サブネット、またはネットワークベースでキャッシュされるかもしれません。 最後の「n」ホストMIATsを保つことができました。 珍しい目的地に関しては、1送信先ネットワークあたり1つのエントリーが多くの目的地に適切でしょう。 事実上、ローカルのネットがサブネットであるなら、もう片方の地方のサブネットMIATsは保たれるかもしれません。

   If a good algorithm is found for MIAT, comparing it to the average
   IAT (during data transfer) would give a good measure of the amount of
   network traffic load.  Since IP has no idea when the source of data
   is sending as fast as possible, to get a valid average, upper layer
   protocols would have to figure this out for themselves.  IP could
   however provide an interface to get the current MIAT for a given
   destination.

良いアルゴリズムがMIATに関して見つけられるなら、平均したIAT(データ転送の間の)とそれを比較すると、ネットワークトラヒック負荷の量の良い基準は与えられるでしょう。 IPが、データの源がいつ有効な平均を得るためにできるだけ速く発信するかが分からないので、上側の層のプロトコルは自分たちのためにこれを見積もらなければならないでしょう。 しかしながら、IPは、与えられた目的地に現在のMIATを届けるためにインタフェースを提供できました。

Prue & Postel                                                  [Page 17]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

Prueとポステル[17ページ]RFC1016ソース焼き入れは1987年7月に遅れ--イカを導入しました。

References

参照

   [1]  Postel, Jon, "Internet Protocol - DARPA Internet Program
   Protocol Specification", RFC 791, ISI, September 1981.

[1] ポステル、ジョン、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC791、ISI、1981年9月。

   [2]  Postel, Jon, "Internet Control Message Protocol - DARPA Internet
   Program Protocol Specification", RFC 792, ISI, September 1981.

[2] ポステル、ジョン、「インターネットはメッセージプロトコルを制御します--DARPAインターネットはプロトコル仕様をプログラムする」RFC792、ISI、1981年9月。

   [3]  Karels, M., "Re: Source Quench", electronic mail message to J.
   Postel and INENG-INTEREST, Tue, 24 Feb 87.

[3]Karels、M.、「Re:」 「ソースQuench」とJ.ポステルへの電子メールメッセージとINENG-INTEREST、火曜日、1987年2月24日。

   [4] Nagle, John B., "On Packet Switches With Infinite Storage", RFC
   970, FACC Palo Alto, December 1985.

[4] ネーグル、ジョンB.、「無限の格納があるパケット交換機」、RFC970、FACCパロアルト1985年12月。

   [5] Jacobson, Van, "Re: interpacket arrival variance and mean",
   electronic mail message to TCP-IP,  Mon, 15 Jun 87 06:08:01 PDT

[5] ジェーコブソン、ヴァン、「Re:」 「interpacket到着変化と平均」、TCP-IPへの電子メールメッセージ、月曜日、1987年6月15日の太平洋夏時間6時8分1秒

   [6] Jacobson, Van, "Re: Appropriate measures of gateway performance"
   electronic mail message to J. Noel Chiappa  and INENG-INTEREST, Sun,
   22 Mar 87 15:04:44 PST.

[6] ジェーコブソン、ヴァン、「Re:」 1987年3月22日の太平洋標準時15時4分44秒のJ.クリスマスのChiappaとINENG-INTEREST、Sunまでの「ゲートウェイ性能の穏当な処置」電子メールメッセージ。

   [7] Nagle, John B., "Source quench, and congestion generally",
   electronic mail message to B. Braden and INENG-INTEREST, Thu, 5 Mar
   87 11:08:49 PST.

[7] ネーグル、ジョンB.は「一般に、焼き入れ、および混雑の出典を明示します」、B.への電子メールメッセージ。ブレーデンとINENG-INTEREST、木曜日(1987年3月5日の太平洋標準時11時8分49秒)。

   [8] Nagle, John B., "Congestion Control in IP/TCP Internetworks", RFC
   896, FACC Palo Alto, 6 January 1984.

[8] ネーグル、ジョンB.、「IP/TCPインターネットワークにおける輻輳制御」、RFC896、FACCパロアルト1984年1月6日。

Prue & Postel                                                  [Page 18]

Prueとポステル[18ページ]