Cela me rappelle une phrase de Xavier Niel qui disait déjà il y a
presque une dizaine d’année que les box disparaitraient dans les 15
prochaines années.
Il semble que la migration vers le protocole IPv6 favoriserait le
développement du multicast, et notamment pour la diffusion de la
télévision via les réseaux IP. Hors où en sommes nous aujourd’hui ?
Y a-t-il des blocages qui font qu’aujourd’hui les réseaux de chaînes de
télévision ne se convertissent pas à cette technologie qui leur
permettrait d’obtenir des coûts de diffusion, une économie du réseau
contrairement à l’unicast et une indépendance vis-à-vis des FAIs.
Je parle bien sûr de la diffusion en direct. La VOD ne pouvant
qu’utiliser de l’unicast.
Je remarque par ailleurs que de plus en plus Youtube diffuse des
programmes en direct (utilise-t-il le multicast ou l’unicast ?)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Le 17/12/2017 à 18:15, PP a écrit :
Il semble que la migration vers le protocole IPv6 favoriserait le développement du multicast, et notamment pour la diffusion de la télévision via les réseaux IP. Hors où en sommes nous aujourd’hui ?
Je crains que nous en soyons toujours au même point qu'avant.
Y a-t-il des blocages qui font qu’aujourd’hui les réseaux de chaînes de télévision ne se convertissent pas à cette technologie qui leur permettrait d’obtenir des coûts de diffusion, une économie du réseau contrairement à l’unicast et une indépendance vis-à-vis des FAIs.
Le blocage, c'est que le multicast ne passe pas entre les opérateurs.
Le 17/12/2017 à 18:15, PP a écrit :
Il semble que la migration vers le protocole IPv6 favoriserait le
développement du multicast, et notamment pour la diffusion de la
télévision via les réseaux IP. Hors où en sommes nous aujourd’hui ?
Je crains que nous en soyons toujours au même point qu'avant.
Y a-t-il des blocages qui font qu’aujourd’hui les réseaux de chaînes de
télévision ne se convertissent pas à cette technologie qui leur
permettrait d’obtenir des coûts de diffusion, une économie du réseau
contrairement à l’unicast et une indépendance vis-à-vis des FAIs.
Le blocage, c'est que le multicast ne passe pas entre les opérateurs.
Il semble que la migration vers le protocole IPv6 favoriserait le développement du multicast, et notamment pour la diffusion de la télévision via les réseaux IP. Hors où en sommes nous aujourd’hui ?
Je crains que nous en soyons toujours au même point qu'avant.
Y a-t-il des blocages qui font qu’aujourd’hui les réseaux de chaînes de télévision ne se convertissent pas à cette technologie qui leur permettrait d’obtenir des coûts de diffusion, une économie du réseau contrairement à l’unicast et une indépendance vis-à-vis des FAIs.
Le blocage, c'est que le multicast ne passe pas entre les opérateurs.
PP
Le 17/12/2017 à 20:36, Pascal Hambourg a écrit :
Le 17/12/2017 à 18:15, PP a écrit :
Il semble que la migration vers le protocole IPv6 favoriserait le développement du multicast, et notamment pour la diffusion de la télévision via les réseaux IP. Hors où en sommes nous aujourd’hui ?
Je crains que nous en soyons toujours au même point qu'avant.
Y a-t-il des blocages qui font qu’aujourd’hui les réseaux de chaînes de télévision ne se convertissent pas à cette technologie qui leur permettrait d’obtenir des coûts de diffusion, une économie du réseau contrairement à l’unicast et une indépendance vis-à-vis des FAIs.
Le blocage, c'est que le multicast ne passe pas entre les opérateurs.
J'ai lu sur une discussion sur un forum du site lafibre.info qu'il y avait un problème avec le protocole multicast qui est en unidirectionnel et sans répétition des paquets perdus. Je trouve que techniquement l'excuse n'est pas recevable, car on sait très faire aujourd'hui des flux TNT et satellite qui sont unidirectionnels qui ne pixelisent pas (effet bloc). Il suffit d'intégrer dans les données du flux des bits/octets de correction, avec des répétitions de données dans des paquets différents émis à des moments différents du flux (comme 400ms en TNT) ce qui permet de corriger les parasites intermittents Je pense qu'il y a surtout une grosse pression lobbyingstique de la part des gros FAIs, pour qui le service TV fait actuellement la différence entre eux.
Le 17/12/2017 à 20:36, Pascal Hambourg a écrit :
Le 17/12/2017 à 18:15, PP a écrit :
Il semble que la migration vers le protocole IPv6 favoriserait le
développement du multicast, et notamment pour la diffusion de la
télévision via les réseaux IP. Hors où en sommes nous aujourd’hui ?
Je crains que nous en soyons toujours au même point qu'avant.
Y a-t-il des blocages qui font qu’aujourd’hui les réseaux de chaînes de
télévision ne se convertissent pas à cette technologie qui leur
permettrait d’obtenir des coûts de diffusion, une économie du réseau
contrairement à l’unicast et une indépendance vis-à-vis des FAIs.
Le blocage, c'est que le multicast ne passe pas entre les opérateurs.
J'ai lu sur une discussion sur un forum du site lafibre.info qu'il y
avait un problème avec le protocole multicast qui est en unidirectionnel
et sans répétition des paquets perdus.
Je trouve que techniquement l'excuse n'est pas recevable, car on sait
très faire aujourd'hui des flux TNT et satellite qui sont
unidirectionnels qui ne pixelisent pas (effet bloc). Il suffit
d'intégrer dans les données du flux des bits/octets de correction, avec
des répétitions de données dans des paquets différents émis à des
moments différents du flux (comme 400ms en TNT) ce qui permet de
corriger les parasites intermittents
Je pense qu'il y a surtout une grosse pression lobbyingstique de la part
des gros FAIs, pour qui le service TV fait actuellement la différence
entre eux.
Il semble que la migration vers le protocole IPv6 favoriserait le développement du multicast, et notamment pour la diffusion de la télévision via les réseaux IP. Hors où en sommes nous aujourd’hui ?
Je crains que nous en soyons toujours au même point qu'avant.
Y a-t-il des blocages qui font qu’aujourd’hui les réseaux de chaînes de télévision ne se convertissent pas à cette technologie qui leur permettrait d’obtenir des coûts de diffusion, une économie du réseau contrairement à l’unicast et une indépendance vis-à-vis des FAIs.
Le blocage, c'est que le multicast ne passe pas entre les opérateurs.
J'ai lu sur une discussion sur un forum du site lafibre.info qu'il y avait un problème avec le protocole multicast qui est en unidirectionnel et sans répétition des paquets perdus. Je trouve que techniquement l'excuse n'est pas recevable, car on sait très faire aujourd'hui des flux TNT et satellite qui sont unidirectionnels qui ne pixelisent pas (effet bloc). Il suffit d'intégrer dans les données du flux des bits/octets de correction, avec des répétitions de données dans des paquets différents émis à des moments différents du flux (comme 400ms en TNT) ce qui permet de corriger les parasites intermittents Je pense qu'il y a surtout une grosse pression lobbyingstique de la part des gros FAIs, pour qui le service TV fait actuellement la différence entre eux.
Didier
Le 17/12/2017 à 22:03, PP a écrit :
Je pense qu'il y a surtout une grosse pression lobbyingstique de la part des gros FAIs, pour qui le service TV fait actuellement la différence entre eux.
Sans doute, mais je ne vois pas trop la différence entre les 200 chaines de l'un et les 200 chaines de l'autre, commercialement parlant bien entendu. Didier.
Le 17/12/2017 à 22:03, PP a écrit :
Je pense qu'il y a surtout une grosse pression lobbyingstique de la part
des gros FAIs, pour qui le service TV fait actuellement la différence
entre eux.
Sans doute, mais je ne vois pas trop la différence entre les 200 chaines
de l'un et les 200 chaines de l'autre, commercialement parlant bien entendu.
Didier.
Je pense qu'il y a surtout une grosse pression lobbyingstique de la part des gros FAIs, pour qui le service TV fait actuellement la différence entre eux.
Sans doute, mais je ne vois pas trop la différence entre les 200 chaines de l'un et les 200 chaines de l'autre, commercialement parlant bien entendu. Didier.
Pascal Hambourg
Le 17/12/2017 à 22:03, PP a écrit :
Le 17/12/2017 à 20:36, Pascal Hambourg a écrit :
Le 17/12/2017 à 18:15, PP a écrit :
Il semble que la migration vers le protocole IPv6 favoriserait le développement du multicast, et notamment pour la diffusion de la télévision via les réseaux IP. Hors où en sommes nous aujourd’hui ?
Je crains que nous en soyons toujours au même point qu'avant.
Y a-t-il des blocages qui font qu’aujourd’hui les réseaux de chaînes de télévision ne se convertissent pas à cette technologie qui leur permettrait d’obtenir des coûts de diffusion, une économie du réseau contrairement à l’unicast et une indépendance vis-à-vis des FAIs.
Le blocage, c'est que le multicast ne passe pas entre les opérateurs.
J'ai lu sur une discussion sur un forum du site lafibre.info qu'il y avait un problème avec le protocole multicast qui est en unidirectionnel et sans répétition des paquets perdus.
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder. Le vrai problème, c'est le routage multicast lui-même.
Le 17/12/2017 à 22:03, PP a écrit :
Le 17/12/2017 à 20:36, Pascal Hambourg a écrit :
Le 17/12/2017 à 18:15, PP a écrit :
Il semble que la migration vers le protocole IPv6 favoriserait le
développement du multicast, et notamment pour la diffusion de la
télévision via les réseaux IP. Hors où en sommes nous aujourd’hui ?
Je crains que nous en soyons toujours au même point qu'avant.
Y a-t-il des blocages qui font qu’aujourd’hui les réseaux de chaînes de
télévision ne se convertissent pas à cette technologie qui leur
permettrait d’obtenir des coûts de diffusion, une économie du réseau
contrairement à l’unicast et une indépendance vis-à-vis des FAIs.
Le blocage, c'est que le multicast ne passe pas entre les opérateurs.
J'ai lu sur une discussion sur un forum du site lafibre.info qu'il y
avait un problème avec le protocole multicast qui est en unidirectionnel
et sans répétition des paquets perdus.
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder.
Le vrai problème, c'est le routage multicast lui-même.
Il semble que la migration vers le protocole IPv6 favoriserait le développement du multicast, et notamment pour la diffusion de la télévision via les réseaux IP. Hors où en sommes nous aujourd’hui ?
Je crains que nous en soyons toujours au même point qu'avant.
Y a-t-il des blocages qui font qu’aujourd’hui les réseaux de chaînes de télévision ne se convertissent pas à cette technologie qui leur permettrait d’obtenir des coûts de diffusion, une économie du réseau contrairement à l’unicast et une indépendance vis-à-vis des FAIs.
Le blocage, c'est que le multicast ne passe pas entre les opérateurs.
J'ai lu sur une discussion sur un forum du site lafibre.info qu'il y avait un problème avec le protocole multicast qui est en unidirectionnel et sans répétition des paquets perdus.
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder. Le vrai problème, c'est le routage multicast lui-même.
PP
Le 18/12/2017 à 22:48, Pascal Hambourg a écrit :
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder. Le vrai problème, c'est le routage multicast lui-même.
Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas que cela soit bien lourd en terme de capacité pour les routeurs, non ? Le trafic parait extrêmement réduit si on le compare au trafic youtube, facebook ou mail par exemple.
Le 18/12/2017 à 22:48, Pascal Hambourg a écrit :
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder.
Le vrai problème, c'est le routage multicast lui-même.
Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas
que cela soit bien lourd en terme de capacité pour les routeurs, non ?
Le trafic parait extrêmement réduit si on le compare au trafic youtube,
facebook ou mail par exemple.
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder. Le vrai problème, c'est le routage multicast lui-même.
Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas que cela soit bien lourd en terme de capacité pour les routeurs, non ? Le trafic parait extrêmement réduit si on le compare au trafic youtube, facebook ou mail par exemple.
Pascal Hambourg
Le 19/12/2017 à 08:29, PP a écrit :
Le 18/12/2017 à 22:48, Pascal Hambourg a écrit :
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder. Le vrai problème, c'est le routage multicast lui-même.
Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas que cela soit bien lourd en terme de capacité pour les routeurs, non ? Le trafic parait extrêmement réduit si on le compare au trafic youtube, facebook ou mail par exemple.
Le problème n'est pas le volume de trafic. Comme je l'ai écrit, le problème est la gestion du routage multicast lui-même. A ce jour, elle n'existe pas entre les opérateurs.
Le 19/12/2017 à 08:29, PP a écrit :
Le 18/12/2017 à 22:48, Pascal Hambourg a écrit :
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder.
Le vrai problème, c'est le routage multicast lui-même.
Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas
que cela soit bien lourd en terme de capacité pour les routeurs, non ?
Le trafic parait extrêmement réduit si on le compare au trafic youtube,
facebook ou mail par exemple.
Le problème n'est pas le volume de trafic. Comme je l'ai écrit, le
problème est la gestion du routage multicast lui-même. A ce jour, elle
n'existe pas entre les opérateurs.
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder. Le vrai problème, c'est le routage multicast lui-même.
Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas que cela soit bien lourd en terme de capacité pour les routeurs, non ? Le trafic parait extrêmement réduit si on le compare au trafic youtube, facebook ou mail par exemple.
Le problème n'est pas le volume de trafic. Comme je l'ai écrit, le problème est la gestion du routage multicast lui-même. A ce jour, elle n'existe pas entre les opérateurs.
PP
Le 20/12/2017 à 21:51, Pascal Hambourg a écrit :
Le 19/12/2017 à 08:29, PP a écrit :
Le 18/12/2017 à 22:48, Pascal Hambourg a écrit :
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder. Le vrai problème, c'est le routage multicast lui-même.
Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas que cela soit bien lourd en terme de capacité pour les routeurs, non ? Le trafic parait extrêmement réduit si on le compare au trafic youtube, facebook ou mail par exemple.
Le problème n'est pas le volume de trafic. Comme je l'ai écrit, le problème est la gestion du routage multicast lui-même. A ce jour, elle n'existe pas entre les opérateurs.
En effet, lorsque je cherche des informations au sujet du multicast, j’ai l’impression d’un grand flou. Les routeurs ne semble pas prêts pour une éventuelle connexion à un mbone. Ne serait-ce que dans l’attribution des IP, il n’y a aucun renseignement. J’ai découvert aussi des protocoles tel que rtp et rtsp qui permettent de transmettre en UDP des flux video et audio et qui permettent de ranger et de corriger les données. Cependant je n’ai rien trouvé à propos de l’algorithme de correction et de la robutesse de celui-ci.
Le 20/12/2017 à 21:51, Pascal Hambourg a écrit :
Le 19/12/2017 à 08:29, PP a écrit :
Le 18/12/2017 à 22:48, Pascal Hambourg a écrit :
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder.
Le vrai problème, c'est le routage multicast lui-même.
Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas
que cela soit bien lourd en terme de capacité pour les routeurs, non ?
Le trafic parait extrêmement réduit si on le compare au trafic youtube,
facebook ou mail par exemple.
Le problème n'est pas le volume de trafic. Comme je l'ai écrit, le
problème est la gestion du routage multicast lui-même. A ce jour, elle
n'existe pas entre les opérateurs.
En effet, lorsque je cherche des informations au sujet du multicast,
j’ai l’impression d’un grand flou.
Les routeurs ne semble pas prêts pour une éventuelle connexion à un mbone.
Ne serait-ce que dans l’attribution des IP, il n’y a aucun renseignement.
J’ai découvert aussi des protocoles tel que rtp et rtsp qui permettent
de transmettre en UDP des flux video et audio et qui permettent de
ranger et de corriger les données. Cependant je n’ai rien trouvé à
propos de l’algorithme de correction et de la robutesse de celui-ci.
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder. Le vrai problème, c'est le routage multicast lui-même.
Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas que cela soit bien lourd en terme de capacité pour les routeurs, non ? Le trafic parait extrêmement réduit si on le compare au trafic youtube, facebook ou mail par exemple.
Le problème n'est pas le volume de trafic. Comme je l'ai écrit, le problème est la gestion du routage multicast lui-même. A ce jour, elle n'existe pas entre les opérateurs.
En effet, lorsque je cherche des informations au sujet du multicast, j’ai l’impression d’un grand flou. Les routeurs ne semble pas prêts pour une éventuelle connexion à un mbone. Ne serait-ce que dans l’attribution des IP, il n’y a aucun renseignement. J’ai découvert aussi des protocoles tel que rtp et rtsp qui permettent de transmettre en UDP des flux video et audio et qui permettent de ranger et de corriger les données. Cependant je n’ai rien trouvé à propos de l’algorithme de correction et de la robutesse de celui-ci.
Pierre L=c3=a9onard
Bonjour à toutes et tous, J'ai eu l’occasion pour mes études de travailler sur une application de vidéoconférence en 1993, et eu l'occasion de voire une première conférence en multicast dés 1991 sur le réseau de l'éducation et la recherche RENATER IPV4 bien sur. A cette époque un groupe d'ingénieur géraient le FMBONE comme un réseau au dessus de RENATER avec ses propres routeurs mais utilisant RENATER comme couche de transport. Le 07/03/2018 à 16:51, PP a écrit :
Le 20/12/2017 à 21:51, Pascal Hambourg a écrit :
Le 19/12/2017 à 08:29, PP a écrit :
Le 18/12/2017 à 22:48, Pascal Hambourg a écrit :
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder. Le vrai problème, c'est le routage multicast lui-même.
Dans la plus part des box, le routage multicast est bloqué à l'entrée et à l'émission. Pourquoi ?, cela donnerai l'occasion à tout un chacun de faire sa radio et sa télévision en multidifusion.
Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas que cela soit bien lourd en terme de capacité pour les routeurs, non ? Le trafic parait extrêmement réduit si on le compare au trafic youtube, facebook ou mail par exemple.
Excellente remarque. Que ce soit en ipv4 ou ipv6, la gestion du groupe multicast et des abonnements à ces groupes est géré par le réseau. C'est un travail supplémentaire mais qui est du même niveau que la recherche d'une adresse IP. La différence vient ensuite lors de l'utilisation, les routeurs ne gèrent plus des flux point à point mais des flux multipoints Plus clairement lorsqu'un paquets multicast arrive sur un routeurs et qu'il a des abonnés pour ce flux, il doit multiplier les envoient pour chaque abonnés. Un abonné pouvant être : soit un utilisateur final, soit un autre routeur multicast.
Le problème n'est pas le volume de trafic. Comme je l'ai écrit, le problème est la gestion du routage multicast lui-même. A ce jour, elle n'existe pas entre les opérateurs.
A ce jour, il n'y a pas de peering multicast officiel entre les opérateurs. puisque l'usage du multicast par les clients est interdit. Quand au volume, les opérateurs réfléchissent actuellement à une limitation du volume IP de leurs clients, comme nous l'avons tous sur nos smartphones. Raison : il y a certainement de l'argent à se faire sur le dos des gourmands.
En effet, lorsque je cherche des informations au sujet du multicast, j’ai l’impression d’un grand flou. Les routeurs ne semble pas prêts pour une éventuelle connexion à un mbone. Ne serait-ce que dans l’attribution des IP, il n’y a aucun renseignement.
l'attribution des adresses multicast a été pendant de longues année un prés carré des USA, comme d'habitude pour tout ce qui touche l'Internet. Je n'ai pas entendu dire que l'AFNIC pouvait réservée des adrsses multicast, donc je doute que cela est changé. Le RFC3171 "IANA Guidelines for IPv4 Multicast Address Assignments" donne quelques indication sur la gestion des adresses multicast. Il faut sans doute aussi fouiller toutes les références qui sont nommées.
J’ai découvert aussi des protocoles tel que rtp et rtsp qui permettent de transmettre en UDP des flux video et audio et qui permettent de ranger et de corriger les données. Cependant je n’ai rien trouvé à propos de l’algorithme de correction et de la robutesse de celui-ci.
RTSP est un protocole de session. Le transport des données est ensuite réalisé par RTP. RTP travaille en UDP unicast ou multicast, il n'y a pas de récupération de paquets perdus. C'est à l'application de gérer la façon dont elle rempli les paquets avec ses données pour que ces pertes soient le moins gênantes pour les utilisateurs. J'ai travaillé de 1993 à 1997 sur les flux audios et vidéo H261, La première proposition de mise en paquets des flux étaient mauvaise, métaphoriquement les fluxs étaient découpés avec une simple paire de ciseaux. J'ai proposé un mies em paquets prenant en compte la structure des flux afin de limiter l'incidence des pertes. Une explication de la méthode est décrite dans le document suivant : http://www.leonard.nom.fr/these/theseLivre.pdf Il y en a d'autre, les anglais ont proposé pour le son des outils vic et vat, de mettre dans un paquet dédiée au flux audio, une première partie du son à l'heure courante et une deuxième partie du son du paquet précédent compressé, pour ne pas doubler la bande passante. J'ai d'autre document en ligne, mais mon serveur est en panne. Je vais les transférer sur mon site personnel. Cordialement. Pierre Léonard
Bonjour à toutes et tous,
J'ai eu l’occasion pour mes études de travailler sur une application de
vidéoconférence en 1993, et eu l'occasion de voire une première
conférence en multicast dés 1991 sur le réseau de l'éducation et la
recherche RENATER IPV4 bien sur.
A cette époque un groupe d'ingénieur géraient le FMBONE comme un réseau
au dessus de RENATER avec ses propres routeurs mais utilisant RENATER
comme couche de transport.
Le 07/03/2018 à 16:51, PP a écrit :
Le 20/12/2017 à 21:51, Pascal Hambourg a écrit :
Le 19/12/2017 à 08:29, PP a écrit :
Le 18/12/2017 à 22:48, Pascal Hambourg a écrit :
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder.
Le vrai problème, c'est le routage multicast lui-même.
Dans la plus part des box, le routage multicast est bloqué à l'entrée et
à l'émission. Pourquoi ?, cela donnerai l'occasion à tout un chacun de
faire sa radio et sa télévision en multidifusion.
Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas
que cela soit bien lourd en terme de capacité pour les routeurs, non ?
Le trafic parait extrêmement réduit si on le compare au trafic youtube,
facebook ou mail par exemple.
Excellente remarque. Que ce soit en ipv4 ou ipv6, la gestion du groupe
multicast et des abonnements à ces groupes est géré par le réseau. C'est
un travail supplémentaire mais qui est du même niveau que la recherche
d'une adresse IP. La différence vient ensuite lors de l'utilisation, les
routeurs ne gèrent plus des flux point à point mais des flux multipoints
Plus clairement lorsqu'un paquets multicast arrive sur un routeurs et
qu'il a des abonnés pour ce flux, il doit multiplier les envoient pour
chaque abonnés. Un abonné pouvant être : soit un utilisateur final, soit
un autre routeur multicast.
Le problème n'est pas le volume de trafic. Comme je l'ai écrit, le
problème est la gestion du routage multicast lui-même. A ce jour, elle
n'existe pas entre les opérateurs.
A ce jour, il n'y a pas de peering multicast officiel entre les
opérateurs. puisque l'usage du multicast par les clients est interdit.
Quand au volume, les opérateurs réfléchissent actuellement à une
limitation du volume IP de leurs clients, comme nous l'avons tous sur
nos smartphones.
Raison : il y a certainement de l'argent à se faire sur le dos des
gourmands.
En effet, lorsque je cherche des informations au sujet du multicast,
j’ai l’impression d’un grand flou.
Les routeurs ne semble pas prêts pour une éventuelle connexion à un mbone.
Ne serait-ce que dans l’attribution des IP, il n’y a aucun renseignement.
l'attribution des adresses multicast a été pendant de longues année un
prés carré des USA, comme d'habitude pour tout ce qui touche l'Internet.
Je n'ai pas entendu dire que l'AFNIC pouvait réservée des adrsses
multicast, donc je doute que cela est changé. Le RFC3171 "IANA
Guidelines for IPv4 Multicast Address Assignments"
donne quelques indication sur la gestion des adresses multicast. Il faut
sans doute aussi fouiller toutes les références qui sont nommées.
J’ai découvert aussi des protocoles tel que rtp et rtsp qui permettent
de transmettre en UDP des flux video et audio et qui permettent de
ranger et de corriger les données. Cependant je n’ai rien trouvé à
propos de l’algorithme de correction et de la robutesse de celui-ci.
RTSP est un protocole de session. Le transport des données est ensuite
réalisé par RTP.
RTP travaille en UDP unicast ou multicast, il n'y a pas de récupération
de paquets perdus. C'est à l'application de gérer la façon dont elle
rempli les paquets avec ses données pour que ces pertes soient le moins
gênantes pour les utilisateurs.
J'ai travaillé de 1993 à 1997 sur les flux audios et vidéo H261, La
première proposition de mise en paquets des flux étaient mauvaise,
métaphoriquement les fluxs étaient découpés avec une simple paire de
ciseaux. J'ai proposé un mies em paquets prenant en compte la structure
des flux afin de limiter l'incidence des pertes.
Une explication de la méthode est décrite dans le document suivant :
http://www.leonard.nom.fr/these/theseLivre.pdf
Il y en a d'autre, les anglais ont proposé pour le son des outils vic et
vat, de mettre dans un paquet dédiée au flux audio, une première partie
du son à l'heure courante et une deuxième partie du son du paquet
précédent compressé, pour ne pas doubler la bande passante.
J'ai d'autre document en ligne, mais mon serveur est en panne. Je vais
les transférer sur mon site personnel.
Bonjour à toutes et tous, J'ai eu l’occasion pour mes études de travailler sur une application de vidéoconférence en 1993, et eu l'occasion de voire une première conférence en multicast dés 1991 sur le réseau de l'éducation et la recherche RENATER IPV4 bien sur. A cette époque un groupe d'ingénieur géraient le FMBONE comme un réseau au dessus de RENATER avec ses propres routeurs mais utilisant RENATER comme couche de transport. Le 07/03/2018 à 16:51, PP a écrit :
Le 20/12/2017 à 21:51, Pascal Hambourg a écrit :
Le 19/12/2017 à 08:29, PP a écrit :
Le 18/12/2017 à 22:48, Pascal Hambourg a écrit :
Le problème n'est pas là. Comme tu l'écris, on sait s'en accomoder. Le vrai problème, c'est le routage multicast lui-même.
Dans la plus part des box, le routage multicast est bloqué à l'entrée et à l'émission. Pourquoi ?, cela donnerai l'occasion à tout un chacun de faire sa radio et sa télévision en multidifusion.
Pourtant, tout semble prévu dans le protocole IPv6, et je ne pense pas que cela soit bien lourd en terme de capacité pour les routeurs, non ? Le trafic parait extrêmement réduit si on le compare au trafic youtube, facebook ou mail par exemple.
Excellente remarque. Que ce soit en ipv4 ou ipv6, la gestion du groupe multicast et des abonnements à ces groupes est géré par le réseau. C'est un travail supplémentaire mais qui est du même niveau que la recherche d'une adresse IP. La différence vient ensuite lors de l'utilisation, les routeurs ne gèrent plus des flux point à point mais des flux multipoints Plus clairement lorsqu'un paquets multicast arrive sur un routeurs et qu'il a des abonnés pour ce flux, il doit multiplier les envoient pour chaque abonnés. Un abonné pouvant être : soit un utilisateur final, soit un autre routeur multicast.
Le problème n'est pas le volume de trafic. Comme je l'ai écrit, le problème est la gestion du routage multicast lui-même. A ce jour, elle n'existe pas entre les opérateurs.
A ce jour, il n'y a pas de peering multicast officiel entre les opérateurs. puisque l'usage du multicast par les clients est interdit. Quand au volume, les opérateurs réfléchissent actuellement à une limitation du volume IP de leurs clients, comme nous l'avons tous sur nos smartphones. Raison : il y a certainement de l'argent à se faire sur le dos des gourmands.
En effet, lorsque je cherche des informations au sujet du multicast, j’ai l’impression d’un grand flou. Les routeurs ne semble pas prêts pour une éventuelle connexion à un mbone. Ne serait-ce que dans l’attribution des IP, il n’y a aucun renseignement.
l'attribution des adresses multicast a été pendant de longues année un prés carré des USA, comme d'habitude pour tout ce qui touche l'Internet. Je n'ai pas entendu dire que l'AFNIC pouvait réservée des adrsses multicast, donc je doute que cela est changé. Le RFC3171 "IANA Guidelines for IPv4 Multicast Address Assignments" donne quelques indication sur la gestion des adresses multicast. Il faut sans doute aussi fouiller toutes les références qui sont nommées.
J’ai découvert aussi des protocoles tel que rtp et rtsp qui permettent de transmettre en UDP des flux video et audio et qui permettent de ranger et de corriger les données. Cependant je n’ai rien trouvé à propos de l’algorithme de correction et de la robutesse de celui-ci.
RTSP est un protocole de session. Le transport des données est ensuite réalisé par RTP. RTP travaille en UDP unicast ou multicast, il n'y a pas de récupération de paquets perdus. C'est à l'application de gérer la façon dont elle rempli les paquets avec ses données pour que ces pertes soient le moins gênantes pour les utilisateurs. J'ai travaillé de 1993 à 1997 sur les flux audios et vidéo H261, La première proposition de mise en paquets des flux étaient mauvaise, métaphoriquement les fluxs étaient découpés avec une simple paire de ciseaux. J'ai proposé un mies em paquets prenant en compte la structure des flux afin de limiter l'incidence des pertes. Une explication de la méthode est décrite dans le document suivant : http://www.leonard.nom.fr/these/theseLivre.pdf Il y en a d'autre, les anglais ont proposé pour le son des outils vic et vat, de mettre dans un paquet dédiée au flux audio, une première partie du son à l'heure courante et une deuxième partie du son du paquet précédent compressé, pour ne pas doubler la bande passante. J'ai d'autre document en ligne, mais mon serveur est en panne. Je vais les transférer sur mon site personnel. Cordialement. Pierre Léonard
