> Rémy Sanchez a écrit:
> J'objecte, ce qui disent les graphes (en moyenne) :
> - 10% du serveur
> - 33% en P2P
> - 57% en cache
> Donc ok seulement 1/3 du trafic est P2P, mais en fait ça fait
> un bon gros 3/4 des échanges réseau quand même.

Ca c'est de l'interpolation approximative sans avoir les vraies données. Tu 
arrives à des conclusions hâtives qui sont plus du domaine de la boule de 
cristal que des statistiques. Je ne dis pas que c'est faux, mais ça reste des 
devinettes.

Regarde les chiffres: 57% viennent du cache. En anglais, on dit qu'il y a un 
éléphant dans la pièce et que tu ne le vois pas. 

Le cache de Spotify est prédictif (en anglais: read-ahead, ceux qui configurent 
des cartes RAID seront familiers) (pour de bonnes raisons); par exemple, 30 
secondes avant qu'un morceau commence à jouer, le logiciel prédit que c'est le 
prochain morceau qui va jouer, et commence à charger les donnés. Il est donc 
facile de comprendre qu'une partie conséquente des requêtes servies par le 
cache n'ont été transférées dans le cache que quelques secondes avant que 
l'utilisateur ne les demande, ce qui est le but du cache prédictif. On lit en 
avance, comme ça quand le réseau à un hoquet, l'utilisateur ne s'en rend pas 
compte.

En simplifiant à mort, la raison pour laquelle on n'a pas 95% ou 98% de cache, 
c'est les mecs qui zappent comme des malades.

Là où tes conclusions sont du domaine de la boule de cristal, c'est que tu n'as 
aucune donnée qui te dit quel est le pourcentage du cache qui est rempli avec 
le P2P et celui qui est rempli avec le serveur (pardon, le "claoude"). Encore 
une fois, fais-moi voir des données réelles, pas du vent. P'têt ben que c'est 
la même chose, p'têt ben qu'non.



>> J'aimerais bien voir les stats de Spotify en ce qui concerne la
>> répartition intra-AS / extra-AS car jusqu'à présent j'ai rien vu de
>> bien concret. Là ou Spotify est bon c'est sur la qualité et ne pas
>> tuer l'upstream, mais en ce qui concerne l'optimisation du trafic...

> Spotify ne fait pas le tri directement en fonction de l'ASN, ils
> donnent une note d'utilité à chaque peer et s'en servent quand ils
> doivent supprimer des peers.

C'est là ou je ne suis pas convaincu. Pour le FAI, ce qui compte c'est la 
partie qui reste à l'intérieur de son AS, rien d'autre.


> Par contre regarde le RFC 5632, Comcast a bel et bien
> réussi ce genre de montage.

RFC5632, c'est comme IPv6. Quand plus de zéro pourcent du trafic sera optimisé 
par RFC5632, réveilles-moi. Entre un pair en Australie, un à 
Trifouilly-les-Oies (pas tellement moins loin, pour moi) et un à 50 km dans 
l'AS de mon FAI, je vais t'expliquer comment ça marche: la solution P2P qui ne 
me donne que les 50Kpbs du mec a coté de chez moi, je vais la dégager vite fait 
aux dépens de la solution qui suce en plus le Mbps de Toto de 
Trifouilly-les-Oies et les 500Kbps de Bob de Sydney.

Et le cache qui peut prédire que je veux voir un Marc Dorcel ou "Autant en 
emporte le vent", il n'existe pas encore.

Michel.

P.S. Pour ceux qui n'ont jamais vu ni un Marc Dorcel ni "Autant en emporte le 
vent", allez au cinoche, ou louez une vidéo, au lieu de lire.

---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à