Towards Securing the Internet of Things with QUICを読みました

Towards Securing the Internet of Things with QUIC を読んでみました。

https://www.easychair.org/publications/preprint/68D2

preprintバージョンのため今後更新される可能性はありそうです。

Linuxが載らないような(RAM256KB、フラッシュメモリ1MB)デバイスで、quanのコードサイズ、スタックとヒープの使用量、1-RTTと0-RTT接続を使った場合のバッテリー消費量などを比較しています。

もう少し詳細に紹介します。

続きを読む

Resource Multiplexing and Prioritization in HTTP/2 over TCP versus HTTP/3 over QUIC

rmax先生の論文。

https://h3.edm.uhasselt.be/files/ResourceMultiplexing_H2andH3_Marx2020.pdf

以前qiitaで紹介した 「Of the Utmost Importance: Resource Prioritization in HTTP/3 over QUIC」を読みました - Qiita に内容を追加したものらしい。

ちゃんと読んでないけど、streamのmultiplexingの実装を調査したのがすごいわかりやすかった

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

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