Tracking Video QoS Just Got A Whole Lot Easier

If you follow this blog, you know we’ve mentioned before working with innovative customers to create a creative way to track video Quality of Service (QoS) metrics and make sense of them.

It’s exciting therefore to share that now anyone and everyone can track video QoS in Radar.

Video is fundamentally different to a lot of other online content: not only is it huge (projections are that in the next four or five years video will make up as much as 80% of Internet traffic), it is inherently synchronous. Put another way, your customer might not notice if a page takes an extra second or two to load, but they surely notice if their favorite prime time show keeps stalling out and showing the re-buffering spinner. So our new Performance Report focuses on the key elements that matter to viewers, specifically:

  • Response Time: how long it takes the content source to respond to a request from the intended viewer. Longer is worse!
  • Re-Buffering Ratio: the share of viewing time spent with the content stalled, the viewer frustrated, and the player trying to catch up. Lower is better!
  • Throughput: the speed at which chunks of the video are being delivered to the player after request. Faster is better!
  • Video Start Time: how long it takes for the video to start after viewer request. Shorter is better!
  • Video Start Failures:the percentage of requested video playbacks that simply never start. Lower is better!
  • Bitrate: the actual bitrate experienced by the viewer (bitrate is a pretty solid proxy for picture quality, as the larger the bitrate, the higher the likely resolution of the video). In this case, higher or lower may be better, depending on your KPIs.

Once you enable the tag for your account and add it to your video-bearing pages (see below), you’ll be able to track all these for your site. And, as with all Radar reports, you can slice and dice the results in all sorts of different ways to get a solid picture of how your service is doing, video-wise. Analyses might include:

  • How do my CDNs compare at different times of day, in different locations, or on different kinds of device?
  • What is the statistical distribution of service provided through my clouds? Does general consistency hide big peaks and valleys, or is service generally within a tight boundary?
  • What is the impact of throughput fluctuations to bitrates, video start times, or re-buffering ratios? What should I be focused on to improve my service for my unique audience?

In no time, you’ll have a deep and clear sense of what’s going on with video delivered through your HTML5 player, and be able to extrapolate this to make key decisions on CDN partnering, cloud distribution, and global server load balancing solutions. The ability to really dig down into things like device type and OS – as well as the more expected geography, time, delivery platform, and so forth – means you’ll be able to isolate issues that are not, in fact, delivery-related: for instance, it is possible to see a dip in quality and assume it’s cloud-related, only to discover, in drilling down, that the drop occurs on only one particular device/OS combination, and thus uncover a hiccup in a new product release.

So here’s the scoop. Collecting these QoS metrics isn’t just easy – it’s free, just like our other Radar real user measurements. With the video QoS, you’ll be tracking your own visitors’ experiences, and be able to compare them over time.

The tag works with HTML5 players, running in a browser, and it’s unsurprisingly takes a bit more planning to implement than our standard tag, so you’ll likely want to drop us a line to get started. We’ll be delighted to help you get this up and running – just contact us by going to your Portal and navigating to Impact -> Video Playback Data, then clicking the Contact button..

What Can Metrics Tell Us About Internet Video Delivery?

Over the last year or so, we’ve been working with some innovative streaming video leaders to collect and analyze the Quality of Experience (QoE) their consumers have been receiving. Using the results of several billion streams, we can start to see some fascinating trends emerge.

This data was collected through an updated (and still free!) Radar Community tag, which collected video-specific QoE metrics from HTML5 player elements, across 10 video service providers in Q4 of 2016, who served both live and video-on-demand (VOD) assets to audiences all around the world.

Let’s start with a thoroughly unsurprising result: higher throughput is distinctly correlated with higher bitrates:


That said, we can also say that the return for getting from below 10K kbps to above that line is significantly greater than getting from below 30K to above. Importantly, we can also see that the largest clusters of chunks occur below and around 10K, so focusing on improvement here will have the most significant impact on customer viewing.

We see a not-dissimilar result when we compare throughput with video start failures (VSF). More throughput is very highly correlated with low video start failures:


Once again, getting to above 10K kbps brings the greatest benefit, dropping VSF from a peak of 9% to a more manageable 4%. Doubling the throughput roughly halves the VSF, though the benefits are more modestas speeds exceed 30K.

Less obvious is the degree to which using multiple CDNs can measurably impact the QoE of users. Take a look at the following graph, which compares the Latency of two CDNs across a 7-day period:


CDN1 (in red) shows a very consistent series of results, with only a couple of spikes that really catch the eye. By contrast, CDN2 (in green) shows way more spikes, a couple of which are quite striking, and a clear pattern of higher latency. Based on this very high level view, one might conclude that the incremental benefit of distributing traffic across the two providers would be relatively low. However, look what happens when we double-click and look at a single day:


From midnight to around 5am, CDN2 is by far the superior option – and, tantalizingly, appears to become so again right around 11pm. This might be the perfect example of a situation in which some time-based traffic distribution could deliver QoE improvements. And, assuming the CDNs bear different cost structures, there may very well be an opportunity here to arbitrage some costs and improve margins.  Finally, let’s dig into what happens during a single, rather troublesome hour:


Note that for this particular hour, CDN2 is outperforming CDN1 for around about 50 minutes, meaning that from a pure QoE perspective, we would probably prefer traffic to be sent via CDN2 than CDN1. This is something that would be effectively impossible to spot at the 7-day level, but by digging in deeply, it becomes clear that distributing our traffic across these two CDNs would result in detectable differences for users.

And what would that bring us? Using one more graph, we can see the relationship between latency and video start time (VST):


Unsurprisingly lower latency results in lower VST – which, you can be sure, will in turn contribute to higher VSF. Or, in more direct terms, will mean less people consuming video, and therefore seeing less ads, or becoming increasingly less likely to renew a subscription.

Real User Measurements (RUM) that are tracked through the Cedexis Radar Community provide a powerful set of signposts for how to deliver traffic most effectively and efficiently through the Internet. Adding video-specific metrics helps ensure that the right decisions are being made for a sparkling video experience.

To find out more about adding video metrics for free to your Radar account, drop us a line at <>.

Network Resilience for the Cloud

If we’ve learned nothing else over the last few weeks, it has been that the Internet is an unruly, inherently insecure network. The ups and downs of Dyn – taken offline by hackers, yet subsequently purchased for what appears to be north of half a billion dollars – remind us that we are still a generation or two away from comfortable consistency. More importantly, they remind cloud businesses that they are relying upon a network over which they have only limited control.

Peter Deutch and others at Sun Microsystems proposed, a number of years ago, the Fallacies of Distributed Computing.  They are:

  1. The network is reliable.
  2. Latency is zero.
  3. Bandwidth is infinite.
  4. The network is secure.
  5. Topology doesn’t change.
  6. There is one administrator.
  7. Transport cost is zero.
  8. The network is homogeneous.

The briefest look through this list tells you that these are brilliantly conceived, and as valid today as they were when first introduced in 1994 (in fairness, number 8 was added in 1997). Indeed, turn them upside down and you can already see the poster to go on every Operations team’s wall, reminding them that:

  1. The Internet is inherently unreliable
  2. Internet latency is a fact of life, and must be anticipated
  3. Bandwidth is shared, precious, and limited
  4. No Internet-connected system is 100% secure
  5. Internet topology changes quicker than the staircases at Hogwarts
  6. There are so many administrators of the Internet there may as well be none
  7. Transport always has a cost – your job is to keep it low
  8. The Internet consists of an infinite number of misfitting pieces

In a recent paper commissioned by Cedexis from The FactPoint Group, a new paradigm is proposed: stop building fault-tolerant systems, and start building failure-tolerant systems. Simply stated, an internally-managed network can be constructed with redundancy and failover capabilities, with a reasonable goal of near-100% consistent service.  Cloud architectures, however, have so many moving parts and interdependencies, that no amount of planning can eliminate failures. Cloud architecture, therefore, requires a design that assumes failures will happen and plans for them.


(Click here if you’d like to read the paper in full)

This means there’s more to this than load balancing – we’re really talking about resource optimization. Take, for example, caching within a private cloud. First, we can use a Global Traffic Manager (GTM) to maximize Quality of Experience (QoE) by routing traffic along the pathways that will deliver content the most quickly and efficiently. Secondly we can use intelligent caching to protect against catastrophic failure: a well-tuned Varnish server for instance, can continue to serve cached content while an unavailable origin server is repaired and put back into service. In a situation where DNS services are down, the GTM can use Real User Measurements (RUM) to spot the problem, and direct requests to the right Varnish server (and, in case DNS is down, a well-constructed decision set can contain IP addresses for emergencies). The Varnish server can check for the availability of its origin and, if DNS problems prevent it from sourcing fresh content, can serve cached content.

Will this solve for every challenge? Assuredly not – but the multi-layered preparation for failure greatly improves our chances of protecting against extended outages. Meanwhile, the agility that is adopted by Operations teams as they prepare for failure means a more subtle, sophisticated set of network architectures, which lend themselves to way greater resiliency.

As applications increasingly become a tightly-knit conglomeration of web-connected services and resources, planning for failure is not a choice, it is an imperative. Protecting against the variety of threats to the shared Internet requires agility, forethought, and the zen-like acceptance that failure is inevitable.

In2White, ou comment gérer les pics de traffic et la diffusion de contenus très lourds pour assurer la réussite de votre projet en ligne

Quoi de plus frustrant que de mener à bien un beau projet qui vous tient à cœur pour être ensuite confronté à des problèmes techniques ?

En juin dernier nous avons eu la chance de rencontrer Filippo Blengini qui s’apprêtait alors à sortir un projet assez incroyable.

Snow Mountain

Passionnés de photographie, Filippo et son équipe ont eu la chance de passer du temps aux abords du MontBlanc, le plus haut pic des Alpes. La majesté du lieu n’a pas manqué de leur inspirer l’envie de la partager et de la célébrer avec les internautes du monde entier.

Il leur a semblé que le meilleur moyen d’atteindre ce but nécessiterait de créer la plus grande photo imaginable qui saisirait à la fois l’immensité inouïe et les détails étonnants qui rendent ce panorama exceptionnel.

Cela n’a pas été une mince affaire pour Filippo et son équipe qui ont alors assemblé pas moins de 70,000 clichés HD afin de réaliser une seule immense photo d’une qualité d’image à couper le souffle. Cette photographie interactive donne aux visiteurs la possibilité de découvrir le lieu grâce à ses 14 niveaux de zoom, chacun offrant la meilleure résolution possible.

Dès lors le danger était malheureusement devenu très clair : Chaque connexion sur le site In2White allait engendrer des transferts de données de 30 mégaoctets en moyenne. Comment allaient-ils s’assurer de la fluidité de l’expérience utilisateur et éviter que le site ne plante sous le poids des fichiers ? De telles complications auraient pu gravement nuire au succès du projet de l’équipe In2White.

De plus, un second problème dû aux conditions de publication allait faire surface. En effet, une forte couverture médiatique était à prévoir et entrainerait des pics de trafic au court des premières semaines suivant la parution du projet. Non seulement l’importance de ces pics était imprévisible mais la provenance des visiteurs était elle aussi fortement incertaine.

Filippo s’est alors naturellement tourné vers Cedexis afin de mettre en place une solution qui lui permettrait de ne plus s’inquiéter des problèmes techniques qui pourraient affecter la réussite de son projet.

Avec Radar notre outil de monitoring crowdsourcé depuis les utilisateurs finaux associé à Openmix notre solution de load-balancing en temps réel nous avons permis à Filippo de dormir sur ses deux oreilles sans avoir à s’inquiéter des performances de son site web.

En seulement quelques semaines le site de in2White avait atteint plus de 3 millions de vues avec une audience venue du monde entier. Grâce à Radar et Openmix chaque visite s’est transformée en une expérience unique et fluide.

Vous souhaitez en savoir plus sur le travail de Cedexis qui a fait du projet In2White un réel triomphe ? Téléchargez notre étude de cas ici.

[Comment faire] Maintien d'une session grâce au routage DNS

Solution locale

Nombre d’applications exige que chaque requête HTTP, venue d’un client, soit dirigée vers le même serveur ou la même instance Cloud. On appelle cela la persistance de session.

Il est courant que les applications Web ne partagent pas leur “état” entre différents serveurs ou stockages de données. On utilisait jusqu’alors des répartiteurs de charge matériels tels que ceux fournis par F5 et Brocade, ou, plus récemment, l’Elastic Load Balancer d’Amazon. Cependant, les développeurs d’application et responsables d’infrastructures cherchent à adresser une audience plus étendue mondialement et à déployer leurs applications vers de multiples centres de données. Il devient alors nécessaire d’assurer la persistance de session à la fois mondialement et localement.

Pensée mondiale

Nous avions évoqué dans un article précédent la tendance “actif-actif” dans le design d’applications. Une application active-active peut répondre à toute requête, venue de n’importe quel visiteur, depuis n’importe quel centre de données et à tout moment. L’utilisateur peut très bien être dirigé en pleine session vers un autre centre de données de façon tout à fait transparente.

En revanche, certaines applications nécessitent des données personnalisées en temps réel ; des données qui peuvent mettre du temps à se synchroniser entre plusieurs centres de données différents. Dans ce cas, s’il est tout à fait envisageable de diriger l’utilisateur d’un centre de données à un autre en milieu de session, il peut toutefois subir des baisses de performance ou connaitre un confort d’utilisation dégradé tandis que s’effectuent les transferts de données en tâche de fond. Parmi les exemples d’applications de ce genre, on peut citer les réseaux publicitaires, qui se servent de données en temps réel sur nos comportements en ligne pour déterminer quelles impressions de pub seraient les plus pertinentes pour nous. Certaines applications de jeu peuvent de la même manière, s’appuyer sur des types d’interactions similaires afin d’améliorer la jouabilité.

Le coût d’un transfert

Ce type d’application paye donc le prix du temps de transfert des données d’un centre de données à l’autre. De toute évidence, les utilisateurs devraient être dirigés vers le centre de données affichant les meilleures performances pour lui. Mais alors, que faire si les performances entre le FAI/réseau d’accès et le centre de données se dégradent?

Il faudrait établir un seuil à partir duquel les besoins de chaque application seraient remplis. Le transfert d’un centre de données à l’autre ne s’enclencherait que si les performances étaient réellement meilleures en fonction de ce seuil, ou si le centre de données initial se voyait dans l’incapacité de servir la demande.

Eviter les nœuds

Les clients les plus concernés sont ceux qui ont le choix, en s’appuyant par exemple sur les mesures Cedexis Radar, entre différents prestataires. Le pire comportement envisageable pour une solution de GSLB serait de littéralement jouer au “flipper”, c’est-à-dire de diriger un utilisateur entre des destinations multiples durant une même session. Il nous faut alors envisager une façon d’éviter les nœuds de manière consistante pour assurer une distribution fluide entre les centres de données.

Le Consistent Hashing pour une répartition de charge définie par les Applications

L’aiguilleur de trafic Openmix conçu par Cedexis est suffisamment flexible pour s’atteler à la tâche, utilisant les données de performance Radar avec l’algorithme de “consistent hashing” conçu par le MIT dans les années 1990.

Les clients peuvent laisser Radar déterminer quel centre de données sera le moins performant selon le FAI utilisé par l’utilisateur final. Imaginons par exemple qu’un client dispose de deux centres de données, l’un a Chicago et l’autre à Dallas. Il est évident que certains utilisateurs feraient mieux de passer par Chicago tandis que d’autres seraient préférablement routés sur Dallas. Il est alors très simple de réaliser cet aiguillage avec l’application Openmix standard “Optimal Round Trip Time”.

Mais si le FAI de l’utilisateur est pile à mi-chemin (du point de vue Internet) entre ces deux centres ? A l’aide d’un seuil de variance, nos clients peuvent clairement définir ce que sera un “nœud” de trafic. En implémentant l’une des solutions de Consistent Hashing (hacher les données de la même manière, suivant un même algorithme) disponibles sur le marché, Openmix peut s’assurer que les nœuds seront toujours défaits de la même manière. On peut ainsi garder tous les bénéfices du routing suivant les performances Radar tout en assurant la persistance de session.

Voici un exemple d’implémentation que nous avons créé… N’hésitez pas à regarder et à nous demander de l’aide pour concevoir votre propre application.