Internet Of Things = Internet Of Gateways

The last mile of the Internet of things (IoT) may be enabled by yet another new specification, Thread. It has the advantage of an interesting range of backers, including Google (Nest), ARM, Samsung, and, of course, the climate control pioneer Big Ass Fans, which no standards body could do without. It also has the disadvantage of being a more speculative -- though earnestly hopeful -- futurism, rather than a clever way of using the myriad protocols and standards that have already been deployed.

As application delivery-focused network engineers, we can see something really telling at the core of the open Thread specification. Thread, like many proprietary device connection standards struggling for market dominance, uses little power. It's a feature by design, but low-power endpoints aren't really Internet endpoints.

There needs to be some way to make a bridge, even to the relatively enormous energies of WiFi. And that would seem to confirm a growing suspicion that the IoT is really going to be an Internet of gateways.

Cost drives gateway adoption
The reason gateways are so critical to the IoT is that things, especially on the consumer front, must be inexpensive. Strike that -- things must be cheap. Thread, for example, is based on 6LoWPAN via IEEE 802.15.4 MAC/PHY. The "P" in "WPAN" -- wireless personal area network -- is key here. Smart doohickeys will need to run for a year on a button battery, and 6LoWPAN and other protocols can certainly do that.

However, if an endpoint pops out of its wireless hole only periodically like a prairie dog to exchange a few terse packets and then disappears, it's not doing SOAP, REST, JSON, XML RDP, or anything else application servers expect. So, regardless of the standard, IoT endpoints that make the jump from main power to running for months on batteries will need a gateway. That will lead to something network engineers will care a lot about: an explosion of widely and wildly distributed devices requiring configuration and monitoring.

IoT runs opposite network trends
Today's data center and its adjacent LAN are marvels of increasing colocation, concentration, and centralization. Fewer devices are delivering more application services than ever before, but IoT gateways won't be running in your hypervisor with everything else. The need to manage at scale will hopefully drive IoT gateway management to software-defined networking (SDN) out of the gate, but SDN won't solve the challenge of ensuring quality of experience (QoE).

Certainly, there will be efforts to manage the inevitable complexity of demarcation, security, and access context -- all the moving parts that will connect endpoints regardless of topology and pass traffic. As an engineer focused on delivering compelling end-user experiences that propel the IoT forward, though, SDN won't be enough.

QoE management requires a breadth of monitoring beginning in the cloud/data center at the app server, then out to the core and distribution networks and firewall, then to new distributed gateways, and ultimately to the billions of IoT devices. Traditional device polling, or even SDN gateway monitoring taps, simply won't cut it.

Make applications the focus of your network
The job of measuring, troubleshooting, and reporting on the QoE users have on your network will continue to sit squarely where it has always been: network performance monitoring, particularly application-aware network monitoring. Standing at a network pipe and attempting to measure down to the other end is challenging, regardless of how direct or convoluted the route is. Even if you're monitoring every intermediate element via traditional monitoring methods, you still don't have an absolute metric of service delivery success, except that you do.

Monitoring at the one point where you always have control -- the server NIC -- provides a measurement of performance with true accuracy. Using deep packet inspection (DPI) can reveal everything about the QoE that your end users care about, regardless of the ultimate endpoint. TCP handshake times for Active Directory authentication in your local VDI hypervisors? Done. Time to first data for the REST services that control your customers' IoT devices? Done and done, even without control of any network elements outside your firewall. In addition to finally moving IPv6 forward, IoT may do more to remind engineers about the invaluable goodness of DPI than anything in a long time.

So, Thread Group, bring your specification du jour. ZigBee, Z-Wave, Philips Hue -- heck, even X-10 or NetWareLP_TNG -- do your worst. Throw distant mesh networks, gateways, NAT overlapping IP, and whatever else you can think of at us. We're ready. As long as admins can see your packets, we'll identify your applications even as they evade detection, report on their performance, and ensure we keep the network -- however complex -- humming.