Introduction to Multicast ABR (M-ABR) – Where it works and where it totally fails

Where it totally fails

There is a very good reason why M-ABR is defined by CableLabs. It’s specially related to the “cable” part. On cable, video is not broadcasted on multicast, at least not while DOCSIS 3.1 isn’t everywhere. It’s either on plain QAM or using DVB-C. So replacing IP unicast for IP multicast, if there’s enough users sharing the same content, it only makes sense.

However, if we’re talking about an already existing IP network, usually using IP multicast things are different, *very* different.

To start with, if your STB is already fed by the IP multicast, which on modern systems already include trick modes and pauseTV, and is protected by either FEC or retransmission techniques, there’s nothing to gain, only to loose, namely, complexity, additional network load and increased delay.

Even for current ABR clients, things aren’t clear. If the goal is to reduce the load your own ABR clients impose on your network, using your home gateway, then you have a far simpler solution: implement a multicast to unicast proxy on your gateway. As opposed to the M-ABR solution, where the home gateway converts a broadcasted packet into unicast, simply segment the multicast stream into a TS-based unicast stream, either directly using DASH or HLS, or on a more brute force approach, simply streaming multicast into HTTP.

The advantages: no delay, no added video path complexity, little to none client changes.

Then, there’s a lack of need to it. On most current IPTV networks, the problem isn’t bandwidth, at least on the last mile. The problem is the limited split GPON offers, which is mostly limited to 1:64. This means that on your worst case scenario, each user gets at least 38Mbps of unicast traffic, enough for any streaming video, including 4K HDR.

Conclusion and final remarks

There is now a movement trying to bring M-ABR as a standard, as the current CableLabs document only describes a generic architecture, either using ITU or DVB, which would allow interoperability between vendors offering M-ABR components, which is not the case today. For instance, NORM is fairly well defined, but the packaging method it uses is not defined, nor is the packaging format. So, even before thinking on boarding this ship, you0ll need to wait for the standardisation process to take place. Then, there’s the issue of need, or lack thereof.

Today, there’s only a working implementation of M-ABR, on¬†Comcast, which is lightly described on this panel with a Comcast representative, and there’s good reasons why it’s the only one. It only makes sense on legacy cable networks. If you’re launching a brand new network, either cable of fiber, you’ll be streaming video¬†over multicast from day zero, thus negating any of the benefits this solution would bring.

Also published on Medium.