LRO causing stretch ACK violations interacts badly with delayed ACKing

[Andre Oppermann]

On 21.10.2013 22:58, Colin Percival wrote:
> On 10/21/13 13:11, Andre Oppermann wrote:
>> On 21.10.2013 21:57, Andre Oppermann wrote:
>>> This is an excellent observation!  Our tcp doesn't know about LRO
>>> and I prepared the mbuf header to carry information about the number
>>> of merged LRO segments.  That's not done yet again.  However a small
>>> heuristic in tcp_input looking for segment > mss should be sufficient
>>> for now.  Let me have a look at patching it into a suitable place.
>>
>> Please check out the patch below.  Haven't tested it myself yet though.
>
> Yes, this works:
>> 00:00:00.000000 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [S], seq 3220740500, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 350742 ecr 0], length 0
>> 00:00:00.000613 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [S.], seq 1783557911, ack 3220740501, win 8190, options [mss 1460,nop,wscale 6], length 0
>> 00:00:00.000657 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [.], ack 1, win 1026, length 0
>> 00:00:00.001842 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [.], ack 1, win 127, length 0
>> 00:00:00.032269 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [P.], seq 1:318, ack 1, win 1026, length 317
>> 00:00:00.033080 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [.], ack 318, win 108, length 0
>> 00:00:00.033115 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [.], seq 1:4097, ack 318, win 108, length 4096
>> 00:00:00.033129 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [.], ack 4097, win 962, length 0
>
> Please commit this fix and get it merged for 10.0-RELEASE!

I committed it to my staging branch pending review:
  http://svnweb.freebsd.org/changeset/base/256879

It should go into HEAD later this week and the MFC to 10.x then depends
on re@'s take on it.

-- 
Andre