卒業制作最終発表 linkpoint: ネットワーク負荷軽減のために dns...

卒業制作最終発表卒業制作最終発表

LinkPoint: LinkPoint: ネットワーク負荷軽減のためにネットワーク負荷軽減のためにDNSDNS による近接性を取り入れたによる近接性を取り入れた P2PP2P システムシステム

慶應義塾大学環境情報学部黒宮佑介（ kuro ）親 : 斉藤（ ks91 ）さんサブ親 : 重近（ nazo ）さん

目的目的

　 P2P ネットワークにおいて　下位層トポロジを考慮した網の構築を可能にする

• ネットワーク・計算機資源の有効活用– 近接通信で完結するデータ転送– バックボーンへの負荷を低減– 利便性の向上・新しいサービスの創発

23/04/22 卒業制作最終発表 2

背景背景

• P2P システムの普及– クライアント・サーバモデルとは異なる応用方法

によって構築されたネットワークシステム• 特徴

– ○ 利点：負荷分散性・耐障害性に優れる• 動画などの大容量コンテンツの配信• インターネットクラウドなどの高負荷な処理への対応

– × 欠点：管理・制御が難しい• 展開されるネットワークの全容を把握することが困難• ネットワークトポロジが流動的


問題点問題点

• P2P システムにおける管理性・制御性の欠如– 不規則な P2P ネットワークトポロジを形成

　• 下位層を考慮しないトポロジにより

– 必要以上のトラフィックが発生しバックボーンを圧迫


同じデータなのに遠くから…同じデータなのに遠くから…

Internet Transit

Regional Routers

Edge Network

Regional Routers

Edge Network

Search & File Transfer

組織 A

組織 B

考え方：ネットワーク距離考え方：ネットワーク距離

• 下位層ネットワークトポロジ– そのものを取得するには大量のコストが必要

• 間接的に表現する指標– ネットワーク距離

「指標」を用いることでコストを低減


P2PP2P ネットワークにおけるネットワーネットワークにおけるネットワーク距離ク距離

• 既存手法では RTT や Hop Count が使用される– RTT はデータ転送パフォーマンスの向上のた

め本研究の目的には適さない

– Hop Count は計測ができないノードが多い• トラフィックを集約するための指標が必

要


アプローチアプローチ


• DNS を利用したネットワーク距離– 管理ドメインに着目

• 管理ドメインのラベル : FQDN– 同一のドメイン名を持つノード

• 単一の組織に属しているためネットワーク的に近い

– 優先的に接続する• トラフィックの削減・

集約が可能に

root.

A-a A-b B-a B-b C-a C-b

Distance

ne ad

jp

3rd Level Domain

Sub Domain

2nd Level Domain

Top Level Domain

Distance

Network Distance

Network Distance

A B C

a b c d

FQDNFQDN の解析の解析

• Fully Qualified Domain Name （ FQDN ）– 組織名・地理情報・ネットワーク ID などが含

まれる• FQDN の解析手順

1.ドメインレベルの判定一致しなかったところで終了

2.レーベンシュタイン距離を計算自分のホスト名との差を求める


ドメインレベルレーベンシュタイン距離

p1234-ipbf5678marunouchi.tokyo.ocn.ne.jpp1234-ipbf2222marunouchi.tokyo.ocn.ne.jp

レーベンシュタイン距離レーベンシュタイン距離

• 2 つの文字列の類似度を示す数値–編集距離ともいわれる

• 文字列操作–置換–挿入– 削除必要な手順の最小回数を求める

• 類似度が低いほど大きな数値が出る23/04/22 卒業制作最終発表 9

例）レーベンシュタイン距離 : 31. kitten2. sitten “（ k” を“ s” に置換）3. sittin “（ e” を“ i” に置換）4. sitting “（ g” を挿入して終了）

出典 : Wikipedia

FQDNFQDN による優先度による優先度

• FQDN を解析、「優先度」としてスコアを求める– ドメインレベル

• ドメインレベルごとに 64 点を加算

– レーベンシュタイン距離• 64 点からレーベンシュタイン距離を引いた点を加算

– 64 点• “.” で区切られる最大長（ 63文字）＋ 1 点

• FQDN を詳しく解析すること– ネットワーク距離を細かく分析することにつなが

る23/04/22 卒業制作最終発表 10

評価評価

• 実測データを用いた検証– FQDN による優先度を実測データによって検証

する• OCN• BBTEC

• 提案アルゴリズムの検証– FQDN の解析アルゴリズムを他のドメインの

FQDN の命名規則をもとに検証する• 実ネットワークを用いた評価

– FQDN による優先度によってトラフィックの影響範囲が集約される様子を評価する


実測データを用いた検証実測データを用いた検証

• 実 P2P ネットワーク上のノードに対して検証– 対象 : Winny ・ Share

• 取得した実測データ– FQDN– Hop Count

• 観測期間とノード数– OCN ： 12/11～ 12/17 （ 168時間） 35,000

ノード– BBTEC ： 1/16～ 1/17 （ 48時間） 13,750 ノード


Hop CountHop Count を指標として用いるを指標として用いることこと• 本手法の目的

– インターネットにおけるトラフィックの局所化ネットワーク負荷の軽減

• ネットワーク負荷– フロースループット ×リンク数

• Hop Count–経由するリンク数を示している–小さくすることでネットワーク負荷は低減され

る Hop Count を小さくすることが重要


p****-ipbf****hodogaya.kanagawa.ocn.ne.jp

p****-adsao01yokonib1-acca.kanagawa.ocn.ne.jp

ノード数

Levenshtein DistanceDomain Level

ノード数

. jp ne ocn

OCNOCN から取得した実測データから取得した実測データ

• Hop Count と FQDN による優先度の比較




優先度が高くなるにつれて Hop Count が小さくなる

10

20

30

12

10

8

5

0 64 128 192 256 320 384

アルゴリズムの境界

295 300 305 310 315 320

分布 : 粗

分布 : 密

Levenshtein DistanceDomain Level

. net

ノード数

BBTECBBTEC から取得した実測データから取得した実測データ

• Hop Count と FQDN による優先度の比較


ノード数

softbank************.bbtec.net

10

20

30 30

20

10

0 64 128 192

アルゴリズムの境界

178 180 182 184 186 188 190

分布 : 粗分布 : 密

優先度が高くなるにつれて Hop Count が小さくなる

Hop CountHop Count とと FQDNFQDN 優先度の一致率優先度の一致率

• OCN

• BBTEC

• 一致率–実測データから任意の 2 つのノードを抜き出す– 優先度の高いノード＝ Hop Count が小さい


他のドメインの命名規則他のドメインの命名規則• 地域名・ ID のみが入るもの

– p123a45.tokynt01.ap.so-net.ne.jp– nttkyo123456.tkyo.nt.ngn.ppp.infoweb.ne.jp– pl123.nas955.p-tokyo.nttpc.ne.jp– OFSfb-123p123-123.ppp11.odn.ad.jp

• IP アドレスのみが入るもの– 123-45-67-89.eonet.ne.jp– 89.67.45.123.dy.bbexcite.jp

• IP アドレスの一部が入るもの– q6789.dynamic.ppp.asahi-net.or.jp

• 地域名・ ID と IP アドレスが入るもの– FL1-123-45-67-89.tky.mesh.ad.jp– i123-45-67-89.s05.a015.ap.plala.or.jp– 123x45x67x89.ap123.gyao.ne.jp


FQDNFQDN評価アルゴリズムの検証評価アルゴリズムの検証

• 本アルゴリズム– ドメインレベル＋レーベンシュタイン距離

• 他のアルゴリズム– ドメインレベルアルゴリズム– レーベンシュタイン距離アルゴリズム– 最長一致アルゴリズム


ドメインアルゴリズムドメインアルゴリズム

• 特徴– レーベンシュタイン距離を計算しなくて良い

– ホスト名の類似度が低い場合同じ優先度になってしまう

–例）　 p3002-ipbf1710hodogaya.kanagawa.ocn.ne.jp• 256pt: p3044-ipbf1710hodogaya.kanagawa.ocn.ne.jp• 256pt: p8210-adsao01yokonib1-acca.kanagawa.ocn.ne.jp


256

ノード数Max Priority

. jp ne ocn kanagawa

ノード数

ドメインアルゴリズムドメインアルゴリズム

• OCN の場合


ノード数

Hop Count に関わらず 1 つの優先度に集約

0 64 128 192 256

10

20

30

優先度 256

5

2

8

10

12

208 224 240 256 272 288 304 320

レーベンシュタイン距離アルゴリレーベンシュタイン距離アルゴリズムズム• 特徴

– ドメインレベルの判定を行う必要が無い

– 本来優先度の低いノード群を選ぶ場合がある–例）本アルゴリズム

• 1 位群 : p****-ipbf****hodogaya.kanagawa.ocn.ne.jp • 2 位群 : p****-adsao01yokonib1-acca.kanagawa.ocn.ne.jp

–例）レーベンシュタイン距離• 1 位群 : p****-ipbf****hodogaya.kanagawa.ocn.ne.jp • 2 位群 : p****-ipbf****kagawa.kagawa.ocn.ne.jp



p****-ipbf****kagawa.kagawa.ocn.ne.jp

ノード数

321st Group

2nd Groupノード数

レーベンシュタイン距離アルゴリレーベンシュタイン距離アルゴリズムズム• OCN の場合


p****-ipbf****kagawa.kagawa.ocn.ne.jp




第 2 位群が神奈川から香川へ

10

20

30

優先度 32

0 10 20 30 40 50 30 35 40 45 50

5

8

10

12

15

最長一致アルゴリズム最長一致アルゴリズム

• 文字列を右（後方）から最長一致する• 特徴

– 最も単純なアルゴリズム

– 有効に働く場合と働かない場合がある–例 1 ）　 p3002-

ipbf1710hodogaya.kanagawa.ocn.ne.jp• 有効に働く

–例 2 ）　 softbank219209190116.bbtec.net• 有効に働かない（ネットワーク ID があるため）




ノード数

UpperLower

ノード数


• OCN の場合




本アルゴリズムと同じ傾向に

10

20

30 上位下位

優先度

10 20 30 400 20 25 30 35

5

8

10

90% 10%

ノード数

UpperLower

ノード数


• BBTEC の場合


ノード数

90% 10%

近いものも優先度が低くなる

Hop Count: 10 以下

10

20

30 上位下位

優先度

0 2 5 8 10 12

10

20

30

9 10 11 12 13 14

FQDNFQDN評価アルゴリズムの検証評価アルゴリズムの検証

• ドメインレベルアルゴリズム– ホスト名が違う場合に対応できない

• レーベンシュタイン距離アルゴリズム–第 2 位群の精度の判定を間違う場合がある

• 最長一致アルゴリズム– 有効に働く場合と働かない場合がある

• 本アルゴリズム– すべての場合に適用可能であり、汎用性があ

る23/04/22 卒業制作最終発表 26

実装実装

• 　　 LinkPoint– ネットワーク距離に FQDN を用いた P2P シス

テム• 動作

– メタ情報管理• P2P システム内のファイルの情報を管理• FQDN をメタ情報に付加

– データ転送• メタ情報に含まれる FQDN から接続ノードを決定• ネットワーク距離の近いノードからデータを取得


評価評価

• 実ネットワークを用いた実験–実装のテスト：データ転送時のノード選択

• 自分以外のノードが同じデータを保持自分にとって近いノードからデータを取得するか確認

– アルゴリズムの評価：データ拡散時のノード選択

• 各ノードがそれぞれ個別のデータを保持データ拡散時にデータ転送が近接で収束するか検証

• データを 3種類用意– 10MB, 100MB, 1000MB– ノードあたりのデータ転送量を取得


実験環境実験環境


dmc.keio.ac.jp ics.keio.ac.jp

keio.ac.jp Domain

The Internet

other Domain

bbexcite.jp bbtec.net

20 19

18

15

6 8

11

12

13

16

15 18

sfc.keio.ac.jp

ocn.ne.jp

15

① ③ ⑤

② ④ ⑥

7

15

FQDNFQDN による優先度による優先度

• 本アルゴリズムによって計算した優先度


bbexcite.jp

ocn.ne.jp

bbtec.net

dmc.keio.ac.jp

sfc.keio.ac.jp

ics.keio.ac.jp

bbexcite.jp - 64 0 64 64 64ocn.ne.jp 64 - 0 64 64 64bbtec.net 0 0 - 0 0 0dmc.keio.ac.jp 64 64 0 - 192 192sfc.keio.ac.jp 64 64 0 192 - 192ics.keio.ac.jp 64 64 0 192 192 -

実験結果（データ通常転送時）実験結果（データ通常転送時）

• 異なるドメイン間の結果


bbexcite ocn bbtec

遠くからもデータを受信

同じドメインがいない場合ネットワーク距離は関係ない

15 16 17 18

100MB

200

300

400

11 12 13 14 15 15 16 17 18 19 20

実験結果（データ通常転送時）実験結果（データ通常転送時）

• 同じドメイン間の結果


dmc sfc ics

同じドメインがいる場合ネットワーク距離は有効に働く

近くからデータを受信

100MB

200

300

400

500

600

8 10 12 15 18 20 8 10 12 15 18 20 8 10 12 15 18

• 異なるドメイン間の結果

実験結果（データ拡散時）実験結果（データ拡散時）


①bbexcite ③ocn ⑤bbtec

同じドメインがいない場合ネットワーク距離は関係ない

遠くからもデータを受信

15 16 17 18

250MB

500

750

1000

1250

1000

2000

3000

11 12 13 14 15 15 16 17 18 19 20

1000

500

1500

2000

実験結果（データ拡散時）実験結果（データ拡散時）

• 同じドメイン間の結果


②dmc ④sfc ⑥ ics

同じドメインがいる場合ネットワーク距離は有効に働く

近くからデータを受信

8 10 12 15 18 20

250MB

500

750

1000

1250

8 10 12 15 18 20

1000

2000

3000

4000

5000

1000

2000

3000

4000

5000

8 10 12 15 18

実ネットワークによる実験実ネットワークによる実験

• 同じドメイン名を持つノードが存在しない場合– ネットワーク距離は有効に働かない

遠くからもデータを取得• 同じドメイン名を持つノードが存在する場合– ネットワーク距離は有効に働く

近くからデータを取得

• ネットワーク負荷の軽減が可能23/04/22 卒業制作最終発表 35

まとめまとめ

• 目的：　 P2P ネットワークにおけるネットワーク資源の有効活用– 問題点：不規則なネットワークトポロジ

• アプローチ： DNS の管理ドメイン– FQDN に着目

• 評価： FQDN の解析アルゴリズム– ドメインレベル＋レーベンシュタイン距離–汎用性・精度の面において優位（ 80% の一致率）


今後の展望今後の展望

• 新しい指標の検討– FQDN 以外のパラメータの導入– BGP のルーティング情報の利用

• 評価方法の検討– スループット・セッション数に着目

• 研究成果の社会への貢献–様々な P2P システムへの対応– ISP への提言

• 近傍性の判定に有用になるような FQDN の利用


ご清聴ありがとうございましご清聴ありがとうございましたた

[email protected]


参考文献参考文献

[1] ISP を取り巻く状況と提案http://www.soumu.go.jp/joho_tsusin/policyreports/chousa/internet_policy/pdf/080627_2_si5-2.pdf


卒業制作最終発表 linkpoint: ネットワーク負荷軽減のために dns...

Documents