twitterで見かけた、「Dissecting Performance of Production QUIC」という論文の備忘録
Nice paper on how QUIC being faster in theory doesn't always make QUIC faster in practice, due to implementation details:https://t.co/j4EbEkgPwZ
— Dan Luu (@danluu) 2021年8月7日
BTW, this kind of thing is why I often find high-level design discussions that don't really dig into the details to be overrated. pic.twitter.com/xPkChrZVVp
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の計測結果は必ずしもプロトコルを反映しているとは限らないといえる。また多くの場合、複数のデプロイメント間で一般化はできないと主張している。
これ以降は論文を読んでいた時のメモです。
続きを読む