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)
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 ?
Cela veut dire que l'on voit nos eyeballs manger 4 fois plus de trafic
qu'il n'en produisent.
Cette bande passante est composée par quoi ? nombre de clients P2P ?
accès
? autre ?
je n'ai pas regarde mes stats netflow depuis un paquet mais nbar est
mon ami - voici un de mes VC.
maintenant, avant que vous demandiez - kazaa est mal classifie, ce
n'est pas si populaire :D
Et le GRE c'est car on a un produit de "bonding" utilisant GRE.
7301-1.u3.tcw.uk#show ip nbar protocol-discovery stats byte-count top-n
GigabitEthernet0/0.27
InputOutput
Protocol Byte Count Byte Count
http 3232789187498263036385726
kazaa2 2545540724875921382923294
gre 1059039908223287721559628
secure-http 206821864543 119009865112
smtp 168733511287 135662009956
exchange 132035921484 106277586578
ipsec118278253185 119987106224
bittorrent 65910595759 14045134049
telnet 55730722814 55671816310
ssh 35780458729 45627741426
ftp 40919513007 29777671703
rtp 25218057004 26880020180
icmp 21644825140 21402772638
realaudio33005151386 1687983052
secure-imap 8902127230 16830043475
netbios 10323262432 12433292340
pop3 14188006721 7396298142
custom-0112395195601 4014030220
sqlserver6315658485 5324085330
socks4342373748 3547216576
dns 4190587514 3236822068
snmp 5543968651 1256557636
nntp 6137031284 139611195
pptp 2860007303 2357778091
imap 2200920603 2428726298
secure-pop3 4152268384 197318653
xwindows 1821057462 1669674992
napster 2457594111 773074529
netshow 1409001637 211741597
gnutella 879555777313658526
novadigm 953719207195771635
notes702836708248982760
syslog 8820 865989047
sqlnet 422877573159355382
streamwork 350771714225902720
citrix 409380274137240855
ntp 174891405245817078
pcanywhere 157943419256618769
fasttrack29432340127318753
vdolive 21610914432322611
nfs 15723927314648604
tftp 13270668424549438
l2tp 70157119 68860931
custom-0244805607 44133088
cuseeme 44970078 2944553
rsvp 14371323 19624899
ldap 21549737 8086367
ipinip 12419310 12419310
kerberos 8596520 4185961
sunrpc 6383430 3764524
gopher 6124626 981923
rcmd 1499635 5006997
unknown 727904631166 396429286749
mis à part faire baisser encore plus la bande
passante globale du réseau P2P...
Aucun ??
L'idéal en P2P c'est que le traffic entre client reste dans le même
échange, la` c'est le jackpot.
Spotify - PLEASE MAKE IT HAPPEN :D !!!
Si ton reseaux n'est pas centralise sur Paris cela peut permettre de
ne pas saturer des liens en ralentissant certain protocoles. Il y a
des kits DSL avec DPI integre (Redback a une carte pour SmartEdge -
par example. Comme tu vois NBAR peut aider - si tu as assez de CPU et
peut vivre avec les erreurs de classification - ce qui est mon cas
mais surement pas le cas de tout le monde.
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
êt
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 R&D 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/
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 : >> 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)
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 ?
Cela veut dire que l'on voit nos eyeballs manger 4 fois plus de trafic
qu'il n'en produisent.
Cette bande passante est composée par quoi ? nombre de clients P2P ?
accès
? autre ?
je n'ai pas regarde mes stats netflow depuis un paquet mais nbar est
mon ami - voici un de mes VC.
maintenant, avant que vous demandiez - kazaa est mal classifie, ce
n'est pas si populaire :D
Et le GRE c'est car on a un produit de "bonding" utilisant GRE.
7301-1.u3.tcw.uk#show ip nbar protocol-discovery stats byte-count top-n
GigabitEthernet0/0.27
InputOutput
Protocol Byte Count Byte Count
http 3232789187498263036385726
kazaa2 2545540724875921382923294
gre 1059039908223287721559628
secure-http 206821864543 119009865112
smtp 168733511287 135662009956
exchange 132035921484 106277586578
ipsec118278253185 119987106224
bittorrent 65910595759 14045134049
telnet 55730722814 55671816310
ssh 35780458729 45627741426
ftp 40919513007 29777671703
rtp 25218057004 26880020180
icmp 21644825140 21402772638
realaudio33005151386 1687983052
secure-imap 8902127230 16830043475
netbios 10323262432 12433292340
pop3 14188006721 7396298142
custom-0112395195601 4014030220
sqlserver6315658485 5324085330
socks4342373748 3547216576
dns 4190587514 3236822068
snmp 5543968651 1256557636
nntp 6137031284 139611195
pptp 2860007303 2357778091
imap 2200920603 2428726298
secure-pop3 4152268384 197318653
xwindows 1821057462 1669674992
napster 2457594111 773074529
netshow 1409001637 211741597
gnutella 879555777313658526
novadigm 953719207195771635
notes702836708248982760
syslog 8820 865989047
sqlnet 422877573159355382
streamwork 350771714225902720
citrix 409380274137240855
ntp 174891405245817078
pcanywhere 157943419256618769
fasttrack29432340127318753
vdolive 21610914432322611
nfs 15723927314648604
tftp 13270668424549438
l2tp 70157119 68860931
custom-0244805607 44133088
cuseeme 44970078 2944553
rsvp 14371323 19624899
ldap 21549737 8086367
ipinip 12419310 12419310
kerberos 8596520 4185961
sunrpc 6383430 3764524
gopher 6124626 981923
rcmd 1499635 5006997
unknown 727904631166 396429286749
mis à part faire baisser encore plus la bande
passante globale du réseau P2P...
Aucun ??
L'idéal en P2P c'est que le traffic entre client reste dans le même
échange, la` c'est le jackpot.
Spotify - PLEASE MAKE IT HAPPEN :D !!!
Si ton reseaux n'est pas centralise sur Paris cela peut permettre de
ne pas saturer des liens en ralentissant certain protocoles. Il y a
des kits DSL avec DPI integre (Redback a une carte pour SmartEdge -
par example. Comme tu vois NBAR peut aider - si tu as assez de CPU et
peut vivre avec les erreurs de classification - ce qui est mon cas
mais surement pas le cas de tout le monde.
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
êt
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 R&D 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/
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 : >> 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/
