One of the interesting and I think fundamental shifts in WAN optimisation, was the addition of a rich QoS feature in Branch Repeater version 6. Several years ago Citrix purchased a company called Deterministic Networks, which was a shim that looked at different applications and classified them based on payload, not just TCP/UDP port, for a number of different VPN vendors. Citrix took that technology and added it to Branch Repeater to automatically classify and by association be smarter about how you managed that traffic based on the user not the traffic.
It’s what we called “User centric, not network centric” this in itself was a great step in changing the field of WAN optimisation, but Citrix also changed their QoS to a custom based Fair Queuing, allowing Citrix to associate a weight to an application, location or URL (via application classifier inside BR thanks to packet inspection), this functionality is a major step forward especially when take into account Multi-Steam ICA and end user experience.
Now, most users of Branch Repeater and the new QoS features in version 6, would typically allocate QoS on the Repeater and align it with existing QoS on their router and depending on the amount of ICA in that site they would associate more focus on the Repeater over the router.
Interestingly I have a customer, (90% of all of their traffic is ICA), who has done away with the QoS (Weighted Fair Queuing), on their routers, yes all of their routers! They are only using the QoS settings on the Branch Repeater.
Their reasoning was predicated on a couple of “fundamental truths” from their provider:
- Router QoS was fast and smart , even with ICA and Multi Stream ICA, (MSI)
- The providers QoS configuration was able to cope with different and changing traffic values
- The cost of QoS was of a benefit to the business, mitigating delays and helping with user experience
Almost by mistake the customer had to replace a router and found out that there wasn’t any QoS allocated to their router, the ICA traffic was ONLY being managed by the Repeater and users were seeing a better experience then before when everything was status quo.
The customer did some further research, they spoke to me and I asked to see their Repeater configuration, during this time, one the engineers at the customer’s site decided to get their provider to remove QoS from another site and waited for a couple of days, (this site was having large amount of dropped packets when contended and the provider wanted to increase the link speed). Remarkably overall utilisation and user experience went up!
Now to be fair this customer understands their WAN environment extremely well, they also monitor and do performance testing (iperf test via Repeater), on all of their links and I wouldn’t advocate running out and doing this without the prep work.
However the upshot of all of this was better performance, (Repeater understand ICA better than any router), less operational overhead, (managing the QoS settings on their routers through their provider), and less cost per month on all of their links, (built in cost for QoS)
Something to think about isn’t it?
Courtesy of Matt Moore , Senior Manager WAN Optimisation, A/NZ