La bande passante n’est pas la vitesse

La bande passante est le tuyau

La bande passante est le diamètre du tuyau : combien de bits passent par seconde dans les conditions du lien. La latence est le trajet : le temps qu’un paquet met pour atteindre l’autre extrémité et, pour un aller-retour, pour revenir. Ce sont deux mesures différentes, et l’une n’implique pas l’autre.

Un lien de 100 Mbps peut paraître lent en visioconférence, car l’appel n’a pas besoin de 100 Mbps. Il a besoin d’un aller-retour assez court pour converser, d’une gigue assez faible pour le tampon audio et d’une perte assez faible pour que le codec n’ait pas à masquer un trou. Le débit annoncé ne décrit rien de tout cela.

La bande passante compte pour les transferts massifs, la sauvegarde, l’envoi de vidéo et de nombreux appareils simultanés. Elle compte aussi pour la congestion qui produit latence et perte. Mais quand quelqu’un dit que le lien est lent, demandez quelle application et laquelle des quatre métriques compte pour elle.

La gigue et la perte décident de l’expérience

La gigue est la variation du délai d’un paquet à l’autre. Un flux peut avoir une bonne moyenne et arriver de façon irrégulière. Les médias temps réel embarquent un tampon pour absorber la variation ; lorsque la dispersion dépasse le tampon, l’audio se coupe ou la vidéo se fige.

Un chemin stable est plus simple à utiliser qu’un chemin dont le délai varie fortement. La moyenne peut sembler proche. Le chemin stable laisse l’application planifier ; celui qui oscille l’oblige à attendre la queue lente ou à jeter des paquets qu’elle ne peut pas utiliser.

La perte est le troisième signal. Les applications de données retransmettent, ce qui ajoute un aller-retour et réduit le débit. Les médias temps réel masquent le paquet manquant, ce qui se voit comme un défaut. Un taux de perte faible en moyenne peut se concentrer en rafales et nuire davantage que la moyenne ne le suggère.

Mesurez sur une fenêtre, aux deux extrémités

Mesurez aux deux extrémités et sur une fenêtre. Un ping isolé échantillonne un paquet à un instant ; un appel, un paiement ou une vidéo utilisent de nombreux paquets pendant des minutes. Relevez le minimum, la médiane, le p95 et la perte à l’heure de pointe, et conservez la route et la destination avec les chiffres.

Mesurez le chemin que l’application utilise. Un test de débit public mesure une autre destination et souvent une autre route. Un rapport de route qui ne donne que le débit ne peut pas expliquer un appel qui saccade. Associez le débit au RTT, à la gigue et à la perte, et séparez le segment local du segment international.

Indiquez la fenêtre, la source, la destination et l’heure. Un chiffre sans ces quatre éléments ne peut pas être comparé à un autre. L’explication de la connectivité avec la Chine montre comment le chemin se construit ; l’explication de l’itinérance montre pourquoi l’ancrage change la distance.

Ce que contient un rapport de route utile

Un rapport de route doit permettre de refaire le test. Notez l’adresse source, l’adresse de destination, la fenêtre temporelle, le nombre d’échantillons et l’outil ou la méthode. Un rapport qui ne donne que le RTT moyen ne peut être ni vérifié ni comparé.

Donnez la distribution, pas seulement la moyenne. La médiane décrit le paquet typique, le p95 décrit la queue lente et le maximum montre le pire cas. Pour une application temps réel, le p95 et la perte comptent plus que la moyenne.

Séparez les segments. Un segment d’accès local, un segment de transit international et un segment de destination échouent pour des raisons différentes et ont des propriétaires différents. Un seul chiffre de bout en bout cache quel segment corriger.

Conservez les échantillons bruts avec le résumé et indiquez la date. Une route change ; un rapport sans date devient une affirmation sur un réseau qui n’existe plus.