Saturday, September 10, 2005

There is a tendency to create solutions to the problem at hand without thinking beyond. At first the specific design choices seem necessary but over time it becomes apparent that the solution is a special case and that the design choices have become burdens rather than advantages. USB, SCSI, Firewire (IEEE-1394), Bluetooth and many of the specialized industrial protocols are all packet protocols with attitude. By now it should be obvious that the advantages of sharing generic hardware and sharing the intellectual efforts of general packet transports outweigh the benefits of the idiosyncratic protocols.

By now it should be obvious that requirements like synchronous, isochronous, brittle reliability and QoS are solutions rather than technologies. By building them into protocols we lose the ability to take advantage of the ongoing and rapid innovations in technology.

USB (Universal Serial Bus) was a major improvement over the way devices were connected to computers in the past. The first goal was to replace the serial and parallel ports on computers. It is indeed far better than either -- both in performance and in the ability to add many devices. It also made it easy to connect mice and keyboards and even microphones and speakers. USB microphones and speakers have lagged simply because there has been little effort to provide the necessary chips in sufficient quantity but even at today's prices it is still far more flexible and removes the need to have special colored jacks on the computer itself. With USB 2.0 it became fast enough for high performance peripherals like disk drivers and video streams.

The pragmatic problem is that USB still doesn't really work that well. I keep finding that devices and hubs are not recognized or malfunction or disappear or operate at the wrong speed. The basic problem is that the computer system knows too much about USB and can get confused when things are not just right. There is too much "attitude" in the protocol. In theory I can just use USB as a serial path but there are no readily available generic drivers and I've found the third party drivers are often problematic.

One problem is that USB is considered a reliable bus -- devices appearing and disappearing are considered major events. If I disconnect a CD writer at the wrong time the disc is trashed. You can still have this problem over a network but I hope that people are better prepared for network failures. With USB each device is a dependent of the main processor whereas in a network model they are peers.

USB has two modes -- synchronous and asynchronous. The latter is a packet transport that is tolerant of timing problems and the same protocols should work very well over any network. Synchronous mode was designed for audio streams. But the success of IP telephony should demonstrate that we don't need a special synchronous transport. The problem is even more acute in Firewire (IEEE-1394) which has tight timing constraints that limit the length of the cable in order to support isochronous which is a stronger version of synchronous. Maybe this made sense ten or twenty years ago when saving a chip in an HDTV seemed important but now it's just a misunderstanding of how to build communications systems.

Ultimately all of these buses use packet protocols just like the Internet. So why do we need them at all.

• Synchronous and Isochronous protocol requirements. As I pointed out audio and video over packet networks has been very successful.
• Complexity. There's no reason to assume that a chip using UDP (User Datagram Protocol -- a simple packet protocol) over IP should be any more complicated than one supporting the other buses. More likely it would be less complicated because UDP is very simple and doesn't embody application requirements. Even TCP is very simple.
• Cost. This is more of a function of quantity than particular technologies but it isn't necessary to use expensive transports for simple devices. You can still use a simple wire be it USB or, even better, HomePNA via sloppy phone wires. What is important is having a standard routable protocol rather than a bus that ties a device to a single host.
• Discovery. In theory it's easier to discover devices on a local bus though Firewire is closer to being a network. In practice it's more of a matter of the kind of discovery protocol. Microsoft has put a lot of effort in to UPnP yet strangely it doesn't support USB devices which are supposed to be easier to find! That's because USB doesn't support standard protocols! There's also Apple's Rendezvous based on the IETF zero-config initiative. One could also use a version of the existing USB discovery protocol (whatever it is) by broadcasting over a local network. The discovery protocols should scale beyond local networks but even support simple local discovery would be a great advance.
• Implicit relationships. If you plug a mouse into a local USB port you know what system it belongs to. That's nice but it wouldn't be much harder to have a simple protocol to establish a relationship. The simplest form is a local broadcast where you trust your colleagues not to grab the device. If you are a little more paranoid you can have short number for the device and type that in. You might even support a physical mating protocol. Bluetooth tries to solve this kind of problem. We also have wireless mice. Setting up a relationship is not a deep problem.
• Sharing. While setting up a relationship with a single host is important it's very frustrating to have only one relationship allowed. If I have a scanner why can't I make it available as a resource? In fact we have printers and scanners as network devices. Why are the network versions the exceptions? They demonstrate the power of using a network so why not just make it the norm so I don't have to worry about locating the device near one computer and then having to figure out how to share it.
• Resilience. One important characteristic of the Internet is that packets get lost. Unfortunately they are often too reliable and people forget that. But when one designs for network devices one needs to prepare for problems in staying connected. The relationship is separate from the particular path persistence. One can do the same with USB but once one can deal with hiccups then why not just get the flexibility of a "real" network.
• Security. Having a device tethered via a wire gives the illusion of security -- no one else can see it though there is no guarantee of this. A third party app running on your PC can turn on your local microphone without you knowing it. If we establish a relationships between two devices then you can exchange keys and have a private relationship every bit as safe as using a physical wire.
• Work-arounds. Devices like Keyspan's USB server provide some ability to share devices but they are problematic. Keyspan only supports USB 1.0 devices (though they and others have a device for sharing printers using USB 2.0). But why do we have to bother -- the network protocols are a superset of USB.
• Power. As I've pointed out, USB does provide power to peripherals though within strict limit. It does have a value as an alternative to disparate wall warts -- even Motorola's RAZR phone uses a USB connector for its head set so it can be charged via USB. But it's easy to specify a network cable with power -- in fact there already is a standard for power over Ethernet.

The main point is that all of these bus and relationship protocols are special cases of packet networks that implement subsets of standard IP networks. Why not just use a standard network instead of these special silos? We would avoid the idiosyncratic properties that limit their applicability and also create opportunities for failure. More to the point I'm fed up with working around the quirks and limitations and failure mode of each of these protocols. Perhaps you don't have a dozen or two or three peripherals and think it always works. It reminds me of the novice programmer who debugs a 20 line program and wonders why you can't prove that a 2 million line real time system works perfectly according to an imaginary specification. USB doesn't scale.

The problems are far worse for consumer electronics devices that use special wires. The wires themselves have special properties and must be carefully nurtured. One hint at the right direction is Sling Media's Slingbox. While it's positioned as a way to watch your TV programs from anywhere in the world I see it having more potential as a way to convert the signals from your Set Top Box into standard network streams. The current Slingbox tries too hard to compress the signal but I can see a next generation that allows me to simplify handling the signals within my house. Too bad Tellywood is terrified that it might be too easy to view and repurpose their content. They want things to be hard and arcane!

USB came about when we were first starting to understand how connectivity works and how simple it could be. In fact I started my home networking effort in the same Windows group that embraced USB. It did seem like a wonderful idea then and the shared memory model did seem to make programming easier. I was so thrilled to get beyond the serial ports that I didn't worry about the details. Ten years later I have piles and piles of USB device but it doesn't scale where as IP connectivity has taken over the world.

As I wrote this I was diverted to deal with my sprinkler system -- I'm trying to use a controller with an RS-232 interface (AKA COM port). In fact, many devices still use an RS-232 interface. They might as well just skip over all the other buses and just go directly to IP with XML/HTML protocols. No sense in reliving history to relearn the same lessons.

We can keep the USB and other protocols. All I ask is that it be hosted on a standard packet layer instead of requiring its own special transport. It would make it much easier to take advantage of the power of these devices and really use computing. It's just a slight change in the chipsets used -- is that too much to ask for?

Billing was once just a way to pay for the telecommunications infrastructure but it has become an end in its own right and the primary skill of today's carriers. It makes it difficult for us to get the benefits of the Internet's simple connectivity.

The old cliché of the Information Highway has been supplanted by a trollway -- not only do the trolls want to collect your money, the collection points. In real highways tolls are located at real chokepoints -- where it's difficult to bypass them. On the Information Trollway no expense has been spared to assure that the trolls get paid. After all, trollways are far more expensive than highways.

We do need to fund the building and maintenance of infrastructure but it is all-too-easy to slide from the need to cover costs into the arcania of billing. Using toll booths to collect money is only one mechanism for funding today's highways and we only locate the tolls at natural chokepoints.

Unfortunately traditional telecommunications is fixated on a billing model that is no longer appropriate. The entire system is perverted to meet the needs of a particular billing regimen. The regimen itself assumes that it is the carriers that create value thus preventing others from creating value that doesn't accrue to the carriers.

We accept this model because we have become inured to it. The Internet isn't fixated on the minutia of billing. Unfortunately as we try to provide pervasive connectivity we find ourselves trying to wend our way through the labyrinths of traditional telecommunications. The current carriers are defined by their billing model -- they sell services not connectivity. We will continue to be stymied by their imposed costs and complexities until we recognize that the current billing model has become a perverse end in its own right.

In listening to the Podcast with Nokia's Anssi Vanjoki I was impressed by Nokia's efforts to create a platform not just a cell phone.

He remarked how hard it is to create connections between devices. I see this complexity myself when I read articles about how to interconnect with the myriad of special networks -- especially the cellular networks -- in publications like IEEE Communications. The complexity isn't really intrinsic. It comes from trying to conform to the requirements of network operators. You can't just connect devices -- you must make sure that the messages all pass an appropriate billing point and provide credentials in order to assure that the carriers get paid. For mobile connectivity you must then work around a system designed for carrying phone calls.

We continue to think of communication in terms of wires just like in the 1800's when forests of poles carried telegraph and later phone wires from offices and homes to central offices. The signals were then sent out on other wires towards their destination. How else could it work? Even as telephony went digital and then wireless the idea of the wire persisted in the guise of the circuit. And the billing model continued to be based on the notion of buying particular services from a particular carrier.

This is in sharp contrast with the Internet that doesn't have the concept of circuits -- the relationships are defined by the users not the carriers. It has turned out to be a far more effective and scalable model. It's such a good model that the carriers are replacing their traditional infrastructure with an IP infrastructure -- at least internally.

They still maintaining a fiction of having a special infrastructure and insisting that only they can create video services (see my One Percent essay). They go so far as to each build out their own infrastructure. This is a very very expensive way to maintain a fiction. Wouldn't it be prudent share a common infrastructure?

We see this problem in cellular telephony -- you may be mobile but you are beholden to your carrier and can only connect via others towers if your carrier allows it. My phone might light up four bars in Australia but Verizon won't allow me to use it.

Sure the carriers argue that there are protocol problems but that's a symptom not an excuse. It's a symptom of the complexities of an old-style purpose-built infrastructure -- the very kind that has been rendered obsolete by IP connectivity. The switches in the landline network serve no purpose in this new infrastructure. In cellular telephony we are forced to use these complex switches. 3G IP connectivity is layered on top of this inefficient network.

It's all very complicated and it is a result of trying to maintain a fiction that we need phone companies to provide services and, in turn, they need to bill us for these services even if it means spending many billions of dollars on redundant infrastructure.

Despite building all this extra capacity the carriers act as if they are hording a scarce resource and have to carefully dole out the capacity to preserve "Quality of Service". But QoS presumes you know what the services is so you can decide what's most important. QoS actually makes the network behavior worse because it requires predetermining what is important and then imposing this on the entire networks -- a complicated and wasteful mission. The carriers aren't trying to make things complicated -- they are just prisoners of their own mythology. QoS is just another face on the assumption that they carriers are providing billable services and not an undifferentiated commodity.

Not only are we at the mercy of complex protocols but we have the corrupting effect of putting these rules, priorities and limitations into the heart of the network. Speaking of hearts has your heart called home lately to report anomalies to your physician? It would be feasible to have a pacemaker report back if we could assume simple connectivity.

We sacrifice simplicity in the name of an 18th century notion that we must pay for each service even if we just want connectivity -- it's like buying flour but paying the grocer for the cake you make yourself -- the flour is just a cheap ingredient. Even worse if all you can afford is inexpensive bread and must pay for a cake just to get the ingredients.

In the 20th century, let alone the 21st, we know that IP connectivity is a simple commodity and need to shift to billing for connectivity as a utility.

Much of the complexity that Anssi cites stems from the restrictions imposed by the 19th century model of communications. We must demand simplicity and the ability to craft our own solutions. Once again, we see that in an emergency it's much easier to keep the IP infrastructure functioning than traditional telephony. It's also true in everyday mundane applications.

Today cellular telephony is the closest we have to a ubiquitous transport but as with the flour example, it's priced as a high value service. At 10¢ a message (SMS charge) it would cost a $1000/yr just to have your pacemaker send a few bytes of status message to your physician. As Marie Antoinette was supposed to have said -- let them eat cake!

Friday, September 09, 2005

Wednesday, September 07, 2005