Citrix SD-WAN uses an algorithm to select the links through which data packets are sent, and it’s expected to select the best links, after bandwidth allocation is prioritized. But for this to happen in a way that delivers the best end-user experience, you have to make sure to fine tune the criteria for evaluating link health.

Does that mean that if your Citrix SD-WAN doesn’t have the right parameters in place, a link that was working properly and that had been evaluated as stable could no longer be fully functional?

Yes.

According to the evaluation criteria of the links, penalties can be applied, which can result in bandwidth reduction and disuse of the link.

It’s important to understand how to customize parameters and the acceptable limits for link selection. However, for this to happen in a satisfactory way and to ensure there’s no negative impact, it’s imperative that the criteria used to evaluate the links’ health are fine-tuned, respecting the link characteristics and the limits the applications support. In this blog post, I’ll recommend ways to help you get the most out of Citrix SD-WAN (and the links) and deliver a high-quality user experience.

Assessing Links with Citrix SD-WAN

Citrix SD-WAN can help assess whether a contracted link is delivering the agreed-upon service level. When evaluating link quality, you have to consider parameters like stability, jitter, latency, congestion, and bandwidth. When the parameters are aligned, Citrix SD-WAN will ensure a great user experience, with high bandwidth aggregation and availability.

In many cases, the complexity of the provider’s infrastructure may also affect link quality. Internet links without dedicated bandwidth, for example, require more attention because they tend to oscillate more, and proper performance isn’t always possible.

With Citrix SD-WAN, you can collect metrics that show the efficiency of each link in milliseconds (link monitoring is done in both directions — download and upload). And if you have to show that a link isn’t delivering what’s been promised, you’ll have all the information you need to act.

Criteria for Link Classification

With Citrix SD-WAN, a link has at least two paths: one for download (WAN-to-LAN) and one for upload (LAN-to-WAN). The quality of the virtual paths depends on the quality of the links connected to them. Citrix SD-WAN monitors and scores each.

Before we go any further, let’s review some concepts around link classification. Citrix SD-WAN will classify the path as being in one of four states, in both directions (download and upload). These classifications, detailed below, can be visualized through the paths statistics in the monitoring dashboard:

Bad — By default the values considered for packet loss (Bad) will use the algorithms specified below. The link rating as Bad will occur whenever any of these conditions have been exceeded.

  • 3 lost out of last 4
  • 4 out of last 10
  • 5 out of last 20
  • 6 lost out of last 30
  • 11 lost out of last 200

When a virtual path enters a Bad state, the Path Probation Period is started by default to determine when the link can return to Good.

Dead — Shown in red, Dead indicates that communication with the link is impossible. It’s measured based on non-response time, which is 150ms by default. For Dead events, where there is no communication in the path, the Citrix SD-WAN waits 10 seconds by default (Path Probation Period) before trying to use the link again.

Congestion — Represented in red in a different column of the dashboard, Congestion means that there is congestion at some point in the link. This detection is done through jitter monitoring, which corresponds to the statistical variation of the delay in the delivery of data in a network. Congestion, in most cases, occurs when a device in the cloud has to buffer packets because it doesn’t have enough bandwidth to transmit them. This threshold is activated by default when jitter is greater than 20ms.

The penalty here is a 20 percent bandwidth reduction, specified for the link and each 100ms cycle. If jitter doesn’t return to the specified value, an additional 20 percent reduction is applied. Penalties will continue to be applied, which can move the link to an unusable state. Jitter checking cycles happen every 100ms, even if the link is completely penalized. If the link returns to usable condition based on the specified parameters, it will return to its normal state of usage.

Good — Shown in green, Good means all limits are within the expect values.

Changing Configurations

Configuration of the thresholds for packet loss (Bad) and link unavailability (Dead) is centralized in the Autopath Group and is automatically applied to all Citrix SD-WAN links that belong to that group.

In addition to being the main point for this configuration, the Autopath Group is used to automatically create paths (links) between locations and links that belong to same Autopath Group. You can see the parameters available for customization here:

The configuration for packet loss can also be done in isolation by path. However, if the link has been created automatically, it should be converted to “Static” before enabling the option to edit the Bad and Dead configuration in isolation.

In the screenshot below, accessible via Connections -> Virtual Paths -> Paths, you can see the paths were created automatically.

After you find the link you need to customize parameters for Bad and Dead links, you can enable configuration editing in isolation by selecting “Edit” and then, selecting “Convert to Static Path,” as shown below:

The congestion configuration is linked to the configuration of the SD-WAN link in the Sites menu. However, for public internet and private intranet SD-WAN links, the configuration is in Advanced Settings. Please note that the configuration is in microseconds.

As for private MPLS links, the congestion configuration is tied to the MPLS queue.

Customizing Settings

Packet loss might not affect the user experience, often because there are no significant data volume, protocol, or applications more resilient to packet loss.

Citrix SD-WAN quickly detects (in milliseconds) any variation that could compromise connection quality and uses better links to avoid performance degradation. However, sometimes the default settings aren’t tolerant enough to the contracted networks or links. There are also penalties to guarantee the quality of the communication.

So in some scenarios, you shouldn’t use the default configuration because more packet loss than the defaults may be acceptable for your environment. Additionally, to find the ideal thresholds, it will be necessary to monitor the user experience. Ultimately, the characteristics of the applications and protocols they use will determine how sensitive to loss they will be.

Here are some examples that you can use in determining an environment’s initial configuration:

  • For applications more tolerant to loss and retransmission of packets such as HTTP:
    • 40 percent loss in 1 second may not affect the user experience.
  • For applications less tolerant to loss and retransmission of packets such as RDP and G.729 (VoIP):
    • RDP: 10 percent loss in 1 second may not affect the user experience.
    • VOIP: 2 percent loss in 1 second may not affect the user experience.

There will be situations in which the links may oscillate a lot. With the default “Silence Period” and “Path Probation Period” parameters configured, the virtual path will be unavailable for a considerable amount of time. Depending on the number of links available and the stability of the remaining links, this may result in path or virtual path unavailability.

In some situations, it’s best to keep a connected location, even with poor communication quality, rather than disconnect. Here are some examples you can use for configurations:

  • For situations in which constant oscillation of links is expected and you want to use links, even in precarious situation:
    • Reduce the time of Path Probation Period so that the SD-WAN tries to use the link again quickly.
    • Increase the Silence Period so that the SD-WAN ignores shorter periods without communication.
  • For situations in which the links are not expected to oscillate and the quality of communication must be maintained:
    • Increase the time of Path Probation Period so that the SD-WAN avoids using links that oscillate for longer periods.
    • Reduce the Silence Period so that the SD-WAN can more thoroughly evaluate the periods in which it is not possible to establish communication through the link.

Whatever configuration you choose (and choose the best one for your case), you need to take into account the impact on the user experience.

Finally, you should note that, in addition to the link monitoring configuration, there are configurations related to the buffer and packet transport mode through which you can configure packet retransmission. I’ll cover this topic in a future blog on planning the ideal QoS in SD-WAN.

How Citrix SD-WAN Selects Links

Typically, Citrix SD-WAN selects links using criteria like this:

Is there a Path at Good state?

  • If yes, select the best Path Good based on its score.
  • If no, select Path Bad with the most bandwidth available.

We can’t share how we score links, but key variables we take into account include latency, jitter, and any penalty associated with the path. The link scoring algorithm accounts for bandwidth and congestion, but those aren’t strictly considered for scoring.

Whenever a path is classified as Good, the SD-WAN will select it. Paths classified as Bad might not be eligible for data traffic unless all available links are classified as Bad or if no more bandwidth is available in Good paths.

It’s important to ensure appropriate thresholds so we don’t unduly penalize links. After all, if all paths are penalized at the same time, all communication will be compromised. This means that, in addition to the appropriate threshold, the amount of data links available for the SD-WAN can increase the chances of not penalizing the user experience.

Ensure a High-Quality User Experience

We can compare the conventional model of links to a two-way street, where there’s one lane in each direction and no signals. Eventually, an accident or damage to the road might delay traffic. With Citrix SD-WAN, you can have multiple lanes in both directions, with signaling and monitoring to ensure full fluidity.

That requires configuration parameters that account for the characteristics of the contracted links and the apps and protocols that will make use of them. Citrix SD-WAN can help. Besides aggregating bandwidth, providing high availability, and selecting the best ways to transport data, Citrix SD-WAN can assess whether your provider is delivering on the promised SLAs and meeting minimum requirements to ensure a high-quality user experience.

Learn more about Citrix SD-WAN here and check out the reference architecture in the Citrix Tech Zone.


Citrix Tech Bytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.

Click here for more Tech Bytes and subscribe.

Want specific Tech Bytes? Let us know! tech-content-feedback@citrix.com.