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

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 2 Apr, 2012, at 16:41 , Robert Elz wrote:

>    Date:        Mon, 2 Apr 2012 12:25:52 -0700
>    From:        Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>
>    Message-ID:  <72B44EA1-F0F4-45A5-9A03-D93BEEE34DF5%gmail.com@localhost>
> 
> 
>  | NetBSD, having previously advertised that its window was open to 239672, 
> now
>  | claims that its window closed at sequence 239664 while apparently chucking
>  | FreeBSD's last 8 bytes.  FreeBSD should ignore this
> 
> No, it shouldn't, shrinking the window is legal, just not recommended.
> Senders need to be prepared for it to happen and deal with it (see page 42
> of rfc793).

It seems to be more than just "not recommended", as in "strongly discouraged"
and the "robustness principle dictates" that you should never do it yourself
even if someone else does.

Never mind the rest, though, most of what I wrote was based on insufficient
reading.  I somehow thought the packet trace was obtained from the NetBSD end, 
but
I see now it was obtained somewhere else and the temporal ordering of the 
packets
in the trace isn't what NetBSD is seeing.  Looking at it this way, the packet
trace is fully consistent.  FreeBSD sends the extra 8 bytes, NetBSD later
ack's it.

> Here NetBSD's window of 39 (39 * 32 bytes, or 1248) was advertised, and
> FreeBSD sent 1240 bytes.   At that point the buffer has 8 bytes left.
> What's NetBSD to do now?   If it sends a window size of 1 (32 bytes
> scaled) it allows FreeBSD to send 32 more bytes, but has buffer space
> for just 8.   That's wrong.   The next lower window size it can advertise
> is 0 - that's really the only rational choice, it is shrinking the window,
> but that's legal, and FreeBSD is supposed to be able to handle that.

Yes, this is fine.  NetBSD should decide how much data it will accept
and then truncate its advertised window down to the next lower 32 byte
boundary (so that the advertised right edge of the window is always
between what it will accept and 31 bytes lower than that).  This will
ensure that NetBSD never gets more data than it is willing to accept,
though it might get a bit less than that.  Now that I'm looking at the
trace right this is how it seems to work.

Since NetBSD will often need to jitter the right hand edge of the
window back and forth like this, the remaining issue is only
whether FreeBSD needs to track this jitter or not, and I believe
an acceptable answer to that is "not".  Given that window shrinkage
is unlikely (if not illegal) I think tracking the most advanced window
edge it has seen from NetBSD and "handling" window shrinkage in the
same way that it "handles" a broken neighbour which advertises a non-zero
window but refuses to ack the packets you are sending is not unreasonable.


> Darren told me the trace is from an intermediate firewall, I believe one
> much closer to the FreeBSD than the NetBSD, so this probably isn't a safe
> assumption.   The timestamp option values probably allow a better analysis
> of what has been received where, and when, but I haven't bothered to look
> at them, I'm not sure it matters, whatever it believes, there's nothing I
> can see in the packet sequence that authorises the FreeBSD to start sending
> from (relative) seq 239672 onwards, and it does, in a packet burst that
> goes all the way up to 265592 - that's 25920 bytes beyond the window
> (give or take that missing 8).
> 
> That's just broken.

Notice there's another inconsistency, however.  While the zero window
packet NetBSD sends is carrying data which advances the (NetBSD) sequence
to 4438371, the FreeBSD packets are carrying an ack for 4441251.  FreeBSD
has seen NetBSD packets which are not in that trace, it is reasonable for
FreeBSD to ignore the zero window in those old packets, and there's no way
to tell whether what it is doing is reasonable without seeing the NetBSD
packet with a sequence of 4441251.

I think the only brokenness there is evidence for in that trace is the trace
itself.  There's not enough of the conversation to figure out what is going
on.

Dennis Ferguson