First login?
Lost password?
 
 
sctp-discussion AT lists.franken.de 
SCTP Discussions

Text archives Help


Re: [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt


Chronological Thread 
  • From: Arun Prasad <arun AT netlab.hcltech.com>
  • To: bidulock AT openss7.org
  • Cc: discussion AT sctp.de, tsvwg AT ietf.org, sctpimp AT netlab.hcltech.com
  • Subject: Re: [SCTP-Discussion] RE: [Tsvwg] contradiction in draft-ietf-tsvwg-sctpimpguide-03.txt
  • Date: Fri Mar 15 06:37:01 2002
  • List-id: SCTP Discussions <discussion.sctp.de>
Hi Brian,
    Comments inline......

"Brian F. G. Bidulock" wrote:

Arun,

The association does not time out because when doing a zero
window probe there is nothing to use to calculate RTT, so
a Heartbeat must be sent to the destination within the hearbeat
interval.  When the Hearbeat Ack is succesfully returned, the
retransmission counts are cleared.  If you use the recommended
values for heartbeat interval, RTO min, and path max retrans
you will not lose the association on a zero window probe of
indefinite length.

        Ha, I got the point.....The thing which I missed is the HeartBeatAck
and clearing of the Rtx counter..... I think the  the first issue is cleared ...
Now I could derive the solution for it... See if that is ok...

    * There is no need of maintaining a seperate timer for the Zero Window
        probing, as the T3 timer will automatically do this job....
    * There is no special processing required for the zero window probing except
        the following check, the rest can follow the procedures Rfc 2960...
                Check:
                    *While trying to send a Data chunk (either new or Retransmitted one..)
                       and if the SND.WND=0 (Effective SendWindow)  then the Data
                        chunk is sent to the peer only if there is no Outstanding chunks.........
                And by continuiuing this, will lead to the Rtx counter exceeding the
                Max.Retrans threshold.... then the path will become inactive and a HB is
                sent.... and when an HB-ACK is received.... the Path will again go to
                the ACTIVE state... and continue Retransmitting that Data chunk till the
                ARwnd is Non-zero....
 

 

In your example with a receive buffer of 500 and an incoming
data chunk of 1500, it is typical to not discard this chunk,
but to process it (let the rwnd slop by 1000 bytes) and then
start advertizing a zero receive window.  This way there is no
problem.

        But the  above  point contradicts the implementation guide... If I have
    understood the below lines properly.....
    "The SCTP endpoint MUST always acknowledge the reception of each
   valid DATA chunk when the DATA chunk received is inside its receive
   window."
        But even the Receiver discards the data chunk and sends a SACK of
ARwnd = non_zero_value..... the sender will still have the SND.WND as zero
and will be doing the zero window probing.......  The below is that scenario....

    * Sender sends a data chunk of size 1500 when its SND.WND=500 (because
       one data chunk is allowed to be sent when the Rwnd is not sufficient...)
    * Receiver receiving this will discard the chunk as it has the Rwnd= 500.....
        And Sends the Sack as ARwnd = 500...
    * Sender upon receiving the SACK, will update its SND.WND as
            SND.WND = (500 - 1500) ( ARwnd - number of bytes in flight)
            SND.WND = 0
    * Then when the T3 timer expires, the Sender will have no OutStanding Data
        bytes and its SND.WND is zero...... So it will again resend this Data chunk....
 
    This continues as the first case (explained above  in the first comment...), as usual
    T3 expires for N times, the path goes INACTIVE... and after sending and
    receiving the HB-ACK, again transmission continues......
 

            I think the above illustrations seems to solve the querries... If my assumption
is not valid or if I have missed some point, please point out....

Thanks
-arun

 

Both these procedures are provided for by RFC 2960 and the
implementation guide.  We just wanted to clarify some things
that was not so clear in RFC 2960.

--brian

On Fri, 15 Mar 2002, Arun Prasad wrote:

>
>    Hi Ivan,
>        Thanks for the response....  Please see the comments inline...
>
>
>      [Arias-Rodriguez Ivan (NRC/Helsinki)] :-/
>
>          What is then a "zero window probe"? I guess that the concept
>      applies to any DATA chunk sent when rwnd is zero... So, it seems to
>      me that you are doing a zero window probe here...
>
>          Maybe the mistake comes from the fact that once the T3 timer
>      expires, the DATA chunk is marked for retransmission and thus, not
>      considered outstanding any more...
>
>          Since it is not outstanding, you immediately make a zero window
>      probe... I hope I'm not missing anything...
>
>
>              I accept with you, that when T3 timer expires,  there will
>      be no Outstanding
>
>    data, and the same data chunk will be retransmitted... as a zero
>    window probe...
>    But when the procedure continues, the T3 timer will expire for say the
>    Max.Retrans
>    threshold value and then the Path goes down (if its the only path
>    Assoc goes down..)
>    The error counter will not be clear when SACK is received due to the
>    following
>    condition....
>    Sec 8.2 of 2960:
>        When an outstanding TSN is acknowledged or a HEARTBEAT sent to
>    that
>       address is acknowledged with a HEARTBEAT ACK, the endpoint shall
>       clear the error counter of the destination transport address to
>    which
>       the DATA chunk was last sent (or HEARTBEAT was sent).
>
>
>    So I think it should be made clear....... My suggestiong are ...
>
>        * When a Data Chunk is to be sent and (SND.WND = 0) then  the
>    transmission
>            should be considered "Zero Window Probe"  and T3 timer should
>    not be
>            started.....  Instead some timer say like "Persist Timer"
>    should be started.
>            When the Persist timer expires, the same data chunk should be
>    again used
>            for "Zero Wnd Probe".... this procedure should follow till the
>    Peer advertises
>            a non-zero window....
>                                OR
>        * When a T3 timer expires and the (ARwnd = 0) then the Rtx Counter
>    should
>            not be increamented  ( this ensures that the counter will not
>    reach the threshold
>            and make the Path INACTIVE)...    This ensures that during
>    "Zero Window
>            probe" the T3 timer will act as the "Persist timer"... and
>    this will come to
>            normal when the  the endpoint receives a SACK with non-zero
>    ARwnd.....
>
>                I think if we dont follow any of the schemes as above, we
>    will end up in
>    mixing the Retransmission procedure with the Zero Windo Probe.. and
>    Aborting the
>    Association... which should not be done......
>
>
>
>
>
>           * 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 )
>
>      [Arias-Rodriguez Ivan (NRC/Helsinki)] I guess this question is
>      answered by my previous comment...
>
>
>       *********************
>          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...)
>
>      [Arias-Rodriguez Ivan (NRC/Helsinki)]
>
>          *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). )
>
>      [Arias-Rodriguez Ivan (NRC/Helsinki)] Yes, but this means that you
>      are not supposed to surpass rwnd. You can always have one DATA
>      chunk outstanding, but I think that the only special case when you
>      can surpass the rwnd is when the received a_rwnd is 0 and you don't
>      have any TSN outstanding...
>
>            I think ur statement above contradicts the the statement from
>    the draft.....
>    "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"
>
>          It says, "Including if it is 0".... which I think means... any
>      ARwnd value even it is
>
>    zero.....  Have I misunderstood something here......
>
>
>
>           *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......
>
>      [Arias-Rodriguez Ivan (NRC/Helsinki)] Yes, you are right... The
>      point is that you shouldn't send a DATA chunk carrying more user
>      data than the rwnd allows... unless it is completely impossible not
>      to surpass this value, i.e. you make a 0 window probe...
>
>            Again Iam to the same confusion.....  and couldnt get the
>    solutions for my
>    doubt of "when the Receiver drops the Data chunk from the Sender
>    because it
>    doesnt contain enough Rwnd.... and it contiues to advertise the small
>    ARwnd (non
>    zero) it has....  Which will not trigger the "Zero window probe
>    procedure" in the
>    Sender side...
>            Not sure where Iam missing, but Iam missing something.....
>
>
>
>
>    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
>    ****************************************************************

--
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock AT openss7.org    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

_______________________________________________
tsvwg mailing list
tsvwg AT ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg

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

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


Archive powered by MHonArc 2.6.19+.

Top of page