アカウント名:
パスワード:
技術的には革新
確か、『QoSなんぞやっている暇があったら、回線をジャブジャブ引いたほうがよほどよい。QoSはコスト的に見てもやるだけ無駄』
「回線をジャブジャブ引いてもQoSの確保は難しい」というのが、QoS技術の原点のはずなのですがね。
（特にNTTの）研究所の方々にはコストの概念とビジネスセンスがないものですから。
最適解を出すためにはO(2^n)の計算漁を必要とする
単なる帯域確保でこんなに計算量が必要ありません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
消費者からみて、 (スコア:3, すばらしい洞察)
技術的には革新なのかも知れませんが、それを使う消費者にとって
うれしいことが何なのかわからない技術、という意味ではキャプテン
システムと同根かもしれませんね。
Re:消費者からみて、 (スコア:2, 興味深い)
確か、『QoSなんぞやっている暇があったら、回線をジャブジャブ引いたほうがよほどよい。QoSはコスト的に見てもやるだけ無駄』という研究結果が「NTTの研究所から」出てたような記憶があるんですが。
NGNの何がどう革新なんだかさっぱりわかりません。
fjの教祖様
Re:消費者からみて、 (スコア:1)
「回線をジャブジャブ引いてもQoSの確保は難しい」というのが、QoS技術の原点のはずなのですがね。
現実には、プロバイダがP2Pのトラフィックを絞っている話があります。これは、優先制御（QoSの一歩手前）の一つの応用と見なせます。この事例は回線をジャブジャブ引くことの限界と、QoS制御の有効性を証明していると思います。
QoSも良いですが、マルチキャスト技術の方が、世間に与えるインパクトは大きいのではないかと個人的には思っています。
Re:消費者からみて、 (スコア:1)
『回線をジャブジャブ引いても QoSの確保は難しい』ではありません。そんな馬鹿な話はありえない。それはRTOSとスループット優先OSとの違いと同じ。問題は『ジャブジャブ量』の持つべき性質を適切に考えるかどうか。
あるリクエストがあってから1us以内に3k命令を実行する必要がある処理があるとしましょう。ソフトDVDプレイヤーとかってようするにそういう処理を必要とします。そのようなプログラムを10個同時に動かしたい。ただし、リクエストはプログラム1つにつき1秒に1回程度しか来ない。
通常のPCは、1us以内に3k命令を実行する…つまり3Gipsの計算処理能力は普通に持っている性能でしかありません。つーか、いまどきのPCは12Gips以上ある。また、単純に考えてリクエストは1秒に10回しか来ない。必要な計算量は30k命令/secでしかない。これなら、12Gipsのプロセッサには楽勝で処理できるはずです。
しかし、そのようなリクエストが10個同時に発生してしまうと、その1usec以内に処理しなくてはいけない計算量は30k命令になります。この瞬間だけ30Gipsの計算量が必要になる。
『回線をジャブジャブ引いても…』と思っている人は、12Gipsのプロセッサがある事を「十分」としている。この場合、リソースの衝突が起こるからそりゃQoS確保は難しいでしょう。
この場合必要なのは12Gipsのプロセッサ1個ではなく、3Gipsのプロセッサ10個です。「10個必要なのに1個しか用意しないで、なにが『ジャブジャブ』か」というのがポイント。
----
ネットワークの QoS 問題もこれと一緒。帯域幅と経路遅延等をまぜこぜに考えるのがおかしいだけ。
特に日本では非常時の回線確保が業務の一部となっているため、HA確保のための冗長性が必要になります。これを念頭に置くと、「冗長性のための複数経路確保」という名の「本数ジャブジャブ」が必須になります。ここをケチろうとして、ややこしい制御をしようとするから問題が複雑になりNGNなどと言いたくなる。
アナロジーで言うなら、人間のように脳に一極集中させたら、脳の破綻一撃で全系が破綻する。ヒトデのように分散制御させるのがHA的に見て基本。その上でQoSを考える必要がある。この場合重要なのは「仮想化されていない、実本数としての回線数」と「ノード間直接連結数」が大事。
NGNは人間の脳と一緒。ネットワークに機能を載せすぎて、「見かけのコスト」が低いように見えて「実質コスト(特に異常時コストと、異常時の発生確率)」が爆発している。
fjの教祖様
Re: (スコア:0)
真剣にQoSやってる人を何人も見たけど、かける言葉も見つかりません
Re: (スコア:0)
＃だからこそ、研究所にしかいられないという面もあるが
Re:消費者からみて、 (スコア:1)
そうは思わんがね。
どちらかというと、NTTの人達には「根本的に」コストセンスもビジネスセンスもない。研究所に限る必要はなく。
そういう世界では、逆に分散幅が最大である研究員が、「コスト的に引き合わない」と計算して出した結果が最もあてになる。
実際問題として。QoSというのは「ネットワーク」上におけるリアルタイムリソース配分問題の1種だ。これをCPUやメモリ対して適用すると『リアルタイムOS』の制御問題になる。数学的には完全に等価な問題であり、完璧な解は「いかなる要求に対しても十分なリソースがある場合」にしか存在しない事は自明に属している。
つまり、QoSに対する究極の解は「QoSなんぞ必要としないぐらい、太い回線を並列で何本も走らせろ」になる。そして、ネットワークにおいて、回線をたくさん走らせるコスト増大速度は最大でも O(n)に過ぎない。一方で、QoSにおいてはネットワークの各ノード(リーフノードだけではなく、中間ノードも含めた全てのノード)において、最適解を出すためにはO(2^n)の計算漁を必要とする(普段はそこまでの計算量は必要としないが、その結果得られるのは所詮近似解な上に、それでもO(n*logn)を下回る事はありえない)。
つまり、QoSはそもそもノード数が一定を超えるとコスト破綻を起こすようにできているのだ。ネットワークを「バックボーンモデル」などの障害に著しく弱い構造にするならばともかく、生活のバックボーンとして High Availability を提供する事を考えるならば(つまり、性能ががたがたになる事はあっても、ちょっとやそっとでは停止する事はない、という属性を必須とするならば)、QoSはコストを「計算量的に」見る限り全く引き合わない。
もちろん。もしネットワークを1から作り直しているのであれば、定数項問題と言うのが発生しうる。nが物凄く小さい間はO(2^n)のアルゴリズムの方が、O(log n)のアルゴリズムよりもコストが小さい状態になりうる、というあれだ。しかし、NTTの場合は最初から巨大なnを相手にしなくてはいけない、という大前提がある。なのでnが小さい場合は全く考慮する必要は無い。
fjの教祖様
Re:消費者からみて、 (スコア:1)
O(n^2)の間違いでは。そう考えても、こんな計算量を必要とするのはルーティングぐらいです。単なる帯域確保でこんなに計算量が必要ありません。せいぜい、O(n)です。
巨大なネットワークでこそQoSが重要だと思います。経路上の1ノードでも帯域を確保出来なくなるとQoSは破綻するので、破綻のリスクは経路上のノード数乗のオーダO(X^n) で増加します。つまり、巨大なネットワークでこそ、QoS保証の仕組みが必要です。
リアルタイムOSを例に挙げておられましたが、コストがシビアな組み込み機器でこそリアルタイムOSが使われてます（安いCPU+リアルタイムOS）。
Re:消費者からみて、 (スコア:1)
失格。
『帯域確保』に必要なコストが O(n)ですむのは「リソースが十分にある」場合だけだ。
すでにある優先順位に従ってリソースが使われているときに、さらに優先度の高い要求が来た場合、
1) リソースを最高優先度のものに割り当て
2) はじき出されたものを迂回路に回す
3) それでも間に合わないものをサービス停止し、そのコスト請求を止める
というこの3段階を行う必要がある。
2以降のコストが洒落にならない。
回線利用率が50%を超えるまでは実は笑って済ませられるほど簡単な近似解で十分なのだが、50%を超えた状態を維持し続けたまま…と言った途端にオーダーが跳ね上がる。
HAを考えると、単純なバックボーンモデルはナンセンスだ(そして、NTTに対する非常時回線確保からも判るようにHA要件は義務だ)。必然的に迂回路の再計算が必要になるが、『迂回路側』でも同じような帯域確保が発生した場合に、解が振動したりしないアルゴリズムを採用する必要がある。
するといきなりO(n)ではすまなくなる。
これはある種の「神の目」を解く問題なので、計算量が単純であるためには、リソースが十分ある、という仮定がどうしても必要になる。しかしリソースが十分にあるなら、最初からQoSなんか心配する必要は無いのだ。
fjの教祖様
Re: (スコア:0)
やっぱりビジネスがわかってないようだ。
天から金が降ってくるとでも思ってるのかなぁ……