A Study on Receiver‐based Management Scheme of Access Link Resources for QoS‐Controllable TCP Connections 2004/2/20 大阪大学 大学院情報科学研究科 情報ネットワーク学専攻 博士前期課程 宮原研究室 東 和弘 k‐[email protected]‐u.ac.jp 1 研究背景 • インターネットの急速な発展に伴うトラヒックの増加 インターネットの急速な発展に伴うトラヒックの増 加 →バックボーンネットワークの高性能化 • →バックボーンネットワークの高性能化 ボトルネックはエンドホスト，アクセスリンクへ移行 • ボトルネックはエンドホスト，アクセスリンクへ移 – エンドホスト資源管理方式[4] を提案 行 – エンドホスト資源の管理だけでは不十分 [4] を提案 – エンドホスト資源管理方式 →アクセスリンク資源の管理が必要 – エンドホスト資源の管理だけでは不十分 • ボトルネックが動的に変化するネットワークへの対応 →アクセスリンク資源の管理が必要 – 例: P2P ネットワーク • ボトルネックが動的に変化するネットワークへの対 – 様々な資源の管理が要求される 応 →資源の統合的な管理が必要 – 例: P2P ネットワーク [4] T. Okamoto, T. Terai, G. Hasegawa, and M. Murata, “A resource/connection management scheme for HTTP proxy 2004/2/20 2 servers,” in Proceedings of Second International IFIP‐TC6 Networking Conference, pp. 252–263, May 2002. アクセスリンクにおける問題 • アプリケーションの複数同時 実行による資源競合 – アクセスリンクにおいて輻輳が発生しやすい 送信側ホスト • TCP の性質によるアクセスリンク資源の浪費 – short‐lived コネクション • パケット廃棄の影響が大きい P2P – long‐lived コネクション • アプリケーションの特徴を反映できない • アクセスリンク資源を有効に活用できない Network Update 受信側ホスト Streaming ラストホップルータ インターネット アクセスリンク 2004/2/20 FTP Web 3 提案方式 受信側ホストにおいて， • アクセスリンクへのパケット到着レートの制限 – 全ての TCP コネクションに割り当てる受信バッファの 総量を調整 • アクセスリンクにおける輻輳を回避 • 優先順位に応じた受信バッファの割り当て – 各 TCP コネクションに割り当てる受信バッファサイズ を 変更 2004/2/20 • short‐lived コネクション： パケット廃棄の減少と反応時間の 向上 • long-lived コネクション： アプリケーションの特徴を反映し 4 た 到着レートの制限 ~ 通常時 ~ RTT に変化なし 送信側ホスト →アクセスリンク資源に 受信側ホスト 余裕 ラストホップルータ インターネット アクセスリンク 受信バッファの総量 ラストホップルータバッファ • 全コネクションの RTT の変化に よって輻輳状態を推測 – 変化なし→アクセスリンク資源 に余裕 – 増加→輻輳発生 • 受信バッファの総量を調整 – アクセスリンク資源に余裕→ 増加 2004/2/20 – 輻輳発生→減少 5 到着レートの制限 ~ 輻輳時 ~ 送信側ホスト RTT が増加 受信側ホスト →輻輳発生 ラストホップルータ インターネット アクセスリンク 受信バッファの総量 ラストホップルータバッファ • 全コネクションの RTT の変化に よって輻輳状態を推測 – 変化なし→アクセスリンク資源 に余裕 – 増加→輻輳発生 • 受信バッファの総量を調整 – アクセスリンク資源に余裕→ 増加 2004/2/20 – 輻輳発生→減少 6 受信バッファの割り当て • short‐lived コネクション – 優先的に割り当て • スロースタートフェーズ中の輻輳ウィンドウサイ ズの増加アルゴリズムを考慮 • 1 RTT ごとに 2 倍 • long‐lived コネクション – アプリケーションの特徴を反映した優先度と 各コネクションの RTT を考慮 2004/2/20 7 性能評価 ~ 比較対象 (関連研究) ~ • Spring[1] – ラストホップルータバッファと帯域遅延積を考慮して，受信バッ ファを 割り当てる – インタラクティブ型のアプリケーションの反応時間の向上 • Mehra [2] – アクセスリンク帯域を優先度，最低転送レート，重みに従って共有 させる – ストリーミングなどのサービスに対し，優先的に最低転送レートを 占有 • 従来方式 – 各 TCP コネクションに割り当てる受信バッファサイズを固定 [1] N. T. Spring, M. Chesire, M. Berryman, V. Sahasranaman, T. Anderson, and B. N. Bershad, “Receiver based management of low2004/2/20 bandwidth access links,” in Proccedings of IEEE INFOCOM 2000, pp. 245–254, 2000. 8 [2] P. Mehra, A. Zakhor, and C. D. Vleeschouwer, “Receiver‐driven bandwidth sharing for TCP,” in Proceedings of IEEE INFOCOM 2003, Mar. 2003. 性能評価 ~ シミュレーション ~ A: 20Mbps, 5ms B: 20Mbps,15ms C: 20Mbps,25ms A ラストホップルータ 100Mbps, 25ms 受信側ホスト 128KB アクセスリンク Down: 4Mbps, 5ms UP: 500Kbps, 5ms 128KB 20Mbps, 5ms D 送信側ホスト short‐lived コネクション シミュレーション開始 100 秒後から確立 2004/2/20 B C • A, B, C から無限長サイズの バルクデータ転送 – アクセスリンク帯域を 使い切る – long‐lived コネクション • D からランダムな間隔ごとに 30 KB のデータ転送 – シミュレーション開始 100 秒後 – 合計 100 回 – short‐lived コネクション • 評価指標 – short‐lived コネクション • コネクション確立時間 • データ転送時間 – アクセスリンクの利用率 – ラストホップルータのキュー長 9 性能評価~ シミュレーション結果 ~ short-lived コネクションの データ転送時間 1 1 0.8 0.8 データ転送にかかる 時間が最も小さいが・・・ 0.6 キュー長が短い →遅延が小さい キューイングによる 遅延が増加 0.6 0.4 CDF CDF short-lived コネクション確立時間 0.2 0 0 0.4 0.2 提案方式 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0 4 利用率が高く アクセスリンクの 利用率が低下 3.5 3 2.5 0 2004/2/20 50 100 150 200 250 300 350 400 450 500 time [s] Average Queue Length [packets] Access Link Utilization [Mbps] 4.5 0.4 0.6 0.8 1.0 time [s] time [s] アクセスリンクの利用率 アクセスリンクの 0.2 キュー長が大きい ラストホップルータのキュー長 80 →遅延が大きい 1.2 Spring Mehra 従来方式 70 60 50 40 30 20 キュー長が短い キューが頻繁に空 →遅延が小さい 10 0 0 50 100 150 200 250 300 350 400 450 500 time [s] 10 性能評価~ シミュレーション結果 ~ short-lived コネクションの データ転送時間 1 1 0.8 0.8 0.6 CDF CDF short-lived コネクション確立時間 0.4 0.2 0 0 0.6 0.4 0.2 提案方式 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0 4 3.5 3 2.5 Average Queue Length [packets] Access Link Utilization [Mbps] 4.5 0.4 0.6 0.8 1.0 time [s] time [s] アクセスリンクの利用率 0.2 ラストホップルータのキュー長 1.2 Spring Mehra 80 従来方式 • 優先順位に応じて受信バッファを割り当てること 70 によって， 60 50 – short-lived コネクションの確立時間とデータ 40 転送時間が向上 3020 0 2004/2/20 50 100 150 200 250 300 350 400 450 500 time [s] 10 0 0 50 100 150 200 250 300 350 400 450 500 time [s] 11 性能評価~ シミュレーション結果 ~ short-lived コネクションの データ転送時間 short-lived コネクション確立時間 1 1 0.8 • アクセスリンクへのパケット到着レートを制限する 0.6 0.6 ことによって， 0.4 0.4 – アクセスリンクの利用率が高く， 0.2 0.2 提案方式 – キュー長が短い 0 0 0 0.2 0.4 0.6 0.8 1.0 1.2 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 CDF CDF 0.8 time [s] アクセスリンクの利用率 4.5 4 3.5 3 2.5 0 2004/2/20 50 100 150 200 250 300 350 400 450 500 time [s] Average Queue Length [packets] Access Link Utilization [Mbps] time [s] ラストホップルータのキュー長 80 Spring Mehra 従来方式 70 60 50 40 30 20 10 0 0 50 100 150 200 250 300 350 400 450 500 time [s] 12 まとめと今後の課題 • まとめ – アクセスリンク資源管理方式を提案 • アクセスリンクにおける輻輳の回避 • 各 TCP コネクション，アプリケーションの特徴を反映 • 関連研究との性能比較によって提案方式の有効性を確認 – 統合方式を提案 • ボトルネックが動的に変化するネットワークへの対応 • エンドホスト資源管理方式との統合 • シミュレーションによって有効性を確認 • 今後の課題 – 実ネットワーク上での実装実験による性能評価 2004/2/20 13 提案方式の適用イメージ short-lived A long-lived B アクセスリンク資源に 余裕 受信側ホスト long-lived C ラストホップルータ インターネッ ト ACK long-lived ラストホップルータバッファ 受信バッファの総量 受信バッファの総量 AA B C 2004/2/20 D D 14 提案方式の適用イメージ ~ 輻輳時 ~ short-lived A long-lived B 輻輳発生 long-lived C 受信側ホスト ラストホップルータ 輻輳 ACK インターネッ ト long-lived ラストホップルータバッファ 受信バッファの総量 受信バッファの総量 A AB B CC 2004/2/20 D D 15
© Copyright 2024 ExpyDoc
