はてなブックマーク

最近のLinuxではeBPFで輻輳制御アルゴリズムを実装し、カーネル内で実行できる。今日はDCTCP実装を眺めてみたいと思う。その前にオリジナルのDCTCPについて確認する。マージされたのはバージョン3.17の頃。 commit e3118e8359bb7c59555aca60c725106e6d78c5ce Author: Daniel Borkmann <daniel@iogearbox.net> Date: Fri Sep 26 22:37:36 2014 +0200 net: tcp: add DCTCP congestion control algorithmDCTCPはRFCにもなっているけど、オリジナルは2010年にMSRとスタンフォード大のチームによって提案された（Data Center TCP (DCTCP) [SIGCOMM2010]）。一般的な輻輳制御アルゴリズムでは

LinuxのTCP/IPスタックと*BSDのTCP/IPスタックどっちが優れているのかというのはよく出てくる質問で、探せばベンチマーク結果もいろいろ出てくるが、当然TCP/IPスタック以外のカーネル構造の違いも大きいので、apple-to-appleの比較は難しい。 ユーザベースではLinuxが圧倒的なのだろうけど、NetflixのCDNではFreeBSDが使われているのは有名（「Netflix and FreeBSD: Using Open Source to Deliver Streaming Video 」[FOSDEM2019]）。また、「サービス可用性を改善するための異種OS間プロセスマイグレーションの活用」によると、一般的にLinuxは常に高スループットであるが、高負荷時にはエラーが頻発する。一方、FreeBSDは高負荷時でもエラーを起こさない。粘りがあるというか、ダイソンの掃

eBPFでcommit logを調べてみるといろいろと面白そうなものが出てくるな。例えば、TCP-BPF [netdev 2.2]。TCPコネクションのパラメータをBPFで操作できる。さらに最近（バージョン5.5以降）では、輻輳制御もeBPFで実装できるようになっているようだ。eBPFによりカーネルからどんどん機能を追い出してLinuxはマイクロカーネル化するのだという鼻息荒い発表も見かけるが（「eBPF - Rethinking the Linux Kernel」[QCon2020]）、正直これが正しい方向性なのかよくわからない。面白いけど。 eBPFを使っているわけではないが、輻輳制御をユーザレベルで実装するという研究はいくつかある（「Restructuring Endpoint Congestion Control」 [SIGCOMM2018]、「Deploying Safe Use