Re: [tcpm] TCP Tuning for HTTP - update

Hi, Willy,

Yes - this is yet another example of TCP's "twisty maze of passages, all
alike" ;-)

Joe


On 8/18/2016 3:05 PM, Willy Tarreau wrote:
> 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 23:05:00 UTC