Building a transport for desktop and application virtualization is a multi-dimensional problem. Users can access these remote applications and desktops from anywhere:
- From the same site as where the infrastructure is hosted over LAN;
- From a remote branch office over WAN/cloud;
- From their favorite coffee shop over public Wi-Fi; or
- On the move and accessing the remote infrastructure over mobile networks.
Given that end users can be located anywhere, the network conditions at their disposal can also vary—a lot. The bandwidth can vary from few tens of kilo bits-per-second to 100s of megabits-per-second. Latency can vary from sub-millisecond to 100s of milliseconds, and packet loss can vary from near-zero to up to 50%.
In addition, end users could be using any device and access the remote applications and desktops on any platform (such as Windows or Linux). They may be interested in:
- Multimedia workloads like audio/video which are latency sensitive and loss tolerant; and/or
- Interactive workloads like mouse/keyboard movements, which are latency sensitive but loss intolerant; and/or
- Bulk data transfer workloads like drive redirection/USB redirection, which are latency insensitive and loss intolerant.
TCP Is Not the Right Transport
The ubiquitous transport, namely transmission control protocol (TCP), is not a right fit for this multi-dimensional problem due to many reasons. In particular:
- TCP relies on re-transmissions to guarantee reliable delivery of the stream. Identifying the right packets to retransmit takes time and this is not suited for interactive/multimedia workloads especially on challenging networks.
- Middle-boxes like proxies and application gateways transparently terminate TCP and thereby hide the bottleneck bandwidth from the endpoints. This makes estimating the available end-to-end bandwidth difficult.
- TCP also lacks a good packet loss model which makes reacting to losses undetermined.
In addition, TCP cannot be augmented easily to fix the problems. This is primarily because TCP carries the baggage of being standards compliant. Modifying TCP on many platforms is very difficult, as the implementations are baked into the operating system itself.
VMware Blast Extreme Adaptive Transport Is the Answer
All this led us to build VMware Blast Extreme Adaptive Transport. The adaptive transport, which is part of Blast Extreme, is built over UDP. We believe that is the right solution for this multi-dimensional problem. The key differentiators include:
- A unique scheme of unifying data re-transmission with network-aware, forward-error correction (FEC). Unlike other implementations where FEC is integrated as a layer on top of re-transmission mechanism, our solution seamlessly unifies it right into the re-transmission layer. This helps us to proactively re–transmit the right amount of packets without round-trip wait time.
- A novel technique to generate idempotent re-transmitable acknowledgments, which largely helps to reduce or eliminate re-transmission timeouts.
- To cope up high packet loss domains and/or when the application doesn’t have enough data to send, our solution effectively estimates packet loss and drives a unique bandwidth estimating congestion control algorithm. This seeks high throughput with a small queue by probing the bottleneck bandwidth and roundtrip time sequentially.
In addition to the above differentiators at the transport level, our adaptive transport architecture also brings key advantages to the table. Notably:
- It avoids any intermediate proxying of data from VMware Horizon client to remote desktops and applications. This helps estimate the network characteristics precisely and adapt quickly to changing network conditions.
- Introducing a driver that multiplexes/de-multiplexes datagrams to different sessions in constant time without any copying. This helps scale linearly for multi-sessions on RDS environments and improves the consolidation ratio of number of user sessions per RDS host. This also simplifies the firewall configuration and reduces the number of open UDP ports on the RDS desktops to one.
- It is designed as a common middleware across different platforms. This enables us to bring the innovations to all the Horizon clients and Linux VDI at the same time.
No discussion of the transport is complete without discussing the security layer. Blast Extreme Adaptive Transport is secured using an end-to-end SSL/TLS stream. This is not terminated at any intermediate proxies, including the VMware Blast Security Gateway, so the endpoints have full visibility into the bottleneck bandwidth. The Blast Security Gateway authenticates the protocol using per-datagram, hash-based message authentication code (HMAC), the keys for which are learned when the adaptive transport sets up the session.
Blast Extreme Adaptive Transport is enabled by default in VMware Horizon View 7.1 and Horizon Client 4.4. If the clients are connecting from outside the demilitarized zone (DMZ), you would also need to have VMware Unified Access Gateway to take full advantage of the new transport. The adaptive transport will automatically sense the network for UDP availability and will fallback to legacy Blast TCP if UDP is not available (i.e. UDP is administratively blocked). To that end, the default out of the box settings should get you going with our adaptive transport.
Check out Blast Extreme Adaptive Transport in your environment, and share your experiences as we continue enhancing this new transport to power Blast Extreme. If you’re going to VMworld Europe, be sure to sit in on these sessions to learn more:
- Delivering 3D Graphics Desktops and Applications in the Real World with VMware Horizon, Blast Extreme AdaptiveTransport, and NVIDIA GRID [ADV1607BE]
- Deliver Any App, Any Desktop, Anywhere in the World Using VMware Blast Extreme [ADV1609BE]
Because you liked this blog:
