If the essence of what is human can be summed up in the descriptive term “tool user,” then engineers, especially the hardware/software oriented EEs, are the tool creators, users, and modifiers. Not only of physical implements, but also of the ideas and concepts developed for one task, sometimes thrown aside, and then picked up again when the market or applications environment changes.
Some ideas, such as nonvolatile RAMs, BiCMOS, Silicon/Germanium transistors, even PDAs (remember Apple's Newton) gain attention momentarily because they seem to solve a problem but are pushed aside for reasons of economics, learning curve, etc., only to gain wide use later when the circumstances change.
Even more intriguing are those designed to solve a particular set of problems in a specific market and on a specific platform but which are not thrown aside. Rather, they are re-engineered, adapted and redefined to meet the new requirements.
Falling into this last category is the increasingly ubiquitous Universal Serial Bus, defined by Intel Corp. and a lot of the PC vendors as a way to get rid of all those pesky serial and parallel bus connections that were so unsightly and which took so much space on the outside of the box.
Like carpenters, mechanics, and plumbers on a project, who, finding they do not have the appropriate tool to accomplish a new task, take an existing one and adapt it to their needs, so have developers taken the familiar and useful USB tool and adapted it to the needs of Internet-centric computing.
At recent conferences as diverse as Comdex, CES, the Intel Developer Forum, 3GSM and CeBIT, I have seen all sorts of new USB variations and combos. All sorts of products are emerging to take advantage of a connectivity specification that not only connects PCs to peripherals but PCs to PCs, PDAs to almost anything, and cameras to anything with big enough memory. USB is not just confined to wired connections: a number of wireless combinations coming to market as well.
At these conferences, one question that always came up when I talked to engineers was: “Where is USB going next?” Aside from the straightforward extrapolations of what we are seeing now and further improvements in the underlying specification, one common area of interest and speculation was on how to combine the advantages of USB with those of the TCP/IP protocol: in essence USB over IP.
My conversations have ranged from conversations with executives such as Stephen Popovich, chief operating officer and corporate vice president of Inside Out Networks, a division of Digi International, who have actual products to “what if” bull sessions with engineers and a lot of back of the napkin type of sketches common in the industry. Aside from the various ways technically that might be used, what was most interesting to me were the number of ways I was told that USB over IP might affect the way we do connected computing, to wit:
(1) P2P P2P. Point to point, peer to peer. One potential use is as a low cost, secure way of gaining remote access to your desktop or remote system without letting the world in.
Over the years, I have experimented with a number of ways to give us access to our computer files remotely, or to directly control a connected peripheral device from my laptop thousands of miles away. But most require too much transmission overhead, or if, web page based, are too insecure. Or they work, are too expensive.
I've also investigated the peer-to-peer software that is used to share music. In the latter there does not seem to be any way securely to limit the number of peers to give the illusion of individual point-to-point connectivity. If you wanted to share with just one other or access your system and its peripherals remotely, you have to share that access with the world. Looking at USB over IP in this light makes it a private point to point peer to peer mechanism (P2P)x2 or (P2P)2 doesn't it?
(2) QoS and USB over IP. In both wired and wireless network environments, Quality of Service is a big concern. The way the IETF has dealt with this is to come up with some global specs that allow quasi-point-to-point operations to be conducted over connections and specific pathways using protocols that defeat the whole purpose of the packet-based Internet. It would seem that a hardware/software based USB over IP solution would have some advantages in achieving a higher QoS without as much protocol overhead.
(3) Video/audio and USB over IP. A subset of the above. Video and audio transmission over the Internet has always been a QoS issue, which is still problematic. There have been attempts to adapt video teleconferencing to the Internet, but they have been iffy at the low end because of the inherent TCP/IP QoS issues. And the telecom companies are pushing very hard to deliver VoIP over the Internet with the same quality and reliability as the traditional point-to-point telecom approach.
But as a user of VoIP telephones, I've found the quality of the voice is related to the other traffic on my local ISP server and more generally over the Internet. If I had a USB over IP box and someone else had a similar one, would our voice or video be more reliable and of higher quality?
(4) Privacy/Security and USB over IP. Thinking about the hardware/software solutions that companies such as Digi's IONet have come up with its USB over IP solution, raises some interesting security/privacy issues. Could it be possible to set up a reasonably private and secure connection over the Internet with two such boxes or among a group of people with similar boxes especially if you throw in an open source encryption algorithm such as PGP?
Would the Defense establishment, which focuses, for cost and time to implementation issues, on COTs, go for such a scheme? If not, could you use such a scheme to create a poor-man's or a businessman's secure phone or secure point-to-point data delivery system?
(5) USB over IP as a deterministic Internet mechanism. The reason most industrial applications involving control data, or data which requires immediate action in real time have stuck with their proprietary schemes rather than shifting to Ethernet-based TCP/IP is that the latter is a statistical, asynchronous protocol, whereas most industrial apps require a more deterministic, token-passing-like environment, in which issues relating to latency are based on specifics rather than statistical averages.
In the industrial environment, there have been efforts to create a deterministic Ethernet spec, but this is only achievable by limiting the scope of the Ethernet to a few local connections to give the illusion of deterministic operation. Is there an advantage to using USB over IP or over a local Ethernet TCP/IP to improve real time latency and deterministic operation that does not impose the limits that “deterministic Ethernet” does?
I am not an expert, so I can't speculate on whether or not any of these ideas might or might not hold water. All I do is listen and try to connect the dots, ask questions, and write about what I hear. What do you think? I'd like to get your feedback.
Bernard Cole is site leader and contributing editor of iApplianceweb and an independent editorial services consultant working with high technology companies. He welcomes your feedback. Call him at 602-288-7257 or send an email to .