核融合科学研究所 計算機・情報ネットワークセンター 山本 孝志

Presentation on theme: "核融合科学研究所 計算機・情報ネットワークセンター 山本 孝志"— 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., …

5 距離・速度積の比較 （データレゼボワール プロジェクトより）
2005年12月 NIFS－京都大 180km x 630Mbps = 113.4Tbm/s

6 問題点 SuperSINET 1Gbpsの回線を生かしきれない。 TCP/IPのAck応答に起因する普遍的な問題。
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 SACK Timestamp 最近のOSは、ほぼ対応済み。
2^16(64kB)以上に対応させる。 SACK 欠落データを個別に指定 Timestamp RTTの計測 最近のOSは、ほぼ対応済み。 ACK SACK op.

10 Window Size Window Sizeを大きくしましょう。 でも、だめじゃない。 Linux Windows
/etc/sysctl.conf Windows Dr. TCP でも、だめじゃない。 # increase TCP max buffer size net.core.rmem_max = net.core.wmem_max = # increase Linux autotuning TCP buffer limits # min, default, and max number of bytes to use net.ipv4.tcp_rmem = net.ipv4.tcp_wmem = # 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=

11 実際のWindow = min(awin, cwin)
ウィンドウサイズ 告知ウィンドウサイズ (awin) 輻輳ウィンドウサイズ (cwin) 実際のWindow = min(awin, cwin) advertised window, congestion window % sudo tcpdump tcp port smtp 07:39: IP A > B.smtp: S 0:0(0) win 8760 <mss 1460> 07:39: 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, SC2003 cf. Comet Project

15 輻輳制御の開発 輻輳回避アルゴリズムの改良
AIDM； additive increases multiplicative decreases x = x + α(x) 順調なとき x = (1 – β)x　パケットロス発生 α β Standard (Reno) 1/x 0.5 Scalable TCP 0.01 0.125 HighSpeed TCP Ta(x) Tb(x) Hamilton TCP fa(x) fb(x) Bic TCP slow startの改良 Vegas RTTで調節 Fast TCP Vegasの改良 Binary Increase Control TCP x = cwin テーブル： Ta(x), Tb(x) 関数： fa(x), fb(x)

16 輻輳制御アルゴリズムの比較例 JGNテストベット SLAC
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 UDPの例 UDPを使う？ UDT （UDP-Based Data Transfer Protocol）
「結局TCPの焼き直しになる」と言われているが UDT （UDP-Based Data Transfer Protocol） SABULの後継 UDP Socket API UDT Socket API UDT Applications 汎用的な開発環境(Configurable Congestion Control; CCC)も公開。 900Mbps (1Gbp, RTT=100ms)

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

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

20 今後の研究について

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

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

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

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

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

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

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

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

29 参考：一般的なテクニック TCP Tuning Guide

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