ISOC-JP/JPNIC IETF95 報告会 ネットワーク計測関連WG報告

1. ISOC-JP/JPNIC IETF95報告会
ネットワーク計測関連WG報告
NTTコミュニケーションズ
技術開発部
亀井聡
lmap/nmlrg etc..
2016.05.10＠田町グランパークタワー

2. 自己紹介
 所属
• NTTコミュニケーションズ 技術開発部
• Data Science and AI Technical Unit
 インターネットトラフィック・品質の計測，解析．
 最近はビッグデータとかAIとかIoTとかも．
 IETFには IETF75 Stockholm から参加．
• P2PRG, ALTO, LEDBAT, DECADE, …
 Network Friendry な P2P アプリケーションのためのフレーム
ワークの標準化(総務省P2P実験)．
 RFC6875: 日本での実験結果．
• 少し間をあけてIETF87 Berlin から再度参加
 国内で実施している100ノード規模でのアクティブ計測との整合
性検討等．
2

3. 計測関連のWG/RG取り組み俯瞰
 LMAP (Large-Scales Measurement Performance)
• 大規模なネットワーク測定についてのWG
 IPPM (IP Performance Metrics)
• ネットワークの性能指標のWG
 NETCONF (Network Configuration)
• ネットワーク機器制御プロトコル
 NMLRG (Network Machine Learning Research Group)
• ネットワークデータへの機械学習適用を目指す研究．
LMAPの設立経緯とフレームワーク，最近の流れ，
データ分析を対象とした NMLRG を紹介
3

4. LMAP設立に至るバックグラウンド
 各国政府による主に消費者保護を目的とした取り組み
• アメリカ FCC(2010-)，イギリス Ofcom(2008-)，フランス
ARCEP(2013-)．
• 日本では総務省の「インターネットのサービス品質計測等のあり方に
関する研究会」(2013-)
• FCCは一般ユーザ，Ofcomは一般ユーザと調査員，ARCEPは調査員に
よる計測がメイン
• 日本では，調査員による人口メッシュで1500箇所，15都市での測定
を計画．対象はモバイル．
 IETF LMAP (Large-Scale Measurement of Broadband
Performance) での標準化開始
 FCC CTO の働きかけにより発足(2013-)．
 全体的に，アクセスを対象とした取り組みが中心．
 近年はモバイルもターゲットに．
4

5. LMAPで議論されている主なRFC/draft
 RFCs
• Large-Scale Broadband Measurement Use Cases
 RFC7536, 2015.05
• A Framework for Large-Scale Measurement of
Broadband Performance (LMAP)
 RFC7594, 2015.09
 WG draft
• Information Model
• restconf
• lmap-yang (Data Model)
• Registry (ippmが主導)
5

6. LMAPで議論されている主なRFC/draft
 RFCs
• Large-Scale Broadband Measurement Use Cases
 RFC7536, 2015.05
• A Framework for Large-Scale Measurement of
Broadband Performance (LMAP)
 RFC7594, 2015.09
 WG draft
• Information Model
• restconf
• lmap-yang (Data Model)
• Registry (ippmが主導)
6

7. Large-Scale Broadband Measurement Use Cases
 ISP, Regulator のユースケースを想定．
• ISP
 顧客のQoE．
 新しい装置や技術の影響評価．
 網設計
 SLA監視
 障害検知
• Regulator
 透明 (中立的)な性能情報の提供
 ブロードバンド化の進展の測定
 トラフィック管理状況のモニタリング
7

8. A Framework for LMAP
 Use Cases を受けて対象
を以下に限定．
• 単一組織による運用
• 測定エージェントは単
一コントローラに所属
 制御プロトコル
• HTTP(S), NETCONF-
YANG, IPFIX
 計測項目はIPPMで
8
+--------+ +-----------+ +-----------+ ^
|End user| | | Observed | End user | |
| |<-----|-----------|---Traffic--->| | |
| | | | Flow | | |
| | | | | | Non-LMAP
| | | | Measurement | | Scope
| | | |<--Traffic--->| | |
+--------+ | | +-----------+ |
................|...........|.................................V
<MP> |Measurement| <MP> ^
|Agent: | |
|LMAP | |
+----------->|interface | |
| +-----------+ |
| ^ | LMAP
| Instruction | | Report Scope
| (over Control | | (over Report Channel) |
| Channel) | +-----------------------+ |
| | | |
| | | |
| | v |
| +------------+ +------------+ |
| | Controller | | Collector | |
| +------------+ +------------+ v
| ^ ^ | ^
| | | | |
| | +--------+ | |
| | | v |
+------------+ +----------+ +--------+ +----------+ |
|Bootstrapper| |Subscriber|--->| data |<---| Results | Non-
+------------+ |parameter | |analysis| |repository| LMAP
|database | | tools | +----------+ Scope
+----------+ +--------+ |
|
v
MP: Measurement Peer

9. A Framework for LMAP
9
Controller
Measurement Agent
（MA）
Measurement Peer
（MP）
Collector
LMAP WG
IPPM WG
結果の蓄積，分析

10. LMAPで議論されている主なRFC/draft
 RFCs
• Large-Scale Broadband Measurement Use Cases
 RFC7536, 2015.05
• A Framework for Large-Scale Measurement of
Broadband Performance (LMAP)
 RFC7594, 2015.09
 WG draft
• Information Model
• restconf
• lmap-yang (Data Model)
• Registry (ippmが主導)
10

11. WG drafts
 Information Model を固めて Data Model に流し込んでからプ
ロトコル(restconf)を決める手筈で，計測項目は IPPM の
Registry を使う，という方向性．
 Information Model が固まりつつある．
11
object {
string ma-report-result-schedule-name;
string ma-report-result-action-name;
string ma-report-result-task-name;
[ma-metric-registry-obj ma-report-result-metrics<0..*>;]
[ma-option-obj ma-report-result-options<0..*>;]
[string ma-report-result-tags<0..*>;]
datetime ma-report-result-start-time;
[datetime ma-report-result-end-time;]
string ma-report-result-conflicts<0..*>;
[ma-report-table-obj ma-report-result-tables<0..*>;]
} ma-report-result-obj;

12. NMLRG (Network Machine Learning Research Group)
 IETF94, Yokohama から開催
 LMAP等WGがプロトコル定義を目指し，解析部分がスコープ外
なのに対し，分析事例が集まるのは貴重．アウトプットとして
目指しているのは survey, requirement．
 ネットワークがダイナミクスや複雑さを増す中，手動での運用
だけでなくプログラミングまでも自動化したいという要求に機
械学習で応えられないか．というのが動機．
12

13. NLMLRG in IETF94
 IETF94
• Introduction to Machine Learning, its potential usage in
network area, & the proposed NMLRG
• Multidimensional Aggregation for DNS monitoring
• Applying Machine Learning to Software-Defined
Networks
• Machine Learning in Spam Filtering
• Autonomic Network Configuration Using Machine
Learning
• Research on Network Fault Analysis Based on Machine
Learning
13

14. NLMLRG in IETF95
 IETF95
• Meeting theme guidance - network traffic
• HTTPS Traffic Classification
• ML in the Routers: Learn from and Act on Network
Traffic
• Application of Machine Learning to Flow-based Network
Monitoring
• Malicious domains: Automatic Detection with DNS
traffic analysis
• Machine-learning based policy derivation and
evaluation in broadband networks
• Predicting Interface Failures For Better Traffic
Management
14

15. 全体傾向
 チュートリアル的なものと夢を語るものと国際会議的(学会的)な
ものが混在．
• RGはだいたいこんな感じ．
 ようやく具体的なものが出始めている印象．
• WG連携はまだ．
15

16. HTTPS Traffic Classification
 HTTPS/HTTP-over-TLSの増加によりトラフィックの識別が難
しくなっている．
 フローの分別を機械学習で行った評価結果．
 maps.google.com / drive.google.com / dl.dropbox.com /
photos.dropbox.com を分離．
 エラー率0.2%ぐらい．まずまず．
 教師データはSNI等使ってオーソドックスに構築．
16

17. ML in the Routers
 ML in the Routers: Learn from and Act on Network Traffic
 ルータのデータを集めて学習するのではなく，ルータが学習す
る話．
 dynamic traffic alerting とか load balancing とか．
 連携して anomaly detection．routing policy の変更など．
 実装はこれから
17

18. Flow-based Network Monitoring
 Application of Machine Learning to Flow-based Network
Monitoring
 フローと一部をDPI(正確にはpacket trace)したものから生成し
た擬似フローで機械学習．
 詳細読み取れないが，おそらくCDNフローを検知している．
18

19. その他
 Malicious domains: Automatic Detection with DNS traffic
analysis
• DNSトラフィックからブラックリスト生成．
• Hadoop(Impala, Spark)環境でキャプチャデータを解析．
 Machine-learning based policy derivation and evaluation in
broadband networks
• モバイル等の複雑な機器ポリシーを機械学習で生成．
• Network Configuration と Traffic allocation が output
• 提案のみ．
 Predicting Interface Failures For Better Traffic Management
• 8ルータ1スイッチ構成の実機網で装置故障を検知
19

20. まとめ
 インターネット計測系の共通化の営みは淡々と進んでいる．
• 範囲を限定してはいるが，プロトコルがそろそろ固まりそう．
• 実装まではまだ少し時間がかかりそうではある．
 データ活用に関する議論は始まったばかり．
• 夢を語るものから地に足がついたものに移りつつある．
• WG連携やRequirement draftが出てくるまでもう少し．
 運用自動化，につながるといいな……．
20