BRKSPV 2160

CDN Architecture and Sizing
BRKSPV-2160
Ignacio Martinez
Consulting Systems Engineer
Objectives of this session
 Taking “End-to-end Multi-screen Video Delivery” as a use case, identify the role
and functions of Origin Servers and CDNs
 Show the main components of a CDN and see how they have been optimized
for ABR and large scale caching
 Understand the differences between various CDN Architectures
 Describe the key parameters and challenges of sizing a CDN presenting a

Methodology for efficiently dimensioning a CDN
BRKSPV-2160 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Agenda
 The CDN and end-to-end multi-screen Video Delivery
– Origin Servers and CDNs
– ABR Video
 CDN Architecture aspects
– Cache types
– Distribution models
– CDN Virtualization
– CDN Interconnection
– CDN Analytics, Security, Management and IPv6
 CDN Sizing Parameters, Challenges and Methodology
– Intervening factors
– Popularity and Cache Hit Ratio
– Putting it all together
Introduction
End to end Multi-screen Video Delivery
 Today we will talk about Origin Servers and CDNs as well as ABR
Live ABR traffic
VOD ABR traffic
Live & VOD

Metadata Workflows Personalization Billing CRM
Productization Navigation + authentication
Catalog creation Portal & Offer Presentation
Content Management & Entitlement
DRM Biz logic
DRM server
Content Preparation workflows

Licence acquire
Our focus today
Encoding CDN – Content Distribution Clients

Live & VOD Origin Servers
SE
Source Content Origin Servers i
Live Enc SE i i
i
i
Live i
i
i
CA i
VOD Origin Servers i i
i
i
i i
Enc VOD i
Content Acquirer Streamer Engine

Storage Local Cache
Local Cache
Origin Servers and the CDN
 Origin Servers
– Combine Content + Publishing Metadata 1 1
– Perform Revalidation functions

– Deal with Authorization
– “Store” all content (preserved until explicitly
removed)
2
– Package Content for publishing (on-demand
encapsulation, encryption) 1 3
 Content Acquirers
– Map Publishing name space (CDN) into
Origination space (OS)
– “Cache” only the most popular content in the CDN
– Evict content according to cache occupation,
popularity and publishing criteria
BRKSPV-2160 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public
Content Ingest
 Encoders “push” Content to Origin Servers (WebDAV, FTP)
– Content is always sent
 Content Acquirers “pull” Content from Origin Servers (HTTP GET)
– Only when strictly required (on user request)
GET http://live-origin.cp.com/ GET http://live.cp.com/

POST/PUT http://live-origin.cp.com/
Live CDN
OS CA SE
Enc
GET http://vod-origin.cp.com/ GET http://vod.cp.com/
OD
Enc NAS
Origin Server
 Ingest must be flexible, resilient
and secure
 One CDN can ingest from multiple
Origin Servers
– Local or in remote locations
 Origins can be replicated
– Locally (load balancing)
– Remotely (disaster recovery)
 Origins can have structure
– Security
– Capture/Recording/Playout
separation for better scalability
HTTP ABR streaming concepts
 Content + Content Representation
Client monitors
 The client is intelligent
- Playout buffer
- Local resources (CPU, memory, screen, etc.)
- Network (TCP) connections and bandwidth
Client manages
Manifest
- Manifest database
Fragments - HTTP transport
- TCP connection(s)
Client performs adaptation
Microsoft Smooth Streaming
Origin server operation (1/2)
Encoder facing
 Receives fragments & “server” manifest
 For live:
– Builds and maintains “client” manifest
Fragment Fragment Movie
– Maintains fmp4 file on disk
File Type
Movie Fragment
(ftyp)
(moof)
(moof)
Fragm
(mdat)
Fragm
(mdat)
Movie
Movie
Media
Media
Metadata Random
Data
Data
ent
ent
Access
– Updates the “mfra”/index box
(moov)
(mfra)
 Runs a “http handler” (IIS extension)
Microsoft Smooth Streaming
Origin server operation (2/2)
Client facing Fragment
 Delivers most current client manifest
Fragme
(moof)
(mdat)
Media
Movie
Data
nt
– Client manifests are downloaded once
GET 720p.ism/QualityLevels(572000)/Fragments(video=160577243) HTTP/1.1
 For each http GET

– Lookup “mfra” box, retrieve fragment offset
Fragment Fragment
File Type (ftyp)

Movie
Fragment
Movie Metadata
Movie Fragment
Movie Fragment
Random
Media Data
Media Data
(moov)
(moof)
(moof)
(mdat)
(mdat)
Access
(mfra)
– Retrieves fragment, present it to http engine

– Delivers fragment via http to client
Apple HLS Streaming
Origin Server operation
Encoder facing .ts .m3u8
 Encoder publishes via FTP or

WebDav
 Segments stored as “small objects” GET http://video.com/Medium.m3u8
GET http://video.com/Medium/segment-00073.ts
 Live manifest - maintained by
Encoder
Sliding window, e.g. last 6 segments
Client facing
 Live/VOD, client downloads playlist
For live, playlist downloaded periodically
Sliding window cfg ->length of the playlist
 Segment URL in the playlist refers a
file on disk (URI)
“ordinary” web server as origin
Smooth vs. HLS Format Comparison
80% similar, 100% incompatible
HSS (Microsoft) HLS (Apple)
Transport Protocol HTTP HTTP
Fragment Size (typical) 2 seconds 10 seconds
#TCP connections 2 1
# Content Files on Origin Server #profiles #profiles x 360/Hr of content
Codec Support VC-1, H.264,WMA H.264
Wire Format MP4 fragments MP2TS fragments
Content File Format on Origin Server .ismv, Fragmented mp4 .ts, Segmented TS
Byte Range Mechanism No YES (later drafts)
Std HTTP Origin Server No Yes
Encryption/DRM Windows DRM PlayReady AES-128 (only encryption)
Client Silveright, OSMF (OpenSource) iPhone OS +, Quicktime X
Client Manifest file .ismc (.ism/Mfest or .isml/Mfest) .m3u8
Origin server Helper integrated with IIS server HTTP server
New services - Time Shifted TV (TSTV)
 Time shift TV, delayed viewing of a live event. Two flavors:
Restart TV (startOverTV), accessible only during the event
Catch-up TV accessible only after the event (via VOD catalog or reverse EPG)
 Restart vs Catch-up TV - similar functionality, different implementation

Re-start TV: “Sliding window”, buffer maintained on Origin Server (aka DVR window)
Catch-up TV: “Recording” a VOD asset and publish the recording
 Both services require additional client and backend logic
Time Shifted TV – Origin Server Role
 The defaults : “rolling” buffer for Live TV (sliding window)
Maintained by the encoder in HLS, 3 segments.
Maintained by the IIS helper in HSS/Smooth, 3 segments.
 Restart TV “rolling” buffer with additional segments

maintained by:
The encoder, in HLS
The IIS helper in HSS/Smooth
 Catch-up TV / Archive – the event will be recorded on storage, recordings

performed by
The Encoders for HLS (followed by VOD typical transcode workflow)
The IIS helper for HSS/Smooth (producing the ABR format)
New services - cloud DVR (cDVR)
 Recording types
– Shared
– Unique
 Integrated with OS
functions
– Playout
– On-demand
encapsulation and
encryption
 Highly unique
content
– Low playout demand
– Low hit ratio
 – Storage
Like TSTV, demanding
requires backend logic
CDN - Introduction to dynamic caching
 Concepts CDN
TPS
– “Proxy” for Origin Servers Content

Service
Router
– Redirecting clients to CDN Origin Acquirers =

Servers ROOT Edge
streamers
– CDN functional elements Acquir
Ingest
BW Acquir
Cache
Fill BW
Egress
BW
End-
points
ers er
 Implementation Content
Library
Cache
Storage
Cache
Storage
– Popularity, admission and eviction algorithms

–
Nr of
Cache pollution and content affinity cache
access
Content popularity
– From URL to CDN file system Main i j N

rank
memory
– ABR Context: impact of small objects

Flash disk
Cache
– CDN tiered storage, cost f(latency) Spinning disk
Hit
ratio Cache hit ratio, f(popularity)
Cache size
as % of Content Library
Let’s recap
Directly influencing the OS and CDN element performance
 Smooth/HSS / HLS protocol differences

Different disk and wire format => Origin server assumes different functionality
Miscellaneous: other differences, out of scope of this presentation
 Smooth/HSS / HLS - The Origin Server implementations

Helper application vs ordinary web server
RestartTV (DVR window) and Cacth-up TV, handled differently by the OS
Different operating system, different performance model
 CDNs – many factors

Content popularity
CDN hardware (processor, NIC, memory & storage size)
The CDN implementation and specific ABR optimizations
CDN Architecture
Caching basics
Origin Server
 RFC2616 OS OS
 Cache Types
Internet
– Proxy Caches CDN
– Transparent Caches
– Private Caches
Proxy
Transparent
 CDN acts as a Proxy Cache to the Cache
Cache
Origin Server SR
– OS performs revalidation
 CDN efficiency
– How much popular content can the
CDN cache
DNS
CDN Reference Architecture
 Basic CDN Design
– Two tiers
 Acquisition (ingest)
 Edge Delivery
– Two node types
 Datacenter
 Edge PoP
 Three planes
– Content Data Plane
– Content Routing Plane
– Management Plane
 Hierarchical Caching
– Popularity based
Hierarchical Caching
Architecture highlights
 Highly scalable Architecture vs. Centralized Caching systems

– Ingest and Delivery scale independently
– Higher overall Cache Hit Ratio
 A CDN Overlay is a perfect fit to hierarchical networks
– Service Provider Networks are hierarchical
 Popularity based caching algorithm makes efficient usage of caching storage
vs. Backoffice-based popularity management
 Multi-tier CDN optimizes overall system performance and resiliency
– Edge-tier Streamers focus on high performance delivery
– Acquisition-tier Streamers can provide for both ingest (Content Acquirer) and backup
streaming when PoP Streamers fail or are overloaded
– Multiple redundancy models for Streamers and Acquirers
Content Routing
 Request Redirection model Origin Server
– Service Router is the Authoritative

Nameserver for Service domain names
Geo-Location and Proximity
 30x based redirection Services
– Service Router resolves domain name to
its IP address
– Service Router then uses 302/307 CDN
redirection to a Streamer Request
Redirection
 DNS based redirection
– Service Router resolves domain to IP
DNS
address of Streamer
 Service Router uses Static IP, Geo-
location and Proximity Services
Other CDN Architectures
 Hierarchical Streaming
C BO
– Backoffice monitors content
popularity
– Backoffice drives content distribution
 Popular Content is pushed to the edge C
 Long-tail Content is streamed centrally
– Content popularity may change
 Peer to peer C C C
– Distributed Hash Table model
– Content can be cached anywhere
– Appropriate in fully meshed
topologies C C C
The Challenges with Distributing ABR Objects
Old World Movie.mp4
Progressive Download
Frag1-1 Frag1-2 Frag1-3 Frag1-Z
New World . 2hr movie, 2s segments
ABR Delivery . 3600 fragments x 7 profiles
FragN-1 FragN-2 FragN-3
. 25,000 objects/movie FragN-Z
 Short fragment sizes translate to very high request TPS

 TCP connections can be short-lived (client and network conditions)
 Fragment sizes (HLS v. Smooth) - mean object sizes are different.
CDS object handling can be configured on a per-DS basis
Transaction Rates, TPS Object Size (MB)

Obj Client TPS for
Length Request 2000 Objects/Hour Obj/Hr 200
(sec) TPS clients /Asset channels 3000 kbps 1500 kbps 500 kbps
Smooth 2 0.500 1,000 1800 360,000 Smooth 0.75 0.38 0.13
HLS 10 0.100 200 360 72,000 HLS 3.8 1.9 0.6
PDL 3600 0.000 0.56 1 200 PDL 1,350 675 225
CDN Optimizations for ABR
 Optimized TCP connection handling
Scaling to support the large # of connections for ABR
 Optimized HTTP request handling
Scaling to support the large # of GET requests for ABR
 Request Bundling
For live streaming, aggregates multiple cache-fill requests
for the same content into a single request to the next
cache-tier or Origin Server
 Small Object Cache Throughput Optimizations
Small objects written to memory, delayed write to disk
(SSD or HDD)
Large objects continue to be cached on disk
Client/Streamer Stickiness (Content Affinity)
 Service Visibility
Reporting and Analytics optimizations for ABR
Wholesale Services
 In VDS-IS since day one: Delivery
Service concept
– Virtual CDN equivalent
 VDS-IS Enhancements on support
of Wholesale Services
– Per Delivery Service bandwidth limits
– Per Delivery Service max sessions
– Per Delivery Service transaction logs
 Per CP Reports available using
Cisco Analytics
– Cisco VDS-SM Service Manager
Proximity Routing
 Separate Content Routing Plane
– Implemented at Service Router
– Better system scalability
 Streamers inform Service Router
about status and load using
keepalive messages
– Streamer Redundancy
 Variety of Streamer Selection
criteria available
– Load, content and service
availability, content based routing,
last resort routing
– Include network metrics via NPS
Web Acceleration
 Accelerate webpage loading on
any device, any browser
 Caching optimizations for small
objects
 Front-End Optimization (FEO)
– Rewrite HTML for better rendering
 Application Delivery Controllers
– SSL, GZIP, App load balancing
 HTTP Security
– HTTP DDOS, HTTPS, Attack
Mitigation
CDN Interconnection (1/2)
 IETF work on CDNI group
 Practical experience in Cisco
sponsored CDN Federation Pilot
Validate CDN Interconnection from both
Business and Technical viewpoints
Business and Technical Tracks
Three phases completed
I - Validate existing CDN platforms
II - Test CDN Selection enhancements
III - Service Oriented
Now launching the Alpha CDN Federation
Service
Participation from CPs, SPs, Public CDN
Providers and Exchange Service
Providers
CDN Interconnection (2/2)
 CDN Selection
– URL Rewriting and Re-Signing
techniques
– Keep CP information opaque
– Service Broker concept (VDS-SB)
 Inter-CDN Ingest
– Upstream CDN concept
– OS URL mappings
 VDS-SB
CDN Virtualization
 Virtualization of CDN functions
– From appliances to bare metal
servers to VMs
 Leverage virtualization capabilities
– Storage, Processing, Networking
 Dynamic VM creation/deletion
– Elastic CDNs
 Standards based, open source
– OpenStack support
Other CDN aspects
 CDN Analytics  Security
– Monitoring and Reporting – DDOS Attacks
– Sizing – ACL protection
– Optimized for ABR
 Management  IPv6
– Service Provisioning – Control plane (Service Router)
– Operation – Data Plane (Streamers)
– Ingest (Content Acquirers)
 VDS-SM and CDSM
Architecture recap
 While other architecture models
exist, Hierarchical caching is the
best fit for Service Provider
networks
 CDNs are optimized for certain
content (e.g. VDS-IS is optimized
for ABR Video)
 CDNs must be multiservice
– Support any content type
– Web Acceleration features
– Wholesale
– CDN Interconnection
Sizing a CDN
Before we start
 Expected CDN efficiency goal
Throughput Library Size
 Cache parameters
– Cache performance Streaming Performance Caching Performance
– Cache disk technology and size
On-demand Cache Size
 System parameters Live Performance
Performance
Popularity
# Titles
– Topology (number of PoPs, tiers)
Object CHR
– Edge throughput # Channels
Protocol
size
– Live/on-demand ratio
Topology
– OD Library size
– Popularity distribution curve
– Failover/Redundancy policy CDN Efficiency
Topology
 OS Sizing depends on CDN OS OS
efficiency
100 10 90% CDN
 Define CDN topology and apply Efficiency
Hierarchical Caching to achieve
efficiency goal CA
20
 Example
– CDN Efficiency goal: 90%
– Two-tier CDN (edge + acquisition) SE SE
– Edge CHR: 80%
– Acquisition CHR: 50% 100
– Efficiency = 1 – (1 – Ec)*(1 – Ac) = 90%
Edge Throughput
 For each Edge PoP live
50 live channels
– Obtain the peak throughput VoD Agg bitrate = 10 Mbps
Live/VoD ratio = 60%
– Obtain Live performance (Gbps) OS
f(# channels, bitrate, format) NAS
Edge PoP CHR = 80%
– And On-demand performance Acquisition CHR = 50%
3 0.5
f(CHR, bitrate, format) Total Ingest = 3.5 Gbps
– Prorate using Live/OD ratio
– Put as many caches as needed
– Add resiliency option (1+0, 1+1,
N+1) 4 2
0.5
– Calculate OD distribution traffic 0.5
 Calculate Live distribution traffic
– Aggregate bitrate of all the Live
channels at all the profiles 20 30 10 15
Acquisition Throughput
 For each Acquisition site live
50 live channels
– Obtain the distribution traffic VoD Agg bitrate = 10 Mbps
Live/VoD ratio = 60%
– Obtain On-demand performance OS
f(CHR, bitrate, format) NAS
Edge PoP CHR = 80%
– Put as many acquirers as needed Acquisition CHR = 50%
3 0.5
– Add CA resiliency option (1+1, N+1) Total Ingest = 3.5 Gbps
– Add Disaster Recovery option
– Add PoP failure option
 Calculate Ingest traffic 4 2
– OS sizing 0.5
0.5
20 30 10 15
Popularity and CHR
CHR
a
 Meet the CHR goals for the
different tiers
– Provide room for a minimum
portion of the content Library
 Get an estimate of popularity
distribution for on-demand
– Zipf’s law P(k) = k-a / Si=1,N i-a
– 80/20 rule of thumb
 Determine min cache storage
and load it into
streamers/acquirers
– On a per-location basis with
Content Affinity
Other factors
 ABR
– CHR more difficult to predict
than for PDL
 Refresh
– Additional traffic caused by
temporary content renewal
– Triggered by revalidation
 Eviction
– Popularity driven
– Also depends on size, decay
 Topology Considerations
– Hierarchical Caching gains
– Content Affinity
Sizing the Content Routing plane
 Transactions per second (TPS)  Example
– Driven by number of absolute URLs – 50K concurrent streams @ 1
that require DNS resolution Mbps average bitrate (50 Gbps
system)
 TCP connections per stream – 20 min average viewing time
– HSS uses two (audio, video), HLS – 50,000 / (20 x 60) = 41.7 TPS
one
– Allow for 20% burst = 50 TPS
 Other aspects
– Geo-location queries
– Proximity requests
– Both are cached
CDN Sizing Methodology recap
 Set your Expectations
– Given your OS and network resources, establish the edge and acquisition CHR
 Collect service data, ideally from an Analytics System
– Topology: # of PoPs, # of Acquisition nodes, # of Intermediate nodes if any
– Throughput: Expected peak traffic per PoP, Live/VoD ratio
– Traffic: formats, profiles, bitrates
– VoD: Library size, popularity distribution
– Resiliency requirements: 1+1, N+1
– Request Routing: # of TPS
 Obtain cache performance at expected CHR (edge and acquisition)
– For both live and on-demand and prorate to obtain performance per unit
 Put as many streamers and acquirers as required (performance) and load them
with as much caching storage as required to match the CHR
 If it works, don’t touch it. Otherwise, go to square 0
Summary and final recap
 New Video Technologies and Services are putting pressure on CDNs
– ABR
– Timeshift TV, cloud DVR
– Many optimizations required
 Hierarchical Caching CDN Architecture is the best fit for Service Providers
– Leverage hierarchical networks in SPs
– Easily extendable to Wholesale, CDN Interconnection and other services
 CDNs can be properly dimensioned following a Methodology
Related Sessions
 BRKSPV-2999 Wednesday 11:30 - 13:00 (90 min)
– Virtualized and elastic Video Preparation and Distribution - Francois Le Faucheur
 BRKSPV-2931 Thursday 14:30 - 16:00

– Service federation across Service Providers, Global CDNs and Media Companies -
Francois Le Faucheur
Call to Action…
Visit the World of Solutions:-
 Cisco Campus
 Walk-in Labs
 Technical Solutions Clinics
 Meet the Engineer
 Lunch Time Table Topics, held in the main Catering Hall
 Recommended Reading: For reading material and further resources for this
session, please visit www.pearson-books.com/CLMilan2014
Complete Your Online Session Evaluation
 Complete your online session
evaluation
 Complete four session evaluations
and the overall conference evaluation
to receive your Cisco Live T-shirt

BRKSPV 2160

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

BRKSPV 2160

Diunggah oleh

Hak Cipta:

Format Tersedia

CDN Architecture and Sizing

 Understand the differences between various CDN Architectures

 Describe the key parameters and challenges of sizing a CDN presenting a

Live & VOD

Content Preparation workflows

Our focus today

Encoding CDN – Content Distribution Clients

Content Acquirer Streamer Engine

– Perform Revalidation functions

GET http://live-origin.cp.com/ GET http://live.cp.com/

GET http://vod-origin.cp.com/ GET http://vod.cp.com/

Client performs adaptation

 Runs a “http handler” (IIS extension)

Client facing Fragment

 Delivers most current client manifest

 For each http GET

File Type (ftyp)

– Retrieves fragment, present it to http engine

Encoder facing .ts .m3u8

 Encoder publishes via FTP or

Transport Protocol HTTP HTTP

Fragment Size (typical) 2 seconds 10 seconds

# Content Files on Origin Server #profiles #profiles x 360/Hr of content

Codec Support VC-1, H.264,WMA H.264

Wire Format MP4 fragments MP2TS fragments

Byte Range Mechanism No YES (later drafts)

Std HTTP Origin Server No Yes

Encryption/DRM Windows DRM PlayReady AES-128 (only encryption)

Client Silveright, OSMF (OpenSource) iPhone OS +, Quicktime X

Client Manifest file .ismc (.ism/Mfest or .isml/Mfest) .m3u8

Origin server Helper integrated with IIS server HTTP server

 Restart vs Catch-up TV - similar functionality, different implementation

 Both services require additional client and backend logic

 Restart TV “rolling” buffer with additional segments

 Catch-up TV / Archive – the event will be recorded on storage, recordings

– “Proxy” for Origin Servers Content

– Redirecting clients to CDN Origin Acquirers =

– Popularity, admission and eviction algorithms

– From URL to CDN file system Main i j N

– ABR Context: impact of small objects

 Smooth/HSS / HLS protocol differences

 Smooth/HSS / HLS - The Origin Server implementations

 CDNs – many factors

 Highly scalable Architecture vs. Centralized Caching systems

– Service Router is the Authoritative

 Short fragment sizes translate to very high request TPS

Transaction Rates, TPS Object Size (MB)

 CDNs can be properly dimensioned following a Methodology

 BRKSPV-2931 Thursday 14:30 - 16:00

 Meet the Engineer

 Lunch Time Table Topics, held in the main Catering Hall

Anda mungkin juga menyukai