La Fibre
Datacenter et équipements réseaux => Équipements réseaux => 
Infrastructure réseau (opérateurs) => Discussion démarrée par: Douks le 02 mars 2021 à 13:48:22
-
Salut tavou 👋
Par curiosité, j'ai cherché à savoir comment faisaient les opérateurs pour limiter le débit proposé dans une offre FO.
Par exemple Sosh, ils proposent du 300/300, mais avec la même box qui peut probablement fournir 1G.
Ils font de la QOS ? Si c'est le cas, comment ça se fait que le débit max ne soit pas fixé précisément à 300 (ça fluctue à +5/+10 pour moi) ?
-
Le débit est limité sur l'OLT.
Il est possible que Orange propose un burst pendant une courte durée. Le débit étant un nombre de paquet pendant une durée, si la durée d'analyse est importante, cela peut se voir.
SFR proposait par exemple un burst à 100 Mb/s en upload pendant 1120ms, avant d'être bridé par l'OLT à 50 Mb/s.
C'était il y a 10 ans, les débits ont évolués mais le principe reste là (enfin un Burst de plus d'une seconde c'est très long). Je rappelle par contre que le burst n'est possible que si on a le média pour aller au-delà. Il n'est pas possible de faire du burst à plus de 1 Gb/s sur un média limité physiquement à 1 Gb/s (ou 100 Mb/s dans le test fait il y a 10ans, les ONT étaient à l'époque en 100 Mb/s).
L'offre Fibre de SFR est de 100 Mb/s en download et 50 Mb/s en upload... en théorie car SFR propose un débit réel de 100 Mb/s en upload pendant les premières 1120 millisecondes
Les tests de débit des abonnés Fibre Gpon me semblant pouvoir dépasser 50 Mb/s au début du transfert, j'ai vérifié que ce n'étais pas qu'une impression en réalisant une trace Wireshark.
Voici le matériel utilisé :
- NeufBox v5 avec 4 ports etherent 1 Gb/s
- ONT Alcatel-Lucent avec 2 ports ethernet 100 Mb/s
- Serveur sur Internet (sur le réseau Free) relié à 1 Gb/s à Internet
- Iperf pour générer le trafic upload (NeufBox => Internet)
(un grand merci à nimbus3d (https://lafibre.info/index.php?action=profile;u=402), membre de LaFibre.info avec qui j'ai fais les tests)
(https://lafibre.info/images/altice/200903_install_sfr_gpon_43.jpg)
Voici les graphes des données reçus. La capture est réalisée sur le récepteur (serveur relié à Internet) car si je réalise la capture sur le PC qui génère le trafic, on ne sait pas si le flux envoyé l'est réellement ou si il est buffurisé sur un équipement réseau ou supprimé, par exemple l'ONT.
Pour ce test IPERF le PC envoi en UDP à un débit de 100 Mb/s en permanence.
(https://lafibre.info/images/altice/sfr_fibre_upload_udp.png)
Nous observons un burst de 100 Mb/s (c'est du trafic upload, dans le sens Client => Internet) pendant 1120 millisecondes alors que l'offre est théoriquement de seulement 50 Mb/s
-
Salut tavou 👋
Par curiosité, j'ai cherché à savoir comment faisaient les opérateurs pour limiter le débit proposé dans une offre FO.
Par exemple Sosh, ils proposent du 300/300, mais avec la même box qui peut probablement fournir 1G.
Ils font de la QOS ? Si c'est le cas, comment ça se fait que le débit max ne soit pas fixé précisément à 300 (ça fluctue à +5/+10 pour moi) ?
Techniquement oui, c'est de la QOS : tu détruits X paquets sur Y, par échelle de temps (la seconde souvent), et ainsi tu réduits le débit.
Par analogie avec les tuyaux d'eau, c'est comme si on t'amenait un gros tuyau de grosse section (et donc potentiellement de gros débit), mais qu'à un endroit on te le troue, avec un trou plus ou moins gros.
Le débit général dans le tuyau va donc diminuer, puisqu'une partie de l'eau va s'échapper et se perdre par le trou.
-
Techniquement oui, c'est de la QOS : tu détruits X paquets sur Y, par échelle de temps (la seconde souvent), et ainsi tu réduits le débit.
Par analogie avec les tuyaux d'eau, c'est comme si on t'amenait un gros tuyau de grosse section (et donc potentiellement de gros débit), mais qu'à un endroit on te le troue, avec un trou plus ou moins gros.
Le débit général dans le tuyau va donc diminuer, puisqu'une partie de l'eau va s'échapper et se perdre par le trou.
Pas de QoS, mais un débit en dur paramétré au niveau de l'OLT.
-
Pas de QoS, mais un débit en dur paramétré au niveau de l'OLT.
Oki oki :-)
Mais on est d'accord que techniquement, il n'y a pas 36 solutions pour limiter un débit de données informatiques : si le medium physique supporte plus que ce que l'on souhaite : on bute des paquets à la chaine.
Il existe d'autres solutions techniques que j'ignore ? :-)
-
la ou je bossais avant on appelait ça un shapper
de mémoire ça échantillonnait toutes les secondes et ça dropait les paquets en trop.
on pourrait appeler ça de la qos vu que le principe est le même (sur des systèmes de qos avancé il y a moyen de faire des choses plus intéressantes avec des système de buffer avec des files de priorité qui évite de dropper directement les paquets).
-
Ok merci de la précision, c'est bien ce que je pensais.
Après on est sur du vocabulaire là, mais on parle bien du même principe technique ;-)
-
Merci pour vos réponses ;)
Ca implique que chaque "ligne" FO arrivant sur l'OLT à sa propre configuration ? Une idée de comment c'est gérer pour déployer ça massivement ? Ca m'étonnerait qu'il y ait un toto qui se tape la config du bestiau h24 ? :p
-
Via de l'orchestration et des scripts, heureusement oui :P
-
Ca implique que chaque "ligne" FO arrivant sur l'OLT à sa propre configuration ? Une idée de comment c'est gérer pour déployer ça massivement ? Ca m'étonnerait qu'il y ait un toto qui se tape la config du bestiau h24 ? :p
Chez nous (on gère des OLT vu qu'on fait du FTTH passif), oui, chaque ONU a sa propre config. Un script lit un modèle et change certaines variables (débit, téléphonie?, port TV?) en fonction de l'abonnement, et c'est injecté dans l'OLT directement.
2 gros avantages :
- l'authentification est autonome : pas de serveurs derrière qui demandent de la maintenance ou qui risquent de planter, emportant avec eux les ONU, donc c'est très fiable.
- si j'ai besoin d'appliquer une conf particulière (genre un abonné pour un opérateur/vlan différent), j'ai le dernier mot en changeant la config directement, pour gagner en flexibilité.
Le seul inconvénient, c'est la touche "Espace" qui prend cher avec un "show run" ;D
-
Le seul inconvénient, c'est la touche "Espace" qui prend cher avec un "show run" ;D
Au hasard, vous tournez avec du Cisco ? ;)
-
Au hasard, vous tournez avec du Cisco ? ;)
Non, ZTE.
Mais les interfaces de configuration se ressemblent bcp.
-
Du coup si j’ai bien compris des paquets sont détruits pour limiter le débit mais la vrai question. Les paquets qui sont détruit sont choisis au hasard ou il ya des paquets avec des données utiles qui sont détruits ? Ça serait un peu con non ? Ça pourrait nuire à certaines communications et causer du packet loss ?
-
Du coup si j’ai bien compris des paquets sont détruits pour limiter le débit mais la vrai question. Les paquets qui sont détruit sont choisis au hasard ou il ya des paquets avec des données utiles qui sont détruits ? Ça serait un peu con non ? Ça pourrait nuire à certaines communications et causer du packet loss ?
Evidemment, tu mets des priorités sur tes paquets.
C'est con de jeter l'UDP (qui ne peut pas être retransmis) pour la voip ou la tv, quand tu as des gus qui font des speedtests auto aux tops horaires.
-
C'est con de jeter l'UDP (qui ne peut pas être retransmis) pour la voip ou la tv, quand tu as des gus qui font des speedtests auto aux tops horaires.
C'est pas tentant de leur dropper les paquets speedtest auto aux tops horaires ? ;)
-
C'est pas tentant de leur dropper les paquets speedtest auto aux tops horaires ? ;)
Justement, ces paquets deviennent non-prio de fait, héhé 8)
-
Evidemment, tu mets des priorités sur tes paquets.
C'est con de jeter l'UDP (qui ne peut pas être retransmis) pour la voip ou la tv, quand tu as des gus qui font des speedtests auto aux tops horaires.
Nous on ne fait aucune prio, les tuyaux sont assez grands pour contenir a la fois les gogols speedtest et la voip :)
-
Evidemment, tu mets des priorités sur tes paquets.
C'est con de jeter l'UDP (qui ne peut pas être retransmis) pour la voip ou la tv, quand tu as des gus qui font des speedtests auto aux tops horaires.
C’est vraiment con ! Donc disons sur une connexion UDP Freebox => Amazon Web Services si par hasard les paquets détruits sont ceux utiles et les paquets (vides) restent intacts c’est le client qui se fait carotter dans l’histoire.. des bugs tv ou streaming peuvent apparaître. Il ya d’autres alternatives a ce mode de limitation ?
En gros il faut que le traffic soit taggé pour ne pas drop les paquets utiles ou ça ne change rien ?
-
C’est vraiment con ! Donc disons sur une connexion UDP Freebox => Amazon Web Services si par hasard les paquets détruits sont ceux utiles et les paquets (vides) restent intacts c’est le client qui se fait carotter dans l’histoire.. des bugs tv ou streaming peuvent apparaître. Il ya d’autres alternatives a ce mode de limitation ?
Bah encore une fois, soit les paquets sont droppés au hasard, soit tu es un peu intelligent et tu priorises les paquets importants.
Donc à mon sens, c'est "vraiment con", de laisser l'équipement décider seul plutôt que l'humain.
Et oui, s'il y a un moment où le client se fait carroter, c'est uniquement les secondes où la capa utilisée est supérieure à la capa allumée par le FAI.
Genre s'il vend 32 abonnements à 8 Gbps sur un arbre allumé à 8 Gbps, faut pas s'étonner que ce cas puisse se produire.
(après c'est rare, mais avec les speedtests automatisés, les "collisions" sont bcp plus fréquentes qu'avant)
En gros il faut que le traffic soit taggé pour ne pas drop les paquets utiles ou ça ne change rien ?
L'idée est bonne.
Mais normalement les paquets sont reset à l'entrée/sortie du FAI. Donc normalement tes prio sautent quand tu sniffes d'un côté ou de l'autre ;)
Car sinon, suffit de tagg effectivement les paquets côté hébergeur, et pouf, tu deviens prio sur tout le réseau du FAI.
-
Oui c’est vrai mais moi je parlais juste d’un packet tag sans incidence sur les prio juste pour que le réseau puisse différencier les paquets vides et les paquets utiles quand il limite le débit en droppant ceux qui sont vides. La connexion serait beaucoup plus intéressante/performante comme ça.