RFC1046 日本語訳
1046 Queuing algorithm to provide type-of-service for IP links. W.Prue, J. Postel. February 1988. (Format: TXT=30106 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Prue
Request for Comments: 1046 J. Postel
ISI
February 1988
Prueがコメントのために要求するワーキンググループW.をネットワークでつないでください: 1046 J.ポステルISI1988年2月
A Queuing Algorithm to Provide Type-of-Service for IP Links
サービスのタイプをIPリンクに供給する待ち行列アルゴリズム
Status of this Memo
このMemoの状態
This memo is intended to explore how Type-of-Service might be implemented in the Internet. The proposal describes a method of queuing which can provide the different classes of service. The technique also prohibits one class of service from consuming excessive resources or excluding other classes of service. This is an "idea paper" and discussion is strongly encouraged. Distribution of this memo is unlimited.
このメモがサービスのTypeがインターネットでどう実行されるかもしれないかを探検することを意図します。 提案は異なったクラスのサービスを提供できる列を作りの方法を説明します。 また、テクニックは、1つのクラスのサービスが過度のリソースを消費するか、または他のクラスのサービスを除くのを禁止します。 これは「考え紙」です、そして、議論は強く奨励されます。 このメモの分配は無制限です。
Introduction
序論
The Type-of-Service (TOS) field in IP headers allows one to chose from none to all the following service types; low delay, high throughput, and high reliability. It also has a portion allowing a priority selection from 0-7. To date, there is nothing describing what should be done with these parameters. This discussion proposes an approach to providing the different classes of service and priorities requestable in the TOS field.
IPヘッダーの分野が1つを許容するサービスのType(TOS)はなにもから以下のすべてのサービスタイプまで選びました。 低い遅れ、高生産性、および高信頼性。 また、それには、0-7から優先権選択を許す部分があります。 これまで、何もこれらのパラメタでするべきであることについて説明するものがありません。 この議論はTOS分野で要求可能な異なったクラスのサービスを提供して、プライオリティへのアプローチを提案します。
Desired Attributes
必要な属性
We should first consider how we want these services to perform. We must first assume that there is a demand for service that exceeds current capabilities. If not, significant queues do not form and queuing algorithms become superfluous.
私たちは、最初に、どのようにこれらのサービスが働いて欲しいかを考えるべきです。 私たちは、最初に、現在の能力を超えているサービスの要求があると思わなければなりません。 そうでなければ、重要な待ち行列は形成されません、そして、待ち行列アルゴリズムは余計になります。
The low delay class of service should have the ability to pass data through the net faster than regular data. If a request is for low delay class of service only, not high throughput or high reliability, the Internet should provide low delay for relatively less throughput, with less than high reliability. The requester is more concerned with promptness of delivery than guaranteed delivery. The Internet should provide a Maximum Guaranteed Delay (MGD) per node, or better, if the datagram successfully traverses the Internet. In the worst case, a datagram's arrival will be MGD times the number of nodes traversed. A node is any packet switching element, including IP gateways and ARPANET IMP's. The MGD bound will not be affected by the amount of traffic in the net. During non-busy hours, the delay provided should be better than the guarantee. If the delay a
低遅れのクラスのサービスには、ネットに通常のデータより速くデータを通す能力があるべきです。 要求が高生産性か高信頼性ではなく、低遅れのクラスのサービスだけのためのものであるなら、インターネットは比較的少ないスループットに低い遅れを提供するべきです、高信頼性以下で。 リクエスタは配送が保証されるより配送の引渡し日に関係があります。 データグラムが首尾よくインターネットを横断するなら、インターネットは1ノードあたり1Maximum Guaranteed Delay(MGD)、または、よりよく提供されるべきです。 最悪の場合には、データグラムの到着はノードの数が横断したMGD回になるでしょう。 ノードはIPゲートウェイとARPANET IMPのものを含むあらゆるパケット交換要素です。 MGDバウンドはネットにおける交通の量で影響を受けないでしょう。 非忙しい時間、提供された遅れは保証より良いはずです。 遅れです。
Prue & Postel [Page 1] RFC 1046 Type-of-Service Queuing February 1988
1988年2月に列を作るサービスのPrueとポステル[1ページ]RFC1046タイプ
satellite link introduces is less than the MGD, that link should be considered in the route. If however, the MGD is less than the satellite link can provide, it should not be used. For this discussion it is assumed that delay for individual links are low enough that a sending node can provide the MGD service.
リンクが紹介する衛星がMGD以下である、そのリンクはルートで考えられるべきです。 しかしながら、MGDが衛星中継が提供されることができるより少ないなら、それを使用するべきではありません。 この議論において、個人のためのその遅れであると思われて、リンクは送付ノードがMGDサービスを備えることができるくらい低いです。
Low delay class of service is not the same as low Round Trip Time (RTT). Class of service is unidirectional. The datagrams responding to low delay traffic (i.e., Acking the data) might be sent with a high reliability class of service, but not low delay.
低遅れのクラスのサービスは低いRound Trip Time(RTT)と同じではありません。 サービスのクラスは単方向です。 低い遅れ交通に反応するデータグラム、(すなわち、Acking、データ) 低い遅れではなく、高信頼性のクラスのサービスは送るかもしれません。
The performance of TCP might be significantly improved with an accurate estimate of the round trip time and the retransmission timeout. The TCP retransmission timeout could be set to the maximum delay for the current route (if the current route could be determined). The timeout value would have to be redetermined when the number of hops in the route changes.
TCPの性能は周遊旅行時間と再送タイムアウトの正確な見積りでかなり向上されているかもしれません。 現在のルートのために最大の遅れにTCP再送タイムアウトを設定できました(現在のルートが決定できるなら)。 ルートによるホップの数が変化すると、タイムアウト値は再決定しなければならないでしょう。
High throughput class of service should get a large volume of data through the Internet. Requesters of this class are less concerned with the delay the datagrams have crossing the Internet and the reliability of their delivery. This type of traffic might be served well by a satellite link, especially if the bandwidth is high. Another attribute this class might have is consistent one way traversal time for a given burst of datagrams. This class of service will have its traversal times affected by the amount of Internet load. As the Internet load goes up, the throughput for each source will go down.
高生産性のクラスのサービスはインターネットで多くのデータを手に入れるべきです。 このクラスのリクエスタはそれほど彼らの配送のインターネットと信頼性に交差するデータグラムが持っている遅れに関係がありません。 特に帯域幅が高いなら、このタイプの交通は衛星中継によってよく役立たれるかもしれません。 このクラスが持っているかもしれない別の属性はデータグラムの与えられた炸裂のための一貫した一方通行の縦断時間です。このクラスのサービスで、縦断時代はインターネット負荷の量で影響を受けるでしょう。 インターネット負荷が上がるのに従って、各ソースへのスループットは落ちるでしょう。
High reliability class of service should see most of its datagrams delivered if the Internet is not too heavily loaded. Source Quenches (SQ) should not be sent only when datagrams are discarded. SQs should be sent well before the queues become full, to advise the sender of the rate that can be currently supported.
高信頼性のクラスのサービスは、インターネットが大いにロードされ過ぎるというわけではないとデータグラムの大部分が届けられるのを見るべきです。 データグラムが捨てるときだけ、ソースQuenches(シンガポール航空の便名)を送るべきではありません。 待ち行列が現在支持できるレートを送付者に知らせるために完全になる前にSQsをよく送るべきです。
Priority service should allow data that has a higher priority to be queued ahead of other lower priority data. It is important to limit the amount of priority data. The amount of preemption a lower priority datagram suffers must also be limited.
優先サービスで、より高い優先度を持っているデータは他の低優先度データの前に列に並ばせるべきです。 優先権データの量を制限するのは重要です。 また、低優先度データグラムが受ける先取りの量を制限しなければなりません。
It is assumed that a queuing algorithm provides these classes of service. For one facility to be used over another, that is, making different routing decisions based upon the TOS, requires a more sophisticated routing algorithm and larger routing database. These issues are not discussed in this document.
待ち行列アルゴリズムがこれらのクラスのサービスを提供すると思われます。 使用される1つの施設に、別のもの、すなわち、異なったルーティング決定がTOSに基礎づけた作成は、より高度なルーティング・アルゴリズムと、より大きいルーティングデータベースを必要とします。 本書ではこれらの問題について議論しません。
Prue & Postel [Page 2] RFC 1046 Type-of-Service Queuing February 1988
1988年2月に列を作るサービスのPrueとポステル[2ページ]RFC1046タイプ
Applications for Class of Service
サービスのクラスのアプリケーション
The following are examples of how classes of service might be used. They do not necessarily represent the best choices, but are presented only to illustrate how the different classes of service might be used to advantage.
↓これはサービスのクラスがどう使用されるかもしれないかに関する例です。 それらは、必ず最も良い選択を表すというわけではありませんが、提示されますが、異なったクラスのサービスがどう利点に利用されるかもしれないかを例証します。
Interactive timesharing access using a line-at-a-time or character- at-a-time terminal (TTY) type of access is typically low volume typing speed input with low or high volume output. Some Internet applications use echoplex or character by character echoing of user input by the destination host. PC devices also have local files that may be uploaded to remote hosts in a streaming mode. Supporting such traffic can require several types of service. User keyboard input should be forwarded with low delay. If echoplex is used, all user characters sent and echoed should be low delay to minimize the echoing delay. The computer responses should be regular or high throughput depending upon the volume of data sent and the speed of the output device. If the computer response is a single datagram of data, the user should get low delay for the response, to minimize the human/computer interaction time. If however the output takes a while to read and digest, low delay computer responses are a waste of Internet resources. When streaming input is being sent the data should be sent requesting high throughput or regular class of service.
一度に線を使用する対話的な時分割アクセスかキャラクタ時間の端末(TTY)タイプのアクセスは低いか高いボリューム出力で入力された速度をタイプする通常低いボリュームです。 いくつかのインターネットアプリケーションがあて先ホストでユーザ入力をまねるキャラクタでechoplexかキャラクタを使用します。 また、PC装置には、ストリーミングのモードでリモートホストにアップロードされるかもしれないローカルファイルがあります。 そのような交通を支持すると、いくつかのタイプにサービスを要求できます。 低い遅れと共にユーザキーボード入力を進めるべきです。 echoplexが使用されているなら、キャラクタが最小にする低い遅れが反響遅れであったなら送って、言葉を繰り返したすべてのユーザです。 コンピュータ応答は送られたデータ量と出力装置の速度に応じた通常の、または、高いスループットであるべきです。 コンピュータ応答がデータの単一のデータグラムであるなら、ユーザは、人間/コンピュータインタラクション時間を最小にするために応答のための低い遅れを得るべきです。 しかしながら、出力が読んで、読みこなすにはしばらくかかるなら、低い遅れコンピュータ応答はインターネット資料の浪費です。 ストリーミングの入力を送るとき、データに高生産性か通常のクラスのサービスを要求させるべきです。
The IBM 3270 class of terminals typically have traffic volumes greater than TTY access. Echoplex is not needed. The output devices usually handle higher speed output streams and most sites do not have the ability to stream input. Input is typically a screen at a time, but some PC implementations of 3270 use a variation of the protocol to effectively stream in volumes of data. Low delay for low volume input and output is appropriate. High throughput is appropriate for the higher volume traffic.
端末のIBM3270のクラスは交通量をTTYアクセサリーよりすばらしく通常します。 Echoplexは必要ではありません。 通常、出力装置は、より高い速度出力ストリームを扱います、そして、ほとんどのサイトには、入力を流す能力がありません。 入力されているのが、通常一度にスクリーンですが、3270年のいくつかのPC実現が、事実上、データのボリュームで流れるのにプロトコルの変化を使用します。 低いボリューム入出力のための低い遅れは適切です。 より高いボリューム交通に、高生産性は適切です。
Applications that transfer high volumes of data are typically streaming in one direction only, with acks for the data, on the return path. The data transfer should be high throughput and the acks should probably be regular class of service. Transfer initiation and termination might be served best with low delay class of service.
データの高い量を移すアプリケーションは一方向だけに通常ストリーミングです、データのためのacksで、リターンパスで。 データ転送は高生産性であるべきです、そして、acksはたぶん通常のクラスのサービスであるべきです。 低遅れのクラスのサービスに転送開始と終了を最もよく供給するかもしれません。
Requests to, and responses from a time service might use low delay class of service effectively.
時間指定サービスからの要求、および応答は利用するかもしれません。有効に低遅れのクラスのサービスを利用してください。
These suggestions for class of service usage implies that the application sets the service based on the knowledge it has during the session. Thus, the application should have control of this setting
サービス用法のクラスが、アプリケーションがサービスを設定するのを含意するので、これらの提案はそれがセッションの間に持っている知識を基礎づけました。 したがって、アプリケーションはこの設定を管理するべきです。
Prue & Postel [Page 3] RFC 1046 Type-of-Service Queuing February 1988
1988年2月に列を作るサービスのPrueとポステル[3ページ]RFC1046タイプ
dynamically for each send data request, not just on a per session/conversation/transaction basis. It would be possible for the transport level protocol to guess (i.e., TCP), but it would be sub- optimal.
ダイナミックである、セッション/会話/取引基礎あたりのaだけではなく、それぞれの送信データ要求のために。 輸送レベルにおいて、しかし、推測するプロトコル(すなわち、TCP)、それがサブ最適であることは、可能でしょう。
Algorithm
アルゴリズム
When we provide class of service queuing, one class may be more desirable than the others. We must limit the amount of resources each class consumes when there is contention, so the other classes may also operate effectively. To be fair, the algorithm provides the requested service by reducing the other service attributes. A request for multiple classes of service is an OR type of request not an AND request. For example, one can not get low delay and high throughput unless there is no contention for the available resources.
私たちがサービスの列を作りのクラスを提供するとき、1つのクラスが他のものより望ましいかもしれません。 主張があるとき、私たちが各クラスが消費するリソースの量を制限しなければならないので、また、他のクラスは有効に働くかもしれません。 公正に、なるように、アルゴリズムは他のサービス属性を減少させることによって、要求されたサービスを提供します。 複数のクラスのサービスを求める要求はAND要求ではなく、要求のORタイプです。 例えば、利用可能資源のための主張が全くない場合、1つは低い遅れと高生産性を得ることができません。
Low Delay Queuing
低い遅れの列を作り
To support low delay, use a limited queue so requests will not wait longer than the MGD on the queue. The low delay queue should be serviced at a lower rate than other classes of service, so low delay requests will not consume excessive resources. If the number of low delay datagrams exceeds the queue limit, discard the datagrams. The service rate should be low enough so that other data can still get through. (See discussion of service rates below.) Make the queue limit small enough so that, if the datagram is queued, it will have a guaranteed transit time (MGD). It seems unlikely that Source Quench flow control mechanisms will be an effective method of flow control because of the small size of the queue. It should not be done for this class of service. Instead, datagrams should just be discarded as required. If the bandwidth or percentage allocated to low delay is such that a large queue is possible (see formula below), SQs should be reconsidered.
低い遅れを支持するために、したがって限られた待ち行列が要求する使用は待ち行列のときにMGDより長い間、待っていません。 低い遅れ待ち行列は他のクラスのサービスより低レートで修理されるべきです、遅れ要求が過度のリソースを消費しないように、とても低いです。 低い遅れデータグラムの数が待ち行列限界を超えているなら、データグラムを捨ててください。サービス率は、他のデータがまだ通ることができるくらい十分低いはずです。 (以下のサービス率の議論を見てください。) データグラムが列に並ばせられると、保証されたトランジット時間(MGD)を過すように、十分小さく待ち行列限界をしてください。 Source Quenchフロー制御メカニズムが待ち行列の小型によるフロー制御について有効な手段になるのはありそうもなく見えます。 このクラスのサービスのためにそれをするべきではありません。 代わりに、データグラムは必要に応じてただ捨てられるべきです。 大きい待ち行列が低い遅れに割り当てられた帯域幅か割合がそのようなものであるので可能であるなら(以下の公式を見てください)、SQsは再考されるべきです。
The maximum delay a datagram with low delay class of service will experience (MGD), can be determined with the following information:
低遅れのクラスのサービスがあるデータグラムが経験する最大の遅れ(MGD)、以下の情報で決定できます:
N = Queue size for low delay queue
P = Percentage of link resources allocated to low delay
R = Link rate (in datagrams/sec.)
N
Max Delay = -----
P * R
Nはリンク低い遅れR=レート(データグラム/秒の)に割り当てられた低遅れ待ち行列P=百分率のリンクリソースのために待ち行列サイズと等しいです。 エヌマックス遅れ=----- P*R
If Max Delay is held fixed, then as P and R go up, so does N. It is probable that low delay service datagrams will prove to be, on the average, smaller than other traffic. This means that the number of datagrams that can be sent in the allocated bandwidth can be larger.
マックスDelayがPとRがそして、上がるとき修理されているのに保たれて、そうするのでN.Itがそんなに低くありえそうであるなら、データグラムが判明するサービスを遅らせてください、平均して、他の交通より小さいです。 これは、割り当てられた帯域幅で送ることができるデータグラムの数が、より大きい場合があることを意味します。
Prue & Postel [Page 4] RFC 1046 Type-of-Service Queuing February 1988
1988年2月に列を作るサービスのPrueとポステル[4ページ]RFC1046タイプ
High Reliability Queuing
高信頼性の列を作り
To support high reliability class of service, use a queue that is longer than normal (longer queue means higher potential delay). Send SQ earlier (smaller percentage of max queue length) and don't discard datagrams until the queue is full. This queue should have a lower service rate than high throughput class of service.
高信頼性のクラスのサービスを支持するには、標準より長い待ち行列を使用してください(さらに長い待ち行列はさらに高い潜在的遅れを意味します)。 より多くの早さに(よりわずかな百分率の最大待ち行列の長さ)シンガポール航空の便名を送ってください、そして、待ち行列が完全になるまで、データグラムを捨てないでください。 この待ち行列に、高生産性のクラスのサービスより低サービス率があるべきです。
Users of this class of service should specify a Time-to-Live (TTL) which is made appropriately longer so that it will survive longer queueing times for this class of service.
このクラスのサービスのユーザは生きるこのクラスのサービスのために、より長い待ち行列回を乗り切るように適切により長くされるTime(TTL)を指定するべきです。
This queuing procedure will only be effective for Internet unreliability due to congestion. Other Internet unreliability problems such as high error rate links or reliability features such as forward error correcting modems must be dealt with by more sophisticated routing algorithms.
この列を作り手順は混雑によるインターネット非信頼性だけに効果的になるでしょう。 より高度なルーティング・アルゴリズムで高い誤り率リンクなどの他のインターネット非信頼性問題か前進のエラー修正モデムなどの信頼性の機能に対処しなければなりません。
High Throughput Queuing
高生産性の列を作り
To support high throughput class of service have a queue that is treated like current IP queuing. It should have the highest service rate. It will experience higher average through node delay than low delay because of the larger queue size.
高生産性のクラスのサービスを支持するには、現在のIPの列を作りのように扱われる待ち行列を持ってください。 それには、最も高いサービス率があるべきです。 それはノード遅れを通したより大きい待ち行列サイズによる低い遅れより高い平均を経験するでしょう。
Another thing that might be done, is to keep datagrams of the same burst together when possible. This must be done in a way that will not block other traffic. The idea is to deliver all the data to the other end in a contiguous burst. This could be an advantage by allowing piggybacking acks for the whole burst at one time. This makes some assumptions about the overlying protocol which may be inappropriate.
可能であるときに、それが終わって、同じくらいのデータグラムであることを保つことになっているかもしれない別のことは一緒にはち切れました。 これは他の交通を妨げない方法で完了していなければなりません。 考えは隣接の炸裂ですべてのデータをもう一方の端に送ることです。 ひところ全体の炸裂のためにacksを背負うのを許容することによって、これは利点であるかもしれません。 これは不適当であるかもしれない付加プロトコルに関するいくつかの仮定をします。
Regular Service Queuing
定期点検の列を作り
For datagrams which request none of the three classes of service, queue the datagrams on the queue representing the least delay between the two queues, the high throughput queue or the high reliability queue. If one queue becomes full, queue on the other. If both queues are full, follow the source quench procedure for regular class of service (see RFC-1016), not the procedure for the queue the datagram failed to attain.
サービスの3つのクラスのいずれも要求しないデータグラムに関しては、2つの待ち行列、高生産性待ち行列または高信頼性待ち行列の間の最少の遅れを表す待ち行列のときにデータグラムを列に並ばせてください。 1つの待ち行列が完全になるなら、もう片方に列を作ってください。 両方の待ち行列が完全であるなら、データグラムが達しなかった待ち行列のための手順ではなく、通常のクラスのサービス(RFC-1016を見る)のためのソース焼き入れ手順に従ってください。
In the discussion of service rates described below, it is proposed that the high throughput queue get service three times for every two times for the high reliability queue. Therefore, the queue length of the high reliability queue should be increased by 50% (in this example) to compare the lengths of the two queues more accurately. A
以下で説明されたサービス率の議論では、高生産性待ち行列が高信頼性待ち行列のための2回毎のために3回サービスを得るよう提案されます。 したがって、高信頼性待ち行列の待ち行列の長さは、より正確に2つの待ち行列の長さを比較するために50%(この例の)増加するべきです。 A
Prue & Postel [Page 5] RFC 1046 Type-of-Service Queuing February 1988
1988年2月に列を作るサービスのPrueとポステル[5ページ]RFC1046タイプ
simplification to this method is to just queue new data on the queue that is the shortest. The slower service rate queue will quickly exceed the size of the faster service rate queue and new data will go on the proper queue. This however, would lead to more packet reordering than the first method.
この方法への簡素化はただ最も短い待ち行列に関する新しいデータを列に並ばせることです。 より遅いサービス率待ち行列は急速により速いサービス率待ち行列のサイズを超えるでしょう、そして、新しいデータは適切な待ち行列に行くでしょう。 しかしながら、この最初の方法より多くのパケット再命令に通じるでしょう。
Service Rates
サービス率
In this discussion, a higher service rate means that a queue, when non-empty, will consume a larger percentage of the available bandwidth than a lower service rate queue. It will not block a lower service rate queue even if it is always full.
この議論では、下側のサービス率待ち行列より高いサービス率は、非空であるときに、待ち行列が利用可能な帯域幅の、より大きい百分率を消費することを意味します。 いつも完全であっても、それは下側のサービス率待ち行列を妨げないでしょう。
For example, the service pattern could be; send low delay 17% of the time, high throughput 50% of the time, and high reliability 33% of the time. Throughput requires the most bandwidth and high reliability requires medium bandwidth. One could achieve this split using a pattern of L, R,R, T,T,T, where low delay is "L", high reliability is "R", and high throughput is "T'. We want to keep the high throughput datagrams together. We therefore send all of the high throughput data at one time, that is, not interspersed with the other classes of service. By keeping all of the high throughput data together, we may help higher level protocols, such as TCP, as described above. This would still be done in a way to not exceed the allowed service rate of the available bandwidth.
例えば、サービスパターンはそうであるかもしれません。 33%の割合で時間、時間の50%の高生産性、および高信頼性の17%を低い遅れに送ってください。 スループットは最も多くの帯域幅を必要とします、そして、高信頼性は中型の帯域幅を必要とします。 '1つはLのパターンを使用することでこの分裂を実現するかもしれません、R、R、T、T、T、低い遅れが「L」であり、高信頼性が「R」であり、高生産性が「T'であるところで」。 高生産性データグラムを団結したいと思います。 したがって、私たちがひところ高生産性データのすべてを送って、それは他のクラスのサービスで点在するのではなく、います。 高生産性データのすべてを団結することによって、私たちは、より高い平らなプロトコルを助けるかもしれません、TCPなどのように、上で説明されるように。 これはまだ利用可能な帯域幅の許容サービス率を超えない方法で完了しているでしょう。
These service rates are suggestions. Some simplifications can be considered, such as having only two routing classes; low delay, and other.
これらのサービス率は提案です。 2つのルーティングのクラスしか持っていないのなどようにいくつかの簡素化を考えることができます。 低い遅れで、他です。
Priority
優先権
There is the ability to select 8 levels of priority 0-7, in addition to the class of service selected. To provide this without blocking the least priority requests, we must give preempted datagrams frustration points every time a higher priority request cuts in line in front of it. Thus if a datagram with low priority waits, it will always get through even when competing against the highest priority requests. This assumes the TTL (Time-to-Live) field does not expire.
選択されたサービスのクラスに加えて8つのレベルの優先権0-7を選択する能力があります。 最少の優先権要求を妨げないでこれを提供するために、より高い優先権要求がそれの正面で列に割り込むときはいつも、私たちは先取りされたデータグラムフラストレーションポイントを与えなければなりません。 最優先要求を競争さえするとき、したがって、低い優先度があるデータグラムが待っていると、それはいつも通るでしょう。 これは、TTL(生きる時間)分野が期限が切れないと仮定します。
When a datagram with priority arrives at a node, the node will queue the datagram on the appropriate queue ahead of all datagrams with lower priority. Each datagram that was preempted gets its priority raised (locally). The priority data will not bump a lower priority datagram off its queue, discarding the data. If the queue is full, the newest data (priority or not) will be discarded. The priority preemption will preempt only within the class of service queue to
優先権があるデータグラムがノードに届くと、ノードはすべてのデータグラムの前の適切な待ち行列のときに低優先度でデータグラムを列に並ばせるでしょう。 先取りされた各データグラムで、(局所的に)優先権を上げます。 データを捨てて、優先権データは待ち行列で低優先度データグラムに突き当たらないでしょう。 待ち行列が完全であるなら、最も新しいデータ(優先権であるか否かに関係なく)は捨てられるでしょう。 先取りが中だけでサービス待ち行列のクラスを先取りするために望んでいる優先権
Prue & Postel [Page 6] RFC 1046 Type-of-Service Queuing February 1988
1988年2月に列を作るサービスのPrueとポステル[6ページ]RFC1046タイプ
which the priority data is targeted. A request specifying regular class of service, will contend on the queue where it is placed, high throughput or high reliability.
どれ、優先権データは狙うか。 要求が通常のクラスのサービスを指定すると、待ち行列のときに、それがどこに置かれるか、そして、高生産性か高い信頼性を主張するでしょう。
An implementation strategy is to multiply the requested priority by 2 or 4, then store the value in a buffer overhead area. Each time the datagram is preempted, increment the value by one. Looking at an example, assume we use a multiplier of 2. A priority 6 buffer will have an initial local value of 12. A new priority 7 datagram would have a local value of 14. If 2 priority 7 datagrams arrive, preempting the priority 6 datagram, its local value is incremented to 14. It can no longer be preempted. After that, it has the same local value as a priority 7 datagram and will no longer be preempted within this node. In our example, this means that a priority 0 datagram can be preempted by no more than 14 higher priority datagrams. The priority is raised only locally in the node. The datagram could again be preempted in the next node on the route.
実現戦略は、要求された優先権を2か4に掛けて、次に、バッファオーバーヘッド領域に値を格納することです。 データグラムが先取りされるたびに値を1つ増加してください。 例を見て、私たちが2の乗数を使用すると仮定してください。 優先権6バッファには、12の初期の地方の値があるでしょう。 新しい優先権7データグラムには、14の地方の値があるでしょう。 優先権6データグラムを先取りして、2個の優先権7データグラムが届くなら、地方の値は14まで増加されます。 もうそれを先取りできません。 その後に、それは、優先権7データグラムと同じ地方の値を持って、もうこのノードの中で先取りされないでしょう。 私たちの例では、これは、14個未満のより高い優先権データグラムで優先権0データグラムを先取りできることを意味します。優先権はノードで局所的にだけ上げられます。 再びルートの上の次のノードでデータグラムを先取りできました。
Priority queuing changes the effects we were obtaining with the low delay queuing described above. Once a buffer was queued, the delay that a datagram would see could be determined. When we accepted low delay data, we could guarantee a certain maximum delay. With this addition, if the datagram requesting low delay does not also request high priority, the guaranteed delay can vary a lot more. It could be 1 up to 28 times as much as without priority queuing.
優先権の列を作りは低い遅れの列を作りが上で説明されている状態で私たちが得ていた効果を変えます。 バッファがいったん列に並ばせられると、データグラムが見る遅れは決定できるでしょうに。 少ない遅れデータを受け入れたとき、私たちはある最大の遅れを保証できました。 この添加によると、また、低い遅れを要求するデータグラムが高い優先度を要求しないなら、保証された遅れはずっと多く異なることができます。 それは優先権の列を作りの最大28倍はるかに1であるかもしれません。
Discussion and Details
議論と詳細
If a low delay queue is for a satellite link (or any high delay link), the max queue size should be reduced by the number of datagrams that can be forwarded from the queue during the one way delay for the link. That is, if the service rate for the low delay queue is L datagrams per second, the delay added by the high delay link is D seconds and M is the max delay per node allowed (MGD) in seconds, then the maximum queue size should be:
衛星中継(または、どんな高い遅れリンクも)に低い遅れ待ち行列があるなら、最大待ち行列サイズは一方通行の遅れの間に待ち行列からリンクに送ることができるデータグラムの数によって減少させられるべきです。 すなわち、低い遅れ待ち行列のためのサービス率が1秒あたりLデータグラムであり、高い遅れリンクによって加えられた遅れがD秒であり、Mが秒に1ノードあたりの遅れが許容した最大(MGD)であるなら、最大の待ち行列サイズは以下の通りであるべきです。
Max Queue Size = L ( M - D), M > D
= 0 , M <= D
マックス待ち行列サイズはLと等しく(M--D)、M>Dは0、M<=Dと等しいです。
If the result is negative (M is less than the delay introduced by the link), then the maximum queue size should be zero because the link could never provide a delay less than the guaranteed M value. If the bandwidth is high (as in T1 links), the delay introduced by a terrestrial link and the terminating equipment could be significant and greater than the average service time for a single datagram on the low delay queue. If so, this formula should be used to reduce the queue size as well. Note that this is reducing the queue size and is not the same as the allocated bandwidth. Even though the
結果が否定的であるなら(Mはリンクによって導入された遅れ以下です)、リンクがMが評価する保証より遅れを決して提供しないかもしれないので、最大の待ち行列サイズはゼロであるべきです。 帯域幅が高いなら(T1リンクのように)、地球のリンクと終わっている設備によって導入された遅れは、低い遅れ待ち行列の単一のデータグラムのための平均したサービス・タイムより重要であって、長いかもしれません。 そうだとすれば、この公式は、また、待ち行列サイズを減少させるのに使用されるべきです。 これが待ち行列サイズを減少させていて、割り当てられた帯域幅と同じでないことに注意してください。 the
Prue & Postel [Page 7] RFC 1046 Type-of-Service Queuing February 1988
1988年2月に列を作るサービスのPrueとポステル[7ページ]RFC1046タイプ
queue size is reduced, the chit scheme described below will give low delay requesters a chance to use the allocated bandwidth.
待ち行列サイズは減少して、以下で説明された子供計画は割り当てられた帯域幅を使用する機会を低い遅れリクエスタに与えるでしょう。
If a datagram requests multiple classes of service, only one class can be provided. For example, when both low delay and high reliability classes are requested, and if the low delay queue is full, queue the data on the high reliability queue instead. If we are able to queue the data on the low delay queue, then the datagram gets part of the high reliability service it also requested, because, once data is queued, data will not be discarded. However, the datagram will be routed as a low delay request. The same scheme is used for any other combinations of service requested. The order of selection for classes of service when more than one is requested would be low delay, high throughput, then high reliability. If a block of datagrams request multiple classes of service, it is quite possible that datagram reordering will occur. If one queue is full causing the other queue to be used for some of the data, data will be forwarded at different service rates. Requesting multiple classes of service gives the data a better chance of making it through the net because they have multiple chances of getting on a service queue. However, the datagrams pay the penalty of possible reordering and more variability in the one way transmission times.
データグラムが複数のクラスのサービスを要求するなら、1つのクラスしか提供できません。 例えば、低い遅れと高信頼性のクラスの両方が要求されたら、低い遅れ待ち行列が完全であるなら、代わりに高信頼性待ち行列に関するデータを列に並ばせてください。 私たちが低い遅れ待ち行列に関するデータを列に並ばせることができるなら、データグラムはまたそれが要求した高信頼性サービスの一部を得ます、データがいったん列に並ばせられると、データが捨てられないので。 しかしながら、データグラムは少ない遅れ要求として発送されるでしょう。 同じ計画はいかなる他の要求されたサービスの組み合わせにも使用されます。 1つ以上が要求されているとき、サービスのクラスのための選択の注文は低い遅れ、高生産性、当時の高信頼性でしょう。 1ブロックのデータグラムが複数のクラスのサービスを要求するなら、データグラム再命令が起こるのは、かなり可能です。 もう片方の待ち行列がデータのいくつかに使用されることを引き起こしながら1つの待ち行列が完全であるなら、異なったサービス率でデータを転送するでしょう。 複数のクラスのサービスを要求すると、それらにはサービス待ち行列に乗るという複数の可能性があるのでネットを通してそれを作るというより良い見込みはデータに与えられます。 しかしながら、データグラムは一方通行のトランスミッション時代に可能な再命令と、より多くの可変性の罰金を支払います。
Besides total buffer consumption, individual class of service queue sizes should be used to SQ those asking for service except as noted above.
総バッファ消費以外に、個々のクラスのサービス待ち行列サイズはシンガポール航空の便名に使用されて、サービスを求めるものに上で述べたように除かれるということであるべきです。
A request for regular class of service is handled by queuing to the high reliability or high throughput queues evenly (proportional to the service rates of queue). The low delay queue should only receive data with the low delay service type. Its queue is too small to accept other traffic.
通常のクラスのサービスを求める要求は、均等(待ち行列のサービス率に比例している)に高信頼性か高生産性待ち行列に列を作ることによって、扱われます。 低い遅れ待ち行列は低遅れサービスタイプでデータを受け取るだけであるべきです。 待ち行列は他の交通を受け入れることができないくらい小さいです。
Because of the small queue size for low delay suggested above, it is difficult for low delay service requests to consume the bandwidth allocated. To do so, low delay users must keep the small queue continuously non-empty. This is hard to do with a small queue. Traffic flow has been shown to be bursty in nature. In order for the low delay queue to be able to consume the allocated bandwidth, a count of the various types being forwarded should be kept. The service rate should increase if the actual percentage falls too low for the low delay queue. The measure of service rates would have to be smoothed over time.
上に示された低い遅れのための小さい待ち行列サイズのために、少ない遅れサービスのリクエストが割り当てられた帯域幅を消費するのは、難しいです。 そうするために、低い遅れユーザは絶え間なく非空に小さい待ち行列を保たなければなりません。 これは小さい待ち行列を処理しにくいです。 交通の流れは、現実にburstyになるように示されました。 低い遅れ待ち行列が割り当てられた帯域幅を消費できるように、進められる様々なタイプのカウントは保たれるべきです。 実際の割合が低い遅れ待ち行列のためにまた、堕落するなら、サービス率は増加するべきです。 サービス率の基準は時間がたつにつれて、整えられなければならないでしょう。
While this does sound complicated, a reasonably efficient way can be described. Every Q seconds, where Q is less than or equal to the MGD, each class gets N M P chits proportional to their allowed percentage. Send data for the low delay queue up to the number of
これが複雑に聞こえている間、かなり効率的な方法を述べることができます。 あらゆるQがQが、よりMGD以下である、N M Pの子供を彼らの許容割合に各クラスを比例させているところで後援します。 安値のための遅れが数まで列を作る送信データ
Prue & Postel [Page 8] RFC 1046 Type-of-Service Queuing February 1988
1988年2月に列を作るサービスのPrueとポステル[8ページ]RFC1046タイプ
chits it receives decrementing the chits as datagrams are sent. Next send from the high reliability queue as many as it has chits for. Finally, send from the high throughput queue. At this point, each queue gets N M P chits again. If the low delay queue does not consume all of its chits, when a low delay datagram arrives, before chit replenishment, send from the low delay queue immediately. This provides some smoothing of the actual bandwidth made available for low delay traffic. If operational experience shows that low delay requests are experiencing excessive congestion loss but still not consuming the classes allocated bandwidth, adjustments should be made. The service rates should be made larger and the queue sizes adjusted accordingly. This is more important on lower speed links where the above formula makes the queue small.
データグラムとして子供を減少させるそれが受け取る子供を送ります。 次に、高信頼性待ち行列から、それには子供がいるのと同じくらい多くが発信します。 最終的に、高生産性待ち行列から発信してください。 ここに、各待ち行列は再びN M Pの子供を得ます。 低い遅れデータグラムが届く場合低い遅れ待ち行列が子供のすべてを消費しないなら、至急、子供補給の前に、低い遅れ待ち行列から発信してください。 これは低い遅れ交通に利用可能にされた実際の帯域幅の何らかのスムージングを提供します。 運用経験が、少ない遅れ要求が過度の混雑の損失になっているのを示しますが、まだクラスを消費していないのが帯域幅を割り当てるなら、調整をするでしょうに。 サービス率をより大きくするべきでした、そして、待ち行列サイズはそれに従って、適応しました。 下側の速度リンクでは、上上の公式が待ち行列を小さくするこれは、より重要です。
What we should see during the Q seconds is that low delay data will be sent as soon as possible (as long as the volume is below the allowed percentage). Also, the tendency will be to send all the high throughput datagrams contiguously. This will give a more regular measured round trip time for bursts of datagrams. Classes of service will tend to be grouped together at each intermediate node in the route. If all of the queues with datagrams have consumed all of their allocated chits, but one or more classes with empty queues have unused chits then a percentage of these left over chits should be carried over. Divide the remaining chit counts by two (with round down), then add in the refresh chit counts. This allows a 50% carry over for the next interval. The carry over is self limiting to less than or equal to the refresh chit count. This prevents excessive build up. It provides some smoothing of the percentage allocation over time but will not allow an unused queue to build up chits indefinitely. No timer is required.
私たちがQ秒の間に見るべきであるものはできるだけ早く少ない遅れデータを送るという(ボリュームが許容割合を下回っている限り)ことです。 また、傾向はすべての高生産性データグラムを近接して送ることでしょう。 これはデータグラムの炸裂のための、より通常の測定周遊旅行時間を与えるでしょう。サービスのクラスは、ルートによるそれぞれの中間的ノードで一緒に分類される傾向があるでしょう。 データグラムによる待ち行列のすべてが彼らの割り当てられた子供のすべてを消費しましたが、空の待ち行列がある1つ以上のクラスに未使用の子供がいるなら、子供の上まで残っているこれらの割合は持ち越されるべきです。2(概数に切り下げがある)に残っている子供カウントを割ってくださいといって、次に、中で加えてください、子供カウントをリフレッシュしてください。 これは次の間隔の間、50%の先へ進めるのを許します。 先へ進めるのが自己制限である、それほど子供カウントをリフレッシュしないでください。 これは過度の体格を上に防ぎます。 それで、時間がたつにつれて、割合配分の何らかのスムージングを提供しますが、未使用の待ち行列は子供を無期限に確立しないでしょう。 タイマは全く必要ではありません。
If only a simple subset of the described algorithm is to be implemented, then low delay queuing would be the best choice. One should use a small queue. Service the queue with a high service rate but restrict the bandwidth to a small reasonable percentage of the available bandwidth. Currently, wide area networks with high traffic volumes do not provide low delay service unless low delay requests are able to preempt other traffic.
説明されたアルゴリズムの簡単な唯一の部分集合が実行されることであるなら、低い遅れの列を作りは最も良い選択でしょう。 小さい待ち行列を使用するべきです。 高いサービス率で待ち行列を修理しなさい、ただし、帯域幅を利用可能な帯域幅のわずかな妥当な百分率に制限してください。 現在、少ない遅れ要求が他の交通を先取りできないなら、高い交通量がある広域ネットワークは低い遅れサービスを提供しません。
Applicability
適用性
When the output speed and volume match the input speed and volume, queues don't get large. If the queues never grow large enough to exceed the guaranteed low delay performance, no queuing algorithm other than first in, first out, should be used.
出力速度とボリュームが入力速度とボリュームに合っている場合、待ち行列は大きくなりません。 待ち行列が保証された低遅れ性能を超えることができるくらい大きく決してならないなら、最初のコネ以外のどんな最初に出ている待ち行列アルゴリズムも使用するべきではありません。
The algorithm could be turned on when the main queue size exceeds a certain threshold. The routing node can periodically check for queue
主な待ち行列サイズが、ある敷居を超えているとき、アルゴリズムをつけることができました。 ルーティングノードは待ち行列がないかどうか定期的にチェックできます。
Prue & Postel [Page 9] RFC 1046 Type-of-Service Queuing February 1988
1988年2月に列を作るサービスのPrueとポステル[9ページ]RFC1046タイプ
build up. This queuing algorithm can be turned on when the maximum delays will exceed the allowed nodal delay for low delay class of service. It can also be turned off when queue sizes are no longer a problem.
増してください。 最大の遅れが低遅れのクラスのサービスのために許容こぶのような遅れを超えるとき、この待ち行列アルゴリズムをつけることができます。 また、待ち行列サイズがもう問題でないときに、それをオフにすることができます。
Issues
問題
Several issues need to be addressed before type of service queuing as described should be implemented. What percentage of the bandwidth should each class of service consume assuming an infinite supply of each class of service datagrams? What maximum delay (MGD) should be guaranteed per node for low delay datagrams?
いくつかの問題が、サービスが説明されるように列を作るタイプが実行されるべき前に記述される必要があります。 それぞれのクラスのサービスは、それぞれのクラスのサービスデータグラムの無限の供給を仮定しながら、帯域幅の何パーセントを消費するべきですか? どんな最大の遅れ(MGD)が低い遅れデータグラムのためにノード単位で保証されるべきですか?
It is possible to provide a more optimal route if the queue sizes for each class of service are considered in the routing decision. This, however, adds additional overhead and complexity to each routing node. This may be an unacceptable additional complexity.
それぞれのクラスのサービスのための待ち行列サイズがルーティング決定で考えられるなら、より最適のルートを提供するのは可能です。 しかしながら、これは追加オーバーヘッドと複雑さをそれぞれのルーティングノードに追加します。 これは容認できない追加複雑さであるかもしれません。
How are we going to limit the use of more desirable classes of service and higher priorities? The algorithm limits use of the various classes by restricting queue sizes especially the low delay queue size. This helps but it seems likely we will want to instrument the number of datagrams requesting each Type-of-Service and priority. When a datagram requests multiple classes of service, increment the instrumentation count once based upon the queue actually used, selecting, low delay, high throughput, high reliability, then regular. If instrumentation reveals an excessive imbalance, Internet operations can give this to administrators to handle. This instrumentation will show the distribution for types of service requested by the Internet users. This information can be used to tune the Internet to service the user demands.
私たちはどのようにより望ましいクラスのサービスと、より高いプライオリティの使用を制限するつもりですか? 限界が使用する待ち行列を制限するのによる様々なクラスのアルゴリズムは特に低遅れ待ち行列サイズを大きさで分けます。 これは助けますが、それは私たちが、データグラムの数に各サービスのTypeと優先権を要求して欲しいと器具と思うつもりであるのがありそうに見えます。 データグラムが複数のクラスのサービスを要求するときには、次に、通常の状態でかつて実際に使用される待ち行列、選択に基づいている計装カウント、低い遅れ、高生産性、高信頼性を増加してください。 計装が極端な不均衡を明らかにするなら、インターネット操作は扱う管理者にこれを与えることができます。 この計装はインターネットユーザによって要求されたサービスのタイプのために分配を示すでしょう。 ユーザが要求するサービスにインターネットを調整するのにこの情報を使用できます。
Will the routing algorithms in use today have problems when routing data with this algorithm? Simulation tests need to be done to model how the Internet will react. If, for example, an application requests multiple classes of service, round trip times may fluctuate significantly. Would TCP have to be more sophisticated in its round trip time estimator?
今日このアルゴリズムでデータを発送するとき、使用中のルーティング・アルゴリズムには、問題があるでしょうか? シミュレーションテストは、インターネットがどう反応するかをモデル化するためにする必要があります。 例えば、アプリケーションが複数のクラスのサービスを要求するなら、周遊旅行時間はかなり変動するかもしれません。 周遊旅行時間見積り人では、TCPは、より高性能でなければならないでしょうか?
An objection to this type of queuing algorithm is that it is making the routing and queuing more complicated. There is current interest in high speed packet switches which have very little protocol overhead when handling/routing packets. This algorithm complicates not simplifies the protocol. The bandwidth being made available is increasing. More T1 (1.5 Mbps) and higher speed links are being used all the time. However, in the history of communications, it seems that the demand for bandwidth has always exceeded the supply. When there is wide spread use of optical fiber we may temporarily
このタイプの待ち行列アルゴリズムへの異論はそれでルーティングと列を作りをさらに複雑にしているということです。 パケットを扱うか、または発送するときほとんどプロトコルオーバーヘッドを持っていない高速パケット交換機への現在の関心があります。 このアルゴリズムが複雑にする、プロトコルを簡素化しません。 利用可能にされる帯域幅は増加しています。 絶えず、より多くのT1(1.5Mbps)と、より高い速度リンクは使用された状態です。 しかしながら、コミュニケーションの歴史では、帯域幅の要求がいつも供給を超えていたように思えます。 私たちが一時そうするかもしれない光ファイバの広い普及の使用があるとき
Prue & Postel [Page 10] RFC 1046 Type-of-Service Queuing February 1988
1988年2月に列を作るサービスのPrueとポステル[10ページ]RFC1046タイプ
experience a glut of capacity. As soon as 1 gigabit optical fiber link becomes reasonably priced, new applications will be created to consume it all. A single full motion high resolution color image system can consume, as an upper limit, nearly a gigabit per second channel (30 fps X 24 b/pixel X 1024 X 1024 pixels).
容量の十分な供給を経験してください。 1個のギガビット光ファイバリンクが合理的に値を付けられるようになるとすぐに、新しいアプリケーションは、それを皆、消費するために作成されるでしょう。 ただ一つのフルモーション高画質カラーイメージシステムは上限としておよそ2番目のチャンネル(30fps X24b/画素X1024X1024画素)あたり1つのギガビットを消費できます。
In the study of one gateway, Dave Clark discovered that the per datagram processing of the IP header constituted about 20% of the processing time. Much of the time per datagram was spent on restarting input, starting output and queuing datagrams. He thought that a small additional amount of processing to support Type-of- Service would be reasonable. He suggests that even if the code does slow the gateway down, we need to see if TOS is good for anything, so this experiment is valuable. To support the new high speed communications of the near future, Dave wants to see switches which will run one to two orders of magnitude faster. This can not be done by trimming a few instructions here or there.
1門の研究では、デーブ・クラークはそれを発見しました。IPヘッダーのデータグラム処理単位で処理時間のおよそ20%構成されています。 多くの1データグラムあたりの現代は出力を始動して、データグラムを列に並ばせて、入力された再開であることに費やされました。彼が、そのa少追加量の処理がTypeを支持すると考えた、-、-サービスは手頃でしょう。 彼が、コードがゲートウェイを減速させても、私たちが、何かに、TOSが良いかどうかを見る必要を提案するので、この実験は貴重です。 近い将来に関する新記録速度コミュニケーションを支持するために、デーヴは1〜2桁より速く動くスイッチを見たがっています。 そこでここでいくつかの指示を整えることによって、これができません。
From a practical perspective, the problem this algorithm is trying to solve is the lack of low delay service through the Internet today. Implementing only the low delay queuing portion of this algorithm would allow the Internet to provide a class of service it otherwise could not provide. Requesters of this class of service would not get it for free. Low delay class of datagram streams get low delay at the cost of reliability and throughput.
実用的な見解から、今日、このアルゴリズムが解決しようとしている問題は低くインターネットを通した遅れサービスの不足です。 このアルゴリズムの低い遅れ列を作り部分だけを実行するのに、インターネットはそれが別の方法で提供できなかったサービスのクラスを提供できるでしょう。 このクラスのサービスのリクエスタはただでそれを得ないでしょう。 低遅れ種類のデータグラムストリームは信頼性とスループットの費用で低い遅れを得ます。
Prue & Postel [Page 11]
Prueとポステル[11ページ]
一覧
スポンサーリンク
