This article is focused on answering the question, “What is Stateless” in the context of networking software architecture so let’s dive in to answer some of those questions.
1. What is 'State'?
For example, if you’re reading this article online your web browser has created a connection to our web server. The fact that this connection is active now, is state information. Someplace in your network, there’s a router that is keeping the information about this connection (the connection state) so that the router knows that it is ok to send any data you’re requesting from our webpage to your browser. If the router didn’t know that there was an active connection it wouldn’t send the data and you’d probably have to push the refresh button on your browser to cause your router to rebuild its state information.
In networking, state information is used for routing, security, traffic management, and many more purposes. But for all the value that state information provides, managing network state information is a big challenge. Remember that ‘state’ reflects the status of something right now. The status of the network right now depends on knowing what just happened in the context of the status of what just happened before. If this seems confusing, think about it in this way. If I gave you $10 dollars and you put it into your wallet with your other cash, that state of the cash in your wallet would be $10 plus whatever money you already had. There’s no way for me to know the current state of the cash in your wallet without having this other information. If you think about a router in a network that is trying to keep track of all the open existing connections, if the router misses a request to either open or close a connection, its view of what connections are currently active is going to be wrong. Its state information isn’t going to accurately reflect what is going on in the network right now. Why would this be a problem? Read on…
2. What is the downside to having to maintain 'State' information in each network device?
The trouble with how state information is managed in the network today is that each network device has to keep track of its own state. For example, your router keeps track of your open connections. If your router fails, or it misses a connection request it’s state information will be wrong. This mismatch in state information will mean that all of your connections will need to be reestablished.
Now imagine the number of connections that an Internet core router has to keep track of. Multiply this number by a million or two and you’ll begin to understand why managing ‘state’ information in a network is a big task. This is also why network outages are so difficult to resolve. State issues in one device are cascaded through the network and can cause issues in all the other devices.
You might think that we’re making a big deal about something that isn’t really a problem. Most of the time networks work well, right? Check out downdetector.com. Open the report for any popular internet service provider (ISP) and you’ll see something like this picture:
Even if there isn’t a problem, since state is maintained in each network device, the devices are difficult to upgrade and maintain. Tasks that should be simple such as upgrading software or increasing a device’s capacity are service disrupting.
3. What is the best way to manage 'State' information?
For example, routers are one of the most common types of networking devices. Routers contain a tremendous amount of state information so we’ve created a ‘stateless’ routing microservice network function that you can use in place of a router. I like to explain it this way. To build a network we need routing but we don’t need a router. A stateless routing microservice network function is a highly efficient piece of software that forwards packets to the proper destination. But we know that for a routing function to work properly we need state information, such as what connections are active. The trick to building a ‘stateless’ networking function is to store the state information somewhere else.
4. Can you store 'State' information somewhere else?
5. So, what does 'Stateless' mean?
6. Why isn't everything 'Stateless'?
You might be wondering why networking devices are still being built using stateful processes. The issue is that in order for a process such as routing to operate efficiently it needs to be able to read and write state information very VERY quickly. Let’s do some math.
Let’s assume that we’re running a router on a moderately fast network. For example, let’s use a data rate of 1 Gbps (1 x 10^9 bits per second). For context, this is a typical rate for a fast LAN; 5G could be as fast at 10 Gbps, and core optical networks operate at 400 Gbps. At 1Gbps, it takes about 7 nanoseconds to read one byte. A typical data packet contains about 1,000 bytes so it takes about 7 x 10^9 x 1,000 or 7 microseconds to read an entire data packet. So our theoretical router would need to be able to process and forward packets at an average speed of 7 microseconds per packet in order to keep up with a data rate of 1 Gbps.
The RAM inside your computer can read and write data with about a 20 nanosecond delay. This is more than fast enough for routing packets IF we keep the state information inside the routing program. So we can build fast but ‘stateful’ routing functions this way.
If we want to separate the state information and store it in a database then we need to consider how long it takes to read/write from a database. A normal database read/write operation typically requires about 1,000 microseconds, or about 150 times the amount of time it takes to read a packet. So, a typical database is far too slow, it has too much latency to allow us to process packets fast enough.
So how did we build a system that can process packets at network speeds and use a distributed database to store state? It’s no secret, you can read about it in our patent. Some of the key parts of our invention is that we applied the latest cloud-native software development techniques such as the use of parallel processing, batching of database queries and we used a RAM-based database called RAMCloud. RAMCloud can return database queries in a little as 5 microseconds. That’s about 200 times faster than a normal database. When we combine modern software design techniques, along with our patented processes and with the speed of RAMCloud, we end up with a new kind of networking tool that can be used to construct networks that use stateless network microservices.
7. What are the benefits of using 'Stateless' network functions?
Stateless network functions are a completely new type of tool for building networks. Consider it this way, let’s say you wanted to build a tiny house. Your tools might include hammers, screwdrivers, tape measures, etc. But if you were to build a tiny house the ‘Stateless’ way you’d print it on your 3D printer. The 3D printer method is immensely more flexible, faster, and more cost-effective than traditional techniques.
Building networks using stateless network functions has the same type of advantages. You can build networks using yesterday’s tools or you can build them with a stateless network functions platform. Regardless of the way you build them you end up a similar construct. But if you choose to build your networks using stateless tools you’ll get these benefits as well:
- Speed – use, configure and manage only the functions you need
- Scale-out, not up – one cluster can handle thousands of interconnections
- End-to-end visibility– manage interconnections that span many stateless network functions as a single traffic flow – view the entire flow and each function within it
- Flexibility to adjust, scale, or remove functions on-demand – evolve and innovate with 100% API control – you define how your network functions/interconnections operate.
- Incredible resiliency – always on, always available – no disruptions for updates, inherently HA and built-in protection from software or hardware failures
- True multi-tenancy – full hierarchical, per tenant, control plane & data plan isolation. Even your tenants can have tenants
