It’s Over 9000: Analyzing Early QUIC Deployments with the Standardization on the Horizon

「It’s Over 9000: Analyzing Early QUIC Deployments with the Standardization on the Horizon」はQUICのデプロイ状況を調査した論文です。

論文のリンク: https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/zirngibl2021over9000.pdf

紹介記事のページ: 2.6 million addresses support QUIC | APNIC Blog

データなど: quicimc.github.io

論文の調査が行われた時点で、QUICをサポートする230万のipv4ホストと30万のipv6を発見しています。

また、トランスポートパラメータの種類も調査しており、合計で45の異なるコンフィギュレーションが見つかりました。

実際に発見されたトランスポートパラメータの種類は以下のリンクから見ることが可能です。

github.com

デプロイされているホストの数と比べるとパラメータの設定の種類が少ないように見えます。これは、デプロイしているプロパイダ数がそこまで多くないことが影響しているようです。

s2n-quicのecho exampleを動かしてみた

s2n-quicはAWS が公開したRust のQUIC実装です。サンプルのエコーを動かしてみました。

aws.amazon.com

echoのexampleは https://github.com/aws/s2n-quic/tree/main/examples/echo に用意されています。

リポジトリをクローンして、リリースビルドをします。

$ git clone https://github.com/aws/s2n-quic.git
$ cd s2n-quic/examples/echo/
$ cargo build --release

サーバーとクライアントを別のターミナルで開きます。

サーバーを実行します。

$ ./target/release/quic_echo_server 
Connection accepted from Ok(127.0.0.1:40591)
Stream opened from Ok(127.0.0.1:40591)

クライアントを実行します

$ ./target/release/quic_echo_client 
aaaa←これは自分で入力した
aaaa←返ってきた出力

テスト用の証明書が用意されているので、すぐに使えたのが良かったです。 https://github.com/aws/s2n-quic/tree/main/quic/s2n-quic-core/certs

qlogの出力方法はgithubを眺めただけではわかりませんでした。そういうテストがありそうなのですが。。。

Client::builder() あるいは Server::Builder() 呼び出し時に、with_event を呼ぶとできる仕組みがありそうな気もします。

余談ですが、ちょっと前に読んでいたIt’s Over 9000: Analyzing Early QUIC Deployments with the Standardization on the Horizon という論文で、Amazon もQUICをデプロイしているという情報があったので、自前で作っている可能性は想像できたかもしれないです。。。

HTTPS RRのバイナリを読む

読むバイナリは、dig cloudflare.com type65 の結果返ってくるものの、RRの部分です。(参考)

; <<>> DiG 9.16.1-Ubuntu <<>> cloudflare.com type65
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47082
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;cloudflare.com.                        IN      TYPE65

;; ANSWER SECTION:
cloudflare.com.         107     IN      TYPE65  \# 79 000100000100180268330568332D32390568332D32380568332D3237 02683200040008681084E5681085E500060020260647000000000000 000000681084E5260647000000000000000000681085E5

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: 土  1月 15 15:52:40 JST 2022
;; MSG SIZE  rcvd: 134

読む際には、下記のバージョンのドラフトを参考にしています。

www.ietf.org

ちなみに、ある程度新しめのWiresharkだと普通に解釈してくれます。(3.6.1で確認。3.2.3にはありませんでした）

f:id:neko--suki:20220116113155p:plain
Wiresharkのキャプチャ

実装はおそらくこのあたり かと思います。

続きを読む

The Packet Number Space Debate in Multipath QUICのメモ

QUIC Protocol

「The Packet Number Space Debate in Multipath QUIC」というQUICマルチパスの拡張に関する論文です。

arxiv.org

Multipath QUICの現在のドラフトMultipath Extension for QUIC draft-lmbdhk-quic-multipath-00 上では、単一のパケット番号空間を選択するか、複数のパケット番号空間（＝パス毎にパケット番号空間）を採用するかが選べるようになっています。

この論文では、ネットワークシミュレータのNS3を使って、それぞれの手法が性能に与える影響を調べています。

論文では、パスごとに1つのパケット番号空間を使用することで、Multipath QUIC接続が受信者のACK戦略に対してより耐性を持つことを示唆しています。 逆に、一つのパケット番号空間を使用すると、受信側のACKの送信の仕方による性能の影響が大きいことを示しています。

続きを読む

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章の備忘録です。

続きを読む