Re: [tcpm] TCP Tuning for HTTP - update

On Thu, Aug 18, 2016 at 02:52:31PM -0700, Joe Touch wrote:
> 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.

No that's not what I was saying, just that it was often avoiding the
extra 200ms delay before sending the ACK for the odd segment number
which further amplifies the ACK compression issue.

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

On some systems you can force to have delayed ACKs even on PSH, I do it
on linux (disable quick-ack). That's very useful to merge the response
with the ACK for the request. But these are tricky must not be abused.

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

I wasn't aware.

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

Yep definitely. And it's even worse with deep buffers at the intersection
of fast and slow networks like the RAN for some mobile operators because
the stacks here tend to be tuned to assume that a loss is a loss and cause
fast retransmit which further fill the RAN's buffers. Sometimes the uplink
is filled with ACKs and I even found it could be efficient to kill one every
two ACKs in such a case. But I think this asymmetry is progressively going
away in favor of more balanced links.

Willy

Received on Thursday, 18 August 2016 22:07:27 UTC