複数パス利用環境におけるエンドッーエンド片方向特性推定方式

澤井新↑ 小川清* 飯田登** 渡辺尚
静岡大学大学院情報学研究科*名古屋市工業研究所**浜松大学ⅱ静岡大学情報学部
有線,無線インフラの普及により,1つの端末が複数の通信手段を同時に利用する環境が整い
つつある.そのような環境では,複数の通信経路の中から,より適するエンドッーエンド片方向
経路を選択可能である.最近はエンドッーエンドでの片方向特性に敏感なアプリケーションが多
く,適切な経路選択のためには,パスの片方向特性を考慮することが必要である.そのため,経
路選択のための尺度のひとっとして片方向遅延差に注目する.片方向遅延差とは,2つの片方向
遅延の差分であり,片方向遅延を比較できる.我々は,片方向遅延差を推定する方式を提案,実
装し,工ミュレーション環境において動作を確認した.さらに,実測実験により,実インターネ
ット環境に適用させたのち,提案方式の評価を行った.その結果,経路選択において本方式が有
効であることが確認できた.

A study on measurement Of one-way characteristics for end-to-end path selection

OGAWA K1yoshi* IIDA Noboru** WATANABETakashi SAWAI Arata GraduateSchOOlOfInformation,ShizuokaUniversity*NagoyaMumcipallndustrialResearchlnstitute FacultyofInformation,ShizuokaUniversity UniversityofHamamatsu
TherearemanyplaceswhereuserscanaccesstOthelnternetwithwiredorwlrelesslinks and it is soonable tO use several link sat the same time. ln the situation, user scan select better one-way path by considering it sone-way characteristics. This paper proposes a measurement t0 01forinferingd ifferences 0f one-way delay, which can be used t0 select the better path. We have developed a prototype of the tool and have evaluated the t001ⅲ lnternet enironment.

1 はじめに

近年,計算機の小型化,軽量化と通信インフラの普及
を挙げ,第3章で,片方向遅延差推測方式を提案する.
が進んでいる.ADSL回線などの有線インフラの利用に
そして,第4章にて,実装した提案方式の動作確認と,
加え,PHS,携帯電話によるインターネットへの接続
精度の改善を行い,第5節で,片方向遅延差の測定と提
や,ノートパソコン,PDA等の小型怪量端末と無線イン
案方式の評価を行う.最後に,第6節で,まとめと今後
フラを組み合わせたモバイル環境を利用するユーザも多
の課題について述べる.
い.今後も,第三世代携帯電話,無線LANによるホッ
トスポットサービス等の普及により,同時に複数の通信

2 既存の測定方式

手段を利用可能な環境が多くなる.そのような環境では,
以下に現在のインターネット環境において,片方向遅
複数の通信経路の中から,ューザにとってより適するェ
延を推定可能な方式のいくっか述べる.
ンドッーエンドの経路を選択することが可能である.現
在,ューザはエンドッーエンド経路の選択の尺度として,

2.1 往復pingとタイムスタンブオプションの利用

往復パスに関する特性を利用していることが多い.しか
この方式は,タイムスタンブオプションを指定した
し,使用するアプリケーションによっては,どちらか片
ICMPェコー要求バケットとその応答を利用する.クラ
方向のパスの特性に大きく影響を受ける.また,往路と
イアントが,ェコー要求を送信した時刻,応答を受信し
復路が異なる経路を通ることにより,性能を向上させる
た時刻と,サーバで書き込まれたタイムスタンプにより,
ような実装も考えられる.よって,より適切な経路選択
片方向遅延を計測する.片方向遅延を求めるためには,
のためには,パスの片方向特性を考慮することが重要で
サーバとクライアント間の時刻同期がとれていること,
ある.われわれは,片方向ごとに経路を選択するために
および,サーバがタイムスタンブオプションに対応して
片方向遅延差に注目し,その測定方式について研究を行
いることが必要である.遅延差を測るのであれば時刻同
期は必要ない.
った.
以下,本稿では,第2章で,既存の片方向遅延測定方式

2.2 マルチキャストバケットの利用

MINCプロジェクトにより,マルチキャストバケット
を用いて,木構造パスに沿ったエンドッーエンドの観測
から内部リンクの特性を統計的に推定する方式の研究
が行われている卩Ⅱ2].また,マルチキャストが普及し
ていないため,複数のグループが,同様の推定原理をも
とに,ュニキャストバケットを用いる方式を提案してい
る卩].いずれも,多数回の試行による統計的な推定を
基にしている.

3 片方向遅延差推定方式

3.1 概要

我々は,本章において,片方向遅延差推測方式を提案
する.本方式では,計測を行う送信端末(以下クライア
ント)が,1回の計測(以下1セット)ごとに複数の
ICMPェコー要求バケットを,ほぼ同時に送信先端末
(以下サーパ.本稿では,計測バケットを返信するとい
う点においてサーバと呼ぶ)に送信する.クライアント
側で,送信するバケットの送信元アドレスを返信先のア
ドレスへ書き換えることにより,複数の往復パスを経由
させる.クライアントが,送信バケットに送信時のタイ
ムスタンプを書き込み,ICMPェコー応答バケットを受
信した時刻とタイムスタンプの差をとり往復遅延を計
測する.各往復パスを通過したバケットの往復遅延を用
い片方向遅延差を推測する.

3.2 目的

研究の目的は,インターネット利用時,複数の経路の
中から,より適した経路をユーザが選択可能にすること
である.一般にユーザは接続リンクの帯域幅や往復遅延
を考慮し,パス選択をすることが多いが,ェンドッーエ
ンドで,アプリケーションごとに,片方向ごとの経路が
選択できることがより望ましい.そのために,本稿では,
経路を選択するための尺度として片方向遅延差に注目
し,片方向遅延差を測定するための測定方式を提案する.

3.3 想定環境

ューザ端末が,無線有線は問わず,それぞれにIPア
ドレスの付加された複数の通信インタフェースを有し
ている環境を想定する.例えば,PHSを使用してISP
(lnternetServiceprovider)1のアクセスポイントに
接続し,同時に,IEEE802.11bを使用してISP2に接
続している環境である.帯域幅だけに注目し,
IEEE802.11bを選択する場合があるが,それでは,ュ
ーザから見て1つ目のリンクにおける1つの尺度しか
評価していない.途中の経路で,帯域幅のボトルネック
が存在したり,輻輳が生じている可能性もある.また,
利用するアプリケーションによっては,遅延やバケット
ロス率などその他の要素がより重要になるだろう.
同じ通信方式を利用していても,接続ポイントが異な
れば工ンドッーエンドの経路が異なるので経路選択の
意義がある.例えば,2つのIEEE802.1lbインタフェ
ースにより異なるISPに接続している場合があげられ
る.このような例は,複数のサービス提供者が,電波範
囲の重なる場所で,無線チャネルを重ならないようにし
てサービスを提供している時に起こりうる.

3.4 設計方針

本研究では,主に以下の点を考慮し,測定方式を設計
している.

3.4.1片方向遅延差

片方向の特性を表す尺度として,片方向遅延差を扱う.
片方向遅延差とは,2つの片方向遅延の差分であり,経
路の遅延の大小を決定することが可能である.片方向遅
延自体を求めるためには,特別な機能がある測定対象サ
ーバや代理サーバ等が必要となるため,片方向遅延はユ
ーザにとって扱いにくい.本方式では,片方向遅延自体
を求めることはしないで,片方向遅延差を推測する.片
方向遅延差が求まれば,各パスを比較し,より遅延の小
さい片方向パスを求めることができる.

3.4.2 即答性

測定方式には,即答性を求める.例えば,本測定方式
の利用ケースとして,アプリケーションサーバへの最初
のアクセス時に測定を行うことが考えられるが,測定自
体に時間がかかりすぎるとサービスの低下につながる.
許容範囲内の時間で経路選択の尺度を提示することを
目指す.
また,[5]では,インターネット環境で,2つのping
の送信間隔を変史して送信し,往復遅延の相関関係につ
いて調査している.結果によると,最初のpmgバケッ
トの送信と2回目の送信との間隔の増加に伴い相関が
低くなる.これは,ネットワークは常に状態が変化して
おり,長期間に渡って多数回測定した推測値は,測定時
と推測値利用時との時間間隔の増加に伴い,利用時には
有効性が低くなることを示している.そこで,推測値を
利用する直前に行う即答性の高い測定を行うために,本
方式は,測定を比較的短期間で行うものとする.

3.4.3単体型測定

一般ューザが,容易に利用可能な測定方式にするため
に,代理計測サーバを必要としないで,測定ツール単体
で機能する方式をとる.その場合,ソースルーチングオ
プションを利用することにより,単体で機能することが
可能だが,対応するルータは少数であるため利用しない.

3.4.4 サーバ機能

適応範囲を広くするために,サーバ側にIP層より上
位の測定のための特別な機能を要求しない,また,サー
バでの対応が少ないICMPタイムスタンプ応答も,本
稿では利用しない.

3.5 片方向遅延差推定方式の動作と推測方法

3.5.1 往復パスn><n経路の場合の動作と推測方法

往復パスがn><n経路の場合とは,クライアントのイ
ンタフェースがn個存在し,サーバのインタフェースが
1個の場合である.クライアントは各インタフェースに
付加されたIPアドレスを送信元アドレスとしたICMP
ェコー要求バケットn個を,ほぼ同時に各インタフェー
スからサーバへ送信する.クライアントはICMPェコ
ー要求バケットのデータ部に,送信時の時刻を書き込み,
受信時に受信した時刻とバケットのデータ部のタイム
スタンプとの差を計算し,往復遅延を求める.推測は,
得られた往復遅延同士を組み合わせた差分を計算する
ことにより行う.送信バケットは1セットにつき,n><
n個送信し,往路でn個,復路で11個の片方向遅延差
を推定できる.これは,往復pingとタイムスタンブオ
プションを利用した場合の効率と同じである.以下に
クライアントインタフェースが2個の場合を例にして
動作と推測方法について述べる.

3.6 往復パス2><2経路の場合の動作例

クライアントにIPアドレスの付加された通信インタ
フェースが2つあり,サーバに1つある場合の動作を述
べる.クライアントは,インタフェースA(以下,IFA)
とインタフェースB(以下IFB)を有し,IFAには
IPアドレスA(以下CaddrA)が,IFBにはIPアド
レスB(以下CaddrB)が付加されている.サーバは,
IPアドレスSaddrAを有するものとする.
クライアント(図1のC)が2っ,サーバ(図1のS)
が1つのインタフェースを有する場合,往路で2つの片
方向パス,復路で2つの片方向パスが選択可能であり,
往復パスでは4つのパスが存在することになる.
実際のインターネット上では,1つの片方向経路は常
に同じ経路を通過するわけではない.IPルーチングで
は,ルータごとに送信先アドレスを参照して経路を決定
するため,同じ送信先アドレスを指定したバケットが異
なる経路を通過することがある.本稿での片方向パスは,
000囹00
信する.パス3も同様にしてバケットを通過させる.
過しクライアントの
Bに到着し,クライアントが受
返信されたICMPェコー応答バケットは,復路Bを通
レスに指定し,ICMPェコー応答バケットを返信する
レス,自身のIPアドレスであるsaddrAを送信元アド
ケットの送信元アドレスであるCaddrBを送信先アド
へ到着する.バケットを受信したサーバは,受信したパ
ICMPェコー要求バケットは,往路Aを通過しサーバ
ェコー要求バケットをIFAから送信する.送信された
saddrA,送信元アドレスをCaddrBに指定したICMP
パス2を通過させるためには,送信先IPアドレスを
コマンドを使用したときの動作と同様である.
ケットを通過させる.パス1とパス4での動作はping
3)往復遲1
(醪往復遅延3
(切往復遅2
|復路A-復路B|
朝|往路A-往路8
(町往復遅延
回|往路A-往路Bは物月復路Aー復路Bー
復路の片方向遅延差
往路の片方向遅延差
始点が端末のインタフェース,終点がIPアドレスで決
定されるものとする.
SaddrA
CaddrACaddrB
往復パス1
復整A
SaddrA
SaddrA
復路A(3)彳洛B
◎
CaddrACaddrBCaddrACaddr3
往復パス3
2><2経路
SaddrA
往路A
◎
CaddrACaddrd
往復ノ収4
往復パス2
図1
1セットの測定で,4本の往復パスすべてに,ほぼ同時
に計測バケットを送信する.クライアントはICMPェ
コー要求バケットのデータ部に,送信時の時刻を書き込
む.パス1を通過させるためには,送信先IPアドレス
をsaddrA,送信元アドレスをCaddrAに指定した
ICMPェコー要求バケットをIFAから送信する.送信
されたICMPェコー要求バケットは,往路Aを通過し
サーバへ到着する.バケットを受信したサーバは,受信
したバケットの送信元アドレスであるCaddrAを送信
先アドレスに,そして,自身のIPアドレスである
saddrAを送信元アドレスに指定し,ICMPェコー応
答バケットを返信する.返信されたICMPェコー応答
バケットは,復路Aを通過しクライアントのIFAに到
着し,クライアントが受信する.パス4も同様にしてパ
図2片方向遅延差の推測

3.7 往復パス2><2経路の場合の片方向遅延差推測

片方向遅延差は往復遅延の差をとることにより推測
する.本節では,2><2本のパスが存在している場合を
例にして,片方向遅延差の推測について述べる.図2
の(a)から(d)は,各往復パスの往復遅延を表しているも
のとし,それぞれの往復遅延1から4と呼ぶ.
ほぼ同時に片方向パスを通過するバケットの遅延が
同じであると仮定するならば,往復遅延1と往復遅延2
の差分をとることにより,復路Aと復路Bの片方向遅
延差を求めることができる(図2.(e)).同様に,往復遅延
3と往復遅延4の差分をとることによっても,復路A
以下に,本方式を利用する上での制約について述べる.

3.8 制約

応答バケットの返信時刻もほぼ同時であるとみなす.
稿ではその時刻の差は小さいものとして,ICMPェコー
る遅延時間によりばらっきが生じ,同時刻ではない.本
ICMPェコー要求バケットの送信時刻と各往路で生じ
サーバによるICMPェコー応答バケットの送信時刻は,
A,復路でBを通る往路遅延差を往路遅延差Bと呼ぶ.
図2.(g)).復路で経路Aを通る往路遅延差を往路遅延差
復遅延2と往復遅延4の差により計算できる(図2.(f),
往路の片方向遅延差は,往復遅延1と往復遅延3,往
遅延差Bと呼ぶ
差を往路遅延差A,復路でBを通る往路遅延差を往路
なるパスである.以下,復路で経路Aを通る往路遅延
2.(h)).その2つの片方向遅延差が通過した往路は,異
と復路Bの片方向遅延差を求めることができる(図

3.8.1 送信元アドレスの書き換えバケットの破棄

本方式では,クライアントからの送信バケットの送信
元アドレスを書き換えることにより,返信バケットの復
路パスを操作している.クライアントの接続先の組織か
らみると,送信元として存在し得ないIPアドレスから
バケットが送信されてきたことになる.インターネット
上では,送信元アドレスを詐称することにより様々な不
正行為が行われているため,そうしたバケットを転送せ
ずに破棄するように設定されているルータやファイア
ウォールが存在する.そのような環境では,本方式の機
能は制限される.すべての復路遅延差を推定するために
は,少なくとも1本の往路パスで送信元アドレスの書き
換えが可能であることが必要であり,すべての往路遅延
差を推定するためには,少なくとも(往路パス本数ーD
本の往路パスで送信元アドレスの書き換えが可能であ
ることが必要である.送信元アドレス書き換えバケット
破棄の問題は,MobileIPv4でも存在しており,IPv6
においては,経路制御拡張ヘッダの利用により解消する
ことが可能となる.その場合,拡張ヘッダにより,IPv4
でのソースルートオプションと同じように機能する.
IPv4であってもソースルートオプションがうまく機能
すれば,本方式でも利用可能である.

3.8.2 ICMPバケットの到達と返信

本方式では,ICMPェコー要求,ICMPェコー応答パ
ケットを計測に利用しているため,バケットは,それぞ
れ,クライアントからサーバへ,サーバからクライアン
トへ配送されなければならない.ルータやファイアウォ
ールによっては配送しない場合がある.また,ICMPェ
コー要求バケットに対して,サーバがICMPェコー応
答バケットを返信しなければならない.サーバによって
は,返信しない場合がある.ICMPェコー要求,ICMP
ェコー応答を利用する方法以外に,UDPェコープロト
コルを利用する方法,UDPバケットとICMP宛先到達
不能メッセージを利用し,クライアントで時刻を記録し
ておく方法がある.

3.9 実装上の考慮

3.9.1 insintervalの指定

本計測方式では,1セットの計測中では,ほぼ同時に
バケットを送信すると仮定している.それは,各計測パ
ケットに同じネットワーク状態を経験させるためであ
るが,1つのパスを通過する複数のバケットの間隔が短
い場合,先発バケットが後発バケットに影響を与える.
先発バケットは,パス上の各キューにおいて自然なキュ
ー遅延を経験するが,後発バケットは,各キューにおい
て先発バケットの影響を受け,遅延が増加してしまう可
能性が高くなる.この影響を少なくするために,1セッ
ト内では,同じ往路パス上は,一定の間隔を置いてバケ
ット送信する.その間隔をinsintervalとし,設定可能
とする.具体的に,3><3の経路が存在する場合を図3
に示す.最初に,図3.(a)の3つのバケットを連続して
送信する.これらのバケットは,同じ片方向パスを通過
しないため,相互の影響はあまりない(各パスが途中か
ら同一リンクを通ることにより相互に影響を与えるこ
とがある).次に,insinterval経過した後,図3.(b)
のバケットを送信し,さらにlnsinterval経過後,図
3.(c)のバケットを送信する.
こまでをセットと呼ぶ,
複数セット計測する場合はsetintervalで指定した間
隔ごとに,同じ動作を繰り返す.
クライアントにn個のインタフェースが存在する場
合,1セットの計測にかかる時間は,insintervalがな
い場合よりもinsinterval><(nー1)時間増加する.
そこで,setintervalは,(往路の本数><intinterval)
以上でなければならないと規定する.それは,セット間
のバケットが,insintervalより小さな間隔で,同じパ
ス上に送出されるのを防ぐためである.この規定がある
と,insintervalが増加すると,結果的にset_interval
も増加し,即答性が低くなる.
図31 セットとsetinterval

3.9.2 初期バケット遅延増加の回避

あるパスにバケットを連続して送信するにあたり,最
初のバケットの遅延時間が,それ以降のバケットに比へ
て増加することが知られている.これは,クライアント,
パス上のリンクやルータ,サーバ等のバケット転送機能
がしばらく使用されておらず,連続して送られているパ
ケットに対して要する転送時間よりも初期バケットに
要する転送時間が増加してしまうからであると思われ
る.そこで,最初の計測バケットを送信する前に各パス
に対してバケットを送信し,計測の初期バケットへの遅
延の増加を避ける.

3.10 応用:往復パスn><n本の場合

往復パスがn><n本の場合とは,クライアントの
インタフェースがn個存在し,サーバのインタフェース
がrn個の場合である.rn個のインタフェースが存在する
場合として,例えば,クライアントと同じように複数の
インタフェースをもつ端末がもう1台存在していて,そ
の端末に対して通信を行う例がある.端末間でIP電話
サービスを利用する場合など,特に片方向パスごとの遅
延差を求めることに意義があるであろう.n><n本
パスがある場合,クライアントは各インタフェースに付
加されたIPアドレスを送信元アドレスとしたICMPェ
コー要求バケットn個を,ほぼ同時に各インタフェース
から,サーバのインタフェースm個へ送信する.送信パ
ケットは1セットの測定につき,n><n個になる.

4 予備実験

4.1 ェミュレーション環境での動作実験

我々は,ェミュレーション環境を構築し,複数の実験
を行い,片方向遅延差測定方式の実装が正しく動作する
か確認した.以下に行った実験のうち2つについて述べ
る.

4.1.1 工ミュレーション環境

工ミュレーションネットワークを,クライアントPC1
台,サーノヾPC1台,NISTnetをのせたpc2台と/、プ
1台を用いて構成した(図4).NISTnetは,LinuxPCを,
ネットワークの様々な状況をエミューレートするルー
タとして構築するツールである[6].NISTnetにより,
ルータ上で,ネットワークの片方向遅延や遅延の平均偏
差等を設定することが可能である.
また,提案方式の計測中,クライアント,ルータ,サ
ーバのインタフェースで,到着するICMPバケットを
モニタリングし,正しい経路を通過しているか確認した
ル-タA:NISTNet
Client経路A
経路B
ル-タB:NISTNet
Server
図4工ミュレーション環境

4.1.2 動作実験1

動作実験1では,片方向遅延を,往路A-125ms,往
路A=100mS,復路B=150mS,復路B—75msと設定し,
遅延の平均偏差は,すべてOmsとした.4セットの計
測を行い,動作を確認した.得られた推測値を表1に記
す.1セットにおいて,往路の遅延差と復路の遅延差が
2つずっ得られ,それぞれ片方向の遅延差を推測できて
いることを確認した.
表1動作実験1の片方向遅延差推測結果
1
往路遅延差A(ms)
-24753
-25.0
-25.1
25.425
25.345
3
-24.78
-25.15
25.57
2520
4平均
/路遅延差B
路遅延差A
復路遅延差B
4.1.2動作実験2
-25℃05
25489
25237
-24.78
-25.01
25.501
25268
-24.8443
-25.079
25.49825
252635
実験2では,全片方向遅延を100mS,往路Aだけ遅
延平均偏差を20msにし,その他の経路の平均偏差をO
に指定した.4セットの計測を行い,動作を確認した
得られた推測値を表2に記す.往路Aの片方向遅延平
均偏差が影響しているのは,往路Aを通過するバケッ
トの往復遅延利用して片方向遅延差を計算する場合で
あり,往路Aを通らない計測バケットによる推測値,
復路遅延差Bは,影響を受けていないことを確認した
表2動作実験2の片方向遅延差推測結果
'主路遅延差A(ms)
1
23.146
/主路遅延差B
′路遅延差A
′路遅延差B
-5.948
四349
0255
2
12ユ02
9401
2832
0131
3
ー159
-1306
-2643
0.195
2276
-453
27.523
0223
平均
0.201
14.26525
-3.53525
10.5285

4.2 insintervalの設定実験

3.9.2節で述べたように,insintervalが小さすぎる
場合,1セット内の先発バケットが,同じパスを通過す
る後発バケットの遅延を増加させる.
ある1本のパスに,ボトルネックとなるリンクが存在
しているとする.そのパスに2つのバケットを同時に送
信するとき,先発バケットがそのパスのボトルネックで
待機させられる時間よりも,2つのバケットの送信間隔
が大きければ,後発バケットは,先発バケットの影響を
受けない.そのため,ボトルネックでの遅延時間を求め
ることができれば,先発バケットの影響を受けない最小
のinsintervalを設定できる.
ボトルネックリンクを推測する方式は,いくっか存在
するが,ューザが利用しやすいような方法でなければ,
実際に片方向遅延差測定を行うときに役に立たない.
本稿では,パス上の全リンクの状態を求めるのではな
く,少なくとも端末に直接つながっているリンクの特性
だけは,ある程度把握し,insintervalを求めるために
利用する.研究の前提である複数経路を有する環境は,
無線インフラを利用する場合に経験することが多いた
め,実際にボトルネックとなるのは,回線速度の小さい
1ホッブ目ではないかと予想する.もちろん,有線であ
ったとしても,当てはまる可能性はある.その予想が間
違っていたとしても,少なくとも1ホッブ目におけるパ
ケット同十の影響は排除できる.また,1ホッブ目のリ
ンクは,クライアントからの通信が通過する確率が非常
に高いので,そのリンクを通し異なるサーバにアクセス
する時に,手間をかけずにその結果を再利用することが
できる.
我々は,直接接続リンクでの遅延増加の観察を行うた
めに,最初にpmgを用いて遅延増加の観察を行う.そ
して,その結果が,提案方式において妥当であるか,提
案方式を用いて確かめる.

4.2.1 pingを用いた遅延増加の観察

a)実験方法
はじめにtracerouteを使い,クライアントから1ホ
ッブ目にあるルータを求める(クライアントのルーチン
グテープルより求めることが簡単であるが,実際にバケ
ットが転送されるルータと異なることがある).次に
送信時刻を記入したICMP工コー要求バケットを,1
ホッブ目ルータに,送信間隔1000mSから10msまで変
史して送信し,工コー応答バケットを受信することによ
り往復遅延を計測する.機能的にはpmgコマンドと同
じであり,本方式においてインタフェースが1つである
場合の動作と同じである.ICMPバケットは送信間隔に
つき64個ずっ送信を行う.また,あるサーバへのパス
のボトルネックとなっているリンクが,直接接続されて
いるリンクであるか確認するために,同じリンクを通し,
サーバに対しても同じ計測を行った.対象とする通信
方式はPDC,ADSL,PHSである.
b)結果と考察
1ホッブ目にあるルータへ計測した遅延を“通信方式
・往路後発A-往路先発A
復路後発A復路先発A
ー往路後発B-往路先発B
ー復路後発B-復路先発B
-◆-PDConehop
PDCserver
——ADSLonehop
++ADSLserver
----PHSonehop
ー・一PHSserver
60
6000
5000
()製き相一
3000
-20
2000
-40
1000
10
20
30
506080100300
5001000
insinterval(ms)
図6実測片方向遅延平均の差
純
20
30
団
6080100200300
500
1000
送信間隔(ms)
b)結果と考察
結果を図6に示す.往路後発Bと往路先発Bは,ど
図5接続リンクでの遅延増加
ちらも,往路でPHS回線を通過している片方向遅延の
平均である.insintervalが小さくなるにつれ,後発
名onehop',サーバへの計測値を。=通信方式名
バケットが先発バケットの影響を受けやすくなり,遅延
server”とし,得られた結果を図5に示す.接続リン
差が増加している.また,insintervalが100msで,
クが無線通信方式では,次ホップルータへの第一リンク
先発バケットと後発バケットの影響が少なくなってい
がボトルネックとなっていることが図5より確認でき
る.これは,pingを用いた結果とほぼ一致し,連続す
る.図5では,送信間隔が小さくなるにつれて,第一リ
る往復バケットによるinsⅲteⅣalの決定は,妥当であ
ンクにおいて遅延が増加している.しかし,その後サー
るといえる.ADSL回線を通過する経路Bに関しては,
バを経由する経路を通過しても,ほぼ同じ増分のままで
先発と後発のバケットの影響がほとんどないことがわ
ある.つまり,直接接続リンクより先には,隣接バケッ
かり,これも4.2.1項の実験値と一致する.
トに対して遅延を発生させるボトルネックとなり得る
リンクがないのである.この実験では,その他にも,サ

4.2.3 insintervalの決定

ーバへの往復遅延と次ホップルータへの往復遅延を比
以上の2つの実験の結果をふまえ,次章の複数の環境
較したとき,差分が全体の遅延よりも小さいことから,
での測定実験では,insintervalの値を200mSに設定
第一リンクの遅延がかなり大きいこともわかる.
する.
次に,insintervalの値について考察する.グラフよ
り,無線通信では,約100mSより送信間隔を小さくす

5 片方向遅延差推定方式の評価実験

ると遅延の増加が激しくなることがわかる.特に,PHS

5.1 測定実験環境

において顕著であり,insintervalの値には十分注意し
サーバは静岡大学浜松キャンパス内に設置し,クライ
なければならない.同じ無線であってもPDCはそれほ
アントは,PHS,ADSL,PDCをアクセス手段として用い,
ど急激な変動をとっていないこともわかる(ただし,
それぞれ異なるISPに接続する.実験で利用する通信
PDCはロス率が高くなるため,バケットロス率の差を
方式,回線速度の理論値,接続先を表3に示す.サーバ
求めるときには,評価が悪くなる)
とクライアントはNTPを利用し,計測を行う直前に,
同一LAN上で時刻同期をとる(片方向遅延差を求める

4.2.2 提案方式を用いた遅延増加の観察

場合に,実際には時刻同期は必要ないため,誤差は結果
a)実験方法
には影響しない).さらに,サーバでは,クライアント
本実験では,項4.2.1での結果が,実際の提案方式に
から送信されてくるICMPバケットをモニタリングし,
おいても当てはまるか調査する.4.2.1節の結果より,
インタフェースへのエコー要求バケットの到着時刻と
無線通信方式の中から特にinsintervalの値を長く設
応答バケットの送信時刻を記録する.計測に使用する
定しなければならないと思われるPHSを使用し,先発
ICMPェコー要求バケットは全実験において64byteと
バケットが後発バケットに与える影響について調べる.
した.本稿では,主に片方向遅延差の計測による推測片
片方向遅延差推定方式を用い,insintervalの値を変
方向遅延差の値と,サーバで計測された時刻を用いた実
化させ,後発バケットの実測片方向遅延と先発バケット
測片方向遅延差を比較する.
の実測片方向遅延の差の推移を観察する.経路Aは
ADSL,経路BはPHS接続である.1つのsetinteハ′al
ごとに,測定は8セット行い,セット間の影響を少なく
するためにsetmtervalは5000mSに設定する.

表3通信方式
通信方式PDC
ィーサネット
PHS
ADSL
上り(bps)
96k
512k
68k
100M
下り(bps)
96k
128k
1.5M
100M
静岡大学
接続先J-phoneb-mobileOCN

5.2 実験方法

いくっかの通信方式の組み合わせにおいて,決定した
insintervalを設定し測定を行い,推定値の値より推定
方式について考察する.使用する接続方式は,
ADSLPHS,PDCである.insintervalは200mS,
setinten′alは500mSに設定し,8セット測定した
実験4で計測した通信方式とその結果の図番号を表4
に示す.
表4各経路の通信方式
図9
経路Aの通信方式
ADSL
経路Bの通信方式
PDC

5.3 結果と考察

図7,8,9に得られた推測結果を示す.片方向遅延
差は,以後,経路B—経路Aの計算をして表示する.
経路Bの片方向遅延が経路Aよりも大きいと正の数と
してプロットされる.
図7では,推測往路遅延差Aと推測復路遅延差Aが
非常に正確である.本方式は2つのパスの共通パスで経
験する遅延の差が小さいほど,正確に片方向遅延差を計
算できる.上記の片方向遅延差推定が正確なのは,共通
パスが,遅延変動の少ないADSLだからである.共通
パスがPHSのときは,ADSLのときより,実測値との
差が大きいが,片方向経路を選択するという目的からみ
ると,十分な精度である.
図8のグラフはかなり変動が大きくなっている.セッ
ト番号が前半の推測遅延が極端に大きくなっている.
れは,PDCでの遅延に比べてPHSでの遅延が極めて大
きいからである.ただし,実測遅延差も同様な値をとっ
ていることからわかるように,測定の誤差ではない.実
際にこのような差をバケットが経験しているのである.
その遅延変動は,測定方式が原因で引き起こされるもの
ではない.PHSを利用するとき,送信し始めのバケッ
ト数個の遅延が非常に大きくその後落ちつくような現
象が見られるのである.本方式では,初期バケット遅延
の軽減を行うために1セットのバケットを送信してい
るが,この結果をみると十分でなかったと考えられる.
これは,今後の実装上の課題である.
推定の精度は,共通パスがPDCである場合は実測値
の変動が大きいにも関わらず,比較的正確なものになっ
ている.Pingによる実験でPDCは他の無線方式に比べ
変動が少なかったが,その結果とうまく合致する.
次に,共通パスがPHSの場合をみると1回の測定内の
変動が大きいにも関わらず.ある程度の精度が得られて
いる.これは本測定方式が1セット内でのみ推測を行
ー◆ー・推測彳主路遅延差A
推測復路遅延差A
ー推測往路遅延差B
ー推測復路遅延差B
実測往路遅延差A
ー・一・実測復路遅延差A
-・--十一・実測彳主路遅延差B
-・・・-・一・実測復路遅延差B
図7ADSL-PHS
図8
PDC
PHS
図7
ADSL
PHS
推推推推実実実実
1200
1000
図8PDC-PHS
ー・-・一一推住格遅延差4
ーー倉ー-攅ま畴を延差日
ーーー-攅復延差日
ー-・・一一実復格遅延差4
nl_lmber
図9ADSL-PDC
っているからである.たとえセット間の変動が大きくと
際のインターネット上での計測を行った.その結果,経
も,セット内で同じようなネットワーク環境を経験でき
路選択において本方式が有効であることが確認できた
れば,精度は悪化しない.一般に連続して送信するバケ
今後は,多くの接続環境でより多くのデータの収集,
ットの間隔が大きくなるほど,相関が低くなるため,
精度の評価を行い,適した設定値の考察や実装の改良を
insintervalの値を大きくし過ぎると,推測の精度が下
行う.さらに,インタフェース数nの値を増加させた
がる.ただし,逆にinsinteⅣalの値を小さくしすぎる
計測,n><n経路の計測,バケットロス率差の推測
と実験で述べたように後発バケットが先発バケットの
の実装を行う予定である.
影響を受け精度が下がってしまう.図8の場合は,セット内では,変動が小さかったため精度があまり落ちていないと考えられる.
図9のADSLを共通部分としてもっ経路は,精度が
高く推定できている.PDCを共通部分にもっ経路は,
Comunications、信g.,pp.152-158公lay2000
予想よりも正確に測定が行われていない.実験時の
PDCと通る経路が安定していなかったことも考えられ
るが,その他の測定方式に起因する問題である可能性も
ある.ただし,経路選択は正しく行うことができる.
全体の結果より,本方式は,経路選択を行ううえで十
分な精度があり,経路選択を有効に行えるといえる.

6まとめと今後の課題

本稿では,片方向ごとに経路を選択するために,片方向遅延差に注目し,片方向遅延差推定方式を提案,実装した.片方向遅延差とは,2つの片方向遅延の差分であり,経路の遅延の大小を決定することが可能である.片方向遅延差推定方式の実装後,動作確認を行い,実

参考文献

[1]AndrewAdamsRamonCaceresNickDuffieId,and
et.al.,”TheuseOfend-to-endmulticastmeasurementfor
charactenzmgmternalnet、vorkbehmor,
IEEE

[2]M.Coate,A.Hero,RNowak,and B.Yu,”lnternet tomography,"IEEE Signal Proc. Mag. pp.152ー158, May 2002
[3]N.Duffield,J.Horowiz,F.L.Presti and
D.Towsley,'Networkdelaytomographyfromend-to-end unicast measurements,"inProc.int. WorkshoponDigital Communications, September 2001
[4]M.Coatesand.R.Nowak,”Network distribution inference from end-to-endumcastmeasurements,mProc.lnt. WorkshoponDigitalCommumcations,September2001
[5] 岡山本幸寿,渡辺尚,,,分散オプジェクトシステムにおける複製配置方式の評価について,''マルチメディア,分散,協調とモパイルシンポジウム論文集、,01.2000,00.7,pp.67:72
[6]澤井新,小川清,飯田登,渡辺尚"MobileIPtおける経路最適化選択の検討",情報処理学会MBL, November,2000
[7]http://www.itl.mst.gov/div892/itg/carson/nistnet/