QualNet 5.0.2

Routing Protocol OLSR_INRIA

キューとパケット落ちの関連について詳しく知りたいと考えています。
そのために、以下のような簡易な環境で、パケットの中継ノードのみのパケット落ちを確認することを試みました。

150m間隔の３*３の格子状ネットワークにおいて、中継ノードである中央のノード(以下5番ノード)に上下左右の2本のCBRフローを中継させ、
5番ノードのみでパケット落ちが発生することを確認したいと考えています。(パケット落ちは【Analyzer】の【Network】→【FIFO】→【Total Packets Dropped】から確認しています。)

しかし、CBRの送信量を変えてみても、中継ノードでパケット落ちが発生する前に、送信端末ノードでパケット落ちが発生してしまい、5番ノードでのパケット落ちが確認できません。
どうすれば5番ノードのみでパケット落ちが発生することが確認できるでしょうか？


以下は自分自身で行った作業とこの質問をするに至った理由です。
確認している結果画面
　【CBR Client】→【Total Packets Send】
　【CBR Server】→【Total Packets Recieved】
◎【Network】→【FIFO】→【Total Packets Dropped

以下変更点
Radio Type 802.11a/g Radio
Transmission Power at 6 Mbps 8.0
Transmission Power at 9 Mbps 8.0
Transmission Power at 12 Mbps 10.0
Transmission Power at 18 Mbps 18.0
Transmission Power at 24 Mbps 18.0
Transmission Power at 36 Mbps 16.0
Transmission Power at 48 Mbps 16.0
Transmission Power at 54 Mbps 16.0

シミュレーション時間 150s

CBRのプロパティ画面で
Item to send 275（色々変更しています）
Item　Size　800
Interval 10micro/seconds
Start Time 60s
End Time 100s

上の条件でItem to sendのみを変えパケット落ちの結果を見ていたところ,Item to send 250の時には、どのノードでもパケット落ちが確認できませんでしたが、Item to send 275にして初めてパケット落ちが確認できました。
しかし、これは中継ノードである5番ノードのパケット落ちでは無く、送信端末ノードのパケット落ちでした。つまり送信量を変えたとしても先に送信端末ノードでパケット落ちが発生してしまいます。
＊確認したいのは、中継ノードのみのパケット落ちなので送信端末ノードでのパケット落ちが発生することは好ましくない。

続いて5番ノードのキューサイズを小さくすることで、5番ノードでパケット落ちが発生することに期待しました。
具体的にはitem to send 250の時(他は上記と同条件)、送信端末ノードでパケット落ちが発生しなかったギリギリのラインだったので、この条件下において、
【5番ノード】→【Node Configuration】→【Network Layer】→【Schedulers and Queues】→【IP Input Queue Size】がデフォルトで150000になっていたので、これを極端に1などに変更してみましたが150000の時と結果は変わらず、【Analyzer】→【CBR Server】→【Total Packets Recieved】の項目なども一切変化が見られませんでした。

私の解釈では、パケットが届いた時は一時的に、キューにパケットが格納され、それが次の目的地に向けてキューから出て（出る時はパケットは Output Queueから出る。この時の キューサイズが【IP Input Queue Size】）送信される。
この時のパケットを格納できるキューサイズの大きさが【IP Input Queue Size】であり、これを小さくすることで、パケットが格納できなくなり、パケット落ちが発生するという解釈だったのですが間違っているのでしょうか？

特に考え無しに,３項目ある【IP output Queue Size】の値を150000から全て1にした場合の結果も確認してみました。
すると、【Total Packets Dropped】にて5番ノードのみでパケット落ちが確認できてしまいましたが（metric value 75）、ここに来て、今までは[0]（output queueのインタフェースだと思っている）、の結果だったのに対して、初めて[1]の結果が表示されたこと、値を150000から１と極端に減らしたにも関わらず、【Total Packets Recieved】は、それほど減っていないこと（送信250,250パケットに対して、受信245,248）など、キューとパケット落ち、受信パケット量の関係がいまいちよく理解できません。
結局のところ以下の点がよく理解できていないからかもしれません。
【IP input Queue Size】
【IP output Queue Size】と３つあるインターフェース


Documentフォルダにあるすべてのガイドを参照しましたが、Input Queueが何なのか詳しく書いてありませんでした。

「「DEFAULT_NETWORK_INPUT_QUEUE_SIZE 150000
Default size in bytes of an input queue, if it's not specified in the input file with the IP-QUEUE-PRIORITY-INPUT-QUEUE-SIZE
parameter.」」など

アドバイスできる方、よろしくお願いします。
configファイルを添付させていただきます。
3kake3_matome.zip

gogoteaさん、こんにちは。

詳しくは調べていませんが、添付のシナリオを実行したところ、私の環境では、【Network】→【FIFO】→【Total Packets Dropped】で５番ノードのパケットドロップを確認できたので、もしかしたら何かコードを修正しているということはないでしょうか。

kumanomiさん、こんばんは
返信ありがとうございます。

最初にソースコードは基本的に変えていません。
(routing_olsr-inria.cppの
#define DEBUG_OUTPUT 1に変更したことはあります。
これはrouting tableを表示するためのもので、特に変更しても統計結果が変わるようなことはありません。
添付したconfigとは別の環境ですが、同様にCBRを↑→↓←のように上下左右の何れかにリンクを張った際は、その張ったライン上を通ってパケットを中継していたことをrouting tableから確認しました。
ソースを誤って修正してしまったことによる統計値の変化がないことは断言します。)

長文のため、重要な文の前には★★をつけてあります。

kumanomiさんのPCでは、パケットドロップを確認できたとのことですが
添付したconfigファイルは本文の

「特に考え無しに,３項目ある【IP output Queue Size】の値を150000から全て1にした場合の結果も確認してみました。
すると、【Total Packets Dropped】にて5番ノードのみでパケット落ちが確認できてしまいましたが（metric value 75）」

上記の引用部分にあたりますので、確かにパケット落ちが確認できたと思います。
此方のＰＣでも確認できています。

【IP output Queue Size】
このような結果を確認して頂けたかと思います。【Total Packets Recieved】

★★おそらく、この結果を見たkumanomiさんは「何だ5番ノードでパケットドロップを確認できてるから問題解決。」
と思われての回答だと思うのですが、私はこの結果に納得できません。

初めは、【IP input Queue Size】を小さくすれば、中継されてくるパケットをキューに格納できずに、パケット落ちしてしまうと考えていたため、IP input Queue Sizeを1にしてシミュレーションを実行したが、結果は150000の時と変わらなかった。
つまり、中継されてくるパケットを格納するキューはinput queueではなかったことが分かりました。私が誤認していたわけです。

では、【IP output Queue Size】を小さくしたらどうなるかということを調べたのが添付したconfigファイル。
【IP output Queue Size】は３つあるインターフェース全て1byteです。

結果は挙げた通り、5番ノードで75[1]落ち。(今ままでインターフェスは[0]しか使われていなかったのに突然[1]が使われたことは若干謎である。インターフェースを[0]の１つだけにしたら[0]で75パケット落ち)

真っ先に思ったことは、【IP output Queue Size】を下げたら、5番ノードでパケット落ちが確認できたので、中継されてきたパケットを格納するのは、input Queueではなくoutput Queueのほうだったということです。

★★しかし、改めて考えてみると納得できない点があります。
この時の【Total Packets Sent】に対する【Total Packets Recieved】の変化です。
本文の通り
Item　Size(byte)　800byte（１パケットのサイズです）
（送信250,250パケットに対して、受信245,248）

しかし、5番ノードの【IP output Queue Size】は全てのインターフェースで１(byte)にしたはずです。
先ほど中継されてきたパケットはoutput Queueのほうに格納されると結論づけましたが、最低でも800byte(1パケットの単位)あるのに1byteしか格納できないはずのキューに格納されていることになってしまいます。
つまり私としては、１パケットですら５番ノードで格納できないので、全てのパケットが５番ノードで落ち、宛先端末ノードにはパケットが届くわけがないと考えているわけです。
（送信250,250パケットに対して、受信0,0）なら納得できます。

★★そのような結果にならないことから、そもそも「output Queue」「input Queue」とは何なのか理解できず、結果として、キューとパケット落ち、Total Packets Recievedの関連が分かりません。


なるべく詳細に現状をお伝えしたかったので、かなりの長文となってしまいました。
以下に最終的にやりたいこと、本トピックを立てた目的をまとめておきました。

これでも伝わらない点などあるかと思いますがご指摘いただければ捕捉をいれますので、よろしくお願いします。
ここまで読んで頂いてありがとうございました。


【最終的にやりたいこと】
3*3ではなく10*10のネットワークで、同様に2本のＣＢＲ通信を中央のノードで交差するように通信させ、中央のノードでパケットドロップを故意に起こします。
送信端末ノードは2つあるわけですが、片方のノードの全てのトラフィックを1列/2列隣りのノードを経由した時のトTotal Packets Recievedとパケットドロップの値を確認する。
（伝わりづらいかもしれないので図を下に書いておきました。）

さらに、下の送信端末ノードが4000パケットを送信していたと仮定し、
例えば、2列隣りの経路を使って3000パケット送信、残りの1000パケットを元の経路で送信したら、4000パケット全てを２列隣りの経路を使うより、良い結果（Total Packets Recievedが増える）になるネットワーク環境が必ずあるはず。
なぜなら、全て２列隣りの経路を通ってしまうと、結局トラフィックが交差するノードで同様にパケットドロップが起こるから。
ある程度のトラフィックを分散させることで、交差するノードでのパケットドロップを抑えることで、Total Packets Recievedがトータル的に見て増加するはず。

このように、トラフィックを分散させることで良い結果が得られるようなネットワーク環境を故意につくりたいと考えています。
それを知るために、まずはパケットドロップとキュー、Total Packets Recievedの関係を3*3のネットワーク環境で調べています。
分散方法については、後の課題です。（Static routing tableを考えていましたが、１つのノードは１つのstatic routing ファイルしか持てず、分散させることができないという課題が残っていますが...）

通常
　　↑
　　↑
→→→→→
　　↑
　　↑

2列隣り
　　←←↑
　　　　↑
→→→→→
　　　　↑
　　→→

【本トピックスのテーマ】
3*3の簡易なネットワークでキューとパケット落ち、Total Packets Recievedの関連について詳しく知る。
・どのような条件で初めて中継ノードでパケット落ちが発生するのか
・パケット落ちが発生することで、パケット受信量は結果的にどうなるのか
・input queue　とoutput queueはそもそも何なのか

gogoteaさん。
追加情報ありがとうございます。少し考えてみました。

Network->FIFO->Total Packet Droppedで2,4のみドロップデータがあって、5にないのは、2,5が始点のデータはドロップして、5が始点のデータはドロップしなかった、ということではないでしょうか。

それから、Queue Sizeを1byteにした時の問題については、OLSRでルーティングテーブルを構築するためのメッセージが5番で落ちてしまい、結果、5番ノードは利用されないルーティングテーブルができた、という可能性は無いでしょうか。

あまり自信はないのですが……

回答ありがとうございます。

「Network->FIFO->Total Packet Droppedで2,4のみドロップデータがあって、5にないのは、2,5が始点のデータはドロップして、5が始点のデータはドロップしなかった、ということではないでしょうか。」

これはメイントピック本文中の
「しかし、CBRの送信量を変えてみても、中継ノードでパケット落ちが発生する前に、送信端末ノードでパケット落ちが発生してしまい、5番ノードでのパケット落ちが確認できません。」
に対しての返答といったところでしょうか？

これに対しての回答はもちろんYESです。
中継のノードでパケット落ちをさせるために、パケット送信を行っているのに、送信端末ノードでパケット落ちが発生していては本末転倒です。


5番ノードでOLSRの制御パケットが届かず、5番ノードを経由していないのではないか？というご指摘を頂きましたが、
結果その通りでした！
実は私もそのことを少し考えて、【OutputWindow】に表示されるルーティングテーブルを確認していたのですが、インターフェースのIPアドレスが

169.0.0.1
169.0.0.2
169.0.0.3
169.0.0.4
169.0.0.9
169.0.0.10
169.0.0.11
169.0.0.12
169.0.0.13
（上から準備ノード１のインターフェース、ノード２のインターフェース...を表す）
このように最後の数字がノード番号とずれていて混乱してしまいました。この現象は過去に一度ノードを配置した後でそれを削除し、新しく再配置する際に、インターフェースの番号がずれてしまうようです。

改めて169.0.0.9→169.0.0.5のように戻し
確認してみました。

次の★マークまで読み飛ばしてもらってもかまいません。

更に添付していた3kake3_matomeシナリオでは、
【Nodes】のほうでOutputQueueSizeを変更していました。
以前別のシナリオ(10kake10)にてOutputQueueSizeを変更する際には【Nodes】からではなく【Interferce】から変更しなければ結果は何も変わらないという検証をしたのですが、今回、なぜか【Noedes】からOutputQueueSizeを変更しても、統計に変化が現れる結果となってしまい、そこが謎ではありましたが、【Nodes】からの変更は元に戻し（OutputQueueSizeを1->15000に戻し）【Interfece】の項目でQueueSizeを1にしましたが同じ結果が得られたので、以降【Interfece】の項目でOutputQueueSizeを変更していきました。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

【捕捉】【Interfece】の項目からOutputQueueSizeを変更しなければならないの検証

必要であれば添付しますが、読み飛ばしてもらってもかまいません。

________【QualNet1.11.12_10.00.29.Stat】___________________________
10kake10シナリオ
【interface】→【RoutngiProtocol】→【File Statics】出力結果の項目があった。
デフォルトでは　IP input Queueは非表示

input Queueを表示するようにチェックをいれたが、その項目はない。
今まで、Total packets Droppedの項目を見てきたが（FIFO）
IpOutdiscard(IP)のほうも気になる。Total packets Droppedと
同じ結果だった

CBR：送信端末ノード→宛先受信端末ノード
1->100 6->96 95->7 51->60

シミュレーション時間 150seconds
items to send　全て4000s
items Size 　　全て512 byte
interval 　　　10millsecond
start Time 60s
End 　Time 100s
丁度4000Packet送る設定。


【パケット受信】
7番:1151
60番:2183
96番:2041
100番:1534

【Total Packets Dropped】ドロップ（パケット落ちしたノード番号）
1484(35)　1646(46) 2020(55)　99(56)

宛先端末 7 60 96 100
トラフィック受信量　 1151 2183 2041 1534
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
【QualNet1.11.12_11.19.03.Stat】
10kake10シナリオ
【Interface】（Nodesのほうは変更されないようだ）→【Network layer】→【Schedulers and Queues】
Number of IP Output Queuesを１に変更（サイズはデフォルトのまま）
input Queueを表示するようにチェックを外した（デフォルト設定）
他の条件は全て【QualNet1.11.12_10.00.29.Stat】と同じ

input Queueのチェックによる変化は一目無し（Network Layerの項目には変化がないようにみえる）


宛先端末 7 60 96 100
トラフィック受信量 1200 1778 2246 1712

【Total Packets Dropped】ドロップ（パケット落ちしたノード番号
966(35)　1547(46)　2811(55)　70(65)

結果は色々と変わった...　特にパケット落ちが56番ではなく70番に変わっている

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
【QualNet1.11.12_12.44.09.Stat】
今度は対象に
【Nodes】（Interferceのほうは変更されないようだ）→【Network layer】→【Schedulers and Queues】
Number of IP Output Queuesを１に変更（サイズはデフォルトのまま）

宛先端末 7 60 96 100
トラフィック受信量 1151 2183 2041 1534

【Total Packets Dropped】ドロップ（パケット落ちしたノード番号）
1484(35)　1646(46) 2020(55)　99(56)

結論：
【QualNet1.11.12_10.00.29.Stat】とまったく同じ結果になった。
Nodesのほうで、Number of IP Output Queuesを変えても効果が出ない。
今後、Output Queuesの設定を変更する時は、【Interferce】のほうから変更すべき！

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
【QualNet1.11.12_13.24.26.Stat】
宛先端末 7 60 96 100
トラフィック受信量 1200 1778 2246 1712

【Total Packets Dropped】ドロップ（パケット落ちしたノード番号
966(35)　1547(46)　2811(55)　70(65)

結果は【Interfaece】で変更した時とまったく同じ
【QualNet1.11.12_11.19.03.Stat】と同じ

結論：
★★やはり【Queue】を弄る際には、【Interferce】で操作する。
確定情報

インターフェースの数を３本から１本に変化した時の考察は必要。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿


【結果】
【OutputQueueSize＝150000】
Total Packets Received_QueueSize　パケット数（宛先端末ノード番号）
245(6) 248(8)


【OutputQueueSize＝１】
5番ノードを通っていないことを確認
4->1->2->3->6
2->1->4->7->8
Total Packets Droppedは75(5番ノード)
QualNet.1.13.12＿18.33.57

OLSRの経路情報が5番ノードで受信できていなかったので、別の経路を使ってマルチホップ通信を行っていたようです。

【OutputQueueSize＝73】で初めて、5番ノードを中継しないマルチホップ通信を行うので、このQueueSizeを境に経路情報が届かなくなるのだと考察できます。

これで、疑問点が１つ解決できました。
ありがとうございます。


問題はここから、どうやって自分にとって理想的なネットワーク環境（トラフィックを分散させることで、トラフィック受信量が増える）を作るかですね。
引き続き検証していきます。