What about the trade-offs ?
Merging multicast and unicast has been the whole grail of networking research ever since multicast was invented, and the reason why it took so long it because there are trade-offs, which in the case of live video, are very significant trade-offs. Starting with the original diagram of the architecture, lets add an estimation of the delay each component bring to the video workflow:
Keep in mind we’re talking about live content, and there are two main types of live content: live sports and most everything else. No one cares if your favourite series’ episode has 10 or 20 seconds delay between users using different reception methods (Over the air, Cable STB or a tablet). Few people will even be bothered if the news start at 4:00:15 instead of 4:00 sharp, or if you’re still going for the champagne bottle while your neighbours are already popping the cork.
However, customers will get extremely upset if the neighbours scream “Touchdown!” (in the the US) or “Goal” (elsewhere), but on their screen the ball is still on the midfield. This is the most differentiating characteristic between different IPTV implementations.
The delay is the elephant in the room whereas M-ABR is concerned. OTT users are used to it from day one, as most OTT services already have a significant delay as compared with the cable broadcast. If you look that the diagram above, delay starts right after the video leaves the broadcaster, but the scale of it differs significant depending on the platform.
Taking as baseline the Set Top Box, which is used to consume most high value content such as live sports, OTT and M-ABR architectures have increasing delays. For OTT services, delay is caused for both the cDVR component, which by design cannot be lower than 1 segment, but most implementations impose a 2 segments delay, and by the ABR client implementation, which requires at least 2 segments to be downloaded before starting playback. In total, it means that most OTT implementations have at least a 4 segments delay or around 8 seconds, as compared the with STB playing the same content. Again, this is irrelevant for non live content, such as movies and series, but critical for live sports.
When adding the M-ABR architecture on top of the OTT architecture, delay is even increased by at least 2 segments, totally 12 seconds. One segment is due to the segment broadcasting step and the other due to the store and forward architecture of the multicast proxy.
In sum, M-ABR works, but contrary to what cable labs describes, it’s never intended to replace the current cable broadcast. It’s only a method to avoid flooding a cable network with unicast packets intended for mobile devices. If that’s the goal, then it works, and it doesn’t significantly impairs the viewer’s experience. At least, significantly more then it already does.