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データ処理の流れ（１）• データはセグメントに小分けして送受信• 送信者：シーケンス番号を付加• 受信者：「次に受信したい」シーケンス番号を

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データ処理の流れ（２）

• ウィンドウベースの送信レート制御• 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）

輻輳ウィンドウ制御（１）

16

• 未知の利用可能帯域をいかに正確かつ迅速に求めるか？• パケットロスを起こすまで、cwndを拡大

• 2つのフェーズ：スロースタートで素早くあたりを付け、輻輳回避で徐々に拡大

cwnd

time

ssthresh（スロースタート閾値）

スロースタート（指数的増加）

輻輳回避（線形的増加）

w

w/2

パケットロス パケットロス パケットロス

(15)

パケットロス パケットロス パケットロス

輻輳ウィンドウ制御（２）

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クロッキング（１）• 送信ウィンドウのセグメントを一度に送信するのではなく、RTT内で均一に送信

• バースト送信によるバッファあふれの回避

19

送信ウィンドウ

ルータボトルネックリンク

ACKクロッキングなし：

ACKクロッキングあり：

バッファあふれバースト送信

(17)

ACKクロッキング（２）• 送信ウィンドウのセグメントを一度に送信するのではなく、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)

ソケットバッファチューニング• 帯域遅延積の２倍（帯域 x RTT）必要

• 1 Gbps × 50ミリ秒 x 2 = 12.5 MB

• 送信側と受信側それぞれで設定が必要• デフォルトの最大ソケットバッファサイズは４MB

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

帯域

帯域 計算通信 計算通信 一対一全対全

一対一全対全

実験１ 実験２

(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)

実験１：間欠通信性能

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)

通信アイドル後のスロースタート（１）• 一定時間通信を行わないと、スロースタートから再開• （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分のバースト送信

通信アイドル後のスロースタート（２）(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)

実験２：全対全通信性能

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メッセージは複数セグメントに分割して送信

• １プロセス１ノードを仮定

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

１イテレーション内の通信パターン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が発生（１）メッセージの末尾パケットが破棄

（２）（１）がプロセスの組で発生

• 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

３つの変更点 対応する問題点通信再開時ペーシング 通信開始時における、スロー

スタートの省略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. ソケットバッファサイズは帯域遅延積の２倍（帯域×RTT）以上必要（デフォルトは4MB）

2. setsockopt関数はlistenやconnect関数の前に実行

3. インタフェースキューあふれは輻輳とみなされるので、帯域遅延積の大きなネットワークでは、キュー長の拡大が必要

4. 高速TCPは公平性を保ちつつ、帯域利用効率の向上を追求。公平性を失った実装の使用はインタネットでは危険

5. 帯域遅延積が大きなネットワークでは、スロースタートはまったく「スロー」ではない。バースト送信の抑制には、ペーシングが効果的

76

(76)

まとめ（２）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

全対全 一対一

時刻０まで全対全通信時刻０から一対一通信を開始

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 2 3 4 5 6 7 9 10 11 13 15 16

シーケンス番号（２）選択確認応答

累積確認応答 選択確認応答

セグメント8の損失しか通知できない

TCPヘッダのオプションフィールドを使い、歯抜け状の損失を通知できる（最大4個）

89

重複ACKによる高速再送

• 重複ACK（同じACK番号）を3回以上連続で受信すれば、再送する

• 1 RTTにたかだか一つのパケットロスしか検出できない

• ウィンドウサイズが大きくなり、歯抜け状にパケットが損失すると、性能の劣化は避けられない

X

RTT

1R

TT2

101112131415

101617

99999

151617

90

再送タイムアウト（１）

• もっとも保守的な再送制御• 一定時間内に確認応答がなければ再送• 「確認応答が返ると予想される時間（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

線形 ２乗

３乗

指数 対数＆指数

高速TCPのcwnd制御

スライディングウィンドウ

#1 #2 #3 #4 #5 #6 #7 #8

確認応答済 未送信確認応答待ち

シーケンス番号

時間

セグメントの状態：

送信ウィンドウ（＝４）

セグメントが新しく確認応答されると、送信ウィンドウが右にスライドし、送信可能なセグメントが増える

（送信バッファ管理）

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,...);

※（２）では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]

（２）タイムスタンプと３つのSACKブロックを含む場合

注意：データの先頭がワードでアライメントされるように、オプションサイズがワードの倍数になるようNOPを入れる

（１）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 スイッチ

実パケットギャップパケット