New to RiOS 5 is a better QoS engine. Now admins can not only employ rate limiting between sites, but they can also assign a priority to traffic that passes through. For example, admins can define 2Mbps of traffic from datacenter to remote office A and 3Mbps of traffic from datacenter to remote office B. Within each link, admins can then prioritize specific traffic types, such as HTTPS and CIFS. Each link is unique and can have its own traffic prioritization policy.
Available since RiOS 4, MX-TCP's capability of nearly eliminating TCP's slow start after packet loss directly benefits from the new QoS engine. MX-TCP is so aggressive that in some situations, it can consume all available bandwidth, thus "starving" other traffic. The QoS engine works perfectly in this situation, preventing one traffic flow from filling the pipe and obstructing another flow.
I Can See Clearly Now...
One knock against many WAN optimization appliances is they tunnel or repackage the TCP/IP packets between appliances blinding WAN-monitoring tools. Riverbed has provided export to NetFlow for a while now for WAN monitoring, but RiOS 5, in addition to RiOS's native transport, includes two additional modes of operation: Port Transparency and Full Transparency.
With Port Transparency, as in native mode, each Steelhead will still use its respective IP addresses as the source and destination addresses for each packet but will keep the original destination TCP/IP port. In Full Transparency mode, the Steelheads leave both the original source and destination IP addresses the same as the destination port. Riverbed recommends that admins use the native tunneling between Steelheads unless the network is very complex or IP address accounting is required. Full Transparency may also require router changes and has been known to cause issues with stateful inspection firewalls.
One feature that I know network admins will really appreciate is that the Steelhead appliance no longer loses network connection on a restart of the core services. This means that when a policy change or other modification is made to a Steelhead and IT restarts the services, network traffic is no longer disrupted. I tested this feature by doing a continuous ping across the WAN while restarting the services, and not once did I drop a packet.