Re: Latency, TCP ACKs and upload needs

[Lee <ler762 () gmail com>]

On 4/19/16, Jean-Francois Mezei <jfmezei_nanog () vaxination ca> 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.
>
> A satellite company who currently can't even deliver its advertised 5/1
> now brags its next satellite will deliver 25/1.

Take a look at https://www.rfc-editor.org/rfc/rfc3449.txt
  TCP Performance Implications of Network Path Asymmetry

> So I have a few questions:
>
> Considering a single download TCP connection. I am aware that modern TCP
> stacks will rationalize ACKs and send 1 ACK for every x packets
> received, thus reducing upload bandwidth requirements. Is this basically
> widespread and assumed that everyone has that ?

The usual defaults are to ack every other packet & wait 200ms before
acking a single packet.


> Also, as you split available bandwidth between multiple streams, won't
> ack upload requirements increase because ACK rationalisation happens far
> less often sicne each TCP connection has its own context for ACKs?

Yes.  And multiple streams will interfere with each other.
It used to be popular to split a download into multiple streams but I
thought that went out of style now that tcp window scaling is
generally enabled by default.

> 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)
>
> 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 ?
>
>
>
>
> 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 ?

There's an initial timeout that's on the order of 3-5 seconds.  Once
the xfer starts ... I've forgotten the details, but the retransmission
timer is based on the "smoothed round trip time" (srtt).

> 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) ?

The window size is what the receiver advertises, the congestion window
(cwnd) is what the sender computes based on the advertised window size
& packet loss.  cwnd is what gets reduced when there's packet loss.
& yes, reducing cwnd is bad for thruput as is not having selective
acks (sack) enabled on the receiver.

> And when the first ACK finally arrives, won't the sender assume this ACK
> was for the resent 457 ?

The sender keeps track of the 'smoothed round trip time' (srtt).
Since it can't tell if the ack is for the original or retransmitted
pkt, it's not supposed to use that ack for updating the rtt

>   Or is satellite latency low enough that
> stacks all have enough default "patience" to wait for ACKs and this is a
> non issue ?

should be a non-issue

> (Note Xplornet refused to answer questions on whether they operate
> special proxies at their gound stations to manage TCP connections to
> appear "close").
>
>
>
> 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 ?

dunno.  Assuming the bandwidth is available, I suspect you could get
25Mb/s doing something like downloading a movie from archive.org but
for anything interactive like web surfing / gaming I'd bet no - but
because of latency, not the 1Mb/s uplink speed.

Regards,
Lee