IETF 105
全体概要 + α
後藤浩之 (グリー)自己紹介- 後藤 浩之 (グリー)- インフラ担当- ISOC-JP インターネット標準化推進委員会- 興味：Web, HTTP・QUIC関連

目次- 全体概要報告- 自分が参加した部分の動向

全体概要

開催概要

- 期間: 7/20(土) ~ 7/26(金)- 場所: カナダ モントリオール-(IETF102と同じ会場)- ホスト: Comcast, NBCUniversal

参加者

カレンダーハッカソン
もう恒例となったハッカソン-

土曜, 日曜 で開催
280人, 42プロジェクト
月曜に Hackdemo happy hour

https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon

引用: https://datatracker.ietf.org/meeting/105/materials/slides-105-ietf-sessa-all-slides-ietf-105-administrativeoperations-plenary-01

ANRW
ACM / IRTF Applied Networking Research Workshop（ANRW）-

Measurement and Optimisation
QUIC
DNS and Security
Network Functions and Middleboxes

Request for Conversation (HotRFC)
こちらも恒例-日曜 18:00 から議論したいことをLT形式で発表していく。Side Meeting情報も今回は23発表

SHOULDやMUSTに加え「Should we add "RESERVED"」を定義しようといった発表もあり盛り上がっていた。

Unofficial Side Meetings
WGやBoF以外のミーティング。
-

Week dayの 8:00 ~ 9:45 に確保されている--

トータル40サイドミーティング
同じ時間帯に 2~6つ入ったりする（それ以外の空き時間で実施されることもある）

通常のWG Meetingの部屋で実施
Meeting次第だが、minutesが共有される
カレンダーでスケジュールを確認する-

https://www.ietf.org/how/meetings/105/side-meetings/

Tech Plenary
プライバシーに関する2名の発表があった
プリンストン大学のArvind Narayanan准教授- プライバシー測定とその影響に関する発表- ブラウザのフィンガープリンティングを利用し、ユーザをトラッキング可能化測定する
サイト (https://panopticlick.eff.org/)
コロンビア大学のSteven Bellovin教授- Notice and Consent (新しい問題ではなく、ずっと議論されている)- 最近の動向 (Machine Learning = 性別,嗜好が推測される)- The IETF’s Role

BoF
-Applications Doing DNS (ADD)
Local Optimizations on Path Segments (LOOPS)Media Operations (MOPS)
Lightweight Authenticated Key Exchange (LAKE)IETF Meeting Network Requirements (netrqmts)

get together
日本勢で会食をする企画-

30人ほど参加
1リットルビールが出てくる

初参加の人ほど参加して交友を広げてほしい=> Slack あります

Next Meeting
IETF 106 Singapore- 期間: 11/16 ~ 11/22-「IETF 106 Registration, Reservations,and Social Event Now Open!」- Early Bird cut-off: 09/30- ホスト:Nokia

Any Comments?
Any Questions?

QUIC関連QUICとは
QUICとは、Google社が考案したプロトコル
UDP上で動作し、TCPのような信頼性と、TLSのように暗号化された通信を提供する。上位プロトコルとして、HTTPを想定しているが限定はされない

引用 IETF98 QUIC Tutorial 14p
https://datatracker.ietf.org/meeting/98/materials/slides-98-edu-sessf-quic-tutorialdraft-ietf-quic-qpack-09
draft-ietf-quic-http-22
draft-ietf-quic-tls-22
draft-ietf-quic-recovery-22
draft-ietf-quic-transport-22

OPS関連
draft-ietf-quic-manageability-05
draft-ietf-quic-applicability-05

ハッカソン- 前回: 12th Implementation Draft (draft-20)

H: handshake
D: Stream Data
C: Connection Closeハッカソン- 今回: 13th Implementation Draft (draft-22)

H: handshake
D: Stream Data
C: Connection CloseQUIC の状況- Chair「WGLCを目指す」- マイルストン: 。。。
- 「Early-Stage Process」 -> 「Late-Stage Process」-

https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md- IETF105 での議論はUpdate / Issue整理 / 関連報告 (2セッション)- ほぼほぼ Issue 整理

QUIC WGの今後- Interim: 2019-10-16 (America/Los_Angeles)- Interoperability Test

HTTP関連

HTTP WG
- 2セッション開催- HTTPtre Issue 整理- 今回はNew Workは少なめ
大きなトピックは、後述の Priority の議論を除いてない

Side Meetings

WebTransport
WebSocketというHTTP/1.1 や HTTP/2のコネクションをアップグレードしリアルタイム双方向通信を行うプロトコルがある。また、JavaScriptで利用するためのAPIがW3Cで定義されている。
HTTP/3 や QUICでは、トランスポートレイヤの改善されており、Unreliable deliveryなどを行えるように新しいフレームワークとして WebTransportがGoogleの人によって提案されている。
-draft-vvv-webtransport-overview
draft-vvv-webtransport-quic
draft-vvv-webtransport-http3

APIに関しては引き続きW3C側で議論

Masque
HTTP/3のコネクションをVPNとして利用する, “masque” プロトコルの提案。またクライ
アント認証方式も議論されている第三者からはただのHTTP/3に見えるため、masqueを喋っていることはわからない。
-

draft-schinazi-masquedraft-schinazi-httpbis-transport-authクライアント

内部ネットワー
クWebサーバ
HTTP/3
内部サーバ

Priority ()HTTP/2からはクライアントからHTTPリクエストの優先度を伝える事ができるようになった。
一般的にページのレンダリングを開始するにあたって、「 HTML > CSS > JavaScript >IMG」といった優先度があり、それをブラウザ自身が優先度を決定しサーバに通知する。
そのために、優先度木というものをサーバとクライアントで共有していた。

Priority (2/2)
HTTP/2で導入された、依存木の仕組みは複雑であり実用しずらいということが調査および実装者からフィードバックがあった。
HTTP/3では当初、HTTP/2のPriorityの仕組みを導入しつつ、パケットの順番が入れ替わっても動作するように改良されたPriorityの仕組みを導入していた。
Kazuho(Priority) HTTPヘッダレイヤでPriorityを扱う議論などがあった。

https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/att-0095/The_Priority_Header_Field.pdf