Globalement je suis satisfait du service de mon fournisseur d'accès, Free. C'est assez logique : si j'étais globalemet insatisfait, ce ne serait plus mon fournissaur d'accès.

Ce qui ne veut pas dire que j'en sois intégralement content. Par exemple, avec ma freebox V6, Free me fournit en un seul contrat de la téléphonie fixe, des services audiovisuels (TV en direct et en différé, vidéo clubs...) et de l'accès Internet. Le tout passe par un seul accès ADSL donc une bande passante limitée, avec un système de priorités sous forme de canaux virtuels ATM, dits VC : le VC de la téléphonie passe toujours avant celui de l'audiovisuel qui prend toujours le pas sur celui de l'internet, avec pour effet qu'un appel téléphonique peut toujours passer même si une chaîne TV ADSL prend toute la bande passante, et que la chaîne en question pourra toujours s'afficher même si on lance un téléchargement sauvage.

Ou pas.

Car la priorité audiovisuel/internet n'est pas assurée au moins dans un cas, celui de Canal Play, le service de vidéo à la demande de Canal+. Faites l'essai : lancez la bande-annonce de votre choix sur Canal Play, puis lancer un bon gros téléchargement, par exemple un des tests de débit d'accès de Free. Si comme moi vous avez juste assez de débit pour du SD, le résultat est immédiat : gros parasites verdâtres et son haché. Coupez le téléchargement : miracle, la bande-annonce reprend. Je soupçonne que Canal Play ne passe pas par le VC ATM de la télévision, en fait, et que du coup, il n'a pas de bande passante garantie.

Soucieux de préserver la sérénité dans mon couple quitte à assombrir mes relations avec ma progéniture, je me suis donc lancé dans une mission : assurer moi-même la qualité de service (QoS) dans ce cas.

Et VLAN !

Commençons par un petit descriptif du problème.

Le trafic qui circule entre la freebox server et la freebox player contient essentiellement deux sous-trafics: l'audiovisuel (chaînes ADSL, enregistrements, vidéos, mais aussi trafic internet requis par la freebox player) et l'internet (tout le reste, non requis par la freebox player). Pour éviter que ces trfics n'interfèrent, l'audiovisuel est transmis dans ce qu'on appelle un VLAN, en l'occurrence le VLAN 100. La Freebox player voit ce trafic car elle surveille particulièrement le VLAN 100, et le reste du réseau local ne le voit pas car il ne surveille que le trafic internet, qui n'est dans aucun VLAN. La plupart du temps, le trafic audiovisuel vient du VC ATM réservé à l'audiovisuel, donc a déjà pris le pas sur le trafic internet. Dans le cas de Canal Play, ce n'est pas le cas : les deux trafics se télescopent et chacun n'arrive à passer qu'en partie.

Le problème consiste donc à laisser passer tout le trafic audiovisuel entre la freebox server et le réseau, mais seulement une part du trafic internet, le total étant bien sûr inférieur ou égal au débit entrant de notre accès. Malheureusement, nous ne contrôlons ni le débit auquel Canal nous envoie ses données, ni celui auquel nous arrive le trafic internet. Comment faire alors pour ralentir le trafic Internet ? Tout simpelment en créant un léger bouchon, de sorte qu'en cas de saturation du débit descendant, tout le trafic entrant ne puisse pas passer, ce qui va obliger à rejeter une partie du trafic ; et à passer en priorité le trafic audiovisuel, ce qui va impliquer que seul le trafic internet pourra être rejeté.

Mais, direz-vous, si cela permet de garantir le visionnage du contenu audiovisuel, le rejet d'une partie du trafic internet va empêcher tout usage du réseau ! Eh bien non : il existe un mécanisme d'adaptation qui fait que l'émetteur du trafic internet que nous recevons, sera informé du rejet de sontrafic ou de sont raitement tardif, et va alors adapter son débit pour minimiser celui-ci, donc faire repasser automatiquement le débit entrant sous le seuil de saturation. Il y aura certes quelques perturbations, mais elles seront temporaires.

A quoi s'ajoute qu'il faudra aussi laisser circuler l'ensemble du trafic IPv6, au cas où l'option correspondante serait activée sur la freebox.

Embarquement immédiat

Puisque nous voulons contrôler le trafic entre la freebox server et le réseau local, nous allons devoir interposer entre les deux un appareil muni de deux prises Ethernet : d'un côté, il sera raccordé à la freebox server en lieu et place du freeplug ; de l'autre, il sera raccordé au freeplug en lieu et place de la freebox server (au besoin en passant par un commutateur Ethernet pour raccorder d'autres appareils sans passer par le CPL. Pour pouvoir contrôler le comportement det appareil intercalaire, il faudra qu'il fonctionne sous Linux et qu'on puisse le configurer aussi finement que possible. Certains NAS conviennent à cet usage. Ici, la solution a été développée sur un OpenRD Client, avec comme cible finale un LaCie Wireless Space, simplement parce que j'avais ça sous la main. :)

Pour les techniques employées, je ne vais pas en développer les détails, en tout cas pas tout de suite... Pour l'instant, je renvoie à des pages extérieures qui donnent déjà les informations utiles ; à terme, je les remplacerai par des pages locales.

Tout le monde sur le pont !

Le mécanisme à mettre en oeuvre pour arriver à nos fins est un pontage Ethernet similaire à celui présenté là. Un pont revient à englober plusieurs interfaces Ethernet en une seule pseudo-interface : toute donnée qui arrive à une des interfaces du pont est renvoyé sur les autres interfaces. Ainsi, en pontant les deux interfaces de notre boîtier, on peut intercaler celui-ci entre les freebox Server et Player, et celles-ci pourront continuer à communiquer.

Enfin, presque : un pont va effectivement faire passer le trafic entre ses interface, mais seulement le trafic qui n'est d'aucun VLAN ! On peut donc utiliser internet (IPv4 comme IPv6) à travers notre boîtier, mais les freebox ne se verront pas. Il nous faut ponter le VLAN 100 également.

D'où, le deuxième mécanisme : les interfaces virtuelles. A partie d'une interface physique, disons eth0, la commande vconfig add eth0 100 permet de créer l'interface virtuelle eth0.100 sur laquelle est visible le trafic... oui, du VLAN 100.

On pourrait se dire que puisqu'on a déjà un point entre eth0 et eth1, appelé br0, on pourrait créer br0.100 : malheureusement, ça ne donnera rien puisque le pont ne voit que le trafic hors VLANs, donc ne verra pas le VLAN 100 et ne pourra pas le ressortir sur br0.100.

N'essayez pas non plus de créer eth0.100 et eth1.100 en espérant que br0.100 verra leur trafic : ça ne fonctionne pas non plus.

La bonne méthode consiste bien à créer eth0.100 et eth1.100 mais à les relier par un second pont -- que j'ai appelé br100. Et ça ne fonctionnera pas non plus. :)

En effet, le pont br0 ne fait pas passer le trafic VLAN 100 d'une interface à l'autre... mais il le "consomme" quand même, ce qui fait que le bridge br100 ne le verra pas ! Il faut donc expliquer au pont br0 de rejeter sans le "consommer" le trafic du VLAN 100 ; le noyau Linux se chargera de le représenter au pont br100, qui lui, le fera passer. Cette explication se fait à l'aide de la commande ebtables ; elle consiste à ajouter une règle dans la chaîne PREROUTING de la table "broute" lui enjoignant de "laisser tomber" (drop) les paquets du VLAN 100.

Voilà, le trafic audiovisuel est maintenant ponté comme le trafic Internet. Notre boîtier est "transparent" aux deux freebox, mais pour l'instant, il ne gère pas de priorités, donc on aura exactement le même symptôme avec Canal Play.

Trafic et contrebande

Peut-être vous dites-vous que maintenant, on pourrait faire intercepter le trafic des chaînes payantes et l'enregistrer ou d'autres choses du genre. N'y comptez pas, le trafic entre les freebox est chiffré. :)

En revanche, on peut l'analyser à l'aide de tcpdump et expérimenter diverses actions sur les freebox : visualisation ou enregistement de chaînes ADSL ou TNT, rejeu d'enregistrements, vidéos... Et l'on finit par se rendre compte que le trafic audiovisuel ADSL (les chaînes ADSL et la VoD, notamment...) se distingue du contenu audiovisuel non ADSL (les rejeux d'enregistrements ou de vidéos, les enregistrements de TNT...) par le champ ToS des paquets échangés : pour du contenu ADSL, il vaut 0x10, pour le contenu non ADSL, il vaut 0x00.

Nous pouvons donc mettre en place une gestion de priorité basée sur le champ ToS des paquets transitant par le pont. Sous Linux, le contrôle de trafic se fait en utilisant le paquet iproute et plus exactement la commande tc. Pour hiérarchiser la bande passante en entrée (notre direction la plus sensible), nous allons commencer par découper le trafic en deux bandes : ADSL et non-ADSL. La bande ADSL est alors subdivisée en deux bandes, audiovisuelle, la plus prioritaire des bandes, et non audiovisuelle, la moins prioritaire ; la bande non-ADSL a une priorité intermédiaire. Enfin, les deux bandes ADSL audiovisuelle et non ADSL seront capable de "mettre en attente" leur trafic ponctuellement retardé pour ne pas le perdre, mais la bande ADSL non audiovisuelle n'aura pas cette faculté, de sorte qu'elle perdra des paquets en cas de congestion, ce qui aura pour effet de faire réduire leur débit aux sources de ce trafic. Une fois ces bandes définies, des filtres se chargent de placer dans chaque bande le trafic qui lui revient (ToS 0x10 en ADSL audiovisuel, trafic freebox->LAN et LAN->LAN en non ADSL, le reste en ADSL non audiovisuel).

Par symétrie, le même principe est appliqué au débit sortant afin qu'un fort débit Internet sortant cède le pas au trafic audiovisuel, même si la problématique n'est pas aussi critique que dans le sens entrant.

En transit

Cette solution fonctionne, mais elle n'est pas parfaite.

Pour commencer, il faut pouvoir estimer le débit maximum descendant de son accès puis estimer une valeur inférieure pour plafonner les bandes ADSL. Plafonnez trop haut, et la congestion ne se fait plus dans le boîtier mais chez Free au niveau du DSLAM. Plafonnez trop bas, et vous amputez votre bande passante.

Ensuite, elle repose sur une caractéristique du trafic ADSL audiovisuel qui n'a rien d'officiel : il suffirait que Free change le champ ToS pour que le tri ne soit plus possible, plus selon ce critère en tout cas.

Mais bon : le jour où le problème se posera, on avisera. :)