Dissecting Performance of Production QUIC の備忘録

twitterで見かけた、「Dissecting Performance of Production QUIC」という論文の備忘録

https://cs.brown.edu/~tab/papers/QUIC_WWW21.pdf

GoogleFacebook、Cloudflareのパブリックなエンドポイントに対する性能の評価と分析を行っている。

単一のオブジェクト取得と、ウェブページの取得を評価している。

インターネット経由の評価だが、エッジケースの分析のため遅延やロスの追加した場合の評価も行っている。

以下の3つの洞察が得られたと述べられている。

洞察1. QUICはTCPに対して1-RTT分少ない遅延で通信できるなどの特有の優位性があるにもかかわらず、その全体的なパフォーマンスは、サーバーの輻輳制御アルゴリズムの選択と、エッジケースのネットワークシナリオにおける輻輳制御の実装の堅牢性によって大きく左右される。

f:id:neko--suki:20210815114552p:plain
計測結果

Figure 4(a)からわかるように、100KBのサイズのオブジェクトを取得するときは、ハンドシェイクが1-RTT分少ないことが結果に表れている。

Figure 4(a)のヒートマップの最下段は、GoogleFacebook、Cloudflareのエンドポイントに対して、ロスを設定した上で単一のオブジェクトを取得したときのH3(over QUIC)とH2(over TCP) の性能差を表している。

ここで、Cloudflareの場合のみ、ファイルサイズが1M以上の場合にH2のほうが速い結果になっている。これは、輻輳制御をQUICはCubic、TCPはBBRとしていたことが原因である。

f:id:neko--suki:20210815162757p:plain

また、Figure 7では、GoogleFacebookのエンドポイントに対して、100msの遅延を設定して100KBのオブジェクトを取得した時に、Ackされたバイト数を時系列にプロットしている。

Googleの場合は、QUIC (H3)とTCP (H2)を比べるとTCPが1-RTT分の時間(=100ms) 遅れて同じような挙動をしていることが分かる。

一方で、Facebookの場合は、QUICが1-RTT分の速さを活かせていない結果になっている。Facebookのサーバー実装のProxygenのメンテナと話をしたところ、BBRの実装のバグが原因であることが分かった。

f:id:neko--suki:20210815163717p:plain

Figure 8では、Chrome、Proxygen (Facebook製)、ngtcp2 で同様の実験を行っている。この実験では3つのクライアントでGoogle/Facebook/Cloudflareのエンドポイントの100KB/1MB/5MBのオブジェクトにアクセスしたときの結果を、3つの中で最も速かったものを基準にしてどれくらいの性能だったかを載せている。

100KBの時にChromeが遅い場合がある。これはSSL verificationをChromeのみオフにすることができないため、その影響でこうなっている。

また、100msの遅延を設定したときに、ngtcp2がFacebookへの接続が他のクライアントに比べて異常に速いことが分かる。

f:id:neko--suki:20210815171037p:plain

Ngtcp2は暗号の設定がProxygenのデフォルトのものとは異なる。なので、ハンドシェイクに2回時間がかかっている。しかし、この挙動のおかげで性能が低下していなかった。

Proxygenでは、PTOの設定が100msになっていた(初期値は自由に設定できる)。その結果、サーバーがクライアントに送ったInitialパケットがPTO タイムアウトになる。再度Initialを送信する。しかし、その10ms後に、クライアントからハンドシェイクパケットが返ってくる。この挙動の時に、再度送信したInitialがImplicit にAckされたことになり、RTTが10msと評価される。ここで、ProxygenがこのImplicit Ackされたパケット(=RTT 10ms) として輻輳制御モードに対するRTTを与えてしまう。

そうすると、10msから本来のRTT100ms への遅延の増加を検出するので、ボトルネック帯域に到達したとして、指数関数的な帯域の増加をやめる。

f:id:neko--suki:20210815172413p:plain

Figure 11はローカルに同等の環境を構築して実験を行った結果である。ChromeやProxygenをクライアントにした場合、サーバーが見積もった帯域が非常に低く抑えられていることが分かる。

Ngtcp2は、TLSの設定が異なるので、再度Initialを送る。その結果この問題が起きていなかった。

洞察2. QUICクライアントの中には、最適なパフォーマンスを得るために、自明ではない設定の調整が必要なものがあることがわかった

Ngtcp2 のようにサーバーが想定している暗号スイートと違うものを使用していると遅延が増えてしまうので、適切な設定が必要な場合がある。

洞察3. ウェブページのパフォーマンスには、HoLの削除の影響は小さい

f:id:neko--suki:20210815174025p:plain

Figure 14では、ウェブページに対する実験の結果を乗せている。

FacebookGoogleのエンドポイントに対してロスを追加した場合、H3がH2よりもあまり優れていないことが分かる(ロスがある場合、H3のほうがHoLブロッキング除去によって性能が良くなると予想して実験をしていた)。

逆にCloudflareの場合はH3のほうが良い結果になった。しかし、異なるサイズのウェブページで結果が一貫していないので、プロトコルの設計ではなくウェブページのレイアウト設計が根本的な原因であると主張している。

f:id:neko--suki:20210815175010p:plain

Figure 15は、Cloudflareの5MBのページ相手に、SIの指標において重要になるメインとなる画像(この画像がロードされ描画されるまでの時間が早いほどSIという指標ではよい結果になる)のリクエスト開始時刻と終了時刻をヒートマップにしている。

ここから、H3は一貫して画像のロードが終わるまでの時間が速いことが分かる。

f:id:neko--suki:20210815175339p:plain

Figure 16では、ロス0%の時のHTTPのフレームの受信がいつ行われたかをプロットしている。H2とH3でリソースのロード順が違うことが分かる。

Cloudflareのエンジニアに確認した結果、H2は優先度を無視しており、H3は優先度をサポートしておらず、デフォルトでFIFOのスケジューラ(最初にリクエストが来たものを最初に返す)設定にしていたことが分かった。H3 (QUIC)によるパフォーマンスの向上はたまたま画像が先にリクエストされレスポンスを返すようになるというアプリケーション上の設定が原因で、QUICプロトコルの影響ではなかった。

f:id:neko--suki:20210815181103p:plain

Figure 18 はPage Load Time で評価している。小さなページではH3がH2よりもわずかに有利だが、大きなページでは明確な優位性はない。(最上段)

ロスを設定すると、Cloudflareの結果は単一のオブジェクトのダウンロードとは異なる結果になる。これは、3rd-partyのコンテンツが含まれておりそれらはTCPでやり取りが行われたことが原因と考えられている。(TCP-BBRでやり取りが行われるので、性能の低下が起きない。なので、QUICとTCPが同じような結果になる)

Cloudflare以外は、single-objectと同じような結果になった。つまり輻輳制御とハンドシェイクのRTTの回数の削減が、HoLブロッキングが削除された結果よりも影響が大きいと主張している。

これらを総合して、QUICの性能は本質的に実装設計の選択、バグや設定に依存しており、QUICの計測結果は必ずしもプロトコルを反映しているとは限らないといえる。また多くの場合、複数のデプロイメント間で一般化はできないと主張している。

これ以降は論文を読んでいた時のメモです。

1. Introduction

observations

  • QUICのTCPに対する接続確立の1-RTTの優位性は、小さいペイロードの時に大きな影響がある
  • 大きなペイロードの場合、QUICの設計よりもサーバーの輻輳制御のほうが影響が大きい
  • パケット番号の空間を分離することで、異なる暗号レベルに分けることが、輻輳制御の振る舞いに大きな影響を与えるエッジケースを発生させていた
  • QUICのクライアントは同じTLSの設定である必要がないため、QUICサーバーが特定の設定を前提としているとパフォーマンスに問題が起きる
  • HoLの削除は、Page Load TimeとSpeed Indexにおいて、輻輳制御と比べると影響はほとんどない

QUICのベンチマークや分析を行う際には、実装や運用(構成)上の選択を考慮するよう注意しなければならない。

4. methodology

H3 over QUIC と H2 over TCPの比較を行っている。

ベンチマークに使用したツールは公開されている。

github.com

f:id:neko--suki:20210815112803p:plain
構成図

ベンチマークの構成図。普通のインターネット回線を使用している。MacのNetwork Link Conditionerというツールを使用している。

4.1 Testbed

4.1.1 Server-side Setup

サーバーは、2020/12時点でdraft29 準拠のGoogleFacebook、Cloudflareのパブリックなエンドポイントを使用している。

2種類のベンチマークを実施している

  • single object resources: これはプロトコルの生の振る舞いを見るために行った
  • multiple object web-pages: ページロード中の振る舞いを見るために行った。

それぞれについて、静的なリソース(image, text file)、静的なページ (about page, blog post) などを使用している。

4.1.2 Client-side Setup

計測に使用したマシンはMacBook Air (OSX 10.13.6, Intel Core i5 1.3 GHz, 8 GB memory) 。コンテンツプロバイダへのRTTは10-20ms だった。

H2のクライアントはChromecURL、H3はChromeFacebookのProxygen、Ngtcp2 を使用している。

フロー制御の設定は以下の通り

  • TCP: OSXのデフォルトセッティング。バッファサイズは初期値が128KBで、最大1MB まで増える

  • QUIC: Chromeはコネクションレベルで15MB、ストリームレベルで6MB割り当てている(ベンチマークペイロードより大きいので十分なサイズ)。Proxygen、ngtcp2は1GBを双方のパラメータにしている

TCPのオプションはSACKを使用している。(QUICも同様)

ProxygenとNgtcp2がサポートしていないので、cURLSSL verificationはオフにしている。Chromeはこれをオフにできないのでその影響が結果に出ている。

4.2 Network Environment

いくつかのネットワーク状態のシミュレーションのために、Network Link Conditionerというツールを使用している。(Linux のtcのようなエミュレーションができる。)

f:id:neko--suki:20210815112324p:plain

Table2にそれぞれのパラメータが書かれている。帯域は固定で、Wi-Fi接続。

通常の場合(ロスも遅延も設定しない)と、エッジケースとして高い遅延、高いロスがあるケースを扱っている。遅延とロスは同時には設定しない。

実回線を経由するので、それぞれの設定に対して40回の実験を行っている。

5. Evaluation Framework

metrics

single object の計測は、TTLB (time-to-last-byte) を使用している。これは、最初のパケットがクライアントから送信されてから最後のバイトをクライアントが受信するまでの時間である。

Multi-object は、SI (Speed-Index)、PLT (Page Load Time) を使用している。

SIは、Google Light House、PLTはWProfX で取得している。

Statical Analysis

インターネット経由になるので、メディアンを使用する。

6. Measurement Tools

計測のワークフロー。single objectは、クライアントは3種類使っていて、multi-objectはChromeのみ(ウェブページのロードになるので)。

f:id:neko--suki:20210815114047p:plain

7. Single-Object Results

7.1 TCP(H2) vs QUIC(H3) Performance

予想では、一つのBidirectional Streamを使っているだけなで差は大きくならないと考えられていたが、そうはならなかった。

f:id:neko--suki:20210815114552p:plain
計測結果

計測結果、Figure 4aの左のヒートマップがGoogle、真ん中がFacebook、右がCloudflareの結果になっている。それぞれのヒートマップは左の列が100KBのオブジェクト、真ん中が1MBのオブジェクト、右の列が5MBのオブジェクトを表している。最初の行が0.0% のロスを設定(=デフォルトでなにも設定しない)、真ん中の行が0.1%、下の行が1%のロスを設定している。

Figure 4.b は、同様の構成だが各行が遅延を設定した場合を表している。1行目は遅延50msを設定した場合、2行目は遅延100msを設定した場合になっている。

ヒートマップは、青色の場合はH3のほうが速く赤色の場合はH2のほうが速い。また差が5%以内のものは数値には書かれていない。

7.1.1 No Extra Loss or Delay

100KBのペイロードでは、H3が良い結果になる。一方で、ペイロードが大きくなるとほぼ同じような結果になる。

この挙動は以下の二つの理由から、QUICがTCPに対して1RTTのハンドシェイクを行っていることによるものと考えられる。

  1. コンテンツプロバイダ間で一貫しており、実装設計ではなくプロトコル設計が根本にあることが示唆されている。

  2. 1RTTの差はshort-lived connectionのほうが、long-lived connection に比べると影響が多い。(大きいデータをダウンロードする場合のほうが、全体の時間に締める1-RTT削減による改善の効果が小さいという意味)

ネットワークの帯域幅が10mbpsの場合、QUICの1RTTの優位性は、ペイロードが1MB未満の接続には大きな影響を与えるが、それ以外の接続には無視できる程度の影響しか与えないことが分かった。

7.1.2 Extra Loss

ロスを追加した場合

ペイロードが100KBの時は同様に、H3のほうが良い結果になるがペイロードサイズを大きくするとH2とH3の性能は大きな差がなくなる。

ただし、Cloudflareのものだけは、1%のロスを設定したときに他の二つのエンドポイントとは異なる振る舞いをする。(H2のほうが良い結果になる)

f:id:neko--suki:20210815115925p:plain

この結果を分析するために、Figure 5ではGoogleとCloudflareそれぞれについてH2とH3のAckされたバイト数を比較している。CloudflareのH3は、H2に遅れてしまい追いつけなくなっている。

ここから、CloudflareはTCPにBBR、QUICはCUBICを使っているのではないかと考えた。それを確認するために、40回追加のイテレーションをProxygen (H3)とcURL(H2) のクライアントを使って、Cloudflareの1MBのエンドポイントに対して1%のロスを設定して行った。

f:id:neko--suki:20210815120309p:plain

Figure 6ではその結果のTTLBと最初に再送されたバイトのオフセットの相関関係を見ている。

図左のQUIC(cubic)についてTCP(BBR)と比べて、強い相関関係があることが分かる。(早期に再送が発生した場合にTTLBが大きな値になっているという意味だと思われる)

Figure 6 (a)を見るとTCPは再送の比率が10%を超えていることが分かる。しかし性能に与える影響は小さいことが分かる。

この大量の再走は、Cloudflareがロスに反応する前に計測を行ったクライアント側のバッファが埋まっていることが原因で、その結果余計にパケットがロスしている。(本来であれば1%のはず?)

ロスが多いのにもかかわらず、TCPのほうがより良い性能になっていることから、どのように輻輳制御アルゴリズムが反応するかが

このように、QUICよりも1桁多いロスが起きているにもかかわらず、TCPはより良いTTLBを達成することができている。これによって輻輳制御のロスに対する反応が、ロスしたパケットの総数よりもはるかに多くTTLBに影響を与えることが示された。

cubicではロスが早い段階で検出されるとWmax がその時点のcwndで固定されるので、ランダムロスによって早期にロスが発生するとかなり低い値で抑えられてしまう。BBRの場合は、ロスよりもデータがAckされたレートを使用しているので、 早期のロスの影響は少なかった。(Figure 6の、TCP(BBR)では相関関係が低く、QUIC (cubic)のほうは相関関係が高い)

結果、CloudflareのCubicを使っている構成では、ランダムロスが発生するような環境では帯域を十分に使えなかった。

10mbpsの帯域幅での持続的なランダムロスは、一般的な実世界のネットワーク状況を反映していない可能性がありますが、輻輳制御がQUICのパフォーマンスに大きな影響を与えることが示された。

したがって、QUICとその輻輳制御を区別することは重要であり、これを誤って行うとQUICに対する誤った認識を招くことになる。

7.1.3 Extra Delay

GoogleのエンドポイントはH3のほうが良い結果になっている。 一方で、Facebookのエンドポイントは 100KB, 100ms の時に、H2のほうが良い結果になっている。

f:id:neko--suki:20210815162757p:plain

Figure 7 は100msecの遅延を追加したときにAckされたバイトをプロットする。

Googleのエンドポイント相手(Figure 7 (a))だと、Chrome H3のほうが、1-RTT 少ない影響でChromeH3のほうがChrome H2よりも早くACKが始まっている。

Facebookのエンドポイント(Figure 7 (b)) だと、この1-RTTの優位を維持できない結果になっている。

Proxygenのメンテナと話をしたところ、BBRの実装のバグが見つかった。FacebookTCPもBBRを使っていた。

GoogleFacebookもBBRを使っていたが、QUICの性能では大きな差が計測された。

TCPはチューニングされたカーネルを使っているので同じ輻輳制御アルゴリズムで同じ結果になる。

このように、QUICのユーザー空間の性質は、輻輳制御の実験という点ではより柔軟性がある。しかし、通常のネットワーク条件と異常なネットワーク条件でうまく動作するように輻輳制御の実装を最適化することは、Facebookのような大規模なコンテンツプロバイダであっても明らかに簡単な作業ではないといえる。

7.2 Client Consistency

ここからはクライアントを変更した計測。

f:id:neko--suki:20210815163717p:plain

Figure 8にクライアントを変更した結果を載せている。

ヒートマップの各セルの値は、3つのクライアントのメディアンの値の中で一番小さいものに対しる性能比を表している。つまりあるクライアント(行)に対する値が0の場合は、そのクライアントの性能が一番良かったことを表している。

100KB の時Chromeは一貫して遅い。これは、SSL Verificationの20msが理由。

Proxygen、Ngtcp2 は行っていない。20msは、GoogleFacebook、Cloudflareのそれぞれのendpointに対する13.9%、14.7%、7.2% となる。これはChrome 100KBの時の遅くなっている割合と同じくらいになる。

なので、ここから、ロスなし、帯域10Mbps、20msのRTTの場合は、QUICのクライアントは同等のパフォーマンスになることが分かった。

Figure 8 (c)から、Facebookのエンドポイントに対して100msの遅延を追加した場合、Ngtcp2 が他を大きく上回っている。これは、Ngtcp2のデフォルトのTLS暗号グループとFacebookTLSの設定に互換性がないことが原因だった。

7.2.1 Proxygen Implicit Ack Bug

Ngtcp2のデフォルトのTLS Cipher GroupはP256、ProxygenのデフォルトはX25519 である。

通常であれば、Initialの再送信によって1RTTが追加で発生する。ところが100msの遅延が追加することで、ProxygenのバグによってInitialの再送信がNgtcp2にとってはメリットになっていることがローカルでの再現実験で分かった。

RTTが100msを超えるときに、ProxygenのサーバーはInitialパケットのACKを受信する前にProbe Timeout(PTO)が発生する。それによりProbeパケットの送信が発生する。(RTTの計測がない場合は任意の値を設定できるので、Proxygenでは100msとしている。)。以降はサーバーの最初のパケットとProbeパケットをそれぞれInit_0、Init_1 とする

Probeパケットは受信側からACKを誘発し、その新しいACKパケットの情報から前のパケットが実際にロスしたのかを確認することを目的としている。

QUICの仕様では、PTO Probeは新しいデータがあれば含まないといけない、つまり実際には送信側によって普通のパケットとして扱われる。 言い換えると、Probeパケットは自身がAckされなかったら再度発生する。

f:id:neko--suki:20210815171037p:plain

Figure 10(a), (b)は Init_0を送った後にどのようにPTOが切れて、Init_1 を引き起こしているかを表している。高いRTTを設定しているので、Init_1を送った後にクライアントからのInit_0に対するACKを受け取る。Ngtcp2とそれ以外の違いは、Handshakeパケットではなく新しい鍵を含んだInitial パケットで応答している点(cipher suiteが違うため)。

QUICサーバーはHandshakeパケットをクライアントから受信したら、Initialパケットの処理をやめてそれらの輻輳制御の状態を廃棄する。こうする理由は、前のInitial パケットがAckされていなくても即座に処理を開始できるようにするためである。サーバーの観点だと、クライアントからのHandshakeパケットを受信したことはInitialフェーズの完了を意味し、それ以降の Initialパケットは無関係であることを意味する。

Proxygenサーバーが、Init_1がインフライト中にハンドシェイクパケットを受信すると、暗示的にInit1がACKされたことになり、実際のACKを待たずに処理を先に進めることができる。ImplicitなACKは、インフライトなinitialを即座に捨てる。これ自身は問題ではない。問題となるのは、Proxygenが、このImplicit ACKから輻輳制御モードに対するRound Tripを与えてしまうことにある。

Figure 10(a)では、実際のRTTが100ms以上にもかかわらず10ms以下の値が登録されてしまう。(サーバーがInitialパケットなどを送信するタイミングが55ms、タイムアウトが発生しInit_1を送るのが155ms、クライアントから正しいパケットを受け取るのが165ms。ここでInit_1がImplicit Ackになるので、165ms-155msで10msがRTTになる)

これはBBRの輻輳制御モードに大きな影響を与える。この場合、BBRは10msから100msへの遅延の増加を検出するので、ボトルネック帯域に到達したとして、指数関数的な帯域の増加をやめる。

f:id:neko--suki:20210815172413p:plain

Figure 11 はローカルで実験を行った結果である。グラフからChrome, Proxygenの場合のサーバーはestimated bandwidthが増加していないことが分かる。

Ngtcp2の場合は、TLSの設定が違うのでこの問題には遭遇しない。Ngtcp2は正しくACKするので、暗示的なACKによるRTTの急増は発生しない。

7.2.2 Aftermath

f:id:neko--suki:20210815172713p:plain

これについてパッチが当たった後に計測されたものがFigure 12。H3の性能がパッチをあてる前と比べて向上していることが分かる。(もともと、ChromeとProxygenが遅かったのが改善されたということが言いたい)

今回のバグは、QUIC独自の機能であるパケット番号空間の分離が、不適切な扱いを受けた場合にネットワークのパフォーマンスを著しく低下させる新規のエッジケースを生み出すことを示している。

このバグは、クライアントのコンフィギュレーションがQUICの性能の最適化に重要な役割を果たしていることを示す。Ngtcp2はFacebookとCloudflareのサーバー相手に2-RTTがハンドシェイクにかかっていたことで、他のクライアントより性能が低かった。Ngtcp2を適切なTLSの設定にすると、性能はほかのクライアントと同等な結果になった。

8. Multi-Object Result

いくつかの例外を除いて、シングルオブジェクトのベンチマーク結果によると、GoogleFacebook、Cloudflareのプロダクションエンドポイントに対して、多重化が行われていない場合、QUICはTCPと同等かそれ以上の性能を発揮している。

MultiplexingによるHoLの除去により、よりH3にとって好ましい結果が出ることが期待できる。

特に、ロスを追加した場合にはさらなるパフォーマンスの向上が期待できる。ただし、Cloudflareのエンドポイントの場合は輻輳制御にCubicを使用しているためロスを追加するとH3の性能は低下すると予想している。

8.1 Speed Index

f:id:neko--suki:20210815174025p:plain

Figure 14 を見ると、FacebookGoogleエンドポイントの場合ロスを追加したときにH3はH2よりあまり優れていないことが分かる。

逆にCloudflare対向の場合はH3のほうが良い結果になったが、異なるサイズのウェブページで結果が一貫していないことから、プロトコル設計ではなくウェブページのレイアウト設計が根本的な原因であることが明らかになった。

SIは小さいサイズのページで一貫してよい結果となっている。これは、1-RTTハンドシェイクの影響であるといえる。

f:id:neko--suki:20210815174600p:plain

Figure 14はLighthouseが生成したCloudflareのlargeサイズのページである。上部のH2のほうが下部のH3よりも、赤枠で囲まれた画面の大きい部分を占める画像のダウンロードが遅いため悪い結果になっている。

Cloudflareに対するこの現象はネットワークの状態にかかわらず起きている。

8.1.1 Cloudflare

H3とH2を比較するために、Cloudflareのlargeサイズのページの画像について、リクエストの開始時刻と終了時刻を分析した。

f:id:neko--suki:20210815175010p:plain

Figure 15のヒートマップから、H3ではネットワークの状態にかかわらず一貫して画像のロードが速いことが分かる。

根本原因の調査のため、0%ロスの時にいつHTTPのフレームを受信したかを調べた。

f:id:neko--suki:20210815175339p:plain

Figure 16で示すように、H2とH3でのリソースのロード順番が違うことが分かる。H3の場合、Figure 15からリクエストを送るのが遅く受信が速いことが分かっていたが、Figure16の図からもMain Imageの受信が速いことが分かる。(Figure 15の0%ロスの時と同じ)

ブラウザはリソースのダウンロード順をヒントから決めることができるので、ブラウザが割り当てたリソースの優先度を調査した。H2とH3は本質的には同じ優先度にしている。H2とH3は異なる優先度のスキームを採用しているが、main imageは他の画像/gifよりも優先度が高くなっている。

なので、CloudflareのエッジサーバーはH3の優先度には従っているが、H2は無視していると考えられた。Cloudflareのエンジニアに確認をしたら、CloudflareのH2のスタックはブラウザの画像の優先度の提案を無視していると回答があった。Cloudflareは、これらの変更によりパフォーマンスが向上したとしているが、今回のベンチマーク結果によると、ブラウザの優先順位の値は視覚的なQoEのために依然として重要であることが分かる。

Cloudflareのエンジニアは、H3の優先度も現在サポートされていないと言った。ChromeのH3の優先度に合わせて動く挙動は、デフォルトのFIFOのスケジューラの結果そうなっている。H3の優先順位を介してブラウザがコンテンツを順次読み込むべきだと示し、それがたまたまCloudflareのデフォルトのQUICストリームスケジューラと一致している。

分析の結果、大きなサイズのCloudflareのWebページでH3がH2よりもパフォーマンスを向上したのは、QUICプロトコルによるものではなく、アプリケーションの設定の違いによるものであると結論づけられた。

これらの違いは、Cloudflare社が自社のH3ベンチマークについて説明した際には言及されていませんでした。これは、この研究での総合的なアプローチが、H2とH3の比較を歪める、これまで省略されていたプロトコル以外の要因の特定に役立つことを示している。

8.1.2 Stream Multiplexing

f:id:neko--suki:20210815180306p:plain

Figure 17は、GoogleFacebook、Cloudflareのそれぞれのmultiplexingの戦略の際を会わらしている。

CloudflareのサーバーはSequentialに送信するので、HoL Blocking の除去は効果を発揮しないことが分かる。

ラウンドロビンに切り替えることは当然のことだと思われるかもしれませんが、実際には、前のセクションで示したようなリソースの優先順位付けや、潜在的なパケットロスのパターンなどにより、ラウンドロビンを使用する利点ははるかに微妙なものです。

GoogleFacebookはRound-robinを使用している。過去の先行研究では、round-robinでブロックされるデータが減っていることが示されている。しかし、SIの結果を見るとロスの追加による効果は無視できるレベルであることが分かる。ただし、ランダムロスだけを扱っているので、バーストロスの場合は異なる結果が得られる可能性がある。

8.2 Page Load Time

PLTは、リソースのロード順が関係ない指標である。

f:id:neko--suki:20210815181103p:plain

Figure 18から、PLTもSIと一致した結果になる。小さなページではH3がH2よりもわずかに有利だが、大きなページでは明確な優位性はない。

Cloudflareの結果は、ロスを追加した場合、H3がより良いかH2と同じくらいの結果になっている。これはsingle objectのダウンロードとは異なる結果になる。

Cloudflareの環境のsingle objectとmultiple objectの違いは、3rd-partyのコンテンツを使っていたことが原因の可能性がある。これらはTCP上でやり取りされるので、PLTに影響を与える可能性がある。

GoogleFacebookのものはすべてH3で提供されていた。

f:id:neko--suki:20210815181553p:plain

Table3がH3でダウンロードされたリソースの割合を表している。JavaScriptCSSはPLTに影響を与えるので、これらがPLTの結果に影響した可能性がある。

Cloudflare以外は、single-objectと同じような結果になった。つまり、輻輳制御とハンドシェイクのRTTの回数の削減が、HoLブロッキングが削除された結果よりも影響が大きい。

さらに、Cloudflare の Web ページにサードパーティTCP コンテンツが存在することや、前述の Cloudflare の H2 と H3 の多重化戦略の違いを考慮すると、Cloudflare の PLT の結果に対するプロトコル設計の影響を正確に測定することは困難である。

9. Conclusion

先行研究ではローカル環境行われていた計測を、この研究ではプロダクションの環境で行ったことが新しい。

QUICとTCPの間、およびQUICの実装間でのパフォーマンスの不一致の原因となる、複数の、プロトコルおよび実装の側面を特定することができた。

ほとんどの性能差は、開発者の設計とオペレータの設定(輻輳制御アルゴリズムや暗号スイートの選択など)に起因することが明らかになった。ほとんどの場合、性能差は実装の詳細によるもので、QUICプロトコルの固有の特性によるものではなかった。

この点を考慮して、QUICのエッジケースへの対応や輻輳制御アルゴリズムを一から実装する際のオーバーヘッドを考慮すると、実際にQUICを最適化することは困難で時間がかかると結論づけられている。QUICは、レイテンシー、汎用性、アプリケーション層の簡素化という点で、TCPに比べて本質的に優れていることを示した。しかし、これらの利点は、実装上の高いオーバーヘッドを犠牲にしており、実装間での性能の不一致につながっている。GoogleFacebook、CloudflareのQUICのパフォーマンスプロファイルに大きな違いがあることを示すことで、多くのユースケースにおいて、QUICを導入してもネットワークやアプリケーションのパフォーマンスが自動的に改善されるわけではないことを示している。