There is a line in the press release about Akamai buying Octoshape, which says that the “the acquisition is not material to Akamai’s financials.” We’d like to take issue with that statement.
While the amount that Akamai has likely paid for the tiny 40 man Danish IP specialist is not material to its results, we think that if it pushes the Octoshape technology throughout its customer base, it will make a huge difference to their loyalty and what they are prepared to pay for video delivery. This does Akamai a whole heap of financial good, and there are rumors that both DirecTV and AT&T are preparing OTT services based on the Octoshape delivery system in the US.
Akamai’s business is based on sending either files or video streams around the internet, moving them between 170,000 servers around the world, so that content never has far to travel when it is ordered from a device at the edge of the network.
But think about it, 170,000 is barely 1,000 servers per country – and that can never be anywhere near enough, especially when servers have to deliver not one content service, but hundreds, from iTunes and App Store files to the latest UHD video. For years now we have been hearing that Akamai does not have enough capacity in any given country to provide a streaming OTT service – and yet the future, according to virtually every source of research, is more and more OTT video.
The answer has been seen in the form of every local operator and even some major content providers like Netflix, having their own CDN. So Akamai, through a number of acquisitions, entered the market for selling the software that allowed operators to have their own CDNs, but has been largely quiet about the number of operators that have taken it up on its offer.
Quietly, it has continued to grow the number of servers it has out at the edge of the network, but what would that number truly have to be in order to cope with, for instance, all broadcast television in a country going unicast across the network, instead of being broadcast over RF.
Slowly, the economics of IP delivery are eating away at RF delivery, and at some point in the not too distant future, all broadcasters will buy into IP only delivery. In many countries, especially in Europe a hybrid approach has been adopted – where broadcast TV acts as a trigger to stimulate OTT delivered video of past series, both to TV sets and also to other IP connected devices.
But the economics are not, we would argue, working out for companies like Akamai. Sure it has reached $2 billion in revenue, and it is growing at 25% per annum, but data growth is substantially ahead of that, making room for new entrants which will slowly grow to compete with Akamai.
And with major customers like Apple starting to build out their own CDNs, Akamai could have been on the edge of going backwards, with big chunks of its revenue swept away.
One of the key problems for IP delivery of video is that there cannot be a long hop, going through multiple routing steps, or the end to end video stream will be too slow, due to competing traffic at each router. Another is that you want to send the data once from the middle to the edge of the network, and if it is consumed by more than one person, you don’t have to send it again.
That was the reason for using Multicast protocols in Multicast routers for IPTV, where you send the content to multiple DSLAMs (Digital Subscriber Line Access Multiplexers) which keep a track of which lines want the TV channel, and branch the service to each of them. But that required fully managed networks.
We have question marks over both the idea of CDNs and the idea of Adaptive Bit Rate architectures for general purpose IP video delivery. The first is straightforward:
If an HTTP ABR 2Mbps video stream is sent to 1 million devices, that means the internet has to sustain a 2Tbps stream across the network. By charging for each destination, the IP route remains expensive, and wasteful of resources and at the edge, even if you can store the video and send multiple copies, you end up with them arriving not in real time. Live sporting events have arrived as far apart as 2 minutes, so that the first live stream arrives 2 minutes ahead of the last session set up. The roar of ‘Goal!’ from your next door neighbor’s TV set could come a full 2 minutes before your TV catches up.
This is where the dream of the IGMP protocol came in, and where multicast derived from. When Live TV is sent across a multicast enabled network, it is sent once and branches to the segments where it is needed, and eventually down to the homes that take it. It is sent once to each part of the network it travels to.
But it also means bolstering your network to wire speed, adding DSLAMs or ISLAMs, putting in new multicast enabled routers throughout, agreeing complex Service Level Agreements, and setting up MPLS delivery and Quality of Service protocols. It is the main reason that IPTV stopped looking financially attractive and it stopped dead the moment that Move Networks invented Adaptive Bit Rate delivery over HTTP.
So most operators have not multicast-enabled their routers (expensive) and they also cannot deliver this type of service unless they have a direct relationship with the content business.
Octoshape gets around this. It uses multiple routes for video files to each device and proprietary error correction to re-build them. It uses UDP multicasting, a software method for emulating multicasting, so routers don’t have to be multicast enabled, but the result is the same. But UDP means that TCP is not involved, which can back off too aggressively when it bumps into traffic problems, creating buffers. And it delivers a flat bit rate end to end, instead of allowing Adaptive Bit Rate services to balloon their resources, and eat up say all available spectrum in an LTE network, leaving unpredictable outcomes for cellcos. Effectively it wraps HLS streams into UDP and then unwraps them on the remote device.
There was a recently passed standard on Automatic Multicast Tunneling which rely on the existing Internet Group Management (IGMP) and Multicast Listener Discovery (MLD) protocols to run a multicast transmission.
All of this means that generic cloud storage can be used to hold assets, not expensively mounted CDN servers, and the system has predictable throughputs, while allowing device makers like Apple, to insist on delivery of its own protocols, one the UDP wrapper is taken off.
You might argue that rivals like Limelight, which use cloud storage to cache video, are already dragging CDN design down a path that is very different from the way Akamai has historically been constructed. And Akamai since 2006 has been tweaking its architecture to get HD video across its service.
In 2011, Akamai said it had partnered with Dutch company Civolution, a watermarking and fingerprinting spin out of Philips, to use its NexGuard technology in the Akamai cloud platform. That was so that content customers can insert a different Civolution watermark into every copy of its content. This was done for HD then, and will be strictly adhered to for UHD now.
If you put this watermarking together with UHD class delivery, which costs less simply because it can use existing cloud storage in conjunction with its existing CDN servers and Akamai won’t necessarily have to keep growing its 170,000 server farm, then this all looks good for Akamai.
Akamai had already been working to allow its edge servers to stream ABR fragments over UDP, and now it can accelerate a network wide transformation.
In essence Akamai can provide the financial muscle to allow Octoshape to close down some of the major deals it has referred to – trials at US Tier 1 players for OTT video – and in turn Octoshape, can help Akamai create a better generic technology platform combining conventional CDN with a route to broadcast volume UHD delivery running against cloud economics, which are even more attractive than CDN economics.
That means it can chase broadcasters shipping out video world-wide, in the highest quality, at scale not before seen – and that will see Akamai’s growth rate continue for quite a while yet.
While there was no cash discussed in the release, we would reckon that Octoshape had revenues in the area of $15 million, and that it could have been sold for two or three times revenue, because of the technology advantage it will bring.