Faultline’s research arm, Rethink TV, is gearing up to publish its market forecast for Multi-CDN adoption, and unfortunately, the waters appear quite muddy. Chronicling the move from Public CDN, to Private CDN, and the rise of P2P CDN, has been quite the undertaking, but the big question remains how many customers actually fall under the Multi-CDN definition – using more than one of these approaches.
A history recap is useful, to set the scene. Back in the day, you could only watch video across dedicated video delivery networks – and it was live. Chiefly, these were terrestrial broadcast, very similar to the radio broadcasts that preceded television, cable networks, and satellite feeds. With the arrival of the internet, IPTV emerged as another dedicated infrastructure option, but as internet adoption grew, Over The Top (OTT) delivery stormed onto the scene.
The OTT services, as the name implies, are delivered over the top of other networks, and as so many pay TV service operators had evolved to become ISPs already, they quickly found themselves having to deliver rival video services across their broadband networks.
Running parallel to this shift from dedicated video networks to on-demand OTT services, was the emergence of online-only video – purchases from stores like iTunes, or perhaps a digital version of a DVD or Blu-ray you had purchased. These saw entire copies of a video being sent to the customer, downloaded in full, and stored on the customer’s device – where it could be watched in full, as many times as they liked, without ever having to re-download the file.
Sometimes, this could take hours, and most video players didn’t support the option to watch the file as it was downloading. Instead, you had to wait until the download was complete, before you could fire it up, but once you had the download, you could watch as many times as you liked, without your ISP ever noticing.
But in the OTT world, as we likely all know, there is a fundamentally different approach. Instead of downloading an entire video, we stream it to the viewer – encoding a video to suit the screen it is going to be watched on, breaking that encoded file up into millions of packets, and then sending those to the viewer’s device, usually via TCP/IP but now often UDP/IP, which reassembles the packets into a temporary video file.
In this model, the video dies with the end of the session. If the TV is turned off, if the mobile app is shut, then the stream dies. There isn’t an accessible version of this video stored anywhere, and if the viewer wants to watch that particular video again, we must go through the whole process again.
Similarly, if a viewer wants to rewind or skip ahead, they can do so almost immediately, without having to wait for the entire file to be downloaded, and if it turns out that the viewer only watches a few minutes of a movie, we haven’t wasted the resources to send an entire film. The video is sent and assembled a few seconds at a time, rather than in one large and slow transfer.
For live video streaming, UDP/IP is far more likely to be involved, as are the newer SRT and RIST. UDP/IP has less overhead than TCP/IP, firing packets out and trusting that the user receives them, rather than waiting and confirming the packet receipt as TCP/IP does. In streaming, there is more tolerance for packet loss, as long as the video keeps playing, which suits UDP’s fire-and-forget architecture.
But there are still physical constraints at play, which SRT or UDP/IP alone can’t solve. If a user in New York is trying to stream video from an origin server in Los Angeles, we’re still relying on physical cables to transport those IP packets. The longer this distance, the more chance there is for packet loss in the process.
This is where CDNs come into play. The Content Delivery Network, as the name implies, is a series of interconnections and servers that aim to reduce the physical distance and/or the time that a particular packet has to travel. A CDN allows that New Yorker to stream video from a server in their city, rather than on the other side of the country.
The CDN servers make copies of these packetized files, in an optimal fashion, and when a new user makes a request for this same file, this cached file can be sent directly to the user – instead of having to hit up the Origin Server again, or the web host that holds the original files. The CDNs help offload some of the bandwidth burden from the origin servers and their hosts, and so provide a valuable service.
The CDN provider places its servers in the Internet Exchange Points (IXPs) between the tier 1 network providers, as well as specific places nearest the most viewers. The architecture of the CDN has a huge bearing on its performance, and the CDN providers are in a constant state of analyzing their networks and reallocation or installing resources to match the demand. As CDNs deliver the vast majority of content consumed across the internet, they play a very important role.
Now, there are multiple approaches to using CDNs. A video service might choose to pay a service provider like Akamai, and hook its origin servers up to Akamai’s CDN, in order to improve the customer experience. In this case, the service is likely going to be provided with a Public CDN – that is, a multi-tenant CDN that is used by other customers.
If the service got big enough, it might find that it could save money by cutting out the middleman and creating its own CDN, or paying a little more to get a single-tenant CDN option from a CDN service provider. This is what we would call a Private CDN deployment, and the largest services make heavy use of these.
Depending on performance, a customer might find that they need to make use of more than one CDN provider. Perhaps they commission a Private CDN to support the initial Public CDN choice, or maybe they opt for another Public CDN interconnect.
In both scenarios, we would refer to this as a Multi-CDN deployment, due to the fact that more than one CDN is being used to deliver video. A major difference in Multi-CDN is that you are relying on the end-device to calculate which CDN is the best option – something that used to be anathema to vendors but that has changed recently. Consequently, Multi-CDN is more complicated than using just one CDN, requiring load balancers and aggregators to perform network analytics and take action as required.
There is a third approach that needs to be factored in, which has threatened to take off for a couple of years now. Unfortunately, as with many trends in the technology sector, the name is confusing. Peer to Peer (P2P) CDNs are lurking on the sidelines, and offer an alternative to the CDNs of old, using a technology called WebRTC to offload some of the burden from the CDN and onto the ISP networks that serve the viewers.
In this model, the conventional CDN would deliver video to a client device, which would then distribute those packets to other nearby clients. In this model, one initial viewer would be downloading the video file, and then sending copies of those packets onto other viewers. This approach could significantly reduce the CDN costs that the video service provider has to pay to the CDN vendors.
Historically, P2P CDNs were positioned as direct rivals to conventional CDNs, but this has evolved over time. Now, they tend to be marketed as a supplemental technology, and use the Multi-CDN umbrella to do this, although there are a few that vaunt themselves as complete replacements to a conventional CDN.
The maturity of WebRTC has been a major facilitator, and with all modern web browsers now supporting the protocol, the footprint for potential WebRTC clients has never been better. In addition, the emergence of the new CMAF (Common Media Application Format), which sees Apple’s HLS move from the MPEG .ts container to the fragmented .mp4 containers used by MPEG and Microsoft, should create greater simplicity in the delivery pipeline too – via chunked encoding and the new Common Encryption (CENC – ISO/IEC 23001-7:2016) initiative.
So, WebRTC threatens to shakeup the Multi-CDN marketplace, all while the probability of an OTT provider using multiple public or private CDNs increases. Rethink TV’s upcoming report will clarify the current state of the market, and gauge whether WebRTC is a threat to the likes of Akamai or Limelight, or something that instead could be bought into and leveraged.