Stretching the CDN
Network operators must dimension their content delivery network (CDN) correctly for an anticipated daily volume of video traffic but also be prepared to stretch to meet expected and unexpected peaks in demand. These are both complex design elements. Scaling, content-aware caching, virtualization, and the Elastic CDN can all play a part.
Let’s get ready to stretch the CDN.
Today, the benefits of content delivery networks are well known.
On the 1 hand, service providers are experiencing a huge surge in unicast video traffic from on-demand, catch-up TV, live-pause and replay, and cloud DVR services. All this from a multitude of fixed and mobile devices, meaning demand can come from anywhere in the network.
On the other hand, subscribers’ patience and attention spans are forever diminishing. How long do you put up with a spinning wheel when streaming a video?
The content delivery network solves these challenges by enabling slick on-demand and live TV services.
But like any other network, the CDN must be able to maintain a high quality of service at all times. That means coping with daily traffic as well as spikes in user demand, whether anticipated or not.
There are 2 secrets to getting this right: laying strong foundations with correct dimensioning to handle projected traffic and, like the elasticated waistband on a good pair of pants, being ready to stretch when more is required.
Dimensioning is about determining the fundamental aspects of the network such as storage capacity, throughput or bandwidth of each cache, and network topology (the number of sites, the number of caches per site, the characteristics of each cache, etc.).
Dimensioning is the single most critical aspect of designing a content delivery network. It’s a complex task that needs to consider a number of factors, as we’ll see below, and so the outcome is invariably different for each operator.
The goal is to deliver unicast traffic with a high quality of service in a cost effective way. Bad dimensioning leads to bad performance, a possible need to re-architecture the CDN in the future, and a definite decline in customer satisfaction.
Good dimensioning considers the following criteria.
- Network, i.e., fixed or mobile – Each has different constraints in terms of latency, throughput and packet loss.
- Devices – The higher the screen size and resolution, the higher the storage and throughput needed, so it’s important to consider the variety and quantity of different devices used by subscribers.
- Distribution of subscribers – Urban areas generate the most requests for content so will require more caches than rural areas. Strategically positioned caches in rural areas will help improve latency.
- Services – On-demand services put a premium on storage space while live content needs higher throughput.
- Content popularity – The latest blockbuster in a video-on-demand (VOD) service will have the highest concurrent demand but also a long tail with requests coming in for weeks or months. A catch-up TV service would have a more even spread of demand and a much shorter tail, typically only 7 days.
Where possible, an operator’s historical traffic data provides the starting point for analysis. Alternatively, Alcatel-Lucent IP Video Services can draw on best practices from an extensive installed base to make recommendations.
Dimensioning must also consider how the content delivery network can be scaled up over time as traffic increases.
Scaling requires additional caches to be deployed either at the edge of the network or between the edge and the origin server.
A 1st approach is to deploy caches in front of the origin server, protecting it from peaks in requests. In this case, it makes sense for the caches to be centralized, perhaps in the same location as the origin server. As traffic grows, an additional layer of caches can be deployed at the edge of the network, closer to subscribers, creating a hierarchy.
The characteristics of a cache are dependent on its role, position in the network, and how many requests it serves. Edge caches need high throughput to deliver content quickly while intermediary caches need more storage as they handle requests for less popular content.
If a subscriber requests content that is not cached at the edge, the request is forwarded to the intermediary cache. If the intermediary cache has the content, it will send it to the edge cache. If not, the request will go all the way to the origin server.
However, bear in mind that the closest cache is not always the best!
For example, traffic congestion in 1 part of the network can be avoided by selecting a different cache. Alternatively, varying cache selection can increase the lifespan of hard disks by reducing unnecessary duplication. The Alcatel-Lucent Velocix CDN has sophisticated content-aware cache selection algorithms that give plenty of scope to fine-tune performance based on:
- User location and proximity to serving locations
- Operator network topology and associated costs
- Geographic location and associated costs
- Loading on caches and POP router
To cache or not to cache
Content is distributed around a CDN based on its popularity. Only the most popular content is cached at the edge. It’s not cost-effective to cache everything at the edge as storage costs would outstrip the alternative of increasing bandwidth to deliver content from the origin. Slightly less popular content can be cached in the intermediary caches. Long tail content that is only requested occasionally remains in the origin.
Caching based on popularity is a completely automated process in the Velocix CDN. Let’s look at a real-life example from the launch of a VOD service.
When the service is launched, all the content is stored in and served from the origin. As end-user requests come in, content is cached at the edge. The content remains at the edge if there are multiple requests. If not, it is removed from the cache. Over time, most requests are served from the edge (blue line) while only a few requests go to the origin (green line), significantly reducing the load on the origin server and traffic across the network.
The same scenario for VOD can apply to live TV.
This is an example of content delivery network traffic for a South American operator during a semi-final of the Copa America soccer tournament in June 2015. Traffic increases dramatically just before kick-off (at 21:00), with a dip at half-time and another increase towards the end of the match.
The red egress line shows that most of the traffic is served from the caches at the edge of the network rather than the origin server. This has 3 effects:
- It protects the origin from too many requests that could potentially overwhelm it
- It reduces the network traffic in between the origin and the edge caches, saving bandwidth
- It improves the user experience by minimizing the delay and avoiding traffic interruption
The result of not being able to cope with this demand can be disastrous, as Yahoo! found out when streaming their first ever NFL game in October 2015.
To manage peaks in live TV, an operator must have anticipated the demand and installed enough capacity to deal with the traffic. That means, when traffic falls back to normal levels, there is spare capacity going to waste.
This is where virtualization can come into play.
With virtualization, the spare capacity installed to manage peaks in traffic is only spun-up (brought online) when necessary.
The software is decoupled from the hardware. This has an added benefit: the same generic compute and storage hardware can be used for other applications. This means service providers can manage a single pool of hardware, which:
- Reduces costs
- Shortens lead times
- Simplifies operations
When a traffic peak is anticipated or detected, the content delivery network spins-up virtual caches. The machines are released when traffic levels return to normal. As the machines are not continuously on standby, they consume less energy.
A more advanced implementation can be envisaged that allows the same hardware to perform more than one function. When TV traffic is low, these virtualized machines carry out applications that are non time-sensitive, such as offline VOD transcoding or billing calculations. The machines are switched to CDN caching duty only in times of peak traffic.
While this setup is harder to organize and implement, it provides a higher return on investment. In general, virtualization reduces total cost of ownership of the CDN, speeds up delivery time, and improves the user experience.
With this automatic scaling up and down, the CDN becomes “elastic”. Capacity can be changed in a matter of minutes, when and where necessary.
This is achieved through an orchestration layer. Information about the load at each CDN site (each site may contain 1 or more caches) is given to the orchestrator which then determines a threshold for when extra capacity is needed at that site. If a spike in traffic causes the spare capacity to dip below this threshold, 1 or more virtualized machines are spun-up.
For a planned TV event or daily peak-hour viewing, the orchestrator can be instructed to add enough capacity to cope with the anticipated increase in demand. If even more capacity is needed during the event, the system responds dynamically. And once demand has slowed, extra capacity is released for other applications or services.
Video consumption is more unpredictable than ever. The next blockbuster movie or TV series, the next viral YouTube video, the next major sporting upset or news event, may be just a few minutes away. But with comprehensive dimensioning, scaling, and preparing to stretch for the unexpected, a content delivery network will provide a solid foundation now and into the future.
Publishing and caching video article
Cloud DVR network article
Our authors look forward to your questions and comments.