Network Quality Estimation in Chrome

docs.google.com

Twitterで見かけたChromeにあるNetwork Quality Estimator サービス（NQE)の紹介のスライドです。

ページのロードの最適化のために、ネットワークの状態を計測するサービスが含まれているそうです。

developerも、RTT estaimate, Download bandwidth estimate, EffectiveConnectionType の3つを使うことが可能らしいです。

以下はスライドを読んでいるときに書いた自分用のメモです

続きを読む

Evaluating COPA congestion control for improved video performance

engineering.fb.com

FacebookがLive Videoというアプリケーションで、新しい輻輳制御アルゴリズムのCOPAをCUBIC・BBRと比較したという記事です。

COPAを使うことで、goodputとアプリケーションのRTTの2つの観点で、CUBIC, BBRよりも良い結果を得られています。

COPAとBBRはアプリケーションの遅延を減らすだけではなく、より品質が良い動画を提供できるといえそうです。

続きを読む

MVFST-RL: An Asynchronous RL Framework for Congestion Control with Delayed Actions を読んでみました

論文 輻輳制御 ネットワーク

facebook AI researchが発表した強化学習の手法を輻輳制御に適用する論文を読んでみました。

非同期に行動の決定を実行することで帯域を有効に使えるようにした論文です。ただし、複数のネットワークを一緒に学習させると高いスループットが出せないという課題があります。

続きを読む

An Active-Passive Measurement Study of TCP Performance over LTE on High-speed Rails を読んでみました

ネットワーク 論文 輻輳制御

arxiv.org

https://arxiv.org/pdf/1812.04823.pdf

中国鉄路高速の上海北京間で、TCP over LTEの性能を計測した論文。300km/h以上の速度で運行しているときの、車内Wi-FiからLTEで通信する実ユーザーの計測データをもとに議論をしています。

主な内容は以下の4点です

  • BBRとCUBICの比較 -300km/hと350km/hの時で、物理層のレートが下がることで、CUBICは47.5%、BBRは40.1% goodputが下がることを示しています
  • TCPフローの主な特徴の調査
    • トラフィックに占めるアプリケーション（text, image, video...)の割合や、電車の乗客の特性による通信内容の違いなどについて説明しています
  • ハンドオーバーの影響の確認
    • ハンドオーバーの発生の仕方を3種類に分類し、ハンドオーバーによるスループットの影響について述べています
  • BBRをより詳細に調査し、改善の余地があることの確認
    • RTpropに修正を加えてBBRに改善の余地があることを示しています

LTEのハンドオーバーによる性能への影響が興味深かったので、少し取り上げます

続きを読む

IETF QUICの実装に使われている輻輳制御のアルゴリズムを調べてみました。(2019/12/6時点)

BBR、CUBIC、NewRenoの3つに絞って調べています。

各実装のレポジトリを、BBR、CUBIC、Reno、congestion、でキーワード検索して、出てきた情報から判断しています。詳細な実装を確認したわけではないので、実際には実装されていてもキーワード検索時に引っかからなかった場合は見落としている可能性がありますのでご注意ください。

もし間違っていたらご連絡いただけると助かります。

implementation language 実装されている輻輳制御アルゴリズム コメント
aioquic python ? コードとissueを検索してみましたが、何が実装されてるかまではわかりませんでした
AppleQUIC C, Objective-C ? closed sourceのため詳細不明
ats c++ NewReno このコミットログを見ると draft-19にあわせたと書いているので、NewRenoの可能性が高いと思います
f5 c ? closed sourceのため不明
kwik java NewReno ソースコードを検索したら、NewRenoCongestionController.java というのがありました
lsquic c BBR, CUBIC ソースコードを検索したら、BBRとCUBICの実装がありました
msquic c ? closed sourceのため不明
mvfst c++ BBR, CUBIC, NewReno, COPA BBR, CUBIC, NewNewRenoに加え、昨年論文が発表されたCOPAまで実装されていました。参考情報: COPAの論文 FaceBookの記事
Neqo Rust ? コードとissueを検索してみましたが、何が実装されてるかまではわかりませんでした
ngtcp c ? コードとissueを検索した限りでは、何が実装されてるかまではわかりませんでした
nginx_quic c ? quicheの拡張なので、quicheと同じだと思います
Pandora c ? closed sourceのためわかりませんでした
picoquic c CUBIC, NewReno ソースコードを検索したら、CUBICとNewRenoの実装がありました
quant c11 ? コードとissueを検索した限りでは、何が実装されてるかまではわかりませんでした
quiche Rust NewReno このissueによると 今はNewRenoしか実装していないようです
quicker TypeScript ? コードとissueを検索してみましたが、何が実装されてるかまではわかりませんでした
quicly c Reno コードを検索した限りでは、Renoが実装されているようでした
Quincy Java ? コードとissueを検索してみましたが、何が実装されてるかまではわかりませんでした
quinn Rust ? コードとissueを検索してみましたが、何が実装されてるかまではわかりませんでした
sora_quic Erlang/OTP ? closed sourceのためわかりませんでした
quic-go Go CUBIC コードを検索した限りでは、CUBICが実装されているようでした

単純なキーワード検索のみだと、不明なものが多かったです。個人的な予想ですが、そういう場合は、IDに従ってNewRenoを実装しているのではないかと思います。

もし、QUICのライブラリを実際に利用する場合は、ネットワークエミュレータなどで挙動を確認して、どの輻輳制御アルゴリズムを使っているか推定するのもありだと思います。

quic-goを使った開発をするときのtips

go のQUICライブラリのquic-goを使った開発したときのtipsの備忘録です。

github.com

  1. Keylogファイルの書きだし方
  2. デバッグログの出力方法

についてメモしておきます。

Keylogファイルの書きだし方

↓で説明があるように、wiresharkでQUICの復号を行うためには、該当通信のKEYLOGファイルが必要になります。

asnokaze.hatenablog.com

quic-goでKeylogファイルを書きだすためには、quic.DialAddr を呼び出すときに、tls.Config に、KeylogWriterを持たせることで実現できます。

TLS ConfigにKeylogWriterを持たせる例は、goのdocumentから確認することができます

golang.org

例えば、以下のように実装すると、

   w, err := os.Create("./keylog.log")
    tlsConf := &tls.Config{
        InsecureSkipVerify: true,
        NextProtos:         []string{"hogehoge"},
        KeyLogWriter:       w,
    }

    config := &quic.Config{
        KeepAlive: true,
    }

    session, err := quic.DialAddr(addr, tlsConf, config)

keylog.logというファイルが生成されます。

中身は↓のようなフォーマットになっています。

CLIENT_HANDSHAKE_TRAFFIC_SECRET ... ...
SERVER_HANDSHAKE_TRAFFIC_SECRET ... ...
CLIENT_TRAFFIC_SECRET_0 ... ...
SERVER_TRAFFIC_SECRET_0 ... ...

logの出し方

github.com

環境変数 QUIC_GO_LOG_LEVEL=loglevel を設定して、プログラムを実行するとログの出力ができます。

例えば、QUIC_GO_LOG_LEVEL=debug と設定すると、QUICパケットの送信時に、QUICパケットとその内部に含まれるフレームのログが見たり

18:13:25.216025 client -> Sending packet 0x5 (26 bytes) for connection 0x39abd2c4bae665f6062f, 1-RTT
18:13:25.216028 client  Short Header{DestConnectionID: 0x0d76cf58, PacketNumber: 0x5, PacketNumberLen: 2, KeyPhase: 0}
18:13:25.216031 client  -> &wire.StreamFrame{StreamID: 6, FinBit: true, Offset: 0x15, Data length: 0x0, Offset + Data length: 0x15}

受信したQUICパケットを見たるすることが出来ます。

18:13:25.241739 client  Short Header{DestConnectionID: (empty), PacketNumber: 0x5, PacketNumberLen: 2, KeyPhase: 0}
18:13:25.241742 client  <- &wire.AckFrame{LargestAcked: 0x5, LowestAcked: 0x2, DelayTime: 25.504ms}

これ以外にも、接続シーケンスや切断したときの情報などを確認することが出来ます。

コードを動かして規格の中身を確認したいときに便利かもしれないです。

「LiteSpeed Beats Nginx in HTTP/3 Benchmarks」の紹介

blog.litespeedtech.com

OpenLiteSpeedとnginx の実装を比較している記事

163バイトのindex file、そこからリンクを張られている1MB、10MB、1GB のファイルのダウンロードを比較している。

index fileに対しては、同時に複数アクセスして毎秒どれくらいのリクエストをさばけるのかを確認しています。

1MB、10MB、1GBのファイルに対しては、ダウンロード時間を比較しています。

すべての結果でOpenLiteSpeedのほうが良い結果が出ていました。nginxはCPU使用率やメモリ使用量が多いらしいです。

主張したいのは

nginx’s HTTP/3 is not ready for production use. It delivers poor performance and, at the same time, uses too much CPU and memory.

のようです。

以下のツイッターのスレッドで議論が続いているようです。