10. Congestion Control (輻輳制御)

10. Congestion Control (輻輳制御)

RTP に対する輻輳制御は, RFC 3550 [5] および適用可能な RTP プロファイル (例: RFC 3551 [16]) に従って使用しなければなりません. ベストエフォート (best-effort) サービスを使用する場合の追加要件として, 本ペイロード形式の利用者はパケット損失を監視し, 損失率が許容可能な範囲内にあることを確保しなければなりません. 同一ネットワークパス上で同一のネットワーク条件にある TCP フローが, 妥当な時間尺度で測定した平均スループットが RTP フローが達成する値以上であれば, パケット損失は許容可能とみなされます. この条件は, 輻輳制御機構を実装して送信レート (または階層型マルチキャストセッションで購読する階層数) を適応させるか, 損失率が許容できないほど高い場合に受信者がセッションを離脱するよう手配することで満たせます.

リアルタイム符号化を用いる場合, 輻輳制御の原則に従うために必要なビットレート適応は容易に実現できます. 一方, 事前符号化コンテンツを送信する場合, 帯域適応には, 同一コンテンツの異なるビットレートでの複数の符号化表現の利用可能性, またはビットストリーム内に non-reference pictures (非参照ピクチャ) または sub-sequences (サブシーケンス) [22] が存在することが必要です. 異なる表現間の切り替えは, 通常同一 RTP セッション内で行えます, 例えば Extended プロファイルの SI/SP スライスとして知られる概念を用いるか, Instantaneous Decoding Refresh (即時デコードリフレッシュ, IDR) ピクチャ境界でストリームを切り替えることによります. ダウングレード不能なパラメータ (profile/level ID の profile 部分など) の変更が必要な場合にのみ, メディアストリームの終了と再開が必要となります. これは異なる RTP ペイロード型を用いることで実現できます.

MANE は第 7.3 節で概説した提案に従い, 先行するパケット損失によりストリームが損傷した際に, パケットストリームから特定の使用不能パケットを除去してもよいです. これは特定の特殊なケースでネットワーク負荷を軽減するのに役立ちます.

修正日语第10章中的错误：将「第 7.3 节」改为「第 7.3 節」。

<｜tool▁calls▁begin｜><｜tool▁call▁begin｜> StrReplace