XenDesktop Bandwidth: The Complete Set
Part 3 – Bringing It All Together: Daily User Average and General Recommendations
In Part 1, I discussed the methodology and infrastructure used for testing.
Then in Part 2, I covered the importance of optimizations, and showed that bandwidth savings can exceed 80%.
This blog post will show the results of the full Login VSI 4.0 Medium Workload and some general recommendations to help you succeed based on our findings. Once again, tests were run at the three configurations defined in part 2 of the series and once again significant bandwidth savings were seen.
Login VSI 4.0 Medium Workload
The release of Login VSI 4.0 in May 2013 brought a number of improvements and changes, including an overhaul of the Medium workload, which is now four separate segments and 48 minutes in length. In addition, there is more variation in the documents accessed and a more realistic average workload.
The new workload also means that I could not compare the results to previous tests with older versions; of which there are many. Luckily the XenDesktop 7 tests which everyone is patiently waiting for are run with the same workload and more and more papers are published every week using the newest version of the tool.
For consistency and caching reasons, the workload was forced to use only a single video out of the five provided in the VSI Content Library. Video 1 in the content library was chosen for this purpose and is a trailer for a British movie by the name of Wild Target. For more information on the Medium workload see the Login VSI workload overview page.
“Daily User Average”
Many customers often ask what the average bandwidth requirement is for XenDesktop. As mentioned earlier in the series, the answer is always “it depends”. It depends on what the user is doing, the visual settings of the desktop, and the policies in effect. It also depends on the network conditions. Because the ICA protocol is an adaptive TCP based protocol, the average bandwidth consumption on a LAN will be different than a WAN (as seen in the second blog post of this series). To elaborate on this, refer to the two charts below.
The first chart shows us that bandwidth will depend on what is on the screen. The chart shows a portion of the Medium workload which at first is idle, then plays a video (which was not redirected) and is then idle once again. When idle, the session consumed less than 5kbps, even though applications were running, because no screen refreshes were occurring. This would not be the case if a session is left idle, but with a video playing on repeat or on a web page which constantly refreshes its advertisements. When playing the video the session consumed the entire available network. (Note that server fetched, server rendered video delivery is the least preferred method, more to come on why).
The second chart depicts a portion of the Login VSI Medium workload during which various graphical websites are being browsed. Once again you can see periods of very low bandwidth consumption, during which all apps remained open and the web site was fully loaded but no user interaction took place. When browsing over a WAN connection the bandwidth utilization decreases as HDX Adaptive Orchestration senses that the network conditions are restricted and tunes the session. The end result of this is that a quality responsive session can be delivered at lower bandwidth costs when needed.
So with all of this mind, what is the “daily average”?
The average bandwidth, excluding video, for the Login VSI Medium workload using the best practices optimized image on a 1.536 Mbps WAN connection was approximately 85kbps. Adding in video without any redirection bumped that up to approximately 160kbps. I have broken down the averages separately because video is especially bandwidth intensive although both bandwidth, and more importantly user experience, can be improved using Citrix HDX technologies such as HDX Flash Redirection. I will discuss some of these technologies further in this post although many of them are thoroughly explained in this Whitepaper.
Please note that these averages do not mean that you can simply run a full XenDesktop over an 85kbps connection; again, it always depends. There are various other factors that need to be considered before simply deploying a production environment with a limit of 85kbps for every user:
- Burst capacity must be accounted for. For example, running a PowerPoint presentation or maximizing an image requires short bursts of bandwidth which must be accommodated to ensure a smooth user experience.
- Other traffic on the network must be considered. A typical WAN will have more than just ICA traffic and a good understanding of that traffic is important prior to deployment. This traffic can be managed through CloudBridge with advanced QoS capabilities to ensure ICA sessions are not slowed down due competing network traffic such as a print job or file transfer.
- Not all users can be represented by the Medium Login VSI workload. Understanding and segmenting users is an important step of any deployment. For example, a manager who might sit in on various meetings throughout the day will have different bandwidth requirements than an employee who is at the computer all day except for lunch and coffee. Although both may use the same set of applications, the bandwidth needs may be significantly different.
The average bandwidth for all three configurations is summarized in the chart below.
This “Average” is meant to help as a baseline when planning a deployment. Results will vary depending on all of the factors previously discussed and there is no substitute to testing. The VSI Medium workload does not cover custom applications with specific requirements, that left untuned, can often consume excess bandwidth. The amount of time users spend on virtual infrastructure also needs to be considered. This average is based on a desktop that is always on, meaning XenDesktop is the primary workstation for the user. If a virtual desktop is to be used for very specific purposes, less bandwidth might be needed to accommodate usage.
The charts at the end of this post show the results from the different networks and configurations tested.
Flash Redirection and CloudBridge (Formerly Branch Repeater)
HDX Flash Redirection has been part of XenDesktop for quite a while and has helped many customers achieve better scalability and a better user experience over the WAN. To summarize how HDX Flash Redirection works, flash content is fetched by and rendered on the client device. This allows for two important things to happen from a bandwidth perspective.
- The content can be buffered and played at its original quality without having to send excessive screen changes through ICA
- The content can be cached on the local device and if accessed again, could have almost no effect on bandwidth over the WAN
HDX Flash Redirection has been discussed at length in various articles and more information can be found in this article.
Keeping in mind that server fetched and rendered typically requires the most bandwidth, flash redirection should be considered whenever possible to help reduce traffic and improve user experience. However, video is still video and even with flash redirection it still requires additional bandwidth. So what happens when an entire branch has to watch the same videos for corporate training or if there someone in the office is sending out the newest cat video on YouTube?
This is where Citrix’s CloudBridge solution can help. Video caching is one of the use cases where CloudBridge can have a huge impact on bandwidth saving over the WAN. CloudBridge can cache these videos allowing others in the branch to watch them with LAN like performance while drastically reducing the bandwidth required. CloudBridge can also, to an extent, help improve the delivery of other forms of video over the WAN. For more information on CloudBridge and video delivery see this Whitepaper.
As you can see there are many factors to consider when bandwidth is a constraint. Whether you are just getting started planning for a deployment, or having issues with a current one, here are some general recommendations to consider.
- Optimize. It is extremely important that you take the time to optimize the desktop image. As you saw in the last blog post, removing some of the ‘eye candy’ makes a big difference.
- Create a Citrix policy for WAN connections. While there are various ways to implement this, having a WAN based policy can make a big difference without interfering with sessions in the LAN. Just a slight reduction in FPS can have a huge impact on bandwidth utilization.
- Rethink video delivery. Flash redirection can reduce bandwidth consumption and improve the quality of videos over the WAN. Combined with CloudBridge, this can make multiple views of videos almost bandwidth neutral with an excellent user experience.
- Understand the users. Understanding how users will utilize their virtual desktops can be tremendously helpful in planning for bandwidth. For example, to know the average concurrency of users. An office may have 100 potential users, but if only 50 users are connected at any given time, bandwidth for 100 users may not be necessary. Knowing these requirements and finding out the possible issues before starting will help avoid headaches later. For more information read the Citrix Virtual Desktop Handbook.
- Test, test, test. There is no substitute to testing and networks do not always behave as expected. For example, custom applications sometimes drain bandwidth unnecessarily which could be tuned prior to deployment. The effects of latency and packet loss might also be higher than anticipated which could be uncovered and remediated during testing.
- Burst Capacity. Plan for burst bandwidth requirements such as video, printing, and data transfer. Although the average bandwidth may be relatively low, it is important to have adequate capacity to support burst activities to maintain a smooth user experience. In the results above, the simulated T1 network was sufficient to support an overall good user experience.
Taking into consideration everything mentioned so far I present you with a simple use case. Let’s say a branch office has 20 users who access typical office applications and browse the web. How much bandwidth is needed for this branch to support these ICA sessions? Assuming that each user requires 100kbps (rounding up the medium workload average discussed earlier) the total bandwidth required would be 4Mbps. This is the dedicated bandwidth required to support the sessions and does not include activities such as printing or data transfer. As each user interacts with the session, the bandwidth consumption will vary and for much of the time will be close to none as someone writes an email or grabs a coffee. However, when a user opens a new application or browses to another web page, the burst capacity that they need is available in that 4Mbps. With that in mind, the formula below can be used, with caution, as a starting point when planning a WAN deployment.
Bandwidth (kbps) = 200H + 100D + 2000X + Z
H = Number of concurrent users requiring video without flash redirection
D = Number of concurrent users who are not watching video
X = Number of concurrent users who require 3D applications (2000kbps borrowed from other testing)
Z = Additional 1000 to 2000 kbps minimum capacity to support peaks in smaller environments (<10 users)
Note that this formula is intended for XenDesktop 5.6, this does not take into account the new H.264 codec used by XenDesktop 7 nor is flash redirection included in this formula. Better user experience over the WAN can be achieved using the new codec and flash redirection.
In the formula above, “Z” is a parameter required for smaller environments to account for the burst capacity. (Let’s call it burst factor) To illustrate, here is another example. What if a branch only has 5 users who will be watching video occasionally? Using the formula above based solely on the number users, they would require a 1Mbps connection, which I would not recommend for non-redirected video. For this scenario the burst factor would need to be added to meet the burst capacity requirement. This formula will work better for larger WAN deployments as the average over time will be more stable and burst factor becomes redundant. Use it with caution and do not forget to account for bursts and most importantly, to test.
For conditions where total available bandwidth is constrained beyond these recommendation, please review part 2 of this series where we showed that some applications can run smoothly with bandwidth as low as 256kbps using the right policies and optimizations. For more options in constrained networks continue following the rest of the series where I will cover some additional possibilities to help use the network more efficiently.
In part 4, I will discuss XenApp and how it compares to XenDesktop from a bandwidth point of view. I will also point out an interesting use case to consider when delivering to the WAN.
Thanks For Reading,