The Riverbed Blog (testing)

A blog in search of a tagline

Accelerate your Voice-over-IP?

Posted by riverbedtest on June 17, 2008

It’s widely acknowledged that Riverbed provides the best performance over the WAN for key applications in mainstream use, such as CIFS, Exchange, NFS, and various web applications.  Our competitors have a tough time dealing with that, so rather than compete head-on against Riverbed, some of them attempt to distinguish themselves in other areas such VoIP, Citrix, and other real-time applications  For example, the website of one Riverbed competitor claims "Up to 1,000% Citrix ICA acceleration over the WAN, with a consistent 300%."  The same vendor makes similar claims for accelerating VoIP and RDP traffic.  When I see these claims, I’m puzzled at their choice of words.  By "acceleration", I would hope they are not claiming the ability to allow the VoIP conversationalists to talk faster.  I would also reason that they are not claiming the ability to allow real-time data to travel faster than the speed of light.  So what does it mean to achieve "1000% acceleration" of VoIP and other real-time traffic types?

Well, perhaps our competitors are claiming the ability to compress the VoIP and Citrix traffic.  That might be a worthy endeavour, until one considers that VoIP, Citrix, and most other real-time applications consume relatively little bandwidth–each session consumes perhaps a few kbps or so.  So in most cases we’re talking about compressing a small amount of data into an even smaller amount of data.  Is this worthwhile?  Probably not, unless we’re talking about a large number of sessions.  Compression and data deduplication is definitely worthwhile for CIFS, FTP, and other bulky data transfers.  But when these technologies are applied to a real-time application the potential bandwidth savings are very meager and probably not worthwhile.

But there’s another problem–RDP, Citrix ICA, VoIP, and most other real-time traffic types are already compressed and/or encrypted.  In the case of VoIP, the most commonly-used voice codec (G.729) is extremely efficient, having been developed after many generations of earlier codecs.  Data processed by this codec is already highly-compressed and any further compression is not likely to be possible.  In the case of Citrix ICA traffic is efficiently encoded and compressed in this bulletin published by Citrix.  According to this document, the Citrix compression level can be reduced, but it cannot be disabled entirely.

Despite the above facts, some Riverbed competitors continue to insist on their ability to deliver compression for VoIP and Citrix through their solution.  But if you’ll notice, they never talk about the effect of compression on the performance and responsiveness of the real-time application.  Even if additional compression were possible, compression algorithm processing will certainly add new latency and jitter, especially compared the original case with no external compression.  We all know how the latency and jitter negatively affect responsiveness and performance of real-time applications; gaining compression at the added cost of new latency and jitter is rarely a favorable tradeoff.

Okay, so if the packet payloads are compressed and encoded, leaving very little to be gained, then perhaps we should look at header compression. Instead of sending large numbers of small packets all with the same header information, let’s just gather up their small-sized packet payloads and send all of their data with one larger packet, using one shared header.  But here, the problem is that by coalescing the small packets, the real-time delivery of each individual packet has been disrupted.  I am dismayed that some vendors would shamelessly propose to deliberately delay packets of a real-time application so that they can be grouped and sent together with other later-arriving packets.  This process deliberately adds jitter and latency, which we all know affects the real-time responsiveness and performance of VoIP or thin client applications.

There’s no such thing as a free lunch.  If something sounds too good to be true, then it pays to be cautious and critical.  Any solution that promises worthwhile compression gains probably carries with it the critical drawback of adding the jitter and latency that compromises the application.  When it comes to real-time applications such as VoIP, RDP, and Citrix ICA, the end-user experience should be preserved as much as possible.  While it is possible to measure compression gains by counting bytes with a network analyzer, it’s much more difficult to quantitatively measure the degradation in the end-user experience that might result.  Vendors that promise the former without addressing the latter should be viewed with a critical eye.

Real-time traffic such as VoIP, RDP, and Citrix ICA all require special consideration and must be handled differently by the WAN infrastructure.  WAN optimization approaches that are effective for bulk TCP traffic such as CIFS, FTP, and SnapMirror may not be appropriate for these real-time applications.  Certainly, addressing QoS and network congestion issues can help.  However, additional compression benefits, if they are possible at all, will only come at the price of compromising the end-user’s real-time experience.

Advertisements

19 Responses to “Accelerate your Voice-over-IP?”

  1. http://awards.techworld.com/winners2008.asp
    Josh,
    I believe you are mistaken about what at least Expand Networks does for real time applications such as Citrix and RDP. I’ve checked our site and we do say we improve Citrix and RDP traffic. I am not sure where you get the 1000% VOIP even from the SP site.
    I do know that Expand won the TechWorld 2008 award for best Application Acceleration Product of the Year over Riverbed and Silverpeak (see link above.)
    And here I have a link to a client we helped with RDP reported by Byte and Switch — http://www.byteandswitch.com/document.asp?doc_id=156521
    And on the Expand Website
    http://www.expand.com/News-Events/Release.aspx?pressID=8fc71037-4651-491b-9579-68f2d7f6420d
    I do agree with Josh that if anyone is facing challenges with their RDP/Citrix or want to ensure that their WAN Optimization vendor won’t cause problems for their VOIP, they should be skeptical and insist upon a POC over a real link and not just lab trials. Your data is too important to accept as gospel what vendors say about their competition.
    Regards,
    Stewart http://www.expand.com

  2. Josh Tseng said

    Hi Steward,
    Yes, indeed Expand does make claims to “accelerate” VoIP traffic. Here’s an excerpt from one of the marketing brochures posted on your website:
    http://www.expand.com/Industries/Case-Studies/Texas_Instruments.pdf
    “After careful evaluation, TI selected Expand Networks’ Accelerators because they were the most effective and expedient solution to accelerate the VoIP
    applications within their network.”
    In any case Stewart, I’m glad you responded to my blog, because I’ve always been wanting to ask someone from Expand what it means to “accelerate” a real-time application, whether it be Citrix ICA, RDP, or VoIP.
    What precisely does Expand mean when its website claims to achieve “up to 1000% Citrix ICA acceleration over the WAN?” Does it mean Expand allows end-users to type 1000% faster? Or does it mean the Expand boxes are able to anticipate the end-user’s mouse-movements and keyboard strokes and deliver the real-time data before the WAN can? In the case of VoIP, does your ability to “accelerate” the voice traffic mean you can make the persons talk faster, and perhaps make them sound like the Chip & Dale?
    Of course, I’m just kidding, but you get the point. My original blog was about the poor choice of words that Riverbed’s competitors (including Expand) use in their [overly] aggressive marketing campaigns.
    Josh Tseng

  3. Stewart at Expand said

    Josh,
    Glad you were just kidding. Otherwise I would have thought you were serious. I mean, Citrix and RDP are both part of the number of applications that — I think there are 81 of them, right? — for your version 5 that you fail to optimize as well as all UDP traffic.
    Is this why you are slamming others like Expand because you do nothing for Citrix, RDP, and VOIP traffic — for example breaking VOIP sessions when clients download large files on their network at the same time?
    It is sloppy attempts at FUD like the above that educated consumers easily recognize for what it is — a clumsy grab at mindshare. I know you are still a young company but surely you recognize that spouting words in place of functionality doesn’t work in the long run.
    And since we are being all friendly — are you “widely acknowledged” as the best everywhere but EMEA — that pesky TechWorld 2008 award that your team lost this year to Expand? (Viewers see my previous post) Or are you conceding the point?
    You have made great accomplishments, no doubt, but don’t tarnish your strengths by trying to make them more than they are — or try to sling mud on others just because they offer solid functionality that your solution lacks.
    Best Regards,
    Stewart
    For those following this blog — give Expand a call. I am unlikely to convert Josh to Expand, but I should be able to make some of your network problems go away.

  4. Art Vandalay said

    Stewart,
    Let’s give Riverbed credit where credit is due, they are a tremendous “point solution”, if all you have is CIFS traffic on your network. Unfortunatley, in this day and age, CIFS is not the only thing running on networks. So, if you wish to address not only CIFS traffic, but anything at the ip level, you may want to call Expand Networks; in a uniformed platform they offer QoS, Compression, Caching / CIFS acceleration, Management and Visibility, and application acceleration. Oh yeah, they also have the ability to join the MSFT domain (it is a Linux device via SAMBA), and support SMB packet- signing, act as a print server, DHCP Server, and provide DNS caching.
    Stewart, I bet you have many RDP and Citrix customers, and as a matter of fact, I recently saw an RDP customer press release the other day on your website. Would you please give me a call, as I see Expand to be the most holistic offering on the market.
    Art Vandalay
    CIO, Vandalay Industries

  5. Josh Tseng said

    Hi Stewart,
    No need to get testy here…I’m not slamming Expand’s or anyone else’s product. Rather, all I did was ask you a very simple question…what does Expand mean when they claim to be able to “accelerate” real-time applications such as ICA and VoIP. And I’m still waiting for your answer to my question.
    Could Expand mean they can apply QoS to the real-time traffic to “accelerate” it? Well, Riverbed and just about every other WAN optimization product can do that too, so I fail to see why Expand’s so special in that regard.
    Do you mean that Expand can compress Citrix ICA and VoIP? Well, I don’t think that’s possible on a consistent basis, but don’t take my word for it–take a look at the Citrix document I referenced in my original blog to see what Citrix themselves say about that.
    Riverbed has thousands of customers using Citrix ICA, RDP, and VoIP. And most of them are getting better performance for these real-time apps due to Riverbed’s ability to eliminate 70-90% of the TCP-based traffic that would have been congesting the WAN. So I would disagree with your statement that Riverbed doesn’t provide benefits for VoIP, ICA, and RDP. It’s just that the “wow” factor for the other applications is usually so great that it overshadows the incremental benefits that Riverbed provides for real-time applications.
    As far as breaking VoIP sessions, I think you must have mistaken Riverbed for another vendor. You see, unlike Expand and most other WAN optimization vendors, Riverbed uses RFC 2581-compliant TCP, unless you change the default settings. We are no more likely to break a VoIP session than an FTP session initiated from a Windows or Unix server, and I think our thousands of customers with VoIP in their networks will back that up.
    And lastly, congratulations to you for winning the Techweb 2008 award. It must be sweet for Expand to finally win an award. Riverbed has won so many awards over the years that I don’t think too much of them anymore…forgive me if I was remiss for not congratulating you earlier.
    Josh

  6. Josh Tseng said

    Hi “Art”,
    You must watch Seinfeld. For those following this discussion who don’t watch Seinfeld, Art Vandalay is a fake name George made up to represent a fake business man (and Elieen’s boyfriend). The episode was actually on last night. Anyways, I would hope that not all of Expand customers are fictional 🙂
    I believe the 4000+ existing Riverbed customers would strongly disagree with your comment that Riverbed is a “point solution.” Some of the largest and most complex networks in the world have Riverbed deployed in them, and many of these customers are using Riverbed to accelerate hundreds of different applications.
    Unlike Expand and other WAN optimization vendors, Riverbed also accelerates Exchange (MAPI, MAPI2003, and MAPI2007), SSL, HTTP, MS-SQL, and Oracle 11i, all in addition to CIFS. In addition, Riverbed performs generic TCP compression and data reduction for all TCP applications, and this provides acceleration for the numerous other applications that don’t exhibit chatty protocol behavior.
    Josh

  7. Art Vandalay said

    Please refer to page 226 of the RVBD Steelhead Manaul it basically states that “ICA traffic is by-passed” Go ahead and look it up….RVBD does nothing for ICA or RDP…or any other type of interactive traffic, such as Telnet, or even UDP traffic for that matter.
    -Art Vandalay

  8. Josh Tseng said

    Hi Art,
    I appreciate that you study Riverbed’s manuals. By default, Riverbed passes-through ICA traffic. We do that because we believe we can benefit all network traffic, including ICA, if we were to focus on optimizing the traffic that represents 80-95% of all IP traffic by byte-volume in most networks. And that traffic is your CIFS, MAPI, FTP, HTTP, SSL, etc… We have thousands of customers who agree with me, that Citrix ICA, RDP, and VoIP all perform better because of Riverbed in their network.
    Furthermore, we have found that using Steelhead to compress ICA can lead to as much as 40% data reduction in some corner cases. I have real test data I can show you. However, unlike Expand and our other competitors, we don’t incorporate results from corner cases into glossy marketing brochures in a desperate attempt to sell them to customers.
    Josh

  9. Darren said

    We’re an Expand customer. Overall, it’s a ‘good’ if not great product.
    We use lots of Citrix applications on our WANs. I can say that in our environment Expand cannot compression Citrix (Metaframe for Unix) traffic.
    In fact, Citrix native compression is massively better than Expand’s.
    I do have a call open with Expand about this so it’s currently a hot topic for me thus the post.
    When Expand engineering/R&D reach a conclusion I’ll update the blog with it.
    It could well be that our environment is unusual, though at the moment, Citrix’s documen sounds remarkably accurate of our findings.

  10. Darren said

    …that’ll teach me to not proof read my comments before posting. He’s what I meant to post……
    We’re an Expand customer. Overall, having chosen, deployed and lived with the product (on 14 global sites) for about 2 years.
    We use the product for QoS, TCP acceleration, compression, WAFS and (to get this post on topic) Citrix. We use Metaframe 4.0 for Unix which obviously uses the same protocol as the more common Windows variety.
    I can say that in our environment Expand accelerators cannot compress Citrix traffic as effectively as the native Citrix compression algorithm.
    I do have a call open with Expand about this so it’s currently a hot topic for me, though admittedly I may be being a bit premature here as I haven’t had Expand’s R&D team reach a conclusion yet (though 1-3rd line support couldn’t help).
    It could well be that our environment is unusual, though at the moment, Citrix’s document describes a situation that is remarkably similar to what we’re seeing.
    Citrix’s document proclaiming there are no benefits to be have is carefully worded; it correctly states that you can disable Citrix compression (contrary to what was said in this blog), what is more difficult is disabling encryption as even their basic encryption scheme ‘hashes’ the data making compression difficult. Their document does say that you are no able to disable the hashing feature using the standard admin interface – the implication being it may be possible using another tool.
    So, in conclusion, ‘out of the box’ Expand doesn’t massively save bandwidth for Citrix traffic in our ‘real world’ environment. It does help with packet aggregation (but that’s mainly from client to server and is therefore much less traffic). The blog mentioned artificially adding delay. The aggregation settings are very customisable, and therefore can be tuned to eliminate any noticeable delay in the client while still getting good bandwidth savings.
    I’ll post again when I’ve heard from Expand and hopefully achieved some bandwidth savings for Citrix using their product. Hopefully, the answer will add weight to one argument or the other and help potential customers get a view of whether Citrix compression is a realistic goal for a WAN acceleration solution or not.
    Darren (darrenjsykes@hotmail.com)

  11. Josh Tseng said

    Hi Darren,
    Thanks for your post. I would be very interested in your update on whether Expand is able to compress your Citrix ICA, without impacting the end-user’s experience.
    There are a small number of Riverbed customers who report corner cases where their Steelhead devices are able to provide as much as 40% data reduction for Citrix ICA. Unfortunately, these are corner cases such as viewing video-on-demand through the Citrix thin client platform, where the same bytes (videos) are being repeatedly played. Other corner cases may involve scripted operations that are repeated, again yielding the same byte-patterns being sent by ICA. I have spoken with a former employee of one of our competitors that these are the types of tests that are used to support this vendor’s claims of being able to compress Citrix ICA. While the results might be real, they don’t represent typical Citrix ICA use cases.
    As far as packet aggregation (i.e., header compression), I’m still having difficulty understanding the wisdom of your Expand devices aggregate small ICA packets into larger packets. My question is, if for a given ICA session larger packets are a more efficient for delivery over the WAN, then why didn’t the origial Citrix server send out the ICA data in larger packets in the first place?
    Thanks,
    Josh Tseng

  12. Darren said

    Josh,
    That was quick!
    Citrix frequently sends small packets (5 bytes of payload is not uncommon from client to server in our environment).
    To answer your question about why Citrix itself doesn’t just send larger packets in the first place, I believe it’s because it has to treat each connection individually.
    i.e. you could have 100 clients all being sent a small packet at the same time.
    The accelerator will know that each of those packets are to pass over a WAN and to the same remote accelerator. In that case, it makes sense to aggregate the packets for transmission over the WAN.
    For small packets all destined for the same client – maybe the ICA hasn’t been optimised as much as it could have (unlikely given it’s age, I know).
    In our environment Citrix sends up to 12MB/second (Bytes) to a single client – almost 25MB uncompressed.
    With Citrix compression disabled, I get 20-35% compression using Expand’s compression algorithm.
    I also have a support case open with Citrix to determine whether it is possible to disable encryption entirely (packet traces show it currently is not, despite my best efforts to do so).
    I believe I’ll need that to give the compression engine a chance of doing a reasonable job.

  13. Josh Tseng said

    Darren,
    Yes, agreed that packet aggregation can yield compression results given the right circumstances. I think your example of a small packet being sent to 100 users at the same destination, at the exact same moment, would be the best opportunity for it. But of course, if this is happening consistently all the time, wouldn’t that mean there are thousands of users at that site? In that case, just buy more bandwidth, since this affects so many people.
    Anyhow, I’m still doubtful that packet aggregation can be done without impacting the end-user’s real-time transactional application. When you aggregate small packets, won’t information concerning the time dimension be lost? Specifically, the time spacing between small packets has been removed and that information cannot be recovered. The end-result can make mouse movements more jerky and keystroke responses less consistent. Perhaps if you type without looking at the screen it wouldn’t matter, but for many people it would.
    There’s a reason the Citrix server wants to send out packets containing 5 bytes of data. And that is because it wants the thin client to do something right away. Now when you have your Expand device grab that small packet, hold on to it, then aggregate it with the next packet to show up, I don’t see how impacts can be avoided.
    Let us know if you do find a way to disable encryption entirely for Citrix. My sources indicate it’s not possible, but that could be old information.
    Josh

  14. Darren said

    I see your point, though can only really speak from experience of our application and users.
    With compression enabled within Citrix, I see an additional 30% reduction in client to server traffic and about 3-4% reduction in server to client.
    As most traffic is from server to client, that obviously doesn’t make a massive dent on the network utilisation graph. However, in a different environment (i.e. word processing where traffic is balanced both ways) it may be more useful.
    I have very ‘demanding’ users who use a CAD application all day over the WAN; the users issue a command and lost of high resolution, high colour graphics is drawn – so it’s all server to client traffic.
    The aggregation feature is being used and the users cannot see the difference; there is no noticable lag.
    This may be because the aggregation timeout is so low not to make a difference. i.e. if the lag on the line is 50ms and aggregation adds 20ms (plucking figures out of the air) then could a user really notice the 20ms delay in moving the cursor/typing a character?
    Citrix themselves claim ICA can be used on high latency satellite links (i.e. 10x the latency of our environment). With technology like speedscreen (like incidentally cannot be used on the Unix version of their product), the tolerable latency increases further.
    If an acceleration was adding seconds of delay I would fully agree with you, but from what I’ve seen that’s not the case and therefore it’s a decent approach.
    However, in our environment, server to client traffic (which frankly is what we need to reduce to see a benefit) almost always uses 1500 byte packets rendering CAD images so aggregation is never used anyway.
    The only way using an Expand box would result in more users/quicker responses in our environment than a competitor (i.e. a device capable of TCP acceleration) is to get better compression than their competitor and Citrix themselves do, so that’s what I’m aiming for.
    Without that, the other benefits (such as aggregation) are as good as useless.
    From what I’ve read, Riverbed pass the Citrix traffic without attempting compression. Therefore, I’d conclude that if the Expand boxes can better the Citrix native compression, Expand boxes will perform better than a Riverbed devices in our Citrix environment.

  15. Josh Tseng said

    Hi Darren,
    The problems you are currently facing are very similar to those of hundreds of Riverbed customers who have since switched from using a thin client/Citrix ICA solution to a thick client approach for their CAD applications. I would strongly suggest you bring in Riverbed for a test drive. Architecture and engineering customers using CAD was where Riverbed made the first major impact when we introduced the Steelhead solution some 4+ years ago. Not only will your users get better performance and enhanced productivity from this approach, but you will free yourselves from those expensive annual Citrix licensing fees. We have hundreds of CAD customers who swear by Riverbed, and we can allow you to talk to some of them.
    If your users print documents, then they’re probably complaining about print performance for those documents that they’re working on through Citrix. A TCP-based data reduction solution such as Riverbed will help far more than Expand’s memory-only-based packet compression.
    It seems you are using packet aggregation not necessarily because you are seeing benefits, but because no one is complaining. Is an additional 20ms delay (or whatever the delay is) from packet aggregation affecting the end-user’s performance? Perhaps you’re right, and there is no difference. But another explanation is that there is an adverse impact, but not to the extent that would prompt the end-user to complain to you. In either case, is packet aggregation something you want to do if you’re not seeing any benefits?
    Josh

  16. Darren said

    Josh,
    I’ve used the application myself from a remote office and I honestly cannot tell the difference in lag with our current settings, so I’m happy I’m not impacting productivity.
    As far as moving from a Citrix solution, it’s just not possible in our environment.
    When launching the application, it downloads 100MB of data and updates (an attribute on) 60,000 files over NFS.
    Processing on that data within the application then generates hundreds of MB of output files.
    We’ve previously attempted to use caches (we use Netapp filers, so their flexcaches) with some success but the cost implications of replicating/caching the data are too great in our environment compared to throwing bandwidth at Citrix. We don’t have any printing requirements to that’s not a concern.
    Darren

  17. Josh Tseng said

    Darren,
    Another thought is that Expand is seeing large packets, so it doesn’t even attempt packet aggregation. So in effect perhaps there’s no difference when you turn on the packet aggregation capability because the Expand device doesn’t even attempt it in the first place.
    Anyways, downloading 100MB or more of data to launch the application is not unusual for Riverbed customers using CAD applications. The initialization data probably has a lot of byte-level commonality among your many users, so this is a “warm” transfer and can probably be done in a few seconds. The unknown factor here is how the application updates the 60,000 files over NFS. Riverbed does have NFSv3 optimizations. If you gave me the name of the CAD application your users are using, then I could tell you more definitively whether our customers have had success with it.
    Finally, note that the Riverbed approach is not caching. I have another blog that talks about the difference between Riverbed and caching. We have many customers who have migrated from having local Netapp or Windows filers in the branch office to consolidating all of their filers to the data center, and only having Riverbed at the branch office.
    Josh

  18. Darren said

    The application is Cadence Virtuoso.
    We’ve currently got about 200TB worth of data stored centrally which is accessed using that, and other applications over NFS.

  19. Josh Tseng said

    Darren,
    We do have at least one customer using Riverbed to optimize Cadence Virtuoso, and there are probably others that I’m not aware of. We have thousands of customers and we’re adding hundreds of new customers every month, so it’s not possible for us to keep track every single customer and application anymore. This specific customer is reporting 36% data reduction on port 5280 and 40% on port 56008. They are also using Riverbed for other applications such as Exchange, CIFS, etc…
    Note that these are data reduction reports only, and the actual performance is going to depend on your specific environment. In particular the way in which your app updates the 60,000 files is the big unknown. Data reduction does not necessarily translate into time-based performance improvement.
    The only way you’re going to know if Riverbed is going to allow you to get rid of Citrix is if you bring us in for a test drive. We can give no promises that this is going to work for you specifically, but over the last four years we can point to many other customers who have been able to migrate off of Citrix ICA specifically for CAD applications.
    Josh

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

 
%d bloggers like this: