End to end principle: simplicity clears the fog
In my previous blog I was discussing Application Aware Networks, Application Defined Networking and the end-to-end principle.
In the context of today’s Social, Mobile, the Cloud and Big Data era (also recognized as the Nexus revolutionizing business and society), the question is if we can continue with the same network principles given our increasing dependence on shared Internet/Cloud infrastructures. The complexity and unpredictability are increasing daily, and not all applications can cope with huge uncertainty and complexity. This situation also has an enormous cost in terms of Opex (as a function of complexity) and Capex (as a function of overprovisioning to deal with unpredictability). This explains why SDN was invented…and why it is becoming so popular.
But let me cite again Saltzer to motivate the end-to-end ADN approach:
“End-to-end arguments are a kind of “Occam’s razor” when it comes to choosing the functions to be provided in a communication subsystem. Because the communication subsystem is frequently specified before applications that use the subsystem are known, the designer may be tempted to “help” the users by taking on more function than necessary. Awareness of end-to-end arguments can help to reduce such temptations.”
Today we clearly see the temptations to “help users” in the SDN space. I also clearly see the opportunity. Network virtualization, with all the flexibility it can bring would certainly help to greatly offload some of the “awareness” function inside the network. For example, a Virtual Network could deliver customized and adaptable network services on-demand (such as isolated virtual paths). These services would have different characteristics in terms of bandwidth, latency, reliability, and security that would target applications willing to pay more for having specific care in data transportation—without changing the core network.
For example, in a public Cloud like AWS such feature would change many things. Today, if you are experiencing highly variable latency because of noisy neighbors (running CPU burning or intrusive Iperf tests) you typically end up moving your workload to a less crowded zone. You cannot ask for network isolation because the underlying network is unmanageable, rigid and cannot be updated automatically. Moreover, it is painful to instrument your system to detect this performance variability. But even worse, allowing the variable latency to go un-remediated is harmful to your application and the user experience.
A responsive virtual network would be able to set up — on-demand — dedicated and isolated paths, thereby protecting the workload from highly variable latency when necessary without paying for useless extra compute power. This would also allow a provider to allocate more resources to more customers and keep all customers happy.
But networks deployed in current networks and clouds are still not virtualized at that level. Hopefully, the adoption of SDN solutions in both public and private Cloud environments will accelerate the delivery of such advanced networks.
But, as Saltzer says, we will ultimately need to combine the sophisticated virtual network with some intelligence at the end. Simply because the Cloud will always be relying on a complex network of heterogeneous networks.
This is where Application Defined Networking (AND) plays a critical role. ADN proposes to deliver the performance predictability end to end. This is a service being simultaneously application aware (for making the right adaptation choice) and network aware, maintaining the states of the network. ADN, because it respects both the end-to-end and the separation of concerns principles, keeps the application and the network simple and handles all the complexity underneath.
And ADN is delivered today over simple networks for existing application. ADN is not only both network neutral and application neutral but also highly powerful. It relies on simple end-to-end sensors and a logically centralized and decoupled intelligence.