QUICはXORベースのFECをやめるらしい

QUICのXORベースのFECに関して、実験を行った結果無効にすると言う報告がありました。
https://groups.google.com/a/chromium.org/forum/?nomobile=true#!topic/proto-quic/Z5qKkk2XZe0


まとめとしては

  • QUICチームは、QUICのXORベースの複数の実験をした
  • 殆どのメトリックスで悪い結果となった
  • QUICのFEC初期バージョンは削除されるだろう
  • QUICチームは内部的に議論を行い、過去に成功したFECに関する情報を得て次の新しいFECをデザインする
  • TLP(Tail Loss Probe)の方がアプリケーションに取っては良さそう


軽くその資料を眺めたのでメモ

QUICのXORベースのFEC

QUICはXORベースのFECを実装しています。FECとはメッセージに冗長性を持たせることにより、メッセージの誤りなどを検出・回復する技術です。


QUICではXOR(排他的論理和)を用いたFECを利用しており、損失したパケットを再送なしに回復することが出来ます。


QUICにおける全てのパケットはFECグループに属しており、各グループはグループ番号がついています。1つのFECグループに属しているパケット全てをXOR演算した結果をFECパケットとして追加で送信します。もし仮に、FECグループのうち一つのパケットがロスしてもFECグループのパケット及びFECパケットより再送なしにリカバリすることが出来ます。

アドバンテージ

XORベースのFECは計算機的なオーバーヘッドは少なく、実装も比較的シンプルです。もとのパケットを変更することなく、XORベースのFECは随時処理ができるので、処理をするのに複数のパケットを必要とするFEC手法とは異なります。

ディスアドバンテージ

XORベースのFECは一つのみパケットを理科張りすることができます。もし2つ以上のパケットが損失した場合は、FECパケットはただの浪費になります。QUICのFECはパケットベースであり、QUICの再送はフレームベースのため、フレームの再送は損失したパケットの回復の役には立ちません。

損失の分布

パケットロスがない場合は、全てのFECはただの浪費となります。また、QUICでは1つのFECグループで2つ以上の損失があった場合も同様です。それゆえ、QUICのFECがどれほど有効か予測するためにグループの中で1つのみパケットが損失することがどれ程起こるか知る必要がありました。


QUICがパブリックに使用される前に、chromeで実験を行いました。20パケットを帯域幅にあわせて送信したり、バーストで送信しました。パケットロスの場合約65%が1つのFECパケットで回復できることが分かりました。このデータは有用でしたが、実際に輻輳制御やロスに対してリカバリ方法を持つトランスポートでのFECの価値を測定したものではありませんでした。


最近では、QUICのパケットロスの分布を詳細に記録し始めています。進行中ですが、現実の損失分布ではFEC v1は期待より悪いようです。

実験

主に重要な項目としては

  • YouTube Join Latency: ビデオが再生開始する前の時間
  • YouTube Rebuffer Rate: ビデオの再生時間のうち、再生に失敗した割合
  • Search Latency: Google検索の結果のロードにかかった時間
  • Chrome Latency: Chromeで計測されたQUICリクエストに使用した時間
FEC on headers and body

Chrome Stableで実験的にヘッダとボディでFECを有効にしました。サーバからクライアントへの通信だけ有効にしており、クライアントからサーバへの送信では影響していません。

  • YouTube Join Latency: 中央値も平均値も増加
  • YouTube Rebuffer Rate: 増加
  • Search Latency: 変化なし
  • Chrome Latency: レイテンシの平均時間は改善され、中央値は少し悪化しました。しかし、両方共統計的に有意ではありません。
FEC after ¼ RTT of quiescence

QUICチームは Chrome devで実験的に有効にし、クライアントからもサーバにFECを送信するようにしました。同時に、他の実験ではTLP after 1/4 RTTの送信を有効にし、比較を行いました。

  • YouTube Join Latency: レイテンシの中央値も平均値も増加
  • YouTube Rebuffer Rate: 増加
  • Search Latency: 大きな変化はなし。TLP after 1/4 RTT は平均値を改善。
  • Chrome Latency: FECは、統計的に有意でないものの平均値を遅くしました。Aggressive TLP は統計的に有意出ないものの、平均値を早くしました。