iOS 7でMPTCP(Multipath TCP)がサポートされた。 ((Apple iOS 7 surprises as first with new multipath TCP connections))
唐突 ((しかし実はIETF87で、anonymous OSが実装しているという話もあり、iOS 7がそれだったのかと納得した訳だが))なのだが僕の博士課程における研究テーマであり、先のIETFで大人たちにメッタメタにされたのも悔しいのでMPTCPについて説明して、何が出来るようになるかを書きたいと思う。
MPTCPとは簡単にいうとTCPストリームを複数の経路で転送することにより、ストリームの多重化・耐障害性の向上を図るプロトコルである。
このタイミングでなぜこうしたプロトコルが必要か簡単に説明したい。
僕らが使うアプリケーションは大抵TCPを用いて通信をしている。それは長いインターネットの歴史でもあり、順序制御・再送制御・誤り制御をトランスポート層のプロトコルが行うことにより、僕らはそういったことを意識せず済むからである。
TCPはIPおよびポート番号を用いてストリームを識別する。例えばsrc: 192.168.0.1:3208 dest: 192.168.0.2: 63234といった形だ。そのためIPアドレスやポート番号が変更されると通信を継続するにはTCPストリームを再接続しなければならない。
話を変えて僕らが持つスマートフォンは大抵3GとWiFiという2つのIPインターフェイスを持っていることが多い。TCP・UDPでは1つのストリームにおいて複数のIPアドレスを用いることが出来ないため、通常どちらかのインターフェイスを優先的に使用するように制御されている。例えばWiFiが有効な環境においては新規のTCPストリームはWiFiのIPアドレスを用いて通信するなどだ。
この発想はインターフェイスが頻繁に変更されない場合有効である。しかし、インターフェイスが頻繁に接続・切断を繰り返しインターフェイスのスイッチが頻繁に発生するような場合（例えば公衆無線LANが入り乱れる都心の市街地を歩いているような場合）においてTCPセッションはインターフェイスが切り替わる度に再接続を行わなければならない。
TCPは僕らが生まれる前(1982年)に発明され、その当時の不安定な回線において信頼できる通信を行うために、3-way handshakeを必要とする。3GやWiFiなど遅延が大きなネットワークにおいてただただ通信を開始するためだけにパケットを往復させることは通信に大きな遅延を引き起こす。これが市街地において特に移動中公衆無線LANが全く使い物にならない原因の一つである。
（もちろんWiFiのイニシエーションにも時間がかかるので、それを早くしようという802.11aiなどもあるがこれは後日）
そこでTCPが持つ1つのIPアドレス・ポート番号でバインドされた経路しか使えない状況を改善し、複数の経路を用いてTCPのような通信を可能にしようという取り組みがなされてきた。
SCTPはPoint-to-point のプロトコルであるものの、エンドホストが複数のアドレスをサポートするため、エンドホストに到達するために複数のアドレスを使用することが可能であり、それにより下層レイヤー（つまりIPインターフェイス）の切替といった場合にもストリームが切断されることなく通信が可能なプロトコルである。
またMobile IPやMobile IPv6といったIPレベルでの取り組みもなされた。Mobile IP/IPv6はホームアドレスと呼ばれる移動をしても変化しないアドレスを用いることでインターフェイスが切り替わりネットワークをハンドオーバーしてもTCPやUDPなどIPアドレスをキーとして依存するプロトコルの切断を防ごうという取り組みである。
さらにはもっと低いレイヤーで3G/WiFiのハンドオーバーといった研究開発が行われてきた。
しかしながら、今日現在いずれのプロトコルもliftすることができていない。
なぜなら僕らはTCP・UDPをから逃れることができないからだ。
現在僕らがインターネットで使う殆どのプロトコルはトランスポートにTCP/UDPを使用して、インターネットもTCP/UDPを前提に設計・運用されている。例えばIPv4アドレスを共有する手法としてNATがあるが、NAT自体TCP/UDPに特化していて(もちろんGREとか対応しているのもあるけど) いくらTCPが先に述べたような問題があったとしても星の数ほどあるNAT-boxをSCTPに対応させるということは不可能である。
また3G/WiFiのハンドオーバーなども3G/WiFiいずれも同じネットワークオペレータが運用するといった場合には実現が可能でも、今日のインターネットような様々な組織が様々なネットワークを運用する形態においてはなかなかdeployすることが難しい。（技術的にもポリシー的にも難しい）
そんな中TCPを殆ど改変せず複数のストリームを扱えるようにしようという発想で提案されたのがMPTCPだった。
プロトコルの詳しい説明はきちんとまとめて記事にしたいので控えるが、MP_CAPABLEと呼ばれるTCPオプションを用いてエンドホストでnegotiationを行い、双方がそれをサポートする場合に限り2つ以上の経路を用いて通信を多重化し、下層レイヤーの障害の影響を受けずにTCPセッションを維持することが出来るTCPの拡張プロトコルである。
このMP_CAPABLEなどの処理はOSなどに実装されたTCP実装が透過的に行うため、アプリケーションからは普通のSocketと同じように利用することが可能である。つまり既存のアプリケーションを変更することなく、自動的に複数の経路を用いて障害に強く、多重化されたTCP通信を行うことが出来る。SCTPなどはアプリケーション自体の書き換えが必須であったことを考慮すると非常に有効であるといえる。
TCPオプションという話をすると必ず問題になるのがmiddleboxである。
理想的な環境ではインターネットを流れるパケットは改変されることなくエンドに転送される。しかし、現実のインターネットではNATやファイアウォール、更にはアプリケーションアクセラレータなどパケットを改変する中間者が大量に存在する。
MP_CAPABLEなどの未知のTCPオプションが存在する場合、そうしたmiddleboxはパケットを破棄したり、TCPオプションの破棄などを行うことが指摘されている。 ((Is it Still Possible to Extend TCP? Michio Honda, Yoshifumi Nishida, Costin Raiciu, Adam Greenhalgh, Mark Handley and Hideyuki Tokuda, ACM Internet Measurement Conference (IMC), November 2011, pp.181-192, Berlin, Germany))
そこでMPTCPではそうしたmiddleboxが存在している場合でも通信を行えるような仕組みや、最悪の手段としてTCPにフォールバックする仕組みが存在している。 ((How Hard Can It Be?! Designing and Implementing a Deployable Multipath TCP))
前振りが長いが、で、MPTCPがiOS 7でサポートされて何がインパクトが有るか。さーっと考えてみた限りこんなインパクトが考え得る。
- 3G/WiFiのハンドオーバーがスムーズになる
- 優先制御が可能であるため、回線の重み付けが可能にある
ここでは説明していなかったが、MPTCPでは経路毎の優先制御が可能である。
例えば3G:10%, WiFi:90%といった具合である。この場合もWiFiが切れても自動的に3Gで再送が行われるため、TCPセッションは切れることがない
現時点ではLinuxとfreebsd, iOS7でしか実装されていない。
GoogleはRTTの影響を受けにくいプロトコルとしてUDPをベースとしてQuicを提唱している。Quicももちろん有効に働くと思うが、Quicの場合アプリケーションの書き換えが必要になる。
MPTCPはカーネルにおいて処理されるため、アプリケーションの書き換えなしにストリームの多重化が可能になる。もちろんどちらのプロトコルが優位であるという議論をしたいわけではない。
iOS 7ではまずはSiriでMPTCPが有効にされているという話だ。
ユーザの音声データをなるべく早くサーバに送信したい（でも失敗したくない＝再送は時間がかかるのでUXに影響がでる）ので、WiFi/3Gの両方を使うことで確実に早く転送したいというケースで、MPTCPのユースケースとしては非常に優れていると思う。
記事でも指摘されていたがこれから他のアプリでも有効になるのではないかと思う。
MPTCPはサーバでも有効にされて初めて効果がでるプロトコルなのでこれからサーバ側の実装も必要になる。まだまだユースケースも少ないプロトコルなので、標準化や研究にうまく結びつけていきたいなと思う。
ここは間違ってるとか、補足すべきことがあるとかあったら指摘していただけるとうれしいです。
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.