1 / 31

広帯域高遅延ネットワーク 伝送技術

広帯域高遅延ネットワーク 伝送技術. 核融合科学研究所 計算機・情報ネットワークセンター 山本 孝志. 2006 年 2 月 28 日 「核融合実験のデータ処理に関する次世代システム技術の検討」. 自己紹介. 核融合科学研究所 計算機・情報ネットワークセンター 1997 年 10 月に赴任 業務: ネットワーク管理とセキュリティ管理 ワクチン、ファイヤウォール、 DHCP 登録、同講習会 4 年前から非常勤講師を始める 大同工大 情報工学科 やっと C 言語がわかってきた. 確認君 1 号 近影. 概 要. 何が問題なのか どのような対策が開発されたか

sugar
Download Presentation

広帯域高遅延ネットワーク 伝送技術

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 広帯域高遅延ネットワーク伝送技術 核融合科学研究所 計算機・情報ネットワークセンター 山本 孝志 2006年2月28日 「核融合実験のデータ処理に関する次世代システム技術の検討」

  2. 自己紹介 • 核融合科学研究所 • 計算機・情報ネットワークセンター • 1997年10月に赴任 • 業務:ネットワーク管理とセキュリティ管理 • ワクチン、ファイヤウォール、DHCP登録、同講習会 • 4年前から非常勤講師を始める • 大同工大 情報工学科 • やっとC言語がわかってきた 確認君1号 近影

  3. 概 要 • 何が問題なのか • どのような対策が開発されたか • TCP base • UDP base • では、どうやって研究を進めるか • 実機、シュミレーション

  4. 世界記録 • Internet 2 Land Speed Record • 8 Gbps • 32,000km, RTT = 500ms • Seattle - Tokyo - Chicago - Amsterdam - Seattle • 東大, WIDE, Chelcio Comm., … • http://data-reservoir.adm.s.u-tokyo.ac.jp/lsr-20051110/

  5. 2005年12月 NIFS-京都大 180km x 630Mbps = 113.4Tbm/s 距離・速度積の比較(データレゼボワール プロジェクトより) http://data-reservoir.adm.s.u-tokyo.ac.jp/press/lsr-20041225-j/graph-j.png http://data-reservoir.adm.s.u-tokyo.ac.jp/lsr-20051110/

  6. 問題点 • SuperSINET 1Gbpsの回線を生かしきれない。 • SNET 100Mbp以下? • ルータには何の問題もありませんよ (by NII) • TCP/IPのAck応答に起因する普遍的な問題。 • Long Fat pipe Network: LFN

  7. ACK (LAN) スライディングウインドウ 傾きは光速

  8. ACK (WAN) NIFS – Kyoto Univ.: RTT=10ms, 1Gbps*10ms /8 = 1.25MB Window=10 良好 スカスカ

  9. TCP/IP のオプション • Window Scale • 2^16(64kB)以上に対応させる。 • SACK • 欠落データを個別に指定 • Timestamp • RTTの計測 最近のOSは、ほぼ対応済み。 ACK SACK op.

  10. Window Size • Window Sizeを大きくしましょう。 • Linux • /etc/sysctl.conf • Windows • Dr. TCP • でも、だめじゃない。 # increase TCP max buffer size net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 # increase Linux autotuning TCP buffer limits # min, default, and max number of bytes to use net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 # turn on window scale and timestamp option HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323=3 # set default TCP window size (default = 16KB) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize=131400 # and maybe set this too: (default = not set ) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\GlobalMaxTcpWindowSize=16777216

  11. ウィンドウサイズ • 告知ウィンドウサイズ (awin) • 輻輳ウィンドウサイズ (cwin) 実際のWindow = min(awin, cwin) % sudo tcpdump tcp port smtp 07:39:18.686 IP A.49110 > B.smtp: S 0:0(0) win 8760 <mss 1460> 07:39:18.689 IP B.smtp > A.49110: S 0:0(0) ack 1 win 5840 <mss 1460> ジャンボフレームMTU: 9000バイト

  12. 輻輳回避 • TCPは、他との通信の公平性を保つため、ウインドウサイズを調整して輻輳回避を行う。 • Tahoe • Reno • New Reno • Vegas P. loss

  13. 輻輳回避(WAN) 1.Gigabitクラスのバーストに耐えられない 2. 回復に予想以上の時間がかかる。 1時間以上との報告例もあり。

  14. バースト対策 • レートコントロールをする。 • PAUSEパケットを入れてデータの転送速度を抑制する。 • PAUSEパケットは HUBで捨てられる。 • 7Gbps (8.2Gbps, RTT=350ms, 24,000km, 日米1往復半) @ SC2003 cf. Comet Project http://www.comet-can.jp/

  15. 輻輳制御の開発 • 輻輳回避アルゴリズムの改良 • AIDM; additive increases multiplicative decreases • x = x + α(x) 順調なとき • x = (1 – β)x パケットロス発生 x = cwin テーブル: Ta(x), Tb(x) 関数: fa(x), fb(x)

  16. 輻輳制御アルゴリズムの比較例 • JGNテストベット • SABUL > FAST > Scalable, HS-TCP, p-Standard > Standard • 鶴他、ITRC-14, 2003年11月 • SLAC • Bic-TCPがよい。FASTは最もよいが、逆向きの流れによる劣化が激しい。 • Hadrien Bullot, et. at, J. Grid Computing, Dec 2003

  17. Applications UDT Socket API UDT Socket API UDP UDPの例 • UDPを使う? • 「結局TCPの焼き直しになる」と言われているが • UDT (UDP-Based Data Transfer Protocol) • SABULの後継 • 汎用的な開発環境(Configurable Congestion Control; CCC)も公開。 • 900Mbps (1Gbp, RTT=100ms)

  18. Sender Sender データ 2 1 2 1 2 1 Receiver Receiver 制御 UDT A UDT B UDT • レートコントロール • 連続した2つのパケットより帯域幅を推測 • パケット単位に番号を打ち、ACK, NAKを受ける。 • いずれもUDPを利用。 TCPへの影響が若干大きい (帯域を奪う)

  19. その他 • 複数のTCPセッションを利用する。 • bbftp • GridFTP (socket sizeの自動交渉も行う?) • PSockets (並列TCPのAPI, C++) • ルータの変更が必要 • TCPプロトコルの置き換え • XCP; eXplicit Congestion control Protocol • ECNを出す(らしい) • ジャンボフレーム

  20. 今後の研究について

  21. 目的 • SuperSINETの有効利用 • SNET: LHD実験データ、シュミレーション • 世界標準

  22. 何を対象にするか • 輻輳制御方式を比較する • TCP base & UDP base • 当面、開発の容易さから Linux。 • Windows Server 2003 ? • FreeBSD, Mac OS X • UDT/CCC

  23. Linux? • Linux kernelのソースを読む • ネットワークのところだけでも • 実装する際には必須 • 何かつかめるはず。 • つかめなければ、… • kernel >= 2.6.13で対応済み • Reno • Vegas • BIC-TCP • HSTCP; HighSpeed TCP • HTCP; Hamilton TCP • STCP; Scalable TCP • Hybla • Westwood

  24. 計測・実測環境 • 実環境での測定 • SuperSINETを利用する • PCルータで遅延を模擬する • dummynet on FreeBSD • Google: dummynet gigabit  11件 • 自分でソケットプログラミングをする on Linux • 本当にできるの? • シュミレーション • Network Simulator 2: NS-2 C++ & Otcl cf. http://www.isi.edu/nsnam/ns/

  25. Long Fat Pipe Network LFN L ab Backborn Short Fat Pipe Network LAN T. Yamamoto

  26. LFN研究室 端末 A PCルータ 端末 B Mother: Intel(R) Server Board SE7520JR2 CPU: 2.80DGHz X2 Memory: 2.0GB HD: SATA 120GB, 7200rpm NIC: on board X2 細々と構築中

  27. 計画は? 3年計画 • 18年度 前半 実装、模擬実験 • ラック装荷から遅延エミュレータの開発まで • Which is best ? • 19年度?SuperSINETのどこかと実験 • 全くの未定 • 20年度? 新方式の開発、実装。 • やはり全くの未定

  28. 御清聴ありがとうございました。

  29. 参考:一般的なテクニック • TCP Tuning Guide • http://dsd.lbl.gov/TCP-tuning/

  30. 参考:評価方法 • もちろん、帯域を有効に使っているかどうか • あと、公平性 • 特定のストリームが有利になっていないか • RTTの違い, 同じ方式内、他の方式の違い • Ethernetはベストエフォート • FDDI (Token方式)は原理的に公平。

  31. Linuxの対応(詳細) • アルゴリズムを簡単に切り替えられます。(kernel >= 2.6.13) sysctl -w net.ipv4.tcp_congestion_control = htcp reno: Traditional TCP used by almost all other OSes. (default) bic: BIC-TCP highspeed: HighSpeed TCP: Sally Floyd's suggested algorithm htcp: Hamilton TCP hybla: For satellite links scalable: Scalable TCP vegas: TCP Vegas westwood:optimized for lossy networks

More Related