Moaning about "most complete" broadband, someone has, quite sensibly, asked if we can do multicast. We are a very techie ISP, so why not?
So, here is my reasoning why not, at the moment. It is not totally ruled out, but I do think it will disappear to be honest.
First off, I'll try and explain what multicast is. In a packet network you send packets of data, and this is usually a packet going to one end destination. The Internet as a whole is all about routing a packet to its destination.
However, there are two other modes of operation. One is broadcast which is sending a packet everywhere, and one us multicast which is sending to a set of devices. In practice broadcast is "everywhere on this LAN" or some suitable "broadcast network", and not everywhere on the Internet all at once.
On a LAN multicast and broadcast just work. The switch or hub ensure that every device sees the packet, and the devices filter to get those in which they are interested. Multicast and broadcast are effectively the same for most switches as there is no "layer 2 multicast subscription" process to tell the switches which devices want the multicast traffic. It is done by device drivers configuring the individual hardware to filter for what traffic is wanted. Switches can be smarter and snoop on higher layer protocols in some cases, but its not necessarily a problem to solve as switches and LANs are fast enough anyway.
Where it gets interesting is wide area multicast. The logic sounds simple enough, and sounds like a useful thing. For example, the BBC could stream a TV station as multicast, sending it just the once to a peering ISPs. The ISP duplicates the packets to its links, and so on to its customers. Customer routers send the traffic as mulicast packets on the final LAN and multiple devices can see the stream in real time.
The problem, as an ISP, is simple. We would have to copy the packets to each customer. That is technically a pain, and does not save us any money as most of the cost is the link to customers. It does reduce some traffic on peering to the likes of BBC but that is not as costly.
There is, technically, a way to do multicast on L2TP, which would address traffic. I don't think BT support it yet (or anyone else), and I can imagine the fun they would have billing for it. But it would mean a packet to each BRAS, and there are hundreds of them. This would start to have some saving as long as we commonly get two or more people on a BRAS streaming the same traffic at the same time. At present that is simply not going to happen.
But could there be enough demand if ISPS did multicast? I am not convinced. The problem is that there are already very good technical means to distribute the same content to many - using radio and satellite. It works, and is cheap, and already in use.
But could we make multicast better? If the way broadband worked is proper routers and switches at an exchange level, multicast could just be one packet in to BT and that duplicates and spreads at each aggregation point and efficiently gets to every device that wants it. Yay!
But hang on - the big things now are catch-up TV and on-demand TV. The content delivery networks are providing this at an application level. Colocating kit at ISPs and closer to the end users. Eventually you can see how CDNs may have boxes at an exchange level to serve the unicast streamed content. There are already systems to include content at the BRAS level within BT.
If they do that, they can "multicast" efficiently using unicast traffic at local nodes. Once you have that you don't need the layer 2/3 multicast systems.
So, at the moment, it is simply not worth the effort. I think if we get to the stage where it is worth the effort the CDNs will be able to do it way better than we could by some means.
Multicast on the LAN will stay - but basically, I think the idea of wide area multicast being done at layer 2/3 is probably the wrong way to do it, and that is why it is not taking off. The right way to do it is application level live content distribution and recorded content delivery platforms. IMHO
I'll keep an eye on it though, you never know.
Subscribe to:
Post Comments (Atom)
Deliveries from China
I have PCBs made in China (well Hong Kong). This is all my many small PCB projects (not FireBrick). I would rather use UK suppliers but I am...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
Consider the use case where two or more PCs at the end of an A&A connection want to watch or listen to the same BBC multicast stream. It would be cool if I only had to pay for the bandwidth from A&A once rather than once per PC/device. At the moment I cannot access the BBC's multicast services which makes me feel like some parts of the net are inaccessible to me.
ReplyDeleteDon’t forget your router also has to support multicast from the WAN to the LAN… From memory when Zen was trialling it, not allot of routers supported it.
DeleteGood point Kevin, but I believe my Cisco edge router and FreeBSD internal router will both support this - it's just A&A that don't in between the BBC and A&A ;)
DeleteFYI: there a list of ISPs that do support multicast here: http://www.bbc.co.uk/multicast/tv/home.shtml (don't know if it's accurate or whether the service still actually works).
I agree this is probably a lot of work for a small return; just making the point that it would be of benefit to some end users where multiple devices need access to the same stream.
Ironically - not a lot of routers support it is one of the key issues IPv6 has suffered.
Delete"The problem, as an ISP, is simple. We would have to copy the packets to each customer."
ReplyDeleteI don't follow you here. You would only be copying the packets to each customer router that created a subscription to the multicast group, and any customers watching the same stream on multiple devices would benefit from this (as would you, as you are only carrying one copy of the stream within your network - rather than one stream per viewer).
As an end-user, I would really like to be able to receive any live broadcasts in this manner (i.e. anything broadcast on TV or Radio). In the past I looked at Exterity kit for transporting DVB-T/S multiplexes onto IP, and this can also easily be done using free software like DVBlast along with a cheap DVB-T(2) receiver.
I haven't looked lately, but I hope that they are still streaming the subtitles as text instead of images. There is a neat service called Box Of Broadcasts that lets you search inside subtitle text to find programmes you want to watch!
We would be paying for a packet to each end user that is subscribed and receiving the stream. We have to copy the packet and send to that end user. And pay BT to do that.
DeleteAs some have said, if more than one person at the customer premises are streaming the same thing live then yes, this makes for one packet to the customer premises. Though, that said, you could do what you like with packets once they get to you, and distributing to local boxes could just as easily be managed at an application level as layer 2/3, which is my whole point really.
if ten customers are subscribed to 1 unicast streams that is 10 packets in on the peer and ten packets out on the BT link. if ten customers are subscribed to 1 unicast stream thats 1 packet in on the peer and one out on the bt link - no worse than unicast, the replication (as I understand it) should be a hardware level thing in your routers.....
Deletewith respect to leveraging the protocol for catch up TV, thats a matter of application design, but a "sky box office" approach where you join the next start time e.g. a stream starts every 10 seconds as long as there is at least one person asking for that stream.
With respect to broadcasting working well, I agree and I play with mythtv grabbing digital content straight off the airwaves, but with things like this in the lords: http://www.guardian.co.uk/technology/2012/jul/31/digital-television-internet-revolution - multicast seems the only way the net could deliver corrie effectively (although the L2TP issues would also need work)
sky box office is not like that, not on my sky box anyway. It had programs broadcast on satellite, and stream via the Internet unicast. They don't appear to use multicast or start a stream every 10 seconds. But even if you did that, you could not fast forward as you can with streamed recorded TV.
DeleteAs for copying 1 to 10 packets. Yes, but the peering costs incrementally almost zero but the 10 packets cost huge BT rates. So not a real saving, and a lot of work. No, it is not always in hardware to copy packets.
It is only live TV that even needs to consider multicast anyway - anything pre-records (e.g. Corrie) can be conveyed by a variety of means, including P2P. You only have to send the decode key at the scheduled time.
Even live TV, it is things like live sports which are the only thing, and some live events. News is repeating the same story slightly differently every 10 minutes, and better done streamed from latest version.
Sorry, the every 10 seconds bit was me embracing and extending the concept, what I meant was that new streams could overlap. the same content as existing streams. boxoffice is every 1/2 hour or whatever, it is broadcast (which like you say a multicast is quite like a multicast)
DeleteIt also seems a shame that in order to deliver content efficiently to the world, all kinds of tricks like content delivery platforms in exchanges (the NAT of delivery?) - it seems more of a barrier to entry for the little guy and encroaching on the "common carrier" status of ISPs....
Indeed, I have been in hotels where the pay-per-view was done like that. Horrid.
DeleteI can see cases where multicast is right and works - and some people have commented on here that specific, carefully designed IPTV systems do work well. But general Internet access offering multicast is not the same proposition commercially or technically.
Maybe wide area multicast will have its day, maybe not. My hunch is that such things will move to the application, to set-top boxes and TV sets, which will talk unicast to concentrators nearby, P2P content in advance, and stream recorded and live content in much the same way.
Maybe IPv6 will have its day, maybe not. My hunch is that such things will move to tiered NAT :-) (sorry, just being a little cheeky there and I really do hope that this doesn't happen, but I'm sure that there are many who DO believe that this is the future....)
DeleteWould you think that 10 seconds to wait for a stream to start be too much? - that kind of wait is common with current unicast video streams.
Multicast is available on the "core internet" - we peer (at work) with one of the ISPs mentioned on the BBC trial site, and multicast is there to be "had" from the internet routing table, just like unicast 4 and 6..
another poster saying it doesn't work "on the internet" is down (IMO) to the same adopter gap as IPv6 faced (faces?) namely support by/on the edge ISP and the soho router.... (the same poster agreeing that it is a fundamentally stable and reliable technology widely deployed)
I kinda (sadly) agree with you that we probably won't see multicast for all the reasons you mention, but more specifically the chicken and egg of multicast needing a "killer app" (IPv6's "killer app" is a lack of IPv4 addresses) - without the infrastructure supporting multicast, no-one will come up with that app......
Yes, cheeky, and to be expected, I know. I am not saying the 10 seconds thing is a problem, just that if you have the infrastructure to do on-demand, then you have the means to distribute close to end point on unicast. It is like multicast but done at the application layer, that is all. It also has the same efficiencies in packets on the network.
DeleteThe infrastructure for application level on-demand unicast is growing now, and is commercially viable.
The infrastructure for high quality broadcast (satellite and the like) is here now, and commercially viable.
Neither is running out (unlike IPv4) or needs any nasty bodges to work around. The protocol work for application level content distribution is not a bodge or complicated, just doing the same job at a different level. Unlike IPv4 using NAT which goes against the design principles of IP.
I agree IPv6 has been slow, and some of the reasons are similar, but a different set of issues and solutions I feel.
I think most of the Box office content is available over IP now if the STB is connected to the internet.
DeleteAlthough In Sky's case They seem to be using a progressive download (At least they do for the Anytime+ content, I must admit i've never bought anything from the PPV on it.)
I was part of a team looking at delivery of TV over IP networks around 2000 - At the time multicast looked the only feasible option to get the streams across the core networks without running out of bandwidth or money or both. The access network never looked to be the problem.
ReplyDeleteDidn't take off though and I suspect the economics are somewhat different these days.
I also nearly got a job at an anti-virus house which wanted to use multicast to push signature file updates out. Perhaps I shouldn't have told them it was doomed to failure in the interview :/
AFAICS multicast has always been a solution looking for a problem and it's never worked across the Internet as a whole (possibly because it has no application driving it)
For the virus signatures, non real time wide area distribution is best done using peer to peer.
DeleteI think it is trying to solve real problems, but in the wrong way at the wrong level in the stack.
Funny, I'd say that peer to peer is a solution that only exists because multicast isn't available. (not that it is a bad solution in itself)
DeleteI think you nail it with the CDN argument. Bittorrent also solves a similar different multicast-like problem.
ReplyDeleteThey both have the advantage that they can be deployed incrementally and without needing IP layer support.
@Mark: you might look at get_iplayer: its a command line (and apparently also a web interface) software package that lets you download iPlayer stuff for later viewing. I'm not sure how it deals with live streams, but it works well for me for "catch up" mode.
Our gateways and set-top boxes do multicast, and it's a critical feature, used to deliver broadcast IPTV.
ReplyDeleteI've done a satellite gateway in a previous job, and multicast was used for NTP (send one packet and all gateways on a whole continent receive it), software updates and IPTV.
So, multicast, routed over WAN interfaces, really is widely deployed, as a critical service, but only by operators that offer paid IPTV as part of their offering, completely managed inside their own network.
Multicast doesn't work over the Internet. You can't get to the BBC, or connect P2P clients. Forget it.
If A&A doesn't have a managed service offering that uses it, then there is completely no reason to implement it.
Multicast on the LAN is a whole different story, with switch snooping, IPv6, wireless LAN implications. It's also used by local services, most importantly UPnP such as DLNA, UPnP IGD, and multicast DNS.
I'm aware of at least one broadcaster keeping a neat multicast/unicast combination design in their labs. The trick is simple - if your box has multiple gigabytes of local storage, you can record any part of the incoming stream. When I start watching a programme, you unicast it to me; if someone near me in network terms starts watching the same programme, you switch both me and them to multicast. They record the multicast stream, and the broadcaster unicasts in the bit they're missing so that they don't realise that there are bits being recorded while they're watching. There's extra trickery when two people join me - the bits they're both missing can be multicast, and unicast used to get the last person to join the multicast group up to speed.
ReplyDeleteIt was all very, very clever back in 1999 when I saw them demonstrate it; it meant that they could do video on demand stuff without the worry about lots of people joining the stream and overwhelming the core servers. Whether it's still useful is a different matter.
It is a mix of multicast and applications level cleverness. I am just thinking the latter is happening anyway so may avoid need for wide area multicast. We will have to see.
DeleteSimon - is there a way we can put a stand alone box in our network to "support" multicast, or does it mean the actual muticast packets being supported in the L2TP endpoints?
I know this is an old blog post, it seems that Multicast has some newer support in the BT network with FTTC... Would this change AAISP's position on the matter? http://www.openreach.co.uk/orpg/home/products/super-fastfibreaccess/multicast/multicast.do
DeleteThat still won't fit with PPP, and even with Ethernet level services it is only a helpful per L2S (part of an exchange) if you have more than one user of a multicast at a time. I think the market is changing and multicast is less of a concern anyway as unicast connections are having to handle video on lots of links at once and CDNs are having to deliver, simply for on-demand and catch-up. Simultaneous (e.g. live) can work on that platform, so as it gets better multicast is no longer needed.
DeleteThere is a unicast to multi unicast solution that is kindof not supported by the bbc, but kinda works.
ReplyDeleteIts an small app for linux called get_iplayer. (Its apt-get'able if you run a debian based distro)
When used with ffmpeg it gets content from iplayer and saves it to your hdd. From there it can be added to your DLNA store (minidlna works well) and played / streamed to/on many devices all at once without incurring any extra bandwidth charges from AAISP.
It should be noted that the bbc iplayer service legally only allows you to keep content for 30 days, Out of the box get_iplayer will ask if it should delete any content older than 30days.
What, if anything, has changed since this was originally published ? (One thing - it was published way back when, before IPv6 became available from many UK ISPs.)
ReplyDelete