Mtrologie et Caractrisation de trafic

Mtrologie Caractrisation de trafic

Leila Azouz Saidane

Partie I
Mtrologie ou Science des mesures
Ntographie Groupe de travail Mtrologie http://www.inria.fr http://gt-metro.grenet.fr Didier Benza Luc Saccavini Philippe Owerzaski Chadi Baraket Khadija Ramah

Mtrologie
Dfinition : La mtrologie est la science de la mesure au sens le plus large. La mesure est l'opration qui consiste donner une valeur une observation.

Mtrologie dans lInternet

Introduction L'Internet a t cr comme un rseau simple, ouvert, flexible, o le seul service offert aux utilisateurs est le "routage au mieux" des paquets (en anglais Best Effort). Interconnexion des rseaux.

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 --KELVIN
5

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 dont measure it. We cannot build effective models or simulators if we dont measure Wide area network behavior is unpredictable Many applications have minimum performance requirements: Reliability, predictability, Network managers adjust systems to conditions.
6

Mtrologie dans lInternet

Motivation L'Internet a t cr sans infrastructure de mesure standard qui permet aux oprateurs et aux utilisateurs d'observer ce qui se passe et d'changer les rsultats entre eux. le cur de l'Internet fournit un service simple consistant en un routage au mieux des paquets
7

Mtrologie rseau ?
Objectif : savoir ce qui se passe sur le rseau En situation normale (tableaux de bord, historique) En cas dincident Sur mon site, chez mes prestataires, sur lInternet Comment ? Mesurer les paramtres cls du rseau Liens, quipements
8

Evolution
Trs forte augmentation des dbits Ethernet filaire : 100Mb/s (1995) 100Gb/s (2010) Ethernet sans fil : 11Mb/s (1999) 100Mb/s (2010) xDSL/cble : 1Mb/s (2000) 50Mb/s (2009) Arrive dIPv6 Nouvelles applications: (ex: tel/IP, ) Contractualisation plus prcise (SLA, QoS: dbit, dlai, taux de perte..)

Evolution
Consquences sur les technologies rseaux Apparition de nouveaux protocoles
Ex: SCTP( Stream Control Transmission Protocol) Ex: DCCP (Datagram Congestion Control Protocol)

Apparition de nouvelles versions de TCP (contrle de flux) Echelle de variations de dbit plus grande et plus rapide Mise en service de la QoS Consquence sur la mtrologie rseau La mtrologie doit tre tous les niveaux En espace : LAN, WAN, En technologies (Ethernet, IP, TCP, HTTP) Evolution des mtriques : nouvelles et plus prcises, mieux dfinies
10

Enjeux

QoS Architecture dInternet Dimensionnement des structures (routeurs, serveurs ) Modles dadministration Scurit Evaluation de performances Tarification

QoS

Dfinition :

garantir de bonnes conditions de transmission pour un trafic donn en terme de : Dbit Fiabilit (taux de perte des paquets) Dlais de transmission Gigue

Trafic cibl :

streaming, VoIP, temps rel

Mtrologie Internet

Trois Problmatiques :
Etre insensible au facteur dchelle Fournir une solution de bout en bout indpendamment des diffrents domaines traverss Sadapter la dynamicit des ressources du rseau et la variabilit du trafic

La mtrologie devra mesurer en continu la QoS offerte Le but de la mtrologie est dadapter les mcanismes de transmission aux conditions de trafic et du rseau

Mesures pour lutilisateur

Surveiller les performances vcues par une application:
Pourquoi le tlchargement de la page Web est si lent? Pourquoi l'interactivit dans ma conversation audio est mauvaise? Vrifier si le niveau du service reu rpond son besoin
Ai-je assez de bande passante? Ai-je obtenu le service promis par l'oprateur?

Mesures pour les oprateurs

Surveiller le niveau courant dune activit. Respecter les SLAs(Service Level Agreements). Detecter les pannes et les checs Ingnierie du rseau pour de meilleures performances. Planifier pour des capacits futures . Feedback aux clients.
15

Mesures pour les oprateurs

Caractrisation du trafic internet

Classification du trafic internet Dfinir :

Un niveau de service associ chaque classe (QoS) Une chelle de temps tudier (paquets, flots, sessions)

Modlisation du trafic
vnements caractristiques (pics, fluctuations)

Abstraction par un processus alatoire si possible

Dfinition des dcisions Traitements appliquer en fonction de l'vnement dtect

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

Mtrologie active
Principe: Gnration de trafic pour effectuer des mesures (taux de pertes, dlai, RTT) Exemples: ping: Connectivity, round-trip delay, loss. Traceroute: Connectivity, path, hop-delay. . Avantage : Le seul moyen actuel davoir des mesures orient utilisateur Inconvnient : ajout dun trafic supplmentaire dans le rseaux

21

Active measurement
Active tools send stimulus (packets) into the network and 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.

Mtrologie passive
Principe : Ecoute du trafic en divers points du rseau Traitement danalyse sur les traces obtenues Deux types danalyse : En-ligne Hors-ligne Avantage : pas dintrusion sur le rseau Inconvnient : Complexit danalyse
23

Mtrologie : quelques outils

Mesures passives Simple Network Management Protocol (abrg SNMP), en franais protocole simple de gestion de rseau : 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

Mtrologie : quelques outils

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

Example of passive tools

Router/switch traffic statistics: SNMP: Collects aggregate traffic stats from routers. Netflow: Collect aggregate flow stats from Cisco routers. Packet monitors: Tcpdump for Unix-based user hosts. Dedicated measurement systems: OC3MON, IPMON, etc. 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 to analyze 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

Format des Datagrammes IPv4

En-tte : partie fixe (20 Octets) + partie optionnelle variable Donnes : charge utile du datagramme

32 bits
4 Version Lg_ent 8 Type de service Drapeau Identification Dure de vie Protocole 16 24 Longueur totale Dep_fragment Total de contrle den-tte (checksum)

Adresse source Adresse destination Options (ventuelles) Donnes

30

Bourrage

Format des Datagrammes IP

Champs
Version

Description
Version du protocole: IPv4/IPv6 (permet de vrifier que la source, la destination et tous les routeurs traverss sont en accord sur le format du datagramme) Longueur de lentte en multiple de 32 bits: de 5(20 Oct) si pas doption 15 (60ot

Long
4 bits

Lg_ent Long. Totale Indentification Drapeaux Dp_fragment Dure de vie (TTL) Protocole

4 bits 16 bits 16 bits 3 bits 13 bits 8 bits

Longueur totale du datagramme en octets : entte+donnes (jusqu 216 octets) Numro de datagramme affect par la source. Indique quel datagramme appartient un fragment DF : Dont fragment , MF : More fragments et 1bit inutilis
Localisation (offset) : dplacement du fragment dans le datagramme (multp de 8oct)

Compteur utilis pour limiter la dure de vie des datagrammes : dcrment chaque routeur (traitement+file dattente), paquet dtruit quand passe 0 Indique par un numro quel protocole confier le contenu du datagramme (TCP ou UDP ou ICMP). Numros standards dfinis dans RFC 1060 Vrifie la validit de len-tte, doit tre recalcul chaque saut Bits 0 rajouts (si ncessaire) pour avoir une longueur dentte multiple de 32 bits car la longueur du champ options est variable

8 bits

Checksum Bourrage (Padding)

16 bits 04 octets 31

Format des Datagrammes IPv4

Version : 4 bits (si diffrent, paquet rejet, pas de message derreurs pour la source) IHL : 4 bits (Internet Header Length) longueur dentte 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 dentte avec des 0s Total length : 2 octets; longueur totale de ce datagramme en octets (entte+donnes); max=65635 octets. Protocol : 1 octet; protocole la destination (numros standard: RFC 1060); TCP, UDP, ICMP, Time to live: 1 octet; dcrment par chaque routeur. Sil atteint 0 le paquet est rejet. Le routeur dcrmente par au moins 1(plus si attente dans les files dattente); utilis 32 comme hop count ; permet dviter 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 @

Format des Datagrammes IPv4

Identification : 2 octets; affectation par source: Num. de squence des datagrammes (deux fragments du mme datagramme si Identification, @source, @destination, Protocole concident); problme de longueur DF: Dont Fragment; 1 bit; 0 pour fragmentation permise MF: 1 bit; si 0 le dernier fragment dun datagramme Offset: 13 bits; offset du fragment actuel (dplacement 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)= Prcdence (suppose des files dattente diffrentes; DiffServ) + les bits Delay, Throughput, Reliability, 0,0 (non utiliss). Header checksum: 2 octets; complment 1 de34 la somme

Format des Datagrammes IPv4

Type de service : prcise le mode de gestion du datagramme (8 bits)
F Informations pour les algorithmes de routage pouvant servir pour le choix de routes satisfaisant certains critres de QoS quand cela est possible. F Priorit : 0 (normal) 7 (supervision rseau) (3 bits) Champs souvent ignor, ncessite la prise en charge dalgorithmes de priorit au niveau des routeurs, suppose des files dattente diffrentes (DiffServ) F 3 drapeaux indiquant le type de service requis Dlai (D) : indique un besoin en courts dlais, Dbit(T) : dbit de transmission lev, Fiabilit (R) F 2 bits inutiliss 0 1 2 3 4 5 6 7

Priorit

Inutilis
35

Format des Datagrammes IPv4

Options indiques suivant le format TLV (Tag, Length, Value):
F Champs optionnels, longueur variable F Chaque type doption est cod sur un octet : Code option F Il est suivi dun octet prcisant la longueur + ensemble doctets de donnes associes loption 0 : 1 2 3 4 5 6 7 F Code option
Copie Classe doption Numro doption

Copie : si 1 : loption doit tre recopie dans tous les fragments du datagramme Classe doption : 0 : datagramme de contrle ou de supervision 2 : mise au point et mesure 36 1 et 3 rservs pour une utilisation future

Format des Datagrammes IPv4

F Numro doption : identificateur de loption. Exemples : 3 (classe option 0) : Option routage dfini par la source : spcifie la route prendre par le datagramme. Le champs code sera alors suivi par un champs doption de lg variable comportant la description de la route 7 (classe option 0) : Option Enregistrement de route : utilis pour enregistrer un itinraire, chaque routeur fournissant son adresse IP au datagramme. Le champs code sera alors suivi par un champs doption de lg variable comportant la description de la route 4 (classe option 2) : Option Horodatage dans Internet. Pour enregistrer lhorodatage le long dune route. Option Horodatage dans Internet avec Enregistrement de route

37

Format des Datagrammes IPv4

Option enregistrement de route
F La source initialise la longueur quelle suppose ncessaire. F Au niveau dun routeur intermdiaire, si pointeur est infrieur longueur , le routeur ajoute son adresse IP dans le dplacement indiqu par pointeur et incrmente pointeur de 4 octets, sinon il achemine le datagramme sans y insrer son adresse.

16

24 31

Code option(7)

Longueur

Pointeur

Premire adresse IP
Liste de routeurs associe loption enregistrement de Seconde adresse IP route

Utilis si option horodatage avec enregistreme nt de route (Code option =4)

38

ICMP : Internet Control Message Protocol

change de messages derreur et de supervision Rendre compte des problmes "routeurs"
Datagramme ne peut pas atteindre sa destination Manque de rserve de mmoire Datagramme dtruit 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 derreur causerait lui-mme une erreur : aucun message ICMP ne doit tre engendr propos de datagrammes contenant dj des messages ICMP.
Une douzaine de messages diffrents
39

ICMP Exemple

192.168.1.24

192.168.1.32

40

Format dun datagrame ICMP

Chaque message ICMP a un format propre. Ils commencent tous par 3 champs (entte) :
type (8 bits) code (8 bits) info. supplmentaire sur le type total de contrle (16 bits)

+ 32 bits utiliss ou non utiliss selon le type du message + lentte et les 64 premiers bits du datagramme ayant provoqu lerreur (englobant les info importantes des protocoles de plus haut niveau)

41

ICMP (quelques messages)

Type 0 3 4 de la 8 11

Signification rponse une demande dcho destination inaccessible limitation de production de la source (Si dbit source lev) demande dcho expiration du TTL

42

ICMP (quelques messages)

Dterminer si une destination est sur le rseau (ping)
Echo : type= 8requte; type=0 rponse ; Code = 0 Identifier/Sequence number (4 octets) : associer la requte et sa rponse Data : variable; copie dans la rponse type = 13 requte; 14 rponse Code = 0 Identifier/Sequence number (4 octets) : associer la requte et sa rponse Originate timestamp (4 octets): temps avant lmission de de la requte Receive timestamp (4 octets): : temps la rception de la requte Transmit timestamp (4 octets): : temps la transmission de la rponse

Echange de date (Timestamp)

Demande dune adresse rseau

type = 15 requte; 0 rponse Obsolete car remplac par BOOTP ou DHCP (Dynamic Host Configuration Protocol)
43

ICMP (quelques messages)

F Demande du masque de sous-rseau (RFC 950) type 17 requte; 18 rponse ; Code = 0 Identifier/Sequence number (4 octets) : identifier la requte et sa rponse Adress mask : 4 octets F Le rseau est en congestion ; la source doit diminuer son utilisation rseau type = 4; Code = 0 Entte IP + 64 bits du datagrame cause du problme F Redirect : routage

44

ICMP (quelques messages)

Message derreurs
type (1 octet) + code (1 octet)+ champ spcifique au type (4 octets)+ (entte + 64 premiers bits du datagrame cause du problme) Problme de paramtrage type = 12, code = 0 Pointer : 1 octet; pointeur au problme dans lentte TTL expir type = 11 Code = 0 : died in transit ; Code = 1 : died during reassembly Destination non joignable type = 3 Code = 0 : net unreachable ; Code = 1 : host unreachable ; Code = 2 : protocol unreachable ; Code = 3 : port unreachable
45

Refresh: ICMP

Le protocole UDP
User Datagram Protocol
Connectionless ; service end-to-end Sans contrle de flux Pas dacquittement (ack) Adressage travers des ports Dtection des erreurs au niveau de lentte (Checksum) optionnel.
Sorce port Length data Destination port Checksum UDP header

47

Le protocole TCP : Format de lentte dun segment

Transmission Control Protocol

numro de squence par octet fentre danticipation ajustable par le destinataire temporisation en attente dun ACK (contrle de rception et retransmission) Format de len-tte : 0
Port source Port destination Numro de squence (numro de squence du 1ier octet de donnes dans le flot) Numro dACK (numro du prochain octet attendu du flot et Ack jusqu ce n-1) Long. En - tte Rserv Checksum U A P R S F R C S S Y I GKHT N N Taille de la fentre Pointeur urgent

31

Options

Bourrage 48

Entte dun segment TCP (suite)

6 drapeaux dun bit chacun URG est positionn 1 si le pointeur durgence est en cours dutilisation (dcalage partir du n de squence courant indiquant o lon peut trouver les donnes urgentes)Evite dinterrompre les messages. ACK est positionn 1 pour valider le n dAck. Sil est 0; le champ n dAck est ignor. PSH (PuSH: donnes pousses) est positionn 1 pour demander au destinataire de remettre les donnes lapplication concerne ds leur arrive RST est positionn 1 pour rinitialiser 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) nest pas utilis SYN=1 et ACK=1 Demande de connexion accepte FIN est positionn 1 pour indiquer que lmetteur na plus de donnes transmettre (demander la libration de la connexion). Il peut continuer recevoir des donnes. Les segments SYN et FIN ont leurs propres n de squenceordre de traitement

49

Le protocole TCP (suite)

Contrle de la congestion Problme :

Le dbit de lmetteur est suprieur soit la capacit du rseau soit la capacit du rcepteur; ce qui provoque la perte de paquets, do lapparition dune congestion.

50

Le protocole TCP (suite)

Contrle de congestion
Solutions :

La dtection se base sur le fait que : si un paquet est perdu, ceci est probablement d un problme de congestion plutt qu une erreur de transmission (le taux derreur sur les supports de transmission actuels est considr faible).

Le rcepteur peut viter la congestion en spcifiant une taille de la fentre en fonction de la taille de la mmoire libre Reste rsoudre la congestion due au rseau : algorithme du dmarrage lent Slow Start. Cet algorithme utilise une seconde fentre dite de congestion. utilise la fentre de congestion Fentre_autorise = min (indication_rception, fentre_congestion)
51

TCP

Le protocole TCP Tahoe

Contrle de la fentre de congestion
44 40
Fentre de congestion (Ko)

Seuil dvitement

36 32 28 24 20 16 12 8 4
Incrmentation chaque rception des acks (Si mission de 8 seg. et rception des ack correspondants, on passe 16)
Evitement de congestion (Incremental Increase) : On naugmente la fentre de 1 que si tous les segments de la fentre sont ack.

Expiration du temporisateur ou ICMP/Source Quench remont TCP Le seuil est ramen la moiti de la taille de la fentre atteinte

Taille max. dun segment (1 Ko) 0 =>Ne perturbe pas Considrablement les connexions existantes

10

12

14

16

18

20

22

24
52

Temps

Le protocole TCP (Reno)

Contrle de la fentre de congestion (Reno)

53

Refresh: TCP congestion control

Slow start threshold Receiver window

TCP window (W )

Updated slow start threshold

Congestion

Slow Start

Congestion

ance Avoid tion onges C

CA

SS

Time

Loss detection via duplicate ACKs

Loss detection via Timeout

Le protocole TCP (suite)

Contrle de congestion : les solutions Le dmarrage lent (Slow Start) Multiplicative decrease + Incremental Increase
En cas de perte dun segment, il faut rduire la fentre de congestion dun facteur multiplicatif (de moiti) Quand lmission de trafic commence sur une nouvelle connexion ou reprend aprs une priode de congestion, il faut commencer par une fentre de congestion limite un seul segment et incrmenter la fentre de congestion dun segment la fois, chaque fois quun accus de rception est reu.

La phase dvitement de congestion (congestion avoidance)

Objectif : ralentir le rythme daugmentation de la fentre pour viter une nouvelle congestion

55

What to do with tcpdump data? TCPTRACE

A well known powerful tool that uses the measurements collected by tcpdump to analyze 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 of parameters

a->b: 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: 16 15 13 450 1 450 0 0 1460 bytes 450 bytes 450 bytes 449 bytes 40544 bytes 5840 bytes 0 times 23174 bytes 450 bytes 1 pkts b->a: total packets: ack pkts sent: pure acks sent: unique bytes sent: actual data pkts: actual data bytes: rexmt data pkts: rexmt data bytes: 0 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: 1 pkts 16 16 2 18182 13 18182 0 1460 bytes 1448 bytes 806 bytes 1398 bytes 33304 bytes 33304 bytes 0 times 33304 bytes 1448 bytes

An example of Tcptrace output :list of parameters

a->b: throughput: RTT samples: RTT min: RTT max: RTT avg: 1113 Bps 48 74.1 ms 204.0 ms 108.6 ms b->a: throughput: RTT samples: RTT min: RTT max: RTT avg: 44957 Bps 47 0.1 ms 38.8 ms 8.1 ms

duplicate acks: triple dupacks: max # retrans: max owin: min non-zero owin: avg owin: wavg owin:

0 0 1 451 bytes 1 bytes 31 bytes 113 bytes

duplicate acks: triple dupacks: max # retrans: max owin: min non-zero owin: avg owin: wavg owin:

0 0 0 1449 bytes 1 bytes 1213 bytes 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

Time Line Graph

Problem: We cannot know exactly the time at which packets arrive and leave the second peer, since measurements are only taken at one peer. Heuristic: Assume symmetric paths and use half the round-trip time.
52

Evolution des mtriques

Evolution de lInternet Evolution des mtriques nouvelles plus prcises mieux dfinies

66

Les mtriques IPPM: IP Performance Metrics

67

Un cas dcole RTT

Mesure du RTT entre deux machines A et B avec ping Ne donne pas les asymtries : de routage, de queuing Sensibilit au traitement spcifique du protocole ICMP Sensibilit aux OS, leur charge Approche IPPM : RTT = OWD1 + OWD2 OWD1 = dlai de A vers B OWD2 = dlai de B vers A OWD >= temps de propagation + temps de srialisation Mesures linterface rseau Horloges synchronises par GPS Mesures ponctuelles, statistiques (chantillonnage dfini) Mesure indirecte de la charge des liens

68

Les mtriques IPPM: IP Performance Metrics

Il s'agit d'un travail (ralis par le groupe IETF du mme nom) qui dcrit trs prcisment la terminologie mais aussi les mthodes et les units utiliser pour la dfinition de mtriques RFC 2330

69

IPPM = IP Performance Metrics

Importants travaux lIETF autour des mtriques Exemples de mtriques IPPM dfinies 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 mtrique rseau ?

Une mtrique est une caractristique du comportement d'un rseau. Elle est exprime dans une unit standard et permet de faire des comparaisons
Dans le temps : Aprs un changement de configuration Aprs une panne, un changement de route Dans l'espace Entre 1 poste et deux autres postes, afin de comparer des situations Entre deux rseaux Dont les topologies sont proches mais les performances diffrentes
71

Limitations physiques
Certaines mtriques sont lies des limites physiques Ex: La vitesse de la lumire dans le vide est une limite basse absolue : V = 299 792 458 m/s
Il ne sert rien d'esprer mieux
72

Limitations au niveau des quipements

Les quipements traverss imposent leurs propres limitations

Files d'attente Charge sur des liens Dcisions de routage Tous les paquets d'un mme flux n'empruntent pas le mme 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 mtriques 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) Dlai 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 insrer 1500 octets sur une ligne de 1Gbits/sec il faut : 1500x8 / 109 = 0,000012 s = 12 s Pour insrer 1500 octets sur une ligne de 10Mbits/sec il faut: 1500x8 / 107 = 0,0012 s = 1,2 ms Temps de mise en paquet/Packetization delay Temps pris par une application pour remplir un paquet IP Il s'agit d'un dlai variable et configurable Autres dlais : Codec, Queuing,
74

Les mtriques IPPM: les critres respecter

Les mtriques doivent tre concrtes et bien dfinies Les rsultats d'une mesure avec une mtrique donne doivent tre reproductibles : une mesure effectue de multiples fois dans des conditions identiques doit donner des rsultats identiques Les mtriques doivent tre utiles, pour les fournisseurs d'accs et les utilisateurs afin qu'ils comprennent les performances qu'ils peroivent ou fournissent
75

Les mtriques IPPM

Une mtrique IPPM est une quantit relative la performance ou la fiabilit d'Internet qui a t spcifie avec beaucoup d'attention

Les units de mesures utilises sont celles du Systme International d'Units

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 ts dfinies sont des mesures directes, par injection de trafic par ex mesure du RTD d'un paquet IP d'une taille donne sur un chemin donn une heure donne
76

 Host/Hte : 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 htes ; a inclut les liaisons loues ou Ethernet, les nuages Frame Relay, etc. Router/Routeur : un hte qui facilite la communication au niveau 3 entre des htes en acheminant des paquets IP Path/Chemin : une squence de la forme <h0, l1, h1, ..., ln, hn> o - n 0, - Chaque hi est un hte et chaque li est un lien entre hi-1 et hi, - Chacun des h1...hn-1 est un routeur, - Une paire <li, hi> est nomme un hop/saut. - Un chemin est un concept unidirectionnel.
77

Les mtriques IPPM : vocabulaire

Les mtriques IPPM : vocabulaire

Cloud/Nuage : un graphe non orient dont les sommets sont des routeurs et les artes des liens qui connectent des paires de routeurs Subpath/sous-chemin : Pour un chemin donn, un sous-chemin est n'importe quelle sous-squence d'un chemin qui est elle-mme un chemin. (Dbute et se termine par un hte).

<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 mtriques IPPM : vocabulaire

Exchange/Un point d'change : un cas particulier de lien. Un exchange interconnecte soit - Un hte un nuage - Un nuage un autre nuage

Cloud subpath/Sous-chemin de nuage : le souschemin d'un chemin dont tous les routeurs appartiennent un nuage

79

L'incertitude temporelle
Synchronisation entre deux horloges IPPM Clock Offset : dcalage entre une horloge et le temps UTC Exactitude : par rapport une norme IPPM Accuracy : plus l'offset est proche de zro, plus l'horloge est prcise Rsolution : la valeur minimale de temps qu'une horloge sait mesurer IPPM Resolution : la plus petite unit de temps par laquelle une horloge est mise jour Ecart de frquence : diffrence de frquence entre deux horloges IPPM Skew : diffrence de frquence entre l'horloge et le temps UTC Variation de lcart : variation de lcart de frquence IPPM Drift : variation du skew au cours du temps
80

Les mtriques IPPM : Wire time

Le RFC IPPM dfinit la notion de wire time / temps filaire de la faon suivante : P est un paquet H est un hte L est l'endroit ou H observe un lien Internet * Le temps d'arrive 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 dpart filaire de P de H est le premier instant T ou tous les bits de P sont partis en L
81

Les mtriques IPPM : Wire time

La mesure du wire time se fait au niveau d'un hte cela veut dire que le RFC ne prvoit pas de mesures via des boitiers spcialiss en des points d'un lien ou un hte ne pourrait pas tre. Le RFC prvoit des difficults avec la notion de wire time en cas de fragmentation : les fragments sont des paquets IP lgitimes avec des wire time alors que le paquet agrg n'en a pas Il faut dire qu'auparavant la notion de wire time tait couramment utilise mais jamais dfinie (premier ou dernier bit, l'arrive, au dpart ?) ce qui induisait des erreurs de l'ordre des dlais de srialisation et de propagation. La norme dfinie limine le dlai de srialisation de la mesure.
82

Les mtriques IPPM : types de mtriques

Singleton
Mtrique atomique

* par exemple temps de transit sens unique un instant donn pour des paquets de taille N Sample (chantillon)
Mtrique drive d'une mtrique de type singleton, en prenant plusieurs instances temporelles ou spatiales.

* Par exemple, un ensemble de temps de transit sens unique pour des instants rpartis selon une loi de Poisson dans un intervalle de temps donn Statistical
Mtrique calcule partir des valeurs des singletons pris dans un sample.

* Par exemple, la valeur moyenne du temps de transit sur une priode de temps donne, calcule en faisant la moyenne du sample prcdent
83

 La collecte de sample sert surtout observer les variations d'une mtrique donne. 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'arrive des paquets ne peut pas tre prdite Lchantillonnage n'est pas biais ( impartial), mme si la mesure affecte ltat du rseau La mesure n'induit pas de synchronisation Elle peut tre utilise pour collecter des mesures sur des comportements cycliques
84

Les mtriques IPPM : collecte dchantillons

Les mtriques IPPM : les mtriques dfinies

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 mtriques IPPM : EDF

EDF = Empirical distribution function EDF est la fonction F(x) qui indique la proportion de mesures dont la valeur est infrieure ou gale x Si on a l'chantillon des 6 mesures suivantes : -2, 7, 7, 4, 18, -5 Alors :

F(-8) = 0 F(-5) = 1/6 F(-5.0001) = 0 F(-4.999) = 1/6 F(7) = 5/6 F(18) = 1 F(239) = 1.

Les mtriques IPPM : percentile

Xth percentile = plus petite valeur p de l'chantillon telle que F(p) >= X% Exemple : -2, 7, 7, 4, 18, -5 Alors :

50th percentile = 4 F(4) = 3/6 = 50% 25th percentile = -2 F(-5) = 1/6 < 25% et F(-2) = 2/6 >= 25% 100th percentile = 18 0th percentile is

Les mtriques IPPM : Type-P

Introduction de la notion du Type-P La plupart les mtriques d'Internet sont dpendantes du type de paquet utilis (protocole, taille, ports src/dst) Quand une mtrique dpend du type de paquet utilis, son nom doit contenir l'expression Type-P pour la rendre gnrique Une mtrique gnrique n'est pas directement utilisable Pour faire une mesure, il faut d'abord spcifier plus prcisment le type de paquet qui sera utilis : gnrique spcifique type-P-metric TCP-src1550-dst80-size800-metric

Les mtriques
Connectivity
One-way Delay

Network Capacity

One-way Packet Loss

IPPM NMWG

One-way Packet Duplication

Delay Variation

Packet Reordering Bulk Transfer Capacity

CiRen 32 Performances Rseau Mtriques IPPM D. Benza

Les mtriques IPPM : les mtriques dfinies

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 mtriques IPPM :les RFC compagnons

A Framework for Defining Empirical Bulk Transfer Capacity Metrics : RFC 3148 Network performance measurement for periodic streams : RFC 3432 A One-way Active Measurement Protocol Requirements : RFC 3763

IP Performance Metrics (IPPM) metrics registry : RFC 4148

A One-way Active Measurement Protocol (OWAMP) : RFC 4656

Les mtriques IPPM : Autres mtriques (certaines en cours)

Defining Network Capacity (draft-ietf-ippm-bw-capacity-05 1/12/2007) Two-way Active Measurement Protocol (TWAMP) (draft-ietf-ippmtwamp-04 11/2007) IP Performance Metrics for spatial and multicast (draft-ietfippm-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-frameworkcompagg-04 8/1/2007) One-Way Packet Duplication Metric for IPPM (draft-ietf-ippmduplicate-02.txt 7/2/2008)

Les mtriques IPPM : Connectivit

La mesure dont l'utilit est la plus vidente : est-ce qu'un paquet partant d'une machine A est reu par la machine B ? Mais quand on y rflchit bien, cette notion n'est pas si simple dcrire que a :
Parle-t-on de connectivit instantane ? De connectivit sur une priode de temps Unidirectionnelle ou bi-directionnelle ? Pour quel type de paquets ?

Les mtriques IPPM : Connectivit

Type-P-Instantaneous-Unidirectional-Connectivity(Src, Dst, T) = Boolen
Src et Dst ont une connectivit sens unique instantane 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) = Boolen

A1 et A2 ont une connectivit bi-directionnelle instantane de type-P l'instant T si un paquet de type-P transmis de A1 l'instant T arrive A2 et 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 mtriques IPPM : Connectivit

Type-P-Interval-Unidirectional-Connectivity(Src, Dst, T, dT)= Boolen
Singleton

Type-P-Interval-Bidirectional-Connectivity(A1, A2, T, dT) = Boolen

Singleton

Pour les deux mtriques ci-dessus il suffit que la mtrique instantane correspondante soit vraie pour un seul instant dans l'intervalle [T, T+dT] pour que la mtrique soit vraie

Les mtriques IPPM : Connectivit

Type-P1-P2-Interval-Temporal-Connectivity(Src, Dst, T, dT) = Boolen
Sample Pour N instants T1 rpartis 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 instantane de type-P1 avec Dst l'instant T1 Dst a une connectivit unidirectionnelle instantane 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 et Dst dans l'intervalle [T, dT]

Les Mtriques IPPM : OWD

Dfinition d'un Type-P-One-Way-Delay gnrique
Le temps de transit entre deux machines peut varier en fonction du type de paquets Par exemple, un protocole considr comme moins prioritaire que TCP par les routeurs, est plus susceptible d'tre retard en file d'attente.

Le temps de transit impacte normment les applications temps-rel La borne infrieure du One-Way Delay est la somme des temps de propagation et de srialisation le long du chemin Les valeurs de cette mtrique au-dessus de la borne infrieure donnent une indication de la charge du chemin

Le calcul du OWD ncessite une grande prcision dans la synchronisation des horloges

Les Mtriques IPPM : OWD

Le OWD donne une indication plus fine que le Round Trip Delay
Routage asymtrique

Il peut y avoir du queuing asymtrique (charge des liens diffrentes dans un sens et dans l'autre)
La performance d'une application peut tre impacte par le temps de transit dans un sens, pas par celui dans lautre

Les Mtriques IPPM : OWD

Type-P-One-way-Delay (Src, Dst, T) = dT
T = wire time mission T+dT = wire time rception

Singleton Si le paquet est dupliqu sur le chemin, dT est calcul au wire time de l'arrive du premier paquet

Si le paquet est fragment et non rassembl, il est estim perdu

Une synchronisation GPS est souhaitable pour calculer cette mtrique

Les Mtriques IPPM : OWD

Type-P-One-way-Delay-Poisson-Stream(Src, Dst, T0, Tf, ({T0, dT0}, {T1, dT1}, ..., {Tf, dTf})
Sample

)=

T0, T1, ... Tf : gnrs selon une loi de Poisson TN-TN-1 = en moyenne 1/

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

39

Les Mtriques IPPM : Round-trip Delay

Type-P-Round-trip-Delay(Src, Dst, T) = dT
T = wire time mission du paquet au dpart de Src T+dT = wire time rception 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%

41

Les Mtriques IPPM : One-way Packet Loss

La mtrique One-way Packet Loss est plus prcise que le Round Trip Packet Loss, le chemin aller n'est pas forcment le mme que le chemin retour Certaines applications sont plus sensibles aux pertes de paquets dans un sens que dans l'autre, les transferts de fichiers, par exemple :
Donnes dans un sens, gros volumes de donnes ACK dans l'autre sens, quelques paquets seulement

Queuing asymtrique

42

Les Mtriques 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 : gnrs 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
CiRen 32 Performances Rseau Mtriques IPPM D. Benza 43

Les Mtriques IPPM : Delay Variation

Type-P-One-way-ipdv(Stream(Src, Dst, I1, I2, T2 ), L, F) = ddT, T1,

F : fonction de slection de deux paquets mis T1 et T2

Paquets conscutifs Dlai min et dlai max dans l'intervalle Paquets envoys des indices donns etc

L : longueur des paquets mis Si dT1 est le OWD(Src, Dst, T1) et dT2 = OWD(Src, Dst, T2) alors ddT = dT2 dT1 Singleton

45

Les Mtriques 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%) = mdiane 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, le paquet avec le OWDmax et le paquet avec le OWDmin Type-P-One-way-ipdv-jitter(Stream(Src, Dst, T0, Tf, Statistical L'estimation du jitter , L)) , L))

e( jn)=ipdvn

46

IPPM : Rordonnancement de paquets

Les paquets peuvent arriver dans un ordre diffrent de l'ordre d'mission Par exemple :
Quand les paquets d'un mme flux empruntent des chemins avec des dures diffrentes d'acheminement des paquets (load balancing, par ex) Retransmission par un protocole de niveau 2 Algorithme de gestion de files rordonnanant les paquets ..

48

IPPM : Rordonnancement de paquets

Type-P-Reordered(Src, Dst, SrcTime, s, NextExp) = Boolen
Singleton SrcTime : Temps d'mission du paquet s : numro de squence NextExp : Le numro de squence attendu

Type-P-Reordered-Ratio-Stream(Src, Dst, T0, Tf, K, L) = R

T0, Tf temps de dbut et de fin
dT = temps de transit max (au-del de dT, le paquet est dclar perdu) K le nombre de paquets envoys de Src L, le nombre de paquets reus parmi K L <= K R = le ratio du nombre de paquets rordonnancs par rapport au nombre de paquets reus :
R= Count(Type-P-Reordered=True) L

49

IPPM : Rordonnancement de paquets

Type-P-Packet-Reordering-Extent-Stream(Src, Dst, T0, Tf, K, L) = { ei, ... ej }
Les paquets sont numrots l'mission 1..K ei est la distance qui spare i de l'emplacement qu'il aurait normalement du occuper son arrive Type-P-Packet-Late-Time-Stream(Src, Dst, T0, Tf, K, L) = {lTi, ... lTj}

On utilise l'horloge de la destination Le numro de squence de dpart du paquet arriv en position i, est not s[i]. Pour tous les paquets rordonnancs lTs[i] = Retard du paquet s[i]

IPPM : Rordonnancement de paquets 6/11

Type-P-Packet-Byte-Offset-Stream(Src, Dst, T0, Tf, K, L) = {bOi, ... bOj}
Dcalage en nombre d'octets du paquet s[i] par rapport la position qu'il aurait du occuper

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 discontinuits correspondant des paquets rordonns

IPPM : Rordonnancement 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 mtriques un reordering-free run est une squence de paquets conscutifs sans rordonnancement 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 carrs des longueurs de run

IPPM : Rordonnancement de paquets

a % de paquets dans l'ordre = 100 p

La longueur moyenne des runs sans rordonnancement :

a x

x, le nombre de run a, le compteur de paquets dans l'ordre. p, le nombre de paquets q, la somme des carrs des longueurs de run

IPPM : Rordonnancement de paquets

q donne une ide de la variation autour de la moyenne :

q a = qx a a x

x, le nombre de run a, le compteur de paquets dans l'ordre. p, le nombre de paquets q, la somme des carrs des longueurs de run

Mtriques IPPM vs NMWG

NMWG = Network Monitoring Working Group de l'Open Grid Forum, cherche dvelopper un dictionnaire commun de mtriques

Availability Capacity Utilization Available Bandwidth Achievable Bandwidth

One Way Delay Jitter Round Trip Delay One Way Loss Roundtrip Loss One-Way Reordering

Mtriques IPPM vs NMWG

NMWG
One-Way-Delay RoundTripDelay One-WayandRoundTripLoss+Losspattern
(NMWG)(IPPM)

IPPM

Availability Capacity

Connectivity Network Capacity

Utilization
AvailableBW AchievableBW Jitter

Pasdquivalent
Pasdquivalent BulkTransfercapacity IPDelayVariation & Jittercalcul

Exprimentations et Rsultats

Quantit totale de donnes par application sur une plaque ADSL de France Tlcom

Exprimentations et Rsultats

Rpartition du dbit par application en octets/ssur une plaque ADSL de France Tlcom

Caractrisation du trafic internet

Classification du trafic internet

Dfinir :
Une caractristique d'agrgation (type de protocole, taille, etc...) Un niveau de service associ chaque classe (QoS) Une chelle de temps tudier (paquets, flots, sessions)

Caractrisation du trafic internet

Modlisation du trafic
vnement caractristiques (pics, fluctuations) Abstraction par un processus alatoire si possible

Dfinition des dcisions

Traitements appliquer en fonction de l'vnement dtect

Exprimentations et Rsultats

Classification admise:
Deux principaux types de trafic :
Streaming : contrainte de dbit lastique : pas de contraintes

Remarque :
Trafic de type lastique actuellement largement majoritaire ( 90 %)

Exprimentations et Rsultats

Analyse du trafic

Trafic particulirement instable

Proprit d'auto-similarit Dpendance long terme

Causes
TCP: dpendances induites :
par les acquittements Par les mcanismes de slow start et congestion avoidance

Transfert de Flot de gros paquets sur des dures importantes

Exprimentations et Rsultats

Analyse du trafic

Comparaison entre les oscillations observables dans un trafic Internet et un trafic Poissonnien

Exprimentations et Rsultats

Analyse du trafic

Trafic Internet caractris par une prsence forte de TCP trafic complexe et non prvisible

Partie II
Caractrisation de Trafic
Bibliographie James Roberts Philippe Robert Franois Bachelli Thomas Bonald .
123

Caractrisation de trafic
Traffic engineering Role: 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 used to 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

Quality of service requirements

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

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 quasiinstantaneously (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

Caractrisation 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

Stream traffic: Arrival rate

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

TRAFFIC VARIATIONS AND THE NOTION 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

Stream traffic: Traffic demand

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: Duration

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

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

Exponential vs Pareto : Probability Density Function

139

Exponential vs Pareto : Cumulative Distribution Function

140

 In mathematics, a self-similar object is exactly or approximately similar to a part of itself L'autosimilarit est le caractre d'un objet dans lequel on peut trouver des similarits en l'observant diffrentes chelles.

Self similarity : Auto similarit

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

Elastic traffic
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: 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

 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.

Elastic traffic: Distribution of object sizes

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

 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 agregation: Capacity overbooking

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.
network capacity

Realized performance

traffic demand
161

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 generally has 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-toend 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

Packet Scale Performance

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

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 lautre document et dvelopper 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 181 and mean document size).