[要約] RFC 4445は、メディア配信指標（MDI）の提案に関するものであり、ネットワークの品質を評価するための指標を定義しています。その目的は、ネットワークのパフォーマンスを測定し、メディア配信の品質を向上させることです。
Network Working Group J. Welch
Request for Comments: 4445 IneoQuest Technologies
Category: Informational J. Clark
Cisco Systems
April 2006
A Proposed Media Delivery Index (MDI)
提案されたメディア配信指数（MDI）
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
IESG Note
IESGノート
This RFC is not a candidate for any level of Internet Standard. There are IETF standards which are highly applicable to the space defined by this document as its applicability, in particular, RFCs 3393 and 3611, and there is ongoing IETF work in these areas as well. The IETF also notes that the decision to publish this RFC is not based on IETF review for such things as security, congestion control, MIB fitness, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCは、インターネット標準のレベルの候補者ではありません。このドキュメントで定義されているスペースに非常に適用できるIETF標準があり、特にRFCS 3393および3611として適用可能であり、これらの分野でも進行中のIETF作業があります。IETFはまた、このRFCを公開する決定は、セキュリティ、混雑制御、MIBフィットネス、展開プロトコルとの不適切な相互作用などのIETFレビューに基づいていないことにも注目しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、RFC 3932を参照してください。
Abstract
概要
This memo defines a Media Delivery Index (MDI) measurement that can be used as a diagnostic tool or a quality indicator for monitoring a network intended to deliver applications such as streaming media, MPEG video, Voice over IP, or other information sensitive to arrival time and packet loss. It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and a data loss at-a-glance measure for a particular flow. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media.
このメモは、ストリーミングメディア、MPEGビデオ、Voice over IP、または到着時間に敏感なその他の情報などのアプリケーションを提供することを目的としたネットワークを監視するための診断ツールまたは品質インジケーターとして使用できるメディア配信インデックス（MDI）測定を定義します。およびパケット損失。これは、トラフィックジッターの兆候、公称流量からの偏差の尺度、および特定のフローのガラス張りでのデータ損失を提供します。たとえば、MDIは、UDPストリーミングメディアを運ぶネットワークの特性評価と比較における参照として使用できます。
The MDI measurement defined in this memo is intended for Information only.
このメモで定義されているMDI測定は、情報のみを対象としています。
There has been considerable progress over the last several years in the development of methods to provide for Quality of Service (QoS) over packet-switched networks to improve the delivery of streaming media and other time-sensitive and packet-loss-sensitive applications such as [i1], [i5], [i6], [i7]. QoS is required for many practical networks involving applications such as video transport to assure the availability of network bandwidth by providing upper limits on the number of flows admitted to a network, as well as to bound the packet jitter introduced by the network. These bounds are required to dimension a receiver`s buffer to display the video properly in real time without buffer overflow or underflow.
過去数年間で、ストリーミングメディアやその他の時間に敏感でパケットに敏感なアプリケーションの提供を改善するために、パケットスイッチされたネットワークよりもサービス品質（QO）を提供する方法の開発がかなりの進歩がありました。[i1]、[i5]、[i6]、[i7]。QoSは、ネットワークに入院したフローの数に上限を提供することにより、ネットワーク帯域幅の可用性を保証するために、ネットワークによって導入されたパケットジッターをバウンドすることにより、ネットワーク帯域幅の可用性を保証するために、ビデオトランスポートなどのアプリケーションを含む多くの実用的なネットワークに必要です。これらの境界は、バッファオーバーフローやアンダーフローなしでリアルタイムでビデオを適切に表示するために、受信者のバッファーを寸法化するために必要です。
Now that large-scale implementations of such networks based on RSVP and Diffserv are undergoing trials [i3] and being specified by major service providers for the transport of streaming media such as MPEG video [i4], there is a need to diagnose issues easily and to monitor the real-time effectiveness of networks employing these QoS methods or to assess whether they are required. Furthermore, due to the significant installed base of legacy networks without QoS methods, a delivery system`s transitional solution may be composed of networks with and without these methods, thus increasing the difficulty in characterizing the dynamic behavior of these networks.
RSVPとDiffServに基づいたこのようなネットワークの大規模な実装が試験を受けており[I3]、MPEGビデオ[I4]などのストリーミングメディアの輸送のために主要なサービスプロバイダーによって指定されているため、問題を簡単に診断する必要があり、これらのQoSメソッドを採用しているネットワークのリアルタイムの有効性を監視するため、またはそれらが必要かどうかを評価するため。さらに、QoSメソッドのないレガシーネットワークの重要なインストールベースにより、配信システムの移行ソリューションは、これらのメソッドの有無にかかわらずネットワークで構成されているため、これらのネットワークの動的な動作を特徴付けることが困難になります。
The purpose of this memo is to describe a set of measurements that can be used to derive a Media Delivery Index (MDI) that indicates the instantaneous and longer-term behavior of networks carrying streaming media such as MPEG video.
このメモの目的は、MPEGビデオなどのストリーミングメディアを運ぶネットワークの瞬間的および長期的な動作を示すメディア配信インデックス（MDI）を導出するために使用できる一連の測定値を記述することです。
While this memo addresses monitoring MPEG Transport Stream (TS) packets [i8] over UDP, the general approach is expected to be applicable to other streaming media and protocols. The approach is applicable to both constant and variable bit rate streams though the variable bit rate case may be somewhat more difficult to calculate. This document focuses on the constant bit rate case as the example to describe the measurement, but as long as the dynamic bit rate of the encoded stream can be determined (the "drain rate" as described below in Section 3), then the MDI provides the measurement of network-induced cumulative jitter. Suggestions and direction for calculation of MDI for a variable bit rate encoded stream may be the subject of a future document.
このメモは、UDPを介したMPEGトランスポートストリーム（TS）パケット[i8]の監視に対処していますが、一般的なアプローチは他のストリーミングメディアおよびプロトコルに適用できると予想されます。このアプローチは、一定のビットレートストリームと可変ビットレートストリームの両方に適用できますが、可変ビットレートのケースは計算がやや困難になる場合があります。このドキュメントは、測定を説明する例として一定のビットレートのケースに焦点を当てていますが、エンコードされたストリームの動的ビットレートを決定できる限り（セクション3で説明する「ドレインレート」）、MDIは提供しますネットワーク誘導累積ジッターの測定。可変ビットレートエンコードストリームのMDIを計算するための提案と方向は、将来のドキュメントの対象となる可能性があります。
Network packet delivery time variation and various statistics to characterize the same are described in a generic approach in [i10]. The approach is capable of being parameterized for various purposes with the intent of defining a flexible, customizable definition that can be applied to a wide range of applications and further experimentation. Other approaches to characterizing jitter behavior are also captured such as in [i12]. A wide-ranging report format [i11] has been described to convey information including jitter for use with the RTP Control Protocol (RTCP) [i12]. The MDI is instead intended to specifically address the need for a scalable, economical-to-compute metric that characterizes network impairments that may be imposed on streaming media, independent of control plane or measurement transport protocol or stream encapsulation protocol. It is a targeted metric for use in production networks carrying large numbers of streams for the purpose of monitoring the network quality of the flows or for other applications intended to analyze large numbers of streams susceptible to IP network device impairments. An example application is the burgeoning deployments of Internet Protocol Television (IPTV) by cable and telecommunication service providers. As described below, MDI provides for a readily scalable per-stream measure focused on loss and the cumulative effects of jitter.
ネットワークパケット配信時間の変動と同じことを特徴付けるさまざまな統計は、[i10]の一般的なアプローチで説明されています。このアプローチは、幅広いアプリケーションとさらなる実験に適用できる柔軟でカスタマイズ可能な定義を定義する目的で、さまざまな目的のためにパラメーター化することができます。[I12]のように、ジッターの動作を特徴付ける他のアプローチもキャプチャされます。RTPコントロールプロトコル（RTCP）で使用するためにジッターを含む情報を伝えるために、広範囲のレポート形式[I11]が報告されています[I12]。代わりに、MDIは、コントロールプレーンまたは測定輸送プロトコルまたはストリームカプセル化プロトコルとは無関係に、ストリーミングメディアに課される可能性のあるネットワーク障害を特徴付けるスケーラブルで経済的な計算メトリックの必要性に特に対処することを目的としています。これは、フローのネットワーク品質を監視する目的で、またはIPネットワークデバイスの障害を受けやすい多数のストリームを分析する他のアプリケーションのために、多数のストリームを運ぶ生産ネットワークで使用するターゲットメトリックです。アプリケーションの例は、ケーブルおよび通信サービスプロバイダーによるインターネットプロトコルテレビ（IPTV）の急成長する展開です。以下で説明するように、MDIは、損失とジッターの累積効果に焦点を当てた容易にスケーラブルなストリームごとのメジャーを提供します。
The MDI provides a relative indicator of needed buffer depths at the consumer node due to packet jitter as well as an indication of lost packets. By probing a streaming media service network at various nodes and under varying load conditions, it is possible to quickly identify devices or locales that introduce significant jitter or packet loss to the packet stream. By monitoring a network continuously, deviations from nominal jitter or loss behavior can be used to indicate an impending or ongoing fault condition such as excessive load. It is believed that the MDI provides the necessary information to detect all network-induced impairments for streaming video or voice-over-IP applications. Other parameters may be required to troubleshoot and correct the impairments.
MDIは、パケットジッターのために、消費者ノードで必要なバッファーの深さの相対的な指標と、失われたパケットの指標を提供します。さまざまなノードでストリーミングメディアサービスネットワークを調査し、さまざまな負荷条件下で調査することにより、パケットストリームに重要なジッターまたはパケット損失を導入するデバイスまたはロケールをすばやく識別することができます。ネットワークを継続的に監視することにより、公称ジッターまたは損失行動からの逸脱を使用して、過度の負荷などの差し迫ったまたは進行中の障害状態を示すことができます。MDIは、ビデオまたはボイスオーバーIPアプリケーションのストリーミングにすべてのネットワーク誘導障害を検出するために必要な情報を提供すると考えられています。障害のトラブルシューティングと修正には、他のパラメーターが必要になる場合があります。
The MDI is updated at the termination of selected time intervals spanning multiple packets that contain the streaming media (such as transport stream packets in the MPEG-2 case). The Maximums and Minimums of the MDI component values are captured over a measurement time. The measurement time may range from just long enough to capture an anticipated network anomaly during a troubleshooting exercise to indefinitely long for a long-term monitoring or logging application. The Maximums and Minimums may be obtained by sampling the measurement with adequate frequency.
MDIは、ストリーミングメディア（MPEG-2ケースの輸送ストリームパケットなど）を含む複数のパケットにまたがる選択された時間間隔の終了時に更新されます。MDIコンポーネント値の最大値と最小値は、測定時間にわたってキャプチャされます。測定時間は、トラブルシューティング中に予想されるネットワークの異常をキャプチャするのに十分な長さから、長期的な監視またはロギングアプリケーションの無期限に長いまでの範囲です。適切な周波数で測定値をサンプリングすることにより、最大値と最小値を取得できます。
The MDI consists of two components: the Delay Factor (DF) and the Media Loss Rate (MLR).
MDIは、遅延係数（DF）と媒体損失率（MLR）の2つのコンポーネントで構成されています。
The Delay Factor is the maximum difference, observed at the end of each media stream packet, between the arrival of media data and the drain of media data. This assumes the drain rate is the nominal constant traffic rate for constant bit rate streams or the piece-wise computed traffic rate of variable rate media stream packet data. The "drain rate" here refers to the payload media rate; e.g., for a typical 3.75 Mb/s MPEG video Transport Stream (TS), the drain rate is 3.75 Mb/s -- the rate at which the payload is consumed (displayed) at a decoding node. If, at the sample time, the number of bytes received equals the number transmitted, the instantaneous flow rate balance will be zero; however, the minimum DF will be a line packet's worth of media data, as that is the minimum amount of data that must be buffered.
遅延係数は、メディアデータの到着とメディアデータの排出の間に、各メディアストリームパケットの最後に観察される最大差です。これは、ドレインレートが、一定のビットレートストリームの名目上のトラフィックレートまたは、可変レートメディアストリームパケットデータのピースごとの計算されたトラフィックレートであることを前提としています。ここでの「排水率」は、ペイロードメディアレートを指します。たとえば、典型的な3.75 MB/s MPEGビデオトランスポートストリーム（TS）の場合、ドレインレートは3.75 MB/sです。デコードノードでペイロードが消費される（表示）レートです。サンプル時間で、受信したバイト数が送信された数に等しい場合、瞬時流量バランスはゼロになります。ただし、最小のDFは、バッファリングする必要があるデータの最小量であるため、ラインパケットのメディアデータに相当するメディアデータになります。
The DF is the maximum observed value of the flow rate imbalance over a calculation interval. This buffered media data in bytes is expressed in terms of how long, in milliseconds, it would take to drain (or fill) this data at the nominal traffic rate to obtain the DF. Display of DF with a resolution of tenths of milliseconds is recommended to provide adequate indication of stream variations for monitoring and diagnostic applications for typical stream rates from 1 to 40 Mb/s. The DF value must be updated and displayed at the end of a selected time interval. The selected time interval is chosen to be long enough to sample a number of TS packets and will, therefore, vary based on the nominal traffic rate. For typical stream rates of 1 Mb/s and up, an interval of 1 second provides a long enough sample time and should be included for all implementations. The Delay Factor indicates how long a data stream must be buffered (i.e., delayed) at its nominal bit rate to prevent packet loss. This time may also be seen as a measure of the network latency that must be induced from buffering, which is required to accommodate stream jitter and prevent loss. The DF`s max and min over the measurement period (multiple intervals) may also be displayed to show the worst case arrival time deviation, or jitter, relative to the nominal traffic rate in a measurement period. It provides a dynamic flow rate balance indication with its max and min showing the worst excursions from balance.
DFは、計算間隔にわたる流量の不均衡の最大観測値です。このバイテでのバッファリングされたメディアデータは、ミリ秒単位でどれだけの期間で表現され、DFを取得するためにこのデータを公称トラフィックレートで排出（または埋める）にかかります。1〜40 mb/sの典型的なストリームレートの監視および診断アプリケーションの診断アプリケーションのストリームバリエーションの適切な兆候を提供するには、10分の1ミリ秒のDFの表示をお勧めします。DF値は、選択した時間間隔の最後に更新および表示する必要があります。選択した時間間隔は、多くのTSパケットをサンプリングするのに十分な長さであるように選択されるため、公称トラフィック率によって異なります。1 MB/s以上の典型的なストリームレートの場合、1秒の間隔は十分に長いサンプル時間を提供し、すべての実装に含める必要があります。遅延係数は、パケットの損失を防ぐために、公称ビットレートでデータストリームをバッファリング（つまり、遅延）する必要があるかどうかを示します。今回は、バッファリングから誘導されなければならないネットワークレイテンシの尺度と見なされる場合があります。これは、ストリームジッターに対応し、損失を防ぐために必要です。測定期間（複数の間隔）にわたるDFの最大および最小も表示され、測定期間の公称交通率に比べて最悪の到着時間偏差またはジッターを示すことができます。最大値と最小のバランスからの最悪の遠足を示す動的流量バランスの表示を提供します。
The Delay Factor gives a hint of the minimum size of the buffer required at the next downstream node. As a stream progresses, the variation of the Delay Factor indicates packet bunching or packet gaps (jitter). Greater DF values also indicate that more network latency is necessary to deliver a stream due to the need to pre-fill a receive buffer before beginning the drain to guarantee no underflow. The DF comprises a fixed part based on packet size and a variable part based on the buffer utilization of the various network component switch elements that comprise the switched network infrastructure [i2].
遅延係数は、次の下流ノードで必要なバッファーの最小サイズのヒントを提供します。ストリームが進むにつれて、遅延係数のバリエーションは、パケットバンチングまたはパケットギャップ（ジッター）を示します。DFの値が大きいほど、排水を開始する前に受信バッファーを事前に充填する必要があるため、ストリームを提供するためにストリームを提供するには、より多くのネットワークレイテンシが必要であることも示しています。DFは、パケットサイズに基づいた固定部品と、スイッチされたネットワークインフラストラクチャを構成するさまざまなネットワークコンポーネントスイッチ要素のバッファ使用に基づく可変部品を含む[I2]。
To further detail the calculation of DF, consider a virtual buffer VB used to buffer received packets of a stream. When a packet P(i) arrives during a calculation interval, compute two VB values, VB(i,pre) and VB(i,post), defined as:
DFの計算をさらに詳しく説明するために、ストリームの受信パケットをバッファするために使用される仮想バッファVBを検討してください。計算間隔中にパケットp（i）が到着すると、2つのVB値、VB（i、pre）とVB（i、post）を計算します。
VB(i,pre) = sum (Sj) - MR * Ti; where j=1..i-1
VB(i,post) = VB(i,pre) + Si
where Sj is the media payload size of the jth packet, Ti is the relative time at which packet i arrives in the interval, and MR is the nominal media rate.
ここで、SJはJTHパケットのメディアペイロードサイズであり、TIは私が間隔で到着するパケットが相対的な時間であり、MRは名目メディアレートです。
VB(i,pre) is the Virtual Buffer size just before the arrival of P(i). VB(i,post) is the Virtual Buffer size just after the arrival of P(i).
VB（i、pre）は、p（i）の到着直前の仮想バッファサイズです。VB（i、post）は、p（i）の到着直後の仮想バッファサイズです。
The initial condition of VB(0) = 0 is used at the beginning of each measurement interval. A measurement interval is defined from just after the time of arrival of the last packet during a nominal period (typically 1 second) as mentioned above to the time just after the arrival of the last packet of the next nominal period.
VB（0）= 0の初期条件は、各測定間隔の開始時に使用されます。測定間隔は、次の公称期間の最後のパケットが到着した直後の上記のように、公称期間（通常1秒）の最後のパケットの到着時から定義されます。
During a measurement interval, if k packets are received, then there are 2*k+1 VB values used in deriving VB(max) and VB(min). After determining VB(max) and VB(min) from the 2k+1 VB samples, DF for the measurement interval is computed and displayed as:
測定間隔中、Kパケットを受信した場合、VB（MAX）およびVB（MIN）の導出で2*K 1 VB値が使用されます。2K 1 VBサンプルからVB（MAX）およびVB（MIN）を決定した後、測定間隔のDFが計算され、次のように表示されます。
DF = [VB(max) - VB(min)]/ MR
As noted above, a measurement interval of 1 second is typically used. If no packets are received during an interval, the last DF calculated during an interval in which packets did arrive is displayed. The time of arrival of the last previous packet is always retained for use in calculating VB when the next packet arrives (even if the time of the last received packet spans measurement intervals). For the first received measurement interval of a measurement period, no DF is calculated; however, packet arrival times are recorded for use in calculating VB during the following interval.
上記のように、通常、1秒の測定間隔が使用されます。間隔中にパケットが受信されない場合、パケットが到着した間隔中に計算された最後のDFが表示されます。最後の前のパケットの到着時間は、次のパケットが到着したときにVBの計算に使用するために常に保持されます（最後に受信したパケットの時間が測定間隔を拡大する場合でも）。測定期間の最初の受信した測定間隔では、DFは計算されません。ただし、パケットの到着時間は、次の間隔でVBの計算に使用するために記録されます。
The Media Loss Rate is the count of lost or out-of-order flow packets over a selected time interval, where the flow packets are packets carrying streaming application information. There may be zero or more streaming packets in a single IP packet. For example, it is common to carry seven 188 Byte MPEG Transport Stream packets in an IP packet. In such a case, a single IP packet loss would result in 7 lost packets counted (if those 7 lost packets did not include null packets). Including out-of-order packets is important, as many stream consumer-type devices do not attempt to reorder packets that are received out of order.
メディアの損失率は、選択された時間間隔にわたって失われたまたはオーバー外のフローパケットのカウントであり、フローパケットはストリーミングアプリケーション情報を運ぶパケットです。単一のIPパケットにゼロ以上のストリーミングパケットがある場合があります。たとえば、IPパケットに7つの188バイトMPEGトランスポートストリームパケットを携帯することが一般的です。そのような場合、単一のIPパケット損失は、7つの失われたパケットがカウントされると、7つの失われたパケットにNULLパケットが含まれていなかった場合）。多くのStream Consumer-Typeデバイスは、順番に受信されたパケットを並べ替えようとしないため、オーダーアウトパケットを含めることが重要です。
Combining the Delay Factor and Media Loss Rate quantities for presentation results in the following MDI:
プレゼンテーションのための遅延係数とメディア損失率の量を組み合わせると、次のMDIが得られます。
DF:MLR Where: DF is the Delay Factor MLR is the Media Loss Rate
DF：MLRここで：DFは遅延係数MLRがメディアの損失率です
At a receiving node, knowing its nominal drain bit rate, the DF`s max indicates the size of buffer required to accommodate packet jitter. Or, in terms of Leaky Bucket [i9] parameters, DF indicates bucket size b, expressed in time to transmit bucket traffic b, at the given nominal traffic rate, r.
受信ノードでは、名目上のドレインビットレートを知っているDFの最大値は、パケットジッターに対応するために必要なバッファーのサイズを示します。または、漏れやすいバケツ[i9]パラメーターに関しては、DFはバケットサイズBを示します。
If a known, well-characterized receive node is separated from the data source by unknown or less well-characterized nodes such as intermediate switch nodes, the MDI measured at intermediate data links provides a relative indication of the behavior of upstream traffic flows. DF difference indications between one node and another in a data stream for a given constant interval of calculation can indicate local areas of traffic congestion or possibly misconfigured QoS flow specification(s) leading to greater filling of measurement point local device buffers, resultant flow rate deviations, and possible data loss.
既知の適切に特性化された受信ノードが、中間スイッチノードなどの未知のまたはあまり明確に特性化されていないノードによってデータソースから分離されている場合、中間データリンクで測定されたMDIは、上流のトラフィックフローの動作の相対的な指標を提供します。DFの違い指定されたノードと別のノード間の特定の計算間隔のデータストリームの別のノードは、測定ポイントのローカルデバイスバッファーのより大きな充填につながる交通渋滞のローカル領域または誤解されたQoSフロー仕様を示すことができます。、および可能なデータ損失。
For a given MDI, if DF is high and/or the DF Max-Min captured over a significant measurement period of multiple intervals is high, jitter has been detected but the longer-term, average flow rate may be nominal. This could be the result of a transient flow upset due to a coincident traffic stream unrelated to the flow of interest causing packet bunching. A high DF may cause downstream buffer overflow or underflow or unacceptable latency even in the absence of lost data.
特定のMDIの場合、DFが高く、および/または複数の間隔のかなりの測定期間にわたってキャプチャされたDF Max-Minが高い場合、ジッターは検出されましたが、長期の平均流量は名目上である可能性があります。これは、パケットバンチングを引き起こす関心の流れとは無関係の偶然のトラフィックストリームのために、一時的な流れの動揺の結果である可能性があります。高DFは、失われたデータがない場合でも、下流のバッファーオーバーフローまたはアンダーフロー、または容認できないレイテンシを引き起こす可能性があります。
Due to transient network failures or DF excursions, packets may be lost within the network. The MLR component of the MDI shows this condition.
一時的なネットワークの障害またはDFの遠足により、ネットワーク内でパケットが失われる可能性があります。MDIのMLR成分は、この状態を示しています。
Through automated or manual flow detection and identification and subsequent MDI calculations for real-time statistics on a flow, the DF can indicate the dynamic deterioration or increasing burstiness of a flow, which can be used to anticipate a developing network operation problem such as transient oversubscription. Such statistics can be obtained for flows within network switches using available switch cpu resources due to the minimal computational requirements needed for small numbers of flows. Statistics for all flows present on, say, a gigabit Ethernet network, will likely require dedicated hardware facilities, though these can be modest, as buffer requirements and the required calculations per flow are minimal. By equipping network switches with MDI measurements, flow impairment issues can quickly be identified, localized, and corrected. Until switches are so equipped with appropriate hardware resources, dedicated hardware tools can provide supplemental switch statistics by gaining access to switch flows via mirror ports, link taps, or the like as a transition strategy.
フローのリアルタイム統計のための自動または手動のフロー検出と識別とその後のMDI計算により、DFは動的な劣化または増加する流れの増加を示すことができます。。このような統計は、少数のフローに必要な最小限の計算要件により、利用可能なスイッチCPUリソースを使用してネットワークスイッチ内のフローについて取得できます。たとえば、ギガビットイーサネットネットワークに存在するすべてのフローの統計には、専用のハードウェア施設が必要になる可能性がありますが、バッファー要件とフローあたりの必要な計算は最小限であるため、これらは控えめです。ネットワークスイッチにMDI測定を装備することにより、フロー障害の問題を迅速に識別し、局在化し、修正できます。スイッチに適切なハードウェアリソースが装備されるまで、専用のハードウェアツールは、ミラーポート、リンクタップなどを介したスイッチフローへのアクセスを取得することにより、補足スイッチ統計を提供できます。
The MDI figure can also be used to characterize a flow decoder's acceptable performance. For example, an MPEG decoder could be characterized as tolerating a flow with a given maximum DF and MLR for acceptable display performance (acceptable on-screen artifacts). Network conditions such as Interior Gateway Protocol (IGP) reconvergence time then might also be included in the flow tolerance DF resulting in a higher-quality user experience.
MDIフィギュアは、フローデコーダーの許容パフォーマンスを特徴付けるためにも使用できます。たとえば、MPEGデコーダーは、許容可能なディスプレイパフォーマンス（許容可能な画面上のアーティファクト）のために、特定の最大DFとMLRでフローを許容するものとして特徴付けられます。インテリアゲートウェイプロトコル（IGP）の再変換時間などのネットワーク条件は、フロートレランスDFにも含まれ、高品質のユーザーエクスペリエンスが発生する可能性があります。
The MDI combines the Delay Factor, which indicates potential for impending data loss, and Media Loss Rate as the indicator of lost data. By monitoring the DF and MLR and their min and max excursions over a measurement period and at multiple strategic locations in a network, traffic congestion or device impairments may be detected and isolated for a network carrying streaming media content.
MDIは遅延係数を組み合わせます。これは、差し迫ったデータ損失の可能性と、メディアの損失率が失われたデータの指標として示されます。測定期間中およびネットワーク内の複数の戦略的位置でDFとMLR、およびそれらのMINおよびMAXの遠足を監視することにより、ストリーミングメディアコンテンツを運ぶネットワークの交通渋滞またはデバイスの障害を検出および分離することができます。
The measurements identified in this document do not directly affect the security of a network or user. Actions taken in response to these measurements that may affect the available bandwidth of the network or the availability of a service is out of scope for this document.
このドキュメントで特定された測定値は、ネットワークまたはユーザーのセキュリティに直接影響しません。ネットワークの利用可能な帯域幅またはサービスの可用性に影響を与える可能性のあるこれらの測定に応じて取られたアクションは、このドキュメントの範囲外です。
Performing the measurements described in this document only requires examination of payload header information (such as MPEG transport stream headers or RTP headers) to determine nominal stream bit rate and sequence number information. Content may be encrypted without affecting these measurements. Therefore, content privacy is not expected to be a concern.
このドキュメントで説明されている測定値を実行するには、名目上のストリームビットレートとシーケンス番号情報を決定するために、ペイロードヘッダー情報（MPEGトランスポートストリームヘッダーやRTPヘッダーなど）を調べる必要があります。コンテンツは、これらの測定に影響を与えることなく暗号化される場合があります。したがって、コンテンツのプライバシーは懸念事項であるとは期待されていません。
[i1] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[i1] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[i2] Partridge, C., "A Proposed Flow Specification", RFC 1363, September 1992.
[i2] Partridge、C。、「提案されたフロー仕様」、RFC 1363、1992年9月。
[i3] R. Fellman, `Hurdles to Overcome for Broadcast Quality Video Delivery over IP` VidTranS 2002.
[i3] R.フェルマン、「IP Vidtrans 2002での放送品質のビデオ配信のために克服するハードル。
[i4] CableLabs `PacketCable Dynamic Quality-of-Service Specification`, PKT-SP-DQOS-I06-030415, 2003.
[i4] cablelabs `packetcable dynamic of-service specification」、pkt-sp-dqos-i06-030415、2003。
[i5] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[i5] Shenker、S.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[i6] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[i6] Wroclawski、J。、「制御されたロードネットワーク要素サービスの仕様」、RFC 2211、1997年9月。
[i7] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[i7] Braden、R.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。
[i8] ISO/IEC 13818-1 (MPEG-2 Systems)
[i8] ISO/IEC 13818-1（MPEG-2システム）
[i9] V. Raisanen, "Implementing Service Quality in IP Networks", John Wiley & Sons Ltd., 2003.
[i9] V. Raisanen、「IPネットワークのサービス品質の実装」、John Wiley＆Sons Ltd.、2003。
[i10] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[I10] Demichelis、C。およびP. Chimento、「IPパフォーマンスメトリック（IPPM）のIPパケット遅延変動メトリック」、RFC 3393、2002年11月。
[i11] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[I11] Friedman、T.、Caceres、R。、およびA. Clark、「RTPコントロールプロトコル拡張レポート（RTCP XR）」、RFC 3611、2003年11月。
[i12] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[i12] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
The authors gratefully acknowledge the contributions of Marc Todd and Jesse Beeson of IneoQuest Technologies, Inc., Bill Trubey and John Carlucci of Time Warner Cable, Nishith Sinha of Cox Communications, Ken Chiquoine of SeaChange International, Phil Proulx of Bell Canada, Dr Paul Stallard of TANDBERG Television, Gary Hughes of Broadbus Technologies, Brad Medford of SBC Laboratories, John Roy of Adelphia Communications, Cliff Mercer, PhD of Kasenna, Mathew Ho of Rogers Cable, and Irl Duling of Optinel Systems for reviewing and evaluating early versions of this document and implementations for MDI.
著者は、Ineoquest Technologies、Inc。のMarc ToddとJesse Beeson、Bill Trubey、Time Warner CableのJohn Carlucci、Cox CommunicationsのNishith SinhaのJohn Carlucciの貢献に感謝します。Tandberg Television、Gary Hughes of Broadbus Technologies、SBC LaboratoriesのBrad Medford、Adelphia CommunicationsのJohn Roy、Cliff Mercer、Kasennaの博士号、Rogers CableのMathew Ho、およびこの文書の初期バージョンのレビューと評価のためのOptinel SystemsのIRL DulingおよびMDIの実装。
Authors' Addresses
著者のアドレス
James Welch IneoQuest Technologies, Inc 170 Forbes Blvd Mansfield, Massachusetts 02048
James Welch Ineoquest Technologies、Inc 170 Forbes Blvd Mansfield、Massachusetts 02048
Phone: 508 618 0312 EMail: Jim.Welch@ineoquest.com
電話：508 618 0312メール：jim.welch@ineoquest.com
James Clark Cisco Systems, Inc 500 Northridge Road Suite 800 Atlanta, Georgia 30350
ジェームズクラークシスコシステム、INC 500ノースリッジロードスイート800ジョージア州アトランタ30350
Phone: 678 352 2726 EMail: jiclark@cisco.com
電話：678 352 2726メール：jiclark@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびwww.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、その中に記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。