North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: TCP and WAN issue

  • From: Adrian Chadd
  • Date: Tue Mar 27 21:02:09 2007 
On Tue, Mar 27, 2007, Philip Lavine wrote:
> 
> This is the exact issue. I can only get between 5-7 Mbps. So the question is really what incremental performance gain do WAN accelerators/optimizers offer? Can registry/OS tweaks really make a significant difference because so far with all the "speed enhancements" I have deployed to the registry based on the some of the aforementioned sites I have seen no improvement.
> 
> I  guess I am looking for a product that as a wrapper can multiplex a single socket connection.

The "WAN optimisers" (yuk, I do have to deal with them in my current work)
offer some kind of TCP acceleration and flow control - the most advanced
I've seen here is Packeteer. What they (claim to) do is a few things, notably:

* spoof the TCP connection at both ends over high-latency links so the
  TCP stacks at either end think they're talking to something with low RTT/loss
  and thus open up their window sizes right up w/ less touchy expoential backoff;
* then massage the TCP delay and window sizes to make things play happy
  inside the given pipe size.
* Then insert all kinds of protocol spoofing to deal with WAN link speed/RTT
  to fix performance of "LAN only" protocols (such as pretending to be SMB
  end-to-end I believe) - this isn't a new thing btw, I seem to remember seeing
  routers in the 90's spoof various bits of IPX/SPX over ISDN to get a speedup
  and prevent spurious re-dial just to see if the other end is there..

Now, this stuff seems to work fine in the situations I'm using them for
(low bandwidth links, lots of users end-to-end, TCP normally chokes rather
easily) but they do allow things like windows boxes to get full speed out
of satellite links.

This, of course, makes 0% difference to the throughput of my well-tuned
Linux Squid web proxies at either end; but it does mean the proxies don't
end up using -all- of the bandwidth of the link as they want to do.

So!

* if you're after "fill this pipe please" and you don't require the super-fine
  application throttling/shaping/acceleration, then do whatever QoS you require
  on your DS3 (if any!) to ensure you're not causing your high-priority traffic
  to get tail-dropped in the "dumb" fashion and causing backoff, and
* you don't need jumbo frames to get full DS3 speed over 70ms; just bump up
  tx/rx buffer sizes and maximum window sizes and re-test.
* realise that the WAN accelerators make their money doing TCP optimisation
  because its easier to buy a box and put it in then push out group policies
  to windows desktops to fix their default TCP settings. :)
* and finally, make sure the rest of your network isn't introducing issues -
  stuff like bung cables/drivers/duplex settings can cause packetloss which
  becomes much nastier over higher latency links (backoff/retry over LAN
  happens much faster than your 70ms cross-country link.)




Adrian