data overflowing the window

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

I note that data flowing over channels is flow-controlled with a window
mechanism somewhat similar to TCP's (connect-18, section 5.2 et al).
However, since (unlike TCP) there are no sequence numbers, I think I
see a problem.

connect-18 excerpt:

   Data transfer is done with messages of the following type.

     byte      SSH_MSG_CHANNEL_DATA
     uint32    recipient channel
     string    data

   The maximum amount of data allowed is the current window size.  The
   window size is decremented by the amount of data sent. Both parties
   MAY ignore all extra data sent after the allowed window is empty.

But I think I see a race.  If a CHANNEL_DATA and a WINDOW_ADJUST cross
in transit, the two ends' idea of how much window space is available
can get permanently out of sync.  For example:

A                                                                B

Suppose the connection is idle and B's receive window is 1000 bytes.

--> CHANNEL_DATA, 1500 bytes -->

A now thinks B's receive window is zero, with the last 500 bytes of
data being possibly ignored.

                                <-- WINDOW_ADJUST, 1000 bytes <--

B now thinks its receive window is 2000 bytes.

                                --> CHANNEL_DATA, 1500 bytes -->

B now thinks its receive window is 500 bytes.

<-- WINDOW_ADJUST, 1000 bytes <--

A now thinks B's receive window is 1000 bytes.

At this point, the two ends are 500 bytes out of sync, and A could (for
example) send 750 bytes thinking B won't ignore any of it whereas B is
actually likely to ignore the last 250 bytes of it.

Without sequence numbers, I can't see any way to fix this short of
making it a protocol error to send out-of-window data; if anyone is
ever allowed to send beyond the end of the peer's receive window, this
situation can arise.  Is there some more compelling reason why
connect-18 doesn't make it a protocol error to send out-of-window data?

(Actually, it's also fixable if you allow window space to go negative.
But that amounts to throwing away the window mechanism entirely.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B