Workspot desktops show an optional “Connection Quality” icon in their top-of-screen toolbar, which is based on estimated bandwidth and round-trip time (RTT). This article describes how what these metrics are measured and what they do (and don’t) mean.
Quick Summary:
If the available bandwidth is > 3.5 Mbps and the latency is < 80ms, all is well, even if the numbers bounce around within that range.
The “Connection” Icon
Mousing over the “Connection” icon reveals a report that lists the most recent available bandwidth and RTT estimates. These same values are reported to Workspot Watch and Workspot Trends.
The “Connection” Icon uses the following color coding:
Green: Available bandwidth is over TBD1 and RTT is less than TBD2.
Yellow: Available bandwidth is between TBD3 and TBD4. RTT is between TBD5 and TBD6.
Red: Available bandwidth is below TBD4 or RTT is above TBD6.
RTT Estimation
The estimation of network round-trip time (RTT) is more useful and accurate than bandwidth estimation. The method used in RDP is covered in the in Section 2.2.14 of the RDP specification, but for practical purposes it is equivalent to other methods.
Round-trip time is generally dominated by speed-of-light propagation delays along the link and the queuing delay at the bottleneck gateway.
The measurement involves a single small request packet and a single small response packet, so serialization delays are minimal.
If either the request packet or the response packet is dropped, their retransmission results in a value that’s several times larger than the true RTT. Usable links have packet losses of a few percent or less, so this retransmissions are infrequent.
The Client reports the latest RTT measurement only: it is not averaged or filtered in any way.
Interpreting RTT Values
Round-trip times increase with distance due to speed-of-light propagation delays:
Between California and New York: 60 ms.
Between California and India: 240 ms.
Users tend to notice longer delays but not shorter ones:
RTT | Effect on Users |
|---|---|
< 60-80 ms | Feels local |
80-150 ms | Feels sluggish, especially to fast typists, but usable. |
150-200 ms | Interactive tasks become error-prone. |
>200 ms | Poor productivity. |
Bandwidth Estimation
The bandwidth estimator works in the desktop-to-Client direction only. It estimates the available bandwidth (that is, the otherwise unused link bandwidth) at the network chokepoint between the desktop and the Client.
The bandwidth estimator is a standard RDP feature, described in Section 2.2.14 of the RDP specification. It estimates the instantaneous “available bandwidth” of the path in the desktop-to-Client direction by instructing the RDP client to measure the interval between the arrival of the command the the last of a series of test packets. The aggregate size of these packets divided by the interval gives the measured bandwidth.
The bandwidth estimator is run at times chosen by the RDP engine, so the update period is variable.
The estimate applies only to the available bandwidth of a single TCP connection over the path between the desktop and the Client.
It does not measure link bandwidth but available bandwidth; that is, the bandwidth that is left unused by other senders.
The estimate gives no insight into the location or the cause of unexpectedly poor results.
The Client reports the latest measurement only: it is not averaged or filtered in any way.
How Much Bandwidth Does the User Need?
The RDP protocol uses bandwidth extremely efficiently. Microsoft’s Remote Desktop Protocol (RDP) bandwidth requirements examples give the following usage values:
Application | Bandwidth Used |
|---|---|
Word and Excel | 0.5 Mbps or less |
Web Browsing | 1.0 Mbps or less |
PowerPoint | 1.6-1.8 Mbps |
Full-screen video | 2.5-3.5 Mbps |
These assume the use of the recommended H.264/AVC 444 graphics mode.)
Third-Party Bandwidth Tests
Other bandwidth estimators, such as Ookla’s Speedtest, use a much longer measurement period and multiple connections to flood the link and force other traffic to back off. This results in higher reported bandwidths than the RDP estimator, whose purpose is to measure conditions as they actually are at the start of the test. The two are not directly comparable. If the speed test has a single-connection mode, the results will be more similar.
Troubleshooting Slowness Issues
Since the RDP protocol used by Workspot desktops and Clients not only uses link bandwidth sparingly, it adjusts its usage dynamically, the user’s Workspot connection is rarely overloading the link on its own. The culprit lies elsewhere.
Troubleshooting starts by noting whether the symptoms affect individual users or all users of a given desktop pool or datacenter.
The common culprits are listed by location below, and roughly in order:
Client-Side Issues
Client-side issues typically affect individual end-users or the end-users at a single location, while server-side issues affect entire desktop pools:
Weak Wi-Fi signal or Wi-Fi interference (especially on 2.4 GHz).
This is invariably on the Client side of the link.
The usual corrective actions apply, especially using a wired connection when possible.
Speed-of-light delays over transcontinental or intercontinental links. No fix.
Bulk traffic on the Client side (streaming, downloads) causing queuing and its associated latency.
Many consumer-grade routers have excessively deep queues (“bufferbloat”) that can add substantial delays.
ISP congestion or bad last-mile data delivery in general.
Server-Side and Network Configuration Issues
These issues will typically affect all the users whose connections follow the same path:
VPN or proxy/SWG overhead — delays from extra hops, tunneling, and serialization.
Proxy or gateway in wrong place (proxies and gateways should be in the same datacenter as the Workspot pools to minimize total path distance).
MTU/fragmentation or security software (AV, firewalls inspecting RDP traffic).
Server resource exhaustion (high CPU, disk I/O, memory pressure).
This will affect individual desktops or application servers, not entire pools.
Other Issues
These can happen anywhere:
Defective network cables.
Misconfigured hardware (duplex mismatch, old NIC drivers, QoS gone wrong).