だから、QoSは要らない
―― 列車と自動車、そしてインターネットのQoS ――

常識で考えれば、インターネットにQoS技術を広く適用するのは不合理だ。単に、容量を増やす方が理に適っている。

ダン・ブリックリン

翻訳:翻訳工房 M
ご利用上の注意

はじめに

 どのようなアプリケーションでも、インターネット上で正常に機能するには、新しい QoS(Quality of Service)が必要になる。こういう話をよく聞く。正常動作には「特別なトラフィック」を特別に扱う必要があるという、漠然とした直感があるようだ。しかし、私が思うに、こうした考えには重大な欠陥がある。我々が必要とし、また依存しているアプリケーションにとって、QoSはインターネット環境を悪化させるだけではない。QoSが果たすとされていることさえ実現できないだろう。また、一見したところでは、QoSは直感的に必要だと思われるが、少し考えてみればインターネットの常識に反することがわかる。

何故、QoSか

 QoSを擁護する議論はいろいろとある。例えば、音声(音声は、引き合いに出されるアプリケーションの筆頭だろう)を扱うアプリケーションを巡って、IP接続にはよく知られた伝送遅延があるためにデータの送達が「保証」されず、そうしたアプリケーションのための伝送媒体として適切ではないという議論がある。しかし、「音声にはQoSが必要だ」という議論は、いささか直感的にすぎると思われる。「電話線による専用線では、QoSが確保されている――ご存じのとおり、通話上問題になるようなデータ喪失や遅延はない。だから、インターネットのような信頼性の低い接続で音声を伝送するには、それに相当する機能が必要になる」というのだ。また、「価値」を巡る議論もある。私の「価値ある」音声トラフィックが、巨大ファイルのダウンロード(多分、――事もあろうに――ネットワーク上で共有している音楽か、さもなければポルノ写真かだ)と対等に伝送路を共用するなんて、何という不公平だ。「良い」トラフィックは、優先されねばならない。電話やケーブルテレビに携わる人々は回線と価値ということを常に考えてきたから、この見方は理解できるだろう。

日常から学ぶ

 QoSという概念を理解するために、誰もがよく知っている身近な例、自動車と道路を考えてみよう。一車線の道路は回線のようなものだ。回線の場合はデータパケットが流れるが、道路の場合は自動車が走る。

 動力による輸送(列車)が始まった当時、輸送設備の中で、「道路」(線路)が最も高価だった。だから、列車を定刻に走らせるために、数々の時刻表が念入りに作られたのだ。時刻をたとえわずかでも変更しようとすれば、その影響は運行全体に及ぶほどだ。予定外の優先列車など、軽々に云々するようなものではなかったのだ。現代でも、都市部における公共交通は、微に入り細を穿った調整によって、同時に多くの列車を運行している。そこで大きな役割を果たしているのは信号だ。列車の間隔をできるだけ短縮し、可能な限り線路の利用率を大きくすべく貢献している。

 「道路外」に出ることのできる自動車が登場したとき、多様な自動車が道路を共用できるように、いろいろなルールが考案された。自動車がまだ少なかった頃は、それだけで十分だった。しかし、結局、二車線以上の道路が必要になった。複数の車線を用意すれば、運転者は車線を変更することで速度を選べ、簡単なルールだけでトラフィックを管理できるのだ。

 自動車交通には、緊急自動車の通行という、皆さんご存じのQoS問題がある。周知の通り、緊急自動車が近づいてきたら、一般の自動車は道を譲り、緊急自動車を通さなければならない。それでは、どのようにして緊急自動車であることを知るのだろうか。緊急自動車は警光灯を点灯しサイレンを鳴らしているから、これは極めて明白だ。「公認の」自動車だけに使用が許され、一般の自動車は使うことのできない、緊急自動車の合図なのだ。

バスが車線を変更する 消防車は通り過ぎる

 消防車が交差点を通過できるように、バスが車線を変更する。次いで、自動車が2台、空いている一方通行の道路の片側に寄り、消防車はサイレンを鳴り響かせながら通り過ぎる。

 さて、このルールは、どのように機能するのだろうか。まず、道路がガラガラなら、緊急自動車は何も特別なことをする必要はない。ひた走るだけで良い。このルールが活きるのは、道路が混み合っている場合だ。緊急自動車は十分な速度で走り、他の自動車(次にあの救急車に乗るのは自分かも知れないと考えている人、あるいは、パトカーが追いかけているのが自分でなくてホッとしている人の運転する自動車)はわずかに遅れるだけ。しかし、道路が渋滞している場合は、このルールは機能しない(渋滞しているトンネルを考えてみよ)。緊急自動車は、たとえ進めるとしても、他の自動車を避けながら進むことになり、せいぜい、「一般」車よりはマシという程度だろう。また、自動車がすべて緊急自動車なら渋滞してしまう。あるいは、「公認」されていない自動車が急を要する事態になった場合は、その前途は暗澹たるものだ。例えば、住居侵入に出動した警察官はよいが、心臓発作を起こした人を乗せて病院に急いでいる普通の車はダメだ。他にも問題がある。警察官はどのような場合に緊急自動車のサイレンを鳴らすことができ、どのような場合鳴らしてはいけないのか。何がしかを支払えば、優先されるべき特権を得ることはできるのだろうか。

 この簡単な考察から、単純な「緊急自動車QoS」アルゴリズムが機能する条件と特性が見えてくる。すなわち、社会にとって利益があると認められた場合にのみ適用されるべきこと。道路の容量が十分にある場合は不要であり、中程度の混雑であれば機能するが、渋滞している場合は有効性が低下する(ないよりはマシ)。しかも、トラフィック全体の中で、緊急性を要するものの割合がごくわずかな場合にのみ機能する。つまり、ほとんどが「緊急性あり」の場合や、激しい渋滞になっている場合には、機能しないのだ。

ラッシュアワー ラッシュアワー

ラッシュアワーのときは、自動車を寄せる余地もない。

 こうした特性をグラフで見てみよう。

QoSは、利用率が一定の範囲にあるときのみ有効

図1 QoS技術は、容量に対する利用率が一定の狭い範囲にあるときにのみ効果を発揮する

 これは、道路の建設費が高い都市部では、効果を発揮する。都市部の交通量は、一般に、このグラフの湾曲部を大きく超えることはなく、と言って、QoSアルゴリズムが不要なほどに閑散としているわけではない。さらに、一般の自動車に比べて緊急自動車の数は少なく、交通上の特権を利用するかしないかは、公共心を持つ訓練された人々が判断しているからだ。

 この「サイレンが聞こえ警光灯が見えたら、道路の片側に自動車を寄せる」アルゴリズムは、規模が大きくなるにつれ難しい点が出てくることに注意。現代の交通事情では、通常の速度で見通しのよい場合に有効だ。あるいは、のろのろ運転だが道を譲るための余地がある場合にも効果がある。交通密度の高い地域でこそ役に立つサイレンは高速道路ではさほどの効果はなく、警光灯はネオンサインの溢れる繁華街ではあまり役立たない。だから、緊急自動車はこの両方を使う(他にも、「緊急」の文字を鏡像にしたりする)。

インターネットの場合

 以上のQoSに関する考察をまとめてみよう。

 さて、インターネットに話を戻そう。自動車交通の場合とまったく同じように、容量が十分にあれば、QoS技術は不要だ。QoS技術が威力を発揮するのは、利用率はある程度あるが、しかし高すぎない場合だ。

 自動車交通の場合と異なり、パケットに優先権を与える方法については、ほとんど合意が得られていない。(医者からヘルプデスクへのインスタントメッセージは、優先すべきだろうか。あるいは、放射線医がMRI画像を送る場合はどうだろう。その重要性は、ピザを食べに行こうという電話より高いのか低いのか。ピザを食べに行くのと、ポルノ画像とでは、どうだろうか。)価格を使って、価値判断を社会に委ねることはできない(ポルノ画像は有料のことが多いし、その伝送が、子供の生まれた両親から祖父母に電子メールで送った写真と帯域幅を張り合ったとしても、問題はないだろう)。自動車交通の場合は、緊急時の特権が使われることは滅多にない。だから、そうした状況を判断する訓練された人がいるのだ。インターネットの場合、それは不可能だし、好ましくもない。

 都市部の道路はゆっくりと整備が進み、輸送速度に対する一般市民のイメージはおよそ一致している。インターネットの容量と利用率が一定だとすれば、そうした都市部の道路交通と同じように、おそらくは、QoSにも妥当性があるだろう(いつそれに訴えるべきかが、ハッキリしていれば)。しかし、インターネットの容量は増え続けている。ファイバーが何キロにも渡って新たに敷設され、光が通るのを待っているのだ。QoSを導入すれば、混雑が高じるまでのわずかな期間は、役に立つだろう。それを過ぎれば、QoSのアルゴリズムは有害無益だ。新しい伝送技術やIP接続の新しい利用法が登場したときにも、対応できないと思われる。その同じ努力を容量の拡大に注げば、QoSは不要になるだろう。

 QoSを導入すれば、ごく一部のトラフィックの伝送状況が少しよくなり、利用率はわずかに改善される。しかし、容量はいつも新技術によって10の冪乗で増加してきたし、それが打ち止めになるという信ずべき理由もないのだ。むしろ、複雑なQoS技術のために、より新しい、より大きな伝送容量への動きが抑制される可能性がある。QoSを優先する必要性は、その分、減殺される。

 グラフを使って説明しよう。QoS必要論の前提は、QoSを必要とするトラフィックはわずかで、識別も容易だということだ。しかし、そのどちらも怪しい。

100Mbps、QoSなし

図2 100MbpsでQoSなしのネットワークを考えよう。ある程度の利用率までは、さまざまなトラフィックは快適に行き交う。その限界を、例えば、30Mbpsとしよう。そして、50Mbps付近で渋滞が始まるとする。

100Mbps、QoSあり

図3 この100Mbpsのネットワークに、理想的なQoSアルゴリズムを導入する。「選ばれた」トラフィックは、例えば、利用率50Mbpsまで順調だ。しかし、90Mbpsを超えると渋滞に巻き込まれる(「選ばれた」トラフィックが多いと、この閾値は下がる)。

1Gbps、QoSなし

図4 図2のネットワークにQoSを導入するのではなく、より高速の1Gbpsのネットワークにアップグレードする(新技術を導入する。IP接続では回線を複数本利用できるので、現行技術でも実現可能だ)。このネットワークでは、利用率300Mbpsまで快適だ。渋滞は500Mbpsから始まる。

 ここで思い起こすのは、Ethernet型ネットワークの弱点である。この種のネットワークは、トラフィックが多すぎると自滅するのだ。(Ethernetの最も単純な実装では、ネットワーク上のノードはいつでもパケットを送り出せる。しかし、2つのノードが同時に通信を始めれば、信号が「衝突」し、受信側は混乱してしまう。その場合、どちらのノードもランダムに選んだ時間だけ待ってから、送信を繰り返す。だから、衝突が多発するとオーバーヘッドが増え、ネットワークの効率が低下するのだ。)Ethernetの負荷が小さいときは、衝突は少なく、トラフィックは快適に流れる。「容量」の30%まで、この非決定性システムは、ほぼ専用線と同じように振る舞う。問題は、利用率が30%〜60%の場合だ。アルゴリズムを工夫してトラフィックの流通可能量を若干増やす試みには、それだけの価値はあるのだろうか。あるいは、全トラフィックを流せるだけの高速な媒体を探すべきなのだろうか。これまで、1Mbpsから5Mbpsへ、10Mbpsへ、100Mbpsへ、1Gbpsへと容量を増やしてきたように。そして、容量が拡大するたびに、新しいアプリケーションが登場してきたのだ。私には、答えは明白だ。渋滞対策でわずかな可能性を引き出すよりも、容量を増やす努力をすべきなのだ。Ethernetには、その方が有効だ。

 電話やテレビのシステムでは、インフラストラクチャーの進歩はゆっくりとしたものだった。「需要」の動向は知られており、高価な交換機や電話線のほとんどは、需要のピーク(休日など)に合わせて設計された。予期せぬ負荷が掛かると(緊急事態が発生したり、テレビ番組で電話の受け付けがあったり、あるいは、バグ付きのワープロが全国発売されたりして需要が急増したり)、システムは輻輳状態に陥る。この場合、複雑なアルゴリズムを導入することもできよう。なぜなら、利用(人間の間で交わされる音声による会話)の特性や増加は比較的一定であり、よく知られているからだ。ここでは、因子2が基本だ。しかし、以前に指摘したことだが、そうした対策を施しても、利用者の求めに応じた通信を保証することはできない。通信に関する最大の問題は、大きな遅延を持つ接続にあるのではなく、人間が電話の側にいないことがあるという問題なのだ。これは、末端での対策によって解決できる。つまり、留守番電話だ。専用線か「信頼性の低い」IP接続かの議論では、線路や機器の障害はよくあることという事実が、忘れられている。

 インターネットは、単純なサービス(IP接続)を提供している。伝送には多様な技術が使われているが、それと単純性は、よく合っている。自動車交通の場合とは異なり、多くの分野における進歩の積み重ねにより、毎年倍々ゲームで容量を増やしてきたのだ。各アプリケーションの挙動はよくわからず、一方で、新しいアプリケーションがいつも登場している。需要は大きく拡大し、その速さは人口増加率よりも遙かに速い。今、我々が使っている設備技術からほんの少し余分に引き出すよりも、より大きな容量を求めた方がずっとよい。

2003年7月30日 ダン・ブリックリン

コメント

 Jerry Saltzer教授から、次のコメントを戴いた。教授は、インターネットを構成する基本原理の一つとなった論文「End-to-End Argument」の著者の一人であり、多くのオンラインテキストフォーマットシステムの元祖であるRUNOFFの開発者でもあり、MITでの私の恩師でもある。

 議論の大筋と喩えは、実に適切だ。しかし、もう少し、議論を整理する必要があるだろう。

 電話システムは、少なくとも、ある種のQoS機能を持っているが、これは、低くあるべきQoSトラフィックが多くなると破綻するというモデルに反する。ロサンゼルスで地震が発生すると、無事だった人は一斉に電話を取り上げ、他州にいる親類に無事を知らせる。電話システムは輻輳して、発信音が聞こえるまでに30分も待たねばならないといった事態になる。しかし、警察署で受話器を取れば発信音が聞こえ、すぐに病院に電話することができるのだ。電話システムは厳格な優先度付きシステムになっており、そのネットワークに経路がある限り、特定の顧客に独占的に提供することができる。

 この仕組みは、明らかに、規模の拡大には、うまく対応できない。しかし、重大な公的施策に直接対応するためには、拡大の必要性はない。

 このアナロジーをパケット通信に適用すれば、QoS機能に努力を傾けるのは得策ではないかも知れないが、少々手荒な方法でも、極めて単純な、規模が固定されたQoS機構を用意する、公的政策としての必要性はあるかも知れない。

 私も、Saltzer教授と同意見だ。社会的安全性を考慮する必要がある。少なくとも接続の一部を「公認された」エンドポイントに、できる限り単純な方法で提供する必要があるだろう。Bob Frankstonが私に指摘したことだが、何であれ特別な仕組みに依存しすぎるのは控えるべきだ。なぜなら、「標準」システムより脆いことが多いからだ(2001年9月11日に知ったように。インターネットは、「特別な」専用電話システムよりも、上手に負荷に耐えたのだ)。また、「特別な」システムは、「悪意ある連中」の攻撃目標になりやすいものだ。

消防車のための特別車線

ニューヨーク市の単純なQoSシステム。消防車のための特別車線

 Bobは、また、次の点も指摘している。インターネットの渋滞と電話「回線」の渋滞は、同じではない。電話の場合は受話器を置かなければ回線は開放されず、他の利用者が使えるようにはならない。一方、インターネットでは、自動車交通と同じように、渋滞しても、わずかずつは進み、最終的には到達するのだ。

 これからわかるように、さらに重要な問題は、渋滞したときにアプリケーションがある種の「思いやりのある縮退」をするということだ。社会的安全性に関連するアプリケーションは、接続が渋滞しても、可能な限り可能性のある方法で処理するという方法で構築されなければならないだろう。例えば、帯域幅が減少したり遅延が大きくなったりしたら、声の「生中継」から「蓄積型交換型」のインスタントメッセージ(音声またはテキスト)に切り替えるのだ。また、情報の喪失が検出できるようになっているべきだ。そうすれば、「裏階段を上がるべからず」というメッセージが「裏階段を上がる」になることはない。変化する条件に対応するのは、従来は、困難だった。アナログ/機械的な装置の時代、増幅器とレバーと歯車でできていた時代には。しかし、今日では、強力なデータ処理能力と巨大なストレージ容量が使えるのだ。エラー訂正符号も、当たり前のように使われている。例えば、バッファー付きの受信機(イラク発の低品質ビデオ生中継で使われたような)を見よ。それは、ごく簡単な対策なのだ。

2003年8月2日 ダン・ブリックリン


この論文は、原著者の許可を得て、翻訳工房Mが翻訳したものです。訳出上の誤謬の責任は翻訳者にあります。
原著 Dan Bricklin「Why We Don't Need QOS: Trains, Cars, and Internet Quality of Service