Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels

[Guillaume Autran <gautran@mrv.com>]

The server socket sockopt are all default, except for the 
TCP_WINDOW_CLAMP which is set to 1400 (application specific).
Guillaume.


Alexey Kuznetsov wrote:

>Hello!
>
>  
>
>>Do you think this will also fix Ion's issue with small window size never 
>>going back up ?
>>    
>>
>
>I was wrong even about this one. That bad case, which I rememebered,
>is not triggered here. And even if packet lengths and windows were modified
>to trigger it, the effect would not be so pathological.
>
>
>12:23:24.474506 IP 10.10.10.3.3560 > 10.10.10.2.3200: P 13323:14703(1380) ack 1 win 6144 <nop,nop,timestamp 3256371 268597947>
>12:23:24.508950 IP 10.10.10.2.3200 > 10.10.10.3.3560: . ack 14703 win 14 <nop,nop,timestamp 268598804 3256371>
>
>This value for window is OK, we adverised 1394, so we have to reply with 14.
>
>But where is the ACK opening full window after receiver application
>reads data from buffer? It is the puzzle. It looks like rcvbuf is still
>full.
>
>Now sender cannot send anything due to SWS avoidance.
>
>12:23:29.362161 IP 10.10.10.3.3560 > 10.10.10.2.3200: . 14703:14717(14) ack 1 win 6144 <nop,nop,timestamp 3256380 268597947>
>
>I interpret this as SWS avoidance override timer.
>
>12:23:29.362791 IP 10.10.10.2.3200 > 10.10.10.3.3560: . ack 14717 win 14 <nop,nop,timestamp 268599289 3256380>
>
>This is impossible. :-) Well, it is possible, if rcv_mss is 14. It is what
>I thought, but it is impossible. :-)
>
>Honestly, I still cannot invent any way how this could happen.
>
>Can you say what setsockopt()s were made on receiver socket? It looks
>like just fiddlined with SO_RCVBUF is not enough.
>
>Alexey
>
>  
>

-- 
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================