ISP は深刻な性能問題を隠してきた? 62
ストーリー by reo
P2Pアプリ全般の話ではないのかな 部門より
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 に実装されるまでには時間がかかるだろうとのことである。
queue アルゴリズム (スコア:5, 参考になる)
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)
Re: (スコア:0)
速度差が存在するネットワークで発生する問題だと言うのもポインとだと思う。
世界的に回線が逼迫してきて (スコア:3)
ようやく問題箇所を潰していこうということでしょうか。
無駄な通信が少しでも減るといいのですが。
# この書き込みも無駄なので本当は書き込まないほうがネットワークには優しいのかな
Re: (スコア:0)
IPv4アドレスが枯渇して1年以上もしてようやくボチボチと置き換え始めてるという始末ですよ。それこそ「5年前には解決されるべきことだった」。
一事が万事この調子の泥縄の塊。
Re: (スコア:0)
様々な指摘や苦情が出ているのに重大な事故が起きない限り後回しだったり、目を向けない、隠蔽するってのは社会の常ですね
Re: (スコア:0)
ISPエッジとユーザ側ルータのキューに適切な空きがある状態を維持できれば、
(BitTorrentみたいに)帯域を使うアプリでISPの提供できる帯域が埋め尽くされ
ても、(他のセッションでの)遅延増加・廃棄といった性能低下は少ないはず。
そのためによりスマートな輻輳制御(キュー遅延ベースでのパケット廃棄？)を
実装しよう。ということなんでしょうか。
…どうだろう。設備(特にエッジやユーザの)を置き換えるソリューションが、
どんどん普及するとは思えない。というか現状だとREDすら使われてないような
気がするんだけど、中の人教えてくれないかな。
Re:世界的に回線が逼迫してきて (スコア:2)
>ISPエッジとユーザ側ルータのキューに適切な空きがある状態を維持できれば、
>(BitTorrentみたいに)帯域を使うアプリでISPの提供できる帯域が埋め尽くされ
>ても、(他のセッションでの)遅延増加・廃棄といった性能低下は少ないはず。
>そのためによりスマートな輻輳制御(キュー遅延ベースでのパケット廃棄？)を
>実装しよう。ということなんでしょうか。
原文を読む限り、そういう話では無いと思います。問題とされているのは(そして解決可能とされているのは)、ユーザ間の帯域公平ではなく、一人のユーザの通信における TCP Window サイズとバッファ長とのミスマッチです。
詳細は http://queue.acm.org/detail.cfm?id=2209336 [acm.org] のあたりをどうぞ。
Re: (スコア:0)
Linux 3.5の実装だと、公平性確保のFair Queue(FQ)と組み合わせることもできるようです (fq_codel)。
とはいえハッシュを使っているため、運悪いと混んでる所に衝突しますね多分。
Re: (スコア:0)
ルータのバッファにたまりはじめると、パケットの到着が少しづつ遅くなるので、
(パケットロスによる検知をかける前に)この事実を検知して輻輳制御をかける方法も
あります。この方法だと、キューいっぱいまでたまらないので、遅延を短かくでき
ます。
CoDel AQMアルゴリズム (スコア:3, 参考になる)
詳細はこの辺に
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)
夜9時前後とか酷い遅延するんですけど（DTIのホームページでpingが1秒とかw）、これで直ったりするんですかね？
Re: (スコア:0)
直りませんね。
遅延は小さくなりますが、廃棄(=Pingのタイムアウト)が増えますね。
結局のところ、ISPはユーザーがお金を払ってくれるものを提供するわけで、
「うちは賢いキューイングでQoEが高いのです！」と力説しても、
それを理解できるほど消費者は賢くなく、当然賢いキューイングに対して追加料金を
取ることもできず、投資は回収できないので、積極的に設備更改するインセンティブには
ならないですね。
今のルーターのEOL/EOSが見えてきたときに、安ければ考えてみるか、
ぐらいにしかならんでしょう。
Re: (スコア:0)
スループットは低くなりますが、直るはずです。
そもそも (スコア:0)
電話に端を発した不特定利用者間通信網は、加入者全員が同時に通信を行うことはない。という仮定の上に成り立っているものであり、
その仮定が実情にそわなくなったのだから網としてはもう成立しない訳です。
＃おやぢギャグです。
Re:理由が何であれISPは十分な設備を準備しているのか疑問 (スコア:1)
Re: (スコア:0)
>お客さん！それならば、それなりの額をいただかないとなりませんが、よろしいですか？
最大値を保証しろと言ってるんじゃなくて
実勢値と保証値示せって言ってるだけでしょ
価格上げなきゃならん理由など微塵もない
Re: (スコア:0)
保証値があるならベストエフォートとは言わないのでは？
保証して欲しいなら、そういう契約を結ばないと。
Re:理由が何であれISPは十分な設備を準備しているのか疑問 (スコア:2)
「ベストエフォート」を謳うなら、どのくらい努力しているか公表しても
ばちは当たらないよね、みたいな話だと思ったけど。
それがいやなら「ティーザー」型サービスとでも言っとけば。
Re:理由が何であれISPは十分な設備を準備しているのか疑問 (スコア:2)
> 「ベストエフォート」を謳うなら、どのくらい努力しているか公表しても
> ばちは当たらないよね、みたいな話だと思ったけど。
通信業者「これくらい努力してます」、ユーザ「努力が不十分だ」
みたいなやり取りするくらいなら、品質保証したほうが楽でしょ。
そもそも「ベストエフォート回線」というのは品質保証されている回線で
なされているほどの品質保持のための対策を行いませんってことを
婉曲的に表現している言葉だ。
まぁ、そんな誤解しやすい表現を使うのはおかしいって理屈はわかる。
現状の「ベストエフォート回線」の実態にあう別の呼び方を考えて
消費者庁にそれを通信業者に使わせるように提案してみたら。
Re:理由が何であれISPは十分な設備を準備しているのか疑問 (スコア:1)
Re:理由が何であれISPは十分な設備を準備しているのか疑問 (スコア:1)
Re: (スコア:0)
努力と保証は全然違う。
Re: (スコア:0)
いや「最大」って書いてるなら問題ないって理屈にならないか？ それ。「契約」を盾にするならそれこそそういう「契約」でしょ。
Re: (スコア:0)
契約者の環境で絶対に実現しない「最大」を表示してるのだとすれば詐欺だよね
意味の無い最大値を示すのではなくて実勢値が判断できる材料を提供するべきじゃないの
Re: (スコア:0)
その理屈でハブやスイッチ、Cat6のケーブル等々にも文句つけて歩いてくださいな。
# 消費者運動としてやるのは勝手だけど、/.のネタとしては不毛だなという感想。
Re:理由が何であれISPは十分な設備を準備しているのか疑問 (スコア:2)
局の中に入って各社のラックを見てみると、
普通にB社のコンシューマ向けHUBや、
Y社のローエンドルータが使われてましたよ。
この地域のユーザーのうち、たった1人しか通信してないなら
謳ってるパフォーマンスが出るのかな、と思いましたよ。
〜◍
Re: (スコア:0)
> 普通にB社のコンシューマ向けHUBや、
KDDIのラックですかね。
http://d.hatena.ne.jp/magisystem/20081117 [hatena.ne.jp]
Re: (スコア:0)
ラックの中には、通常稼働時には
別にそれほど重要でない機材やネットワークも多く入ってますよ。
特に遠隔地でもないロケーションの場合の
非重要管理系や商用試験環境、移行時利用機材などでは
「まあなんかあったら直接行く」
「平常時はそもそも閉息してる」とか
現実的によくあります。
もちろん利用者へのサービスレベルには影響ありません。
その辺見極めずに
ラックの中のものはすべて利用者を収容してる機材のはず、
とかだとさすがに素人すぎですね。
Re: (スコア:0)
自称技術者が知ったかぶりをしてプロを叩くのをニヤニヤしながら眺めるのが /.j の醍醐味なんですから、そういうツッコミは野暮ってもんですよ。
Re: (スコア:0)
そのサブ系とメイン系が安っすいルータ1台にぶら下がってたりするんだよ。
っていう突っ込みも野暮ってもんかな。
Re: (スコア:0)
>そのサブ系とメイン系が安っすいルータ1台にぶら下がってたりするんだよ。
>っていう突っ込みも野暮ってもんかな。
そういうのは、ソースを出さない/出せないなら野暮そのものですね。
涙目の中学生がウソで塗り固めた２Ｐプレイヤーやってるのと見分けがつかないでしょ？
Re: (スコア:0)
何で腐すのか判らないけど(業界の人？)無線LANルータなんかは箱に実効値を表示するようになってきたしそんなに大それた要求じゃないと思うけど。
しかしまあベストエフォートとか言って開き直るなんてずいぶん横柄な業界だな。鉄道や電力で同じ事やったらどうなってしまうだろうか。
Re:理由が何であれISPは十分な設備を準備しているのか疑問 (スコア:2)
> 鉄道や電力で同じ事やったらどうなってしまうだろうか。
単に「ベストエフォート」の通信回線は鉄道や電力ほどの必須インフラとして
提供されていないってことでしょ。
# まぁ、鉄道や電力をとりあげてるのは話の流れでそうなってんだろうけど。
Re: (スコア:0)
鉄道も電気も同じでしょ。
遅延したり停電したりしても開き直るだけで、払い戻ししてくれるわけでもない。
保証が欲しければお高いサービスを買え、というのも一緒。
Re: (スコア:0)
完全な100%じゃ無けりゃ全部同じだってのは幾らなんでも乱暴。程度の問題だよ。
電車の定時運行や電力の安定供給がネットと同じくらいの『ベストエフォート』だなんて本気で思ってないですよね？
ネットの速度低下が人身事故の遅れと同じくらいの発生頻度なら誰も文句を言わないよ。ただの一度も出ない値を平然と載せるのはモラルが無さ過ぎるでしょ。
消費者庁辺りが動いてWebに実績値を載せるように義務付けるとかすれば真っ当な競争になるんだろうけど。しこたま儲けてるんだからしっかり設備投資してくれないとね。
Re: (スコア:0)
> 電車の定時運行や電力の安定供給がネットと同じくらいの『ベストエフォート』だなんて本気で思ってないですよね？
かけてるエフォートは同じくらいですね。
もしかして、同じエフォートをすれば通信でも電車でも電気でも同じ稼働率が出ないとおかしいと思ってる？
Re: (スコア:0)
>契約者の環境で絶対に実現しない「最大」を表示してるのだとすれば
偶然その地域の人の大部分が通信していない「隙間」の瞬間に当たれば、その最大値（に近いもの）が実現できたりはしないの？
最大**Mbpsって書いてて装置そのものがそれ以下でしか動かないんなら駄目だろうけど、運が良ければその値が出る、ってんならありかもよ？
Re:理由が何であれISPは十分な設備を準備しているのか疑問 (スコア:1)
いや、どことは言わないけど某社はバックボーンで帯域絞ってるから前提として広告されてる速度は理論値環境でも出ない。
Re: (スコア:0)
そんなのもあるのか……
それは明らかにアウトだよなあ。
Re: (スコア:0)
少なくとも、たった一度の偶然や作為であってもその最大速度(に近いもの)の実現を証拠として提示できなければ、
詐欺呼ばわれも仕方無い気がするな。
まあウソとは言い切れないけれど、それを言ったら根拠のない「最大xxxTbps」もアリになっちゃうわけだし。
Re: (スコア:0)
実際には訴えるメリット、調査能力、コストもさほど無いであろうけど、訴えられたら負けるってところ多そうだな
Re: (スコア:0)
>実現
サービス開始時で、ユーザーもほとんどいない状況なら可能かも……
それか、無線系の実験はやってるだろうから、そういう時の速度とか。
謳い文句は、「（他のユーザーが誰も使っていなければ）最大○○Mbps！」
……まあ、嘘ではない。
Re: (スコア:0)
いや、根拠のない「最大xxxTbps」はウソだから、ナシだろ？ その差がわからない程度のアタマでは何いっても無駄だと思うぞ。
Re: (スコア:0)
おかげでLTEは従量制料金が常識になりそうですよ。よかったですね。
Re: (スコア:0)
パケットロスが出まくりで使い物にならない回線品質に、クレームを入れると
「ベストエフォートなので保証はありません。パケットロスの比率をきめたSLAもありません。」
と言われて愕然としたことがあります。
ベストエフォート＝品質保証なし と勘違いしているキャリアが多いらしい。
Re: (スコア:0)
> ベストエフォート＝品質保証なし と勘違いしているキャリアが多いらしい。
君のベストエフォートの定義って何？
Re: (スコア:0)
君のベストエフォートの定義って何？
Re:理由が何であれISPは十分な設備を準備しているのか疑問 (スコア:1)
> 速度はでなくてもいいので、パケットロスが出まくりで通信ができないレベルの回線はいらないってことです。
そういう独自定義を使う場合は「ベストエフォート」の様な一般的な単語ではなく「俺様の定義するベストエフォート」と書いてくれると助かる。
Re: (スコア:0)
ベストエフォート＝品質保証あり と勘違いしているクレーマーが多いらしい。