QUICの現状確認をしたい 2018/3 (QPACK, Spin Bit, Invariants)

QUICの現状確認をしたい。
(あまり追えてないのでつらい)

前回
asnokaze.hatenablog.com

次回
asnokaze.hatenablog.com


目次

仕様の状況

3月頭に4つのコアドキュメントのdraft-10が出ている。

あまり差分は大きくないが、トランスポートでは前回分で書いたコネクションマイグレーション時に使うPATH_CHALLENGE、PATH_RESPONSEフレームが追加されたほか、ACK周りの再送するフレームに関する情報が追記された。

TLS利用の仕様では、QHKDF-Expandに関する記述が増えている。

おそらく、もうそろそろ draft-11 が出ると思われる。

また、その他の仕様では、QUICのHTTPヘッダ圧縮方式については長らく議論されていたが、QCRAMと呼ばれていた仕様がWG Draftとなっている。なお、非常に紛らわしいところであるが、QCRAMはQPACKに改名された。

QPACKについては以前書いたが、少なからずの変更が入っている。
asnokaze.hatenablog.com

また、将来のQUICバージョンアップデートをデプロイしやすくするための、invariantsと呼ばれる仕様もdraft-01が出ている。WG Last Callとなっている。

asnokaze.hatenablog.com

マイルストーンの変更

WGのマイルストーンに、Header Compression for HTTP over QUICが追加されたほか。

以前、チェアから意見が出たとおり、マルチパス QUICに関するマイルストーンは削除されました。

QUIC V1では、マルチパスQUICは対応されません。
QUIC V1では、マルチパスQUICは対応されません。

IETF101

3/17 ~ 3/23 にかけて、IETF 101がロンドンで開催された。
QUICに関しては、QUIC WGのセッションが2つ開催されたほか、ハッカソンで実装を持ち寄っての相互接続テストも実施された。

下記の発表が行われました

  • Hackathon Update
  • EDITORS UPDATE
  • QUIC DTLS and Stream 0
  • Invariants
  • ECN
  • Spin Bit Proposal

議事録及び発表資料はGithubで公開されている
wg-materials/ietf101 at master · quicwg/wg-materials · GitHub

相互接続性テスト

4th Implementation Draftで、相互接続テストが実施された。これは、 draft-09 と TLS1.3 draft-23の実装です。

f:id:ASnoKaze:20180331005345p:plain

  • V: Version Negotiation
  • H: Handshake
  • D: Stream Data
  • C: Connection Close
  • R: Resumption
  • Z: 0-RTT
  • S: Stateless Retry

次回のinteropは、5月にリモートでの開催が予定されている。
5th Implementation Draftとして、draft-11 と TLS1.3 draft-28で相互接続テストが実施される。

Spin Bit

発表資料: wg-materials/spin-101.pdf at master · quicwg/wg-materials · GitHub

以前書いたSpin BitをQUICとして正式に採用するかという議論が白熱しました。
asnokaze.hatenablog.com

会場参加の実装者の賛同はあまり得られておりませんでしたが、下記の通り hum を取ることになりました。

  • (a) QUIC V1にSpin Bitを入れない
  • (b) 予約bitを確保し、拡張仕様として別ドキュメントで定義する
  • (c) まだわからない

結果としては、(b)となったようです。
後日MLでチェアのmnot氏が下記のようにまとめています。
Spin Bit -- a Path Forward

QUIC DTLS and Stream 0

発表資料:wg-materials/Stream0-EKR.pdf at master · quicwg/wg-materials · GitHub

以前書いた通り、EKR氏よりQUIC over DTLSの提案がありました。
asnokaze.hatenablog.com

この話を発端に、QUICのレイヤリングとストリーム0に関しては専門のチームが結成され、検討が進められるようです。

下記のメール参照
Stream 0 Design Team

A First Look at QUIC in the Wild

発表資料:https://datatracker.ietf.org/meeting/101/materials/slides-101-maprg-a-first-look-at-quic-in-the-wild-00

maprg では、QUICのインターネットでの利用状況に関する発表がありました。ヨーロッパのTier-1 ISPでの、QUIC, HTTPSトラフィック量比較などの調査結果が報告されています

InvariantsのWGLC

Version-Independent Properties of QUICがWG Last Callとなっている。

チェアの「Working Group Last Call: QUIC Invariants」に詳しく書いてあるが、これは QUICの不変部分がより高いレベルで変更されないと信頼できるようにするためである。WGLC後すぐに先のステップに進むのではなく、そのタイミングで停滞させるようである。

なお、強い理由があればInvariantsの仕様を変更する事ももちろんある。

このような戦略的なWGLCは面白いなと思いました。

Symmetric connection IDs

Draft-11で入る、大きな変更点があります。
github.com

Coneection-IDが、Source Connection IDとDestination Connection IDに変更され、さらに可変長となりました。これによって、クライアントのパケット処理がよりシンプルになるようです。

この変更によって、Long Headerは下記の通りになります
f:id:ASnoKaze:20180331013127p:plain

Short Headerは下記の通りになります。Short HeaderはDestination Connection IDだけになります。Lengthが無いのは、その長さがお互いにわかっているため、Lengthはありません。
f:id:ASnoKaze:20180331013233p:plain

あまり自分もちゃんと理解できないので、詳しい人がいれば補足してほしい...