Le 29 juil. 2014 à 00:40, Vincent Bernat <ber...@luffy.cx> a écrit :

>> Tout a fait d’accord.  C’est un problème a géométrie hautement
>> variable, je te le concede volontiers.  Par contre, si une chose est
>> sure a 100% c’est qu’il est impossible de faire mieux que l’offload
>> que Netflix offre a travers ses appliances en passant par un
>> quelconque CDN traditionnel.
> 
> Netflix tombe à 0% quand la seule vidéo regardée dans la journée n'est
> pas dans le cache et représente 1000 vues. Un CDN traditionnel tombe à
> presque 99.9% dans le même cas. Juste pour dire qu'un CDN avec cache
> infini peut sans problème faire mieux que Netflix. Si le rapatriement
> initial de Netflix compte comme une vue (parce que ça prend quand même
> de la BP), un CDN avec cache infini fait toujours mieux.
> 
> J'ai pas d'avis dessus, mais sur NANOG, ils se sont bien étripés sur
> quelle méthode est plus efficace entre provisionner par avance et cacher
> au fil de l'eau. On peut comprendre que pour un petit provider, bouffer
> 1Gbps de sa BP sans vraiment être sûr que cela serve vraiment, ça peut
> faire douter. Tandis que cacher au fil de l'eau, on est au moins sur
> qu'il y a du monde qui regarde.

Sur de la « moyen-tail » (i.e. <= 1 à 2 vues / heure glissante sur une zone 
donnée), on peut
facilement atteindre 88-90% sur un CDN du commerce (Akamai, Edgecast, Level3, 
…), et
ce sur un catalogue de 40M+ vidéos encodées chacune en 4 à 9 qualités (suivant 
la qualité
de la vidéo en entrée), en mode « fil de l’eau », avec une garantie de 
time-to-first-frame
inférieure à 300ms.

En interne (équivalent de NFLX OC sur des PoP au « cul » des IX), on atteint 
des efficacités
de cache supérieures (ratio 1/30 à 1/40), car on contrôle mieux l’heuristique 
de mise en cache.
Un cache du commerce va chercher à cacher tout ce qui bouge, ce qui n’est pas 
forcément
la meilleure stratégie, et c’est bien pour cela qu’on envoie pas de la 
long-tail sur ce genre de
solutions (ça exploserait les coûts de feed pour une efficacité proche de 0 sur 
~85% des contenus).

Pour les boitiers au sein des réseaux d’opérateurs, le deal est win-win, 
surtout là où le transit
coûte 3 bras (Asie par ex.). Exemple : chez un opérateur qui pompe 20-30Gbps 
vers ses eyeballs,
on place 3-4 boitiers à 5-6k$ chacun (dans notre cas cela donne à peu près 
~30To de cache), ça
divise par 10 les besoins en feed et c’est rentabilisé en 2 mois.

Les boitiers (appro, livraison, télé-adminstration & maintenance) sont 
généralement à la charge du
fournisseur de contenu, le hosting (électricité/frigorie) et la bande passante 
« interne » au réseau
opérateur sont à la charge de l’opérateur.

Believe it or not, de très nombreux opérateurs sont prêts à « sauter le pas » : 
ça garantit qu’un
service populaire sera mieux délivré à leurs abonnés (qui auraient été le 
consulter de toute manière),
et ce pour un coût extrêmement faible (ce ne sont généralement pas les mètres 
carrés qui manquent).

Mais comme quelqu’un l’a évoqué plus haut, c’est « chacun pour sa g. » au 
niveau des déploiements
(pas de mutualisation entre les services, chacun gère son cache et son 
load-balancing applicatif
comme il l'entend). Brave world … ;-)

Cordialement,
Pierre-Yves



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

Répondre à