Re: [tcpm] TCP Tuning for HTTP - update

[Willy Tarreau <[e-mail]>]

On Thu, Aug 18, 2016 at 10:50:52AM -0700, Joe Touch wrote:
> Hi, Willy,
> 
> On the issue of ACK compression effects:
> 
> 
> On 8/17/2016 10:38 PM, Willy Tarreau wrote:
> >>     - watch out for ACK compression effects (turn it off in favor of ABC
> >> > if you can)
> > It does not happen that much with HTTP. Many connections on the server side
> > see only one, sometimes two requests, and most responses are small (about
> > 20kB on average, with favicon fitting in a single segment). Note, I'm talking
> > about observations on average web sites.
> The effect is more pronounced for smaller responses, for any response
> using an odd number of packets. The last odd packet will be stalled
> because the client needs to timeout before it will send an ACK for a
> single segment (it's waiting for the second segment).

With short keep-alive responses yes but not short-lived connections
since the server sends the FIN immediately afterwards, which hints
the client not to wait for anything else and to ACK immediately.

> It doesn't matter how many requests you have, but the impact can be
> complicated on persistent connections.

Yes I agree. Please note that usually the last segment of a message
carries a push which precisely speeds up delivery to the application
and acking (as most OSes ack on push but apparently not all), so it
is not often emphasized that much. But I've met some 3G networks
where ACK compression was causing excessive retransmits from the
sender, resulting in excess retransmits of ACKs in turn, maintaining
the ACK link congested. It generally gets worse with many parallel
connections than with a single one, and in this regard HTTP/2 has
improved things a lot.

Willy