HTML5カンファレンス2013（http://events.html5j.org/conference/2013/11/）の17:15〜18:00、ルーム5Cの「通信キャリアプロフェッショナルが語るHTML5への期待」のメモです。

（コーディネータ）NTTコム 小松さん
（パネリスト）NTTコム 宮河さん、ソフトバンクモバイル 湧川さん、KDDI 藤井さん

（テーマ）
HTML5によるWebの進化。
他のレイヤに影響を及ぼしている。それをお互いに知らなければやっていけなくなる。
それぞれの領域で、今何が起きているか。

バックボーンNW: NTTコム 宮川さん
アクセスNW: ソフトバンクモバイル 湧川さん
クラウド基盤: KDDI 藤井さん

NTTコム 宮川さんの話

（PDFの資料）
http://www.nttv6.jp/~miyakawa/html5j/HTML-conf-2013-ntt-c-miyakawa.pdf

IP屋さん。
RFC 3769 Requirements IPv6 Prefix Delegationなどに携わった。
（RFC 3769→http://tools.ietf.org/html/rfc3769）

今年、Carrier Grade NATのRFCを完成させた。RFC 6888 CGN Requrements。
（RFC 6888→http://tools.ietf.org/html/rfc6888

IETFがHourGlassモデルを示している。HourGlass、つまり砂時計モデル。
（オリジナルの絵がどれかわからなかったので、Google先生で「hourglass ietf」で画像検索してみてください）

IPが真ん中。
IP屋さんは、今まではTCPより上のことはよくわからない。
HTMLを書くアプリ屋さん側も、TCPより下のことはわからない。
従来はこれでよかった。

キャリアグレードNAT。
今まではNATのWAN側はグローバルアドレスを持っていた。

ほとんどの携帯キャリアは既にCGNの下にある。

こういう会場でIPv4を使うと、通常は時間が経つとセッションが切れる。しかしこの会場ではセッションを一人ずつ割り当てられるように設定してあるので、一度払い出された後は切れなかったはず。
ちなみに今日繋がっているうちの6割？7割？（メモしきれなかった）の端末はIPv6で繋がっている。GoogleなどはIPv6対応しているので、そのままIPv6で繋がる。
IPv4と差を感じないと思うが、今は意識しなくてもIPv6を使っている状況になっている。

2008年頃、iTunesは1つで230〜270セッションも使っていた。
こういう情報を知らないと、ネットワーク側でどういう制限を掛ければいいかがわからない。

SPDYとかWebSocketとインフラは親和性があるのか？ それはわからない。
アプリ開発者の皆さん次第でネットワークの負荷が変わる。

今はサーバとの通信速度を基準にして評価されるが、WebRTC等が流行ると、「隣の家とどれぐらい早いか」のように今までと違う基準が出てくる可能性がある。

ソフトバンクモバイル 湧川さんの話

サーバとマシンのやり取りは、今まではHTTP1.1。
複数のTCPでマルチにセッションを張って1つでTCPに1つのやり取りを行っている。
SPDYでは1つのTCPに複数のストリーム。

今までは1つのページにセッションを切って繋いで……の繰り返しだったが、これからは長時間TCPセッションを張ることになる。
このTCPのLong-livedセッションは、モバイルに向かないか？
　・パケ詰まり
　・ハンドオーバー（で瞬断）

1つのTCPの中に複数のストリームがある場合でも、一つこけると（再送が入るので）そこで止まってしまう。
とすると、やはり複数のTCPセッションを張るのかなと思っている。

キャリアもいろいろやっている。
　・キャッシュ
　・CDN
　・オプティマイザ
　・フィルタリング
　・ファイアウォール
　・DPI
　・QoS

ただ「これからの技術は暗号化セッション上で流す」となるとキャリアができることは限られてくる。
使う側が技術の用途を考えて使ってほしい。
（補足：WebSocketは、従来のHTTP(S)の上でHTTPと異なるWebSocketプロトコルを流すためにHTTPSの経路でWebSocketを使うのが常套。こうしないと、仮にクライアント・サーバの両端がWebSocketに対応していても、通信経路上にWebSocketに未対応のルータ等があるとWebSocket通信ができない）

IPv6＋HTML5で本当のEnd-to-End通信になる。
ただ、本当にこれになって大丈夫かという疑問はあって、それはこれから解いていかないといけない。
今まではアプリとネットワークは別の事象だったが、理解し合わないとまずいのだと思う。

有害サイトのブロックを考えると、パケットの中が見えないと困る。
（HTML5で暗号化されるとこれができなくなる）

KDDI 藤井さんの話

今はネットワークでなくクラウド基盤のところをやっている。
クラウドの上で再定義されているサービスというところに興味を持ってきている。

HTML5はモバイル、ウェアラブル、クラウドへ。

Facebookはハードウェア機器までオープン化してコントロールできるようにしている。
AmazonはJavaScriptでAWSを操作できるようにしている。

PaaS、BaaS、MEAP（モバイル・エンタープライズ・アプリケーション・プラットフォーム）。

NTTコム 宮川さんの話2

先ほども話があったが、2015年に横浜でIETFがある。
これに合わせて、（IETFとW3Cの総会を近いところでやるということは）先例はないが、同時期に日本でW3CのTPACを開催したいと思っている。

インフラとアプリがバラバラでやるのは限界に来ていて、割と深刻な事態に突入しかけている。
これは逆にビジネスチャンスでもある。
IETFなりTPACで何かしようとすると1〜2年はかかるので、ドラフトを書いてくれてもブログで教えてくれるだけでもいいので、何か動いてほしい。
そうすると2年後のところでは動くものができていて、それは（IETFやW3Cで）大きなインパクトになる。

ソフトバンクモバイル 湧川さんの話2

（アプリ側から）ネットワーク側の方に来てほしい。requirements。
元々アプリ屋ではないので。

NTTとソフトバンク、あるいはKDDIも標準化の場では一緒にやっている。

KDDI 藤井さんの話2

他のレイヤから何かをやると、なぜそういうことができるんだということができるようになる。
ビッグジャイアントのプレイヤーに100%染まることはないので、競争し合って発展できる世界を今後も続けてほしいと考えている。

（ネットワークも含めて）すべてがプログラムできるんだということで、アプリやアーキテクチャをやっていってほしい。