RFC1254 日本語訳
1254 Gateway Congestion Control Survey. A. Mankin, K. Ramakrishnan. August 1991. (Format: TXT=67609 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Mankin
Request for Comments: 1254 MITRE
K. Ramakrishnan
Digital Equipment Corporation
Editors
August 1991
コメントを求めるワーキンググループA.マンキンの要求をネットワークでつないでください: 1254 斜め継ぎK.Ramakrishnan DECエディターズ1991年8月
Gateway Congestion Control Survey
ゲートウェイ混雑基準測量
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It is a survey of some of the major directions and issues. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それは主要な指示といくつかの問題の調査です。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
The growth of network intensive Internet applications has made gateway congestion control a high priority. The IETF Performance and Congestion Control Working Group surveyed and reviewed gateway congestion control and avoidance approaches. The purpose of this paper is to present our review of the congestion control approaches, as a way of encouraging new discussion and experimentation. Included in the survey are Source Quench, Random Drop, Congestion Indication (DEC Bit), and Fair Queueing. The task remains for Internet implementors to determine and agree on the most effective mechanisms for controlling gateway congestion.
ネットワークの徹底的なインターネットアプリケーションの成長はゲートウェイ輻輳制御を高い優先度にしました。 IETFパフォーマンスとCongestion Control作業部会は、ゲートウェイ輻輳制御と回避アプローチを調査して、見直しました。 この紙の目的は私たちの輻輳制御アプローチのレビューを提示することです、新しい議論と実験を奨励する方法として。 調査に含まれているのは、Source Quenchと、Random Dropと、Congestion Indication(12月のBit)と、Fair Queueingです。 インターネット作成者がゲートウェイ混雑を制御するために最も効果的なメカニズムを決定して、同意するように、タスクは残っています。
1. Introduction
1. 序論
Internet users regularly encounter congestion, often in mild forms. However, severe congestion episodes have been reported also; and gateway congestion remains an obstacle for Internet applications such as scientific supercomputing data transfer. The need for Internet congestion control originally became apparent during several periods of 1986 and 1987, when the Internet experienced the "congestion collapse" condition predicted by Nagle [Nag84]. A large number of widely dispersed Internet sites experienced simultaneous slowdown or cessation of networking services for prolonged periods. BBN, the firm responsible for maintaining the then backbone of the Internet, the ARPANET, responded to the collapse by adding link capacity [Gar87].
インターネットユーザは定期的にしばしば軽症型における混雑に遭遇します。しかしながら、また、厳しい混雑エピソードは報告されました。 そして、ゲートウェイ混雑は科学的スーパー計算データ転送などのインターネットアプリケーションのための障害のままで残っています。 インターネット輻輳制御の必要性は元々、いくつかの期間の1986年と1987年間、明らかになりました。(その時、インターネットはネーグル[Nag84]によって予測された「混雑崩壊」状態になりました)。 多くの広く分散しているインターネット・サイトが長期の間、ネットワークサービスの同時のスローダウンか休止になりました。 BBN、インターネットの当時の背骨を維持するのに責任がある会社(アルパネット)は、リンク容量[Gar87]を加えることによって、崩壊に応じました。
Much of the Internet now uses as a transmission backbone the National Science Foundation Network (NSFNET). Extensive monitoring and capacity planning are being done for the NSFNET backbone; still, as
インターネットの大部分は現在、トランスミッション背骨として国立科学財団Network(NSFNET)を使用します。 NSFNET背骨のために大規模なモニターとキャパシティプランニングをしています。 as
Performance and Congestion Control Working Group [Page 1] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[1ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
the demand for this capacity grows, and as resource-intensive applications such as wide-area file system management [Sp89] increasingly use the backbone, effective congestion control policies will be a critical requirement.
この容量の需要は増大します、そして、広い領域ファイルシステム管理[Sp89]などの資源集約的な応用がますます背骨を使用するとき、効果的な輻輳制御方針は重大な要件になるでしょう。
Only a few mechanisms currently exist in Internet hosts and gateways to avoid or control congestion. The mechanisms for handling congestion set forth in the specifications for the DoD Internet protocols are limited to:
ほんのいくつかのメカニズムが現在、インターネット・ホストと避けるゲートウェイかコントロール混雑で存在します。 DoDインターネットプロトコルのための仕様に詳しく説明された取り扱い混雑のためのメカニズムは以下のことのために制限されます。
Window flow control in TCP [Pos81b], intended primarily for
controlling the demand on the receiver's capacity, both in terms
of processing and buffers.
受信機の容量で処理とバッファに関して主として要求を制御するために意図するTCP[Pos81b]の窓のフロー制御。
Source quench in ICMP, the message sent by IP to request that a
sender throttle back [Pos81a].
ICMPでのソース焼き入れ、送付者スロットルが[Pos81a]を支持するよう要求するためにIPによって送られたメッセージ。
One approach to enhancing Internet congestion control has been to overlay the simple existing mechanisms in TCP and ICMP with more powerful ones. Since 1987, the TCP congestion control policy, Slow- start, a collection of several algorithms developed by Van Jacobson and Mike Karels [Jac88], has been widely adopted. Successful Internet experiences with Slow-start led to the Host Requirements RFC [HREQ89] classifying the algorithms as mandatory for TCP. Slow-start modifies the user's demand when congestion reaches such a point that packets are dropped at the gateway. By the time such overflows occur, the gateway is congested. Jacobson writes that the Slow-start policy is intended to function best with a complementary gateway policy [Jac88].
インターネット輻輳制御を機能アップすることへの1つのアプローチがオーバレイのTCPの簡単な既存のメカニズムと、より強力なものがあるICMPに行ったことがあります。 1987、TCP輻輳制御方針以来、Slow始め(ヴァン・ジェーコブソンとマイクKarels[Jac88]によって開発されたいくつかのアルゴリズムの収集)は広く採用されます。 Slow-始めのうまくいっているインターネット経験は、TCPに義務的であるとしてアルゴリズムを分類しながら、Host Requirements RFC[HREQ89]に通じました。 混雑がそのようなポイントに達するのでパケットがゲートウェイで落とされるとき、遅れた出発はユーザの要求を変更します。 そのようなオーバーフローが起こる時までには、ゲートウェイは混雑しています。 ジェーコブソンは、補足的なゲートウェイ方針[Jac88]でSlow-スタート方針が最もよく機能することを意図すると書きます。
1.1 Definitions
1.1 定義
The characteristics of the Internet that we are interested in include that it is, in general, an arbitrary mesh-connected network. The internetwork protocol is connectionless. The number of users that place demands on the network is not limited by any explicit mechanism; no reservation of resources occurs and transport layer set-ups are not disallowed due to lack of resources. A path from a source to destination host may have multiple hops, through several gateways and links. Paths through the Internet may be heterogeneous (though homogeneous paths also exist and experience congestion). That is, links may be of different speeds. Also, the gateways and hosts may be of different speeds or may be providing only a part of their processing power to communication-related activity. The buffers for storing information flowing through Internet gateways are finite. The nature of the internet protocol is to drop packets when these buffers overflow.
私たちが興味を持っているインターネットの特性はそれを含んでいます。一般に、それは任意のメッシュで接続されたネットワークです。 インターネットワークプロトコルはコネクションレスです。 要求をネットワークに置くユーザの数はどんな明白なメカニズムによっても制限されません。 リソースの予約は全く起こりません、そして、トランスポート層セットアップは財源不足のため禁じられません。 ソースからあて先ホストまでの経路は数門とリンクを通して複数のホップを持っているかもしれません。 インターネットを通した経路は異種であるかもしれません(均質の経路が、また、存在していて、混雑になりますが)。 すなわち、リンクは異なった速度のものであるかもしれません。 また、ゲートウェイとホストは、異なった速度があるか、またはそれらの処理能力の一部だけをコミュニケーション関連の活動に提供しているかもしれません。 インターネット・ゲートウェイを通して流れる情報を格納するためのバッファは有限です。 インターネットプロトコルの本質はこれらのバッファがあふれるとパケットを落とすことです。
Performance and Congestion Control Working Group [Page 2] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[2ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
Gateway congestion arises when the demand for one or more of the resources of the gateway exceeds the capacity of that resource. The resources include transmission links, processing, and space used for buffering. Operationally, uncongested gateways operate with little queueing on average, where the queue is the waiting line for a particular resource of the gateway. One commonly used quantitative definition [Kle79] for when a resource is congested is when the operating point is greater than the point at which resource power is maximum, where resource power is defined as the ratio of throughput to delay (See Section 2.2). At this operating point, the average queue size is close to one, including the packet in service. Note that this is a long-term average queue size. Several definitions exist for the timescale of averaging for congestion detection and control, such as dominant round-trip time and queue regeneration cycle (see Section 2.1).
ゲートウェイに関するリソースの1つ以上の要求がそのリソースの容量を超えていると、ゲートウェイ混雑は起こります。 リソースはバッファリングに使用されるトランスミッションリンク、処理、およびスペースを含んでいます。 操作上、非充血しているゲートウェイは待ち行列でほとんど平均的に作動しません、待ち行列がゲートウェイの特定のリソースのための待ち行列であるところで。 リソースが混雑している時の間の1つの一般的に使用された量的な定義[Kle79]が操作ポイントがリソースパワーが最大であるポイントより大きい時です、リソースパワーが延着するようにスループットの比率と定義されるところで(セクション2.2を見てください)。 この操作ポイントでは、平均した待ち行列サイズは使用中の状態でパケットを含むおよそ1つです。 これが長期の平均した待ち行列サイズであることに注意してください。 いくつかの定義が、混雑のために検出を平均するスケールと優位な往復の時間などのコントロールのために存在していて、再生サイクルを列に並ばせます(セクション2.1を見てください)。
Mechanisms for handling congestion may be divided into two categories, congestion recovery and congestion avoidance. Congestion recovery tries to restore an operating state, when demand has already exceeded capacity. Congestion avoidance is preventive in nature. It tries to keep the demand on the network at or near the point of maximum power, so that congestion never occurs. Without congestion recovery, the network may cease to operate entirely (zero throughput), whereas the Internet has been operating without congestion avoidance for a long time. Overall performance may improve with an effective congestion avoidance mechanism. Even if effective congestion avoidance was in place, congestion recovery schemes would still be required, to retain throughput in the face of sudden changes (increase of demand, loss of resources) that can lead to congestion.
取り扱い混雑のためのメカニズムは2つのカテゴリ、混雑回復、および輻輳回避に分割されるかもしれません。 要求が既に容量を超えたとき、混雑回復は作動状態を回復しようとします。 輻輳回避は現実に予防しています。 それはポイントにおける、または、最大の力のポイントの近くのネットワークに要求を保とうとします、混雑が決して起こらないように。 混雑回復がなければ、ネットワークは、完全に作動するのをやめるかもしれませんが(スループットのゼロを合わせてください)、インターネットは長い間輻輳回避なしで作動しています。 総合的な性能は有効な輻輳回避メカニズムで向上するかもしれません。 有効な輻輳回避が適所にあったとしても、混雑回復計画が、混雑に通じることができる急変(需要増加、リソースの損失)に直面してスループットを保有するのにまだ必要でしょうに。
In this paper, the term "user" refers to each individual transport (TCP or another transport protocol) entity. For example, a TCP connection is a "user" in this terminology. The terms "flow" and "stream" are used by some authors in the same sense. Some of the congestion control policies discussed in this paper, such as Selective Feedback Congestion Indication and Fair Queueing aggregate multiple TCP connections from a single host (or between a source host-destination host pair) as a virtual user.
この紙では、「ユーザ」という用語はそれぞれの個々の輸送(TCPか別のトランスポート・プロトコル)実体について言及します。 例えば、TCP接続はこの用語で「ユーザ」です。 用語「流れ」と「流れ」は同じ意味で何人かの作者によって使用されます。 Selective Feedback Congestion IndicationやFair Queueingなどのこの紙で議論した輻輳制御方針のいくつかが仮想のユーザとして独身のホスト(またはソースホスト兼あて先ホスト組の間で)から複数のTCP接続に集められます。
The term "cooperating transport entities" will be defined as a set of TCP connections (for example) which follow an effective method of adjusting their demand on the Internet in response to congestion. The most restrictive interpretation of this term is that the transport entities follow identical algorithms for congestion control and avoidance. However, there may be some variation in these algorithms. The extent to which heterogeneous end-system congestion control and avoidance may be accommodated by gateway policies should
「協力関係を持っている輸送実体」という用語はインターネットで混雑に対応して彼らの要求を調整する有効な手段に従うTCP接続(例えば)のセットと定義されるでしょう。 今期の最も制限している解釈は輸送実体が輻輳制御と回避のための同じアルゴリズムに従うということです。 しかしながら、これらのアルゴリズムの何らかの変化があるかもしれません。異種のエンドシステム輻輳制御と回避がゲートウェイ方針で設備されるかもしれない範囲はそうするべきです。
Performance and Congestion Control Working Group [Page 3] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[3ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
be a subject of future research. The role played in Internet performance of non-cooperating transport entities is discussed in Section 5.
今後の研究の対象になってください。 セクション5で非協力輸送実体のインターネット性能で果たされた役割について議論します。
1.2 Goals and Scope of This Paper
1.2 この紙の目標と範囲
The task remains for Internet implementors to determine effective mechanisms for controlling gateway congestion. There has been minimal common practice on which to base recommendations for Internet gateway congestion control. In this survey, we describe the characteristics of one experimental gateway congestion management policy, Random Drop, and several that are better-known: Source Quench, Congestion Indication, Selective Feedback Congestion Indication, and Fair Queueing, both Bit-Round and Stochastic. A motivation for documenting Random Drop is that it has as primary goals low overhead and suitability for scaling up for Internets with higher speed links. Both of these are important goals for future gateway implementations that will have fast links, fast processors, and will have to serve large numbers of interconnected hosts.
インターネット作成者がゲートウェイ混雑を制御するために有効なメカニズムを決定するように、タスクは残っています。 インターネット・ゲートウェイ輻輳制御のための推薦を基礎づける最小量の一般的な習慣がありました。 この調査では、私たちは、よりよく知られている1つの実験ゲートウェイ混雑経営政策、Random Drop、および数個の特性について説明します: ソースQuench、Congestion Indication、Selective Feedback Congestion Indication、およびFair Queueing、ラウンドのBitとStochasticの両方。 Random Dropを記録することに関する動機はそれには第一の目標として、より高い速度リンクがあるInternetsのために拡大することへの低いオーバーヘッドと適合があるということです。 これらの両方が速いリンク、速いプロセッサを持って、多くのインタコネクトされたホストに役立たなければならない今後のゲートウェイ実現の重要な目標です。
The structure of this paper is as follows. First, we discuss performance goals, including timescale and fairness considerations. Second, we discuss the gateway congestion control policies. Random Drop is sketched out, with a recommendation for using it for congestion recovery and a separate section on its use as congestion avoidance. Third, since gateway congestion control in itself does not change the end-systems' demand, we briefly present the effective responses to these policies by two end-system congestion control schemes, Slow-start and End-System Congestion Indication. Among our conclusions, we address the issues of transport entities that do not cooperate with gateway congestion control. As an appendix, because of the potential interactions with gateway congestion policies, we report on a scheme to help in controlling the performance of Internet gateways to connection-oriented subnets (in particular, X.25).
この紙の構造は以下の通りです。 まず最初に、私たちはスケールと公正問題を含む性能目標について議論します。 2番目に、私たちはゲートウェイ輻輳制御方針について議論します。 無作為のDropは概略を述べられます、使用の混雑回復と別々のセクションに輻輳回避としてそれを使用するための推薦で。 ゲートウェイ輻輳制御が本来エンドシステムの要求を変えないで以来の3番目、2つのエンドシステム輻輳制御計画(Slow-始めとEnd-システムCongestion Indication)で私たちは簡潔にこれらの方針への有効な応答を提示します。 私たちの結論の中では、私たちはゲートウェイ輻輳制御と協力しない輸送実体の問題を記述します。 付録として、ゲートウェイ混雑方針との潜在的相互作用のために、私たちは、計画に関して接続指向のサブネット(特にX.25)へのインターネット・ゲートウェイの性能を制御するのを手伝うと報告します。
Resources in the current Internet are not charged to users of them. Congestion avoidance techniques cannot be expected to help when users increase beyond the capacity of the underlying facilities. There are two possible solutions for this, increase the facilities and available bandwidth, or forcibly reduce the demand. When congestion is persistent despite implemented congestion control mechanisms, administrative responses are needed. These are naturally not within the scope of this paper. Also outside the scope of this paper are routing techniques that may be used to relocate demand away from congested individual resources (e.g., path-splitting and load- balancing).
現在のインターネットのリソースは彼らのユーザに請求されません。 輻輳回避のテクニックが、ユーザが基本的な施設の容量を超えたところまで増加するのを助けることを期待できません。 この2つの可能な解決策があるか、施設と利用可能な帯域幅を増加させるか、または強制的に需要を抑えてください。 実行された混雑制御機構にもかかわらず、混雑がしつこいときに、管理応答が必要です。 これらはこの紙の範囲の中で自然にそうしていません。 この紙の範囲の外にも、混雑している個々のリソース(例えば、経路分かれると負荷バランスをとること)から遠くに要求を移動させるのに使用されるかもしれないルーティングのテクニックがあります。
Performance and Congestion Control Working Group [Page 4] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[4ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
2. Performance Goals
2. パフォーマンス目標
To be able to discuss design and use of various mechanisms for improving Internetwork performance, we need to have clear performance goals for the operation of gateways and sets of end-systems. Internet experience shows that congestion control should be based on adaptive principles; this requires efficient computation of metrics by algorithms for congestion control. The first issue is that of the interval over which these metrics are estimated and/or measured.
様々なメカニズムのInternetwork性能を向上させるデザインと使用について議論できるように、私たちはエンドシステムのゲートウェイとセットの操作の明確な性能目標を必要とします。インターネット経験は、輻輳制御が適応型の原則に基づくべきであるのを示します。 これは輻輳制御のためのアルゴリズムによる測定基準の効率的な計算を必要とします。 創刊号はこれらの測定基準が見積もられている、そして/または、測定される間隔のものです。
2.1 Interval for Measurement/Estimation of Performance Metrics
2.1 パフォーマンス測定基準に関する測定/見積りのための間隔
Network performance metrics may be distorted if they are computed over intervals that are too short or too long relative to the dynamic characteristics of the network. For instance, within a small interval, two FTP users with equal paths may appear to have sharply different demands, as an effect of brief, transient fluctuations in their respective processing. An overly long averaging interval results in distortions because of the changing number of users sharing the resource measured during the time. It is similarly important for congestion control mechanisms exerted at end systems to find an appropriate interval for control.
それらが短過ぎるか、またはネットワークの動特性に比例して長過ぎる間隔にわたって計算されるなら、ネットワーク性能測定基準は歪められるかもしれません。 例えば、小さい間隔以内に等しい経路をもっている2人のFTPユーザが、鋭く異なった要求を持っているように見えるかもしれません、彼らのそれぞれの処理における簡潔で、一時的な変動の効果として。 ひどく長い平均した間隔は時間測定されたリソースを共有しているユーザの変化番号のためにひずみをもたらします。 エンドシステムで出された混雑制御機構には、コントロールに関して適切な間隔を見つけるのは同様に重要です。
The first approach to the monitoring, or averaging, interval for congestion control is one based on round-trip times. The rationale for it is as follows: control mechanisms must adapt to changes in Internet congestion as quickly as possible. Even on an uncongested path, changed conditions will not be detected by the sender faster than a round-trip time. The effect of a sending end-system's control will also not be seen in less than a round-trip time in the entire path as well as at the end systems. For the control mechanism to be adaptive, new information on the path is needed before making a modification to the control exerted. The statistics and metrics used in congestion control must be able to provide information to the control mechanism so that it can make an informed decision. Transient information which may be obsolete before a change is made by the end-system should be avoided. This implies the monitoring/estimating interval is one lasting one or more round trips. The requirements described here give bounds on:
輻輳制御のためのモニターしているか、平均した間隔への最初のアプローチは往復の回に基づいた1です。 それのための原理は以下の通りです: 制御機構はできるだけはやくインターネット混雑における変化に順応しなければなりません。 非充血している経路にさえ、変えられた状態は送付者によって往復の時間より速く検出されないでしょう。 また、送付エンドシステムのコントロールの効果は全体の経路とエンドシステムで往復の時間以下で見られないでしょう。コントロールへの変更を出させる前に、制御機構が経路の適応型の、そして、新しい情報であることが必要です。 輻輳制御に使用される統計と測定基準は、十分な情報に基づいた判断を下すことができるように情報を制御機構に供給できなければなりません。 変更がエンドシステムによって行われる前に時代遅れであるかもしれない一時的な情報は避けられるべきです。 これは、モニター/推計間隔が1回の永久のものか、より丸い旅行であることを含意します。 ここで説明された要件は以下で領域を与えます。
How short an interval: not small enough that obsolete information
is used for control;
どれくらい短い間隔: 時代遅れの情報がコントロールに使用されるほど小さくない。
How long: not more than the period at which the end-system makes
changes.
どれくらい長い: エンドシステムが変更を行う期間だけ。
But, from the point of view of the gateway congestion control policy, what is a round-trip time? If all the users of a given gateway have
しかし、ゲートウェイ輻輳制御方針の観点から、往復の時間は何ですか? 与えられたゲートウェイのすべてのユーザがそうしたなら
Performance and Congestion Control Working Group [Page 5] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[5ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
the same path through the Internet, they also have the same round- trip time through the gateway. But this is rarely the case.
インターネットを通した同じ経路、彼らもゲートウェイを通して同丸い旅行時間を過します。 しかし、めったにこれはそうではありません。
A meaningful interval must be found for users with both short and long paths. Two approaches have been suggested for estimating this dynamically, queue regeneration cycle and frequency analysis.
ユーザのために短いものと同様に長い経路で重要な間隔を見つけなければなりません。 2つのアプローチがダイナミックにこれを見積もるために示されて、待ち行列再生は、サイクルと周波数解析です。
Use of the queue regeneration cycle has been described as part of the Congestion Indication policy. The time period used for averaging here begins when a resource goes from the idle to busy state. The basic interval for averaging is a "regeneration cycle" which is in the form of busy and idle intervals. Because an average based on a single previous regeneration may become old information, the recommendation in [JRC87] is to average over the sum of two intervals, that is, the previous (busy and idle) period, and the time since the beginning of the current busy period.
待ち行列再生サイクルの使用はCongestion Indication方針の一部として記述されています。 リソースが状態と忙しくしに活動していなさから行くとき、ここでの平均のために費やされた期間は始まります。 平均のための基本的な間隔は忙しくて活動していない間隔の形にある「再生サイクル」です。 現在の忙しい期間の初め以来前のただ一つの再生に基づく平均が旧情報になるかもしれないのが、合計2回の間隔、すなわち、前の(忙しく活動していません)の期間、および回の間、平均への[JRC87]の推薦の理由です。
If the gateway users are window-based transport entities, it is possible to see how the regeneration interval responds to their round-trip times. If a user with a long round-trip time has the dominant traffic, the queue length may be zero only when that user is awaiting acknowledgements. Then the users with short paths will receive gateway congestion information that is averaged over several of their round-trip times. If the short path traffic dominates the activity in the gateway, i.e., the connections with shorter round- trip times are the dominant users of the gateway resources, then the regeneration interval is shorter and the information communicated to them can be more timely. In this case, users with longer paths receive, in one of their round-trip times, multiple samples of the dominant traffic; the end system averaging is based on individual user's intervals, so that these multiple samples are integrated appropriately for these connections with longer paths.
ゲートウェイユーザが窓のベースの輸送実体であるなら、再生間隔がどう彼らの往復の時代まで応じるかを見るのは可能です。 そのユーザが承認を待っているときだけ、長い往復の時間をもっているユーザに優位な交通があるなら、待ち行列の長さはゼロであるかもしれません。 そして、短い経路をもっているユーザは彼らのいくつかの往復の時代にわたって平均されているゲートウェイ混雑情報を受け取るでしょう。 短い経路交通がゲートウェイで活動を支配しているなら、すなわち、より短い丸い旅行時間との関係はゲートウェイリソースの優位なユーザです、そして、次に、再生間隔は、より短いです、そして、彼らに伝えられた情報は、よりタイムリーである場合があります。 この場合、より長い経路をもっているユーザは彼らの往復の時代の1つのときに優位な交通の複数のサンプルを受け取ります。 終わりのシステム平均は個々のユーザの間隔に基づいています、より長い経路とのこれらの関係において、これらの複数のサンプルが適切に統合しているように。
The use of frequency analysis has been described by [Jac89]. In this approach, the gateway congestion control is done at intervals based on spectral analysis of the traffic arrivals. It is possible for users to have round-trip times close to each other, but be out of phase from each other. A spectral analysis algorithm detects this. Otherwise, if multiple round-trip times are significant, multiple intervals will be identified. Either one of these will be predominant, or several will be comparable. An as yet difficult problem for the design of algorithms accomplishing this technique is the likelihood of "locking" to the frequency of periodic traffic of low intensity, such as routing updates.
周波数解析の使用は[Jac89]によって説明されます。 このアプローチでは、交通到着のスペクトル解析に基づく間隔を置いて、ゲートウェイ輻輳制御をします。 ユーザが互いの近くで往復の時を過すのが、可能ですが、互いからのフェーズから脱してください。 スペクトル解析アルゴリズムはこれを検出します。 さもなければ、複数の往復の回が重要であるなら、複数の間隔が特定されるでしょう。 数個がこれらのどちらかが支配的になるだろうか、または匹敵するようになるでしょう。 まだ、このテクニックを達成するアルゴリズムのデザインのための難問は低強度の周期的な交通の頻度に「ロック」であるという見込みです、ルーティングアップデートなどのように。
Performance and Congestion Control Working Group [Page 6] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[6ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
2.2 Power and its Relationship to the Operating Point
2.2 Operating PointへのパワーとそのRelationship
Performance goals for a congestion control/avoidance strategy embody a conflict in that they call for as high a throughput as possible, with as little delay as possible. A measure that is often used to reflect the tradeoff between these goals is power, the ratio of throughput to delay. We would like to maximize the value of power for a given resource. In the standard expression for power,
彼らができるだけ高いスループットを求めるので、輻輳制御/回避方略のパフォーマンス目標は闘争を具体化します、大至急。 これらの目標の間の見返りを反映するのにしばしば使用される測定はパワー(遅らせるスループットの比率)です。 与えられたリソースのためにパワーの値を最大にしたいと思います。 パワーのための定型の表現で
Power = (Throughput^alpha)/Delay
パワーは(スループット^アルファ)/遅れと等しいです。
the exponent alpha is chosen for throughput, based on the relative emphasis placed on throughput versus delay: if throughput is more important, then a value of A alpha greater than one is chosen. If throughput and delay are equally important (e.g., both bulk transfer traffic and interactive traffic are equally important), then alpha equal to one is chosen. The operating point where power is maximized is the "knee" in the throughput and delay curves. It is desirable that the operating point of the resource be driven towards the knee, where power is maximized. A useful property of power is that it is decreasing whether the resource is under- or over-utilized relative to the knee.
解説者アルファはスループットに対遅れ置かれた相対的な強調に基づいてスループットに選ばれています: スループットが、より重要であるなら、Aアルファ1以上の値は選ばれています。 スループットと遅れが等しく重要であるなら(例えば、バルク転送通信と対話的な通信の両方が等しく重要です)、1つと等しいアルファは選ばれています。 パワーが最大にされる操作ポイントはスループットと遅れカーブで「ひざ」です。 リソースの操作ポイントがひざに向かって動かされるのは、望ましいです。パワーはひざで最大にされます。 パワーの役に立つ特性はリソースが下か利用され過ぎていることにかかわらずひざに比例して減少しているということです。
In an internetwork comprising nodes and links of diverse speeds and utilization, bottlenecks or concentrations of demand may form. Any particular user can see a single bottleneck, which is the slowest or busiest link or gateway in the path (or possibly identical "balanced" bottlenecks). The throughput that the path can sustain is limited by the bottleneck. The delay for packets through a particular path is determined by the service times and queueing at each individual hop. The queueing delay is dominated by the queueing at the bottleneck resource(s). The contribution to the delay over other hops is primarily the service time, although the propagation delay over certain hops, such as a satellite link, can be significant. We would like to operate all shared resources at their knee and maximize the power of every user's bottleneck.
さまざまの速度と利用のノードとリンクを包括するインターネットワークでは、要求のボトルネックか集中が形成されるかもしれません。 どんな特定のユーザも単一のボトルネックを見ることができます。(それは、経路(または、ことによると同じ「バランスのとれている」ボトルネック)の最も遅いか最も忙しいリンクかゲートウェイです)。 経路が支えることができるスループットはボトルネックによって制限されます。 特定の経路を通したパケットのための遅れはそれぞれの個々のホップにおけるサービス時間と待ち行列で決定します。 待ち行列遅れはボトルネックリソースにおける待ち行列によって支配されます。 他のホップの上の遅れへの貢献は主としてサービス・タイムです、衛星中継などのあるホップの上の伝播遅延が重要である場合がありますが。 彼らのひざのすべての共用資源を操作して、すべてのユーザのボトルネックのパワーを最大にしたいと思います。
The above goal underscores the significance of gateway congestion control. If techniques can be found to operate gateways at their resource knee, it can improve Internet performance broadly.
上の目標はゲートウェイ輻輳制御の意味を強調します。 彼らのリソースひざでゲートウェイを操作するのをテクニックを見つけることができるなら、それはインターネット性能を広く向上させることができます。
2.3 Fairness
2.3 公正
We would like gateways to allocate resources fairly to users. A concept of fairness is only relevant when multiple users share a gateway and their total demand is greater than its capacity. If demands were equal, a fair allocation of the resource would be to provide an equal share to each user. But even over short intervals,
私たちは、ゲートウェイにリソースをユーザに公正に割り当てて欲しいと思います。 複数のユーザがゲートウェイを共有するときだけ、公正の概念が関連していて、彼らの総需要は容量より大きいです。 要求が等しいなら、リソースの公正な配分は等しいシェアを各ユーザに提供することでしょうに。 しかし、短い間隔にわたって同等です。
Performance and Congestion Control Working Group [Page 7] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[7ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
demands are not equal. Identifying the fair share of the resource for the user becomes hard. Having identified it, it is desirable to allocate at least this fair share to each user. However, not all users may take advantage of this allocation. The unused capacity can be given to other users. The resulting final allocation is termed a maximally fair allocation. [RJC87] gives a quantitative method for comparing the allocation by a given policy to the maximally fair allocation.
要求は等しくはありません。 ユーザのためにリソースの正当な分け前を特定するのは困難になります。 それを特定したので、少なくともこの正当な分け前を各ユーザに割り当てるのは望ましいです。 しかしながら、すべてのユーザがこの配分を利用するかもしれないというわけではありません。 他のユーザに設備余力を与えることができます。 結果として起こる最終的な配分は最高に公正な配分と呼ばれます。 [RJC87]は与えられた方針で最高に公正な配分に配分をたとえるための量的な方法を与えます。
It is known that the Internet environment has heterogeneous transport entities, which do not follow the same congestion control policies (our definition of cooperating transports). Then, the controls given by a gateway may not affect all users and the congestion control policy may have unequal effects. Is "fairness" obtainable in such a heterogeneous community? In Fair Queueing, transport entities with differing congestion control policies can be insulated from each other and each given a set share of gateway bandwidth.
インターネット環境には異種の輸送実体があるのが知られています。(実体は同じ輻輳制御方針(私たちの協力輸送の定義)に従いません)。 次に、ゲートウェイによって与えられたコントロールはすべてのユーザに影響するかもしれないというわけではありません、そして、輻輳制御方針には、不平等な効果があるかもしれません。 「公正」はそのような種々雑多な共同体で入手可能ですか? Fair Queueingでは、ゲートウェイ帯域幅のセットシェアを考えて、互いでそれぞれから異なった輻輳制御方針がある輸送実体を隔離できます。
It is important to realize that since Internet gateways cannot refuse new users, fairness in gateway congestion control can lead to all users receiving small (sub-divided) amounts of the gateway resources inadequate to meet their performance requirements. None of the policies described in this paper currently addresses this. Then, there may be policy reasons for unequal allocation of the gateway resources. This has been addressed by Bit-Round Fair Queueing.
インターネット・ゲートウェイが新しいユーザを拒否できないのでゲートウェイ輻輳制御における公正がそれらの性能必要条件を満たすために不十分なゲートウェイリソースの少な(細分される)量を受けるすべてのユーザに通じることができるとわかるのは重要です。 現在この紙で説明されている方針のいずれもこれを記述しません。 そして、ゲートウェイリソースの不平等な配分の方針理由があるかもしれません。 これはラウンドのBit Fair Queueingによって記述されました。
2.4 Network Management
2.4 ネットワークマネージメント
Network performance goals may be assessed by measurements in either the end-system or gateway frame of reference. Performance goals are often resource-centered and the measurement of the global performance of "the network," is not only difficult to measure but is also difficult to define. Resource-centered metrics are more easily obtained, and do not require synchronization. That resource-centered metrics are appropriate ones for use in optimization of power is shown by [Jaf81].
ネットワーク性能目標はエンドシステムかゲートウェイ基準系の測定値によって評価されるかもしれません。 パフォーマンス目標がしばしばリソース中心であり、「ネットワーク」のグローバルな性能の測定は、測定するのが難しいだけではありませんが、また、定義するのも難しいです。 リソース中心の測定基準は、より容易に得られて、同期を必要としません。 リソース中心の測定基準がパワーの最適化における使用のための適切なものであることは[Jaf81]によって示されます。
It would be valuable for the goal of developing effective gateway congestion handling if Management Information Base (MIB) objects useful for evaluating gateway congestion were developed. The reflections on the control interval described above should be applied when network management applications are designed for this purpose. In particular, obtaining an instantaneous queue length from the managed gateway is not meaningful for the purposes of congestion management.
ゲートウェイ混雑を評価することの役に立つManagement Information基地(MIB)の物が開発されたなら有効なゲートウェイ混雑取り扱いを開発するという目標に、それは貴重でしょう。 ネットワークマネージメントアプリケーションがこのために設計されているとき、上で説明されたコントロールインタバルに関する反射は適用されるべきです。 管理されたゲートウェイから瞬時に起こっている待ち行列の長さを得るのはふくそう管理の目的のために特に、重要ではありません。
Performance and Congestion Control Working Group [Page 8] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[8ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
3. Gateway Congestion Control Policies
3. ゲートウェイ輻輳制御方針
There have been proposed a handful of approaches to dealing with congestion in the gateway. Some of these are Source Quench, Random Drop, Congestion Indication, Selective Feedback Congestion Indication, Fair Queueing, and Bit-Round Fair Queueing. They differ in whether they use a control message, and indeed, whether they view control of the end-systems as necessary, but none of them in itself lowers the demand of users and consequent load on the network. End- system policies that reduce demand in conjunction with gateway congestion control are described in Section 4.
ゲートウェイで混雑に対処することへの一握りのアプローチが提案されました。 これらのいくつかが、Source Quenchと、Random Dropと、Congestion Indicationと、Selective Feedback Congestion Indicationと、Fair Queueingと、ラウンドのBit Fair Queueingです。 彼らがコントロールメッセージを使用するか、そして、本当に、彼らが、エンドシステムのコントロールが必要であるとみなしますが、それらのいずれも本来ネットワークにユーザと結果の負荷の要求を下ろさないか否かに関係なく、彼らは異なります。 ゲートウェイ輻輳制御に関連して需要を抑える終わりのシステム方針がセクション4で説明されます。
3.1 Source Quench
3.1 ソース焼き入れ
The method of gateway congestion control currently used in the Internet is the Source Quench message of the RFC-792 [Pos81a] Internet Control Message Protocol (ICMP). When a gateway responds to congestion by dropping datagrams, it may send an ICMP Source Quench message to the source of the dropped datagram. This is a congestion recovery policy.
現在インターネットで使用されているゲートウェイ輻輳制御の方法はRFC-792[Pos81a]インターネット・コントロール・メッセージ・プロトコル(ICMP)に関するSource Quenchメッセージです。 ゲートウェイがデータグラムを落とすことによって混雑に応じるとき、それは低下しているデータグラムの源にICMP Source Quenchメッセージを送るかもしれません。 これは混雑回復方針です。
The Gateway Requirements RFC, RFC-1009 [GREQ87], specifies that gateways should only send Source Quench messages with a limited frequency, to conserve CPU resources during the time of heavy load. We note that operating the gateway for long periods under such loaded conditions should be averted by a gateway congestion control policy. A revised Gateway Requirements RFC is being prepared by the IETF.
ゲートウェイRequirements RFC(RFC-1009[GREQ87])は、ゲートウェイが重量物の時間CPU資源を節約するために限られた頻度と共にメッセージをSource Quenchに送るだけであるはずであると指定します。 私たちは、長期の間、そのようなロードされた条件のもとでゲートウェイを操作するのがゲートウェイ輻輳制御方針で逸らされるべきであることに注意します。 改訂されたゲートウェイRequirements RFCはIETFによって準備されています。
Another significant drawback of the Source Quench policy is that its details are discretionary, or, alternatively, that the policy is really a family of varied policies. Major Internet gateway manufacturers have implemented a variety of source quench frequencies. It is impossible for the end-system user on receiving a Source Quench to be certain of the circumstances in which it was issued. This makes the needed end-system response problematic: is the Source Quench an indication of heavy congestion, approaching congestion, a burst causing massive overload, or a burst slightly exceeding reasonable load?
Source Quench方針の別の重要な欠点はまたは、あるいはまた、詳細が任意であり、方針が本当に様々な方針の家族であるということです。 主要なインターネット・ゲートウェイメーカーはさまざまなソース焼き入れ頻度を実行しました。 Source Quenchを受けるときのエンドシステムユーザがそれが発行された事情を確信しているのは、不可能です。 これで、必要な終わりシステム・レスポンスは問題が多くなります: 混雑、大規模なオーバーロードを引き起こす炸裂、または妥当な負荷をわずかに超えている炸裂にアプローチして、Source Quenchは重い混雑のしるしですか?
To the extent that gateways drop the last arrived datagram on overload, Source Quench messages may be distributed unfairly. This is because the position at the end of the queue may be unfairly often occupied by the packets of low demand, intermittent users, since these do not send regular bursts of packets that can preempt most of the queue space.
ゲートウェイがオーバーロードで最後に到着したデータグラムを落とすという範囲に、Source Quenchメッセージは不公平に分配されるかもしれません。 これは待ち行列の終わりの位置がしばしば低い要求のパケットによって不公平に占められるかもしれないからです、間欠ユーザ、これらが待ち行列スペースの大部分を先取りできるパケットの通常の炸裂を送らないので。
[Fin89] developed algorithms for when to issue Source Quench and for responding to it with a rate-reduction in the IP layer on the sending
[Fin89]は発信のときにIP層のレート減少でいつSource Quenchを発行するか、そして、それに応じるためのアルゴリズムを開発しました。
Performance and Congestion Control Working Group [Page 9] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[9ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
host. The system controls end-to-end performance of connections in a manner similar to the congestion avoidance portion of Slow-start TCP [Jac88].
接待します。 システムは終わりから終わりへの接続に関するSlow-スタートTCP[Jac88]の輻輳回避一部と同様の方法における、実績を制御します。
3.2 Random Drop
3.2 無作為の低下
Random Drop is a gateway congestion control policy intended to give feedback to users whose traffic congests the gateway by dropping packets on a statistical basis. The key to this policy is the hypothesis that a packet randomly selected from all incoming traffic will belong to a particular user with a probability proportional to the average rate of transmission of that user. Dropping a randomly selected packet results in users which generate much traffic having a greater number of packets dropped compared with those generating little traffic. The selection of packets to be dropped is completely uniform. Therefore, a user who generates traffic of an amount below the "fair share" (as defined in Section 2.3) may also experience a small amount of packet loss at a congested gateway. This character of uniformity is in fact a primary goal that Random Drop attempts to achieve.
無作為のDropは交通が統計的基礎でパケットを落とすことによってゲートウェイを充血させるユーザにフィードバックすることを意図するゲートウェイ輻輳制御方針です。 この方針のキーはすべての入って来る交通から手当たりしだいに選択されたパケットがそのユーザのトランスミッションの平均相場に比例している確率で特定のユーザのものであるという仮説です。 手当たりしだいに選択されたパケットを落として、ユーザの、より大きい数のパケットが落とされる多くの交通を発生させる結果が交通をほとんど発生させないそれらと比較されました。 落とされるべきパケットの品揃えは完全に一定です。 したがって、また、「正当な分け前」(セクション2.3で定義されるように)の下で量の交通を発生させるユーザは混雑しているゲートウェイの少量のパケット損失を経験するかもしれません。 事実上、一様性のこのキャラクタはRandom Dropが達成するのを試みる第一の目標です。
The other primary goal that Random Drop attempts to achieve is a theoretical overhead which is scaled to the number of shared resources in the gateway rather than the number of its users. If a gateway congestion algorithm has more computation the more users there are, this can lead to processing demands that are higher as congestion increases. Also the low-overhead goal of Random Drop addresses concerns about the scale of gateway processing that will be required in the mid-term Internet as gateways with fast processors and links are shared by very large active sets of users.
Random Dropが達成するのを試みるもう片方の第一の目標はユーザの数よりむしろゲートウェイの共用資源の数に合わせて調整される理論上のオーバーヘッドです。 ゲートウェイ混雑アルゴリズムにより多くの計算があるなら、より多くのユーザがそこのそうです、混雑が増加するのに従って、より高い処理要求へのこの缶のリード。 また、速いプロセッサとリンクがあるゲートウェイが非常に大きい活動的なセットのユーザによって共有されるとき、Random Dropの低いオーバーヘッド目標は中期のインターネットで必要であるゲートウェイ処理のスケールに関して危惧に対処します。
3.2.1 For Congestion Recovery
3.2.1 混雑回復のために
Random Drop has been proposed as an improvement to packet dropping at the operating point where the gateway's packet buffers overflow. This is using Random Drop strictly as a congestion recovery mechanism.
無作為のDropはパケット低下へのゲートウェイのパケットバッファがあふれる操作ポイントでの改良として提案されました。 これは混雑回収機構として厳密にRandom Dropを使用しています。
In Random Drop congestion recovery, instead of dropping the last packet to arrive at the queue, a packet is selected randomly from the queue. Measurements of an implementation of Random Drop Congestion Recovery [Man90] showed that a user with a low demand, due to a longer round-trip time path than other users of the gateway, had a higher drop rate with RDCR than without. The throughput accorded to users with the same round-trip time paths was nearly equal with RDCR as compared to without it. These results suggest that RDCR should be avoided unless it is used within a scheme that groups traffic more or less by round-trip time.
Random Drop混雑回復では、待ち行列に到達する最後のパケットを落とすことの代わりに、パケットは待ち行列から手当たりしだいに選択されます。 Random Drop Congestion Recovery[Man90]の実現の測定値は、低い要求のユーザにはRDCRがある、より高い低下率がゲートウェイの他のユーザより長い往復の時間経路のためあったのを示しました。 それなしで比べて、同じ往復の時間経路がユーザに与えられたスループットはRDCRについて伯仲していました。 これらの結果は、それが往復の時間までに多少交通を分類する計画の中で使用されない場合RDCRが避けられるべきであると示唆します。
Performance and Congestion Control Working Group [Page 10] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[10ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
3.2.2 For Congestion Avoidance
3.2.2 輻輳回避のために
Random Drop is also proposed as a congestion avoidance policy [Jac89]. The intent is to initiate dropping packets when the gateway is anticipated to become congested and remain so unless there is some control exercised. This implies selection of incoming packets to be randomly dropped at a rate derived from identifying the level of congestion at the gateway. The rate is the number of arrivals allowed between drops. It depends on the current operating point and the prediction of congestion.
また、無作為のDropは輻輳回避方針[Jac89]として提案されます。 意図がゲートウェイが混雑するようになって、ままであるために予期されるとき、低下パケットを開始することであるので、何かがない場合、コントロールは運動しました。 これは、ゲートウェイで混雑のレベルを特定するのから得られたレートで手当たりしだいに落とされるために入って来るパケットの品揃えを含意します。 レートは低下の間に許容された到着の数です。 それは現在の操作ポイントと混雑の予測に依存します。
A part of the policy is to determine that congestion will soon occur and that the gateway is beginning to operate beyond the knee of the power curve. With a suitably chosen interval (Section 2.1), the number of packets from each individual user in a sample over that interval is proportional to each user's demand on the gateway. Then, dropping one or more random packets indicates to some user(s) the need to reduce the level of demand that is driving the gateway beyond the desired operating point. This is the goal that a policy of Random Drop for congestion avoidance attempts to achieve.
方針の一部は混雑がすぐ、起こって、ゲートウェイがパワーカーブのひざを超えて作動し始めていることを決定することです。 適当に選ばれた間隔(セクション2.1)で、その間隔の間のサンプルのそれぞれの個々のユーザからのパケットの数はゲートウェイで各ユーザの要求に比例しています。 そして、1つ以上の無作為のパケットを落とすと、必要な操作ポイントにゲートウェイを動かしている要求のレベルを減少させる必要性はユーザに示されます。 これは輻輳回避のためのRandom Dropの方針が達成するのを試みる目標です。
There are several parameters to be determined for a Random Drop congestion avoidance policy. The first is an interval, in terms of number of packet arrivals, over which packets are dropped with uniform probability. For instance, in a sample implementation, if this interval spanned 2000 packet arrivals, and a suitable probability of drop was 0.001, then two random variables would be drawn in a uniform distribution in the range of 1 to 2,000. The values drawn would be used by counting to select the packets dropped at arrival. The second parameter is the value for the probability of drop. This parameter would be a function of an estimate of the number of users, their appropriate control intervals, and possibly the length of time that congestion has persisted. [Jac89] has suggested successively increasing the probability of drop when congestion persists over multiple control intervals. The motivation for increasing the packet drop probability is that the implicit estimate of the number of users and random selection of their packets to drop does not guarantee that all users have received enough signals to decrease demand. Increasing the probability of drop increases the probability that enough feedback is provided. Congestion detection is also needed in Random Drop congestion avoidance, and could be implemented in a variety of ways. The simplest is a static threshold, but dynamically averaged measures of demand or utilization are suggested.
Random Drop輻輳回避方針のために決定するために、いくつかのパラメタがあります。 1番目はパケットが一定の確率で落とされるパケット到着の数に関する間隔です。 例えば、サンプル実現では、2つの確率変数がこの間隔が2000のパケット到着にかかって、低下の適当な確率が0.001であるなら1〜2,000の範囲に一様分布で描かれるでしょうに。 描かれた値は、到着で落とされたパケットを選択するために数えることによって、使用されるでしょう。 2番目のパラメタは低下の確率のための値です。 このパラメタは混雑が持続したというユーザの数、彼らの適切なコントロールインタバル、およびことによると時間の長さの見積りの関数でしょう。 [Jac89]は、混雑が複数のコントロールインタバルの上で持続するとき、相次ぐ低下の確率を増加させるのを示しました。 パケット低下確率を増加させることに関する動機はユーザの数の暗黙の見積りと落とす彼らのパケットのランダム・セレクションが、すべてのユーザが需要を減少させることができるくらいの信号を受け取ったのを保証しないということです。 低下の確率を増加させると、十分なフィードバックを提供するという確率は増加します。 混雑検出をまた、Random Drop輻輳回避で必要であり、さまざまな方法で実行できました。 最も簡単であるのが、静的な敷居ですが、要求か利用のダイナミックに平均した手段は示されます。
The packets dropped in Random Drop congestion avoidance would not be from the initial inputs to the gateway. We suggest that they would be selected only from packets destined for the resource which is
初期の入力からゲートウェイまでRandom Drop輻輳回避で落とされたパケットがないでしょう。 私たちは、それらが単にそうするリソースのために運命づけられたパケットから選択されると示唆します。
Performance and Congestion Control Working Group [Page 11] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[11ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
predicted to be approaching congestion. For example, in the case of a gateway with multiple outbound links, access to each individual link is treated as a separate resource, the Random Drop policy is applied at each link independently. Random Drop congestion avoidance would provide uniform treatment of all cooperating transport users, even over individual patterns of traffic multiplexed within one user's stream. There is no aggregation of users.
混雑にアプローチしていると予測されます。 例えば、複数のアウトバウンドリンクがあるゲートウェイの場合では、それぞれの個々のリンクへのアクセスは別々のリソースとして扱われて、Random Drop方針は独自に各リンクに付けられます。 無作為のDrop輻輳回避は協力関係を持っている輸送ユーザの皆、一定の治療法を提供するでしょう、1人のユーザの流れの中で多重送信された交通の個々のパターンの上でさえ。 ユーザの集合が全くありません。
Simulation studies [Zha89], [Has90] have presented evidence that Random Drop is not fair across cooperating and non-cooperating transport users. A transport user whose sending policies included Go-Back-N retransmissions and did not include Slow-start received an excessive share of bandwidth from a simple implementation of Random Drop. The simultaneously active Slow-start users received unfairly low shares. Considering this, it can be seen that when users do not respond to control, over a prolonged period, the Random Drop congestion avoidance mechanism would have an increased probability of penalizing users with lower demand. Their packets dropped, these users exert the controls leading to their giving up bandwidth.
シミュレーション研究[Zha89]、[Has90]はRandom Dropが協力することの向こう側のフェアとまたは輸送のユーザでないという非協力している証拠を提示しました。 送付方針がGo逆N「再-トランスミッション」を含んでいて、Slow-始めは含んでいなかった輸送ユーザがRandom Dropの簡単な実現からの帯域幅の過度のシェアを受けました。 同時に活発なSlow-スタートユーザは不公平に低いシェアを受けました。 これを考える場合、ユーザが制御するために応じないとき長期の間Random Drop輻輳回避メカニズムには下側の要求でユーザを罰するという増加する確率があるのを見ることができます。 それらのパケットは低下して、これらのユーザは彼らが帯域幅をあきらめるのに通じるコントロールを及ぼします。
Another problem can be seen to arise in Random Drop [She89] across users whose communication paths are of different lengths. If the path spans congested resources at multiple gateways, then the user's probability of receiving an unfair drop and subsequent control (if cooperating) is exponentially increased. This is a significant scaling problem.
通信路が異なった長さのものであるユーザの向こう側にRandom Drop[She89]に起こると別の問題が認められることができます。 経路が複数のゲートウェイで混雑しているリソースにかかっているなら、不公平な低下とその後のコントロール(協力するなら)を受けるというユーザの確率は指数関数的に増加します。 これは重要なスケーリング問題です。
Unequal paths cause problems for other congestion avoidance policies as well. Selective Feedback Congestion Indication was devised to enhance Congestion Indication specifically because of the problem of unequal paths. In Fair Queueing by source-destination pairs, each path gets its own queue in all the gateways.
不平等な経路はまた、他の輻輳回避方針のために問題を起こします。 選択しているFeedback Congestion Indicationは、特に不平等な経路の問題のためにCongestion Indicationを高めるために工夫されました。 ソース目的地組のFair Queueingでは、各経路はすべてのゲートウェイでそれ自身の待ち行列を得ます。
3.3 Congestion Indication
3.3 混雑指示
The Congestion Indication policy is often referred to as the DEC Bit policy. It was developed at DEC [JRC87], originally for the Digital Network Architecture (DNA). It has also been specified for the congestion avoidance of the ISO protocols TP4 and CLNP [NIST88]. Like Source Quench, it uses explicit communications from the congested gateway to the user. However, to use the lowest possible network resources for indicating congestion, the information is communicated in a single bit, the Congestion Experienced Bit, set in the network header of the packets already being forwarded by a gateway. Based on the condition of this bit, the end-system user makes an adjustment to the sending window. In the NSP transport protocol of DECNET, the source makes an adjustment to its window; in the ISO transport protocol, TP4, the destination makes this
Congestion Indication方針はしばしば12月のBit方針と呼ばれます。 それは12月[JRC87]に元々Digital Network Architecture(DNA)のために開発されました。 また、それはISOプロトコルのTP4とCLNP[NIST88]の輻輳回避に指定されました。 Source Quenchのように、それはユーザへの混雑しているゲートウェイからの明白なコミュニケーションを使用します。 しかしながら、混雑を示すのに可能な限り低いネットワーク資源を使用するために、情報は1ビットで伝えられます、Congestion Experienced Bit、ゲートウェイによって既に進められるパケットのネットワークヘッダーのセット。 このビットの状態に基づいて、エンドシステムユーザは送付の窓に調整します。 DECNETのNSPトランスポート・プロトコルでは、ソースは窓に調整します。 ISOトランスポート・プロトコル、TP4では、目的地はこれを作ります。
Performance and Congestion Control Working Group [Page 12] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[12ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
adjustment in the window offered to the sender.
送付者に提供された窓での調整。
This policy attempts to avoid congestion by setting the bit whenever the average queue length over the previous queue regeneration cycle plus part of the current cycle is one or more. The feedback is determined independently at each resource.
この方針は、現在のサイクルの前の待ち行列再生サイクルと部分の上平均した待ち行列の長さが1以上であるときはいつも、ビットを設定することによって混雑を避けるのを試みます。 フィードバックは各リソースで独自に決定しています。
3.4 Selective Feedback Congestion Indication
3.4 選択しているフィードバック混雑指示
The simple Congestion Indication policy works based upon the total demand on the gateway. The total number of users or the fact that only a few of the users might be causing congestion is not considered. For fairness, only those users who are sending more than their fair share should be asked to reduce their load, while others could attempt to increase where possible. In Selective Feedback Congestion Indication, the Congestion Experienced Bit is used to carry out this goal.
簡単なCongestion Indication政策はうまくゲートウェイに総需要に基づいた状態で行きます。 ユーザの総数かほんのユーザのいくつかが混雑を引き起こしているかもしれないという事実が考えられません。 公正において、彼らの正当な分け前より発信するユーザだけが彼らの負荷を減少させるように頼まれるべきです、他のものは、可能であるところで増加するのを試みることができましたが。 Selective Feedback Congestion Indicationでは、Congestion Experienced Bitは、この目標を行うのに使用されます。
Selective Feedback works by keeping a count of the number of packets sent by different users since the beginning of the queue averaging interval. This is equivalent to monitoring their throughputs. Based on the total throughput, a fair share for each user is determined and the congestion bit is set, when congestion approaches, for the users whose demand is higher than their fair share. If the gateway is operating below the throughput-delay knee, congestion indications are not set.
選択しているFeedbackは、間隔を平均する待ち行列の始まり以来異なったユーザによって送られたパケットの数の数を覚えていることによって、働いています。 これはそれらのスループットをモニターするのに同等です。 総スループットに基づいて、各ユーザのための正当な分け前は決定しています、そして、混雑ビットは設定されます、混雑にアプローチすると、要求が彼らの正当な分け前より高いユーザのために。 ゲートウェイがスループット遅れひざの下で作動しているなら、混雑指摘は設定されません。
A min-max algorithm used to determine the fair share of capacity and other details of this policy are described in [RJC87]. One parameter to be computed is the capacity of each resource to be divided among the users. This metric depends on the distribution of inter-arrival times and packet sizes of the users. Attempting to determine these in real time in the gateway is unacceptable. The capacity is instead estimated from on the throughput seen when the gateway is operating in congestion, as indicated by the average queue length. In congestion (above the knee), the service rate of the gateway limits its throughput. Multiplying the throughput obtained at this operating point by a capacity factor (between 0.5 and 0.9) to adjust for the distributions yields an acceptable capacity estimate in simulations.
分最大アルゴリズムは、以前はよく容量の正当な分け前とこの方針の他の詳細が[RJC87]で説明されることを決定していました。 1つの計算されるべきパラメタが各リソースがユーザの中で分割される能力です。 これほどメートル法、相互到着時間の分配とユーザのパケットサイズに依存します。 リアルタイムでゲートウェイでこれらを決定するのを試みるのは容認できません。 容量は代わりにスループットで見られるのからゲートウェイが混雑で作動していると見積もられています、平均した待ち行列の長さによって示されるように。 混雑(ひざの上の)では、ゲートウェイのサービス率はスループットを制限します。 利用率(0.5〜0.9)によってこの操作ポイントで得られた、配のために適応したスループットを掛けると、シミュレーションにおける許容できる容量見積りはもたらされます。
Selective Feedback Congestion Indication takes as input a vector of the number of packets sent by each source-destination pair of end- systems. Other alternatives include 1) destination address, 2) input/output link, and 3) transport connection (source/destination addresses and ports).
選択しているFeedback Congestion Indicationはそれぞれのソース目的地組のエンドシステムによって送られたパケットの数のベクトルに入力されるように取ります。他の代替手段は1)送付先アドレス、2)入力/出力リンク、および3)輸送接続(ソース/送付先アドレスとポート)を含んでいます。
These alternatives give different granularities for fairness. In the
これらの代替手段は公正ために異なった粒状を与えます。 in
Performance and Congestion Control Working Group [Page 13] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[13ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
case where paths are the same or round-trip times of users are close together, throughputs are equalized similarly by basing the selective feedback on source or destination address. In fact, if the RTTs are close enough, the simple congestion indication policy would result in a fair allocation. Counts based on source/destination pairs ensure that paths with different lengths and network conditions get a fair throughput at the individual gateways. Counting packets based on link pairs has a low overhead, but may result in unfairness to users whose demand is below the fair share and are using a long path. Counts based on transport layer connection identifiers, if this information was available to Internet gateways, would make good distinctions, since the differences of demand of different applications and instances of applications would be separately monitored.
経路が同じであるか、またはユーザの往復の倍が近くに一緒にあるケース、スループットは、選択しているフィードバックをソースか送付先アドレスに基礎づけることによって、同様に均等化されます。 事実上、RTTsが十分近くにあるなら、簡単な混雑指示方針は公正な配分をもたらすでしょう。 ソース/目的地組に基づくカウントは、異なった長さとネットワーク状態の経路が公正なスループットに個々のゲートウェイに届くのを確実にします。 リンク組に基づくパケットを数えると、低いオーバーヘッドが持たれていますが、要求が正当な分け前の下にあって、長い経路を使用しているユーザへの不公平はもたらされるかもしれません。 この情報がインターネット・ゲートウェイに利用可能であったならトランスポート層接続識別子に基づくカウントは良い区別をするでしょう、異なったアプリケーションの要求とアプリケーションの例の違いは別々にモニターされるでしょう、したがって。
Problems with Selective Feedback Congestion Indication include that the gateway has significant processing to do. With the feasible choice of aggregation at the gateway, unfairness across users within the group is likely. For example, an interactive connection aggregated with one or more bulk transfer connections will receive congestion indications though its own use of the gateway resources is very low.
ゲートウェイにはする重要な処理があるというSelective Feedback Congestion Indicationインクルードに関する問題。 ゲートウェイの集合の可能な選択で、グループの中のユーザの向こう側の不公平はありそうです。 例えば、ゲートウェイリソースのそれ自身の使用は非常に低いのですが、1つ以上のバルク転送接続と共に集められた対話的な接続は混雑指摘を受けるでしょう。
3.5 Fair Queueing
3.5 公正な待ち行列
Fair Queueing is the policy of maintaining separate gateway output queues for individual end-systems by source-destination pair. In the policy as proposed by [Nag85], the gateway's processing and link resources are distributed to the end-systems on a round-robin basis. On congestion, packets are dropped from the longest queue. This policy leads to equal allocations of resources to each source- destination pair. A source-destination pair that demands more than a fair share simply increases its own queueing delay and congestion drops.
公正なQueueingは個々のエンドシステムのために別々のゲートウェイ出力キューをソース目的地組維持する方針です。 [Nag85]によって提案される方針で、ゲートウェイの処理とリンクリソースは連続ベースのエンドシステムに広げられます。 混雑のときに、パケットは最も長い待ち行列から落とされます。 この方針はそれぞれのソース目的地組へのリソースの等しい配分につながります。 単に正当な分け前以上を要求するソース目的地組はそれ自身の待ち行列遅れと混雑低下を増加させます。
3.5.1 Bit-Round Fair Queueing
3.5.1 ラウンドのビットの公正な待ち行列
An enhancement of Nagle Fair Queueing, the Bit-Round Fair Queuing algorithm described and simulated by [DKS89] addresses several shortcomings of Nagle's scheme. It computes the order of service to packets using their lengths, with a technique that emulates a bit- by-bit round-robin discipline, so that long packets do not get an advantage over short ones. Otherwise the round-robin would be unfair, for example, giving more bandwidth to hosts whose traffic is mainly long packets than to hosts sourcing short packets.
ネーグルFair Queueingの増進、[DKS89]によって説明されて、シミュレートされたラウンドのBit Fair Queuingアルゴリズムはネーグルの計画のいくつかの短所を記述します。 それはそれらの長さを使用することでパケットに対するサービスの注文を計算します、ビットの連続規律を少し見習うテクニックで、長いパケットが短いものの上で優位を占めないように。 さもなければ、例えば、連続は、脆いパケットの出典を明示するホストより多くの帯域幅を交通が主に長いパケットであるホストに与えながら、不公平でしょう。
The aggregation of users of a source-destination pair by Fair Queueing has the property of grouping the users whose round-trips are
Fair Queueingによる1ソース目的地組のユーザの集合には、周遊旅行があるユーザを分類する特性があります。
Performance and Congestion Control Working Group [Page 14] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[14ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
similar. This may be one reason that the combination of Bit-Round Fair Queueing with Congestion Indication had particularly good simulated performance in [DKS89].
同様。 これはラウンドのBit Fair QueueingのCongestion Indicationへの組み合わせが[DKS89]に特に良いシミュレートされた性能を持っていた1つの理由であるかもしれません。
The aggregation of users has the expected drawbacks, as well. A TELNET user in a queue with an FTP user does not get delay benefits; and host pairs with high volume of connections get treated the same as a host pair with small number of connections and as a result gets unfair services.
ユーザの集合には、また、予想された欠点があります。 FTPユーザとの待ち行列におけるTELNETユーザは遅れ利益を得ません。 そして、わずかなポートの数、結果が不公平なサービスを得るので、接続の高いボリュームがあるホスト組は同じようにホスト組として扱われます。
A problem can be mentioned about Fair Queueing, though it is related to implementation, and perhaps not properly part of a policy discussion. This is a concern that the resources (processing) used for determining where to queue incoming packets would themselves be subject to congestion, but not to the benefits of the Fair Queuing discipline. In a situation where the gateway processor was not adequate to the demands on it, the gateway would need an alternative policy for congestion control of the queue awaiting processing. Clever implementation can probably find an efficient way to route packets to the queues they belong in before other input processing is done, so that processing resources can be controlled, too. There is in addition, the concern that bit-by-bit round FQ requires non-FCFS queueing even within the same source destination pairs to allow for fairness to different connections between these end systems.
問題は、実現に関連しますが、Fair Queueingの周りで言及されて、恐らく政策協議を適切に離れさせることができません。 これは混雑を受けることがありますが、決定に入って来るパケットが列を作るのに使用されるだろうところで自分たちで使用されるリソース(処理)はFair Queuing規律の利益のために受けることがあるというわけではないという関心です。 ゲートウェイプロセッサがそれにおける要求に適切でなかった状況で、ゲートウェイは処理を待つ待ち行列の輻輳制御のための代替的政策を必要とするでしょう。 賢明な実現はたぶん処理リソースを制御できるように他の入力処理をする前にそれらがある待ち行列にパケットを発送する効率的な方法にも当たることができます。 添加、ビットごとの丸いFQが非FCFSを必要とするという関心には、これらのエンドシステムの間の異なった接続への公正を考慮するために、同じソース目的地組の中にさえ待ち行列があります。
Another potential concern about Fair Queueing is whether it can scale up to gateways with very large source-destination populations. For example, the state in a Fair Queueing implementation scales with the number of active end-to-end paths, which will be high in backbone gateways.
Fair Queueingに関する別の潜在的心配は非常に大きいソース目的地人口でゲートウェイまで比例できるかどうかということです。 例えば、Fair Queueing実現における状態は終わりから端へのアクティブな経路の数で比例します。(経路は背骨ゲートウェイで高くなるでしょう)。
3.5.2 Stochastic Fairness Queuing
3.5.2 推計的な公正列を作り
Stochastic Fairness Queueing (SFQ) has been suggested as a technique [McK90] to address the implementation issues relating to Fair Queueing. The first overhead that is reduced is that of looking up the source-destination address pair in an incoming packet and determining which queue that packet will have to be placed in. SFQ does not require as many memory accesses as Fair Queueing to place the packet in the appropriate queue. SFQ is thus claimed to be more amenable to implementation for high-speed networks [McK90].
推計的なFairness Queueing(SFQ)は、Fair Queueingに関連する導入問題を記述するためにテクニック[McK90]として示されました。 下げられる最初のオーバーヘッドは入って来るパケットでソース目的地アドレス組を訪ねて、そのパケットがどの待ち行列に置かれなければならないかを決心するものです。 SFQは、適切な待ち行列にパケットを置くためにFair Queueingと同じくらい多くのメモリアクセスを必要としません。 SFQは高速ネットワーク[McK90]には実現により従順であるとこのようにして主張されます。
SFQ uses a simple hash function to map from the source-destination address pair to a fixed set of queues. Since the assignment of an address pair to a queue is probabilistic, there is the likelihood of multiple address pairs colliding and mapping to the same queue. This would potentially degrade the additional fairness that is gained with Fairness Queueing. If two or more address pairs collide, they would
SFQはソース目的地アドレス組から固定セットの待ち行列まで写像するのが簡単であるハッシュ関数を使用します。 待ち行列への1アドレス組の課題が確率的であるので、同じ待ち行列に衝突して、写像される複数のアドレス組の見込みは、あります。 これはFairness Queueingと共に獲得される追加公正を潜在的に下がらせるでしょう。 2アドレス組以上が衝突するなら、彼らは衝突するでしょう。
Performance and Congestion Control Working Group [Page 15] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[15ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
continue to do so. To deal with the situation when such a collision occurs, SFQ periodically perturbs the hash function so that these address pairs will be unlikely to collide subsequently.
そうし続けてください。 そのような衝突が起こるとき、時局に処するために、SFQが定期的にハッシュ関数を混乱させるので、これらが組に演説するのが次に、衝突しそうにないでしょう。
The price paid for achieving this implementation efficiency is that SFQ requires a potentially large number of queues (we must note however, that these queues may be organized orthogonally from the buffers in which packets are stored. The buffers themselves may be drawn from a common pool, and buffers in each queue organized as a linked list pointed to from each queue header). For example, [McK90] indicates that to get good, consistent performance, we may need to have up to 5 to 10 times the number of active source-destination pairs. In a typical gateway, this may require around 1000 to 2000 queues.
この実現効率を達成しながら代価を払われた価格はSFQが潜在的に多くの待ち行列を必要とするということです。(しかしながら、私たちは、これらの待ち行列が組織化されるかもしれないのがパケットが格納されるバッファから直交していることに注意しなければなりません。 一般的なプールからバッファ自体を得たかもしれません、そして、各待ち行列におけるバッファはそれぞれの待ち行列ヘッダーから示された繋がっているリストとして結団されました。). 例えば、[McK90]は、良くて、一貫した性能を得るために、私たちが活動的なソース目的地組の数の最大5〜10倍を必要とするかもしれないのを示します。 典型的なゲートウェイでは、これは1000年頃から2000の待ち行列を必要とするかもしれません。
[McK90] reports simulation results with SFQ. The particular hash function that is studied is using the HDLC's cyclic redundancy check (CRC). The hash function is perturbed by multiplying each byte by a sequence number in the range 1 to 255 before applying the CRC. The metric considered is the standard deviation of the number of packets output per source-destination pair. A perfectly fair policy would have a standard deviation of zero and an unfair policy would have a large standard deviation. In the example studied (which has up to 20 source-destination (s-d) pairs going through a single overloaded gateway), SFQ with 1280 queues (i.e., 64 times the number of source- destination pairs), approaches about 3 times the standard deviation of Fairness Queueing. This must be compared to a FCFS queueing discipline having a standard deviation which is almost 175 times the standard deviation of Fairness Queueing.
[McK90]レポートシミュレーションはSFQと共に結果として生じます。 研究される特定のハッシュ関数はHDLCの周期冗長検査(CRC)を使用しています。 ハッシュ関数は、CRCを適用する前に範囲で1〜255に各バイトを一連番号に掛けることによって、混乱させられています。 考えられたメートル法はソース目的地組あたりのパケット出力の数の標準偏差です。 完全に公正な方針には、ゼロの標準偏差があるでしょう、そして、不公平な方針には、大きい標準偏差があるでしょう。 研究された例(最大20ソース目的地(s-d)組に積みすぎられた1つの門を通らせる)では、1280があるSFQは列を作ります(すなわち、ソース目的地組の数の64倍)、Fairness Queueingの標準偏差の3倍に関するアプローチ。 Fairness Queueingの標準偏差のおよそ175倍である標準偏差を持っているFCFS待ち行列規律とこれを比較しなければなりません。
It is conjectured in [McK90] that a good value for the interval in between perturbations of the hash function appears to be in the area between twice the queue flush time of the stochastic fairness queue and one-tenth the average conversation time between a source- destination pair.
[McK90]では、ハッシュ関数の摂動の間隔の間の値打ち品が推計的な公正待ち行列の待ち行列好景気の2倍とソース目的地組の間の平均した会話回の1/10の間の領域にあるように見えると推測されます。
SFQ also may alleviate the anticipated scaling problems that may be an issue with Fair Queueing by not strictly requiring the number of queues equal to the possible source-destination pairs that may be presenting a load on a particular gateway. However, SFQ achieves this property by trading off some of the fairness for implementation efficiency.
SFQも、厳密に特定のゲートウェイの上に負荷を提示しているかもしれない可能なソース目的地組と等しい待ち行列の数を必要としないことによって、Fair Queueingの問題であるかもしれない予期されたスケーリング問題を軽減するかもしれません。 しかしながら、SFQは、実現効率のために何らかの公正を交換することによって、この特性を獲得します。
[McK90] examines alternative strategies for implementation of Fair Queueing and SFQ and estimates their complexity on common hardware platforms (e.g., a Motorola 68020). It is suggested that mapping an IP address pair may require around 24 instructions per packet for Fair Queueing in the best case; in contrast SFQ requires 10
[McK90]は、Fair QueueingとSFQの実現がないかどうか代替の戦略を調べて、一般的なハードウェアプラットホームのそれらの複雑さが(例えば、モトローラ68020)であると見積もっています。 IPアドレス組を写像するのがFair Queueingのために最も良い場合で1パケットあたりおよそ24の指示を必要とするかもしれないことが提案されます。 対照的に、SFQは10を必要とします。
Performance and Congestion Control Working Group [Page 16] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[16ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
instructions in the worst case. The primary source of this gain is that SFQ avoids a comparison of the s-d address pair on the packet to the identity of the queue header. The relative benefit of SFQ over Fair Queueing is anticipated to be greater when the addresses are longer.
最悪の場合における指示。 この利得の一次資料はSFQがパケットにおけるs-dアドレス組の比較を待ち行列ヘッダーのアイデンティティとして避けるということです。 Fair Queueingの上のSFQの相対的な利益は、アドレスが、より長いときに、よりすばらしくなるように予期されます。
SFQ offers promising implemenatation benefits. However, the price to be paid in terms of having a significantly larger number of queues (and the consequent data structures and their management) than the number of s-d pairs placing a load on the gateway is a concern. SFQ is also attractive in that it may be used in concert with the DEC-bit scheme for Selective Feedback Congestion Indication to provide fairness as well as congestion avoidance.
SFQは有望なimplemenatation利益を提供します。 しかしながら、負荷をゲートウェイに置いているs-d組の数よりかなり多くの待ち行列(そして、結果のデータ構造と彼らの管理)を持つことに関する代価は関心です。 また、Selective Feedback Congestion Indicationが輻輳回避と同様に公正を提供するのにそれが12月-ビット計画と協力して使用されるかもしれないので、SFQも魅力的です。
4. END-SYSTEM CONGESTION CONTROL POLICIES
4. エンドシステム輻輳制御方針
Ideally in gateway congestion control, the end-system transport entities adjust (decrease) their demand in response to control exerted by the gateway. Schemes have been put in practice for transport entities to adjust their demand dynamically in response to congestion feedback. To accomplish this, in general, they call for the user to gradually increase demand until information is received that the load on the gateway is too high. In response to this information, the user decreases load, then begins an exploratory increases again. This cycle is repeated continuously, with the goal that the total demand will oscillate around the optimal level.
理想的なゲートウェイ輻輳制御では、ゲートウェイによって及ぼされたコントロールに対応してエンドシステム輸送実体は彼らの要求を調整します(減少します)。 輸送実体がダイナミックに混雑フィードバックに対応して彼らの要求を調整するように、計画は習慣に入れられました。 一般に、これを達成するために、ゲートウェイの上の負荷が高過ぎるという情報が受信されるまで、彼らは、ユーザが需要を徐々に増加させるように求めます。 この情報に対応して、ユーザは、負荷を減少させて、次に、再び踏査の増加を始めます。 このサイクルは合計が最適水準の周りで揺れるのを要求する目標で絶え間なく繰り返されます。
We have already noted that a Slow-start connection may give up considerable bandwidth when sharing a gateway with aggressive transport entities. There is currently no way to enforce that end- systems use a congestion avoidance policy, though the Host Requirements RFC [HR89] has defined Slow-start as mandatory for TCP. This adverse effect on Slow-start connections is mitigated by the Fair Queueing policy. Our conclusions discuss further the coexistence of different end-system strategies.
私たちは、攻撃的な輸送実体とゲートウェイを共有するとき、Slow-スタート接続がかなりの帯域幅をあきらめるかもしれないことに既に注意しました。 そこでは、Host Requirements RFC[HR89]はSlow-始めをTCPに義務的であると定義しましたが、その終わりのシステム使用を実施する現在のどんな方法も輻輳回避方針ではありませんか? Slow-スタート接続へのこの悪影響はFair Queueing方針で緩和されます。 私たちの結論はさらに異なったエンドシステム戦略の共存について議論します。
This section briefly presents two fielded transport congestion control and avoidance schemes, Slow-start and End-System Congestion Indication, and the responses by means of which they cooperate with gateway policies. They both use the control paradigm described above. Slow-start, as mentioned in Section 1, was developed by [Jac88], and widely fielded in the BSD TCP implementation. End- system Congestion Indication was developed by [JRC87]. It is fielded in DEC's Digital Network Architecture, and has been specified as well for ISO TP4 [NIST88].
このセクションは簡潔に2を提示します。輸送が輻輳制御と、回避計画、Slow-始め、およびEnd-システムCongestion Indicationと、応答であるによって彼らがゲートウェイ方針に協力する戦闘配置につけてください。 それらの両方が上で説明されたコントロールパラダイムを使用します。 セクション1で言及される遅れた出発は、[Jac88]によって開発されて、BSD TCP実現で広くさばかれました。 エンドシステムCongestion Indicationは[JRC87]によって開発されました。 それは、12月のDigital Network Architectureでさばかれて、また、ISO TP4[NIST88]に指定されました。
Both Slow-start and End-system Congestion Indication view the relationship between users and gateways as a control system. They
Slow-始めとEnd-システムCongestion Indicationの両方がユーザとゲートウェイとの関係を制御システムであるとみなします。 それら
Performance and Congestion Control Working Group [Page 17] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[17ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
have feedback and control components, the latter further broken down into a procedure bringing a new connection to equilibrium, and a procedure to maintain demand at the proper level. They make use of policies for increasing and decreasing the transport sender's window size. These require the sender to follow a set of self-restraining rules which dynamically adjust the send window whenever congestion is sensed.
フィードバックとコントロールの部品を持ってください、と新しい接続を均衡に連れて来る手順、および維持する手順へさらに砕けている後者は適切なレベルで要求します。 彼らは輸送送付者のウィンドウサイズを増加して、減少させるための方針を利用します。 これらが、送付者がダイナミックに適応する1セットの自己を拘束する規則に従うのを必要とする、混雑が感じられるときはいつも、窓を送ってください。
A predecessor of these, CUTE, developed by [Jai86], introduced the use of retransmission timeouts as congestion feedback. The Slow- start scheme was also designed to use timeouts in the same way. The End-System policies for Congestion Indication use the Congestion Experienced Bit delivered in the network header as the primary feedback, but retransmission timeouts also provoke an end-system congestion response.
これらの前任者([Jai86]によって開発されたCUTE)は混雑フィードバックとして再送タイムアウトの使用を導入しました。 また、Slowスタート計画は、同様に、タイムアウトを使用するように設計されました。 Congestion IndicationのためのEnd-システム方針は第一のフィードバックとしてネットワークヘッダーで届けられたCongestion Experienced Bitを使用しますが、また、再送タイムアウトはエンドシステム混雑応答を引き起こします。
In reliable transport protocols like TCP and TP4, the retransmission timer must do its best to satisfy two conflicting goals. On one hand, the timer must rapidly detect lost packets. And, on the other hand, the timer must minimize false alarms. Since the retransmit timer is used as a congestion signal in these end-system policies, it is all the more important that timeouts reliably correspond to packet drops. One important rule for retransmission is to avoid bad sampling in the measurements that will be used in estimating the round-trip delay. [KP87] describes techniques to ensure accurate sampling. The Host Requirements RFC [HR89] makes these techniques mandatory for TCP.
TCPとTP4のような信頼できるトランスポート・プロトコルでは、再送信タイマーは、2つの闘争目標を満たすために最善をつくさなければなりません。 一方では、タイマは急速に無くなっているパケットを検出しなければなりません。 そして、他方では、タイマは間違い警報を最小にしなければなりません。再送信タイマがこれらのエンドシステム方針による混雑信号として使用されるので、タイムアウトがパケット滴に確かに対応するのは、ひとしお重要です。 1つの「再-トランスミッション」に、重要な規則は往復の遅れを見積もる際に使用される測定における悪い標本抽出を避けることです。 [KP87]は、正確な標本抽出を確実にするためにテクニックについて説明します。 Host Requirements RFC[HR89]はこれらのテクニックをTCPに義務的にします。
The utilization of a resource can be defined as the ratio of its average arrival rate to its mean service rate. This metric varies between 0 and 1.0. In a state of congestion, one or more resources (link, gateway buffer, gateway CPU) has a utilization approaching 1.0. The average delay (round trip time) and its variance approach infinity. Therefore, as the utilization of a network increases, it becomes increasingly important to take into account the variance of the round trip time in estimating it for the retransmission timeout.
平均到着率対平均であるサービス率の比率とリソースの利用を定義できます。 これほどメートル法、0〜1.0を変えます。 混雑の状態では、1つ以上のリソース(リンク、ゲートウェイバッファ、ゲートウェイCPU)が1.0にアプローチする利用を持っています。 平均した遅れ(周遊旅行時間)とその変化は無限にアプローチします。 したがって、ネットワークの利用が増加するのに従って、再送タイムアウトのためにそれを見積もることにおける、周遊旅行時間の変化を考慮に入れるのはますます重要になります。
The TCP retransmission timer is based on an estimate of the round trip time. [Jac88] calls the round trip time estimator the single most important feature of any protocol implementation that expects to survive a heavy load. The retransmit timeout procedure in RFC-793 [Pos81b] includes a fixed parameter, beta, to account for the variance in the delay. An estimate of round trip time using the suggested values for beta is valid for a network which is at most 30% utilized. Thus, the RFC-793 retransmission timeout estimator will fail under heavy congestion, causing unnecessary retransmissions that add to the load, and making congestive loss detection impossible.
TCP再送信タイマーは周遊旅行時間の見積りに基づいています。 [Jac88]は、周遊旅行時間見積り人を重量物を乗り切ると予想するどんなプロトコル実現の最も重要な特徴とも呼びます。 遅れにおける変化のために中のRFC-793[Pos81b]が説明するために固定パラメタ、ベータを含むタイムアウト手順を再送してください。 高々30%利用されたネットワークに、ベータに提案された値を使用する周遊旅行時間の見積りは有効です。 したがって、RFC-793再送タイムアウト見積り人は重い混雑で失敗するでしょう、負荷に加える不要な「再-トランスミッション」を引き起こして、充血性の損失検出を不可能にして。
Slow-start TCP uses the mean deviation as an estimate of the variance
遅れた出発TCPは変化の見積りとして平均偏差を使用します。
Performance and Congestion Control Working Group [Page 18] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[18ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
to improve the estimate. As a rough view of what happens with the Slow-start retransmission calculation, delays can change by approximately two standard deviations without the timer going off in a false alarm. The same method of estimation may be applicable to TP4. The procedure is:
見積りを改良するために。 何がSlow-スタート「再-トランスミッション」計算で起こるかに関する荒い意見として、タイマが間違い警報で発射されないで、遅れはおよそ2つの標準偏差で変化できます。 見積りの同じ方法はTP4に適切であるかもしれません。 手順は以下の通りです。
Error = Measured - Estimated
Estimated = Estimated + Gain_1 * Error
Deviation = Deviation + Gain_2 * (|Error| - Deviation)
Timeout = Estimated + 2 * Deviation
誤り=は測定しました--逸脱+利得_2+ 利得_1*誤り逸脱であると見積もられていたおよそおよそ==*、(| 誤り|、--逸脱) タイムアウト=が+ 2*逸脱を見積もっていた
Where: Gain_1, Gain_2 are gain factors.
どこ: 利得_1、Gain_2は利得要素です。
4.1 Response to No Policy in Gateway
4.1 ゲートウェイで方針がないことへの応答
Since packets must be dropped during congestion because of the finite buffer space, feedback of congestion to the users exists even when there is no gateway congestion policy. Dropping the packets is an attempt to recover from congestion, though it needs to be noted that congestion collapse is not prevented by packet drops if end-systems accelerate their sending rate in these conditions. The accurate detection of congestive loss by all retransmission timers in the end-systems is extremely important for gateway congestion recovery.
有限バッファ領域のために混雑の間、パケットを落とさなければならないので、ゲートウェイ混雑方針全くないときさえ、ユーザへの混雑のフィードバックは存在しています。 パケットを落とすのが、混雑から回復する試みである、それは、注意される必要がありますが、エンドシステムがこれらの状態でそれらの送付レートを加速するなら、その混雑崩壊はパケット滴によって防がれません。 ゲートウェイ混雑回復に、エンドシステムのすべての再送信タイマーによる充血性の損失の正確な検出は非常に重要です。
4.2 Response to Source Quench
4.2 ソース焼き入れへの応答
Given that a Source Quench message has ambiguous meaning, but usually is issued for congestion recovery, the response of Slow-start to a Source Quench is to return to the beginning of the cycle of increase. This is an early response, since the Source Quench on overflow will also lead to a retransmission timeout later.
Source Quenchメッセージをあいまいな意味を持っていますが、混雑回復のために通常発行するなら、Slow-始めのSource Quenchへの応答は増加のサイクルの始まりまで戻ることです。 また、オーバーフローでのSource Quenchが後で再送タイムアウトに通じるので、これは早めの応答です。
4.3 Response to Random Drop
4.3 無作為の低下への応答
The end-system's view of Random Drop is the same as its view of loss caused by overflow at the gateway. This is a drawback of the use of packet drops as congestion feedback for congestion avoidance: the decrease policy on congestion feedback cannot be made more drastic for overflows than for the drops the gateway does for congestion avoidance. Slow-start responds rapidly to gateway feedback. In a case where the users are cooperating (all Slow-start), a desired outcome would be that this responsiveness would lead quickly to a decreased probability of drop. There would be, as an ideal, a self- adjusting overall amount of control.
エンドシステムのRandom Dropの眺めはゲートウェイのオーバーフローで引き起こされた損失の視点と同じです。 これは混雑フィードバックとしてのパケット滴の輻輳回避の使用の欠点です: 混雑フィードバックに関する減少方針をゲートウェイが輻輳回避のためにする低下よりオーバーフローには抜本的にすることができません。 遅れた出発は急速にゲートウェイフィードバックに応じます。 ユーザが協力している場合(すべてのSlow-始め)では、望ましい結果はこの反応性が急速に低下の減少している確率につながるだろうということでしょう。 理想として、自己の調整している総合的な量のコントロールがあるでしょう。
Performance and Congestion Control Working Group [Page 19] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[19ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
4.4 Response to Congestion Indication
4.4 混雑指示への応答
Since the Congestion Indication mechanism attempts to keep gateways uncongested, cooperating end-system congestion control policies need not reduce demand as much as with other gateway policies. The difference between the Slow-start response to packet drops and the End-System Congestion Indication response to Congestion Experienced Bits is primarily in the decrease policy. Slow-start decreases the window to one packet on a retransmission timeout. End-System Congestion Indication decreases the window by a fraction (for instance, to 7/8 of the original value), when the Congestion Experienced Bit is set in half of the packets in a sample spanning two round-trip times (two windows full).
Congestion Indicationメカニズムが、ゲートウェイを非充血させ続けるのを試みるので、協力する場合、エンドシステム輻輳制御方針は需要を他のゲートウェイ方針と同じくらいあまり抑える必要はありません。 パケット滴へのSlow-スタート応答とCongestion Experienced BitsへのEnd-システムCongestion Indication応答の違いが主として減少方針であります。 遅れた出発は窓を再送タイムアウトの1つのパケットまで減少させます。 断片(例えば7/8の元の価値に)に従って、エンドシステムCongestion Indicationは窓を減少させます、往復の2回わたるサンプルがCongestion Experienced Bitにパケットにおける半分はめ込まれるとき(2窓の満)。
4.5 Response to Fair Queuing
4.5 公正な列を作りへの応答
A Fair Queueing policy may issue control indications, as in the simulated Bit-Round Fair Queueing with DEC Bit, or it may depend only on the passive effects of the queueing. When the passive control is the main effect (perhaps because most users are not responsive to control indications), the behavior of retransmission timers will be very important. If retransmitting users send more packets in response to increases in their delay and drops, Fair Queueing will be prone to degraded performance, though collapse (zero throughput for all users) may be prevented for a longer period of time.
Fair Queueing方針が12月のBitとシミュレートされたラウンドのBit Fair Queueingのようにコントロール指摘を発行するかもしれませんか、またはそれは待ち行列の受け身の効果だけによるかもしれません。 受け身のコントロールが主効果(恐らくほとんどのユーザが指摘を制御するために敏感でないので)であるときに、再送信タイマーの働きは非常に重要になるでしょう。 Fair Queueingは降格している性能に傾向があるでしょう、崩壊(すべてのユーザへのスループットがない)は、より長い期間の間防がれるかもしれませんが再送するならユーザがそれらの遅れと低下の増加に対応して、より多くのパケットを送るのを。
5. Conclusions
5. 結論
The impact of users with excessive demand is a driving force as proposed gateway policies come closer to implementation. Random Drop and Congestion Indication can be fair only if the transport entities sharing the gateway are all cooperative and reduce demand as needed. Within some portions of the Internet, good behavior of end-systems eventually may be enforced through administration. But for various reasons, we can expect non-cooperating transports to be a persistent population in the Internet. Congestion avoidance mechanisms will not be deployed all at once, even if they are adopted as standards. Without enforcement, or even with penalties for excessive demand, some end-systems will never implement congestion avoidance mechanisms.
提案されたゲートウェイ方針が実現に近づくとき、過剰需要のユーザの衝撃は原動力です。 ゲートウェイを共有する輸送実体がすべて協力的であり、必要に応じて需要を抑える場合にだけ、無作為のDropとCongestion Indicationは公正である場合があります。 インターネットの数個の部分の中では、エンドシステムの良い働きは結局、管理を通して励行されるかもしれません。 しかし、様々な理由で、私たちは、非協力輸送がインターネットのしつこい人口であると予想できます。 それらが規格として採用されても、輻輳回避メカニズムは一気に配備されないでしょう。 実施なしでで、過剰需要のための刑罰があってもいくつかのエンドシステムは輻輳回避メカニズムを決して実行しないでしょう。
Since it is outside the context of any of the gateway policies, we will mention here a suggestion for a relatively small-scale response to users which implement especially aggressive policies. This has been made experimentally by [Jac89]. It would implement a low priority queue, to which the majority of traffic is not routed. The candidate traffic to be queued there would be identified by a cache of recent recipients of whatever control indications the gateway
ゲートウェイ方針のどれかの文脈の外でそれがあるので、私たちはユーザへの比較的小規模の応答のための提案についてここに言及するつもりです(特に攻撃的な政策を実施します)。 これは[Jac89]によって実験的に作られています。 それは低い優先待ち行列を実行するでしょう。(交通の大部分がそれに発送されません)。 列に並ばせられて、ゲートウェイがいかなるコントロール指摘の最近の受取人のキャッシュによっても特定されるだろうということである候補交通
Performance and Congestion Control Working Group [Page 20] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[20ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
policy makes. Remaining in the cache over multiple control intervals is the criterion for being routed to the low priority queue. In approaching or established congestion, the bandwidth given to the low-service queue is decreased.
方針は作ります。 複数のコントロールインタバルの上にキャッシュに残るのは、低い優先待ち行列に発送されるための評価基準です。 アプローチか確立した混雑では、低いサービス待ち行列に与えられた帯域幅は静まります。
The goal of end-system cooperation itself has been questioned. As [She89] points out, it is difficult to define. A TCP implementation that retransmits before it determines that has been loss indicated and in a Go-Back-N manner is clearly non-cooperating. On the other hand, a transport entity with selective acknowledgement may demand more from the gateways than TCP, even while responding to congestion in a cooperative way.
エンドシステム協力自体の目標は質問されました。 [She89]が指摘するように、それは定義するのが難しいです。 それを決定する前に再送されるTCP実現は示された損失です、そして、方法が明確にGo逆Nへの、非協力である。 他方では、選択している承認がある輸送実体は協力的な方法で混雑に応じさえする間、TCPゲートウェイからの以上を要求するかもしれません。
Fair Queueing maintains its control of allocations regardless of the end-system congestion avoidance policies. [Nag85] and [DKS89] argue that the extra delays and congestion drops that result from misbehavior could work to enforce good end-system policies. Are the rewards and penalties less sharply defined when one or more misbehaving systems cause the whole gateway's performance to be less? While the tax on all users imposed by the "over-users" is much less than in gateways with other policies, how can it be made sufficiently low?
公正なQueueingはエンドシステム輻輳回避方針にかかわらず配分のコントロールを維持します。 [Nag85]と[DKS89]は、不正行為から生じる余分な遅れと混雑低下が良いエンドシステム方針を実施するために働くことができたと主張します。 1かさらにふらちな事ををしているシステム原因であるときに以下が急激に定義した報酬と刑罰は少なくよりなる全体のゲートウェイの性能ですか? 「過剰ユーザ」によって課されたすべてのユーザの税金が他の方針があるゲートウェイよりはるかに少ない間、どうしたらそれを十分低くすることができますか?
In the sections on Selective Feedback Congestion Indication and Bit- Round Fair Queueing we have pointed out that more needs to be done on two particular fronts:
Fair Queueingの周りのSelective Feedback Congestion IndicationとBitの上のセクションで、私たちは、以上が、2つの特定の戦線でする必要であると指摘しました:
How can increased computational overhead be avoided?
どうしたら増加するコンピュータのオーバーヘッドを避けることができますか?
The allocation of resources to source-destination pairs is, in
many scenarios, unfair to individual users. Bit-Round Fair
Queueing offers a potential administrative remedy, but even if it
is applied, how should the unequal allocations be propagated
through multiple gateways?
多くのシナリオでは、ソース目的地組へのリソースの配分は個々のユーザのに対しフェアではありません。 ラウンドのビットFair Queueingは潜在的行政上の救済を提供しますが、それが適用されていても、不平等な配分は複数のゲートウェイを通してどのように伝播されるべきですか?
The first question has been taken up by [McK90].
最初の質問は[McK90]によって始められました。
Since Selective Feedback Congestion Indication (or Congestion Indication used with Fair Queueing) uses a network bit, its use in the Internet requires protocol support; the transition of some portions of the Internet to OSI protocols may make such a change attractive in the future. The interactions between heterogeneous congestion control policies in the Internet will need to be explored.
Selective Feedback Congestion Indication(または、Fair Queueingと共に使用されるCongestion Indication)がネットワークビットを使用するので、インターネットでの使用はプロトコルサポートを必要とします。 インターネットの数個の部分のOSIプロトコルへの変遷で、そのような変更は将来、魅力的になるかもしれません。 インターネットの異種の輻輳制御方針の間の相互作用は、探検される必要があるでしょう。
The goals of Random Drop Congestion Avoidance are presented in this survey, but without any claim that the problems of this policy can be solved. These goals themselves, of uniform, dynamic treatment of users (streams/flows), of low overhead, and of good scaling
Random Drop Congestion Avoidanceの目標はこの調査で提示されますが、いずれがなければも、この方針の問題を解決できると主張してください。 ユーザ(流れ/流れ)の一定の、そして、ダイナミックな処理、低いオーバーヘッド、および良いスケーリングのこれらの目標自体
Performance and Congestion Control Working Group [Page 21] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[21ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
characteristics in large and loaded networks, are significant.
大きくてロードされたネットワークにおける特性は重要です。
Appendix: Congestion and Connection-oriented Subnets
付録: 混雑と接続指向のサブネット
This section presents a recommendation for gateway implementation in an areas that unavoidably interacts with gateway congestion control, the impact of connection-oriented subnets, such as those based on X.25.
このセクションは領域でのやむを得ずゲートウェイ輻輳制御と対話するゲートウェイ実現のための推薦を提示します、接続指向のサブネットの影響、X.25に基づくものなどのように。
The need to manage a connection oriented service (X.25) in order to transport datagram traffic (IP) can cause problems for gateway congestion control. Being a pure datagram protocol, IP provides no information delimiting when a pair of IP entities need to establish a session between themselves. The solution involves compromise among delay, cost, and resources. Delay is introduced by call establishment when a new X.25 SVC (Switched Virtual Circuit) needs to be established, and also by queueing delays for the physical line. Cost includes any charges by the X.25 network service provider. Besides the resources most gateways have (CPU, memory, links), a maximum supported or permitted number of virtual circuits may be in contest.
データグラム交通(IP)を輸送するために、コネクション型サービス(X.25)を管理する必要性はゲートウェイ輻輳制御のために問題を起こすことができます。 純粋なデータグラムプロトコルであり、1組のIP実体が、自分たちの間のセッションを確立する必要がある場合、IPは情報の区切りを提供しません。 解決策は遅れ、費用、およびリソースの中で妥協にかかわります。 新しいX.25 SVC(Virtual Circuitを切り換える)が、設立される必要があるときの呼び出し設立、および物理行への待ち行列遅れは遅れを導入します。 費用はX.25ネットワークサービスプロバイダーでどんな料金も含んでいます。 ほとんどのゲートウェイが持っている(CPU(メモリ)はリンクされます)リソース以外に、コンテストには支持されるか、または仮想のサーキットの数が受入れられた最大があるかもしれません。
SVCs are established on demand when an IP packet needs to be sent and there is no SVC established or pending establishment to the destination IP entity. Optionally, when cost considerations, and sufficient numbers of unused virtual circuits allow, redundant SVCs may be established between the same pair of IP entities. Redundant SVCs can have the effect of improving performance when coping with large end-to-end delay, small maximum packet sizes and small maximum packet windows. It is generally preferred though, to negotiate large packet sizes and packet windows on a single SVC. Redundant SVCs must especially be discouraged when virtual circuit resources are small compared with the number of destination IP entities among the active users of the gateway.
SVCsはIPパケットが、送られる必要があって、どんな確立したSVCもないときの要求か目的地IP実体への設立まで設立されます。 問題、および十分な数の未使用の仮想のサーキットが許容する費用、余分なSVCsが設立するかもしれないときには任意に、同じ組のIP実体の間に設立されてください。 余分なSVCsは大きい終わりから終わりに遅れ、小さい最大のパケットサイズ、および小さい最大のパケット・ウィンドウに対処するとき性能を向上させるという効果を持つことができます。 一般に、もっとも、それが独身のSVCの上の大きいパケットサイズとパケット・ウィンドウを交渉するのが好ましいです。 仮想のサーキットリソースがゲートウェイの活発なユーザの中で目的地IP実体の数と比べて小さいときに、余分なSVCsは特にがっかりしなければなりません。
SVCs are closed after some period of inactivity indicates that communication may have been suspended between the IP entities. This timeout is significant in the operation of the interface. Setting the value too low can result in closing of the SVC even though the traffic has not stopped. This results in potentially large delays for the packets which reopen the SVC and may also incur charges associated with SVC calls. Also, clearing of SVCs is, by definition, nongraceful. If an SVC is closed before the last packets are acknowledged, there is no guarantee of delivery. Packet losses are introduced by this destructive close independent of gateway traffic and congestion.
いつかの期間の不活発が、コミュニケーションがIP実体の間で中断したかもしれないのを示した後にSVCsは閉じられます。 このタイムアウトはインタフェースの操作で重要です。 あまりに低く値を設定すると、通行は止まっていませんが、最後になりましたが、SVCは結果として生じることができます。 これは、SVCを再開させるパケットのための潜在的に大きい遅れをもたらして、また、SVC呼び出しに関連している料金を被るかもしれません。 また、SVCsをきれいにするのも定義上「非-優雅」です。 最後のパケットが承認される前にSVCが閉じられるなら、受渡保証が全くありません。 この破壊的な閉鎖はゲートウェイ交通と混雑の如何にかかわらずパケット損失を導入します。
When a new circuit is needed and all available circuits are currently
新しいサーキットが必要であり、現在すべての利用可能なサーキットが必要であるときに
Performance and Congestion Control Working Group [Page 22] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[22ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
in use, there is a temptation to pick one to close (possibly using some Least Recently Used criterion). But if connectivity demands are larger than available circuit resources, this strategy can lead to a type of thrashing where circuits are constantly being closed and reopened. In the worst case, a circuit is opened, a single packet sent and the circuit closed (without a guarantee of packet delivery). To counteract this, each circuit should be allowed to remain open a minimum amount of time.
使用中に、閉じる1つを選ぶ誘惑があります(ことによると何らかのLeast Recently Used評価基準を使用して)。 しかし、接続性要求が利用可能なサーキットリソースより大きいなら、この戦略はサーキットが絶えず閉じられて、再開しているところで一種の打つのに通じることができます。 最悪の場合には、サーキットは開けられました、そして、単一のパケットは発信しました、そして、サーキットは閉じました(パケット配信の保証なしで)。 これを打ち消すために、サーキットが残っているはずであることができるそれぞれが最小の時間を開きます。
One possible SVC strategy is to dynamically change the time a circuit will be allowed to remain open based on the number of circuits in use. Three administratively controlled variables are used, a minimum time, a maximum time and an adaptation factor in seconds per available circuit. In this scheme, a circuit is closed after it has been idle for a time period equal to the minimum plus the adaptation factor times the number of available circuits, limited by the maximum time. By administratively adjusting these variables, one has considerable flexibility in adjusting the SVC utilization to meet the needs of a specific gateway.
サーキットが使用中のサーキットの数に基づいて開いたままで残ることができるとき、1つの可能なSVC戦略がダイナミックに変化することになっています。 3、行政上、被制御変数は、利用可能なサーキットあたりの秒の使用されていて最小の時間と、最大の時間と適合要素です。 この計画では、期間の同輩のために最小限と適合要素回数への利用可能なサーキットの最大の時間までに制限された数を空費するためにことになった後にサーキットは閉じられます。 行政上これらの変数を調整することによって、1つは特定のゲートウェイの需要を満たすようにSVC利用を調整する際にかなりの柔軟性を持っています。
Acknowledgements
承認
This paper is the outcome of discussions in the Performance and Congestion Control Working Group between April 1988 and July 1989. Both PCC WG and plenary IETF members gave us helpful reviews of earlier drafts. Several of the ideas described here were contributed by the members of the PCC WG. The Appendix was written by Art Berggreen. We are particularly thankful also to Van Jacobson, Scott Shenker, Bruce Schofield, Paul McKenney, Matt Mathis, Geof Stone, and Lixia Zhang for participation and reviews.
この紙は1988年4月、1989年7月の間のパフォーマンスとCongestion Control作業部会の議論の結果です。 PCC WGと絶対的なIETFメンバーの両方が以前の草稿の役立っているレビューを私たちに与えました。 ここで説明されたいくつかの考えがPCC WGのメンバーによって寄付されました。 AppendixはArt Berggreenによって書かれました。 ヴァン・ジェーコブソン、スコットShenker、ブルース・スコーフィールド、ポールMcKenney、マット・マシス、ジェフ・ストーン、およびLixiaチャンにも、私たちは参加とレビューのために特に感謝しています。
References
参照
[DKS89] Demers, A., Keshav, S., and S. Shenker, "Analysis and Simulation of a Fair Queueing Algorithm", Proceedings of SIGCOMM '89.
[DKS89] Demers、A.、Keshav、S.、S.Shenker、および「公正な待ち行列アルゴリズムの分析とシミュレーション」、SIGCOMM89年の議事。
[Fin89] Finn, G., "A Connectionless Congestion Control Algorithm", Computer Communications Review, Vol. 19, No. 5, October 1989.
[Fin89] フィンランド人、G.、「コネクションレスな輻輳制御アルゴリズム」とコンピュータコミュニケーションは、Vol.19、1989年10月No.日5に見直します。
[Gar87] Gardner, M., "BBN Report on the ARPANET", Proceedings of the McLean IETF, SRI-NIC IETF-87/3P, July 1987.
[Gar87] ガードナー、M.、「BBNはアルパネットに関して報告する」マクリーンIETF、様-NIC IETF-87/3P、1987年7月の議事。
[GREQ87] Braden R., and J. Postel, "Requirements for Internet Gateways", RFC 1009, USC/Information Sciences Institute, June 1987.
[GREQ87] ブレーデンR.、およびJ.ポステル、「インターネットゲートウェイのための要件」、RFC1009、科学が1987年6月に任命するUSC/情報。
[HREQ89] Braden R., Editor, "Requirements for Internet Hosts -- Communications Layers", RFC 1122, Internet Engineering Task Force, October 1989.
[HREQ89] ブレーデンR.、エディタ、RFC1122、インターネットが特別委員会を設計することでの1989年10月に「インターネットホストのための要件--コミュニケーションは層にします」。
Performance and Congestion Control Working Group [Page 23] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[23ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
[Has90] Hashem, E., "Random Drop Congestion Control", M.S. Thesis, Massachusetts Institute of Technology, Department of Computer Science, 1990.
[Has90] Hashem、E.、「無作為の低下輻輳制御」、m.s.論文、マサチューセッツ工科大学、コンピュータサイエンス学部、1990。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Proceedings of SIGCOMM '88.
[Jac88] ジェーコブソンと、V.と、「輻輳回避とコントロール」、SIGCOMM88年の議事。
[Jac89] Jacobson, V., "Presentations to the IETF Performance and Congestion Control Working Group".
[Jac89] ジェーコブソン、V.、「IETFパフォーマンスと輻輳制御ワーキンググループへのプレゼンテーション。」
[Jaf81] Jaffe, J., "Bottleneck Flow Control", IEEE Transactions on Communications, COM-29(7), July, 1981.
[Jaf81] ジャフィー、J.、「ボトルネックフロー制御」、コミュニケーションにおけるIEEE取引、COM-29(7)、1981年7月。
[Jai86] Jain, R., "A Timeout-based Congestion Control Scheme for Window Flow-controlled Networks", IEEE Journal on Selected Areas in Communications, SAC-4(7), October 1986.
[Jai86]ジャイナ教徒、R.、「窓のタイムアウトベースの輻輳制御計画はネットワークを流れる制御しました」、コミュニケーションの選択された領域に関するIEEEジャーナル、嚢-4(7)、1986年10月。
[JRC87] Jain, R., Ramakrishnan, K., and D. Chiu, "Congestion Avoidance in Computer Networks With a Connectionless Network Layer", Technical Report DEC-TR-506, Digital Equipment Corporation.
[JRC87] ジャイナ教徒、R.、Ramakrishnan、K.、およびD.チウ、「コネクションレスなネットワーク層があるコンピュータネットワークにおける輻輳回避」、技術報告書12月-TR-506(DEC)。
[Kle79] Kleinrock, L., "Power and Deterministic Rules of Thumb for Probabilistic Problems in Computer Communications", Proceedings of the ICC '79.
[Kle79] クラインロックと、L.と、「コンピュータコミュニケーションの確率的問題のためのパワーと決定論的な経験則」、ICC79年の議事。
[KP87] Karn, P., and C. Partridge, "Improving Round Trip Estimates in Reliable Transport Protocols", Proceedings of SIGCOMM '87.
[KP87] SIGCOMM87年のKarn、P.、およびC.ヤマウズラ、「信頼できるトランスポート・プロトコルにおける周遊旅行見積りを改良します」、議事。
[Man90] Mankin, A., "Random Drop Congestion Control", Proceedings of SIGCOMM '90.
[Man90] マンキン、A.、「無作為の低下輻輳制御」、SIGCOMM90年の議事。
[McK90] McKenney, P., "Stochastic Fairness Queueing", Proceedings of INFOCOM '90.
[McK90] McKenney、P.、「推計的な公正待ち行列」、INFOCOM90年の議事。
[Nag84] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, FACC Palo Alto, 6 January 1984.
[Nag84] ネーグル、J.、「IP/TCPインターネットワークにおける輻輳制御」、RFC896、FACCパロアルト1984年1月6日。
[Nag85] Nagle, J., "On Packet Switches With Infinite Storage", RFC 970, FACC Palo Alto, December 1985.
[Nag85] ネーグル、J.、「無限の格納があるパケット交換機」、RFC970、FACCパロアルト1985年12月。
[NIST88] NIST, "Stable Implementation Agreements for OSI Protocols, Version 2, Edition 1", National Institute of Standards and Technology Special Publication 500-162, December 1988.
[NIST88]NIST、「OSIプロトコル、バージョン2、版の1インチ、米国商務省標準技術局の特別な公表500-162、1988年12月の安定した実現協定。」
[Pos81a] Postel, J., "Internet Control Message Protocol - DARPA Internet Program Protocol Specification", RFC-792, USC/Information Sciences Institute, September 1981.
[Pos81a] ポステル、J.、「インターネットはメッセージプロトコルを制御します--DARPAインターネットはプロトコル仕様をプログラムする」RFC-792、科学が1981年9月に設けるUSC/情報。
Performance and Congestion Control Working Group [Page 24] RFC 1254 Gateway Congestion Control Survey August 1991
パフォーマンスと輻輳制御作業部会[24ページ]RFC1254ゲートウェイ混雑は調査1991年8月に制御されます。
[Pos81b] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC-793, DARPA, September 1981.
[Pos81b] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC-793、DARPA、1981年9月。
[RJC87] Ramakrishnan, K., Jain, R., and D. Chiu, "A Selective Binary Feedback Scheme for General Topologies", Technical Report DEC-TR-510, Digital Equipment Corporation.
[RJC87] Ramakrishnan、K.、ジャイナ教徒、R.、およびD.チウ、「Topologies司令官の選択している2進のフィードバック計画」、技術報告書12月-TR-510(DEC)。
[She89] Shenker, S., "Correspondence with the IETF Performance and Congestion Control Working Group".
[She89] Shenker、S.、「IETFパフォーマンスと輻輳制御ワーキンググループとの通信。」
[Sp89] Spector, A., and M. Kazar, "Uniting File Systems", Unix Review, Vol. 7, No. 3, March 1989.
[Sp89] スペクター、A.、およびM.Kazar、「ファイルシステムを結合させます」、unixはVol.7、1989年3月No.日3に論評します。
[Zha89] Zhang, L., "A New Architecture for Packet Switching Network Protocols", Ph.D Thesis, Massachusetts Institute of Technology, Department of Computer Science, 1989.
[Zha89] チャン、L.、「パケット交換網プロトコルのための新しい構造」、博士号論文、マサチューセッツ工科大学、コンピュータサイエンス学部、1989。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
Allison Mankin The MITRE Corporation M/S W425 7525 Colshire Drive McLean, VA 22102
アリソン・マンキン斜め継ぎ社のM/S W425 7525Colshireはマクリーン、ヴァージニア 22102を追い立てます。
Email: mankin@gateway.mitre.org
メール: mankin@gateway.mitre.org
K.K. Ramakrishnan Digital Equipment Corporation M/S LKG1-2/A19 550 King Street Littleton, MA 01754
リトルトン、K.K.Ramakrishnan DEC M/S LKG1-2/A19 550キング・ストリートMA 01754
Email: rama@kalvi.enet.dec.com
メール: rama@kalvi.enet.dec.com
Performance and Congestion Control Working Group [Page 25]
パフォーマンスと輻輳制御作業部会[25ページ]
一覧
スポンサーリンク
