Module 5 - Multimedia Networking:

A multimedia network application is any network application that employs audio or video.

A multimedia application can be classified as

i. Streaming stored audio/video,
ii. Conversational voice/video-over-IP,
iii. Streaming live audio/video.

Properties of Video

1. Video distributed over the Internet typically ranges from 100 kbps for low-quality video
conferencing to over 3 Mbps for streaming high-definition movies.
 When designing networked video applications, there is a necessary of high bit-rate
requirements of video.
2. Another important characteristic of video is that video can be compressed i.e trading off
video quality with bit rate.
 A video is a sequence of images, typically being displayed at a constant rate, for example,
at 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.

3. There are two types of redundancy in video, both of which can be exploited by video
compression.
a. Spatial redundancy b. temporal redundancy

i. Spatial redundancy: It is the redundancy within a given image.

An image that consists of mostly white space has a high degree of redundancy and can be
efficiently compressed.

ii. Temporal redundancy: reflects repetition from image to subsequent image.

An image and the subsequent image are exactly the same; there is no reason to reencode
the subsequent image;

iii. We can also use compression to create multiple versions of the same video, each at a
different quality level.

iv. With video, compression techniques are used to reduce the bit rates of the stream.
Properties of Audio
Digital audio has significantly lower bandwidth requirements than video.

How analog audio (which humans and musical instruments generate) is converted to a digital
signal?

Pulse code modulation (PCM):

The analog audio signal is sampled at some fixed rate, for example, at 8,000 samples per second.

• Each of the samples is then rounded to one of a finite number of values. This operation is
referred to as quantization. The number of such finite values— called quantization values—is
typically a power of two, for example, 256 quantization values.

• Each of the quantization values is represented by a fixed number of bits. For example, if there
are 256 quantization values, then each value—and hence each audio sample—is represented by
one byte. The bit representations of all the samples are then concatenated together to form the
digital representation of the signal.

As an example, if an analog audio signal is sampled at 8,000 samples per second and each
sample is quantized and represented by 8 bits, then the resulting digital signal will have a rate of
64,000 bits per second.
For playback through audio speakers, the digital signal can then be converted back—that is,
decoded—to an analog signal.
There is a trade-off between the quality of the decoded signal and the bit-rate and storage
requirements of the digital signal.

Speech encoding often uses PCM, with a sampling rate of 8,000 samples per second and 8 bits
per sample, resulting in a rate of 64 kbps.
The audio compact disk (CD) also uses PCM, with a sampling rate of 44,100 samples per
second with 16 bits per sample, resulting in a rate of 705.6 kbps.

Human speech can be compressed to less than 10 kbps.

A popular compression technique for near CD-quality stereo music is MPEG 1 layer 3, known
as MP3.
A related standard is Advanced Audio Coding (AAC), which has been popularized by Apple.

Types of Multimedia Network Applications

Multimedia applications can be classified into three broad categories:
(i) streaming stored audio/video,
(ii) conversational voice/video-over-IP,
(iii) streaming live audio/video.
 Streaming Stored Audio and Video
Streaming stored video, which typically combines video and audio components.

In this class of applications, the underlying medium is prerecorded video, such as a movie, a
television show, a prerecorded sporting event, or a prerecorded user generated video (such as
those commonly seen on YouTube).
These prerecorded videos are placed on servers, and users send requests to the servers to view
the videos on demand. Many Internet companies today provide streaming video, including
YouTube (Google),
 Streaming. The client typically begins video playout within a few seconds after it begins
receiving the video from the server.
i.e The client will be playing out from one location in the video while at the same time
receiving later parts of the video from the server. This technique, known as streaming
Streaming avoids having to download the entire video file before playout begins.

 Interactivity. Because the media is prerecorded, the user may pause, reposition forward,
reposition backward, fast-forward, and so on through the video content. The time from when
the user makes such a request until the action manifests itself at the client should be less than
a few seconds for acceptable responsiveness.

 Continuous playout. Once playout of the video begins, it should proceed according to the
original timing of the recording. Therefore, data must be received from the server in time for
its playout at the client; otherwise, users experience video frame freezing or frame skipping

In order to provide continuous playout, the network must provide an average throughput to the
streaming application that is at least as large the bit rate of the video itself.

 Conversational Voice-and Video-over-IP

Real-time conversational voice over the Internet is often referred to as Internet telephony,
since, from the user’s perspective, it is similar to the traditional circuit switched telephone
service. It is also commonly called Voice-over-IP (VoIP).
Conversational video is similar, except that it includes the video of the participants as well as
their voices.

Conversational voice and video are widely used in the Internet today, with the Internet
companies Skype, QQ, and Google Talk

The 2 important considerations for conversational voice and video applications are Timing
considerations and tolerance of data loss

Timing considerations are important because audio and video conversational applications are
highly delay-sensitive. For a conversation with two or more interacting speakers, the delay from
when a user speaks or moves until the action is manifested at the other end should be less than a
few hundred milliseconds.
For voice, delays smaller than 150 milliseconds are not perceived by a human listener, delays
between 150 and 400 milliseconds can be acceptable, and delays exceeding 400 milliseconds can
result in frustrating, if not completely unintelligible, voice conversations.

Tolerance of data loss: On the other hand, conversational multimedia applications are loss-
tolerant— occasional loss only causes occasional glitches in audio/video playback, and these
losses can often be partially or fully concealed.

Streaming Live Audio and Video

 This type of applications is similar to traditional broadcast radio and television, except that
transmission takes place over the Internet. These applications allow a user to receive a live
radio or television transmission—such as a live sporting event or an ongoing news event—
transmitted from any corner of the world. Today, thousands of radio and television stations
around the world are broadcasting content over the Internet.
 Live, broadcast-like applications often have many users who receive the same audio/video
program at the same time. Although the distribution of live audio/video to many receivers
can be efficiently accomplished using the IP multicasting techniques.

 As with streaming stored multimedia, the network must provide each live multimedia flow
with an average throughput that is larger than the video consumption rate. Because the event
is live, delay can also be an issue, although the timing constraints are much less stringent
than those for conversational voice.

Streaming Stored Video

For streaming video applications, prerecorded videos are placed on servers, and users send
requests to these servers to view the videos on demand.

Streaming video systems can be classified into three categories:

a. UDP streaming, b. HTTP streaming, c. Adaptive HTTP streaming.

A common characteristic of all three forms of video streaming is the extensive use of client-side
application buffering to mitigate the effects of varying end-to-end delays and varying amounts of
available bandwidth between server and client.

When the video starts to arrive at the client, the client need not immediately begin playout, but
can instead build up a reserve of video in an application buffer. Once the client has built up a
reserve of several seconds of buffered-but-not-yet-played video, the client can then begin video
playout.
There are two important advantages provided by such client buffering.

1. Client side buffering can absorb variations in server-to-client delay.

i.e If a particular piece of video data is delayed, as long as it arrives before the reserve of
received-but-not yet-played video is exhausted, this long delay will not be noticed.

2. if the server-to-client bandwidth briefly drops below the video consumption rate, a user can
continue to enjoy continuous playback, as long as the client application buffer does not
become completely drained.

In client-side buffering, suppose that video is encoded at a fixed bit rate, and thus each video
block contains video frames that are to be played out over the same fixed amount of time, ∆.
The server transmits the first video block at t0,
the second block at t0+2∆,
the third block at t0+2∆, and so on.

Once the client begins playout, each block should be played out ∆ time units after the previous
block in order to reproduce the timing of the original recorded video.

Because of the variable end-to-end network delays, different video blocks experience different
delays. The first video block arrives at the client at t1 and the second block arrives at t2. The
network delay for the ith block is the horizontal distance between the time the block was
transmitted by the server and the time it is received at the client;

Note that the network delay varies from one video block to another.
In this example, If the client were to begin playout as soon as the first block arrived at t1, then the
second block would not have arrived in time to be played out at out at t1+∆. In this case, video
playout would either have to stall (waiting for block 1 to arrive) or block 1 could be skipped—
both resulting in undesirable playout impairments.
Instead, if the client were to delay the start of playout until t3, when blocks 1 through 6 have all
arrived, periodic playout can proceed with all blocks having been received before their playout
time.

 UDP Streaming

With UDP streaming, the server transmits video at a rate that matches the client’s video
consumption rate by clocking out the video chunks over UDP at a steady rate.
Before passing the video chunks to UDP, the server will encapsulate the video chunks within
transport packets specially designed for transporting audio and video using the Real-Time
Transport Protocol (RTP).
the server to-client video stream, the client and server also maintain, in parallel, a separate
control connection over which the client sends commands regarding session state changes (such
as pause, resume, reposition, and so on).

It suffers from three significant drawbacks.

1. Due to the unpredictable and varying amount of available bandwidth between server and
client, constant-rate UDP streaming can fail to provide continuous playout.
2. UDP streaming requires a media control server, such as an RTSP server, to process client-to-
server interactivity requests and to track client state for each ongoing client session. This
increases the overall cost and complexity of deploying a large-scale video-on-demand
system.
3. Many firewalls are configured to block UDP traffic, preventing the users behind these
firewalls from receiving UDP video.

 HTTP Streaming

In HTTP streaming, the video is simply stored in an HTTP server as an ordinary file with a
specific URL. When a user wants to see the video, the client establishes a TCP connection with
the server and issues an HTTP GET request for that URL. The server then sends the video file,
within an HTTP response message, as quickly as TCP congestion control and flow control will
allow.
On the client side, 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—
specifically, it periodically grabs video frames from the client application buffer, decompresses
the frames, and displays them on the user’s screen.
Advantages of HTTP:

1. The use of HTTP over TCP also allows the video to traverse firewalls and NATs more easily.
2. Streaming over HTTP also obviates the need for a media control server, such as an RTSP
server, reducing the cost of a large-scale deployment over the Internet.
3. Most video streaming applications today—including YouTube and Netflix—use HTTP
streaming (over TCP) as its underlying streaming protocol.

Prefetching Video

The server transmits video at the rate at which the video is to be played out. However, for
streaming stored video, the client can attempt to download the video at a rate higher than the
consumption rate, thereby prefetching video frames that are to be consumed in the future.

This prefetched video is naturally stored in the client application buffer. Such prefetching occurs
naturally with TCP streaming, since TCP’s congestion avoidance mechanism will attempt to use
all of the available bandwidth between server and client.

Client Application Buffer and TCP Buffers

 At the server side, the portion of the video file in white has already been sent into the server’s
socket, while the darkened portion is what remains to be sent.
 After “passing through the socket door,” the bytes are placed in the TCP send buffer before
being transmitted into the Internet. Because the TCP send buffer is shown to be full, the
server is momentarily prevented from sending more bytes from the video file into the socket.

The interaction between client and server for HTTP streaming.

 On the client side, the client application (media player) reads bytes from the TCP receive
buffer (through its client socket) and places the bytes into the client application buffer. At the
same time, the client application periodically grabs video frames from the client application
buffer, decompresses the frames, and displays them on the user’s screen.

 When the user pauses the video during the streaming process. Bits are not removed from the
client application buffer, even though bits continue to enter the buffer from the server.

 Once the client receive TCP buffer becomes full, bytes can no longer be removed from the
client TCP send buffer, so it also becomes full.

 Once the TCP send buffer becomes full, the server cannot send any more bytes into the
socket. Thus, if the user pauses the video, the server may be forced to stop transmitting, in
which case the server will be blocked until the user resumes the video.

Analysis of Video Streaming

let B denote the size (in bits) of the client’s application buffer, and let Q denote the number of
bits that must be buffered before the client application begins playout. (Of course, Q < B.) Let r
denote the video consumption rate—the rate at which the client draws bits out of the client
application buffer during playback.

So, for example, if the video’s frame rate is 30 frames/sec, and each (compressed) frame is
100,000 bits, then r = 3 Mbps. To see the forest through the trees, we’ll ignore TCP’s send and
receive buffers.
Suppose at time t = 0, the application buffer is empty and video begins arriving to the client
application buffer.
What time t= tp does playout begin?
What time t=tf does the client application buffer become full?

 To determine tp, the time when Q bits have entered the application buffer and playout begins.
Thus, the amount of time required to build up Q bits (the initial buffering delay) is tp = Q/x.

 To determine, tf the point in time when the client application buffer becomes full.

 If the server send rate is less than the video consumption rate, then the client buffer will
never become full. Eventually the client buffer will empty out entirely, at which time the
video will freeze on the screen while the client buffer waits another seconds to build up Q
bits of video.

 Thus, when the available rate in the network is less than the video rate, playout will alternate
between periods of continuous playout and periods of freezing.

 To determine the length of each continuous playout and freezing period as a function of Q, r,
and x.

 When x > r, starting at time tp, the buffer increases from Q to B at rate x-r. since bits are
being depleted at rate r but are arriving at rate x.

Early Termination and Repositioning the Video

 HTTP streaming systems often make use of the HTTP GET request message, which specifies
the specific range of bytes the client currently wants to retrieve from the desired video.
 When the user repositions to a new position, the client sends a new HTTP indicating with the
byte-range header from which byte in the file should the server send data.
 When the server receives the new HTTP earlier request and instead send bytes beginning
with the byte indicated in the byte range request.
 When a user terminates the video early, some prefetched-but-not-yet-viewed data transmitted
by the server will go unwatched—a waste of network bandwidth and server resources.
 There is significant wasted bandwidth in the Internet due to early termination, which can be
quite costly, particularly for wireless links [Ihm 2011]. For this reason, many streaming
systems use only a moderate-size client application buffer, or will limit the amount of
prefetched video using the byte-range header in HTTP requests

Drawback of HTTP streaming All clients receive the same encoding of the video, despite the
large variations in the amount of bandwidth available to a client, both across different clients and
also over time for the same client.
Adaptive Streaming and DASH:
 In DASH, the video is encoded into several different versions, with each version having a
different bit rate and, correspondingly, a different quality level.
 The client dynamically requests chunks of video segments of a few seconds in length from
the different versions.
 When the amount of available bandwidth is high, the client naturally selects chunks from a
high-rate version;
 When the available bandwidth is low, it naturally selects from a low-rate version. The client
selects different chunks one at a time with HTTP GET request messages.
 DASH allows clients with different Internet access rates to stream in video at different
encoding rates. Clients with low-speed 3G connections can receive a low bit-rate (and low-
quality) version, and clients with fiber connections can receive a high-quality version.
 DASH allows a client to adapt to the available bandwidth if the end-to-end bandwidth
changes during the session.

Advantages:
 DASH allows the client to freely switch among different quality levels.
 DASH dynamically monitors the available bandwidth and client buffer level, and adjusting
the transmission rate with version switching,
 DASH can often achieve continuous playout at the best possible quality level without frame
freezing or skipping.
 Since the client (rather than the server) maintains the intelligence to determine which chunk
to send next, the scheme also improves server-side scalability.
 Client can use the HTTP byte-range request to precisely control the amount of prefetched
video that it buffers locally.

Content Distribution Networks:

 In order to distributing massive amounts of video data to users distributed around the world,
all major video-streaming companies make use of Content Distribution Networks (CDNs).
 A CDN manages servers in multiple geographically distributed locations, stores copies of the
videos (and other types of Web content, including documents, images, and audio) in its
servers, and attempts to direct each user request to a CDN location that will provide the best
user experience.
 The CDN may be a private CDN, that is, owned by the content provider itself; for example,
Google’s CDN distributes YouTube videos and other types of content.
 The CDN may alternatively be a third-party CDN that distributes content on behalf of
multiple content providers; Akamai’s CDN, for example, is a thirdparty CDN that distributes
Netflix and Hulu content, among others.
CDNs typically adopt one of two different server placement philosophies

Enter Deep. One philosophy, pioneered by Akamai, is to enter deep into the access networks of
Internet Service Providers, by deploying server clusters in access ISPs all over the world.
Akamai takes this approach with clusters in approximately 1,700 locations.
The goal is to get close to end users, thereby improving user-perceived delay and throughput by
decreasing the number of links and routers between the end user and the CDN cluster from
which it receives content.

Bring Home. A second design philosophy, taken by Limelight and many other CDN companies,
is to bring the ISPs home by building large clusters at a smaller number (for example, tens) of
key locations and connecting these clusters using a private high-speed network. Instead of
getting inside the access ISPs, these CDNs typically place each cluster at a location that is
simultaneously near the PoPs of many tier-1 ISPs.

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 (from a central repository or from another cluster) and stores a copy locally while
streaming the video to the client at the same time.

CDN Operation
When a browser in a user’s host is instructed to retrieve a specific video (identified by a URL),
the CDN must intercept the request so that it can (1) determine a suitable CDN server cluster for
that client at that time, and (2) redirect the client’s request to a server in that cluster.

To illustrate how DNS is typically involved to intercept and redirect requests.

Suppose a content provider, NetCinema, employs the third-party CDN company, KingCDN, to
distribute its videos to its customers.
On the NetCinema Web pages, each of its videos is assigned a URL that includes the string
“video” and a unique identifier for the video itself;
For example, Transformers 7 might be assigned [Link]

Six steps then occur,

1. The user visits the Web page at NetCinema.
2. When the user clicks on the link [Link] the user’s host sends
a DNS query for [Link].
3. The user’s Local DNS Server (LDNS) relays the DNS query to an authoritative DNS server
for NetCinema, which observes the string “video” in the hostname [Link]. To
“hand over” the DNS query to KingCDN, instead of returning an IP address, the NetCinema
authoritative DNS server returns to the LDNS a hostname in the KingCDN’s domain,
4. From this point on, the DNS query enters into KingCDN’s private DNS infrastructure. The
user’s LDNS then sends a second query, now for [Link], and KingCDN’s DNS
system eventually returns the IP addresses of a KingCDN content server to the LDNS.

5. The LDNS forwards the IP address of the content-serving CDN node to the user’s host.

6. Once the client receives the IP address for a KingCDN content server, it establishes a direct
TCP connection with the server at that IP address and issues an HTTP GET request for the
video.
If DASH is used, the server will first send to the client a manifest file with a list of URLs,
one for each version of the video, and the client will dynamically select chunks from the
different versions.

Fig. DNS redirects a user’s request to a CDN server

Cluster Selection Strategies:

At the core of any CDN deployment is a cluster selection strategy, is a mechanism for
dynamically directing clients to a server cluster or a data center within the CDN.
One simple strategy is to assign the client to the cluster that is geographically closest.

Using geo-location databases 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, that is, the cluster that is the fewest kilometers from the LDNS “as the bird flies.”
Such a solution can work reasonably well for a large fraction of the clients.

A problem inherent with all DNS-based approaches is that

 some end-users are configured to use remotely located in which case the LDNS location may
be far from the client’s location.
 Moreover, this simple strategy ignores the variation in delay and available bandwidth over
time of Internet paths, always assigning the same cluster to a particular client.

In order to determine the best cluster for a client based on the current traffic conditions,
 CDNs can instead perform periodic real-time measurements of delay and loss performance
between their clusters and clients. For instance, a CDN can have each of its clusters
periodically send probes (for example, ping messages or DNS queries) to all of the LDNSs
around the world.
 One drawback of this approach is that many LDNSs are configured to not respond to such
probes.

 An alternative to sending extraneous traffic for measuring path properties is to use the
characteristics of recent and ongoing traffic between the clients and CDN servers.
 Another alternative for cluster-to-client path probing is to use DNS query traffic to measure
the delay between clients and clusters.

IP Anycast: An approch to matching clients with CDN servers is to use IP anycast.

The idea behind IP anycast is to have the routers in the Internet route the client’s packets to the
“closest” cluster, as determined by BGP.
During the IP-anycast configuration stage, the CDN company assigns the same IP address to
each of its clusters, and uses standard BGP to advertise this IP address from each of the different
cluster locations.
When a BGP router receives multiple route advertisements for this same IP address, it treats
these advertisements as providing different paths to the same physical location (when, in fact, the
advertisements are for different paths to different physical locations).

Following standard operating procedures, the BGP router will then pick the “best”. (i.e., closest,
as determined by AS-hop counts) route to the IP address according to its local route selection
mechanism.

Initial configuration phase: if one BGP route (corresponding to one location) is only one AS
hop away from the router, and all other BGP routes (corresponding to other locations) are two or
more AS hops away, then the BGP router would typically choose to route packets to the location
that needs to traverse only one AS.
 Fig. Using IP anycast to route clients to closest CDN cluster

Distributing content: When any client wants to see any video, the CDN’s DNS returns the
anycast address, no matter where the client is located. When the client sends a packet to that IP
address, the packet is routed to the “closest” cluster as determined by the preconfigured
forwarding tables, which were configured with BGP as just described.
This approach has the advantage of finding the cluster that is closest to the client rather than the
cluster that is closest to the client’s LDNS.

However, the IP anycast strategy again does not take into account the dynamic nature of the
Internet over short time scales. Besides network-related considerations such as delay, loss, and
bandwidth performance, there are many additional important factors that go into designing a
cluster selection strategy.

Case Studies: Netflix, YouTube, and Kankan:

Streaming stored video by highly successful large-scale deployments: Netflix, YouTube, and
Kankan.
Netflix :
 Netflix has become the leading service provider for online movies and TV shows.
 In order to rapidly deploy its large-scale service, Netflix has made extensive use of third-
party cloud services and CDNs.
 Netflix is an interesting example of a company deploying a large-scale online service by
renting servers, bandwidth, storage, and database services from third parties while using
hardly any infrastructure of its own.

Fig. Netflix video streaming platform

Netflix video-streaming platform has four major components:

 The registration and payment servers, the Amazon cloud, multiple CDN providers, and
clients.
 Netflix maintains registration and payment servers, which handle registration of new
accounts and capture credit-card payment information.
 Netflix runs its online service by employing machines (or virtual machines) in The Amazon
cloud.

Some of the functions taking place in the Amazon cloud include:

• Content ingestion. Before Netflix can distribute a movie to its customers, it must first ingest
and process the movie. Netflix receives studio master versions of movies and uploads them to
hosts in the Amazon cloud.
• Content processing. The machines in the Amazon cloud create many different formats for each
movie, suitable for a diverse array of client video players running on desktop computers,
smartphones, and game consoles connected to televisions.
• Uploading versions to the CDNs. Once all of the versions of a movie have been created, the
hosts in the Amazon cloud upload the versions to the CDNs.

To deliver the movies to its customers on demand, Netflix makes extensive use of CDN
technology. Netflix embodies many of the key principles, including adaptive streaming and CDN
distribution.

YouTube:
 YouTube makes extensive use of CDN technology to distribute its videos.
 Google has installed server clusters in many hundreds of different locations. From a
subset of about 50 of these locations, Google distributes YouTube.
 Google uses DNS to redirect a customer request to a specific cluster, Most of the time,
Google’s 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 directed (via DNS) to a more distant cluster.
 If a cluster does not have the requested video, instead of fetching it from somewhere else
and relaying it to the client, the cluster may return an HTTP redirect message, thereby
redirecting the client to another cluster.
 YouTube does not employ adaptive streaming (such as DASH), but instead requires the
user to manually select a version.
 YouTube employs HTTP streaming to limit the flow of transmitted data after a target
amount of video is prefetched.

Kankan
 Kankan, currently the leading P2P-based video-on-demand provider in China, has over
20 million unique users viewing its videos every month.
 At a high level, P2P video streaming is very similar to BitTorrent file downloading.
 When a peer wants to see a video, it contacts a tracker (which may be centralized or peer-
based using a DHT) to discover other peers in the system that have a copy of that video.
This peer then requests chunks of the video file in parallel from these other peers that
have the file.
 The Kankan design employs a tracker and its own DHT for tracking content.
 For distributing video chunks among peers, Kankan uses UDP whenever possible,
leading to massive amounts of UDP traffic within China’s Internet.