[要約] RFC 2354は、ストリーミングメディアの修復オプションに関するガイドラインです。その目的は、ストリーミングメディアの品質を向上させ、ユーザーエクスペリエンスを向上させることです。
Network Working Group C. Perkins
Request for Comments: 2354 O. Hodson
Category: Informational University College London
June 1998
Options for Repair of Streaming Media
ストリーミングメディアの修復オプション
Status of this Memo
本文書の状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。このメモは、いかなる種類のインターネット標準も指定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. The techniques discussed include redundant transmission, retransmission, interleaving and forward error correction. The range of applicability of these techniques is noted, together with the protocol requirements and dependencies.
このドキュメントでは、パケット損失の影響を受けやすい連続メディアストリームを修復するためのさまざまな可能な手法をまとめています。説明する手法には、冗長な送信、再送信、インターリーブ、および前方誤り訂正が含まれます。これらの手法の適用範囲は、プロトコルの要件と依存関係とともに示されています。
1 Introduction
1はじめに
A number of applications have emerged which use RTP/UDP transport to deliver continuous media streams. Due to the unreliable nature of UDP packet delivery, the quality of the received stream will be adversely affected by packet loss. A number of techniques exist by which the effects of packet loss may be repaired. These techniques have a wide range of applicability and require varying degrees of protocol support. In this document, a number of such techniques are discussed, and recommendations for their applicability made.
RTP / UDPトランスポートを使用して連続メディアストリームを配信する多くのアプリケーションが登場しています。 UDPパケット配信の信頼性が低いため、受信ストリームの品質は、パケット損失によって悪影響を受けます。パケット損失の影響を修復できるいくつかの手法が存在します。これらの手法には幅広い適用範囲があり、さまざまな程度のプロトコルサポートが必要です。このドキュメントでは、このような手法の多くについて説明し、その適用性に関する推奨事項を示します。
It should be noted that this document is introductory in nature, and does not attempt to be comprehensive. In particular, we restrict our discussion to repair techniques which require the involvement of the sender of a media stream, and do not discuss possibilities for receiver based repair.
このドキュメントは本質的に導入であり、包括的であることを意図していないことに注意してください。特に、メディアストリームの送信者の関与を必要とする修復手法に限定して説明し、受信者ベースの修復の可能性については触れません。
For a more detailed survey, the reader is referred to [5].
より詳細な調査については、読者は[5]を参照してください。
2 Terminology and Protocol Framework
2用語とプロトコルフレームワーク
A unit is defined to be a timed interval of media data, typically derived from the workings of the media coder. A packet comprises one or more units, encapsulated for transmission over the network. For example, many audio coders operate on 20ms units, which are typically combined to produce 40ms or 80ms packets for transmission. The framework of RTP [18] is assumed. This implies that packets have a sequence number and timestamp. The sequence number denotes the order in which packets are transmitted, and is used to detect losses. The timestamp is used to determine the playout order of units. Most loss recovery schemes rely on units being sent out of order, so an application must use the RTP timestamp to schedule playout.
ユニットは、メディアデータの時間間隔で定義され、通常、メディアコーダーの動作から導出されます。パケットは、ネットワーク経由で送信するためにカプセル化された1つ以上のユニットで構成されます。たとえば、多くのオーディオコーダーは20ミリ秒のユニットで動作します。これらは通常、40ミリ秒または80ミリ秒のパケットを送信用に生成するために結合されます。 RTP [18]のフレームワークを想定しています。これは、パケットにシーケンス番号とタイムスタンプがあることを意味します。シーケンス番号は、パケットが送信される順序を示し、損失を検出するために使用されます。タイムスタンプは、ユニットのプレイアウト順序を決定するために使用されます。ほとんどの損失回復スキームは、ユニットが順不同で送信されることに依存しているため、アプリケーションはRTPタイムスタンプを使用してプレイアウトをスケジュールする必要があります。
The use of RTP allows for several different media coders, with a payload type field being used to distinguish between these at the receiver. Some loss repair schemes send multiple copies of units, at different times and possibly with different encodings, to increase the probability that a receiver has something to decode. A receiver is assumed to have a `quality' ranking of the differing encodings, and so is capable of choosing the `best' unit for playout, given multiple options.
RTPを使用すると、いくつかの異なるメディアコーダーが可能になります。ペイロードタイプフィールドは、レシーバーでこれらを区別するために使用されます。一部の損失修復スキームでは、受信機がデコードするものを持っている可能性を高めるために、ユニットの複数のコピーを異なる時間に、場合によっては異なるエンコーディングで送信します。レシーバーは、さまざまなエンコーディングの「品質」ランキングを持っていると想定されているため、複数のオプションを指定すると、再生に「最適」なユニットを選択できます。
A session is defined as interactive if the end-to-end delay is less then 250ms, including media coding and decoding, network transit and host buffering.
エンドツーエンドの遅延が250ミリ秒未満の場合、セッションはインタラクティブであると定義されます。
3 Network Loss Characteristics
3ネットワーク損失特性
If it is desired to repair a media stream subject to packet loss, it is useful to have some knowledge of the loss characteristics which are likely to be encountered. A number of studies have been conducted on the loss characteristics of the Mbone [2, 8, 21] and although the results vary somewhat, the broad conclusion is clear: in a large conference it is inevitable that some receivers will experience packet loss. Packet traces taken by Handley [8] show a session in which most receivers experience loss in the range 2-5%, with a somewhat smaller number seeing significantly higher loss rates. Other studies have presented broadly similar results.
パケット損失の影響を受けやすいメディアストリームを修復する必要がある場合は、遭遇する可能性が高い損失特性をある程度知っていると役立ちます。 Mboneの損失特性について多くの調査が行われ[2、8、21]、結果は多少異なりますが、幅広い結論は明らかです。大規模な会議では、一部の受信者がパケット損失を経験することは避けられません。 Handley [8]が取得したパケットトレースは、ほとんどのレシーバーで2〜5％の範囲の損失が発生するセッションを示しています。やや小さい数値で、損失率が大幅に高くなっています。他の研究は広く類似した結果を示しています。
It has also been shown that the vast majority of losses are of single packets. Burst losses of two or more packets are around an order of magnitude less frequent than single packet loss, although they do occur more often than would be expected from a purely random process. Longer burst losses (of the order of tens of packets) occur infrequently. These results are consistent with a network where small amounts of transient congestion cause the majority of packet loss. In a few cases, a network link is found to be severely overloaded, and large amount of loss results.
損失の大部分は単一のパケットによるものであることも示されています。 2つ以上のパケットのバースト損失は、単一のパケット損失よりも桁違いに少なく、純粋にランダムなプロセスから予想されるよりも頻繁に発生します。 （数十パケット程度の）長いバースト損失はまれにしか発生しません。これらの結果は、少量の一時的な輻輳がパケット損失の大部分を引き起こすネットワークと一致しています。いくつかのケースでは、ネットワークリンクが非常に過負荷であることが判明し、大量の損失が発生します。
The primary focus of a repair scheme must, therefore, be to correct single packet loss, since this is by far the most frequent occurrence. It is desirable that losses of a relatively small number of consecutive packets may also be repaired, since such losses represent a small but noticeable fraction of observed losses. The correction of large bursts of loss is of considerably less importance.
したがって、これが最も頻繁に発生するので、修復スキームの主な焦点は単一のパケット損失を修正することです。比較的少数の連続したパケットの損失も修復できることが望ましい。そのような損失は、観測された損失のわずかではあるが顕著な割合を表すからである。大量の損失の訂正は、それほど重要ではありません。
4 Loss Mitigation Schemes
4損失軽減スキーム
In the following sections, four loss mitigation schemes are discussed. These schemes have been discussed in the literature a number of times, and found to be of use in a number of scenarios. Each technique is briefly described, and its advantages and disadvantages noted.
次のセクションでは、4つの損失軽減スキームについて説明します。これらのスキームは、文献で何度も議論されており、多くのシナリオで役立つことがわかりました。各手法について簡単に説明し、その長所と短所を示します。
Retransmission of lost packets is an obvious means by which loss may be repaired. It is clearly of value in non-interactive applications, with relaxed delay bounds, but the delay imposed means that it does not typically perform well for interactive use.
失われたパケットの再送信は、損失を修復できる明白な手段です。遅延の範囲が緩和された非対話型アプリケーションでは明らかに価値がありますが、課せられた遅延は、対話型の使用では通常十分に機能しないことを意味します。
In addition to the possibly high latency, there is a potentially large bandwidth overhead to the use of retransmission. Not only are units of data sent multiple times, but additional control traffic must flow to request the retransmission. It has been shown that, in a large Mbone session, most packets are lost by at least one receiver [8]. In this case the overhead of requesting retransmission for most packets may be such that the use of forward error correction is more acceptable. This leads to a natural synergy between the two mechanisms, with a forward error correction scheme being used to repair all single packet losses, and those receivers experiencing burst losses, and willing to accept the additional latency, using retransmission based repair as an additional recovery mechanism. Similar mechanisms have been used in a number of reliable multicast schemes, and have received some discussion in the literature [9, 13].
レイテンシが長くなる可能性があることに加えて、再送信を使用すると帯域幅のオーバーヘッドが大きくなる可能性があります。データの単位が複数回送信されるだけでなく、追加の制御トラフィックがフローして再送信を要求する必要があります。大規模なMboneセッションでは、ほとんどのパケットが少なくとも1つのレシーバーによって失われることが示されています[8]。この場合、ほとんどのパケットの再送信を要求するオーバーヘッドは、前方誤り訂正の使用がより受け入れられるほどのものになる可能性があります。これにより、2つのメカニズム間の自然な相乗効果が得られます。フォワードエラー訂正スキームを使用して、すべての単一パケット損失と、バースト損失が発生している受信者が受信し、追加の回復メカニズムとして再送信ベースの修復を使用して、追加のレイテンシを受け入れます。 。同様のメカニズムが多くの信頼できるマルチキャスト方式で使用されており、文献[9、13]でいくつかの議論を受けています。
In order to reduce the overhead of retransmission, the retransmitted units may be piggy-backed onto the ongoing transmission, using a payload format such as that described in [15]. This also allows for the retransmission to be recoded in a different format, to further reduce the bandwidth overhead. As an alternative, FEC information may be sent in response to retransmission requests [13], allowing a single retransmission to potentially repair several losses. The choice of a retransmission request algorithm which is both timely and network friendly is an area of current study. An obvious starting point is the SRM protocol [7], and experiments have been conducted using this, and with a low-delay variant, STORM [20]. This work shows the trade-off between latency and quality for retransmission based repair schemes, and illustrates that retransmission is an effective approach to repair for applications which can tolerate the latency.
再送信のオーバーヘッドを減らすために、再送信されたユニットは、[15]で説明されているようなペイロード形式を使用して、進行中の送信にピギーバックできます。これにより、再送信を別の形式で再コード化して、帯域幅のオーバーヘッドをさらに削減することもできます。別の方法として、FEC情報を再送信要求に応じて送信することもでき[13]、1回の再送信でいくつかの損失を修復できる可能性があります。タイムリーでネットワークフレンドリーな再送信リクエストアルゴリズムの選択は、現在検討されている領域です。明らかな出発点はSRMプロトコル[7]であり、これを使用して、低遅延のSTORM [20]のバリエーションで実験が行われています。この作業は、再送信ベースの修復スキームのレイテンシと品質のトレードオフを示し、再送信がレイテンシを許容できるアプリケーションの修復に効果的なアプローチであることを示しています。
There is no standard protocol framework for requesting retransmission of streaming media. An experimental RTP profile extension for SRM-style retransmission requests has described in [14].
ストリーミングメディアの再送信を要求するための標準プロトコルフレームワークはありません。 SRMスタイルの再送信要求の実験的なRTPプロファイル拡張は、[14]で説明されています。
Forward error correction (FEC) is the means by which repair data is added to a media stream, such that packet loss can be repaired by the receiver of that stream with no further reference to the sender. There are two classes of repair data which may be added to a stream: those which are independent of the contents of the stream, and those which use knowledge of the stream to improve the repair process.
フォワードエラー訂正（FEC）は、メディアストリームに修復データを追加する手段であり、送信側を参照することなく、そのストリームの受信側がパケット損失を修復できます。ストリームに追加できる修復データには2つのクラスがあります。ストリームのコンテンツに依存しないものと、ストリームの知識を使用して修復プロセスを改善するものです。
A number of media-independent FEC schemes have been proposed for use with streamed media. These techniques add redundant data, which is transmitted in separate packets, to a media stream. Traditionally, FEC techniques are described as loss detecting and/or loss correcting. In the case of streamed media, loss detection is provided by the sequence numbers in RTP packets.
ストリーミングメディアで使用するために、メディアに依存しないFECスキームがいくつか提案されています。これらの技術は、別個のパケットで送信される冗長データをメディアストリームに追加します。伝統的に、FEC技術は損失の検出や損失の修正として説明されています。ストリーミングメディアの場合、損失検出はRTPパケットのシーケンス番号によって提供されます。
The redundant FEC data is typically calculated using the mathematics of finite fields [1]. The simplest of finite field is GF(2) where addition is just the eXclusive-OR operation. Basic FEC schemes transmit k data packets with n-k parity packets allowing the reconstruction of the original data from any k of the n transmitted packets. Budge et al [4] proposed applying the XOR operation across different combinations of the media data with the redundant data transmitted separately as parity packets. These vary the pattern of packets over which the parity is calculated, and hence have different bandwidth, latency and loss repair characteristics.
冗長FECデータは通常、有限体の数学を使用して計算されます[1]。最も単純な有限体はGF（2）であり、加算は単なる排他的OR演算です。基本的なFECスキームは、n-kのパリティパケットでk個のデータパケットを送信し、n個の送信されたパケットのうち任意のk個から元のデータを再構成します。 Budge et al [4]は、メディアデータと冗長データがパリティパケットとして個別に送信されるさまざまな組み合わせにXOR演算を適用することを提案しました。これらは、パリティが計算されるパケットのパターンを変化させるため、帯域幅、遅延、および損失修復特性が異なります。
Parity-based FEC based techniques have a significant advantage in that they are media independent, and provide exact repair for lost packets. In addition, the processing requirements are relatively light, especially when compared with some media-specific FEC (redundancy) schemes which use very low bandwidth, but high complexity encodings. The disadvantage of parity based FEC is that the codings have higher latency in comparison with the media-specific schemes discussed in following section.
パリティベースのFECベースの技術には、メディアに依存せず、失われたパケットを正確に修復できるという大きな利点があります。さらに、処理要件は比較的軽く、特に非常に低い帯域幅を使用するが複雑度の高いエンコーディングを使用する一部のメディア固有のFEC（冗長性）スキームと比較した場合は特にそうです。パリティベースのFECの欠点は、次のセクションで説明するメディア固有のスキームと比較して、コーディングのレイテンシが高くなることです。
A number of FEC schemes exist which are based on higher-order finite fields, for example Reed-Solomon (RS) codes, which are more sophisticated and computationally demanding. These are usually structured so that they have good burst loss protection, although this typically comes at the expense of increased latency. Dependent on the observed loss patterns, such codes may give improved performance, compared to parity-based FEC.
より高次で計算が要求されるリードソロモン（RS）コードなど、より高次の有限体に基づくFECスキームがいくつか存在します。これらは通常、優れたバースト損失保護を持つように構成されていますが、これは通常、遅延の増加を犠牲にしています。観測された損失パターンに応じて、このようなコードは、パリティベースのFECと比較してパフォーマンスが向上する可能性があります。
An RTP payload format for generic FEC, suitable for both parity based and Reed-Solomon encoded FEC is defined in [17].
パリティベースとリードソロモン符号化FECの両方に適した汎用FECのRTPペイロード形式は、[17]で定義されています。
The basis of media-specific FEC is to employ knowledge of a media compression scheme to achieve more efficient repair of a stream than can otherwise be achieved. To repair a stream subject to packet loss, it is necessary to add redundancy to that stream: some information is added which is not required in the absence of packet loss, but which can be used to recover from that loss.
メディア固有のFECの基礎は、メディア圧縮スキームの知識を活用して、他の方法で実現できるよりも効率的なストリームの修復を実現することです。パケット損失の影響を受けるストリームを修復するには、そのストリームに冗長性を追加する必要があります。パケット損失がない場合は不要ですが、その損失から回復するために使用できる情報が追加されます。
The nature of a media stream affects the means by which the redundancy is added. If units of media data are packets, or if multiple units are included in a packet, it is logical to use the unit as the level of redundancy, and to send duplicate units. By recoding the redundant copy of a unit, significant bandwidth savings may be made, at the expense of additional computational complexity and approximate repair. This approach has been advocated for use with streaming audio [2, 10] and has been shown to perform well. An RTP payload format for this form of redundancy has been defined [15].
メディアストリームの性質は、冗長性を追加する方法に影響します。メディアデータの単位がパケットの場合、またはパケットに複数の単位が含まれている場合、その単位を冗長性のレベルとして使用し、重複した単位を送信することは論理的です。ユニットの冗長コピーを再コード化することにより、追加の計算の複雑さとおおよその修復を犠牲にして、帯域幅を大幅に節約できます。このアプローチは、ストリーミングオーディオでの使用が推奨されており[2、10]、良好に機能することが示されています。この形式の冗長性のためのRTPペイロード形式が定義されています[15]。
If media units span multiple packets, for instance video, it is sensible to include redundancy directly within the output of a codec. For example the proposed RTP payload for H.263+ [3] includes multiple copies of key portions of the stream, separated to avoid the problems of packet loss. The advantages of this second approach is efficiency: the codec designer knows exactly which portions of the stream are most important to protect, and low complexity since each unit is coded once only.
メディアユニットがビデオなどの複数のパケットにまたがる場合、コーデックの出力内に直接冗長性を含めるのが賢明です。たとえば、H.263 + [3]に提案されているRTPペイロードには、ストリームのキー部分の複数のコピーが含まれ、パケット損失の問題を回避するために分離されています。この2番目のアプローチの利点は効率です。コーデックの設計者は、ストリームのどの部分を保護することが最も重要であるかを正確に把握しており、各ユニットが一度だけコーディングされるため、複雑度が低くなります。
An alternative approach is to apply media-independent FEC techniques to the most significant bits of a codecs output, rather than applying it over the entire packet. Several codec descriptions include bit sensitivities that make this feasible. This approach has low computational cost and can be tailored to represent an arbitrary fraction of the transmitted data.
代替アプローチは、メディア全体に依存しないFEC技術をパケット全体に適用するのではなく、コーデック出力の最上位ビットに適用することです。いくつかのコーデックの説明には、これを実現可能にするビット感度が含まれています。このアプローチは計算コストが低く、送信データの任意の部分を表すように調整できます。
The use of media-specific FEC has the advantage of low-latency, with only a single-packet delay being added. This makes it suitable for interactive applications, where large end-to-end delays cannot be tolerated. In a uni-directional non-interactive environment it is possible to delay sending the redundant data, achieving improved performance in the presence of burst losses [11], at the expense of additional latency.
メディア固有のFECを使用すると、レイテンシが低くなり、単一パケットの遅延のみが追加されるという利点があります。これにより、エンドツーエンドの大きな遅延を許容できないインタラクティブなアプリケーションに適しています。一方向の非対話型環境では、冗長データの送信を遅らせることが可能であり、追加のレイテンシを犠牲にして、バースト損失[11]が存在する場合のパフォーマンスの向上を実現します。
When the unit size is smaller than the packet size, and end-to-end delay is unimportant, interleaving [16] is a useful technique for reducing the effects of loss. Units are resequenced before transmission, so that originally adjacent units are separated by a guaranteed distance in the transmitted stream, and returned to their original order at the receiver. Interleaving disperses the effect of packet losses. If, for example, units are 5ms in length and packets 20ms (ie: 4 units per packet), then the first packet could contain units 1, 5, 9, 13; the second packet would contain units 2, 6, 10, 14; and so on. It can be seen that the loss of a single packet from an interleaved stream results in multiple small gaps in the reconstructed stream, as opposed to the single large gap which would occur in a non-interleaved stream. In many cases it is easier to reconstruct a stream with such loss patterns, although this is clearly media and codec dependent. Note that the size of the gaps is dependent on the degree of interleaving used, and can be made arbitrarily small at the expense of additional latency.
ユニットサイズがパケットサイズよりも小さく、エンドツーエンドの遅延が重要でない場合、インターリーブ[16]は、損失の影響を減らすための有用な手法です。ユニットは送信前に並べ替えられるため、元々隣接していたユニットは送信ストリーム内で保証された距離だけ離れており、受信機では元の順序に戻ります。インターリーブにより、パケット損失の影響が分散されます。たとえば、ユニットの長さが5ミリ秒でパケットが20ミリ秒の場合（つまり、パケットごとに4ユニット）、最初のパケットにはユニット1、5、9、13が含まれます。 2番目のパケットにはユニット2、6、10、14が含まれます。等々。インターリーブされていないストリームで発生する単一の大きなギャップとは対照的に、インターリーブされたストリームから単一のパケットが失われると、再構築されたストリームに複数の小さなギャップが生じることがわかります。これは明らかにメディアとコーデックに依存しますが、多くの場合、そのような損失パターンでストリームを再構築する方が簡単です。ギャップのサイズは、使用するインターリーブの度合いに依存し、追加のレイテンシを犠牲にして任意に小さくできることに注意してください。
The obvious disadvantage of interleaving is that it increases latency. This limits the use of this technique for interactive applications, although it performs well for non-interactive use. The major advantage of interleaving is that it does not increase the bandwidth requirements of a stream.
インターリーブの明らかな欠点は、遅延が増えることです。これにより、対話型アプリケーションでのこの手法の使用が制限されますが、非対話型での使用には効果的です。インターリーブの主な利点は、ストリームの帯域幅要件が増加しないことです。
A potential RTP payload format for interleaved data is a simple extension of the redundant audio payload [15]. That payload requires that the redundant copy of a unit is sent after the primary. If this restriction is removed, it is possible to transmit an arbitrary interleaving of units with this payload format.
インターリーブデータの潜在的なRTPペイロード形式は、冗長オーディオペイロードの単純な拡張です[15]。そのペイロードでは、ユニットの冗長コピーがプライマリの後に送信される必要があります。この制限が取り除かれた場合、このペイロード形式でユニットの任意のインターリーブを送信することが可能です。
5 Recommendations
5推奨事項
If the desired scenario is a non-interactive uni-directional transmission, in the style of a radio or television broadcast, latency is of considerably less importance than reception quality. In this case, the use of interleaving, retransmission based repair or FEC is appropriate. If approximate repair is acceptable, interleaving is clearly to be preferred, since it does not increase the bandwidth of a stream. Media independent FEC is typically the next best option, since a single FEC packet has the potential to repair multiple lost packets, providing efficient transmission.
望ましいシナリオが非対話型の単方向送信である場合、ラジオまたはテレビ放送のスタイルでは、待ち時間は受信品質ほど重要ではありません。この場合、インターリーブ、再送信ベースの修復、またはFECの使用が適切です。近似的な修復が許容できる場合、インターリーブはストリームの帯域幅を増加させないため、明らかに優先されます。単一のFECパケットは複数の失われたパケットを修復して効率的な伝送を提供する可能性があるため、通常はメディアに依存しないFECが次善のオプションです。
In an interactive session, the delay imposed by the use of interleaving and retransmission is not acceptable, and a low-latency FEC scheme is the only means of repair suitable. The choice between media independent and media specific forward error correction is less clear-cut: media-specific FEC can be made more efficient, but requires modification to the output of the codec. When defining the packet format for a new codec, this is clearly an appropriate technique, and should be encouraged.
インタラクティブセッションでは、インターリーブと再送信の使用による遅延は許容できず、低遅延FECスキームが適切な修復の唯一の手段です。メディア非依存とメディア固有の順方向エラー訂正の選択はそれほど明確ではありません。メディア固有のFECはより効率的にすることができますが、コーデックの出力を変更する必要があります。新しいコーデックのパケット形式を定義する場合、これは明らかに適切な手法であり、推奨されます。
If an existing codec is to be used, a media independent forward error correction scheme is usually easier to implement, and can perform well. A media stream protected in this way may be augmented with retransmission based repair with minimal overhead, providing improved quality for those receivers willing to tolerate additional delay, and allowing interactivity for those receivers which desire it. Whilst the addition of FEC data to an media stream is an effective means by which that stream may be protected against packet loss, application designers should be aware that the addition of large amounts of repair data when loss is detected will increase network congestion, and hence packet loss, leading to a worsening of the problem which the use of error correction coding was intended to solve.
既存のコーデックを使用する場合、メディアに依存しない前方誤り訂正方式は通常、実装が簡単で、適切に実行できます。この方法で保護されたメディアストリームは、オーバーヘッドを最小限に抑えた再送信ベースの修復で補強され、追加の遅延を許容する受信機に改善された品質を提供し、それを望む受信機に双方向性を許可します。メディアストリームへのFECデータの追加は、そのストリームをパケット損失から保護できる効果的な手段ですが、アプリケーション設計者は、損失が検出されたときに大量の修復データを追加するとネットワークの輻輳が増加するため、パケット損失により、誤り訂正符号化の使用が解決しようとする問題の悪化につながります。
At the time of writing, there is no standard solution to the problem of congestion control for streamed media which can be used to solve this problem. There have, however, been a number of contributions which show the likely form the solution will take [12, 19]. This work typically used some form of layered encoding of data over multiple channels, with receivers joining and leaving layers in response to packet-loss (which indicates congestion). The aim of such schemes is to emulate the congestion control behavior of a TCP stream, and hence compete fairly with non-real time traffic. This is necessary for stable network behavior in the presence of much streamed media.
現時点では、この問題を解決するために使用できるストリーミングメディアの輻輳制御の問題に対する標準的な解決策はありません。しかし、解決策がとられる可能性の高い形式を示す多くの貢献がありました[12、19]。この作業では通常、複数のチャネルを介したデータの何らかの形式の階層化エンコーディングが使用され、レシーバーはパケット損失（輻輳を示します）に応じてレイヤーに参加したりレイヤーを離れたりします。このようなスキームの目的は、TCPストリームの輻輳制御動作をエミュレートすることであり、それにより非リアルタイムトラフィックと公平に競争します。これは、多くのストリーミングメディアが存在する場合の安定したネットワーク動作に必要です。
Since streaming media applications are in use now, without congestion control, it is important to give some advice to authors of those tools as to the behavior which is acceptable, until congestion control mechanisms can be deployed. The remainder of this section uses the throughput of a TCP connection over a link with a given loss rate as an example to indicate behavior which may be classified as reasonable.
ストリーミングメディアアプリケーションは現在、輻輳制御なしで使用されているため、輻輳制御メカニズムを展開できるようになるまで、許容可能な動作についてこれらのツールの作成者にアドバイスを提供することが重要です。このセクションの残りの部分では、例として、所定の損失率のリンクを介したTCP接続のスループットを使用して、妥当と分類される可能性のある動作を示します。
As a number of authors have noted (eg: [6]), the loss rate and throughput of a TCP connection are approximately related as follows:
多くの著者が指摘しているように（例：[6]）、TCP接続の損失率とスループットは、おおよそ次のように関連しています。
T = (s * c) / (RTT * sqrt(p))
where T is the observed throughput in octets per second, s is the packet size in octets, RTT is the round-trip time for the session in seconds, p is the packet loss rate and c is a constant in the range 0.9...1.5 (a value of 1.22 has been suggested [6]). Using this relation, one may determine the packet loss rate which would result in a given throughput for a particular session, if a TCP connection was used.
ここで、Tは観測されたスループット（オクテット/秒）、sはパケットサイズ（オクテット）、RTTはセッションの往復時間（秒）、pはパケット損失率、cは0.9の範囲の定数です... 1.5（1.22の値が推奨されています[6]）。この関係を使用して、TCP接続が使用された場合に、特定のセッションの特定のスループットをもたらすパケット損失率を決定できます。
Whilst this relation between packet loss rate and throughput is specific to the TCP congestion control algorithm, it also provides an estimate of the acceptable loss rate for a streaming media application using the same network path, which wishes to coexist fairly with TCP traffic. Clearly this is not sufficient for fair sharing of a link with TCP traffic, since it does not capture the dynamic behavior of the connection, merely the average behavior, but it does provide one definition of "reasonable" behavior in the absence of real congestion control.
パケット損失率とスループットの間のこの関係はTCP輻輳制御アルゴリズムに固有ですが、同じネットワークパスを使用するストリーミングメディアアプリケーションの許容可能な損失率の見積もりも提供します。これは、TCPトラフィックと公平に共存することを望んでいます。これは、TCPトラフィックとのリンクの公平な共有には明らかに不十分です。接続の動的な動作をキャプチャするのではなく、単に平均的な動作をキャプチャするだけですが、実際の輻輳制御がない場合の「合理的な」動作の1つの定義を提供します。 。
For example, an RTP audio session with DVI encoding and 40ms data packets will have 40 bytes RTP/UDP/IP header, 4 bytes codec state and 160 bytes of media data, giving a packet size, s, of 204 bytes. It will send 25 packets per second, giving T = 4800. It is possible to estimate the round-trip time from RTCP reception report statistics (say 200 milliseconds for the purpose of example). Substituting these values into the above equation, we estimate a "reasonable" packet loss rate, p, of 6.7%. This would represent an upper bound on the packet loss rate which this application should be designed to tolerate.
たとえば、DVIエンコーディングと40ミリ秒のデータパケットを使用するRTPオーディオセッションには、40バイトのRTP / UDP / IPヘッダー、4バイトのコーデックステート、160バイトのメディアデータがあり、204バイトのパケットサイズsを提供します。 1秒あたり25パケットを送信し、T = 4800になります。RTCP受信レポートの統計から往復時間を推定することができます（例として200ミリ秒）。これらの値を上記の式に代入すると、「妥当な」パケット損失率pが6.7％と推定されます。これは、このアプリケーションが許容できるように設計する必要があるパケット損失率の上限を表します。
It should be noted that a round trip time estimate based on RTCP reception report statistics is, at best, approximate; and that a round trip time for a multicast group can only be an `average' measure. This implies that the TCP equivalent throughput/loss rate determined by this relation will be an approximation of the upper bound to the rate a TCP connection would actually achieve.
RTCP受信レポートの統計に基づく往復時間の見積もりは、せいぜい概算であることに注意してください。また、マルチキャストグループのラウンドトリップ時間は、「平均」の尺度にすぎないこともあります。これは、この関係によって決定されるTCPと同等のスループット/損失率が、TCP接続が実際に達成する速度の上限の概算になることを意味します。
6 Security Considerations
6セキュリティに関する考慮事項
Some of the repair techniques discussed in this document result in the transmission of additional traffic to correct for the effects of packet loss. Application designers should be aware that the transmission of large amounts of repair traffic will increase network congestion, and hence packet loss, leading to a worsening of the problem which the use of error correction was intended to solve. At its worst, this can lead to excessive network congestion and may constitute a denial of service attack. Section 5 discusses this in
このドキュメントで説明されている修復手法の一部は、パケット損失の影響を修正するために追加のトラフィックを送信します。アプリケーション設計者は、大量の修復トラフィックを送信するとネットワークの輻輳が増加し、パケット損失が増加し、エラー修正を使用して解決しようとした問題が悪化することを認識しておく必要があります。最悪の場合、これは過度のネットワーク輻輳につながる可能性があり、サービス拒否攻撃を構成する可能性があります。セクション5ではこれについて議論します
more detail, and provides guidelines for prevention of this problem.
詳細、およびこの問題の防止のためのガイドラインを提供します。
7 Summary
7まとめ
Streaming media applications using the Internet will be subject to packet loss due to the unreliable nature of UDP packet delivery. This document has summarized the typical loss patterns seen on the public Mbone at the time of writing, and a range of techniques for recovery from such losses. We have further discussed the need for congestion control, and provided some guidelines as to reasonable behavior for streaming applications in the interim until congestion control can be deployed.
インターネットを使用したストリーミングメディアアプリケーションは、UDPパケット配信の信頼性が低いため、パケット損失の影響を受けます。このドキュメントでは、執筆時点でパブリックMboneに見られる典型的な損失パターンと、そのような損失から回復するためのさまざまな手法についてまとめています。輻輳制御の必要性についてさらに説明し、輻輳制御を展開できるようになるまでの暫定的なストリーミングアプリケーションの合理的な動作に関するいくつかのガイドラインを示しました。
8 Acknowledgments
8謝辞
The authors wish to thank Phil Karn and Lorenzo Vicisano for their helpful comments.
著者は、有益なコメントをしてくれたPhil KarnとLorenzo Vicisanoに感謝します。
9 Authors' Addresses
9作者のアドレス
Colin Perkins Department of Computer Science University College London Gower Street London WC1E 6BT United Kingdom
コリンパーキンスコンピューターサイエンス大学カレッジロンドンガワーストリートロンドンWC1E 6BTイギリス
EMail: c.perkins@cs.ucl.ac.uk
Orion Hodson Department of Computer Science University College London Gower Street London WC1E 6BT United Kingdom
オリオンホドソンコンピューターサイエンス大学カレッジロンドンガワーストリートロンドンWC1E 6BTイギリス
EMail: o.hodson@cs.ucl.ac.uk
References
参考文献
[1] R.E. Blahut. Theory and Practice ofError Control Codes. Addison Wesley, 1983.
[1] R.E.ブラハット。エラー制御コードの理論と実践。アディソンウェスリー、1983年。
[2] J.-C. Bolot and A. Vega-Garcia. The case for FEC based error control for packet audio in the Internet. To appear in ACM Multimedia Systems.
[2] J.-C. BolotとA. Vega-Garcia。インターネットにおけるパケットオーディオのFECベースのエラー制御の事例。 ACMマルチメディアシステムに表示されます。
[3] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell, J. Ott, S. Wenger, and C. Zhu. RTP payload format for the 1998 version of ITU-T reccomendation H.263 video (H.263+). Work in Progress.
[3] C. Bormann、L。Cline、G。Deisher、T。Gardos、C。Maciocco、D。Newell、J。Ott、S。Wenger、およびC. Zhu。 1998バージョンのITU-T推奨H.263ビデオ（H.263 +）のRTPペイロード形式。進行中の作業。
[4] D. Budge, R. McKenzie, W. Mills, W. Diss, and P. Long. Media-independent error correction using RTP, Work in Progress.
[4] D.バッジ、R。マッケンジー、W。ミルズ、W。ディス、P。ロング。 RTP、Work in Progressを使用したメディアに依存しないエラー修正。
[5] G. Carle and E. W. Biersack. Survey of error recovery techniques for IP-based audio-visual multicast applications. IEEE Network, 11(6):24--36, November/December 1997.
[5] G.カールとE. W.ビアサック。 IPベースのオーディオビジュアルマルチキャストアプリケーションのエラー回復技術の調査。 IEEEネットワーク、11（6）：24-36、1997年11月/ 12月。
[6] S. Floyd and K. Fall. Promoting the use of end-to-end congestion control in the internet. Submitted to IEEE/ACM Transactions on Networking, February 1998.
[6] S.フロイドとK.フォール。インターネットにおけるエンドツーエンドの輻輳制御の使用を促進します。 IEEE / ACM Transactions on Networkingに提出、1998年2月。
[7] S. Floyd, V. Jacobson, S. McCanne, C.-G. Liu, and L. Zhang. A reliable multicast framework for light-weight sessions and applications level framing. IEEE/ACM Transactions on Networking, 1995.
[7] S.フロイド、V。ジェイコブソン、S。マッカンン、C.-G。劉、L。張。軽量セッションおよびアプリケーションレベルのフレーミングのための信頼性の高いマルチキャストフレームワーク。 IEEE / ACM Transactions on Networking、1995年。
[8] M. Handley. An examination of Mbone performance. USC/ISI Research Report: ISI/RR-97-450, April 1997.
[8] M.ハンドラリー。 Mboneパフォーマンスの調査。 USC / ISI調査レポート：ISI / RR-97-450、1997年4月。
[9] M. Handley and J. Crowcroft. Network text editor (NTE): A scalable shared text editor for the Mbone. In Proceedings ACM SIGCOMM'97, Cannes, France, September 1997.
[9] M.ハンドラリーとJ.クロウクロフト。ネットワークテキストエディター（NTE）：Mbone用のスケーラブルな共有テキストエディター。 Proceedings ACM SIGCOMM'97、カンヌ、フランス、1997年9月。
[10] V. Hardman, M. A. Sasse, M. Handley, and A. Watson. Reliable audio for use over the Internet. In Proceedings of INET'95, 1995.
[10] V.ハードマン、M。A.サッセ、M。ハンドラリー、A。ワトソン。インターネットで使用するための信頼性の高いオーディオ。 INET'95のプロシーディングス、1995年。
[11] I. Kouvelas, O. Hodson, V. Hardman, and J. Crowcroft. Redundancy control in real-time Internet audio conferencing. In Proceedings of AVSPN'97, Aberdeen, Scotland, September 1997.
[11] I.コウベラス、O。ホドソン、V。ハードマン、J。クロウクロフト。リアルタイムのインターネット電話会議における冗長制御。 AVSPN'97の議事録、スコットランドのアバディーン、1997年9月。
[12] S. McCanne, V. Jacobson, and M. Vetterli. Receiver-driven layered multicast. In Proceedings ACM SIGCOMM'96, Stanford, CA., August 1996.
[12] S. McCanne、V。Jacobson、およびM. Vetterli。レシーバー主導の階層型マルチキャスト。 Proceedings ACM SIGCOMM'96、スタンフォード、CA、1996年8月。
[13] J. Nonnenmacher, E. Biersack, and D. Towsley. Parity-based loss recovery for reliable multicast transmission. In Proceedings ACM SIGCOMM'97, Cannes, France, September 1997.
[13] J. Nonnenmacher、E。Biersack、およびD. Towsley。信頼性の高いマルチキャスト送信のためのパリティベースの損失回復。 Proceedings ACM SIGCOMM'97、カンヌ、フランス、1997年9月。
[14] P. Parnes. RTP extension for scalable reliable multicast, Work in Progress.
[14] P.パーネス。スケーラブルで信頼性の高いマルチキャストのためのRTP拡張、Work in Progress。
[15] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J-C., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[15] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、JC。、Vega-Garcia、A。、およびS. Fosse-Parisis、「RTP Payload for Redundant Audioデータ」、RFC 2198、1997年9月。
[16] J.L. Ramsey. Realization of optimum interleavers. IEEE Transactions on Information Theory, IT-16:338--345, May 1970.
[16] J.L.ラムジー。最適なインターリーバーの実現。 IEEE Transactions on Information Theory、IT-16：338--345、May 1970。
[17] J. Rosenberg and H. Schulzrinne. An A/V profile extension for generic forward error correction in RTP. Work in Progress.
[17] J. RosenbergおよびH. Schulzrinne。 RTPでの一般的な前方誤り訂正のためのA / Vプロファイル拡張。進行中の作業。
[18] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A transport protocol for real-time applications", RFC 1889, January 1996.
[18] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A transport protocol for real-time applications」、RFC 1889、1996年1月。
[19] L. Vicisano, L. Rizzo, and Crowcroft J. TCP-like congestion control for layered multicast data transfer. In Proceedings IEEE INFOCOM'98, 1998.
[19] L. Vicisano、L。Rizzo、およびCrowcroft J.レイヤードマルチキャストデータ転送のためのTCPに似た輻輳制御。 Proceedings IEEE INFOCOM'98、1998年。
[20] R. X. Xu, A. C. Myers, H. Zhang, and R. Yavatkar. Resilient multicast support for continuous media applications. In Proceedingsof the 7th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV'97), Washington University in St. Louis, Missouri, May 1997.
[20] R. X. Xu、A。C. Myers、H。Zhang、R。Yavatkar。継続的なメディアアプリケーションに対する弾力性のあるマルチキャストサポート。 1997年5月、ミズーリ州セントルイスのワシントン大学、デジタルオーディオおよびビデオのネットワークおよびオペレーティングシステムサポートに関する第7回国際ワークショップ（NOSSDAV'97）の議事録。
[21] M. Yajnik, J. Kurose, and D. Towsley. Packet loss correlation in the Mbone multicast network. In Proceedings IEEE Global Internet Conference, November 1996.
[21] M. Yajnik、J。Kurose、およびD. Towsley。 Mboneマルチキャストネットワークでのパケット損失相関。 Proceedings IEEE Global Internet Conference、1996年11月。
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。