The “heavy side” of thin clients
Posted by Josh on Thu 12 Aug 2010Categories: Cisco , Cisco Routers , Windows - [6] Comments
The company I work for has been implementing thin client technologies based on Citrix and Microsoft Terminal Services for a long time. Today, VMWare’s Virtual Desktop Infrastructure (VDI) is starting to be the hot item. This post addresses the network concerns presented by thin client technologies. My first experience with this issue was presented by a small branch employee playing ‘Wheel of Fortune’ online. The network died every time it was her turn to spin the wheel.
The term “thin client” is misleading in terms of networking. Thin only refers to the hardware requirements for the client. It does not mean the technology is thin on the network. Apparently thin client technologies are great for centralized control, network management, cost savings and other things that I really have no authority to speak on. However, in regards to the network, it only takes one client to destroy a wan link or internet connection.
Update: This post is not intended to guide anyone away from thin client technologies … whether it be server based or virtualized desktops. The intent is to inform individuals of how much traffic can be generated by thin client technologies if mis-used, are poorly designed or simply not understood. The video was not produced by a device with acceleration technologies. It is just simple Microsoft Remote Desktop Protocol.
I will demonstrate how much bandwidth can be consumed by a thin client session.
Do the following:
- Open the ‘Task Manager’ on your PC
- Click on the ‘Networking Tab’
- Click on ‘View > Select Columns’
- Check ‘Bytes Sent/Interval’ and ‘Bytes Received/Interval’
- Click ‘Ok’
- Establish an RDP session with a Microsoft Server/PC on your local area network.
- Open YouTube
- Play a video that is very interactive like a football game.
- Make note of the Bytes Sent and Bytes Received
- Multiply the Bytes Sent and Received by 8 to get bits per second.
- Now you see how easy it is to kill a network with a thin client.
Why does this happen?
Everything happens at the server. The server just sends the screen to the client. Sounds thin enough … but when the screen is trying to keep up with screen changes produced by video, stock tickers, games … bandwidth is consumed. Even a clock updating seconds can generate more traffic than you think.
The next time your internet is slow, check traffic to logmein.com, webex.com or gotomypc.com. If the internal wan is slow and network traffic is heavily tcp port 3389 (rdp) or tcp port 1494 (Citrix) … you might want to check the user’s activities.

August 13th, 2010 at 2:08 pm
Hi Josh,
I have experience with the Citrix style of hosted-application type of setup. I don’t have much experience in the area VDI/thin client other than working with Wyse thin terminals for a POC, but I have been very impressed with its advantages (like centralized mgmt as you said). Thank you for sharing this helpful information, some disadvantages that should definitely be taken into consideration before implementing VDI.
I was actually caught a little by surprise by this info because I didn’t think the performance hit would be so severe thanks to [vendor]‘s acceleration add-ons such as Wyse’s TCX. However, it does make sense to me now, since I realize a hosted application only has to be concerned with that application’s presentation, not the full Windows desktop, etc…
This document by Citrix also mentions network performance as a top 10 mistake, if you’re interested:
http://hqextsrvsft01.citrix.com/article/CTX126190
I feel VDI has a place, but perhaps in specific environments. I have seen some very successful (Wyse) thin-client deployments in medical offices, in which they use only a few EMR-type applications (Windows based) – no video or such. This has enabled them to easily and quickly deploy their EMR system to newly acquired offices.
Thanks again,
Paul Paradiso
@theparadiso on twitter
August 13th, 2010 at 4:20 pm
Paul,
Thank you for your response. This post was not intended to guide anyone away from thin client technologies … whether it be server based or virtualized desktops.
The intent is to inform individuals of how much traffic can be generated by thin client technologies if mis-used, designed poorly or simply not understood.
The video was not produced by a device with acceleration technologies. It is just simple Microsoft Remote Desktop Protocol. Possibly the fattest thin client technology that exists. I don’t know.
The documentation you provided from Citrix indicates there have been significant improvements in technologies. High-def video with only 1.5Mbps without a caching device at the branch … not bad.
Thanks again for sharing your experiences Paul!
Josh
August 13th, 2010 at 6:09 pm
but it has some advantages like
it operate in lower administrative privileges makes it secure and provide stateless environment that help to counter malwares.
August 13th, 2010 at 7:48 pm
Karl,
I agree.
Josh
August 22nd, 2010 at 6:18 am
Josh, we actually looked at implementing such a solution for our remote workforce. Basically using RDP over a Cisco VPN IPSec connection to our HQ for access to some systems and apps (web-based).
The results to the testing phase were not too bad, but we were risking bursting past our data thresholds with the circuit provider. Instead we pushed the webapps (that’s what they’re made for)over the VPN tunnel instead which reduced the throughput drastically – though seems like a no brainer. The drop is obvious though if you look at the difference in how the data is delivered.
Using RDP like you mention is like presenting the whole desktop and everything else on that remote desktop. Pushing the webapp was just pushing data requested by the browser. Great post though!
LBSources..
December 28th, 2010 at 6:20 pm
Josh,
Great write-up. Had a client with a single T1 serving a remote location with 15 users. Whenever they would visit their hosted website that had small youtube videos in the right pane, network T1 would nearly max out causing all other traffic to halt and drop. The problem that I have found with RDP is I could not find any way to apply any type of QoS policy to traffic within that encapsulated RDP traffic. Maybe there is some way on the Terminal server to tag traffic with DSCP so we can put higher priority on real-time traffic they use. Welcome any suggestions.