Re: [tcpm] TCP Tuning for HTTP - update

[Joe Touch <[e-mail]>]

On 8/18/2016 12:59 PM, Willy Tarreau wrote:
> 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.
If you have connection-per-transfer, but not if you have persistent
connections (the server wouldn't issue a close()).

>> 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.
PSH is optional.

The PSH bit forces data not to be aggregated by the sending TCP (i.e.,
to gather multiple send() calls) and forces the receiver to do the same,
but I don't see anywhere that PSH forces ACK compression to be
circumvented. If you have a pointer that'd be useful (I'm speaking of an
RFC). I looked for "delayed ACK" (the term used in 4.2.3.2 of RFC 1122)
and could not find any indication of a relation to PSH there, in fact
the delayed ACK discussion has no exceptions at all.

Additionally, that were true, setting the PSH bit constantly could cause
TCPs to open their slow-start windows much faster (2x per RTT, rather
than 1.5x as currently).

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

Most TCP variant assume that loss=congestion; that's often the wrong
interpretation for wireless.

(exceptions include TCP variants tuned for wireless)

Joe