Re: [FRnOG] Impact du P2P sur le traffic entrant/sortant des ISP (was: Pb Cogent/OpenTransit)

2009-10-07 Par sujet 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/



Re: [FRnOG] Impact du P2P sur le traffic entrant/sortant des ISP (was: Pb Cogent/OpenTransit)

2009-10-07 Par sujet Sebastien Chaumontet
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)

2009-10-07 Par sujet Bernard Dugas

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)

2009-10-06 Par sujet Laurent GUERBY
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)

2009-10-06 Par sujet Thomas Mangin

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)

2009-10-06 Par sujet Cyriac REMY
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)

2009-10-06 Par sujet Jérôme Nicolle
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/