3.4. 定義とアルゴリズム概要 (Definitions and Algorithm Overview)
受信者ごとに, 以下の状態情報を保持する必要がある (主として [1] より). 下記 h) を除く各変数は各受信者で独立に計算されるため, 任意の時点でローカル値が一致しない場合がある.
a) senders を RTP セッション内のアクティブ送信者数とする.
b) members を RTP セッション内の受信者数の現在の推定値とする.
c) tn および tp を, タイマ再考慮 (timer reconsideration) 前に算出された, 次 (および前回) の RTCP RR 送信予定時刻とする.
d) Tmin を [1] に従う RTCP パケット間の最小間隔とする. [1] とは異なり, 最初の RTCP パケット送信前にグループ規模をある程度サンプルするため, 初期 Tmin は 1 秒とする. 最初の RTCP パケット送信後, Tmin は 0 に設定する.
e) T_rr を, 定期スケジュールされた RTCP パケットを直近送信した直後の受信者が, 次の Regular RTCP パケットを送信するまでの間隔とする. この値は [1] の規則に従い, ただし本文書で定義する Tmin を用いて得る: T_rr = T ([1] の「算出間隔」) かつ tn = tp + T. T_rr は常に, 再考慮または tn 決定のために最後に計算された T を指す. 本文書では T_rr を Regular RTCP 間隔 (Regular RTCP interval) とも呼ぶ.
f) t0 を, 報告すべきイベントを受信者が検出した時刻とする.
g) T_dither_max を, マルチパーティセッションでのフィードバック爆発 (implosion) を防ぐために RTCP フィードバックパケットが追加で遅延され得る最大間隔とする. その値は T_rr に基づき動的に算出する (または将来, すべての RTP 受信者に共通する別の仕組みで導出され得る). ポイントツーポイントセッション (メンバーが正確に 2 名でグループ規模の変化が想定されないセッション, 例: ユニキャストストリーミング) では, T_dither_max は 0 とする.
h) T_max_fb_delay を, イベントに対するフィードバックが送信者にとってまだ有用であるために報告されねばならない上限時間とする. この値はアプリケーション固有であり, 本文書では値を定義しない.
i) te を, フィードバックパケットがスケジュールされる時刻とする.
j) T_fd を, 時刻 t0 のイベントに応答して FB メッセージを送信する際の実際の (ランダム化された) 遅延とする.
k) allow_early を, 受信者が次の定期 RTCP 間隔 tn より前に FB メッセージを送信してよいかを示すブール変数とする. この変数は単一受信者によるフィードバック量を抑制するために用いる. Early フィードバック送信後は allow_early を FALSE にし, 次の Regular RTCP 送信が行われた時点で TRUE に戻す.
l) avg_rtcp_size を [1] で定義される RTCP パケットサイズの移動平均とする.
m) T_rr_interval を, Regular RTCP パケット間に用いてよい任意の最小間隔とする. T_rr_interval == 0 の場合, この変数は RTCP フィードバックアルゴリズム全体に影響しない. T_rr_interval != 0 の場合, 次の Regular RTCP パケットは, 直近の Regular RTCP 送信の T_rr 後 (すなわち tp+T_rr) にはスケジュールされず, 少なくとも直近の Regular RTCP 送信から T_rr_interval 経過後, つまり tp+T_rr_interval 以降にスケジュールされる. なお T_rr_interval は T_rr および tp の計算には影響しない. その代わり, 例えば FB メッセージを含まないなどの理由で tp+T_rr_interval より前にスケジュールされた Regular RTCP パケットは抑制され得る. T_rr_interval は Early RTCP パケットの送信スケジュールには影響しない.
注: T_rr_interval を独立変数として与えることは, アプリケーションが必要とする帯域消費を抑えるために Regular RTCP フィードバックを最小化しつつ, より頻繁な Early RTCP パケットでタイムリーなフィードバックを可能にすることを意図する. 全体の RTCP 帯域だけを下げると Early フィードバックの頻度も下がるため, この目的は達成できない.
n) t_rr_last を, T_rr_interval により抑制されずに最後に Regular RTCP パケットがスケジュールされ送信された時刻とする.
o) T_retention を, AVPF 実体が過去の FB メッセージを保存する時間窓とする. これは, フィードバックイベントに気づく前に他実体から FB を受信した場合にもフィードバック抑制が機能することを保証するためである. T_retention は MUST 少なくとも 2 秒とする.
p) M*Td を, 受信者を非アクティブとみなすタイムアウト値 ([1] で定義) とする.
報告すべきイベントに対するフィードバックの状況を図 2 に示す. 時刻 t0 に, そのようなイベント (例: パケット損失) が受信者で検出される. 受信者は現在の帯域, グループ規模, その他アプリケーション固有パラメータに基づき, 送信者へ FB メッセージを送る必要があると判断する.
マルチパーティセッションでフィードバックパケットの爆発を避けるため, 受信者は MUST RTCP フィードバックパケットの送信をランダム時間 T_fd 遅延させる (乱数は区間 [0, T_dither_max] 上で一様分布). 複合 RTCP パケットの送信は MUST te = t0 + T_fd にスケジュールする.
T_dither_max は Regular RTCP 間隔 T_rr から導出され, T_rr はグループ規模に基づく. 将来文書は, すべての RTP 受信者が同一の T_dither_max 算出方式を用いることが保証できるなら, RTT 等に基づく別の計算を指定してもよい.
あるアプリケーションシナリオでは, FB メッセージに許容できるローカル遅延の上界 T_max_fb_delay を受信者が定めてもよい. T_dither_max の事前推定または実際の計算が, この上界を侵害し得ることが分かる場合 (例: T_dither_max > T_max_fb_delay), 受信者は MAY 得られる利益が不十分と判断してフィードバックを全く送らない.
Early RTCP パケットがスケジュールされた場合, 次の Regular RTCP パケットのタイムスロットを MUST それに応じて更新し, 新しい tn (tn=tp+2*T_rr) と新しい tp (その後 tp=tp+T_rr) を得る. これにより Early フィードバック使用時の短期平均 RTCP 帯域が, Early なしの場合を超えないようにする.
event to
report
detected
|
| RTCP feedback range
| (T_max_fb_delay)
vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) )
|---+--------+-------------+-----+------------| |--------+--->
| | | | ( ( |
| t0 te |
tp tn
\_______ ________/
\/
T_dither_max
Figure 2: Event report and parameters for Early RTCP scheduling