semyendow: IBM's Andy Piper: Negotiating the Internet of Things

He is officially called the "Messaging Community Lead" for IBM's WebSphere message queue (MQ) architecture, which is a title that grants some modicum of honor without claiming too much authority. Andy Piper has become IBM's point man for the concept of a planet enmeshed in billions, perhaps trillions, of signal-sending, communicating devices. The case may be made that anything that can be "on" could be made to send a signal on a network - perhaps something as simple as "on" itself, periodically. The possibilities for a world where the operating status of any electronic device may be measured from any point on the globe, are astounding.

Sponsor

How do we ensure such a world doesn't become infinitely more chaotic than it already is? Have the architects of MQTT protocol considered whether it would be feasible to apply today's malicious use models for Web technologies to an Internet of Things? What, if anything, is being done to safeguard against a plethora of "thing-in-the-middle" attacks, where for instance, devices that are not shipping crates full of valuable merchandise identify themselves as such? ReadWriteWeb discussed these broader topics at length with IBM's Andy Piper.

Two weeks ago, IBM and its development partner Eurotech formally submitted Message Queue Telemetry Transport protocol to the Eclipse Foundation open source group. It's being called "the" Internet of Things (IoT) protocol, but in fairness it's only one candidate. It would serve as the communications mechanism for devices whose size may scale down to the very small level, with negligible power and transmission radius of only a few feet.

A trillion heartbeats

One example application already in the field, Piper told RWW, is in pacemakers. Tiny transmitters inside pacemakers communicate using MQTT with message queue brokers at their patients' bedsides. Those brokers then communicate with upstream servers using more conventional, sophisticated protocols such as WebSphere MQ.

"Look, this is engineered for a constrained environment," Piper emphasized. "But because of that, [these devices] are actually extremely efficient at doing things like conserving battery, and using very low bandwidth. So [MQTT] is actually a fairly sensible protocol for both the machine-to-machine (M2M) space that we're addressing with the Eclipse announcement, and also the mobile explosion as well. All these devices need to be connected."

Most protocols submitted by corporations to organizations for adoption as universal standards have some direct tie-in to those corporations, and MQTT is no exception. Although the APIs for anyone to incorporate MQTT into their own MQs are already published, WebSphere MQ has an early advantage.

This leads to what distinguishes the interconnection protocol for MQTT from HTTP and the Web as we've come to understand it. HTTP is end-to-end; all endpoints are addressable there on a universal map. MQTT, by stark contrast, is only at the outer shell. It communicates with so-called brokers using a wire protocol - literally a pattern of bits, as opposed to a componentized packet with a header and a container. Those brokers then communicate upstream using today's protocols, HTTP among them.

"It's not as such about replacing the Web; it's about enabling devices to talk to the Web," says Piper. "And these devices are unlikely to have user interfaces; they're really about just collecting data."

The push

IBM's model (like all IBM models through history) is layered and given a mnemonic. There are three classes of devices: intelligence, interconnect, and instrumentation. Unlike Microsoft's model, which argues that intelligence can be driven completely to the edge at the device level, IBM maintains intelligence at the core, maybe even in the cloud. Instrumentation, on the other hand, doesn't need to be all that intelligent. In fact, it can be essentially autonomic. But it can still communicate, and MQTT would be its protocol.

While HTTP is a heavier-weight protocol, Piper points out, its inherent synchronicity (from his vantage point; other architects consider HTTP asynchronous) renders it unreliable. "If you get a network timeout - you get them all the time as you move between cell areas now, you start sending a tweet and you walk five yards and your tweet doesn't get sent because the network connection dropped," he reminds us. An Internet of Things cannot be bound together using unreliable protocols, says Piper, especially because things can be moved from one place to any other without knowing why.

So MQTT works in reverse of HTTP. It's a push model, which means the device at the edge of the network is the server, and the device it's contacting is effectively the client (the reverse of the browser scenario). "The principle here is, keep the data on the wire as small as possible," he remarks.

Explosion

With projections of almost 24 billion simultaneously communicating devices around the world just by the year 2020, analysts have already gone on record as predicting the size of the world's databases may become unsustainable even before then, and that there may not be enough bandwidth in the laws of physics to maintain enough channels. Andy Piper notes that these analysts' predictions are based on the notion that the Web will be the modus operandi for the collection of all data. He argues that it won't, because it can't.

Andy Piper 03 (300 px).jpg "When you look at the wire trace of an HTTP packet, you end up with a lot of stuff in the headers which you don't see as a user," he tells RWW. "HTTP was designed for getting documents to a user interface. And it's been kind of bent and twisted into being used for inter-application and server-side communication, and that's fine when you have the bandwidth. But if you just want to send, 'The temperature is ___,' and then send 61.7, 60,7, 61.7, every five seconds, you really don't want to be doing a full HTTP post to send that information to an endpoint. So [MQTT] is asynchronous push; it's not request/response, which is what HTTP is."

Just as IPv4-based Internet networks have local loops with reserved addresses (192.168.x.x, for example) that cannot resolve to the broader Internet, MQTT is a protocol that exists only within the local loops, if you will, between brokers and endpoints. Communication at this lowest level may only be feasible, he says, with an extremely simplified protocol whose web doesn't appear to be the world. However, the broker managing the local loop truly does know how to communicate with an individual endpoint device. So utilizing MQ and MQTT, it is theoretically possible for a signal to address one specific device, and for that one device to communicate upstream with an endpoint that does get resolved into a URI. For that reason, Piper admits, there will still be an urgent need to reassess the problem of finite bandwidth.

Current networks of devices, such as Cisco routers, utilize small packets of health and status data that some literally call "weather reports." They're sent at specific intervals, and when they don't arrive on time, servers conclude something may be wrong. Such "weather reports" have been said to constitute a majority of the actual messages sent between routers and other devices at the lower levels of the Internet.

So suppose everything with an MQTT channel can send a "ping." That's still billions of simultaneous heartbeats. If MQTT is designed for situations where connectivity is even less reliable than for the Web, how does a broker manage all the inputs without triggering a panic attack?

Andy Piper tells us IBM's method of choice for MQTT involves a kind of built-in fallback procedure: "The way that MQTT deals with the chance that the network might be unreliable, you might want to know that your nuclear power station has vanished off your map for five seconds, because that could be really significant. It's actually got a really neat little feature."

The way it works, he explains, is by assigning a kind of "power of attorney" to one of the broker devices further up the chain. If the device doesn't send its heartbeat signal, the broker realizes it and sends a signal to that effect to the server monitoring the process. If there's no heartbeat for a long time, the broker sends a kind of manifest of possible instructions - what Piper describes as a "last will and testament."

Although MQTT is technically not a messaging protocol, and IBM doesn't really recommend it as such, that hasn't stopped Facebook from experimenting with it. As the largest social network revealed in August, it has developed a kind of routing protocol for clearing the way for messages to pass between mobile phones - a protocol that uses MQTT because it was geared for telemetry. In Part 2 of our discussion, I'll ask IBM's Andy Piper whether the door is still open for some other device, perhaps a malicious one, to masquerade as an endpoint device... say, as an ATM machine.

Discuss