A reader asks why routers can't take on more of the acceleration function
This article was sent in by a reader, Network Architect and CCIE Derek Small. Derek wants to know why no network vendors have implemented WAN caching as a router feature. Got an opinion?
Many vendors today sell WAN acceleration devices. These devices primarily cache content locally so that subsequent requests for the same content can be served locally, instead of burdening the WAN with the same content. Most of them also support a function typically called “local acknowledgment.”
As we all know, with TCP communications, the server sends a burst of data, called a TCP window, in several packets. Only after the server receives an acknowledgment from the client that the entire window has been received without errors does the server start sending the next window of packets. On high-speed WANs the latency associated with distances over a few hundred miles can limit a given TCP flow to a couple megabits per second. With local ACK, the local WAN caching device sends an acknowledgment to the server as soon as it receives the last packet in the window, so the server gets the ACK in a few milliseconds, not a few hundred milliseconds. The WAN caching device then waits for the ACK from the remote client before starting to send the next window. The WAN caching devices, assuming there is one on each end of the WAN circuit, usually employ some proprietary method of speeding up the transfer over the WAN (usually they just break up the stream so that each window is it’s own stream, and can run concurrently over the WAN). The end result of all this is that to the client and the server, they each look like they are on the local LAN, and transfer rates generally go up from 5-7Mbps, to 50Mbps, 100Mbps or more.
I’m curious why no network vendors have implemented this as a router feature. Using this on a router, the router would take over termination of the TCP flow, provide local ACK to the server, and handle buffering each window until the ACK is received from the remote client. The router would need to buffer each window of course, in case it received a NACK, so it could retransmit the window to the client.
Here is where implementing this on the router could really help. When the router starts receiving the second window of data from the client, the router could evaluate the current load on the WAN circuit and decide to buffer the data locally, and hold off on sending the ACK to the server, or start a second stream concurrently over the WAN for the second window, and send the local ACK to the server. The router on the other end would need to buffer the second window, until it received the ACK from the client for the first window, so it would need to have a handshake with the router at the server end to establish that WAN acceleration is taking place.
Using local ACK on a WAN acceleration device doesn’t allow the acceleration device to be aware of the current WAN load, so you can fill your WAN with a single file request. Some WAN accelerators detect packet drops, and use that as a sign that WAN congestion is occurring, but they can only tell when things are saturated. The router can determine that you are nearing some threshold, say 70%, and stop doing local ACK until the load begins to fall.
To protect against router buffer overload, you would need to be able to set a threshold for the maximum amount of memory which could be used for WAN acceleration, and/or the maximum number of concurrent window transmissions for a given flow.
This feature should also allow for an ACL or route-map (for NBAR) to identify traffic which should be considered for acceleration, so the router doesn’t waste resources accelerating Email or some warez server that an employee loaded up with the latest episodes of Lost.
These days, it is not uncommon for routers to be loaded with 1GB of DRAM or more, and a buffer as small as 5-10MB could easily improve throughput for a given coast-to-coast transfer, from 5-7Mbps to 20-40Mbps on a WAN circuit of 45Mbps or faster.
Derek Small, CCIE #5832, CCSP, InfoSec is a network architect for Cincinnati Bell Technology Solutions, GE Professional Services
Posted by Cisco Subnet editor Julie Bort. Got an idea for an article you’d like to see on Cisco Subnet? E-mail me at jbort@nww.com
More from Cisco Subnet:
Win great stuff from Cisco Subnet Like e-mail? Subscribe to the Cisco Alert newsletter.Cisco Subnet RSS feed
- Juniper aims higher than Cisco
- Cisco rival Brocade misfiring on IP
- Fallout from Cisco, HP split
- Cisco patches multiple holes in its security products
- Cisco said to be readying major upgrade to CRS-1
- Cisco shipping 160G Ethernet card for ASR 9000
- IPv4 Space is Getting Low – Really Low
- The scoop on the New TSHOOT Course and Exam
- Win one of 50 CCNP training books, videos and Cert Kits
Like RSS readers? Subscribe to the
Follow all Cisco Subnet bloggers on Twitter.Jim Duffy on TwitterFollow
