Why? Because Stephen Conroy’s dunderheaded attempts to encroach on our relatively open Internet will require ISPs to sniff HTTP traffic on IP addresses that happen to fall on the ACMA blacklist. Because the blacklist is secret and subject to change without notice, my US–based Linode could have all its HTTP traffic sniffed on a whim.

Aside from the Australian Government creating a root CA and getting that included in major browsers (like what the Chinese did), it is not possible for them to sniff SSL–encrypted traffic to my site. So, to improve the privacy rights of my readers, those who use my code, and myself, all pages and bzr repositories available on the jeremy.visser.name domain are now HTTPS–enabled.

GoDaddy have an free SSL certificate scheme for open source projects. Because I write a lot about my open source goings-on, and host code on this site, I wondered if I would be eligible for the scheme. Turns out my request was a little unorthodox, and their identity verification system wasn’t properly equipped to deal with third-level registrations on the .name domain, but after some consideration they went ahead and provided me with a free SSL certificate. Thanks, GoDaddy!

I should mention that I am using TLS-SNI to serve the HTTPS version of this site, which means if you are using Internet Explorer, Chrome or Safari on Windows XP, you will get certificate errors. Sorry — nothing I can do about that, unfortunately. Also, I have been told Safari users on Mac OS X are getting certificate errors. Sorry about that, but the certificate is trusted on every other TLS-SNI supporting browser I have tested it on, so not sure what’s going on there.

I’m not redirecting users from the HTTP to HTTPS version just yet for two reasons: (1) I’m not sure what the best approach with regards to Google juice is, and (2) in case users cannot access the HTTPS version, they can still force the HTTP version. I’ll probably start redirecting in the near future though.

Paranoid? Maybe. Far-fetched? Definitely not.

We’ve had 1.5 mbit broadband since our village was first ADSL–enabled in 2005 (first with iiNet, then with Internode since December 2008). While 1.5 mbit is great by 2005 standards, by 2010 standards and living in a family of 6, even watching a YouTube video without stuttering (not to mention gaming or using VoIP at the same time) is barely possible.

A couple of times this year, I noticed that while attempting to play Nexuiz online, despite there being nothing other than gaming traffic on our pipe, my ping time skyrocketed from its usual 50-60 mark up to a minimum of 300, which made the game unplayable. Using ssh to connect to a remote box, I also noticed considerably poor responsiveness when typing. In February of this year, I reported the issue to Internode, who dismissed the issue by saying our exchange had no reported congestion issues.

The issues were generally quite bearable, only being infrequent.

At the beginning of this month, Dad bumped our broadband plan from Internode Easy Broadband to “ADSL Fast”. Living in Yerrinbool, our only option is Telstra Wholesale ADSL1, and are classified as Zone 2 (Regional) which is considerably poorer value than being in a Zone 1 (Metro) area or having DSLAMs from other ISPs available, but it’s the only option we have.

Since getting a theoretically 8 mbit service, we have very rarely reached the maximum speed. During most of the day and evening, the speeds waver from anywhere between 0.5 mbit and 5 mbit. Note that this is not a line noise issue. Our signal-to-noise ratio and line attenuation values (latter is 11 dB) are consistently almost perfect, and our sync speed is always right on 8192 kbps.

Not only that, but our latency has been terrible. It would be bearable if we had to live with slow speeds only, but our ping times skyrocket, which makes responsiveness far worse (e.g. ssh), and gaming is just about impossible.

I called up Internode and provided them with several graphs much like the following:

That demonstrates the latency problems by graphing the ping times to resolv.internode.on.net with my laptop being the only machine connected to the Internet — it was even directly connected to our PPPoE modem, bypassing our router.

To ensure that the above was a “clean room” test without interference from any traffic, I even ran something like the following to make sure of that:

# iptables -I OUTPUT -p ! icmp -j DROP
# iptables -I INPUT  -p ! icmp -j DROP

So by doing all of the above, I have eliminated variables from my own network. The conclusion is simple: the latency is being caused on the other end of the line. Only Internode and Telstra have the power to fix it.

Unfortunately, as I was told by an Internode support rep, Telstra won’t fix latency issues — only packet loss issues, which is a bit of a raw deal. That said, we are getting some packet loss:

--- 192.231.203.132 ping statistics ---
14400 packets transmitted, 14141 received, 1% packet loss, time 2912556ms
rtt min/avg/max/mdev = 39.659/245.465/539.602/168.439 ms, pipe 3

So there are two problems: slow speeds, and terrible latency. I think both are a direct result of congestion, but as I’m not Telstra and Internode aren’t being completely cooperative, I can’t say for sure.

It’s been months now, and it’s getting worse, not better. Sigh.

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?

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.

From the pretty performance graphs in the report, the filter doesn’t appear to be performing too badly. Implemented correctly, this filter could be put to use without a major impact on performance. However, that’s missing the point!

The point being that with the filter in place, it is basically equivalent to being wiretapped all day every day. Wiretapping in itself is not bad — it is sometimes plays an important role in solving crimes, or thwarting conspiracies. However, all wiretapping to date requires prior evidence of criminal activity, and a warrant is needed to perform it.

This “clean feed” is effectively wiretapping without a warrant. In other words, treating the general public like criminals. Guilty until proven innocent.

Once you establish that, how well the filter performs is a moot point. Admittedly, it is entirely possible BGP will be used so that only certain websites will be run through the filter (i.e. selective proxy). However, there is no guarantee that this technique will be used, and it is only a technical difference — the legislation to implement would be exactly the same. So the government could effectively change at will to monitoring all web traffic.

One quote I found interesting from the report:

Telstra reported that heavy traffic sites could overload its trial filtering solution if included in the filtering blacklist. This is also the case for all filters presented in the pilot.

So basically they are admitting the filter will be vulnerable to denial-of-service attacks. This could be exploited by criminals around the world with access to large botnets. Not only that, but a large amount of personal information is still transmitted over HTTP. Though unencrypted, the links between me and the website I am exchanging with are largely trusted. However, putting a filter in the middle that is explicitly designed to read the information suddenly makes the situation far scarier.

I also found no mention of IPv6 in the report. Because the trial has been reported to depend heavily on proprietary software, no mention of IPv6 is made, and of which it is common knowledge that proprietary software is more often than not lagging behind in cutting edge technologies, it is entirely likely that the filter will: (a) possibly hinder IPv6 adoption by ISPs, (b) cut off access to IPv6–enabled sites, or (c) be ineffective at blocking sites that are accessible via IPv6.