The Importance Of Correcting Packet Loss In VDI
Posted by
David Greenfield
March 30, 2011
Recently, on the LinkedIN WAN optimization professionals group, I participated in a conversation around whether virtual desktop infrastructure (VDI) is ready for the WAN. Face it, delivering responsive VDI over the WAN is going to be a challenge. One of the interesting points that came up was the importance of correcting for packet loss when considering WAN optimizers.
Riverbed argued heavily that special features aimed at fixing packet loss should not be a significant factor when considering a WAN optimizer. Packet loss is "mostly a technical distraction that sounds scary and is handled by TCP for the vast majority of people the vast majority of the time," says Steve Smoot, Riverbed's VP of technical operations.
At first glance, I dismissed Mr. Smoot's comments as mere vendor positioning. After all, I spent a decade tracking carrier services where countless network engineers had complained to me about the congestion problems on the Net. What's more, Riverbed built its brand on compensating for packet loss (and other networking problems) by aggressively retransmitting TCP. No wonder Mr. Smoot would be opposed to requiring additional packet loss techniques.
The problem, though, is that TCP retransmission won't address the challenges faced by today's real-time applications. Many such applications--VoIP, video and, to some extent, VDI (VMware's, most notably)--use UDP, not TCP. Improving TCP flows on a link will have some impact on other flows, but can't address problems specific to the UDP flows. The point was made in the discussion that today's carrier networks are stable enough to obviate the need for specific packet loss compensation for UDP. Are vendors downplaying the packet loss problem for their own gain, or do they have a legitimate point?
To find out, I went back to my sources at some of the major pharmaceutical and manufacturing firms to hear their experiences on their own global WANs. I also checked the Internet Health Report several times, a pretty good measure of various network statistics over the past 24 hours.
Page: 1 | 2 | 3 | 4 | Next Page »
