IIJmio meeting 16 「通信速度」に影響を与える要素とは

©Internet Initiative Japan Inc. ‐ 1 ‐‐ 1 ‐

IIJmio meeting #16「通信速度」に影響を与える要素とは

Internet Initiative Japan Inc.

hori


本日のテーマは「通信速度」

通信速度はロマン

• 技術革新によりサービスの理論値(規格上の最大値)が上がるとワクワクしますよね?

• 話者の理論値遍歴:

• 1.2-56kbps(アナログ)、64/128kbps(INS)、1.5Mbps(T1)

• 0.5-135Mbps(ATM)、156M-9.6Gbps(POS)

• 10M-1Gbps(ADSL/VDSL/FTTH)、10M-100Gbps(Ethernet)、

• 9.6kbps(PDC)、32kbps(PHS)、2-14Mbps(W-CDMA)、37.5-375Mbps(LTE)

理論値と実効速度

• コンシューマ向けサービスの多くでは「最大xxMbps」はあくまで理論値

• 常にこの速度が得られることを保証はしていない

• いわゆる、ベストエフォート

• 対義語: ギャランティ

• 理論値と実効速度のギャップはベストエフォートサービスにとって永遠のテーマ

• IIJmioのフレッツ、モバイルでも速度低下についてはお叱り、ご心配をいただいている状況

その通信速度(実効速度)に影響を与える要素は何か、今一度考えてみるのが

本日のテーマ


通信速度はどう測る?

感じる

• 感じられるのは主に遅さ。ある程度以上の速さは体感し辛い

• ウェブページを開くと画像が表示されない

• アプリをダウンロードすると時間が掛かる

• ビデオを見ると頻繁に読み込み中で止まる

• sshするとターミナルの操作がカクカクする

• VoIPの音声が途切れる

計測する

• (みんな大好き) スピードテストサイト、スピードテストアプリ

• ほんと大好き…

• 確かに一見してわかりやすいが、それ故に我々を悩ます存在でもある

• (レイヤ高め) ブラウザの開発ツール

• (お手軽) iperf

• (高価) 測定器でRFC2544試験


スピードテストで測る通信速度って何?

測定項目

• “ダウンロード/アップロード速度” (bps)

• 端末と計測先の間で単位時間に転送できたデータ量 (片方向)

• いわゆるスループット。一般的に「通信速度」と言えばこれを指す

• TCP(HTTP)で計測するのが一般的

• “ping” (秒、ミリ秒)

• 端末と計測先の間で行き帰りに掛かった時間 (双方向)

• いわゆるRound Trip Time (RTT)、遅延

• ICMP Echo Request/Reply (ping) で計測

この計測でわかること

• とある計測先とのTCP 1セッションの実効速度 (bps)

• とある計測先とのICMPのRTT (ミリ秒)

この計測ではわからないこと

• パケットロス有無 (実効速度が結果的に表してはいるが)

• RTTの揺らぎ (jitter)

• 普段自分が使うアプリケーションの速度

• 通信先、プロトコル、セッション数など、条件が計測アプリとは違う


(余談1) bpsとpps

bps (Bit Per Second)

• 1秒あたりに転送できるデータ量(bit)

• よく目にする指標。ネットワークの帯域を表すにはこちらが有効

pps (Packet Per Second)

• 1秒あたりに転送できるパケット数

• ネットワーク機器の性能を表すにはこちらのほうが有効

• ネットワーク機器の負荷は転送バイト数ではなく、転送パケット数に依存する

• 自分に届いたパケットの宛先を経路表で調べ次の転送先(NextHop)を決定、イーサネットヘッダを付け替えて転送先に送り出すのがルータ最大のお仕事

• データ(ペイロード)はパケットを送り出すときに後ろに付けるだけ

経路表

A

B C

A B C

宛先A

宛先B

ルータX

ルータY

宛先A: NextHop: ルータX宛先B: NextHop: ルータY宛先C: NextHop: ルータY

宛先C


なぜTCPで測る?

TCP93.8%

UDP5.2%

ESP0.7%

GRE0.3%

ICMP0.0%

TCP UDP ESP GRE ICMP

TCP87.5%

UDP9.3%

ESP3.1%

GRE0.1%

ICMP0.0%

TCP UDP ESP GRE ICMP

2015年 2017年

出典: 2015年 Internet Infrastructure Review Vol.28 (2017年は話者が独自に作成)

IIJモバイルサービスで流れるトラフィックの内訳

• UDPが増加傾向にあるが、未だTCPが支配的

• UDP増加の要因は443/UDP (QUIC)

• 443/UDP含め、HTTP/HTTPS関連が9割近い

実利用で一番使われる → 実利用での速度を表しやすい

• 単にTCP(HTTP)が実装し易いから、かも?

帯域で見たプロトコル分布


速度の変化はなぜ起きる? (1/2)

ノード同士を繋ぐデータの通り道 = ベアラ

各ベアラで発生する事象がEnd-to-Endアプリケーションの速度に影響

UE S-GW P-GW

Radio Bearer S1 Bearer

E-RAB S5/S8 Bearer

EPS Bearer External Bearer

End-to-End Service

PDN(Internet)

IP

TCP

HTTP

Application

eNodeB Application Peer

無線リソースの不足など

バックホールの帯域不足など

MNO/MVNO間接続点の契約帯域不足など

お客様のクーポン枯渇、経由するISPバックボーンの

帯域不足など

POI


速度の変化はなぜ起きる? (2/2)

MVNOではPOIの帯域不足が速度低下の要因となることが多い

• POIの帯域 = MVNOがMNOから購入する接続帯域

• MVNOが「帯域を増強します」と言ったらここを増やしていると思ってOK

なぜ帯域不足に陥る?

• (短期的) 需要読み違え

• 帯域増強には時間が掛る。将来の需要を見越して増強手続きをするが、予測を外すことも

• (根本的) MVNO事業のビジネス

• 価格に応じた品質、品質に応じた価格のサービスを提供することでMNOと差別化

• 設備産業であるISP/MVNOは、究極的には一定の設備(帯域)でより多くの収益を得る(=お客様を収容する)ことが目標、ギリギリの設備(稼働率100%)でやりくりしたいのが本音

• 一方で、コストに占めるMNO接続帯域費用の割合が非常に大きい

• 品質とコストのバランスを最適に保つことがMVNO事業のキモであり、同時に悩みのタネでもある

S-GWP-GW

POI1G

bps

1.2Gbps1Gbps 輻輳


POIが輻輳したらどうする?

1.2Gbpsのトラフィックを1Gbpsにするには? (トラフィック制御)

• いずれかのパケットを破棄する → パケットドロップ

• 帯域に余裕が出るまで送信を我慢する → バッファリング、キューイング

パケットドロップ

• どのパケットを破棄するかで、誰がどのような影響を受けるか決まる

• 通信の秘密、ユーザ間の公平性、ネットワーク中立性による制約があり、事業者の一方的な都合だけで自由な制御はできない

• パケットロスが発生する

バッファリング、キューイング

• 一定に見えるトラフィックもミクロに見れば量に波がある

• 帯域が足りない時は空きができるまで送信を遅らせる

• と言っても、蓄えられる量には限りがあり、長くても100msがいいとこ

• 200Mbpsを1秒蓄えるには25MBのメモリ(しかも高速なもの)が必要

• 蓄えるので遅延が発生する

では、パケットロス/遅延が通信、特にTCPに与える影響は?


そもそもTCPって?

Transmission Control Protocol

• RFC793 (1981年)

• インターネットでもっとよく使われるL4プロトコル

信頼性を重視した設計

• 安定しないネットワークでもパケットを相手先まで確実に届けられる設計

• その分、他のプロトコル(例えばUDP)から見ると非効率とも言える

TCPはすごい

• もっとも使われているだけあって、極めてよく考えられたプロトコル

• 確実にパケットを届ける様々な仕組み

• 輻輳・欠損・誤り・順序逆転・重複への対処

枯れたプロトコルでありながら、未だ活発な研究開発・拡張が続く

• 輻輳制御アルゴリズム

• Multi-Path TCP

• iOS Siriで実用

(余談) モバイル界隈だとSCTPも忘れてはいけない

• RFC4960 Stream Control Transmission Protocol

• UDP、TCP、SS7のいいところを取り込んだような、信頼性の高いプロトコル


TCPの雑シーケンス (1/2)

クライアントサーバ

Flag: SYN

Flag: SYN,ACK

Flag: ACK

双方が受信可能状態になってから、データを送り始める (3way Handshake)

Flag: ACK, Seq: 1, Len: 100

Flag: ACK送ったら受信確認を待って次を送る



受信確認ができなかったらもう一度送る(再送制御)Flag: ACK


Flag: ACK, Seq: 401, Len: 100都度受信確認を待つと効率が悪いので事前に決めた量だけまとめて送る(ウインドウ制御)

Flag: ACK, WindowSize: 0受信し切れないときは送信の停止を要求する (フロー制御)


TCPの雑シーケンス (2/2)

クライアントサーバ

Flag: ACK Seq: 501 Len: 100


輻輳しないよう、徐々に送信ペースを増やしていく(スロースタート)Flag: ACK Seq: 701 Len: 100




受信確認ができなければ送信ペースを落とす(輻輳制御)Flag: ACK

Flag: ACK


シーケンスから分かるTCPの特徴

双方がデータ受信可能になってから送る

• データ転送開始までに時間が掛かる

パケットロスしないよう徐々に送信速度を上げる、上げすぎてパケットロスし

たら一気に速度を下げる

• 接続先との途中経路は何が起きるかわからない前提

• 最大効率で送るまでに時間が掛かる

送ったら受信確認する、確認できなければ送信側が自発的に再送する

• 次を送る前に受信確認を待つので、RTTで効率(速度)が変わる

RTT 100ms時のTCPスループット実測値 (@FreeBSD)

# kldload dummynet

# ipfw add 65534 allow ip from any to any

# ipfw add 1 pipe 1 ip from <server> to any

# ipfw pipe 1 config delay 100ms

$ ping –c 5 <server>

(snip)

round-trip min/avg/max/stddev =

100.550/100.626/100.699/0.050 ms

$ iperf -c <server> -w 64k –t 120

(snip)

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-120.2 sec 72.1 MBytes 5.03 Mbits/sec

RTT毎のTCPスループット理論値(Window Size 64KB前提)


(余談2) 通信先が遠いとTCPは遅い

物理的距離、ネットワーク的距離とRTTは無関係じゃない

• 「インターネットに距離は関係ない」は都市伝説

• 遠いと、経由する機器が増える。経由する機器が多いと遅延が増す、お金が掛かる

• ルータ、伝送装置、ケーブル、etc

距離を超える工夫

• 物理的に短いファイバを利用する (日米は南半球周りより北半球周りが近い)

• 自社ネットワークを伸ばす (余計なISPを経由せず最適なネットワークが作れる)

• CDNを使う (近くから送る、事前に送っておく)

• プロトコルを変える (QUICなど)

• TCP高速化装置を入れる (シーケンス、パラメータをいじる)

https://www.iij.ad.jp/company/network/backbone/

東京の交換機最寄りのルータ〜 SanJose IPバックボーンルータ距離約8,300km (Google Map)L3ホップ数 2ホップRTT 平均 100.475ms

東京の交換機最寄りのルータ〜 NewYork IPバックボーンルータ距離約12,400km (Google Map)L3ホップ数 3ホップRTT 平均 143.756ms


(余談3) TCPの進化

Window Scale

• RFC1323 (1992年)

• Window Size上限64KBを拡張し、転送を効率化

Selective Ack

• RFC2018 (1996年)

• 必要なデータだけ効率的に再送

Explicit Congestion Notification

• RFC3168 (2001年)

• 中間ノード(ルータなど)が輻輳を検知すると受信側を通じて送信側に通知、送信側がウィンドウ制御で送信速度を落とす

• IPとTCPの合せ技 (IPも使うのでルータが介在できる)

Fast Open

• RFC7413 (2014年)

• 2回目以降の接続では、最初のSYNからいきなりデータを転送する

• 3way Handshakeのコスト削減

輻輳制御アルゴリズム

• Tahoe、Reno、NewReno、Vegas、Cubic、Compound-TCP

• より効率的な制御を求めて


パケット破棄 or 遅延?

POIが輻輳する

→ パケット破棄が発生 → 再送が発生

→ 遅延が発生 → 速度低下が発生

どうしても避けられない場合、パケット破棄と遅延のどちらが優しい?

• 以外と難しい命題

• 流れるトラフィックの特性や何を重視するかにも依存

• これという答えはないと考える

パケット破棄

• 再送で無駄なトラフィックが増え、更なる輻輳を生む

• しかし、TCPの仕組みで自然と速度が下がり、そのうち再送も減る

• 再送の仕組みがないプロトコルは通信が成り立たない

遅延

• 遅くなっても、最終的に通信は成立する

• みんなが速度を落として譲り合えば、さらに他の接続が流れる余地も生まれる

• リアルタイム性が求められるアプリケーションには向かない

• 蓄えるだけのリソースが必要 (機材が高価になる)


トラフィック制御に対するIIJの考え方 (1/2)

再送を減らす

• 再送はさらなる輻輳を生む

• 輻輳が始まったら早めに送信ペースを落としてもらう

公平性を重視する

• 出したもの勝ち、使ったもの勝ちにはしない

• 各お客様に対してある程度の速度を(極力)確保する

• 使った分に応じてコストを負担するモデル (クーポンの考え方)

遅延を一定にする

• 遅延のゆらぎ(Jitter)が大きいとVoIPなどへの影響が大きい

• 多少遅延が大きくても安定させる

実利用での品質を重視する

• 実利用時の通信はTCP 1接続ではない。複数接続を前提にした最適化

• 初速を出やすくし、少量通信は早く完結させて待ち行列を減らす


トラフィック制御に対するIIJの考え方 (2/2)

優れた土管を目指す

• 土管は中身に触れない、中身に応じた恣意的な制御はしない

• スピードテストだけ良くなる制御とか言語道断

• 流れ込んだパケットをそのままスムースに届けることを目指す

代償はある程度許容する

• RTTが比較的大きくなる傾向

• スピードテスト(RTT、スループット)の結果は悪く出がち

実状に追従し最適化を続ける

• 今の制御が来年も最適とは限らない

• HTTP2、QUICの台頭。端末解像度が高くなり、コンテンツも重量化

増強は正義

• 結果だけ考えれば、素直に接続帯域を増強するに優るものなし

• でもそうは言っても、やっぱり利益は欲しい

• 将来に渡り、安定してサービスを提供し続けるのも通信事業者の責務

• 赤字では長くは続かない。赤字当たり前の業界は不健全

• お客様満足と事業者利益の両立を追求するのが事業者のお仕事


本日のまとめ

様々な要素はあるが、MVNOではPOIの輻輳から来るパケットロスと遅延が通

信速度に大きな影響を与える。

IIJは実利用での品質、公平性、通信事業者として守るべきルールを重視しな

がら、通信制御をしている。

増強は正義。

最後に

• 現在の通信品質に必ずしも満足いただけていないことは重々承知しています

• 非常に重い課題ではありますが、小手先の対応から根本的な対策までさまざま手を打っていきますので、もうしばらく見守っていただければ幸いです