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 . 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. ). 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 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
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 (, 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 et ). 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 et section 4 du , 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 ), 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.