Download - HPCユーザが知っておきたいTCP/IPの話 ~クラスタ・グリッド環境の落とし穴~
HPCユーザが知っておきたいTCP/IPの話
~クラスタ・グリッド環境の落とし穴~
産業技術総合研究所情報技術研究部門高野 了成
2009年5月29日 SACSIS2009チュートリアル
HPCユーザとTCP/IP
2
限界までネットワーク性能を出したい!
• グリッド環境で性能が出ないと悩んでませんか?• 例)長距離大容量データ転送(帯域 1 Gbps、
RTT 100ミリ秒)におけるチューニング
• デフォルト設定だとスループットは240 Mbps ☹
• 各種チューニングにより940 Mbps ☺
(2)
HPCユーザとTCP/IP
限界までネットワーク性能を出したい!
• Ethernetで安価にPCクラスタを組めたが、性能も それなりと割り切っていませんか?
• 例)TCP/IPが苦手とする間欠通信の改善 (2秒ごとに10MBのデータの連続送信の繰り返し)
3
0
200
400
600
800
1000
0 100 200 300 400 500 600
Band
wid
th (M
bps)
Time (msec)
160ミリ秒
0
200
400
600
800
1000
0 100 200 300 400 500 600
Band
wid
th (M
bps)
Time (msec)
x3.5
(2)
チュートリアルの目的• クラスタ・グリッド環境でTCP/IPの通信性能を引き出すポイントの理解
• 長距離大容量データ転送• MPI並列通信
• TCP/IP、特にTCP輻輳制御の仕組みの理解
• 標準TCP(Reno [RFC2851])
• 最近の高速TCP(CUBIC、Compound TCP)
4
(3)
発表の流れ
• 標準TCP/IPの基本
• TCP/IPと長距離大容量データ転送
• 高速TCP輻輳制御アルゴリズム
• TCP/IPとMPI並列通信
• その他のチューニング方法• TCP/IPをよりよく知るためのツール
• まとめ
5
(4)
標準TCP/IPの基本
(5)
TCP (Transport Control Protocol)
•コネクション指向で、信頼性のある バイトストリーム型通信の提供
•通信相手やネットワークの混雑状況にあわせた、自律的な送信レート制御
7
フロー制御、輻輳制御
再送制御
(6)
標準TCPの基本(対象範囲)
• 再送制御• 再送タイムアウト• 高速再送• SACK
8
• 送信レート制御• フロー制御• 輻輳制御• スロースタート• 輻輳回避• ACKクロッキング
(7)
TCPデータ処理の流れ(1)• データはセグメントに小分けして送受信• 送信者:シーケンス番号を付加• 受信者:「次に受信したい」シーケンス番号を
ACK番号に持つACKを返信
• 再送に備えて、セグメントはACKが届くまで再送キューに保持
ACK送信
送信データ 受信データ#4 #2 #1
9
RTT (Round Trip Time)
#3
#2
#5
#6#5#3 #4
※シーケンス番号はバイト単位だが、 簡単のため(1セグメント)=(1シーケンス)とする
(8)
再送キュー
#5 #1
再送機構• 再送タイムアウト(RTO):
• 一定時間(RTT+α)でACKが届かなければ再送
• 高速再送:• 重複ACKを連続で3回受信すると再送
• 1 RTTで破棄を検出可能(RTOより「+α」分高速)
ACK送信
送信データ 受信データ
再送キュー
#4
#3
#2 #1
#3#3#2
破棄
重複ACK
10
RTT (Round Trip Time)
#3#5
(9)
TCPデータ処理の流れ(2)
• ウィンドウベースの送信レート制御• ACKが届くまでに(1 RTT期間内)、送信ウィンドウ分のデータを送信
ACK送信
送信データ 受信データ
再送キュー
#7 #5
11
RTT (Round Trip Time)
#6
#2
#8
#5#3 #4
送信ウィンドウ
送信レート=送信ウィンドウ/RTT
#8 #1#4 #1
(10)
#9
TCPにおける送信レート制御• フロー制御• 「通信相手の処理速度」に合わせた制御
• 輻輳制御• 「ネットワークの混雑状態」に合わせた制御
12
ネットワーク
送信者 受信者
輻輳制御
フロー制御
輻輳:過負荷によりネットワーク利用率が低下すること
(11)
フロー制御• 「通信相手の処理速度(受信バッファサイズ)」にあわせて送信レートを制御
➡広告ウィンドウ(rwin)
• 受信者がACKと共に空きバッファ量を通知
• 空きバッファ量が減少するとrwinが縮小
13
(13)
ACK送信
送信データ受信データ
再送キュー
#7 #5
RTT (Round Trip Time)
#6
#2
#8
#5#3 #4
送信ウィンドウ
#8 #1#4#3
rwin#9
輻輳制御の必要性• 狭帯域回線の存在や複数回線の多重化により、ボトルネックとなる回線の手前のルータで輻輳が発生
• 入出力の速度差はルータのバッファで吸収• キュー長が一定長を超えると、受信セグメントを破棄(バッファあふれ)
➔ 輻輳崩壊を回避するために輻輳制御が必要
14
ルータ
帯域(B) 帯域(B/2)
送信時間(T) 送信時間(2T)
バッファあふれ#1#2#3#5 #4 #1#2#4#7 ... #3
(-)
輻輳制御• 「ネットワークの混雑状況」にあわせて送信レートを制御➡輻輳ウィンドウ(cwnd)
• 送信者が帯域見積もり手法を使って推測• 輻輳発生時にはcwndを小さくして輻輳を抑制
15
(14)
ACK送信
送信データ受信データ
再送キュー
#7 #5
RTT (Round Trip Time)
#6
#2
#8
#5#3 #4
送信ウィンドウ
#8 #1#4#3
rwin#9
ネットワークの利用可能帯域(cwnd)
輻輳ウィンドウ制御(1)
16
• 未知の利用可能帯域をいかに正確かつ迅速に求めるか?• パケットロスを起こすまで、cwndを拡大
• 2つのフェーズ:スロースタートで素早くあたりを付け、輻輳回避で徐々に拡大
cwnd
time
ssthresh(スロースタート閾値)
スロースタート(指数的増加)
輻輳回避(線形的増加)
w
w/2
パケットロス パケットロス パケットロス
(15)
パケットロス パケットロス パケットロス
輻輳ウィンドウ制御(2)
cwnd
time
ssthresh(スロースタート閾値)
スロースタート(指数的増加)
輻輳回避(線形的増加)
高速再送 再送タイムアウト
17
• 再送タイムアウト:cwndを最小値まで縮小し、 スロースタートから再開
• 高速再送:cwndを半分に縮小
• 理由:早い段階で輻輳検出→より軽微な輻輳
高速再送w
w/2
(16)
二つのウィンドウ制御• 広告ウィンドウ(rwin):ACKのTCPヘッダ
• 輻輳ウィンドウ(cwnd):内部変数
‣送信ウィンドウとして、両者の小さい方を使用
18
(12)
ACK送信
送信データ受信データ
再送キュー
#7 #5
RTT (Round Trip Time)
#6
#2
#8
#5#3 #4
#8 #1#4#3
rwin#9
送信ウィンドウ=min(cwnd, rwin)
ネットワークの利用可能帯域(cwnd)
輻輳制御
フロー制御
ACKクロッキング(1)• 送信ウィンドウのセグメントを一度に送信するのではなく、RTT内で均一に送信
• バースト送信によるバッファあふれの回避
19
送信ウィンドウ
ルータボトルネックリンク
ACKクロッキングなし:
ACKクロッキングあり:
バッファあふれバースト送信
(17)
ACKクロッキング(2)• 送信ウィンドウのセグメントを一度に送信するのではなく、RTT内で均一に送信
• バースト送信によるバッファあふれの回避• ACK受信を「クロック」としてセグメントを送信
• ボトルネックにあわせてセグメント送信間隔が平滑化
20
(1) data回線速度に合わせて、到着間隔が広がる
(2) ACK
(17)
TCP/IPと長距離大容量データ転送
(34)
広域ネットワークのTCP性能
• RTTが100ミリ秒のギガビットネットワークにおいて、輻輳がないにもかかわらず、 スループットが240 Mbpsしか得られなかった
22
S R
帯域: 1 Gbps RTT: 100ミリ秒
GbE GbE
問題の原因:輻輳ウィンドウサイズ不足
(35)
帯域遅延積
• (帯域)×(遅延):ネットワークパイプの容量• 例)帯域が1Gbps、片道伝送遅延が50ミリ秒(RTTが100ミリ秒)の場合は6.25MB
帯域:1 Gbps
片道伝送遅延: 50ミリ秒
1 Gbps x 50ミリ秒 = 50 Mbit = 6.25 MB
23
ネットワーク帯域をすべて使い切るには、送信ウィンドウは帯域遅延積の2倍以上必要である
(36)
ソケットバッファチューニング• 帯域遅延積の2倍(帯域 x RTT)必要
• 1 Gbps × 50ミリ秒 x 2 = 12.5 MB
• 送信側と受信側それぞれで設定が必要• デフォルトの最大ソケットバッファサイズは4MB
24
送信ソケットバッファ:(送信キュー)+(再送キュー)
送信データ 受信データ
再送キュー
RTT (Round Trip Time)
送信ウィンドウ
受信ソケットバッファ:(受信キュー)+(out-of-orderキュー)
6.25MB 6.25MB
12.5MB
(37)
TCPパラメータの設定
•システム全体の設定‣sysctl コマンド
•ソケット(コネクション)ごとの設定‣ソケットAPI
25
(-)
sysctl パラメータ(net.*の一部)
sysctl 意味 default
net.core.rmem_default 受信バッファサイズのデフォルト値 109568
net.core.rmem_max 受信バッファサイズの最大値 131071
net.core.wmem_default 送信バッファサイズのデフォルト値 109568
net.core.wmem_max 送信バッファサイズの最大値 131071
net.core.netdev_max_backlog プロセッサごとの受信キューサイズ 1000
net.ipv4.tcp_rmem TCP受信バッファサイズ [min, default, max] 4096, 87380, 4194304
net.ipv4.tcp_wmem TCP送信バッファサイズ [min, default, max] 4096, 16384, 4194304
net.ipv4.tcp_mem 利用可能ページ数 [low,pressure, high] 98304, 131072, 196608
net.ipv4.tcp_no_metrics_save メトリクス保存の無効化 0
net.ipv4.tcp_sack SACK 1
net.ipv4.tcp_congestion_control TCP輻輳制御アルゴリズム cubic
※バッファサイズの初期値は、メモリ搭載量によって変わる(上表は1GBメモリ搭載の場合)26
(39)
sysctl コマンド• カーネルの実行時パラメータを変更するコマンド
• (Linux)procfs経由でも同様の操作が可能
• その他の操作
$ sysctl net.core.wmem_maxnet.core.wmem_max = 131071
# sysctl -w net.core.wmem_max=1048576net.core.wmem_max=1048576
$ sysctl -p # 設定ファイル(/etc/sysctl.conf)の再読込み$ sysctl -a | grep tcp # 現在の設定の確認
$ cat /proc/sys/net/core/wmem_max131071
# echo 1048576 > /proc/sys/net/core/wmem_max
27
(38)
自動バッファサイズチューニング
※受信バッファも同様
TCP(送信側)の場合:
net.ipv4.tcp_wmem[0](4KB)
tcp_wmem[1](16KB)
tcp_wmem[2](4MB)
min default maxメモリ圧迫
メモリ利用可能(cwnd拡大)
• (Linux)メモリ使用状況に応じた、ソケットバッファサイズの動的調整
• 帯域遅延積が大きい場合は、tcp_wmemとtcp_rmemの最大値を大きく設定する必要
• デフォルト設定ではcwndが4MBで頭打ち
28
(41)
ソケットAPI• コネクション単位の設定• setsockopt(2)で取得、getsockopt(2)で変更
• SO_SNDBUFで明示的にバッファサイズが設定された場合、自動チューニングは無効化
• SO_SNDBUFの上限はnet.core.wmem_max
int ssiz; /* send buffer size */cc = setsockopt(so, SOL_SOCKET, SO_SNDBUF, &ssiz, sizeof(ssiz));
socklen_t optlen = sizeof(csiz);cc = getsockopt(so, SOL_SOCKET, SO_SNDBUF, &csiz, &optlen);
レベル オプション 意味SOL_SOCKET SO_SNDBUF 送信バッファサイズSOL_SOCKET SO_RCVBUF 受信バッファサイズ
29
(40)
setsockopt関数の注意点
• listen、connect関数よりも前に実行する必要
• (Linux)引数値の2倍に自動的に設定
• man tcp(7)によると、「TCP はこの余分な空間を、 管理目的やカーネル内部の構造体に用い」るため
$ iperf -w 1m -c 192.168.0.2------------------------------------------------------------Client connecting to 192.168.0.2, TCP port 5001TCP window size: 2.00 MByte (WARNING: requested 1.00 MByte)------------------------------------------------------------
30
Iperfベンチマークの警告メッセージ
(42)
ソケットバッファ設定後
31
0
100
200
300
400
500
600
700
800
900
1000
0 10 20 30 40 50 60
Band
wid
th (M
bps)
Time (Second)
sndbuf=12.5MB
• ソケットバッファを適切に設定しても、性能の立ち上がりが緩慢
• 輻輳が起きないはずなのに、輻輳回避の挙動?
帯域: 1 Gbps RTT: 100ミリ秒 TCP: CUBIC
(期待するカーブ)
(43)
0
100
200
300
400
500
600
700
800
900
1000
0 10 20 30 40 50 60
Band
wid
th (M
bps)
Time (Second)
sndbuf=12.5MB txqueuelen=10000sndbuf=12.5MB
インタフェースキューあふれ
32
• インタフェースキュー:QoS制御などに使用される、 NICごとの送信キュー
• インタフェースキューあふれは輻輳と判定• 帯域遅延積が大きい場合、キュー長の拡大が必要
プロトコルスタック
NIC
インタフェースキュー
NIC: Network Interface Card
(44)
インタフェースキュー長• インタフェースキューあふれはtcコマンドで確認
• ifconfigを用いて、キュー長を設定可能$ ifconfig eth0eth0 Link encap:Ethernet HWaddr 00:22:64:10:cc:9d inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::222:64ff:fe10:cc9d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:795673 errors:0 dropped:0 overruns:0 frame:0 TX packets:163559 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:72212519 (72.2 MB) TX bytes:29126498 (29.1 MB) Interrupt:17 $ ifconfig eth0 txqueuelen 10000
33
$ tc -s qdisc show dev eth0qdisc pfifo_fast 0: root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 41825726768 bytes 1383455 pkt (dropped 72, overlimits 0 requeues 25164) rate 0bit 0pps backlog 0b 0p requeues 25164
(45)
netstat -s
• プロトコルごとの統計情報の取得• 標準的なLinuxには同梱(net-toolsパッケージ)
$ netstat -s[snip]Tcp: 49 active connections openings 4925 passive connection openings 56 failed connection attempts 12 connection resets received 1 connections established 226842 segments received 161944 segments send out 210 segments retransmited 1 bad segments received. 575 resets sent[snip]
TcpExt: 55 resets received for embryonic SYN_RECV sockets 108 TCP sockets finished time wait in fast timer 10969 delayed acks sent Quick ack mode was activated 67 times 7961 packets directly queued to recvmsg prequeue. 43 bytes directly received in process context from prequeue 69443 packet headers predicted 11162 acknowledgments not containing data payload received 110524 predicted acknowledgments 4 times recovered from packet loss by selective acknowledgements 37 congestion windows recovered without slow start after partial ack 4 TCP data loss events 6 timeouts after SACK recovery 1 timeouts in loss state 5 fast retransmits 5 retransmits in slow start 167 other TCP timeouts[snip]
34
セグメント送受信数
再送数
輻輳検出数
(71)
高速TCP輻輳制御アルゴリズム
(46)
広帯域ネットワークでの問題点• 標準TCPでは、帯域遅延積に対してcwndが小さすぎて、ネットワーク利用効率が低下
• 輻輳回避でのcwndの拡大が緩慢
• 当初の設計時の想定は、せいぜい数十パケット程度
36
帯域 1Gbps、RTT 200ms、MTU 1500Bの場合
8000パケット
8000 RTT ≒ 27分
16000
Time
cwnd
巨大な未使用帯域
輻輳回避
(47)
対応策• 複数コネクションの利用• PSockets、GridFTP、(BitTrrent Swarming)
• 輻輳制御アルゴリズムの改良• 輻輳回避• 帯域遅延積小:既存TCPと公平に(TCP Friendly)
• 帯域遅延積大:アグレッシブに(スケーラビリティ)• スロースタート• バースト送信への対応
37
(48)
• 公平:コネクション間の送信レートが等しいこと• 効率の追求だけではなく公平性を保つことも重要
• プロトコル間公平性(Inter-protocol fairness)
• TCP Friendliness:標準TCPとの公平性
• プロトコル内公平性(Intra-protocol fairness)
• RTT公平性:RTTが異なるコネクション間の公平性
• RenoはRTTが短い方が有利
公平性
38
(50)
TCP輻輳制御アルゴリズム
39
アルゴリズム 輻輳検出方法 備考NewReno
ロスベース(パケット破棄)
RFC 2852
HighSpeed TCP
ロスベース(パケット破棄)
RFC 3649
Scalable TCP ロスベース(パケット破棄)BIC
ロスベース(パケット破棄)
CUBIC
ロスベース(パケット破棄)
LinuxのデフォルトH-TCP
ロスベース(パケット破棄)
Vegas遅延ベース
(キューイング遅延の増加)Westwood+
遅延ベース(キューイング遅延の増加)
FAST
遅延ベース(キューイング遅延の増加)
Illinois
ハイブリッドYeAH ハイブリッドCompound TCP
ハイブリッドWindows Vistaのデフォルト
キューイング遅延≒輻輳RTT2 > RTT1
パケット破棄≒輻輳ロスベース: 遅延ベース:
(49)
CUBIC• スケーラビリティと通信の安定性の向上:パケット ロス時のcwnd(Wmax)まで素早く回復後、水平状態をしばらく維持し、さらに上限を探査
• RTT公平性の向上:cubic関数を基に、前回パケット ロス時からの経過時間によりcwndを計算
40
Time
Wmax
Wmin
cwnd
Steady state behavior Probing
Wcubic = C
�T − 3
�Wmaxβ
C
�3
+ Wmax
(51)
Compound TCP
• Windows Vistaの標準
• ロスベースと遅延ベースの ハイブリッド型アルゴリズム
• 遅延小:アグレッシブに• 遅延大:Reno互換
• 公平性に優れるが、他のプロトコルの影響を受けやすい
• dwndが0になりRenoに後退
41
loss-based (cwnd)
delay-based (dwnd)
cwnd + dwnd
loss free period
キューイング遅延(RTT)の増加を検出
Reno互換
+
=
(52)
「鈍感力」TCP• 輻輳制御しないTCP
• 常に最大送信レートで通信• 輻輳検出に関係なく輻輳ウィンドウを最大値で固定• 帯域遅延積を明示的に設定することも可能
• 広告ウィンドウも最大値で固定• 自動バッファサイズチューニングの影響を回避
• 公平性無視で、閉じたネットワークでの利用を想定• (実はHPCユーザが一番望む形のTCP?)
42
http://code.google.com/p/pspacer/wiki/DonkanTcp
(53)
スロースタートの問題• RTTごとに送信データ量は倍増
• 帯域遅延積が大きくなると、スロースタートは「スロー」ではなくアグレッシブ
• バースト送信により、大量のパケット破棄が発生 →帯域利用効率の著しい低下
S R
RTT: 200ミリ秒BW: 500 Mbps
GbE GbE
43
平均では500Mbps以下だが、バースト送信によりピークは1Gbpsに達し、バッファがあふれる
ルータ(スイッチ)で大量のパケット破棄
RTT: 200ミリ秒
(54)
スロースタートの改良
• Limited slow start [RFC 3742]• max_ssthresh < cwnd <= ssthreshの場合、RTTごとの
cwnd増加をmax_ssthresh/2に抑制
• Swift Start• Packet-pair probingによる帯域見積もりに基づいて、
ACKクロッキングするまでペーシング
• HyStart (Hybrid slow start)• 遅延ベースのアイデアを導入し、RTTの増加が閾値を超えたらスロースタートを終了
• (Linux 2.6.29)CUBIC使用時にデフォルト有効
44
(55)
TCP/IPとMPI並列通信
(18)
MPI通信におけるTCP性能の問題
• MPIの典型的アプリは、TCPが仮定するストリーム型のデータ転送(e.g.ファイル転送)とは異なる通信負荷
• 計算フェーズと通信フェーズの繰り返し• 突然、通信パターンが変化• 一対一通信と集団通信
46
Time Time
帯域
帯域 計算通信 計算通信 一対一全対全
一対一全対全
実験1 実験2
(19)
実験に用いたPCクラスタ環境
47
•CPU: Pentium4/2.4GHz•Memory: DDR400 512MB•NIC: Intel PRO/1000 (82547EI)•OS: Linux-2.6.9-1.6 (Fedora Core 2)•Socket buffer: 20MB
WANエミュレータ
GtrcNET-1
Node7
Host 0Host 0
Host 0Node0
Catalyst 3750
Node15
Host 0Host 0
Host 0Node8
Catalyst 3750
……
…
……
…8 PCs 8 PCs
(20)
実験1:間欠通信性能
48
•CPU: Pentium4/2.4GHz•Memory: DDR400 512MB•NIC: Intel PRO/1000 (82547EI)•OS: Linux-2.6.9-1.6 (Fedora Core 2)•Socket buffer: 20MB
WANエミュレータ
GtrcNET-1
Node7
Host 0Host 0
Host 0Node0
Catalyst 3750
Node15
Host 0Host 0
Host 0Node8
Catalyst 3750
……
…
……
…
RTT: 20 ms帯域: 500 Mbps
8 PCs 8 PCs
各クラスタから 1ノードずつを使用
2秒ごとに10MBデータの転送
(-)
間欠通信時のトラフィック
2秒ごとに10MBデータの連続 送信の繰り返し
• 理想的は160ミリ秒(10MB/500Mbps)で送信完了
• 通信アイドル後は、毎回スロースタートから再開するため、非効率
49
送信 送信 送信 送信
(部分拡大)
0
200
400
600
800
1000
0 2 4 6 8 10
Band
wid
th (M
bps)
Time (sec)
0
200
400
600
800
1000
0 100 200 300 400 500 600
Band
wid
th (M
bps)
Time (msec)
160ミリ秒 x3.5
(21)
通信アイドル後のスロースタート(1)• 一定時間通信を行わないと、スロースタートから再開• (Linux)RTO時間経過ごとにcwndが半減 [RFC 2861]
• MPIアプリケーションでは高頻度に発生
• HTTP/1.1のパイプラインでも同様の問題が発生
• (kernel 2.6.18以降)通信アイドル後のスロースタートを省略可能 net.ipv4. tcp_slow_start_after_idle=0
50
cwnd
time
ssthresh(スロースタート閾値)通信アイドル
期間スロースタート
輻輳回避
(22)
• 通信アイドル後にスロースタートする理由:• ネットワークの状況が変化する可能性• cwnd分のセグメントを一気に送ると、ACKクロッキングが働かずバースト送信が発生→輻輳の原因
51
ACK送信RTT (Round Trip Time)
cwnd
送信データ 受信データ
再送キュールータの
バッファあふれ
cwnd分のバースト送信
通信アイドル後のスロースタート(2)(23)
通信再開時ペーシング• ACKクロッキングの代わりに、高精度タイマによるクロックを基に一定のペースでパケットを送信
• (ACKが届かない)最初のRTTだけ
• 送信間隔=RTT/cwnd
52
ACK送信RTT (Round Trip Time)
cwnd
送信データ 受信データ
再送キュー
RTT/cwnd 要カーネル改造
(24)
通信再開時ペーシングの効果
2秒ごとに10MBデータの連続 送信の繰り返し
• スロースタートを省略し、 アイドル前のcwndから再開
• さらに、バースト送信回避のため、通信再開時ペーシングを使用
53
0
200
400
600
800
1000
0 100 200 300 400 500 600
Band
wid
th (M
bps)
Time (msec)
0
200
400
600
800
1000
0 100 200 300 400 500 600
Band
wid
th (M
bps)
Time (msec)
通信再開時ペーシングなし
通信再開時ペーシングあり
(25)
実験2:全対全通信性能
54
•CPU: Pentium4/2.4GHz•Memory: DDR400 512MB•NIC: Intel PRO/1000 (82547EI)•OS: Linux-2.6.9-1.6 (Fedora Core 2)•Socket buffer: 20MB
WANエミュレータ
GtrcNET-1
Node7
Host 0Host 0
Host 0Node0
Catalyst 3750
Node15
Host 0Host 0
Host 0Node8
Catalyst 3750
……
…
……
…
RTT: 0 ms帯域: 1 Gbps
8 PCs 8 PCs
全16ノードを使用
(-)
全対全(All-to-all)通信• すべてのプロセス間でデータを交換する集団通信• MPIメッセージは複数セグメントに分割して送信
• 1プロセス1ノードを仮定
55
A0 A1 A2 A3
B0 B1 B2 B3
C0 C1 C2 C3
D0 D1 D2 D3
data
proc
ess A0 B0 C0 D0
A1 B1 C1 D1
A2 B2 C2 D2
A3 B3 C3 D3
A
C
B
Dフェーズ 1
1イテレーション内の通信パターンA
C
B
Dフェーズ 2
A
C
B
Dフェーズ 3
A
B
C
D
各ノードは全データを受信完了すると、次のイテレーションへ遷移
(29)
全対全通信時の輻輳• 全対全通信の繰り返し• スイッチでパケット喪失• 受信待ちのため、後続 パケットの送信が中断
• 連続した通信呼出しだが、トラフィックは間欠的
• 中断時間は約200ミリ秒
• 再送タイムアウトが発生56
0
200
400
600
800
1000
0 500 1000 1500 2000
Band
wid
th (M
bps)
Time (msec)
1ノード当たりの全対全送信帯域
32 KB
メッセージサイズ32KB時のトラフィック
0
50
100
150
200
250
0 200 400 600 800 1000
Band
wid
th (M
bps)
Message size (KB)
200ミリ秒
(理論性能:約230Mbps)
(28)
RTO発生の原因• 次の2つの条件が成立した場合にRTOが発生(1)メッセージの末尾パケットが破棄
(2)(1)がプロセスの組で発生
• TCPとメッセージ通信のセマンティクスギャップ?
57
フェーズ
イテレーション 1
2
1 2 3
A A
C
B
DC
B
D
A
C
B
D
プロセスA、Cは受信未完了のため、停止
C D
A B
D
A
D
Aすべてのプロセスが
停止C
B
C
B
RTO発生
(30)
RTO時間の計算
• RTO = RTT + α(詳細は下式参照)
• α過大→再送遅れ
• α過小→無駄な再送の発生
• RTTが0ミリ秒でも、RTO時間は200ミリ秒以上!
SRTT: Smoothed Round Trip Time
RTO = SRTT + max(G, 4 x RTTVAR)
SRTT = (1 - β) x SRTT + β x RTT
RTTVAR = (1 - γ) x RTTVAR + γ x |SRTT - RTT|
β = 1/8, γ = 1/4, G = 200 msec
58
} スループットの低下
参考:RFC2988では、Gは1秒(RTT計測用のタイマの粒度が500ミリ秒と荒いから)
(31)
RTO時間短縮の効果
• 変更前:G = 200ミリ秒
• 変更後:G = 0ミリ秒
• (kernel 2.6.23以降) ip routeコマンドにより設定変更可能
59
0
200
400
600
800
1000
0 500 1000 1500 2000
Band
wid
th (M
bps)
Time (msec)
RTO時間短縮なし
0
50
100
150
200
250
0 200 400 600 800 1000
Band
wid
th (M
bps)
Message size (KB)
w/o RTO fixw/ RTO fix
0
200
400
600
800
1000
0 500 1000 1500 2000
Band
wid
th (M
bps)
Time (msec)
RTO時間短縮あり
32 KB
1ノード当たりの全対全送信帯域RTO = SRTT + max(G, 4 x RTTVAR)
(32)
全対全通信の考察• 小メッセージサイズ• バースト送信はスイッチのバッファで吸収
‣バッファサイズが大きい、 ノンブロッキングスイッチ
• 中メッセージサイズ• RTOが頻発
‣ RTO時間短縮が効果的
• 大メッセージサイズ• 確率的に末尾パケットの欠損が減るため、RTOは減少
60
0
50
100
150
200
250
0 200 400 600 800 1000
Band
wid
th (M
bps)
Message size (KB)
w/o RTO fixw/ RTO fix
1ノード当たりの全対全送信帯域
32 KB
(-)
MPI通信向けTCP/IPの改良
61
3つの変更点 対応する問題点通信再開時ペーシング 通信開始時における、スロー
スタートの省略ACKクロッキングの代用
RTO時間の短縮 再送タイムアウト時の待ち時間の短縮
通信パラメータ保存復元 通信パターンによる、急激なcwnd値の変化に対応
詳細は、松田他「MPIライブラリと協調するTCP通信の実現」, 情報処理学会論文誌コンピューティングシステム(ACS11), 2005
(33)
その他のチューニング方法
(65)
63
利用可能帯域に合わせてパケット間隔を平滑化(ペーシング)することで、パケットロスのない安定した通信を実現できる
バースト性トラフィックはパケットロスによる著しい性能劣化を引き起こす可能性がある
ペーシング技術バッファあふれ
(57)
PSPacer:ソフトウェアによる精密ペーシング機構
• 特別なハードウェアが不要で、ソフトウェアだけによる精密なペーシングの実現
• Linuxカーネルモジュールとして動作(OSの再インストールが不要で簡単に利用可)
• 産総研で開発し、GPLライセンスによるオープンソースソフトウェアとして公開
http://www.gridmpi.org/pspacer.jsp
64
詳細は、高野他「ギャップパケットを用いたソフトウェアによる精密ペーシング方式」, 情報処理学会論文誌コンピューティングシステム(ACS14), 2006
(58)
スロースタート時の効果• 目標レート(500Mbps)を超過するバースト送信が抑制され、パケットロスを回避
• スロースタートフェーズに限らず、送信レートを制限
PSPacerなし PSPacerあり(500Mbps)65
(63)
長距離TCP通信への適用
66
141 Mbps
394 Mbps
535 Mbps 980 Mbps
490 Mbps
490 Mbps
Sender
A
B
Receiver
C
D
1 GbpsRTT 200ms
w/o PSPacer w/ PSPacer
※Scalable TCPを使用
利用可能帯域と通信パターンが既知ならば、どんなに 長距離TCP通信であっても高い帯域利用効率を達成可能
(64)
67
PSPacerの10GbE対応
0
2
4
6
8
10
0 2 4 6 8 10
平均送信レート
(Gbp
s)
目標送信レート (Gbps)
PSPacer+HTB
目標送信レートを100Mbps刻みで設定し、Iperfを5秒間実行した平均送信レートをGtrcNET-10を用いて観測
HTB: Hierarchical Token Bucket(Linux標準の帯域制御モジュール)
PSPacerは10GbEでも、正確な帯域制御を実現
CPU: Quad-core Xeon (E5430) x 2NIC: Myricom Myri-10G (PCIe x 8) MTU: 9000 byteMemory: 4GB DDR2-667
(62)
実験の再現性
• 送信先ごとにメトリクス情報をキャッシュするので、実験ごとに初期値がばらばら
• 何を計測しているのかわからなくなる可能性• ipコマンドでキャッシュ内容の確認
• キャッシュの無効化
$ ip route show cached to 192.168.0.2192.168.0.2 from 192.168.0.1 dev eth1 cache mtu 9000 rtt 187ms rttvar 175ms ssthresh 1024 cwnd 637 advmss 8960 hoplimit 64
# sysctl -w net.ipv4.tcp_no_metrics_save=1net.ipv4.tcp_no_metrics_save=1
68
(66)
ジャンボフレーム• ネットワーク帯域を効率的に利用可能• ヘッダオーバヘッド削減によるスループットの向上
GbE:MTU 1500B → 949.3 Mbps
(Gb MTU 9000B → 991.4 Mbps
• 実装依存なので、“ping -M do”(IPフラグの“Don’t fragment” bitをonという意味)で疎通確認すること
$ ping -M do -s 9000 192.168.0.2PING 192.168.0.2 (192.168.0.2) 9000(9028) bytes of data.From 192.168.0.1 icmp_seq=1 Frag needed and DF set (mtu = 9000)From 192.168.0.1 icmp_seq=1 Frag needed and DF set (mtu = 9000)From 192.168.0.1 icmp_seq=1 Frag needed and DF set (mtu = 9000)
$ ping -M do -s 8972 192.168.0.2PING 192.168.0.2 (192.168.0.2) 8972(9000) bytes of data.8980 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=3.76 ms8980 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.127 ms8980 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=0.133 ms
69
NG
OK
(67)
イーサネットフロー制御• InfinibandやMyrinetのクレジットベースフロー制御との違い
• 一時的に特定の終端ノードに受信が集中した場合、 バッファあふれが発生
• イーサネットフロー制御(IEEE 802.3x)
• 受信バッファが閾値を超えたときに、PAUSEフレームを送信することで、対向の送信を一時中断
• ホストおよびスイッチの設定確認が必要$ sudo ethtool -A eth0 tx on rx on
$ sudo ethtool -a eth0Pause parameters for eth1:Autonegotiate: offRX: offTX: off
70
[参考]Lossless Ethernetが標準作業中
(68)
TCP/IPをよりよく知るためのツール
(69)
Rough consensus, running code
• 何が正しい挙動か迷ったらRFC?
• 標準はReno [RFC 2851]までで、多くは実装依存
• できるだけ新しいカーネルを使おう• net/ipv4以下に限ってもメジャーバージョン間で平均180個のパッチがコミット
• ただし、regressionなどの可能性があるので、 できる限り複数バージョンでチェック
• 例)BICのinit_ssthresh、ABCの性能バグ
• 結局ソースコードを追う羽目になる• 静態解析(エディタ)と動態解析の併用
72
(70)
Web100
• 米国Pittsburgh Supercomputing Center (PSC)などで開発
• コネクションごとにカーネル変数値がprocfs経由で 取得可能
• netstat -sよりも詳細な情報が取得可能 [RFC 4898]
• カーネルパッチが必要• システムの負荷が高いと、データ取得プロセスが スケジューリングされず、欲しいデータが取得できない場合があるので注意
http://www.web100.org/73
(72)
TCP Probe• KProbesを使って、TCP受信処理関数にプローブを挿入し、変数の値を取得する仕組み
• データはカーネル内部のバッファに格納され、後からprocfs経由で取得
• カーネルに同梱• 取得したい場所や変数に合わせて、カスタマイズしたモジュールを用意すると便利
74
(72)
TCP Probeの使い方
http://www.linuxfoundation.org/en/Net:TCP_testing
$ sudo modprobe tcp_probe port=5001$ sudo chmod 444 /proc/net/tcpprobe$ cat /proc/net/tcpprobe >/tmp/tcpprobe.out &$ TCPCAP=$!(通信の実行)
$ kill $TCPCAP
cwndとssthreshのプロット結果
75
(73)
まとめ(1)1. ソケットバッファサイズは帯域遅延積の2倍(帯域×RTT)以上必要(デフォルトは4MB)
2. setsockopt関数はlistenやconnect関数の前に実行
3. インタフェースキューあふれは輻輳とみなされるので、帯域遅延積の大きなネットワークでは、キュー長の拡大が必要
4. 高速TCPは公平性を保ちつつ、帯域利用効率の向上を追求。公平性を失った実装の使用はインタネットでは危険
5. 帯域遅延積が大きなネットワークでは、スロースタートはまったく「スロー」ではない。バースト送信の抑制には、ペーシングが効果的
76
(76)
まとめ(2)6. 間欠通信時の通信効率を上げるには、通信アイドル後の スロースタートの省略が有効(tcp_slow_start_after_idle)
7. さらに通信再開時のバースト送信を回避するには、 ペーシングが効果的
8. 集団通信時など、再送タイムアウト(RTO)の頻発による通信性能の低下には、RTO時間の短縮が有効
9. 実験の再現性を高めるために、ルーティングメトリクスのキャッシュを無効化
10.できるだけ新しいカーネルを使用し、できる限り複数バージョンで確認
77
(77)
予備資料
高性能TCP群雄割拠時代?
TCP輻輳制御の簡単な歴史NCP
TCP
IPv4
Tahoe
Vegas
FASTHSTCP
CompoundTCP
RenoRFC2851(standard)
NewRenoRFC2852
(experimental)
HTCPBIC
CUBIC
ScalableTCP
TCPRFC793
(standard)
ARPANETからインタネットへTCPとIPの分離 (1970年代後半)
輻輳崩壊の観測 (1986)
→輻輳制御の導入
79
関連RFCSpec. sysctl default
TCP (RFC 793) - -
Window scaling (RFC 1323) tcp_window_scaling 1
TImestamps option (RFC 1323) tcp_timestamps 1
TIME-WAIT Assassination Hazards (RFC 1337) tcp_rfc1337 0
SACK (RFC 2018, 3517) tcp_sack 1
Control block sharing (RFC 2140) tcp_no_metrics_save 0
MD5 signature option (RFC 2385) - -
Initial window size (RFC 2414) - -
Congestion control (RFC 2581) - -
NewReno (RFC 3782) - -
Cwnd validation (RFC 2861) tcp_slow_start_after_idle 1
D-SACK (RFC 2883) tcp_dsack 1
Limited transmit (RFC 3042) - -
Explicit congestion notification (RFC 3168) tcp_ecn 0
Appropriate Byte Counting (RFC 3465) tcp_abc 0
Limited slow start (RFC 3742) tcp_max_ssthresh 0
FRTO (RFC 4138) tcp_frto 0
Forward ACK tcp_fack 1
Path MTU discovery tcp_mtu_probing 0
80
参考URLProject URL
BIC/CUBIC http://netsrv.csc.ncsu.edu/twiki/bin/view/Main/BIC
FAST http://netlab.caltech.edu/FAST/
TCP Westwood+ http://c3lab.poliba.it/index.php/Westwood
Scalable TCP http://www.deneholme.net/tom/scalable/
HighSpeed TCP http://www.icir.org/floyd/hstcp.html
H-TCP http://www.hamilton.ie/net/htcp/index.htm
TCP-Illinois http://www.ews.uiuc.edu/~shaoliu/tcpillinois/
Compound TCP http://research.microsoft.com/en-us/projects/ctcp/
TCP Vegas http://www.cs.arizona.edu/projects/protocols/
TCP Westwood http://www.cs.ucla.edu/NRL/hpi/tcpw/
Circuit TCP http://www.ece.virginia.edu/cheetah/
TCP Hybla https://hybla.deis.unibo.it/
TCP Low Priority http://www.ece.rice.edu/networks/TCP-LP/
UDT http://www.cs.uic.edu/~ygu1/
XCP http://www.ana.lcs.mit.edu/dina/XCP/
Web100 http://www.web100.org/
TCP Probe http://www.linuxfoundation.org/en/Net:TcpProbe
iproute2 http://www.linuxfoundation.org/en/Net:Iproute2
81
バックアップ
0
200
400
600
800
1000
-1 0 1 2 3 4
Band
wid
th (M
bps)
Time (sec)
通信パターン変化時のトラフィック
全対全:帯域を共有
一対一:帯域を占有
• cwndが小さな値から大きな値へ移行(50→600以上)
• 移行時間は輻輳回避フェーズのアルゴリズム依存 (BIC TCPを使用)
83
全対全 一対一
時刻0まで全対全通信時刻0から一対一通信を開始
cwnd=50
cwnd=600
通信パラメータ保存復元の効果
• 保存復元なしの場合:cwnd=49で通信再開
• 保存復元ありの場合:cwnd=582で通信再開
• 一対一通信と集団通信でパラメータ(ssthresh)を独立に保持
• 通信パターン変更時に、ペーシングを用いて通信 再開
84
0
200
400
600
800
1000
0 0.5 1 1.5 2 2.5 3 3.5 4
Band
wid
th (M
bps)
Time (sec)
0
200
400
600
800
1000
0 0.5 1 1.5 2 2.5 3 3.5 4
Band
wid
th (M
bps)
Time (sec)
通信パラメータ保存復元なし
通信パラメータ保存復元あり
有用なツール• パケットダンプ• tcpdump
• Wireshark (a.k.a. Etherreal)
• 統計情報の取得• netstat
• Web100
• TCP Probe
• ネットワークエミュレーション• netem
85
自己紹介(過去の研究)
•「高性能通信」をキーワードにOSからHPC分野で研究開発に従事
• 1996-2001 マルチメディア処理向けOS
• 2002-2004 高性能ストリーミングサーバ
• 2003- グリッド環境向け並列通信ライブラリ
• 2003- 長距離TCP/IP通信向け高性能通信機構
• 2008- 性能保証型分散資源管理システム
86
輻輳制御とは?• 輻輳:過負荷によりネットワーク利用率が低下すること• 輻輳制御:競合する送信者間でネットワーク帯域を共有するアルゴリズム
• 終端ノードによる輻輳制御:TCP
• 中継ノードによる輻輳制御:REDなどのAQM、ECN
87
ルータ
多重化
トラフィック送信者
RED: Random Early DetectionAQM: Active Queue ManagementECN: Explicit Congestion Notification
End-to-end原則
• インタネットの柔軟性と拡張性の源泉• エラー訂正など複雑な処理は終端ノードで• ネットワークは極力単純に
• 終端ノードが自律的に輻輳制御することで、ネットワーク全体の安定を目指す
• 輻輳制御を困難にしている側面もある• cf. ECN (Explicit Congestion Notification)など、 中間ノードによる輻輳シグナルの通知が提案されているが、普及していない
88
選択確認応答(SACK)
1 2 3 4 5 6 7 9 10 11 13 15 16
シーケンス番号(1)累積確認応答 受信した
セグメント
損失したセグメント累積確認応答
1 2 3 4 5 6 7 9 10 11 13 15 16
シーケンス番号(2)選択確認応答
累積確認応答 選択確認応答
セグメント8の損失しか通知できない
TCPヘッダのオプションフィールドを使い、歯抜け状の損失を通知できる(最大4個)
89
重複ACKによる高速再送
• 重複ACK(同じACK番号)を3回以上連続で受信すれば、再送する
• 1 RTTにたかだか一つのパケットロスしか検出できない
• ウィンドウサイズが大きくなり、歯抜け状にパケットが損失すると、性能の劣化は避けられない
X
RTT
1R
TT2
101112131415
101617
99999
151617
90
再送タイムアウト(1)
• もっとも保守的な再送制御• 一定時間内に確認応答がなければ再送• 「確認応答が返ると予想される時間(RTO時間)」にタイマを設定し、タイムアウトすると再送
RTO: Retransmission TimeOut
RTT: Round Trip Time
ACK
data data
RTT RTOX
再送
正常時 セグメント欠損時91
ACK受信時 輻輳検出時
AIMD (Additive Increase Multiplicative Decrease)
• cwndを少しずつ拡大し、一気に縮小する制御アルゴリズム
• α: 増加レート、β: バックオフ因数
Reno: α=1, β=0.5
time
cwnd
w/2w
92
cwnd← (1− β)cwndcwnd← cwnd +α
cwnd
輻輳回避
RTT
93
Example of Growth Functions
Win
dow
Siz
e STCP
CUBIC
HTCPHSTCP
Time
BIC
引用:H.Cai, et al., “Stochastic Ordering for Internet Congestion Control,” PFLDnet2007
線形 2乗
3乗
指数 対数&指数
高速TCPのcwnd制御
スライディングウィンドウ
#1 #2 #3 #4 #5 #6 #7 #8
確認応答済 未送信確認応答待ち
シーケンス番号
時間
セグメントの状態:
送信ウィンドウ(=4)
セグメントが新しく確認応答されると、送信ウィンドウが右にスライドし、送信可能なセグメントが増える
(送信バッファ管理)
94
#1 #2 #3 #4 #5 #6 #7 #8
#1 #2 #3 #4 #5 #6 #7 #8
セルフクロッキング
1Mbps 1Mbps100Kbps
1Mbps100Kbps
1Mbps
(1) data
(2) ACK(3) data
8ミリ秒
80ミリ秒
80ミリ秒
80ミリ秒80ミリ秒
回線速度に合わせて、到着間隔が広がる
ACK到着を送信の契機にすることで、送信レートが自動的に制御される
95
• ボトルネックリンクの速度に合わせて、送信レートを制御• バースト送信が抑制され、通信の安定化を実現
コネクション状態遷移CLOSED
LISTEN
SYN_RECV
ESTABLISHED
FIN_WAIT_1
FIN_WAIT_2
CLOSING
TIME_WAIT
SYN_SENT
CLOSE_WAIT
LAST_ACK
appl: listen()
recv: SYNsend: SYN, ACK
recv: ACK recv: SYN, ACKsend: ACK
recv: SYNsend: SYN, ACK
appl: connect()send: SYN
※一部の状態遷移は省略
recv: FINsend: ACK
appl: close()send: FIN
recv: ACK
2MSL timeout
recv: FINsend: ACK
recv: ACK recv: ACK
recv: FINsend: ACK
recv: FIN, ACKsend: ACK
active open
active close
passive open
passive close
96
コネクション確立(とソケット関数の対応)
(1) SYN (SeqNo=1000)
(2) SYN, ACK (SeqNo=200,AckNo=1001)
(3) ACK (AckNo=201)
パッシブオープン
(サーバ側)
fd=accept(lfd,...);
lfd=socket(...);bind(lfd,...);listen(lfd,...);
fd=socket(...);connect(fd,...);
※(2)ではSYNパケットにACKをピギーバックすることで同時送信している
SYN
_SEN
TES
TABL
ISH
ED
アクティブオープン
(クライアント側)
LIST
ENSY
N_R
CV
DES
TABL
ISH
ED
97
コネクション終了
(1) FIN (SeqNo=2000)
(2) ACK (AckNo=2001)
(4) ACK (AckNo=701)パッシブクローズ
(サーバ側)
close(fd);
(3) FIN (SeqNo=700) close(fd);
(とソケット関数の対応)
EOFをアプリケーションに配信
2 MSL
MSL: Maximum Segment Lifetime
※FIN-ACK送信後の一定時間、ソケットは破棄されずに保持される
FIN
_WA
IT_1
FIN
_WA
IT_2
アクティブクローズ
(クライアント側)
TIM
E_W
AIT
CLO
SE_
WA
ITLA
ST_A
CK
CLO
SED
98
TIME_WAIT状態
• アクティブクローズ側は、FIN受信後2MSL時間(Linuxでは60秒)ソケットを保持
• FINの再送への対応
• この間ローカルポートの再利用は不許可• bind関数でEADDRINUSEエラー発生(Linuxはlisten 関数でも発生)
• setsockopt(SO_REUSEADDR)関数で即時再利用が可能
• サーバがクライアントにコールバックするような プログラムは注意が必要
99
ジャンボフレームとブリッジ
• 仮想化技術などで実デバイスと仮想デバイスをブリッジすることが多いが、仮想デバイスのMTUサイズに注意
• ホストOSのネットワーク性能が悪化することもある
Guest OS
Host OS
eth0
veth0
br0
eth0
MTU 1500 MTU 9000
MTU 1500MTU 9000 ※元のeth0のIPアドレスを
br0に割り当てた場合100
Linuxの輻輳制御アルゴリズム
• kernel 2.6.29では13種類をサポート
• デフォルトはCUBIC
• 現在の設定の確認
• アルゴリズムの変更
101
$ sysctl net.ipv4.tcp_congestion_controlcubic
$ sysctl -w net.ipv4.tcp_congestion_control=htcpnet.ipv4.tcp_congestion_control = htcp
Ethernetヘッダフォーマット
• さらにフレームの前にプリアンブル(8バイト)、 フレーム間にIFG(12バイト)
• Taged-VLANの場合はフレームサイズが4バイト増える
Source MAC address (6)
Destination MAC address (6)
Type(2) Payload (46 -- 1500) FCS (4)
MAC: Media Access ControlIFG: Inter Frame GapFCS: Frame Check Sequence
0800 IPv4 datagram (46 -- 1500)
8100 VLAN tag 0800 IPv4 datagram (46 -- 1500)
102
IPv4ヘッダフォーマットVersion Header length TOS LengthLengthLengthLength
IdentifierIdentifierIdentifier 0 DF MF Fragment offset
TTLTTL Protocol Header checksumHeader checksumHeader checksumHeader checksum
Source IP addressSource IP addressSource IP addressSource IP addressSource IP addressSource IP addressSource IP address
Destination IP addressDestination IP addressDestination IP addressDestination IP addressDestination IP addressDestination IP addressDestination IP address
Options (variable length)Options (variable length)Options (variable length)Options (variable length)Options (variable length)Options (variable length)Options (variable length)
Payload (variable length)Payload (variable length)Payload (variable length)Payload (variable length)Payload (variable length)Payload (variable length)Payload (variable length)
0 31
DF Don’t Fragment MF More Fragment
Flags:
103
IPv6ヘッダフォーマットVersion Traffic class Flow labelFlow labelFlow label
Payload lengthPayload lengthPayload length Next header Hop limit
Source IP address (128 bit)Source IP address (128 bit)Source IP address (128 bit)Source IP address (128 bit)Source IP address (128 bit)
Destination IP address (128 bit)Destination IP address (128 bit)Destination IP address (128 bit)Destination IP address (128 bit)Destination IP address (128 bit)
Extension header (variable length)Extension header (variable length)Extension header (variable length)Extension header (variable length)Extension header (variable length)
Payload (variable length)Payload (variable length)Payload (variable length)Payload (variable length)Payload (variable length)
0 31
104
TCPヘッダフォーマット送信元ポート番号送信元ポート番号送信元ポート番号送信元ポート番号送信元ポート番号送信元ポート番号送信元ポート番号送信元ポート番号 あて先ポート番号
シーケンス番号シーケンス番号シーケンス番号シーケンス番号シーケンス番号シーケンス番号シーケンス番号シーケンス番号シーケンス番号確認応答番号確認応答番号確認応答番号確認応答番号確認応答番号確認応答番号確認応答番号確認応答番号確認応答番号
ヘッダ長 予約 U A P R S F 広告ウィンドウサイズチェックサムチェックサムチェックサムチェックサムチェックサムチェックサムチェックサムチェックサム 緊急ポインタ
オプション(最大40バイト)オプション(最大40バイト)オプション(最大40バイト)オプション(最大40バイト)オプション(最大40バイト)オプション(最大40バイト)オプション(最大40バイト)オプション(最大40バイト)オプション(最大40バイト)
アプリケーションデータ(可変長)アプリケーションデータ(可変長)アプリケーションデータ(可変長)アプリケーションデータ(可変長)アプリケーションデータ(可変長)アプリケーションデータ(可変長)アプリケーションデータ(可変長)アプリケーションデータ(可変長)アプリケーションデータ(可変長)
0 31
ACK(A) 確認応答番号が有効 FIN(F) 送信者はデータ送信を終了
PSH(P) データをすみやかにプロセスに送る RST(R) コネクションのリセット
SYN(S) シーケンス番号の同期 URG(U) 緊急ポインタが有効
Flags:
105
TCPオプションkind length meaning
0 - オプションリストの最後1 - NOP
2 4 最大セグメントサイズ(MSS)3 3 ウィンドウスケール4 2 選択確認応答(SACK)許可5 2+8N (1≦N≦4) 選択確認応答(SACK)8 10 タイムスタンプ19 18 MD5シグネチャ27 8 クイックスタートレスポンス
106
TCPオプション(例)
NOP NOP kind=8 len=10
Time StampTime StampTime StampTime Stamp
NOP NOP kind=5 len=18
SACK Block [0]SACK Block [0]SACK Block [0]SACK Block [0]
SACK Block [1]SACK Block [1]SACK Block [1]SACK Block [1]
SACK Block [2]SACK Block [2]SACK Block [2]SACK Block [2]
(2)タイムスタンプと3つのSACKブロックを含む場合
注意:データの先頭がワードでアライメントされるように、オプションサイズがワードの倍数になるようNOPを入れる
(1)MSS、SACK許可、タイムスタンプ、Window Scaleを含む場合
kind=2 len=4 MSSMSS
kind=4 len=2 kind=8 len=10
Time StampTime StampTime StampTime Stamp
NOP kind=3 len=3 WScale
107
参考書籍詳解TCP/IP〈Vol.1〉プロトコル 著者: W.リチャードスティーヴンス 出版社:ピアソンエデュケーション 発売日:2000/12
Linuxカーネル解読室 著者: 高橋浩和、小田逸郎、山幡為佐久 出版社:ソフトバンククリエイティブ 発売日:2006/11
High Performance TCP/IP Networking: Concepts, Issues, and Solutions 著者: Raj Jain 、Mahbub Hassan 出版社:Pearson Prentice Hall 発売日:2003/10
トランスポートプロトコル 著者: 尾家祐二、村山公保、西田佳史 出版社:岩波書店 発売日:2001/4
108
精密な帯域制御• 精密な帯域制御を実現するには、正確なパケット送信間隔制御が不可欠
• (パケットサイズ)=(ギャップサイズ)の場合:送信レートは物理帯域の1/2
• 既存のタイマ割込み駆動方式では実現が困難• 1Gbps, MTU 1500 B:12マイクロ秒の制御が必要
• OSのタイマ間隔は1~10ミリ秒
109
1500BTime
ギャップサイズ 12 us12 us
ギャップサイズ:あるフローに着目したときの パケット間ギャップ
ソフトウェアによる精密な帯域制御PSPacer:バイトクロック方式
•タイマ割込みを使わず、送信バイトをクロックに利用例)GbE, 1 バイト = 8 ナノ秒
•根拠:パケットをワイヤレートで連続して送信できれば、パケット送信間隔は正確に制御可能
•通信が発生しない隙間にダミーのパケット(ギャップ パケット)を挿入
110
12 us12 us
バイトクロック(byte)
送信タイミングは通信開始からの送信バイトで決定
03000600090001500B 1500B
実パケットギャップパケット
標準準拠したギャップパケットの実現
• PAUSEフレーム(IEEE 802.3x フロー制御)の利用
•副作用なし•必ずスイッチ・ルータの入力ポートで破棄
•実パケットのみが、元の送信間隔を保持して出力•特別なハードウェアが不要
111
送信PC スイッチ
実パケットギャップパケット