Subject: IG - Clarification desirable

From: Andreas Jungmaier <[email-masked]>
Date: Mon, 15 Mar 2004 15:49:32 +0100

Hi all,

section 2.15 of the IG currently states that:

    ---------
    New text: (Section 6.2)
    ---------

    The SCTP endpoint MUST always acknowledge the reception of each
    valid DATA chunk when the DATA chunk received is inside its receive
    window.

    When the receiver's advertised window is 0, the receiver MUST drop
    all new incoming DATA chunk and immediately send back a SACK with
    the current receive window showing only DATA chunks received and
    accepted so far.  The dropped DATA chunk MUST NOT be included in the
    SACK as they were not accepted.  The receiver MUST also have an
    algorithm for advertising its receive window to avoid receiver silly
    window syndrome (SWS) as described in RFC 813.  The algorithm can be
    similar to the one described in Section 4.2.3.3 of RFC 1122.
    Because of receiver SWS avoidance, even when the receiver's internal
    buffer is not full anymore, as long as the advertised window is
    still 0, the receiver MUST still drop all new incoming DATA chunk.

IMHO, it would be desirable to state more precisely just what a 
"new" incoming data chunk is. 

Possible interpretations are: 
1. "new" is anything the peer has not seen so far. Clearly, this interpretation 
   prevents successful retransmissions.
2. "new" is any TSN after/higher than the highest TSN received so far.
   This interpretation is *probably* what is intended by the IG.

However, I wonder what happens, if the highest TSN received so far
is a very high one, and a number of TSNs in between are missing. 
Would an implementation close the RWND, as a preventive measure, for
data chunks it has not received so far (this might lead to an implementation
not accepting a much higher TSN in some cases) ?

Hope this posting makes sense, else I may provide an example scenario
for this.

Best regards,
Andreas

- -- 
Dipl.-Ing. Andreas Jungmaier              
Computer Networking Technology Group     
University of Duisburg-Essen                       
http://www.exp-math.uni-essen.de/~ajung   
PGP Key-ID: D382 4AC0             

PGP Key-Fingerprint: 228C 7C2C 3381 2DD4  9998 2812 5C0B 0B04  D382 4AC0