Application Aware Networks and the End-to-End Principle
Recently, I was a panelist at GigaOm Structure. The group gathered to discuss a huge topic — Application Aware Networks, which are tightly connected to Software Defined Networking and Application Defined Networking (ADN), although they are not exactly the same concepts.
Personally, I define Application Aware Networks as communication networks that take care of the Apps they support, while Application Defined Networking denotes the activity of dynamically adapting the interconnection of resources of an application infrastructure. Thus, an ADN solution can rely on Application Aware Networks to adapt the resource interconnections of an application, while also leveraging other capabilities like upgrading or reconfiguring the related resources.
The Application Aware Network is not a new concept. Peter Seenkiste proposed it in 1996. But in the last couple of months this term has become hot again in the context of Software Defined Networks.
Why do we need Application Aware Networks? The term awareness denotes an ability to perceive, while the opposite is ignorance. Today, thanks to protocol layering, networks ‘ignore’ the applications they support. This means networks and applications are decoupled—i.e., networks provide one-size-fits-all best effort connectivity without knowing anything about the applications running over them. The result of this ‘best effort’ is performance unpredictability.
We have lived with this Internet design for 40 years. It is a very simple and scalable model. “The Design Philosophy of the DARPA Internet Protocols,” written by D.D. Clark in 1995 introduces it, and the “End-To-End Arguments in System Design” of J.H. Saltzer, D.P. Reed and D.D. Clark, published in 1984, details the rational for this approach very well.
Additionally, the Internet and the Web all owe their success to these simple and highly scalable principles and choices.
Of course Clark, Saltzer and their colleagues were well aware of the limits of their design choices, specifically concerning the consequences on performance. In fact, at the time these works were written they were already considering the performance issue.
Let me cite Saltzer: “Using performance to justify placing functions in a low-level subsystem must be done carefully. Sometimes, by examining the problem thoroughly, the same or better performance enhancement can be achieved at the high level. Performing a function at a low level may be more efficient, if the function can be performed with a minimum perturbation of the machinery already included in the low-level subsystem, but just the opposite situation can occur — that is, performing the function at the lower level may cost more — for two reasons. First, since the lower level subsystem is common to many applications, those applications that do not need the function will pay for it anyway. Second, the low-level subsystem may not have as much information as the higher levels, so it cannot do the job as efficiently.”
This is where I see the difference between Application Aware Networks (low-level subsystems) and Application Defined Networking (higher level).
Wide area accelerators (like WAC) and load balancers (like ADC) have been added to the network “at a higher level” to compensate for the performance issues resulting from the initial design choices. But unlike these solutions—which have added to the complexity of the overall system, leaving the net globally dumb and unpredictable—Application Defined Networking respects the robust end-to-end principle.
I will explain this in the next blog.