Latency, TCP ACKs and upload needs
bicknell at ufp.org
Wed Apr 20 14:27:53 UTC 2016
Others have already answered with the technical details. Let me take a
stab at some more, uh, variable items.
In a message written on Tue, Apr 19, 2016 at 09:29:12PM -0400, Jean-Francois Mezei wrote:
> Also, when you establish a TCP connection, do most stacks have a default
> window size that gives the sender enough "patience" to wait long enough
> for the ACK ?
Your question is phrased backwards. All will wait for the ACK, the
timeouts are long (30-120 seconds). The issue is that you only get
one window of data per RTT, so if the window is too small, it will
choke the connection.
90%+ of the stacks deployed will be too small. Modern Unix generally
has "autotuning" TCP stacks, but I don't think Windows or OS X has
those features yet (but I'd be very happy to be wrong on that point).
Regardless of satellite uplink/downlink speeds, boxes generally need
to be tuned to get maximum performance on satellite.
> What i am trying to get at here is whether 25/1 on satellite, in real
> life with a few apps exchanging data, would actually be able to make use
> of the 25 download speed or whether the limited 1mbps upload would choke
> the downloads ?
With a properly tuned stack what you're describing is not a problem.
1460 byte payloads down, maybe 64 byte acks on the return, and with SACK
which is widely deployed an ACK every 2-4 packets. You would see about
2,140 packets/sec downstream (25Mbps/1460), and perhaps send 1070 ACKs
back upstream, at 64 bytes each, or about 68Kbps. Well under the 1Mbps
Leo Bicknell - bicknell at ufp.org
PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 811 bytes
Desc: not available
More information about the NANOG