バッファブロート（Bufferbloat）とは、ネットワーク機器のバッファ（一時的に荷物を溜める待機場所）が大きすぎて、回線が混んだときに待ち時間が膨れ上がる現象だ。上りの速度テストは20Mbpsを示した。配信のビットレートは12Mbpsだから、数字の上では余裕がある。ところがリモートのディレクターから戻ってくる声が、こちらの動きより0.2秒ほど遅れて聞こえる。配信映像も、数秒おきに粗くなる。
仕組み
回線の出口が細いところ（たとえば上り回線）に、送信側からデータが押し寄せる。
出口に入りきらない分は、機器のバッファに溜まる。
バッファが大きいと、パケットを捨てずに溜め込み続ける。その結果、溜まった分だけ順番待ちが長くなる。
待ち時間は「バッファ内のデータ量 ÷ 回線速度」で決まる。
回線業者に電話をかけ、ケーブルを替え、エンコーダーの設定を疑った。最後に見つかったのは、誰も測っていなかった1つの数字だった。回線が忙しいときの往復時間である。
速度テストが教えてくれるのは、1秒間に何ビット流せるかだ。配信の品質を決めるもう1つの数字、つまり「流している最中に待ち時間がどこまで伸びるか」は、速度テストの画面には出てこない。測っていなかった自分を責めたくなるが、責める相手は別にいる。
この待ち時間の膨張には名前がある。バッファブロートだ。回線の入口にある荷物の待機場所（バッファ）が満杯まで詰まり、後から来たパケットが順番待ちをさせられる現象を指す。GettysとNicholsがACM Queueに書いた論文（2011年）は、ケーブルモデムのバッファが128KBや256KBだった例を挙げている。別の測定では、空いているときの往復時間が10ミリ秒未満の経路で、負荷をかけると1.2秒を超えたという。
数字を1つ置く。256KiBのバッファが、上り10Mbpsの出口で満杯になったとする。最後尾のパケットは 256×1024×8÷10,000,000 ≒ 0.21秒、つまり210ミリ秒待たされる。待ち時間を抑える仕組みであるCoDelが目標にする値は5ミリ秒（RFC 8289）。210÷5で、その42倍だ。
これは配信担当の腕の問題ではない。洗面台にたとえるとわかりやすい。排水口が細いのに洗面ボウルだけが大きいと、蛇口を全開にした瞬間から水位が上がり続ける。蛇口を閉めても、溜まった水が抜けるまで待たされる。待ち時間は「溜まった水の量÷排水の速さ」で決まる。排水口が上り回線、ボウルがバッファ、蛇口が自分の配信と同じ回線に乗ったすべての通信だ。ボウルばかり大きく作った設計が悪いのであって、蛇口をひねった人が悪いのではない。
対処はある。測定は3つの手順、5分以内で終わる。抑える方法は3系統に絞れる。ただし手順をここで書けば、あなたは半分だけ知って現場に入り、かえって迷うことになる。だから詳細は有料部にまとめた。
この記事の有料部で手に入るもの
- 5分以内で終わる「負荷をかけたときの往復時間」の測り方と、合格・要対策・危険の3区分に分ける判定表
- 測定値からバッファの大きさを逆算する式
- 実測した上り速度から、送出ビットレート・出口の絞り値・機器の隔離を決める計算手順
- SRTのレイテンシを、負荷時の往復時間から決め直す計算例
- 会場のネットワーク管理者に、数字で依頼するための書式
往復時間が20ミリ秒から230ミリ秒に跳ねた回線では、SRTの再送を間に合わせるために必要なレイテンシが、80ミリ秒から920ミリ秒に膨らむ（SRT Deployment Guideの「往復時間の4倍」を使った算出。20×4と230×4）。80ミリ秒のまま送り続ければ、再送が間に合わず、欠けた映像がそのまま視聴者の画面に出る。次の現場に同じ設定を持ち込まないための手順が、このあとにある。
（ここから先は有料エリア）
コメント