Les métriques de l’étude

Le tableau 3.1 indique les métriques que l’on va étudier. Chaque métrique étudiée sera mise en relation avec une des questions posées précédemment.

Métriques de supervision

La supervision du trafic consiste à analyser le flux général de paquets qui transite au sein d’un équipement comme un routeur ou un commutateur. On parle d’étude macro-scopique, telle qu’indiquée dans le rapport [Owezarski2003-1]. Les informations analy-sées par la supervision sont généralement les informations analyanaly-sées par un adminis-trateur Réseau ou encore un FAI. En réponse aux questions sur la supervision, nous avons sélectionné dans un premier temps l’identification des protocoles de transport. Le champ protocole de l’en-tête IP indique le protocole de niveau suivant utilisé dans la partie des données du datagramme Internet [RFC760]. Les valeurs des différents proto-coles sont spécifiées en référence [RFC3232, IANA-port].

TABLE3.1 – Les métriques de métrologie passive.

Métriques En-tête Champs

Supervision du trafic

Caractérisation des destinations

IP ^Adresses sources et destinations Protocole de transport employé Protocole

Service utilisé TCP Numéro de port Performance protocolaire Performance de TCP

Événement de congestion ECN/NS

+ CWR, Numéro de séquence RTT Timestamp Pertes Numéro de séquence dé-séquencements Retransmissions Débits binaires Écoulé Timestamp, Numéro de séquence, fenêtre Descendant Montant Utile Caractérisation des flots Débit Durée Timestamp Longueur Nombre de paquets échangés

Nous avons vu précédemment que les services évoluent dans le temps et selon les débits [Zheleva2015]. L’analyse du champ numéro de port de l’en-tête TCP aide à l’identi-fication du Service utilisé. Chaque numéro de port est associé à un service précis défini dans le [RFC776].

En règle générale, le trafic Internet est divisé en trois catégories en fonction de la destination par rapport à la source. C’est le groupe de travail 802 de l’IETF qui est en charge des caractérisations.

— Local Area Network (LAN) : « Un réseau de données destiné à desservir une zone de quelques kilomètres carrés ou moins. Parce que le réseau est connu pour ne couvrir qu’une petite zone, des optimisations peuvent être faites dans les protocoles de signal de réseau qui permettent des débits de données jusqu’à 100 Mbit/s. » [RFC1983].

— Metropolitan Area Network (MAN) : « Un réseau de données destiné à desservir une zone proche de celle d’une grande ville. Ces réseaux sont mis en œuvre par des techniques innovantes, comme le passage de câbles à fibres optiques dans les tun-nels du métro. » [RFC1983]

— Wide Area Network (WAN) : « Un réseau, généralement construit avec des lignes séries, qui couvrent une large zone géographique. » [RFC1983]

La répartition des adresses IP de destination va permettre d’identifier le pays où se si-tue l’information. Cette information peut permettre de connaître la pertinence du lieu d’hébergement de l’information par rapport au service et à l’application utilisée. Nous utilisons pour cela la base de données associée à l’outil rTraceroute, outil d’analyse gra-phique des traces présenté dans la section 2.2.2. Dans le cas où une adresse IP n’est pas

répertoriée dans notre base de données, l’information sera extraite de la base de données de RIPE NCC, avec l’outil rgeoloc [LanYanFock2015].

Métriques de performance

Le groupe de travail IPPM de l’IETF a défini dans différents documents des métriques de bases, comme la mesure de connectivité [RFC2678], le délai unidirectionnel [RFC2679], le taux de perte unidirectionnel [RFC2680]. Ces deux dernières métriques sont également définies dans le sens aller-retour avec le [RFC2681].

Nous avons comme objectif la comparaison du débit théorique et le débit mesuré. Le calcul du débit mesuré par TCP se fait à travers 3 métriques : le RTT, la taille de la fe-nêtre d’émission et la probabilité de perte de paquets. Le RTT est le délai entre la mise du premier bit de la question sur le câble et la réception du dernier bit de la réponse [RFC2681]. Il est calculé par la différence de temps entre l’émission du paquet et la ré-ception de l’ACK correspondant. Si le RTT est trop important, TCP peut considérer un paquet comme perdu.

Une perte est définie comme « l’émission d’un paquet par la source mais non reçu par la destination » [RFC2680]. Si le paquet est perdu, alors TCP va réduire la fenêtre d’émission.

La fenêtre d’émissionest calculée à partir du champ Fenêtre des segments TCP. Ce champ est défini dans le [RFC6528] comme le nombre d’octets de données commençant par celui indiqué dans le champ d’accusé de réception que l’expéditeur de ce segment est prêt à accepter.

À l’aide de la formule, indiquée par l’équation 3.1, il est possible de calculer le débit mesuré par TCP. Debit = F enetre RT T √ P robabilite perte (3.1)

Les débits mesurés pourront être classés selon qu’ils soient montants, descendants, confondus ou utiles. Cette différenciation s’explique par le fait que la comparaison avec le débit théorique est montant et descendant. Le débit écoulé (throughput) correspond « au nombre de paquets ou de bits par seconde » [RFC6201]. Le débit utile (goodput) corres-pond « au nombre de paquets ou de bits utiles (non retransmis) par seconde. »[RFC5166] L’étude des performances du protocole TCP passe dans un premier temps par l’étude des pertes et des retransmissions.

Une retransmission est définie par le [RFC6298] comme étant le « segment le plus ancien qui n’a pas été acquitté par le récepteur TCP. » Pour obtenir le nombre de re-transmissions, on regarde les numéros de séquences des segments TCP. Si dans un flot IP, un numéro de séquence apparaît plusieurs fois, alors cela implique la retransmission du paquet. Les retransmissions seront séparées selon la raison de la retransmission (fast retransmit) ou retransmissions abusives (spurious retransmit).

Le [RFC5681] explique le phénomène pouvant provoquer une retransmission par le mé-canisme de fast retransmit. La retransmission d’un paquet due au mémé-canisme de fast re-transmit est calculée en fonction du nombre d’acquittements dupliqués et de la différence temporelle entre le paquet de données observées et le précédent acquittement.

Les paquets spurious retransmit sont des paquets subissant des fausses retransmissions. Si le numéro de séquence du paquet attendu est inférieur ou égal au numéro d’acquittement du précédent ACK, alors le paquet observé est un paquet retransmis abusivement.

Lorsque le paquet est ré-émis, il va se produire du dé-séquencement. Le dé-séquencement se définit dans le [RFC6248] : « L’arrivée ordonnée est une propriété que l’on trouve dans les paquets qui transitent par leur chemin, où le numéro de séquence des paquets aug-mente avec chaque nouvelle arrivée et il n’y a pas de régression. La détection du ré-ordonnancement à destination est basée sur l’ordre d’arrivée des paquets par rapport à une valeur de référence non inversée. »

Les paquets retransmis peuvent également servir à l’identification des événements de congestion. Pour identifier ces événements, deux techniques peuvent être mises en place.

La première consiste a étudier la présence des drapeaux ECN et Congestion Window Re-duce (CWR) dans les en-têtes des paquets TCP [RFC8311].

La seconde technique se propose d’étudier les variations de la fenêtre d’émission de TCP. Cette étude doit être couplée avec l’analyse des phénomènes de pertes et de retransmis-sion autour de cet événement.

Dans la section 1.1.2, nous avons constaté que la capacité de stockage d’un lien est problématique pour les flots courts. Afin de poursuivre l’étude de l’impact de la capa-cité de stockage des liens de l’Internet réunionnais, nous allons caractériser les flux. La caractérisation d’un flotpeut se faire selon la durée (temps écoulé entre le premier et le dernier paquet), la taille (nombre de paquets échangés) et le ratio entre la durée et la taille. D’après les travaux réalisés par [Lan2006], un flot se caractérise par la définition suivante : « a flow is an unidirectional series of IP packets with same source and destination addresses, port numbers and protocol numbers. » Ce qui peut se traduire par la définition sui-vante : « un flot est une série de paquets IP avec le même tuple suivant (adresse IP source, port source, adresse IP destination, port destination, protocole IP) ». Dans ce cas précis, une connexion TCP de par son coté bi-directionnel est constituée de deux flots.