But the world is not so rosy
The reduction on the network usage is only as great as the number of users consuming the content. If we take as an example Charter‘s average number of users per node which numbered 500 as of Q4’16, and the almost 200 channels offered, things stop adding up. Why? Because the number of users per node is decreasing while the number of channels increases everyday. This means that the gains obtained from going from unicast to multicast gets lower and lower due to the lack of end users sharing the same streams. And this this assuming a permanent blue sky world.
But the world is everything but blue skies, as things start to get less rosy very quickly. To start with, lets get to what it means “ABR”. It means that the consumed bandwidth adapts to the E2E network conditions of the end user, and in this case the weakest link is the WiFi network on the customer’s home. WiFi is all too known for being unreliable and prone to packet loss. As such, every time a user drops from the highest ABR profile into a lower one, one of 2 thinks needs to happen: either the lower profiles are driven directly from the cDVR origin, or for each lower profile, a specific multicast group needs to be added to the network. If we take into account that most ABR sources uses 5 to 10 bitrate profiles, it’s easy to see how the gains from aggregating users diminishes, but network complexity increases exponentially.
If the network resiliency on the home network is flaky, on the WAN things are far better, but zero packet loss is not assured every time, and specially on DOCSIS network, although things are far better on DOCSIS 3.x than on previous versions. There are however methods to recover from packet loss from the multicast component, as there are no built-in methods to recover from packet loss. But fear not, as there are brilliant methods to recover from multicast packets going missing, without linearly incrementing network traffic. One of those methods is Nack-Oriented Reliable Multicast (NORM) which is one of the most innovative network protocols I’ve ever read.
But, regardless of how brilliant NORM is, from an E2E perspective, it has consequences. The home gateway needs to wait for all packets which are part of a segment to be received, with or without retransmissions, before being able to forward the whole segment to the end device. Neither DASH using MP4ff, nor Smooth Streaming support incomplete segments which causes the proxy component not to operate on a byte range method, where every received bytes are forward to the end device, to an old store-and-forward approach, where a segments needs to be fully received before it can be forwarded to the end device.
Finally, there a problem with REQ2, “Keep the ABR client devices unchanged”. On most, if not all, live ABR client implementations, a number of segments are requested immediately, starting from the most recent segment, corresponding to the “now” segment. And here lies one the most fundamental problem: the current segment is *never* available on the multicast proxy when the ABR client requests it, because it’s still being broadcasted into multicast. However, it’s not only the current segment which is never available in time, due to the store-and-forward architecture of the multicast proxy, also the second to last segment is also not available in time.
The consequences of those missing segments is that segments will never be served from the multicast sources, but will always use the cDVR origin server, rendering the whole design totally useless. Unless, a change on the ABR client is performed, on which it ignores as last the 2 last segments. This said, it means that REQ2 “Keep the ABR client devices unchanged” wouldn’t be achievable, although only a small change would be required. However, there are two alternatives which can replace changes on the client implementation:
- If you manage the origin server yourself, you can simple create a new manifest endpoint which is always kept 2 segments behind. In this way, the two latest segments would always be available on the multicast stream. Although this solution foregoes any changes on the client device, it significantly adds complexity on the video path. It also doesn’t affect the delay, as it’s kept exactly the same.
- If you don’t manage the origin server, you can simple outright hack the manifest, by proxying it, and apply the equivalent to a 2 segment delay. It isn’t nice, it only world while the segment is not using SSL, but it works. It’s actually simpler to implement than to do it on the video path, although it’s a hack.