Re: Persist Mode -- ** Standards bug ??
- I've not implemented a TCP stack that uses the scale option ( performance over
satellite links is not my problem), so I had not thought about this.
I have now, and I can see your point.
For the last 7 bytes the receiver is advertising a right window position past it's
actual right position.
It would not be a problem if the window was calculated. n*scale - ( scale-1). I
would argue that if that isn't the formula for the window then 1323 has a serious
bug as it breaks some fundamentals.
Matt Mathis wrote:
> I think we have conflicting standards.... although I agree with your
> recollection, I believe that strict "never retract the window" can not be
> implemented. Consider the following scenario:
> A connection negotiates TCP window scale (e.g. 3, so the window size is
> quantized in steps of 8 bytes).
> After running for awhile with a reasonable window, the receiver stops
> consuming data.
> The sender continues to send data, 1 byte at a time, progressively filling
> the window.
> Under these conditions the right edge of the window can not be maintained at a
> constant position in the sequence space. Following 7 consecutive data packets
> it will advance by one byte. On the 8th, it will retract by 7 bytes.
> (Alternatively, if the TCP rounds windows to MSS, the steps are MSS sized).
> Furthermore when the window finally closes all the way, it will always be due
> to a window retraction.
> If the TCP doesn't behave this way it will violate some other part of RFC1323
> or the base specifications. Therefore every TCP that implements 1323 violates
> rule 1 under some conditions.
> Furthermore any TCP requires strict adherence to rule 1 is broken.
> I believe that this is "well tested" in todays Internet (it happens all the
> time) but nobody has been looking for symptoms.
> Now a question for the readers: what might happen if this rule was formally
> retracted or amended?
- On Fri, 6 Jul 2001, Charles Esson wrote:
> I've not implemented a TCP stack that uses the scale option ( performance overI beleive all implementation are careful to do the rounding such that they
> satellite links is not my problem), so I had not thought about this.
> I have now, and I can see your point.
> For the last 7 bytes the receiver is advertising a right window position past
> it's actual right position.
> It would not be a problem if the window was calculated. n*scale - ( scale-1). I
> would argue that if that isn't the formula for the window then 1323 has a
> serious bug as it breaks some fundamentals.
never announce space beyond the end of the buffer. Im my example the last
non-zero receiver window announcement would be when there are exactly 8 bytes
of space left (and the window field would have the value 1). Following the
next byte sent the announced window *must* drop to 0 even though there are
still 7 bytes of space left. Otherwise the receiver will announce space beyond
the end of the buffer.