Subject: [Tsvwg] RE: PR-SCTP question.

From: "Sellar, Ronnie" <[email-masked]>
Date: Tue, 6 May 2003 08:05:53 +0100

Hi,

Sending a SHUTDOWN or SHUTDOWN-ACK when all your data has been acked or
abandoned was the best solution we came up with.  We did realise that this
would mean some change to SHUTDOWN/SHUTDOWN-ACK processing for a PR-SCTP
implementation.  

We also thought it would be a good idea to raise this now so that any
solution could be tested in Delaware.  

So do we go ahead and code 1) and 2) in Randall's e-mail or do we have to
wait for some agreement from the authors ?

Thanks for your replies.

Ronnie 

---
Ronnie Sellar			Artesyn Communications Products
Tel: +44 131 475 7015		Suite 4, 2 Anderson Place
Fax: +44 131 475 7001		Edinburgh EH6 5NP
mailto:[email-masked]	http://www.artesyncp.com

> -----Original Message-----
> From: Randall Stewart (cisco) [mailto:[email-masked]]
> Sent: 05 May 2003 19:46
> To: [email-masked]
> Cc: [email-masked]; Sellar, Ronnie; Sctp-Impl (E-mail); Phillip T.
> Conrad; Qiaobing Xie; Michael Tüxen; Michael A. Ramalho
> Subject: Re: PR-SCTP question.
> 
> 
> Brian:
> 
> Seems like a much better solution than having a timer..
> 
> so we end up with:
> 
> 1) A note in PR-SCTP about the SHUTDOWN cases as you mention.
> 
> 2) A note in PR-SCTP regarding SACK's aka a FWD-TSN MUST be
>     treated as a DATA chunk in regard to sending SACK's ( I think
>     this is needed since there is no mention to it in the document
>     currently).
> 
> R
> 
> 
> Brian F. G. Bidulock wrote:
> 
> >Randall,
> >
> >If the FWD-TSN is treated in the same fashion as DATA is in the
> >base protocol with regard to the sending of SACK, in this case a
> >SACK would already be required by the base protocol would it
> >not?  So I don't think that there is a need for an alteration in
> >SACK processing.  IHO the problem appears to be (as you allude)
> >that for a normal DATA transmission there is a retransmit timer
> >running whereas for FWD-TSN there is not.  During normal data
> >transmission during the association, this is not problematic
> >because of the rules for sending subsequent FWD-TSN in receipt
> >of SACK.  It is only in this case where there is no further data
> >to send.
> >
> >As this only appears to be a problem in this one situation (not
> >subsequent DATA to send and no SACKs forthcoming), it might be
> >possible to handle this with a SHUTDOWN rule such as follows:
> >
> >Whenever the PR-SCTP sender enters the SHUTDOWN-PENDING state,
> >and there are only TSNs marked dropped for retransmission (for
> >which FWD-TSNs have been sent) a SHUTDOWN chunk is sent and the
> >sender enters the SHUTDOWN-SENT state.  (The same for
> >SHUTDOWN-RECEIVED and SHUTDOWN-ACK-SENT states.)
> >
> >Whenever the PR-SCTP receiver receives a SHUTDOWN or
> >SHUTDOWN-ACK and there are gaps in its received TSN sequence
> >(messages awaiting reordering before delivery to the user), it
> >will treat the SHUTDOWN or SHUTDOWN-ACK though it were a forward
> >TSN for all missing data chunks.
> >
> >The trick here is to not delay the SHUTDOWN (or SHUTDOWN-ACK)
> >chunk being sent waiting for acknowledgement of dropped TSNs
> >but to send it anyways with the knowledge that the receiver can
> >imply any missing TSNs as having been dropped.
> >
> >I think this would better meet the intent of PR-SCTP (and in
> >particular timed-reliability) as it does not rely on a timer to
> >arrive at the implication of a missed FWD-TSN.  The receipt of a
> >SHUTDOWN or SHUTDOWN-ACK can be treated as an implied FWD-TSN
> >for all outstanding data.
> >
> >Under the base protocol, what happens if a sender sends a
> >SHUTDOWN chunk *before* all its sent data is acknowledged?  I
> >think an implementation could either complete the shutdown and
> >discard data awaiting reordering, or ABORT the association.  For
> >PR-SCTP, receiving SHUTDOWN early could be construed as cause to
> >mark as dropped all outstanding data, and move the cummulative
> >ack point to the "highest" received TSN and complete the
> >SHUTDOWN procedure.
> >
> >Does that make sense?
> >
> >So effectively the rules would be that a SHUTDOWN or
> >SHUTDOWN-ACK should not be delayed in the SHUTDOWN-PENDING or
> >SHUTDOWN-RECEIVED states solely on the basis of unacknowledged
> >but "dropped" TSNs, and that a received SHUTDOWN or SHUTDOWN-ACK
> >chunk that is otherwise valid should be construed by the
> >receiver to have the same effect as a FWD-TSN dropping all
> >outstanding TSNs.
> >
> >Is that simpler than a timer?
> >
> >--brian
> >
> >
> >Whenever the receiver receives
> >
> >
> >On Mon, 05 May 2003, Randall Stewart (cisco) wrote:
> >
> >  
> >
> >>Ronnie:
> >>
> >>Nope, I don't think you are missing anything. I have been 
> testing the
> >>internal Cisco-IOS implementation of PR-SCTP against the KAME stack
> >>and have reached the same conclusion. I think we need to 
> require that the
> >>receiver of a FWD-TSN send a SACK in reponse to this. Otherwise
> >>you have this deadlock scenario.... I have made the KAME stack
> >>send the SACK.. but this then begs another question...
> >>
> >>If the SACK in the return path was lost (I am testing at times with
> >>error rates set to 20%... so that happens a lot).. what do we do?
> >>
> >>It almost sounds like we need not only to require a FWD-TSN get
> >>a SACK in response.. but that the sender of the FWD-TSN, if no
> >>other data is being sent, start a timer to retransmit the FWD-TSN
> >>if no SACK is received.. not sure if I worded that clear but I think
> >>it will be needed...
> >>
> >>Co-authors.. what do you-all think?
> >>
> >>R
> >>
> >>
> >>Sellar, Ronnie wrote:
> >>
> >>    
> >>
> >>>Hi,
> >>>
> >>>We have just started looking at PR-SCTP with a view to 
> having a prototype
> >>>implementation ready for the next Interop in Delaware and 
> have come up with
> >>>a question regarding the FORWARD-TSN chunk and how it could affect
> >>>association termination.
> >>>
> >>>Consider the following example.  Endpoint A has an 
> association with endpoint
> >>>B in which all the data it sends is ordered and marked as 
> 'unreliable' for
> >>>whatever reason.  Endpoint A has now sent all the data it 
> wants to send to B
> >>>but can't yet close the association because B has not yet 
> acknowledged one
> >>>of the TSNs.  Lets say that it has transmitted TSNs 1-100 
> but has not yet
> >>>received an acknowledgement of TSN 97 since B has not yet 
> received that TSN.
> >>>
> >>>In this situation A cannot yet send the SHUTDOWN since not 
> all data is acked
> >>>and B has three chunks it cannot deliver to it's user (98, 
> 99 and 100) since
> >>>it has not received 97.  When A receives the last SACK it 
> decides that it no
> >>>longer wants to retransmit chunk 97 and so issues a 
> FORWARD-TSN chunk to
> >>>move the cumulative ack TSN on to 100.  How does A know 
> that B received the
> >>>FORWARD-TSN chunk ?  There is no more data to send so B 
> will not be sending
> >>>any more SACKs.  If B sends no more SACKs A's cumulative 
> ack TSN will not
> >>>advance and so he will not be able to send the SHUTDOWN chunk.
> >>>
> >>>In B's case when he receives the FORWARD-TSN he will be 
> happy, deliver
> >>>98-100 to the user and move his cumulative TSN forward.  
> But he is not
> >>>required to send a SACK to tell A he has done so.  Are we 
> now in a stalemate
> >>>situation ?
> >>>
> >>>Also consider the case where B never receives the 
> FORWARD-TSN.  He is now
> >>>stuck with 98-100 in his buffers which he cannot deliver 
> since he doesn't
> >>>know that 97 is not coming.  Have we reached a similar stalemate ?
> >>>
> >>>Perhaps I'm missing something, but I do think there seems 
> to be a problem if
> >>>a FORWARD-TSN chunk is the last chunk to be transmitted on 
> an association.
> >>>Please feel free to correct me if I'm wrong.
> >>>
> >>>Cheers
> >>>
> >>>Ronnie 
> >>>
> >>>---
> >>>Ronnie Sellar			Artesyn Communications Products
> >>>Tel: +44 131 475 7015		Suite 4, 2 Anderson Place
> >>>Fax: +44 131 475 7001		Edinburgh EH6 5NP
> >>>mailto:[email-masked]	http://www.artesyncp.com
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>-- 
> >>Randall R. Stewart
> >>ITD
> >>Cisco Systems Inc.
> >>[email-masked] 815-342-5222(cell) or 815-477-2127(office)
> >>
> >>    
> >>
> >
> >  
> >
> 
> 
> -- 
> Randall R. Stewart
> ITD
> Cisco Systems Inc.
> [email-masked] 815-342-5222(cell) or 815-477-2127(office)
> 
> 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg