QUIC標準化現状確認メモ

Googleの考案したQUICは現在IETFで標準化が進められており、多くの人々によって議論されております。QUICの中身よりも現在の状況について、自分用に整理する。

Issueが追えてないので残念感ある。

概要

UDP上で信頼性のある暗号化されたHTTP/2通信を行うQUICは、もともとはGoogleが考案・実装・実証をすすめられていた。

IETFの会合で数度のBoF(WG設立前の議論)の開催へて、2016年にQUIC WGが出来QUICの標準化を進めることが決定した。

QUIC WGのゴールはCharterにかかれている通り、大まかに以下のとおりである

  • アプリケーションのために、コネクション及びトランスポートの遅延を最小化すること
  • head-of-lineブロッキングの無い多重化を提供すること
  • エンドポイントの変更のみでデプロイ可能とすること
  • マルチパスとFEC(forward error correction)を拡張機能として有効にする
  • TLS1.3を使用した常時暗号を提供すること

また、マイルストーンとしては主要な4つの仕様は 2018年ごろにほぼほぼ標準としては固まった状態となり、IESGに提出される予定になっている

  • Mar 2018 Core Protocol document to IESG
  • Mar 2018 Loss detection and Congestion Control document to IESG
  • Mar 2018 TLS 1.3 Mapping document to IESG
  • Nov 2018 HTTP/2 mapping document to IESG
  • Nov 2018 QUIC Applicability and Manageability Statement to IESG
  • May 2019 Multipath extension document to IESG

7月に行われるIETF99において、以下にあげる仕様(draft04)で相互接続通信ハッカソンが行われる予定になっている。しかし、フル実装ではなく1RTTハンドシェイクにフォーカスしたものである (First Implementation Draft · quicwg/base-drafts Wiki · GitHub)

仕様・ドキュメント

主要仕様

現在の仕様、主要な4つに関してはWGドラフトとなりすでに改版が進んでいる。直近で6/13にdraft-04となっている

Ops

Opsに関して、すでにAdopetされている個人ドラフト

個人ドラフト

その他個人ドラフト

ドキュメント

その他仕様ではないが、参照されるもの

Google QUIC

その他Google QUIC側の資料は「Chromiumのプロジェクトページ」から辿れる。すべての資料ではないが、YoutubeにおいてFECを有効にした際の評価についての資料などもある。

議論/発表資料

直近の議論と、発表資料についてまとめる

IETF QUIC Working Group Interim Meeting

6/6~8にかけて行われた、IETFの本会合との間に設けられているQUIC WGの中間会議

議事録」の通りとなるが、Implementation Draftの議論、幾つかのIssueについての熱い議論及び、下記の発表があった

過去のIETF/Interimの議事録・発表資料はGithubで公開されている
https://github.com/quicwg/wg-materials

The HTTP Workshop

6/12~13にかけて行われた、標準化の場ではないが、仕様の著者、ブラウザベンダ、ミドルウェア実装者、CDNや大手サービスがHTTPについて議論するWorkshopであり、QUICに関する発表もあった。

Next IETF

次のIETFは7/16~21であり、もちろんQUIC WGのセッションもある。スケジュールはすでに公開されており、QUICのセッションは20, 21である。

余談だが、リモートでの参加は誰でも無料で出来る、深夜帯ではあるが興味ある方は下記記事を参照頂ければと思う
qiita.com