1 / 20

Linux の TCP/IP 通信における 高帯域高遅延ネットワーク上で 性能低下を引き起こす 通信中断の原因解析と改良

Linux の TCP/IP 通信における 高帯域高遅延ネットワーク上で 性能低下を引き起こす 通信中断の原因解析と改良. 児玉祐悦、高野了成、岡崎史裕、工藤知宏 産業技術総合研究所グリッド研究センター. ルータの帯域制御方式の評価を行っている際に、著しい通信性能の低下が観測された。. Router (Cisco GSR12404). WAN Emulator (AIST GtrcNET-1). policing 500Mbps. one way delay: 5ms. Node A. Node B. GbE. 背景（１）.

whitney
Download Presentation

Linux の TCP/IP 通信における 高帯域高遅延ネットワーク上で 性能低下を引き起こす 通信中断の原因解析と改良

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. LinuxのTCP/IP通信における高帯域高遅延ネットワーク上で性能低下を引き起こす通信中断の原因解析と改良LinuxのTCP/IP通信における高帯域高遅延ネットワーク上で性能低下を引き起こす通信中断の原因解析と改良 児玉祐悦、高野了成、岡崎史裕、工藤知宏 産業技術総合研究所グリッド研究センター IC2007@福岡　2007/10/25

  2. ルータの帯域制御方式の評価を行っている際に、著しい通信性能の低下が観測された。ルータの帯域制御方式の評価を行っている際に、著しい通信性能の低下が観測された。 Router (Cisco GSR12404) WAN Emulator (AIST GtrcNET-1) • policing 500Mbps • one way delay: 5ms Node A Node B GbE 背景（１） • １ＧバイトのデータをノードＡからノードＢに対してTCP/IPで転送 • Goodput: 70- 300 Mbpsとばらつきが大きい。 • ワーストケースでは設定帯域の1/5以下 IC2007@福岡　2007/10/25

  3. 性能低下時のバンド幅を10ミリ秒間隔で測定したところ、通信が数秒間にわたって頻繁に中断していることが確認された。性能低下時のバンド幅を10ミリ秒間隔で測定したところ、通信が数秒間にわたって頻繁に中断していることが確認された。 バンド幅（Ｍｂｐｓ） 時間（秒） 背景（２） IC2007@福岡　2007/10/25

  4. 本発表のアウトライン • 通信途絶の原因究明のための詳細な状況の把握 • 10ミリ秒ごとのバンド幅 • 10ミリ秒ごとの輻輳ウィンドウサイズ(cwnd) • パケットごとのデータ・ACKシーケンス • 原因究明と改良方法 • 性能評価 • まとめ IC2007@福岡　2007/10/25

  5. Router (Cisco GSR12404) WAN Emulator (AIST GtrcNET-1) • policing 500Mbps • one way delay: 5ms Node A Node B GbE input output 設定帯域 バンド幅 時間 実験環境 policing トークンバッファ ・設定帯域にあわせて一定間隔(itv)で増加 ・データ転送時に減少 許容バースト(bt) データパケット トークンがあるか Yes:転送 No:破棄 IC2007@福岡　2007/10/25

  6. GtrcNET • 産総研で開発したＦＰＧＡを用いたネットワークテストベッド • GtrcNET-1: GbE (GBIC) x 4ports + 16MBytes/port • ネットワーク実験のための種々の機能を1台で実現 • 遅延のエミュレーション • 高精度バンド幅測定 • パケットキャプチャ • テストパケット生成 • 帯域制御（pacing,shaping,policing) • GtrcNET-10: 10GbE (XENPAK) x 3ports + 1GBytes/port http://www.gtrc.aist.go.jp/gnet/ IC2007@福岡　2007/10/25

  7. バンド幅（Ｍｂｐｓ） バンド幅（Ｍｂｐｓ） 拡大 通信が中断して見える部分でも1RTTで1、２パケット程度の通信が行われている。 時間（秒） 時間（秒） 時間（秒） 詳細なバンド幅の確認 IC2007@福岡　2007/10/25

  8. Web100パッチにより輻輳ウィンドウサイズ(cwnd) を10ミリ秒間隔で取得 • パケットロスによりcwndが低下した後で、数秒間cwndが回復していない • Timeoutが起きているときと、起きていないときとがある。 Mbytes Timeouts 時間（秒） 輻輳ウィンドウサイズの確認 CurCwnd CurSsthresh Timeouts IC2007@福岡　2007/10/25

  9. GtrcNET-1によりノードＡの入出力パケットをキャプチャし、データ・ＡＣＫ・ＳＡＣＫシーケンスを取得GtrcNET-1によりノードＡの入出力パケットをキャプチャし、データ・ＡＣＫ・ＳＡＣＫシーケンスを取得 • ＳＡＣＫを受信し、再送が行われる • 再送に対するＳＡＣＫを受信しているが、再々送が行われていない Data Seq ACK Seq SACK Start SACK End Mbytes Mbytes 拡大 時間（秒） 時間（秒） パケットシーケンスの確認 IC2007@福岡　2007/10/25

  10. SACK (Selective ACK) snd_nxt snd_una 0 1 2 3 4 5 6 7 8 9 10 11 12 ACK受信済 未送信 X X X X X X パケットLoss • ACK: 連続してどこまで受信したかを示す • SACK: 不連続な受信パケットを示すことにより、ロストしたパケットのみを再送する仕組。最大4組まで前回のSACKがシフトされる。 ACK(0) ACK(0), SACK {(3,4)} ACK(0), SACK {(3,5)} ACK(0), SACK {(7,8),(3,5)} ACK(0), SACK {(7,9),(3,5)} ACK(0), SACK {(11,12),(7,9),(3,5)} ACK(0), SACK {(11,13),(7,9),(3,5)} IC2007@福岡　2007/10/25

  11. パケット中断の原因(1) • Linux 2.6.17のソースを検証したところ、以下のバグが原因と判明 • ABC(Appropriate Byte Count)使用時に再送タイムアウトが起きた後のLoss状態でcwndが増加しない。 • 複数のSACKブロック受信し、SACKブロックをソートするときに、先頭のブロックを破壊するときがある。 • 再送パケットの破棄の検出に失敗するときがある。 IC2007@福岡　2007/10/25

  12. 再送パケット破棄の検出方法 • 再送パケットより確実に後に送信したパケットのSACKを受信した場合。 • 再送パケットより大きなシーケンス番号を持つSACKではだめ。 • 最初のパケットに対するSACKか、再送パケットに対するSACKか、区別できない。 • 再送タイムアウト（200ms）を待つと性能低下が大きい。 • 再送時のsnd_nxtを記録しておき、それより大きなSACKを受信した場合を、再送パケットの破棄の検出条件にしている。 IC2007@福岡　2007/10/25

  13. snd_nxt snd_nxt < SACK(8,11) Lost | Retransmit m: ack_seq SACK(start_seq,end_seq) n n n/ m Lost n Transmit Sacked 再送パケットの破棄検出の例 snd_una 0/ 10 2 1 1 2 3 4 5 6 8 9 0 1 2 3 4 5 6 7 8 9 10 11 12 3 7/ 11 SACK(3,4) SACK(8,11) Scoreboarding process 0/ 13 10 Retransmit (Good) IC2007@福岡　2007/10/25

  14. SACK(8,11)+ SACK(1,3) Lost | Retransmit m: ack_seq SACK(start_seq,end_seq) n n n/ m Lost n Transmit Sacked 再送パケットの破棄検出失敗の例 snd_nxt snd_una 0/ 10 1 2 3 4 5 6 7/ 11 8 9 10 11 12 SACK(1,3) > SACK(8,11) Scoreboarding process 10 No retransmit (NG) IC2007@福岡　2007/10/25

  15. 改良方法 • 最初の２つバグは2.6.22では修正済みであった • 性能は改善されるが、3つ目のバグが残っているため、再送タイムアウト(RTO)が頻繁に起きていた。 • RTOまでの200msは通信が行われないため性能低下を引き起こしていた。 • 3つ目のバグの改良方法 • FIX1:受信SACKブロック内の最大エンドシーケンスをあらかじめ求めておき、再送パケットの破棄のチェックにこの値を用いる。 • FIX2:すでに受け取っているSACKブロックの処理をスキップする。 • 複数の新しいSACKブロックが含まれている場合は、FIX2だけでは正しく再送パケットの破棄を検出できないが、FIX2ではSACK処理の効率化が期待できるので、FIX1とFIX2を両方適用することが望ましい。 IC2007@福岡　2007/10/25

  16. snd_nxt snd_nxt SACK(8,11) SACK(8,11)+ SACK(1,3) SACK(8,11)+ SACK(1,3) Lost | Retransmit m: ack_seq SACK(start_seq,end_seq) n n n/ m Lost n Transmit Sacked 改良方法の例 snd_una 0/ 10 2 1 1 2 3 4 5 6 8 9 0 1 2 3 4 5 6 7 8 9 10 11 12 3 7/ 11 < 11 SACK(1,3) SACK(8,11) FIX1 Scoreboarding process 10 0/ 13 Retransmit < FIX2 Scoreboarding process 0/ 13 10 Retransmit IC2007@福岡　2007/10/25

  17. 性能評価(1) IC2007@福岡　2007/10/25

  18. 2.6.22では頻繁にＲＴＯを起こし、帯域が上下している。2.6.22では頻繁にＲＴＯを起こし、帯域が上下している。 • 提案方式ではＲＴＯを起こさないため、ペーシングによりパケット破棄が起きた後でもすばやく帯域を回復している。 バンド幅（Ｍｂｐｓ） 時間（秒） 性能評価(2) 提案手法 2.6.22 IC2007@福岡　2007/10/25

  19. まとめ • 大量のパケット破棄が生じている状況で起きる通信中断の原因を解明し、その改良方法を提案し、評価により効果を確認した。 • 提案した修正をLinuxネットワークカーネル開発者に報告し、2.6.24-rc1には本修正が適用されている。 IC2007@福岡　2007/10/25

  20. 通信性能低下要因の追求 • 実ネットワークでは現象を再現できない場合があり、ネットワークエミュレーションを使った環境が有効。 • スループットの低下を起こさないハードウェアエミュレータが高速ネットワークでは重要 • 10ミリ秒程度の細かな時間間隔での情報取得（バンド幅や輻輳ウィンドウサイズなど）が有効 • これでは不十分な場合、パケット単位の情報取得（SACKシーケンス, in_flight カーネル変数など）が有効 • 最後はソース。オープンソースなＯＳが不可欠。 IC2007@福岡　2007/10/25

More Related