JPNIC News & Views vol.1493【臨時号】第98回IETF報告 [第2弾] トランスポートエリア関連報告～IETF QUIC プロトコル標準化とその周辺～

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

2017年3月26日(日)～31日(金)にかけて、米国のシカゴにて開催された第98回
IETFミーティングの報告を、vol.1492より連載にてお届けしています。本号
ではその第2弾として、最近注目を集めているQUICに関する議論を中心に、ト
ランスポートエリアの動向をご紹介します。

第3弾以降では、IPv6やセキュリティ、DNSに関する動向を順次お届けする予
定です。また、第1弾として発行した全体会議の報告については、下記のURL
からバックナンバーをご覧ください。

  □第98回IETF報告

    ○[第1弾] 全体会議報告 (vol.1492)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2017/vol1492.html

また、第98回IETFのオンサイトでの報告会を、ゴールデンウィーク明けの2017
年5月12日(金)に開催いたします。前日の5月11日(木)17:00まで参加申し込み
を受け付けていますので、こちらにもぜひお申し込みください。

    IETF報告会(98thシカゴ)開催のご案内
    https://www.nic.ad.jp/ja/topics/2017/20170418-01.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第98回IETF報告 [第2弾]  トランスポートエリア関連報告
                              ～IETF QUIC プロトコル標準化とその周辺～
                                                     東京大学 小林克志
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■ QUICの背景と概要

QUIC WGは、前回のソウル会合で活動を開始した(*1)、トランスポートエリア
の新しいワーキンググループ(WG)です。今回のIETFでは、WGと併せて前日の
日曜日にチュートリアルも開催され、両方に多くの参加があり関心の高さが
わかります。WGとしての活動は非常に活発で、IETF会合に加え年3回のInterim
会合も計画されています。ちなみに、第1回Interimは2017年1月に東京で開催
され、3日間にわたって深い議論がなされています。

(*1) https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1457.html

WGの目的は、低遅延かつセキュアな通信を実現するトランスポートプロトコ
ルである「QUIC」の策定です。今日のWebサービスでは、体感品質(UX)の良否
は集客に直結するため、UXに大きな影響を与える、ネットワーク遅延を含む、
あらゆる遅延を可能な限り抑えることが求められています。QUICでは、バイ
トストリーム型トランスポート、すなわちTCPに起因するヘッドオブラインブ
ロッキング(HoL)の回避によって遅延を抑制します。HoLの問題は、HTTP/2で
も一つのコネクションにストリームを多重化し、ストリームに優先度を与える
ことで解決が図られていますが、QUICはHTTP/2では回避できない、トランス
ポート層におけるHoLの解決を目指しています。

WGのCharterでは、基本部分の標準化は2018年で完了する計画で、五つの目
標、すなわち

1) トランスポートに起因するアプリケーションの遅延の最小化
2) HoLのない多重化
3) 変更はエンドポイントのみ
4) マルチパス・前方誤り訂正(FEC)への拡張
5) 常にセキュアであること

が示されています。これらの目標の達成には困難が予想されますが、次に述
べた実装・利用実績もすでにあり、標準化・普及は意外と早い可能性があり
ます。

Google社はIETFのプロセスに先立ち、2013年から実験という位置付けでQUIC
(以下、Google QUIC)を、YouTubeなど自身のサービスで利用しています。同
社の発表では、Chromeブラウザ向けトラフィックの88%がGoogle QUICで占め
られ、HTTP(S)/TCPトラフィックは残りの一部に過ぎないことが明らかにされ
ています。QUICは、Google QUICを出発点として標準化が開始されました。
IETFらしいランニングコード先行というアプローチに加え、Google社の実績
は強力な推進力となっています。事実、今回のWGで複数の選択肢が検討され
た際にも、Google QUICで実績のある方式に収束することもありました。

QUICを一言でまとめると、

・上位アプリケーションにHTTP/2を想定
・マルチストリームに対応
・デフォルトでTLS 1.3の機能を利用する
・UDPベースのセキュアなトランスポート

と言えます。つまり、HTTP/2、TLS 1.3の仕様が固まった今が、標準化開始の
タイミングでもあったわけです。ベースとなるGoogle QUICがあるとはいえ、
多くのサービスが使用するHTTP/2向けに、TCPに代わるトランスポートをフル
スクラッチで設計・標準化する機会はそうそうないわけですから、多くの技
術者の注目を集めるのも当然です。


■ WGでの議論

WGでは最初に、

- 適用範囲(Applicability)に関するアプリケーションプロトコル設計者向け
  文書
- 取り扱い(Manageability)に関するコンテンツプロバイダを含むネットワー
  ク運用者向け文書

の二つがWGドラフトとして採用されました。

次いで、仕様が記述された四つのWG文書のアップデートについて発表が行わ
れました。発表順に、

1) トランスポートコア
2) TLS 1.3へのマッピング
3) 損失検出と輻輳制御
4) HTTP/2のマッピング、

となっています。

1)では、多くの変更の中から、ヘッダ形式、コネクションID、バージョン番
号のルール、トランスポートパラメータをTLS拡張として扱う、MTUディスカ
バリ、フローコントロールのうちSTOP_WAITINGの廃止、冗長な再送・確認応
答の禁止、エラーコードの取り扱い、などの修正が説明されました。質疑で
はコネクションIDとプライバシーの関係、そしてハードウェア実装に関する
懸念が示されました。

2)では、TLSハンドシェイクの非暗号化、QUICヘッダの整合性、TLS 1.3以上
を必須とする、1)との関連でトランスポートパラメータをTLS拡張として定義
する、といった修正が説明されました。

3)では、損失検出と早期再送、ハンドシェイク時の損失回復、RTT計算方法に
関する修正が説明されました。

4)では、特定番号のストリームマッピングの変更、HTTP/2ヘッダ圧縮方式の
変更、設定情報交換のフレーム形式の違いなどが説明されました。ストリー
ムマッピングの変更では、従来の暗号化ハンドシェイクのStream 1に加え、
新たにHTTP/2制御メッセージはStream 3に固定するというものです。HTTP/2
ヘッダ圧縮方式の変更は、TCPを前提としたHPACKから、QUIC向けに再設計さ
れたQPACKとするというものです。

残りの時間を使って議論が進められましたが、後述するGitHubにおいて、チェ
アから議論すべき課題が示され、それぞれを検討するというスタイルが採ら
れています。

最初に、非暗号化データの整合性チェックで利用する、アルゴリズムが議論
されました。CRC32、FNV-1a、AES-GCMについて議論され、会場ではFNV-1aが
好ましいという声が多くありました。

次いで、QUICおよびTLSバージョンの、ネゴシエーション方式について議論さ
れました。ダウングレードを可能とする方式、複数プロトコルバージョンの
組み合わせ爆発への懸念が示されました。

続いて、通信相手の接続性が失われた場合の、暗黙のコネクション切断につ
いて議論されました。明示的なシグナリングは不要で、端末側のタイマーで
管理すれば良いという意見に対し、明示的なシグナリングがない場合、ロー
ドバランサーなどのミドルボックスにおける、コネクション管理の懸念が示
されました。

さらに、受信済みのパケット番号を相手に返送できるようにすべきかどうか
について議論があり、往復遅延の計測には不可欠というコメントがありまし
た。一方で、パケット番号に加えてより多くの情報を返送することに対して
は、プライバシーに関する懸念も示されました。

最後は時間切れで、多くの課題が次回のInterim(パリ、2017年6月)に持ち越
されました。


■ 関連するWG/RG (Research Group)

その他、QUICと関係が深い話題として、TCPM (TCP Maintenance and Minor
Extensions) WGでタイマーベースの損失検出アルゴリズムRACKについて、IRTF
(Internet Research Task Force) ICCRG (Internet Congestion Control RG)
でBBR輻輳制御アルゴリズムについて発表がありました。前者のRACKは、重複
確認応答だけでは(閾値に達せず)判定できない損失を、送信側がタイマーに
よって早期に判定する方式で、QUICにも採り入れられる見込みです。後者の
BBR輻輳制御アルゴリズムは、経路上のボトルネックに起因する遅延を抑えつ
つ高いスループットを実現する方式ですが、これがGoogle QUICに実装されて
いることが示されました。ちなみに、実装と異なり標準文書では、BBRのよう
に標準化されていない方式を参照することはできないので、QUICは輻輳制御
方式として(標準化中の)CUBICおよびRenoが参照されています。


■ 変わるWG運営

WGの会場レイアウトは、従来のシアター形式からU字型のテーブル形式に変更
されていました。このレイアウトは、今回のIETFにおいて一部の会議室で試
行的に導入されたものです。IETFでは、フロアのマイクに発言希望者が並ぶ
形式が名物でしたが、テーブルの着席者は自席のマイクから直接発言し、マ
イクの往復にかかる遅延が抑制されることで、議論の効率化が期待されてい
ます。

WGでは、文書管理にオープンソースソフトウェア開発向けリポジトリ(GitHub)
を利用しています。QUIC WG文書はマークダウン形式で記述されており、修正
提案はそれへのパッチとして提起するようになっています。WGに提起された
すべての課題もGitHubで管理されており、誰でも容易に議論の流れを追うこ
とができます。そして、WGでは新たな課題を指摘する前に、解決済みの内容
を蒸し返すことがないように、過去の課題をレビューするように求めていま
す。

GitHubに関しては、プレナリでIESG (Internet Engineering Steering Group)
からリポジトリに置かれるべきIETFライセンスファイルの採用が発表されま
した。これはリポジトリ機能で作業ファイルを更新した場合の知財などの取
り扱いについても、文書、議論、メーリングリストでの貢献と同等に扱うと
いうものです。さらに、WGのGitHub利用についてBoF (Birds of a Feather)
が開かれ、GitHubの利用は最初にHTTPBIS WGが採り入れ、多くのWGがそれに
続いていることなども示されました。共有リポジトリのような、ソフトウェ
ア開発で培われた手法を採り入れる傾向は、ますます強くなっていくものと
思われます。

nroffやXMLでドラフトを書いていた経験からすると、GitHubを利用した標準
文書作成は隔世の感があります。現在の標準文書では求められる品質は高く、
個人あるいは数人で実現できるレベルではないという背景も、多人数の共同
作業を前提としたシステムへの移行を促しているということなのでしょう。


■ 帯域ファーストからUXファーストへ

会場でお会いした国内の通信事業者の方から「移動網ではネットワーク遅延
の抑制は大きな課題だが、利用者には帯域をアピールしている。」「総務省
のガイドラインも実質的に実効速度の計測・情報提供となっており、実効速
度に影響の大きい損失の抑制に力が入れられている。」「この傾向が続くと、
損失抑制に力を入れた結果、UXが極端に悪化したBufferbloatのような状況が
起こるのではないか」と懸念する声も聞かれました。遅延の抑制によって体
感品質を向上させていくという流れとは異なる性能指標が示されていること
は、はたしてユーザーにとって良いことなのか考えさせられました。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃  http://feedback.nic.ad.jp/1493/3dc32b345acf9b71d22c01b0d8456e9a ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃  http://feedback.nic.ad.jp/1493/33561fdd30378cee0a291038a7120a0b ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  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 News & Views vol.1493 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 ＠ 問い合わせ先  jpnic-news@nic.ad.jp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
登録・削除・変更   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), 2017 Japan Network Information Center
このページを評価してください
