Subject: RE: [Tsvwg] sctp Window deadlock

From: [email-masked]
Date: Tue, 5 Feb 2002 16:43:08 +0200

Hi all!
 
    Well, I think that the point here is that once the T3 timer expires on an address, all the TSNs that were outstanding on that address are automatically marked for retransmission, i.e, they are not outstanding TSNs any longer...
 
    In this situation, as you are allowed to have at least one TSN outstanding no matter the value of rwnd, you will send the oldest TSN marked for retransmission and restart the T3 again (if possible using another different address than the first time)...
 
    After several failures, you will abort the association... It might take time (RTO.Max is one minute), but at the end you get rid of the association...
 
    However... If the path heartbeat mechanism is enabled, every received HEARTBEAT ACK chunk will erase the retransmission counter... Thus we are in the same problem... But this is because the receiver is not behaving in the expected way...
 
    BR Iván Arias Rodríguez

-----Original Message-----
From: ext Arun Prasad [mailto:[email-masked]]
Sent: 05. February 2002 16:37
To: Ashraf
Cc: Tsvwg; Randall Stewart
Subject: Re: [Tsvwg] sctp Window deadlock

hi Ashraf, 

From 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 

    My understanding from the above is, trying to send the Data chunk only once 
for probing, and if that chunk is not acknowledged (or acknowledged with rwnd 
as zero), then even when the Rtx timer expires for that Data chunk, the data chunk 
will be queued in the local Q (as the rwnd is zero, and already one data chunk 
has been sent for probing...) and will not be retransimtted..... 
    I dont know whether my understanding is right......  Just getting a feeling that 
Iam going wrong somewhere....( might be ur understanding is right.....) 
Somebody please clarify..... 

Thanks 
-arun 

Ashraf wrote: 

Hi, 
    My understanding is ( pls correct me if I am wromg),  each time when the timer expires, the path /assoc retrans counter will be 

incremented and sender keeps on probing  for change in window size  by sending next fragment ( in ur caase fragment B ) and  ending 

up in T3 timer expiry each time. Will the Assoc will be  terminated once this count reached the threshold value.?" 

Thanks, 
ashraf 

Arun Prasad wrote: 

> Hi Ashraf, 
>     ya RTT timer will be started, but upon its expiry, we come to the same problem.. 
> because we cant send the retransmitted packets due to rwnd shortage...... 
> 
> Thanks 
> -arun 
> 
> Ashraf wrote: 
> 
> > Hi arun, 
> >     I think  for the new data chunk ( which we are sending  to probe for change in window), we start RTT timer and  give 
> > appropraite treatment, when it expires. 
> > 
> > thanks, 
> > ashraf 
> > 
> > Arun Prasad wrote: 
> > 
> > > Hi Ashraf, 
> > >     Thanks for the rsp.... 
> > > ya, I agree that partial-delivery will solve the problem... But imagine an errornous 
> > > stack ( or SCTP stack which didnt implement the partial delivery API)  is on the 
> > > receiving side.... Then with the below example scenario, the Sender stack will 
> > > get stuck.... ie.,  the association will never tear down (as RTX timer is not running) 
> > > so the Sender side will be hung (with no mistake on its side....) forever..... 
> > > I think this situation should be avoided...... 
> > > 
> > > Thanks 
> > > -arun 
> > > 
> > > Ashraf wrote: 
> > > 
> > > > Arun, 
> > > >     This is what RFC has to say : 
> > > > "If the data receiver  run out of buffer space while still  waiting for  for more fragments 
> > > > to complete the re-assembly, of the message, it should dispatch part of its inbound message 
> > > > through a partial deliver API, freeing some if its buffer space in order receive  rest of 
> > > > the message" 
> > > > 
> > > > guess this should take care of the deadlock  situation you are mentioning here. 
> > > > 
> > > > Thanks, 
> > > > Mohd. Ashraf 
> > > > Arun Prasad wrote: 
> > > > 
> > > > > Hi all, 
> > > > >     The question might be more of  SCTP implementation specific....   According 
> > > > > to the SCTP rfc2960, the data sender should not send any data packets if it doesnt 
> > > > > have enough Send-Windown (Peer Rwnd).... Just take the below example.... 
> > > > > 
> > > > > The Peer's Rwnd (at the Init time ) is 1500 bytes. 
> > > > > The Sender receivies a data buffer of size 6000 from its upper layer to be sent 
> > > > > to the Peer.... The Sender will then fragment the packets to fragments A,B,C,D of 
> > > > > size 1500 bytes (because the local mtu size is 1500bytes).... 
> > > > > Now the Sender sends the frag A to the Peer... Upon receiving the frag A, the 
> > > > > Peer's Rwnd will be zero.... This is informed to the Sender by sending a SACK with 
> > > > > rwnd as 0. The Sender which would have queued the frags B,C,D... will then 
> > > > > send frag B as the probing data to the Peer... The peer again will respond with 
> > > > > a SACK of rwnd 0 .  Now the deadlock situation occurs,  as the 
> > > > >     * Sender cant send any more data packets as the Peer's rwnd is zero.... 
> > > > >     * Peer cant increase its rwnd till it releases the data chunks which it had already 
> > > > >        received,  but to release that it needs to reassemble the frags (ABCD) and 
> > > > >       deliver it to the above layer, only then it can release the buffers..... Since its 
> > > > >       waiting for the frags C and D...  this will never release the buffers.... so 
> > > > >       will not increase the rwnd..... 
> > > > > 
> > > > > This situation can be avoided if the Sender doesnt sent Data messages of size 
> > > > > greater than the Peer's rwnd.... But the Rfc doesnt say anything about this..... 
> > > > > Or there should be some timers, to get out of the Deadlock situation..... 
> > > > > 
> > > > > Any suggestions........ 
> > > > > 
> > > > > Thanks 
> > > > > -arun 
> > > > > 
> > > > > _______________________________________________ 
> > > > > tsvwg mailing list 
> > > > > [email-masked] 
> > > > > https://www1.ietf.org/mailman/listinfo/tsvwg 
> > > > 
> > > >   ------------------------------------------------------------------------------------------------------------------------ 
> > > >                            Name: Wipro_Disclaimer.txt 
> > > >    Wipro_Disclaimer.txt    Type: Plain Text (text/plain) 
> > > >                        Encoding: 7bit 
> > > 
> > > -- 
> > > **************************************************************** 
> > > 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 
> > 
> >   ------------------------------------------------------------------------------------------------------------------------ 
> >                            Name: Wipro_Disclaimer.txt 
> >    Wipro_Disclaimer.txt    Type: Plain Text (text/plain) 
> >                        Encoding: 7bit 
> 
> -- 
> **************************************************************** 
> V.Arun Prasad 
> HCL Technologies Ltd. 
> 51, Jawaharlal Nehru Road, 
> Ekkattuthangal, 
> Guindy Industrial Estate, 
> Chennai - 600097. 
> 
> Contact # : 9144 - 2334174 
>             9144 - 2334181 
>             extn : 233 
> **************************************************************** 

  ------------------------------------------------------------------------------------------------------------------------ 
                           Name: Wipro_Disclaimer.txt 
   Wipro_Disclaimer.txt    Type: Plain Text (text/plain) 
                       Encoding: 7bit

-- 
**************************************************************** 
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: Randall Stewart <[email-masked]>
Date: Tue, 05 Feb 2002 09:50:20 -0600

Ivan:

I agree with all your assesement except I would NOT count
the T3 against anything towards failure (no matter if
HB's are running or not) if we are doing widow-probes.

I run special code for this when we get in the window-probe
mode... And no threshold managment is done... 

This is the same thing that happens in TCP (if my understanding
is correct).. i.e. once the sender clamps the rwnd=0 you
will continue to probe until it opens up.. as long as
you get a SACK back that is...

R

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

---

From: Arun Prasad <[email-masked]>
Date: Wed, 06 Feb 2002 10:29:19 +0530

Hi Randal,
    Yes, in TCP there is a timer called "Persist timer", which is used for the Probing
activity and not the T3 timer... and this has no threshold as u mentioned.....
    But  if this the procedure to be followed, then why its not specified in the Rfc
and the implementation guides (or yet to be included....).  What I thought is,
if the procedure is to be followed then it should be there in the Rfc (atleast
with the MAY condition).......
Or we should go to the tcp implementation for all these conditions which are
missing in the SCTP Rfc  :)

Or did I miss something in the imp guides and Rfc !!!!

Thanks
-arun

---

From: Randall Stewart <[email-masked]>
Date: Wed, 06 Feb 2002 04:49:59 -0600

> Or did I miss something in the imp guides and Rfc !!!!

Section 2.15 of the implementation guide

---
Randall R. Stewart

---

From: Arun Prasad <[email-masked]>
Date: Wed, 06 Feb 2002 20:34:15 +0530

Hi Randel,
    Thanks, I missed it (or rather misunderstood it..... )....  I have one more
doubt in that.... will post it in a seperate mail....

Thanks
-arun