2011-06
20
03:07:46
ソフトバンク回線のパケットロスがひどいというので、ほんとーーにそうなのか確かめてみた


追記書いてます。

#softbank 携帯によるデータ通信でのパケロスは本当に酷いのか?

という話があって、聞こえてくる話では75%のパケットロスもあるのだという。
一般的にネットワークに関わる層には一概に信じられないロス率だが、Twitterなどで流れてくる数値ではよく信用できないのと、ある程度偏ったテスト環境になってしまっている気もしたので、ドコモ回線含め時間帯も変えて比較してみることにした。
テスト環境は以下の通り。

テスト概要
JailBreakしSIMフリー化したiPhone3GS(iOS4.2.1)にてソフトバンク iPhone通常回線(smile.world)とドコモ データ定額(mopera.flat.foma.ne.jp)で複数のサーバーに対してping(ICMP echo)テストを実施し、パケットロス率およびラウンドトリップを計測する。

テスト方法
SSHでiPhoneへログインし、Cydiaのinetutilsに付属するpingコマンドを計30回試行し平均値を得る。

テストサーバー

  1. www.yahoo.co.jp(ロケーション: 東京 丸の内 ブロードバンドタワー)
  2. www.google.co.jp(ロケーション: 恐らくアメリカ西海岸)
  3. テストサーバー1(ロケーション:アメリカ FremontにあるVPSサーバー)
  4. テストサーバー2(ロケーション: さくらインターネットのVPSサーバー。設置場所は不明だが国内)

テストは都内から行っている。また時間帯も変えることとし、とある日曜日のPM9時台と翌日AM2時台の二度行った。

結果は以下の通りである。

テストケース1: PM9時台に実施

フレッツ光(Wi-Fi)
packet loss min avg max stddev
www.yahoo.co.jp 0% 11.704 16.691 23.845 3.0003ms
www.google.co.jp 0% 43.708 46.835 54.807 2.081ms
テストサーバー1 0% 139.024 187.894 239.065 30.026ms
テストサーバー2 0% 18.814 22.512 25.306 1.460ms
docomo(データ定額)
packet loss min avg max stddev
www.yahoo.co.jp 0% 108.174 118.389 154.171 8.798ms
www.google.co.jp 0% 128.898 141.954 155.505 6.944ms
テストサーバー1 0% 206.165 217.398 361.339 26.932ms
テストサーバー2 0% 106.566 132.891 613.313 89.298ms
Softbank(iPhone)
packet loss min avg max stddev
www.yahoo.co.jp 73% 88.733 179.106 370.456 92.697ms
www.google.co.jp 86% 116.306 120.867 126.555 4.248ms
テストサーバー1 76% 240.308 259.038 318.825 24.805ms
テストサーバー2 90% 121.751 131.433 146.446 10.763ms

テストケース2: AM2時台に実施

Softbank(iPhone)
packet loss min avg max stddev
www.yahoo.co.jp 3% 114.327 245.465 2133.128 403.058ms
www.google.co.jp 23% 107.446 178.063 896.914 161.420ms
テストサーバー1 0% 533.464 1064.434 1991.588 373.095ms
テストサーバー2 3% 401.674 967.69 1886.757 345.000ms

 

比較のためWi-Fi(回線はフレッツ光)も付記している。

まず第一に流れている話通り、PM9時台では確かにロス率は70%から最大90%にも達している。まさしく通常はあり得ないレベルだと言ってもいいだろう。
しかしもう一点注目すべきなのは、ラウンドトリップに関しては、実はドコモのそれと遜色ない、若しくは場合により上回っている場合もあるということだ。
次にAM2時台となるとロス率は格段に改善されている。ほぼ問題無いレベルと言ってもいいだろう。しかしその反面ラウンドトリップは極端に落ち込み、特にmax値は10倍以上遅延しているケースもあった。また平均偏差も非常に大きくなっている点にも注目したい。これはネットワーク状態が安定していないことを示している。
果たしてこれらは何を意味しているのか。

ここから憶測にすぎないが、テストケース1において、恐らくソフトバンクのバックボーンネットワークの性能自体はドコモと比較してもそれほどの遜色は元々無さそうだと言うことだ。しかしそれはパケットロス率を上げることでバックボーンへの負荷を低減しているからではないか。
これはテストケース2においてロス率が下がったと同時にラウンドトリップが極端に下がった(つまりネットワークが飽和しつつある)ことからも想像できる。
すなわち、パケットロス率はバックボーンへの負荷を減らすべく元から意図されたもので、時間帯により例えばスイッチングルーターのバッファ量を調整するなどして日夜調整されているのではないかという推測が成り立つ。

僕自身はネットワークの実務経験も乏しく専門性は持ち合わせていないのでこれ以上の論評は差し控えるが、これはこれで1つの「見切り」かも知れないという気はする。
ユーザーとしての感想を述べるなら、僕自身はパフォーマンスも少なくとも最近は1Mbpsを下回ることもなく安定して使えていると思っており、これまでもソフトバンク回線に(電波の入り以外に)大きな不満を感じたことはない。
スマートフォンに絞ればほとんどの通信はTCPベースであることは確かであり(UDPで困るのはDNSぐらいか)非常に多くのリトライパケットが発生するとしても全体としてはそれなりの「実測値」が得られると言うことなのかも知れない。

ネットワーク屋にとってはとても考えられない対応かも知れないし(僕自身もそうしたチューニングを決意する度胸はないが)、単にパケットロス率のみ取り上げて非難するのは簡単だ。しかし1つの方法論として今後「冷静に」大いに議論されても良い点ではないだろうかとも思う。
何故なら、これはもしかすると今後いずれのキャリアも通る道かも知れないからだ。

45 thoughts on “ソフトバンク回線のパケットロスがひどいというので、ほんとーーにそうなのか確かめてみた

  1. ソフトバンクの回線容量はドコモの1/3なので容易に輻輳を起こします。
    対策として不要なパケットは破棄しています。
    PINGはICMPなので破棄されました。

    1. 補足です。
      不要なパケットというのはソフトバンクが勝手に決めたものでユーザーにとっては不要でないパケットも含まれます。
      ドコモやKDDIのようなまともな回線にするのを放棄した結果です。

  2. 最も肝心な事を忘れている。
    再送の発生はパケット料金の増加を意味するということ。
    え、定額だから関係ない?
    それって、何か違いません?

  3. 検証結果と記事のコメントがかなり勉強になりました。

    やはり詳しい人がみると全然違いますね。
    自分も簡単な内容ですが、検証してみましたが、
    TCP通信での再送は、特に見られませんでした。

    ICMP側は、何か設定があるんですねぇ
    こういう話を聞くともっと勉強しなきゃと、
    思いますね。。

  4. ICMPだけでは不十分というのはもっともな意見。
    ICMPロス率は酷いものに見える。
    ICMPは通常低優先であるのはみなさん指摘の通り。
    ついでに、ping 1000回程度で規制するネットワーク屋、アプリケーションプロバイダは居ない。 そんな少量を相手にする余裕は無い。

    で、結局試験内容が不十分なのでちゃんと検証できていないので再検証が必要と思われる。

  5. 実験を行うのであればTCPでのパケットロス量を測定すべきです。TCPで大量のパケロスが発生してリトライが多ければ通信性能が大幅に劣化するはずですが、それを感じていないのであればIPv4でのICMPの流量規制が行われているだけな気がします。ICMPへの規制はよくあります。

    1. 3G回線下でTCPのエラー率やロス率を観測するよい方法は何かありますでしょうか。
      一般論としてICMPを落とすことはよくあると思いますが、キャリアグレードつまり公共インフラでも本当によくあることなのでしょうか。

      ロス率によく注目されてしまうようなのですが、僕自身はRTTの変化により注目しています。(恐らく)繁忙期であるPM9時台の方がそれより混雑は緩和されていたであろうAM2時台の方が軋轢していそうだという点です。その指摘ではこれが説明できないと思うのですよ。もっとも表面上に現れていない何らかの理由が別にある可能性もありますが。

      1. sshでログインできるホストがあるのであれば、tcpdumpでTCPパケットのシーケンスを見るというのはいかがでしょうか?TCPパケットを眺めていると再送がわかります。とはいえ、tcpdumpで生で眺めるのは難しいので-wオプションを利用してダンプ結果をファイルに保存してから、その保存ファイルをwiresharkで読み込んで解析するという方法もあります。

        ただ、測定したいのがどこなのかという問題もあります。
        電波の部分での品質問題とバックボーン部分の問題とを切り分ける方法に関しては、現時点で思いつきません。
        こういう計測って計測場所によってもかなり変わってしまうので結構難しいんですよね。。。

      2. 「キャリアグレードつまり公共インフラでも本当によくあることなのでしょうか」に答えてませんでした。すみません。
        私はキャリアやISPに勤めているわけではないので、現時点での設定詳細は知りませんが、利用しているルータにそのような機能は備わっているものと思われます。

        一昔前に、「tracerouteしたら最も遅かったのはIXだったから、きっと遅いのはIXに違いない!」というのがありました。
        ICMPの優先度を下げるのは良くある話だと思います。
        ただし、tracerouteの優先度を下げるのは、ICMP TIME EXCEEDEDを生成することでルータの脳みそを使ってしまうからなので、rate limitとは多少方向性が違うとは思いますが。

        1. バックエンドであればそれでいいんですが、フロント側で計測できないと今回は意味無いと思うのですね。やはり難しいでしょうね。
          繰り返しになりますが、本文でも述べているとおりICMPのロス率に拘っているのではありません。ICMPは制限されているかも知れないし、同じく制限されていないかも知れません。
          RTTの変動についてはどのようにお感じになられますか。

          1. 一般的にRTTの変動はキューにパケットが溜まっている状態や輻輳状態を意味することが多いのですが、ICMPを別枠で扱っている場合にはICMPだけのRTTが変動している可能性もあるので、TCPパケットによるRTTとICMPパケットによるRTTでは意味が変わって来る可能性もあると思います。

          2. なお、私が言いたいのは「ICMPでの計測は実体に沿わない場合があるのでTCPで計測すべきだと思う」ということであり、「ソフトバンクの回線品質は良いに違いない」と言っているわけではありません。

            携帯側のアプリで対応するのは難しいので、Webサーバ側でTCPでのパケットロス数を表示するようなWebアプリを作れば、ICMPで計測するよりかはもう少し状況がわかるようになりますかね。

          3. 拝見しました。
            こちらは相手先サーバーでの再送率ですよね。そもそもiPhone側で計測できなければあまり意味が無くないでしょうか(そもそも相手サーバーへ到達する以前の、iPhoneとキャリアネットワーク間の問題なので)。

          4. TCPは通信の両端が相互にパケット喪失数を認知しあう技術なので、片方のパケットダンプを全て見つつ再送回数を計測すると、もう片方でのパケット受信状況がわかります。

            もう一つのポイントとしては、ネットワークの両端はパケットが喪失した場所を特定することができないので、電波による通信時に喪失したのか、それとも光回線に入ってから喪失したのかは第三者はわからないのが一般的です。
            逆にいうと、この条件下では、どちらの側からTCPセッションを観測したとしても同じような結果になる筈です。

            ただし、上りトラフィックと下りトラフィックでスループットが違う可能性があるので、どちらからどちらに向けてトラフィックを多く流すかで性能が違うという結果はあり得るかも知れません。

          5. iPhone再起動後、ブラウザで数ページ表示させてnetstat取ってみました。
            以下、生ログですが、やはり再送多くないでしょうかね。

            iPhone3GS:/var/mobile root# netstat -s
            tcp:
            2975 packets sent
            823 data packets (127194 bytes)
            47 data packets (22945 bytes) retransmitted
            0 resends initiated by MTU discovery
            1670 ack-only packets (30 delayed)
            0 URG only packets
            0 window probe packets
            166 window update packets
            269 control packets
            2831 packets received
            1083 acks (for 127551 bytes)
            194 duplicate acks
            0 acks for unsent data
            1562 packets (1037894 bytes) received in-sequence
            74 completely duplicate packets (58068 bytes)
            0 old duplicate packets
            0 packets with some dup. data (0 bytes duped)
            66 out-of-order packets (87858 bytes)
            0 packets (0 bytes) of data after window
            0 window probes
            0 window update packets
            10 packets received after close
            0 bad resets
            0 discarded for bad checksums
            0 discarded for bad header offset fields
            0 discarded because packet too short
            156 connection requests
            1 connection accept
            0 bad connection attempts
            0 listen queue overflows
            157 connections established (including accepts)
            137 connections closed (including 17 drops)
            0 connections updated cached RTT on close
            0 connections updated cached RTT variance on close
            0 connections updated cached ssthresh on close
            0 embryonic connections dropped
            1048 segments updated rtt (of 1017 attempts)
            112 retransmit timeouts
            0 connections dropped by rexmit timeout
            0 persist timeouts
            0 connections dropped by persist timeout
            0 keepalive timeouts
            0 keepalive probes sent
            0 connections dropped by keepalive
            0 correct ACK header predictions
            1301 correct data packet header predictions
            16 SACK recovery episodes
            0 segment rexmits in SACK recovery episodes
            0 byte rexmits in SACK recovery episodes
            22 SACK options (SACK blocks) received
            44 SACK options (SACK blocks) sent
            0 SACK scoreboard overflow

          6. TCPコネクション数が157で受信パケット数2831とあるので、ファイルサイズが小さな画像が複数含まれるWebを開いて細かいTCPセッションを複数張ったような状況だろうと推測します。これだとack数が多くなっても不思議ではないので、この実験方法+netstat結果だけからは何ともいいようがない気がします。

          7. 注目すべきは、156 connection requestsに対する112 retransmit timeoutsなのでは?

          8. 157 connections established (including accepts)
            137 connections closed (including 17 drops)

            とあるので、いくつかのコネクションが正常に閉じずに残った結果timeoutが発生している可能性もありそうなので、その数だけだと何とも言えない気がします。
            サーバ側でのtcpdumpで見れば実際にパケット喪失による再送であるかどうかが解ると思います。

            あと、もう一つ気になるのが、
            2975 packets sent

            112 retransmit timeouts
            だとTCPで7割以上の喪失という結果にならなそうなところです。

          9. パケット喪失率70%に誰も拘っていないのですが(笑)、端的に言って156セッション中112回の再送要求が出ることは特に問題でも何でもないというお考えでしょうか。
            これについてはもう少し後で再テストすると差異がはっきりするかも知れませんね。
            なお同タイミングで「iPhoneで」取得したtcpdumpファイルです。これも生で置いておきますね。
            http://www.rocaz.net/junk/wwwrocaz2.pcap

          10. tcpdumpデータありがとうございます。拝見しました。確かに通信中にTCP retransmitが発生しています。

            TCPはパケットを喪失させながら自分にとって最適な通信量を測って行くという輻輳制御機構があるので、TCPの再送が発生することそのものは自然なことなのですが、その回線に対して発生割合が健全であるかどうかに関しては、残念ながらちょっとわかりません。
            その辺に関しては、可能な限り似た条件でドコモ回線とソフトバンク回線で比較するのが良い気がします。
            SIMカードを変更して同一機種で試されているので、両方のキャリアでTCPでの測定を行われると良いデータになると思います。

            tcpdumpデータを拝見する限り、ある程度まとまったところで一気にパケロスが起きている感じがするので、何らかの他のバーストトラフィックと競合してる可能性もありそうですね。
            気になるのが、HTTP GETを含むTCPセッションの一番最初のパケットが良く落ちている点ですかね。

            p.s. 「7割」に関してはICMPとTCPでの測定結果の差に関してという意味だけです。紛らわしくてすみません。

          11. なるほど。貴重なご助言ありがとうございます。
            今確認したところ、既にSB回線でICMPロスは既に発生しなくなっていたので、ドコモとの比較は明日以降の方が良さそうですね。
            僕も必ずしもICMPとTCPのポリシー一致に拘っているのではなく、RTTの変化を根拠に何らかのトラフィックポリシー変更が意図的に行われているのでは?という疑問です。
            ICMPロスが無くなったと言うことは、現時点でこのポリシーが変更された可能性があるので、再度同一テストを行ってみますね。
            いろいろと検証頂いてありがとうございます。

          12. 結構長い時間ネットモヒカン状態になってしまって恐縮です。。。(^_^;)

            ICMPのロスに関してですが、他の誰かが同じ回線上でICMPを流しているタイミングと被ると今回計測されたような結果になる可能性があります。
            たとえば、このブログを読んで「試してみよう」と思った人が同じ中継機器(ルータやその他機器)を経由するICMPトラフィックを流している可能性もあります。

            昨年7月のJANOGでの発表資料中(20ページ)を見ると、icmp rate-limitのデフォルト値として500msecに1つとか、100msecに一つという例が紹介されています。
            http://www.janog.gr.jp/meeting/janog26/program/fallback.html

            こういう設定が行われていれば、数人が1秒に一回のpingをするだけで競合してしまう可能性があります。

            ただし、何のために通過するICMPパケットに対する制限をしているのか、色々考えているうちに合理的な理由がわからなくなりました。
            ソフトバンクの人は、何の目的があってICMPへの制限をしてるのですかね????

            あと、繰り返しになってしまって恐縮ですが、TCPでの性能比較であれば有用なデータになると思うので、続編楽しみにしています!

          13. 最後に一つ。先ほどからTwitter上で「何故ICMPを制限」というような話題で話をしていたのですが、その過程で以下のような話になりました。

            1. ICMPはpacket per secで制限しているのではないか?
            2. tcpdumpデータを拝見するとTCPセッションの最初のデータパケットであるHTTP GETを含むものが再送されることが多いので、TCPはTCP session数で制限しているのではないか?

          14. なるほど、そういう推奨設定があるのですね。ただ時間帯により挙動が大きく変わるので完全に否定は出来ませんが(確立統計的に)その線は薄いのではないかと感じます。
            TCPとICMPの制御ポリシーは同意です。キャリアグレードルーター性能とかを考えるとセッション数に依存して捨ててしまうと言うのは説得力があると思います。

            ICMPとTCPの違いは置いておいて、僕はRTTの結果からは時間帯によりバックボーン若しくは3Gネットワーク軋轢を回避するため、様々なインカミング・パケットに制限をかけているのだと推測しました。まだ万人を納得させるデータにはなっていないと思っていますが、ICMPもとりあえず巻き込んでおいた、というのは安直でしょうか。

            こちらこそ遅くまでお付き合い頂きありがとうございました。感謝。

          15. 「最後に一つ」と書いた後でアレですが。。。

            tcpdumpデータにTCP Dup Ackが大量に発生しているのが何か凄く目立つのですが、これって間に何らかのTCPセッション数制限もしくは通信を遅延させたりする機器がありそうですね。

          16. 僕も気になっていました。
            どういう意味かは分からなかったのですが、そういう可能性があるのですね。なのでduplicateするわけですか、なるほど

          17. 横から失礼します。

            両端のホストのTCPの実装がSACKをサポートしていない限り、受信したパケットのシーケンスNo.が連続していなければ、Dup ACKを返すような仕様になっているはずです。
            なので、Dup ACKsが連続して出ているというだけでは、単に送信パケットが棄却されたということで、それ以上の深い意味はないはずです。
            Dup ACKsを3つ続けて受信すると、パケットが相手に届いていないと判断して、パケットを再送します。
            その間に受信したデータはバッファされているので、再送パケットを受信すると、バッファされているデータも合わせてACKを返します。

        2. 念のためですが、tracerouteの例は「良くある勘違いとして」という意味です。
          自分の文章を見直してみて、誤解を与えかねない表現だったと思い始めました。。。(^_^;)

  6. ロス率が高くてもラウンドトリップが悪化しないこともあるんですね。

    経験上、混雑する時間帯ではRTTが数十秒をに達することも少なくありません。
    そういったときは不思議とパケットロスが50%程度だったりしますが…。

  7. パケットロス率が高くてもRTTがそれほど悪化していないこともあるんですね。

    経験上、混雑する時間帯では周期的に非常に遅くなることがあり、そのときのRTTは数十秒になることもしばしばあります。
    そういったときのパケットロスは不思議なことに50%程度だったりします。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください