▣ The underlying medium is pre-recorded video. For example: a movie.

▣ These pre-recorded videos are placed on servers.

▣ The users send requests to the servers to view the videos on-demand.

▣ Nowadays, many Internet companies provide streaming video. For example: YouTube.

▣ Three key distinguishing features of streaming stored video:

1) Streaming

▩ The client begins video playout within few seconds after it begins receiving the video from the server.

▩ At the same time,

i. The client will be playing out from one location in the video.

ii. The client will be receiving later parts of the video from the server.

▩ This technique avoids having to download the entire video-file before playout begins.

2) Interactivity

▩ The media is pre-recorded, so the user may pause, reposition or fast-forward through video-content.

▩ The response time should be less than a few seconds.

3) Continuous Playout

▩ Once playout of the video begins, it should proceed according to the original timing of the recording.

▩ The data must be received from the server in time for its playout at the client. Otherwise, users experience video-frame skipping (or freezing).

▣ When a browser wants to retrieve a specific video, the CDN intercepts the request.

▣ Then, the CDN

i. determines a suitable server-cluster for the client and

ii. redirects the client's request to the desired server.

▣ Most CDNs take advantage of DNS to intercept and redirect requests.

▣ CDN operation is illustrated in Figure 2.1.

Fig 2.1: DNS redirects a use's request to a CDN server

▣ Suppose a content provider "NetCinema" employs the CDN company "KingCDN" to distribute videos.

▣ Let URL = http://video.netcinema.com/6Y7B23V

▣ Six events occur as shown in Figure 2.1:

i.The user visits the Web page at NetCinema.

ii.The user clicks on the following link:

http://video.netcinema.com/6Y7B23V,

▩ Then, the user's host sends a DNS query for "video.netcinema.com".

iii.The user's local-DNS-server (LDNS) forwards the DNS-query to an authoritative-DNS-server

iv."NetCinema".

▩ The server "NetCinema" returns to the LDNS a hostname in the KingCDN's domain.

▩ For example: "a1105.kingcdn.com".

v.The user's LDNS then sends a second query, now for "a1105.kingcdn.com".

▩ Eventually, KingCDN's DNS system returns the IP addresses of a "KingCDN" server to LDNS.

vi.The LDNS forwards the IP address of the "KingCDN" server to the user's host.

vii.Finally, the client

a. establishes a TCP connection with the server

b. issues an HTTP GET request for the video.

3.1 Limitations of the Best-Effort IP Service

▣ The Internet's network-layer protocol IP provides best-effort service.

▣ The IP makes best effort to move each datagram from source to destination.

▣ But IP does not guarantee deliver of the packet to the destination.

▣ Three main challenges to the design of real-time applications:

i. Packet-loss

ii. Packet delay and

iii. Packet jitter.

3.1.1 Packet Loss

▣ By default, most existing VoIP applications run over UDP.

▣ The UDP segment is encapsulated in an IP datagram.

▣ The datagram passes through router buffers in the path from sender to receiver

▣ Problem:

▩ There is possibility that one or more buffers are full.

▩ In this case, the arriving IP datagram may be discarded.

▣ Possible solution:

▩ Loss can be eliminated by sending the packets over TCP rather than over UDP.

▩ However, retransmissions are unacceptable for real-time applications, they increase delay.

▩ Packet-loss results in a reduction of sender's transmission-rate, leading to buffer starvation.

3.1.2 End-to-End Delay

▣ End-to-end delay is the sum of following delays:

i. Transmission, processing, and queuing delays in routers.

ii. Propagation delays in links and

iii. Processing delays in end-systems.

▣ For VoIP application,

i. delays smaller than 150 m secs are not perceived by a human listener.

ii. delays between 150 and 400 m secs can be acceptable but are not ideal and

iii. delays exceeding 400 m secs can seriously hinder the interactivity in voice conversations.

▣ Typically, the receiving-side will discard any packets that are delayed more than a certain threshold.

▣ For example: more than 400 m secs.

3.1.3 Packet Jitter

▣ Jitter refers to varying queuing delays that a packet experiences in the network's routers.

▣ If the receiver

i. ignores the presence of jitter and

ii. plays out audio-chunks,

then the resulting audio-quality can easily become unintelligible.

▣ Jitter can often be removed by using sequence numbers, timestamps, and a playout delay

5.1 Policing: The Leaky Bucket

▣ Policing is an important QoS mechanism

▣ Policing means the regulation of the rate at which a flow is allowed to inject packets into the network.

▣ Three important policing criteria:

i. Average Rate

▩ This constraint limits amount of traffic that can be sent into n/w over a long period of time.

ii. Peak Rate

▩ This constraint limits maximum no. of packets that can be sent over a short period of time

iii. Burst Size

▩ This constraint limits the maximum no. of packets that can be sent into n/w over a very short period of time.

5.2 Leaky Bucket Operation

▣ Policing-device can be implemented based on the concept of a leaky bucket.

▣ Tokens are generated periodically at a constant rate.

▣ Tokens are stored in a bucket.

▣ A packet from the buffer can be taken out only if a token in the bucket can be drawn.

▣ If the bucket is full of tokens, additional tokens are discarded.

▣ If the bucket is empty, arriving packets have to wait in the buffer until a sufficient no. of tokens is generated.

Fig 5.1: The leaky bucket policer

Fig 5.2: The leaky bucket policer 2