Kaigi on Rails 2023に参加していただいたみなさま、ありがとうございました。初のオフライン、オンラインのハイブリッド開催となりましたが、登壇者の皆様、Proposalを出してくださった皆様、協賛してくださった企業の皆様、そして一般参加者の皆様のご協力のおかげで無事に今年のKaigi on Rails 2023を終えることができました。
もともと会場でのサイネージの役割としてのなにかを用意したいよね、という構想はあったので運営内でのみ使うWeb appを作るつもりではいたのですが、大倉さんがドーンと rails new をしたリポジトリが爆誕したのでそこに乗っかることにしました。お披露目クオリティに達したのが本当にギリギリだった1こともあり、イベント開催までの周知が全くできておらず当日にアクセスが集中して軽い障害が発生したのは本当に申し訳ないと思っています。でもこれで来年はもっと多くの人が使ってくれそうで嬉しいです。いくつか追加機能のアイデアも頂いています。
職選びの観点で言うなら、たぶん自分はPythonやGoやJavaScriptの案件でもなんとか生活できるくらいのお金はいただけると思っています。それでもRubyの会社を選び続けるのは、Rubyでサービスを開発・運用し、コミュニティに投資している会社であれば、自分がRubyKaigiやKaigi on Railsのために使う時間のことを考慮してくれる(そのことで急に休みを入れることに理解がある)、そういうことへの理解があるからです。その点で、フルタイムRubyコミッタを抱えていたクックパッドは本当にいい会社でした。
また、懇親会でのLT大会において、直前に開催されたIETF 117 San Franciscoで自分が聞いていたセッションで触れられていたdraftについて一言で説明していくという発表もさせていただきました。これについては発表資料はありませんが、IETF 117 San Franciscoの参加記でより詳細に記事にしています。
そもそもTCPと比較した際のQUICの優位点として、複数のstreamを使用することによるHead-of-line blocking(HOLB)の回避が挙げられます。WebTransport over HTTP/2ではこのstreamの独立をサポートしていません。また、続く “Partial Reliability” では、"HTTP/2 retransmits any lost data.“ とあるように、欠損したデータは全て再送されます(バッファリングできない分はdropすることが許可されます)。
Stream Independence:
WebTransport over HTTP/2 does not support stream independence, as HTTP/2 inherently has head-of-line blocking.
Partial Reliability:
WebTransport over HTTP/2 does not support partial reliability, as HTTP/2 retransmits any lost data. This means that any datagrams sent via WebTransport over HTTP/2 will be retransmitted regardless of the preference of the application. The receiver is permitted to drop them, however, if it is unable to buffer them.
https://www.ietf.org/archive/id/draft-ietf-webtrans-http2-06.html#name-transport-properties
では真にlow-latency性を求める通信はどのように行うべきかというと、今まで通りに素のUDPやWebRTCを使ったり、RTP over QUIC (RoQ)2の登場を待つ、ということになるのかなあ……ちょっとわかりません。ただ言えることとしては、RFC 9002 QUIC Loss Detection and Congestion Controlにおいて、QUICがその欠損制御を無効化するような仕組みは定義されていないということです。
moqはQUICを用いたメディア転送に関するプロトコル、Media over QUICを策定するためのworking groupです。今議論されているのはMedia over QUICそのものの仕様をどうするか、という点ですね。まだmoq wgからRFCは出ていません。116もそうでしたが、moqはセッションが2回ありました。なぜなんでしょうか。
私はうなすけといい、Kaigi on Railsのオーガナイザー、つまり運営チームの一員です。Kaigi on Railsにおいては、運営に関わる全員がProposalを評価し、その結果から採択・非採択を決定します。なので僕は皆さんから送られてくるProposalを読み、評価をするメンバーのうちのひとりです。
この記事の目的は何か
昨年のKaigi on Rails 2022において、皆さんから多くのProposalを提出していただき、大変ありがたく思っております。2023年も引き続きKaigi on Railsを開催できること、皆さんからの Proposalを受け取れることを喜ばしく思います。
As I wrote in last year’s participation (JA), I applied for the Ruby Association Grant 2022. As a result, it was accepted and I was able to complete the port of aioquic to some extent.
I think this presentation was a little early final report. I am a little concerned about whether or not I will apply for the Grant again this year, but I will think about it again when the time comes. This is because, after all, time constraints are unmanageable. It is true that it makes a deadline, and I can certainly make progress with the help of my mentor, but I have no choice but to devote my personal time to writing the code. I felt that if I cannot generate the time to do this as a job, I will not be able to continue. However, I wondered if any company would invest in the QUIC implementation of Pure Ruby, which is not suitable for production use. I have not been able to approach companies because I am worried about this, or rather, I have not been able to come up with an answer to this question.
As a member of #RubyKaigiNOC
“unasuke dropped”
I have been helping with the RubyKaigi network for the past few years. This year again, as a member of #RubyKaigiNOC, I mainly helped with L1.
Sorah, who is the organizer of the RubyKaigi and NOC boss, is a very busy person. Therefore, this year I decided to take some of her tasks away from her. But as a result, other NOC members including her, helped me. However, thanks to that, I was able to gain knowledge about fluentd. I had never written a fluentd configuration before. The book “fluentd実践入門” written by tagomoris was very helpful in doing this task, and I got him to sign the book for me on #authorsrb.
I’m very pleased to provide the Internet to all RubyKaigi attendees. I hope to provide the same experience in Kaigi on Rails which is the conference about Ruby on Rails in Japan as one of an organizer of that either. But it’s a very hard thing in this year I thought.
As a DJ of RubyMusicMixin2023
Continuing from last year, I had the opportunity to DJ at a RubyMusicMixin2023 organized by pixiv. After a great Kaigi, it is a great time to dance to the music also.
1. Write Codes, 2. Receiving and sending in English (as a lingua franca), 3. Show Your Presence at International Conferences – by kakutani
The most difficult part of this year’s RubyKaigi was speaking in English. I think I did a little bit about “1. Write Codes” in “Developing the Ruby Ecosystem,” as Kakutani-san mentioned. On the other hand, I did nothing about 2 and 3.
However, DeepL and ChatGPT have recently allowed us to empower English language skills. I may still be powerless in face-to-face conversations, but in one-way speaking situations where I have to prepare a script in advance or writing, they help me a lot. (Also, I wrote this blog in English and Japanese too!) In fact, for my presentation, I first wrote a script in Japanese, had it translated into English by DeepL, and then adjusted the English text to suit my English skill. (I spoke a little Japanese. I apologize.)
About the future
As I mentioned in my talk, I’m trying to create my own QUIC implementation based on my porting knowledge. In doing so, I’m reading RFC 8446 and draft-ietf-tls-rfc8446bis, although this is a bit of a detour. Because, during the porting process, I was trying to rewrite the existing Python implementation in Ruby in its original form, and not much thought was given to the TLS 1.3 specification itself.
そして、お金を払って参加するのであれば、何か目標を自分に課すといいかもしれません。議論の様子や発表される資料は全て公開されています。それでも現地に参加するのは、実際に「インターネット」に関わっている人達に会えるからです。実際僕も、今回のIETF Meetingで「QUIC working groupのchairに話してQUIC開発者が集まっているSlackに招待してもらう」ことを目標として参加し、達成しました1。現地参加するのであれば、現地参加だから意味のある目標をひとつ決めて参加するのがいいと思います。
次に、暗号化に関連しますが、OpenSSL binding API の問題です。PythonもRubyも、暗号化や、鍵交換に関わる処理はOpenSSLを利用しています。Python、aioquicだとpyca/cryptographyが、Rubyだとopenssl gemがOpenSSLのAPIを利用するのに使われますが、この2つのライブラリ間で、OpenSSL APIの抽象化度合いが異なります。なのでOpenSSL APIを使う部分の移植については、まずPython側の実装が最終的に何のOpenSSL C APIを呼んでいるかを突き止め、それがopenssl gemではどんなAPIになっているかを調べる、という手順が必要でした。
QUICについては、IETFのQUIC working group(以降WGなどと略します)で議論されており、現在activeなDraftは8つあります。またQUICのWG以外でもQUICが関連しているRFCやDraftがあります。例えば最近はQUIC上で映像や音声の転送を行うための仕様について議論するMedia Over QUIC WGが盛り上がっている2ようです。
Media Over QUICのほうに目を向けてみると、mailing listの投稿がとても活発で追いかけるのが大変なのですが、下記のyukiさんのまとめによれば、Warpをbase draftとして議論が進んでいるようです。まとめではdraftの番号が02となっていますが、今年3/13に04が出ています。
