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

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

    Date:        Mon, 2 Apr 2012 20:28:57 -0700
    From:        Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>
    Message-ID:  <5E7FDFF5-1E2E-4375-8451-4412ABC462A4%gmail.com@localhost>

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

Agreed - that was pretty much what I said in my first message(s) on
the topic.

  | trace is fully consistent.  FreeBSD sends the extra 8 bytes, NetBSD later
  | ack's it.

Yes, I eventually found that too.

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

I hadn't really bothered looking at what was happening in that direction,
but you're right, I should, and will, a little later.

  | I think the only brokenness there is evidence for in that trace is the trace
  | itself.

There was a message I sent only to Darren (because of his Reply-To header...)
in which I said much the same thing - the data he included was missing the
important packets.

  | There's not enough of the conversation to figure out what is going on.

So he gave me access to the raw packet capture of the whole trace ... I'll
look at it closer including the sequence numbers flowing the other way.

What I did notice already is that the reason for the window filling seems to
be packet loss (you already saw that it is a long RTT connection, it is
entirely possible for one lost packet to result in a window full stall before
the retransmit starts it all going again).

It is possible there's actually nothing at all wrong, though the trace does
end with a RST during one of these window full stalls (there are a few through
the full connection).   But the FreeBSD node's behaviour still looks a bit
odd (especially if the assumption I believe is correct that the trace was
taken quite near it, meaning what it shows and what the FreeBSD system saw
are quite close, both in packet accuracy & order, and time).

kre