The application delivery challenges have been the enemy of network since the advent of Internet. So, what are these application delivery challenges that can bring down a network to its heels?
Above are some of the common problems faced not only by traditional networks but are also relevant even for today’s SD-WAN based networks. All these problems are interconnected, and they work very well together creating a ripple effect across your network.
One of the most common causes for packet loss is network congestion and this can occur due to low bandwidth with lot of applications contesting for the same resources but that’s not always the case. You can have good bandwidth for your WAN links but if the devices deployed don’t have big and fast buffers to process that traffic, it will result in congestion and that can lead not only to packet loss but also higher response times from the device causing high latency. You can throw the best of the hardware and higher WAN bandwidth to your network but the applications that ride on top of your network can behave differently or become slow due to some resource issue on the server and this can also lead to high latency and packet loss.
The WAN bandwidth costs have gone down and the buffers on the devices have also improved a lot. Even the application stack that runs on top of your network that includes all the on-prem or cloud applications have also improved a lot with improved response times, efficient resource utilization but with all these improvements on both the network and application layers, the hunger and consumption of more and more data has also increased manifold.
A WAN optimization solution is built to address all these challenges and WAAS was Cisco’s WAN optimization solution for the past decade. It was announced end of life on 1st of November 2021, and it used different features and application specific optimizations with the primary goal of improving application performance.
There were lot of challenges with WAAS stack in terms of continuous upgrades and scale for today’s network and addressing optimization challenges for use cases such as cloud applications or satellite traffic optimization.
These challenges called for a need to write the new WAN optimization stack from ground up which caters to today’s network needs and applications and hence the move towards AppQoE.
AppQoE solution simplification compared to WAAS:
WAAS runs on Linux codebase which is a separate code from the WAN edges. This brings in a challenge from maintainability of stack and continuous upgrades to it. Also, its current stack caters more to the traditional deployments compared to AppQoE which is more catered to SD-WAN deployments.
AppQoE is integrated with the SD-WAN and works very well with other IOS XE solutions like QoS, DPI and other features. It uses the existing Orchestration/ZTP workflow from vManage and centralized controller policy to deploy and manage your SD-WAN network more efficiently. Comparing this with WAAS it’s a completely independent solution, not integrated with SD-WAN and with a complete separate management plane like WAAS Central Manager or WCM.
AppQoE uses Appnav and GRE to redirect the interesting traffic to TCP/DRE for optimization. Comparing that with WAAS where we have multiple options available which are good from the perspective that it gives flexibility in terms of deployment but also brings in lot of complexity from deploying, managing, and debugging perspective if you look at the overall WAAS solution. Appnav on AppQoE has also been simplified in the way it intercepts and redirects the traffic for optimization. The whole AppQoE configuration is taken care in the backend with just a few simple clicks from vManage.
AppQoE feature comparison with WAAS:
Loss mitigation with Forward error correction and packet duplication and optimizations for different SaaS applications are the key differentiations that are supported with AppQoE and not with WAAS. So, you can optimize your office 365 traffic or Salesforce or cloud application with AppQoE. Using cloud OnRamp with all these will further improve overall the application experience from end user perspective.
There are no application specific optimizations with AppQoE compared to WAAS like SMB AO or MAPI AO but that is taken care by TCP/DRE optimizations on AppQoE that will optimize these applications as underneath it’s still TCP traffic.
Key building blocks of AppQoE:
TCP Optimization, Forward Error Correction and Packet Duplication, DRE/LZ and vManage are key building blocks of AppQoE.
TCP Optimization uses BBR2 congestion algorithm to define how fast it can send the data over the WAN link. BBR stands for Bottleneck Bandwidth and Round-trip propagation time. It also uses standard inbuilt TCP improvements like windows scaling, large initial windows, selective acknowledgement as part of its stack.
Forward error correction or FEC and packet duplication are primarily targeted towards link integrity issues like network errors, packet loss, etc. and to improve the overall network stability. Forward error correction sends parity packets to the peer to improve network stability while packet duplication sends duplicate packets over the redundant WAN link to efficiently handle packet loss scenarios.
DRE and LZ are compression techniques with a key difference that DRE does byte level caching and is completely protocol agnostic while LZ is also protocol agnostic however it does a zip type compression on top of DRE to reduce the amount of data on the WAN.
vManage enables the complete orchestration/ZTP workflow for SD-WAN edges and its different features like AppQoE. It gives a single pane of glass for your overall network including telemetry and monitoring.
TCP Optimization - WAAS vs Viptela OS vs IOS XE SD-WAN:
TCP optimization is a very generic term and used quite freely when we talk about this in terms of WAAS, Viptela OS and AppQoE. All of them support TCP optimization however there is quite a bit of difference between the three implementations.
The primary difference between TCP and UDP is that of guaranteed packet delivery. It is a very important feature of TCP but there is one more important feature and that is flow control which basically decides how fast or slow it must send the data. This primarily depends on congestion on the link and WAAS uses Cubic Congestion algorithm to determine the sending rate. This was developed by Google but its good only for traditional loss-based networks where packet loss is considered as a key parameter to calculate the sending rate. The networks have improved, and we have much more bandwidth now on our WAN pipes with even bigger buffers on the network nodes.
Hence comes the BBR which was again developed by Google with a ground up rewrite of congestion control and it uses latency instead of packet loss as a primary factor to determine the sending rate. There are two versions of BBR - BBR1 and BBR2.
BBR1 is used in Viptela OS. It used Cubic in earlier releases but it was later upgraded to BBR1. It is much better compared to Cubic, and you get much better throughput and reduced latency with it however, BBR1 has its own share of issues with respect to performance on links with different latencies. One other issue that was noticed with BBR1 was related to how it handled different queue lengths.
Hence the move towards BBR2 on AppQoE that further improves on BBR1 in terms of using variable latency links, queue lengths, and reducing retransmissions. AppQoE with BBR2 along with other features like Forward Error Correction, Packet Duplication, DRE/LZ that can enhance the overall application experience for your application deployed on-prem or in cloud.
Forward Error Correction:
Forward Error Correction addresses the link integrity challenges in the network. This is one of the mechanisms used in a SD-WAN network to mitigate packet loss.
It sends one parity packet or error correcting packet for every 4 packets. There are many ways to generate this parity packet. One of which is exclusive OR (XOR) which is used by our stack. The receiving end will examine sequence numbers of the packets to check if they are missing. If it received all the packets, then the parity packet is discarded. If one of the data packets is missing, then it is regenerated by performing the same bitwise exclusive OR operation on the received 3 packets and the parity packet. This removes the need for sender to send the packet again in turn avoiding packet loss.
The primary use case for Forward Error Correction is for real time traffic like Voice and Video which is very time sensitive and the whole communication can get impacted with a slight increase in packet loss.
Packet Duplication:
Packet Duplication is also one of the mechanisms to mitigate packet loss.
It is typically used for critical and real time traffic to improve the overall quality of experience for these applications. It’s quite a simple feature where it sends duplicate packets over redundant WAN links to mitigate packet loss. If the receiving Edge router receives all the packets, then the duplicate packets are discarded.
Data Redundancy Elimination (DRE):
DRE is one of the key building blocks of AppQoE and is such a powerful feature that it alone can give WAN traffic reduction by 60-90%.
It’s a dual-sided TCP stream optimizer where DRE replaces the repeated data in the stream with much shorter reference called signature. It then sends this shortened stream across the WAN thereby reducing the amount of traffic over the WAN link. Since it’s a dual-sided solution, the receiving end also has the same synchronized DRE cache with its own corresponding signature database. It is completely application and protocol agnostic in the sense that it can be any application that uses TCP or any protocol like HTTP, SMB, MAPI, FTP that ride on TCP that can be optimized using DRE.
Lempel-Ziv Compression (LZ):
Lempel-Ziv compression is part of the DRE stack and is also a compression technique just like DRE with the difference being that it uses zip like compression on the data stream before it is sent over the WAN. This compression is on top of DRE compression so you can get additional reduction in WAN traffic using LZ. It can give almost 10% additional reduction in WAN traffic on top of DRE.
DRE Data Security:
We store data on the disk for DRE to optimize it. This brings in the question of what about the security of this data, how secure it is?
The DRE cache is stored in a /data partition on the disk. This partition is always encrypted. There are 2 keys involved in disk encryption. The data partition is encrypted using a symmetric key and the symmetric key itself is encrypted using an RSA key. DRE generates and stores only the symmetric key in an encrypted form on the disk while SKA manages the generation and storing of RSA keys. So, there is this dual encryption that you get for the DRE cache keeping it fully secure.
SSL Optimization:
SSL optimization is also one of the use cases that is supported on our WAN edges along with DRE.
If there is SSL traffic that needs to be optimized, for e.g., HTTPs, one of the most important parts of the whole SSL communication is certificate exchange. If WAN edge is not able to decrypt the incoming traffic it will not be able to optimize it and so the flow first needs to be unencrypted to apply any optimization on top of it. The way it does this is by acting as SSL proxy and intercepting the traffic from client/server and providing its own certificates to the client using the modified server certificate.
This is a completely FIPS compliant solution and DRE is fully integrated with SSL proxy feature to encrypt/decrypt the data stream for optimization.
AppQoE Deployment Scenarios:
There are two deployment scenarios available with AppQoE.
Integrated service node will have both the Service Controller and Service Node functions in the same device. Service Controller will intercept the traffic and use Appnav to redirect it to Service node and Service node will optimize the traffic using TCP/DRE, LZ.
External Service Node deployment will have service controller and service node functions are on separate devices. A WAN edge like a ASR1k or Catalyst8500 can be used here as a Service controller and use Appnav to redirect the traffic to external service node that can be a catalyst 8000v to do only optimization with TCP/DRE, LZ.
The solution is designed in such a way that its high scalable so if there are high number of TCP flows that needs to be optimized then both the functions of service controller and service node should be on separate devices like for a typical hub location which is aggregating traffic from multiple branch sites.
For branch the usual preference is to deploy as a one box solution and hence the choice of integrated service node option and again there are options for multiple platforms here depending on the desired scale.
AppQoE Use Cases:
There are multitude of deployment use cases supported with AppQoE. We can categorize them in basically 4 different categories:
Branch to datacenter traffic: This is a straightforward use case where the data resides on-prem and users located in different branch sites access this data day in and day out. Lot of this data is redundant and both TCP and DRE with LZ can help to optimize this data for faster access with reduced latency resulting in increased application experience from end user perspective.
Cloud application traffic optimization: We can deploy catalyst 8000v in cloud and so the applications that are residing in cloud can use this solution for improving application experience. Catalyst 8000v will be deployed in front of the application residing in the cloud and the other WAN edge will be deployed at one of the sites whether on branch or datacenter. AppQoE combined with app aware routing and cloud OnRamp brings a powerful solution that be deployed for faster access to the cloud applications.
Optimizing satellite traffic: This use case is not only important but is also very challenging. Imagine a use case where a ship using a satellite connection communicating to one of the regional data centers and the users on the ship using this satellite connection to access the required data. The satellite connection itself comes with very high latency almost to the tune of 600-900ms may be even more and this brings in a challenge of application response time, packet loss, etc. AppQoE with TCP and DRE can optimize this traffic as well and can work with these high latency links to provide a better application experience
SD-WAN Remote Access: Work from home has become a standard across the organizations and so this use case is even more relevant today. A remote user working from home can use AnyConnect or any of the native VPN client to connect to one of the WAN edges. The use case could be that of a file download and application access to one of the applications that are deployed in on-prem DC or in cloud. These remote users would be coming in on one of the service VPN and the VPN connection would be terminating on one of the WAN edges. From WAN edge perspective this would be a normal user and the request to download a file or application access would be subject to the same TCP/DRE/LZ optimization like a user that is in one of the branch sites. The traffic from WAN edge to the peer WAN edge would be optimized and remote user would get faster access to this data even while working from the comfort of their home. This again is a very powerful solution that can be deployed to extend the AppQoE benefits for remote users.
WAAS to AppQoE Migration Platforms:
There are multiple migration options available from platform perspective when migration your existing WAAS deployment to AppQoE with SD-WAN. The choice of platforms completely depends on the required scale and performance on your Branch or Datacenter or Cloud.
To summarize AppQoE along with other features in SD-WAN stack is a very powerful solution that brings different level of optimization depending for different use cases and it addresses different problem statements like latency optimization or bandwidth optimization with DRE and LZ.
This is a fully integrated solution with other SD-WAN features like UTD and SSL proxy so as a whole - the solution is very powerful with all the pieces tied together.
With the choice of many platforms available for different use case and scale deployment and along with a WAN optimization stack that is built from ground up to address these challenges faced by today’s network and with a tight integration with SD-WAN stack and consistent policy framework across your SD-WAN network, it makes Cisco the only vendor which ties all these important pieces together to bring a solution for today’s network,
This is a very powerful solution that can be deployed to improve the overall application experience which is the end goal of any network.
You can also refer to below links for more details on AppQoE config and supported platforms and WAAS EoL:
Config Guide (Integrated Service Node and External Service Node): Cisco SD-WAN AppQoE Configuration Guide, Cisco IOS XE Release 17.x - External Service Nodes for AppQoE Services [Cisco SD-WAN] – Cisco
Config Guide (DRE): Cisco SD-WAN AppQoE Configuration Guide, Cisco IOS XE Release 17.x - Traffic Optimization with DRE [Cisco SD-WAN] – Cisco
WAAS End-of-Sale and End-of-Life Announcement: Cisco Wide Area Application Services (WAAS) Software - End-of-Sale and End-of-Life Announcement for the Cisco WAAS portfolio - Cisco
