IIJmio タイプAが遅い!? その答えはMTUの設定値に

2017/2/3 イベントレポ, ネットワーク, ネットワーク（KDDI）

はじめに

IIJmio meeting 14では、大内師よりKDDI網の各種特殊性について解説があった。しかしSlide Shareで共有されたプレゼンテーションではGoogleからの到達性が悪く、基礎知識がない状態で頭を空っぽにして閲覧するのは不可能なのでこの記事を書くに至る。

当然ながらこの記事はIIJmio meeting 14を見てきたの下に属するものである。

インターネットの基礎知識

みなさんが現在利用されているインターネットというのは、TCP/IPによる通信が主となって行われているのは大変有名な話である。利用者がサーバに要求したデータは細切れにされ、TCPヘッダが付加されてTCPセグメントになる。TCPヘッダが貼りあわされてTCPセグメントになったデータの破片はIPヘッダがさらに付与されてIPパケットとなる。そしてインターネットは一般的にイーサネットを伝送路として使っているので、さらにイーサネットのヘッダを貼り合わせてイーサネット・フレームとしているわけである。モバイルルータを化粧箱に詰め、その化粧箱をフラストレーションフリーボックスに詰め、さらに緩衝材とともに一般の配送用の箱に詰めてそれをトラックで運ぶというのをイメージすれば一部の人には解りやすいだろうか? 荷物を運ぶ軽トラを中型トラックに載せ、中型トラックを大型トラックに載せ、大型トラックを鉄道貨物の長物車に載せると考えても構わない。こういう非常に遠大な、勘弁してくれよと言いたくなるほどラッピングしてデータ通信が行われるというわけである。

そしてもう1つ単位に関する問題がある。それは一般的には8ビットと1バイトとは等価であるが、1バイトが8ビットでないシステムも過去に存在していたという事実もあるので、通信路について話す場合は8ビットをひとまとめにした物は1オクテットとして扱うということである。この文を読んでいる大概の人は1オクテットと1バイトとが等価であると考えていいが、計算機工学をやってるような人は決してこのように考えてはならない。

問題の詳細

さて今回の問題に戻ろう。今回の問題は “KDDI網内でジャンボフレームがサポートされず、速度低下が起きる” という話である。KDDIが発売していない端末は、IPパケットの長さは最長1500オクテットまで許容されていると設定されているため、IPパケットの長さが1500オクテットまで大丈夫な場合を前提とした値をMSSとしてサーバに通知する。当然ながら (サーバが許容すれば) 送信されるIPパケットの長さも最長1500オクテットとなっている。そしてサーバはその値をバカ正直に信じて要求されたデータを、1500オクテット区切りにしたIPパケットで、インターネットと携帯電話網の境界であるP-GWへと送りつけるわけである。サーバとP-GWを結ぶ回線は1460オクテット超(推定・根拠は後述)に対応する回線であれば何でもかまわず、仮に1460オクテット以下までしかサポートしない回線であれば、この問題はそもそも起きえない。大概はイーサネットとちゃんと互換性のあるものなので1500オクテットの対応となるだろう。なお、フレッツ光を使ってPPPoEでISPに接続しているサーバは、適切に設定・調整されている場合NGNの構造とPPPoEの関係上、MTUが1454オクテットとなっているはずである。

インターネットとの境界であるP-GWと、基地局のハンドオーバを把握するS-GW, 基地局であるeNodeBとの間は、それぞれUDP/IPの上に載ったGTPというプロトコルでそれぞれ繋がっており、サーバから送られてきたIPパケット(以下、内側パケットと称する)はGTPにより包装されるため、GTPヘッダ・UDPヘッダ・IPヘッダの計40オクテットがさらに付与されることとなる。従って仮にサーバから1500オクテット完璧に使い切った内側パケットが端末に届けられるとき、GTPおよびUDP/IPで包装した結果生じるパケット(以下、外側パケットと称する)は単純計算で1540オクテットの長さとなり、標準的な長さよりも長いパケットをP-GWと基地局との間に流さなければならない。

しかしこのP-GWと基地局との間を結ぶコアネットワークのどこか(もしくは全体)が1500オクテットまでしか対応しない(=ジャンボフレームに対応しない)経路だとどうなるだろうか? その答えは非常に簡単である。長さの制限を考えずに作った外側パケットを、IPの規格書通りに分割してしまうのである。

この結果、コアネットワーク内に存在するルータや基地局に分割・結合の負荷がかかってしまうだけでなく、ジャンボフレーム非対応のコアネットワークであっても内側パケットの最大長を十分短く設定すればジャンボフレーム対応のそれと比べて数パーセントパケットが増えるのに対し、内側パケットが長すぎるとジャンボフレーム非対応のコアネットワークの場合ジャンボフレーム対応のそれと比べて2倍もしくはそれ以上のパケット数がコアネットワークを流れることとなってしまい、ネットワークの有効活用という面から考えてもよろしくない。

問題の解消方法

既に設定されているMTUの値を書き換える、というのが問題の解消方法ではあるが、Androidスマートフォンや、IIJで動作を確認したモバイルルータのNEC Aterm MR05LN, MR04LNではMTUの値を書き換えるためのインターフェースが具備されておらず、モバイルネットワークを経路とすることを前提として構築したVPNを使ってしまうのが一番簡単な解消法ではないかと考えられる。

あとがき

KDDIが発売された機種ではMTUが1420になっている一方で、3GPPの方では外側パケットの暗号化やらIPv6伝送やらのことを考えて1358オクテットにするべき的なことが書かれており、この2つの考え方の違いを面白く感じる。

KDDI網を使ったMVNOの皆々様はLS-NATの出入口で、スマートフォンのセルラーモデム側でもpath MTU Discoveryが走っていることを期待して、DFビットの立った1500オクテットのIPパケットを捨てるようにするか、”正当業務行為” であると称して、TCPハンドシェイク時のMSSを勝手に書き換えるという “通信の最適化” をやっていただきたいと強く願いながら筆を置かせていただく。