Overview
Real-time applications have more stringent delay requirements than normal data transmissions. As a result, retransmission of the lost packets is generally not a valid option for such applications. In these cases, a better method to attempt recovery of information from packet loss is through Packet Replication and Forward Error Correction (FEC).
Real time applications with high bandwidth requirements cannot work efficiently in an environment with low capacity links. Packet Striping or Link Aggregation techniques can be utilized to provide required bandwidth to real time applications.
Packet Replication, FEC, Packet Striping and network conditions could cause packets to arrive out of order resulting in retransmission or discarding of packets at end host. Packet reordering and delivering packets to end hosts in original order can improve application performance.
Packet Replication
Versa FlexVNF provides packet replication to minimize packet loss and reduce network latency.
Copies of the packet are sent on alternate available paths to reach next hop branch or hub. Duplicate packets are discarded at the receiving branch and original order of the packets is preserved while forwarding packets to the end host.
Packet replication can be turned on for specific application data traffic or only for the FEC parity packets. It can be turned on automatically when paths carrying traffic becomes noncompliant with configured SLA metrics and can be automatically stopped when utilization exceeds configured threshold. Sites with limited capacity path can use automatic start to enable packet replication only on SLA violation.
Replication is recommended for the sites where audio calls are not clear and gaps are experienced between voice.
Figure 1 and Figure 2 shows how the replication mechanism works in an SDWAN scenario. The sender sends the packets. Site1 is configured to replicate every packet and send 1 copy of packet on alternate path in addition to forwarding original packet to site2. When a flow matches the policy Site1, it will start replicating packets. VNF2 keeps track of the sequence numbers so that it can identify copies of (duplicate) packets and keep track of the original order of packets. The first packet received at Site2 is forwarded to next hop or end host and a copy of the packet is discarded.
Figure 1: No loss scenario: Sender sends 3 packets. Site1 generates a copy of each packet. Site2 receives 6 packets and forwards original 3 packets as there is no loss and discard the copies.
Figure 2: Packet loss scenario: Sender sends 3 packets. Site1 generates a copy of each packet. Original P1 and a copy of P2 is lost. Site2 receives 4 packets and forwards all 3 packets which were generated by the sender, a copy of P1 and P2 P3 original packets and discard the copies. If replication is not enabled Site2 would have forwarded only P2 and P3 as P1 is lost and the sender has to retransmit when the receiver detects this loss.
Forward Error Correction (FEC)
Versa FlexVNF provides recovery of lost packets on the receiving branch using Forward Error Correction. For every N packets, it generates an FEC packet which is used to recover lost packet on the receiving branch.
Like packet replication, FEC is recommended for the sites experiencing loss of clarity in VoIP calls or for any critical traffic which is experiencing packet loss on the path. It can be turned on automatically when links carrying the traffic becomes noncompliant with configured SLA metrics and can be automatically stopped when utilization exceeds configured threshold.
FEC can be turned on along-with replication, at the sites having multiple paths, to provide maximum protection and correction. Or FEC can be used to recover packets independently where replication might not be useful, like at the sites having a single path available for transporting traffic.
Using FEC the observed loss at the receiver’s end is minimized providing the user with a better quality of experience. For example, if there is a loss of 5% on path, if 3 packets are sent, then the probability that all three packets make it across the network is 85.74%. This probability increases to 98.6% when FEC is used to generate a parity packet for every 3 packets.
In some codecs, critical information is present in the initial part of the payload, so it is more important to be able to recover the initial part of the payload. This information can be utilized to reduce the overhead of generating parity packets. It is possible to configure the size of the payload that needs to be recovered rather than the whole payload.
When FEC is configured, one of the main parameters that need to be configured is the frequency of the generation of parity packets. That parameter is the Number-of-Packets per Parity (NPP). Lower value gives better protection but results in higher overhead. For e.g. if a parity packet is generated for every 3 packets (npp = 3) then the overhead is 100/3 = 33%. If there is a uniform loss of 5% in that path, the probability that all 3 packets make it across the network is 98.6 (85.74 without FEC). When the NPP is changed to 6, then the overhead reduces to 100/6 = 16%. Now the probability of all 6 packets making it across the network will be 95.56%. The user has a choice of improving the protection at the cost of extra bandwidth, depending on the level of protection desired. Only the sender needs to be configured with the NPP parameter. The parity packet has enough information for the receiver to figure out the NPP parameter on the sender side.
Figure 3 and Figure 4 shows how the FEC mechanism works in an SDWAN scenario. The sender sends the packets. The FEC in Site1 is configured to generate a parity packet every 3 packets. When a flow which matches the policy is received in Site1, it will start generating parity packets. Site2 keeps track of the sequence numbers so that it can identify lost packets. If no packets are lost, Site2 will consume the parity packet. However, if Site2 detects a loss, when the parity packet arrives in Site2, it will use this information to regenerate the lost packet.
Figure 3: No loss scenario: Sender sends 3 packets. Site1 generates a parity packet for every 3 packets. Site2 consumes the parity packet since there is no loss
Figure 4: Scenario with packet loss: Sender sends 3 packets. Site1 generates a parity packet When parity packet arrives, Site2 regenerates the packet.
Packet Stripping
Packet striping provides a link or bandwidth aggregation at sites where the requirement is to utilize throughput of multiple links for one flow. To provide combined throughput, Versa FlexVNF sends successive packets on alternate available paths to reach next hop branch or hub. The original order of the packets is preserved while forwarding packets to the end host.
Packet striping is recommended for the sites which have low capacity links and require high throughput for a specific type of traffic to be compliant with configured SLA metrics.
Figure 5 and Figure 6 shows how the packet striping mechanism works in an SDWAN scenario. The sender sends the packets. Site1 is configured to do packet striping. When a flow which matches the policy is received in Site1, it will start sending successive packets on all available paths. Site2 keeps track of the sequence numbers so that it can maintain the original order before forwarding packets to next hop or end host. If stripping is enabled then the sender will see the combined throughput of the available paths otherwise sender will see throughput of only one path on which the traffic is flowing.
Figure 5: Without packet striping: Traffic is using single path between Site1 and Site2. As a result, throughput seen by the sender is 5 Mbps.
Figure 6: With packet striping: Successive packets are sent on different paths of 5 Mbps each. Throughput seen by the sender is 10 Mbps.
Packets are forwarded on alternate paths based on the available bandwidth on the path. If there are two paths Path1 and Path2 of respective capacity 5 Mbps and 10 Mbps, then Versa FlexVNF will forward double the number of packets on Path2 then on Path1. Distributing the packet load evenly on the available paths.
Packet Reordering
FEC recovery can cause reordering. For example, consider the case where FEC is generated every 4th packet, and the 2nd packet is lost. Since the 2nd packet can be regenerated only when the parity packet is received, which happens after the 4th packet, the receiver will see packets in the following order: 1, 3, 4 and then 2. A configuration option is provided which would make the receiving FlexVNF to buffer the received packets till they can be sent out in order, shielding the user.
Similarly, in packet replication and striping, as packets are arriving on different bandwidth paths, it can arrive out of order. Delivering out of order packets to end host can cause retransmissions. A configuration option is provided which would enable real time packet reordering to provide a seamless experience to end hosts.
Figure 7 shows how the packet reordering works in real time. Site1 sends packets to Site2 in original order on all available paths. Site2 receives packet 4 out of order. To maintain original order while forwarding packets to end host, packet 4 is buffered at Site2 until packet 3 arrives and packets are forwarded in original order to end host. As buffering the packet could add a delay in delivering the packet, Versa FlexVNF maintains adaptive timers to decide when to stop waiting for the packet to maintain order and forward the buffered packets.
Figure 7: With Packet Reordering: Site1 having packet striping enabled, sends packets on all available paths. Site2 receive packet 4 out of order. Packets forwarded to end host are in original order.
Configuration
Packet replication, packet stripping and FEC are configured as part of Forwarding Profile on Versa Director. Forwarding profile can be applied on specific application defined in SD-WAN Policy and SD-WAN Rule.
Sender side needs to enable these features as they are disabled by default. The receiver automatically enables handling after receiving data packets with above mentioned features enabled.
Use Case Scenario
Along with packet replication and FEC, automatic path steering can be combined to provide maximum reliability for a business-critical application or for audio/video flows. When more than one path is available for then FEC can be enabled by default and packet replication can be configured as automatic on/off based on SLA profile. SLA violation profile can be configured based on packet loss, say for 5% loss on the path we will mark it as SLA violated path. When flows start experiencing loss <5% and paths are still SLA compliant, FEC will enable the receiving site to recover packet loss till it reaches a threshold of 5% packet loss. At that point, the path will be marked as SLA violated and automatic path steering will move the flow to a better available path with none or less packet loss. In the worst situation if the other path also becomes lossy then packet replication will be turned on automatically and can recover from packet losses. Hence the combination of these features can provide maximum possible performance at the same time not adding a lot of overhead on the paths.