2.6 – Video Streaming and Content Distribution Networks

  • Netflix and YouTube consume 37% and 16% of the traffic in North America (2015)

2.6.1 – Internet Video

  • A video is a sequence of images, typically being displayed at a constant rate, f.ex. 24 or 30 images per second.
    • An uncompressed, digitally encoded image consists of an array of pixels with each pixel encoded into a number of bits to represent luminance and color.
  • Compressed Internet video typically ranges from 100 kbps for LQ video to over 3 Mbps.
    • Can translate to huge amount of traffic and storage, a single 2 Mbps video with a duration of 67min will consume 1GB
      • Thus the most important performance measure for streaming video is average end-to-end throughput.

2.6.2 – HTTP Streaming and DASH

  • In HTTP streaming the video is stored as a normal file on the HTTP server. The user then establishes a TCP connection with the server and issues an HTTP Get request for the URL of the video. The server then sends the video file, within an HTTP response message.
    • The bytes are collected in a client application buffer. Once the number of bytes in this buffer exceeds a predetermined threshold, the client application begins playback (The application periodically grabs video frames from the client application buffer, decompresses the frames and displays them)
    • The con of this is that all clients receive the same encoding of the video, despite the larger variations of bandwidth that the users have.
  • Dynamic Adaptive Streaming over HTTP (DASH):
    • The video is encoded into several different versions, with each version having a different bit rate/quality level.
    • The client dynamically requests chunks of video segments of a few seconds in length. When the amount of available bandwidth is high, the client selects the high-rate version and when the available bandwidth is low, the client selects the low-rate version.
    • Each video version is stored in the HTTP server, each with a different URL. The HTTP server also has a manifest file, which provides a URL for each version along with its bit rate.
      • The client first requests the manifest file, then it requests the bit-rate version it wants.
    • While downloading chucks, the client also measures received bandwidth and runs a rate determination algorithm to select the chunk to request next.

2.6.3 – Content Distribution Networks

  • Build a single massive data center, store all of its videos in the data center, and stream the videos directly from the data center to the clients worldwide.
    • 3 Problems with this approach:
      • If the client is far from the data center, server-to-client packets will cross many communication links and likely pass through many ISPS. If one of these links provides a throughput that is lies than the video consumption rate, the end-to-end throughput will also be below the consumption rate thus resulting in freezing delays.
      • A popular video will likely be sent many times over the same communication links. Not only does this waste network bandwidth, but the Internet video company itself will be paying its provider ISP for sending the same bytes into the internet over and over again.
      • A single data center represents a single point of failure. If the data center or its links to the internet goes down, it would not be able to distribute nay videos.
  • Almost all major video-streaming companies use Content Distribution Networks (CDN):
    • A CDN manages servers in multiple geographically distributed locations, stores copies of the videos in its server, and attempts to direct each user request to a CDN location that will provide the best service.
    • The CDN may be private (owned by the content provider) or be a third-party CDN (Akamai, Limelight and Level-3) that distributes content on behalf of multiple content providers.
  • CDNs typically adopt one of two different server placement philosophies:
    • Enter Deep (pioneered by Akamai):
      • Deploying server clusters in access ISPs all over the world.
      • Akamai has clusters In approximately 1700 locations.
      • The goal is to get close to end users, thereby improving user-perceived delay and throughput by decreasing the number of links and router between the end user and the CDN server.
      • The task of maintaining and managing the clusters becomes challenging.
    • Bring Home (Limelight and many others):
      • Building large clusters at a smaller number of sites. Instead of getting inside the access ISPs these CDNs typically place their clusters in Internet Exchange Points (IXPs)
      • Lower maintenance and management overhead than “Enter Deep”, but possibly at the expense of higher delay and lower throughput to the end user.
  • The CDN replicates content across its clusters.
    • Many CDNs do not push videos to their clusters, but instead use a simple pull strategy:
      • If a client requests a video from a cluster that is not storing the video, then the cluster retrieves the video and stores a copy locally while streaming the video the client at the same time.
  • When a browser in a user’s host is instructed to retrieve a specific video, the CDN must intercept to request so that it can determine a suitable CDN server cluster, for that client at that time, and redirect the client’s request to a server in that cluster.
    • Most CDNs take advantage of DNS to intercept and redirect requests.
    • Example: Suppose a content provider employs a third-party CDN company to distribute its videos to its customers:
      • The user visit the web page at the content provider
      • When the user clicks on the link video.example.com/A64G53GS, the user’s host sends a DNS query for video.example.com
      • The user’s Local DNS server relays the DNS query to an authoritative DNS server for the content provider, which observers the string “video” in the host-name. To “hand over” the DNS query to the third-party’s DNS instead of returning an IP address, the content providers authoritative DNS server returns the LDNS a hostname in the third-party-CDN’s domain, f.ex. a1105.TPCDN.com
      • The DNS query enters the private DNS infrastructure. The user’s LDNS sends a second query which the third-party-CDN’s DNS system responds to.
      • The LDNS forwards the IP address of the content-serving CDN node to the user’s host
      • The client can now establish a direct TCP connection to the server and issue a HTTP GET request for the video.
  • At the core of any CDN deployment is a cluster selection strategy:
    • A mechanism for dynamically directing clients to a server cluster or a data center within the CDN.
    • CDNs generally employ proprietary cluster selection strategies.
  • A simple strategy to assign the client to the cluster that is geographically closest:
    • Using commercial geo-location databases and MaxMind, each LDNS IP address is mapped to a geographic location.
    • When a DNS request is received from a particular LDNS, the CDN chooses the geographically closest cluster.
      • Works well for most clients, but not all as the geographically closest cluster may not be the closest cluster in terms of the length or number of hops of the network path.
      • It also doesn’t work for users has configured to use a remote LDNS
      • The strategy doesn’t take into variation in delay or the available bandwidth at the time into consideration either.
  • CDNs can perform periodic real-time measurements of delay and loss performance between their clusters and clients (it can periodically send probes to all the LDNSs around the world), but a problem is that many LDNSs are configured to not respond to such probes.

2.6.4 – Case studies: Netflix, YouTube, and KanKan

  • Netflix
    • Netflix has two major components, Amazong cloud and its private CDN infrastructure
    • Amazon cloud handles:
      • Content ingestion:
        • Ingest and process the studio master versions of the movies that gets uploaded to the Amazon cloud
      • Content processing:
        • Creates many different formats for each movie, suitable for a diverse array of client video players (different versions of these versions are again created by DASH)
      • Uploading versions to its CDN:
        • Once all the versions of a movie has been created, the hosts in the Amazon cloud upload the versions to its CDN.
    • Netflix started with third-party CDNs, but has later made their own CDNs.
      • Netflix has installed server racks both in IXPs and within residential ISPs themselves (2016: server racks in 50 IXPs locations and hundreds of ISPs).
        • Netflix provide instructions to possible ISP partners about how to install their racks who has several 10Gbps ports and 100TB of storage.
    • Netflix does not use pull-caching. Instead they distribute by pushing the videos to its CDN servers during off-peak hours.
      • The locations who cant hold the entire library gets sent the most popular videos determined on a day-to-day basis.
    • When a user selects a movie to play, the Netflix software determines which of its CDN servers have copies of the movie. Among those servers it determines the “best” server for the client request (if the client is close to a local ISP with the movie then that gets chosen, if not then the closest IXP)
      • Netflix then sends the IP address and manifest URL to the user. The server and client then interact with DASH.
    • Netflix does not need to employ a DNS redirect to connect a particular client to a CDN server. Instead the Netflix software directly tells the client to use a particular CDN.
    • Netflix use Push caching instead of pull caching.
  • YouTube
    • 300 hours of video uploaded every minute and billion of views per day.
    • Began in April 2005 and was bought by google in November 2006.
    • Proprietary design and protocols.
    • Use CDN technology like Netflix and has server racks installed in IXPs and ISPs
      • Uses pull caching and DNS redirect.
    • Googles cluster-selection strategy directs the client to the cluster for which the RTT between client and cluster is the lowest; however in order to balance the load across clusters, sometimes the client is redirected to a more distant cluster.
    • Use HTTP streaming, making a small number of different versions available which the user has to manually choose. It does not use DASH.
      • It uses the HTTP byte range request to limit the flow of transmitted data after a target amount of video is prefecthed.
    • Users upload videos to youtube over HTTP. The processing of the video takes place in Googles data centers.
  • KanKan
    • Uses P2P video delivery with tens of millions of users every month.
    • Similar to BitTorrent file downloading. When a peer wants a video it contacts a tracker to discover other peers in the system with a copy of the video.
      • The requesting peer then requests chucks of the video in parallel from the other peers that have the video.
    • Requests are preferentially made for chunks that are to be played back in the near future in order to ensure continuous playback.
    • Has migrated to a hybrid CDN-P2P streaming system. They have deployed a few hundred servers within China and pushes video content to these servers.
      • Helps in the start-up stage of video streaming.
      • The client requests the beginning of the content from the CDN server, and in parallel requests content from peers.
        • When the P2P traffic is sufficient it will switch to only use peers to stream.
        • If it doesn’t get sufficient it will continue to stream from the CDN server.

results matching ""

    No results matching ""