[188866] in North American Network Operators' Group
Re: Latency, TCP ACKs and upload needs
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Wed Apr 20 10:28:05 2016
X-Original-To: nanog@nanog.org
Date: Wed, 20 Apr 2016 07:27:53 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <5716DB68.1080801@vaxination.ca>
Errors-To: nanog-bounces@nanog.org
--qMm9M+Fa2AknHoGS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Others have already answered with the technical details. Let me take a=20
stab at some more, uh, variable items.
In a message written on Tue, Apr 19, 2016 at 09:29:12PM -0400, Jean-Francoi=
s 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.
--=20
Leo Bicknell - bicknell@ufp.org
PGP keys at http://www.ufp.org/~bicknell/
--qMm9M+Fa2AknHoGS
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUBVxeR6bN3O8aJIdTMAQLrdBAAplePrrMu3j2ymxTPLSzLACVDR886fI1X
Z59EV3GRyCy8FTgRMu26Ox6rISarwRucLmLH3ZEzsf48obuypGXx22aLhqznZIFR
wpLyyr4yjAbnk9O7EOhRh/fw/FM3SkX1iCjKVonKdRU+LL7CYT+9ND7fpWaYrNPJ
Tze5I+rqLeI6LjRE9gduNE8qXvW6vti/lBRnjodrTs0EwJCwBsEOWL2TAXTvyMyi
z37JjcrozxYSZjKyPUwZPhIkCyXYQeALWvCShJkvF1zDxthZ6BI8h8eQ2Ldfo9fF
kp7Y29gG+z+bybtT2s10gnLtasWcc9IXpJA5c5rN+gTTMNbwU7CW2qNqiJ2JjdYC
YDLpyE/0CyQ/L4R2rSvjXBpfrY2buNNR+bda+RZNCvZ9+VsgLV3pWb3cV1i5A1iW
rFz43A3RJbdAWBvvGRZm/5xP/I8EjNPLowLg09jKqcoSz1ZpbgMnlee2HwgTM4Qp
7gxKgd9q6ROlu4sXrQqSaBy6743UaN0v2nFLtPlqmQkQUwP1sS8A6G4C/KvnL/9U
SiRh4H/By0noHyKNuh8iZQ95lwCtgFJBdOgVdW61ifel8gpegpCKCpsxTQ3f5zGi
MM8m7fuMK6eGpmEkRCt9Aj7BMT7SOs5l+dxFDZCUUwOwJ0qJOTqnFBXeEmPESHFf
8Tlj81PK5xI=
=3ODS
-----END PGP SIGNATURE-----
--qMm9M+Fa2AknHoGS--
