AppQoE & WAAS FAQ

pkhilola · ‎01-16-2022

AppQoE:

What is AppQoE?

AppQoE is a WAN optimization stack and optimizes WAN traffic for different use cases for applications that are deployed on-prem or in cloud.
What are the benefits of using AppQoE?

AppQoE improves application experience by deploying different levels of optimization:
- Bandwidth Optimization – using DRE (Data Redundancy Elimination) and LZW
- Latency Optimization – using TCP Optimization
- Loss Mitigation – using Forward Error Correction and Packet Duplication
- SaaS application optimization – using Cloud OnRamp, Application Aware Routing along with TCP optimization
What are different key building blocks of AppQoE?

The following are the key building blocks of AppQoE:
- TCP Optimization
- Forward Error Correction and Packet Duplication
- DRE & LZW
- SSL Proxy/Optimization
How does TCP Optimization on AppQoE work?

TCP optimization on AppQoE splits the TCP session from Client to Server into 3 different sessions.
- Client to WAN Edge 1
- WAN Edge 1 to WAN Edge 2
- WAN Edge 2 to Server
The packet flow is as below:
- Clients sends a SYN packet with destination as Server IP
- Appnav on WAN Edge 1 will intercept this traffic based on either protocol, prefix, application, etc. and redirect to AppQoE process running on same WAN Edge 1 (integrated service node deployment will have both Appnav and AppQoE running on same WAN edge unlike an external service node deployment where both the process will be on different WAN edges)
- TCP stack within AppQoE will respond back with SYN ACK to the client on behalf of Server and will complete the 3-way handshake with Client
- WAN Edge 1 will then initiate another TCP session to the Server on behalf of the Client
- It will send a SYN packet to the Server on behalf of the Client and as part of this it will advertise its identity and capabilities. Capabilities here refers to whether the WAN edge can do TCP optimization, DRE/LZW, etc.
- The Appnav process running on peer WAN Edge 2 will intercept this traffic and redirect to AppQoE process.
- The peer WAN Edge 2 will now know the request for optimization from WAN Edge 1
- It will initiate a separate TCP session towards Server by sending the same SYN packet to Server
- Server will respond back with SYN ACK which will again be intercepted by Appnav on WAN Edge 2 and redirected to AppQoE process
- TCP stack within AppQoE will send this SYN ACK towards WAN Edge 1 and as part of this it will also advertise its identity and capabilities.
- Appnav process on WAN Edge 1 will intercept this traffic and redirect to AppQoE process on WAN Edge 1
- WAN edge 1 now knows the confirmation from WAN Edge 2 for optimization
- It will then send the ACK back towards WAN Edge 2 to complete the 3-way handshake
- WAN Edge 2 will also complete the 3-way handshake with Server on its own end of the TCP session
What congestion algorithm is used in AppQoE?

TCP Optimization is one of the key building blocks of AppQoE. It uses BBR2 congestion algorithm to define how fast it must send the data over WAN link. BBR stands for Bottleneck bandwidth and Routing-trip propagation.

This is the primary difference when comparing AppQoE TCP optimization with TCP optimization on WAAS or Viptela OS. WAAS uses Cubic congestion algorithm while Viptela OS uses BBR1 congestion algorithm.

The networks have changed today and moved from loss-based networks to more latency based and so BBR2 uses latency as one of the key parameters on how fast it must send the data and it also takes variable latency links and queue lengths into consideration while calculating the sending rate.
Does AppQoE optimize UDP traffic?

No, UDP traffic is not optimized with AppQoE
What are different use cases addressed by AppQoE?

AppQoE can optimize any TCP traffic. The use cases can be categorized into below 4 sections:

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 LZW 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: 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: AppQoE with TCP and DRE can optimize this Satellite traffic and can work with high latency links to provide a better application experience. It supports latencies as high as 900 ms and address challenges like application response times, packet loss, etc. that are very common in Satellite links.

SD-WAN Remote Access: AppQoE benefits are now extended to the remote users working from the comfort of their home. A remote user uses AnyConnect or one of the native VPN clients for connecting to one of the WAN edges or access to application hosted in Cloud or data that resides in one of the on-prem datacenters. AppQoE can optimize this traffic using TCP and DRE/LZW.
What different SaaS applications can AppQoE optimize?

AppQoE can optimize any SaaS application that uses TCP. The top 4 asks have been for Office365, Salesforce, G-Suite and applications hosted in AWS.
Does AppQoE support caching?

No, it is currently not supported with AppQoE and is on roadmap
What is the difference between DRE and LZW?

DRE & LZW are both compression techniques however there is a fine difference between the two. DRE reduces the amount of WAN traffic by caching previously seen data patterns while LZW reduces the amount of WAN traffic by doing zip like compression on top of DRE.
Can AppQoE optimize Enterprise applications such as SMB/CIFS, MAPI, Citrix VDI?

There are no application specific optimizers in AppQoE. However, SMB/CIFS, MAPI, Citrix VDI are all TCP based applications so TCP, DRE/LZW on AppQoE can provide significant optimization benefits for different applications.
Is AppQoE supported on non SD-WAN deployments?

No, AppQoE is only supported for SD-WAN deployments
What are traffic interception methods used in AppQoE?

AppQoE supports Appnav/GRE as traffic interception/redirection methods
Does AppQoE support flow sync between Appnav Controllers (Service Controllers)?

No, flow sync is currently not supported
Does AppQoE support high WAN latency use cases?

Yes, AppQoE is a WAN optimization solution and is typically deployed for high WAN latency use cases
Does AppQoE support satellite connection use case and how much is the max latency supported?
Yes, optimizing Satellite traffic is supported with latencies as high as 900ms
What is Forward Error Correction?

FEC or Forward Error Correction is one of the key building blocks of AppQoE. It is one of the mechanisms used in 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.
What are some design considerations we need to keep in mind while designing networks with Forward Error Correction?

Below are some design considerations when designing the network around FEC:
- FEC is a dual sided solution so it must be enabled on both ends of SD-WAN tunnels edges through which the flow traverses. It can also work on sites that have single WAN transport.
- It has performance implications so it must be enabled on subset of flows and not all flows
- Its primary use case is to apply it for real time traffic like Voice/Video however Voice apps typically have FEC built into the codec.
- FEC implementation differs between vEdge and XE SD-WAN edge so interop between the two is not supported.
What is Packet Duplication feature?

Packet duplication is one of the key 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 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
What are some of the design considerations we need to keep in mind while designing networks with Packet Duplication?

Below are some design considerations when designing the network around Packet Duplication:
- It requires more than 1 WAN transport per site as it duplicates traffic across redundant links
- It has performance implications so it must be enabled on subset of flows and not for all traffic
- Packet duplication implementation differs between vEdge and XE SD-WAN, so interop is not supported between the two.
What is DRE?

DRE or Data Redundancy Elimination is a compression technique that reduces the amount of WAN traffic by caching previously seen data patterns.

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.
How much WAN traffic reduction we can expect with DRE?

The actual traffic reduction depends on use case and the type of traffic but generally we have seen traffic reduction anywhere from 60-90%.
What applications/protocols can be optimized with DRE?

DRE is application and protocol agnostic so cache from one protocol can be used to optimize traffic from any other protocol.
Can DRE be deployed in Cloud to optimize SaaS applications?
Yes, DRE can be deployed in Catalyst 8000v to optimize traffic for SaaS application.
How does DRE work with UTD and SSL Proxy?

DRE is fully integrated with UTD and SSL Proxy feature. The flow must be decrypted first for it to be optimized by DRE.
- Once the TCP sessions are established, packets from Client are sent to UTD to determine if the session should be decrypted, pass-through or never decrypted.
- If UTD responds with the decrypt verdict, then subsequent flows are created within SSL Proxy with two connections, one between Client and WAN Edge and second between WAN Edge and Server.
- Once these connections are setup, data from server reaches TCP stack running on WAN Edge and then to SSL Proxy where it is decrypted.
- It is then sent to DRE for optimization and then to UTD, SSL Proxy, TCP stack and it is sent out of the device.
What is DRE Cache and DRE Signature database

DRE has two important databases as part of its optimization. DRE Cache is where the incoming data from data stream is stored in 32 bytes units of measurement. A corresponding signature database is created for every 32 bytes of data in DRE cache. The signature size is 5 bytes.
What is DRE 1^st pass and DRE 2^nd pass?

When DRE is enabled for the first time, the DRE cache is empty. When different users start sending data, DRE will start to cache that to build a DRE cache database. This process is known as DRE 1^st pass since DRE has not seen this data earlier and is building the cache for the first time. Once this cache is built and if DRE sees this data from client again, it can use the same cache to optimize the traffic. This process is known as DRE 2^nd pass.
Is DRE a dual sided solution?

Yes, DRE is a dual sided solution, and it must be deployed on both ends of the SD-WAN tunnel.
Where is DRE cache stored on the disk?

DRE cache is stored on /data partition on the disk
Is the DRE cache secure?

Yes, DRE cache is stored on /data partition on the disk and this partition is always encrypted using a symmetric key. This symmetric key is further encrypted with an RSA key.
How can we deploy DRE?

DRE is deployed as a docker container on WAN edges
How does SSL Optimization work with DRE?

SSL optimization is one of the important use cases for any WAN optimization stack. It enables to see the unencrypted flow so that features like DRE can use that to optimize the data. 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
What are different certificate management options available with SSL optimization?

There are multiple certificate management and deployment options available. We can use enterprise CA, or vManage as CA or we can also use vManage as intermediate CA connected to the enterprise CA. The choice of deployment completely depends on the use case. All these solutions work with DRE and SSL proxy use case.
What are the different handshake procedures for SSL optimization?

SSL optimization supports RSA, DSA and ECDSA handshake procedures
What is Integrated Service Node?

Integrated Service Node deployment refers to a deployment where both Service Controller and Service Node functions are deployed on same WAN edge. It is mostly used for a Branch deployment as a one box solution.
What is Service Controller?

Service Controller is a function to intercept and redirect the traffic to AppQoE process running on same WAN edge or a different WAN edge. Appnav process running on a WAN edge acting as Service Controller is used to do traffic redirection.
What is External Service Node?

External Service Node deployment refers to a deployment where both Service Controller and Service Node functions are deployed on different WAN edges. It is mostly used for a Data Center deployment as it aggregates traffic from multiple branches.
What deployment scenario is recommended for AppQoE?

The choice of deployment scenario, whether it is internal service node or external service node deployment, completely depends on the use case and scale requirements. Typically, integrated service node is used for Branch deployment whereas external service node is used for Data Center deployment.
How does AppQoE use VPG interface?

VPG or Virtual port Group interface is used to stich the LAN to WAN or WAN to LAN traffic. At a high level, once traffic is received on LAN, it is sent to VPG interface which then redirects it to AppQoE process. Once AppQoE does optimization, traffic is sent back to VPG interface which then sends it out towards WAN.
What are different platforms supported with AppQoE?

AppQoE supports different platforms for both Integrated Service Node and External Service node deployment. Please check this link for more details - Cisco SD-WAN AppQoE Configuration Guide, Cisco IOS XE Release 17.x - Traffic Optimization with DRE [Cisco SD-WAN] - Cisco
Is there any way to utilize AppQoE without full-blown SDWAN?

AppQoE is a feature developed inside our SD-WAN solution. It cannot work without SD-WAN
Can AppQoE be used for the Real-time Voice/Video applications (teams, Webex, etc)? if yes, which tools from AppQoE will be used?

Before using FEC or Packet Duplication for Voice traffic, it is highly recommended to test it out in the lab to make sure it is not causing any out-of-order packet issues. Other than that other AppQoE features are relevant to TCP traffic.
What TCP Congestion algorithm is used for AppQoE; BBR or BBRv2?

It depends on the platform. certain platforms use BBR and certain platforms use BBRv2.
Is there a list of what each cEdge platform uses?

Alll cEdge platforms use BBRv2 and vEdge platforms use BBR
Is DRE applicable to TCP traffic only?

Yes, DRE is applicable only for TCP traffic
In an AppQoE in SDWAN and WAAS in SDWAN mixed environment (or let's say customer is in migration phase) can DRE and LZW optimization work between AppQoE SN and WAAS?

Interoperability between WAAS and AppQoE is not supported.
Do we support TLSv1.3 decryption or do we downgrade TLSv1.3 connections to TLSv1.2?TLS version 1.3 is not supported and is downgraded to TLS version 1.2.Learn more
Is there CVD or design guide for AppQoE?

We don't have it as of now. We will share it once it is available.

This article might help:
https://www.cisco.com/c/en/us/support/docs/routers/sd-wan/221870-catalyst-sd-wan-appqoe-dre-topology-c.html
Which states that vEdges use Cubic and cEdge use BBR; has that changed to be just BBR on vEdge and BBRv2 on cEdges?

vEdges use the BBR starting from 20.4 release and prior to that vEdges were using CUBIC. cEdges always used BBRv2.

WAAS:

What is WAAS?

WAAS stands for Wide Area Application Services and is a WAN optimization stack. It went end-of-life on 1^st Nov 2021. End-of-life link - https://www.cisco.com/c/en/us/products/collateral/routers/wide-area-application-services-waas-software/waas-portfolio-eol.html
What applications can WAAS optimize?

WAAS optimizes application traffic using TCP optimization, DRE/LZW and different application specific optimizers like SMB AO, CIFS AO, MAPI AO, etc.
How has AppQoE improved WAN optimization compared to WAAS?

AppQoE uses a enhanced congestion algorithm BBR2 which caters to the deployments we see today. It comes with improvements on packet retransmissions, using variable latency links and queue lengths. Comparing that with WAAS which uses Cubic congestion algorithm which is made for traditional loss-based networks. AppQoE also is a tightly integrated solution with SD-WAN compared that to WAAS which is a separate stack then SD-WAN.
What are migration platforms for WAAS?

Please check this link for different platforms that can be deployed with AppQoE - Cisco SD-WAN AppQoE Configuration Guide, Cisco IOS XE Release 17.x - Traffic Optimization with DRE [Cisco SD-WAN] - Cisco
Can WAAS & AppQoE interop?

No, WAAS & AppQoE interop is not supported.