I offer this advice having watched the emails from disgruntled users of the service pile up. In response, Telecom tells us the problems are over. Which only brings forth a further flaming flood of JetStream hate mails. Who’s right?
The cynicism theory runs like this. When JetStream was first switched on back in 1999, business customers who’d been paying through the nose for leased line and ISDN internet access suddenly saw themselves with a much cheaper, broader bandwidth option. The question in everyone’s mind was how could Telecom tolerate the migration of these valuable customers to a service that would earn it a fraction as much revenue?
The answer, it would seem, is that it couldn’t. To help convince commercial customers of the inadvisability of using JetStream for always-on internet access, Telecom built in plenty of service interruptions. The proof? Since late last year we’ve been reporting on persistent micro-outages, causing problems for users running Citrix thin client applications, for example.
But it’s too cynical, even for me, to think that this might be a deliberate ploy. I favour the disarray explanation. What other way is there of describing a service for which the customer can be billed for unsolicited data? That’s what a mounting pile of anecdotal evidence is telling us about JetStream. We’ve heard — and written -- about users whose JetStream-connected PCs have unwittingly acted as servers of gigabytes of music files (JetStream user gets $10,000 bill surprise), running up five-figure data charges. At least in those instances Telecom has shown some willingness to waive some charges (and the users hopefully have learned the lesson of disallowing uploads).
But how would you feel if you’d left your unattended JetStream connection on for half a day only to find when you get your bill a month later that several gigabytes of data had been streamed at you by some malicious individual? Annoyed, to say the least. You might reasonably expect the service to filter such network pollution, but it ain’t so. In fact, Telecom’s advice to fearful users of its always-on service is turn it off. That’s disarray, in my book.
The JetStream “reliability statement” on Telecom's website is about as unreassuring as you might expect. It reads: “Although JetStream's performance has been good, the current back-up structure can affect our ability to resolve a major fault quickly. We cannot guarantee how quickly we can resolve problems with the network.” Potential JetStream customers should read it and heed it.
Telecom, meantime, might like to read and heed what some of its existing DSL users have been telling us by email (names have been deleted — we wouldn’t want to spoil any beautiful customer relationships):
“After suffering around two to three years of micro-outages I was delighted to see the press release on 27/2/2002 that Telecom had resolved these issues, yet what do I find today but an outage at 8.43am lasting for around 10 minutes. Why does Telecom put out a press release claiming it’s fixed when it’s not?”
“This appalling service has to be addressed.”
“IMHO Telecom has pumped JetStream full of morphine. There are broken bones everywhere, but nobody can feel the pain. Example: If you unplug the DSL line from a SpeedTouch Pro and then plug it back in 15 seconds later, everything may continue as if nothing happened (it ends up being a 30 to 45-second outage) … so rather than fix the cause they have fixed the effect; DSL outages now go unnoticed unless you are like me and actually care that an interactive session keeps ‘freezing’. For a business it has created a support issue -- gone is any evidence of what may be causing problems. This affects JetStream, IP.Networking and IP.Remote. We have users with DSL lights flashing like mad every five minutes, ring the DSL help desk, to be told no line errors, no disconnects ‘a perfect line’.”
“Here's my latest syslogs listing all the times my connection's been terminated recently. It's getting bad enough that nearly every time I sit down at my computer I have to reconnect ...
Feb 20 22:34:11 goliath pppd: Connection terminated.
Feb 21 12:45:17 goliath pppd: Connection terminated.
Feb 22 00:52:21 goliath pppd: Connection terminated.
Feb 22 18:42:03 goliath pppd: Connection terminated … “
This log ran to about 30 recorded “connection terminated”s up to March 4 … I’m sure you're getting the idea. Perhaps Telecom might too.