quic標準化動向〜2017/7

QUIC標準化動向〜2017/7


Kazuho OkuFastly


• 大手CDN「Fastly」勤務• HTTP/2サーバ「H2O」開発者– TLS 1.3実装済 (known as picotls)– QUIC実装中 (known as quicly)

• HTTP関連のインターネットドラフト著者– 103 Early Hints– Cache Digest for HTTP/2

自己紹介


• QUICとは• 標準化動向• 標準化の論点• まとめ• TLS 1.3動向

目次


QUICとは


• TCP/IPとTLSとHTTP/2の一体化

QUICとは

HTTP/2

TLS

TCP

IP

QUIC

QUIC-HTTP

UDP

TLS暗号化

多重化

トランスポート


• 接続確立の高速化• ヘッドオブラインブロッキングの回避• ローミング• プライバシー保護と進化可能性

一体化の理由


• 従来: 2RTT– TCPハンドシェイク: 1RTT– TLSハンドシェイク: 1RTT

• QUIC: 1RTT– SYNとTLSハンドシェイクを一体化

接続確立の高速化


• HTTP/2では、先行するレスポンスのパケットが欠落すると、後続するレスポンスのパケットが届いていてもデコードできない– TCP(TLS)はデータを順に処理するモデルだから

• QUICでは、パケット単位でデコード可能– TLSを用いてハンドシェイク後、パケット単位の暗号鍵をTLSスタックからexport

– AEAD nonce=packet number

ヘッドオブラインブロッキング


• QUICでは、IPアドレス/ポートではなく64bitのConnection IDを用いて接続を判別することが可能– クライアントのアドレスがかわっても通信を継続

ローミング


• QUICでは、Connection IDとパケット番号以外の全てのデータを暗号化–通信の中継者に漏れる情報が少ない–ルータ等のバグにより、プロトコルの進化が阻害されない

• カーネルではなくユーザランドで実装可能• 接続確立時にプロトコルバージョンのネゴシエーション

プライバシー保護と進化可能性


• GQUIC– GoogleがChromeと自社サーバ間で利用しているプロトコル

–定期的にバージョンアップ• いずれはIQUICになる

• IQUIC– GQUICをもとにIETFで標準化中のプロトコル

２つのQUIC


• モバイル・新興国など回線状態の悪い環境におけるユーザ体験の改善

• 検索のレイテンシ:– 90パーセンタイル: 10.3%減少– 99パーセンタイル: 16.7%減少

• 動画再生時のリバッファ発生率– 90パーセンタイル: 70.4%減少– 99パーセンタイル: 18.5%減少

参考文献: The QUIC Transport Protocol: Design and Internet-Scale Deployment

GQUICの効果測定


• パケット構成:–ヘッダ:• Type, Connection ID, Packet Numberは平文• 残りはAEAD暗号化

– 平文部分はAEADの認証データ– フレーム群:• STREAM, ACK, MAX_DATA, …• HTTPのフレーム != QUICフレーム

– HTTPのフレーム（例: PRIORITY）はSTREAM内のデータ

IQUICのパケットフォーマット


Long Packet:0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+|1| Type (7) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ Connection ID (64) +| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Packet Number (32) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Version (32) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Frames (*) ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

STREAM Frame:0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+|1 1 F S S O O D|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Stream ID (8/16/24/32) ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Offset (0/16/32/64) ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| [Data Length (16)] | Stream Data (*) ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


ACK Frame:0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|1 0 1 N L L M M|[Num Blocks(8)]| NumTS (8) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Largest Acknowledged (8/16/32/64) ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| ACK Delay (16) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| ACK Block Section (*) ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Timestamp Section (*) ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ACK Block Section:0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| First ACK Block Length (8/16/32/64) ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| [Gap 1 (8)] | [ACK Block 1 Length (8/16/32/64)] ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| [Gap 2 (8)] | [ACK Block 2 Length (8/16/32/64)] ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| [Gap N (8)] | [ACK Block N Length (8/16/32/64)] ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


標準化動向


• 2016/11 ワーキンググループ設立• 2017/7 初回相互接続テスト• 2018/3 コアドキュメント群のラストコール完了• 2018/11 HTTPマッピングのラストコール完了

予定ロードマップ(2016/11)


• 2016/11 ワーキンググループ設立• 2017/7 初回相互接続テスト• 2018/3 コアドキュメント群のラストコール完了• 2018/11 HTTPマッピングのラストコール完了

実際


初回相互接続テスト

参照: https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit

• 当初はハンドシェイクのみにする予定だった• 次回はHTTP/0.9での相互接続が目標


• Rough Consensus and Running Code• 基本はMLとGitHub Issuesで議論• 年6回のミーティング–年3回のIETF–年3回のInterim Meeting–ハッカソンで相互接続を確認、問題の洗い出し

標準化の進め方


標準化の論点


• トランスポート– Server-chosen Connection ID– Stateless Reset– Closing Connections– Unidirectional Streams– On-path RTT measurement–…

• HTTPバインディング

標準化の論点


• GQUICの仕様: IDはクライアントが決定• やりたいこと: IDにPOP識別子を埋込みたい–理由: クライアントのアドレスがローミングすると、

AnycastベースのCDNでは異なるPOPにパケットが届き始める

–元のPOPがどこかをどうやって判別するのか• 結論: ハンドシェイク終了時にサーバで

Connection IDを発番

Server-chosen Connection ID


• QUICではRSTも暗号化される• 課題: エンドポイントがリセットされて暗号鍵が失われたら、接続をリセットできない???

• 結論:以下の手順でやる– 1. RSTを表すバイト列を接続確立時に発行• このバイト列はstatic keyとconnection IDから導出• 一見暗号化されたデータのように見える

– 2. サーバはリセット時に、このバイト列を送信– 3. クライアントはパケットの復号に失敗したら、このリセットでないか確認

Stateless Reset


• 接続レベルでの切断用パケットは不要?–注: ストリーム単位でのFINはある– タイムアウト時に切断パケットを流すのは電力とネットワークの無駄

• 結論:–切断用パケットはQUICでは標準化しない–必要なら各プロトコルバインディングで対応• 例: DNS over QUICなら切断用パケット不要• 例: HTTP over QUICなら、切断時に、サーバが最後に処理したリクエストのstream IDを送信

Closing Connections


• ストリームを片方向として定義したい–各バインディングで両方向のストリームを束ねれば、双方向ストリームを実現可能

• メリット:– QUICレイヤのステートマシン単純化

• デメリット:–バインディングの複雑化

• 結論: 提案の再検討– コアで双方向ストリームをサポートする点は合意

Unidirectional Streams


• QUICでは、ルータはACKに含まれるpacket numberを観測できない（暗号化されるから）

• 課題: ルータが接続のRTTを測定し、それに基づいた最適化を施せない

• 解決案:–パケットヘッダ内に、ルータが自由に書き換え可能な1bitを用意する

–エンドポイントはこの1bitをそのままエコー• 問題: プライバシーリスク

On-path RTT measurement


• ECN対応–ルータが輻輳をエンドポイントに通知–エンドポイントはピアにECN情報を通知※

– ※をQUICで行うべきか、どうやるか• Encrypting Metadata– packet numberも暗号化したい

その他のコアのissue


• 問題: ヘッダとボディを別々のストリームで送るか否か–注: ヘッダを送るストリームはリセットできない（圧縮情報として後続のリクエストから参照されるため）。ボディはリセット必須

• 結論:–圧縮情報はcontrol streamで送信–ヘッダとボディはリセット可能な単一ストリーム• ヘッダはcontrol streamの圧縮情報を参照

HTTPバインディング


• ヘッダ圧縮– HPACKは配送順に依存するので改良が必要–ふたつの提案: QPACK, QCRAM–両者の主要な差異:• header indexを絶対値で送るか、絶対値を復元可能な相対値で送るか

• トランスポートが受信したACKの情報を使ってヘッダ圧縮器のステートを更新するか、HTTPバインディングレベルでACKを送るか



• 優先度制御– HTTP/2では、Idle Streamを使って、複数のストリームをまとめて優先度制御していた

– QUICにはIdle Streamが存在しない• すべてのStreamでHTTPリクエストを流さないと色々面倒なことになるので…

–解決策: ストリームをまとめるグループ専用のID空間を用意しよう



まとめ


• 議論錯綜中–特にunidirectional streamはコアの設計に影響

• interopはちょい遅れくらいでがんばり

まとめ


TLS 1.3動向


• draft-21のWGLCなう• 一部のファイアウォールを通過できない問題– Facebookがcleartext handshake messageの

IDを変えることで、疎通率が改善したと報告• Googleが追試中

• Using Early Data in HTTP

TLS 1.3動向

quic標準化動向 〜2017/7

Technology

quic標準化動向〜2017/7