Rolling out a nationwide broadband network isn’t a walk in the park, so I’ve been patient when glitches have occurred in the complex network fabric between me and my internet service provider. Overall, I’ve been satisfied with the service, and have found Telecom’s techies and contractors helpful and knowledgeable (with a few rare exceptions).
Now, however, I rank myself as a very dissatisfied and unhappy JetStream customer. Even though some people might consider JetStream a “consumer grade solution”, and that you shouldn’t expect too much out of it, it’s worth remembering that I am paying good money for it -- $199 a month for the 1500MB plan, plus 18 cents per megabyte of excess data. Over a year I probably spend about $3000 on JetStream; there are others who spend a good deal more than that.
For that sort of money, I expect a reasonably reliable service, with Telecom working hard to prevent any unnecessary outages. However, my connection has been plagued by so-called micro-outages since the beginning of the year, and I can only assume that Telecom doesn’t care about offering a reliable service to a large number of JetStream customers.
The “micro-outages” only affect JetStream customers who have a static IP address, and who go through an ISP’s network to reach the internet (using Telecom’s FastIP service). Customers of other ISPs who resell JetStream through Telecom’s FastIPDirect service, which routes traffic directly to Telecom’s global-gateway internet access service, do not suffer “micro-outages”.
When a micro-outage happens, your JetStream service stops sending and receiving traffic to and from the internet for between ten to twenty seconds approximately. It’s caused by a fundamental design flaw in Telecom’s network: for unknown reasons, Telecom decided to use Routing Information Protocol version 2 (RIPv2) to maintain routing tables for its network.
The problem with RIP is that when triggered network topology updates are lost or absent, routing information changes can take a long time to propagate to the appropriate routers. When that happens, you cannot send or receive anything, as your traffic does not have a route to the outside world.
Some days you can expect frequent micro-outages (the worst I’ve seen is five per hour), other days the connection is fine. Note that this isn’t an issue with DSL itself, nor the modem or the DSLAM in the local exchange. There is nothing the JetStream customer or his/her ISP can do about it.
Needless to say, frequent network interruptions wreak havoc with interactive applications like Secure Shell (and no, using a Download Manager, as suggested by a Telecom employee who shall remain unnamed, isn’t going to help). You lose work, and have to devise workarounds for the unreliable connection, eating into your productivity.
I have an email from this month in which an ADSL helpdesk worker clearly states that the micro-outages are caused by RIP issues, and the archives of the NZ ADSL users mailing list at www.unixathome.org/adsl indicate that Telecom has been aware of this issue since March this year, possibly before.
You would have thought that by now Telecom would have replaced RIP with a better-suited protocol. I was expecting the issue to have been solved long ago, because Telecom knew about it and had had input from several, very knowledgeable customers and ISPs, which clearly showed where the problem was. No such luck. The ADSL helpdesk staffer says Telecom will switch to the Open Shortest Path First (OSPF) routing protocol in four weeks’ time, but whether or not that actually happens remains unconfirmed. It’s not like Telecom bothers to keep its valued JetStream customers up-to-date with service information.
Reporting the faults to Telecom has been a waste of time for both customers and Telecom’s contractors. These days you’re not supposed to talk to the ADSL helpdesk (the number has been removed from the Jetstream web site and 123 won’t give it out), but to go through your ISP’s helpdesk first.
With a modicum of technical nous, it’s easy to see that it’s not a fault with your modem, your phone line or even the local exchange. Despite this, you’re still supposed to go through the “is your modem plugged in?” rigmarole, and have Telecom contractors check your phone line and the DSLAM in the local exchange. ISPs are blamed for the outages as well, even though they have no access to the faulty systems within Telecom’s network.
Whether this is because of communications breakdown, a total lack of network diagnostics tools or general incompetence at Telecom, I cannot say. I do know that it’s incredibly annoying, especially when you and others have provided ample clues as to where Telecom should look for problems.
It’s quite unforgivable that Telecom has sat so long on a known issue, without telling customers when it will be resolved (or compensating customers for it). I know of several JetStream customers who have given up and taken their business elsewhere, after patiently waiting for months for a resolution.
There’s a rich irony in Telecom complaining about the low broadband uptake when it can’t be arsed to sort out a fundamental problem with its expensive service that is affecting a large number of customers. The issue also highlights the need to let other DSL providers enter the local loop, as I’m sure competition would have given Telecom an incentive to mend its broken network.
Telecom should apologise to the affected JetStream customers and ISPs, and issue a refund to them.
Saarinen is a PC World New Zealand columnist and looks after an Auckland-based company's internet application servers.