Wednesday, August 15, 2012
Not a Stack, a Crowd
What we all used to know as simple server-based computing architecture has been replaced by the glossy and over-hyped marketing term "the cloud". But from an architecture perspective, the cloud is pretty much the same IP-based networking we've been using for decades. Because the Internet backbone is (at least today) still over-provisioned, an Internet and IP-based cloud can work well, even for important transactions. (Whether that holds true for the decades ahead is a different matter, of course.)
But the Internet of Things shares only a need of wide connectivity with "the cloud". In most other important ways, it’s completely different: crowds of billions of end devices that connect intermittently at very low speeds to other machines, not to humans. In my developing picture of the IoT, this makes traditional protocol stacks irrelevant – or at the very least, overkill.
While the traditional protocols may make sense for connecting Propagator nodes and Integrator functions (see the previous blog post), the vast numerical majority of connections will be to relatively low-data-need devices such as HVAC units, air quality sensors, and street lights. This is the segment of the communications architecture that must be re-thought from the ground up, in my opinion.
Rather than treat intermittent connections, data loss, and low data rates as problems (as they would be in IP), we must embrace these as facts of life in the Internet of Things. It’s a lossy world on the IoT frontier, and that's OK – if we engineer the architecture with that in mind. Most of these end devices won't need constant check-ins with a central site to function. They'll simply keep running, functioning with or without network updates. If an update comes, fine, but there's no immediate response required.
Turning to nature, birdsong and pollen give us another picture of how the IoT devices will treat communications. Many birds sing without expecting (or waiting for) an answer. They sing "blindly" to mark territory, advertise mating availability, or signal danger – and trust in the universe to deliver the message to hearers who may act upon the message. Similarly, trees and other flowering plants broadcast pollen extremely broadly (hence, allergy season) without any feedback on whether the "message" is received. Propagated by winds, pollen may be carried hundreds or thousands of miles away from the originating source.
All of this leads to my heretical view of the very edge of the Internet of Things: it just isn't reliable when viewed from the perspective of a single message. The devices may be switched off at various times, propagation paths may be lost, etc. Yet by sending the same small data chirps over and over, eventually there is a good chance that some or a few will get through. This will mean over-transmitting on a massive scale. But because each data chirp is so small, there is virtually no net cost involved in this over-provisioning.
I believe that this is one of the key things about the Internet of Things that is completely different from the "Big I" Internet: the very small amount of data in each transmission and the lack of criticality of any single transmission. As the traditional Internet becomes clogged with ever larger real-time data streams such as those generated by video and multiplayer gaming, the IoT's growth will be at the fringes of the network with billions of low-duty-cycle, low-data-rate devices.
I believe we'll need a new architecture at the edges of the Internet of Things. In place of the traditional IP protocol stack with hierarchical layers of routing topologies, there will instead be a gigantic crowd of devices speaking and listening – each unconcerned with what's happening anywhere else in the network. Instead of rigid routing paths there will be transient clumps and aggregations of unrelated devices sharing propagation facilities. It's a truly best-effort world, and as I have said before – that will be good enough.
Conceptually, I am breaking this new architecture into the elements of Naming, Communication, and Propagation. Next blog, we'll start with the most challenging aspect of this architecture: naming those billions of IoT end points in the crowd.