Subject: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt

From: Arun Prasad <[email-masked]>
Date: Thu, 14 Mar 2002 17:15:13 +0530

Hi all,
    In the draft-ietf-tsvwg-sctpimpguide-03.txt section 2.15 "Window probes in
SCTP"....    we felt some contradictions....

---------
   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 above point specifies that when we receive any Data chunks and the
Rwnd is zero then we have to drop those packets and  those chunks' TSN will
not be included in the SACK sent........ Consider the following example...
    * Sender sends a probing data chunk of  "Tsn x" to Receiver when the Receiver
        has advertised the the ARwnd as zero....
    * Receiver upon receiving this chunk will check its Rwnd, Since the Rwnd is zero
       it will drop the chunk and sends a SACK with CUM_TSN as " x-1" (not
       including "TSN x"....
    * Sender upon receiving this SACK cannot send another "Zero Window Probe"
       because there is an OutStanding Data chunk ( this condition is from the same
        section.. "Note that zero window probe SHOULD only be sent when all
        outstanding DATA chunks have been cumulatively acknowledged "...)  but its
        RTX timer will expire and sends the  same Data chunk "TSN x" one more
        time...( note, that zero window probe is no more used...) ...
    * Receiver again drops the packet and sends a SACK as above......

            This procedure continues till the Maximum Retransmission Counter goes
    off and the Association closes.... (According to section 2.15.2 "When a sender is
doing zero window probing, it should not time out the association if it continues to
receive new packets from the receiver", this again contradicts )

*********************
    Next issue is from the lines
"---------
   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."

       Considere the below scenario:
    * Sender sending a data chunk of size 1000 when SND.WND = 1500
    * Receiver receives the data chunk and sends a SACK wth  ARwnd = 500
        (It cant apply SWS avoidance here by sending a (ARwnd = 0), because that
           would violate SCTP principle that a window cannot shrink by moving the
            right edge...)
    *Sender receiving the SACK, will send another Data chunk of size 1500 when
      SND.WND = 500 ( this is allowed according to the RFC, "However,
      regardless of the value of rwnd (including if it  is 0), the data sender can always
      have one DATA chunk in flight to    the receiver if allowed by cwnd (see rule B
      below). )

    *Receiver on receivin this data chunk will do the check as specified above
        ( data chunk's size is less than Rwnd), since this check fails, it will drop the
        packet and sends a SACK of ARwnd = 500....

            Here again we came to the same issue as the first one.... Here we never
go into "Zero Window Probing" as we never get ARwnd = 0......

Are the issues making sense... Atleast for me... its totally confusing.....  The Probing
ideas given in the draft is condradictory in the sense, the Send side Alg  follows the
TCP way, but not the Receive side.... ( I guess in TCP,  when the ARwnd is zero,
it will still accept the data chunks from the Sender.... anyway in TCP case the
zero window probing will be done with "one byte", but in SCTP a whole CHUNK
is sent....)

Thanks
-arun

--
****************************************************************
V.Arun Prasad
HCL Technologies Ltd.
51, Jawaharlal Nehru Road,
Ekkattuthangal,
Guindy Industrial Estate,
Chennai - 600097.

Contact # : 9144 - 2334174
            9144 - 2334181
            extn : 233
****************************************************************