Métrologie et Caractérisation de trafic

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•…

http://gt-metro.grenet.fr/

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


– 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


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


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


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


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


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


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


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


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)


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


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 ?


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


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


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


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


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


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


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


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


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


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


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


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é


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 %)


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


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



• 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


• 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

http://en.wikipedia.org/wiki/File:Exponential_pdf.svg

140

Exponential vs Pareto :Cumulative Distribution Function

http://en.wikipedia.org/wiki/File:Exponential_cdf.svg

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

Métrologie et Caractérisation de trafic

Documents