Re: [lwip-users] transfer stucks when snd_wnd is less than TCP_MSS

[Kieran Mansley]

On Thu, 2007-03-08 at 19:18 +0200, Vlad wrote:
> I mean second. lwip receives ack packets that sets snd_wnd less and less with 
> every packet:
> 
> 19:11:10.246024 IP x1:port1 > x2:port2: P 61680:63140(1460) ack 1 win 20480
> 19:11:10.246055 IP x2:port2 > x1:port1: . ack 63140 win 15340
> 19:11:10.246604 IP x1:port1 > x2:port2: P 63140:64600(1460) ack 1 win 20480
> 19:11:10.246641 IP x2:port2 > x1:port1: . ack 64600 win 13880
> 19:11:10.247193 IP x1:port1 > x2:port2: P 64600:66060(1460) ack 1 win 20480
> 19:11:10.247224 IP x2:port2 > x1:port1: . ack 66060 win 12420
> 19:11:10.248301 IP x1:port1 > x2:port2: P 66060:67520(1460) ack 1 win 20480
> 19:11:10.248340 IP x2:port2 > x1:port1: . ack 67520 win 10960
> 19:11:10.248974 IP x1:port1 > x2:port2: P 67520:68980(1460) ack 1 win 20480
> 19:11:10.249011 IP x2:port2 > x1:port1: . ack 68980 win 9500
> 19:11:10.249588 IP x1:port1 > x2:port2: P 68980:70440(1460) ack 1 win 20480
> 19:11:10.249619 IP x2:port2 > x1:port1: . ack 70440 win 8040
> 19:11:10.250184 IP x1:port1 > x2:port2: P 70440:71900(1460) ack 1 win 20480
> 19:11:10.250215 IP x2:port2 > x1:port1: . ack 71900 win 6580
> 19:11:10.250778 IP x1:port1 > x2:port2: P 71900:73360(1460) ack 1 win 20480
> 19:11:10.250814 IP x2:port2 > x1:port1: . ack 73360 win 5120
> 19:11:10.251726 IP x1:port1 > x2:port2: P 73360:74820(1460) ack 1 win 20480
> 19:11:10.251764 IP x2:port2 > x1:port1: . ack 74820 win 3660
> 19:11:10.252660 IP x1:port1 > x2:port2: P 74820:76280(1460) ack 1 win 20480
> 19:11:10.252705 IP x2:port2 > x1:port1: . ack 76280 win 2200
> 19:11:10.253375 IP x1:port1 > x2:port2: P 76280:77740(1460) ack 1 win 20480
> 19:11:10.253409 IP x2:port2 > x1:port1: . ack 77740 win 740
> 
> At this moment remote server (x2 - remote, x1 - local) stops send packets, 
> and 
> my program cannot send packets (they stays in queue) because snd_wnd == 740,
> segment size is 1460 == TCP_MSS. Connection times out in 1 minute.

Hmmm, seems like the network stack you're talking to is being rather
uncooperative.  Normally a stack would try not to advertise less than 1
MSS of receive window, and to send an update with more window space as
soon as possible if it did close the window in this way.  We shouldn't
drop any packets due to this though - lwIP will just wait until the
other side advertises more window space and then carry on.  I'm also
surprised that the connection times out in 1 minute - that's a very fast
timeout.  Does the other stack not eventually advertise more window
space?  If not, I think the problem is at that end.  Looks like lwIP is
doing the right thing to me.

Kieran