Auteur Sujet: peering symétrique gratuit ou asymétriques payant ? (Lu 84388 fois)

Boris de Bouygues Telecom · « **Réponse #60 le:** 08 janvier 2013 à 16:34:10 »

La piste du multicast est complexe (négociation avec chaque FAI) et coûteuse également. C'est impossible sur le câble qui est fortement utilisé aux USA.

=> Les chaînes Google TV seront basées sur des flux unicast.

Autre intérêt : pas d'horaire, on choisit l'émission que l'on souhaite regarder quand on a envie. C'est déjà le cas des 13 chaînes thématiques lancées par Youtube en France ces dernières semaines.

butler_fr · « **Réponse #61 le:** 08 janvier 2013 à 16:45:56 »

enfin ça représente une charge énorme au niveau réseau non?

c'est sur que la diffusion en multicast c'est beaucoup plus compliqué voir impossible.

Fredwww · « **Réponse #62 le:** 08 janvier 2013 à 18:29:01 »

Dans tous les cas, même en restant chez son FAI pour la TV, on voit bien qu'on se dirige de plus en plus vers de l'unicast:

Contenus type TV de rattrapage
Vidéo à la demande. Encore que dans ce cas avec l'utilisation d'un CDN qui distribue au plus près du client (type Orange), on se rapproche plus d'une forme de mutlicast
Retour en début d'émission même sans avoir enregistrer (actuellement sur les chaînes OCS et bientôt FranceTV

vivien · « **Réponse #63 le:** 08 janvier 2013 à 18:55:31 »

Comme pour la vidéo à la demande, il est possible d'héberger au plus près de l’utilisateur des GGC dans chaque POP régional, à coté des serveurs de VoD populaire. (seul les vod populaires sont répliquées en région, les VoD les moins populaires ne sont pas disponibles sur quelques points en France.

Le fonctionnement, c'est simple tout le trafic Youtube est envoyé sur le GGC (via les DNS).

- Si les données demandées sont déjà sur le GCC (90% des cas) alors c'est le GCC qui envoi les données au client.

- Si les données demandées ne sont pas sur le GCC (10% des cas) alors le GGC récupère chez Google les données, les met en cache a la place du contenu qui n'a pas été utilise depuis le plus longtemps et le GCC envoi les données au client.

Ce qui fait peur aux FAI c'est ce graphe, le pourcentage du trafic mondial occupé par YouTube (rouge) et Google (bleu)

Si vous avez la courbe pour les années suivantes, je suis intéressé, cela s’arrête fin 2009, depuis Youtube a grossi.

Optrolight · « **Réponse #64 le:** 08 janvier 2013 à 19:16:02 »

Jusqu'à 2010 tu as ceci .
http://ddos.arbornetworks.com/2010/10/google-breaks-traffic-record/

butler_fr · « **Réponse #65 le:** 08 janvier 2013 à 19:28:51 »

donc en gros la google tv reprend le principe des google cache?

mais imaginons dans un cas extreme que 50% des abonnées d'un dslam d'un opérateur regardent la tv via la google tv.
quid de la bande passante sur le dslam??

en prenant un flux tv de 6mbps (pas le top du top) pour 50 personnes qui regarderont ce flux ça fait déjà 300mbps!!

je ne sais pas en moyenne combien il y a de personnes sur un dslam et de quels type de liens il dispose pour écouler sont traffic mais pas sur que ce soit énorme.

après il faut que le model de la google tv / apple tv marche.

vivien · « **Réponse #66 le:** 08 janvier 2013 à 19:43:32 »

50% c'est bien trop important. Les Geeks, c'est 10% max des abonnés.

Un DSLAM c'est 1000 clients au maximum pour les plus gros modèle de DSLAM.
Le lien pour le relier au réseau est de 1 Gb/s. Il serait possible de mettre 2 Gb/s mais comme statistiquement il n'arrive jamais que le trafic dépasse 300 Mb/s, c'est inutile.

Il ne faut pas faire débit de synchro moyen x nombre de client mais consommation par client a l'heure de pointe multiplié par un coefficient. Plus il y a de clients plus ce coefficient se rapproche de 1,0 car on se rapproche de la donnée statistique.

Un abonné ADSL, cela consomme 130 Kb/s de trafic unicast à l'heure de pointe.

butler_fr · « **Réponse #67 le:** 08 janvier 2013 à 19:55:28 »

d'accord avec toi sur les données actuelles
mais si ce que propose google est adopté en masse? (j'ai un doute pour la france ou les box avec tv sont bien implantées)

à ce moment la on passerait d'une consommation de flux tv multicast à une consommation de flux tv en unicast.
d'ou une augmentation conséquente de la consommation unicast.

en tablant sur 10% de personnes adoptant le bazar, donc 5% qui vont regarder la TV vers 20h, on trouve 300mbps avec un flux en 6mbps.
300mbps pour au grand max 10 chaines c'est énorme! on peu faire passer le tout en 60mbps en multicast!

vivien · « **Réponse #68 le:** 08 janvier 2013 à 21:45:15 »

Je ne suis pas en phase sur les chiffres.

Youtube ne propose pas de flux à 6Mb/s. Je suis preneur d'un seul exemple. Les flux qui ne sont pas en live ont un taux de compression bien supérieurs aux flux live (pas besoin d'image i toutes les secondes, double compression,...). Je propose de partir sur un débit de 1 Mb/s pour la moitié des clients (SD) et 3 Mb/s pour l'autre moitié des clients (HD).

je reprends tes hypothèses : 10% qui adoptent Google TV => 100 clients sur le DSLAM si il est rempli au max
15% qui regardent des émissions TV de Google en unicast (pour le JT sur TF1 ce sera toujours du multicast) => il ne reste que 15 clients.
Sachant que la personne doit demander son émission, je pense que 15% des personnes qui regardent simultanèment une émission Google unicast est réaliste.

7,5 clients avec un débit de 1 Mb/s + 7,5 clients avec un débit de 3 Mb/s, cela fait 27 Mb/s de plus pour le DSLAM. C'est négligeable pour le DSLAM.
Maintenant si on parle d'un FAI qui a 5,5 millions de clients, cela fait 148,5 Gb/s au total pour Google TV.

butler_fr · « **Réponse #69 le:** 08 janvier 2013 à 22:47:16 »

le principe de la google tv c'est quoi de base?
remplacer notre décodeur actuel sur les box, ou faire un youtube like + replay + vod?

du coup je pense que j'ai pas saisi le fonctionnement du truc.....

et au final 148 gbps ça commence déjà à faire beaucoup.
on arrive à avoir une obligation d'héberger (gratuitement ou non) l'infra de google (si le système des google cache marche avec la google tv).

Snickerss · « **Réponse #70 le:** 08 janvier 2013 à 23:29:05 »

Je pense qu'un jour il faudra se tourner vers des solutions P2P. Même en augmentant la taille des liens, on ne pourra pas multiplier les fermes de serveur, même optimisées, cela a un coût .. Aujourd'hui les PC sont de plus en plus puissant, que de ressources disponibles. Imaginez une box quelconque qui gère ça de façon transparente, je pense qu'il y a un potentiel enorme

Leon · « **Réponse #71 le:** 09 janvier 2013 à 00:25:16 »

Citation de: Snickerss le 08 janvier 2013 à 23:29:05

Je pense qu'un jour il faudra se tourner vers des solutions P2P. Même en augmentant la taille des liens, on ne pourra pas multiplier les fermes de serveur, même optimisées, cela a un coût .. Aujourd'hui les PC sont de plus en plus puissant, que de ressources disponibles. Imaginez une box quelconque qui gère ça de façon transparente, je pense qu'il y a un potentiel enorme

Je ne suis pas d'accord avec toi.
Il est facile de faire un serveur de streaming qui débite un max. Beaucoup plus facile que pour faire un serveur web classique. Délivrer un flux vidéo live ou un gros fichier vidéo, ça ne demande pas beaucoup de ressources serveur. Beaucoup moins que de calculer des pages PHP, ou délivrer plein de petits fichiers, pour le même débit.

Et je pense qu'on peut encore optimiser le matériel et les logiciels qui font du streaming. Nous ne sommes qu'au tout début de l'utilisation d'accélération matérielle dans les serveurs. Ca va se généraliser dans les années à venir.

A l'extrème, on trouve des produits surprenants qui délivrent des quantités monstrueuses de débit de streaming dans un tout petit volume. Les 2 systèmes utilisent des FPGA pour une optimisation maximale. Un FPGA est beaucoup plus performant qu'un processeur classique, pour effectuer une tâche bête et répétitive.

Le premier système fait 20Gb/s de streaming (y compris HTTP) en 1U, avec une consommation ridicule.
http://www.edgeware.tv/downloads/pdf/WTV_A4.pdf

Le 2ieme fait 300Gb/s dans une baie. La distribution se fait via un énorme cache de 1To de RAM (!). Certes, pas en HTTP, le HTTP demande plus de ressource.
https://en-us.lionbridge.com/WorkArea/linkit.aspx?LinkIdentifier=id&ItemID=747&libID=959
Et encore, ce sont des vieux matériels. On fait sans doute mieux aujourd'hui.

Le P2P? Ca n'est absolument pas optimisé. C'est un truc de Geek à mon avis. Ca nécessite de faire tourner un serveur 24h/24. Et ça a été montré que plein de petits serveurs étaient moins efficaces (économiquement et énergétiquement) qu'un très gros serveur centralisé.

Leon.