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

2019年7月下旬にカナダ・モントリオールで開催された第105回IETFミーティ
ングのレポートを、vol.1708より連載にてお届けしています。連載の最終回
となる本号では、TCPとQUICのそれぞれの特徴に触れつつ、トランスポートエ
リアにおける技術トレンドについてご紹介します。

なお、これまでに発行した第105回IETFの各報告については、下記のURLから
バックナンバーをご覧ください。

  □第105回IETF報告
    ○[第1弾] 全体会議報告 (vol.1708)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2019/vol1708.html
    ○[第2弾] IoT関連報告 MUDとHackathon
      ～IoT機器の安全なネットワーク接続～ (vol.1709)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2019/vol1709.html
    ○[第3弾] 「DNSの処理を行うアプリケーション」の話題 (vol.1711)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2019/vol1711.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第105回IETF報告 [第4弾]  トランスポートエリア関連報告
                                           GE Global Research 西田佳史
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2019年7月20日(土)から26日(金)の日程で、カナダのモントリオールにおいて
第105回のIETFミーティングが開催されました。筆者は主にトランスポート層
プロトコル関連のミーティングに参加してきましたので、今回はIETFにおけ
るこの分野の、技術トレンドについて報告させていただきたいと思います。

筆者は10年間ほど、IETFのMultipath TCPワーキンググループ(WG)という、
TCPの拡張技術の標準化を行うグループのコチェア(共同議長)を務めてきまし
たが、今回のモントリオールの会議では、WGの収束がかなり真剣に議論され
ました。もしWGの収束が正式に決定されるとなると、WGは実質的に消滅し、
今後関連する技術の議論は他のWGへと移管されることになります。筆者とし
ては、立ち上げ時から関わってきたWGが無くなることに関して寂しさを感じ
る部分はありますが、発足からかなり長い時間が経過し、標準化の作業もか
なり落ち着いてきたので、そろそろ区切りをつけてもいいかもしれないとい
う気持ちもあります。


■ Multipath TCPの技術動向について

Multipath TCPはTCPの拡張技術の一つで、この拡張を利用すると、TCPで複数
の通信経路を用いた通信が可能になります。従来のTCPでは、Wi-Fiと携帯電
話の二つの通信回線があったとしても、一つのTCPコネクションで利用できる
のは、どちらか片方の回線に限定されていました。一方、Multipath TCPを利
用する場合は、一つのコネクションで二つの回線を同時に利用したり、どち
らかの回線を通信状況に応じて選択しながら通信したりするといった、柔軟
な運用が可能になります。この技術はApple社の提供する、Siriなどのサービ
スで利用されています。Apple社では、Multipath TCPで遅延の小さなネット
ワークを優先的に利用することで、迅速なレスポンスを実現することを目的
としているようです。

今後のMultipath TCP技術の動向は、セキュリティ機能の強化などの、機能拡
張に関して議論が進められていくことになると思われます。Multipath TCPに
は、まだこのような技術的課題が残っているので、WGを収束するには早いの
ではという意見もあるのですが、一方でセキュリティのような機能拡張は、
Multipath TCPには必要ないかもしれないという意見もあります。この背景に
は、昨今のIETFでQUICという新しいトランスポート技術の議論が、活発になっ
てきたことがあげられます。


■ QUICの技術動向について

QUICは、UDPの上位層として設計されているトランスポートプロトコルで、TCP
の上位互換となるような機能を提供できるように、設計開発が進められてい
ます。QUICは、TCPの持っている問題点に対する改善策を採り入れて、通信の
効率化、高速化や、安全性の強化などを目標としています。また、QUICの開
発に伴って、HTTP技術の改変も進んでいます。今までのHTTPは、トランスポー
ト層のプロトコルにTCPを利用していましたが、これをQUICに置き換えた、新
しいHTTPを開発するというものです。このQUICをベースにしたHTTPは、HTTP/3
として、現在標準化のための議論が進められています。


■ QUICとTCPの違いについて

ここでQUICとTCPの違いについて、簡単に説明してみたいと思います。

一つは、セキュリティ面の強化です。現在、TCPを用いた通信を暗号化する場
合は、上位層でTLSを利用するのが通常となっています。これは、TCPに暗号
化の技術がなかったためです。近年、この問題に対処するためにtcpcryptと
いう、TCPのセキュリティ拡張が開発され標準化されましたが、まだ技術の普
及が進んでいません。また、長い歴史を持つTCPでは、多くの既存アプリケー
ションがあるため、暗号化機能を持たない過去のバージョンとの、互換性を
保つ必要があります。このため、暗号化を行わない通信も、引き続きサポー
トしていくことが求められています。

これに対し、過去の資産のないQUICは、すべての通信を暗号化し、暗号化し
ない通信は一切サポートしない、という設計になっています。こういった点
から、先ほどのMultipath TCP WGの例では、Multipath TCPで難しい課題があ
りそうなセキュリティ拡張を考えるよりも、QUICでマルチパス通信を行うこ
とを検討した方が楽なのではないかという意見が出るようになりました。

また、通信遅延の低減もQUICが注力している点です。TCPはデータ送信を開始
する前に、通信手順の確認作業のため、最低でも3回のメッセージの交換を行
う必要があります。また前述の通り、TCPで暗号化を行う場合はTLSを利用す
る必要がありますが、TLSの暗号化手順を確認するため、ここでもメッセージ
の交換が必要になります。

ここで問題となるのは、TLSのメッセージ交換は、TCPの通信が確立した後で
ないと、行うことができないという点です。つまり、TCP＋TLSで通信を行う
場合、データが転送できる準備が整うまで合計で7、8回程度の、メッセージ
交換が必須となってしまうのです。たかがこの程度という見方もあるかもし
れませんが、RTT (Round Trip Time)の比較的大きな回線では、体感できるほ
どの差が出る可能性があります。QUICでは、暗号化の機能がプロトコル内に
あるので、TCPによる通信の確立とTLSの暗号化手順の確認に相当するものを、
同時に行うことができるため、データ送信の準備が整うまでの時間を大幅に
短縮できるメリットがあります。

また、HTTPなどの通信では、比較的短い間隔で同じ相手と通信を行うことが
よくありますが、このような場合、QUICはさらに低遅延な通信を行うことが
できます。この仕組みは、TLSの最新バージョン1.3でも採用されている0-RTT
と呼ばれるもので、過去の通信で利用したセッションに関するパラメータを
キャッシュしておくことによって、2回目以降の通信では、通信のセットアッ
プの開始時からデータ転送を行うことを可能にするものです。

さらにQUICには、TCPで指摘されていた問題点に対する対策が、いくつか取ら
れています。例えば、TCPにはロストしたパケットが再送されて正しく受信さ
れるまで次のパケットを処理できない、ヘッドラインブロッキングと呼ばれ
る問題がありますが、QUICではストリームという概念を導入することで、こ
の問題を軽減することができます。またRTTの計測は、通信の性能を左右する
要素の一つですが、QUICではホスト内での遅延とネットワークの遅延を区別
する仕組みが導入されていて、TCPよりも高い精度でRTTの計測を行うことが
可能になっています。その他、バージョン番号の導入や、機能拡張を柔軟に
するパケットフォーマットの工夫により、新しい機能を比較的簡単に追加し
ていくことができる設計となっている点なども、TCPになかった特徴です。

このように有利な特徴を持つQUICですが、TCPの方にメリットがあると思われ
るケースもあります。例えばTCPでは、TOE (TCP Offload Engine)という、NIC
レベルで高速にパケットを処理する技術の普及が進んでいます。またTCPに
は、PEP (Performance Enhancing Proxy)という中継ノードを利用して転送性
能を向上させる手法がありますが、パケットヘッダまで暗号化するQUICでは、
この方式を利用することには困難や制約があります。さらに、インターネッ
ト上にはUDPのトラフィックを遮断したり、転送速度を制限したりしているサ
イトも存在しています。加えてISPの観点からは、QUICトラフィックを観測し
ても通信状況がわからないため、問題があった場合に対処が難しい技術とい
う理由で、積極的に採用したくないといった意見もあります。

いろいろな視点はありますが、QUICは現在IETFにおいて、とても注目を集め
ているようです。IETFミーティングでは、1週間の間に100以上のミーティン
グが並行して行われますが、昨今のIETFミーティングではQUIC WGのミーティ
ングは毎回150名程度の参加者がおり、参加者数の多いWGの上位5位内に常に
入っています。また、QUIC WG以外のミーティングでも、QUICの性能解析、
deploymentの状況などに関する議論が、多く行われている印象を受けました。

実は、IETFがTCPやUDPに代わるトランスポートプロトコルの開発と標準化を
試みたのは、今回が初めてではありません。過去にはSCTPやDCCPという、二
つのプロトコルが標準化されました。ただし、この二つのプロトコルは、現
状でそれほど普及していません。これらのプロトコルの普及にあたり妨げと
なった大きな要因は、NATを新しいトランスポートプロトコルに対応するよう
に、更新する必要があることです。また、新しいプロトコルの特長を生かし
たキラーアプリケーションの存在も重要になります。しかし、UDP上のプロト
コルであるQUICは、NATを更新する必要はありませんし、Webアプリケーショ
ンという大きなターゲットも既に持っています。QUICが今後どの程度普及し
ていくのかは、今の時点でははっきりとは分かりませんが、過去のプロトコ
ルにあった普及における問題を克服している点で、期待が持てると思います。

以上、簡単ですが、IETFにおけるトランスポート技術関連の報告をさせてい
ただきました。筆者は個人的に、QUICの影響によりIETF全体でトランスポー
ト技術の議論の熱が、近年高まっている印象を受けています。今後も機会が
あればミーティングに参加して、この分野の技術動向に着目していきたいと
思っています。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
          まわりの方にもぜひNews & Viewsをオススメください！
      転送にあたっての注意や新規登録については文末をご覧ください。
                  ◇              ◇              ◇
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃ https://feedback.nic.ad.jp/1717/6dc15e0bd8c20507fa6430bb7a33ed6d ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃ https://feedback.nic.ad.jp/1717/bd58991141f84b4490ef7f2c33c3316a ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  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.1717 【臨時号】

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