Re: [tcpm] TCP Tuning for HTTP - update

[Willy Tarreau <[e-mail]>]

On Fri, Aug 19, 2016 at 11:50:26AM +0100, Jeremy Harris wrote:
> On 18/08/16 18:50, Joe Touch wrote:
> > 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).
> 
> Should we be pushing for the delayed-ack timer to be autotuned?

I personally don't think so. It is very important to ack quickly, especially
nowadays where some mobile phone's stacks are tuned to retransmit very
aggressively and RTTs are already getting pretty close to the ACK delays
we might reach. If we try to increase the delayed-ack timer, we'll risk
to get more retransmits (eg: twice the same request from the client, using
the smaller uplink). If we shrink them, we lose the opportunity to merge
segments. In my experience, the 200ms delayed ack and the 40ms the stack
gives me when I set MSG_MORE are pretty fine to cover all use cases I've
met in field.

Regards,
Willy