Salut, permettre l'usage du multicast à l'utilisateur ne serait pas la solution qui sonnerait la fin de ce bricolage qu'est le P2P ? Les utilisateurs verront vite le gain en performance, donc je ne me fait pas trop de soucis pour leur migration rapide des applications sur cette techno.
Quand je parle de multicast à cette échelle c'est qqchose de scalable, donc pas d'ASM mais plus du SSM. Bon ok, après l'IPv6, ca fait encore une nouvelle fonctionnalité a implémenter. On fait les deux en même temps ? -- Seb 2009/10/7 Thomas Mangin <thomas.man...@exa-networks.co.uk>: >> Le principe dont on parle, trouver le contenu à un nombre minimal de >> hop, a une contrepartie majeure : il faut dupliquer le contenu pour >> maximiser les chances de le trouver. Et annoncer tout le contenu >> disponible depuis chaque point du réseau. > > Sans parler de certains réseaux qui utilisent MPLS de l'exchange a leur > point de concentration ce qui fausse tout. > >> A contrario, pour privilégier la distribution et réplication du >> contenu rare, il faut prioritariser les transferts lointains. > > Les algos la aussi sont naïfs. Ceci dit, les clefs et le contenu pourrait > être dissocie et autant que je sache ce n'est pas le cas. > >> - Capacité de stockage à combiner avec une robustesse suffisante pour >> supporter assez d'IOPS (emule tue les disques durs, plus que >> bittorrent, à cause du nombre de transferts simultanés possibles et >> des seek que ça crée sur les têtes de lecture) > > SDD est la !.. Yaca attendre un peu :) > >> Qui dit chiffrement et discrétion (pour passer au travers des DPI) dis >> complication de l'algorithme et possible réduction de l'efficacité en >> taux de transfert pur (overhead, leurres, ...) > > Oui, réduction du transfert effectif, pas du traffic. On risque de voir le > P2P utuliser encore plus de bande passante rien que pour echapper au DPI ! > >> Implémenter une recherche en prioritarisant les échanges sur les >> voisins impose aussi une exploration de la topologie du réseau, qui se >> fait via ICMP à priori > > A mon avis elle se fait par l'analyse des entrées RIPE, que tu diffuse via > P2P a tous les clients. > Si deux entrees on le meme MNT, c'est le meme reseau, ca seul ca devrait > aide beaucoup. > >> Aucun intérêt sur le >> réseau FT de chercher un voisin sur le même LNS, puisqu'il est à 60ms >> minimum. > > Je me demande quel traffic engineering ils ont !! > >> Sur un réseau câble, puisque l'upstream est réduit et >> mutualisé, il faut être très vigilant à ne pas interférer avec les ups >> rare des voisins. > > Merci, j'avais rate ca !! > > Cette presentation est interressante (et essayer de comprendre comment > passer la fonctionalite en v6 encore plus ;p) > http://www.peering-forum.eu/assets/Presentations/briscoebtqosinterconnect.pdf > > L'idee est de mettre la "back pressure" sur le traffic responsable de > congestion et lui seulement afin de mieux utiliser les liens sans les > saturer. > > Thomas--------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
