TCP and WAN issue
ltd at interlink.com.au
Wed Mar 28 01:24:11 UTC 2007
> I have an east coast and west coast data center connected with a DS3. I am
> running into issues with streaming data via TCP and was wondering besides
> hardware acceleration, is there any options at increasing throughput and
> maximizing the bandwidth? How can I overcome the TCP stack limitations
> inherent in Windows (registry tweaks seem to not functions too well)?
even on "default settings" on a modern TCP stack, getting close to
path-line-rate on a 80msec RTT WAN @ DS3 speeds with a single TCP stream should
not be that difficult.
the Windows TCP stack as of Windows XP SP2 has some fairly decent defaults. it
will do RFC1323 / large windows / SACK., but all of these can be tuned with
registry settings if you wish.
with a particular implementation of FCIP (Fibre Channel over IP) i worked on,
we could pretty much sustain a single TCP stream from a single GbE port at
wire-rate GbE with RTT up to 280msec with minimal enhancements to TCP.
at that point it started to get difficult because you had close to 32MB of data
in transit around at any given time, which is the current standard limit for
how large you can grow a TCP window.
i think the first thing you should do is ascertain there are no problems with
your LAN or WAN. i.e. that there are no drops being recorded, no duplex
mismatch anywhere, etc.
i suggest you fire up "ttcp" on a host on each end and see what throughput you
get. with both tcp & udp you should be able to get close to 5.5 to 5.6 MB/s.
if you can't, i'd suggest looking into why & addressing the root cause.
once you've done that, its then a case of ensuring the _applications_ you're
using can actually "fill the pipe" and aren't latency-sensitive at that
More information about the NANOG