Jul 28, 2015
The topic of the Software-Defined WAN (SD-WAN) is certainly a hot one today. Almost every engineer I talk to is, at least, in the investigating phase of the evolution to an SD-WAN. While the term “software-defined” means many things to many people and can be somewhat confusing, in the WAN space there seems to a number of defining factors that most people can agree on. These include
• Freedom of hardware
• Ability to use broadband to replace part or all of the WAN with a similar experience to MPLS
• Multi-path technology
• Secure solution
• Centralized control
• Open platform
• Improved visibility
There might be a few other characteristics but certainly no one would argue with the above. However, there’s one technology that should be part of an SD-WAN that I rarely hear talked about and that’s caching.
For some reason, caching has always been and continues to be the ugly stepchild of the WAN. Large media companies and other types of organizations that push large data files over the network have used historically caching. Recorded videos and high volumes of web traffic used to be the exception but have now become the norm. Isn’t the industry at a point now where almost every organization sends large data files over the network repeatedly? We live in such a video-centric society that it’s commonplace now to find a video for almost everything in our personal and professional lives. Also, there have been great leaps in technology that make the recording and distribution of video incredibly simple.
As an example, earlier this year, Polycom announced something called “MediaSuite” to enable the self-servicing of recorded video. Prior to this release, anyone hosting an audio or video session had the ability to record the call for future playback. The challenge was that once the call had ended, the person had to send an email off to the help desk, then the file was emailed to the worker with some cryptic name that meant nothing and that was then forwarded along only to get lost in an inbox for all of eternity. The complexity in accomplishing this was too high to make it worth it. With MediaSuite, the worker goes to a portal, records the session, names it something sensible and then sends a link out for people to view for review or in case they missed it.
Another example is YouTube. While most people consider YouTube to be something for recreational use, there are many businesses that have created company sites within YouTube for training videos, CEO presentations or other cases where the visual medium enhances the experience. Also, the fact remains that recreational traffic on a network continues to drive up volumes, particularly when workers want to follow news and sporting events at work.
Caching can make the headaches of large data sets that kill the network go away. There is a tremendous amount of value in the migration to an SD-WAN, but if one of the problems with the old WAN is that videos, pictures and other large data sets are being pulled across the WAN multiple times, the shift to an SD-WAN isn’t really going to help because that content still needs to be pulled across the network multiple times. Sure, one might be able to direct all video, picture, and e-mail traffic to take a certain path, and that will help, but that’s just redirecting the problem to being a less expensive problem.
The use of caching technology, whether it’s a premises-based solution or a service like Akamai, can deliver a superior application experience to workers. The worker in the branch will be accessing local content so any recorded video being watched won’t be choppy. Other workers won’t see their experience compromised either.
The best way to deal with large amounts of static content that’s sent over the WAN multiple times is to send it only once, cache it at the edge and free up that bandwidth for more important things. As organizations go through the migration to an SD-WAN, caching should be considered a core piece of that strategy.