特別研究報告高速 TCPにおけるパケットスぺーシングの効果

特別研究報告
題目
高速 TCP におけるパケットスぺーシングの効果
指導教官
鶴正人助教授
報告者
米山由布子
平成 18 年 2 月 27 日
九州工業大学情報工学部電子情報工学科
平成 17 年度特別研究報告
高速 TCP におけるパケットスぺーシングの効果
米山由布子
内容梗概
現在，インターネットの高速化と大容量データ転送を必要とするアプリケーションの出現
により，高速長距離ネットワークに適した高速データ転送プロトコルの開発に関する様々な
課題が活発に研究されている．その中の１つが，送信側が送ったデータに対して受信側から
確認応答 (ACK:ACKnowledge) が戻ってくるまでの時間幅 (RTT:Round Trip Time) 内で
のパケットの送信をできるだけ滑らかに（一定レートに）に制御する「バースティネスコン
トロール」である．バーストトラヒックが発生する場合，中間ルータでバッファオーバーフ
ローが起こる可能性がある．この問題を解決するためのバースティネスコントロールの機構
が，それぞれのパケット伝達のタイミングを直接制御する，パケットスペーシングである．
そこで，本研究では，高速長距離ネットワークに適した新しい TCP (Transmission Control
Protocol) の開発のためのステップとして，
（独）産業技術総合研究所グリッド研究センターで
開発されたパケットスペーシングのソフトウェアである PSPacer (Precise Software Pacer)
を用いて，それが高速長距離ネットワークでの高速データ転送にどのような効果があるかを，
高速ネットワークテストベッドである JGN2 上での実験によって分析評価した．その結果，
標準 TCP，FAST TCP のどちらのプロトコルに対しても，平均スループットの向上が確認
できた．特に，UDP によるクロストラヒックが存在する環境においては著しい効果が観察
された．
主な用語
バースティネスコントロール，パケットスぺーシング，PSPacer
目次
1
はじめに
1
2
高速 TCP における課題
2
2.1
タイマ割り込み . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
ウインドウサイズコントロール . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
4
PSPacer
5
3.1
機構 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.1.1
iproute2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.2
Qdisc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
4.1
ギャップパケット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1
5
6
10
パケットスペーシングメカニズム
ターゲットレート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2
IPG-aware packet scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3
実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
13
実験
5.1
エミュレータを用いた実験ネットワーク . . . . . . . . . . . . . . . . . . . . 13
5.2
実環境ネットワークでの実験 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3
実験内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3.1
iperf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3.2
FAST TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3.3
ソケットバッファサイズ . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3.4
PSPacer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
18
結果と考察
6.1
エミュレータを用いた実験の時の検証 . . . . . . . . . . . . . . . . . . . . . . 18
i
6.2
6.3
7
実環境ネットワークの時の検証 . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2.1
Standard TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2.2
FAST TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
提案機構の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
34
まとめ
謝辞
35
参考文献
36
ii
1
はじめに
近年，インターネットでは，膨大な量になる DNA 情報の取り出しなど，高速長距離ネッ
トワークにおける大容量データ転送における問題が，大きな検討課題の一つとなっている.
インターネットで用いられる IP 通信では，短時間に多くのパケットがまとまって送られる
バーストトラヒックが発生して利用可能な帯域を一時的に越えてしまうことがある．する
と，ネットワークの中間にあるスイッチやルータのバッファオーバーフローを引き起こし，
パケット消失が生じて実効通信性能が著しく低下する可能性がある．通常の PC やストリー
ミングサーバなどでは，バーストトラヒックの発生が避けられず，通信性能が低下してしま
う．これを抑えるためには，利用可能な帯域に応じてパケットを等間隔に送信する平滑化処
理が必要である．産総研グリッド研究所では，平滑化によりバーストトラヒックを抑えるこ
とで効率よく通信が行えることに注目し，ソフトウエアで平滑化を実現する PSPacer の開
発が行われた．
そこで本研究では，高速長距離ネットワークにおける高速性/効率性と他のプロトコルと
の親和性の両立を目指した新しい TCP の開発のための一課題として，パケットスペーシン
グがどのような場合 (対象プロトコル，ネットワーク環境) にどの程度の効果があるのか，と
いうことを評価する．
以下，2 章で，高速長距離ネットワークにおける問題点について説明する．次に 3 章で産
総研グリッド研究所で提案された PSPacer について説明し，4 章ではパケットスペーシング
のメカニズムについて詳しく説明する．5 章では，PSPacer を使った実験について説明し，
6 章ではその実験結果を示し，考察する．最後に 7 章でまとめと今後の課題を示す．
1
2
高速 TCP における課題
IP 通信においてエンドツーエンドのデータ転送を提供するトランスポートプロトコルと
して，Transmission Cotrol Protocol (TCP) と User Datagram Protocol (UDP) があるが，
WWW，ファイル転送，メール配送など，１ビットの不足もなくデータを完全に転送する必
要があるアプリケーションの多くは TCP を使っている．これは，TCP が，エンドツーエ
ンドのパケットの転送結果を保証しない IP 通信網の上で，次の２つを行うからである．
• エンドツーエンドの高信頼バイトストリーム転送
途中の経路でパケットのロスや順序逆転が発生した場合に，再送や並べ替えを行う（エ
ラー制御）．あるいは，受信側の処理能力以上にパケットが到着しないように，送信
速度を制限する（エンドツーエンドのフロー制御）．
• ネットワーク帯域の効率的な利用
ネットワーク状態を推定して適応的に送信速度を調整する．パスの途中が空いていそ
うなら速度を上げ，混んでいそうなら速度を落す（輻輳制御）．
ところが，高速長距離ネットワーク上では，標準 TCP を使って大容量ファイル転送して
も，十分なスループットは達成できず，そのため，様々な形での標準 TCP の改良／拡張が
研究されている．基本的には，信頼性のあるトランスポートプロトコルにおいては，何らか
の形のエラー制御や輻輳制御を行う必要がある．そして，高速な通信になればなるほど短い
時間スケールでの迅速なエラー制御や輻輳制御が必要になるが，一方，長距離になればなる
ほど伝播遅延によりフィードバックが遅れる．つまり，長距離通信において，エンドツーエ
ンドのプロトコルによって送信速度の制御を適切に行なうことでパケットロスも防ぎながら
高速性を実現することは，本質的な困難を抱えている．
送信速度の制御には，通常，送信側が送ったデータに対して受信側から確認応答 (ACK:
ACKnowledgement) が戻ってくるまでの時間幅 (RTT: Round Trip Time) 内に連続して送
信するデータの量を決める「ウインドサイズコントロール」と，その RTT 内でのパケット
の送信をできるだけ滑らかに（一定レートに）に制御する「バースティネスコントロール」
2
とがある．そこで，本節では，
「バースティネスコントロール」に従来使われているタイマ割
り込みの問題点と，高速長距離環境における「ウインドサイズコントロール」の問題点を簡
単に説明する．
2.1
タイマ割り込み
タイマ割り込みとは，コンピュータの内部に組み込まれた時計が一定間隔の時間を刻んだ
ことを，稼働中のソフトウエアに通知するためのハードウエア機構のことである．タイマ割
り込みは, オペレーティングシステムによって一定の間隔で補足され，システムのソフトウ
エアコンポーネントや実行中のアプリケーションソフトは，必要に応じてその経過時間な
どの情報を受信することができる．タイマ割り込みでパケットの送信されるタイミングは，
ペーシングタイマが決定し，通常ミリ秒単位でこれを表示する．
従来，ソフトウエアによりパケットの送信間隔を制御する場合，タイマ割り込みが用いら
れてきた．linux 等のオペレーティングシステムが提供するタイマ割り込みは通常 1∼10ms
程度の間隔であり，送信間隔の制御を精密に行うことはできなかった．一方，タイマ割り込
みの間隔を短くすると，プロセッサの負荷が大きくなり，計算機の計算性能や通信性能に悪
影響を与えるという問題があった．
2.2
ウインドウサイズコントロール
ウインドウサイズコントロールとは，それぞれの RTT の期間のトランスミッションの
量を制御するための課題である．RTT が長いと，ACK が返ってくるのが遅くなるため，ス
ループットが出なくなる．ACK とは，コンピュータ間の通信において，送信したデータが
送信先に到達した時に送信先のコンピュータが送信元のコンピュータに送る確認応答のこと
である．データ転送が正常に終了したときなどに送信される．
高速長距離のネットワークに焦点を合わせたウインドウサイズコントロールは広く研究
され，多くの体系が提案された．まず一つは， HighSpeed TCP，Scalable TCP，BIC-TCP
などの AIMD(Additive Increase and Multiplicative Decrease) の異なるアルゴリズムは利
用可能な帯域幅を見積り，そしてパケットロスの比率に基づくウインドウサイズを決定する．
3
そしてもう一つの体系として，FAST TCP は中間ルータでバッファによって引き起こされ
る遅延に基づいて利用可能な帯域幅を見積もる．
4
3
PSPacer
PSPacer を使用しない通常の通信では，パケット送信間隔にかたより (バーストトラヒッ
ク) が発生し，スイッチやルータのバッファオーバーフローを引き起こすためにパケット消
失が生じる．PSPacer を使用することで，パケットを等間隔に送信するため安定した通信が
可能となる．
従来，ソフトウエアによりパケットの送信間隔を制御する場合，タイマ割り込みが用いら
れてきた．PSPacer では，タイマ割り込みではなく，パケットとパケットの間に別のパケッ
ト (ギャップパケット) を送信するという手法により送信間隔を制御している．ギャップパケッ
トの数や大きさを制御することにより，送信間隔を精密に制御することができる．ギャップ
パケットは，スイッチやルータの入力ポートで破棄されるため，ネットワークに影響を与え
ることはない．
本章ではまず，高速 TCP における課題について説明する．次に PSPacer のしくみにつ
いて説明し，その中でも特に iproute2，Qdisc，tc について説明する．そして PSPacer の
インストールについての説明を行う．
3.1
機構
PSPacer は，パケット間ギャップ (IPG：Inter Packet GAP) を調整することによって精密
なぺーシングを提供するパケットスケジューラである．このスケジューラは，tc コマンド
によるトラヒック制御から利用可能なクラスフルキューイング規則として実装されており，
各クラスごとに設定した送信ターゲットレートにしたがってトラヒックを平滑化する．ター
ゲットレートの指定方法には，tc コマンドから静的に指定する静的ターゲットレートモード
と，TCP の場合に限り，輻輳ウィンドウサイズとラウンドトリップタイムから送信レート
を見積もる動的ターゲットレートモードが利用できる．PSPacer は Linux プラットフォー
ムへのトラヒックコントロールフレームワークである，iproute2 に基づいて実装される．こ
のフレームワークは 3 個の基本要素を提供する．その基本要素とは， qdisc，class(パケッ
トの種別)，filter(情報の選別) である．qdisc とは，送受信用のパケットを繋ぐ送信データ
5
キューのことである．また，PSPacer は 2 つの部分から成る．負荷可能なカーネルモジュー
ルと，ユーザレベルライブラリである．前者は，クラスフル qdisc である．そして後者は tc
コマンドを使ってコントロールし，それをモニターするためにこのモジュールで伝送する．
PSPacer はパケット間ギャップとして IEEE802.3x PAUSE フレームを使用する．した
がって，システムが関連しているスイッチ/ルータから伝送を止めるために PAUSE フレー
ムを使用することができない．PAUSE フレームの元々の用途としては，全二重イーサネッ
トでは，PAUSE フレームを送信することで相手に対して送信を待たせることができる．
「中
断時間× 512 ビット時間」が実際の送信中断時間となるが，
「中断時間」に 0 を指定すると
送信再開の指示となる．
主な機能としては，一般的な PC を用いて 100 以上のコネクションを別々に帯域制御，平滑
化できる．ギガビットイーサネットの場合，IP 通信のコネクションごとに 8Kbps∼930Mbps
の範囲で送信帯域を設定でき，帯域に合わせてパケットの送信間隔を 1 バイトのデータ送信
に要する時間単位の高い精度で制御できる．また，PSPacer は，Linux のローダブルカーネ
ルモジュールとして実装されており，簡単に導入可能で，デバイスドライバにも依存しない．
PSPacer を導入した後，IP アドレスやポート番号によるパケット振り分けルールを記述し，
帯域制御，平滑化を行う通信のインターフェイスと帯域を指定するだけで動作する．ネット
ワークを利用するアプリケーションの変更も不要である．
PSPacer を用いると，送信帯域の変動が最小限に抑えられ，バッファオーバーフローの可
能性を低減する．このため，ネットワークの物理帯域の利用効率を飛躍的に増大させること
ができる．PSPacer は，以下のような用途で有効である．
• 遠距離広帯域の TCP/IP 通信の場合
インターネットの通信で広く用いられている TCP/IP では，RTT ごとに送信可能な
データの最大量を制御している．このため，遅延が大きい遠距離ネットワークでは，
バーストトラヒックが発生しやすくなる．PSPacer を用いれば，大陸間のような遅延
が非常に大きな環境でもネットワーク帯域の 9 割以上を利用できる．
• 同一経路を通して複数の通信が行われる場合
6
ストリーム配信などで，ネットワーク上の同一の経路を用いて複数の通信を行う場合，
それぞれの通信のバーストトラヒックが重なって，利用可能な帯域を簡単に超えてし
まうことがある．PSPacer を用いれば，それぞれの通信の帯域が設定値を超えること
はなくなり，ネットワークの帯域を最大限に利用できる．
3.1.1
iproute2
iproute2 とは，ネットワークトラヒックに対するクラス分け，優先度付け，帯域制御など
の機能を提供するためのフレームワークである．ほとんどの Linux ディストリビューショ
ンでは，伝統ある arp，ifconfig，route といったコマンドを現在でも用いている．これらの
ツールは動作はするものの Linux2.2 以降ではときどき期待通りの働きをしないことがある．
例えば，GRE(generic Routing Encapsulation) トンネルは今日ではルーティングの一部と
なっているが，これは完全に別のツールが必要である．ここで GRE トンネルとは，Cisco
によって開発された高機能なトンネリングプロトコルで，マルチキャストや IPv6 トラヒッ
クも転送できるという特徴をもつ．また， Linux を含む多くの OS は，デフォルトゲート
ウェイの送出先を 1ヶ所しか設定できない．iproute2 を使うと，2 つのプロバイダに接続を
した 1 台の LinuxBox からそれぞれの接続に対して正しく通信することが可能である．
3.1.2
Qdisc
PSP(PSPacer) qdisc は CBQ(Class-Based Queueing：帯域制御) のような階層的なクラ
ス構造を持つことが可能であり，リーフノードの各クラスはそれぞれ qdisc を持つ．PSP
qdisc にパケットがエンキューされると，ルートから開始して，次に示す方法にしたがい，
どのノードにパケットを分類するか決定する．これをリーフノードに達するまで繰り返す．
1. クラスに登録されたフィルタを調べ，条件が成立したノードへ送る．
2. どの条件にも合致しなかった場合は，デフォルトクラスへ送る．
また，PSP クラスツリーのルート qdisc は，次のパラメータを持つ．
7
• parent major
必須のパラメータ．qdisc の親クラスを指定する．親クラスはインタフェースのルー
ト，もしくは既存のクラスのどちらかになる．
• handle major
qdisc にハンドルを割り当てる．ハンドルはメジャー番号にコロンをつなげた表記で
表される．ハンドルは qdisc を参照する際に使用されるため，サブクラスを設定する
場合に必要となる．
• default minor-id
クラシフィケーションされなかったトラヒックはこのマイナー番号を持つクラスに送
られる．
• rate rate
インターフェースの最大転送レートを明示的に指定する．PCI(Peripheral Component
Interconnect) バスボトルネックでインターフェースの物理性能を出せない場合に利用
する．PCI とは，CPU（Central Processing Unit ：中央演算処理装置）と高性能な
周辺機器との間でデータ交換を行うための、CPU 非依存の業界標準バス・アーキテク
チャのことである．
クラスは次に示すパラメータを保持する．
• parent major
必須のパラメータ．クラスの親クラスを指定する．クラスではなく，直接 qdisc に追
加する場合は，マイナー番号を省略する．
• classid major
必須パラメータ．qdisc のように，クラスにも名前を付けることができる．子供 (ク
ラス，qdisc) から参照されるために必要である．メジャー番号は所属する qdisc のメ
ジャー番号と等しくなければならない．
8
• rate rate
最大送信レートを指定する．
• mode mode
動作モードを指定する．0 から 2 の整数値を取る．0 はスぺーシングなし，1 は静的
ターゲットレートによるスペーシング，2 は動的ターゲットレートによるスペーシン
グである．
実際の PSPacer の起動のコマンドは，5 章で説明をおこなう．
9
4
パケットスペーシングメカニズム
正確なソフトウエアスペーシングを達成するために，2 つのメカニズムが提案されている.
まず一つは, ギャップパケットである. そしてもう一つは，IPG-aware packet scheduling と
いうメカニズムである.
本章では, まずギャップパケットについての説明を行い，次に IPG-aware packet scheduling
について説明を行う. そのあとでパケットスペーシングの実装についての説明を行う.
4.1
ギャップパケット
正確なソフトウエアスペーシングのために，実のパケットの間にダミーのパケットを挿入
する. このダミーのパケットのことを，ギャップパケットという. ギャップパケットは連続し
て伝達された実のパケットの間にギャップを挿入する. パケットは NIC(Network Interface
Card) の IFQ(Interface Queue) から送信される. したがって，IFQ にたまっている実のパ
ケットの間にギャップパケットを挿入することによって，次のパケットの送信は，NIC で
ギャップパケットを送ったあとに行われる. ギャップパケットのサイズを変えることによって，
次の実のパケットの伝達の送信時を正確に制御することができる. 例えば, 半分の送信レート
に制御するために，ギャップパケットは，ギャップパケットサイズが実のパケットのものと
同じであるところで，すべての実のパケットの間に挿入される. また，ギャップパケットは,
次の伝達の始動時を遅らせることを除いた，どんな副作用も発生させるべきではない. そし
てギャップパケットは NIC が接続されているスイッチの入力ポートで捨てられるべきであ
る. ギャップパケットの図を図 4.1 に示す.
10
図 4.1: ギャップパケット
4.1.1
ターゲットレート
ターゲットレートは，以下の方程式で求められる. cwnd は，輻輳ウインドウサイズである．
targetrate =
cwnd × packetsizu
RT T
(4.1)
次にギャップパケットが挿入されている場合のターゲットレートは，以下の方程式で求めら
れる．maxrate は NIC の最大の物理的な帯域幅である.
targetrate0 = maxrate ×
packetsize
packetsize + gapsize
(4.2)
この 2 式を使って，ギャップパケットのサイズが計算される. すなわち，
gapsize =
4.2
maxrate × RT T
− packetsize
cwnd
(4.3)
IPG-aware packet scheduling
IPG-aware packet scheduling メカニズムの基本的な考え方は，それぞれのボトルネック
リンクの帯域幅に基づいて計算される，必要な IPG に基づくパケット伝達を計画すること
である. もしネットワークが単一のボトルネックリンクを持つだけであるなら，スケジュー
ラはギャップパケットを挿入するだけである. しかし，もしネットワークが複数のボトルネッ
クリンクを持つなら, パケット伝達の順序や，パケットの間隔を計算するために，このメカ
ニズムが必要である.
11
このメカニズムについては，まだ実装されておらず，今後の課題となっている.
4.3
実装
それぞれの伝達されたパケットは,TCP/IP プロトコルスタックの処理のあと，出力 NIC
に関連している IFQ の列に並ばせられる．Linux kernel は QoS 制御フレームワークのた
めに，複数の qdisk を提供する．qdisc モジュールは IFQ とキューイングアルゴリズムから
成る．
sch-ipg では，2 つの構成要素を提供する．まず一つは Target Rate Estimator である．
ここでは，スペーシングのためのターゲットレートを計算する．そしてもう一つは，Gap
Packet Injector である．ここでは，反待ち行列要求がデバイスドライバから受け取られる
時，ターゲットレートに基づくギャップパケットを挿入する．
12
図 5.1: ネットワークエミュレータを用いた実験環境
5
実験
本研究では実験ネットワークを構築して PSPacer を用いて，実験を行い，パケットスペー
シングの有効性を評価する．本章では実験モデル，実験手法についての説明を行う．
5.1
エミュレータを用いた実験ネットワーク
PC1 と PC2 の間にエミュレータを置いた 1 対 1 の実験環境である．実験ネットワーク
を図 5.1 に示す．
PC1 のマシンにだけ Standard(linux-2.6.10-41msmp)，FAST(linux-2.6.7) と PSPacer
version 1.1 をインストールしてある．
5.2
実環境ネットワークでの実験
PC1 と PC2 の間にスイッチがあり，北九州 JGN2 リサーチセンターを経由するネット
ワークになっている．実験ネットワークを図 5.2 に示す．
13
JGN2
sender
router
JGN2
receiver
図 5.2: 実環境ネットワーク
この実環境ネットワークの実験においても，PC1 のマシンにだけ Standard (linux-2.6.10-
41msmp)，FAST(linux-2.6.7) と PSPacer version 1.1 をインストールしてある．
5.3
実験内容
ネットワークエミュレータを用いた実験では，高速 TCP と Standard TCP における
PSPacer の効果を検証するためネットワークエミュレータを用いて遅延を発生させ，iperf で
の測定を行った．RTT の値は，50ms，100ms，150ms，200ms と変化させた．また，PSPacer
の送信帯域は 930Mbps に設定した．
実環境ネットワークでの実験では，Standard TCP，FAST TCP それぞれで，1 本流し
た場合，2 本流した場合，UDP と共に流した場合の，平均スループットを測定した．また，
UDP では，帯域を 10Mb/s と 20Mb/s の両方の場合で測定した．この実験環境でも，ネッ
トワークエミュレータを用いた実験と同様，PSPacer の送信帯域は 930Mbps に設定した．
5.3.1
iperf
実験ネットワークに TCP や UDP のデータを送信し，そのスループットを計測するため
に iperf を用いた．iperf は，TCP と UDP のトラヒックを発生させ，そのスループットを計
測するツールであり，パケットの送信時間，UDP の bandwidth，バッファ長等のパラメー
タを自由に設定する事ができる．使用方法は，受信側で iperf をサーバモードとして起動さ
14
せ，送信側でクライアントモードでサーバを指定して起動させることで，任意のプロトコル
とパラメータで通信を行う事ができる．この時の結果より，スループットを計測できる．受
信側 (サーバ) で iperf を起動させるには以下のコマンドを用いる．
% iperf -s
送信側 (クライアント) で立ち上げるには以下のコマンドを使用する．
% iperf -c <受信側ホスト名 (又は受信側 IP アドレス)>
上記のようにオプションを付加しなければ，デフォルトのパラメータを用いて，プロトコル
は TCP をつ使って通信を行う．iperf を使用する時は送信側よりも受信側を先に起動させ
ておく点に注意する必要がある．
5.3.2
FAST TCP
FAST TCP とは，カリフォルニア工科大学の研究チームが開発したプロトコルである．
2003 年６月４日のニュー・サイエンティスト（オンライン版）によると，下り方向の速度を
引き上げるもので，100Gbps の超高速ダウンロードも可能である．パケット送受信の失敗が
あった場合に早い段階で検知して，適切なデータレートに修正してパケットロスを抑える．
FAST TCP を起動させる場合，送信側，受信側でコマンドが必要である．まず，送信側
でのコマンドを以下に示す．
echo ‘‘4096 33554432 33554432’’ > /proc/sys/net/ipv4/tcp_mem
echo ‘‘4096 33554432 33554432’’ > /proc/sys/net/ipv4/tcp_rmem
echo ‘‘4096 33554432 33554432’’ > /proc/sys/net/ipv4/tcp_wmem
echo ‘‘4096 33554432 33554432’’ > /proc/sys/net/core/wmem_max
echo ‘‘4096 33554432 33554432’’ > /proc/sys/net/core/rmem_max
echo ‘‘1’’ > /proc/sys/net/ipv4/tcp_fast
echo ‘‘1’’ > /proc/sys/net/ipv4/tcp_fast_bc
echo ‘‘1’’ > /proc/sys/net/ipv4/tcp_fast_kmon_rtt
15
echo ‘‘400’’ > /proc/sys/net/ipv4/tcp_fast_kmon_t
/sbin/ifconfig eth0 txqueuelen 4000
echo ‘‘1500’’ > /proc/sys/net/core/netdev_max_backlog
modprobe e1000 RxDescriptors=4096,4096
受信側のコマンドは，送信側のコマンドの 6∼9 行目がなくなるだけで，あとは変わら
ない．
5.3.3
ソケットバッファサイズ
ソケットバッファは，アプリケーション層と TCP 層（トランスポート層）の間でのデー
タの受け渡しをするために使われるバッファのことである．ソケットバッファは，ソケット
ごとに受信用バッファと送信用バッファが確保されている．ソケットバッファのサイズが
小さすぎると，アプリケーションが TCP からデータを受け取る，あるいは，データを送る
ための時間がかかり，結果としてアプリケーションから見た通信速度が遅くなってしまう．
逆に大きすぎてもリソースを消費するだけとなってしまうため，通信環境に合わせた最適な
サイズに設定することが必要である．ソケットバッファのサイズは，アプリケーション側
から設定することができるが，何も設定しなかった場合，システムのデフォルトのサイズが
適用される．
Standard TCP での実験の場合に，このソケットバッファサイズを以下のコマンドを用い
て設定した．このコマンドは，送信側，受信側両方で設定した．
sysctl -w net.ipv4.route.flush=1
sysctl -w net.core.rmem_max=33554432
sysctl -w net.core.wmem_max=33554432
sysctl -w net.core.rmem_default=65536
sysctl -w net.core.wmem_default=65536
sysctl -w net.ipv4.tcp_rmem=’’4096 33554432 33554432’’
sysctl -w net.ipv4.tcp_wmem=’’4096 33554432 33554432’’
16
sysctl -w net.ipv4.tcp_mem=’’33554432 33554432 33554432’’
sysctl -w net.core.netdev_max_backlog=1500
madprobe e1000 RxDescriptors=4096,4096
madprobe e1000 TxDescriptors=4096,4096
5.3.4
PSPacer
ここでは，PSPacer を起動させる時に必要なコマンドについて説明を行う．このコマンド
は，送信側のみで必要である．
ethtool -K eth0 tso off
/sbin/tc qdisc add dev eth0 root handle 1: psp default 2
/sbin/tc class add dev eth0 parent 1: classid 1:1 psp rate 930mbit
/sbin/tc class add dev eth0 parent 1: classod 1:2 psp mode 0
/sbin/tc qdisc add dev eth0 parent 1:1 handle 10: pfifo
/sbin/tc qdisc add dev eth0 parent 1:2 handle 20: pfifo
/sbin/tc filter add dev eth0 parent 1: protocol ip pref 1 u32 match ip
dst <受信側 IP アドレス> classid 1:1
17
6
結果と考察
本章では，PSPacer を用いたパケットスペーシングの効果についての実験結果を示し，考
察する．
6.1
エミュレータを用いた実験の時の検証
エミュレータで遅延を発生させ，実験を行い，その際，300 秒間の平均スループットの値
を検証した．Standard TCP の場合の結果を図 6．1，図 6．2，図 6．3，図 6．4 に示す．
Standard TCP では，変化させた RTT の全ての値で PSPacer の効果がみられた．次に，
FAST TCP の場合の結果を図 6．5，図 6．6，図 6．7，図 6．8 に示す．FAST TCP の場
合では，変化させた RTT の全ての値で PSPacer の効果が見られなかった．これは，ネッ
トワークエミュレータを用いた実験環境ではパケットロスがおきないため，効果がみられな
かったものと考えられる．
18
1000
throughput[Mbps]
800
600
400
200
without pacing
with pacing
0
0
50
100
150
time[s]
200
250
300
図 6.1: ネットワークエミュレータを用い，Standard TCP で測定した結果 (RTT 50)
1000
throughput[Mbps]
800
600
400
200
without pacing
with pacing
0
0
50
100
150
time[s]
200
250
300
図 6.2: ネットワークエミュレータを用い，Standard TCP で測定した結果 (RTT 100)
19
1000
throughput[Mbps]
800
600
400
200
without pacing
with pacing
0
0
50
100
150
time[s]
200
250
300
図 6.3: ネットワークエミュレータを用い，Standard TCP で測定した結果 (RTT 150)
1000
throughput[Mbps]
800
600
400
200
without pacing
with pacing
0
0
50
100
150
time[s]
200
250
300
図 6.4: ネットワークエミュレータを用い，Standard TCP で測定した結果 (RTT 200)
20
1000
throughput[Mbps]
800
600
400
200
without pacing
with pacing
0
0
50
100
150
time[s]
200
250
300
図 6.5: ネットワークエミュレータを用い，FAST TCP で測定した結果 (RTT 50)
1000
throughput[Mbps]
800
600
400
200
without pacing
with pacing
0
0
50
100
150
time[s]
200
250
300
図 6.6: ネットワークエミュレータを用い，FAST TCP で測定した結果 (RTT 100)
21
1000
throughput[Mbps]
800
600
400
200
without pacing
with pacing
0
0
50
100
150
time[s]
200
250
300
図 6.7: ネットワークエミュレータを用い，FAST TCP で測定した結果 (RTT 150)
1000
throughput[Mbps]
800
600
400
200
with spacing
without spacing
0
0
50
100
150
time[s]
200
250
300
図 6.8: ネットワークエミュレータを用い，FAST TCP で測定した結果 (RTT 200)
6.2
実環境ネットワークの時の検証
この実験環境では，Standard TCP，FAST TCP それぞれで，1 本流した場合，2 本流し
た場合，UDP と共に流した場合の，平均ープットの値を検証した．また，UDP では，帯域
を 10Mb/s と 20Mb/s の両方の場合で測定した．この実験環境でも，ネットワークエミュ
レータを用いた実験と同様，PSPacer の送信帯域は 930Mbps に設定した．
22
6.2.1
Standard TCP
Standard TCP を用いた場合の結果を，図 6.9，図 6.10，図 6.11，図 6.12，図 6.13，図
6.14，図 6.15，図 6.16，図 6.17 に示す．
23
1000
throughput[Mbps]
800
600
400
200
0
0
50
100
150
time[s]
200
250
300
with pacing
without pacing
図 6.9: 実環境ネットワークを用い，Standard TCP 1 本で測定した結果
1000
iperf1
iperf2
SUM
throughput[Mbps]
800
600
400
200
0
0
50
100
150
time[s]
200
250
300
図 6.10: 実環境ネットワークを用い，Standard TCP 2 本で測定した結果 (PSPacer なし)
24
1000
throughput[Mbps]
800
600
400
200
iperf1
iperf2
SUM
0
0
50
100
150
time[s]
200
250
300
図 6.11: 実環境ネットワークを用い，Standard TCP 2 本で測定した結果 (PSPacer あり)
1000
throughput[Mbps]
800
600
400
200
without pacing
with pacing
0
0
50
100
150
time[s]
200
250
300
図 6.12: 実環境ネットワークを用い，Standard TCP+UDP(10Mbps) で測定した結果
25
1000
throughput[Mbps]
800
600
400
200
with spacing
without spacing
0
0
50
100
150
time[s]
200
250
300
図 6.13: 実環境ネットワークを用い，Standard TCP+UDP(20Mbps) で測定した結果
100
2
loss
jitter
1.5
60
1
40
jitter[ms]
loss[%]
80
0.5
20
0
0
50
100
150
time[s]
200
250
0
300
図 6.14: 実環境ネットワークを用い，Standard TCP+UDP(10Mbps) で測定した場合のロ
ス率 (PSPacer なし
26
100
2
loss
jitter
1.5
60
1
40
jitter[ms]
loss[%]
80
0.5
20
0
0
50
100
150
time[s]
200
250
0
300
図 6.15: 実環境ネットワークを用い，StandardTCP+UDP(10Mbps) で測定した場合のロス
率 (PSPacer あり)
100
2
loss
jitter
1.5
60
1
40
jitter[ms]
loss[%]
80
0.5
20
0
0
50
100
150
time[s]
200
250
0
300
図 6.16: 実環境ネットワークを用い，StandardTCP+UDP(20Mbps) で測定した場合のロス
率 (PSPacer なし)
27
100
2
loss
jitter
1.5
60
1
40
jitter[ms]
loss[%]
80
0.5
20
0
0
50
100
150
time[s]
200
250
0
300
図 6.17: 実環境ネットワークを用い，StandardTCP+UDP(20Mbps) で測定した場合のロス
率 (PSPacer あり)
6.2.2
FAST TCP
FAST TCP を用いた場合の結果を，図 6.18，図 6.19，図 6.20，図 6.21，図 6.22，図 6.23，
図 6.24，図 6.25，図 6.26 に示す．
28
1000
throughput[Mbps]
800
600
400
200
with spacing
without spacing
0
0
50
100
150
time[s]
200
250
300
図 6.18: 実環境ネットワークを用い，FAST TCP 1 本で測定した結果)
1000
throughput[Mbps]
800
600
400
200
iperf1
iperf2
SUM
0
0
50
100
150
time[s]
200
250
300
図 6.19: 実環境ネットワークを用い，FASTTCP 2 本で測定した結果 (PSPacer なし)
29
1000
throughput[Mbps]
800
600
400
200
iperf1
iperf2
SUM
0
0
50
100
150
time[s]
200
250
300
図 6.20: 実環境ネットワークを用い，FAST TCP 2 本で測定した結果 (PSPacer あり)
1000
throughput[Mbps]
800
600
400
200
without pacing
with pacing
0
0
50
100
150
time[s]
200
250
300
図 6.21: 実環境ネットワークを用い，FAST TCP+UDP(10Mbps) で測定した結果
30
1000
throughput[Mbps]
800
600
400
200
with spacing
without spacing
0
0
50
100
150
time[s]
200
250
300
図 6.22: 実環境ネットワークを用い，FAST TCP+UDP(20Mbps) で測定した結果
100
2
loss
jitter
1.5
60
1
40
jitter[ms]
loss[%]
80
0.5
20
0
0
50
100
150
time[s]
200
250
0
300
図 6.23: 実環境ネットワークを用い，FAST TCP+UDP(10Mbps) で測定した場合のロス率
(PSPacer なし)
31
100
2
loss
jitter
1.5
60
1
40
jitter[ms]
loss[%]
80
0.5
20
0
0
50
100
150
time[s]
200
250
0
300
図 6.24: 実環境ネットワークを用い，FAST TCP+UDP(10Mbps) で測定した場合のロス率
(PSPacer あり)
100
2
loss
jitter
1.5
60
1
40
jitter[ms]
loss[%]
80
0.5
20
0
0
50
100
150
time[s]
200
250
0
300
図 6.25: 実環境ネットワークを用い，FAST TCP+UDP(20Mbps) で測定した場合のロス率
(PSPacer なし)
32
100
2
loss
jitter
1.5
60
1
40
jitter[ms]
loss[%]
80
0.5
20
0
0
50
100
150
time[s]
200
250
0
300
図 6.26: 実環境ネットワークを用い，FAST TCP+UDP(20Mbps) で測定した場合のロス率
(PSPacer あり)
6.3
提案機構の評価
以上の結果より，エミュレータを用いた実験では，Standard TCP には PSPacer の効果が
みられ，優れたスループットを得られることが分かった．しかし，FAST TCP には，PSPacer
の効果はみられなかった．
実環境ネットワークでの実験では，Standard TCP，FAST TCP のどちらにも PSPacer の
効果がみられた．特に FAST TCP では，PSPacer がない場合，FAST TCP １本の場合に比
べ，UDP と共に測定すると平均スループットは 200Mbps 程低い．それに対して，PSPacer
がある場合は，平均スループットはほとんどかわらず安定している．
33
7
まとめ
本研究では，高速長距離ネットワークにおいて，バーストトラヒックを発生させないこと
を目的として，産総研グリッド研究所で開発されたソフトウエアである PSPacer を使って
実験を行い，その有効性を明らかにした．具体的には，現在インターネットで広く使われて
いる Standdard TCP と，高速長距離ネットワーク向けの新しい TCP である FAST TCP
を用いて，平均スループットを測定し，その平均スループットの向上を目的とした．
ネットワークエミュレータを用いた実験ネットワークと，実環境ネットワークでの実験を
行い，PSPacer の有効性を調査した．その結果，以下のことが分かった．
• ネットワークエミュレータを用いた実験では，Standard TCP は PSPacer の効果がみ
られ，良好なスループット特性を示すことが分かった．しかし，FAST TCP は PSPacer
の効果はみられなかった．
• 実環境ネットワークでの実験では，Standard TCP，FAST TCP 共に PSPacer の効
果がみられ，良好なスループット特性を示すことが分かった．
また，今後の課題としては，以下に示すことが挙げられる．
• ネットワークの規模を大きくした場合の特性の評価
• 実環境ネットワークでの実験の場合の，FAST TCP+UDP の場合の UDP での不自
然なロスの原因の調査．
34
謝辞
本研究を進めるにあたり、様々な面において適切に御指導をくださいました鶴正人助教授
に心から感謝致します．また，ゼミに対して適切な御意見を頂きました，尾家祐二教授，川
原憲治助教授，池永全志助教授，福田豊助手に厚くお礼申し上げます．また，本研究に対し
御指導頂きました株式会社アックスの高野了成様に深く感謝致します．また，本研究に対
しお忙しい中終始熱心に御指導して頂きました九州電力の神山勝司様，NICT 北九州 JGN2
リサーチセンターの熊副和美様に深く感謝致します．また様々な面で御協力頂きました鶴研
究室，尾家研究室，川原研究室の皆様に感謝申し上げます．最後に研究室での生活を快適に
整えて下さいました竹村真奈美事務補佐員，吉木智絵事務補佐員に感謝致します．
35
参考文献
[1] Ryousei Takano,Tomohiro Kudoh,Yuetsu kodama,Motohiko Matsuda,Hiroshi Tezeka
and Yutaka Ishikawa: “Design and Evaluation of Precise Software Pacing Mechanisms
for Fast Long-Distance Networks”
[2] 鶴正人，熊副和美，尾家祐二: “長距離通信のための TCP 性能改善技術の動向情報処
理 ,vol.44,No.9,pp.951–957
[3] http://www.gridmpi.org/pspacer-1.0/index.ja.jsp
[4] http://www.aist.go.jp/aist-j/aistinfo/aist-today/vol05-09/vol05-09-topics/ vol05-09topics.html
36

Download Report