XLINK: QoE-Driven Multi-Path QUIC Transport in Large-scale Video Services の紹介と備忘録

SIGCOMM21で発表された「XLINK: QoE-Driven Multi-Path QUIC Transport in Large-scale Video Services」というMultipath QUIC を大規模な動画サービスに適用するための、設計、実装+検証についての論文です。

著者のページで論文が公開されています。

www.hongqiangliu.com

論文へのリンク

また、以下のページでは、発表動画が視聴可能です。短くまとまっているので、動画発表を見ると理解しやすいかもしれないです。

https://dl.acm.org/doi/10.1145/3452296.3472893

論文では、マルチパスQUICをラージスケール(大規模な商用サービス)の動画サービスへの適用について書かれています。

従来提案されていたマルチパスQUICとは別のXLINKというマルチパスQUICを実装しています。

この実装では、QoEとコストの両立をゴールとしています。

XLINKでは、いくつかの動画フレームを含むストリームを構成するパケットを送り終えた時に、まだACKされていないパケットがあったら次のストリームを送る前に速いパスに再注入します。

また、最初の動画フレームの優先度を高くすることも可能です。これによって、最初の動画フレームを送り切ったときにまだACKされていない部分があったら再注入をします。

これらを無条件で適用すると冗長なトラフィックが発生する場合があります。不要な再注入は行わないためにクライアントから動画の残り時間に関するフィードバックを受け取ります。そしてクライアントにバッファされている動画の残り時間が短い場合に再注入を行います。

また、無線間の遅延を考慮して、以下の方法でパスの制御を行います。

  • プライマリパスを無線の種類で判断します。論文の例だと、5G SA > 5G NSA > Wi-Fi > LTE としています(国、地域で変わる可能性あり)。
  • どのパスから来たデータかによらず、ACKは最速のパスで返します。

以下は5章~7章の備忘録です。

続きを読む

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の計測結果は必ずしもプロトコルを反映しているとは限らないといえる。また多くの場合、複数のデプロイメント間で一般化はできないと主張している。

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

続きを読む

A Pure HTTP/3 Alternative to MQTT-over-QUIC in Resource-Constrained IoT の備忘録

HTTP3 でpub-subとMQTT-over-QUICの比較をIoTの観点から行った論文の備忘録です。

IoTという文脈で、ネットワークエミュレータに遅延と帯域を設定して、性能(最初のデータが到達するまでの時間、通信終了までの時間やスループット)、ネットワークへのオーバーヘッド(バイト量とパケット数)、リソースの使用状況(CPU使用率、RAM使用量)、の3つを比較しています。

性能面では、H3 pub-subのほうが優れた結果が得られていますが、ネットワークのオーバーヘッドやリソースの使用状況はHTTP3 pub-subのほうが MQTT-over-QUICよりも多くのリソースを使用する結果となったようです。

これらの結果から、IoTという文脈を考えた場合、トレードオフが存在しているということを示唆しています。

元論文は下で読めます。

arxiv.org

続きを読む

「QUIC at Snapchat」の備忘録

SnapchatのQUICの導入事例の記事を読んだので備忘録として書きました。

eng.snap.com

QUICの導入による、遅延の改善、BBRの適用によるエラーレート(接続タイムアウト、切断、などのエラーの発生率)、マイグレーションによるリクエスト成功率の向上、について触れられていました。

元記事は短いので元記事を読むのがいいかも?

続きを読む

WWDC21のAccelerate networking with HTTP/3 and QUICを見ました。

WWDC21で、「Accelerate networking with HTTP/3 and QUIC」という発表がありました。

developer.apple.com

iOS15、MacOS Monterey からHTTP/3とQUICが利用可能になるらしく、HTTPの進化、HTTP/3の使い方、QUICの使い方の紹介が取り上げられていました。

気になったスライドをピックアップしてまとめてみました。

続きを読む

「Debugging Modern Web Protocols with qlog」の紹介

Robin Marx氏の論文「Debugging Modern Web Protocols with qlog」の紹介です。何かおかしなところがありましたら原文を確認いただけると。

概要

本論文では「Debugging Modern Web Protocols with qlog」では、QUICのデバッグ用に作られたqlog/qivsに対する

①QUICの開発者がqlog/qvisを採用したいと思うか?

②qlog/qivsがQUICのデバッグに必要不可欠なものになるのか?

③qlogはスケールするのか?

という3つの疑問への回答を、実装者へのサーベイ結果と著者の経験をもとに議論している。

論文: https://qlog.edm.uhasselt.be/anrw/files/DebuggingModernWebProtocols_Marx_ANRWReview_23apr2020.pdf

著者のページ:

qlog.edm.uhasselt.be

qlogのgithub:

github.com

続きを読む

最近の活動

会社のお仕事で外部に公開されているもののまとめ。

登壇

  1. IoT@Loft #5 クラウドとロボティクス、オープンソース活用による次世代ロボットの可能性での登壇 LT4 - 株式会社アプトポッド AWS RoboMakerと連携するクラウド経由の遠隔制御の取り組み

aws.amazon.com

テックブログ

  1. 高頻度データ伝送におけるQUIC適用の検討 tech.aptpod.co.jp

  2. AWS re:Invent 2019 で AWS RoboMakerとintdash によるTurtlebot3の遠隔制御の展示を行いました! tech.aptpod.co.jp

  3. AWS RoboMakerとintdashでTurtlebot3を遠隔制御できるようにしました! tech.aptpod.co.jp