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

2016年11月13日(日)～18日(金)にかけて、韓国のソウルにて開催された第97
回IETFミーティングの報告を、vol.1455より連載にてお届けしています。本
号では第3弾として、トランスポートエリアの動向を取り上げます。トランス
ポートエリアは、Google社が「QUIC」というプロトコルを提唱するなど、最
近注目を集める話題が目白押しのエリアです。

次号以降では、セキュリティおよびDNS分野の動向をお届けする予定です。こ
れまでに発行した全体会議およびIPv6関連の動向報告については、下記のUR
Lからバックナンバーをご覧ください。

  □第97回IETF報告

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

    ○[第2弾] IPv6関連WG報告 ～v6ops、sunset4 WGに関して～ (vol.1456)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1456.html

今週末の2016年12月16日(金)に開催する第97回IETFの報告会は、明日15日(木)
の17:00が参加申し込みの締切となっております。参加希望で申し込みがお済
みでない方は、お早めにお願いいたします。

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

■ はじめに

2016年11月13日(日)から18日(金)の日程で、韓国のソウルで第97回のIETFミー
ティングが開催されました。筆者は主にトランスポート層の技術に関連する
ワーキンググループ(WG)の会議に参加しましたので、その内容について報告
いたします。

IETFにおけるトランスポート層技術の議論は一時期停滞していた感がありま
したが、ここ数年は再び活発になってきているような気がします。これには
トランスポート層の一部機能が、現在のインターネットで利用するのに最適
ではなくなってきたという背景があり、近年Google社などの大手の企業が、
積極的にこの問題に取り組むようになってきたことがその要因ではないかと
思います。

TCPに代表されるインターネットのトランスポート層技術は30年以上前に開発
されたもので、現在でも大きな変更なしに使われ続けているという優れた設
計思想を持った技術ではあります。しかしながら、インターネットの発展に
伴って、いくつかの問題点が挙げられるようになってきました。

一つは、TCPの転送速度制御機構が、現在のインターネットにおいては最適な
ものではないという点です。TCPは当時のネットワーク環境や通信技術の水準
に合わせて設計されたために、現在の高速な通信環境ではネットワークの性
能を十分に利用しきれない可能性があります。また、インターネットの利用
状況も実用的、実務的なアプリケーションが増えて、遅延や効率に対する要
求が当時と比べて相当高くなっています。このような問題への対策として、
現在IETFではtcpm (TCP Maintenance and Minor Extensions)、tsvwg
(Transport Area WG)、iccrg (Internet Congestion Control Research
Group)といったグループで、TCPの拡張、改変について議論が行われていま
す。また、QUIC (Quick UDP Internet Connections)という、UDPをベースに
した新しいトランスポート層技術も最近注目を集めており、この技術の標準
化をめざすQUIC WGが新たに設立されました。

また、近年のインターネットでは、マルチパス(複数の通信経路)を想定して
プロトコルを設計することが重要になってきました。当時のインターネット
では、1台の固定されたPCが一つのネットワークに接続されるという前提があ
りましたが、現在はスマートフォンのような小型のデバイスを見ても、Wi-Fi
とキャリア回線の二つのネットワークに接続する機能を備えていて、しかも
利用者の移動に伴って、使用しているネットワークアドレスが変化する可能
性もあります。現在IETFでは、mptcp (multipath TCP) WGが、TCPのマルチパ
ス機能に関する標準化を進めています。

さらにここ数年、インターネット上のトラフィック監視や盗聴などに関して
関心が高まり、通信の暗号化に対する需要が大きくなってきました。この問
題に関しては、現在tcpinc (TCP Increased Security) WGが、TCPに暗号化の
機能を付加する技術について検討を重ねています。

それでは、今回のIETFで筆者が特に注目したものについて、簡単に解説して
いきます。


■ tcpm (TCP Maintenance and Minor Extensions)

tcpm WGの会議では、Google社のYuchung Cheng氏による、RACK (Recent
ACKnowledgment)という発表が大きな関心を集めていました。TCPは、ACKを元
にパケットロスを検出していますが、RACKはこれをタイマーベースに変更し
てより早くパケットロスを検出し、通信の効率化を図るという設計思想に基
づいています。少し単純化しすぎかもしれませんが、「このパケットは遅く
ともこのくらいの時間で届くはずなので、もしそれ以上かかった場合はなん
らかの原因でパケットが喪失したと考える」という捉え方をすると、理解が
早いかもしれません(詳細は draft-ietf-tcpm-rack-01を見てください）。

また、同じくGoogle社のNeal Cardwell氏による「TCP Options for Low
Latency」という発表も注目を集めていました。これは、TCPをデータセンター
のような高速通信が求められる環境に適したものにするため、TCPのtimestamp
optionで使用される値の粒度をマイクロ秒やナノ秒レベルに変更し、TCPのACK
遅延時間(パケットを受け取ってから実際にACKを送信するまでの時間)も同様
に低く抑えることによって、高速ネットワークでTCPを効率的に機能させると
いう提案です。大胆な提案ですが、Google社内のデータセンターでは、既に
2005年頃から試験的に導入を始めていたそうです。


■ tsvwg (Transport Area WG)

tsvwg WGでは、同WGの議長でもあるDavid Black氏の「Explicit Congestion
Notification (ECN) Experimentation」という発表を個人的に注目していま
した。ECNは、現在それほど利用されているとは言えませんが、数年程前から
Microsoft社のdatacenter TCPのような、ECNを拡張した技術への関心が再び
高まってきました。

このような背景を元に、Black氏はRFC3168で規定されているECNの仕様の一部
を更新し、ECNのフレームワークを利用した、新しい技術の開発促進を図ると
いう内容の発表を行いました。この提案は、反対意見もなく多くのサポート
を受けたため、近日中にWGのアイテムとして採用され、標準化へのプロセス
が開始される見通しとなっています。

この提案が受け入れられたことにより、今後はSimula Research Laboratory
のBob Briscoe氏らが開発を進めている、L4S (Low Latency, Low Loss,
Scalable Throughput)などの、ECNの拡張をベースにした技術の開発が、より
一層活発になるのではないかと思います。


■ mptcp (multipath TCP)

mptcp WGでは、mptcpの現在の仕様を規定したexperimental RFC6824の改訂版
として、RFC6824bisの標準化を進めています。RFC6824bisでは、現行RFCに基
づいた実装から得られた知見を元に、Handshake mechanismの改善、新機能の
追加などが提案されています。今回の発表でもいくつかの新機能の提案があ
り、大きな反対はなかったため、そのまま追加されていくものと思います。
その他の注目点としては、mptcpをISP内部やISP間の通信で利用したいという
要望から、mptcpのproxy機能に関する関心が高まっていることが挙げられま
す。mptcpは、複数の通信経路を同時に利用して通信することができ、それぞ
れの通信経路に対するデータ転送速度の制御、異なる通信経路を経由して届
いたパケットの再構成といった、マルチパス通信の諸問題に対処する機能が
あります。

ISPでは、mptcp proxyを複数ある通信経路の集約ポイントに設置することに
より、サービスをより効率的に行うことができる可能性に着目しています。
今回の会議では、proxy技術の標準化の方向などについて議論が行われまし
た。また今回のIETFでは、BANANA (Bandwidth Aggregation for interNet
Access)というBoFが開催され、通信経路の集約技術に関する議論が行われま
したが、mptcpも利用すべき技術の一つとして検討されることになるようで
す。ただし、今回のBANANA BoFは初めての会議だったため、具体的な結論が
出るまでには至りませんでした。


■ iccrg (Internet Congestion Control Research Group)

iccrgは、IETFではなくIRTF (Internet Research Task Force)のRG (Research
Group)の一つですが、ここでもトランスポート関連の議論が行われることが
あります。今回は、先ほどのCheng氏とCardwell氏によるTCP BBRの発表があ
りましたが、質問者がマイクの前に長い行列を作り、関心の高さをうかがわ
せました。TCP BBRは簡単に説明すると、ネットワークの可用帯域を推測して
転送速度の調節を行う技術ですが、過去に提案されたTCP Vegasなどとは、帯
域推測の結果に強く依存した制御を行う(つまりパケットロスを輻輳の兆候と
見なさない)という点が大きく異なっています。発表中に、Google社のネット
ワーク環境を利用した実験結果が示されていましたが、これを見る限り良好
な結果が得られているようです。ただし、この技術はまだ実験中とのことで、
標準化の動きはそれほどすぐには起こらないものと思われます。


■ おわりに

以上、簡単ですがトランスポート技術関連の報告をさせていただきました。
今回、筆者の参加した会議は全体的に、発表件数が通常よりも少なめな印象
を受けました。しかし、その分活発な議論が長い時間行われ面白い発表が多
く、個人的に楽しめたと思います。


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

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

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          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), 2016 Japan Network Information Center