RFC1193 日本語訳
1193 Client requirements for real-time communication services. D.Ferrari. November 1990. (Format: TXT=61540 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Ferrari
Request for Comments: 1193 UC Berkeley
November 1990
コメントを求めるワーキンググループD.フェラーリ要求をネットワークでつないでください: 1193 UCバークレー1990年11月
CLIENT REQUIREMENTS FOR REAL-TIME COMMUNICATION SERVICES
リアルタイムの通信サービスのためのクライアント要件
Status of this Memo
このMemoの状態
This memo describes client requirements for real-time communication services. This memo provides information for the Internet community, and requests discussion and suggestions for improvements. It does not specify any standard. Distribution of this memo is unlimited.
このメモはリアルタイムの通信サービスのためのクライアント要件について説明します。 このメモはインターネットコミュニティ、要求議論、および提案のための情報を改良に提供します。 それはどんな規格も指定しません。 このメモの分配は無制限です。
Abstract
要約
A real-time communication service provides its clients with the ability to specify their performance requirements and to obtain guarantees about the satisfaction of those requirements. In this paper, we propose a set of performance specifications that seem appropriate for such services; they include various types of delay bounds, throughput bounds, and reliability bounds. We also describe other requirements and desirable properties from a client's viewpoint, and the ways in which each requirement is to be translated to make it suitable for lower levels in the protocol hierarchy. Finally, we present some examples of requirements specification, and discuss some of the possible objections to our approach.
瞬時通信サービスは彼らの性能要件を指定して、それらの要件の満足に関して保証を得る能力をクライアントに提供します。 この紙では、私たちはそのようなサービスに適切に見える性能仕様一式を提案します。 彼らは様々なタイプの遅れ領域、スループット領域、および信頼性の領域を含んでいます。 また、私たちはクライアントの観点、およびそれをプロトコル階層で下のレベルに適するようにするように翻訳される各要件がことである方法から他の要件と望ましい特性について説明します。 最終的に、私たちは、要件仕様に関するいくつかの例を提示して、可能な反論のいくつかについてアプローチと議論します。
This research has been supported in part by AT&T Bell Laboratories, the University of California under a MICRO grant, and the International Computer Science Institute. The views and conclusions in this document are those of the author and should not be interpreted as representing official policies, either expressed or implied, of any of the sponsoring organizations.
この研究はAT&Tベル研究所、MICRO交付金の下におけるカリフォルニア大学、および国際電子計算機科学協会によって一部サポートされました。 視点と結論を本書では作者のものであり、言い表されるか、または含意された公式方針を表しながら、後援組織のいずれについても解釈するべきではありません。
1. Introduction
1. 序論
We call real-time a computer communication service whose clients are allowed to specify their performance requirements and to obtain guarantees about the fulfillment of those requirements.
私たちは、リアルタイムのaをクライアントが彼らの性能要件を指定して、それらの要件の遂行に関して保証を得ることができるコンピュータ通信サービスと呼びます。
Three terms in this definition need further discussion and clarification: clients, performance, and guarantees.
この定義における3つの用語がさらなる議論と明確化を必要とします: クライアント、性能、および保証。
Network architecture usually consists, at least from a logical viewpoint, of a stack of protocol layers. In the context of such an architecture, the notions of client and server apply to a number of
通常、ネットワークアーキテクチャは少なくとも論理的な観点からプロトコル層のスタックから成ります。 アーキテクチャ、クライアントの概念、およびサーバが数に当てはまるそのようなものの文脈で
Ferrari [Page 1] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[1ページ]RFC1193要件
different pairs of entities: every layer (with the support of the underlying layers) provides a service to the layer immediately above it and is a client of its underlying layers. In this paper, our considerations generally apply to any client-server pair. However, most of them particularly refer to human clients (users, programmers) and to the ways in which such clients express their communication and processing needs to the system (e.g., interactive commands, application programs). This type of client is especially important, since client needs at lower layers can be regarded as translations of the needs expressed by human clients at the top of the hierarchy. When the client is human, the server consists of the entire (distributed) system, including the hosts, their operating systems, and the networks interconnecting them.
異なった組の実体: あらゆる層(下位層のサポートがある)が、それのすぐ上に層に対するサービスを提供して、下位層のクライアントです。 一般に、この紙では、私たちの問題はどんなクライアント/サーバ組にも適用されます。 しかしながら、彼らの大部分は特に、人間のクライアント(ユーザ、プログラマ)とそのようなクライアントが彼らのコミュニケーションと処理の必要性をシステムに述べる方法を参照します(例えばインタラクティブは命令します、アプリケーション・プログラム)。 このタイプのクライアントは特に重要です、必要性に関する翻訳が階層構造の最上部の人間のクライアントで言い表したように下層におけるクライアントの必要性を見なすことができるので。 クライアントが人間であるときに、サーバは全体(分配された)のシステムから成ります、ホスト、彼らのオペレーティングシステム、およびそれらとインタコネクトするネットワークを含んでいて。
As for the generic term, performance, we will give it a fairly broad meaning. It will include not only delay and throughput, the two main network performance indices, but also reliability of message delivery. Real-time communication is concerned with those aspects of quality of service that have to do with performance in this broad sense.
総称、性能に関して、私たちはかなり広い意味をそれに与えるつもりです。 それは遅れだけとスループット、2つの主なネットワーク性能インデックスリスト、しかし、メッセージ配送のどんな信頼性も含まないでしょう。 瞬時通信はこの広い意味における性能と関係があるサービスの質のそれらの局面に関係があります。
The term guarantee in this paper has a rather strong legal flavor. When a server guarantees a given level of performance for the communications of a client, it commits itself to providing that performance and to paying appropriate penalties if the actual performance turns out to be insufficient. On the other hand, the client will have to obey certain rules, and will not be entitled to the requested performance guarantees unless those rules are scrupulously obeyed. In other words, client and server have to enter into a contract specifying their respective rights and duties, the benefits that will accrue, the conditions under which those benefits will materialize, and the penalties they will incur for not keeping their mutual promises. We believe that a legal viewpoint is to be adopted if serious progress in the delivery of communication services (not only the real-time ones) is desired. Utility services, as well as other kinds of service, are provided under legally binding contracts, and a mature computer communication utility cannot fail to do the same. In the field of real-time communication, such a contract will by definition include performance guarantees.
この紙における用語保証には、かなり強い法的な風味があります。 サーバがクライアントのコミュニケーションのために与えられた技量を保証するとき、実績が不十分であると判明するなら、それは、性能であって賃金に刑罰を当てるために立場を明らかにします。 他方では、クライアントは、ある規則に従わなければならなくて、それらの規則がきちんと従われない場合、要求された契約履行保証の権利を与えられないでしょう。 言い換えれば、クライアントとサーバはそれらのそれぞれの権利と義務、生じる利益、それらの利益が具体化する状態、およびそれらが彼らの相互約束を守らないように被る刑罰を指定する契約に入らなければなりません。 私たちは、法的な観点が通信サービス(リアルタイムでないものだけ)の配送における重大な進歩が望まれているなら採用されることであると信じています。 法的に拘束力がある契約に基づき共用サービス、および他の種類のサービスを提供します、そして、熟しているコンピュータコミュニケーションユーティリティは必ず同じようにできます。 瞬時通信の分野では、そのような契約が定義上契約履行保証を含むでしょう。
Real-time services may be offered in any kind of network or internetwork. Some of their predictable applications are:
どんな種類のネットワークかインターネットワークでもリアルタイムのサービスを提供するかもしれません。 彼らの予測できるアプリケーションのいくつかは以下の通りです。
(a) digital continuous-media (motion video, audio)
communication: lower bounds on throughput and upper bounds
on delay or delay variability or both are needed to ensure
any desired level of output quality; in the interactive case,
both the values of delay and delay variabilities have to be
(a) デジタル連続したメディア(動画ビデオ、オーディオ)コミュニケーション: スループットにおける下界と遅れ、遅れの可変性または両方の上限がどんな必要なレベルの出力品質も確実にするのに必要です。 ケース、遅れの値と遅れの可変性の両方がインタラクティブでなければならないことで
Ferrari [Page 2] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[2ページ]RFC1193要件
bounded; some limited message losses are often tolerable in
the cases of video and voice (whenever very high quality is
not required), but usually not in the case of sound;
バウンドしています。 いくつかの限られたメッセージの損失がビデオと声(非常に高い品質は必要でないときはいつも)に関するケースにもかかわらず、通常、音のいずれの場合でもしばしば許容できるというわけではありません。
(b) transmission of urgent messages in real-time distributed
systems: delay bounds are the important guarantees to be
provided in these applications; losses should ideally be
impossible;
(b) リアルタイムの分散システムにおける、急報の送信: 遅れ領域はこれらのアプリケーションに提供される重要な保証です。 損失は理想的に不可能であるべきです。
(c) urgent electronic-mail messages and, more in general,
urgent datagrams: again, delay is the obvious index to be
bounded in this case, but small probabilities of losses can
often be tolerated;
(c) 緊急の電子メールメッセージとさらに一般に緊急のデータグラム: 一方、遅れはこの場合境界がある明白なインデックスですが、しばしば損失のわずかな確率を許容できます。
(d) transfers of large files: minimum throughput bounds are
usually more important than delay bounds in this
application; also, all pieces of a file must be delivered
with probability 1;
(d) 大きいファイルの転送: 通常、最小のスループット領域はこのアプリケーションにおける遅れ領域より重要です。 また、確率1でファイルのすべての断片を提供しなければなりません。
(e) fast request-reply communication: e.g., data base queries,
information retrieval requests, remote procedure calls; this
is another case in which delay (more precisely, round-trip
delay) is the index of primary interest; reliability
requirements are generally not very stringent.
(e) 速い要求回答コミュニケーション: 例えば、データは質問、情報検索要求、遠隔手続き呼び出しを基礎づけます。 これが中の別のそうである、(延着します)(より正確である、往復の遅れ) 主要に関心のインデックスです。 一般に、信頼度要求事項はそれほど厳しくはありません。
We conjecture that, when networks start offering well-designed and reasonably-priced real-time services, the use of such services will grow beyond the expectations of most observers. This will occur primarily because new performance needs will be induced by the availability of guaranteed-performance options. As the history of transportation and communication has repeatedly shown, faster services bring about major increases of the shipments that are perceived as urgent. The phenomenon will be more conspicuous whenever the quality of service provided to non-real-time clients will deteriorate. It is clear from this comment that we assume that real-time services will coexist within the same networks and internetworks with non-real-time communications. Indeed, postulating a world in which the two types of service are segregated rather than integrated would be unrealistic, as it would go against the clear trend towards the eventual integration of all information services. For the same reason, the traffic in the network is assumed to be heterogeneous, i.e., to consist of a variety of types of messages, representing a variety of information media and their combinations, with a wide spectrum of burstiness values (from uncompressed continuous fixed-rate streams to very short and erratic bursts of information).
私たちは、ネットワークがよく設計されて合理的に値を付けられたリアルタイムのサービスを提供し始めるとそのようなサービスの使用がほとんどの観察者への期待を超えて成長すると推測します。 主として新たな性能の必要性が保証値オプションの有用性によって引き起こされるので、これは起こるでしょう。 輸送とコミュニケーションの歴史が繰り返して示したように、より速いサービスは緊急であるとして知覚される出荷の主要な増加を引き起こします。 非リアルタイムのクライアントに提供されたサービスの質が悪化するときはいつも、現象は、より目立つでしょう。 このコメントによって、私たちが、リアルタイムのサービスが非瞬時通信がある同じネットワークとインターネットワークの中に共存すると思うのは、明確です。 本当に、統合しているというよりむしろ2つのタイプのサービスが隔離されている世界を仮定するのは非現実的でしょう、すべての情報サービスの最後の統合に向かって明確な傾向に反するだろうというとき。 同じ理由から、さまざまなタイプに関するメッセージから成るようにすなわち、ネットワークにおけるトラフィックが異種であると思われます、さまざまな情報媒体と彼らの組み合わせを代表して、burstiness値(解凍された連続した定率ストリームから非常に短くて不安定な情報の炸裂までの)の広いスペクトルで。
This paper discusses the client requirements and characteristics of a
この論文はaのクライアント要件と特性について議論します。
Ferrari [Page 3] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[3ページ]RFC1193要件
real-time communication service. Server requirements and design principles will be the subject of a subsequent paper. Section 2 contains some considerations about the ways in which the clients specify their requirements, and those in which a server should reply to requests for real-time services. Performance requirements are presented in Section 3; other properties that clients may need or desire are described in Section 4. Section 5 deals with the problem of translating the requirements of a human client or an application for the equivalent lower-level ones. In Section 6, we briefly present four examples of client requirement specifications, and in Section 7 we discuss some of the objections that can be raised against our approach.
瞬時通信サービス。 サーバ要件と設計原理はその後の論文の対象になるでしょう。 セクション2はクライアントが彼らの要件を指定する方法、およびサーバが本当の時間指定サービスを求める要求に答えるべきであるそれらに関するいくつかの問題を含みます。 パフォーマンス要件はセクション3に提示されます。 クライアントが必要とするかもしれない他の特性か願望がセクション4で説明されます。 セクション5は人間のクライアントの要件を翻訳するという問題か同等な低レベルもののアプリケーションに対処します。 セクション6では、私たちは簡潔にクライアント要件仕様に関する4つの例を提示します、そして、セクション7では、私たちのアプローチに対して上げることができる反論のいくつかについて議論します。
2. Client Requests and Server Replies
2. クライアント要求とサーバ回答
No real-time service can be provided if the client does not specify, together with the requirements, the characteristics of the expected input traffic. Describing input traffic and all the various requirements entails much work on the part of a client. Gathering the necessary information and inputting it may be very time- consuming. A well-designed real-time communication service will minimize the effort to be spent by a client.
クライアントが指定しないなら、どんなリアルタイムのサービスも提供できません、要件と共に、予想された入力トラフィックの特性。 入力トラフィックとすべての様々な要件について説明すると、多くの仕事がクライアント側の伴われます。 必要事項を集めて、それを入力するのは、まさしくその時間消費であるかもしれません。 クライアントによって費やされるように、よく設計された瞬時通信サービスは取り組みを最小にするでしょう。
Sensible default values, the possibility of partial or incremental specifications (e.g., by editing preexisting specifications), and a number of standard descriptions should be provided. These descriptions will include characterizations of inputs (e.g., those of a video stream for multimedia conferencing, an HDTV stream, a hi-fi audio stream, a file transfer stream, and so on) and standard sets of requirements. With these aids, it might be possible for a human client to specify his or her request by a short phrase, perhaps followed by a few characters representing options or changes to the standard or default values.
実際的なデフォルト値値、部分的であるか増加の仕様(例えば、先在の仕様を編集するのによる)の可能性、および多くの標準の記述を提供するべきです。 これらの記述は入力(例えば、マルチメディア会議のためのビデオストリーム、HDTVストリーム、ハイファイのオーディオストリーム、ファイル転送ストリームなどのもの)の特殊化と要件の標準セットを含むでしょう。 これらの援助によると、それは、人間のクライアントが短い句でその人の要求を指定するのにおいて可能であるかもしれないか、恐らくオプションを表すいくつかのキャラクタで続くか、または規格かデフォルト値に変化します。
Since requests for real-time services may be denied because of a mismatch between the client's demands and the resources available to the server, the client will appreciate being informed about the reasons for any rejection, so that the request can be modified and resubmitted, or postponed, or cancelled altogether [Herr89]. The information provided by the server to a human client should be meaningful, useful, and non-redundant. The reason for rejection should be understandable by the client (who should be assumed not to know any of the details of the operating system, of the protocols or of the network) and should be accompanied by data that will be useful to the client in deciding what to do as well as how the request ought to be modified to make it successful. If, for example, a bound specified by the client cannot be guaranteed by the server under its current load, the information returned to the client should include
本当の時間指定サービスを求める要求がクライアントの要求とサーバに利用可能なリソースの間のミスマッチのために否定されるかもしれないので、クライアントは、どんな拒絶の理由に関しても知識があるのに感謝するでしょう、要求を全体で変更されて、再提出するか、延期されるか、または中止できる[Herr89]ように。 サーバによって人間のクライアントに提供された情報は、重要で、役に立って、非余分であるべきです。 不合格理由は、クライアント(オペレーティングシステム、プロトコルまたはネットワークの細部のいずれも知らないと思われるべきである)を理解できさせるべきであり、何をするか、そして、要求がそれをうまくいくようにするようにどのように変更されるべきであるかを決める際にクライアントの役に立つデータによって伴われるべきです。 例えば、現在の負荷の下でサーバでクライアントによって指定されたバウンドを保証できないなら、クライアントに返された情報は包含するべきです。
Ferrari [Page 4] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[4ページ]RFC1193要件
the minimum or maximum value of the bound that the server could guarantee; the client will thus be able to decide whether that bound would be acceptable (possibly with some other modifications as well) or not, and act accordingly.
サーバが保証できたバウンドの最小の、または、最大の値。 クライアントは、それが付いたかどうかが、許容できると(ことによるとまた、ある他の変更がある)決めて、その結果、善処できるでしょう。
When the client is not a human being but an application or a process, the type of a server's replies should be very different from that just described [Herr89]; another standard interface, the one between an application and a real-time service, must therefore be defined, possibly in multiple, application-specific versions.
いつ、クライアントが人間ではなく、アプリケーションであるか、そして、プロセス、サーバの回答のタイプはただ説明されたそれ[Herr89]と非常に異なっているべきです。 したがって、別の標準インターフェース(アプリケーションとリアルタイムのサービスの間のもの)を定義しなければなりません、ことによると複数の、そして、アプリケーション特有のバージョンで。
Clients will also be interested in the pricing policies implemented by the server: these should be fair (or at least perceived to be fair) and easy to understand. The client should be able easily to estimate charges for given performance guarantees as a function of distance, time of day, and other variables, or to obtain these estimates from the server as a free off-line service.
また、クライアントはサーバによって実装された価格決定方針に興味を持つでしょう: これらは、公正であって(または、公正であると少なくとも知覚されます)、分かり易いはずです。 クライアントは、距離、時刻、および他の変数の関数として与えられた契約履行保証のための充電を見積もっているか、または無料のオフラインサービスとしてサーバからこれらの見積りを得るために容易にできるべきです。
3. Performance Requirements
3. パフォーマンス要件
A client can specify a service requirement using the general form
クライアントは、一般的なフォームを使用することでサービス要件を指定できます。
pred = TRUE,
predはTRUEと等しいです。
where some of the variables in predicate pred can be controlled or influenced by the server.
サーバで述部predの変数のいくつかに制御するか、または影響を及ぼすことができるところ。
A simple and popular form of performance requirement is that involving a bound. A deterministic bound can be specified as
簡単でポピュラーなフォームの性能要件はそんなに意味ありげなバウンドです。 決定論的なバウンドとして、指定できます。
(var <= bound) = TRUE, or var <= bound,
(var<=は固まりました) =TRUE、またはvar<がバウンドと等しいです。
where variable var is server-controlled, while bound is client- specified. The bounds in these expressions are upper bounds; if < is replaced by > , they become lower bounds.
可変であるところでは、varがサーバによって制御されていますが、バウンドは指定されたクライアントです。 これらの式における領域は上限です。 <を>に取り替えるなら、それらは下界になります。
When the variable in the latter expression above is a probability, we have a statistical bound, and bound in that case is a probability bound; if the predicate is a deterministic bound, we have:
上の後者の式における変数が確率であるときに、私たちには、統計的なバウンドがあります、そして、その場合縛られているのは、確率バウンドです。 述部が決定論的なバウンドであるなら、私たちには以下があります。
Prob (var <= bound) >= probability-bound.
Prob、(var<はバウンド) >=と確率行きであることで等しいです。
In this requirement, the variable has an upper bound, and the probability a lower bound. Note that deterministic bounds can be viewed as statistical bounds that are satisfied with probability 1.
この要件では、変数には上限があって、確率は下界を持っています。 確率1に満たされている統計的な領域として決定論的な領域を見なすことができることに注意してください。
A form of bound very similar to the statistical one is the fractional bound:
統計的なものと非常に同様のバウンドのフォームは断片的なバウンドです:
Ferrari [Page 5] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[5ページ]RFC1193要件
Ca (var <= bound) >= b,
Ca(var<=は固まった)>はbと等しいです。
where variable var has a value for each message in a stream, and Ca is a function that counts the number of times var satisfies the bound for any a consecutive messages in the stream; this number Ca must satisfy bound b. Obviously, a fractional bound is realizable only if b <= a . Fractional bounds will not be explicitly mentioned in the sequel, but they can be used in lieu of statistical bounds, and have over these bounds the avantages of easy verifiability and higher practical interest.
可変であるところでは、varが絶え間なく各メッセージのための値を持っています、そして、Caがvarがストリームにおけるどんなa連続したメッセージのためのバウンドも満たす回数を数える機能です。 Caが満たさなければならないこの数はbを縛りました。 . 断片的なb<=領域が続編で明らかに言及されない場合にだけ明らかに、断片的なバウンドが実現可能ですが、それらは、統計的な領域の代わりに使用されて、これらの領域の上に簡単な検証可能性の、そして、より高く実用的な関心のavantagesを持つことができます。
In this section, we restrict our attention to those requirements that are likely to be the most useful to real-time clients.
このセクションでは、私たちは留意をそれらの傾向がある中でリアルタイムのクライアントにものである最も役に立つ要件に制限します。
3.1 Delay requirements
3.1 遅れ要件
Depending on the application, clients may wish to specify their delay requirements in different ways [Gait90]. The delays involved will usually be those of the application-oriented messages known to the client; for instance, the delay between the beginning of the client- level transmission of a video frame, file, or urgent datagram and the end of the client-level reception of the same frame, file, or urgent datagram. (In those cases, e.g., in some distributed real-time systems, where message deadlines are assigned instead of message delays, we can always compute the latter from knowledge of the former and of the sending times, thereby reducing ourselves again to a delay bound requirement.) Also, they will be the delays of those messages that are successfully delivered to the destination; the fraction of messages that are not, to which the delay bounds will not apply, will be bounded by reliability specifications. Note that clients will express delay bounds by making implicit reference to their own clocks; the design of a real-time service for a large network will have to consider the impact on bounds enforcement of non-synchronized clocks [Verm90]. Some of the forms in which a delay requirement may be specified are
アプリケーションによって、クライアントは異なった方法[Gait90]で彼らの遅れ要件を指定したがっているかもしれません。 通常、かかわった遅れはクライアントにとって知られているアプリケーション指向のメッセージのものになるでしょう。 例えば、ビデオフレーム、ファイル、または緊急のデータグラムのクライアントレベル送信の始まりと同じフレーム、ファイル、または緊急のデータグラムのクライアントレベルレセプションの終わりの間の遅れ。 (それらのケース、例えば、メッセージの締め切りがメッセージ遅延の代わりに割り当てられるいくつかの分配されたリアルタイムのシステムでは、私たちは前者と送付現代に関する知識から後者をいつも計算できます、その結果、再び遅れの制限された要件に自分達を減少させます。) また、首尾よく送付先に届けられるそれらのメッセージの遅れになるでしょう。 遅れ領域が適用しないものにはないということであるメッセージの部分は信頼性の仕様でバウンドしました。 クライアントがそれら自身のの暗黙の参照を時計にすることによって遅れ領域を言い表すことに注意してください。 大きいネットワークのためのリアルタイムでサービスのデザインは非連動することの実施が時間を計る領域[Verm90]への影響を考えなければならないでしょう。 遅れ要件が指定されるかもしれないフォームのいくつかがそうです。
(i) deterministic delay bound:
(i) 決定論的な遅れは付きました:
Di <= Dmax for all i,
ディ<はすべてのiのためにDmaxと等しいです。
the client is delivered to the destination client-level entity, and Dmax is the delay upper bound specified by the client. In our descriptions we assume, without loss of generality, that the client requesting a real-time service is the sending client, and that the destination (which could be a remote agent of the client or another user) is a third party with respect to the establishment of the particular communication being considered (In our descriptions we assume, without loss of generality, that the client requesting a
目的地クライアントレベル実体にクライアントを渡します、そして、Dmaxはクライアントによって指定された遅れ上限です。 記述では、私たちが一般性の喪失なしでリアルタイムのサービスを要求するクライアントが送付クライアントであり、考えられて、目的地(クライアントか別のユーザのリモートエージェントであるかもしれない)が特定のコミュニケーションの確立に関する第三者であると思う、(記述では、私たちは、一般性の喪失なしでそれがaを要求するクライアントであると思います。
Ferrari [Page 6] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[6ページ]RFC1193要件
real-time service is the sending client, and that the destination (which could be a remote agent of the client or another user) is a third party with respect to the establishment of the particular communication being considered.);
リアルタイムのサービスは送付クライアントであり、それは目的地(どれがクライアントのリモートエージェントであるかもしれないか、そして、別のユーザ) 特定のコミュニケーションの確立に関する第三者は考えられますか?)です。
(ii) statistical delay bound:
(ii)統計的な遅れは付きました:
Prob ( Di <= Dmax ) >= Zmin,
Prob(ディ<はDmaxと等しい)>はZminと等しいです。
where Di and Dmax are defined as above, and Zmin is the lower
bound of the probability of successful and timely delivery;
ダイアナとDmaxが同じくらい上で定義されて、Zminがうまくいっていてタイムリーな配送の確率の下界であるところ。
(iii) deterministic delay-jitter bound:
(iii)決定論的な遅れジターは付きました:
Ji = | Di - D | <= Jmax for all i,
Ji=| ダイアナ--D| <= すべてのiのためのJmax
where D is the ideal, or target delay, Ji is the delay jitter of
the i-th message delivered to the destination, and Jmax is the
upper jitter bound to be specified by the client together with D;
note that an equivalent form of this requirement consists of
assigning a deterministic upper bound D + Jmax and a deterministic
lower bound D - Jmax to the delays Di [Herr90];
Dが理想であるか目標遅れ、Jiが遅れジターであるところ、i、-、第メッセージは送付先に配送されました、そして、JmaxはDと共にクライアントによって指定されるべき上側のジターバウンドです。 この要件の同等なフォームがD+Jmaxと決定論的な下界Dを決定論的な上限に割り当てるのから成ることに注意してください--遅れダイアナ[Herr90]へのJmax
(iv) statistical delay-jitter bound:
(iv)統計的な遅れジターは付きました:
Prob (Ji <= Jmax) >= Umin, for all i,
すべてのiのためのProb(Ji<はJmaxと等しい)>=Umin
where Umin is the lower bound of the probability that Ji be
within its limits.
Uminが確率の下界であるところでは、そのJiは限界の中のそうです。
Other forms of delay bound include bounds on average delay, delay variance, and functions of the sequence number of each message, for example, Dmax(i) for the deterministic case. There may be applications in which one of these will be the preferred form, but, since we have not found any so far, we believe that the four types of bounds listed as (i)-(iv) above will cover the great majority of the practical cases.
他の形式の遅れバウンドはそれぞれのメッセージの一連番号、例えば、決定論的なケースのためのDmax(i)の平均遅れ、遅れ変化、および機能の領域を含んでいます。 私たちは、4つのタイプの領域が(i)として記載したと信じています--これらのどれが好まれた形になるかに利用があるかもしれませんが、私たちが今までのところのいずれも見つけていないので、上の(iv)は実用的なケースの大多数をカバーするでしょう。
3.2 Throughput requirements
3.2 スループット要件
The actual throughput of an information transfer from a source to a destination is bounded above by the rate at which the source sends messages into the system. Throughput may be lower than this rate because of the possibility of unsuccessful delivery or message loss. It is also bounded above by the maximum throughput, which is a function of, among other things, network load. As the source increases its input rate, the actual throughput will grow up to a limit and then stop. Clients concerned with the throughput of their
ソースから目的地までの情報転送の実際のスループットはソースがメッセージをシステムに送るレートに従って上であることで境界があります。 スループットは失敗の配送かメッセージの損失の可能性のためにこのレートより低いかもしれません。 また、それも最大のスループットに従って上であることで境界があります。(スループットは特にネットワーク負荷の機能です)。 ソースが入力率を増加させるのに従って、実際のスループットは、限界まで成長して、次に、止まるでしょう。 クライアントはスループットに関係があった、彼ら
Ferrari [Page 7] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[7ページ]RFC1193要件
transfers will want to make sure that saturation is never reached, or is reached only with a suitably small probability and for acceptably short intervals. Also, if the bandwidth allocated to a transfer is not constant, but varies dynamically on demand to accommodate, at least to some extent, peak requests, clients will be interested in adding an average throughput requirement, which should include information about the length of the interval over which the average must be computed [Ferr89a].
転送は、飽和が決して達していないか、または適当にわずかな確率だけと許容できて短い間隔の間達しているのを確実にしたくなるでしょう。 また、転送に割り当てられた帯域幅が一定ではありませんが、少なくともある程度ピーク要求に対応するという要求のときにダイナミックに異なると、クライアントは平均したスループット要件を加えたくなるでしょう。(それは、平均を計算しなければならない間隔[Ferr89a]の長さの情報を含むべきです)。
Thus, reasonable forms for throughput requirements appear to be the following:
したがって、スループット要件のための妥当なフォームは以下であるように見えます:
(i) deterministic throughput bound:
(i) 決定論的なスループットは付きました:
Ti >= Tmin, for all i,
すべてのiのためのTi>=Tmin
where Ti is the throughput actually provided by the server, and
Tmin is the lower bound of throughput specified by the client,
that is, the minimum throughput the server must offer to the
client;
Tiが実際にサーバによって提供されたスループットであり、Tminがクライアントによって指定されたスループットの下界であるところでは、すなわち、サーバがクライアントに提供しなければならない最小のスループットです。
(ii) statistical throughput bound:
(ii)統計的なスループットは付きました:
Prob (Ti >= Tmin) >= Vmin,
Prob(Ti>はTminと等しい)>はVminと等しいです。
where Ti and Tmin are defined as above, and Vmin is the lower
bound of the probability that the server will provide a throughput
greater than the lower bound;
TiとTminが同じくらい上で定義されて、Vminがサーバが下界より大きいスループットを提供するという確率の下界であるところ。
(iii) average throughput bound:
(iii)平均したスループットは付きました:
T >= Tave,
T>はテーヴと等しいです。
where T is the average throughput provided by the server, Tave is
its lower bound specified by the client, and both variables are
averaged over an interval of duration I specified by the client;
the above inequality must obviously hold for all intervals of
duration I, i.e., even for that over which T is minimum.
テーヴがサーバによるクライアントによって指定された下界と、変数の両方であるならTがどこの平均したスループットであるかは私がクライアントで指定した持続時間の間隔の間、平均されています。 上の不平等は持続時間Iのすべての間隔の間、明らかに成立しなければなりません、すなわち、Tが最小であるそれのためにさえ。
One clear difference between delay bounds and throughput bounds is that, while the server is responsible for delays, the actual throughputs of a non-saturated system are dictated by the input rates, which are determined primarily by the clients (though they may be influenced by the server through flow-control mechanisms).
遅れ領域とスループット領域の1つの明確な違いはサーバが遅れに原因となる間非飽和したシステムの実際のスループットが入力率によって書き取られるという(彼らがフロー制御メカニズムを通してサーバによって影響を及ぼされるかもしれませんが)ことです。(率は主としてクライアントによって測定されます)。
Ferrari [Page 8] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[8ページ]RFC1193要件
3.3 Reliability requirements
3.3 信頼性の要件
The usefulness of error control via acknowledgments and retransmission in real-time applications is doubtful, especially in those environments where message losses are usually higher, i.e., in wide-area networks: the additional delays caused by acknowledgment and retransmission, and out-of-sequence delivery are likely to be intolerable in applications with stringent delay bounds, such as those having to do with continuous media. Fortunately, the loss of some of the messages (e.g., video frames, voice packets) is often tolerable in these applications, but that of sound packets is generally intolerable. In other cases, however, completeness of information delivery is essential (e.g., in file transfer applications), and traditional retransmission schemes will probably have to be employed.
リアルタイムのアプリケーションにおける承認と「再-トランスミッション」を通した誤り制御の有用性は疑わしいです、特に通常、メッセージの損失が、より高いそれらの環境で、すなわち、広域ネットワークで: 堪え難い承認と「再-トランスミッション」によって引き起こされた遅れ、および順序が狂って配送が傾向がある厳しいのがあるアプリケーションが遅らせる追加はバウンドしています、連続したメディアと関係があるものなどのように。 幸い、メッセージ(例えば、ビデオフレーム、音声パケット)のいくつかの損失はこれらのアプリケーションでしばしば許容できますが、一般に、音のパケットのものは堪え難いです。 しかしながら、他の場合では、情報送達の完全性は不可欠です、そして、(例えば、ファイル転送アプリケーションで)伝統的な「再-トランスミッション」計画はたぶん使われなければならないでしょう。
A message may be incorrect when delivered or may be lost in the network, i.e., not delivered at all. Network unreliability (due, for example, to noise) is usually the cause of the former problem; buffer overflow (due to congestion) or node or link failure are those of the latter. The client is not interested in this distinction: for the client, the message is lost in both cases. Thus, the simplest form in which a reliability bound may be expressed and also, we believe, the one that will be most popular, is
メッセージは、渡すと不正確であるかもしれないか、ネットワークで無くなる、またはすなわち、全く渡されないかもしれません。 通常、ネットワーク非信頼性(例えば雑音に当然の)は前の問題の原因です。 バッファオーバーフロー(混雑による)、ノードまたはリンクの故障が後者のものです。 クライアントはこの区別に興味を持っていません: クライアントに関しては、メッセージはどちらの場合も、失われています。 したがって、信頼性が付いた最も簡単な書式は言い表されるかもしれなくて、私たちはまた、そうするものが最もポピュラーであり、あると信じています。
Prob (message is correctly delivered) >= Wmin,
Prob(正しくメッセージを送る)>はWminと等しいです。
where Wmin is the lower bound of the probability of correct delivery, to be specified by the client. The probability of message loss will obviously be bounded above by 1 - Wmin. This is a statistical bound, but, as noted in Section 3, a deterministic reliability bound results if we set Wmin = 1.
Wminがクライアントによって指定されるためには正しい配送の確率の下界であるところ。 メッセージの損失の確率は明らかに1時までに上であることで境界があるでしょう--Wmin。 これは統計的なバウンドですが、セクション3に述べられるように、私たちがWmin=1を設定するなら、決定論的な信頼性は結果を縛りました。
In those applications in which any message delivered with a delay greater than Dmax must be discarded, the fraction of messages usable by the destination will be bounded below by Wmin Zmin. The client may actually specify the value of this product, and let the server decide the individual values of the two bounds, possibly subject to a client-assigned constraint, e.g., that the price of the service to the client be minimum.
遅れがDmaxを捨てなければならないよりすばらしい状態でどんなメッセージも果たしたそれらのアプリケーションでは、目的地で使用可能なメッセージの部分はWmin Zminによる以下であることで境界があるでしょう。 クライアントは、サーバにことによると例えば、クライアントに対するサービスの価格が最小であるというクライアントによって割り当てられた規制を条件として実際にこの製品の値を指定して、2つの領域の個人価値について決めさせるかもしれません。
If the value of Wmin is greater than the system's reliability (the probability that a delivered message is correct), then there is no buffer space allocation in the hosts, interfaces, switches and routers or gateways that will allow the client-specified Wmin to be guaranteed. In this case, the server uses error correcting codes, or (if the application permits) retransmission, or duplicate messages, or (if the sequencing problem discussed in Section 4.1 can be solved
Wminの値がシステムの信頼性(渡されたメッセージが正しいという確率)より大きいなら、バッファスペース割当てが全くクライアントによって指定されたWminが保証されるのを許容するホストかインタフェースかスイッチとルータかゲートウェイにありません。 または、この場合サーバが(アプリケーションが可能にするなら)誤り検出方式、「再-トランスミッション」、または写しメッセージを使用する、(セクション4.1で議論した配列問題は解決できます。
Ferrari [Page 9] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[9ページ]RFC1193要件
satisfactorily or is not a problem) multiple physical channels for the same logical channel, or has to refuse the request.
または、満足である、問題) 同じ論理チャネルのための複数の物理的なチャンネルでない、または要求を拒否しなければなりません。
4. Other Required or Desirable Properties
4. 他の必要であるか望ましい特性
In this section, we briefly describe client requirements that cannot be easily expressed as bounds on, but are related to, communication performance. These include sequencing, absence of duplications, failure recovery, and service setup time. We are not concerned here with features that may be very important but have a functionality (e.g., multicast capabilities) or security (e.g., client authentication) rather than a performance flavor. Requirements in these areas will generally have appreciable effects also on performance; we do not discuss them only because of space limitations.
このセクションで私たちが簡潔に、領域として容易に言い表すことができないクライアント要件について説明して、関連する、コミュニケーション性能。 これらは配列、複製の欠如、失敗回復、およびサービス準備時間を含んでいます。 ここでそれには、非常に重要ですが、性能風味よりむしろ機能性(例えば、マルチキャスト能力)かセキュリティ(例えば、クライアント認証)があるかもしれないことを特徴に私たちを心配させません。 一般に、これらの領域の要件は性能にもかなりの効果を持つでしょう。 私たちは単に宇宙制限のためにそれらについて議論しません。
For a given application, some of these properties may be required, some others only desirable. Also, some may be best represented as Boolean variables (present or absent), some others as continuous or multi-valued discrete variables, others yet as partially qualitative specifications.
与えられたアプリケーションに、これらのいくつかの特性が必要であるかもしれなく、何かが望ましいだけの他のものです。 また、ブール変数(現在の、または、休んでいる)か連続するとしての何人かの他のものかマルチ評価された離散変数(まだ部分的に質的な仕様としての他のもの)として或るものを表すかもしれないのは最も良いです。
4.1 Sequencing
4.1 配列
For applications involving message streams (rather than single datagrams), it may be necessary or desirable that messages be delivered in sequence, even though the sequence may not be complete. If the lower-level servers are not all capable of delivering messages sequentially, a resequencing operation may have to be performed at some higher level in the hierarchy. In those cases in which reliability requirements make retransmission necessary, resequencing may delay delivery of a large number of messages by relatively long times. An adequate amount of buffer space will have to be provided for this purpose at the level of the resequencer in the protocol hierarchy.
メッセージストリーム(単一のデータグラムよりむしろ)にかかわるアプリケーションに、連続してメッセージを送るのは、必要であるか、または望ましいかもしれません、系列が完全でないかもしれませんが。 低レベルサーバがメッセージをすべて連続して送ることができないなら、再配列操作は何らかのより高いレベルで階層構造で実行されなければならないかもしれません。 信頼度要求事項が「再-トランスミッション」を必要にするそれらの場合では、再配列は多くのメッセージの比較的長い回の配送を遅らせるかもしれません。 このためにプロトコル階層の「再-シーケンサ」のレベルで適当量のバッファ領域を提供しなければならないでしょう。
If sequencing is not guaranteed by all servers at all levels, the application may be able to tolerate out-of-sequence messages as long as their number is small, or if the delay bound is so large that very few out-of-sequence messages have to be discarded because they are too late. The client could be allowed to specify a bound on the probability that a message be delivered out of sequence, or to bundle out-of-sequence losses with the other types of message loss described by Wmin. The client would specify the value of Wmin (or Wmin Zmin), and the server would have to decide how much probability to allow for buffer overflow, how much for network error, and how much for imperfect sequencing, taking into account the stringency of the delay bounds.
遅れバウンドが順序が狂ってそんなにほんのわずかな状態で非常に大きいのでそれらの番号が少ない限り、メッセージが捨てられなければならなくて、配列がすべてのサーバによってすべてのレベルで保証されないなら、それらが遅過ぎるので、アプリケーションは順序が狂ってメッセージを許容できるかもしれません。 順序が狂ってメッセージを送るという確率でバウンドを指定するか、または他のタイプのメッセージの損失がWminによって説明されている状態で、クライアントは順序が狂って損失を束ねることができました。 クライアントはWmin(または、Wmin Zmin)の値を指定するでしょう、そして、サーバはネットワーク誤りによってバッファオーバーフロー、どのようにのためにどのくらいの確率に多くを許容するか、そして、不完全な配列のために、遅れの逼迫を考慮に入れるのがどれほどバウンドするかを決めなければならないでしょう。
Ferrari [Page 10] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[10ページ]RFC1193要件
On the other hand, with fixed-route connections and appropriate queueing and scheduling in the hosts and in the network, it is often not too hard to ensure sequenced delivery at the various layers, hence also at the top.
他方では、ホストとネットワークにおける固定ルート接続、適切な待ち行列、およびスケジューリングでは、それは先端でもしばしばしたがって、様々な層で配列された配送を確実にすることができないくらい困難であるというわけではありません。
4.2 Absence of duplications
4.2 複製の欠如
Most of the discussion of sequencing applies also to duplication of messages. It is, however, easier and faster to eliminate duplications than to resequence, as long as some layer keeps track of the sequence numbers of the messages already received. The specification of a bound may be needed only if duplications become very frequent, but this would be a symptom of serious network malfunction, and should not be dealt with in the same way as we handle delays or message losses. These observations do not apply, of course, to the case of intentional duplication for higher reliability.
また、配列の議論の大部分はメッセージの複製に適用されます。 複製を排除するのは、「再-系列」よりしかしながら、より簡単であって、速いです、何らかの層が既に受け取られたメッセージの一連番号の動向をおさえる限り。 複製が非常に頻繁になる場合にだけバウンドの仕様が必要であるかもしれませんが、これを重大なネットワーク不調の兆候であるだろう、私たちが遅れかメッセージの損失を扱うとき、同様に、対処するべきではありません。 これらの観測はもちろんより高い信頼性のための意図的な複製に関するケースに適用されません。
4.3 Failure recovery
4.3 失敗回復
The contract between client and server of a real-time service will have to specify what will happen in the event of a server failure. Ideally, from the client's viewpoint, failures should be perfectly masked, and service should be completely fault-tolerant. As we have already mentioned, however, it is usually unrealistic to expect that performance guarantees can be honored even in presence of failures. A little less unrealistic is to assume that service can resume a short time after a failure has disrupted it. In general, clients may not only wish to know what will happen if a failure occurs, but also have a guaranteed upper bound on the likelihood of such an occurrence:
リアルタイムでサービスのクライアントとサーバとの契約は、何がサーバ失敗の場合起こるかを指定しなければならないでしょう。 理想的に、失敗は完全にクライアントの観点から、仮面であるべきです、そして、サービスは完全にフォルト・トレラントであるべきです。 しかしながら、私たちが既に言及したように、通常、失敗の存在でさえ契約履行保証を光栄に思うことができると予想するのは非現実的です。 もう少し非現実的でないのは、失敗がそれを混乱させた後にサービスが短い間を再開できると仮定することです。 一般に、失敗が起こると何が起こるかを知っていることを願っているだけではなく、クライアントはそのような発生の見込みに保証された上限を持ってもいるかもしれません:
Prob (failure) <= Fmax.
Prob(失敗)<はFmaxと等しいです。
Different applications have different failure recovery requirements. Urgent datagrams or urgent message streams in most real-time distributed systems will probably not benefit much from recovery, unless it can be made so fast that hard deadlines may still be satisfied, at least in some cases. In the case of video or audio transmission, timely resumption of service will normally be very useful or even necessary; thus, clients may need to be given guarantees about the upper bounds of mean or maximum time to repair; this may also be the case of other applications in which the deadlines are not so stringent, or where the main emphasis is on throughput and/or reliability rather than on delay.
異なったアプリケーションには、異なった失敗回復要件があります。 ほとんどのリアルタイムの分散システムにおける緊急のデータグラムか急報の流れがたぶんあまり回復の利益を得ないでしょう、まだ困難な締め切りを満たすことができるくらい速くそれを作ることができないなら、少なくともいくつかの場合で。 ビデオか音声通信の場合では、通常、タイムリーなサービスの再開は、非常に役に立つか、または必要になりさえするでしょう。 したがって、クライアントは、修理する意地悪であるか最大の時間の上限に関する保証が与えられている必要があるかもしれません。 また、これは締め切りがそれほど厳しくないか、または主な強調がスループット、そして/または、遅れでというよりむしろ信頼性にある他のアプリケーションのそうであるかもしれません。
In communications over multi-node routes and/or long distances, the network itself may contain several messages for each source-
マルチノードルート、そして/または、長距離の上コミュニケーションでは、ネットワーク自体は各ソースへのいくつかのメッセージを含むかもしれません。
Ferrari [Page 11] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[11ページ]RFC1193要件
destination pair at the time a failure occurs. The recovery scheme will have to solve the problems of failure notification (to all the system's components involved, and possibly also to the clients) and disposition of messages in transit. The solutions adopted may make duplicate elimination necessary even in contexts in which no duplicates are ever created in the absence of failures.
失敗が起こるときの目的地組。 回復計画は失敗通知(システムのコンポーネントがかかわったすべてと、そして、ことによるとクライアントにも)の問題とトランジットにおけるメッセージの気質を解決しなければならないでしょう。 採用された解決策で、写し除去は写しが全く今までに失敗がないとき作成されない文脈でさえ必要になるかもしれません。
4.4 Service setup time
4.4 サービス準備時間
Real-time services must be requested before they can be used to
communicate [Ferr89b]. Some clients may be interested in long-term
arrangements which are set up soon after the signing of a contract
and are kept in existence for long times (days, months, years).
Others, typically for economical reasons, may wish to be allowed to
request services dynamically and to avoid paying for them even when
not in use. The extreme case of short-term service is that in which
the client wants to send one urgent datagram, but this is probably
best handled by a service broker ("the datagraph office") using a
permanent setup shared by many (or all) urgent datagrams. In most
other cases, a request for a short-term or medium-term service must
be processed by the server before the client is allowed to receive
that service (i.e., to send messages). Certain applications will
need the setup time to be short or, in any case, bounded: the maximum
time the client will have to wait for a (positive or negative) reply
to a request may have to be guaranteed by the server in the contract.
[Ferr89b]を伝えるのにそれらを使用できる前にリアルタイムのサービスを要求しなければなりません。 クライアントの中には契約の調印のすぐ後にセットアップされて、長い回(日、月、年)のために現存しているように保たれる長期協定に興味を持っている人もいるかもしれません。 通常経済的な理由によって、他のものは、ダイナミックにサービスを要求して、使用中でないときにさえ、それらの対価を支払うのを避けるのが許容されたいかもしれません。 極端な短期的にサービスのケースはクライアントが1個の緊急のデータグラムを送りたがっているそれですが、サービスブローカー(「datagraphオフィス」)は、たぶん多くの(すべて)緊急のデータグラムによって共有された永久的なセットアップを使用することでこれを扱います。クライアントがそのサービス(すなわち、メッセージを送る)を受けることができる前に、最も良く、他のほとんどの場合では、サーバで短期的であるか中型の用語のサービスを求める要求を処理しなければなりません。 あるアプリケーションは、準備時間が短いか、またはどのような場合でも、境界がある必要があるでしょう: クライアントが(肯定するか否定する)の回答を要求に待つのに過す最大の時間は契約のサーバによって保証されなければならないかもしれません。
5. Translating Requirements
5. 要件を翻訳します。
Performance specifications and other requirements are assigned at the top level, that of the human client or application, either explicitly or implicitly (see Section 2). To be satisfied, these specifications need the support of all the underlying layers: we believe that a real-time service cannot be implemented on top of a server at some level that is unable to guarantee performance. (Some of the other requirements can be satisfied even without this condition: for example, reliable delivery (when retransmission is acceptable) and sequencing.) Upper-level requirements must be translated into lower-level ones, so that the implementation of the former will be adequately supported. How should this be done?
パフォーマンス仕様と他の要件はトップレベル、人間のクライアントかアプリケーションのもので明らかかそれとなく割り当てられます(セクション2を見てください)。 満たされるために、これらの仕様はすべての下位層のサポートを必要とします: 私たちは、性能を保証できない何らかのレベルにおけるサーバの上でリアルタイムのサービスを実行できないと信じています。 (この状態がなくても他の要件のいくつかを満たすことができます: 例えば、信頼できる配信(「再-トランスミッション」が許容できるとき)と配列) 前者の実現が適切に支持されるように、上側のレベル要件を低レベルものに翻訳しなければなりません。 これはどのように完了しているべきですか?
5.1 Delay requirements
5.1 遅れ要件
The method for translating delay bounds macroscopically depends on the type of bound to be translated. All methods have to deal with two problems: the effects of delays in the individual layers, and the effects of message fragmentation on the requirements.
遅れ領域を翻訳するための方法は、翻訳されるために巨視的にバウンドのタイプに頼っています。 すべての方法が2つの問題に対処しなければなりません: 個々の層における、遅れの効果、およびメッセージ断片化の要件への効果。
(i) Deterministic delay bound. A deterministic bound on the delay
(i) 決定論的な遅れは付きました。 遅れにおける決定論的なバウンド
Ferrari [Page 12] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[12ページ]RFC1193要件
encountered by a message in each layer (or group of layers) in
the hosts will have to be estimated and enforced.
The delay bound for a server at a given level will be obtained
by subtracting the delay bounds of the layers above it in both
the sending and the receiving host from the original global
bound:
それぞれでメッセージで遭遇して、ホストの層(または、層のグループ)は、見積もられていて、励行されなければならないでしょう。 発信と受信ホストの両方でそれの上でオリジナルのグローバルなバウンドから層の遅れ領域を引き算することによって、与えられたレベルにサーバに向かっている遅れを得るでしょう:
Dmax' = Dmax - SUMi {d(max,i)}.
'Dmax'=Dmax--SUMi、d(最大、i)。
Message fragmentation can be handled by recalling that delay is
defined as the difference between the instant of completion of the
reception of a message and the instant when its shipment began.
If x is the interfragment time (assumed constant for simplicity
here) and f is the number of fragments in a message, we have
遅れがメッセージのレセプションの完成の瞬間、出荷が始まった瞬間の違いと定義されたと思い出すことによって、メッセージ断片化を扱うことができます。 xがinterfragment時間(ここで簡単さに一定であると思われる)であり、fがメッセージの断片の数であるなら、私たちは数でした。
Dmax' = Dmax - x(f-1),
'Dmax'=Dmax--x(f-1)
where Dmax' is the fragment delay bound corresponding to the
message delay bound Dmax, i.e., the delay of the first fragment.
'どこDmax'はメッセージ遅延バウンドDmaxに対応する断片遅れバウンドであるか、すなわち、最初の断片の遅れ。
(ii) Statistical delay bound. The statistical case is more
complicated. If the bounds on the delay in each layer
(or group of layers) are statistical, we may approach the
problem of the messages delayed beyond the bound
pessimistically, in which case we shall write
(ii)統計的な遅れは付きました。 統計的なケースは、より複雑です。 それぞれの層(または、層のグループ)の遅れの領域が統計的であるなら、私たちは悲観的にバウンドを超えて遅れたメッセージの問題にアプローチするかもしれません、その場合、書くつもりです。
Zmin' = Zmin / (PRODi {z(min,i)}),
'Zmin'がZmin/と等しい、(PRODi、z(分、i))
where the index i spans the layers (or group of layers) above the
given lower-level server, Zmin' is the probability bound to be
enforced by that lower-level server, and d(max,i) and z(min,i) are
the bounds for layer i. (A layer has a sender side and a receiver
side at the same level in the hierarchy.) The expression for
Zmin' is pessimistic because it assumes that a message delayed
beyond its bound in a layer will not be able to meet the global
bound Dmax. (The expression above and the next one assume that
the delays of a message in the layers are statistically
independent of each other. This assumption is usually not valid,
but, in the light of the observations that follow the next
expression, the error should be tolerable.)
私は与えられた低レベルサーバを超えて層(層のグループ)にかかります、Zmin。'どこ、インデックス、'その低レベルサーバによって確率バウンドは実施されることになっていて、d(最大、i)とz(分、i)は層iのための領域であるか。 (層は同じレベルで送付者側と受信機側を階層構造で持っています。) 層におけるバウンドを超えて遅れたメッセージがグローバルな制限されたDmaxに会うことができないと仮定するので、'Zminのための表現'は悲観的です。 (上の表現と次の人は、層のメッセージの遅れが互いから統計的に独立していると仮定します。 この仮定は通常有効ではありませんが、次の表現に続く観測の見地から、誤りは許容できるべきです。)
At the other extreme, we have the optimistic approach, which
assumes that a message will not satisfy the global bound only if
it is delayed beyond its local bound in each layer:
それとは正反対に、私たちには、楽観的なアプローチがあります:(アプローチは、それが各層における地方のバウンドを超えて遅らせられる場合にだけメッセージがグローバルなバウンドを満たさないと仮定します)。
Zmin' = 1 - (1 - Zmin)/(PRODi {1 - z(min,i)}).
'Zmin'=1--(1--Zmin) /、(PRODi、1--、z(分、i)、)
Ferrari [Page 13] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[13ページ]RFC1193要件
The correct assumption will be somewhere in between the
pessimistic and the optimistic ones. However, in order to be able
to guarantee the global bound, the system will have to choose the
pessimistic approach, unless a better approximation to reality can
be found. An alternative that may turn out to be more convenient
is the one of considering the bounds in the layers as
deterministic, in which case Zmin' will equal Zmin, and the global
bound will be statistical only because the network will guarantee
a statistical bound.
正しい仮定が悲観的なものと楽観的なものの間のどこかにあるでしょう。 しかしながら、グローバルなバウンドを保証できるように、システムは悲観的なアプローチを選ばなければならないでしょう、現実への、より良い近似を見つけることができないなら。 'より近いと判明するかもしれない代替手段はその場合、層の領域が決定論的であるとみなすZminのものです'はZminと等しいでしょう、そして、単にネットワークが統計的なバウンドを保証するので、グローバルなバウンドは統計的になるでしょう。
When estimating the effects of message fragmentation, the new
bounds must refer to the fragment stream as though its components
were independent of each other. Assuming sequential delivery of
fragments, a message is delayed beyond its bound if its last
fragment is delayed beyond the fragment bound. Our goal can be
achieved by imposing the same probability bound on fragments as on
messages [Verm90]. Thus,
メッセージ断片化の効果を見積もっているとき、まるでコンポーネントが互いから独立しているかのように新しい領域は断片の流れについて言及しなければなりません。 断片の連続した配送を仮定して、最後の断片が断片バウンドを超えて遅らせられるなら、メッセージはバウンドを超えて遅れます。 メッセージ[Verm90]のように断片の上に縛られた同じ確率を課すことによって、私たちの目標を達成できます。 このようにして
Zmin' = Zmin.
'Zmin'はZminと等しいです。
Note that both expressions for D prime sub max given in (i) above
apply to the statistical delay bound case as well.
(i)で上に与えられたD主要な潜水艦最大のための両方の表現が統計的な遅れに適用されるというメモはまた、ケースを縛りました。
(iii) Deterministic delay-jitter bound. For the case of layer to
layer translation, the discussion above yields:
(iii)決定論的な遅れジターは付きました。 層のケースが利回りを超えて翻訳、議論を層にするように:
Jmax' = Jmax - SUMi {j(max,i)} ,
'Jmax'=Jmax--SUMi、j(最大、i)
where j(max,i) is the deterministic jitter bound of the i-th layer
above the given lower-level server. When messages are fragmented,
the delay jitter bound can be left unchanged:
与えられた低レベルサーバを超えて層にしてください。j(最大、i)が決定論的なジターバウンドであるところ、i、-、第メッセージが断片化されるとき、遅れジターバウンドは変わりがないままにできます:
Jmax' = Jmax .
'Jmax'はJmaxと等しいです。
There would be reasons to reduce it in the case of message
fragmentation only if the underlying server did not guarantee
sequenced delivery, and if no resequencing of fragments were
provided by the corresponding reassembly layer on the receiving
side.
基本的なサーバが単に配列された配送を保証しないで、受信側の上の対応する再アセンブリ層のそばで断片を再配列でないのを提供するなら、メッセージ断片化の場合でそれを減少させる理由があるでしょうに。
(iv) Statistical delay-jitter bound. The interested reader will
be able with little effort to derive the translation formulas
for this case from the definition in Section 3.1 (iv)
and from the discussion in (ii) and (iii) above.
(iv)統計的な遅れジターは付きました。 このような場合定義からセクション3.1(iv)と(ii)と(iii)での議論から翻訳定石を得るための少ない努力が上にある状態で、興味のある読者はできるでしょう。
Ferrari [Page 14] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[14ページ]RFC1193要件
5.2 Throughput requirements
5.2 スループット要件
Since all layers are in cascade, the throughput bounds would be the same for all of them if headers and sometimes trailers were not added at each layer for encapsulation or fragmentation. Thus, throughput bounds have to be increased as the request travels downward through the protocol hierarchy, and the server at each layer knows by how much, since it is responsible for these additions.
すべての層が滝にあるので、ヘッダーと時々トレーラがカプセル化か断片化のために各層で加えられないなら、それらのすべてに、スループット領域は同じでしょうに。 したがって、要求がプロトコル階層を通って下向きに移動するのに従って、スループット領域は増加しなければなりません、そして、各層のサーバはいくらで知っているか、それがこれらの追加に責任があるので。
5.3 Reliability requirements
5.3 信頼性の要件
If we assume, quite realistically, that the probability of message loss in a host is extremely small, then we do not have to change the value of Wmin when we change layers.
層を変えるとき、ホストのメッセージの損失の確率が非常にわずかであると全く現実的に思うなら、私たちはWminの値を変える必要はありません。
The effects of message fragmentation are similar to those on statistical delay bounds, but in a given application a message may be lost even if only one of its fragments is lost. Thus, we have
メッセージ断片化の効果は統計的な遅れ領域でそれらと同様ですが、与えられたアプリケーションでは、断片の唯一の1つが無くなっても、メッセージは失われるかもしれません。 したがって、私たちはそうしました。
Wmin' = 1 - (1 - Wmin)/f ,
'Wmin'=1--(1--Wmin) /f
where Wmin' is the lower bound of the correct delivery probability for the fragment stream, and f is the number of fragments per message. The optimistic viewpoint, which is the one we adopted in Section 5.1 (ii), yields Wmin' = Wmin, and the observations made in that section about the true bound and about providing guarantees apply.
'どこWmin'は断片の流れのための適度の配送確率の下界であるか、そして、fは1メッセージあたりの断片の数です。 '楽観的な観点(私たちがセクション5.1(ii)に採用したものである)はWminをもたらすこと'がWminと等しいです、そして、本当のバウンドと保証を与えることに関するそのセクションでされた観測は適用されます。
5.4 Other requirements
5.4 他の要件
Of the requirements and desiderata discussed in Section 4, those that are specified as a Boolean value or a qualitative attribute do not have to be modified for lower-level servers unless they are satisfied in some layer above those servers (e.g., no sequencing is to be required below the level where a resequencer operates). When they are represented by a bound (e.g., one on the setup time, as described in Section 4.4), then bounds for the layers above a lower-level server will have to be chosen to calculate the corresponding bound for that server. The above discussions of the translation of performance requirements will, in most cases, provide the necessary techniques for doing these calculations.
セクション4で議論した要件と必需品では、それらが何らかの層の中でそれらのサーバを超えて満たされていない場合(例えば、配列でないのは「再-シーケンサ」が作動するところでレベルの下で必要であることです)、ブール値か質的な属性として指定されるものは低レベルサーバのために変更される必要はありません。 次に、低レベルサーバを超えた層のための領域は、そのサーバのための対応するバウンドについて計算するために選ばれなければならないでしょう。それらがバウンドで表される、(例えば、中で説明されるとしての準備時間の1、セクション4.4) 多くの場合、性能要件に関する翻訳の上の議論はこれらの計算をするための必要なテクニックを提供するでしょう。
The requirement that the server give clear and useful replies to client requests (see Section 2) raises the interesting problem of reverse translation, that from lower-level to upper-level specifications. However, at least in most cases, this does not seem to be a difficult problem: all the translation formulas we have written above are very easily invertible (in other words, it is
サーバがクライアント要求(セクション2を見る)に明確で役に立つ回答を与えるという要件は逆の翻訳のおもしろい問題、低レベルから上側のレベル指定までのそれを上げます。 しかしながら、少なくとも多くの場合、これは難問であるように思えません: 私たちが上に書いたすべての翻訳定石が非常に容易にinvertibleである、(言い換えれば、それはそうです。
Ferrari [Page 15] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[15ページ]RFC1193要件
straightforward to express Dmax as a function of Dmax', Zmin as a function of Zmin', and so on).
'、Dmax、'Zminの機能としてのZmin'の機能などとしてDmaxを急送するために簡単である、)
6. Examples
6. 例
In this section we describe some examples of client requirements for real-time services. Simplifying assumptions are introduced to decrease the amount of detail and increase clarity. Our intent is to determine the usefulness of the set of requirements proposed above, and to investigate some of the problems that may arise in practical cases. An assumption underlying all examples is that the network's transmission rate is 45 Mbits/s, and that the hosts can keep up with this rate when processing messages.
このセクションで、私たちは本当の時間指定サービスのためのクライアント要件に関するいくつかの例について説明します。 簡素化仮定は、詳細の量を減少させて、明快を増加させるように紹介されます。 私たちの意図は、上で提案された要件のセットの有用性を決定して、実用的な場合で起こるかもしれない問題のいくつかを調査することです。 すべての例の基礎となる仮定はネットワークの通信速度が45メガビット/sであり、メッセージを処理するときホストがこのレートについて行くことができるということです。
6.1 Interactive voice
6.1 対話的な声
Let us assume that human clients are to specify the requirements for voice that is already digitized (at a 64 kbits/s rate) and packetized (packet size: 48 bytes, coinciding with the size of an ATM cell; packet transmission time: 8.53 microseconds ; packet interarrival time: 6 ms). Since the communication is interactive, deterministic (and statistical) delay bounds play a very important role. Jitter is also important, but does not dominate the other requirements as in non-interactive audio or video communication (see Section 6.2). The minimum throughput offered by the system must correspond to the maximum input rate, i.e., 64 kbits/s; in fact, because of header overhead (5 control bytes for every 48 data bytes), total guaranteed throughput should be greater than 70.66 kbits/s, i.e., 8,834 bytes/s. (Since the client may not know the overhead introduced by the system, the system may have to compute this value from the one given by the client, which in this case would be 8 kbytes/s.) The minimum average throughput over an interval as long as 100 s is 44% of Tmin, due to the silence periods [Brad64].
人間のクライアントが既にデジタル化されて(64kbits/sレートで)、packetizedされる声(パケットサイズ:ATMセルのサイズと同時に起こります; パケット伝送時間: 8.53マイクロセカンド;48バイト、パケットinterarrival時間: 6ms)のための要件を指定することになっていると仮定しましょう。 コミュニケーションが対話的であるので、決定論的で(統計的)の遅れ領域は非常に重要な役割を果たします。 ジターは、また、重要ですが、非対話的なオーディオやビデオコミュニケーションのように他の要件を支配していません(セクション6.2を見てください)。 システムによって提供された最小のスループットはすなわち、最大の入力率、64kbits/sに対応しなければなりません。 事実上、ヘッダーオーバーヘッド(48データ・バイト毎の5コントロールバイト)のために、総保証されたスループットは70.66以上kbits/sであるべきです、すなわち、8,834バイト/s。 (クライアントがシステムによって導入されたオーバーヘッドを知らないかもしれないので、システムはクライアントによって与えられたものからこの値を計算しなければならないかもしれません。)(この場合、ものは8キロバイト/s.でしょう)。 100秒間としての長い同じくらい間隔にわたる最小の平均したスループットは44%のTminです、沈黙の期間[Brad64]のため。
Voice transmission can tolerate limited packet losses without making the speech unintelligible at the receiving end. We assume that a maximum loss of two packets out of 100 (each packet corresponding to 6 ms of speech) can be tolerated even in the worst case, i.e., when the two packets are consecutive. Since packets arriving after their absolute deadline are discarded if the delay bound is to be statistical, then this maximum loss rate must include losses due to lateness, i.e., 0.98 will have to be the value of Zmin Wmin rather than just that of Wmin.
犠牲者にスピーチを難解にしないで、音声伝送は限られたパケット損失を黙認できます。 私たちは、最悪の場合にはさえ100(スピーチの6msに対応するそれぞれのパケット)のパケットのうちの2の最大の損失を黙認されることができると思います、すなわち、2つのパケットが連続しているとき。 彼らの絶対締め切りの後に到着するパケットが遅れバウンドが統計的であることであるなら捨てられるので、次に、この最大の損失率は遅れによる損失を含まなければならなくて、すなわち、0.98はまさしくWminのものよりむしろZmin Wminの値にならなければならないでしょう。
This is illustrated in the first column of Table Ia, which consists of two subcolumns: one is for the choice of a deterministic delay bound, the other one for that of a statistical delay bound and a combined bound on the probability of lateness or loss. If in a row
これは2「副-コラム」から成るTable Iaの最初のコラムで例証されます: 1つは決定論的な遅れバウンドの選択、統計的な遅れバウンドのもののためのもう片方、および結合したバウンドのために遅れか損失の確率にあります。 aでは、船をこいでくださいなら
Ferrari [Page 16] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[16ページ]RFC1193要件
there is a single entry, that entry is the same for both subcolumns. Note that the maximum setup time could be made much longer if connections had to be reserved in advance.
単一のエントリーがあって、両方の「副-コラム」に、そのエントリーは同じです。 あらかじめ接続を控えなければならないなら最大の準備時間をはるかに長くすることができることに注意してください。
Since voice is packetized at the client's level, we will not have to worry about the effects of fragmentation while translating the requirements into their lower-level correspondents.
声がクライアントのレベルでpacketizedされるので、私たちは彼らの低レベル通信員に要件を翻訳している間、断片化の効果を心配する必要はないでしょう。
6.2 Non-interactive video
6.2 非対話的なビデオ
At the level of the client, the video message stream consists of 1 Mbit frames, to be transmitted at the rate of 30 frames per second. Thus, the throughput bounds (both deterministic and average) are, taking into account the overhead of ATM cell headers, 4.14 Mbytes/s. As in the case of interactive voice, we have two alternatives for the specification of delay bounds: the first subcolumn is for the deterministic bound case, the second for that of a statistical bound on delays and a combined probability bound on lateness or loss; the latter bound is set to at most 10 frames out of 100, i.e., three out of 30. However, the really important bound in this case is the one on delay jitter, set at 5 ms, which is roughly equal to half of the interval between two successive frames, and between 1/4 and 1/5 of the transmission time. This dominance of the jitter bound is the reason why the other delay bounds are in parentheses.
クライアントのレベルでは、ビデオメッセージストリームは、1秒あたり30個のフレームの料金で伝えられるために1メガビットフレームから成ります。 したがって、スループット領域(決定論的で平均の両方だった)はATMセルヘッダーのオーバーヘッドを考慮に入れる4.14Mbytes/sです。 対話的な声に関するケースのように、私たちには、遅れ領域の仕様のための2つの選択肢があります: 最初の「副-コラム」は決定論的な制限されたケース、遅れにおける統計的なバウンドのもののための2番目、および遅れか損失のときに縛られた結合した確率のためのものです。 後者のバウンドは高々すなわち、100、30のうちの3個のフレームのうちの10しかセットではありません。 しかしながら、この場合、本当に重要なバウンドは、遅れジターの5msに設定されたおよそ2個の連続したフレームの半分の間隔と等しいものと、1/5 1/4〜トランスミッション回です。 ジターバウンドのこの支配は他の遅れ領域が括弧にある理由です。
If we assume that video frames will have to be fragmented into cells at some lower level in the protocol hierarchy, then these requirements must be translated at that level into those shown in the first column of Table II. The values of Dmax' have been calculated with x = 12.8 microseconds and f = 2605 fragments/frame. The range of Wmin' and of (Zmin Wmin)' is quite wide, and achieving its higher value (a probability of 1) may turn out to be either very expensive or impossible. We observe, however, that a frame in which a packet or more are missing or have been incorrectly received does not have to be discarded but can be played with gaps or patched with the old packets in lieu of the missing or corrupted ones. Thus, it may be possible to consider an optimistic approach (e.g., Zmin' = Zmin, Wmin' = Wmin, (Zmin Wmin)' = Zmin Wmin ) as sufficiently safe.
私たちが、ビデオフレームが何らかの下のレベルでセルの中にプロトコル階層で断片化されなければならないと思うなら、そのレベルでII Tableの最初のコラムに示されたものにこれらの要件を翻訳しなければなりません。 xで'Dmaxの値'について= 12.8マイクロセカンド計算してあります、そして、fは2605個の断片/フレームと等しいです。 'Wmin'(Zmin Wmin)'の範囲はかなり広いです、そして、より高い値(1の確率)を達成するのは非常に高価であるか、または不可能であると判明するかもしれません。 しかしながら、私たちは、なくなったか崩壊したものの代わりにパケットか以上がなくなるか、または不当に受け取られたフレームを捨てられる必要はありませんが、ギャップでプレーするか、または古いパケットで修理できるのを観測します。 'その結果、十分安全であるとして楽観的なアプローチが(例えば、'= Zmin、Wminが'Wmin、(Zmin Wmin)と等しい'というZmin=Zmin Wmin)であると考えるのは可能であるかもしれません。
6.3 Real-time datagram
6.3 リアルタイムのデータグラム
A real-time datagram is, for instance, an alarm condition to be transmitted in an emergency from one machine to another (or a group of others) in a distributed real-time system. The client requirements in this case are very simple: a deterministic bound is needed (we are assuming that this is a hard-real-time context), the reliability of delivery must be very high, and the service setup time should be very small. The value of 0.98 for Wmin in Table Ib tries
例えば、リアルタイムのデータグラムは非常時に分配されたリアルタイムのシステムで1台のマシンから別のもの(または、他のもののグループ)まで伝えられるべきアラーム状態です。 この場合、クライアント要件は非常に簡単です: 決定論的なバウンドが必要です、そして、(私たちは、これが困難なリアルタイムの背景であると思っています)配送の信頼性は非常に高くなければなりません、そして、サービス準備時間は非常に小さいはずです。 TableイブのWminのための0.98の値は試みます。
Ferrari [Page 17] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[17ページ]RFC1193要件
to account for the inevitable network errors and to suggest that retransmission should not be used as might be necessary if we wanted to have Wmin = 1, because it would be too slow. To increase reliability in this case, error correcting codes or spatial redundancy will have to be resorted to instead.
私たちが、Wmin=1が欲しいと思うなら、必然のネットワーク誤りを説明して、その「再-トランスミッション」を示すのは必要であるかもしれないように使用されていないでしょうに、それが遅過ぎるでしょう、したがって。 この場合信頼性を増加させるように、誤り検出方式か空間的な冗長が代わりに当てにされなければならないでしょう。
Note that one method for obtaining a very small setup time consists of shipping such urgent datagrams on long-lasting connections previously created between the hosts involved and with the appropriate characteristics. Note also that throughput requirements cannot be defined, since we are dealing with one small message only, which may not even have to be fragmented. Guarantees on the other bounds will fully satisfy the needs of the client in this case.
非常に小さい準備時間を得るための1つの方法が以前にかかわって適切な特性をもっているホストの間で創造された持続的な接続のときにそのような緊急のデータグラムを出荷するのから成ることに注意してください。 また、スループット要件を定義できないことに注意してください、私たちが1つの小さいメッセージ(断片化される必要さえないかもしれない)だけに対処しているので。 他の領域における保証はこの場合クライアントの需要を完全に満たすでしょう。
6.4 File transfer
6.4 ファイル転送
Large files are to be copied from a disk to a remote disk. We assume that the receiving disk's speed is greater than or equal to the sending disk's, and that the transfer could therefore proceed, in the absence of congestion, at the speed of the sending disk. The message size equals the size of one track (11 Kbytes, including disk surface overhead such as intersector gaps), and the maximum input rate is 5.28 Mbits/s. Taking into account the ATM cell headers, this rate becomes 728 kbytes/s; this is the minimum peak throughput to be guaranteed by the system. The minimum average throughput to be provided is smaller, due to head switching times and setup delays (seek times are even longer, hence need not be considered here): we set its value at 700 kbytes/s.
大きいファイルはディスクからリモートディスクまでコピーされることです。 私たちが、受信ディスクの速度がそう以上であると思う、転送はしたがって混雑がないとき送付ディスクの速度でディスクのもの、およびそれを送ることができていかけること。 メッセージサイズは1つの道(intersectorギャップなどのディスク表面オーバーヘッドを含む11キロバイト)のサイズと等しいです、そして、最大の入力率は5.28メガビット/sです。 ATMセルヘッダーを考慮に入れて、このレートは728キロバイト/sなります。 これはシステムによって保証される最小のピークスループットです。 提供される最小の平均したスループットはヘッド切り換え回数のために、よりわずかです、そして、セットアップは延着します(シーク時間は、さらに長く、したがって、ここで考えられる必要はありません): 私たちは700キロバイト/sで値を設定します。
Delay bounds are much less important in this example than in the previous ones; in Table Ib, we show deterministic and statistical bounds in parentheses. Reliability must be eventually 1 to ensure the integrity of the file's copy. This result will have to be obtained by error correction (which will increase the throughput requirements) or retransmission (which would break most delay bounds if they were selected on the basis of the first shipment only instead of the last one).
遅れ領域は前のものよりこの例であまり重要ではありません。 Tableイブでは、私たちは括弧に決定論的で統計的な領域を示しています。 結局、信頼性はファイルのコピーの保全を確実にする1であるに違いありません。 この結果はエラー修正(スループット要件を増加させる)か「再-トランスミッション」(それらが最後のものの代わりにだけの最初の積荷に基づいて選択されるなら、ほとんどの遅れ領域を壊す)によって得られなければならないでしょう。
The second column in Table II shows the results of translating these requirements to account for message fragmentation. The values x = 78.3 microseconds and f = 230 have been used to compute those of Dmax'.
Table IIにおける第2コラムはメッセージ断片化を説明するというこれらの要件を翻訳するという結果を示しています。 '= 78.3マイクロセカンドの値xとf=230はDmaxのものを計算するのに使用されました'。
7. Discussion
7. 議論
In this section, we briefly discuss some of the objections that can be raised concerning our approach to real-time service requirements. Some of the objections are fundamental ones: they are at least as
このセクションで、私たちは簡潔にリアルタイムのサービス要件への私たちのアプローチに関して上げることができる反論のいくつかについて議論します。 反論のいくつかが基本的なものです: それらは少なくともそうです。
Ferrari [Page 18] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[18ページ]RFC1193要件
related to the basic decisions to be made in the design of the server as they are to client requirements.
クライアント要件にはそれらがあるのでサーバの設計で作られているという基本的な決定に関連しました。
Objection 1: Guarantees are not necessary.
異論1: 保証は必要ではありません。
This is the most radical objection, as it stems from a basic disagreement with our definition of real-time service. The problem, however, is not with definitions or terminologies: the really important question is whether a type of service such as the one we call "real-time" will be necessary or at least useful in future networks. This objection is raised by the optimists, those who believe that network bandwidth will be so abundant that congestion will become a disease of the past, and that delays will therefore be small enough that the enforcement of legalistic guarantees will not be necessary. The history of computers and communications, however, does not unfortunately support these arguments, while it supports those of the pessimists. In a situation of limited resources (limited with respect to the existing demand for them), we believe that there is no serious solution of the real-time communication problem other than one based on a policy for the allocation of resources that rigorously guarantees the satisfaction of performance needs. Even if the approaches to be adopted in practical networks will provide only approximate guarantees, it is important to devise methods that offer without exceptions precisely defined bounds. These methods can at the very least be used as reference approaches for comparison and evaluation.
私たちのリアルタイムでサービスの定義との根本的な意見の相違に由来するとき、これは最も急進的な異論です。 しかしながら、問題が定義か用語と共にありません: 本当に重要な質問は私たちが「リアルタイムでである」と呼ぶものなどの一種のサービスが将来のネットワークで必要であるか、または少なくとも役に立つということです。 楽天家(ネットワーク回線容量が混雑が過去の病気になって、したがって、遅れが法律尊重主義の保証の実施が必要にならないほど小さくなるほど豊富になると信じている人)にこの異論は上げられます。 しかしながら、コンピュータとコミュニケーションの歴史は残念ながらこれらの議論を支持しませんが、それは悲観論者のものを支持します。 限りある資源(それらの既存の要求に関して、制限される)の状況を、私たちは、性能の必要性の満足をきびしく保証するリソースの配分のための方針に基づく1を除いた瞬時通信問題のどんな重大な解決もないと信じています。 実用的なネットワークで採用されるべきアプローチが大体の保証だけを提供しても、例外のないその申し出が正確に領域を定義したのは、捻出方法に重要です。 参照に比較と評価のためにアプローチするとき、これらの方法を少なくとも使用できます。
Objection 2: Real-time services are too expensive because reservation of resources is very wasteful.
異論2: リソースの予約が非常に無駄であるので、リアルタイムのサービスは高価過ぎます。
This may be true if resources are exclusively reserved; for example, physical circuits used for bursty traffic in a circuit-switched network. There are, however, other ways of building real-time services, based on priority mechanisms and preemption rather than exclusive reservation of resources. With these schemes, the real- time traffic always finds the resources it needs by preempting non- real-time traffic, as long as the real-time load is kept below a threshold. The threshold corresponds to the point where the demand by real-time traffic for the bottleneck resource equals the amount of that resource in the system. With this scheme, all resources not used by real-time traffic can be used at any time by local tasks and non-real-time traffic. Congestion may affect the latter, but not real-time traffic. Thus, the only limitation is that a network cannot carry unbounded amounts of real-time traffic, and must refuse any further requests when it has reached the saturation point.
リソースが排他的に予約されるなら、これは本当であるかもしれません。 例えば、実回線はburstyに回路交換ネットワークの交通を使用しました。 しかしながら、リアルタイムのサービスを組み込む他の方法があります、リソースの独占的な予約よりむしろ優先権メカニズムと先取りに基づいて。 これらの計画で、本当の時間交通はいつもそれが非リアルタイムの交通を先取りすることによって必要とするリソースを見つけます、リアルタイムの負荷が敷居の下で保たれる限り。 敷居はリアルタイムの交通によるボトルネックリソースの要求がシステムのそのリソースの量と等しいポイントに対応しています。 この計画で、いつでも、ローカルのタスクと非リアルタイムの交通でリアルタイムの交通で使用されないすべてのリソースは使用できます。 混雑は後者の、しかし、リアルタイムでない交通に影響するかもしれません。 したがって、唯一の制限はネットワークが限りない量のリアルタイムの交通を運ぶことができないで、飽和点に達したときどんなさらなる要求も拒否しなければならないということです。
Ferrari [Page 19] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[19ページ]RFC1193要件
Objection 3: Real-time services can be built on top of non-real-time servers.
異論3: 非リアルタイムのサーバの上でリアルタイムのサービスを組み込むことができます。
If one accepts our interpretation of the term "guarantee," one can easily see that performance guarantees cannot be provided by a higher-level server unless it can rely on real-time support by its underlying server. Since this is true at all levels, we conclude that a real-time network service and similar services at all intermediate levels are needed to provide guaranteed performance to human clients and applications.
1つが「保証」という用語に関する私たちの解釈を受け入れるなら、人は、基本的なサーバでリアルタイムのサポートに依存できないなら、よりハイレベルのサーバで契約履行保証を提供できないのを容易に見ることができます。これがすべてのレベルで本当であるので、私たちは、すべての中間的レベルにおけるリアルタイムのネットワーク・サービスと同様のサービスが人間のクライアントとアプリケーションに保証値を提供するのに必要であると結論を下します。
Objection 4: Delay bounds are not necessary, throughput requirements suffice.
異論4: 遅れ領域は必要でない、スループット要件が十分です。
Guaranteeing minimum throughput bounds does not automatically and in general result in any stringent upper bound on delay. Delays in the hosts and nodes of a packet-switching network fluctuate because of bursty real-time message streams, starting and ending of traffic on individual connections (even those with continuous, constant-rate traffic), and the behavior of scheduling algorithms. Even if delays did not fluctuate, but had a constant value, it would be possible for a given throughput bound to be satisfied with many different constant values for the delay of each message. If delay bounds are wanted, they must be explicitly guaranteed and enforced. (In a circuit- switching network, the circuit assigned to a connection has its own throughput and its own delay. These values may be considered as explicitly guaranteed and enforced.)
自動的で一般に、最小のスループット領域を保証するのは遅れに関するどんな厳しい上限ももたらしません。 パケット交換網のホストとノードの遅れは個々の接続(連続して、一定のレートの交通を伴うそれらさえ)、およびスケジューリングアルゴリズムの振舞いにおける交通のburstyのリアルタイムのメッセージストリーム、始め、および結末のために変動します。遅れに、変動しませんでしたが、恒常価値があったとしても、与えられたスループットバウンドがそれぞれのメッセージの遅れのための多くの異なった恒常価値に満たされるのは、可能でしょうに。 遅れ領域が欲しいなら、それらを明らかに保証されて、実施しなければなりません。 (サーキット切り換えネットワークでは、接続に割り当てられたサーキットはそれ自身のスループットとそれ自身の遅れを持っています。 これらの値は、明らかに保証されているとみなされて、励行されるかもしれません。)
But are delay bounds wanted? We believe they are in digital video and audio communication, especially in the form of delay jitter bounds, and they will be in other contexts as soon as a service which can bound delays is offered.
しかし、遅れ領域は欲しいですか? 私たちは、彼らがデジタルビデオとオーディオのコミュニケーションと、特に遅れジター領域の形にあると信じています、そして、すぐバウンドできるサービスとして遅れを提供するとき、それらは他の文脈にあるでしょう。
Objection 5: Satisfaction of statistical bounds is impossible to verify.
異論5: 統計的な領域の満足は確かめるのが不可能です。
Strictly speaking, this objection is valid. No matter how many packets on a connection have been delayed beyond their bound (or lost or delivered with errors), it is always in principle possible for the server to redress the situation in the future and meet the given statistical requirements. A more sensible and verifiable bound would be a fractional one (see Section 3). For instance, such a bound could be specified as follows: out of 100 consecutive packets, no less than 97 shall not be late. In this case, the bound is no longer Zmin, a probability of 0.97, but is given by the two values B = 97 and A = 100; it is not only their ratio that counts but also their individual values.
厳密に言うと、この異論は有効です。 接続でのいくつのパケットが彼らのバウンド(または、誤りと共に失うか、または渡す)を超えて遅らせられたかとしても、サーバが将来、状況を直して、与えられた統計的な必要条件を満たすのは、原則としていつも可能です。 より分別があって証明可能なバウンドは断片的なもの(セクション3を見る)でしょう。 例えば、以下の通りそのようなバウンドを指定できました: 100の連続したパケットから、少なくとも97は遅れないでしょう。 この場合、バウンドをもうZmin、0.97の確率ですが、2つの値B=97とA=100で与えます。 それは重要であるそれらの比率だけではなく、それらの個人価値でもあります。
Ferrari [Page 20] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[20ページ]RFC1193要件
8. Conclusion
8. 結論
This paper has presented a specification of some of the requirements that human clients and applications may wish to impose on real-time communications. Though those listed seem to be among the most useful and natural ones, no attempt has been made to be exhaustive and comprehensive.
この紙は人間のクライアントとアプリケーションが瞬時通信にでしゃばりたがっているかもしれないという要件のいくつかの仕様を提示しました。 記載されたものは最も役に立って自然なものの中にあるように思えますが、徹底的であって、包括的であることを試みを全くしていません。
We have investigated delay bounds, throughput bounds, reliability bounds, and other requirements. We have studied how the requirements should be translated from the client's level into forms suitable (and correct) for lower levels, described some examples of requirement specification, and discussed some of the objections that may be raised.
私たちは遅れ領域、スループット領域、信頼性の領域、および他の要件を調査しました。 私たちは、要件がクライアントのレベルから下のレベルにおける、適当で(正しい)のフォームにどう翻訳されるべきであるかを研究して、要件仕様に関するいくつかの例について説明して、上げられるかもしれない反論のいくつかについて議論しました。
The material in this paper covers only part of the first phase in the design of a real-time service: that during which the various requirements are assembled and examined to extract useful suggestions for the design of the server. Server needs and design principles will be the subject of the subsequent paper mentioned several times above.
この紙の材料はリアルタイムでサービスのデザインにおける第1段階の一部だけを覆っています: 様々な要件が. サーバが必要とするサーバの設計のための役に立つ提案を抜粋するために組み立てられて、調べられるそれと設計原理は何度か上に参照されたその後の紙の対象になるでしょう。
Acknowledgments
承認
Ralf Herrtwich and Dinesh Verma contributed ideas to, and corrected mistakes in, a previous version of the manuscript. The author is deeply indebted to them for their help and for the many discussions he had with them on the topics dealt with in this paper. The comments of Ramesh Govindan and Riccardo Gusella are also gratefully acknowledged.
ラルフHerrtwichとDinesh Vermaは原稿の旧バージョンで考えを寄付して、誤りを修正しました。 作者は彼らの助けとそれらでこの紙で対処された話題に関してした多くの議論に深くそれらの世話になっています。 また、Ramesh Govindanとリッカルド・グゼルラのコメントは感謝して承諾されます。
References
参照
[Brad64] Brady, P., "A Technique for Investigating On-Off Patterns
of Speech", Bell Systems Technical Journal, Vol. 44,
Pgs. 1-22, 1964.
[Brad64] ブレイディ、P.、「スピーチのオンにオフなパターンを調査するためのテクニック」、ベルシステム専門誌、Vol.44、Pgs。 1-22, 1964.
[Ferr89a] Ferrari, D., "Real-Time Communication in
Packet-Switching Wide-Area Networks", Technical Report
TR-89-022, International Computer Science Institute,
Berkeley, May 1989.
[Ferr89a] フェラーリ、D.、「パケット交換ワイドエリアネットワークにおける瞬時通信」、技術報告書TR-89-022、国際電子計算機科学協会、バークレーは1989がそうするかもしれません。
[Ferr89b] Ferrari D., and D. Verma, "A Scheme for Real-Time Channel
Establishment in Wide-Area Networks", IEEE J. Selected
Areas Communications SAC-8, April 1990.
[Ferr89b] フェラーリD.、およびD.Verma、「ワイドエリアネットワークへのリアルタイムのチャンネル設立の計画」、IEEE J.は領域コミュニケーション嚢-8、4月1990日を選択しました。
[Gait90] Gaitonde, S., D. Jacobson, and A. Pohm, "Bounding Delay on
a Multifarious Token Ring Network", Communications of the
[Gait90]Gaitonde、S.、D.ジェーコブソン、およびA.Pohm、「多方面のトークンリングネットワークに関する制限遅れ」、コミュニケーション
Ferrari [Page 21] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[21ページ]RFC1193要件
ACM, Vol. 33, No. 1, Pgs. 20-28, January 1990.
ACM、Vol.33、No.1、Pgs。 20-28と、1990年1月。
[Herr89] Herrtwich R., and U. Brandenburg, "Accessing and
Customizing Services in Distributed Systems", Technical
Report TR-89-059, International Computer Science Institute,
Berkeley, October 1989.
[Herr89] Herrtwich R.、U.ブランデンブルク、および「分散システムにおけるアクセスとカスタマイズサービス」、技術報告書TR-89-059、国際電子計算機科学協会、バークレー(1989年10月)
[Herr90] Herrtwich, R, personal communication, February 1990.
[Herr90]Herrtwich、R、個人的なコミュニケーション、1990年2月。
[Verm90] Verma, D., personal communication, February 1990.
[Verm90]Verma、D.、個人的なコミュニケーション、1990年2月。
Table Ia
Examples of Client Requirements
クライアント要件に関するテーブルIaの例
Interactive Non-Interactive
Voice Video
対話的な非対話的な音声ビデオ
Delay Bounds
deterministic:Dmax [ms] 200 - (1000) -
statistical:Dmax [ms] - 200 - (1000)
Zmin - (*) - (*)
jitter:Jmax [ms] 1 5
決定論的に領域を遅らせてください、: Dmax[ms]200--(1000)--、統計的である、: Dmax[ms]--200--(1000)Zmin--(*)--(*)ジター: Jmax[ms]1 5
Throughput Bounds
deterministic:Tmin [kby/s] 8.834 4140
average:Tave [kby/s] 3.933 4140
I [s] 100 100
スループットは決定論的にバウンドしています: Tmin[kby/s]8.834 4140は: テーヴ[kby/s]3.933 4140I[s]100 100を平均します。
Reliability Bound:Wmin 0.98 (*) (0.90) (*) Delay&Reliability:ZminWmin - 0.98 - 0.90
信頼性は付きました: 遅れと信頼性: Wmin0.98(*)(0.90)(*)ZminWmin--0.98--0.90
Sequencing yes yes Absence of Duplications yes yes Failure Recovery: max.repair time [s] 10 100 Max.Setup Time [s] 0.8 (o) 15 (o)
DuplicationsはいはいのFailure Recoveryの配列はいはいのAbsence: max.repair時間[s]10 100Max.Setup Time[s]0.8(o)15(o)
----------------------------------
----------------------------------
(*) To be chosen by the server (o) Could be much longer if advance reservations were required (+) Could be achieved by using a preexisting connection
(*) 事前の予約が必要であることで、先在の接続を使用することによって(+)を達成できるだろうということであるなら、サーバ(o)によって選ばれるのは、はるかに長いかもしれないでしょうに。
Ferrari [Page 22] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[22ページ]RFC1193要件
Table Ib
Examples of Client Requirements
クライアント要件に関するテーブルイブの例
Real-Time File
Datagram Transfer
リアルタイムのファイルデータグラム転送
Delay Bounds
deterministic:Dmax [ms] 50 - (1500)
statistical:Dmax [ms] - (1000) -
Zmin - (0.95) -
jitter:Jmax [ms] - -
決定論的に領域を遅らせてください、: Dmax[ms]50--(1500)、統計的である、: Dmax[ms]--(1000)--Zmin--(0.95)ジター: (Jmax[ms])、-
Throughput Bounds
deterministic:Tmin [kby/s] - 728
average:Tave [kby/s] - 700
I [s] - 100
スループットが決定論的にバウンドしている、: Tmin[kby/s]--728 平均: テーヴ[kby/s]--700 I[s]--、100
Reliability Bound:Wmin 0.98 1 Delay&Reliability:ZminWmin - -
信頼性のバウンド: Wmin0.98 1遅れと信頼性: ZminWmin--、-
Sequencing - yes Absence of Duplications yes yes Failure Recovery: max.repair time [s] - 100 Max.Setup Time [s] 0 (+) 5 (o)
配列--DuplicationsはいはいのFailure RecoveryのはいAbsence: max.repair時間[s]--100Max.Setup Time[s]0(+)5(o)
----------------------------------
----------------------------------
(*) To be chosen by the server (o) Could be much longer if advance reservations were required (+) Could be achieved by using a preexisting connection
事前の予約が必要であることで、先在の接続を使用することによって(+)を達成できるだろうということであるなら、サーバ(o)によって選ばれる(*)ははるかに長いかもしれないでしょうに。
Ferrari [Page 23] RFC 1193 Requirements for Real-Time Services November 1990
リアルタイムの1990年11月のためのフェラーリ[23ページ]RFC1193要件
Table II
Translation of the Requirements in Table I
テーブルII テーブルIの要件に関する翻訳
Non-Interactive File
Video Transfer
非対話的なファイルビデオ転送
Delay Bounds
deterministic:Dmax' [ms] (966) - - (1482)
statistical:Dmax' [ms] - (966) (982) -
Zmin' - (*) (0.95) -
jitter:Jmax' [ms] 5 -
'決定論的に領域を遅らせてください、: Dmax'[ms](966)----(1482)統計的な: Dmax'[ms]((966)(982))Zmin'(*)(0.95)ジター:、Jmax'[ms]5、-
Reliability Bound:Wmin' 0.90-1 (*) 1
'バウンド: 信頼性のWmin'0.90-1(*)1
Delay&Reliability:(ZminWmin)' - 0.90-1 -
'遅れと信頼性: (ZminWmin)'--、0.90-1、-
_____________________________________
_____________________________________
(*) To be chosen by the server
(*) サーバによって選ばれているように
Security Considerations
セキュリティ問題
Security considerations are not discussed in this memo.
このメモでセキュリティ問題について議論しません。
Author's Address
作者のアドレス
Domenico Ferrari University of California Computer Science Division EECS Department Berkeley, CA 94720
ドメニコ・フェラーリカリフォルニア大学コンピュータサイエンス事業部EECS部のバークレー、カリフォルニア 94720
Phone: (415) 642-3806
以下に電話をしてください。 (415) 642-3806
EMail: ferrari@UCBVAX.BERKELEY.EDU
メール: ferrari@UCBVAX.BERKELEY.EDU
Ferrari [Page 24]
フェラーリ[24ページ]
一覧
スポンサーリンク
