環境は先日決定したとおりで考えるとして
複数フローが集中したときに，負荷を監視し，
送信元ノードにReply，転送容量削減を目指す．
状態遷移図 ちっくなもの
余裕がある→通常通信へ戻る
↑
通常通信→（新規フロー発生）→＜負荷計測＞→余裕がない（集中状態）
↓
転送量削減←送信元ノードにReply
考慮すべき点
・負荷の計測
・送信元ノードへの連絡方法
・転送容量削減アルゴリズム
・負荷の計測
本システムでは動画Flowは一定間隔，一定期間で流れ続けるモデルのため
送信パケットごとに負荷分散を行う必要性は低い．
通常の負荷計測方法としては，RTTとパケットロス率を用いた
送信側でのトラフィック推定手法が多い（情報処理学会論文集2006Julyより）
他の負荷分散手法について調査
参考文献"マルチホップ無線LANにおける動的なトラヒック制御"
P36 過去の送信量と現在の送信量を基に使用帯域を推定するTSW（Time Sliding Window)
アルゴリズムというものがある．
D.D. Clark and W. Fang : “Explicit Allocation of Best-effort Packet Delivery Service,”
IEEE/ACM Transactions on Networking, vol.6, no.4, August. 1998.(古いナー）
読み進めてみますが，果たして読めたところで実装できるのでしょうか…
・送信元ノードへの連絡方法
映像データはUDPで転送されるが，ReplyパケットはTCPが好ましい．
負荷が集中している場合に迅速にTCPパケットが送信できるのか．
送信を開始する前なのでReplyパケットの遅延はさほど問題ない？
・転送容量削減アルゴリズム
アプリケーション側で容量削減（単純に送信データ総量を削減）するが
どの程度削減するべきか，スループットとの兼ね合いを考慮して
画像サイズ，フレーム数，転送間隔を何msにするか などを決定．
