This and last weekend felt a bit like the 1990s. A hot new app had just been released and everyone was talking about it – but its reliability and performance left a lot to be desired. The difference is that the Pokemon GO will probably improve relatively quickly. For the early users of massively multiplayer online games – Ultima Online in particular – the challenges of a nascent Internet infrastructure were a bit more involved.
Because the Internet was growing so fast, much of the industry’s attention (rightfully so) was on maintaining performance and reliability at scale across a multitude of emerging networks. Fast, dependable packet forwarding was the name of the game, and a needed emphasis on hardware-based routing (and custom silicon) was undeniable. After all, Fundamental Truth Number 1 in RFC 1925 is “It Has To Work.”
The downside? The precedence of hardware-based packet processing effectively stifled other potential advances in routing. Sure, CIDR, NATs, and IPv6 were clearly important innovations to routing. But when new network functions were needed (load balancers and firewalls among them) it was often bolted on – and more than likely, in the form of a(nother) hardware appliance.
Enter the middlebox. By the late 1990s, devices that processed packets in ways IP routers couldn’t were proliferate, as were the vendors that created these appliances. Fast-forward to today, and the middlebox trend hasn’t slowed down – as evidenced by a recent study:
“across all network sizes, the number of middleboxes is on par with the number of routers in a network.”
The funny part is that that phylogenetically speaking, routers and many types of middleboxes are closely related. Sure, firewalls evolved well beyond simple packet filtering – from holding state to deep packet inspection to application awareness. Same thing goes for load balancing – DNS Round Robin and server-side techniques have given way to Application Delivery Controllers. But their DNA all comes from the same branch of basic network principles.
The missing link here is session awareness. Nearly all of the advanced service functions available in middleboxes require an understanding of, and control over, sessions. Two decades ago, the state of the art in routing science and technology eschewed session awareness in favor of speed, stability, and scale.
As we describe in this post, things have changed. The combination of powerful-enough general purpose computing platforms and intelligent software allows us to re-think routing, and re-evolve it with session-orientation.
As a result, session-oriented routers are able to provide network security functions at each hop – including controlling session arrival rate, protocol inspection, dynamic blacklisting, access control lists, and hop-by-hop authentication. Each route can have attributes indicating who is permitted to use that route, and every inter-router segment can have authentication and encryption as well. This way, security can be built into every point in the network, rather than only at the borders and edges.
Session-oriented routing also portends some big changes for load balancing – server, link, cloud, global or otherwise. With session-awareness, routers can balance traffic across multiple servers sharing the same IP address, without changing the destination address of a packet. This process could be location-independent – those servers could sit anywhere on the network. Take it a step further, and it’s not hard to see the implications for multi-path routing as well, where path choice can be made a lot more intelligent, going well beyond the limitations of equal cost techniques.
Of course, the idea of combining middlebox capabilities with routing is an idea that’s been visited before – plenty of vendors offer “integrated” functionality in a single network device. But that approach is simply an extension of the middlebox mindset, as the functions are just co-resident in a single box, and you still have to configure and provision each separately. Session-oriented routing means that advanced network functions aren’t just “integrated” with routing – they are native to the act of routing itself. This is a fundamentally different approach, and without the constraints or demands of the 1990s internet evolution, it might have been the best approach, even back then.
It still won’t help you catch Pokémon any faster though… 😉