At the end of my last article on scalability, I mentioned that we’d recently changed our default ICA transport from TCP to something called Enlightened Data Transport, or EDT.
EDT is more closely related to UDP than TCP (and will show up that way on the wire if you look at a trace via Wireshark), but it’s also got some TCP-like elements, so I like to think of it as a smarter, hybrid transport mechanism that is ultimately somewhere in between TCP and UDP. If you’re looking for a good overview of EDT, then I suggest you check out these two great articles by Fernando Klurfan (Part 1) and Georgy Momchilov (Part 2).
The reason I’m so excited about EDT is that it’s something every long-standing Citrix customer can really appreciate. After “How many users can I get on a box?” I have probably been asked this question the second-most in my career: “How can I improve the Citrix user experience on a WAN?” And to be honest, my answer over the last decade+ hasn’t been all that precise or prescriptive. We used to dig into the code and tune ICA network parameters and that was pretty messy. Then we came up with much cleaner solutions in the forms of NetScaler TCP profiles and WAN-friendly policy templates. And these would basically tune some of the same things we had been doing forever to make ICA a little more responsive and interactive. But even after doing some of those things, I still heard customer complaints — things such as “the keyboard still seems sluggish in our offshoring environment,” “it takes forever to print,” or “transferring files or doing anything with peripherals over our WAN link is pretty frustrating.” It all resulted in what seemed like a less-than-stellar Citrix user experience and it manifested itself the most in low bandwidth, high latency network scenarios.
Fast-forward about 20 years into our protocol development and we’ve just debuted a cool new toy called EDT. And now when users complain that there is “high latency” or “the session is slow,” the first thing I ask is if they’ve tried EDT yet, because it can make a huge difference in terms of interactivity and user experience. It really shines when you’re leveraging our printing, CDM and generic USB virtual channels. One of the reasons I wanted to write this article is that it can improve the interactivity of general Thinwire commands by 2-3x, as well! And it works on the LAN just as well as the WAN! So, there is very little reason why every Citrix customer should not be using EDT now. The good news is we’ve just made it our default graphics transport in the latest 7.16 CR. But if you’re using older versions, you’ll still need to seek out the EDT policy and flip it on to take advantage.
Some of the smart folks out there have read about EDT, done their own testing, can’t believe how amazing it’s performing, but they are starting to ask if it’s too good to be true. In other words, what is the impact of EDT when it comes to critical items like single server scalability (SSS) and bandwidth consumption? And that’s really what I’d like to address in this article.
There’s no better way to test something like this out other than using LoginVSI. So we ran a number of tests in a few different lab environments with the latest and greatest version of LoginVSI available. We also included tests with minimal latency to ensure LAN performance is solid and other tests with higher latencies and packet loss (100 ms, 250 ms, 1% loss, etc.). We also used different versions of our code with various Windows platforms since EDT has actually been around for a few releases. We focused more on XenApp versus XenDesktop, as that is what most of our large customers are using in the wild. The results? Extremely impressive stuff. Allow me to summarize the 2 key points related to SSS and bandwidth:
- The impact of EDT on SSS is negligible compared to TCP. One test found exactly the same SSS or VSImax score but overall EDT was within 2% of TCP in terms of SSS. Here is a summary of the test scenarios and results (the numbers are VSImax scores):
Test Scenario (Version, Platform) Thinwire-over-TCP Thinwire-over-EDT XenApp 7.12 (2016) 79 76 XenDesktop 7.14.0 (Win7 x64) 45 45 XenApp 7.14.1 (2012 R2) 81 80 XenApp 7.15 CU1 (2012 R2) 102 100 - The impact of EDT resulted in about 15% more bandwidth consumption on average compared to TCP. It was more negligible on the LAN (less than 10%) but more “hungry” on the WAN (sometimes pushing 50%+ depending on the virtual channel).
One interesting nugget related to bandwidth: I had a colleague, Brendan Lin, test EDT with the latest Receiver and XA 7.15 CU1 on 2012 R2. The average bandwidth of the Task Worker workload using TCP was just over 52 kbps. The average bandwidth with EDT? Just under 53 kbps. Basically the same and we were even amazed, so we double-checked our work! Sure, that test was on the LAN with minimal latency, but it demonstrates that EDT is not just for WAN use cases — it works fantastic on the LAN (with essentially no overhead) but it really starts to shine in WAN scenarios with high latency and/or packet loss.
And what about those WAN results? We put the same Task Worker workload on XA 7.15 CU1 thru a WAN emulator with 250 ms of latency and 1% packet loss. The average bandwidth using TCP was 58.3 kbps and the average bandwidth with EDT was 69.6 kbps to be exact. So, that’s only a 16% increase in bandwidth and you’re getting a much better user experience! It’s interesting to note that this particular LoginVSI workload is really “light” (by design, I might add, since it’s supposed to mimic a typical XenApp-based task worker) on the specific virtual channels that really pushes EDT to its limits. In other words, if we fired up a heavier XenDesktop-based workload with file transfers, printing or other peripheral usage, you’ll see EDT saturate the link much more compared to TCP. And that’s where you might see 50%+ more bandwidth usage.
Of course, it’s hard to provide any numbers like this without a general disclaimer, but you know the drill by now: your mileage is going to vary based on a number of different factors and these numbers and statements I provided above shouldn’t be trusted implicitly. I encourage everyone to fire up LoginVSI or just play around with EDT in your lab to see how it performs. But if you’re wondering how it impacts scalability or how much extra bandwidth it might require, then this is a great starting point.
One question I’ve already been getting asked, as I’ve started to share these results with people: “If it requires additional bandwidth, then how is SSS not impacted? Shouldn’t it be reduced by 15%?” And the answer is that it’s not impacted because CPU (not bandwidth) is still our limiting factor in 99.9% of XenApp and XenDesktop deployments. And since we’re only changing the transport and EDT requires a negligible amount of CPU compared to TCP, SSS remains the same and is not impacted substantially.
To wrap it up, these results are why I believe everyone should start implementing or at least experimenting with EDT in their Citrix environments. It provides a better overall user experience on both the LAN and WAN. It now works with NetScaler via DTLS and Session Reliability is fully supported. And it’s basically FREE since it costs you nothing in terms of SSS and only requires a little extra bandwidth. And if you think about the 30-60% of bandwidth we saved you already by simply going to the 7.13+ release, then flipping on EDT for a better UX is almost a no-brainer.
Hope this guidance helps. And special thanks once again to Brendan Lin for helping me conduct some of these fun tests.
Cheers, Nick
Nick Rintalan, Principal Architect – Citrix Consulting Services (CCS)
