4.1. Loss RLE Report Block (パケットロスRLEレポートブロック)
4.1. Loss RLE Report Block (パケットロスRLEレポートブロック)
このブロックタイプは, 個々のパケット受信とロスイベントに関する詳細なレポートを可能にします。このようなレポートは, たとえばマルチキャストネットワーク特性推論 (MINC) [11] に使用できます。MINCを使用すると, ソースのRTPパケットを配信するために使用されるマルチキャストツリーのトポロジー, およびそのツリー内のリンクに沿ったロス率を発見できます。または, ネットワーク管理アプリケーションに生データを提供するために使用できます。
ロストおよび受信されたRTPパケットのブールトレースは潜在的に長いため, このブロックタイプは, ランレングス符号化を通じてトレースを圧縮できるようにします。ブロックサイズをさらに削減するために, 以下で説明し, [13]で研究されている間引き (thinning) と呼ばれるメカニズムで, ロスイベントレポートをトレースから体系的に削除できます。
Loss RLE Report Blockを生成する参加者は, 可能な限り観察されたイベントを解釈するよりも正確に報告することを優先すべきです。解釈は, レポートブロックを観察する人に任せるべきです。このアプローチに従うことは, Loss RLE Report Blockの計算が, RTP仕様[9]で説明されているSRおよびRRパケットの生成の計算と次の2つの領域で異なることを意味します: 送信者ごとの計算とパケットごとの計算。
送信者ごとの計算では, RTPセッション参加者は, それらのパケットの送信者について報告する条件として, 閾値最小数のRTPパケットの受信を行うべきではありません。この計算手法は, 送信者が有効と見なされるかどうかを判断するために閾値を使用できるRTP仕様のセクション6.2.1および付録A.1で説明されている手法とは異なります。
パケットごとの計算では, RTPセッション参加者は, すべてのシーケンス番号を有効として扱うべきです。この計算手法は, 以前に受信されたパケットのシーケンス番号との連続性に基づいて, シーケンス番号を有効または無効と判断することを提案するRTP仕様の付録A.1で説明されている手法とは異なります。
送信者の有効性とシーケンス番号の有効性は, 生データの解釈です。このような解釈は, たとえば, 無関係なセッションからの古いパケットがRTCP送信間隔の計算に影響を与えることを排除する目的で正当化されます。一方, 古いパケットの存在は, ネットワーク監視アプリケーションにとって興味深いものかもしれません。
それでも必要な1つの計算解釈は, 参加者が16ビットシーケンス番号がロールオーバーしたかどうかを判断することです。通常の状況では, これは難しい作業ではありません。たとえば, パケット番号65,535 (可能な最高のシーケンス番号) の直後にパケット番号0が続く場合, ロールオーバーが発生したと仮定するのが妥当です。ただし, そのパケットは以前のパケット (65,535パケット前) である可能性があります。シーケンス番号は, 前方または後方に複数回ロールオーバーした可能性もあります。シーケンス番号間に大きなギャップがある場合, ロールオーバーを考慮しても, また受信パケット間に長い間隔がある場合, 解釈はより困難になります。
ここで義務付けられているパケットごとの計算手法は, 参加者が送信者から最近受信したパケットのシーケンス番号を追跡することです。その送信者から到着する次のパケットについて, シーケンス番号は, 最新のものから前後32,768パケット以内に収まると判断されなければならず, どちらがより近いかによります。両方の選択が等距離である場合 (距離が32,768の場合のみ可能), ロールオーバーを必要としない選択でなければなりません。付録A.1は, この手法を実装するアルゴリズムを示しています。
各ブロックは, そのSSRCによって識別される単一のRTPデータパケットソースについて報告します。レポートを提供する受信者は, RTCPパケットのヘッダーで識別されます。
トレースの開始および終了RTPパケットシーケンス番号の選択は, アプリケーションに任されています。これらの値は, ブロックで報告されます。トレースの最後のシーケンス番号は, 付随するSRまたはRRレポートで報告されたシーケンス番号とは異なる場合があります。
シーケンス番号のラップアラウンドのため, 終了シーケンス番号は開始シーケンス番号よりも小さい場合があることに注意してください。Loss RLE Report Blockは, シーケンス番号空間で65,534以上の範囲を報告するために使用してはなりません。複数のラップアラウンドを識別する手段がないためです。
Loss RLEレポートによって記述されるトレースは, 一連のブール値で構成され, トレースの各シーケンス番号に1つずつあります。値1はパケット受信を表し, シーケンス番号の最新のラップアラウンド以降 (またはラップアラウンドが発生していないと判断された場合はRTPセッションの開始以降), そのシーケンス番号を持つ1つ以上のパケットが受信されたことを意味します。値0はパケットロスを表し, レポート時点でそのシーケンス番号のパケット受信がないことを意味します。特定のシーケンス番号のロスを報告した後にそのシーケンス番号を持つパケットが受信された場合, 後のLoss RLEレポートは, そのシーケンス番号のパケット受信を報告する場合があります。
エンコーディング自体は, トレース内のパケット受信またはロスのシーケンスを記述するチャンク (chunk) と呼ばれる一連の16ビット単位で構成されます。各チャンクは, ランレングスまたはビットベクトルを指定するか, ヌルチャンクです。ランレングスは, 1から16,383のすべて同じイベント (すべて受信またはすべてロスト) を記述します。ビットベクトルは, 受信とロスが混在する可能性がある15のイベントを記述します。ヌルチャンクはイベントを記述せず, ブロックを32ビットワード境界に丸めるために使用されます。
ロストおよび受信されたパケットのシーケンスからチャンクのシーケンスへのマッピングは, 必ずしも一意ではありません。たとえば, 次のトレースは45パケットをカバーし, そのうち22番目と24番目がロストし, 他は受信されています:
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
1つのエンコーディング方法は次のとおりです:
bit vector 1111 1111 1111 111
bit vector 1111 1101 0111 111
bit vector 1111 1111 1111 111
null chunk
別のエンコーディング方法は次のとおりです:
run of 21 receipts
bit vector 0101 1111 1111 111
run of 9 receipts
null chunk
エンコーディングの選択は, アプリケーションに任されています。この選択の自由の一部として, アプリケーションは, レポートブロックで記述されるシーケンス番号空間を超えるビットベクトルブロックで, 一連のランレングスおよびビットベクトルブロックを終了できます。たとえば, 同じシーケンスの44番目のパケットがロストした場合:
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
これは次のようにエンコードできます:
run of 21 receipts
bit vector 0101 1111 1111 111
bit vector 1111 1110 1000 000
null chunk
この例では, 2番目のビットベクトルの最後の5ビットは, トレースの最後のシーケンス番号を超えるシーケンス番号空間の部分を記述しています。これらのビットはゼロに設定されています。
トレースの最後のシーケンス番号を超えるシーケンス番号空間の部分を記述するビットベクトルブロック内のすべてのビットは, ゼロに設定されなければならず, 受信者によって無視されなければなりません。
ランレングスプラスビットベクトルブロックの数が奇数の場合, Loss RLE Report Blockの最後にヌルパケットが存在しなければなりません。ヌルブロックは, 他のコンテキストに出現してはなりません。
Loss RLE Report Blockを送信する際は慎重に使用する必要があります。ランレングス符号化によって提供される圧縮を使用しても, 通常のRTCPパケットに対して不釣り合いな帯域幅を簡単に消費する可能性があるためです。ブロックタイプには, アプリケーションがレポートサイズを制限できるようにする間引き (thinning) と呼ばれるメカニズムが含まれています。
間引き値Tは, シーケンス番号空間内のパケットのサブセットを選択します: シーケンス番号が2^Tの倍数であるパケット。パケット受信とロスレポートは, これらのパケットにのみ適用されます。Tは0から15まで変化できます。Tがゼロの場合, シーケンス番号空間のすべてのパケットが報告されます。Tが15の場合, 32,768パケットごとに1つが報告されます。
先ほど説明したトレースがシーケンス番号13,821から始まると仮定します。トレースの最後のシーケンス番号は13,865です。トレースが間引き値T=2で間引きされる場合, 次のシーケンス番号が報告されます: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864。間引きされたトレースは次のとおりです:
1 1 1 1 1 0 1 1 1 1 0
これは次のようにエンコードできます:
bit vector 1111 1011 1100 000
null chunk
ビットベクトルの最後の4ビットは, シーケンス番号13,868, 13,872, 13,876, 13,880を表し, トレースの範囲外であるため, ゼロに設定され, 受信者によって無視されます。間引きにより, 22番目のパケットのロスは報告されません。そのシーケンス番号13,842が4の倍数ではないためです。4の倍数でないシーケンス番号のすべてのパケットの受信も報告されません。ただし, この例では, 間引きによりLoss RLE Report Blockを1つの32ビットワード短縮できます。
間引き値の選択は, アプリケーションに任されています。
Loss RLE Report Blockの形式は次のとおりです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=1 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8ビット
- Loss RLE Report Blockは定数1によって識別されます。
rsvd.: 4ビット
- このフィールドは将来の定義のために予約されています。そのような定義がない場合, このフィールドのビットはゼロに設定されなければならず, 受信者によって無視されなければなりません。
thinning (T): 4ビット
- シーケンス番号空間に対して実行される間引きの量。このブロックは, シーケンス番号が0 mod 2^Tのパケットのみを報告します。値0は間引きなしを示し, すべてのパケットが報告されます。最大間引きは32,768パケットごとに1つです (16ビットシーケンス空間内で2パケットに相当)。
block length: 16ビット
- セクション3で定義されています。
SSRC of source: 32ビット
- このレポートブロックが報告するRTPデータパケットソースのSSRC。
begin_seq: 16ビット
- このブロックが報告する最初のシーケンス番号。
end_seq: 16ビット
- このブロックが報告する最後のシーケンス番号プラス1。
chunk i: 16ビット
- 3つのチャンクタイプがあります: ランレングス, ビットベクトル, 終了ヌル。以下のセクションで定義されています。チャンクがすべてゼロの場合, 終了ヌルブロックです。それ以外の場合, チャンクの最左ビットがそのタイプを決定します: 0はランレングス, 1はビットベクトル。