Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

On ABR Streaming and CDN Performance

135 views

Published on

ABR and cache efficiency.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

On ABR Streaming and CDN Performance

  1. 1. Yuriy Reznik, Brightcove, Inc. ON ABR STREAMING AND CDN PERFORMANCE © Brightcove, Inc. All Rights Reserved.
  2. 2. © Brightcove Inc. All Rights Reserved. 2 SOME FACTS FROM HISTORY • Streaming was NOT the first form of video transmission over networks ◦ video phones were there first – AT&T, CLI, PictureTel, H.324/323 stacks, etc. ◦ and many folks tried using same stacks for streaming – but without success • First successful streaming systems (1995+): ◦ RealAudio/RealVideo, Vivo Active, VXtreme, NetShow, etc. ◦ UDP-based stacks, H.263-derivative video codecs, speech codecs for audio ◦ The use or pre-roll delay was absolutely critical to improve quality! • First adaptive bitrate (ABR) streaming system: ◦ RealSystem G2, released in 1998 ◦ It was also UDP based, with server-based “SureStream” adaptation ◦ It was patented: US6314466, US6480541, US7885340, etc. • But the basic concept of multi-rate encoding was actually invented earlier: ◦ E.g. it was found helpful in wireless telephony (AMR, VMR, EVRC codecs) ◦ The difference between ABR streaming and wireless applications was that in streaming all streams were generated ahead of time, while in wireless, encoder mode was dynamically switching.
  3. 3. © Brightcove Inc. All Rights Reserved. 3 HOW ABR STREAMING WAS ENVISIONED TO WORK? • This was the original architecture: • It was the server that was selecting which streams / packets to send and how ◦ In the initial design everything was done over UDP, and server was also handling retransmissions, FECs, etc. ◦ Bandwidth estimation was also initially server-based, but it was later moved to client to minimize delays ◦ And importantly – only one version of the encoded stream was sent for distribution. ◦ Multi-rate encodings were only stored on the streaming server. • But this system was not scalable! ◦ The servers were the weakest links! Handling events beyond 1000 concurrent streams was a challenge. ◦ More evolved systems with proxy servers and caches have started to appear... Until UDP was abandoned altogether.
  4. 4. © Brightcove Inc. All Rights Reserved. 4 HTTP-BASED ABR STREAMING • Thanks to Move Networks (2007), and then Apple/HLS and others – most streams are now sent over HTTP • The ABR adaptation model in HTTP streaming is actually very similar to one used earlier: • What is different, however, is that: ◦ instead of streaming server, a regular HTTP server is used as origin ◦ stream switching is trivialized to HTTP GET operations originating from streaming client ◦ the scaling and delivery is delegated to CDN, which basically caches content on its edges, and thus reduces the load on the origin... • This works reasonably well when the content is popular and becomes stored in the edge cache • This also works when content needs to be pulled back from the origin server, but in this case, it may incur additional delays, and extra costs for “CDN midgress” traffic.
  5. 5. © Brightcove Inc. All Rights Reserved. 5 DISCONNECT BETWEEN ABR STREAMING AND CDN MODEL • Let’s review this diagram again: • There are few issues: ◦ ABR streaming generates several encoded versions of the content, which then start “competing” for CDN edge cache disk space. This increases CDN cache miss rate, and amount of midgress traffic ◦ With modern era OTT streaming it is also common to use several different delivery formats to target different devices. E.g. HLS, DASH, Smooth, etc. They also compete for CDN edge cache, driving the efficiency of the entire system down. ◦ And we also have new codecs, such as HEVC, AV1, and VVC, resulting in even more streams representing same content, competing for same CDN edge cache. • In other words, ABR streaming concept promotes creation of “more” streams, but what CDN really needs to be most effective is “less”!
  6. 6. © Brightcove Inc. All Rights Reserved. 6 WHAT GETS CACHED ON CDN? • Naturally, the content that is retrieved most often • For example, if ◦ we have a set of items 𝑆 = 𝑠 𝑥, 𝑥 ≥ 1 , ◦ we assume popularity model: 𝑝 𝑥 = 𝑥−𝛼 ζ(α) where 𝛼 is a shape parameter, and ζ . is a Riemann Zeta function, and ◦ we also assume that CDN cache can only hold C most probable items, then CDN cache miss probability becomes: 𝑝 𝑚𝑖𝑠𝑠 𝐶, 𝛼 = 1 − ෍ 𝑥=1 𝐶 𝑝 𝑥 = 1 − 𝐻𝐶,𝛼 ζ α , where 𝐻𝐶,𝛼 = σ 𝑥=1 𝐶 𝑥−𝛼 is a generalized Harmonic number • Asymptotically, with large cache capacity C: 𝑝 𝑚𝑖𝑠𝑠 𝐶, 𝛼 ~ 𝐶1−𝛼 𝛼 − 1 ζ α 1 + 𝑂 1 𝐶 • In other words, we have a reasonably simple model! Shape of popularity distribution model for different values of parameter 𝛼 Empirically measured popularity of videos on YouTube M. Cha, H. Kwak, P. Rodriguez, Y-Y. Ahn, S. Moon, Sue. (2009). Analyzing the Video Popularity Characteristics of Large-Scale User Generated Content Systems. IEEE/ACM Trans. Netw.. 17. 1357-1370.
  7. 7. © Brightcove Inc. All Rights Reserved. 7 WHAT IS CACHED WHEN WE HAVE 2 VERSIONS OF SAME CONTENT? • Let’s consider 2 sets: 𝑆1 = 𝑠1,𝑥, 𝑥 ≥ 1 , and 𝑆2 = 𝑠2.𝑥, 𝑥 ≥ 1 • Let also 𝜋 = 𝜋1, 𝜋2 denote usage probabilities of both versions • Then full probabilities of such items become: 𝑝 𝑠1,𝑥 = 𝜋1 ⋅ 𝑝 𝑠 𝑥 and 𝑝 𝑠2,𝑥 = 𝜋2 ⋅ 𝑝 𝑠 𝑥 • And then, at the top of the CDN cache we will observe the following structure (case when 𝜋1 > 𝜋2): • In other words, items in less frequently used format become interleaved with step size 𝑥~ Τ𝜋1 𝜋2 Τ1 𝛼 ! Item Probability Comments 𝑠1,1 𝜋1 𝑝 1 First go items of more frequently used format ... ... ... 𝑠1,𝑥 𝜋1 𝑝 𝑥 𝑥 = 𝜋1 𝜋2 1 𝛼 , solution of 𝜋1 𝑝 𝑥 = 𝜋2 𝑝 1 𝑠2,1 𝜋2 𝑝 1 Now comes first item in less frequently used format 𝑠1,𝑥+1 𝜋1 𝑝 𝑥 + 1 Then follow items in more frequently used content ... ... ... 𝑠1,𝑥2 𝜋1 𝑝 𝑥2 𝑥2 = 2 𝜋1 𝜋2 1 𝛼 , solution of 𝜋1 𝑝 𝑥2 = 𝜋2 𝑝 2 𝑠2,2 𝜋2 𝑝 2 Now comes second item in less frequently used format 𝑠1,𝑥2+1 𝜋1 𝑝 𝑥2 + 1 Then follow items in more frequently used content ... ... ...
  8. 8. © Brightcove Inc. All Rights Reserved. 8 CACHE MISS PROBABILITY WITH 2 VERSIONS OF SAME CONTENT • Using fairly simple math, we can next show that in case of 2 versions of same content, the cache miss probability becomes: 𝑝 𝑚𝑖𝑠𝑠,2 𝐶, 𝛼, 𝜋 ~ 𝜋1 1 𝛼 + 𝜋2 1 𝛼 𝛼 𝐶1−𝛼 𝛼 − 1 ζ α 1 + 𝑂 1 𝐶 • Let’s now compare it with cache miss probability in case of only 1 version: 𝑝 𝑚𝑖𝑠𝑠 𝐶, 𝛼 ~ 𝐶1−𝛼 𝛼 − 1 ζ α 1 + 𝑂 1 𝐶 • Naturally, if we next look at ratio: 𝜉 𝛼, 𝜋 = 𝑝 𝑚𝑖𝑠𝑠,2 𝐶, 𝛼, 𝜋 𝑝 𝑚𝑖𝑠𝑠 𝐶, 𝛼 ~ 𝜋1 1 𝛼 + 𝜋2 1 𝛼 𝛼 we notice, that it becomes asymptotically independent on C! • In other words, considering any CDN with reasonably large cache, we can predict that the use of 2 versions will increase its cache miss probability by 𝝅 𝟏 𝟏/𝜶 + 𝝅 𝟐 𝟏/𝜶 𝜶 • The worst impact happens when both versions are equally probable (𝜋1 = 𝜋2) • The higher is the asymmetry in usage of different formats (or renditions), the better it is from CDN efficiency standpoint! Relative increase in cache miss probability in case of using 2 formats.
  9. 9. © Brightcove Inc. All Rights Reserved. 9 APPLICATION 1: WHEN IT MAKES SENSE TO DEPLOY HEVC? • Consider the following: ◦ 𝑅 = encoding rate used by H.264 ◦ 𝛿 = rate savings of HEVC vs H.264 (in practice, 𝛿 ≈ 0.25..0.5) ◦ 𝜋 = percentage of devices that can play HEVC (in practice, 𝜋 ≈ 25..100% depending on customer) ◦ 𝛼 = shape parameter of content popularity distribution, which is modeled as 𝑝 𝑥 = 𝑥−𝛼 ζ(α) • Then: ◦ The amount of storage that will be used by mix of H.264 + HEVC streams: 𝑆 = 𝑅 + 𝑅 1 − 𝛿 = 𝑅 2 − 𝛿 → always larger than R ◦ Average bandwidth that will be used by a mix of H.264 and HEVC streams: ത𝑅 = 𝑅 1 − 𝜋 + 𝑅 𝜋 1 − 𝛿 = 𝑅 1 − 𝜋 𝛿 → always less than R ◦ CDN cache miss probability will be affected by a factor: 𝜉(𝛿, 𝜋, 𝛼) = 𝜋 1 𝛼 + 1 − 𝜋 1/𝛼 𝛼 1 − 𝛿 𝜋 1 𝛼 𝜋 1 𝛼 + 1 − 𝜋 1/𝛼 𝛼−1 Factor 𝜉(𝛿, 𝜋, 𝛼) can be greater or less than 1 based on values 𝜋 and 𝛿.
  10. 10. © Brightcove Inc. All Rights Reserved. 10 ANALYZING CHANGE IN CDN CACHE MISS PROBABILITY • Concurrent deployment of HEVC changes CDN cache miss probability by a factor: 𝜉 𝛿, 𝜋, 𝛼 = 𝜋 1 𝛼 + 1 − 𝜋 1 𝛼 𝛼 1 − 𝛿 𝜋 1 𝛼 𝜋 1 𝛼+ 1−𝜋 1 𝛼 𝛼−1 where 𝛿 = rate savings, 𝜋 = device support. • Visualizations: • NB: with HEVC rate savings is 𝛿 = 0.5, we must have 𝜋 ≈ 0.82 (about 82% HEVC support across devices) to achieve same CDN cache miss probability.
  11. 11. © Brightcove Inc. All Rights Reserved. 11 ANALYZING CHANGE IN CDN TRAFFIC & OVERALL COST • Generally, with CDNs we have 2 types of traffic: ◦ CDN edge traffic – traffic that delivers data to end user, billed at 𝐶𝑒𝑑𝑔𝑒 per GB ◦ CDN midgress traffic – traffic that pulls data back from origin served, billed at 𝐶 𝑚𝑖𝑑𝑔𝑟𝑒𝑠𝑠 per GB • The total cost of using CDN, therefore is ◦ 𝐶𝑡𝑜𝑡𝑎𝑙 = 𝑅 𝐶𝑒𝑑𝑔𝑒 + 𝑝 𝑚𝑖𝑠𝑠 𝐶 𝑚𝑖𝑑𝑔𝑟𝑒𝑠𝑠 , where 𝑝 𝑚𝑖𝑠𝑠 is a probability of CDN cache miss ◦ • Now, considering HEVC+H.264 vs H.264-only deployments we will have the following change: 𝐶𝑡𝑜𝑡𝑎𝑙,𝐻.264+𝐻𝐸𝑉𝐶 𝐶𝑡𝑜𝑡𝑎𝑙,𝐻.264 = 1 − 𝜋 𝛿 𝐶𝑒𝑑𝑔𝑒 + 𝑝 𝑚𝑖𝑠𝑠 𝜉 𝛿, 𝜋, 𝛼 𝐶 𝑚𝑖𝑑𝑔𝑟𝑒𝑠𝑠 𝐶𝑒𝑑𝑔𝑒 + 𝑝 𝑚𝑖𝑠𝑠 𝐶 𝑚𝑖𝑑𝑔𝑟𝑒𝑠𝑠 , where 1 − 𝜋 𝛿 reflects change in average rate, and 𝜉 𝛿, 𝜋, 𝛼 change in cache miss probability. • In a case when midgress traffic is much more expensive 𝐶 𝑚𝑖𝑑𝑔𝑟𝑒𝑠𝑠 ≫ 𝐶𝑒𝑑𝑔𝑒, we have: 𝐶 𝑡𝑜𝑡𝑎𝑙,𝐻.264+𝐻𝐸𝑉𝐶 𝐶 𝑡𝑜𝑡𝑎𝑙,𝐻.264 ~ 1 − 𝜋 𝛿 𝜉 𝛿, 𝜋, 𝛼 which is basically a change in midgress traffic.
  12. 12. © Brightcove Inc. All Rights Reserved. 12 ANALYZING CHANGE IN MIDGRESS TRAFFIC • As explained earlier, deployment of HEVC will affect CDN midgress traffic by a factor: 𝜂 𝛿, 𝜋, 𝛼 = 1 − 𝜋𝛿 𝜋 1 𝛼 + 1 − 𝜋 1 𝛼 𝛼 1 − 𝛿 𝜋 1 𝛼 𝜋 1 𝛼+ 1−𝜋 1 𝛼 𝛼−1 where 𝛿 = rate savings, 𝜋 = device support. • Visualizations: • NB: with HEVC rate savings of 𝛿 = 0.25 we need at least 𝜋 ≈ 0.33 (about 1/3 of all devices supporting HEVC) to break even in midgress traffic costs.
  13. 13. © Brightcove Inc. All Rights Reserved. 13 APPLICATION 2: WHEN IT MAKES SENSE TO DEPLOY CMAF? • Initial deployment of CMAF will have to co-exist with older flavors of HLS and DASH • In other words, we have to compare 3-format system (HLS+DASH+CMAF) vs 2-format system (HLS+DASH) • The cache miss probabilities in case of 2 and 3 format systems are respectively: 𝑝 𝑚𝑖𝑠𝑠,2 𝐶, 𝛼, 𝜋 ~ 𝜋1 1 𝛼 + 𝜋2 1 𝛼 𝛼 𝐶1−𝛼 1 − 𝛼 ζ α ; 𝑝 𝑚𝑖𝑠𝑠,3 𝐶, 𝛼, 𝜌 ~ 𝜌1 1 𝛼 + 𝜌2 1 𝛼 + 𝜌3 1 𝛼 𝛼 𝐶1−𝛼 1 − 𝛼 ζ α where 𝜌 = 𝜌1, 𝜌2, 𝜌3 are usage probabilities in 3 format system. • If we next assume that after deployment, CMAF will be supported by 𝜿 presentage of both HLS and DASH players, then: 𝜌1 = 𝜅 𝜋1 + 𝜋2 , 𝜌2 = 1 − 𝜅 𝜋1, 𝜌3 = (1 − 𝜅)𝜋2 • Then, by considering inequality: 𝑝 𝑚𝑖𝑠𝑠,3 𝐶, 𝛼, 𝜌 < 𝑝 𝑚𝑖𝑠𝑠,2 𝐶, 𝛼, 𝜋 or equivalently: Δ 𝜅, 𝛼, 𝜋 = 𝜅 1 𝛼 + 1 − 𝜅 1 𝛼 𝜋1 1 𝛼 + 𝜋2 1 𝛼 − 𝜋1 1 𝛼 + 𝜋2 1 𝛼 < 0 we can arrive at region when deployment of CMAF will reduce CDN cache miss probability!
  14. 14. • Let’s plot Δ 𝜅, 𝛼, 𝜋 with respect to 𝜅 (percentage of CMAF capable players), and 𝜋1 (percentage of currently deployed HLS content vs DASH): • It can be observed that there exists region, where deployment of CMAF will lead to negative Δ 𝜅, 𝛼, 𝜋 and hence lower CDN cache miss probabilities. • Naturally, this will only be possible when percentage of CMAF-capable receiving devices will be high. • For example, for current ballpark numbers (𝛼 = 1.16 and 𝜋1 = 0.75), the minimum CMAF deployment factor that is needed to break even in CDN costs is 𝜿 ~ 𝟎. 𝟖𝟒. © Brightcove Inc. All Rights Reserved. 14 WHEN IT MAKES SENSE TO DEPLOY CMAF? Region where deployment of CMAF will decrease CDN cache miss probability
  15. 15. © Brightcove Inc. All Rights Reserved. 15 CONCLUSIONS • A simple analytical model for assessing CDN performance when delivering multiple renditions and formats used by ABR streaming is proposed • It seems to work, as illustrated by examples we considerer • A more interesting problem, however, is this: ◦ considering what we just learned about CDN performance, can we design ABR streaming system such that it performs optimally? • This needs more work... and promises to be a lot of fun!
  16. 16. Yuriy Reznik | yreznik@brightcove.com THANK YOU! © Brightcove, Inc. All Rights Reserved.

×