1. 15-744: Computer Networking
CDN, Video Streaming

2. Overview Domain Name System (DNS) Content Delivery Networks (CDN)
Extension mechanisms for DNS (EDNS)
ICN vs. CDN

3. Content Retrieval C ICN decouples “what” from “where”
Equip network with content caches
e.g., CCN, DONA, NDN, 4WARD ….
Route based on content names
e.g., find nearest replica C C S2
ICN decouples “what” from “where” C
Bind content names to intent
Today: 1) Ask search engine for name of server holding object
2) Resolve name to network address of server
3) Send request for object to server

4. Benefits of deploying ICN
e.g., CCN, DONA, NDN, 4WARD ….
Lower latency
Reduced congestion
Support for mobility
Intrinsic security

5. Difficulties deploying ICN
e.g., CCN, DONA, NDN, 4WARD …. .
Routers need to be replaced to support content-based routing and to incorporate caches

6. Approach: Attribute gains to tenets
Qualitative
Quantitative
Lower latency
Reduced congestion
Support for mobility
Intrinsic security
Decouple “what” from “where”
Bind content names to intent
Equip network with content caches
Route based on content names

7. Basis for incrementally deployable ICN
Key Takeaways
To achieve quantitative benefits:
Just cache at the “edge”
With Zipf-like object popularities, pervasive caching and nearest-replica routing don’t add much
To achieve qualitative benefits:
Build on HTTP
Basis for incrementally deployable ICN

8. Representative points in design space
Cache Placement Request Routing
ICN-SP
Everywhere
Shortest path to origin
ICN-NR
Nearest replica
Edge
Only at edge nodes
Edge-Coop
Edge neighbors alone

9. Object Popularities - Zipf Distribution
ith most popular item occurs with frequency proportional to 1/iα

10. Request latency (hops) - Asia trace
Gap between all architectures is small (< 10%)
Nearest-replica routing provides almost no benefit

11. Revisiting Qualitative Aspects
Decouple names from locations
Build on HTTP
Can be viewed as providing “get-by-name” abstraction
Can reuse existing web protocols (e.g., proxy discovery)
2. Binding names to intents
Use self-certifying names
e.g., “Magnet” URI schemes
Extend HTTP for “crypto” and other metadata

12. idICN: Content Registration
Name Resolution System
Register L.P.idicn.org
Reverse Proxy
P = Hash of public key
L = content label
Publish
content
e.g.,
Origin Server

13. idICN: Client Configuration
Name Resolution System
Proxy
Edge
Cache
Reverse Proxy
Automatic Proxy Discovery
e.g., WPAD
Client
Origin Server

14. idICN: Content Delivery
Name Resolution System
2. Name resolution
3. Rqst by address
Proxy
Edge
Cache
Reverse Proxy
5. Response + Metadata
1. Rqst L.P.idicn.org
4. Fetch
6. Response
Client
Origin Server

15. Conclusions Motivation: Gains of ICN with less pain
Latency, congestion, security
Without changes to routers or routing!
End-to-end argument applied to ICN design space
Can get most quantitative benefits with “edge” solutions
Pervasive caching, nearest-replica routing not needed
Can get qualitative benefits with existing techniques
With existing HTTP + HTTP-based extensions
Incrementally deployable + backwards compatible
idICN design: one possible feasible realization
Open issues: economics, other benefits, future workloads ..

16. Overview Background/Terminology Client-server protocol: HTTP chunking
Video quality analytics

17. It’s all Video! The Internet Today… Video Video Could be Video
Probably Video
It’s all Video!
Encrypted Video?
Purchasing Videos?
Why do we care about video?
DEFINITELY Video!
Sharing Video!
Video in the name!
Ads! (and Videos!)
2014 1H – NA Fixed Access

18. Demystifying Video Delivery
Video Source
Screen
Internet
Video Player
So how video is delivered today?
???
What’s this?
Today’s lecture
Source:

19. Terminology Frame FPS (frames per second) Resolution Bitrate
24, 25, 30, or 60
Resolution
Number of pixels per frame
160x120 to 1920x1080 (1080p) to 4096x2160 (4K)
Bitrate
Information stored/transmitted per unit time
Usually measured in kbps to mbps
Ranges from 200Kbps to 30 Mbps

20. Requirements What’s video quality?
Smooth/continuous playback
High bitrate
Short start-up time
What they mean depends on the type of videos
Delay
Bandwidth
Examples
2, N-way conference
< 200 ms
4 kbps audio only,
200 kbps – 5 Mbps video
Skype, Google hangout, Polycom, Cisco
Short form VoD
< 1-5s
300 kbps – 2 Mbps & higher
Youtube
Long form VoD
< 5-30s
500 kbps – 6 Mbps & higher
Netflix, Hulu, Qiyi, HBOGO
Live Broadcast
< 5-10s
WatchESPN, MLB

21. Client-Server Protocol
Video Source
Screen
Internet
Video Player
???
What protocol?
Source:

22. 1st Gen: HTTP Download
Browser requests the video (file), stores it locally, and gives the file to the player to display.

23. First Gen: HTTP Progressive Download (2)
7/11/2019
First Gen: HTTP Progressive Download (2)
Alternative: set up connection between server and player; player takes over
Web browser requests and receives a Meta File (which describes the object) instead of receiving the file itself;
Browser launches the player and passes it the Meta File;
Player sets up a connection with Web Server and downloads or streams the file by HTTP

24. Streaming Model: Buffers and Timing
Max Buffer Duration
= allowable jitter
File Position
"Bad": Buffer overflows
Smooth Playback Time
Max Buffer Size
Buffer Duration
"Bad": Buffer underflows and playback stops
Buffer Size
"Good" Region: smooth playback
Buffer almost empty
Time

25. Drawbacks of HTTP Progressive Download
7/11/2019
Drawbacks of HTTP Progressive Download
HTTP connection keeps data flowing as fast as possible to user's local buffer
May waste bandwidth if user does not watch the entire video
TCP file transfer can use more bandwidth than necessary
Cannot change video quality (bit rate) to adapt to network congestion
Mismatch between whole file transfer and stop/start/seek playback controls.
However: player can use file range requests to seek to video position
Takeaways of 1st generation: General-purpose protocols don’t work

26. 2nd Generation: Real-Time Streaming
7/11/2019
2nd Generation: Real-Time Streaming
Build our own protocol! This gets us around HTTP; app layer protocol can be better tailored to Streaming
Example: Real-time Streaming Protocol

27. Drawbacks of Real-Time Streaming
7/11/2019
Drawbacks of Real-Time Streaming
Streaming protocols often blocked by routers
HTTP delivery can use ordinary proxies and caches
Takeaways of 1st & 2nd generations:
1st gen: General-purpose protocols (HTTP) don’t work
2nd gen: Rather than adapt Internet to streaming, adapt media delivery to the Internet

28. 3rd Generation: HTTP Streaming
7/11/2019
3rd Generation: HTTP Streaming
Reusing HTTP: Client-centric architecture with stateful client and stateless server
Standard server: Web servers
Standard Protocol: HTTP
Session state and logic maintained at client
HTTP Chunking: Video is broken into multiple chunks (like with bittorrent)
Each chunk can be played independent of other chunks
Playing chunks in sequence gives seamless video
Meta-file (manifest) provides chunk file names

29. HTTP Chunking Protocol
Manifest:
A1, A2, …
Server
Client
Manifest
HTTP Adaptive Player … A1 A1 A2 … A1 A2
Manifest
HTTP GET Manifest
Cache
Web server
Web browser
Web server
HTTP
HTTP
TCP
TCP

30. HTTP Chunking Protocol
Manifest:
A1, A2, …
Server
Client
Manifest
HTTP Adaptive Player … A1 A2 … A1 A1 A2 A1 A2
HTTP GET A2
HTTP GET A1
Cache
Web server
Web browser
Web server
HTTP
HTTP
TCP
TCP

31. Adaptive Bitrate with HTTP Streaming
7/11/2019
Adaptive Bitrate with HTTP Streaming
Encode video at different quality/bitrate levels
Client can adapt by requesting chunks at different bitrate levels
Chunks of different bitrates must be synchronized
All encodings have the same chunk boundaries and all chunks can be played independently, so you can make smooth splices to chunks of higher or lower bit rates

32. HTTP Chunking Protocol
Manifest:
LQ: A1, A2, …
HQ: B1, B2, ...
Server
Client
Manifest
HTTP Adaptive Player … B1 A1 A2 … A1 A1 A1 A2 … B1 B2 …
HTTP GET A1
HTTP GET B2
Cache B2 B1 B2
Web server
Web browser
Web server
HTTP
HTTP
TCP
TCP

33. Advantages of HTTP Streaming
7/11/2019
Advantages of HTTP Streaming
Easy to deploy: it's just HTTP!
Work with existing caches/proxies/Webservers/Firewall
Fast startup by downloading lowest quality/smallest chunk
Bitrate switching is seamless
Can switch bitrate and server (even CDN) during playback
Tradeoff 1: fixed chunk length.
Small with respect to the movie size
Large with respect to TCP
5-10 seconds of 1Mbps – 3Mbps  0.5MB – 4MB per chunk
Tradeoff 2: predetermined bitrate levels
Can only switch between predetermined bitrate levels.

34. Demystifying Video Delivery
Video Source
Screen
Internet
Video Player
???
Source:

35. Demystifying Video Delivery
Video Source
Screen
Encoders & Video Servers
Video Player
CMS and Hosting
ISP & Home Net
Content Delivery Networks (CDN)
Source:

36. Overview Background/Terminology Client-server protocol: HTTP chunking
Video quality analytics

37. What’s wrong with this picture?
Video Source
Screen
Encoders & Video Servers
No Feedback!
Video Player
CMS and Hosting
ISP & Home Net
Content Delivery Networks (CDN)
Source:

38. Closing the Loop with Quality Analytics
Video Source
Content Broker
Screen
Encoders & Video Servers
Video Player
CMS and Hosting
Why feedback from clients?
- Only client can measure video quality accurately
ISP & Home Net
Content Delivery Networks (CDN)
Source:

39. Closing the Loop with Quality Analytics
Video Source
Screen
Encoders & Video Servers
Video Player
CMS and Hosting
ISP & Home Net
Content Delivery Networks (CDN)
Source:

40. Why Quality Analytics is Challenging
Why Quality Analytics is Challenging? (1) Spatial Diversity of Performance
Performance of CDNs have large spatial diversity.
Need to choose CDN (servers) for different clients.

41. Performance of CDNs have large temporal variance.
Why Quality Analytics is Challenging? (2) Temporal Diversity of Performance
Performance of CDNs have large temporal variance.
Need to choose CDN (servers) dynamically.

42. C3: Internet-Scale Control Platform for Video QoE Optimization
Conviva Architecture
How to scale up?
C3: Internet-Scale Control Platform for Video QoE Optimization

43. Next Lecture
Wireless