第114回IETF 参加報告 [第2弾] ～QUIC (MOQ)、HTTPに関する動向～

先日公開した「第114回IETF 参加報告 [第1弾] ～IAB、ANRW、Hot RFC、その他～」に続いて、第2弾としてQUIC・HTTP関連の標準化トピックをご紹介します。今回のレポートは、後藤ひろゆき氏（グリー株式会社 開発本部 / インフラストラクチャ部）にご執筆いただきました。

2022年7月23日(土)から29日(金)にかけて、第114回IETF (IETF 114)がフィラデルフィアで開催されました。今年2022年3月に行われたIETF 113に続いて、現地参加も可能なミーティングになりました。登録上は、現地参加者が622名、リモート参加者が805名となっています。私はオンライン参加でしたが、現地での参加者はマスクの着用を徹底するなど感染防止を行いながらも、ハッカソンなども行われていたようです。ハイブリッド会議の運行も前回の開催から、よりこなれてきたと体感できました。

各ワーキンググループ(WG)の会議については、変わらずプロトコルの議論が行われています。既存のプロトコルのメンテナンスについて議論するもの、新しいプロトコルを議論するもの、それぞれ議論のフェーズは異なっていますが、今回は私の参加したWGの様子を紹介していきます。

QUIC WG

QUIC WGでは、去年QUIC Version 1をRFC 9000として発行しました。さらに、QUICと合わせて標準化が進められていた待望のHTTP/3も、RFC9114として発行が完了しています。HTTP/3については、その後の拡張やメンテナンスはHTTP WGで行われることとなっています。引き続きQUIC WGとしては、QUICプロトコルのメンテナンスと拡張について議論を続けています。

QUIC Version 1の標準化後に行われた、いくつかの取り組みを紹介します。まずは、「RFC 9221 An Unreliable Datagram Extension to QUIC」、「RFC 9287 Greasing the QUIC Bit」を取り上げたいと思います。RFC 9221は、QUICで信頼性のないアプリケーションデータの送信を可能にします。もともとQUICでは、パケットロスして失われたアプリケーションデータは再送されますが、それが不要なユースケースでこの拡張仕様は有用です。RFC9287では、QUICにはQUIC Bitと呼ばれるQUICの通信だと識別するのに使えるbitがありますが、それを分かりづらくする方法を定義します。これにより、ミドルウェアの不適切な実装により新しいプロトコルの通信が阻害される、”硬直化”のリスクを減らします。

RFC目前になっている仕様としては、QUICv2などもあります。これは機能的にはQUICv1と同じですが、鍵導出に用いるパラメータなどが異なっています。実装が適切にパラメータを変えたり、バージョンのネゴシエーションを行うために、QUICv2というプロトコルが用意されました。これにより、将来の新しいQUICバージョンを標準化する際のリスクを低減しています。

IETF 114では続き物の議論もありますが、「Multipath QUIC」や「Multicast QUIC」といった、新しいQUIC拡張の議論が行われています。「Multipath QUIC」は、Multipath TCPのように複数のパス(エンドポイントにとっては複数のネットワークインタフェース)を使って、コネクションを確立する仕組みを定義します。モバイル端末では、Wi-Fiとキャリアネットワーク両方を使う例や、サーバ間の通信でも複数回線を使うユースケースがあります。現在は、QUICにおいてパスごとの再送制御を行うために、パケット番号の付与方式を議論しています。また、「Multicast QUIC」は、マルチキャストでデータを送信できるようにする提案仕様です。まだWGドキュメントにはなっていませんが、著者らによってここ数年議論されてきたテーマになります。まだまだ議論が始まったばかりですが、興味を持っているメンバーで議論が続けられるでしょう。

Media over QUIC

Media over QUICは、QUIC上でメディアデータ、特にライブ映像などを送信するプロトコルの、標準化について議論しています。ここ数年、IETFでは非公式なミーティングの形で議論されており、十分な興味を引いていました。また、具体的な事例も紹介されており、ライブ動画配信プラットフォームのTwitch社が開発した「Warp」、FacebookなどのSNSでライブ映像を扱うMeta社が開発した「RUSH」が、すでにIETFで紹介されています。

IETF 114ではMedia over QUIC (moq)のWG設立に向けて、活動の目標やスコープを表したチャーターについての議論がメインでした。細かい議論はありつつも、このチャーターに沿って活動が行われていきます。おもな方向性として、QUIC(もしくはWebTransport)上で複数のメディア形式に対応できるようなプロトコルの標準化を行います。またシチュエーションとして、配信者からのアップロードと、ネットワークから視聴者への配信のユースケースを考慮してプロトコルが検討されそうです。

今後議論が続けば、WGの設立とともに具体的なプロトコルの設計が始まることと思います。

HTTP WG

HTTP WGは、引き続きHTTPのメンテナンスおよび拡張を行っています。特に最近は、HTTP/3の標準化に合わせてHTTP全般のメンテナンスが行われてきました。HTTP/3は、HTTPメッセージのやり取りを効率化するプロトコルでしたが、HTTPメッセージの意味は変わりません。今までHTTPメッセージの意味は、HTTP/1.1の仕様の一部として標準化されていましたが、独立したHTTPセマンティクス仕様として、別途切り出し整理されました。それが、RFC 9110 HTTP Semanticsです。また、HTTPセマンティクスの整理に合わせて、HTTP/1.1やHTTP/2のエラッタ修正も含め、RFCが合わせて改訂されています。

IETFの本会合がリモート中心となり、HTTP WGはこの2年間は個別開催の中間会議のみを行っていました。IETF 114ではハイブリッド開催となり、現地での参加者も見込まれることから、本会合でのミーティングが久々に開催されました。とはいえ、今まで通り粛々と取り組みが進められているという印象で、特に変わったことはありませんでした。

IETF 114で議論されたトピックのうち紹介するのは、「alt-svc」と「Resumable Uploads」です。「alt-svc」は、すでに標準化されている仕組みですが、利用用途の拡大に伴い議論が盛り上がっています。alt-svcの用途例としては、クライアントに対してサーバのHTTP/3対応をHTTPレスポンスヘッダで通知するのに使われています。クライアントはこのヘッダを見て、HTTP/3でサーバに繋ぎにいきます。このalt-svcの仕組みは現状上手くいっていますが、複数のCDNを使う場合や、新しくHTTPS DNSレコードでシグナリングを行う場合など、ユースケースや利用手段が拡大しています。現状に合わせて整理しようという動きがあります。

二つめ目「Resumable Uploads」は、HTTPを使って再開可能なアップロードを実現するという議論です。現状、通常のHTTPでは、ネットワークなどの事情で中断したアップロードを、途中から再開する手段はありません(ただし、ファイルを分割してアップロードすることで実現している例もあります)。その仕組みを標準化したいというのが、今回上がった話です。具体的な方法についてはまだ議論の余地がありそうですが、需要としては一定の理解が得られ、標準化に向けて議論が続きそうです。

おわりに

今回の会合は、ハイブリッド開催となりました。次回のIETF 115もハイブリッド形式で、2022年11月にロンドンでの開催が予定されています。傾向としては、国外からの現地参加者も増えているようです。標準化がより活発になり、またワクワクするような新しい取り組みが始まることを、楽しみにしています。それでは、また次の機会にお会いしましょう。