Home / Blogs

Connectivity as a Vital Consumer Service

Having Comcast et al provide Internet connectivity is like having your barber do surgery because he knows how to use a knife. I was reminded of this when my Comcast connection failed.

This is part of the larger topic of consumerization. In the past, we were happy to have products that worked at all. I grew up in the world of consumer products and got my start in software building online services meant for use by non-experts. When Dan and I created VisiCalc, we never thought of it as a program—that code was just an implementation tool. We were designing a product meant to be used by normal people, and if something was complicated, we fixed the program rather than force the users to learn an arcane technique. I’m especially thankful to Dan who has a very good design sense as well as a technical understanding. Since I did the bulk of the programming, he was free to focus on the user experience.

When my connectivity flaked out today, I was reminded of the degree to which our connected systems and today’s Internet itself falls far short of what we should expect from products meant to be used day-to-day as part of people’s lives. This is all-the-more important when we consider how much we depend on connectivity.

Very briefly, today’s Internet technology is still not ready for prime time. It’s like the early stages of automobiles when users had to be part-time mechanics. The problem is compounded by depending on companies whose business has been primarily offering television content rather than vital infrastructure.

Verizon prides itself on its technical prowess but that technology has been hidden from view, and the focus has been on services such as telephony and now television on the web. The world has moved on. Users themselves are using the raw connectivity to acquire, or in some cases even develop their own services, but that technology has not been made readily accessible to the users.

In the 1990’s, when I was at Microsoft, one of my requirements in the original design of home networking was “no installers.” The users had to be able to do everything themselves and, to a large degree, I succeed, but it’s still more complicated than it should be. Users have to carefully configure access points, worry about setting up port forwarding with fixed IP addresses and much more unnecessary technical detail. As an industry, we can and must do better.

My immediate problem was losing my connectivity to Comcast. I called Comcast, but they couldn’t diagnose the problem. I was willing to help out and looked at the diagnostic screen on Arris modem, but it didn’t provide any actionable information. At least not in a way I could understand. Instead, I had to have a Comcast technician come to my house and use a signal meter!

Why couldn’t Comcast diagnose the problem remotely? The Comcast support people said that if I were using their modem, they would have had better diagnostics. That is not an excuse. A level playing field requires open protocols that work whether I’m using Comcast gear or my own. In fact, the Arris modem I’m using was one that they specified.

This notion that I should be using their modem is part of the old telephony mindset. The Hush-a-Phone case in 1948 was a dramatic example of this mindset. Not only were people not allowed to own their own phones, they weren’t even allowed to put a box around the phone to hush it because it was deemed that it would harm ATT’s reputation! That attitude persists in the assumption that they control the gear in my house rather than using open protocols.

If Network Neutrality is to have any real meaning we need a level playing field at the IP (Internet Protocol) interface. I shouldn’t be required to have the manufacturer’s gear in order to get support. We need standard and open protocols rather than locking me into a Comcast or Verizon silo. I run into a version of this FiOS Video on Demand which requires that I have a direct connection to their servers, so I can’t do automatic multi-homing! With FiOS, I also can’t provision a set-top box unless I am using their DHCP server on their gear!

Unless we force open protocols, we’ll get increasing ossification and lock-in.

I have multiple connections and am thankful that I can get multiple IP addresses from Comcast for my testing. My Starry® Internet home hub has a screen which is a good design. It was glowing red saying that I didn’t have a Comcast connection. I wouldn’t have known because it’s my fallback path on my Ubiquiti system which doesn’t do regularly connectivity checks (though it should).

I use an Arris Surfboard 8200 modem for my Comcast connection and can connect to its diagnostic screen on, but the information is useless without interpretation. Why doesn’t the screen provide consumer information? It would save a lot of truck rolls. Even better if it had an API for the information—ideally a JSON interface rather than SNMP. There would be huge economic value in having a readable screen and local diagnostics.

Instead, I did the best I could and connected a laptop directly to the modem (yes, the modem, not the router/NAT—something I had to explain to the support people). The modem issued an IP address and gateway address, but they turned out to be spurious—cached from the past. This is confusing in that it makes it seem things are working so I used as my test ping address. (Weird part—I could ping the link-local V6 address but not the V4—why?)

Thanks to the Starry report I knew I had a problem connecting to Comcast and after futzing around with resets, they agreed to send a technician. The lights on the modem were all good (green, with a blue for high speed), but his signal meter said it was a bad signal. I was skeptical since there are a number of indications that I had a connection. It turns out the indicators were misleading. I agreed that it made sense to try a new wire. But he didn’t want to deal with the snow, so I offered to dig a path but discovered the snow blower was damaged. I asked the tech what would happen if I depended on my connectivity for medical devices, but he had no answer. So, he left (I’m skipping ahead here—will fill in). He came back with his supervisor and agreed to do it. (Note I once had a VIP marker in my Comcast record for some reason—don’t know if I still do and don’t know if it was a factor). And that fixed it. May have been gnawed by a squirrel.

The problem is that the inexcusably terrible diagnostics and support compounded the problem. This isn’t just a Comcast problem but an IETF and engineering problem. I plan to report this to BITAG.ORG (The Broadband Internet Technical Advisory Group) of which I am a member.

I wanted to help by having a geek-to-geek conversation with his support people, but that is not allowed! So, I placed a separate call to Comcast customer support and tried to get as technical a person as I could. That’s a challenge because they were not fully informed and didn’t have any better tools than I have. (This is where Verizon often, but not always, does better.) The only useful tool tech he had was his signal meter. Of course, Arris had that information but didn’t provide it in a useful form! WTF! What a waste of HTML! There was also the usual confusion. I probably shouldn’t have mentioned I had multiple IP addresses because I was told that was not possible on a consumer account. No matter, given that I just connected my laptop directly.

By coincidence my Ubiquiti flaked out strangely and issued invalid IP addresses outside the range I used in my house. But that’s a separate conversation. Overall Ubiquiti has given me geek-level tools for managing my network. Where are the consumer-friendly tools? It’s not just the so-called broadband connectivity.

I also noticed that some of my Android devices had lost WiFi connectivity and sat there too stupid to try to reconnect. Why don’t they try to maintain connectivity? Has this been fixed in a more recent version of Android? Are there apps that can fix this? (I tried to find some, but they didn’t really do the job).

And then there is the problem with the IP address. Why should a consumer have to deal with the IP address? It should be a transient identifier, but instead, it’s the user that has to deal with it directly. I tried to mitigate problems in my original home networking design. I wanted self-chosen addresses in net-10 (the range), but that was squashed by those who said corporate users want to use net -10. This would’ve avoided having to have a DHCP server. Today’s 169.254 serve the function, but typically there is a DHCP server with 192.168 addresses. Why can’t we fix this to just work, so the IP address doesn’t matter? We need a more resilient approach.

For now, the main take-ways:

  • As we increasingly rely on connectivity as vital infrastructure there is no excuse for treating it as just another broken television that could be repaired when convenient for the technician.
  • We need a consumer mindset that designs
    • Resilient protocols.
    • Equipment that provides useful information
    • Proactive problem solving
    • Consumer oriented tools and information
  • We need to act like connectivity matters rather than treating it for entertainment purposes only. This includes automatic rollovers to alternate paths. Alas, this runs into a conflict assuring a paywall. I use the term “ambient connectivity” for our ability to assume connectivity as basic infrastructure. As long as there is only billable connectivity, our ability to communicate is limited by the providers’ needs rather than the community’s needs.
  • We also need the arms-length relationships that are central to network neutrality. The protocols mustn’t require (or prefer) proprietary gear in homes and special direct connections to servers.

The consumer mindset is not only good for users; it would save companies like Comcast millions of dollars in support. So why isn’t it done? Perhaps because they are focused on being NBC or, in the case of Verizon, they still think network engineering is for professionals even though today consumers install their own gear.

One reason I do have to use Ubiquiti is that I have over 160 IP devices—most LIFX bulbs. That’s how it should be. But those bulbs depend on all sharing an SSID. This is part of the accidental properties that get locked in. We need a simple flat address space, not the twisting winding passages and concepts like being on the wrong network. We should recognize that devices like printers are peer devices rather than just peripherals (Unix comes closer on this). I tried to introduce some of these concepts in my original UPnP design, but instead, we get today’s UPnP which is very hierarchical and rife with security/trust problems. (Yet another topic).

PS: This consumer mindset issue goes well beyond the Internet stuff. It also applies to the electrical power system and far more ... for another essay.

By Bob Frankston, IEEE Fellow

Bob Frankston is best known for writing VisiCalc, the first electronic spreadsheet. While at Microsoft, he was instrumental in enabling home networking. Today, he is addressing the issues associated with coming to terms with a world being transformed by software.

Visit Page

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Threat Intelligence

Sponsored byWhoisXML API

Brand Protection

Sponsored byCSC


Sponsored byVerisign


Sponsored byDNIB.com

Domain Names

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global

New TLDs

Sponsored byRadix