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

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

On 4 Apr, 2012, at 18:23 , Robert Elz wrote:

> Then the problem as you analysed it would not have happened - if the
> ack moves forward, then so does the front edge of the window (and
> the window becomes smaller without adjusting anything else).
> If we choose to use the window size value, then we move the far
> edge of the window (usually forwards, but potentially backwards)
> independantly of whatever happened to the front edge.

Yes, I also thought this would be better since I generally find
it easier to think about the advertised window in terms of the
right-hand end of the sequence space.  The current code confuses
me.

After looking at the code, however, I realized that it isn't quite
so clear-cut.  It actually tracks two windows, the advertised window
and the congestion window, and since these are often compared they
probably need to be maintained in the same units.  Keeping them both
as a byte count means you have to adjust the advertised window for acks
(if you don't just overwrite it, like the FreeBSD patch) but the
congestion window isn't changed by that since it is just a pipe size.
Keeping them both as sequence numbers would save adjusting the advertised
window for acks but would make you adjust the congestion window sequence
number to account for those acks instead.  This makes it kind of a wash.
The advertised window is easier to think about as a sequence, the
congestion window is easier to think about as a byte count and either
way you are adjusting one of those windows to account for acks.  

The FreeBSD patch does make the problem go away if it works (no more
adjusting the advertised window for acks, it is always copied) but I'd
be a little worried about corner cases at the end or start of connections
which the current code somehow handles.  Making tp->snd_win signed and
dealing with negative values might be the easiest way to preserve the
current behaviour.

Dennis Ferguson