＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
実効帯域
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
2007.4.10 CBRトラヒックをパケットサンプリングすると、実効帯域計算結果はどうなる？
ｍ＝１０のCBRトラヒックの実効帯域は10であるが、サンプリング間隔がある値よりも大きくなると、実効帯域の計算結果は10よりも大きくなった。そこで、更にサンプリング間隔を大きくしてみると実効帯域の計算結果がさらに大きくなると思って試してみたけど、実効帯域の値はある値をピークとして、それ以上大きくなることは無かった。
2007.4.10 実効帯域とタイムスロット幅の関係
ポワソンやCBRトラヒックなどの実際のデータをもとに実効帯域を計算すると、タイムスロット幅が小さいほど実効帯域は大きくなった。タイムスロット幅をものすごく小さくし、それぞれのスロットでのパケット到着数が0か１のどちらかになるようにすると、CBRであれポワソンであれ、実効帯域の大きさは変わらないようだ。つまり、スロット幅が小さければCBRの実効帯域はポワソンの実効帯域に等しくなる。他のトラヒックではどうなるのか、調べてみると面白いかも知れない。もしかしたら、トラヒックの種類に関係なく、実効帯域の計算値はポワソンの実効帯域の理論値で近似できるかもしれない。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
NS2
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
2005.6.19 http://www.ismusic.ne.jp/tetsuya/drop.xls
TCPとUDPが並列処理時、RTOがどんどん倍になってるはずが一見なってない箇所のあった問題だけど、あれはたまたまTCP側のアックが帰ってきたことによるっぽいね。で、アックが帰ってくるとすぐにTCPはパケットを再送したようです。しかし、だからといってRTOがリセットされたわけではなくて、ちゃんと次の再送は倍の時間をようしてます、よ～くみてみよう。TCPタホーではRTOの値がリセットされることは無いみたい。コネクションを切断するまでRTOはリセットされないってことです。
2005.5.24 TCPをレノとかベガスに変える方法
http://www.cool.giti.waseda.ac.jp/~onoder/ns_project/Chapter28.txt
ホームはnsマニュアル和訳プロジェクト 中里研究室
2005.5.18 TCPのフロー制御
受信側のウインドウサイズをアックのヘッダで送信側に伝え、これを受けて送信側は一度に送信するセグメントの数を調整し、受信側でのオーバーフローを防いでいる。この方法をTCPのフロー制御という。では受信ウインドウがいっぱいになると、ウインドウサイズ＝ゼロとしてアックが送信側に返され、これを受けて送信側はセグメントの発信を中断する。これをゼロウインドウ状態という。このままでは通信がとまったままなので、受信ウインドウに飽きができたら、受信側→送信側 に改めてアックを送り、新しいウインドウサイズを通知する。
2005.5.17 MSSとTCP
MSS(最大セグメントサイズ）でウインドウサイズを割れば、TCPで一度に転送するパケットの個数になるのかな？NSでのMSSの設定方法を知りたいところだ。今度調べよう。
2005.5.17 TCPの制御 輻輳回避のアルゴリズム →フロー制御
たぶんこんな感じ。
輻輳の発生
↓
TCPはウインドウサイズを徐々に小さくする
（ウインドウサイズが大きいとパケットが廃棄された時、再転送するパケットの量が多くて時間と帯域の無駄なので）
↓
TCP側のパケットの送信量は徐々に減少
↓
TCP側の送信レートの低下
2005.5.10 火曜 ２５時 シーケンスナンバーとパケットID
|
シーケンスナンバー |
トランスポート層で割り当てられるヘッダ |
|
パケットID |
物理層で割り当てられるヘッダ |
恐らく、こんな関係がある。（謎 物理層レベルで見ると、パケットIDは馬鹿みたいに１から順に全てのパケットに割り当ててるだけなんで被る事は無いけど、同じシーケンスナンバーを持つパケットは４つぐらい存在したりする。
2005.5.10 火曜 ２４時 エンキューとデキューとパケット廃棄
エンキューされたパケット数＝デキューされたパケット数
⇒ そのリンクで廃棄されるパケット数 ＝ 零
エンキューされたパケット数＞デキューされたパケット数
⇒ そのリンクで廃棄されるパケット数＝エンキューされたパケット数―デキューされたパケット数
こんな関係があるっぽい。
2005.5.10 火曜 ２３時 CBR
なんか、パケットサイズを1040byteに指定しても出てくるパケットは1000byteになってしまいます。1000byte以上は使えないっぽいので使わないようにしよう。って、重複する記事が2005.4.7に実はあるし。記憶力悪いなぁ。
2005.5.10 火曜 ２２時 TCPって２個ペアでパケット送信するの？
TCPってパケットサイズが1040バイトに固定だけど、1040のパケット２つを、本当に僅かな時間差で連続して送ることが多いみたい。２つで一つ、2080のパケットって考えても良いんじゃないかなぁ。ってか、アックは２つで１つだし？（謎
2005.5.10 火曜 ２２時 NAMな疑問
NAMでリンクをクリックするとリンク間のパケット送信の様子をタイムチャートで確認できるけど、あれのy軸って何なんだろうね？ ジッタ（パケット到着のばらつき）とかかね？ 今度暇な時に調べようかな。
2005.5.6 金曜 TCPのみのトポロジ
帯域を狭くすると、パケットの廃棄が生じないようにビットレートを下げて送信するようだ。しかし、パケットの廃棄が完全になくなる訳では無いようだ。やはりパケットの廃棄は生じている？
［明日の予定］
・帯域幅を変えた時に、最終的に受信されるパケットの数（送信に成功するパケットの総サイズ）が変わらないかどうかを調べたい。
・TCPでは全てのパケットの通信が完全に保証されているはずなのに、今回のシミュレーションではそうはなっていないようだ。（謎 ちゃんとシミュレーションをして、その理由を先輩に聞く。
［来週のゼミの予定］
TCPとUDPの通信時間を長くして、UDPの通信が終わってからTCPの通信が始まることを確認し、ビットレートを算出する。
2005.4.7 パケットサイズ
ns2では、CBRトラヒックで生成されるパケットサイズが１０００Byteを超えるとパケットが二つに分割されてしまう。例えば1040Byteのパケットを送ると、1000Byteと40Byteの二つのパケットに分割された。計算がややこしいので、パケットサイズは1000バイト以内に収めておくのが良いだろう。
