Deep Dive on DMPO and its Performance Features (available and missing) Part 2

 The following Features will be discussed in this second part of my blog

• TCP Optimization Techniques
• Dejitter Buffering
  
• SAAS Application Monitoring

 

Before diving into the mechanism here an important basic fact:

    Remediation is never done for applications classified as LOW priority

 

 

TCP optimization

TCP has some embedded traffic management capabilities for reliable traffic delivery  (window.size, slow-start, RTT handling,...) 

But there are a bunch of factors which can negatively influence the performance, like

• Latency
• TCP-slow-start
• Last Mile network problems
• Out of Sequence packets
• Busty losses
• end host TCP limitations (missing fatures like SACK, windows scaling or timestamp options)

 Typically TCP optimization helps on the transmission side and improve the download time for large data transfers over latency-high and lossy WAN links.

But it can also be used for improving perfomance when on the receiver side the amount of buffers is limited and/or when the client is not able to use the SACK option using the forward proxy mode.

 TCP optimization uses different features

• Splitting connection and thus latency into smaller segments, where each segment performs separate mechanism for loss recovery
• BBR (bottleneck bandwidth and roundtrip) propagation time
• RACK (recent acknowledgement) loss detection and supplemental TLP (tail loss probe) algorithm
• enabling proxy highperformance TCP options like SACK, windo scaling and timestamp options on behalf of the client

 TCP optimization modes can be divided into 2 different TCP segmentation modes

• 3 Segment Mode (used by choosing AUTO Mode)

 the system automatically splits the TCP connection in to 3 parts by selecting  devices nearest to source and nearest to destination as TCP proxy

• 2 Segment Mode (used in SPLICE mode or Forward/Reverse Proxy Mode)

depending on the main traffic direction the administrator manually chooses an intermediate proxy on a SD WAN device in the path and thus split the connection into 2 seperate TCP connections.

I tested this TCP optimization on anothers vendor devices but especially against packet loss the improvement was rather low.
 

The above described TCP Optimization is not implemented in VMware SD-WAN.

They use a different remediation technique which is very effective but only works on DMPO links between Edges or between Edges and Gateway, so not suitable for Direct Internet Access (DIA).

It uses ACK/NACK Buffering, so that a lost packet on the DMPO-link can be recovered without detection from the TCP endpoints. Thus window-size keeps high independent of single or multiple packet-loss (unless RTT threshhold is crossed).

 

The following example from an older Velocloud presentation shows the drastical difference

 

 Due to a faulty DSL-modem I had in the past 10-15% packet-loss and without SD-WAN bigger file downloads from internet destinations were impossible, but with SD-WAN and an Internet access via Gateways I could continue to work without much poblems.

Dejitter Buffering

 This is an VMware SD Wan implemented remediation method for Realtime applications, but its usefulness is often discussed and quite difficult to measure without special devices, as only the MOS value (and even MOS is not a unique formula) can give you some information if a remediation was helpful or not.

Many SD-WAN vendors claim that today most modern Codecs have fixed or adaptive dejitter buffering implemented, thus any additional Dejitter-Buffering mechanism from SD Wan only adds some buffer delay and has only very limited benefits.

There are SD-WAN vendors which can measure MOS and can also use the measured MOS value for link qualification (SLA) but this is not implemented in VMware SD-WAN.

 SAAS Application Monitoring

 

About a year ago a customer for VMware SD-WAN told me the problem he has.

Some employes working from home (WFH) experience packet loss and significant degradation of Internet Link quality especially for some SaaS applications like Office365 or Salesforce on  afternoons and evenings, due to the fact, that most people are at home and surfing the Internet. So he asked me to find a way to measure the traffic and based on that measurement divert the traffic either to the local breakout (DIA) or send it via SD-WAN cuicuit to one of the 2 hubs and forward it from there.

I had to tell the customer, that as far as I know VERSA Networks is the only vendor  of being capable of comparing DIA with indirect links.

And VMware has nothing similar which allows testing of SaaS Application performance.

Some people might argue, that if there is only one internet connection, diverting the traffic does not help at all, but that is true regarding latency but wrong regarding packet loss as you can use remediation to overcome packet loss on sd-wan circuit and thus overcome the last mile drop problems.

If you buy a SASE solution then they have SASE-Gateways placed in front of SaaS Datacenters and then you can use the remediated SD-WAN connection from Home direkt to that gateways.

But if you have your private Orchestrator ther is still no direct way to also use VMware or MSP installed gateways. (I assumed that they were looking into such feature a year ago, but no information is available)

a. Active Monitoring

Dynamic probe packets to a particular FQDN or IP address can be used to gauge the performance of the WAN path. These probe packets can be ICMP, TCP or HTTP based. Based on these metrics, traffic steering policies can be configured to choose the best WAN path. For example Microsoft recommends probing the FQDN – http://sdwan.measure.office.com for measuring the performance for Microsoft 365 applications.

b. Passive Monitoring

Rather than use active probe packets, a clever SD-WAN edge could also monitor the user traffic flows to the various Microsoft 365 applications and rank them based on various performance metrics. This method of path selection automatically ensures that for example the business critical Microsoft 365 traffic uses the WAN path with the best performance.

• Passive Monitoring is useful for branches and central locations where more employees work and where there is regular access most of the time to various SAAS applications 
•  Active Monitoring is best used in WFH scenarios, where there are no multiple SAAS applications used the whole time

 
 But unfortunately on VMware SD WAN there is currently no way to decide if DIA or a backhaul via Hub or via Gateway is the better performing path to a internet base Saas Application.