Multicast for File Delivery

James Cridland wrote about how broadcast was a potential way to distribute Lion, the new version of OS X. While digital broadcasting is compelling as a mass-distribution media, the logistics don’t stack up to my mind, and while tuners are getting quite cheap, the hassle of trying to get aerial signal to your computer is still there.

Multicast was briefly mentioned in the comments, this provides a much more realistic alternative, and is something that BT, the main ISP Wholesale provider, is implementing. This post covers ISPs that use BT to provide connections to their subscribers, the method most ADSL customers are provided by. Customers with Sky (who are Local-Loop Unbundled) or Virgin (who run a cable network) are on different network topologies.

What is multicast? Basic machine to machine communication is unicast. Broadcast allows one machine to ‘talk’ to all others. Multicast is somewhere between, where other machines can choose to listen to stream on the network, but without the “speaking” machine having to transmit at additional copy. It’s perfect for things like live Radio or TV viewing, where many hundreds of users are viewing/listening to the same thing.

Where are we today?

Most ISPs don’t support multicast, so every download or action on the internet is a separate stream:

 

Content delivery with with unicast, without any multicasting.

 

The ISPs that do support multicast have to split it before it goes to BT. The BBC multicast some content out as a trial, and the traffic looks something like this:

The ISPs save on their ‘transit’ bandwidth, but still have to inject a separate copy of the video for each person watching when it goes to BT. Transit costs are unfortunately the cheaper part of an ISP budget, which means that multicast doesn’t help ISPs that much at the moment.

BT are introducing multicast into their network, which means that the “splitting” of the multi-cast to uni-cast occurs much deeper in the BT network, which means the result looks something like:

Much more efficient, only one copy of Radio1 goes from the ISP to BT (and some older BT documentation implies this may even go directly to BT bypassing the ISP).

But how does this apply to a ‘file’ like Lion? 

If you were to treat the 4 gig Lion update as a broadcast you could transmit it as a “carousel”, where it loops around. Run multiple carousels at different positions in the file and a client would join 1 or more streams based on the amount of bandwidth available, and how much of the file was downloaded

For efficiency, you might also want to offer streams at higher bit-rates so that a client could join fewer streams.

This traffic would need to be flagged as lower priority. TV multicast will be the opposite, and have Quality of Service to make sure video plays back smoothly, here though you would want the download to be dropped if other traffic was present. This will leave you with “holes” in the download.

The client could wait for the broadcast to “come around” on one of the streams and join that appropriately, or it could also make direct connections back to the CDN, or use Peer-to-peer networking, to “mop up” the specific bits of the download it had missed.

Would it make everything faster? 

Yes, and no. It would definitely be more efficient, however the limiting factor will still be the copper at the end of the journey, between the exchange and the customer. However, by reducing the demand to both the CDNs, and the ISPs bandwidth, that last mile should be used more fully.

Will it happen?

For things like downloads using CDNs that are embedded deeper in the network would be simpler for the client, and ease the load on ISPs. After the initial download “flurry” the multicast approaches efficiency reduces.

Two things make it more sense for video content like the BBC iPlayer: you have many people downloading content as it is being released, and you have a custom download manager in place.

Multicast will definitely happen for live-content. For other content it probably remains an interesting thought-experiment, unless the economics proved compelling enough. That is less likely since those impacted (the ISPs) are not those able to make the changes (Content Distributors).

2 thoughts on “Multicast for File Delivery”

  1. Fascinating article. Multicast to the user has always been promised since I was working at Virgin Radio in 2001; the takeup of IPv6 will significantly change all this, since it apparently comes with multicast “built-in”. That’s very interesting news from my point of view.

    In terms of whether the logistics of using broadcast to deliver large files – you mention “the hassle of trying to get aerial signal to your computer”, I commented on my own blog post (is that bad?) with the following:

    If you think of this as simply a network cache in your home (transparently connected to your broadband connection), rather than “an aerial”, you’re probably on a better track. You don’t care how the data gets onto that network drive – it could be delivered from an HTTP download; it could get there from BitTorrent or equivalent; or it could get there from broadcast data. The example of a newspaper delivered over broadcast data has been much used; but it’s not fundementally flawed. It would be considerably cheaper, and easier on the internet as a whole, if the 3 million people who might get The Sun electronically in future get it as a broadcast-delivered download rather than an actual HTTP download. It probably should be transparent to the user – so that all they know is that their Lion OS X upgrade happens almost instantly.

  2. If commenting on your own post is bad, then I’ll be guilty also:

    If you think of this as simply a network cache in your home

    The role of an intelligent local cache is interesting; I always wanted something primed with podcasts in the morning so when I opened my laptop that sync-before-work was just a bit quicker.

    The challenge about all this stuff is making it easy, and that I think that means it won’t happen in an ‘open’ way first; I suspect it will appear from an Apple or Google ecosystem of devices, and then gradually become a more open system in time.

    People are unlikely to know or care about these things, so someone bigger will have to send them the benefits with trivial barrier to adoption.

Comments are closed.