The spark: TCP/IP, publish/subscribe, and the search for a better way

By Arlen Nipper, Co-Creator of MQTT and CTO of Cirrus Link Solutions

Just joining us? Read part 1 of the MQTT story.

As the reliability of AT&T’s circuits faded and the complexity of proprietary VSAT protocols grew, oil and gas companies were desperate for a better communication model. Enter TCP/IP — and a visionary customer who helped us reimagine how industrial data could move.

AT&T Tridom and the birth of TCP/IP for SCADA

By the mid-1990s, Phillips 66 (P66) had deployed AT&T Tridom VSAT technology across its entire pipeline network. But satellite bandwidth was expensive, and their poll/response SCADA architecture was consuming 100% of the available space segment just to maintain the system.

In 1998, Tridom announced a plan to transition from their proprietary encapsulation protocol to the TCP/IP stack. This was a breakthrough.

Note: In the 1990s, TCP/IP was not yet dominant in industrial environments. DECnet still ruled, and DEC VAX computers were everywhere.

Now, with TCP/IP available across all P66 remote sites, the door was open to something new — and that’s where Steve Konig, SCADA manager at P66 Midstream, stepped in.

A visionary use case

Steve had heard about IBM’s MQSeries, which allowed IT systems to “Publish” information to a central broker, and let other systems “Subscribe” to what they needed. This decoupled architecture, running over TCP/IP, was everything SCADA systems were not.

Steve had four key goals:

  1. Decrease latency – Polling could take 15 minutes to refresh data and alarms.
  2. Maintain robust control – Remote commands needed to be reliable.
  3. Access more data – Flow computers and other equipment data were still stranded in the field.
  4. Cut communication costs – Significantly reduce VSAT data volume.

Security and cloud weren’t even on the radar in the 1990s. This was about performance, cost, and access.

The meeting that started it all

As the relationship between IBM and P66 deepened, Andy Stanford-Clark — fresh off a project involving the Atlanta Olympics — entered the picture. He and I met for the first time in Steve’s office in Bartlesville, Oklahoma.

That’s where the idea of building a new, lightweight protocol began to take shape.

Steve laid it out clearly: using IBM MQSeries in its full form was impossible. The MQSeries header alone could be 100s to 1000s of bytes, which translated to tens of thousands of dollars per year in VSAT bandwidth overhead.

We needed something faster. Smaller. Purpose-built for SCADA.

And just like that, we started designing a protocol that would later become MQTT.

Up next: How we turned a blank slate into a working prototype — defining topics, payloads, brokers, and the simple ideas that made MQTT so powerful.