LRO causing stretch ACK violations interacts badly with delayed ACKing

[Colin Percival]

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!

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid