パスワードを忘れた？ アカウント作成
Close
3746000 story
ネットワーク

ISP は深刻な性能問題を隠してきた? 62

ストーリー by reo
P2Pアプリ全般の話ではないのかな 部門より

ある Anonymous Coward 曰く、

ISP は深刻なネットワークの性能問題を隠し、その原因を誤診してきたという話が取り上げられている (jg's Ramblings の記事より) 。

ISP は、通信性能悪化の原因を BitTorrent によるものであるとしてきた。しかし、性能低下の本当の問題はバッファー肥大化によるものである、と記事は指摘する。バッファー肥大化は単純な TCP による単一ファイルのコピーでも起きる上、TCP だけでなく UDP などの他のプロトコルでも簡単にバッファーを満杯にすることができるらしい。BitTorrent 登場以前からインターネットのエッジ (ルーター等) は壊れており、たくさんの制御不能なバッファ処理で溢れかえっているとのこと。

筆者はこの問題は本当は 5 年前には解決されるべきことだったとし、解決に時間がかかった原因を探り、次に「悪夢」が起こったときに同じ事を繰り替えさないためにはどうすればいいかを問いかけている。なお、バッファー肥大化の対策である CoDel AQM algorithm は Linux kernel 3.5 に搭載される予定 (jg's Ramblings の記事) 。実装が複雑であるため、他の OS に実装されるまでには時間がかかるだろうとのことである。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

ISP は深刻な性能問題を隠してきた? More

  • queue アルゴリズム (スコア:5, 参考になる)

    by thorin (14200) on 2012年06月05日 19時19分 (#2167450)
    ちょっと軽い感じで解説してみる。間違えてたら訂正よろしく。

    Internet (パケットネットワーク)の仕組としてバースト時のパケットロスをなくすためにキューにバッファリングする仕組みがある。バンド幅の向上に合わせてこのキューもどんどん大きくなって来ているが、単にそれだけではなく、パケットロスは少なければ少ないほど良いと勘違いしたものか、大は小を兼ると思い込んだのか無闇やたらバッファーがでかくなる症状が流行っている。

    ところがキューを大きくすると確かにパケットロスは減るが、大きくすればするほどパケットの遅延が酷いことになる。パケット遅延は別にリアルタイムゲーム等でのみで必要な要素ではなく、混雑時のデータ転送速度に大きな影響を与える。単に帯域幅が広いだけじゃ駄目なのである。

    特にTCP通信においては致命的。TCP通信には輻輳回避機構があってパケットロスを検知して、最適な通信速度を探す仕組みがあるのだが、パケット遅延が大きくなるとこの仕組みがうまく働くなる。具体的にはネットワークが混雑していてもキューで処理している期間はパケットロスが発見できないため輻輳の検知が遅れ、必要なタイミングからかなり遅れて送信制限がかかることになる。その時点ではもはや間に合わず通信が完全停止するくらいまで減速されてしまう。そして通信を再開するがその時にはキューが空いているので全力で送信してしまい輻輳させてしまう。車に例えるならばアクセル全開と急ブレーキを交互に踏んでいるような状態であり、実際の帯域幅を有効に使えない。

    この問題は古くから知られているが、あんまり対策が進んでいない。対策としてキューの管理をもっと賢くする AQM (Active Queue Management)というものがある。

    比較対象として普通のキューの Tail Dropping 方式をまず説明する。この方式は単純にキューがいっぱいになったら、それ以後の新たなパケットを破棄するという方式である。Linux をはじめとする各OSやルーターやスイッチのキューもデフォルトではこの方式である。この方式はキューが大きくなるとディレイが長くなる。キューに滞留している時間はパケットロスを検知できないという欠陥がある。

    AQM の代表的な例として RED (Random Early Detection/Dropping) 方式がある。この方式はキューの埋まり具合に応じて、キューが一杯になる前にランダムにパケットのドロップし始める。キューが一杯になる前に輻輳が検知できるためにTCPの輻輳検知が有効に働く。Linux や Cisco や Juniper のルーター等にはこの設定ができる。この方式の欠点としてドロップ率等のパラメータを手作業できちんとチューニングしてやらなければならい点がある。落とし過ぎると帯域が埋まる前に輻輳制御してしまうし、落とし方が足りないと結局キューに溜って遅延が長くなる。このような性質のため帯域幅が動的に変化するような環境で使用するのが困難であり、そもそも設定が面倒なので固定幅に帯域制限しているような場合以外ではあまり使われていない。

    そして今回話題に上がっているのは新しい AQM 方式の CoDelである。この方式はざっくり説明すると、パケットがキューに滞在している時間を調べて長時間キューに滞在しているパケットは片っ端からドロップするやり方。時間がパラメータになっているので帯域幅が変動してもパラメータは同じで良いし、パケットのキュー滞在時間は変化しないのでキューも大きくならず輻輳検知にも影響しない。細かい調整無しで使えるのでデフォルトの Tail Dropping 方式を置きかえてることができるはず。

    # Linux 3.5 ってどんだけ先なんだと一瞬思ったけど手元のマシンが Linux 3.4 だった。順当に行けば来月くらいかな。
    # でも、この方式がルーターに実装されて各ISP等に配備されるには5年単位の時間がかかりそうだ。

    • Re:queue アルゴリズム (スコア:2)

      by saitoh (10803) on 2012年06月06日 0時09分 (#2167591)
      「この問題は古くから知られているが、あんまり対策が進んでいない。」のかぁ。 僕が学生時代に既にREDの論文はいっぱい出たたので、それから20年たつ現代ではREDあたりはたいていのバックボーンルータに入ってると思ってた。
      シェア
      親コメント

    • Re: (スコア:0)

      by Anonymous Coward

      速度差が存在するネットワークで発生する問題だと言うのもポインとだと思う。

  • ようやく問題箇所を潰していこうということでしょうか。
    無駄な通信が少しでも減るといいのですが。

    # この書き込みも無駄なので本当は書き込まないほうがネットワークには優しいのかな

    • Re: (スコア:0)

      by Anonymous Coward

      IPv4アドレスが枯渇して1年以上もしてようやくボチボチと置き換え始めてるという始末ですよ。それこそ「5年前には解決されるべきことだった」。
      一事が万事この調子の泥縄の塊。

      • Re: (スコア:0)

        by Anonymous Coward

        様々な指摘や苦情が出ているのに重大な事故が起きない限り後回しだったり、目を向けない、隠蔽するってのは社会の常ですね

    • Re: (スコア:0)

      by Anonymous Coward

      ISPエッジとユーザ側ルータのキューに適切な空きがある状態を維持できれば、
      (BitTorrentみたいに)帯域を使うアプリでISPの提供できる帯域が埋め尽くされ
      ても、(他のセッションでの)遅延増加・廃棄といった性能低下は少ないはず。

      そのためによりスマートな輻輳制御(キュー遅延ベースでのパケット廃棄？)を
      実装しよう。ということなんでしょうか。

      …どうだろう。設備(特にエッジやユーザの)を置き換えるソリューションが、
      どんどん普及するとは思えない。というか現状だとREDすら使われてないような
      気がするんだけど、中の人教えてくれないかな。

      • >ISPエッジとユーザ側ルータのキューに適切な空きがある状態を維持できれば、
        >(BitTorrentみたいに)帯域を使うアプリでISPの提供できる帯域が埋め尽くされ
        >ても、(他のセッションでの)遅延増加・廃棄といった性能低下は少ないはず。
        >そのためによりスマートな輻輳制御(キュー遅延ベースでのパケット廃棄？)を
        >実装しよう。ということなんでしょうか。

        原文を読む限り、そういう話では無いと思います。問題とされているのは(そして解決可能とされているのは)、ユーザ間の帯域公平ではなく、一人のユーザの通信における TCP Window サイズとバッファ長とのミスマッチです。
        詳細は http://queue.acm.org/detail.cfm?id=2209336 [acm.org] のあたりをどうぞ。

        シェア
        親コメント

        • Re: (スコア:0)

          by Anonymous Coward

          Linux 3.5の実装だと、公平性確保のFair Queue(FQ)と組み合わせることもできるようです (fq_codel)。
          とはいえハッシュを使っているため、運悪いと混んでる所に衝突しますね多分。

        • Re: (スコア:0)

          by Anonymous Coward

          ルータのバッファにたまりはじめると、パケットの到着が少しづつ遅くなるので、
          (パケットロスによる検知をかける前に)この事実を検知して輻輳制御をかける方法も
          あります。この方法だと、キューいっぱいまでたまらないので、遅延を短かくでき
          ます。

  • CoDel AQMアルゴリズム (スコア:3, 参考になる)

    by Anonymous Coward on 2012年06月05日 12時59分 (#2167193)

    詳細はこの辺に
    Controlling Queue Delay - ACM Queue
    http://queue.acm.org/detail.cfm?id=2209336 [acm.org]

    ついでに本家スラドの記事も
    Controlling Bufferbloat With Queue Delay
    http://tech.slashdot.org/story/12/05/09/0325228/ [slashdot.org]
    いくつかのコメント抜きだし
    >遅くなるのではなく、ラグくなるのだ
    >大きなバッファはスループットを上げるが、レイテンシを悪くする。バッファが大きすぎるのが問題。
    >ISPは同等の機能をメーカーに要求している。私はパケット処理チップにRED (Random Early Detection)処理を実装していた。
    >彼らはバッファを増やしてパケットロスを最小にしようとした。結果、ユーザーエクスペリエンスはおぞましいものに…。

  • 家のISP(DTI)なんですけど (スコア:0)

    by Anonymous Coward on 2012年06月05日 20時49分 (#2167492)

    夜9時前後とか酷い遅延するんですけど（DTIのホームページでpingが1秒とかw）、これで直ったりするんですかね？

    • Re: (スコア:0)

      by Anonymous Coward

      直りませんね。
      遅延は小さくなりますが、廃棄(=Pingのタイムアウト)が増えますね。

      結局のところ、ISPはユーザーがお金を払ってくれるものを提供するわけで、
      「うちは賢いキューイングでQoEが高いのです！」と力説しても、
      それを理解できるほど消費者は賢くなく、当然賢いキューイングに対して追加料金を
      取ることもできず、投資は回収できないので、積極的に設備更改するインセンティブには
      ならないですね。
      今のルーターのEOL/EOSが見えてきたときに、安ければ考えてみるか、
      ぐらいにしかならんでしょう。

    • Re: (スコア:0)

      by Anonymous Coward

      スループットは低くなりますが、直るはずです。

  • そもそも (スコア:0)

    by Anonymous Coward on 2012年06月06日 5時41分 (#2167627)

    電話に端を発した不特定利用者間通信網は、加入者全員が同時に通信を行うことはない。という仮定の上に成り立っているものであり、
    その仮定が実情にそわなくなったのだから網としてはもう成立しない訳です。

    ＃おやぢギャグです。

typodupeerror

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson