métrologie et caractérisation de trafic
DESCRIPTION
Connaitre les métrologie ippm , ses différents types et détails.TRANSCRIPT
Métrologie et Caractérisation de trafic
• Métrologie • Caractérisation de trafic
Leila Azouz Saidane
Partie I
Métrologie ou
Science des mesures
2
Nétographie•Groupe de travail Métrologie
http://www.inria.fr http://gt-metro.grenet.fr•Didier Benza•Luc Saccavini•Philippe Owerzaski•Chadi Baraket•Khadija Ramah•…
Métrologie
• Définition :La métrologie est la science de la mesure au
sens le plus large. La mesure est l'opération qui consiste à donner
une valeur à une observation.
3
Métrologie dans l’Internet
Introduction•L'Internet a été créé comme un réseau simple, ouvert, flexible, où le seul service offert aux utilisateurs est le "routage au mieux" des paquets (en anglais Best Effort). •Interconnexion des réseaux.
4
Why to measure the Internet ?
“When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and Unsatisfactory kind”
--KELVIN5
Motivation• The Internet is a HUGE network of networks:
•Scientists are curios to study/explore/model systems like this.•Emergent characteristics...
• To improve the Internet, we need to understand its structure and behavior:•We cannot understand it if we don’t measure it.•We cannot build effective models or simulators if we don’t measure
• Wide area network behavior is unpredictable• Many applications have minimum performance requirements:
Reliability, predictability, …• Network managers adjust systems to conditions.
6
Motivation•L'Internet a été créé sans infrastructure de mesure standard qui permet aux opérateurs et aux utilisateurs d'observer ce qui se passe et d'échanger les résultats entre eux.• le cœur de l'Internet fournit un service simple consistant en un routage au mieux des paquets
Métrologie dans l’Internet
7
Métrologie réseau ?
Objectif : savoir ce qui se passe sur le réseau– En situation normale (tableaux de bord, historique…)– En cas d’incident– Sur mon site, chez mes prestataires, sur l’InternetComment ?–– Mesurer les paramètres clés du réseau
• Liens, • équipements
8
Evolution
• Très forte augmentation des débits– Ethernet filaire : 100Mb/s (1995)
à 100Gb/s (2010)– Ethernet sans fil : 11Mb/s (1999)
à 100Mb/s (2010)– xDSL/câble : 1Mb/s (2000) à 50Mb/s (2009)• Arrivée d’IPv6 • Nouvelles applications: (ex: tel/IP, …)• Contractualisation plus précise (SLA, QoS:
débit, délai, taux de perte..) 9
Conséquences sur les technologies réseaux– Apparition de nouveaux protocoles
• Ex: SCTP( Stream Control Transmission Protocol)• Ex: DCCP (Datagram Congestion Control Protocol)
– Apparition de nouvelles versions de TCP (contrôle de flux)– Echelle de variations de débit plus grande et plus rapide– Mise en service de la QoS
Conséquence sur la métrologie réseau– La métrologie doit être à tous les niveaux• En espace : LAN, WAN, … • En technologies (Ethernet, IP, TCP, HTTP…)– Evolution des métriques : nouvelles et plus précises, mieux définies
Evolution
10
Enjeux
QoS
Architecture d’Internet
Dimensionnement des structures(routeurs, serveurs …)
Modèles d’administration
Sécurité
Evaluation de performances
Tarification
QoS
Définition : garantir de bonnes conditions de
transmission pour un trafic donné en terme de : Débit Fiabilité (taux de perte des paquets) Délais de transmission Gigue
Trafic ciblé : streaming, VoIP, temps réel
Métrologie Internet
Trois Problématiques :• Etre insensible au facteur d’échelle• Fournir une solution de bout en bout indépendamment des
différents domaines traversés• S’adapter à la dynamicité des ressources du réseau et à la
variabilité du trafic
La métrologie devra mesurer en continu la QoS offerte
Le but de la métrologie est d’adapter les mécanismesde transmission aux conditions de trafic et du réseau
Mesures pour l’utilisateur
Surveiller les performances vécues par une application:– Pourquoi le téléchargement de la page Web est si lent? – Pourquoi l'interactivité dans ma conversation audio est
mauvaise?– Vérifier si le niveau du service reçu répond à son besoin
• Ai-je assez de bande passante?• Ai-je obtenu le service promis par l'opérateur?
– …
• Surveiller le niveau courant d’une activité.• Respecter les SLAs(Service Level Agreements). • Detecter les pannes et les échecs• Ingénierie du réseau pour de meilleures
performances.• Planifier pour des capacités futures .• Feedback aux clients.
15
Mesures pour les opérateurs
Caractérisation du trafic internet Classification du trafic internet Définir :
• Un niveau de service associé à chaque classe (QoS)
• Une échelle de temps à étudier (paquets, flots, sessions)
Modélisation du trafic
•Événements caractéristiques (pics, fluctuations)
•Abstraction par un processus aléatoire si possible
Définition des décisions
• Traitements à appliquer en fonction de l'événement détecté
Mesures pour les opérateurs
Difficulties in measuring the Internet
• Size of the Internet• Complexity of the Internet: Components, protocols, applications, users• Constant change • New applications• The Internet was not developed with
measurement as a fundamental feature
17
Tradeoffs• Overhead vs. Accuracy:– The more measurements the more data collected, – The more (less) samples the more (less) precise
the measurement.– The more aggregated, the coarser the data.
• Overhead at routers, switches, end-hosts, etc.
• Security vs. Sharing: – Limited access to network internal data.– Privacy of customers should be respected.
18
What can we measure?• Structure:– Topology, e.g. number of links and routers,
connectivity, domains, transport technologies, firewalls, ….
– Routing, e.g. number of hops, routes, size of routing tables, multicast trees.
– Characteristics of links, e.g. bandwidth, delay, loss rate, utilization, etc.
• Traffic:– Packet level, flow level, per transport protocol, etc.– End-to-end performance of data traffic : Delay,
throughput, loss rate, etc.19
What can we measure?
• Users and Applications:
Application mixes: WWW, FTP, Email, Telnet, audio, video, etc.
• Application usage: volume and duration.
• Users’ behavior.
• Does the operator respect the Service Level Agreement?
• Failures:
• In all areas, e.g., why this web server is not working?
• Nefarious behavior:
• attacks, anomalies, etc.
• Mesures actives et mesures passives
Métrologie active Principe:• Génération de trafic pour effectuer des mesures (taux
de pertes, délai, RTT) Exemples: – ping: Connectivity, round-trip delay, loss.– Traceroute: Connectivity, path, hop-delay.–….
Avantage :• Le seul moyen actuel d’avoir des mesures orienté
utilisateurInconvénient :• ajout d’un trafic supplémentaire dans le réseaux 21
Active measurement
• Active tools send stimulus (packets) into the networkand then measure the response.
• Active tools can measure many things:• Delay / loss.
• Topology / routing behavior.• Bandwidth/ throughput.
• Oldest examples of active tools use Internet Control Message
Protocol (ICMP): Network layer probe.• Problems:
•Important characteristics can be missed.
•If sent in large amounts, these tools can change the status of the network.
Métrologie passivePrincipe :• Ecoute du trafic en divers points du réseau• Traitement d’analyse sur les traces obtenuesDeux types d’analyse :• En-ligne• Hors-ligneAvantage :• pas d’intrusion sur le réseauInconvénient :• Complexité d’analyse
23
Métrologie : quelques outils
® Mesures passives •Simple Network Management Protocol (abrégé SNMP), en français « protocole simple de gestion de réseau »: Collects aggregate traffic stats from routers•MRTG - The Multi Router Traffic Grapher, A tool to monitor the traffic load on network-links, Raw data collected via SNMP.•NetFlow is a network protocol developed by Cisco Systems for collecting IP traffic information. Collects aggregate flow stats from Cisco routers•NetFlow has become an industry standard for traffic monitoring •….
24
A flow as seen by a router
Defined by Seven Unique Keys:
Source IP address
Destination IP address
Source port
Destination port
Layer 3 protocol type
TOS byte (DSCP)
Input logical interface (ifIndex)
Store information in a cache then
export it.
Source: cisco
® Mesures passives (NetFlow)– IPFIX: IP Flow Information eXport est la standardisation IETF de Netflow avec pour base la version 9– Renetcol (Renater NetFlow Collector) => http://renetcol.renater.fr
Métrologie : quelques outils
Example of passive tools
Packet monitors:
• Tcpdump for Unix-based user hosts.
• Dedicated measurement systems: OC3MON, IPMON, etc.
Router/switch traffic statistics:
• SNMP: Collects aggregate traffic stats from routers.
• Netflow: Collect aggregate flow stats from Cisco routers.
Server logs:
• Summary of sessions.
• Activities of a WEB server and IDs of clients.
What to do with tcpdump data?TCPTRACE
A well known powerful tool that uses the measurements collected by tcpdump toanalyze tcp connections (http://www.tcptrace.org).
• Tcptrace analyzes the traces collected
• It also generates different types of graphs illustrating various parameters of a TCP
connection..
• Four main options exist:
“nothing”: we get a brief summary of the TCP connections in the file.
“-l”: long list of parameters.
“-r”: statistics on the round-trip time.
“-W”: statistics on the window size.
Rappels:
IP----
ICMP-----TCP
30
Format des Datagrammes IPv4
En-tête : partie fixe (20 Octets) + partie optionnelle variable
Données : charge utile du datagramme
Version Lg_ent Type de service Longueur totale
IdentificationDrapea
uxDep_fragment
Durée de vie Protocole Total de contrôle d’en-tête (checksum)
Adresse source
Adresse destination
Options (éventuelles)
Données
………
32 bits
Bourrage
4 8 16 24
31
Format des Datagrammes IPChamps Description Lon
g
Version Version du protocole: IPv4/IPv6 (permet de vérifier que la source, la destination et tous les routeurs traversés sont en accord sur le format du datagramme)
4 bits
Lg_ent Longueur de l’entête en multiple de 32 bits: de 5(20 Oct) si pas d’option à 15 (60ot
4 bits
Long. Totale
Longueur totale du datagramme en octets : entête+données (jusqu’à 216 octets)
16 bits
Indentification
Numéro de datagramme affecté par la source. Indique à quel datagramme appartient un fragment
16 bits
Drapeaux DF : “ Don’t fragment ”, MF : “ More fragments ” et 1bit inutilisé
3 bits
Dép_fragment
Localisation (offset) : déplacement du fragment dans le datagramme (multp de 8oct)
13 bits
Durée de vie (TTL)
Compteur utilisé pour limiter la durée de vie des datagrammes : décrémenté à chaque routeur (traitement+file d’attente), paquet détruit quand passe à 0
8 bits
Protocole Indique par un numéro à quel protocole confier le contenu du datagramme (TCP ou UDP ou ICMP…). Numéros standards définis dans RFC 1060
8 bits
Checksum Vérifie la validité de l’en-tête, doit être recalculé à chaque saut
16 bits
Bourrage (Padding)
Bits à 0 rajoutés (si nécessaire) pour avoir une longueur d’entête multiple de 32 bits car la longueur du champ « options » est variable
0 à 4 octets
32
Format des Datagrammes IPv4
– Version : 4 bits (si différent, paquet rejeté, pas de message d’erreurs pour la source)
– IHL : 4 bits (Internet Header Length) longueur d’entête en 32 bits; au max 4x15 octets (limite sur la longueur des options).
au min 20 octets (le plus utilisé, sans options)– Padding : 0-4 octets; remplissage d’entête avec des 0’s – Total length : 2 octets; longueur totale de ce
datagramme en octets (entête+données); max=65635 octets.
– Protocol : 1 octet; protocole à la destination (numéros standard: RFC 1060); TCP, UDP, ICMP,…
– Time to live: 1 octet; décrémenté par chaque routeur. S’il atteint 0 le paquet est rejeté. Le routeur décrémente par au moins 1(plus si attente dans les files d’attente); utilisé comme « hop count »; permet d’éviter les boucles
Refresh: IP
TTL decremented by 1 by each router.
Packet discarded by router when TTL reaches 0:
• An ICMP error message is sent back to the source, with router IP @
34
Format des Datagrammes IPv4
Identification : 2 octets; affectation par source: Num. de séquence des datagrammes (deux fragments du même datagramme si Identification, @source, @destination, Protocole coïncident); problème de longueur
DF: Don’t Fragment; 1 bit; 0 pour fragmentation permiseMF: 1 bit; si 0 le dernier fragment d’un datagrammeOffset: 13 bits; offset du fragment actuel (déplacement
dans le contexte du datagramme original); en multiple de 8 octets; pas de longueur totale du datagramme original.
Type of service : 1 octet; indication de qualité de service QoS:
Priorité (3bits)= Précédence (suppose des files d’attente différentes; DiffServ) + les bits Delay, Throughput, Reliability, 0,0 (non utilisés).
Header checksum: 2 octets; complément à 1 de la somme en complément à 1 de l’entête (recalcul et vérification à chaque routeur).
35
Format des Datagrammes IPv4
Type de service : précise le mode de gestion du datagramme (8 bits) Informations pour les algorithmes de routage pouvant servir
pour le choix de routes satisfaisant certains critères de QoS quand cela est possible.
Priorité : 0 (normal) 7 (supervision réseau) (3 bits) Champs souvent ignoré, nécessite la prise en charge
d’algorithmes de priorité au niveau des routeurs, suppose des files d’attente différentes (DiffServ)
3 drapeaux indiquant le type de service requisDélai (D) : indique un besoin en courts délais,Débit(T) : débit de transmission élevé, Fiabilité (R)
2 bits inutilisésPriorité D T R Inutilisé
0 1 2 3 4 5 6 7
36
Format des Datagrammes IPv4
Options indiquées suivant le format TLV (Tag, Length, Value): Champs optionnels, longueur variable Chaque type d’option est codé sur un octet : Code option Il est suivi d’un octet précisant la longueur + ensemble d’octets de
données associées à l’option Code option :
Copie : si 1 : l’option doit être recopiée dans tous les fragments du datagramme
Classe d’option : • 0 : datagramme de contrôle ou de supervision• 2 : mise au point et mesure• 1 et 3 réservés pour une utilisation future
Numéro d’option: identificateur de l’option
Copie Classe d’option
Numéro d’option
0 1 2 3 4 5 6 7
37
Format des Datagrammes IPv4
Numéro d’option : identificateur de l’option. Exemples : 3 (classe option 0) : Option routage défini par la
source : spécifie la route à prendre par le datagramme. Le champs code sera alors suivi par un champs d’option de lg variable comportant la description de la route
7 (classe option 0) : Option Enregistrement de route : utilisé pour enregistrer un itinéraire, chaque routeur fournissant son adresse IP au datagramme. Le champs code sera alors suivi par un champs d’option de lg variable comportant la description de la route
4 (classe option 2) :• Option Horodatage dans Internet. Pour enregistrer
l’horodatage le long d’une route.• Option Horodatage dans Internet avec
Enregistrement de route
38
Format des Datagrammes IPv4
Option enregistrement de route La source initialise la longueur qu’elle suppose nécessaire. Au niveau d’un routeur intermédiaire, si « pointeur » est
inférieur à « longueur », le routeur ajoute son adresse IP dans le déplacement indiqué par « pointeur » et incrémente pointeur de 4 octets, sinon il achemine le datagramme sans y insérer son adresse.
0 8 16 24 31
Code option(7)
Longueur Pointeur
Première adresse IP
Seconde adresse IP
…Liste de routeurs associée à l’option
enregistrement de route
Utilisé si option
horodatage avec
enregistrement de
route (Code option =4)
39
ICMP : Internet Control Message Protocol
Échange de messages d’erreur et de supervision Rendre compte des problèmes "routeurs"
Datagramme ne peut pas atteindre sa destination Manque de réserve de mémoire Datagramme détruit Utilisation d'une route alternative pour optimiser le trafic.
Un message ICMP est encapsulé dans un datagramme IP.
Un datagramme contenant 1 message ICMP est traité exactement comme les autres sauf dans le cas où un datagramme contenant un message d’erreur causerait lui-même une erreur : aucun message ICMP ne doit être engendré à propos de datagrammes contenant déjà des messages ICMP.
Une douzaine de messages différents
40
ICMP Exemple
Ping : Tu es là ? ICMP EchoRequest
Réponse au ping : Oui, je suis là
ICMP EchoREPLY
192.168.1.24 192.168.1.32
41
Format d’un datagrame ICMP
Chaque message ICMP a un format propre. Ils commencent tous par 3 champs (entête) :
type (8 bits) code (8 bits) info. supplémentaire sur le type total de contrôle (16 bits)
+ 32 bits utilisés ou non utilisés selon le type du message
+ l’entête et les 64 premiers bits du datagramme ayant provoqué l’erreur (englobant les info importantes des protocoles de plus haut niveau)
42
ICMP (quelques messages)
Type Signification0 réponse à une demande d’écho3 destination inaccessible4 limitation de production de la
source (Si débit de la source élevé)8 demande d’écho11 expiration du TTL…
43
ICMP (quelques messages)
Déterminer si une destination est sur le réseau (ping) Echo : type= 8requête; type=0 réponse ; Code = 0 Identifier/Sequence number (4 octets) : associer la requête et sa réponse Data : variable; copiée dans la réponse
Echange de date (Timestamp) type = 13 requête; 14 réponse Code = 0 Identifier/Sequence number (4 octets) : associer la requête et sa réponse Originate timestamp (4 octets): temps avant l’émission de de la requête Receive timestamp (4 octets): : temps à la réception de la requête Transmit timestamp (4 octets): : temps à la transmission de la réponse
Demande d’une adresse réseau type = 15 requête; 0 réponse « Obsolete » car remplacé par BOOTP ou DHCP (Dynamic Host
Configuration Protocol)
44
ICMP (quelques messages)
Demande du masque de sous-réseau (RFC 950) type 17 requête; 18 réponse ; Code = 0Identifier/Sequence number (4 octets) : identifier la
requête et sa réponseAdress mask : 4 octets
Le réseau est en congestion ; la source doit diminuer son utilisation réseau type = 4; Code = 0Entête IP + 64 bits du datagrame cause du problème
Redirect : routage
45
ICMP (quelques messages)
Message d’erreurs type (1 octet) + code (1 octet)+ champ spécifique au type (4
octets)+ (entête + 64 premiers bits du datagrame cause du problème) Problème de paramétrage
type = 12, code = 0Pointer : 1 octet; pointeur au problème dans l’entête
TTL expirétype = 11Code = 0 : died in transit ; Code = 1 : died during
reassembly Destination non joignable
type = 3Code = 0 : net unreachable ; Code = 1 : host
unreachable ; Code = 2 : protocol unreachable ; Code = 3 : port unreachable
Refresh: ICMP
47
Le protocole UDP
« User Datagram Protocol » « Connectionless » ; service « end-to-end » Sans contrôle de flux Pas d’acquittement (ack) Adressage à travers des ports Détection des erreurs au niveau de l’entête (Checksum)
optionnel.
data
Sorce port Destination port
ChecksumLength
UDPheader
48
Le protocole TCP : Format de l’entête d’un segment
« Transmission Control Protocol » numéro de séquence par octet fenêtre d’anticipation ajustable par le destinataire temporisation en attente d’un ACK (contrôle de
réception et retransmission) Format de l’en-tête :
Port source Port destination
Numéro de séquence(numéro de séquence du 1ier octet de données dans le flot)
Numéro d’ACK(numéro du prochain octet attendu du flot et Ack jusqu’à ce n°-1)
Long. En -tête
URG
ACK
PSH
RST
SYN
FIN
Taille de la fenêtre
Checksum Pointeur urgent
Options Bourrage
Réservé
0 31
49
Entête d’un segment TCP (suite)
6 drapeaux d’un bit chacun URG est positionné à 1 si le pointeur d’urgence est en cours d’utilisation
(décalage à partir du n° de séquence courant indiquant où l’on peut trouver les données urgentes)Evite d’interrompre les messages.
ACK est positionné à 1 pour valider le n° d’Ack. S’il est à 0; le champ n° d’Ack est ignoré.
PSH (PuSH: données poussées) est positionné à 1 pour demander au destinataire de remettre les données à l’application concernée dès leur arrivée
RST est positionné à 1 pour réinitialiser une connexion ou refuser une tentative de connexion.
SYN sert à établir les connexions SYN=1 et ACK=0 Demande de connexion et le champ ack en mode
superposition (piggyback) n’est pas utilisé SYN=1 et ACK=1 Demande de connexion acceptée
FIN est positionné à 1 pour indiquer que l’émetteur n’a plus de données à transmettre (demander la libération de la connexion). Il peut continuer à recevoir des données.
Les segments SYN et FIN ont leurs propres n° de séquenceordre de traitement
50
• Contrôle de la congestion – Problème :
• Le débit de l’émetteur est supérieur soit à la capacité du réseau soit à la capacité du récepteur; ce qui provoque la perte de paquets, d’où l’apparition d’une congestion.
Le protocole TCP (suite)
51
• Contrôle de congestion–Solutions :
• La détection se base sur le fait que :
si un paquet est perdu, ceci est probablement dû à un problème de congestion plutôt qu’à une erreur de transmission (le taux d’erreur sur les supports de transmission actuels est considéré faible).
• Le récepteur peut éviter la congestion en spécifiant une taille de la fenêtre en fonction de la taille de la mémoire libre
• Reste à résoudre la congestion due au réseau : algorithme du démarrage lent «Slow Start». Cet algorithme utilise une seconde fenêtre dite de congestion.
• TCP utilise la fenêtre de congestion Fenêtre_autorisée = min (indication_réception, fenêtre_congestion)
Le protocole TCP (suite)
52
Contrôle de la fenêtre de congestion
0
4
8
12
16
20
24
28
32
36
40
44F
enêt
re d
e co
nge
stio
n (
Ko)
Seuil d’évitement
Le seuil est ramené à la moitié de la taille de la fenêtre atteinte
Expiration du temporisateurou ICMP/Source Quenchremonté à TCP
Taille max. d’unsegment (1 Ko)=>Ne perturbe pasConsidérablement les connexions existantes
Incrémentation à chaqueréception des acks(Si émission de 8 seg. etréception des ack correspondants, on passe à 16)
Temps
Le protocole TCP Tahoe
Evitement de congestion (Incremental Increase) : On n’augmente la fenêtre de 1 que si tous les segments de la fenêtre sont ack.
53
Le protocole TCP (Reno)
Contrôle de la fenêtre de congestion (Reno)
TC
P w
indow
(W
)
Congest
ion
Congest
ionongestion
Refresh: TCP congestion control
Time
CA
Slow startthreshold
Receiverwindow
Loss detection via duplicate ACKs Loss detection via Timeout
Updated slow startthreshold
C
Slow Start
Avoidance
SS
55
Contrôle de congestion : les solutions Le démarrage lent (Slow Start) Multiplicative decrease + Incremental Increase En cas de perte d’un segment, il faut réduire la fenêtre de
congestion d’un facteur multiplicatif (de moitié) Quand l’émission de trafic commence sur une nouvelle
connexion ou reprend après une période de congestion, il faut commencer par une fenêtre de congestion limitée à un seul segment et incrémenter la fenêtre de congestion d’un segment à la fois, chaque fois qu’un accusé de réception est reçu.
La phase d’évitement de congestion (congestion avoidance)
Objectif : ralentir le rythme d’augmentation de la fenêtre pour éviter une nouvelle congestion
Le protocole TCP (suite)
What to do with tcpdump data?TCPTRACE
A well known powerful tool that uses the measurements collected by tcpdump toanalyze tcp connections (http://www.tcptrace.org).
Tcptrace analyzes the traces collected
It also generate six different types of graphs illustrating various parameters of a TCP
connection..
.
Four main options exist:“nothing”: we get a brief summary of the TCP connections in the file.
“-l”: long list of parameters.
“-r”: statistics on the round-trip time.
“-W”: statistics on the window size.
An example of Tcptrace output : list ofparameters
a->b: b->a:
16162
181821318182
0
1460 bytes
1448 bytes806 bytes1398 bytes
33304 bytes33304 bytes0 times
33304 bytes1448 bytes
total packets:ack pkts sent:pure acks sent:
unique bytes sent:actual data pkts:actual data bytes:
rexmt data pkts:rexmt data bytes:mss requested:
max segm size:min segm size:avg segm size:
max win adv:min win adv:zero win adv:
avg win adv:initial window:initial window:
161513
4501450
001460 bytes
450 bytes450 bytes449 bytes
40544 bytes5840 bytes0 times
23174 bytes450 bytes1 pkts
total packets:ack pkts sent:pure acks sent:
unique bytes sent:actual data pkts:actual data bytes:
rexmt data pkts:rexmt data bytes: 0mss requested:
max segm size:min segm size:avg segm size:
max win adv:min win adv:zero win adv:
avg win adv:initial window:initial window: 1 pkts
An example of Tcptrace output :list ofparameters
a->b: b->a:throughput: 1113 Bps throughput: 44957 BpsRTT samples: 48 RTT samples: 47RTT min: 74.1 ms RTT min: 0.1 msRTT max: 204.0 ms RTT max: 38.8 msRTT avg: 108.6 ms RTT avg: 8.1 ms
duplicate acks: 0 duplicate acks: 0triple dupacks: 0 triple dupacks: 0max # retrans: 1 max # retrans: 0
max owin: 451 bytes max owin: 1449 bytesmin non-zero owin: 1 bytes min non-zero owin: 1 bytesavg owin: 31 bytes avg owin: 1213 byteswavg owin: 113 bytes wavg owin: 682 bytes
owin: outstanding number of bytes.wavg owin: weighted average owin.
Graphing with TCPTRACE
Six graphs can be provided by tcptrace (have then to be plotted by xplot).
Time Sequence Graph.
Throughput Graph.
RTT Graph.
Outstanding Data Graph.
Segment Size Graph.
Time-Line Graph.
Time Sequence Graph
Throughput Graph
RTT Graph
RTT samples calculated as in TCP for only non-retransmitted packets.
Outstanding Data Graph
Segment Size Graph
52
Time Line Graph
Problem: We cannot know exactly the time at which packets arrive and leave thesecond peer, since measurements are only taken at one peer.
• Heuristic: Assume symmetric paths and use half the round-trip time.
Evolution de l’Internet Evolution des
métriquesnouvelles plus précisesmieux définies
Evolution des métriques
66
67
Les métriques IPPM:
IP Performance Metrics
Un cas d’école « RTT »
• Mesure du RTT entre deux machines A et B avec ping– Ne donne pas les asymétries : de routage, de queuing– Sensibilité au traitement spécifique du protocole ICMP– Sensibilité aux OS, à leur charge
• Approche IPPM : RTT = OWD1 + OWD2– OWD1 = délai de A vers B– OWD2 = délai de B vers A– OWD >= temps de propagation + temps de sérialisation
• Mesures à l’interface réseau• Horloges synchronisées par GPS• Mesures ponctuelles, statistiques (échantillonnage défini)• Mesure indirecte de la charge des liens
68
Les métriques IPPM: IP Performance Metrics
• Il s'agit d'un travail (réalisé par le groupe IETF du même nom) qui décrit très précisément la terminologie mais aussi les méthodes et les unités à utiliser pour la définition de métriques
• RFC 2330
69
IPPM = IP Performance MetricsImportants travaux à l’IETF autour des métriques Exemples de métriques IPPM définies– A One-way Delay Metric for IPPM : RFC 2679– A One-way Packet Loss Metric for IPPM : RFC 2680– One-way Loss Pattern Sample Metrics for IPPM: RFC 3357– A Round-trip Delay Metric for IPPM : RFC 2681– IP Packet Delay Variation Metric for IPPM : RFC 3393– Packet Reordering Metric for IPPM : RFC 4737– ….
70
Une métrique réseau ?Une métrique est une caractéristique du comportement d'un réseau. Elle est exprimée dans une unité standard et permet de faire des comparaisons
– Dans le temps : ➔ Après un changement de configuration ➔ Après une panne, un changement de route
– Dans l'espace ➔ Entre 1 poste et deux autres postes, afin de comparer
des situations– Entre deux réseaux
➔ Dont les topologies sont proches mais les performances différentes
71
Limitations physiques
• Certaines métriques sont liées à des limites physiques
Ex: La vitesse de la lumière dans le vide est une limite basse absolue :
V = 299 792 458 m/s
72
➔ Il ne sert à rien d'espérer mieux
Limitations au niveau des équipementsLes équipements traversés imposent leurs propres limitations
•Files d'attente•Charge sur des liens•Décisions de routage– Tous les paquets d'un même flux n'empruntent pas le même chemin•Equilibrage de charge•Programmation de QoS avec du traffic policing ou la mise en œuvre d'algorithmes de gestion de la congestion
73
Les métriques physiques• Temps de propagation/Propagation delay : Temps mis par le signal pour traverser le lien physique– 0,66V 200 000 000 m/s sur une FO (fibre optique)≃– De 0,66V à 0,95V (sur des liens cuivres)– Délai pour faire 1000 km = 1000/200 000 = 0,005 soit 5 ms• Temps d'insertion/Serialization delay : Temps d'insertion d'un paquet sur une ligne physique– Pour insérer 1500 octets sur une ligne de 1Gbits/sec il faut :1500x8 / 109 = 0,000012 s = 12 μs– Pour insérer 1500 octets sur une ligne de 10Mbits/sec il faut:1500x8 / 107 = 0,0012 s = 1,2 ms• Temps de mise en paquet/Packetization delayTemps pris par une application pour remplir un paquet IP– Il s'agit d'un délai variable et configurable• Autres délais : Codec, Queuing, …
74
Les métriques IPPM:les critères à respecter
• Les métriques doivent être concrètes et bien définies
• Les résultats d'une mesure avec une métrique donnée doivent être reproductibles : une mesure effectuée de multiples fois dans des conditions identiques doit donner des résultats identiques
• Les métriques doivent être utiles, pour les fournisseurs d'accès et les utilisateurs afin qu'ils comprennent les performances qu'ils perçoivent ou fournissent
75
Les métriques IPPM• Une métrique IPPM est une quantité relative à la performance ou
à la fiabilité d'Internet qui a été spécifiée avec beaucoup d'attention
• Les unités de mesures utilisées sont celles du Système International d'Unités
• L'unité d'information est le bit. 1 kbits = 1000 bits, pas 1024.
• Le temps utilisé est le temps UTC
• Toutes les mesures qui ont étés définies sont des mesures directes, par injection de trafic
• par ex mesure du RTD d'un paquet IP d'une taille donnée sur un chemin donné à une heure donnée 76
Les métriques IPPM : vocabulaire• Host/Hôte : un ordinateur capable de communiquer en
utilisant les protocoles de l'Internet. Ça inclut les routeurs.• Link/Lien : Une connexion simple de niveau 2 entre deux
hôtes ; ça inclut les liaisons louées ou Ethernet, les nuages Frame Relay, etc.
• Router/Routeur : un hôte qui facilite la communication au niveau 3 entre des hôtes en acheminant des paquets IP
• Path/Chemin : une séquence de la forme <h0, l1, h1, ..., ln, hn>
où- n ≥ 0, - Chaque hi est un hôte et chaque li est un lien entre hi-1 et hi,- Chacun des h1...hn-1 est un routeur,- Une paire <li, hi> est nommée un hop/saut. - Un chemin est un concept unidirectionnel.
77
• Cloud/Nuage : un graphe non orienté dont les sommets sont des routeurs et les arêtes des liens qui connectent des paires de routeurs
• Subpath/sous-chemin : Pour un chemin donné, un sous-chemin est n'importe quelle sous-séquence d'un chemin qui est elle-même un chemin. (Débute et se termine par un hôte).
– <h0, l1, h1, l2, h2, l3, h3, l4, h4> est un chemin• <h0, l1, h1, l2, h2> est un sous-chemin• <h2, l3, h3> est un sous-chemin• <l1, h1, l2, h2> n'est pas un sous-chemin• <h0> est un sous-chemin 78
Les métriques IPPM : vocabulaire
• Exchange/Un point d'échange : un cas particulier de lien. Un exchange interconnecte soit- Un hôte à un nuage - Un nuage à un autre nuage
• Cloud subpath/Sous-chemin de nuage : le sous-chemin d'un chemin dont tous les routeurs appartiennent à un nuage
79
Les métriques IPPM : vocabulaire
L'incertitude temporelle• Synchronisation entre deux horloges– IPPM → Clock Offset : décalage entre une horloge et le temps UTC• Exactitude : par rapport à une norme– IPPM → Accuracy : plus l'offset est proche de zéro, plus l'horloge
est précise• Résolution : la valeur minimale de temps qu'une horloge sait
mesurer– IPPM → Resolution : la plus petite unité de temps par laquelle unehorloge est mise à jour• Ecart de fréquence : différence de fréquence entre deux horloges– IPPM → Skew : différence de fréquence entre l'horloge et le tempsUTC• Variation de l‘écart : variation de l‘écart de fréquence– IPPM → Drift : variation du skew au cours du temps
80
Les métriques IPPM :Wire time
• Le RFC IPPM définit la notion de wire time / ≪temps filaire de la façon suivante :≫
– P est un paquet– H est un hôte– L est l'endroit ou H observe un lien Internet* Le temps d'arrivée filaire de P sur H au niveau de L
est le premier instant T ou un bit quelconque de P est apparu en L
* Le temps de départ filaire de P de H est le premier instant T ou tous les bits de P sont partis en L
81
Les métriques IPPM :Wire time
• La mesure du wire time se fait au niveau d'un hôte → cela veut dire que le RFC ne prévoit pas de mesures via des boitiers spécialisés en des points d'un lien ou un hôte ne pourrait pas être.
• Le RFC prévoit des difficultés avec la notion de wire time en cas defragmentation : les fragments sont des paquets IP légitimes avec deswire time alors que le paquet agrégé n'en a pas
➔ Il faut dire qu'auparavant la notion de wire time était courammentutilisée mais jamais définie (premier ou dernier bit, à l'arrivée, audépart ?) ce qui induisait des erreurs de l'ordre des délais desérialisation et de propagation. La norme définie élimine le délai desérialisation de la mesure.
82
Les métriques IPPM :types de métriques
• Singleton– Métrique atomique
* par exemple temps de transit à sens unique à un instant donné pourdes paquets de taille N
• Sample (échantillon)– Métrique dérivée d'une métrique de type singleton, en prenant plusieurs
instances temporelles ou spatiales.* Par exemple, un ensemble de temps de transit à sens unique pour des instants répartis selon une loi de Poisson dans un intervalle de temps donné
• Statistical– Métrique calculée à partir des valeurs des singletons pris dans un sample.
* Par exemple, la valeur moyenne du temps de transit sur une période de temps donnée, calculée en faisant la moyenne du sample précèdent
83
Les métriques IPPM : collecte d‘échantillons
• La collecte de sample sert surtout à observer les variations d'une métrique donnée. Variations en fonction du point d'observation ou en fonction du temps.• Le RFC recommande l'utilisation d'un échantillonnage
suivant une loi de Poisson• L'arrivée des paquets ne peut pas être prédite• L‘échantillonnage n'est pas biaisé (→ impartial), même si la
mesure affecte l‘état du réseau• La mesure n'induit pas de synchronisation• Elle peut être utilisée pour collecter des mesures sur des
comportements cycliques84
Les métriques IPPM :les métriques définies
• Framework for IP Performance Metrics : RFC 2330• IPPM Metrics for Measuring Connectivity : RFC
2678 • A One-way Delay Metric for IPPM : RFC 2679• A One-way Packet Loss Metric for IPPM : RFC 2680• One-way Loss Pattern Sample Metrics (RFC 3357)• A Round-trip Delay Metric for IPPM : RFC 2681• IP Packet Delay Variation Metric for IPPM : RFC
3393• Packet Reordering Metric for IPPM: RFC 4737
85
Les métriques IPPM : EDF
EDF = Empirical distribution function EDF est la fonction F(x) qui indique la proportion de mesures dont la
valeur est inférieure ou égale à x Si on a l'échantillon des 6 mesures suivantes : -2, 7, 7, 4, 18, -5
Alors :
F(-8) = 0F(-5) = 1/6F(-5.0001) = 0F(-4.999) = 1/6F(7) = 5/6F(18) = 1F(239) = 1.
Les métriques IPPM : percentile
Xth percentile = plus petite valeur p de l'échantillon telle que F(p)>= X%Exemple :
-2, 7, 7, 4, 18, -5Alors :
50th percentile = 4 → F(4) = 3/6 = 50%25th percentile = -2 → F(-5) = 1/6 < 25% et F(-2) = 2/6 >= 25%100th percentile = 180th percentile is ∞
Les métriques IPPM : Type-P
Introduction de la notion du Type-P La plupart les métriques d'Internet sont dépendantes du type de
paquet utilisé (protocole, taille, ports src/dst) Quand une métrique dépend du type de paquet utilisé, son nom
doit contenir l'expression Type-P pour la rendre générique Une métrique générique n'est pas directement utilisable Pour faire une mesure, il faut d'abord spécifier plus précisément
le type de paquet qui sera utilisé :générique → spécifiquetype-P-metric → TCP-src1550-dst80-size800-metric
Les métriques
ConnectivityNetwork Capacity
One-way PacketDuplication
Packet Reordering
IPPMNMWG
Bulk TransferCapacity
One-way Packet Loss
DelayVariation
CiRen 32 – Performances Réseau – Métriques IPPM – D. Benza
One-way Delay
Les métriques IPPM : les métriques définies
Framework for IP Performance Metrics : RFC 2330 IPPM Metrics for Measuring Connectivity : RFC 2678 (2498) A One-way Delay Metric for IPPM : RFC 2679 A One-way Packet Loss Metric for IPPM : RFC 2680 One-way Loss Pattern Sample Metrics (RFC 3357) A Round-trip Delay Metric for IPPM : RFC 2681 IP Packet Delay Variation Metric for IP Performance Metrics
(IPPM) : RFC 3393 Packet Reordering Metric for IPPM: RFC 4737
Les métriques IPPM :les RFC compagnons
A Framework for Defining Empirical Bulk Transfer CapacityMetrics : RFC 3148
Network performance measurement for periodic streams : RFC3432
A One-way Active Measurement Protocol Requirements : RFC3763
IP Performance Metrics (IPPM) metrics registry : RFC 4148
A One-way Active Measurement Protocol (OWAMP) : RFC 4656
Les métriques IPPM : Autres métriques (certaines en cours)
Defining Network Capacity (draft-ietf-ippm-bw-capacity-05 →1/12/2007)
Two-way Active Measurement Protocol (TWAMP) (draft-ietf-ippm-twamp-04 → 11/2007)
IP Performance Metrics for spatial and multicast (draft-ietf-ippm-multimetrics-04 → 7/1/2008)
Spatial Composition of Metrics (draft-ietf-ippm-spatial-composition-04→ 8/1/2008)
Framework for Metric Composition (draft-ietf-ippm-framework-compagg-04 → 8/1/2007)
One-Way Packet Duplication Metric for IPPM (draft-ietf-ippm-duplicate-02.txt → 7/2/2008)
Les métriques IPPM : Connectivité
La mesure dont l'utilité est la plus évidente : est-ce qu'un paquetpartant d'une machine A est reçu par la machine B ?
Mais quand on y réfléchit bien, cette notion n'est pas si simple àdécrire que ça :
– Parle-t-on de connectivité instantanée ?
– De connectivité sur une période de temps
– Unidirectionnelle ou bi-directionnelle ?
– Pour quel type de paquets ?
Les métriques IPPM : Connectivité
Type-P-Instantaneous-Unidirectional-Connectivity(Src, Dst, T) = Booléen– Src et Dst ont une connectivité à sens unique instantanée de type-P à
l'instant T si un paquet de type-P transmis de Src à l'instant T arrive àDst
– Singleton
Type-P-Instantaneous-Bidirectional-Connectivity(A1, A2, T, dT) = Booléen– A1 et A2 ont une connectivité bi-directionnelle instantanée de type-P à
l'instant T si un paquet de type-P transmis de A1 à l'instant T arrive à A2et si un paquet de type-P transmis de A2 à T+dT arrive à A1
– dT est le temps de transit d'un paquet de type-P de A1 vers A2– Singleton
Les métriques IPPM : Connectivité
Type-P-Interval-Unidirectional-Connectivity(Src, Dst, T, dT)= Booléen– Singleton
Type-P-Interval-Bidirectional-Connectivity(A1, A2, T, dT) = Booléen– Singleton
➔ Pour les deux métriques ci-dessus il suffit que la métriqueinstantanée correspondante soit vraie pour un seul instant dansl'intervalle [T, T+dT] pour que la métrique soit vraie
Les métriques IPPM : Connectivité
Type-P1-P2-Interval-Temporal-Connectivity(Src, Dst, T, dT) = Booléen
– Sample– Pour N instants T1 répartis selon une loi de Poisson dans l'intervalle [T, T+dT],
s'il existe au moins un T1 tel que :• Src a une connectivité unidirectionnelle instantanée de type-P1 avec Dst à
l'instant T1• Dst a une connectivité unidirectionnelle instantanée de type-P2 avec Src à
l'instant T1+dT1 où dT1 est le temps de transit entre Src & Dst pour un paquet de type P1
➔ Alors il y a une connectivité bi-directionnelle de type-P1-P2 entre Src etDst dans l'intervalle [T, dT]
Les Métriques IPPM : OWD
Définition d'un Type-P-One-Way-Delay générique– Le temps de transit entre deux machines peut varier en fonction du type
de paquets– Par exemple, un protocole considéré comme moins prioritaire que TCP par
les routeurs, est plus susceptible d'être retardé en file d'attente.
Le temps de transit impacte énormément les applications temps-réel
La borne inférieure du One-Way Delay est la somme des temps depropagation et de sérialisation le long du chemin
Les valeurs de cette métrique au-dessus de la borne inférieure donnentune indication de la charge du chemin
Le calcul du OWD nécessite une grande précision dans la synchronisation
des horloges
Les Métriques IPPM : OWD
Le OWD donne une indication plus fine que le Round Trip Delay
– Routage asymétrique
– Il peut y avoir du queuing asymétrique (charge des liens différentes dansun sens et dans l'autre)
– La performance d'une application peut être impactée par le temps detransit dans un sens, pas par celui dans l’autre
Les Métriques IPPM : OWD
Type-P-One-way-Delay (Src, Dst, T) = dT
– T = wire time émission
– T+dT = wire time réception
Singleton
Si le paquet est dupliqué sur le chemin, dT est calculé au wiretime de l'arrivée du premier paquet
Si le paquet est fragmenté et non réassemblé, il est estimé perdu
Une synchronisation GPS est souhaitable pour calculer cettemétrique
39
Les Métriques IPPM : OWD
Type-P-One-way-Delay-Poisson-Stream(Src, Dst, T0, Tf, ) =({T0, dT0}, {T1, dT1}, ..., {Tf, dTf})
– T0, T1, ... Tf : générés selon une loi de Poisson TN-TN-1 = en moyenne 1/
– Sample
Type-P-One-way-Delay-Percentile(Stream, X) = dT
Type-P-One-way-Delay-Median(Stream) = dT
Type-P-One-way-Delay-Inverse-Percentile(Stream, treshdold) = X %
– Statistical
41
Les Métriques IPPM : Round-trip Delay
Type-P-Round-trip-Delay(Src, Dst, T) = dT
– T = wire time émission du paquet au départ de Src
– T+dT = wire time réception du paquet retour par Src
Type-P-Round-trip-Delay-Poisson-Stream(Src, Dst, T0, Tf, )
Type-P-Round-trip-Delay-Percentile(Stream, X%) = dT
Type-P-Round-trip-Delay-Median(Stream) = dT
Type-P-Round-trip-Delay-Minimum(Stream) = min(dT)
Type-P-Round-trip-Delay-Inverse-Percentile(Stream, dT) = X%
42
Les Métriques IPPM : One-way Packet Loss
La métrique One-way Packet Loss est plus précise que le RoundTrip Packet Loss, le chemin aller n'est pas forcément le même quele chemin retour
Certaines applications sont plus sensibles aux pertes de paquetsdans un sens que dans l'autre, les transferts de fichiers, parexemple :
– Données dans un sens, gros volumes de données– ACK dans l'autre sens, quelques paquets seulement
Queuing asymétrique
43CiRen 32 – Performances Réseau – Métriques IPPM – D. Benza
Les Métriques IPPM : One-way Packet Loss
Type-P-One-way-Packet-Loss(Src, Dst, T) Є{0, 1}
– Singleton
Type-P-One-way-Packet-Loss-Poisson-Stream(Src, Dst, T0, Tf, )= ({T0, L0}, {T1, L1}, ..., {Tf, Lf})– T0, T1, ... Tf : générés selon une loi de Poisson TN-TN-1 = en moyenne 1/
– LN Є{0, 1}
– Sample
Type-P-One-way-Packet-Loss-Average = Avg(L0...Lf)– Stream1 = ({T0, 0},{T1, 1},{T2, 0},{T3, 1},{T4, 0},{T5, 0},{T6, 0}) =
0,286 = 28% de pertes
– Statistical
45
Les Métriques IPPM : Delay Variation
Type-P-One-way-ipdv(Stream(Src, Dst, I1, I2, ), L, F) = ddT, T1,T2
– F : fonction de sélection de deux paquets émis à T1 et T2
••••
Paquets consécutifsDélai min et délai max dans l'intervallePaquets envoyés à des indices donnésetc
– L : longueur des paquets émis
– Si dT1 est le OWD(Src, Dst, T1) et dT2 = OWD(Src, Dst, T2) alorsddT = dT2 – dT1
– Singleton
46
Les Métriques IPPM : Delay Variation
Type-P-One-way-ipdv-Poisson-stream(Stream(Src, Dst, T0, Tf,, L), F) = ({Ti, Tj, ddT}, {Tk, Tp, ddT}, ..., {Tm, Tu, ddT})
– Sample
Type-P-One-way-ipdv-percentile(IPdv, X%) = ddT
– Type-P-One-way-ipdv-percentile(IPdv, 50%) = médiane
– Statistical
Type-P-One-way-ipdv-inverse-percentile(IPdv, ddT) = X%
– Statistical
Type-P-One-way-peak-to-peak-ipdv(Stream(Src, Dst, T0, Tf, , L))–le paquet avec le OWDmax et le paquet avec le OWDmin
Type-P-One-way-ipdv-jitter(Stream(Src, Dst, T0, Tf, , L))– Statistical
– L'estimation du jitter e jnipdvn
48
IPPM : Réordonnancement de paquets
Les paquets peuvent arriver dans un ordre différent de l'ordred'émission
Par exemple :
– Quand les paquets d'un même flux empruntent des chemins avec desdurées différentes d'acheminement des paquets (load balancing, par ex)
– Retransmission par un protocole de niveau 2
– Algorithme de gestion de files réordonnançant les paquets
– …..
49
IPPM : Réordonnancement de paquets
Type-P-Reordered(Src, Dst, SrcTime, s, NextExp) = Booléen– Singleton
SrcTime : Temps d'émission du paquet– s : numéro de séquence– NextExp : Le numéro de séquence attendu
Type-P-Reordered-Ratio-Stream(Src, Dst, T0, Tf, K, L) = R
– T0, Tf temps de début et de fin
– dT = temps de transit max (au-delà de dT, le paquet est déclaré perdu)
– K le nombre de paquets envoyés de Src
– L, le nombre de paquets reçus parmi K L <= K
– R = le ratio du nombre de paquets réordonnancés par rapport au nombrede paquets reçus :
RCountTypePReorderedTrue
L
IPPM : Réordonnancement de paquets
Type-P-Packet-Reordering-Extent-Stream(Src, Dst, T0, Tf, K, L)= { ei, ... ej }
– Les paquets sont numérotés à l'émission 1..K
– ei est la distance qui sépare i de l'emplacement qu'il aurait normalementdu occuper à son arrivée
Type-P-Packet-Late-Time-Stream(Src, Dst, T0, Tf, K, L) = {lTi, ... lTj}
–––
On utilise l'horloge de la destinationLe numéro de séquence de départ du paquet arrivé en position i, est noté s[i].Pour tous les paquets réordonnancés
lTs[i] = Retard du paquet s[i]
– Décalage en nombre d'octets du paquet s[i] par rapport à la position qu'ilaurait du occuper
IPPM : Réordonnancement de paquets 6/11
Type-P-Packet-Byte-Offset-Stream(Src, Dst, T0, Tf, K, L) ={bOi, ... bOj}
Type-P-Packet-Reordering-Gap-Stream(Src, Dst, T0, Tf, K, L) ={Gi, ... Gj}
Type-P-Packet-Reordering-GapTime-Stream(Src, Dst, T0, Tf, K,L) = {gTi, ... gTj}
– Pour le calcul des GapTime, on utilise l'horloge de la destination– Écart entre deux discontinuités correspondant à des paquets réordonnés
IPPM : Réordonnancement de paquets
Type-P-Packet-Reordering-Free-Run-x-numruns-Stream(Src, Dst, T0, Tf, K,L) = x
Type-P-Packet-Reordering-Free-Run-q-squruns-Stream(Src, Dst, T0, Tf, K,L) = q
Type-P-Packet-Reordering-Free-Run-p-numpkts-Stream(Src, Dst, T0, Tf, K,L) = p
Type-P-Packet-Reordering-Free-Run-a-accpkts-Stream(Src, Dst, T0, Tf, K,L) = a
Dans ces métriques un reordering-free run est une séquence de paquetsconsécutifs sans réordonnancement
x, le nombre de run a, le compteur de paquets dans l'ordre. p, le nombre de paquets (quand le flux est complet, p=(x+a)). q, la somme des carrés des longueurs de run
% de paquets dans l'ordre =
La longueur moyenne des runs sans réordonnancement :
100a
p
a
x
x, le nombre de run
a, le compteur de paquets dans l'ordre. p, le nombre de paquets q, la somme des carrés des longueurs de run
IPPM : Réordonnancement de paquets
q
a
x
a
qx
a²
x, le nombre de run
a, le compteur de paquets dans l'ordre. p, le nombre de paquets q, la somme des carrés des longueurs de run
IPPM : Réordonnancement de paquets
q donne une idée de la variation autour de la moyenne :
Métriques IPPM vs NMWG
NMWG = Network Monitoring Working Group de l'Open GridForum, cherche à développer un dictionnaire commun demétriques
•••••
AvailabilityCapacityUtilizationAvailable BandwidthAchievable Bandwidth
•••••
One Way DelayJitterRound Trip DelayOne Way LossRoundtrip Loss
• One-Way Reordering
NMWG IPPM
One-Way-Delay
RoundTripDelay
One-WayandRoundTripLoss+Losspattern(NMWG)(IPPM)
Availability Connectivity
Capacity Network Capacity
Utilization Pasd’équivalent
AvailableBW Pasd’équivalent
AchievableBW BulkTransfercapacity
Jitter IPDelayVariation & Jittercalculé
Métriques IPPM vs NMWG
Expérimentations et Résultats
Quantité totale de données par application surune plaque ADSL de France Télécom
Expérimentations et Résultats
Répartition du débit par application en octets/ssurune plaque ADSL de France Télécom
Caractérisation du trafic internet
Classification du trafic internet• Définir :
• Une caractéristique d'agrégation (type de protocole, taille, etc...)
• Un niveau de service associé à chaque classe (QoS)
• Une échelle de temps à étudier (paquets, flots, sessions)
Caractérisation du trafic internet
Modélisation du trafic• Événement caractéristiques (pics, fluctuations)
• Abstraction par un processus aléatoire si possible
Définition des décisions• Traitements à appliquer en fonction de l'événement
détecté
Expérimentations et Résultats
Classification admise:• Deux principaux types de trafic :
• Streaming : contrainte de débit
• Élastique : pas de contraintes
Remarque :• Trafic de type élastique actuellement largement
majoritaire ( 90 %)
Expérimentations et Résultats
Analyse du trafic
Trafic particulièrement instable• Propriété d'auto-similarité
• Dépendance à long terme
Causes• TCP: dépendances induites :
• par les acquittements
• Par les mécanismes de slow start et congestionavoidance
• Transfert de Flot de gros paquets sur des duréesimportantes
Expérimentations et Résultats
Analyse du trafic
Comparaison entre les oscillations observables dans un traficInternet et un trafic Poissonnien
Expérimentations et RésultatsAnalyse du trafic
Trafic Internet caractérisé par uneprésence forte de TCP
trafic complexe et non prévisible
Partie II
Caractérisation de
Trafic
123
Bibliographie•James Roberts•Philippe Robert•François Bachelli•Thomas Bonald•….
Caractérisation de trafic
• Traffic engineeringRole: to ensure that a network has enough
capacity to need expected demand with adequate QoS.
Understand the three way relationship between demand, capacity and performance
Each of these being quantified in appropriate units.
Uncertain because of the modeling difficulty that it implies.
124
Quality of service in a multiservice network
Depends essentially on two factors: •the service model which identifies different service classes and specifies how network resources are shared, – Identify the entity to which traffic controls apply. “Flow" defined as the succession of packets
pertaining to a single instance of some application (document transfer, visioconference, …)
•and the traffic engineering procedures usedto determine the capacity of those resources.
125
Quality of service requirements
It is useful to distinguish three kinds of quality of service measures:•Transparency •Accessibility •Throughput
126
• Transparency – the time and semantic integrity of transferred
data– For real-time traffic delay should be negligible
while a certain degree of data loss is tolerable. – For data transfer, semantic integrity is generally
required but (per packet) delay is not important.
127
Quality of service requirements
Quality of service requirements
• Accessibility– the probability of admission refusal and the delay for
set up in case of blocking– In the Internet, if no admission control all new
requests are accommodated by reducing the amount of bandwidth allocated to ongoing transfers.
– Accessibility becomes a problem, if it is considered necessary that transfers should be realized with a minimum acceptable throughput.
128
Quality of service requirements
• Realized Throughput – for the transfer of documents such as files or Web
pages, it constitutes the main quality of service measure for data networks.– the transfer of Web pages should be quasi-
instantaneously (less than one second).
129
Quality of service requirements• To meet transparency requirements the
network must implement an appropriately designed service model.
• The accessibility requirements must then be satisfied by network sizing taking into account the random nature of user demand.
• Realized throughput is determined both by how much capacity is provided and how the service model shares this capacity between different flows.
130
Caractérisation du trafic• Traffic in the Internet results from the
uncoordinated actions of a very large population of users and must be described in statistical terms.
• It is important to be able to describe this traffic succinctly in a manner which is useful for network engineering.
• With respect to the above requirements, it proves useful to distinguish two broad classes of traffic
Stream Elastic
131
Stream traffic• Stream traffic entities are flows having an
intrinsic duration and rate (which is generally variable) whose time integrity must be (more or less) preserved by the network.
• Such traffic is generated by applications like the telephone and interactive video services such as videoconferencing where significant delay would constitute an unacceptable degradation.
• The way the rate of stream flows varies is important for the design of traffic controls.
132
• Speech signals are typically of on/off type with talkspurts interspersed by silences.
• Video signals rate variation is generally more complex.
• Importantly for traffic engineering, the bit rate of long video sequences exhibits long-range dependence.
133
Stream traffic: Arrival rate
• The number of stream flows in progress on some link, is a random process varying as communications begin and end.
• The arrival intensity generally varies according to the time of day.
• In a multiservice network it is natural to extend current practice for the telephone network by – identifying a busy period (e.g., the one hour period
with the greatest traffic demand).– and modelling arrivals in that period as a stationary
stochastic process (e.g., a Poisson process). 134
Stream traffic: Arrival rate
TRAFFIC VARIATIONS AND THENOTION OF STATIONARITY
• It is possible to detect a busy period (usually in the afternoon between 2 and 5 pm) during which the traffic intensity is roughly constant.
• This constancy suggests that Internet traffic, like telephone traffic, can be modeled as a stationary stochastic process where statistical variations occur about an underlying constant intensity.
• Busy period performance is then estimated by the long term average behavior derived for the stationary process. 135
• Traffic demand may then be expressed as the expected combined rate of all active flows:
Traffic demand =the arrival rate
x the mean duration x the mean rate of one flow.
136
Stream traffic: Traffic demand
• The duration of telephone calls is known to have a heavy-tailed distribution and this is likely to be true for stream flows suggesting that the number of flows in progress and their combined rate are self-similar processes.
137
Stream traffic: Duration
Heavy-tailed distributions
• Heavy-tailed distributions (distributions à queue lourde) are probability distributions whose tails are not exponentially bounded; that is, they have heavier tails than the exponential distribution. Ex: Pareto distribution
138
139
Exponential vs Pareto :Probability Density Function
140
Exponential vs Pareto :Cumulative Distribution Function
Self similarity : Auto similarité• In mathematics, a self-similar object is exactly
or approximately similar to a part of itself• L'autosimilarité est le caractère d'un objet
dans lequel on peut trouver des similarités en l'observant à différentes échelles.
141
Elastic traffic• The second type of traffic we consider consists
of digital objects or “documents" which must be transferred from one place to another. These documents might be data files, texts, pictures or video sequences transferred for local storage before viewing.
• This traffic is elastic in that the flow rate can vary due to external causes (e.g., bandwidth availability) without detrimental effect on quality of service.
142
Elastic traffic
• Users may or may not have quality of service requirements with respect to throughput. – They do for real-time information extraction
sessions where it is important for documents to appear rapidly on the user's screen.
– They do not for e-mail or file transfers where deferred delivery, within a loose time limit, is perfectly acceptable.
143
• The essential characteristics of elastic traffic are the arrival process of transfer requests and the distribution of object sizes .
• Observations on Web traffic provide useful pointers to the nature of these characteristics.
• The average arrival intensity of transfer requests varies depending on underlying user activity patterns.
• As for stream traffic, it should be possible to identify representative busy periods where the arrival process can be considered to be stationary.
144
Elastic traffic
Elastic traffic: Arrival process
• Measurements on Web sites suggest the possibility of modeling the arrivals as a Poisson process.
• Indeed a Poisson process results naturally when members of a very large population of users independently make relatively widely spaced demands.
• More recent and thorough measurements suggest that the Poisson assumption may be too optimistic.
145
Heavy-tailed distributions
• The size of elastic flows (i.e., the size of the documents transferred) is extremely variable and has a heavy-tailed distribution: most documents are small (a few kilobytes) but the number which are very long tend to contribute the majority of traffic.
146
Elastic traffic: Distribution of object sizes
• Statistics on the size of Web documents reveal that they are extremely variable exhibiting a heavy tailed probability distribution.
• Most objects are very small: measurements on Web document sizes reported reveal that – some 70% are less than 1 Kbyte – and only around 5% exceed 10 Kbytes.
• The presence of a few extremely long documents has a significant impact on the overall traffic volume.
147
Elastic traffic: Traffic demand
• It is possible to define a notion of traffic demand for elastic flows, in analogy with the definition given above for stream traffic, as:
Traffic demand =the average arrival rate in a representative busy
period x the average object size.
148
Traffic aggregations• Another category of traffic arises when individual flows and
transactions are grouped together in an aggregate traffic stream.
• This occurs currently, for example, when the flow between remotely located LANs must be treated as a traffic entity by a wide area network.
• Proposed evolutions to the Internet service model such as differentiated services (DiffServ) and MPLS (multi-protocol label switching) also rely heavily on the notion of traffic aggregation.
• Through aggregation, quality of service requirements are satisfied for an aggregate
scalability problem: maintain state on individual flows cannot keep up with the growth in traffic.
149
Traffic agregation: Capacity overbooking• In existing frame relay and ATM networks, current practice
is to considerably overbook capacity (the sum of guaranteed rates may be several times greater than available capacity), counting on the fact that users do not all require their guaranteed bandwidth at the same time. There is no longer any real guarantee.
• In addition, in these networks, users are generally allowed to emit traffic at a rate over and above their guaranteed bandwidth.
• This excess traffic is “tagged" and in case of congestion, it is handled on a best effort basis using momentarily available capacity.
It does, however, lead to an imprecision in the nature of the offered service It is more rigorous to consider Individual flows
150
Traffic control options
To realize quality of service guarantees. • Open loop control or preventive, traffic control – based on the notion of “traffic contract“
•Closed loop control or reactive traffic control – suitable for elastic flows which can adjust their rate
according to current traffic levels.
151
Open loop control
• A user requests a communication described in terms of a set of traffic parameters
• The network performs admission control, accepting the communication only if quality of service requirements can be satisfied.
• Either ingress policing or service rate enforcement by scheduling in network nodes is then necessary to avoid performance degradation due to flows which do not conform to their declared traffic descriptor. 152
Open loop control
The effectiveness of open loop control depends on how accurately it is possible to predict performance given the characteristics of variable rate flows.
•Statistical guarantee
•Deterministic guarantee
153
Open loop control: Statistical guarantee• Simplifying assumptions :– Flows have defined rates like fluids, assimilating links to
pipes and buffers to reservoirs.– Rate process are stationary
• Loss and delay performance are very difficult to predict when the input process is long-range dependent.
• The models are, generally only capable of predicting asymptotic queue behavior for particular classes of long-range dependent traffic.
154
Open loop control: Deterministic guarantee
• Deterministic guarantees are possible, in particular, if the amount of data A(t) generated by a flow in an
interval of length t satisfies a constraint of the form: A(t) ≤ ρt+σ.
– If the link serves this flow at a rate at least equal to ρ then the maximum buffer content from this flow is σ.
• Loss can therefore be completely avoided and delay bounded by providing a buffer of size σ and implementing a scheduling discipline which ensures the service rate ρ. The constraint on the input rate can be enforced by means of a leaky bucket.
155
Closed loop control
• Closed loop, or reactive, traffic control is suitable for elastic flows which can adjust their rate according to current traffic levels.
• This is the principle of TCP in the Internet. • It aims to fully exploit available network
bandwidth while achieving fair shares between contending flows.
156
Bandwidth sharing objectives
157
max-min fairness
• In a network the generalization of the simple notion of fairness is max-min fairness
• Allocated rates are as equal as possible subject only to constraints imposed by the capacity of network links and the flow's own peak rate limitation.
• The max-min fair allocation is unique and such that no flow rate λ, can be increased without having to decrease that of another flow whose allocation is already less than or equal to λ.
158
max-min fairness
• The simplest rate sharing algorithms are based on individual flows reacting to binary congestion signals.
• Fair sharing of a single link can be achieved by allowing rates to increase linearly in the absence of congestion and decrease exponentially as soon as congestion occurs.
159
Traffic theory
Traffic theory
Traffic theory means the application of mathematical modeling to explain the traffic performance relation linking.
161
network capacity
traffic demand Realizedperformance
Traffic theory
• The traffic theory is an essential component in the design of traditional telecommunications Networks to guide the design of the future multiservice Internet.
• It is increasingly applied in the development of the multiservice Internet.
162
Traffic theory
• Since demand is statistical in nature, performance must be expressed in terms of probabilities and the appropriate modeling tools derive from the theory of stochastic processes.
163
Traffic theory
164
Erlang loss formula
• The formula relies essentially only on the reasonable assumption that telephone calls arrive as a stationary Poisson process.
• It demonstrates the remarkable fact that, given this assumption, performance essentially depends only on a simple measure of the offered traffic, a, equal to the product of the call arrival rate and the average call duration.
• Blocking probabilities are insensitive to additional details about the nature of traffic such as the distribution of call durations.
165
Insensitive property
• It is possible to derive similar traffic performance relations for the Internet, even if these cannot always be expressed as concisely as the Erlang formula.
• Deriving such relations allows us to understand what kinds of performance guarantees are feasible and what kinds of traffic control are necessary.
166
Traffic theory: Objective
• The objective of traffic theory is ultimately to define simple network engineering procedures like applying the Erlang formula in the telephone network.
• Derivation of these procedures and proof of their general validity may, however, require somewhat sophisticated mathematical modeling.
167
Traffic characteristics• The precise characteristics of the Internet traffic (as a
stationary process) depend on the composition of Internet traffic.
• Currently, some 90 to 95% of Internet packets use TCP and correspond to the transfer of digital documents of one form or another (Web pages, data files, MP3 tracks, …).
• The congestion avoidance algorithms of TCP cause throughput to vary elastically in reaction to random changes in the set of transfers in progress.
• A small but growing proportion of traffic relates to inelastic streaming audio and video transmission for both interactive applications
168
TRAFFIC OBJECTS• The traffic process can be described in terms of the
characteristics of a number of objects, including packets, bursts, flows, sessions and connections, depending on the time scale of relevant statistical variations.
• The preferred choice for modeling purposes depends on the object to which traffic controls are applied.
• Traffic characterization proves most convenient at an intermediate flow level.
169
Flow level• A flow is defined for present purposes as the
unidirectional succession of packets relating to one instance of an application.
• For practical purposes, the packets belonging to a given flow have the same identifier (e.g., source and destination addresses and port numbers).
• It is useful to distinguish – elastic flows, where the packets in question constitute a
document being transferred, – and streaming flows, where the packets represent an
audio or video signal.
170
Packet level
• Packet level characteristics of elastic flows are mainly induced by the transport protocol and its interactions with the network.
• Streaming flows, on the other hand, have intrinsic (generally variable) rate characteristics that must be preserved as the flow traverses the network.
171
Session level• Flows are frequently emitted successively and
in parallel in what are loosely termed “sessions.”
• A session corresponds to a continuous period of activity during which a user generates a set of elastic or streaming flows.
172
ARRIVAL PROCESSES AND SERVICE REQUIREMENTS
• It is well known that the arrival process of IP packets can exhibit extreme rate variations at multiple time scales
• First reports of this behavior more than 20 years ago have introduced the called selfsimilarity phenomenon.
• The arrival process of flows in a backbone link typically results from the superposition of a large number of independent sessions.
173
ARRIVAL PROCESSES• Observations confirm the predictable property that
session arrivals can be assimilated to a Poisson process.
• This means simply that the probability of a new arrival in a short interval of length dt is equal to λdt, where λ is the arrival intensity, and is independent of all past activity.
• A Poisson process results naturally when traffic is due to the independent activity of a very large population of users, each individually having a very small intensity.
174
ARRIVAL PROCESSES
• As a first approximation, it is not unreasonable to assume that individual flows also occur as a Poisson process.
• However, the results derived under the simple Poisson assumption are often true under more general assumptions.
175
Elastic flow size• The size of elastic flows (i.e., the size of the
documents transferred) is extremely variable and has a so-called heavy-tailed distribution: most documents are small (a few kilobytes) but the number which are very long tend to contribute the majority of traffic.
• However, it proves very difficult to describe the distribution of elastic flow size.
• It is therefore highly desirable to implement controls such that performance is largely insensitive to the precise document size characteristics. 176
Streaming flows duration
• The duration of streaming flows also generallyhas a heavy-tailed distribution. • Furthermore, the packet arrival process within a
variable rate streaming flow is often self-similar. • As for elastic flows, it proves very difficult to
precisely measure and specify these characteristics for streaming flows.
• It is thus again important to design traffic controls which make performance largely insensitive to them.
177
TRAFFIC THEORY FOR ELASTIC TRAFFIC• Exploiting the tolerance of document transfers to
rate variations implies the use of closed-loop control.
• Assumption: closed-loop control is applied end-to-end on a flow-by-flow basis using TCP.
• TCP realizes closed loop control by implementing an additive increase, multiplicative decrease congestion avoidance algorithm: the rate increases in the absence of packet loss but is halved whenever loss occurs.
178
Packet Scale Performance
179
• Since the flow throughput B depends on the set of flows in progress (each receiving a certain share of available bandwidth), the packet scale performance is mainly determined by flow level traffic dynamics.
• It can, in particular, deteriorate rapidly as the number of flows sharing a link increases.
180
Packet Scale Performance
PERFORMANCE AT FLOW SCALE• Consider an isolated bottleneck link and assume flows
arrive according to a Poisson process.• Assume further that all flows using the link receive an equal
share of bandwidth. • The number of flows in progress is then a random variable
which behaves like the number of customers in a so-called processor sharing queue. Revenir à l’autre document et développer M/G/1
• An interesting feature of this system is that, for any distribution of document size, average flow throughput is simply equal to the difference between link capacity and expected demand (measured by the product of arrival rate and mean document size). 181