Re: Latency, TCP ACKs and upload needs

[Leo Bicknell <bicknell () ufp org>]

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
upstream bandwidth.

-- 
Leo Bicknell - bicknell () ufp org
PGP keys at http://www.ufp.org/~bicknell/

Attachment: _bin
Description: