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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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).

Window management gets real messy with window scaling - hosts cannot advertise
a window size > their available buffer space (obviously) but need to work
out what to do when receiving data that isn't a multiple of the window
scale factor.

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.

Whatever tricks the NetBSD (receiving system, whatever OS) does in this
case, it really cannot avoid shrinking the window in some cases, starting
out smaller and allowing extra bytes from the buffer that hadn't been
advertised to gradually be consumed by these fragments of window scale
units in data packets will still eventually consume all the available
space, at which point shrinking the window is the only option.

  | The problem, then, isn't FreeBSD ignoring the closed window

Well, it is, really, but

  | but rather NetBSD not accepting those last 8 bytes.

that might also be a problem - this one isn't clear to me, that is,
whether a system should enforce the window it advertised, or the one
it really has but cannot advertise.   Before window scaling this couldn't
happen, now it can.

  | I'm pretty sure the problem has something to do with window scaling,

Possibly, but I suspect there's more to it than that, as after the 0 window
is advertised, FreeBSD goes wild and starts sending all kinds of stuff, not
just those missing 8 bytes - almost as if it was treating the 0 as 65536 or
something.

And ...

dennis.c.ferguson%gmail.com@localhost said:
  | I should say that I'm making the assumption that NetBSD actually received
  | the packet above.  I assumed that might be a safe assumption since the
  | trace was taken on the NetBSD box

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.

Why it does it I have no idea, does anyone know how similar FreeBSD's
tcp is to NetBSD's these days?

kre