§2.6.4Case Studies — Netflix and YouTube

Application layer Kurose & Ross pp. 149–151 · ~14 min read

  • push caching
  • pull caching
  • content distribution network
  • manifest file

Where you are

  • Application layer you are here
  • Transport layer
  • Network layer
  • Link layer
  • Physical layer

Netflix and YouTube both run enormous private content distribution networks, and they disagree about almost every mechanism inside them.

Words you will meet

  • Push caching — content is copied out to the caches in advance, during quiet hours.
  • Pull caching — a cache fetches content the first time somebody asks for it.
  • Manifest file — the list telling the player which versions exist and where each one is.
  • DASH (Dynamic Adaptive Streaming over HTTP) — the client measures its own throughput and picks a version chunk by chunk.

Why this matters

Section 2.6.3 gave you a menu of choices: private or third-party, enter deep or bring home, push or pull, which cluster and how to steer clients to it.

These two case studies show the menu being ordered from twice, differently, by two companies of comparable size. That is the value of reading them side by side. Neither is doing it wrong, and being a huge private CDN determines none of the answers.

Netflix

As of 2020 Netflix was the leading service provider for online movies and TV series in North America. Its video distribution has two major components: the Amazon cloud, and its own private CDN (Content Distribution Network) infrastructure.

What the Amazon cloud does

Netflix has a website handling registration and login, billing, the catalogue for browsing and searching, and the recommendation system. That website and its back-end databases run entirely on Amazon servers. The Amazon cloud also handles three critical functions:

FunctionWhat happens
Content ingestionNetflix receives studio master versions of movies and uploads them to hosts in the Amazon cloud.
Content processingMachines there create many formats for each movie, suitable for players on desktops, phones and game consoles. A different version is created for each format and at multiple bit rates, which is what makes DASH possible.
Uploading to the CDNOnce all the versions exist, hosts in the cloud upload them to Netflix’s own CDN.
Figure 2.26 — the Netflix video streaming platform
1 hops: Amazon cloud → CDN server
Amazon cloud — website, billing, ingestion, processingNetflix’s own private CDNupload versionsupload versionsupload versionsmanifest filevideo chunks (DASH)Amazon cloudCDN serverCDN serverCDN serverClient

Drag any device to rearrange the picture. Hover a link to see its rate, delay and length.

Two arrows arrive at the client, from two different places. Play them and notice that the one carrying the video does not come from the cloud.

Read this diagram as text
  • Amazon cloud wired link CDN server
  • Amazon cloud wired link CDN server
  • Amazon cloud wired link CDN server
  • Amazon cloud wired link Client
  • CDN server wired link Client

Two arrows reach the client, and only one carries video

Look at what arrives from where. The manifest file comes from the Amazon cloud. The video chunks come from a CDN server.

The Amazon cloud never carries a frame of video to a viewer. It ingests, processes, decides, and hands over. Everything the viewer actually watches travels a completely different path.

What the CDN is made of

Netflix began streaming in 2007 using three third-party CDN companies. It has since built its own, and now streams all of its videos from it.

What a Netflix rack is, and where they are
How muchWhy it is that way

Cells marked ⓘ have an explanation — click to read it. Sortable columns have a ↕ in the heading.

The numbers matter here: they show what "a CDN" actually costs to own.

In plain words

Netflix does not use pull caching . It uses push caching : videos are pushed to the CDN servers during off-peak hours, rather than fetched on a miss.

For locations that cannot hold the entire library, Netflix pushes only the most popular videos, and which ones those are is determined day by day.

That is only possible because somebody is deciding in advance. Hold that thought for the YouTube half of this section.

Pressing play

What happens when you press play
1 — You browse and choose a filmstep 1 of 5
Your deviceNetflix software, Amazon cloudbrowse, search, log in

The catalogue, the search, the recommendations and the login all come from Amazon servers. Nothing about this part involves the CDN.

Five steps. Two of them are decisions made by software you never see, in a data centre on another continent.

Read all steps as text
  1. 1 — You browse and choose a filmThe catalogue, the search, the recommendations and the login all come from Amazon servers. Nothing about this part involves the CDN.
  2. 2 — Which servers have this film?The Netflix software running in the Amazon cloud first determines which of its CDN servers hold copies of the movie. Not every location holds everything, so this is a real question rather than a formality.
  3. 3 — Which of those is best for you?Among the servers that have the movie, the software determines the best one for this client. If the viewer’s residential ISP has a Netflix rack installed and that rack holds a copy, a server in that rack is typically chosen. If not, a server at a nearby IXP is.
  4. 4 — The cloud tells your device where to goNetflix sends the client the IP address of that specific server, together with a manifest file listing the URLs for the different versions of the movie. No DNS redirect is involved at any point.
  5. 5 — Your device talks to that server directlyThe client and that CDN server interact using a proprietary version of DASH. The client uses the byte-range header in HTTP GET requests to fetch chunks of about four seconds. While they download, it measures the throughput it is receiving and runs a rate-determination algorithm to choose the quality of the next chunk.

No DNS (Domain Name System) redirect — and why Netflix can skip it

Section 2.6.3 showed the DNS redirect that most CDNs use, and it is genuinely clever. Netflix does not use it.

The reason is worth understanding. Netflix’s CDN distributes only video, not web pages. A third-party CDN such as the book’s KingCDN serves arbitrary content for many customers, and DNS is a neutral way to steer clients without either party knowing the other’s business. Netflix has no such problem: its own software already knows which racks hold which film and where the viewer is, so it simply says which server to use.

Being able to simplify is a consequence of doing less. That is a general lesson, not a fact about Netflix.

YouTube

With hundreds of hours of video uploaded every minute and several billion views per day, YouTube is the world’s largest video-sharing site. It began in April 2005 and was acquired by Google in November 2006.

The Google and YouTube design and protocols are proprietary. What is known comes from independent measurement studies rather than from documentation, and this section says only what those studies support.

Like Netflix, Google uses its own private content distribution network , with server clusters in many hundreds of IXP (Internet Exchange Point) and ISP (Internet Service Provider) locations. It distributes videos from those and directly from its huge data centres.

Where YouTube goes the other way

Pull, not push. Google uses pull caching. With hundreds of millions of videos, pushing the right ones everywhere is not a problem anyone can solve in advance, so demand decides instead.

DNS redirect, not direct assignment. Google uses the mechanism of §2.6.3. Most of the time the cluster-selection strategy sends the client to the cluster with the lowest round-trip time. But sometimes, to balance load across clusters, a client is directed to a more distant one.

HTTP (HyperText Transfer Protocol) streaming, not DASH. YouTube makes a small number of versions available at different bit rates, but does not employ adaptive streaming. The user selects the version manually.

In plain words — the byte-range trick

YouTube uses the HTTP byte-range request to limit the flow of transmitted data once a target amount of video has been prefetched.

Why bother? Because of what viewers do. Somebody who skips ahead, or abandons a video after ten seconds, has made every byte beyond that point wasted — wasted capacity and wasted server resources. Prefetching a bounded amount and stopping is a small mechanism with a very large multiplier behind it: several billion views a day.

Several million videos are uploaded to YouTube daily, and uploaders send them over HTTP as well. YouTube then processes each one, converting it to a YouTube video format and creating multiple versions at different bit rates. All of that happens entirely within Google data centres.

Side by side

Netflix and YouTube compared
Netflixown CDN since ~2012YouTubeGoogle’s CDN
Whose CDN?
How content reaches a cluster
How a client is sent to a server
Which cluster is chosen
How quality is chosen
A saving worth noticing

Cells marked ⓘ have a reason behind them — click to read it.

Two private CDNs at similar scale, differing on almost every mechanism. Click any ⓘ.

What the comparison is actually teaching

Both companies run private CDNs. Both operate hundreds of locations. Both stream over HTTP. Both had every option in section 2.6.3 available to them.

And they chose differently on push against pull, on DNS redirect against direct assignment, and on adaptive against manual quality selection.

So none of those choices follows from scale, from ownership, or from the protocol. Each was decided separately, against a different set of constraints — a catalogue small enough to plan against one too large to, video-only delivery against general-purpose delivery. When you meet a design like this in the wild, that is the question to ask: not what is the right answer, but what was this particular answer solving for.

Check yourself

Check yourself

0 of 7 answered
  1. 1.Netflix's website, billing and recommendation system run on Amazon servers, but Netflix streams no video from there. Why the split?

  2. 2.predictNetflix pushes videos to its CDN servers during off-peak hours; YouTube fetches a video on first request. What does each choice buy?

  3. 3.Section 2.6.3 said most CDNs use DNS to redirect a client to a server. Netflix does not. How does its client learn which server to use?

  4. 4.When a Netflix client is choosing where to stream from, which server does the software prefer?

  5. 5.YouTube offers several versions of a video at different bit rates, but does not use DASH. What is the practical difference for the viewer?

  6. 6.YouTube uses the HTTP byte-range request to stop sending after a target amount of video has been prefetched. What does that save, and why does it matter at YouTube's scale?

  7. 7.Both companies run private CDNs and both are enormous. Name a design choice where they genuinely differ.

What to remember

  • Netflix has two halves. The Amazon cloud runs the website, billing, ingestion and processing. Its own private CDN delivers every frame of video. The cloud never carries video to a viewer.
  • Netflix uses no DNS redirect: the cloud sends the client a server’s IP (Internet Protocol) address and a manifest file. It can do that because its CDN distributes only video.
  • YouTube pulls, uses DNS redirect, and picks the lowest RTT; Netflix pushes at off-peak hours and prefers a rack inside the viewer’s own ISP. Two private CDNs of similar scale, disagreeing on almost every mechanism — none of these choices follows from being large.