Fat pipe TCP WAN optimization
Fat pipe TCP WAN optimization (DRO) is designed to move large amounts of data in single or multiple streams over "fat pipes" at a speed of between 5Mb/sec to 1Gb/sec. DRO minimizes the effect of distance by using a TCP protocol-enhancing proxy (typically a derivative of TCP or UDP) that allows it to do things that can't be done with standard TCP/IP v4 or v6. For example, the protocol-enhancing proxy allows DRO to terminate TCP at each end of the pipe, which completely eliminates TCP latency overhead. That, by itself, would greatly increase the effective data throughput, but there are other DRO tricks that increase throughput.

DRO deduplicates data on a block level, which requires a lot less data to traverse the fat pipe. It can also compress the deduplicated data, as well as adjust the window size and payload to decrease the number of roundtrips required to move that data between the primary data center and remote or branch office. (When the TCP window size and payloads are increased, it usually makes the effective data throughput far more sensitive to packet loss cause...

The real throughput magic comes from DRO's capabilities in diminishing the throughput effects of packet loss. WAN packet loss is a fact of life. Most telcos will claim incredibly low packet-loss numbers of 0% to .001%, but those seem to be the exception, not the rule. Users, on the other hand, say their WAN packet-loss rate ranges between .1% to 6%, according to various surveys. Although that may not seem like much, it's devastating to TCP/IP throughput.

TCP was created with very short LAN distances in mind. When packets are lost or dropped, TCP can't reorder packets, so it must retransmit every packet behind the lost one. This isn't such a big deal on a LAN because the distances are short, acknowledgement of packet loss is quick and not much data has to be retransmitted when packets are lost. That isn't the case when traversing a WAN; as distance increases, roundtrip time increases and more packets fill the pipe. This means more packets must be retransmitted when a packet is lost.

< PREV PAGE   |   1  |   2  |   3  |   4  |   5  |   6  |   7  |   8  |   NEXT PAGE  >