DeepField Data Shows Apple Traffic Jumping From 200Gbps to 3Tbps Thanks To iOS8 Downloads

Following up on the data I already published from Qwilt, DeepField has also shared some data with me showing just how much traffic spiked when Apple’s iOS 8 download was released. DeepField collects data from ISPs that participate in their Internet Observatory research project and the below chart shows Apple traffic from those ISPs, which normally sits around 200Gbps combined, peaking at 3Tbps at 6:15pm ET on Wednesday night. The data represents a cross section of consumer providers, mostly in North America, covering many tens of millions of users. Apple’s new CDN is impressive, it has massive capacity and service providers are seeing solid download rates across the board. Apple did rely on Akamai, Limelight and Level 3 for a small percentage of their overall downloads and I’ll have more details on that in a follow up post.

Screen Shot 2014-09-17 at 11.03.19 PM

For more on Apple’s CDN buildout, see these previous posts:

Feb 3rd: Apple Building Out Their Own CDN To Deliver Content To Consumers

May 20th: Apple Negotiating Paid Interconnect Deals With ISPs For Their Own CDN

July 31st: Apple’s CDN Now Live: Has Paid Deals With ISPs, Massive Capacity In Place

Apple iOS 8 Traffic Already 50% Higher Than Regular Traffic Inside ISP Networks

Apple’s iOS 8 update is just kicking into high gear now with the peak expected to hit later this evening as people arrive at home and start updating. Based on data from transparent caching provider Qwilt, traffic inside some last mile networks is already 50% higher than regular network traffic at 4pm PST. It’s also a much bigger update this time around with iOS 8 coming in at 1.3GB versus iOS 7 at 750MB. As of 6pm EST, Apple was accounting for 20.6% inside some networks in the U.S., which is half of Netflix’s 40% share. In France, where iOS 8 launched on the 15th, Apple accounted for the top percentage of traffic, at 24% beating out YouTube at 19.6%. And it’s clear that some ISPs are already capping users on their network.

Data shows that service providers that have deployed Qwilt are caching over 90% of iOS 8 traffic. Apple’s own CDN is doing the majority of the downloads in the U.S., possibly all of them, as I have yet to see a traceroute from the U.S. showing Akamai or any other third party CDN. Outside of the U.S., it does appear that Apple is using third party CDNs in select countries.

one

two

three

Apple’s iOS 8 Downloads Coming From Their Own CDN, Likely Will Be a Traffic Record

I’ve looked at a lot of traceroutes today for the download of Apple’s iOS 8 update and so far, all the records I have seen show they are coming from Apple’s own CDN, not third-party CDNs Akamai and Level 3. It’s still possible Akamai and Level 3 have some of the business, but so far, I only see it coming directly from Apple, which is what I expected. Also, even though it has only been two hours since the iOS 8 download went live, from preliminary data that some ISPs have shared with me, it also looks like iOS 8 will be a traffic record inside last mile providers. I’ll have an updated post when I have more chart and figures on size of the traffic inside ISPs as soon as I get it. I’m still looking to view more traceroute info, so if you have any you can send me, especially from outside the U.S., please email it to me.

Update 3:52pm: One user in Finland is reporting the download coming from Akamai. Would make sense that Apple would use CDNs outside the U.S., but to what extent is still unknown.

Update 7:11pm:  Three tracroutes from London all show Apple as the CDN. I haven’t yet seen a single traceroute in the U.S. showing anyone but Apple for delivery.

3  31.55.187.197 (31.55.187.197)  7.758 ms  7.496 ms  7.168 ms
4  31.55.187.232 (31.55.187.232)  9.369 ms  9.544 ms  9.378 ms
5  195.99.127.0 (195.99.127.0)  12.364 ms
195.99.127.52 (195.99.127.52)  9.704 ms  9.504 ms
6  62.6.201.187 (62.6.201.187)  10.158 ms
host213-121-193-139.ukcore.bt.net (213.121.193.139)  11.071 ms
194.72.31.143 (194.72.31.143)  10.443 ms
7  t2c3-xe-1-1-3-0.uk-lon1.eu.bt.net (166.49.211.182)  9.692 ms
t2c3-xe-0-2-2-0.uk-lon1.eu.bt.net (166.49.211.174)  10.888 ms
t2c3-xe-0-1-2-0.uk-lon1.eu.bt.net (166.49.211.166)  10.196 ms
8  166-49-211-254.eu.bt.net (166.49.211.254)  109.327 ms  109.568 ms  109.273 ms
9  ae14-xcr1.lnd.cw.net (195.2.30.113)  111.650 ms  108.923 ms  108.916 ms
10  ae1-xcr1.slo.cw.net (195.2.31.202)  119.320 ms  119.162 ms  119.422 ms
11  apple-gw.slo.cw.net (195.89.40.2)  120.190 ms  139.025 ms  119.704 ms
12  uklon5-vip-sx-002.aaplimg.com (17.253.34.222)  10.935 ms  11.559 ms  10.968 ms

VC-1 Is Dead: Open Standards Finally Winning the Battle Against Proprietary Formats

It’s that time of the year again, where myself and the digital media team at Frost & Sullivan capture key video technology trends in the media and entertainment world. The industry has come a long way in the last three years, with the alphabet soup of walled garden formats giving way to the relative uniformity of AVC, AAC and AES-128. Granted encapsulation and streaming formats are still a complex enough mess in their own right, but that’s another post for another day.

The drive away from walled gardens towards more open standards is being driven in good measure by, surprisingly enough, Microsoft. Having announced the sunset of SmoothStreaming in 2021 and put significant energy behind DASH and open DRM interfaces for use in standards like HTML5, the company is continuing to step away from the WMV-centric media framework approach it pursued in the early 2000s. Many legacy video formats like RealPlayer and Flash have already faded away. It is perhaps a testament, however, to Microsoft’s early supremacy in the premium OTT video delivery market (although no one called it as such back then) that services like Netflix, Amazon and Rakuten continue to have VC-1 encoded content in their libraries, even though several others like Hulu and Vudu nearly ubiquitously use AVC. That said, there’s little if any incentive – we believe – for new transcoding in WMV format. Even for legacy content, we believe that either re-encoding that material or simply just-in-time transcoding it to AVC is the preferred alternative to storing and managing yet another profile, given that new connected devices are showing a clear drop year over year in support for legacy formats.

One step beyond the video essence is the streaming protocol. The debate between HTTP based streaming and UDP based streaming rages on, particularly in the context of the emergence of DASH, the sunsetting of Silverlight, the demise of Flash on mobile, and the unrelenting drumbeat of statistics that shows video traffic growing in exciting multiples year over year while
infrastructure/capacity will struggle significantly to keep pace. There are indications that even stalwart CDNs like Akamai are looking past the prevalent approach of HTTP-based streaming to look at UDP-based alternatives, at least for high-volume surge content if not more broadly. However, confidence in UDP-based and P2P-based approaches in North America – which accounts for nearly 70 percent of global OTT traffic by our estimates – seems to remain quite low.

We’re currently predicting that use of VC-1 will fade out of M&E content services (enterprise is a different story) more or less entirely within 5 years, with AVC and possibly new codecs like HEVC and Google-backed VP9 starting to make niche appearances. We thought we’d reach out to readers for their feedback on these observations and predictions – are you using VC-1 in your OTT streaming offerings today, and how do you see your codec portfolio changing over the next five years? And, are you looking at UDP-based streaming solutions for your future video streaming needs (even if it’s 4-5 years out) or are you confident that technologies like DASH are the way to go? Are there particular emerging streaming solutions that you find exciting or promising? We’ll compile all our findings in a follow up post – for now, please feel free to comment below. Or if you want to have a deeper discussion on this topic, please email me and we’ll be happy to setup a time to hear your thoughts.

Thursday Webinar – Transcoding and Prepping Content for The Multiscreen Mandate

Thursday at 2pm ET, I’ll be moderating another StreamingMedia.com webinar, this time on the topic of, “Transcoding and Prepping Content for The Multiscreen Mandate.” Encoding your video is one thing; transcoding is another ball of wax entirely. As multiscreen video consumption continues to grow, how does a company with a large video library ensure the best viewing experience, especially when new devices — and their wide array of screen sizes and operating systems — continue to enter the playing field? We’ll discuss workflows and on-prem and cloud solutions that offer ease, efficiency, and cost savings for your video publishing, on demand and live. Join iStreamPlanet, Akamai, Adobe, and Ooyala to learn about:

  • The top three challenges facing content owners and distributors in delivering multiscreen services
  • Secure, cloud-based media processing that offers high quality content preparation through an efficient turnkey media solution
  • One-stop content preparation and packaging for multiple platforms for both live and on-demand media
  • Supporting a wide range of source codecs from established broadcast codecs to newer codecs like h.264/h.265
  • Integration with a content management system and playback infrastructure to support existing and new business models

These questions and many more will be covered in this webinar so REGISTER NOW to join us for this FREE Web event.