Cette durée d'aller retour s'appelle la latence, elle peut limiter les vitesses de transfert indépendamment de la prise en compte des bandes passantes réseau. Bien que les réseaux locaux ont en générale une latence inférieure à 10 ms, la latence sur de longues distances devient problématique. Une transmission à travers l'internet public inter pays est de l'ordre de 80 à 100ms, il n'est pas rare d'avoir plus de 280ms pour des liaisons intercontinentales. Il y a de nombreux facteurs qui influencent la latence – le nombre de hops entre l'envoyeur et le receveur, les caractéristiques de chaque hop, la configuration des routeurs tout au long du chemin de transfert; la proximité du backbone pour les envoyeurs et les receveurs, leurs connectivités particulières, etc- mais le résultat pratique reste le même: la latence entre deux points de transfert au travers des réseaux TCP comme le sont les liaisons FTP.
Un autre facteur clé de la transmission réseau est la perte de paquets, lorsqu'un paquet n'atteint pas sa destination. Les pertes ont de nombreuses origines mais sont souvent dues à la congestion des réseaux – essentiellement la surcharge d'un point n'importe où sur le réseau entre l'envoyeur et le receveur. Le receveur demandera une re-transmission du paquet perdu s'il reconnaît les conditions ou l'envoyeur pourra le renvoyer automatiquement s'il ne reçoit pas l'accusé de réception dans un délai imparti. Celui-ci sera au moins de la durée de la latence (ou chaque paquet devra être renvoyé). En TCP/IP basique, la fenêtre entière (buffer) de réception devra être renvoyée pour un paquet manquant ou pour un mauvais accusé de réception, chaque fois réduisant l'efficacité et causant de larges pertes de bande passante en renvoyant des données qui ont déjà été reçues. De plus, ces re-transmissions doivent s'effectuer avant les paquets ultérieurs ralentissant encore les débits.
En TCP la réponse aux pertes de paquets (ou croyant avoir perdu des paquets, ce qui entraine des latences plus grandes et d'autres facteurs) se traduit par un ralentissement des débits de transmissions pour cause de congestion du réseau, ce qui évidemment n'en est pas toujours la cause. Le protocole TCP pour les mêmes raisons démarre progressivement par nature afin d'éviter la congestion avec d'autres sessions qui seraient en concurrence de bande passante. Cela aussi crée d'autres manques d'efficacités dans les performances particulièrement visibles dans les sessions courtes. Dans les scénarios où de multiples sessions TCP sont en concurrence de ressources, une demande supérieure aux débits nominatif est aussi un phénomène souvent rencontré.
Une trop grande quantité de paquets perdus peut engendrer le crash d'une application en base TCP de type FTP. La combinaison de l'effet de latence avec celui des pertes, peut engendrer des transferts FTP à 1.5Mbps, voire moins sur des réseaux qui offre 45Mbps. L'ajout de bande passante n'aide en rien le phénomène, seule la réduction des pertes et des latences responsables des ralentissements de transmission sera le remède.
Il y a bien d'autres considérations qui ont un impact sur les transmissions à travers un réseau, mais celles que nous venons de décrire sont suffisantes pour comprendre la nature inefficace des transferts haute vitesse via TCP de fichiers de grandes capacités comme ceux des médias. Le résultat net est une très faible utilisation de la bande passante en général moins de 30% et dans les cas de très longues distances ces pourcentages descendent en dessous des 10%.
Pour surmonter ces limitations et pour maximaliser les débits et l'efficacité du transfert des fichiers sur réseaux IP, le logiciel de transfert de données Digital Rapids C2 utilise le protocole réseau UDP (User Datagram Protocol, aussi appelé Universal Datagram Protocol) en lieu et place du TCP. Les transmissions réseaux en UDP n'ont pas le principe d'accusé de réception du receveur; la fiabilité de la gestion et la vérification des erreurs doivent être effectuées au niveau de l'application. Comme les paquets peuvent être continuellement envoyés sans attendre l'accusé de réception du receveur, le problème de latence du réseau est surmonté. L'envoyeur (transmetteur) a la capacité d'utiliser un pourcentage bien plus important de la bande passante, en fait presque la totalité.
Le protocole UDP ne garantit pas l'ordre de transmission, c'est au logiciel de réception de s'assurer que les paquets sont ré-assemblés dans l'ordre correct afin de reconstruire le fichier transféré à l'identique. L'application de transfert est aussi responsable de la perte des paquets, le protocole UDP n'a pas de retransmission inhérente. Avec C2, quand le receveur détermine qu'il est possible qu'un paquet ait été égaré, une retransmission à l'émetteur est demandée comme la mise à jour d'un status périodique. Le nombre des données renvoyées est égal au nombre originellement perdu.
L'absence d'accusé de réception en UDP peut saturer les capacités des réseaux créant une congestion qui inévitablement générera des pertes de paquets. Avec répétitions cela peut amener à des conséquences de dégradations des performances que notre choix voulaient annuler. L'impact de nombreuses pertes peut être plus important que les performances gagnées par les problèmes de latence surmontées, le résultat pourrait actuellement être plus lent que celui en FTP sur base TCP. Beaucoup de solutions de transferts en UDP mesurent les pertes pour accélérer les transmissions, mais dans un effort continuel de vouloir maximiser les débits, la perte de données est effectivement intentionnellement créée comme une technique de mesure. En plus de l'impact sur les transferts, la congestion et les pertes induites sont inamicales pour les autres trafics partagés sur les réseaux. Pour éviter cela, Digital Rapids C2 ne s'arrête pas seulement à déterminer la mesure des paquets perdus mais analyse aussi les conditions additionnelles du réseau en ajustant les débits selon. Une analyse plus profonde pour savoir comment améliorer l'efficacité des transferts du standard TCP dépasse certainement l'objet de cette étude. La clé incontournable est le fait de surmonter les limitations inhérentes à la transmission via TCP pour améliorer la distribution de contenus digitaux à travers un réseau public – ce qui n'est qu'un des aspects pour maximiser l'efficacité globale de la distribution. Deuxième étape: à propos de simultanéité Avec l'amélioration acquise des performances pour tout transfert entre deux points, il faut maintenant les étendre à des applications sur le terrain où les contenus sont distribués à beaucoup – voire des centaines – de destinations.
Idéalement la transmission multicast peut être utilisée afin de réduire significativement le nombre total de data transférés, avec des paquets transmis une seule fois côté émetteur et répliqués via le réseau autant que nécessaire pour atteindre chaque receveur. Chaque point de réception partage la même adresse réseau, la transmission des quantités de données est ainsi réduite car elle n'est pas répliquées pour chacun d'eux. La transmission multicast peut utiliser une technique de suivi de correction automatique des erreurs (FEC), attendu que des canaux unicast additionnels utiliseront la méthode des accusés de réception pour la correction de leurs erreurs. Bien que les transmissions multicast soient viables avec des réseaux privés terrestres en IP ou satellitaires, ils ne sont pas pratiques à mettre en œuvre au travers l'internet public car ils demandent une infrastructure réseau (routers inclus) entre l'envoyeur et les receveurs qui soit configurée en mode multicast. En conséquence l'envoi vers de multiples receveurs à travers l'Internet public se fait en autant de transferts unicast.
Un propriétaire ou un fournisseur de contenus qui doit les transmettre à un grand nombre de partenaires de distribution a la solution de l'envoi multicast (lorsqu'elle est possible) ensuite il choisira un modèle hybride – multicast satellitaire pour ceux qui peuvent le recevoir, multicast sur réseau IP (réseaux privés en IP), et envois multiples unicast pour tous ceux qui restent. L'application utilisée pour ces transferts devra obtenir les informations des capacités de réception dynamiquement pour chaque destination ou chaque utilisateur et parallèlement gérer des transferts hybrides mixtes pour atteindre d'une manière optimale toutes les destinations.
La clé de l'efficacité pour l'envoi de transferts multiples unicast passe par l'optimisation de la simultanéité des transferts. Ce qui est significatif dans de nombreux cas, c'est qu'un receveur à un endroit donné peut aussi devenir envoyeur. Comme exemple on peut prendre un studio local de télévision affilié comme receveur du réseau national, il peut devenir contributeur pour l'envoi, lors de la couverture d'évènements locaux, de médias vers des stations affiliées de la région. Dans ce cas, de multiples stations reçoivent les contenus provenant d'un point central, mais il y a aussi des transferts directs inter-stations.
Pour démontrer les différentes solutions et pour comprendre quels transferts sont les plus efficaces, nous allons choisir et évaluer différentes approches pour le multiple transfert unicast. Tous les scénarii sont basés sur une source A qui livrera un fichier à trois destinations B, C et D. En ce qui concerne la bande passante on considèrera que la sortie de A est au moins aussi importante que chaque flux entrant vers chacun des receveurs, (ce qui est en général le cas pour des envoyeurs qui distribuent beaucoup de données). Afin de simplifier la situation, nous considérerons que les connexions entre les points partagent les mêmes caractéristiques pour les pertes de paquets. Nous considérerons aussi que le système de transferts utilisé est optimisé pour palier à la latence et utilisera le réseau à 90%. Ces scénarii simplifiés mettent en scène un envoyeur pour des receveurs multiples; le concept pourrait être étendu à de multiples envoyeurs transmettant simultanément. Scénario 1: transferts simultanés non concurrents Dans ce scénario, les contenus sont transférés de A vers B, puis de A vers C et finalement de A vers D. C'est le moyen le moins efficace, sans simultanéité de transmission. Cette solution existe et est en usage avec une file d'attente pour des transferts qui se font « un à la fois ». Du point de vue de la performance, une telle approche peut être acceptable si tous les points ont la même bande passante ou si la bande passante de l'envoyeur est inférieure à celle des receveurs. Ce n'est pas forcément le cas lorsque l'envoyeur est le point central de transmission qui habituellement est celui qui possède la bande passante la plus élevée. Alors les débits de tels transferts sont limités par ceux des receveurs. Si l'envoyeur central à 45Mbps et chaque receveur n'a que 10Mbps, l'utilisation de la bande passante de sortie peut être inférieure à 25% durant le transfert. Un autre problème apparaît c'est que la durée global des transferts afin que tous les receveurs aient été livrés augmente avec le nombre de receveurs et ne prend pas en compte la bande passante de l'envoyeur. Sans durées précises, et dans bien des cas, la nécessité d'émissions simultanées vers les utilisateurs des points de distributions, rendent ce scénario impraticable. Scénario 2: En étoile avec un serveur central Dans ce scénario l'architecture est similaire à un réseau en étoile. Tous les envoyeurs et les receveurs ont accès à un serveur central. Un fichier de contenus est envoyé au serveur qui à son tour le distribuera à toutes les destinations. (figure 3)
Dans cet exemple, le fichier sera transmis de A vers le serveur, ensuite le serveur enverra le fichier vers les trois receveurs. Du point de vue de l'envoyeur cette solution peut-être avantageuse, car la quantité totale de « bonnes » données (Sans renvoi de paquets perdus, etc) transmises de A est égale à la taille du fichier comme dans une transmission multicast. D'un point de vue du système complet, le transfert vers le serveur augmente (par la taille du fichier) le total des bonnes données transférées. Ce qui sera négligeable si le nombre de receveurs est important, (pour cent clients la transmission en extra ajoute 1% à l'ensemble) attendu que le pourcentage sera plus significatif si le nombre des receveurs est petit. Jusqu'à 33%.
Cet exemple pourra être bénéficiaire si l'envoyeur A possède une bande passante limitée et ainsi devienne un goulet d'étranglement pour une livraison directe à un seul receveur. Dans cet exemple A est une source commune de distribution elle aura une bande passante dédiée considérable.
|  |
C'est un scénario dans lequel cette topologie en étoile peut être bénéfique si la liaison réseau de A coûte les yeux de la tête (Un réseau privé par exemple) ou une problématique de performance comme trop de pertes de paquets. Dans de tels cas, minimiser le transfert de A, fait soit réaliser des économies, soit augmenter le débit global. Comme nous l'avons dit précédemment, toutes les liaisons dans ces scénarii ont des caractéristiques identiques de pertes de données, ce second facteur n'intervient pas dans cet exemple, mais l'impact financier est toujours bénéficiaire. Cela ne coûte rien de connecter le serveur central à tous les serveurs et tous les receveurs ensemble, cela peut être la solution pour optimiser les débits du système global.
Ce scénario évite de faire face aux problèmes de simultanéité, en déplaçant les données de A vers le serveur central. L'efficacité du système est largement déterminé par la manière dont le serveur distribue les fichiers aux trois destinations réceptrices. Ce qu'il manque, ce sont les liaisons directes transversales, l'envoi d'un fichier de B vers C nécessitera un passage par le serveur, ce qui doublera le temps de transfert requis.
Scénario 3 : réseau en « En côtes de mailles » , « Mesh » en Anglais MediaMesh, tire son nom de cette particularité du réseau utilisé.
C'est ce troisième scénario que nous utilisons avec nos logiciels de transfert Digital Rapids C2. Ce réseau avec une topologie en côtes de mailles relie directement tous les points entre eux. (Figure 4) Les transferts de fichiers prennent place directement entre les lieux d'envoi et ceux de réception. En séparant la gestion du niveau système des opérations de transferts, un serveur central peut être utilisé comme monitoring entre chaque point de liaisons du réseau et pour contrôler ces points afin d'optimiser les transferts individuels bénéfiques pour la globalité des débits, mais sans que le serveur ne s'occupe de transfert de fichiers.
Désormais, cette topologie peut utiliser toute la bande passante disponible de A, gardant la totalité de toutes les « bonnes » données transférées en unicast à leur minimum tout en réduisant la durée générale avant que tous les receveurs aient reçu leur fichier. Cette architecture permet aussi la formation d'une topologie en étoile à l'intérieur de la côte de mailles où un récepteur fonctionne aussi de la même manière que le serveur du scénario 2. (figure 5) Le transfert de données vers ce receveur n'est pas une opération en plus, cependant il faut qu'il reçoive les fichiers quoiqu'il arrive. De plus, l'avantage potentiel du scénario 2 peut être maintenu lorsque A possède une bande passante limitée ou que les coûts de transit de A sont élevés. Cependant, comme tous les points sont connectés entre eux, des transferts additionnels inter points (comme un second transfert de B vers C ou un autre de C vers D)peuvent être facilement réalisés.
|  | Scénario 4 : réseau en côtes de mailles + points de réceptions partagés | C'est une extension au scénario 3, il faut considérer A, B, C, D, comme points de transfert « maîtres » situés à des endroits différents. Dans la solution C2 nous les considérons comme des moteurs de transfert. Comme nous l'avons déjà évoqué, les transferts individuels sur un réseau LAN ou même dans une même ville peuvent être plus efficaces que ceux où les distances sont beaucoup plus importantes à cause des facteurs de perte de paquets, par exemple. Si les réseaux privés sont utilisés pour des liaisons très éloignés, le coût de transfert vers un lien réseau local peut aussi être bien inférieur à ceux des longues distances. (ou gratuit pour les liaisons réseaux dans la même entreprise). Lorsqu'il y a des receveurs multiples, appelés clients dans la terminologie C2, connectés au même LAN, cette architecture permet de partager un moteur particulier en topologie en étoile. (figure 6) Le Moteur sert effectivement de serveur pour ce réseau local, le transfert du fichier se fait d'abord sur le Moteur, puis localement, du moteur vers les Clients. A moins que le moteur lui-même soit considéré comme un receveur , ce qui est possible, cela viendra améliorer la totalité des « bonnes » données transférées en rapport avec la taille du fichier, mais cela minimise le nombre de données transférées (potentiellement avec des performances inférieures et plus coûteuses) sur le réseau externe; tout cela en opposition avec l'envoi direct vers chaque client à partir de l'origine. |  | Conformation aux standards La section précédente s'applique à n'importe quel type de donnée. La distribution digitale de contenus doit être considérée différemment d'une distribution de fichiers standards. Les receveurs peuvent avoir différents besoins de conformation de leurs images avec des formats de compression, des formats de containers, des metadata. Rien qu'en regardant la variété des networks, il y a pléthore de marques et de modèles de serveurs de playout chacun avec des performances spécifiques - des formats de container comme les GXF, LXF, MXF ou MOV, avec en plus différents champs de metadata compatibles et/ou nécessaires.
La livraison de variantes des contenus directement du serveur d'envoi dans chaque format de sortie désiré (comme envoyer deux variantes, une GXF, l'autre MXF) peut retarder l'efficacité de la distribution et augmenter le nombre de données transférées, particulièrement avec le multicast ou avec le partage de moteurs intermédiaires (scénario 4) qui autrement auraient pu être utilisés. (figure 7A) |  |
| Le re-wrapping de media dans un conteneur différent est une opération sans perte. La capacité de conformer, un média transmis, en un autre format à sa réception (re-formatage de MXF en LXF par exemple) permet l'envoi d'un master commun sans risque de perte et qui économise l'envoi de variantes qui auraient du être acheminées séparément. (figure 7b) La capacité de conformer à la réception, au desiderata local nécessite historiquement l'utilisation de produits hétéroclites de transcodages provenant de différents fournisseurs, compliquant un peu plus le workflow. Digital Rapids MediaMesh, le systèmes de livraisons de contenus, intègre directement les fonctionnalités de re-wrapping et de transcodage dans l'outil de réception des fichiers. Dans certains cas les fichiers media reçus doivent être renvoyés sur bande, plutôt qu'une sortie vers un serveur en playout (VOD ou diffusion directe). C'est aussi une fonctionnalité intégrée dans la partie receveur, l'utilisation d'un outil de diffusion séparé dans un mode sans cassette nécessite souvent une étape de conformation des fichiers au format requis par le serveur. Une sortie en HD SDI est incorporée directement dans l'outil de réception MediaMexh RX. |  |
En plus des opérations de re-wrapping de fichiers, il y a aussi les nécessités de les transcoder en différents formats de compression, différentes tailles d'images et/ou différents débits. Des partenaires de distributions et leurs affiliés peuvent avoir les droits de diffusion pour la télévision locale en parallèle de leur site internet. Le transcodage entre différents formats de compressions pour les même types et les mêmes tailles d'images ( transcodage HD Mpeg-2 en H264 pour distribuer en IPTV par exemple) peut engendrer des erreurs de re-compression, il faut utiliser une source à gros débit pour atténuer ces problèmes, une source MPEG-2 en 50Mbps réduite en 6Mbps H.264. De la même manière, des contenus destinés à des débits et des résolutions inférieurs, pour un site web par exemple, peuvent être transcodés à partir d'une source en résolution supérieure sans perte de qualité visuelle significative. La capacité de recréation des éléments reçus, dès leur réception, élimine l'envoi de versions séparées pour chaque outil, et améliore l'efficacité des réceptions. Il y a bien sûr les situations où la qualité maximale doit être conservée, où la re-compression pourrait poser problème, où la création et les multiples envois de fichiers nobles sont nécessaires, il n'y a rien qui empêche d'inclure de tels envois dans l'outil de distribution.
A l'instar de beaucoup de serveur broadcast, certaines plateformes de diffusion réclament des métadata uniques. On les trouve par exemple dans des outils internet, en Digital Cinema ou pour des applications mobiles dont les données cachées sont descriptives et techniques. En tant que tel, la série des métadata compatibles avec le système de distribution doit être extensibles avec des données additionnelles uniques et les metadata distribués avec le package « Master »seront une super série de toutes les exigences de tous les destinataires. Cela nécessite que les metadata soient envoyés dans un format XML par exemple plutôt que dans le container standard du média.
Conclusion L'amélioration de l'efficacité de la distribution digitale de contenus passe par autre chose que l'accélération des performances de transfert avec optimisation des liaisons simultanées, elle passe aussi par la conformation locale via un système clé pour tirer tous les bénéfices d'une offre de livraison digitale.
Le logiciel de livraison digitale C2 par Digital Rapids associé à l'outil de distribution de contenus MediaMesh, combinent une architecture de transferts multi-destinataires efficace et « dimensionnable »; avec des outils de réception puissants; avec une automation intégrée de conformation et de ré-encodage (via TrancodeManager), laisseront l'organisation des médias offrir tous les bénéfices d'un service de livraison intégralement digital.
|
