要約

  • RFC 2354 は、損失検出、データ復元、再生期限への到着、知覚品質を別の証拠として扱い、万能な修復方式を置かなかった。
  • 損失後に追加される修復データは同じボトルネックを消費するため、混雑、損失、追加修復という自己増幅ループを作り得た。

Colin PerkinsとOrion Hodsonによる文書は1998年6月にInformational RFCとして公開された。Internet Standardではなく、包括的な調査でもない。送信側が関与する連続メディア修復に範囲を限定し、受信側だけの隠蔽処理は対象外にした。

最初の区別はメディア単位とパケットである。単位は符号器が作る時間区間で、一つのパケットには複数単位を入れられる。したがって、元のパケットを正確に戻すこと、低品質版で時間を埋めること、大きな穴を小さく散らすこと、期限後に完全なコピーを得ることは、同じ成功ではない。

RTPのシーケンス番号は送信順序と欠落を示し、タイムスタンプは再生順序を示す。修復では単位が意図的に順不同で届くため、受信側は到着順でなく時刻で再生を組み立てる。番号の穴は何が消えたかを示すが、いつまで待てるかは再生時計が決める。

損失の形から費用を決める

RFC 2354が引用したMbone観測では、大規模セッションの多くの受信者が約2〜5%の損失を経験し、一部はさらに高かった。単一パケットの損失が圧倒的に多く、複数パケットのバーストは一桁ほど少なく、長いバーストは稀だった。これは当時の測定であり、現在の全経路を表す数字ではない。

それでも優先順位は明確だった。まず頻発する単発損失を効率よく扱い、短いバーストへの追加保護を評価する。稀な長時間障害のために常時大きな冗長性を送れば、保険料が通常通信を圧迫する。

再送は欠落後に要求とコピーを送る。正確に戻せても往復時間と双方向トラフィックが必要である。大規模マルチキャストでは、ほぼすべてのパケットを誰か一人が失う可能性があり、要求抑制がなければ局所損失が全体負荷になる。RFCは遅延を許せる用途に再送を置き、単発損失をFECで、バーストを追加再送で補う組合せも示した。

メディア非依存FECは損失前にパリティや符号データを送る。受信側は送信元へ戻らず元パケットを正確に再構成できる。単純なXORは軽く、強い符号はバーストに耐える一方、計算と遅延が増える。損失がない時間にも保護データは帯域を使う。

メディア固有の冗長化は符号器の知識を使う。低ビットレート版の音声、動画の重要部分の複製、感度の高いビットだけの保護なら、少ない帯域と遅延で知覚上の連続性を保てる。しかし復元は近似になり得る。「何か再生できた」と「元データが戻った」は別である。

インターリーブはコピーを増やさず、隣接する単位を別パケットに分散する。一つのパケット損失が長い無音でなく複数の短い穴になる。帯域は増えないが、並べ直すまで再生を待つ。放送型には使えても会話の応答性を損ねる。

期限が方式を選ぶ

一方向の非対話配信では、遅延より受信品質を優先できるため、三方式すべてに余地がある。対話セッションでは再送の往復とインターリーブの待機が重く、低遅延FECが残る。それでも汎用FECか符号器固有の冗長化かは、実装と許容品質で変わる。

重要なのは、損失を見たときの反応だった。混雑による損失へ大量の修復を返せば、同じキューをさらに満たし、新しい損失を生み、その損失が次の修復を呼ぶ。RFC 2354は極端な修復トラフィックがサービス妨害になり得ると述べた。

当時、ストリーミング用の標準的な混雑制御はなかった。文書はTCP相当スループットの近似式を使い、合理的な上限を考えた。ただし平均式はTCPの動的応答を再現せず、マルチキャストのRTTも平均的な推定に過ぎないと明記した。

後のRFC 4588とRFC 5109はRTP再送と汎用FECを別々に規定した。RFC 8085はUDP自身に混雑制御がなく、アプリケーションが総送信量を制御すべきだと整理した。歴史が示すのは一つの回復スイッチではなく、別々の責任面である。

RFC 2354の価値は記録の分離にある。欠落を検出した、修復を送った、単位を再構成した、期限に間に合った、利用者が連続性を得た。この五つを一つに畳まなければ、修復が本当に有用な仕事を増やしたか判断できる。