Re: BSD doesn't track window size changes correctly.

[Darren Reed <darrenr%netbsd.org@localhost>]

On 1/04/2012 10:35 PM, Robert Elz wrote:
>     Date:        Sun, 01 Apr 2012 18:13:36 +1000
>     From:        Darren Reed <darrenr%NetBSD.org@localhost>
>     Message-ID:  <4F780E30.3000204%netbsd.org@localhost>
> 
>   | ... the problem here is that it only recognises window updates
>   | that increase the window size.
> 
> That's not quite what the code says, in one of the three alternatives
> the window is only allowed to grow, but ...
> 
>   | Thus if the remote end sends back
>   | a packet that indicates the window size is 0, it is ignored.
> 
> In that case, yes, but that's also very poor behaviour from the peer,
> and not something it can rely upon working (while I'd agree that
> perhaps strictly it should).
> 
> That is, if the peer has previously authorised our sending some data,
> and later tries to take it back, it cannot assume that we had not already
> sent the data up to the advertised window size, nor can it assume (in
> the case that matters) that we ever even saw its attempted window update
> (if I read that right, that third alternative should normally only occur
> for a packet with the same seq & ack as previously received, so there's no
> way any reply we send can distinguish receiving that packet from receiving
> the previous one - unless perhaps it had more data than the earlier packet,
> but that would be a very unusual implementation.)
> 
> That is, a peer that acts like this cannot complain if we keep sending data
> to the old authorised window, and even if we keep retransmitting it if there's
> no ack.
> 
> If I were you I'd concentrate on finding out what wacky system is closing
> the window after previously opening it, that's anti-social TCP at best.

The problems I have observed are running a client from a local FreeBSD server
with a NetBSD server at the other end.

What I am observing happening is two things:
1) NetBSD advertises a window that shrinks as it receives more data, until
   its buffer is full.
2) NetBSD then advertises a window size of 0 that is summarily ignored.

So both ends are BSD TCP...

Here's one such extact:
09:01:33.740701 IP FreeBSD.35421 > NetBSD.ssh: Flags [S], seq 2474756569, win 
65535, options [mss 1460,nop,wscale 3,sackOK,TS val 1064054 ecr 0], length 0
09:01:33.952922 IP NetBSD.ssh > FreeBSD.35421: Flags [S.], seq 1491889712, ack 
2474756570, win 32768, options [mss 1452,nop,wscale 5,nop,nop,TS val 1 ecr 
1064054,sackOK,nop,nop], length 0
...
09:03:38.416891 IP NetBSD.ssh > FreeBSD.35421: Flags [.], ack 239664, win 0, 
options [nop,nop,TS val 249 ecr 1076479], length 0
09:03:38.437943 IP NetBSD.ssh > FreeBSD.35421: Flags [.], seq 4436931:4438371, 
ack 239672, win 0, options [nop,nop,TS val 249 ecr 1076502], length 1440
09:03:38.439168 IP FreeBSD.35421 > NetBSD.ssh: Flags [.], seq 239672:241112, 
ack 4441251, win 7740, options [nop,nop,TS val 1076524 ecr 249], length 1440
09:03:38.439290 IP FreeBSD.35421 > NetBSD.ssh: Flags [.], seq 241112:242552, 
ack 4441251, win 8139, options [nop,nop,TS val 1076524 ecr 249], length 1440
09:03:38.440516 IP FreeBSD.35421 > NetBSD.ssh: Flags [.], seq 255512:256952, 
ack 4441251, win 8139, options [nop,nop,TS val 1076524 ecr 249], length 1440
09:03:38.440638 IP FreeBSD.35421 > NetBSD.ssh: Flags [.], seq 256952:258392, 
ack 4441251, win 8139, options [nop,nop,TS val 1076524 ecr 249], length 1440
09:03:38.440761 IP FreeBSD.35421 > NetBSD.ssh: Flags [.], seq 258392:259832, 
ack 4441251, win 8139, options [nop,nop,TS val 1076524 ecr 249], length 1440
09:03:38.440885 IP FreeBSD.35421 > NetBSD.ssh: Flags [.], seq 259832:261272, 
ack 4441251, win 8139, options [nop,nop,TS val 1076524 ecr 249], length 1440
09:03:38.441007 IP FreeBSD.35421 > NetBSD.ssh: Flags [.], seq 261272:262712, 
ack 4441251, win 8139, options [nop,nop,TS val 1076524 ecr 249], length 1440
09:03:38.441143 IP FreeBSD.35421 > NetBSD.ssh: Flags [.], seq 262712:264152, 
ack 4441251, win 8139, options [nop,nop,TS val 1076524 ecr 249], length 1440
09:03:38.441250 IP FreeBSD.35421 > NetBSD.ssh: Flags [.], seq 264152:265592, 
ack 4441251, win 8139, options [nop,nop,TS val 1076524 ecr 249], length 1440
09:03:39.128537 IP FreeBSD.35421 > NetBSD.ssh: Flags [.], seq 239672:241112, 
ack 4441251, win 8280, options [nop,nop,TS val 1076593 ecr 249], length 1440
09:03:39.720321 IP NetBSD.ssh > FreeBSD.35421: Flags [.], seq 4436931:4438371, 
ack 239672, win 0, options [nop,nop,TS val 252 ecr 1076502], length 1440
09:03:39.721146 IP FreeBSD.35421 > NetBSD.ssh: Flags [.], ack 4441251, win 
8280, options [nop,nop,TS val 1076652 ecr 249], length 0
09:03:39.932057 IP NetBSD.ssh > FreeBSD.35421: Flags [.], ack 239672, win 0, 
options [nop,nop,TS val 252 ecr 1076502], length 0

Darren