twitter で見かけた、「Dissecting Performance of Production QUIC」という論文の備忘録
https://cs.brown.edu/~tab/papers/QUIC_WWW21.pdf
Google 、Facebook 、Cloudflareのパブリックなエンドポイントに対する性能の評価と分析を行っている。
単一のオブジェクト取得と、ウェブページの取得を評価している。
インターネット経由の評価だが、エッジケースの分析のため遅延やロスの追加した場合の評価も行っている。
以下の3つの洞察が得られたと述べられている。
洞察1. QUICはTCP に対して1-RTT分少ない遅延で通信できるなどの特有の優位性があるにもかかわらず、その全体的なパフォーマンスは、サーバーの輻輳 制御アルゴリズム の選択と、エッジケースのネットワークシナリオにおける輻輳 制御の実装の堅牢性によって大きく左右される。
計測結果
Figure 4(a)からわかるように、100KBのサイズのオブジェクトを取得するときは、ハンドシェイクが1-RTT分少ないことが結果に表れている。
Figure 4(a)のヒートマップの最下段は、Google 、Facebook 、Cloudflareのエンドポイントに対して、ロスを設定した上で単一のオブジェクトを取得したときのH3(over QUIC)とH2(over TCP ) の性能差を表している。
ここで、Cloudflareの場合のみ、ファイルサイズが1M以上の場合にH2のほうが速い結果になっている。これは、輻輳 制御をQUICはCubic、TCP はBBRとしていたことが原因である。
また、Figure 7では、Google とFacebook のエンドポイントに対して、100msの遅延を設定して100KBのオブジェクトを取得した時に、Ackされたバイト数を時系列にプロットしている。
Google の場合は、QUIC (H3)とTCP (H2)を比べるとTCP が1-RTT分の時間(=100ms) 遅れて同じような挙動をしていることが分かる。
一方で、Facebook の場合は、QUICが1-RTT分の速さを活かせていない結果になっている。Facebook のサーバー実装のProxygenのメンテナと話をしたところ、BBRの実装のバグが原因であることが分かった。
Figure 8では、Chrome 、Proxygen (Facebook 製)、ngtcp2 で同様の実験を行っている。この実験では3つのクライアントでGoogle /Facebook /Cloudflareのエンドポイントの100KB/1MB/5MBのオブジェクトにアクセスしたときの結果を、3つの中で最も速かったものを基準にしてどれくらいの性能だったかを載せている。
100KBの時にChrome が遅い場合がある。これはSSL verificationをChrome のみオフにすることができないため、その影響でこうなっている。
また、100msの遅延を設定したときに、ngtcp2がFacebook への接続が他のクライアントに比べて異常に速いことが分かる。
Ngtcp2は暗号の設定がProxygenのデフォルトのものとは異なる。なので、ハンドシェイクに2回時間がかかっている。しかし、この挙動のおかげで性能が低下していなかった。
Proxygenでは、PTO の設定が100msになっていた（初期値は自由に設定できる）。その結果、サーバーがクライアントに送ったInitialパケットがPTO タイムアウト になる。再度Initialを送信する。しかし、その10ms後に、クライアントからハンドシェイクパケットが返ってくる。この挙動の時に、再度送信したInitialがImplicit
にAckされたことになり、RTTが10msと評価される。ここで、ProxygenがこのImplicit Ackされたパケット(=RTT 10ms) として輻輳 制御モードに対するRTTを与えてしまう。
そうすると、10msから本来のRTT100ms への遅延の増加を検出するので、ボトルネック 帯域に到達したとして、指数関数的な帯域の増加をやめる。
Figure 11はローカルに同等の環境を構築して実験を行った結果である。Chrome やProxygenをクライアントにした場合、サーバーが見積もった帯域が非常に低く抑えられていることが分かる。
Ngtcp2は、TLS の設定が異なるので、再度Initialを送る。その結果この問題が起きていなかった。
洞察2. QUICクライアントの中には、最適なパフォーマンスを得るために、自明ではない設定の調整が必要なものがあることがわかった
Ngtcp2 のようにサーバーが想定している暗号スイートと違うものを使用していると遅延が増えてしまうので、適切な設定が必要な場合がある。
洞察3. ウェブページのパフォーマンスには、HoLの削除の影響は小さい
Figure 14では、ウェブページに対する実験の結果を乗せている。
Facebook やGoogle のエンドポイントに対してロスを追加した場合、H3がH2よりもあまり優れていないことが分かる（ロスがある場合、H3のほうがHoLブロッキング 除去によって性能が良くなると予想して実験をしていた）。
逆にCloudflareの場合はH3のほうが良い結果になった。しかし、異なるサイズのウェブページで結果が一貫していないので、プロトコル の設計ではなくウェブページのレイアウト設計が根本的な原因であると主張している。
Figure 15は、Cloudflareの5MBのページ相手に、SIの指標において重要になるメインとなる画像（この画像がロードされ描画されるまでの時間が早いほどSIという指標ではよい結果になる）のリクエス ト開始時刻と終了時刻をヒートマップにしている。
ここから、H3は一貫して画像のロードが終わるまでの時間が速いことが分かる。
Figure 16では、ロス0%の時のHTTPのフレームの受信がいつ行われたかをプロットしている。H2とH3でリソースのロード順が違うことが分かる。
Cloudflareのエンジニアに確認した結果、H2は優先度を無視しており、H3は優先度をサポートしておらず、デフォルトでFIFO のスケジューラ（最初にリクエス トが来たものを最初に返す）設定にしていたことが分かった。H3 (QUIC)によるパフォーマンスの向上はたまたま画像が先にリクエス トされレスポンスを返すようになるというアプリケーション上の設定が原因で、QUICプロトコル の影響ではなかった。
Figure 18 はPage Load Time で評価している。小さなページではH3がH2よりもわずかに有利だが、大きなページでは明確な優位性はない。（最上段）
ロスを設定すると、Cloudflareの結果は単一のオブジェクトのダウンロードとは異なる結果になる。これは、3rd-partyのコンテンツが含まれておりそれらはTCP でやり取りが行われたことが原因と考えられている。(TCP -BBRでやり取りが行われるので、性能の低下が起きない。なので、QUICとTCP が同じような結果になる）
Cloudflare以外は、single-objectと同じような結果になった。つまり輻輳 制御とハンドシェイクのRTTの回数の削減が、HoLブロッキング が削除された結果よりも影響が大きいと主張している。
これらを総合して、QUICの性能は本質的に実装設計の選択、バグや設定に依存しており、QUICの計測結果は必ずしもプロトコル を反映しているとは限らないといえる。また多くの場合、複数のデプロイメント間で一般化はできないと主張している。
これ以降は論文を読んでいた時のメモです。
続きを読む
