In order for some manufacturers to try to gain an edge over a competing product they will typically try to use and create some kind of uncertainty around that product using what is known in the IT world as “FUD”, where FUD is an acronym for Fear, Uncertainty, and Doubt.  A couple of the common misconceptions or FUD that competitors try to portray is that Riverbed technologies will “tunnel” all traffic between remote sites and the other is that the Riverbed appliances will cache files, which can result in a client receiving an old copy of information.  Since I have just gotten back from a week of intensive Riverbed training, I would like to help dispel this FUD.  Keep in mind that I’ve been a Cisco trainer for about 7 years and hold many various Cisco certifications, minus CCIE, so I’m leaving any kind of bias at the door. Tunneling FUD

In order to completely understand this you need to be a little bit familiar with the TCP connection sequence of a three-way-handshake.  As a quick review, the three-way handshake is used for two hosts to basically get their ducks in a row before they start sending traffic to each other.  The first segment is a synchronize (SYN) packet that indicates the two hosts wanting to start a connection.  The second packet that comes back to the originator of the first packet is a SYN/ACK packet and then the third packet is an ACK packet.  After that short sequence, then the two hosts can send TCP based traffic.  These packets have lots of info that help with reliability, quality of service (QoS), and flow-control between the hosts.

When we have two Riverbed Steelhead appliances in between the two hosts that are trying to communicate, then basically what happens is that the TCP connection sequence is intercepted between the two hosts and instead of the hosts doing the connection sequence directly with each other they are unknowingly exchanging the connection sequence packets with the intermediary Steelhead appliances.  The TCP handshake still occurs between the two hosts but is proxied between the Steelhead appliances, whereas the Riverbed devices create their own TCP handshake to begin the optimization process.  It can get a little more complex than this in certain instances, but as you can see there is no tunneling that is occurring between the Steelheads or hosts…  just some TCP 3-way handshakes.

Caching FUD

Riverbed Steelhead appliances use a proprietary algorithm called Scalable Data stReamlining (SDR) to break up large amounts of data into smaller pieces called references and stores them on the Steelhead.  The first time that a file is transferred between two Steelheads (cold transfer) all data and references to the data are sent across the wire.  Subsequent transfers are sent using the references and that is where the majority of WAN optimization savings occur.

But what happens when a user goes into a document and changes a few letters, saves it, and another user requests the file?  Does the entire file have to get retransmitted?  The answer is no.  Remember, the Steelhead appliance breaks the file into references so the entire file didn’t change, only some of the references changed.  Now the Steelhead will send the original references that didn’t change along with the new data and new references that point to the new data.  During a warm transfer, the Steelheads are only sending references to blocks of data across the wire and not files so there is no chance that a user can receive an old or outdated copy of a file.  The Steelheads never send a file to a host that has not been requested and will compare references every time a file is transmitted.

Comments (0)
Dave Asher July 1 2009 03:51:30 PM

delicious  |   facebook  |   digg it  |   twitter  |   stumbleupon  |   ping this!