Des infos en vrac sur le serveur "OTT" utilisé par Knet !

Je ne donne pas de photo de l'intérieur, le serveur que j'ai sous la main est plutôt vide ..
En revanche, je peux parler de celui qui est actuellement en production

  * Matériel utilisé:

- le chassis est un supermicro 6017R-WRF (http://www.supermicro.com/products/system/1u/6017/sys-6017r-wrf.cfm)
- un CPU E5-2620 (12 core, dont 6 physiques)
- 32GB de ram DDR3
- une carte PCI 4*SFP+, à base de broadcom (http://www.supermicro.com/products/accessories/addon/AOC-STG-b4S.cfm)
- des vieux disques dur qui trainent ..

Outre les ports SFP+, le serveur est branché sur un port Gb, utilisé pour le management et l'upstream.

  * Logiciel

Niveau réseau, les 4 ports sont montés en LACP, sans vlan (pvid côté switch).
Comme l'upstream utilise le port Gb 'stock', la machine dispose vraiment d'une capacité utile de 40Gbps, soit 4000 clients fullHD simultané.

Au niveau routage, le serveur possède une session BGP avec le switch, afin d'annoncer l'IP "magique" de TV, via exabgp : c'est donc de l'anycast qui va me permettre, un jour peut-être, de faire de la haute disponibilité. Dans l'immédiat, cela permet à tout les abonnés de pointer sur le même nom de domaine, sur la même IP, mais sur des serveurs différents.

Au niveau système, l'ensemble des fichiers est stockés en mémoire : cela m'évite de passer par la case "stockage" pour bondir sur la case "IO cache", nécessaire pour fournir les débits requis. L'ensemble des chunks HLS a une taille inférieure à 5GB.

Quant au logiciel, j'utilise varnish .. un simple proxy cache HTTP. Tout est générique, rien n'est spécifique ! L'autre avantage, c'est que cela simule le comportement du multicast, sur des liens "en bout d'arbre" (deauville par exemple): si personne ne regarde une certaine chaine, cette dernière n'est pas ramené de l'upstream vers la machine.

  * $$

Histoire de faire un peu de business, le coût de la solution "serveur" est inférieur à 5k€ (incluant la carte et les SFP+/DAC)
En rajoutant 4 ports 10G sur un switch (800€) plus le downstream (*2), on arrive à moins de 2k€ pour le réseau

Donc, pour 7k€, il est possible fournir 4000 clients dans le pire des cas (avec le ratio chaine HD / chaine SD, je planche plutôt sur 10k clients par serveur).
Cela fait donc 0.7€ par client (1.75€ dans le pire des cas), one shot.

Quant au logiciel, j'utilise varnish .. un simple proxy cache HTTP.

Je pense que c'est très utilisé.

Je viens de recevoir un message d'erreur de varnish sur le Replay de Free.

C'est le mdp?

Presque toutes les réponses sont dans le post Flux TV: Multicast ou Unicast ?

Il me semble que K-Net ambitionne de faire passer tous ses clients en unicast, mais il faut pour cela upgrader les lien de collecte des DSP.

Je vois que le lien vers le SIEA est passé à 20 Gb/s, cela va permettre de mettre plus de clients de l'Ain en unicast, sous réserve que le SIEA n'ai pas de pb pour transporter les flux.

"permettre aux utilisateurs d'accéder à la TV sur leur PC, leur tablette?" C'est déja possible avec les flux Multicast, K-Net étais le seul FAI à  mettre un logiciel dans sa box qui transforme les flux multicast en unicast (chez le client) pour pouvoir passer sur du WiFi (et donc regarder la TV sur tablette / téléphone avec les mêmes flux que la TV)

L’avantage principal de l'unicast, outre le fait qu'il fonctionne sur des réseaux où le multicast n'est pas possible, c'est la correction des paquets perdus et ne plus avoir de coupures liés a des pb d'implèmentation du protocole IGMP.

IGMP n'est pas suffisamment strict dans sa norme pour que deux équipements qui respectent la norme génèrent des pertes de paquets quand il y a un IGMP General Query suivit immédiatement d'un client qui résilie une flux.

Cela entraîne des problèmes complexes à tester et à reproduire en lab.

Concernant la TV, le fait d'être obligé de changer de chaîne pour que l'image revienne, cela semble visiblement un problème IGMP.

Je vais donner quelques conseils à Wibox, ayant déjà travaillé sur cette problématique.

4 éléments peuvent à l'origine de ce problème : La Set Top Box, la Wibox, le switch du SIEA qui possède les fonctions IGMP proxy, le routeur qui diffuse les flux ou une incompatibilité entre plusieurs de ces équipements.
Des problèmes d'interopérabilité peuvent survenir si une partie des équipements fonctionnent en IGMP snooping v2 et d'autres en IGMP snooping v3. Certaines box font des requêtes en v2  et en cas de non réponse passent ensuite en v3, bref il est préférable du forcer le même protocole partout (généralement IGMP v2)

Pour avancer, il faut des captures Wireshark. Je déconseille de mettre un switch avec port miroring, mon expérience que ces équipements actifs peuvent interférer sur les requêtes IGMP transmises même quand IGMP proxy est désactivé (je pense au matériel linksys / cisco). Je conseille de mettre deux PC linux avec chacun deux interfaces réseau et un pont pour relier les deux interfaces (tutoriel).

|---------|    |----------|    |-------|    |----------|    |----------------|
|   STB   |----| PC Linux |----| Wibox |----| PC Linux |----| CPE RESO-LIAin |----Fibre
|---------|    |----------|    |-------|    |----------|    |----------------|

Il faut vérifier la liste des paquets IGMP reçus et envoyés avant la coupure.
L'idéal serais d'avoir des captures Wireshark plus en amont, sur le réseau du SIEA.


Il faut voir en cas de coupure de flux où à été coupé le flux : C'est le switch du SIEA qui a arrété d'envoyer le flux à la Wibox ou c'est la Wibox qui a arrété d'envoer le flux vers la STB alors qu'elle reçoit toujours le flux de son port Wan ?

Toutes les deux minutes le switch de RESO-LIAin et la Wibox envoi un "IGMP General Query" afin que chaque équipement lui donne la liste des flux auquel il s'est abonné. Un "Query Response Interval" est alors positionné à 10 secondes. Afin de ne pas surcharger le switch, les équipements répondent après un temps d'attente aléatoire qui est entre 0s et 10s. Le switch, lui, va attendre 10 secondes + une petite marge de sécurité avant de couper les flux multicast pour lesquels il n'aura pas reçu de réponse. Il faut donc vérifier si la réponse a été émise juste avant l’expiration du délais, cela pourrait être une cause de coupure de flux.

Le "Query Response Interval" est généralement de 10 secondes pour un "IGMP General Query" mais de 1 seconde pour un "IGMP group-specific Query", envoyé quand un autre port du switch demande de quitter un flux multicast "IGMP Leave IP flux". Il est possible d'avoir des problèmes plus complexe, lié a ces différents timer.

Un exemple de bug difficile a tracer entraînant dans des cas particuliers une coupure de flux pour le client à tord :
- T 0 : La box chez le client est abonné au flux 225.0.0.5 et reçois un "IGMP General Query" avec un délai de réponse de 10 secondes. La box décide de répondre après 9 secondes (c'est un délai aléatoire entre 0 et 10sec).
- T 0 + 1 sec : Le switch de la SIEA à reçu un demande de résiliation du flux 225.0.0.5 (Leave Group message) d'un autre client. Le switch coupe le flux pour ce client et envoi un "IGMP group-specific Query" pour 225.0.0.5. Ce type de demande possède normalement un "Query Response Interval" interval de 1 seconde.
La box chez le premier client reçoit cette demande mais elle à déjà une réponse IGMP qui est en attente d'être envoyée et son mécanisme ne permet pas de répondre à plusieurs requêtes à la fois. (Tout ne sort pas de mon invention, des problèmes de ce type ont déjà existé chez certains opérateurs)
- T 0 + 2 sec : expiration du délai de 1 seconde pour le "IGMP group-specific Query". Le switch considère donc que la box n'est plus d'abonnés à ce flux et coupe le flux 225.0.0.5.
- T 0 + 9 sec : La box répond au "IGMP General Query" avec les 9 secondes d'attente. Le switch s'aperçois que la box est abonné à 225.0.0.5 et lui remet le flux.

Total pour le client : 7 secondes de coupure de flux.
Un P+ / P- permet bien sur d'envoyer une nouvelle demande d'abonnement et donc de retrouver le flux immédiatement.

Ce type de bug devrait ne pas être trop impactant pour le client car il faut plusieurs circonstances pour le re-produire : query general qui coïncide avec une réponse tardive et un autre client qui résilie la même chaîne au début de l'interval de temps. Plus le nombre de client augmente et plus on se met sur une chaîne populaire, plus les demandes de leave sont importantes et plus ce type de bug risque d'arriver si la box ignore les autres requêtes IGMP pendant le temps où la réponse est mise en attente. Je pense donc que ce n'est pas ce bug qui gêne les clients Wibox, c'est plus pour montrer qu'il est possible d'avoir des bug complexes avec IGMP v2 partout.

Concernant les bug liés à l'utilisaiton d'IGMPv2 et v3 sur le même réseau certains fabricants (huawei) ont décidés de forcer le choix d'un protocole. Si on choisit IGMP v2 les requêtes IGMP v3 seront ignorées. Cette modification provoque une coupure complète de flux multicast chez les client IGMPv3 ce qui est en fait préférable à avoir un bug lié a la cohabitaiton v2 et v3 qui est difficilement reproductible en lab.

Intéressant. quelques questions:

une seule machine a base d'un seul Xeon peut vraiment 'cracher' 40Gbps ? si j'ai bien combien l'upstream arrive sur le (les?) port(s) 1Gbs de carte mere et les flux repartent en unicast vers les clients via les 4 ports 10 Gbps tout ca géré par Varnish.

y'a pas un risque d'avoir une seule machine pour 4k clients?

l'upstream c'est du multicast ou du HLS aussi?

Quel délai introduit la solution ?

Comment ca se compare a une solution "micro services" a base de 20 (ou moins selon les besoins) petites machines a 2x1Gbps faisant tourner un simple soft comme udpxy (ou gigapxy) ? (avec un load balancer dns ou autre devant et l'upstream en multicast). moins cher ? tco ?

voir juste utiliser udpxy/gigapxy sur ton gros serveur plutot que Varnish ?