Re: [FRnOG] Impact du P2P sur le traffic entrant/sortant des ISP (was: Pb Cogent/OpenTransit)
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/
Re: [FRnOG] Impact du P2P sur le traffic entrant/sortant des ISP (was: Pb Cogent/OpenTransit)
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/
Re: [FRnOG] Impact du P2P sur le traffic entrant/sortant des ISP (was: Pb Cogent/OpenTransit)
Bonjour, Sebastien Chaumontet wrote: Bon ok, après l'IPv6, ca fait encore une nouvelle fonctionnalité a implémenter. On fait les deux en même temps ? Je me demande si on n'a pas un vrai problème d'architecture devant nous avec le ftth qui arrive. Les lasers à 1Gbps à moins de 10$ sont en test de production, et ils seront à 10Gbps d'ici 1 ou 2 ans : la sortie de la maison n'est plus le goulot d'étranglement. Un département de 25 lignes à 1Gbps va representer 250Terabits/s dans chaque sens, soit potentiellement 500Tb/s de routage dans l'architecture actuelle. (et 5 000Tb/s avec des lignes à 10Gbps...) Bien sûr, il s'agit de capacité. Mais avec les fibres et une architecture locale bien pensée, on peut avoir cette capacité sans goulot d'étranglement dans le département. Faut-il/peut-on garder le routage actuel au dessus du département ? Peut-on faire sans peering local ? Bonne réflexion :-) -- __Bernard DUGAS __ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Impact du P2P sur le traffic entrant/sortant des ISP (was: Pb Cogent/OpenTransit)
On Tue, 2009-10-06 at 13:45 +0200, Radu-Adrian Feurdean wrote: On Tue, 06 Oct 2009 13:10:57 +0200, Raphaël Jacquot quelque part, le P2P ca ne génere qu'un traffic symétrique a 1Mbit par client. le reste des dailytube et youmotion est toujours tout autant assymétrique D'un cote tu as du 0.5-1 Mbps sortant en permanence (presque 24/24) due au P2P et/ou botnet D'un autre cote tu as plusieurs MBps entrants pendant 1-3 heures - le traffic legitime. Multiplie par 1 million d'abbones, ce peut eventuellement donner quelque-chose d'assez symetrique. [...] Je n'ai pas decortiqué les algos des logiciels P2P mais s'il y a un peu de jugeotte sur un echange de fichier (choisir des IPs proches ou constater un meilleur debit vers une IP donnee) le traffic entrant/sortant d'un ISP donné ne devrait pas suivre nb_participant * 1 Mbit/s mais plutot rester a quelques Mbit/s car le reste devrait se faire en interne entre les abonnés de l'ISP avec juste un fraction des clients qui vont chercher/fournir des données a l'exterieur de l'ISP. Techniquement (pour faire polémique) pénaliser juste un peu le traffic P2P entrant/sortant d'un ISP vers le reste du net devrait suffire a faire choisir en premier d'autres clients de l'ISP et donc faire un maximum de traffic interne, non ? Sinon pousser la communauté des developpeurs de logiciels P2P a integrer cette problématique d'une maniere ou d'une autre (publier des tables, des heuristiques sur les IPs, etc...). Je me trompe completement ? Quelle est la situation actuelle telle que vecue par les ISP vis a vis de cette problematique ? Laurent http://guerby.org/blog --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Impact du P2P sur le traffic entrant/sortant des ISP (was: Pb Cogent/OpenTransit)
Je n'ai pas decortiqué les algos des logiciels P2P mais s'il y a un peu de jugeotte sur un echange de fichier (choisir des IPs proches ou constater un meilleur debit vers une IP donnee) le traffic entrant/sortant d'un ISP donné ne devrait pas suivre nb_participant * 1 Mbit/s mais plutot rester a quelques Mbit/s car le reste devrait se faire en interne entre les abonnés de l'ISP avec juste un fraction des clients qui vont chercher/fournir des données a l'exterieur de l'ISP. Le problème est que les logiciels P2P n'ont pas d'algo de proximite correct - ping time au mieux. Et que les projets P4P sont encore au stade expérimental. Je sais qu' un ISP (eyeball) utilise seulement du DPI pour son transit car le traffic P2P interne est inexistant. Le jour ou cela changera je serai content car cela poussera vraiment les points d'interconnexion locaux. Thomas Techniquement (pour faire polémique) pénaliser juste un peu le traffic P2P entrant/sortant d'un ISP vers le reste du net devrait suffire a faire choisir en premier d'autres clients de l'ISP et donc faire un maximum de traffic interne, non ? En theorie, la theorie et la pratique sont identiques. En pratique, ça ne l'est pas. Quelle est la situation actuelle telle que vecue par les ISP vis a vis de cette problematique ? DPI mais chut c'est une secret !! Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Impact du P2P sur le traffic entrant/sortant des ISP (was: Pb Cogent/OpenTransit)
Bonjour, En lisant les différents messages, je vois qu'on est passé d'une problématique centralisée (youtube/dailymotion) à une problématique décentralisée (P2P + nextgen). Ce ratio de 4:1 ne signifie t'il pas que la bande passante globale proposée par le réseau P2P extra-ISP est 4 fois supérieure à celle proposée intra ? Cette bande passante est composée par quoi ? nombre de clients P2P ? accès ? autre ? Favoriser / contraindre les flux dans un même domaine ISP aurait, d'après vous, quels effets ? mis à part faire baisser encore plus la bande passante globale du réseau P2P... ce qui est contraire à l'objectif de ce type de réseau... Enfin par rapport aux prochaines générations de protocole P2P (cryptés, décentralisés, anonymat renforcé), le fameux DPI va t'il encore pouvoir être mis en oeuvre ? si non, quelle solution à plus long terme ? Que de questions Cordialement. Cyriac Ratio here 4:1 as well Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Impact du P2P sur le traffic entrant/sortant des ISP (was: Pb Cogent/OpenTransit)
Filtrer le P2P... Vaste programme ! Pour ceux qui connaissent un peu l'histoire des protocoles de transfert et communication P2P les plus connus, je crois qu'il y a une évidence : ceux qui marchent étaient simples à la base, et se sont alourdis de mesures anti-filtrage qui ont accaparé le temps de cerveau disponible de leurs développeurs respectifs, plus en tout cas que l'optimisation. 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. A contrario, pour privilégier la distribution et réplication du contenu rare, il faut prioritariser les transferts lointains. Mais puisque pour optimiser les ratios avec les voisins, il faut fournir un maximum de paquets sur les contenus les plus demandés, on se retrouve avec une race-condition. Un autre problème à annoncer le plus de contenu possible pour augmenter la probabilité de hit voisin, c'est : - Le besoin en capacité de stockage sur chaque noeud - 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) - Le besoin de chiffrement et discrétion car plus de contenu annoncé = plus de chances de diffuser un contenu potentiellement interdit au partage 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, ...) 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 (ou un protocole spécifique dont la signature sera carractéristique). Il serait alors facile de paralyser le système : forger des réponses ICMP foireuses au niveau des box. Enfin, les topologies de réseau peuvent différer du tout au tout en fonction des ISP, de leurs box, des mesures de filtrage en place, du média d'accès, de la politique de routage... Aucun intérêt sur le réseau FT de chercher un voisin sur le même LNS, puisqu'il est à 60ms minimum. 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. Sur un accès radio / 3G, on peut se retrouver avec des topologies très hétérogènes au sein du même réseau. La modélisation des optimisations pour chaque cas de figure impose une RD lourde et risque d'aboutir à une usine à gaz. Alors si on limite la spec à privilégier les échanges internes à un seul AS, ça semble simple, et ça peut arranger certains ISP, mais au détriment de la qualité globale (exhaustivité, performance et robustesse du réseau P2P). Si on cherche à optimiser tous les cas de figure, pfiouuu... Vaste programme ! Des volontaires ? -- Jérôme Nicolle --- Liste de diffusion du FRnOG http://www.frnog.org/