WAN transfer rates

Possibly someone in this forum with a better understanding of tcp/ip can
articulate this better than I....

I realize that transfer rates across the Internet diminish significantly
with latency, but what's the good answer for someone shrunk down to
<10Mbps when the smallest pipe between them is 100Mbps and latency is
<40ms?

Does anyone have reference to any study done in this area? I'm sure
window tuning can alter this, but I'm interested in average statistics.

Any reference would be appreciated.

thanks,
jeff

I realize that transfer rates across the Internet diminish significantly
with latency, but what's the good answer for someone shrunk down to
<10Mbps when the smallest pipe between them is 100Mbps and latency is
<40ms?

Without window scaling (RFC 1323) your max transfer rate at 40ms RTT is

65535*8/0.040 = 13.1 Mbps. So slightly less than 10 Mbps isn't too
unexpected.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

The best you can do is transfer a window size per round trip. You can see the window size with tcpdump or one of its cousins, and looking at netstat output will get you somewhere in the neighborhood too. So if your window is 16k and your RTT 25 ms, that's 16k every 25 ms. Or 16 * 1000 / 25 = 640k per second = 640000 * 8 = 5 Mbps.

I think the real answer is more complex, if I remember this correctly:

The real transfer results depend on a lot of things, but the foremost
parameter that dominates the transfer rates for a single TCP session is
the duration of the session. If the session is short-lived, regardless of what the maximum window size is, the transfer rate will be abysmal unless the TCP stack is modified to guesstimate the initial window.

For long lived TCP sessions, you want to have enough packets in flight to fill the bandwidth delay product of the link to get the maximum throughput.

Mark Allman, Sally Floyd, and quite a few other people have published numerous papers on this topic.

Essentially the answer is that the transfer rates diminish with increasing latency if and only if the sessions are short-lived.
This becomes a huge problem especially on high bandwidth satellite links where some real "interesting" TCP hacks are employed. Now add a DNS lookup or two to the beginning of the sessions and things really start
to look bad for short-duration traffic over high latency links.

When you have many TCP sessions competing for the same link, then things start to look up.

Regards,

Bora Akyol