Graphes de Terrain
Dynamiques de l’internet
Clémence Magnien
LIP6 – CNRS and Université Pierre et Marie Curie
prenom.nom@lip6.fr
14 février 2013
Jusqu’à présent on a supposé :
une seule route entre une source et une destination routes fixes au cours du temps
...les deux sont faux
1 Paris traceroute et load-balancing Biais associé au load-balancing
2 Dynamique de la topologie de l’internet Contexte et approche
Tracetree Mesures Analyse
3 Détection d’événements dans la dynamique
4 Biais induit par la dynamique
Outline
1 Paris traceroute et load-balancing Biais associé au load-balancing
2 Dynamique de la topologie de l’internet Contexte et approche
Tracetree Mesures Analyse
3 Détection d’événements dans la dynamique
4 Biais induit par la dynamique
Principaux travaux de référence
Fabien Viger, Brice Augustin, Xavier Cuvellier, Clémence Magnien, Matthieu Latapy, Timur Friedman et Renata Teixeira Detection, understanding, and prevention of traceroute
measurement artifacts
Computer Networks 52-5, 2008.
Load-balancing
Load-balancing (équilibrage de charge)
Hop 6 Hop 7 Hop 8 Hop 9
2 0
0 1 0 1
0 1 0 1
2 1
1 0
S L A C E
B D
L envoie les paquets pour E tantôt vers A, tantôt vers B.
Problème causé par le load-balancing
Traceroute −→ Information manquante ou fausse
Problème causé par le load-balancing
Traceroute −→ Information manquante ou fausse
Hop 6 Hop 7 Hop 8 Hop 9
2 0
0 1 0
1
0 1 0 1
2 1
1 0
S L A C E
B D
Problème causé par le load-balancing
Traceroute −→ Information manquante ou fausse
Hop 6 Hop 7 Hop 8 Hop 9
2 0
0 1 0 1
0 1 0 1
2 1
1 0
S L A C E
B D
L
0Problème causé par le load-balancing
Traceroute −→ Information manquante ou fausse
Hop 6 Hop 7 Hop 8 Hop 9
2 0
0 1 0 1
0 1 0 1
2 1
1 0
S L A C E
B D
A
0L
0Problème causé par le load-balancing
Traceroute −→ Information manquante ou fausse
Hop 6 Hop 7 Hop 8 Hop 9
2 0
0 1 0 1
0 1 0 1
2 1
1 0
S L A C E
B D
0
0
A
D
L
0Problème causé par le load-balancing
Traceroute −→ Information manquante ou fausse
Hop 6 Hop 7 Hop 8 Hop 9
2 0
0 1 0 1
0 1 0 1
2 1
1 0
S
0
0
A D
L
0E
1L A C E
B D
Faux liens
Nœuds non vus
Problèmes – 2
Boucles:
TTL = 6
TTL = 8 TTL = 7 TTL = 9
What we see:
Hop 6 Hop 7 Hop 8 Hop 9
Hop 8 Hop 7
Hop 6 1 0 2
0 1
0 1
0 1
0
1 2
0 0
S L
0A
B C
E
L A EProblèmes – 3
Cycles:
Différence de longeur entre routes = k
→ cycle de longueur k
Load-balancing
Plusieurs types de load-balancing : par paquet
→ aléatoire, round-robin par flot
→ paquets d’une même application sur le même chemin par destination
→ paquets pour une même destination sur le même chemin
traceroute et load-balancing
par paquet → aucun contrôle par flot
par destination
traceroute et load-balancing
par paquet → aucun contrôle par flot
par destination
Flot = IPs + ports source & destination, protocole traceroute varie systématiquement le port destination
→ les paquets suivent systématiquement des chemins différents
traceroute et load-balancing
par paquet → aucun contrôle par flot
par destination
Pas de biais dans les mesures avec traceroute
Paris-traceroute
Variante de traceroute :
les ports source/dest sont gardés constants pendant toute la mesure
(utilisation d’autres champs de l’en-tête pour identifier les paquets)
→ pas de problème avec le load-balancing par flot
Paris-traceroute
Variante de traceroute :
les ports source/dest sont gardés constants pendant toute la mesure
(utilisation d’autres champs de l’en-tête pour identifier les paquets)
→ pas de problème avec le load-balancing par flot
Question
Quel est l’impact en pratique du load-balancing ?
Comparer des mesures avec traceroute et paris-traceroute
Mesures
5000 destinations une passe :
un traceroute vers chaque destination
un paris-traceroute vers chaque destination
1 465 passes (74 jours)
Boucles
avec traceroute : ∼ 7% des IP ont une boucle
→ 90% des boucles disparaissent avec paris-traceroute
Cycles
Cycles : rares avec traceroute (fréquence 0.6%)
→ 80% des cycles disparaissent avec paris-traceroute
load-balancing ou événements rares ?
Diamants
0
0 0
0 0 0
0
A
B E C
L D
G
(L 0 , D 0 ) → taille 3
(L 0 , E 0 ), (A 0 , G 0 ), (B 0 , G 0 ) → taille 2
Le load-balancing crée des diamants
Diamants
traceroute :
28 231 diamants
diamants vers 90% des destinations 21.3 diamant / destination en moyenne paris-traceroute :
52% des diamants disparaissent
diamants vers 89% des des destinations
9.7 diamant / destination en moyenne
Diamants
1e-05 1e-04 0.001 0.01 0.1 1
0 10 20 30 40 50 60 70 80
Frequency
Size of the global diamonds
1e-05 1e-04 0.001 0.01 0.1 1
0 10 20
Frequency
Size of the global diamonds
Diamants
1e-05 1e-04 0.001 0.01 0.1 1
0 10 20 30 40 50 60 70 80
Frequency
Size of the global diamonds
1e-05 1e-04 0.001 0.01 0.1 1
0 10 20
Frequency
Size of the global diamonds
Moins de diamants avec paris-traceroute Diamants moins gros
le load-balancing par flot crée de faux liens
Diamants – questions
Diamants restants : load-balancing par paquet ou vrais liens ? Certains diamants sont vus avec paris-traceroute mais pas
traceroute
événements ?
Outline
1 Paris traceroute et load-balancing Biais associé au load-balancing
2 Dynamique de la topologie de l’internet Contexte et approche
Tracetree Mesures Analyse
3 Détection d’événements dans la dynamique
4 Biais induit par la dynamique
Principaux travaux de référence
Matthieu Latapy, Clémence Magnien et Frédéric Ouédraogo A Radar for the internet
First International Workshop on Analysis of Dynamic Networks, 2008.
Clémence Magnien, Frédéric Ouédraogo, Guillaume Valadon et Matthieu Latapy
Fasts dynamics in Internet topology: observations and first explanations
Fourth International Conference on Internet Monitoring and
Protection, 2009.
Résumé
Cartographie au niveau IP Long et coûteux
Tendances actuelles Données massives
(multiplier sources et destinations, mesures distribuées, . . . ) Améliorer la qualité
Dynamique ?
Notre approche
Ce qu’une machine voit de l’internet est :
• intéressant en soi
• (plus) facile à mesurer
• (plus) facile à interpréter
• peut être mesuré efficacement (temps, charge)
notion de vision égo-centrée Mesure efficace + simple = ⇒ Répétition
étude de la dynamique Radar
une source, des destinations, mesures périodiques
Notre approche
Ce qu’une machine voit de l’internet est :
• intéressant en soi
• (plus) facile à mesurer
• (plus) facile à interpréter
• peut être mesuré efficacement (temps, charge)
notion de vision égo-centrée Mesure efficace + simple = ⇒ Répétition
étude de la dynamique Radar
une source, des destinations, mesures périodiques
Notre approche
Ce qu’une machine voit de l’internet est :
• intéressant en soi
• (plus) facile à mesurer
• (plus) facile à interpréter
• peut être mesuré efficacement (temps, charge)
notion de vision égo-centrée Mesure efficace + simple = ⇒ Répétition
étude de la dynamique Radar
une source, des destinations, mesures périodiques
Vue égo-centrée
Vue égo-centrée
Mesure avec traceroute
Mesure avec traceroute
Mesure avec traceroute
Mesure avec traceroute
Mesure avec traceroute
Mesure avec traceroute
Mesure avec traceroute
*
Charge déséquilibrée
*
Charge déséquilibrée
many probes on links closest
0 500 1000 1500 2000 2500 3000
0 5 10 15 20 25 30
x = distance du moniteur, y = # sondes
Limites de traceroute
charge déséquilibrée
⇒ information redondante pas un arbre
⇒ complique l’analyse
֒ → nécessité d’un outil dédié
tracetree
Limites de traceroute
charge déséquilibrée
⇒ information redondante pas un arbre
⇒ complique l’analyse
֒ → nécessité d’un outil dédié
tracetree
Tracetree
Mesures en arrière, en parallèle, arrêt lorsque les chemins se
rencontrent
Tracetree
Mesures en arrière, en parallèle, arrêt lorsque les chemins se
rencontrent
Tracetree
*
Mesures en arrière, en parallèle, arrêt lorsque les chemins se
rencontrent
Tracetree
*
Mesures en arrière, en parallèle, arrêt lorsque les chemins se
rencontrent
Tracetree
*
Mesures en arrière, en parallèle, arrêt lorsque les chemins se
rencontrent
Tracetree
*
Limite du rayon (TTL max):
Sonder jusqu’à une distance donnée du moniteur
Tracetree et radar
Tracetree
1 paquet par lien
mesure homogène et rapide arbre
−→ programme disponible, écrit en C .
Radar
Une source
Un ensemble de destinations Mesures périodiques avec tracetree
Tracetree : mêmes problèmes que traceroute pour la qualité de la
mesure
Tracetree et radar
Tracetree
1 paquet par lien
mesure homogène et rapide arbre
−→ programme disponible, écrit en C .
Radar
Une source
Un ensemble de destinations Mesures périodiques avec tracetree
Tracetree : mêmes problèmes que traceroute pour la qualité de la
mesure
Tracetree et radar
Tracetree
1 paquet par lien
mesure homogène et rapide arbre
−→ programme disponible, écrit en C .
Radar
Une source
Un ensemble de destinations Mesures périodiques avec tracetree
Tracetree : mêmes problèmes que traceroute pour la qualité de la
mesure
tracetree vs traceroute: comparaison empirique
traceroute tracetree
13400 13500 13600 13700 13800 13900 14000 14100 14200 14300
20 30 40 50 60 70 80 90 100 110
x=nb de passes, y=nb d’adresses IP
tracetree vs traceroute: comparaison empirique
tracetree traceroute
13400 13500 13600 13700 13800 13900 14000 14100 14200 14300
1e+06 2e+06 3e+06 4e+06 5e+06 6e+06 7e+06
x =nb de paquets, y=nb d’adresses IP
tracetree vs traceroute: comparaison empirique
tracetree traceroute
A B
13400 13500 13600 13700 13800 13900 14000 14100 14200 14300
1e+06 2e+06 3e+06 4e+06 5e+06 6e+06 7e+06
x =nb de paquets, y=nb d’adresses IP
Paramètres
Plusieurs paramètres des mesures Quelles sources / destinations?
Combien de destinations?
Délai entre passes?
Timeout?
. . . Compromis Haute fréquence Grande quantité de données
Faible charge sur le réseau
Paramètres: la fréquence
— Moniteur de test
— Moniteur de contrôle
speed−up measurement
10400 10600 10800 11000 11200 11400 11600 11800 12000
0 10 20 30 40 50 60 70 80
x=# heures, y =# IP
Paramètres: nombre de destinations
— Moniteur de test
— Moniteur de contrôle
3000 d.
1000 d.
10000 d.
3000 d.
0 5000 10000 15000 20000 25000 30000
0 10 20 30 40 50 60 70 80 90
x=# heures, y =# IP
Paramètres: nombre de destinations
— Moniteur de test
— Moniteur de contrôle
3000 d.
1000 d.
10000 d.
1000 d. (sim)
3000 d.
3000 d. (sim)
0 5000 10000 15000 20000 25000 30000
0 10 20 30 40 50 60 70 80 90
x=# heures, y =# IP
Nos mesures
Deux ensembles de paramètres:
normal: 3000 destinations, 10 min. délai entre passes,
TTL max 30, ... ∼ 100 passes / jour
rapide: 1000 destinations, 1 min. délai entre passes,
TTL max 15, ... > 800 passes / jour
Sources: PlanetLab et autres (> 100) Destinations: Aléatoires, répondant au ping
Plusieurs mois de mesure ininterrompue
Données disponibles pour étude
Nos mesures
Deux ensembles de paramètres:
normal: 3000 destinations, 10 min. délai entre passes,
TTL max 30, ... ∼ 100 passes / jour
rapide: 1000 destinations, 1 min. délai entre passes,
TTL max 15, ... > 800 passes / jour
Sources: PlanetLab et autres (> 100) Destinations: Aléatoires, répondant au ping
Plusieurs mois de mesure ininterrompue
Données disponibles pour étude
Analyse de la dynamique
Caractéristiques attendues : dynamique normale
load-balancing
changements dans les routes . . .
événements spécifiques pannes
. . .
Analyse
Quelle dynamique ? Pour :
mieux comprendre modéliser, simuler détecter des événements ...
Comment répondre cette question ?
Pas de méthode toute faite
Analyse
Quelle dynamique ? Pour :
mieux comprendre modéliser, simuler détecter des événements ...
Comment répondre cette question ?
Pas de méthode toute faite
Étude d’une passe
Variations en fonction : de la source du moment
Quelques tendances générales
∼ 12 000 IP
∼ 12 000 étoiles
la plupart des nœuds à distance 13-18
On observe toujours le même type de comportements
Étude d’une passe
Variations en fonction : de la source du moment
Quelques tendances générales
∼ 12 000 IP
∼ 12 000 étoiles
la plupart des nœuds à distance 13-18
On observe toujours le même type de comportements
Visualisation
Fichier externe out3.gif
Propriétés simples au fil du temps
Première approche :
Évolution de propriétés simples au fil du temps nombre d’IP
nombre d’étoiles
durée des passes
. . .
Propriétés simples au fil du temps
0 2000 4000 6000 8000 10000 12000 14000
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
Nb IP
Date
Nombre d’IP par passe source au Japon
deux mois de mesures
∼ 6 000 passes
Propriétés simples au fil du temps
0 2000 4000 6000 8000 10000 12000 14000
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
Nb IP
Date
Nombre d’IP par passe
Plus ou moins constant (changement de régime) Pics vers le bas → déconnections ?
Pas de pics vers le haut
Présence des IP
Distribution du nombre de présences Toutes les IP vues pendant la mesure ( ∼ 29 000) Pour chaque IP : nombre de passes où on l’a vue
−→ Distribution
Présence des IP
2 mois ∼ 6000 passes
0 500 1000 1500 2000 2500 3000 3500
0 1000 2000 3000 4000 5000 6000
Nb IP
Nb times seen
Présence des IP
2 mois ∼ 6000 passes
0 500 1000 1500 2000 2500 3000 3500
0 1000 2000 3000 4000 5000 6000
Nb IP
Nb times seen
Beaucoup d’IP éphémères
(vues très peu de fois) Un nombre non négligeable d’IP stables
(vues presque à chaque fois)
Présences vs apparitions
0 200 400 600 800 1000 1200 1400
0 1000 2000 3000 4000 5000
Apparitions
Observations
1 2 3 4 5 6 7 8
• • • • •
5 présences, 2 apparitions
Présences vs apparitions
-200 0 200 400 600 800 1000 1200 1400
0 1000 2000 3000 4000 5000
Apparitions
Observations
Parabole : load-balancing
p = 1/2 −→ x = n/2, y = 1/2 ∗ 1/2 ∗ n = n/4
Présences vs apparitions
-200 0 200 400 600 800 1000 1200 1400
0 1000 2000 3000 4000 5000
Apparitions
Observations
p quelconque : x = np, y = p(1 − p )n
−→ y = n ∗ x/n ∗ ((n − x)/n)
Présences vs apparitions
-200 0 200 400 600 800 1000 1200 1400
0 1000 2000 3000 4000 5000
Apparitions
Observations
Deux classes différentes
parabole : load-balancing
proche de l’axe des x : addresses stables
Dynamique : stabilisation?
Comportement attendu
x = # de passes
y = # d’adresses IP distinctes depuis le début
Dynamique : stabilisation ?
Nombre d’IP distinctes observées depuis le début
10000 12000 14000 16000 18000 20000 22000 24000 26000 28000 30000
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
Nb distinct IP
Date
nouvelles IP observées en permanence
Disparitions
Nombre d’IP distinctes qu’on ne verra plus jamais
0 2000 4000 6000 8000 10000 12000 14000 16000 18000 20000
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
Nb distinct IP
Date
Renouvellement continu des IP observées
Tentatives d’explication
Croissance surprenante Deux explications “naturelles”
ip aléatoires
ip dynamiques
IP vues une seule fois ?
10000 12000 14000 16000 18000 20000 22000 24000 26000 28000
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
Nb distinct IP
Date
>= 2
IP vues une seule fois ?
10000 12000 14000 16000 18000 20000 22000 24000 26000 28000
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
Nb distinct IP
Date
>= 2
>= 10
IP vues une seule fois ?
10000 12000 14000 16000 18000 20000 22000 24000 26000 28000
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
Nb distinct IP
Date
>= 2
>= 10
>= 50
IP vues une seule fois ?
10000 12000 14000 16000 18000 20000 22000 24000 26000 28000
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
Nb distinct IP
Date
>= 2
>= 10
>= 50
>= 200
IP vues une seule fois ?
10000 12000 14000 16000 18000 20000 22000 24000 26000 28000
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
Nb distinct IP
Date
>= 2
>= 10
>= 50
>= 200
>= 1000
De nouvelles IP récurrentes...
Élimine l’hypothèse des IPs aléatoires
Des IP dynamiques ?
Destinations “stables”... (un critère possible: le père dans l’arbre a toujours la même adresse)
200 400 600 800 1000 1200 1400 1600 1800
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
Nb distinct IP
Date
courbes de mesures sur ces adresses ont même allure.
Élimine l’hypothèse des IPs dynamiques
Des IP dynamiques ?
Destinations “stables”... (un critère possible: le père dans l’arbre a toujours la même adresse)
200 400 600 800 1000 1200 1400 1600 1800
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
Nb distinct IP
Date
courbes de mesures sur ces adresses ont même allure.
Élimine l’hypothèse des IPs dynamiques
Autonomous Systems
Autonomous System (AS) : institution indépendante Chaque IP est dans un AS
−→ Nombre d’AS vus depuis le début de la mesure
Autonomous Systems
900 920 940 960 980 1000 1020 1040
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
As
Date
Routeviews
Projet Routeviews Nombreux moniteurs
Historique des tables de routage
Routeviews
Simulation du radar au niveau AS Moniteur proche de la source
Table de routage
4.23.112.0/24 4777 2516 215 17132 7500 2497 215 17132 4.23.113.0/24 4777 2516 324 21889 7500 2497 324 21889 2497 174 21889 4.23.114.0/24 4812 3015 174 5313
7500 2497 174 5313
Routeviews
Simulation du radar au niveau AS Moniteur proche de la source Destination → préfixe Table de routage
4.23.112.0/24 4777 2516 215 17132 7500 2497 215 17132 4.23.113.0/24 4777 2516 324 21889 7500 2497 324 21889 2497 174 21889 4.23.114.0/24 4812 3015 174 5313
7500 2497 174 5313
Routeviews
Simulation du radar au niveau AS Moniteur proche de la source Destination → préfixe
→ ensemble de chemins d’AS Table de routage
4.23.112.0/24 4777 2516 215 17132 7500 2497 215 17132 4.23.113.0/24 4777 2516 324 21889 7500 2497 324 21889 2497 174 21889 4.23.114.0/24 4812 3015 174 5313
7500 2497 174 5313
Routeviews
800 850 900 950 1000 1050 1100 1150 1200
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
As
Date
Routeviews
800 850 900 950 1000 1050 1100 1150 1200
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
As
Date
Nouveaux AS ?
AS observés après le début de la mesure (72)
→ Nouveaux ? Historique des tables de routage
70 AS dans la première table de routage
Observations dûes à la dynamique BGP
Tous les as sont-ils équivalents ?
Distribution de la taille observée
1 10 100 1000
1 10 100 1000 10000
Nb distinct IP
Date
Nouveautés à l’intérieur des as ?
Plus gros AS : 1333 IP
300 400 500 600 700 800 900 1000 1100 1200 1300 1400
26/05 02/06 09/06 16/06 23/06 30/06 07/07 14/07 21/07 28/07 04/08
Nb distinct IP
Date
Conclusion sur les apparitions d’IP
Renouvellement continu des IP observées pour les IP volatiles
pour les IP stables Nouvelles IP observées
à l’intérieur des AS déjà vus dans des AS nouvellement observés
Observation de nouveaux AS ← dynamique BGP Remarque:
lien avec les nouveaux diamants observés avec paris-traceroute:
découverte d’IPs entre la passe de traceroute et celle de
paris-traceroute.
Causes importantes des apparitions d’IP
1000 2000 3000 4000 5000 6000 7000
0 500 1000 1500 2000 2500 3000
Nombre de liens
Nombre de passes pente load-balancing
évolution du routage
+ load-balancing + évolution du routage
Outline
1 Paris traceroute et load-balancing Biais associé au load-balancing
2 Dynamique de la topologie de l’internet Contexte et approche
Tracetree Mesures Analyse
3 Détection d’événements dans la dynamique
4 Biais induit par la dynamique
Approches
Plusieurs approches pour détecter les événements Par signature
Si on sait à quoi ressemble un événement (signature)
→ détection de la signature dans les données Top-down
Pas d’a priori sur la dynamique
−→ on cherche à détecter les événements différents de la
dynamique normale
Méthodologie
[Detecting Events in the Dynamics of Ego-centered Measurements of the Internet Topology
Hamzaoui, Latapy, Magnien, 2010]
Distribution d’une statistique, trois cas possibles : homogène
hétérogène
homogène avec outliers
Nombre de nœuds par passe
0 2000 4000 6000 8000 10000 12000
1500 2000 2500 3000 3500 4000 4500 5000 5500 6000
Statistique au fil du temps
Nombre de nœuds par passe
0 5 10 15 20 25 30 35
0 2000 4000 6000 8000 10000 12000
Distribution
Nombre de nœuds par passe
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000
0 2000 4000 6000 8000 10000 12000
Distribution cumulative inverse
Nombre de nœuds par passe
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000
0 2000 4000 6000 8000 10000 12000
Distribution cumulative inverse Conclusion
Pics vers le bas significatifs
Événements non intéressants (pertes de connexion locales)
Nombre de nœuds dans plusieurs passes consécutives
Statistique : nombre d’IP distinctes dans l’union de 5 passes
7000 8000 9000 10000 11000 12000 13000 14000
1500 2000 2500 3000 3500 4000 4500 5000 5500 6000
Statistique au fil du temps
Nombre de nœuds dans plusieurs passes consécutives
Statistique : nombre d’IP distinctes dans l’union de 5 passes
0 5 10 15 20 25 30 35
7000 8000 9000 10000 11000 12000 13000 14000
Distribution
Nombre de nœuds dans plusieurs passes consécutives
Statistique : nombre d’IP distinctes dans l’union de 5 passes
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000
10500 11000 11500 12000 12500 13000 13500 14000
Distribution cumulative inverse
Nombre de nœuds dans plusieurs passes consécutives
Statistique : nombre d’IP distinctes dans l’union de 5 passes
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000
10500 11000 11500 12000 12500 13000 13500 14000
Conclusion
Pics significatifs
Pics vers le haut → changements
Pics vers le bas significatifs ? (perte de connexion locale
longue ?)
Interprétation des événements
Événement statistiquement significatif détecté
→ Interprétation ?
But : compréhension, pertinence de l’événement Deux approches
Corrélations avec des événements connus
Dessin
Tickets d’incidents Abilene
Dans certains cas, correspondance entre un incident détecté et un ticket d’incident
0 200 400 600 800 1000
0 1000 2000 3000 4000 5000 6000 7000
AFFECTED: Peer SINET (CHIC) STATUS: Unavailable
START TIME: Thursday, May 17, 2007, 11:47 AM (1147) UTC END TIME: Pending
DESCRIPTION: Peer SINET’s connection the Internet2 IP Community is unavailable. SINET Engineers have been contacted, however, no cause of outage has been provided yet. SINET is multi-homed.
TICKET NO.: 10201:45
TIMESTAMP: 07-05-18 00:40:43 UTC
Tickets d’incidents Abilene
Dans certains cas, correspondance entre un incident détecté et un ticket d’incident
0 200 400 600 800 1000
0 1000 2000 3000 4000 5000 6000 7000
STATUS: Available
START TIME: Thursday, May 17, 2007, 11:47 AM (1147) UTC END TIME: Friday, May 18, 2007, 3:51 AM (0351) UTC DESCRIPTION: Peer SINET was unavailable to the the Internet2 IP
Network Community. SINET Engineers reported the reason for outage was due to a fiber cut in New York.
SINET is multi-homed.
TICKET NO.: 10201:45
TIMESTAMP: 07-05-18 07:39:16 UTC
Dessin
Pour aller plus loin
Comparer les événements détectés avec d’autres statistiques Caractérisation automatique du type de distribution
fit
Détection automatique et rigoureuse des outliers
Outline
1 Paris traceroute et load-balancing Biais associé au load-balancing
2 Dynamique de la topologie de l’internet Contexte et approche
Tracetree Mesures Analyse
3 Détection d’événements dans la dynamique
4 Biais induit par la dynamique
Présence des IP
Distribution du nombre de présences Toutes les IP vues pendant la mesure ( ∼ 29 000) Pour chaque IP : nombre de passes où on l’a vue
−→ Distribution
Présence des IP
2 mois ∼ 6000 passes
0 500 1000 1500 2000 2500 3000 3500
0 1000 2000 3000 4000 5000 6000
Nb IP
Nb times seen
Présence des IP
1 mois ∼ 3000 passes
0 500 1000 1500 2000 2500
0 1000 2000 3000 4000 5000 6000
Nb IP
Nb times seen
Présence des IP
2 mois ∼ 6000 passes — Distrib. cumulative
0 5000 10000 15000 20000 25000 30000
0 1000 2000 3000 4000 5000 6000
Nb IP
Nb times seen
Présence des IP
1 mois ∼ 3000 passes — Distrib. cumulative
0 5000 10000 15000 20000 25000
0 1000 2000 3000 4000 5000 6000
Nb IP
Nb times seen
Observations dépendantes de la durée de la mesure ?
Mesure plus longue : Moins d’IP stables Plus d’IP éphémères
Conclusion ? Méthodologie
Augmenter la taille de la fenêtre de mesure
Évolution de la distribution
Distributions normalisées
Problème :
Valeur max en x : nombre de passes
Valeur max en y : nombre total d’IP vues en N passes Les courbes ne sont pas directement comparables
Normalisation
y : fraction des IP observées
x : fraction des passes
Résultats
10 000 passes → ∼ 100 jours
Résultats
10 000 passes → ∼ 100 jours
Mesure plus longue : Moins d’IP stables Plus d’IP éphémères
Pas de convergence
Étudier la convergence
Nombre d’IP vues au moins x% des passes, en fonction de la durée de mesure
0 2000 4000 6000 8000 10000 12000 14000 16000 18000 20000
0 2000 4000 6000 8000 10000 12000
0.10 0.30 0.50 0.90 0.99 0.995 0.999
∼ 2 000 IP présentes à 99.5% des passes
→ noyau stable ?
Lien avec la détection d’événements
Pour certains moniteurs / certaines périodes
0 500 1000 1500 2000 2500 3000 3500 4000
0 50 100 150 200 250 300 350 400 450 500
"parse_hash_1_501.dat"
