[188863] in North American Network Operators' Group
Re: Latency, TCP ACKs and upload needs
daemon@ATHENA.MIT.EDU (joel jaeggli)
Tue Apr 19 22:04:17 2016
X-Original-To: Nanog@nanog.org
To: Jean-Francois Mezei <jfmezei_nanog@vaxination.ca>,
"Nanog@nanog.org" <Nanog@nanog.org>
From: joel jaeggli <joelja@bogus.com>
Date: Tue, 19 Apr 2016 19:03:51 -0700
In-Reply-To: <5716DB68.1080801@vaxination.ca>
Errors-To: nanog-bounces@nanog.org
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HITvGRbUnrS32VXMakOuCttw4G51oXuh6
From: joel jaeggli <joelja@bogus.com>
To: Jean-Francois Mezei <jfmezei_nanog@vaxination.ca>,
"Nanog@nanog.org" <Nanog@nanog.org>
Message-ID: <23cd987c-7abb-b055-9453-cbe351c4279f@bogus.com>
Subject: Re: Latency, TCP ACKs and upload needs
References: <5716DB68.1080801@vaxination.ca>
In-Reply-To: <5716DB68.1080801@vaxination.ca>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 4/19/16 6:29 PM, Jean-Francois Mezei wrote:
> As part of the ongoing CRTC hearings, the incumbents' claim that
> continued implementation of the current 5/1 standard would make Canada =
a
> world leader for broadband in the future.
>=20
> A satellite company who currently can't even deliver its advertised 5/1=
> now brags its next satellite will deliver 25/1.
>=20
> So I have a few questions:
>=20
> Considering a single download TCP connection. I am aware that modern TC=
P
> stacks will rationalize ACKs and send 1 ACK for every x packets
> received, thus reducing upload bandwidth requirements. Is this basicall=
y
> widespread and assumed that everyone has that ?
with an mss of 1460 the inbound packets for reasonably well packed flow
will be 36.5x larger than the acks which are 40 bytes.
sack rfc 2018 means you don't have to acknowledge all of the inbound
packets.
> Also, as you split available bandwidth between multiple streams, won't
> ack upload requirements increase because ACK rationalisation happens fa=
r
> less often sicne each TCP connection has its own context for ACKs?
>=20
> When one considers the added latency of satellite links, does 25/1 make=
> sense ? (I need a sanity check to distinguish between marketing spin
> presented to the regulator and real life)
satellite vendors use various forms of tcp acceleration which may
involve among other things having middle boxes that pre-emptively send
the ack, play with the window size etc.
> I noticed that in the USA, EXEDE Satellite advertises 12/3 plans and
> they are also on a VIA Sat satellite, presumably the same vehicle that
> Xplornet tries to deliver its measly 5/1 on. Would all beams be
> identical on a satellite or can they be configured differently with a
> ISP adjustable rate of upload/download inside the same spectrum ?
>=20
>=20
>=20
>=20
> Also, when you establish a TCP connection, do most stacks have a defaul=
t
> window size that gives the sender enough "patience" to wait long enough=
> for the ACK ?
retransmission timeouts are typically measure in seconds...
https://tools.ietf.org/html/rfc6298
and geostationary orbits typically have RTTs under 800ms.
> If sender sends packet 457, doesn't get ACK in time and resends 457,
> doesn't that also result in reduction in window size (the very opposite=
> of what would be needed in high latency links) ?
>=20
> And when the first ACK finally arrives, won't the sender assume this AC=
K
> was for the resent 457 ? Or is satellite latency low enough that
> stacks all have enough default "patience" to wait for ACKs and this is =
a
> non issue ?
>=20
> (Note Xplornet refused to answer questions on whether they operate
> special proxies at their gound stations to manage TCP connections to
> appear "close").
seems likely
>=20
>=20
> 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 us=
e
> of the 25 download speed or whether the limited 1mbps upload would chok=
e
> the downloads ?
>=20
--HITvGRbUnrS32VXMakOuCttw4G51oXuh6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAlcW44gACgkQ8AA1q7Z/VrJX6wCfSkWaFa1RM2Zrp5hvMZ/DBaRM
FG4An0kIyWTqyNo40ScoADezaETO+cDi
=ajFJ
-----END PGP SIGNATURE-----
--HITvGRbUnrS32VXMakOuCttw4G51oXuh6--
