Microsoft had released the public Preview of RDP shortpath for Public Networks.
What does this mean to Administrators?.
RDP shortpath allows the Azure WVD(AVD) to work on UDP rather than TCP. The AVD will establish a direct UDP connection between the RD Client(end user client) and the Session Host(AVD desktop) rather than the traditional reverse connect transport path.
What is the benefit of using RDP Short path?.
- This is a direct connectivity between client and session host which reduces the dependency and overhead of traversing via the AVD Session gateway. This improves the connection reliability and Round trip time which inturn improves the user experience especially on a high latency internet connection.
- RDP Short path transport is based on the Universal Rate Control Protocol (URCP). URCP enhances UDP with active monitoring of the network conditions and provides fair and full link utilization. URCP operates at low delay and loss levels as needed by Remote Desktop. URCP achieves the best performance by dynamically learning network parameters and providing protocol with a rate control mechanism.
AVD Connection Flow before enabling short path
In a normal AVD traffic flow, the Client signals will be accepted by RD Gateway and Reach the session host. RD Gateway will act as a reverse proxy server between the AVD Session Host(AVD desktop) and End user Client(RD Client). The below diagram illustrates the standard reverse connect transport traffic.
Normal AVD Connection traffic from end user machine
The below diagram shows the TCP connection established between Session host and RD Client(end user desktop).
How RDP Shortpath works?
RDP Shortpath uses a standardized set of methods for traversal of NAT gateways. As a result, user sessions directly establish a UDP flow between the client and the session host. More specifically, RDP Shortpath uses STUN protocol to discover the external IP address of the NAT router. There are four primary components used to establish the RDP Shortpath data flow:
- Remote Desktop Client
- Session Host
- Azure Virtual Desktop Gateway
- Azure Virtual Desktop STUN Server
In Azure Virtual Desktop, every RDP connection starts with establishing the reverse connect transport over the Azure Virtual Desktop Gateway. After the user authentication, the client and session host establish the initial RDP transport, and the client and session host start exchanging their capabilities. If RDP Shortpath for public networks is enabled on the session host, then the session host initiates a process called Candidate Gathering.
- At this stage, the session host enumerates all network interfaces assigned to a VM, including virtual interfaces like VPN and Teredo.
- Remote Desktop Service allocates UDP socket on each interface and stores the IP:Port pair in the candidate table as a local candidate.
- Remote Desktop Service uses each UDP socket allocated in the previous step to try reaching the Azure Virtual Desktop STUN Server on the public Internet. Communication is done by sending a small UDP packet to port 3478
- If the packet reaches the STUN server, the STUN server responds with the session host public IP and listener port. This information is stored in the candidate table as a reflexive candidate.
After the session host gathers all candidates, the session host uses the established reverse connect transport to pass the candidate list to the client. When the client receives the list of candidates from the server, the client performs the candidate gathering on its side. Then the client sends its candidate list to the session host. After the session host and client exchange their candidate lists, both parties attempt to connect with each other using all the gathered candidates. This connection attempt is simultaneous on both sides. Many of the NAT gateways are configured to allow the incoming traffic to the socket as soon as the outbound data transfer initializes it. This behavior of NAT gateways is the reason the simultaneous connection is essential. After the initial packet exchange, the client and session host may establish one or many data flows. After that, Remote Desktop Protocol chooses the fastest network path. Client then establishes a secure TLS connection with the session host and initiates the RDP Shortpath transport. After RDP establishes the Shortpath, all Dynamic Virtual Channels (DVCs), including remote graphics, input, and device redirection move to the new transport.
Enabling RDP Shortpath on SessionHosts
To enable RDP Shortpath, a DWORD named “ICEControl” need to be created.
|DWORD:- ICEControl |
Key:- “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations”
The below diagram shows the registry configuration to enable the RDP shortpath.
Once RDP Shortpath is enabled, the AVD connection will be established in UDP Protocol.
You can observe that the available bandwidth increases compare to the TCP traffic and the connection quality is showing as good.
I am testing this feature and will update if any issues observed.
Credits:- Microsoft documentation.
One thought on “Configuring RDPShort Path for AVD Public Networks(Preview)”