Fun With the Cloud, Part Two: Putting the "Service" in Internet Services

For nearly 20 years, I've used the Internet, but until very recently, I really only depended on it for web and email services. Recently I've been playing with some other types of Internet-connected services and the range of service quality that I've found has been, well, wide. One such adventure—video-on-demand—has gotten me thinking that there definitely are better and worse ways to provide services of this type.

I've been using video-on-demand from a well-known service for around two years, and until recently, it was wonderful. To set it up, I clearly needed to connect my television to the Internet, and so got a little interface doodad from a company named "Roku." One end of the box hooks into my network (wired or wireless), and the other end connects to my television via HDMI or component interface. (As many of you know, you can do the same thing with an XBox 360, a PlayStation, some TVs, and other devices.) It's sort of like the on-demand services that many cable providers offer, and offers me the ability to click and watch various kinds of video content without having to drive to and from a video store, which can consume up to an hour in the rural area where I live.

Anyway, the service was absolutely nonpareil until late March of this year, but after that time the service still worked great—so long as I didn't try to use it between about 8:00 pm and 11:00 pm. Across that span of time, the video either paused literally dozens of times per hour and/or periodically dropped out and reset itself to the program's beginning. Clearly the problem lay either in the Roku, my internal network, my cable connection to the video service provider, or the video provider's servers, so I ran a video while at the same time sequentially running speed tests against a half-dozen of the many "internet bandwidth test" servers on the Net. Running the tests caused no change to the video performance and the Internet speed tests all reported from 6–15 million bits per second download rates. (As far as I've ever heard, even the best quality video requires only 1.5 mbps.) So I made one more test: I watched a wonky political show from a different streaming service via Roku's "Newscaster" channel and... surprise, no pauses. Perhaps, although it was 9:15 PM, I was probably the only person watching the show. At this point, I felt sufficiently armed to contact the video-on-demand vendor.

As I'm sure everyone reading this knows, there's sometimes a certain otherworldly nature to talking to most providers of Internet-related services that would be downright funny if it weren't so, well, insulting. At one point I couldn't resist saying, "sure, I'll restart everything connected to the Internet before you'll do any real troubleshooting from your end, whatever you say; but I sort of suspect that the fact that we're talking over a VoIP connection implies that my internal network and my network's connection to the Internet's, so I'm not sure why I need to do that. Oh, and there's the fact that if I reset everything then this connection will soon be terminated, meaning that I'd have to call back and wait another twenty minutes and... oh, now I understand!" Eventually I got to talk to a mildly technical human who first told me that he'd bring my concerns to "the developers" (you need developers to stream video?) and then eventually admitted that yes, I was only getting 706 kbps from their busy servers and that 706 kbps just ain't enough.

That got me thinking: this is a networking problem, for heaven's sake, and I make a living solving networking problems, so why is it this one so hard? Well, if I were trying to stream the videos onto my PC, then I would quickly be able to troubleshoot it with a variety of tools like ping, tracert, pathping, Network Monitor/WireShark, Task Manager (after all, I have no way of verifying that the problem lies in the Roku's firmware, although I highly doubt it), and others. If I were trying to smoke out a problem talking to an Exchange server, I'd have a similar variety of server-side diagnostic tools, as well as a few specialized ones like RPCPing. Similarly, I thought, solving problems with my $60 Linksys router is fairly simple, as its web interface offers ping, tracert, and a few other tools. And then the penny dropped.

It finally dawned on me that while troubleshooting the Linksys LAN/WAN router was easy, it wasn't so easy with my first router. My first dedicated SOHO LAN/WAN router in 1993 cost not $60 but $1200, and came not with a nice web interface (for what should be obvious reasons) but instead a fairly ugly, nearly Help-free set of Unix-ish command-line tools accessed via a telnet client. It's easy to see why SOHO LAN/WAN routers are cheaper now than they were years ago—zillions more of them exist in 2010 than did in 1993—but why are the diagnostic tools better? My guess is that router vendors eventually realized that spending a little money equipping their devices with troubleshooting tools made for fewer support calls and happier customers. So, with hope, other makers of network-attached devices—and their intended services—will come to the same conclusion.

And just in case that wasn't subtle enough, permit me to suggest a few device makers and service providers who might find that a little work now could save them a bundle on service calls down the road. Apple and AT&T, isn't it time to stop spinning about iPhone connectivity issues and give us an app that'll let us see what's going on for ourselves? Similarly, it couldn't cost much to add a diagnostic screen and maybe a ping/tracert function to the Roku device and to Sony's recent Bravias. And Amazon and Netflix, why not consider a few user-accessible server-side tools?

What is most likely, though, is that none of these things will happen until we consumers ask for them. So the next time you're talking to a vendor about a consumer-level network issue that stymies you because of a lack of troubleshooting tools, ask for those tools. Who knows what great things might result?