Designing Better Connectivity Means Building from the Bottom Up

Share on linkedin
LinkedIn
Share on twitter
Twitter
Share on email
Email
Share on linkedin
Share on twitter
Share on email
Illustration by Stories by Freepik

Stateless Inc. was built with the goal of making things easier to connect: via any network, public or private, and regardless of protocol or connection type. 

When Stateless’s founders, Murad and Eric, began working on identifying and solving the current problems of networking, they used advances in compute, storage and web architecture as benchmarks. Compute and storage had become elastic, scalable and could be offered ‘as a service’. Web scale architectural principles made compute and storage infrastructure distributed, self-healing and API-driven.

Networking, on the other hand, had not enjoyed the same gains: for the past 25 plus years networking has been essentially plumbing: monolithic applications that were installed and configured using CLI, and placed a premium on performance rather than flexibility. It was considered an impossible trade-off to have both. Networks were relatively difficult and expensive to build, maintain or change.

Some of the most significant developments in networking came out of the academic community in the last 10 years (the same community where Stateless was born) with frameworks designed to build and test large-scale networking applications. One of these developments, OpenFlow, was a way to standardize the way the control plane functions across a variety of switches and opened the door for large experiments with networking hardware.

OpenFlow Helped Innovate but More Needs to be Done

OpenFlow architectures became good at handling the full cross-section of bandwidth requirements of big data applications, and the sheer number of academic papers based on OpenFlow from about 2007 signaled a rich period of experimentation and innovation with ‘software defined networking’: applying software design principles to networks, and enjoying the efficiency and flexibility that comes with standard APIs rather than having specific solutions with low level, programmable ASICs and CLI tools for each vendor.

OpenFlow made network functions more ‘programmable’, but really was confined to certain protocols, and to the network controller. Networks could be designed better to handle ‘big data’ applications, but were they any more resilient, scalable, elastic than they had been before? Maybe a little. But Stateless identified a few other architectural elements that needed to be unlocked before ‘Web Scale’ networking was real. Any network function relies on maintaining ‘state’: this is the current status of open connections, timers, firewall rules, and any host of other more-or-less dynamic elements. Tightly coupled state means that scaling network functions, and network resiliency rely on a process, even if it is automated via an orchestrator; and the process remains time- and resource-consuming.

 

“Separating network state is the key not only to scalability, but to being able to break network functions down into manageable micro-services while maintaining operational and resource efficiency.”

Stateless breaks apart the monolithic architecture of network functions, beginning with the network state. It’s the key not only to scalability, but to being able to break network functions down into manageable micro-services while maintaining operational and resource efficiency (a microservice with its own dedicated state and process for state recovery makes no sense). We’ll dive deeper into this fundamental architectural shift in a future post.

Why P4?

P4 and Intel’s Tofino chip set, designed for maximum programmability for network switches, takes the flexibility that OpenFlow initiated for the control plane to the next level, and allows full, API-driven control of the switch hardware. P4 allows Stateless to design the packet flows necessary to take advantage of the separation of network state and function, and finally bring Web Scale architecture to networking.

With P4, Stateless can perform very fine-grained control of packet flows, including load balancing, QoS, both across network functions, and across network tenants. For instance, assume that a single tenant, running on a multi-tenant Luxon cluster requires more capacity suddenly across routing, IPsec and firewall functions. If you were to handle this via an orchestrator, you would need to follow the process for spinning up new network functions and replicating state. There would be downtime as the network adapted to the traffic increase. In the case that a tenant required no downtime, then they would have to pay extra for the infrastructure to support this SLA. With Luxon, new IPsec, firewall and routing functions are instantiated immediately, state is instantly available, and packets will flow according to the correct tenant, to the correct network function with no downtime, and even minimal lag.

Stateless & P4 Tofino to reinvent network functions 

P4 and Tofino have given Stateless the tools we needed to reinvent network functions from the very bottom up, including both network function architecture and the control and data plane adaptations to take full advantage of the capabilities of modern software design. P4 affords technology suppliers complete, API-driven access to networking hardware. Intel has enabled a major leap in networking by designing the next generation of tools that bring programmability to network switches. We are very proud to be working with them to bring true ‘Web Scale’ benefits to networking.

Like this post? Share it and spread the word!

Share on linkedin
LinkedIn
Share on twitter
Twitter
Share on email
Email

WANT TO STAY UP TO DATE? 

Subscribe to the Stateless blog for monthly updates

This website uses cookies to ensure you get the best experience on our website. We use cookies to provide social media features and to analyze our traffic.