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

From: [email-masked]
Date: Thu, 14 Mar 2002 20:16:40 +0200

Hi Arun!!
 
    Please, see some comments inline...

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...) ... 

[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...

     * 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...

     *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...

 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....) 

[Arias-Rodriguez Ivan (NRC/Helsinki)] Yep, but just one chunk... Of course, you could in theory make this chunk as small as you want (however, this is not always possible, as if you are retransmitting a TSN, it must be exactly the same one)

I hope it helped!

BR Iván Arias Rodríguez

 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 
**************************************************************** 

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Arun Prasad <[email-masked]>
Date: Fri, 15 Mar 2002 09:21:10 +0530

Hi Ivan,
    Thanks for the response....  Please see the comments inline...

>         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......

> [Arias-Rodriguez Ivan (NRC/Helsinki)] I guess this question is answered by my previous comment...

        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......

> [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…

        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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 14 Mar 2002 22:22:43 -0600

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.

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.

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:

>          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...
>      
>      
>      [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...
>      
>      [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...
>      
>                extn: 233

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ 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 ¦

---

From: Arun Prasad <[email-masked]>
Date: Fri, 15 Mar 2002 10:15:22 +0530

Setting the reply delimiters and resending the message, as the previous message
was not clear....

Thanks
-arun

Arun Prasad wrote:

>>     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...
>>

<arun>

<arun end>

>> [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...
>>
>

<arun>
can always have one DATA chunk in flight to    the receiver if allowed by cwnd".
<arun end>

>> [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...
>

<arun>
<arun end>

Thanks
-arun

---

From: Arun Prasad <[email-masked]>
Date: Fri, 15 Mar 2002 11:05:38 +0530

Hi Brian,
    Comments inline......

> you will not lose the association on a zero window probe of

        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....

> start advertizing a zero receive window.  This way there is no

        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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 14 Mar 2002 23:57:46 -0600

Arun,

On Fri, 15 Mar 2002, Arun Prasad wrote:

>            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....

Yup.  However, the imp guide also allows the implementation to not
timeout the destination in the first place if the a_rwnd = 0.  This is
necessary because heartbeats can be suppressed on a destination basis.

>            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."

This does not say that the endpoint must discard anything.  Nor does it
say that the endpoint is not permitted to ack chunks and slop the 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...

Don't discard the chunk.  Accept it, SACK it, and advertize a_rwnd = 0.
IMO an implementation should never discard messages due to insufficient
receive buffer space without advertising a_rwnd = 0.

--brian

>        * 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....
>    
>                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
>    
>      
>      
>      >              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
>      >       clear the error counter of the destination transport
>      address to
>      >    which
>      >        * 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
>      >          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
>      >      [Arias-Rodriguez Ivan (NRC/Helsinki)] I guess this question
>      is
>      >      answered by my previous comment...
>      >
>      >
>      >       *********************
>      >         valid DATA chunk when the DATA chunk received is inside
>      its
>      >      receive
>      >         window."
>      >
>      >          * 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
>      >            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). )
>      >
>      >            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
>      >
>      >           *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
>      >                  Here again we came to the same issue as the
>      first
>      >      one.... Here we never
>      >            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...
>      [1]http://www.openss7.org/ ¦ trying  to adapt the  world  to
>      himself. ¦
>      [2]https://www1.ietf.org/mailman/listinfo/tsvwg
>      
>    --
> References
>    1. http://www.openss7.org/
>    2. https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Arun Prasad <[email-masked]>
Date: Fri, 15 Mar 2002 11:48:50 +0530

Hi Brian

> necessary because heartbeats can be suppressed on a destination basis.

        Thanks a bunch for clearing this.....
        Then to handle "not timeout the destination in the first place if the a_rwnd = 0"
         I think we have to have an additional check during  T3 timer expiry.....
            * If the (ARwnd = 0) then dont increament the Retrans counter......
               Because in this scenario the T3 timer is acting like a "Persist timer" or
                "Zero window probing timer"......
        This I think will ensure that the Retrans counter doesnt reach the Threshold
    and start sending HB chunk.....
        I think the above is ok.....

> say that the endpoint is not permitted to ack chunks and slop the receive

    Ok...

> receive buffer space without advertising a_rwnd = 0.

    I agree.....

Thanks
-arun

> discussion mailing list
> [email-masked]
> http://www.sctp.de/mailman/listinfo/discussion

---

From: Randall Stewart <[email-masked]>
Date: Fri, 15 Mar 2002 05:32:27 -0600

Arun:

Actually I set a flag in my data chunk tracking
structure to indicate that the chunk is being
used as a window probe.

And of course if the arwnd is NOT 0 you should accept
the chunk as Brian suggests... In general I have my
SWS setup in such a way that if we go below a MTU size
unit we drop to 0 on the sender side.. and the receiver
side scales its SWS avoidance to 1/4 of the total receiver
buffer space... so when I get 3/4 full I drop my rwnd
to 1... if I fill all the way.. I drop it to 0 and start
to discard...

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Randall Stewart <[email-masked]>
Date: Fri, 15 Mar 2002 05:27:07 -0600

Arun:

Some early morning comments.. coffee firmly in hand :>

> Association... which should not be done......

Any time you send a chunk with the rwnd set to 0 this IS a
window probe. We probably need some additional clearification in
the implementors guide here.. When doing a zero window probe
then you should NOT count against the error thresholds.

> > 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...
> >
> 

Actually I think that is quoted from the RFC.. and just reproduced
in the draft... i.e. it does not change.

Whenever you have a data chunk to send that exceeds the rwnd
(i.e. rwnd=500 and say my only data chunk is 1000bytes) and
no other data in-flight then you WOULD need to treat this send 
as a window probe. Now the big difference with this one is that
the receiver IS allowed to accept it.

Also note the receiver and the sender SHOULD be doing SWS avoidance
so that hopefully this situation would be less likely.

Note because of this MUST discard when the rwnd is 0 provision we
do have an interesting scenario. Since you may want the next 
chunk and if the rwnd is 0 you are required to drop the chunk.

What I did (at Michael Tuexen's nice suggestion) is that when
I kick in SWS avoidance I set my rwnd to 1 NOT 0. This then
allows me to accept the data (if it is the next TSN I want).
And of course my sender side SWS will consider 1 to be a rwnd
of 0... so this works very nicely :>

R

---

From: Arun Prasad <[email-masked]>
Date: Fri, 15 Mar 2002 18:50:25 +0530

R,
    Comments inline....

> >         I think the above is ok.....

        Getting a flaw in my own suggestion..... In the above suggestion things will
    work well, if there is no Path Error... If the link becomes during the Zero
    window probe, then from the above method the Endpoint will keep on
    continuing the "Zero window probe"....because the Retrans counter is never
    increamented as the zero window probe is going on...... So this method wont
    work.....
        We have to definitely keep track of the zero window probe packet sent and
    a SACK is received for it.... If no SACK is received for a Zero Window probe
    then the while T3 expires the Retrans counter should be increamented for that
    path......

        To achieve this we can have the following check when we receive the SACK
    during zero window probe....
            * Check if the the ARwnd in SACK is zero and currently the endpoint
                is in zero window probe (this means only one data chunk will be
                outstanding...)
                    If thats the case then treat this Acknowledgement as the
                Acknowledgement for the Path on which the only OutStanding data
                chunk is sent..... By considering this way the Retrans.Counter will
                be cleared if the SACK arrives constantly for every zero window probe...
                If the SACK doesnt come for the zero window probing data chunk
                (due to path error) then the T3 timer will expire N times which make
                the error counter to reach the Threshold and the Path is Deactivated......

        Is the above solution ok.......  I think its better to put some standard solution
in the draft... otherwise each implementer will implement in his own way and end up
with a buggy stack.....

---

From: Randall Stewart <[email-masked]>
Date: Fri, 15 Mar 2002 08:07:15 -0600

Arun:

I did not mention the failing link issue :> I had thought
of it though.. I think it is up to the implementation on
how you wish to solve it. What I did is always rotate
the Window-Probe to an alternate destination.. but do
no thresholding. I figured I would let the HB's take
care of the failure. This makes the handling simpler..

But I think this is an implementation choice...

R

---

From: Arun Prasad <[email-masked]>
Date: Mon, 18 Mar 2002 20:47:29 +0530

Hi all,
    This is the Scenario.... Iam setting the
Local Rwnd = 1500 .....

Since its recomended that SSThresh should be equal to Rwnd at Init time...
Ssthresh = 1500

Now the initial Cwnd = 2* MTU (say 3000)

    Now its in the condition that in the init time itself (Cwnd  > SsThreshold).. So
directly the state goes to "Congestion Avoidance" (as Cwnd >SsThreshold)....

    Ya, its wrong to have Cwnd >SSthresh at Init time..... But how should I ensure
that the Ssthreshold is set to a bigger value..... Any  other recomended value for
Ssthreshold is there ??

    ( We can very well have the minimum limit of Ssthreshol be greater than
        2*MTU..... But curious to know what can be this value.... if Rwnd is less
        than 2 *MTU)...

From Rfc 2960:
" The initial cwnd before DATA transmission or after a sufficiently
      long idle period MUST be <= 2*MTU."

"   o  The initial value of ssthresh MAY be arbitrarily high (for
      example, implementations MAY use the size of the receiver
      advertised window)."

" A SCTP receiver MUST be able to receive a minimum of 1500 bytes in
   one SCTP packet.  :

Thanks
-arun

---

From: Randall Stewart <[email-masked]>
Date: Wed, 27 Mar 2002 08:32:27 -0600

>       example, implementations MAY use the size of the receiver

A couple of observations:

1) If your peer is limiting you to 1500 bytes no matter if
   you are in slow-start or CA you are stuck sending only one
   segment at a time.

2) You can never grow your cwnd if your peer limits the rwnd
   below the value of cwnd.

So I don't think it makes any difference in this case that
you set it and entered CA right away.. you are not going
to have very good performance due to the strict limitiation
of the peers rwnd.

R