Multicast versus IPTV

24 February 2010

I’ve been hearing a lot of buzz about IPTV lately. It’s something that is exciting, useful, and inevitable.

As I understand it, IPTV is defined to be a live television service delivered over multicast (usually RTP) over a broadband Internet connection. Multicast has an advantage over normal traffic (“unicast”) because it avoids the duplication of traffic. Only one copy of the data is ever sent.

TPG currently offer 19 channels over an IPTV service, and TransACT allegedly offer over 50. iiNet is “on the brink of IPTV launch”. There are rumours that Internode are investigating something similar too.

That last paragraph should have triggered alarm bells in your head. It did for me, but maybe I’m just a cynic. Let me explain.

I asked myself: why are the ISPs providing the IPTV service? It sounds wrong to me. I’ve tried to come up with an answer, and my conclusion is that it is because of two reasons: (1) infrastructure (multicast is virtually non-existant in most production networks) and (2) content lock-in.

Having the ISPs provide the infrastructure for the IPTV service (marketing, encoding, distribution, etc.) means the ISP will likely sign a contract to exclusive usage rights with the TV partner for each channel they will provide. If iiNet sign an exclusive deal with Sky News, they sure as heck ain’t going to let Internode or TPG also put the content on their networks.

The infrastructure would also be duplicated. Each ISP needs their own TV receiving equipment (likely a few satellite dishes on top of their data centre), encoding equipment, marketing, private IP multicast network, and whatnot.

With regards to content lock-in, this will also mean that the ISP you choose to use will determine what IPTV channels you are able to watch. Conversely, what IPTV channels you want to watch will determine which ISP you will sign up with.

That sounds all rosy, until you consider that I am not restricted on what websites I can visit based on what ISP I am with. I can watch YouTube or ABC iView from any ISP in Australia. Sure, some ISPs offer better services than others, faster speeds, or more reliable connections, but it’s just the one Internet. This is because the ISP is not in the content provider role. They are merely the gateway to the Internet — the Internet service provider (now where have I heard that term before?).

The way IPTV looks like it is heading is shifting the ISP onto the content provider role. As I’ve already said, this means the service is delivered over the ISP’s private network, available exclusive to that ISP’s customers, and not over the Internet. That’s a Bad Thing™ in terms of net neutrality.

If an ISP “rebroadcasts” content from an IPTV channel that another ISP has signed an exclusive deal on, that would be a copyright violation.

But that still doesn’t explain the title of my post: “Multicast versus IPTV”. The above isn’t actually the crux of what I wanted to get at (apologies to the reader if you’ve managed to read this far in great detail).

I’m supportive of multicast in general. Combined with IPv6 (each /64 subnet has a corresponding multicast subnet), multicast opens up the doorway for anybody to serve high definition audio and video to the Internet at large without the need for exorbitant amounts of bandwidth up their sleeve.

But that’s public multicast. These “IPTV” solutions will be, and currently are, deployed on private multicast networks. On the plus site, private multicast networks mean it is easier for the ISP to deploy the infrastructure — it’s much easier to only have to worry about your own network, than also have to worry about interfacing with others. But it also means less incentive to deploy a public multicast infrastructure, and less incentive for content providers (such as TV networks) to provide their services over multicast themselves. It’s a chicken-and-egg problem.

We don’t need ISPs to “provide IPTV services”. We need a decent multicast network (preferably IPv6) that all Australians can access, so that TV stations themselves can provide the multicast streams with the knowledge that a large percentage of Internet subscribers are able to access their content, and that channel availability discrimination does not occur based on what ISP you choose to sign up with.

That’s the crux of what I’m getting at. I’m sure someone will come along and say “but but but…they have a right to sign exclusive contracts and deliver only over private networks”. My response to that would be that just because you have the right, doesn’t make it right. Nor left. :)

Thoughts?

Enable caching in collectd!

23 February 2010

If you decide to run collectd on your system, don’t do what I did: I ran it for 8 months without caching enabled. Basically, that means that not only was collectd monitoring load, it was generating a huge amount of load itself — way more than anything else running on the system.

Case in point:

collectd load graph. "No caching" shows high iowait, while "CacheTimeout" and "CacheFlush" shows the CPU load more than halved.

The “no caching” bit is what it’s been running like for 8 months, using this config in /etc/collectd/collectd.conf:

<Plugin rrdtool>
        DataDir "/var/lib/collectd/rrd"
</Plugin>

To more than half my idle CPU usage, and get my load averages back down to near 0.00, all I had to do was add:

<Plugin rrdtool>
        DataDir "/var/lib/collectd/rrd"
       CacheTimeout 120
       CacheFlush 900
</Plugin>

I don’t get why they don’t ship it like that by default. Enable caching. Your server will thank you. Thanks to the folks on #slug who held my hand while fixing this. :)

SCLUG site redesigned

21 February 2010

The South Coast Linux Users Group (SCLUG) website has had a lick of paint by yours truly.

The old site didn’t look bad (in particular, I liked the penguin header image), but was getting a little long in the tooth, had a few issues (such as broken category styles, and images being linked to the wrong domain), and didn’t really reflect much about Wollongong, which is where we are based.

So a little Inkscaping later, I came up with this:

SCLUG site in Wollongong livery

Check it out. No, like, seriously. Check it out. A bit more polish to come, but the idea is there.

IPv6–enabled

19 February 2010

This blog is officially IPv6–enabled, as of a few days ago.

The server-side IPv6 connectivity is admittedly powered by 6to4, which is not quite the real deal, but given that the nearest 6to4 gateway is 0.8msec away, I couldn’t very well pass the opportunity to stress test my new Linode.

I’m a pretty firm believer in the fact that IPv6 adoption is absolutely essential to the continued health and function of the Internet. I’ve been IPv6 tunneling from my house for years, had native IPv6 at my house since November, and though I’m certainly not the first to do so, it’s time to IPv6–enable my blog.

Python-iView supports new JSON index from iView 327

3 February 2010

Python-iView users are invited to update their setups to support the latest JSON–based index the ABC pushed yesterday. The index is in a more compact format, which means that loading the GTK+ interface should be faster for you.

Not only that, but the ABC have cleaned up all their blank programmes from the index, which should make picking and choosing something to watch.

Without further ado, here is the usual to get you to the latest version:

$ bzr pull

This latest update requires the use of the json module, which is only available for Python 2.6 users. I fall back to the user of simplejson if json is not available, so you may need to install the module manually (either from the simplejson website, or from your distribution’s package manager, e.g. python-simplejson for Debian or Ubuntu) if you use Python 2.5.