Mon blog

La capacité d'un accès Internet est un critère de choix important pour l'utilisateur et c'est même en général le seul qui est mis en avant dans la publicité (« choisissez la fibre qui fonce à 100 Mb/s »). Peut-on la mesurer sérieusement et objectivement ? Ce RFC explore la question, sans donner encore de réponse définitive.

La capacité est définie dans le RFC 5136. Notre nouveau RFC parle de rate et pas de capacity mais la différence est subtile (je vous laisse la découvrir dans le RFC si vous êtes intéressé). En revanche, il faut se méfier de termes flous et souvent utilisés de manière erronée comme « bande passante » ou « débit ». Ce qui intéresse M. Michu (ou, plus exactement, sa fille qui veut télécharger les quatre premiers épisodes de la saison 5 le plus vite possible), c'est bien la capacité de son accès Internet (cf. RFC 6703). Comme c'est un argument commercial essentiel, bien des gens souhaiteraient la mesurer, qu'ils soient simples citoyens, associations de défense des consommateurs ou bien régulateurs des télécoms. C'est ainsi que l'ARCEP a un tel programme de mesure et que l'Union européenne en a lancé un à travers les sondes SamKnows, qui a donné lieu à un excellent rapport, montrant bien les différences entre les proclamations commerciales et la réalité.

Le groupe de travail IPPM de l'IETF travaille depuis longtemps à normaliser les mesures de performance (qui sont souvent floues et approximatives, permettant ainsi toutes les manipulations). Avec la normalisation de la mesure, on pourrait envisager des comparaisons sérieuses entre les offres des FAI. Ce RFC 7497 ne propose pas encore une telle normalisation mais essaie simplement de décrire rapidement le problème. Il se focalise sur l'accès à l'Internet, pas sur les mesures au sein du cœur du réseau (où les capacités sont beaucoup plus élevées). La plupart du temps, le goulet d'étranglement du chemin suivi par les paquets IP sera le lien entre l'utilisateur et le FAI. Ce choix de mesurer l'accès à l'Internet met quelques limites à l'efficacité de la mesure (dans le cœur, on peut utiliser des engins de mesure perfectionnés et coûteux ; chez l'utilisateur, on devra souvent se contenter de dispositifs moins sophistiqués, par exemple ayant une horloge moins précise). Combien de bits/seconde va pouvoir faire passer M. Michu ? Notez que tout dépend d'où on part. De la box ? D'un PC connecté en Wi-Fi ? Le RFC 7398 mettait déjà en avant l'importance de décrire le chemin emprunté par la mesure (le réseau Wi-Fi de M. Michu peut être très chargé, donnant l'impression d'une capacité plus faible qu'elle ne l'est réellement). Autre piège, les FAI imposent souvent aux abonnés des capacités asymétriques : la capacité descendante (dans la terminologie des FAI, qui se voient au-dessus des utilisateurs) est supérieure à la capacité montante.

Une des nombreuses difficultés de la mesure est que les paquets peuvent être traités différemment selon leurs caractéristiques (RFC 2330, section 13) : paquets longs vs. paquets courts, TCP vs. UDP, différence selon le port de destination, etc. Idéalement, le trafic de test, que l'on injectera pour mesurer combien de bits/seconde passeront, devra être une imitation aussi proche que possible du trafic réel de M. Michu. Ce n'est qu'un des très nombreux pièges qui se présentent lorsqu'on veut faire des mesures sur l'Internet. Au moment de la sortie du rapport ARCEP, on avait ainsi vu pas mal de gens peu informés et n'ayant manifestement jamais réfléchi à la question s'exprimer très fort sur divers forums. Ils affirmaient bien haut leurs certitudes (« LOL mais non, c'est idiot, il ne faut pas faire comme cela ») sans que rien n'indique qu'ils avaient compris la complexité du problème.

Dernier piège cité en section 2 de notre RFC, le moment où faire les mesures actives qui sont indispensables à la détermination de la capacité. Si on les fait aux moments pré-définis, on aura des résultats différents selon qu'à ces moment l'utilisateur télécharge en HD ou pas. Il serait préférable d'attendre un moment calme. Mais cela soulève d'intéressants problèmes de protection de la vie privée (par exemple, la documentation de la SamKnows précise qu'il faut l'installer en coupure, de manière à ce qu'elle puisse voir passer tout le trafic).

La section 3 du RFC décrit plus précisément ces mesures actives. Il faut évidemment un protocole de contrôle permettant la coordination entre la sonde de mesure et l'amer (genre RFC 5357 et RFC 4656). Il faut d'autre part que le trafic généré pour le test soit réduit à ce qui est strictement nécessaire pour mesurer la capacité (l'un des problèmes essentiels des mesures actives est qu'elles perturbent le réseau, cf. section 5 du RFC 7680 et section 4 du RFC 3148, et les sections 6 et 7 de notre RFC, qui insistent sur l'importance du consentement). Comme le lien d'accès typique a des capacités asymétriques, l'idéal serait de pouvoir faire des mesures dans une seule direction. Mais c'est en général irréaliste (il faut des équipements de mesure bien synchronisés, notamment du point de vue temporel, et qui soient des boîtes spécialisées, sachant faire ce que ne peut pas faire une machine Unix ordinaire). Donc, la plupart des mesures seront une mesure de l'aller-retour, dont il faudra extraire ensuite les capacités dans chaque direction.

Au bout du compte, ces mesures actives nécessiteront trois composants :

• L'émetteur, qui est capable d'envoyer des paquets ayant les caractéristiques souhaitées,
• Le receveur,
• Et le rapporteur, qui mesure et envoie les résultats dans le format demandé.

Parmi les caractéristiques demandées pour les paquets (section 4), il faut pouvoir choisir la longueur, le contenu (certains équipements réseaux, par exemple ceux qui effectuent de la compression, donnent des résultats différents selon le contenu), les différents champs de l'en-tête IP (comme ceux du RFC 2474), le protocole (TCP ou UDP), les ports, etc. Ces paquets doivent pouvoir être transmis à un rythme choisi. Bien que le RFC passe très rapidement sur ce point, il faut aussi pouvoir, si on utilise TCP, contrôler l'algorithme d'évitement de la congestion.