RFC1257 日本語訳

Network Working Group                                       C. Partridge
Request for Comments: 1257         Swedish Institute of Computer Science
                                                          September 1991

コメントを求めるワーキンググループC.ヤマウズラ要求をネットワークでつないでください: 1257 スウェーデンのコンピュータ科学協会1991年9月

   Isochronous Applications Do Not Require Jitter-Controlled Networks

同一時間のアプリケーションはジターで制御されたネットワークを必要としません。

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

Abstract

要約

   This memo argues that jitter control is not required for networks to
   support isochronous applications.  A network providing bandwidth and
   bounds delay is sufficient.  The implications for gigabit
   internetworking protocols are briefly considered.

このメモは、ネットワークが同一時間のアプリケーションをサポートするのにジターコントロールは必要でないと主張します。 帯域幅と領域が延着するなら、ネットワークは十分です。 ギガビットインターネットワーキングプロトコルのための含意は簡潔に考えられます。

Introduction

序論

   An oft-stated goal of many of the ongoing gigabit networking research
   projects is to make it possible to support high bandwidth isochronous
   applications.  An isochronous application is an application which
   must generate or process regular amounts of data at fixed intervals.
   Examples of such applications include telephones, which send and
   receive voice samples at regular intervals, and fixed rate video-
   codecs, which generate data at regular intervals and which must
   receive data at regular intervals.

進行中のギガビットネットワーク研究計画の多くのしばしば述べられた目標は高帯域の同一時間のアプリケーションをサポートするのを可能にすることです。 同一時間のアプリケーションは定期的に通常の量のデータを生成しなければならないか、または処理しなければならないアプリケーションです。 そのようなアプリケーションに関する例は固定レートビデオ電話とコーデックを含んでいます。(電話は、一定の間隔を置いて声のサンプルを送って、受け取ります)。(コーデックは、一定の間隔を置いてデータを生成して、一定の間隔を置いてデータを受け取らなければなりません)。

   One of the properties of isochronous applications like voice and
   video data streams is that their users may be sensitive to the
   variation in interarrival times between data delivered to the final
   output device.  This interarrival time is called "jitter" for very
   small variances (less than 10 Hz) and "wander" if it is somewhat
   larger (less than one day).  For convenience, this memo will use the
   term jitter for both jitter and wander.

声とビデオデータ・ストリームのような同一時間のアプリケーションの特性の1つは彼らのユーザが最終産出物デバイスに提供されたデータの間のinterarrival回の変化に敏感であるかもしれないということです。 それが(1日未満)の間、いくらか大きいなら、このinterarrival時間は非常に小さい変化(10Hz未満)と「歩き回ってください」のために「ジター」と呼ばれます。 そして、便宜に、このメモが両方のための用語ジターを使用する、ジター、歩き回ってください。

   A couple of examples help illustrate the sensitivity of applications
   to jitter.  Consider a user watching a video at her workstation.  If
   the screen is not updated regularly every 30th of a second or faster,
   the user will notice a flickering in the image.  Similarly, if voice
   samples are not delivered at regular intervals, voice output may
   sound distorted.  Thus the user is sensitive to the interarrival time
   of data at the output device.

2、3の例が、アプリケーションの感度をジターに例証するのを助けます。 彼女のワークステーションでビデオを監視しているユーザを考えてください。 定期的にスクリーンをアップデートしないと、1秒のあらゆる30番目か、より速くて、イメージでユーザは揺らめくことに気付くでしょう。 同様に、声のサンプルが一定の間隔を置いて提供されないなら、声の出力はひずみに聞こえるかもしれません。 したがって、ユーザは出力装置でデータのinterarrival時間に敏感です。

   Observe that if two users are conferring with each other from their

ユーザが互いと共に協議している2であるならそれを観測してください、彼ら

Partridge                                                       [Page 1]

RFC 1257                 Isochronous and Jitter           September 1991

ヤマウズラ[1ページ]RFC1257同一時間とジター1991年9月

   workstations, then beyond sensitivity to interarrival times, the
   users will also be sensitive to end-to-end delay.  Consider the
   difference between conferencing over a satellite link and a
   terrestrial link.  Furthermore, for the data to be able to arrive in
   time, there must be sufficient bandwidth.  Bandwidth requirements are
   particularly important for video: HDTV, even after compression,
   currently requires bandwidth in excess of 100 Mbits/second.

また、ワークステーション、感度を超えたinterarrival回へのその時、ユーザは終わりから終わりへの遅れに敏感になるでしょう。 衛星中継と地球のリンクの上の会議の違いを考えてください。 その上、データが時間内に到着できるように、十分な帯域幅があるに違いありません。 ビデオには、帯域幅要件は特に重要です: HDTVは現在、圧縮の後にさえ帯域幅より多くの100メガビット/秒を必要とします。

   Because multimedia applications are sensitive to jitter, bandwidth
   and delay, it has been suggested that the networks that carry
   multimedia traffic must be able to allocate and control jitter,
   bandwidth and delay [1,2].

マルチメディア応用がジター、帯域幅、および遅れに敏感であるので、マルチメディアトラフィックを運ぶネットワークがジター、帯域幅、および遅れ[1、2]を割り当てて、制御できなければならないと示唆されました。

   This memo argues that a network which simply controls bandwidth and
   delay is sufficient to support networked multimedia applications.
   Jitter control is not required.

このメモは、単に帯域幅を制御するネットワークと遅れがネットワークでつながれたマルチメディアがアプリケーションであるとサポートするために十分であると主張します。 ジターコントロールは必要ではありません。

Isochrony without Jitter Control

ジターコントロールのない等時性

   The key argument of this memo is that an isochronous service can be
   provided by simply bounding the maximum delay through the network.

このメモの主要な議論はネットワークを通して単にバウンドするのによる最大の遅れを等時性サービスに提供できるということです。

   To prove this argument, consider the following scenario.

この議論を立証するには、以下のシナリオを考えてください。

   The network is able to bound the maximum transit delay on a channel
   between sender and receiver and at least the receiver knows what the
   bound is.  (These assumptions come directly from our assertion that
   the network can bound delay).  The term "channel" is used to mean
   some amount of bandwidth delivered over some path between sender and
   receiver.

ネットワークは最大のトランジットが送付者と受信機の間のチャンネルに遅らせるバウンドにできます、そして、少なくとも受信機はバウンドが何であるかを知っています。 (仮定がネットワークがバウンドできるという直接私たちの主張から来させるこれらは延着します。) 「チャンネル」という用語は、いくらかの量の帯域幅が送付者と受信機の間の何らかの経路を引き渡したことを意味するのに使用されます。

   Now imagine an operating system in which applications can be
   scheduled to be active at regular intervals. Further assume that the
   receiving application has buffer space equal to the channel bandwidth
   times the maximum interarrival variance.  (Observe that the maximum
   interarrival variance is always known - in the worst case, the
   receiver can assume the maximum variance equals the maximum delay).

今度は、アプリケーションが一定の間隔を置いてアクティブである予定である場合があるオペレーティングシステムを想像してください。 受信アプリケーションがバッファ領域が最大のinterarrival変化をチャンネル帯域幅回数との等しさにするとさらに仮定してください。 (最大のinterarrival変化がいつも知られているのを観測してください--最悪の場合には、受信機は、最大の変化が最大の遅れと等しいと仮定できます。)

   Now consider a situation in which the sender of the isochronous data
   timestamps each piece of data when it is generated, using a universal
   time source, and then sends the data to the receiver.  The receiver
   reads a piece data in as soon as it is received and and places the
   timestamped data into its buffer space.  The receiver processes each
   piece of data only at the time equal to the data's timestamp plus the
   maximum transit delay.

今度は、同一時間のデータタイムスタンプの送付者がそれぞれtimestampedデータをバッファ領域にそれが受け取られているので. 受信機が同じくらいすぐ断片データを読み込む受信機にそれがユニバーサルタイムソースを使用して、発生していて、次にデータを送るデータをつなぎあわせて、そして置く状況を考えてください。 受信機は単にデータのタイムスタンプと等しい時間と最大のトランジット遅れでそれぞれのデータを処理します。

   I argue that the receiver is processing data isochronously and thus
   we have shown that a network need not be isochronous to support

受信機が処理データ同一時間であり、その結果、私たちが、ネットワークがサポートすることにおいて同一時間である必要はないことを示したと主張します。

Partridge                                                       [Page 2]

RFC 1257                 Isochronous and Jitter           September 1991

ヤマウズラ[2ページ]RFC1257同一時間とジター1991年9月

   isochronous applications.

同一時間のアプリケーション。

   A few issues have to be resolved to really make this proof stick.

いくつかの問題が、本当にこの証拠棒を作るために解決されなければなりません。

   The first issue is whether the operating system can be expected to
   schedule applications to be active at regular intervals.  I will
   argue that whether or not the network is isochronous, the operating
   system must be able to schedule applications at regular intervals

創刊号はオペレーティングシステムが、アプリケーションが一定の間隔を置いて活発である計画をすると予想できるかどうかということです。 私は、ネットワークが同一時間であるか否かに関係なく、オペレーティングシステムが一定の間隔を置いてアプリケーションの計画をすることができなければならないと主張するつもりです。

   Consider an isochronous network which delivers data with a tight
   bound on jitter.  If the application on the receiving system does not
   wake up when new data arrives, but waits until its next turn in the
   processor, then the isochrony of the network service would be lost
   due to the vagaries of operating system scheduling.  Thus, we may
   reasonably expect that the operating system provides some mechanism
   for waking up the application in response to a network interrupt for
   a particular packet.  But if the operating system can wake up an
   application in response to an interrupt, it can just as easily wake
   the application in response to a clock interrupt at a particular
   time.  Waking up to a clock interrupt provides the regular scheduling
   service we wanted.

きついバウンドがジターにある状態でデータを提供する同一時間のネットワークを考えてください。 受電方式におけるアプリケーションが新しいデータが到着する場合目覚めませんが、プロセッサで次の回転まで待っているなら、ネットワーク・サービスの等時性はオペレーティングシステムスケジューリングの気まぐれのため失われるでしょう。 したがって、私たちは、オペレーティングシステムが特定のパケットのためのネットワーク中断に対応してアプリケーションを起こすのに何らかのメカニズムを提供すると合理的に予想するかもしれません。 しかし、オペレーティングシステムが中断に対応してアプリケーションを起こすことができるなら、それは特定の時間の時計割込みに対応してただ同じくらい容易にアプリケーションを起こすことができます。 時計割込みまで目覚めるのは私たちが欲しかった定期的なスケジューリングサービスを提供します。

   Observe that the last paragraph suggests an application of the End-
   To-End Principle [3].  Given that the operating system must provide a
   mechanism sufficient for restoring isochrony, regardless of whether
   the network is isochronous, it seems unreasonable to require the
   network to redundantly provide the same service.

最後のパラグラフが終わりまでのEnd Principle[3]のアプリケーションを示すのを観測してください。 オペレーティングシステムがネットワークが同一時間であるかどうかにかかわらず等時性を回復するのに十分なメカニズムを提供しなければならないなら、ネットワークが冗長に同じサービスを提供するのが必要であるように無理に思えます。

   Another issue is the question of whether all receiving systems will
   have memory for buffering.  For example, the telephone network is
   required to deliver its data isochronously because many telephones do
   not have memory. However, most receiving devices do have memory, and
   those devices, like telephones, that do not currently have memory
   seem likely to have memory in the future.  Many telephones have a
   modest amount of memory now.  Furthermore, even if the end nodes
   require isochronous traffic it is possible that last switch before
   delivery to the end node could provide the necessary buffer space to
   restore isochrony to the data flow.

別の問題はすべての受電方式にはバッファリングのための記憶力があるかどうかに関する問題です。 例えば、電話網が、多くの電話には記憶力がないのでデータ同一時間を提供するのに必要です。 しかしながら、ほとんどの受信デバイスには、記憶力、および電話のような将来現在メモリを記憶力を持ちそうにないそれらのデバイスがあります。 多くの電話には、現在、穏やかなメモリー容量があります。 その上、エンドノードが同一時間のトラフィックを必要としても、エンドノードへの配送の前のその最後のスイッチが等時性をデータフローに回復するために必要なバッファ領域を提供するかもしれないのは、可能です。

   Readers may wonder if the assumption of a universal time source is
   reasonable.  The Network Time Protocol (NTP) has been widely tested
   on the Internet and is capable of distributing time accurately to the
   millisecond [4].  Its designer is currently contemplating the
   possibility of distributing time accurate to the microsecond.

読者は、ユニバーサルタイムソースの仮定が合理的であるかどうかと思うかもしれません。 Network Timeプロトコル(NTP)は、インターネットで広くテストされて、正確にミリセカンド[4]に時間を分配できます。 デザイナーは現在、マイクロセカンドに正確な時間を分配する可能性を熟考しています。

Some Implications

いくつかの含意

   The most important observation that can be made is that jitter

することができる中で最も重要な観測はそのジターです。

Partridge                                                       [Page 3]

RFC 1257                 Isochronous and Jitter           September 1991

ヤマウズラ[3ページ]RFC1257同一時間とジター1991年9月

   control is not required for networks to be able to support
   isochronous applications.  A corollary observation is that if we are
   to design an internetworking protocol for isochronous applications,
   that internetworking protocol should probably only offer control over
   delay and bandwidth.  (There may exist networks that simply manage
   delay and bandwidth. We know that's sufficient for multimedia
   networking so our multimedia internetworking protocol should be
   capable of running over those networks.  But if the multimedia
   internetworking protocol requires control over jitter too, then
   jitter control must be implemented on those subnetworks that don't
   have it.  Implementing jitter control is clearly feasible - the
   method for restoring jitter in the last section could be used on a
   single network.  But if we know jitter control isn't needed, why
   require networks to implement it?)

ネットワークが同一時間のアプリケーションをサポートすることができるように、コントロールは必要ではありません。 推論観測は私たちが同一時間のアプリケーションのためのインターネットワーキングプロトコルを設計するつもりである場合にだけ、そのインターネットワーキングプロトコルがたぶん遅れと帯域幅のコントロールを提供するべきであるということです。 (単に遅れと帯域幅を管理するネットワークは存在するかもしれません。 私たちが、それがマルチメディアネットワークに十分であることを知っているので、私たちのマルチメディアインターネットワーキングプロトコルはそれらのネットワークをひくことができるべきです。 しかし、マルチメディアインターネットワーキングプロトコルがジターのもコントロールを必要とするなら、ジター管理はそれを持っていないそれらのサブネットワークで実施されなければなりません。 ジターコントロールを実装するのは明確に可能です--ただ一つのネットワークで最後のセクションのジターを回復するためのメソッドを使用できました。 しかし、私たちが、ジターコントロールは必要でないことを知っているなら、なぜネットワークがそれを実装するのが必要ですか?)

   Note that the argument simply says that jitter control is not
   required to support isochronous applications.  It may be the case
   that jitter control is useful for other reasons.  For example, work
   at Berkeley suggests that jitter control makes it possible to reduce
   the amount of buffering required in intermediate network nodes [Y].
   Thus, even if applications express their requirements only in terms
   of bandwidth and delay, a network may find it useful to try to limit
   jitter and thereby reduce the amount of memory required in each node.

議論が、ジターコントロールは同一時間のアプリケーションをサポートするのに必要でないと単に言うことに注意してください。 ジターコントロールが他の理由の役に立つのは、事実であるかもしれません。 例えば、バークレーでの仕事は、ジターコントロールで中間ネットワークノード[Y]で必要であるバッファリングの量を減少させるのが可能になるのを示します。 したがって、アプリケーションが帯域幅と遅れだけに関してそれらの要件を言い表しても、ネットワークによって、ジターを制限して、その結果、各ノードで必要であるメモリー容量を減少させようとするのが役に立つのがわかるかもしれません。

Acknowledgements

承認

   Thanks to the members of the End-To-End Interest mailing list who
   provided a number of invaluable comments on this memo.

このメモの多くの非常に貴重なコメントを提供したEndから終わりへのInterestメーリングリストのメンバーをありがとうございます。

References

参照

   [1] Leiner, B., Editor, "Critical Issues in High Bandwidth
       Networking", Report to DARPA, August 1988.

[1] B.、エディタ、「高帯域ネットワークにおける重要な問題」というLeinerはDARPA、1988年8月に報告します。

   [2] Ferrari, D., "Client Requirements for Real-Time Communication
       Services", IEEE Communications Magazine, November 1990.  See also
       RFC 1193, November, 1990.

[2] フェラーリ、D.、「リアルタイムの通信サービスのためのクライアント要件」、IEEEコミュニケーション雑誌、1990年11月。 また、1990年11月にRFC1193を見てください。

   [3] Saltzer, J., Reed D., and D. Clark, "End-To-End Arguments in
       System Design", ACM Transactions on Computer Systems, Vol. 2, No.
       4, November 1984.

[3] Saltzer(J.)はD.、およびD.クラーク、「システム設計における終わりから終わりへの議論」をアシで飾ります、コンピュータシステムズのACMトランザクション、Vol.2、No.4、1984年11月。

   [4] Mills, D., "Measured Performance of the Network Time Protocol in
       the Internet System", RFC 1128, UDEL, October 1989.

[4] 工場、D.、「インターネットシステムにおける、ネットワーク時間プロトコルの測定パフォーマンス」、RFC1128、UDEL、1989年10月。

   [5] Verma, D., Zhang H., and D. Ferrari. "Guaranteeing Delay Jitter
       Bounds in Packet Switching Networks", Proceedings of TriComm '91,
       Chapel Hill, North Carolina, April 1991.

[5]Verma、D.、チャンH.、およびD.フェラーリ。 「パケット交換網で遅れジター領域を保証します」、TriComm91年、チャペルヒル(ノースカロライナ)4月1991の議事

Partridge                                                       [Page 4]

RFC 1257                 Isochronous and Jitter           September 1991

ヤマウズラ[4ページ]RFC1257同一時間とジター1991年9月

Security Considertaions

セキュリティConsidertaions

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Author's Address

作者のアドレス

   Craig Partridge
   Swedish Institute of Computer Science
   Box 1263
   164 28 Kista
   SWEDEN

クレイグPartridgeスウェーデンのコンピュータ科学協会箱1263の164 28Kistaスウェーデン

   Phone: +46 8 752 1524

以下に電話をしてください。 +46 8 752 1524

   EMail: craig@SICS.SE

メール: craig@SICS.SE

Partridge                                                       [Page 5]

ヤマウズラ[5ページ]