久しぶりにギターを弾こうと思って、いろいろ引っ張り出してPCで録音できる状態を作ったのだが、どうも音が曇っている。
ギターは、ひとりで寂しく弾いても楽しくないしうまくもならない。本当はドラムやボーカルやベースと一緒にやるのが理想であるが、面倒くさいしそんな人もいないので、私は一人で多重録音をしている。
以前はMTRにドラムマシンをつなぎ、1回目はリズムギターを入れて2回目にソロを入れるのを基本としていた。しかし色々と機材がかさばるのともっと多様な楽器を使いたいということで導入したのがACIDである。たしかにACIDなら多様なリズムや楽器のループが使えるし多重録音もできるのだが、やはり所詮は切り貼りしたつくりものなので、イマイチである。
MTRで作ったものは今でもMDにとってあるが、なかなかよい。特に、マランツのアナログMTRでとったものは自分の人生の中でも奇跡として位置づけられている。やっぱり、MTRでカセットテープに録音するのがいいな。録音したあと巻き戻すのもあれはあれでいいインターバルになっていたし。音も心なしかまろやかだったような気がする。
あと、acidのループは全体的にファンキーすぎるというかクールすぎるというか、俺はもっとベタでゆるくて単純なグッドオールドデイズみたいな感じがやりたいんだよね。
rsvpのなぞ
rsvpとは、Intserv方式のQOSを行うプロトコルである。通信を開始する前に、網の入り口のルータが、経路上の通過するすべてのルータに必要な帯域を通知し、経路上のルータは要求された帯域があればそれを確保するという仕組みである。このようなことは用語集などにも載っていることで調べればすぐわかるが、実際に動作させてみるのは大変であった。
以下、ciscoでの設定方法を記す。
１．予約を受け付ける準備
さて問題のRSVPの有効化であるが、これはI/Fモードで下記のようにコマンドを入力する。
if2(config-if)ip rsvp bandwidth 50000
これはif2において、50000kbpsつまり50Mbpsの帯域を予約可能帯域として確保します、という意味である。数値は指定しなければI/Fの帯域の75%となる。この設定を、経路上のルータのすべてのI/Fで設定しておく。これで帯域の予約を受け付ける準備が整った。
２．帯域の予約
予約を行う経路のことを、tunnelと言う。R1で、仮想のtunnelI/Fを作成する。
tunnel source: unnumbered
理由はよくわからないがunnumberedにするのが慣例らしい。
tunnel destination: 予約が必要な経路の終端のルータのloopback address
(3.3.3.3)
必要な帯域：50Mbps(50000kbps)
このトンネルを作成すると、帯域を予約しにいく「PATHメッセージ」というものが送信される（いつ送信されるのか正確には未確認）。経路上のルータはPATHメッセージを受け取ると帯域が確保できれば確保する。RESVメッセージで返事をする（？）。PATHメッセージは経路の終端まで転送され、終端のすべてのルータで帯域が確保できれば、tunnelがupする。tunnelに終端のルータのloopbackアドレスをルーティングするか、autoroute announceを設定することで、tunnelインタフェースを通って通信が行われるようになる。
２．予約の競合
予約可能帯域が50Mbpsであるところに、30Mbpsの予約が二本入ったらどうなるか。priorityが同じであれば、先に予約したtunnelのみがupする。priorityが異なり、予約可能帯域が足りない場合、後から予約したtunnel priorityが予約済みtunnelより高ければ、予約済みtunnelがdownして、後のtunnelがupする。
３．実際の通信
当たり前のことであるが、予約というのは、「誰かにとられないようにとっておく」ものである。上記の経路を誰も使用しないのだったら、予約してもしなくても、10Mのトラフィックは流れる。それどころか帯域とルータの処理能力が許せばそれ以上のトラフィックが流れる。
だから、予約できたかどうかを確認するには、今回の場合であれば、予約をしていないものがこの経路に残り10Mbpsより少なくなるような、FastEtherであれば90Mbpsを超えるトラフィックを流していて、そこに予約したものが10Mbpsのトラフィックを流したら、前者の過剰なトラフィックが破棄されて、後者の10Mbpsのトラフィックが通ればよい・・・が、結論から言うとそうはならなかった。予約は全く形だけで、実際にはベストエフォートの通信しか行われない。
人間社会にたとえるなら、以下のようになる。100個の席があって、10の団体が10席ずつ予約をする。予約どおりに各団体が10人ずつ来れば、予約どおりに全員が座れる。しかし、もしある団体で急遽人が増えて15人で来たとする。当然余分な5人分の席は提供されない。もし他の予約済みの席が空いていたらとりあえず座らせることがあったとしても、その後予約客が来たら当然立ってもらわねばならない。
しかしRSVPプロトコルだけではそこまでやってくれないのだ。予約を取るだけとって、いざとなったら予約を無視してしまうのである。そんなことなら最初から予約など受け付けるな、という話である。忘れてはならないのは、intservでの予約というのは、自分が使用する帯域の上限の申告ではない、ということである。どんなに混雑しても、最低この帯域だけは保証してください、というものである。
「10Mbps予約したのに10Mbps以上流すな」というのもわからなくもないが。
以下、ciscoでの設定方法を記す。
１．予約を受け付ける準備
if2 if1 if2 if1 if2 ( R1 )---( R2 )---( R3 ) 1.1.1.1 3.3.3.3R1が、R1からR3までの間で10Mの帯域の予約を行うとする。まず、あらかじめ各ルータではIGPが設定され、R1はR3のloopbackアドレスに到達可能である必要がある。今回はIGPにはOSPFを使用した。OSPFではTE(traffic engineering)機能を有効にし、TE機能を有効にするエリアとI/Fも指定する。
さて問題のRSVPの有効化であるが、これはI/Fモードで下記のようにコマンドを入力する。
if2(config-if)ip rsvp bandwidth 50000
これはif2において、50000kbpsつまり50Mbpsの帯域を予約可能帯域として確保します、という意味である。数値は指定しなければI/Fの帯域の75%となる。この設定を、経路上のルータのすべてのI/Fで設定しておく。これで帯域の予約を受け付ける準備が整った。
２．帯域の予約
予約を行う経路のことを、tunnelと言う。R1で、仮想のtunnelI/Fを作成する。
tunnel source: unnumbered
理由はよくわからないがunnumberedにするのが慣例らしい。
tunnel destination: 予約が必要な経路の終端のルータのloopback address
(3.3.3.3)
必要な帯域：50Mbps(50000kbps)
このトンネルを作成すると、帯域を予約しにいく「PATHメッセージ」というものが送信される（いつ送信されるのか正確には未確認）。経路上のルータはPATHメッセージを受け取ると帯域が確保できれば確保する。RESVメッセージで返事をする（？）。PATHメッセージは経路の終端まで転送され、終端のすべてのルータで帯域が確保できれば、tunnelがupする。tunnelに終端のルータのloopbackアドレスをルーティングするか、autoroute announceを設定することで、tunnelインタフェースを通って通信が行われるようになる。
２．予約の競合
予約可能帯域が50Mbpsであるところに、30Mbpsの予約が二本入ったらどうなるか。priorityが同じであれば、先に予約したtunnelのみがupする。priorityが異なり、予約可能帯域が足りない場合、後から予約したtunnel priorityが予約済みtunnelより高ければ、予約済みtunnelがdownして、後のtunnelがupする。
３．実際の通信
当たり前のことであるが、予約というのは、「誰かにとられないようにとっておく」ものである。上記の経路を誰も使用しないのだったら、予約してもしなくても、10Mのトラフィックは流れる。それどころか帯域とルータの処理能力が許せばそれ以上のトラフィックが流れる。
だから、予約できたかどうかを確認するには、今回の場合であれば、予約をしていないものがこの経路に残り10Mbpsより少なくなるような、FastEtherであれば90Mbpsを超えるトラフィックを流していて、そこに予約したものが10Mbpsのトラフィックを流したら、前者の過剰なトラフィックが破棄されて、後者の10Mbpsのトラフィックが通ればよい・・・が、結論から言うとそうはならなかった。予約は全く形だけで、実際にはベストエフォートの通信しか行われない。
人間社会にたとえるなら、以下のようになる。100個の席があって、10の団体が10席ずつ予約をする。予約どおりに各団体が10人ずつ来れば、予約どおりに全員が座れる。しかし、もしある団体で急遽人が増えて15人で来たとする。当然余分な5人分の席は提供されない。もし他の予約済みの席が空いていたらとりあえず座らせることがあったとしても、その後予約客が来たら当然立ってもらわねばならない。
しかしRSVPプロトコルだけではそこまでやってくれないのだ。予約を取るだけとって、いざとなったら予約を無視してしまうのである。そんなことなら最初から予約など受け付けるな、という話である。忘れてはならないのは、intservでの予約というのは、自分が使用する帯域の上限の申告ではない、ということである。どんなに混雑しても、最低この帯域だけは保証してください、というものである。
「10Mbps予約したのに10Mbps以上流すな」というのもわからなくもないが。