適応的アプリケーションのための資源管理機構および資源量通知機構を持つフレームワーク

マルチメディア通信と分散処理ワークショップ 平成1o年11月

適応的アプリケーションのための資源管理機構および

資源量通知機構を持つフレームワーク

安 田 泰 勲 ， 稲 村 浩

NTT

情報通信研究所

干

2

3

9

-

0

8

4

7

神奈川県横須賀市光の丘

1

-

1

I

n

t

e

r

n

e

t

:

y

a

s

u

n

o

r

i

，

i

n

a

m

u

r

a

@

i

s

.

l

n

t

t

.

c

o

.

j

p

概要 移動ネットワーク環境では，マルチメディアアプリケー ションは柔軟な

QoS(

Q

u

a

l

i

t

y

o

f

S

e

r

v

i

c

e

s

)

を達成するた めに，ネットワークインターフェースの切替えに対して適 応的に振舞わなければならない.本研究では，アプリケー ションの適応制御のために，ネットワークインターフェー スの切替をトリガとしてその変化を通知し，資源管理を行 なう機構を持つフレームワークについて述べる.我々はこ のフレームワークを

RT-Mach

マイクロカーネル上に実 装し評価を行なった.本研究の特徴はインターフェースの 切替を適応動作のトリガとしたこと，‘資源管理機構'およ び‘資源量通知機構'が協調動作することである.

1.はじめに

ラップトップコンピュータでは様々なネットワークデ バイスが利用可能になっている. これらのネットワーク デバイスは

PCMCIA

カードで提供されている.ユーザ はコンピュータを利用中にデバイスを交換すること

(

h

o

t

-s

w

a

p

p

i

n

g

)

が可能であり，ユーザのモピリテイは格段に向 上した.例えば，オフィスにいるときはラップトップコン ピュータを

E

t

h

e

r

n

e

t

につなぎ，会議室に移動する時は無 線

LAN

に切替えて使うことによって，ネットワークを利 用するアプリケーションを使い続けることができる. 我々はこのような環境を移動ネットワーク環境と呼ぶ. 移動ネットワーク環境では，マルチメディアアプリケー ションは適応的に振舞わなければならない， なぜなら ネットワークデバイスの切替えによって利用可能なネッ トワーク資源の量が大きく変化するため，アプリケーショ ンの

QoS(

Q

u

a

l

i

t

y

o

f

S

e

r

v

i

c

e

)

に大きく影響するからで ある.デバイスの切替が起こった場合，通常の静的な資源 予約ではうまくいかない.例えば，

E

t

h

e

r

n

e

t

に接続され たラップトップコンビュータで，インターネット電話アプ リケーションとファイル転送アプリケーションを同時に 利用する場合を考える. 最初は，インターネット電話は

2Mbps

の帯域を予約し，ファイル転送アプリケーション は残りの帯域を利用している. ここで通信中にユーザが ネットワークデバイスを

E

t

h

e

r

n

e

t

(

lO

Mbps)

から

Wave-LAN(2Mbps)

に切替える.この場合，インターネット電 話は帯域を再予約するだけでなく，自分自身の

QoS

のレ ベルを落し，利用する帯域を減らす必要がある.このよう な適応動作を実現するためには，システムがネットワーク デバイスの変化をアプリケーションに通知しなければな らない. 本研究の特徴は，移動ネットワーク環境において柔軟 な

QoS

制御を達成するために，デバイスの切替をアプリ ケーションの適応動作のトリガーとしたこと，このフレー ムワークでは切替えによって変化した利用可能なネット ワーク資源量を通知する機構およびネットワーク資源の 管理機構の二つの機構が協調動作することである. 我々は，利用可能な資源量を通知する機構，および帯 域幅を制御する機構をもっフレームワークを設計，実装し た. このフレームワークの評価として，簡単な適応的ア プリケーションを用いたデバイス切替えのハンドリング の所要時間，帯域幅制御の正確さ，パケット送信のオーバ ヘッドの評価を行なった. まず，

2

節ではこのフレームワークの概要について述べ， 3節でプロトタイプの設計と実装について述べる. 次に

4

節で本プロトタイプの評価について述べる.最後に

5

節 で関連研究， 6節で今後の予定について述べ， 7節でまとめ る.

2

.

適応的アプリケーションのためのフレーム

ワークの概要

この節では我々が提案する適応的アプリケーションの ためのフレームワークの概要について述べる.このフレー ムワークは二つのメカニスム，資源管理機構および資源量 通知機構から構成される. まず，資源管理機構および資源量通知機構について述 べ，次にフレームワークの全体のモデルについて述べる.

-113-2

.

1.資源管理機構 資源管理機構では，ラップトップコンピュータで動作す る全てのアプリケーションの使用する帯域幅を制御する. アプリケーションは利用したい帯域帽の割り当て要求を 資源管理機構に伝える.資源管理機構は，アプリケーショ ンからの要求が現在利用可能な帯域幅より少ない場合は 帯域幅を割り当てを行ない，不十分な場合には割り当てを 行なわない. 資 源 管 理 機 構 を 導 入 す る 利 点 は 二 つ あ る 一 つ は 他 の アプリケーションが帯域幅を使い尽くさないようにアプ リケーション毎に保護することが可能になることである. 通常のオペレーテイングシステムでは全てのアプリケー ションに対して暗黙に公平に帯域幅を割り当てる. 例え ば，マルチメディアアプリケーションとそれ以外のアプリ ケーションを同時に使う場合を考えると，マルチメディア アプリケーションの方に帯域幅を余分に割り当てたいと いう要求がある. この要求を満たすためには資源管理機 構によって帯域帽を分割することが必要になってくる. 二つめの利点として，適応動作を行なうマルチメディア アプリケーションを実装する場合，資源管理機構を利用す ることによってプログラミングが簡単になる. もしこの 機構が利用できなければ，アプリケーションプログラマは アプリケーション自身が帯域幅の利用を調節する複雑な コードを書かなければならない.

2

.

2

.

資 源 量 通 知 機 構 ラップトップコンピュータで利用可能なネットワーク デバイスの例を表1に示す. d巴吋ce

I

bandwicl出

(

6

戸)

I

latency(msec) Ethernet

1

0

M

I

1

・・・

1

0

Wireless LAN

I

1

・・

.

2

M

I

1

・・・

1

0

serialjmodem

I

2

8

.

8

・・・

6

4k

I

1

0

・・・

1

0

0

表 1:移動ホストで利用できるネットワークデバイスと特性 この表からわかるように，ネットワークデバイスの帯域 幅や遅延はデバイスによってー桁から二桁のオーダで違 うため，固定的な資源予約だけでは許容できる QoSを達 成することは難しい.それゆえ，アプリケーション自身が 利用可能なネットワークに適応して QoSを変化させなけ ればならない.そこで本システムでは適応制御のトリガと してネットワークデバイスの切替えを用い，切り替えを資 源管理機構に通知する機構を用意する. 利用可能なネットワーク資源の量は，資源管理機構は使 用可能なデバイス名から検索した最大帯域幅から各アプ リケーションが利用している帯域幅を差しヲ￨いた値をア プリケーションに通知する.アプリケーションはこの通知 された値をもとに，再割り当て要求を出し，適応動作を行 なう.

2

.

3

.

フ レ ー ム ワ ー ク の モ デ ル Mobile Host Application

ぢ町田

Library _No

的

ご

ス

回

N岨 fy D p a

合

packet

円

Detect

I

Network Device

¥/・

INetwork Device1 change 図 1:フレームワークのモデル ここではフレームワーク全体のモデルについて述べる. 図1に全体のモデルを示す.我々のフレームワークは三つ のコンポーネントから構成される. 一つめは‘Arbiter'であり，これは資源管理機構を実現 している.‘Arbiter'はアプリケーションからのパケット を全てうけとり，アプリケーションからの QoSパラメー タ(帯域幅，遅延)をもとにスケジューリングを行なう. 二つめは 'Notifier'であり，これはPCMCIAカードイ ベントからネットワークデバイスの切替を検知し，ネット ワークデバイス名を‘Arbiter'に通知する.‘Arbiter'は ‘Notifier'から通知を受けとると，利用可能な帯域幅と遅 延に変換し，アプリヶーションに通知する.資源量通知機 構は‘Notifier'と‘Arbiter'が連係することによって実現 されている. 三つめは‘Library'であり，これはアプリケーション にリンクされている. これはアプリケーションと‘Ar・ biter'とのインターフェースであり，アプリケーションは この‘Library'を利用することによって‘Arbiter'にQoS パラメータを伝えたり，‘Arbiter'からの通知を受けとっ たりすることが可能になる.

3

.

フ レ ー ム ワ ー ク の 設 計 と 実 装 この節では2節で述べたフレームワークのモデルをも とにした設計と実装について述べる. まずこのフレーム ワークを設計，実装したプラットフォームについて述べ， 次に各コンポーネントの設計，実装について述べる.最後 に各コンポーネントの協調動作の様子について述べる. 我々はプラットフォームとして RT-Mach[7]マイクロ カーネル環境を選択した.RT-Machマイクロカーネルは マルチメディアアプリケーションを実装するためのいく つかの便利な機能(リアルタイムマルチスレッド，リアル タイムスケジューラ，ネットワーク透過なプロセス問通信 など)を提供している.

-114

-3

.

1

.

Arbiter

の 設 計 と 実 装

A

r

b

i

t

e

r

はパケットスケジューリングによって帯域帽を 制御する.

A

r

b

t

i

e

r

はアプリケーションからの要求をもと にキューを作り，

QoS

パラメータを設定する.

QoS

パラ メータは帯域幅と遅延の組である.このフレームワークで は

UNIX

ソケット互換のプログラミングインターフェー スを採用しており，キューは一つの

UNIX

ソケットに対 して一つ用意される.

A

r

b

i

t

e

r

はアプリケーションから ソケッ ト経由で受けとった全てのパケットをキューに入 れ，キューのパラメータに基づいてスケジューリングを行 ない，ネットワークデバイスに書き込む. 本実装ではパケットスケジューリングアルゴリズムと して

Weighted

D

e

f

i

c

i

t

Round Robin (WDRR)[6]

アルゴ リズムを採用したこのアルゴリズムは

Weighted

Round

Robin (WRR)

を改良し，可変長パケットに対応したもの である.

WDRR

は帯域幅を制御することが可能であり，

Max

-

min f

a

i

r

s

h

a

r

e

に従う.パケットスケジューリング アルゴリズムとして

WeightedF

a

i

r

Queuing

(WFQ)

[

6

]

アルゴリズムが知られているが，計算時間の短さ，実装の 容易さから

WFQ

ではなく，

WDRR

を選択した.本実 装では主に帯域幅の制御を行なっているが，遅延に関して は低遅延，高遅延の 2レベルを用意することで，対話処 理を行なうプログラムなどの低遅延が必要なプログラム に対応している. 低遅延のキューに入っているパケット は，常に高遅延のキューに入っているパケットよりも優先 して送出される. キューはプロトコルスタック処理部とデバイスドライ パの間に位置する.デバイスドライパの中にキューを作っ た場合，切替える可能性のある全てのデバイスのデバイス ドライパを変更しなければならないため，実装の手間が大 きい. しかし，このように設計するによって，特定のプ ロトコルやデバイスに依存せずに，様々なプロトコルのパ ケットやデバイスを一元的に扱うことができ，実装の手間 も減らすことができる.

3

.

2

.

Notifier

の 設 計 と 実 装

N

o

t

i

f

i

e

r

はネットワークデバイスの切替を検知し，

A

r

-b

i

t

e

r

に通知する機能を持つ.ラップトップコンピュータ の切替え可能なデバイスは

PCMCIA

カードで提供され ているため，

PCMCIA

カードイベントをハンドルするこ とにより，ネットワークデバイスの検知を行なう.

N

o

t

i

f

i

e

r

は，

M K

時 プ ロ ジ ェ ク ト

[

5

]

によって

RT-Mach

環境に移植された

PAO[l]

と連係して動作する.

PAO

は

FreeBSD

用のモパイルパッケージであり，

PCM-CIA

カードイベントハンドラ

(

p

c

c

a

r

d

d

)

や各種デバイス ドライパなどを持つ.

N

o

t

i

f

i

e

r

は，

PCMCIA

カードイベ ントハンドリングを行なう

p

c

c

a

r

d

d

からイベントを受け とり，ネットワークデバイスの設定が終った後に，

A

r

b

i

t

e

r

にメッセージとして有効になったデバイス名を通知する.

3

.

3

.

Library

の 設 計 と 実 装

L

i

b

r

a

r

y

はアプリケーションが

A

r

b

i

t

e

r

と通信するた めの

A

p

p

l

i

c

a

t

i

o

n

Programming I

n

t

e

r

f

a

c

e

(

A

P

I

)

を提 供しており，アプリケーションはこれらの

API

を使うた めに

L

i

b

r

a

r

y

をリンクする. これらの

API

では主に

A

r

b

i

t

e

r

に

QoS

パラメータを設定，変更，削除する関数， 適応動作するためのハンドラを登録する関数などがある. データの送受信には，

L

i

b

r

a

r

y

に用意されている

s

o

c

k

e

t

O

，

bindO

，

sendO

，

recvO

などを用い，

UNIX

ソケツトプロ

グラミングと同様に行なう. アプリケーションは本

API

を用いて各キューにパラメータを設定する.適応動作のた めのハンドラも各キューに対して設定する.帯域幅の設定 は現在利用可能なデバイスの最大帯域幅に対する割合で 指定し，遅延の設定は低遅延，高遅延のどちらかを指定す る.パラメータの設定がない場合には，割り当てられてい ない残りの帯減幅を利用することになり，ハンドラを設定 しない場合には適応動作なしでそのまま動作する.

RT-Mach

マイクロカーネル環境では，通常アプリケー ションがネットワークを利用する場合には，

L

i

t

e

s

4

.4

BSD

・

L

i

t

eUNIX

s

e

r

v

e

r

(以下

L

i

t

e

s

)

でプロトコル処理を 行ないデータを送受信する.しかし，これとは別に処理性 能を向上させるために，プロトコル処理を行なうライブラ リ

l

i

b

s

o

c

k

e

t

s

[

3

]

が用意されている.

l

i

b

s

o

c

k

e

t

s

では

UNIX

ソケットインターフェースを持ち，通常のネットワークプ ログラミングスタイルでコーデイングを可能にしている. 本実装は

l

i

b

s

o

c

k

e

t

s

をベースとし，

A

r

b

i

t

e

r

との通信用

API

の追加，およびキューイングを行なうための

UNIX

ソケットシステムコールの内部処理の変更を行なった.

3

.4.各コンポーネントの協調動作 ここでは

A

r

b

i

t

e

r

，

N

o

t

i

f

i

e

r

，および

L

i

b

r

a

r

y

の協調動 作の様子について述べる.本プロトタイプの実装の全体図 を図2に示す. アプリケーションはまず

L

i

b

r

a

r

y

を用いて

UNIX

ソ ケットを作り，次にソケットにパインドされたキューに

QoS

パラメータを設定する.

QoS

パラメータは帯域幅 と遅延の組である.アプリケーションはパケットをソケッ トに送ることによってAr

b

i

t

e

r

のキューに入れる.パラ メータを設定しない場合には共用のデフォルトキューに パケットが送り込まれる.デフォルトキューにあるパケッ トは未割り当ての帯域幅がある場合にはその分を適宜利 用して送出される.

A

r

b

i

t

e

r

は

QoS

パラメータを受けとると，アドミッ ションコントロールを行なう.つまり，現在利用可能な帯 域幅をチェックし資源が十分にある時には割当を行ない， 十分でない場合には利用可能な帯域幅をアプリケーショ ンに通知し，割り当ては行なわない.

PCMCIA

カードのネットワークデバイスが利用可能/ 不可能になった場合，

p

c

c

a

r

d

d

がカードイベントを処理 し，

m

e

s

s

a

g

e

s

e

n

d

e

r

を呼び出し，インターフェースを

e

n

-a

b

l

e

/

d

i

s

a

b

l

e

する

m

e

s

s

a

g

e

s

e

n

d

e

r

は利用可能/不可 能になったデバイス名とその状態(利用可能/不可能)を

-

1

1

5

-A

r

b

i

t

e

r

に通知する

A

r

b

i

t

e

r

は利用不可能のメッセー ジを受けとった場合，ただちにパケットの送出を止め，ア プリケーションの書き込みをプロックする.

A

r

b

i

t

e

r

は利 用可能のメッセージを受けとった場合，パケットの送出を 再開し，アプリケーションの書き込みのプロックを解除す る.さらに，新しい利用可能な帯域幅と平均遅延をアプリ ケーションに通知する. アプリケーションはメッセージを受けとると，通知され た情報を元に資源の再割り当て要求を出すことができる. 再割当要求を出さない場合には以前の割当のままで動作 を続ける.

M

o

b

i

l

e

H

o

s

t

A.ppJicaJi何S Arbittr 図

2

:

RT-Mach

上でのフレームワークの実装

4

.

評価

この節では本実装の評価について述べる.以下の三つの 基準で評価を行なった デバイス切替え処理の所要時間デバイスの変化に対する フレームワークの反応時聞を評価する. 通知機構は デバイスが変化した場合，可能な限り素早く変化を通 知し，資源管理機構と協調動作すべきであり，もっと も重要な評価項目である. 帯域幅制御の精度資源管理機構を評価する.指定した帯 域幅と達成した帯域幅の差で評価を行ない，差が小さ いほど良い結果が得られているといえる. パケット送出のオーバヘッドこの本実装でのスケジュー ラの配置の妥当性を評価する. この項目では

RT-Mach

マイクロカーネル環境で通常の設定でネット ワークを利用する場合と比較して，一つのパケットを 送出する処理に対してどの程度オーバヘッドが生じ るかを測定し，システムの実装の妥当性を判断する. 実験環境は以下の通り. 送り側

DEC

H

i

Note

U

lt

r

a

-

I

I

(

P

e

n

t

i

u

m

150MHz

，

56MB

memory

，

3COM 3C589

，

AT&T WaveLAN)

，

RT-Mach 3

.

0

+

L

i

t

e

s

(MKNG

・

0

0

3s

n

a

p

s

h

o

t

)

安け側

EPSONENDEAVOR(Pentium 133MHz

，

16MB

memory

，

3COM 3C509B)

，

RT-Mach 3

.

0

+

L

i

t

e

s

(MKNG-003 s

n

a

p

s

h

o

t

)

4

.

1.デバイス切替え処理の所要時間 この項目では二つの単純なテストアプリケーションを 実装し評価を行なった. これらのアプリケーションは

1

4

7

2

バイトの

UDP

パケットを連続的に送信するプログ ラムである.違いは，

A

r

b

i

t

e

r

に管域幅の割り当て要求お よび変化への適応動作をする適応的アプリケーションか， 適応動作をしない非適応的アプリケーションかである. この実験の手順は，まずラップトップコンピュータに

E

t

h

e

r

n

e

t

(

l

O

Mbps)

と

WaveLAN(2Mbps)

の

PCMCIA

カードを予め挿入しておき，

E

t

h

e

r

n

e

t

の方だけを有効に しておく. 次に適応的アプリケーションは

E

t

h

e

r

n

e

t

に 対して

8

0

0

k

b

p

s

になるように割合を計算して

A

r

b

i

t

e

r

に帯域の割り当て要求を出し，パケットを送出する. ま た、非適応的アプリケーションは特別な処理はせずに単 にパケットを送出する. そして，ユーザがネットワーク インターフェースを切替えるコマンドを呼ぴだし，

E

t

h

e

r

-n

e

t

から

WaveLAN

に有効なネットワークデバイスを切 替え，ネットワークインターフェースやルーテイングテー プルの再設定を行なう.

N

o

t

i

f

i

e

r

はデバイスの切替を検 知するとメッセージを

A

r

b

i

t

e

r

に送る.

A

r

b

i

t

e

r

はメッ セージを受けとると，適応的アプリケーションに利用可能 な帯域帽を通知する.適応的アプリケーションのハンドラ は

A

r

b

i

t

e

r

からのメッセージを受けとると，その値をもと に再割当要求を出す. この一連の処理の問も非適応的ア プリケーションは

A

r

b

i

t

e

r

によって余った帯域幅を利用 してパケットを送り続けている. 適応的アプリケーションの受け側での

1

0

0

パケット毎 のスループットおよびデバイスの切替によるハンドリン グの所要時間を計測した結果を図

3

に示す. 図

3

の上部は適応的アプリケーションのスループット を表している.この図からは

E

t

h

e

r

n

e

t

と

WaveLAN

の 両方でほぼ

8

0

0

kbps

のスループットが得られている.帯 域幅の指定値と達成値の差は

E

t

h

e

r

n

e

t

と

WaveLAN

の 両方あわせて，最悪でも土

8.5%

の範囲に収まっている. この測定では，結果をファイルに出力しながらアプリケー ションを動作させているため，測定結果の出力に要した時 間も含まれているため，ずれが生じている.純粋な帯域幅 制御の精度の評価は

4

.

2

節で行なっている. 図

3

の下部はネットワークデバイスの切替えのシーケ ンスを表している. まず，切替えコマンドが呼び出され ると，

N

o

t

i

f

i

e

r

は切替を検知し，

A

r

b

i

t

e

r

に

d

e

v

i

c

edown

メッセージを送る.

A

r

b

i

t

e

r

はそのメッセージを受けとる と，ネットワーク用のポートを

d

i

s

a

b

l

e

し，パケットの送 出を止める.ここまでの所要時間は

1

0

5

m

s

e

c

である.次 に，

E

t

h

e

r

n

e

t

インターフェースを

d

i

s

a

b

l

e

してからルー 一

1

1

6

-図からわかるようにEthernetでは指定値と達成値の差 は0%から・0.3%の範囲におさまっており，WaveLANで は 土0.5%の範囲におさまっているというように，ほほ指 定通りに帯域幅の制御が行なわれた.

一

一

_i g --↑ 一 E S E L i - -↑ l i t -- ;

⋮

1₁ 1 i + l l J I l l

-一

1₁ 4 ↓目 蜘 P E l f

-一

ト

!

十

l r L

ト

一 一

t

a

d

-什 一 パ 一

l i

一

_m

t

t a i

l e

丈

L

i a s - i

y

一 一 川 十 一 一 一 一

品 }

竺

了

V - 2

-一 : -一

4

一

J J i

一 白 ん

!

一

す

⋮ 一

一

一

一

一

一

1 1

⋮ 一 一 一 一 一 一 一 い 一 一 一 一

一 一

叶 一

一

一

一

一

一

一

_{一 ﹄ 一 一 一 一 - 川}

市

ゅ 一

_一

_一

_一

_一

_一

一

i

一 一 一 一 一 一 パ 寸 一 一 一 一 一 一 一 一

ハ ハ 一

z z

一 一

_一

_l

u

--

一

J

一 一

_一

_一

_一

_-

_一

一

問 問 初

p

b

L

却 m m o 80 図

4

:

資源管理機構によって達成されたスループット 検軸は指定した宇野域幅(%)で縦軸は達成した帯域幅(%).

4

.

3

.

パ ケ ッ ト 送 出 の オ ー バ ヘ ッ ド 由、即面合w回

h

n

e

i

-

-

-

c

t

x

:

:

山 政

官官

:

.

2

:

ヘ

バ

ZJHFZt(:17

鴇

;

X

F

z

a

面

司

-

-

・

ザ 三

:

￨

刷 叫

自

由

・

.

.

.

・

chinl 14 .. 言 12" ~ 100

。

10

。

70

。

_。

この項目では

UDP

パケットを送出するために，アプ リケーションがwriteOを呼んでからデバイスドライパに データが入るまでの所要時間を計測した.この実験を我々 のフレームワークを利用した場合， Litesを利用した場合， libsocketsを利用した場合の3通りについて 1000回繰り 返し，その平均値を図5にプロットした.我々の Library は libsocketsをベースにしているため，これと比較を行 なう. Litesは RT-Mach上でネットワークを利用する ための通常の方法であり，さらにアプリケーションがネッ トワークデバイスに直接パケットを書かず，ユーザレベル サーノ〈にパケットを渡すという点で我々のフレームワー クの実装と同様の構成のため比較の対象とした. 図

3

:

デバイスの切替えのハンドリングのチャート. ティングテープルをftushし，さらにWaveLANインター フェースを enableしてからルーティングテープルを更新 するのにかかった時間は 701msec. 最後に， device up メッセージを Arbiterに送り， Arbiterがネットワーク用 のポートを再設定し， パケットを再び送り出すのにかかっ た時間は 373msec.合計でデバイス切替のハンドリング の所要時間は1.337secであり，これは十分妥当であると 考える.なぜなら， すべてのアクテイプな TCPのコネク ションは，この実験で得られたハンドリングの所要時間で はタイムアウトせずにコネクションを維持できるからで ある. 制

••

醐 . ，

L

:

:

;

;

旬 -一 K ' H m -路 頭 -e : : : L o -・_{: :} ・ I l l t

-， -，

: : a o -: : ; : ? ? : :

，

T : : : ム m

t

'

;

:

・

;

-J j j E h -， 一 / 一 一 -一 一 -. ， 〆 h i -2 -1 1 7 4 ・ E -: ‘ •• . l o -・ ， 一 〆 日 目 : ‘ -d ﹃ 1 B ・ ; r - --馳 F I ・_: : F a -i ト ・ : ・_ι & l i l i -b e l o v -・ 0_・ ト : ・ : ム 嗣 酬 -M ， ， -4 E -a a 叩 山 由 一 一 一 五 戸 ケ 一 一 嗣 : -= -- ・ 2 -2 -脳 同 T ・ ・ 0 ・ ・ ・ rli v -i ( l l プ 1_・ i d i o -J J o j e r -- : 占 師 副 一 日 一 一 / 一 一 -一 一 回 一 日 一 一 J ・ 一 γ 一 一 E -U i - -欄 間 1400 醐 醐 守 - z 冨 E ト

。

_。

図

5

:

パケット送出の所要時間. 検輸はパケットの大きさ (bytes)で縦軸は所要時間(usec).

117-この項目では二つの単純なテストアプリケーションを 実装し評価を行なった. これらのアプリケーシヨンは

1

4

7

2

バイトの

UDP

パケットを連続的に送信するプログ ラムである.一つは帯域幅を

x%

指定し(以下

F

r

i

m

a

r

y

)

1000個パケットを送出し，もう一つは帯域幅 (100-

x%)

指定し(以下 Co叩etitio吋，Primaryとネットワークアク セスの競合が起きるように連続的にパケットを送出する. 測定は受け側で Primaryの 1000個のパケットを送出 するのにかかった時間をPentiumcounterを用いてEth -ernet， WaveLANのそれぞれで計測し，スループットを算 出した.結果を図4に示す.

4

.

2

.

帯域幅制御の精度

本プロトタイプは libsockets と比較すると常に遅く なっている. この原因は以下の二つであった. 一つはア プリケーションが Arbiter に固定長の IPC を利用して パケットを渡すパスが libsockets と比べて余分にあるた め，時間がかかっている. さらに，パケットを受けとる時 にデータコピーを行なうオーパヘッドもあり，パケットサ イズが大きくなるとそのオーバヘッドも増えている. Lites と比較する場合，データサイズが小さい場合には Lites より若干遅くなっているが，データサイズが大きく なると Libraryでプロトコル処理を行なっている分のゲ インがあるため Litesより速くなっている. この結果から本プロトタイプの実装は libsocketsに劣 るが，同じ構成の Lites とほぼ同程度の性能が得られてい るといえる.より実用性を高めるため，オーバヘッドを減 らすことを検討している.データコピーのオーバヘッドを 減らす方法として共有メモリ機構を実装する方法と， Ar-biterをカーネル内に実装するというこつの方法があるが， 実装の手間を考慮して，共有メモリ機構を実装する予定で ある.

5

.

関連研究

移動ネットワーク環境において適応的アプリケーショ ンのためのフレームワークは幾っか提案されているが，資 源管理と通知機構の両方をもっフレームワークは我々の 知る限りではまだない. 最も近い関連研究は JonInouye'のアプリケーション に特化した適応型システム

[

2

]

である.このシステムでは ピデオプレーヤがネットワークインターフェースの変化 に適応的に振舞う。本研究との違いは，このシステムでは 帯域帽の実測値をパラメータとしたフィードパックドリ ブンの適応制御を採用し，さらに資源管理機構をもってい ないことである. 他の適応型システムの関連研究として Brian D. No-ble と M. Satynarayanan による Odyssey[4] がある. Odyssey は実測ベースの適応制御を採用し，アプリケー ションに依存せず，資源のタイプに特化した QoSの適応 制御機構を提供している. システムは資源レベルを観測 し，関係のあるアプリケーションに予約の参考となる値を 提供する.資源管理機構を持たないため，アプリケーショ ンは資源の利用量を自分自身で完全に制御しなければな らない.それゆえ，アプリケーションプログラマは我々の ものにくらべて複雑なコードを書くことになる.

6

.

今後の予定

また，本プロトタイプが提供している APIはパラメー タに帯域幅と遅延の組を指定する必要がある.そこでアプ リケーションプログラミングをより簡単にするために，こ れらのパラメータをそのまま指定するのではなく，フレー ムレートや解像度，音質などのアプリケーション QoSで 指定できるようにし，現在の API を整理/改良する必要 がある. 今回は評価に実アプリケーションではなく，テストアプ リケーションを用いたが， NV(Network Video)を RT-Mach +本フレームワーク環境に移植し，適応動作も含め た動作確認は終っているので，今後はこれを用いた評価を 行なう予定である.さらに， N V以外にも httpproxyや インターネット電話， telnetなどの実アプリケーションを 適合させ，これらを用いて評価する予定である.

7

.

まとめ

この原稿では，適応制御のためのフレームワークについ て述べたさらに， RT-MachマイクロカーネJレ環境での フレームワークの実装し，評価を行なった.本研究の特徴 はインターフェースの切替を適応動作のトリガとしたこ と，‘資源管理機構'および‘資源量通知機構'が協調動作す るフレームワークであることである.

参考文献

(1) Tatsumi Hosokawa. PAO: FreeBSD Mobile Computing Packagej ava叩叫ila油，blea凶tht“t句均p炉p:ゲ///付ww叩w耽.担企eebs吋d.吋or略g/P臥'AO/

，

1997.

(2) Jon Ino町e，Sh組 問 Cen，Calton Pu， and Jonathan

Walpole. System Support for Mobile Multimedia Ap-plications. In Proceedings

0

/

NOSSDA V'97

，

pages 143-154

，

1997.

(3)Chris Maeda and Brian N. Bershad. Protocol Service Decomposition for High-Performance Networking. In In

Proceeding~

0

/

SIGOPS'93

，

December 1993.

(4) Brian D. Noble

，

M. Satyanaray姐 an

，

Dushyanth

Narayanan， James Eric Tilton， Jason Flinn， 回d Kevin R. Walker・AgileApplication-Aware Adaptation for Mobility. In Proceedings

0

/

SOSP・16

，

1997. (5)Keio・MKng project Keio University SFC. Mi -cro Kernel Next Generation Projectj available at http://www.mkg.sfc.keio.ac

担

/

，

1997. (6)S.Keshav. An Engineering Approach to Computer Net -working. Addison Wesley

，

1997.

(7)H. Tokuda

，

T. Nakajima

，

and P. Rω. Real-Time Mach: Towards a Predictable Real-Time System. In M ach

Workshop

，

USENIX Association

，

October 1990.