Subject: Re: Persist Mode -- ** Standards bug ??

From: Matt Mathis <[email-masked]>
Date: Thu, 5 Jul 2001 10:59:36 -0400 (EDT)

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?

Thanks,
--MM--

On Tue, 19 Jun 2001, Charles Esson wrote:

> 
> 1) Somewhere in the mile high stack of paper that represents the TCP standard
> it says that the receiver is not allowed to reduce it's advertised window.
> 
> 2) Somewhere else it says the sender is not allowed to expect nice things if
> it transmits past the advertised window.
> 
> If both conditions are met the receiver can't close his window before
> in-flight packets are acked.
> 
> If I am right ( and this is from memory), then all three behave correctly as
> the condition should not arise.
> 
> It would seem AIX4.3 and Sun0S 5.6 throw their hands in the air and wait for
> some sanity. Linux insists you obey rule 1.
> 
> As I only allow the window to move forward I am with linux.

---

From: Charles Esson <[email-masked]>
Date: Fri, 06 Jul 2001 09:04:34 +1000

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.

Regards Charles

---

From: Matt Mathis <[email-masked]>
Date: Fri, 6 Jul 2001 15:54:23 -0400 (EDT)

On Fri, 6 Jul 2001, Charles Esson wrote:

> For the last 7 bytes the receiver is advertising a right window position past
> it's actual right position.
> 
> would argue that if that isn't the formula for the window  then 1323 has a
> serious bug as it breaks some fundamentals.

I beleive all implementation are careful to do the rounding such that they
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.

Thanks,
--MM--

---

From: [email-masked]
Date: Fri, 13 Jul 2001 22:10:38 +0400 (MSK DST)

Hello!

> it will advance by one byte.  On the 8th, it will retract by 7 bytes.

Yes.

Plus, window shrinking happens frequently with window update algorithm
used at receiver side f.e. by freebsd. Look into the archives of this maillist,
subj "Send window update algorithm".

> time) but nobody has been looking for symptoms.

All these spurious kinds of window shrinking do not result in _any_
problems if tcp follows minimal RFC requirements.

Real differences in behaviour of different implementations (and some problems)
start when not only effectively delivered to sender advertised window
is shrinken occasionally, but when two conditions happen simulteneously:
- receiver shrinks window used internally for segment accepting
  (i.e. _deliberately_ and explicitly)
- right edge is kept retracted for interval longer than retransmission timeout

However, this does not affect sender satisfying minimal requirements
formulated in RFCs.

Note also, that effect on congestion avoidance (noticed recently in this maillist)
is present only in implementations not falling to restart cwnd after rto.
For those wich normally do not reprobe pipe (like linux-2.2), this effect
is only useful. If AIX and Co do not implement any cwnd validation, it
is rather their feature. :-)

Alexey