RFC1018 日本語訳

Network Working Group                                        A. McKenzie
Request for Comments: 1018                                      BBN Labs
                                                             August 1987
                         Some Comments on SQuID

コメントを求めるワーキンググループA.マッケンジー要求をネットワークでつないでください: 1018年のBBN研究室1987年8月イカのいくつかのコメント

Status of this Memo

このMemoの状態

   This memo is a discussion of some of the ideas expressed in RFC-1016
   on Source Quench.  This memo introduces the distinction of the cause
   of congestion in a gateway between the effects of "Funneling" and
   "Mismatch".  It is offered in the same spirit as RFC-1016; to
   stimulate discussion.  The opinions offered are personal, not
   corporate, opinions.  Distribution of this memo is unlimited.

このメモはSource Quenchの上のRFC-1016に表されたいくつかの考えの議論です。 このメモは「注ぐこと」と「ミスマッチ」の効果にゲートウェイの混雑の原因の区別を取り入れます。 RFC-1016と同じ精神でそれを提供します。 議論を刺激するために。 提供された意見が法人であるのではなく個人的である、意見。 このメモの分配は無制限です。

Discussion

議論

   It appears to me that there are at least two qualitatively different
   types of congestion which may occur at Internet gateways.  One form
   of congestion is the result of the merger of several independent data
   streams from diverse sources at a common point in their communication
   path.  I'll refer to this as "Funneling".  The architecture of the
   Internet (apparently) assumes that traffic flows are bursty and
   asynchronous; therefore congestion which occurs at the result of
   Funneling will typically be the result of "bad luck" as several
   independent bursts happen to arrive at a common point simultaneously.
   It is expected that Funneling congestion will be short-lived, just as
   individual bursts are.  I don't claim that any such assumptions are
   documented or formalized; nevertheless I got a clear sense of this
   class of assumptions both from reading the protocol documentation and
   from personal recollections of long-past design meetings.

私にとって、インターネット・ゲートウェイに起こるかもしれない混雑の少なくとも2つの質的に異なったタイプがあるように見えます。 1つの形式の混雑は彼らの通信路の一般的なポイントのさまざまのソースからのいくつかの独立しているデータ・ストリームの合併の結果です。 私は「注ぐこと」にこれについて言及するつもりです。 インターネットの構造は、交通の流れがburstyであって非同期であると(明らかに)仮定します。 したがって、数回の独立している炸裂が同時にたまたま一般的なポイントに到着するので、Funnelingの結果で起こる混雑は「不運」の通常結果になるでしょう。 ちょうど個々の炸裂のようにFunneling混雑が短命になると予想されます。 私は、どんなそのような仮定も記録されるか、または正式にされると主張しません。 それにもかかわらず、私はプロトコルドキュメンテーションを読むことと、そして、長い過去のデザインミーティングの個人的な回想からこのクラスの仮定の明確な意味を得ました。

   A second form of Internet congestion may arise during a prolonged
   (non-bursty) data transfer between hosts when the resulting traffic
   must pass through a node connecting two communications subsystems
   with significantly different throughput rates.  I'll refer to this as
   "Mismatching".  By contrast with Funneling, Mismatching can be caused
   by the innocent action of a single host, is highly repeatable
   (definitely not just "bad luck"), and will be long-lived.

結果として起こる交通がノードを通り抜けなければならないとき、2番目の形式のインターネット混雑は、長引いている(非burstyの)データ転送の間、2つのコミュニケーションサブシステムをかなり異なった押出量に関連づけながら、ホストの間に起こるかもしれません。 私は「ミスマッチすること」にこれについて言及するつもりです。 対照的に、MismatchingはFunnelingと共に、独身のホストの潔白な動作で引き起こされる場合があって、非常に反復可能で(確実に「不運」であるだけではない)、長命になるでしょう。

   RFC- 1016 discusses two interrelated strategies; one for when to send
   a SQ, and a second for what to do when an SQ is received.  There is
   also a discussion of some experiments, which deal almost exclusively
   with Mismatching congestion. (I understand that the simulation can
   generate multiple flows, but these simply further increase the degree
   of Mismatch; the flow under study is long-lived by design.)  It seems
   to me that the strategy RFC- 1016 proposes for sending SQ's, based on
   queue length, may be appropriate for Funneling Congestion, but
   inappropriate for Mismatch congestion, as discussed below.  The host

RFC1016は2つの相関的な戦略について議論します。 いつシンガポール航空の便名を送るか間の1つ、およびするべきことのためのシンガポール航空の便名が受け取られている1秒。 また、いくつかの実験の議論があります。(実験はMismatching混雑に専ら対処します)。 (これらはMismatchの度を単にさらに増加させます; 私は、シミュレーションが複数の流れを発生させることができるのを理解していますが、研究している流れは故意に長命です。) RFC1016が待ち行列の長さに基づく送付シンガポール航空の便名のもののために提案する戦略がFunneling Congestionに適切ですが、Mismatch混雑に、不適当であるかもしれないように思えます、以下で議論するように。 ホスト

McKenzie                                                        [Page 1]

RFC 1018                 Some Comments on SQuID              August 1987

マッケンジー[1ページ]RFC1018 イカ1987年8月のいくつかのコメント

   behavior proposed in RFC- 1016 may be appropriate for both cases.

両方のケースに、RFC1016で提案された振舞いは適切であるかもしれません。

   Since we assume that Funneling congestion is the result of short-
   lived phenomena, it is appropriate for gateways which are the sites
   of this congestion to attempt to smooth it without excessive control
   actions.  This is the basis for the "hint" in the ICMP specification
   that maybe an SQ should be sent only when a datagram is dropped.  It
   is the basis for the idea in RFC- 1016 that a gateway should be slow
   to cry "congestion" (SQK = 70% of queue space filed), even if
   persistent in attempting to eliminate it (SQLW = 50% of queue space
   filled).  Since Funneling congestion is the result of the actions of
   multiple senders, the growth of internal queues is the only
   reasonable place to watch for its existence or measure its effects.

私たちが、Funneling混雑が短い送られた現象の結果であると思うので、この混雑の場所であるゲートウェイに、過度のコントロール動作なしでそれを整えるのを試みるのは適切です。 これはデータグラムを落とすときだけ、多分、シンガポール航空の便名を送るべきであるというICMP仕様に基づく「ヒント」の基礎です。 それはゲートウェイは「混雑」を泣かせるのが遅いはずであるという(70SQK=%の待ち行列スペースはファイルされました)RFC1016の考えの基礎です、それを排除するのを試みるのにおいてしつこくても(待ち行列スペースの50SQLW=%はいっぱいになりました)。 Funneling混雑が複数の送付者の動作の結果であるので、内部の待ち行列の成長は存在を待ち兼ねるか、または効果を測定する唯一の妥当な場所です。

   Mismatch congestion, on the other hand, is the result of incorrect or
   inadequate information about available transmission bandwidth on the
   part of a single sender. The sending host has available to it
   information about destination host capacity (TCP window size and ACK
   rate) and about local link capacity (from the hardware/software
   interface to the directly-connected network), but no real information
   about the capacity of the Internet path.  As noted in RFC-1016, hosts
   can obtain the best throughput if their datagrams are never dropped,
   and the probability of dropped datagrams is minimized when hosts send
   at the appropriate steady-state rate (no "bunching").  Therefore, it
   is a disservice to a host which is the source of Mismatch congestion
   to wait a "long" time before taking control action.  It would be
   preferable to provide immediate feedback, via SQ's, to the host as
   soon as datagrams with too short an inter-arrival time begin to
   arrive.  The sending host could then immediately (begin to) adjust
   its behavior for the indicated destination.

他方では、ミスマッチ混雑は独身の送付者側の利用可能なトランスミッション帯域幅の不正確であるか不十分な情報の結果です。 あて先ホスト容量(TCPウィンドウサイズとACKは評価する)と地方のリンク容量(ハードウェア/ソフトウェア・インタフェースから直接接続されたネットワークまでの)の情報を持っていますが、送付ホストはインターネット経路の容量のそれに利用可能などんな本当の情報も持っていません。 RFC-1016に述べられるように、彼らのデータグラムが決して落とされないで、ホストが適切な定常状態レート(「束にならない」)で発信するとき低下しているデータグラムの確率が最小にされるなら、ホストは最も良い効率を得ることができます。 したがって、それはホストへのコントロール行動を取る「長い」時以前待つMismatch混雑の源である害です。 即座のフィードバックを提供するのは望ましいでしょう、シンガポール航空の便名のもので、短過ぎる相互到着時間があるデータグラムが到着し始めるとすぐにホストに。 そして、すぐに(そうし始める)、送付ホストは示された目的地のための振舞いを調整できました。

   There are, of course, many implementation issues which would need to
   be addressed in order to implement the type of SQ-sending behavior
   suggested here.  Perhaps, though, they are not as severe as they
   might appear.  Two specific issues and possible solutions, are:

もちろん、ここに示されたシンガポール航空の便名を送る振舞いのタイプを実行するために記述される必要がある多くの導入問題があります。 もっとも、恐らく、それらは彼らが現れるかもしれないほど厳しくはありません。 2つの特定の冊と可能な解決策は以下の通りです。

      1. How should a gateway differentiate between Funneling and
      mismatch congestion?  Perhaps whenever there are more than q"
      items on an output queue to a slower subnet which have been
      received from a faster subnet, then look to see if any h" of them
      have the same source.  It so assume Mismatch and send an SQ to
      that source.  The "q" test might be implemented by a small set of
      counters which are incremented when a packet is placed on an
      output queue and decremented when a packet is sent.  The search
      for a common source might require more cycles but be performed
      less often.  The value of "q" would have to be small enough to
      give an early warning, but bigger than a small multiple of "h".
      The value of "h" would have to be big enough to avoid triggering

1. ゲートウェイは、どのようにFunnelingを区別して、混雑にミスマッチするはずですか? 「q以上がある恐らくときはいつも、」のときに、より遅いサブネットへの出力キューの、より速いサブネットから受け取られて、次にもしあればそれらのh」を見るために見る項目には、同じソースがあります。 それは、したがって、Mismatchを仮定して、そのソースにシンガポール航空の便名を送ります。 「q」テストはパケットを送るとき、出力キューにパケットを置くとき、増加して、減少させる小さいセットのカウンタによって実行されるかもしれません。 共通ソースの検索は、より多くのサイクルを必要としますが、よりしばしば実行されるかもしれません。 「q」の値は、早期警戒を与えることができるくらい小さくて、しかし、「h」のわずかな倍数より大きくなければならないでしょう。 「h」の値は引き金となるのを避けることができるくらい大きくなければならないでしょう。

McKenzie                                                        [Page 2]

RFC 1018                 Some Comments on SQuID              August 1987

マッケンジー[2ページ]RFC1018 イカ1987年8月のいくつかのコメント

      on common cases of source datagram fragmentation by an
      intermediate gateway.

中間ゲートウェイのそばでのソースデータグラム断片化のよくある例に関して。

      2. How can a gateway determine which subnets are "slower" and
      faster", as well as appropriate inter-arrival times?  There may be
      lots of clever ways for a gateway to measure the dynamic bandwidth
      of its directly-connected subnets.  However, I'm more in favor of
      starting with configuration parameters related to the known (at
      installation time) general characteristics of subnet types (e.g.
      Ethernet is 10Mbps, ARPANET is 50 Kbps, SATNET is 100 Kbps, etc).
      This sort of approximation is quite adequate for determining which
      subnet is faster, or what inter-arrival time is appropriate for
      packets being routed to a slower subnet.

2. 適切な相互到着時間と同様に「ゲートウェイは、どちらのサブネットが「より遅く」より速いかをどのように決定できますか?」 ゲートウェイが直接接続されたサブネットのダイナミックな帯域幅を測定する多くの賢明な方法があるかもしれません。 しかしながら、さらにサブネットタイプの知られている(インストール時の)一般的特色に関連する設定パラメータから始まることを支持して私はいます(例えば、イーサネットが10Mbpsである、アルパネットが50Kbpsである、SATNETは100Kbpsですなど)。 どちらのサブネットが、より速いか、そして、または、より遅いサブネットに発送されるパケットに、どんな相互到着時間が適切であるかを決定するのに、この種類の近似はかなり適切です。

Summary

概要

   Funneling congestion and Mismatch congestion are qualitatively
   different, and it would not be surprising if different SQ-sending
   strategies were best for dealing with them.  RFC- 1016 suggests a
   specific SQ-sending strategy which may be inappropriate for dealing
   with Mismatch congestion.  This RFC suggests guidelines for an
   additional SQ-sending strategy for dealing with Mismatch.  Hosts
   implementing the SQuID algorithm of RFC-1016 should be expected to
   achieve better performance if they received SQ's sent according to
   either or both of these strategies.  However, all these ideas are
   still only in half-baked form; real engineering is clearly needed.

混雑を注いで、Mismatch混雑は質的に異なっています、そして、それらに対処するのに、異なったシンガポール航空の便名を送る戦略が最も良いなら、驚くべきものでないでしょうに。 RFC1016はMismatch混雑に対処するのに、不適当であるかもしれないシンガポール航空の便名を送る特定の戦略を勧めます。 このRFCはMismatchに対処するための追加シンガポール航空の便名を送る戦略のためのガイドラインを勧めます。 彼らがこれらの戦略のどちらかか両方に応じて送った状態でシンガポール航空の便名のものを受けるなら、RFC-1016のSQuIDアルゴリズムを実行するホストが、より良い性能を達成すると予想されるでしょうに。 しかしながら、これらのすべての考えがまだ生半可なフォームだけにあります。 本当の工学が明確に必要です。

McKenzie                                                        [Page 3]

マッケンジー[3ページ]