Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

Que doit-on mesurer, la QoS ou la QoE ?

Première rédaction de cet article le 4 juillet 2011
Dernière mise à jour le 1 janvier 2012


Lors de discussions sur la mesure des performances de l'Internet (par exemple au sein du « groupe de travail multilatéral sur la qualité de service » de l'ARCEP), il est fréquent de voir des désaccords sur le fait de mesurer la QoS (Quality of Service) ou bien la QoE (Quality of Experience). La première concerne des mesures plutôt techniques, proches du fonctionnement du réseau. La seconde cherche à mesurer la satisfaction de l'utilisateur, ce fameux M. Toutlemonde. Quelle est la bonne approche ?

Si on vise à fournir une information à ce brave monsieur, le problème semble simple : il faut mesurer la QoE car c'est la seule qui l'intéresse. M. Toutlemonde ne veut probablement pas connaître la latence (RFC 7679 et RFC 2681), la capacité (RFC 5136) ou le taux de perte de paquets (RFC 7680). Ce qu'il veut, prétendent les gens qui parlent pour lui (M. Toutlemonde n'est jamais présent aux réunions mais on le cite tout le temps), c'est télécharger des films ou de la musique le plus vite possible. Certes, les métriques citées plus haut ont une influence nette sur sa QoE mais elle est indirecte et peu compréhensible.

Donc, cela semble réglé, la QoE est la seule chose qui importe. Seuls des barbus pas lavés comprennent quelque chose aux métriques techniques du RFC 2330 et il ne faut donc pas exposer ce pauvre M. Toutlemonde à des notions techniques. Mais, en fait, c'est plus compliqué que cela.

D'abord, la QoE a la particularité de se mesurer de bout en bout. On l'a dit, ce qui intéresse M. Toutlemonde, c'est « je clique pour voir un film, combien de temps attendre avant de le voir ». La QoE ne peut pas donc se mesurer de manière objective sans avoir accès à l'ordinateur de l'utilisateur, puisqu'elle dépend de toute la chaîne. Ainsi, si le PC Windows de M. Toutlemonde est farci de virus et que cela le ralentit, la QoE est moins bonne, quelle que soit la capacité de la fibre optique. Cela réduit fortement l'applicabilité de la QoE. Même dans un monde de Minitels où l'opérateur contrôlerait le terminal de l'utilisateur, il faudrait encore tenir compte des performances du serveur (si on regarde france.fr le jour de son inauguration, ça va très lentement, quels que soient les efforts des FAI pour fournir un bon réseau). On ne sait donc plus très bien qui est responsable des mauvaises performances.

Ensuite, la mesure de la QoE suppose la définition d'une activité typique (j'ai entendu des vagues propositions du genre « le surf sur les cent sites Web les plus populaires »). Cette définition est une mauvaise idée dans son principe. Contrairement à la téléphonie, où le réseau était conçu pour une application, et où il était donc facile de mesurer la qualité du réseau (avec des techniques comme PESQ), l'Internet sert à beaucoup de choses différentes. Un échantillon d'activités serait arbitraire : pourquoi les gens qui font du jeu en ligne ou de la messagerie instantanée, qui ont surtout besoin d'une faible latence, accepteraient-ils l'échantillon soi-disant représentatif des téléchargeurs, qui ont surtout besoin de capacité ?

Pire, cette idée d'« activité typique » empêcherait toute comparaison temporelle, puisque l'échantillon d'activités changerait d'une année sur l'autre, au gré des modes.

Enfin, l'échantillon typique a un énorme défaut si on veut l'utiliser pour des mesures qui seront publiées, genre « le classement des meilleurs FAI » : il encourage les opérateurs à optimiser leur réseau uniquement pour ce qui est mesuré. Si on intègre Facebook (très à la mode où moment où j'écris cet article) dans l'échantillon, tous les FAI feront des efforts pour avoir une bonne connectivité avec Facebook et oublieront le reste.

Dernier problème avec la QoE, l'absence de normalisation. Autant les métriques techniques sont rigoureusement définies (par le groupe de travail IPPM de l'IETF ou bien, si on y tient, par le SG-12 de l'UIT, qui produit des documents comme la Recommandation Y.1540, « Internet protocol data communication service - IP packet transfer and availability performance parameters »), autant les mesures de QoE sont souvent d'une grande subjectivité, définies de manière floue, et jamais discutées collectivement (contrairement aux normes comme les RFC cités plus haut). La plupart ne dépassent pas le niveau « ce soir, ça rame !!! » des forums de discussion bas de gamme. C'est évidemment plus compréhensible que « la latence unidirectionnelle est de 132 milli-secondes pour des paquets de Type-P TCP-80 » mais la technique doit être rigoureuse, avant d'être attirante.

Pour que des mesures massives et objectives soient possibles, il faut donc se concentrer sur des métriques techniques, reflétant le fonctionnement du réseau, comme celles indiquées plus haut. On peut toujours ajouter ensuite des mesures « de plus haut niveau », plus proches du ressenti de l'utilisateur, mais cela ne peut être qu'une fois qu'on dispose de mesures solides proches du réseau.

Un autre débat dans le même groupe ARCEP est discuté dans « Où doit-on mesurer la capacité réseau, chez le FAI ou plus loin ? ».

La consultation publique lancée par l'ARCEP fin 2011 utilise un vocabulaire différent en parlant de mesures techniques pour la QoS et de mesures orientées vers les usages pour la QoE.

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)