━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1946【臨時号】2022.9.7 ◆
  _/ＮＩＣ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1946 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2022年7月下旬に米国・フィラデルフィアおよびオンラインで開催された第114
回IETFミーティングの報告を、vol.1944より連載にてお届けしています。第
2弾となる本号では、QUICおよびHTTPに関する話題をご紹介します。

なお、本号の内容は、JPNICブログでもご覧いただけます。発表資料などへも
アクセスしやすくなっておりますので、ぜひブログでもご覧ください。

  JPNICブログ：第114回IETF 参加報告 [第2弾] 
               ～QUIC (MOQ)、HTTPに関する動向～
  https://blog.nic.ad.jp/2022/7948

また、vol.1944でお届けした第114回IETFの概要に関するレポートについて
は、下記のURLからバックナンバーをご覧ください。

  □第114回IETF 参加報告
    ○[第1弾] ～IAB、ANRW、Hot RFC、その他～ (vol.1944)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2022/vol1944.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第114回IETF 参加報告 [第2弾] ～QUIC (MOQ)、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(*1)として発行しました。さら
に、QUICと合わせて標準化が進められていた待望のHTTP/3も、RFC 9114(*2)
として発行が完了しています。HTTP/3については、その後の拡張やメンテナ
ンスはHTTP WGで行われることとなっています。引き続きQUIC WGとしては、
QUICプロトコルのメンテナンスと拡張について議論を続けています。

(*1) https://datatracker.ietf.org/doc/html/rfc9000
(*2) https://datatracker.ietf.org/doc/html/rfc9114

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

(*3) https://datatracker.ietf.org/doc/html/rfc9221
(*4) https://datatracker.ietf.org/doc/html/rfc9287

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

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

(*5) https://www.ietf.org/archive/id/draft-ietf-quic-multipath-02.html
(*6) https://www.ietf.org/archive/id/draft-jholland-quic-multicast-02.html


■ Media over QUIC

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

(*7) https://www.ietf.org/archive/id/draft-lcurley-warp-01.html
(*8) https://www.ietf.org/archive/id/draft-kpugin-rush-01.html

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

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

(*9) https://datatracker.ietf.org/doc/charter-ietf-moq/


■ HTTP WG

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

(*10) https://www.rfc-editor.org/rfc/rfc9110.html

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

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

(*11) https://www.ietf.org/archive/id/draft-tus-httpbis-resumable-uploads-protocol-02.html

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


■ おわりに

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


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
      わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
                  ◇              ◇              ◇
            メールマガジン以外でも、情報を発信しています！
             JPNICブログ  https://blog.nic.ad.jp/
                 Twitter  https://twitter.com/JPNIC_info

          YouTubeでは初心者向けセミナー資料を公開しています
       https://www.youtube.com/channel/UC7BboGLuldn77sxQmI5VoPw
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃ https://feedback.nic.ad.jp/1946/bed34a728b412b0fe7fe3589542a0591 ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃ https://feedback.nic.ad.jp/1946/9325a06d83f25b6d115a2f68a146696a ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  ::::: https://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ━━ JPNICへのご連絡/お問い合わせは極力電子メールでお願いします ━━
┏━◇【COVID-19に対応したJPNICの業務について】 ◇━━━━━━━━━┓
        https://www.nic.ad.jp/ja/profile/covid-19.html
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
 ■ 各種お問い合わせ先：https://www.nic.ad.jp/ja/profile/info.html ■
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 JPNIC News & Views vol.1946 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田2-12-6 内神田OSビル4階
 ＠ 問い合わせ先 jpnic-news@nic.ad.jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
   ◇ JPNIC Webにも掲載していますので、情報共有にご活用ください ◇
登録・削除・変更   https://www.nic.ad.jp/ja/mailmagazine/
バックナンバー     https://www.nic.ad.jp/ja/mailmagazine/backnumber/
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■     News & ViewsはRSS経由でも配信しています！    ■■■■■
::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  https://www.nic.ad.jp/
■■

Copyright(C), 2022 Japan Network Information Center