Deep Dive on DMPO and its Performance Features (available and missing) Part 1
In the last year I got quite deep insight into ther vendors SD-WAN implementation and also have seen what various vendors are critizising about the VMware DMPO features.
Also there are a lot of misconceptions on the market around some of these features.
So let´s try and evaluate and look a little bit deeper into typical performance features and the VMware implementation of them
Features discussed in this Blog (Part 1)
- Per Packet Load Balancing
- Forward Error Correction (FEC)
- Packet Replication
- Latency Remediation
The following Features will be discussed in Part 2 of my blog
- TCP Optimization Techniques
- Dejitter Buffering
- SAAS Application Monitoring
Per Packet Load Balancing
Unfortunately this term can be quite easily misinterpreted, when you Google for the term and get the following result:
This behaviour (often criticized by other vendors about VMware) as described above would only work quite well when you have very similar or equal connections.
If for example 2 links have both 10Mb/s Bandwidh but one has 10msec delay and the other 30 msec would result in high resequencing overhead, high jitter as every 2nd packet will come late, the next on already waiting,a.s.o.
BUT the VMware SD WAN implementation does a much more clever PER Paket Load Balancing algorithm especially when dealing with different delays.
It is a kind of destination sequence based per packet load sharing mechanism
A packet would only be sent over the link with a higher delay when the
delay for this second link is equal or lower than the sum of the
queueing delay plus the link delay of the first link.
So in the above picture
Packets 1-3 will be sent over Link 1 as the sum of propagation and queueing delay is less than the latency of the alternate link 2
Packet 4 (P4) when using link 2 for sending will have 30msec latency, but Packet 5 (P5) will have 20+ msec queueing delay and 10msec latency, so it will not overtake P4, thus P4 can be sent over the second link without causing waiting delays or jitter.
In that way packets will arive at the correct time and typically resequencing and buffering of later packets at the destination edge would be only needed quite rarely and Jitter will be minimized.
NOTE: per packet load sharing is a DMPO feature, so it only works when sending packets between Edges or between Edges and Gateways using the VCMP protocol. Packets sent to the Internet over 2 or more direct internet Links (DIA) it is always flow based.
Forward Error Correction (FEC)
VMware (or Velocloud) has its Packet Replication Feature erronously named FEC (Forward Error Correction) but both things are quite different implementations only dealing with the same problem, namely Packet Loss
From Cisco Networking academy:forward-error-correction
The advantage of FEC is, that when dealing with typically <10% packet loss, FEC can with 25% overhead rebuild 1 of 4 packets when this packet has been lost.
But it can only recover 1 out of 4 packets and if the first packet got lost there is a high jitter and the remaining 3 packets need to get buffered and then all 4 packets (the 3 original and the recovered packets are available immediately which can create bursty traffic.
-> VMware currently cannot do FEC
Packet Replication
Packet Replication sends every packet twice over available links, can recover also more than one lost packet but with 100% overhead.
Whereas other vendors only do Packet Replication when there is more than one link available, VMware can also use Packet replication on single link, but settings is generally turned on only for applications set as Realtime High Priority and when the link parameter reaches a specific threshhold of packet loss.
If there are more than 2 available links currently the Packet Replication mechanism uses only a second link and ignores further possible paths.
Note: via manual changes in the application map (applications.json) Packet Replication can also be turned on unconditionally for any application but the possible settings inside this JSON file are nowhere documented and the upload of changed app-map id restricted to the Operator level.
The following table is taken from a VMware DMPO White Paper (but as already told FEC on VMware stands for Packet Replication not for Forward Error Correction)
.png)
Amount of Packet Loss is signaled from receiver side to sender every 1 second. Depending on the traffic type and the loss percentage the link is considered GREEN, YELLOW or RED. Packet Loss is measured by adding a sequence number to each VCMP packet.
The QOE threshholds for Traffic Loss are:
- Realtime VOICE <0.3% <1.0% >1.0%
- Realtime VIDEO <0.05% <0.1% >0.1%
- Transactional <1.0% <3.0% >3.0%
When VMware is doing Packet Replication over 2 available links, I assume that they will strictly send the copied packet always on the second link, not using the standard DMPO Per Packet Link Selection mentioned above. (But I will test it in my lab and inform if my assumption is correct or not)
Latency Remediation
It is clear that there can be no remediation method for latency, but if you are using links which have a basic high latency (like satellite-links), it can happen that you always have YELLOW or RED results , even though the line is working correctly.
In recent version (>5.1) the QOE threshholds for Latency can be adapted (changed) in profile or edge, when operator or MSP allows "Customize QOE"
Currently this feature is in Beta state, documentation can be found via the below link
Generally the actual used QOE threshholds and a lot of other parameters can be seen for a privieldged Edge CLI user by using
shell > cat /etc/config/edged
NOTE: you can change paramters in edged but with utmost care, as there is no control if the changed parameter are aceptable or can lead to unintended consequences.
- TCP Optimization Techniques
- Dejitter Buffering
- SAAS Application Monitoring
Comments
Post a Comment