Network Planning for Client Access
Several factors related to the infrastructure and the end-user affect the bandwidth use in a VDI deployment:
- The protocol used for online VDI connections and the specific configuration settings for that protocol.
- The end-user scenarios that are representative of the real desktop environment.
- Percentage of users that run on Cloud Branch servers.
- The number of concurrent users.
VERDE server capacity must be planned for peak connected virtual desktop usage. A virtual desktop running on the server with no users connected to it does not typically consume any bandwidth for the VDI session itself. In addition, RDP is primarily an on-demand protocol – when there are no mouse selects, mouse movements, or keyboard activity, no bandwidth is consumed.
It is tempting to measure average bandwidth usage for a single connected user and simply multiply this by the number of peak connected users to estimate the total bandwidth requirement. However, this does not take into account that, at any given instant in time, not all connected users will have activity that directly contributes to bandwidth. There is a real-time nature to bandwidth usage that needs to be taken into account. There may be ten connected users but only two of them are using bandwidth at any given instant in time.
This leads to other anomalies as well. For example, testing with a single user doesn't provide a good indication of the average per-session bandwidth, especially when used for total bandwidth calculations. A single user may have a good user experience at 128 kbps, but 25 users could have the same experience with an average per session bandwidth of 30 kbps. One suggested approach to deal with the situation is to use an effective concurrency when estimating the total bandwidth. For example: Total Bandwidth (B) = b * (c/100%) * n
where
b = per session bandwidth usage | c = concurrency factor | n = number of connected users. |
For 150 connected users, 50% concurrency, and 64 kbps per-session bandwidth, this would yield about 4.8 Mb/s of total bandwidth required. Concurrency is a bit difficult to estimate and there is very little data available but 50% seems to be a very conservative number.
A second approach is to effectively account for the concurrency in the per-session number. From industry data, per session value of 30 kbps for RDP has been used for planning purposes. Given this, the same 150 users would yield a total bandwidth of 4.5 Mbps. Total Bandwidth (B) = b * n
where
b = average per-session bandwidth usage | n = number of connected users |
The per-session remote display and device performance depend heavily on the amount of total network bandwidth available. Generally speaking, the higher the switched bandwidth, the faster and more responsive the end-user sessions will be. In cases where not all users are connected at the same time, the total network bandwidth might be lower without sacrificing session responsiveness, because only a portion of users will be transmitting at any given time.
From the per-user perspective, the following table illustrates the minimum and recommended bandwidth (shown in kbps or Mbps) and latency (shown in milliseconds) figures for various usage profiles.
Virtual Desktop Usage | Spice Access | RDP Access | UXP Access |
---|---|---|---|
Casual/Line work |
Minimum:
Recommended:
|
Minimum:
Recommended:
|
Minimum:
Recommended:
|
Office/Productivity |
Minimum:
Recommended:
|
Minimum:
Recommended:
|
Minimum:
Recommended:
|
Multimedia Playback |
Minimum:
Recommended:
|
Not Recommended |
Minimum:
Recommended:
|
Actual bandwidth requirements will vary by exact usage profile, subjective user expectation, and effective network topology. In all cases, the higher the available bandwidth per user, the better the user experience will be. These are per-session bandwidth numbers only. When estimating total bandwidth for a large number of users, a concurrency factor should be used along with this per-session value, as indicated above. Several protocol-specific parameters have a significant effect on bandwidth. For RDP, the significant parameters are:
End-user scenarios need to be representative of real-world workloads. Ultimately, setting up a pilot environment with real users and measuring bandwidth usage is the most accurate way to estimate the overall bandwidth requirement.
|
|
|
|
|
|
|