RFC2354 日本語訳

Network Working Group                                         C. Perkins
Request for Comments: 2354                                     O. Hodson
Category: Informational                        University College London
                                                               June 1998

コメントを求めるワーキンググループC.パーキンス要求をネットワークでつないでください: 2354年のO.ホドソンカテゴリ: 情報のユニバーシティ・カレッジロンドン1998年6月

                 Options for Repair of Streaming Media

ストリーミング・メディアの修理のためのオプション

Status of this Memo

この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)インターネット協会(1998)。 All rights reserved。

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]を参照されます。

Perkins & Hodson             Informational                      [Page 1]

RFC 2354         Options for Repair of Streaming Media         June 1998

メディア1998年6月に流れる修理のためのパーキンスとホドソン情報[1ページ]のRFC2354Options

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個以上のユニット以上を含みます。 例えば、多くのオーディオ符号化器が20msユニットを作動させます。(ユニットは、トランスミッションのために40msか80msパケットを作り出すために通常結合されます)。 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の使用はいくつかの異なったメディア符号化器を考慮します、ペイロードタイプ分野が受信機でこれらを見分けるのに使用されている状態で。いくつかの損失修理計画が、受信機には解読することがあるという確率を増加させるようにいろいろな時間においてユニットと、ことによると異なったencodingsで複本を送ります。 異なったencodingsの'上質'のランキングを持っていると思われて、受信機は、再生において'最も良い'ユニットを選ぶことができます、複数のオプションを考えて。

   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.

セッションは終わりから終わりへの遅れが、より少ない当時の250msであるならインタラクティブと定義されます、メディアコード化、解読、ネットワークトランジット、およびホストバッファリングを含んでいて。

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]の損失の特性で行われました、そして、結果はいくらか変わりますが、広い結論は明確です: 大きい会議では、いくつかの受信機がパケット損失を経験するのは、必然です。 ハンドレー[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

また、かなりの大多数の損失が単一のパケットのものであることが示されました。 2つ以上のパケットの炸裂の損失は単一のパケット損失よりおよそ1桁頻繁ではありません、純粋に無作為の過程から予想されるだろうよりしばしば起こりますが。 より長い炸裂の損失(何十ものパケットの注文の)はまれに発生します。 これらの結果は少量の一時的な混雑がパケット損失の大部分を引き起こすネットワークと一致しています。 いくつかの場合では、ネットワークリンクは厳しくであるわかっています。

Perkins & Hodson             Informational                      [Page 2]

RFC 2354         Options for Repair of Streaming Media         June 1998

メディア1998年6月に流れる修理のためのパーキンスとホドソン情報[2ページ]のRFC2354Options

   overloaded, and large amount of loss results.

積みすぎられて、大欠損額は結果として生じます。

   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つの損失緩和計画について議論します。 これらの計画は、文学で幾度か議論して、多くのシナリオで役に立つのがわかりました。 各テクニックは、注意されたその簡潔に説明されていて利点と損失です。

4.1 Retransmission

4.1 Retransmission

   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.

無くなっているパケットのRetransmissionは損失が修理されるかもしれない明白な手段です。 それには、明確に伸びやかな遅れ領域がある非対話的なアプリケーションにおける価値がありますが、課された遅れは、それが対話的な使用のために通常よく振る舞わないことを意味します。

   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

「再-トランスミッション」のオーバーヘッドを下げるために、再送されたユニットは進行中のトランスミッションに背負われるかもしれません、[15]で説明されたそれなどのペイロード形式を使用して。 また、これは、「再-トランスミッション」がさらに帯域幅オーバーヘッドを下げるために異なった形式で再コード化されるのを許容します。 代替手段として、「再-トランスミッション」要求[13]に対応してFEC情報を送るかもしれません、単一の「再-トランスミッション」が潜在的に数回の損失を修理するのを許容して。 そしてともにタイムリーな「再-トランスミッション」要求アルゴリズムの選択。

Perkins & Hodson             Informational                      [Page 3]

RFC 2354         Options for Repair of Streaming Media         June 1998

メディア1998年6月に流れる修理のためのパーキンスとホドソン情報[3ページ]のRFC2354Options

   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.

ネットワーク好意的であるのは、現在の研究の領域です。 明白な出発点は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スタイル「再-トランスミッション」要求のための拡大が[14]で説明した実験RTPプロフィール。

4.2 Forward Error Correction

4.2 前進型誤信号訂正

   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つのクラスに関する修理データがあります: 流れのコンテンツから独立しているもの、および修理の過程を改良するのに流れに関する知識を使用するもの。

4.2.1 Media-Independent FEC

4.2.1 メディアから独立しているFEC

   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]の数学を使用することで通常計算されます。 最も簡単な有限分野は添加がただeXclusive-OR演算であるところのGF(2)です。 基本的なFEC計画はn伝えられたパケットのどんなkからもn-kパリティパケットがオリジナルのデータの再構成を許しているkデータ・パケットを伝えます。 別々にパリティパケットとして伝えられる冗長データへのメディアデータの異なった組み合わせの向こう側にXOR操作を適用して、提案されていた状態で他[4]を動かせてください。 これらは、同等が計算されるパケットのパターンを変えて、したがって、異なった帯域幅、潜在、および損失修理の特性を持っています。

   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

パリティベースのFECベースのテクニックは、彼らがメディア独立者であるので重要な利点を持って、無くなっているパケットのための正確な修理を提供します。 さらに、処理所要は比較的軽いです、特に非常に低い帯域幅、しかし、高複雑さencodingsを使用するいくつかのメディア特有のFEC(冗長)計画と比べると。 同等に基づいているFECの難点はコーディングにはメディア特有との比較における、より高い潜在があるということです。

Perkins & Hodson             Informational                      [Page 4]

RFC 2354         Options for Repair of Streaming Media         June 1998

メディア1998年6月に流れる修理のためのパーキンスとホドソン情報[4ページ]のRFC2354Options

   schemes discussed in following section.

以下の章で議論した計画。

   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]で定義されます。

4.2.2 Media-Specific FEC

4.2.2 メディア特有のFEC

   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のテクニックを適用することです。 いくつかのコーデック記述がこれを可能にする噛み付いている敏感さを含んでいます。 このアプローチは、低いコンピュータの費用を持って、伝えられたデータの任意の部分を表すために合わせることができます。

Perkins & Hodson             Informational                      [Page 5]

RFC 2354         Options for Repair of Streaming Media         June 1998

メディア1998年6月に流れる修理のためのパーキンスとホドソン情報[5ページ]のRFC2354Options

   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の使用には、単一のパケット遅れだけが加えられている低遅延の利点があります。 これで、それは対話型アプリケーションに適するようになります。(そこでは、終わりから終わりへの大きい遅れを許容できません)。 uni方向の非対話的な環境で、冗長データを送るのを遅らせるのは可能です、炸裂の損失[11]の面前で向上した性能を達成して、追加潜在を犠牲にして。

4.3 Interleaving

4.3 インターリービング

   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]は、損失の影響を減少させるための役に立つテクニックです。 ユニットはトランスミッションの前に再配列されます、元々隣接しているユニットを受信機のそれらの最初の注文に保証された距離で伝えられた流れで切り離して、返すように。インターリービングはパケット損失の影響を分散します。 例えば、ユニットが長さにおける5msとパケット20ms(ie: 1パケットあたり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

必要なシナリオが非対話的なuni方向のトランスミッションであるなら、ラジオかテレビ放送のスタイルでは、潜在はレセプション品質よりかなり少ない重要です。 この場合、インターリービング、「再-トランスミッション」のベースの修理またはFECの使用は適切です。 大体の修理が許容できるなら、インターリービングが許容できる、好まれるために、明確に、増加しないので、増加してください。

Perkins & Hodson             Informational                      [Page 6]

RFC 2354         Options for Repair of Streaming Media         June 1998

メディア1998年6月に流れる修理のためのパーキンスとホドソン情報[6ページ]のRFC2354Options

   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パケットには複数の無くなっているパケットを修理する可能性があるので、効率的なトランスミッションを提供して。

   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:

多くの作者が注意した、(eg: [6]) TCP接続に関する損失率とスループットは以下の通りほとんど話されます:

Perkins & Hodson             Informational                      [Page 7]

RFC 2354         Options for Repair of Streaming Media         June 1998

メディア1998年6月に流れる修理のためのパーキンスとホドソン情報[7ページ]のRFC2354Options

    T = (s * c) / (RTT * sqrt(p))

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が1秒あたりの八重奏で観測されたスループットであるところでは、sは八重奏でパケットサイズです、そして、RTTは秒のセッションのための往復の時間です、そして、pはパケット損失率です、そして、cは範囲0.9の定数です…1.22の値は示されました。1.5、([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コード化と40msデータ・パケットとのRTPオーディオセッションには、メディアデータの40バイトのRTP/UDP/IPヘッダー、4バイトのコーデック状態、および160バイトがあるでしょう、パケットサイズ、204バイトのsを与えて。 T=4800を与えて、それは1秒あたり25のパケットを送るでしょう。 RTCPレセプションレポート統計からの往復の時間を見積もっているのは可能です(例の目的について200ミリセカンドと同じくらい賛成の立場で発言してください)。 上の方程式にこれらの値を代入して、私たちは「妥当な」パケット損失率、6.7%のpを見積もっています。 これはこのアプリケーションが許容するように設計されるべきであるパケット損失率に上限を表すでしょう。

   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がこれについて論ずるセクション

Perkins & Hodson             Informational                      [Page 8]

RFC 2354         Options for Repair of Streaming Media         June 1998

メディア1998年6月に流れる修理のためのパーキンスとホドソン情報[8ページ]のRFC2354Options

   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.

作者は彼らの役に立つコメントについてフィルKarnとロレンツォ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

メール: c.perkins@cs.ucl.ac.uk

   Orion Hodson
   Department of Computer Science
   University College London
   Gower Street
   London WC1E 6BT
   United Kingdom

Orionホドソン・コンピュータサイエンス学部ユニバーシティ・カレッジロンドンガウアー・ストリートロンドンWC1E 6BTイギリス

   EMail: o.hodson@cs.ucl.ac.uk

メール: o .hodson@cs.ucl.ac.uk

References

参照

   [1] R.E. Blahut. Theory and Practice ofError Control Codes.
       Addison Wesley, 1983.

[1] R.E.Blahut。 理論と習慣ofError制御コード。 アディソン・ウエスリー、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.ベガ-ガルシア。 FECのためのこの件はインターネットのパケットオーディオのための誤り制御を基礎づけました。 ACM Multimedia Systemsに現れるように。

Perkins & Hodson             Informational                      [Page 9]

RFC 2354         Options for Repair of Streaming Media         June 1998

メディア1998年6月に流れる修理のためのパーキンスとホドソン情報[9ページ]のRFC2354Options

   [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.ボルマン、L.クライン、G.Deisher、T.Gardos、C.Maciocco、D.ヌーエル、J.オット、S.ウェンガー、およびC.朱。 1998年のITU-T reccomendation 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.

D.が動かせる[4]、マッケンジー、W.工場、W.がけなして、P.が切望するR.。 ProgressでRTP、Workを使用するメディアから独立しているエラー修正。

   [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.Biersack。 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.は落ちます。 インターネットにおける終わりからエンドへの輻輳制御の使用を促進します。 ネットワーク、1998年2月にIEEE/ACM取引に提出します。

   [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.フロイド対ジェーコブソン、S.McCanne、C.G リュウ、およびL.チャン。 軽量のセッションとアプリケーションのための信頼できるマルチキャスト枠組みは縁どりを平らにします。 ネットワーク、1995におけるIEEE/ACM取引。

   [8] M. Handley.   An examination of Mbone performance.  USC/ISI
       Research Report:  ISI/RR-97-450, April 1997.

[8] M.ハンドレー。 Mbone性能の試験。 USC/ISIはレポートについて研究します: 1997年4月のISI/RR-97-450。

   [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に、スケーラブルな共有されたテキストエディタ。 議事ACM SIGCOMM97年、カンヌ(フランス)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.ワトソン。 インターネットの上の使用のための高信頼のオーディオ。 INET1995 95年の議事で。

  [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.Kouvelas、O.ホドソン、V.ハードマン、およびJ.クロウクロフト。 リアルタイムのインターネット電話による会議における冗長コントロール。 AVSPN97年、アバディーン、スコットランド9月1997の議事で

  [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.ジェーコブソン、およびM.Vetterli。 受信機駆動の層にされたマルチキャスト。 議事ACM SIGCOMM96年、スタンフォード(カリフォルニア)で8月1996日

  [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。 信頼できるマルチキャスト送信のためのパリティベースの損失回復。 議事ACM SIGCOMM97年、カンヌ(フランス)1997年9月に。

  [14] P. Parnes.   RTP extension for scalable reliable multicast,
       Work in Progress.

[14] P.パルネス。 スケーラブルな信頼できるマルチキャストのためのRTP拡張子、ProgressのWork。

Perkins & Hodson             Informational                     [Page 10]

RFC 2354         Options for Repair of Streaming Media         June 1998

メディア1998年6月に流れる修理のためのパーキンスとホドソン情報[10ページ]のRFC2354Options

  [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] パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J-C.、ベガ-ガルシア、A.、およびS.堀-Parisis、「余分なオーディオデータのためのRTP有効搭載量」、RFC2198(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取引IT-16: (338--345)は1970がそうするかもしれません。

  [17] J. Rosenberg and H. Schulzrinne. An A/V profile extension for
       generic forward error correction in RTP.  Work in Progress.

[17] J.ローゼンバーグと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.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、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.リゾー、およびクロウクロフトのJ. TCPのような混雑は層にされたマルチキャストデータ転送のために制御されます。 議事IEEE INFOCOM1998 98年に。

  [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.シュー、A.C.マイアーズ、H.チャン、およびR.Yavatkar。 連続したメディアアプリケーションの立ち直りの早いマルチキャストサポート。 ネットワークとオペレーティングシステムに関する第7Proceedingsofの国際ワークショップでは、デジタル・オーディオとビデオのために(NOSSDAV97年)を支持してください、セントルイス(ミズーリ)のワシントン大学、1997年5月。

  [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.ヤジニーク、J.黒瀬、およびD.Towsley。 Mboneマルチキャストネットワークにおけるパケット損失相関関係。 議事IEEEグローバルなインターネットコンファレンス、1996年11月に。

Perkins & Hodson             Informational                     [Page 11]

RFC 2354         Options for Repair of Streaming Media         June 1998

メディア1998年6月に流れる修理のためのパーキンスとホドソン情報[11ページ]のRFC2354Options

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Perkins & Hodson             Informational                     [Page 12]

パーキンスとホドソンInformationalです。[12ページ]