Auteur Sujet: Déballage: serveur "TV" (Lu 15474 fois)

vivien · « **Réponse #24 le:** 19 février 2016 à 08:28:44 »

Pour les DSP qui font payer la collecte au Mb/s 95centile cela entraîne forcèment un sur-coût, mais il me semble que K-Net est sur des DSP qui ne font plus payer un prix pour le lien de collecte, sans vérifier la consommation, à un tarif assez faible.

Attention, certains réseaux font payer for cher les flux multicast qui sont rajoutés sur son réseau (il me semble que ce sont les les mêmes qui font payer le trafic de collecte au 95centile)

jack · « **Réponse #25 le:** 19 février 2016 à 11:09:50 »

Citation de: leon_m le 19 février 2016 à 08:21:54

Est-ce que dans certaines DSP, il ne faut pas aussi re-dimensionner à la hausse la 'porte de collecte'? Ce qui implique des couts fixes et récurrents supplèmentaires...

De manière négligeable, oui

Citer

Est-ce que tous les réseaux de DSP son suffisamment dimensionnés pour accueillir le débit supplèmentaire nécessaire?

Suis-je concerné par cette question ?

buddy · « **Réponse #26 le:** 19 février 2016 à 11:12:14 »

Citation de: jack le 19 février 2016 à 11:09:50

Suis-je concerné par cette question ?

oui même si tu n'en es pas responsable, çà serait dommage que tu aies une solution inutilisable par tes abonnés ...

jack · « **Réponse #27 le:** 19 février 2016 à 11:13:55 »

Citation de: buddy le 19 février 2016 à 11:12:14

oui même si tu n'en es pas responsable, çà serait dommage que tu aies une solution inutilisable par tes abonnés ...

Ben, le réseau subit une constante évolution, la monté en débit en fait partie (que ce soit pour de la TV, pour plus d'abonné, ou pour des offres Gb)
Si la DSP en fait pas son travail, cela concerne le domaine économique, juridique et politique, pas technique

vivien · « **Réponse #28 le:** 19 février 2016 à 11:52:30 »

Est-ce que la DSP vous laisse prioriser ces flux, sur les flux internet de base ?

La commande sous Linux pour mettre le DSCP 20 en IPv4 et en IPv6 sur le trafic sortant du port 80 :

/sbin/iptables -t mangle -A OUTPUT -p tcp --sport 80 -j DSCP --set-dscp 20
/sbin/ip6tables -t mangle -A OUTPUT -p tcp --sport 80 -j DSCP --set-dscp 20

jack · « **Réponse #29 le:** 19 février 2016 à 11:56:43 »

Pour certains, oui, mais je ne suis pas vraiment intéressé
La qos ne fonctionne pas par vlan, je ne vois aucune raison de penser que cela fonctionnera mieux avec du dscp

vivien · « **Réponse #30 le:** 19 février 2016 à 13:49:39 »

Le but est de limiter les cas où l'utilisateur va voir la TV se dégrader.

Par exemple un utilisateur qui fait un Test sur de très nombreuses connexions TCP en // pourrait arriver à dégrader une chaîne HD ou la téléphonie.
Dans les autres cas, c'est plus en cas d'incident sur la DSP où le reroutage du trafic entraîne une saturation.

Les gros opérateurs ont tous des stratégie de priorisation plus ou moins complexes (mais sur l'ADSL, l'absence de priorisation sur la téléphonie ou la TV est vite catastrophique)

Leon · « **Réponse #31 le:** 19 février 2016 à 13:58:03 »

Citation de: vivien le 19 février 2016 à 11:52:30

Est-ce que la DSP vous laisse prioriser ces flux, sur les flux internet de base ?

Si le cache dans la Box est réellement de l'ordre de 10 secondes, je pense que la priorisation du flux n'est pas indispensable.

Leon.

kgersen · « **Réponse #32 le:** 19 février 2016 à 14:51:34 »

un HLS est moins sensible qu'un flux tv 'tendu' mais quand meme ca peut merder si y'a une saturation.

C'est exactement comme Netflix et Youtube en fait (sauf qu'il n'y a pas de DASH).

Maintenant tout les clients sont en fibre et le serveur est pas 'loin' ou derriere un peering/transit.

apres je ne sais pas comment le lien "client KNet - DSP - KNet " fonctionne.

L'avantage du HLS est qu'on peut faire du P2P... un truc du genre:
- un client demande le prochain chunk de la chaine, le serveur lui envoi le chunk ainsi que quelques IP de clients (proches en terme d'infra) a qui il très récemment aussi envoyé ce chunk.
- au prochain chunk, plutôt que de demander en 1er au serveur, le client fait une demande en // a la liste des IP des autres clients. si aucun n'a le chunk suivant, le client demande au serveur.

ca me semble pas trop compliquer à mettre en oeuvre mais faut le coder (coté serveur et coté client). A priori KNet n'a pas la main sur le code du client ?

vivien · « **Réponse #33 le:** 19 février 2016 à 15:01:35 »

Netflix a des astuces (multiples connexions TCP) pour passer devant les autres en cas de saturation, sans mettre de DSCP.

Si on compare un flux K-Net a un flux Netflix sur un lien saturé, c'est le flux K-Net qui va souffrir.

Faites le test Netflix ou même Youtube contre CanalPlay, vous allez voir que CanalPlay se fait dégommer (baisse de résolution et même freeze complet). En regardant le fonctionnement, Canal Play me semble architecturé de la même façon (blocs de quelques secondes et le client attend d'avoir récupéré le bloc pour demander le suivant avec a chaque bloc une ouverture de connexion). Netflix va télécharger en continue (sur la même connexion TCP), et va le faire sur plusieurs connexions TCP.

Maintenant sur une ligne a 100 Mb/s c'est plus difficile a reproduire que sur un ADSL à 5 Mb/s.

kgersen · « **Réponse #34 le:** 19 février 2016 à 15:07:35 »

oui et Netflix fait aussi de l'adaptatif (DASH) aussi donc baisse la résolution (donc la taille des chunks) si c'est encombré.

Optix · « **Réponse #35 le:** 19 février 2016 à 17:57:50 »

Citation de: kgersen le 19 février 2016 à 14:51:34

L'avantage du HLS est qu'on peut faire du P2P... un truc du genre:
- un client demande le prochain chunk de la chaine, le serveur lui envoi le chunk ainsi que quelques IP de clients (proches en terme d'infra) a qui il très récemment aussi envoyé ce chunk.
- au prochain chunk, plutôt que de demander en 1er au serveur, le client fait une demande en // a la liste des IP des autres clients. si aucun n'a le chunk suivant, le client demande au serveur.

ca me semble pas trop compliquer à mettre en oeuvre mais faut le coder (coté serveur et coté client). A priori KNet n'a pas la main sur le code du client ?

Tu ne vois que les avantages du P2P, alors qu'il y a aussi des inconvénients : vie privée (très facile de savoir qui regarde quoi), droits (si un mec regarde une chaine payante, ça débloque l'accès pour tout le monde ?), intégrité de la donnée (facile de réinjecter des données corrompues dans le réseau). Il faut vraiment comprendre que le P2P, c'est comme gueuler en place publique : je veux telle chaine, pour que tes peers t'envoient le jus. Malheur à celui qui commet le péché de luxure en zappant sur une chaine coquine ^^' .

De mon point de vue, cette solution fait très "bricolage".