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

1. ピンバック: ソフトバンクのパケロスが酷いのは都内だけじゃなかった | だいすけのブログ

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

   返信

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

      返信

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

   返信

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

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

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

   返信
5. ピンバック: links for 2011-06-20 « 個人的な雑記

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

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

   返信

7. 実験を行うのであれば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. はじめまして。
               あきみちさんの仰っていた、tcpdump + Wireshark の方法で検証してみました。

               http://blog.kenichimaehashi.com/?article=13085761170

               この結果から自分で理解した範囲では、やはり ICMP だけ意図的に落としているのかなという印象です。

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

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

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

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

            6. 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

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

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

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

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

               あと、もう一つ気になるのが、
               2975 packets sent
               で
               112 retransmit timeouts
               だとTCPで7割以上の喪失という結果にならなそうなところです。

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

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

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

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

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

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

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

                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での性能比較であれば有用なデータになると思うので、続編楽しみにしています！

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

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

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

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

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

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

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

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

            18. 横から失礼します。

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

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

            返信

8. a

   返信

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

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

   返信

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

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

    返信

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