Chronological Thread 

< Chronological >      < Thread >

---

Dear all,
this seems to be a good description what to do in case of a restart.
Happy SCTPing
Michael

Michael Tüxen Tel.: +49 89 722 47210
Siemens AG Fax: +49 89 722 48212
ICN WN CS SE 51 E-mail:
Michael.Tuexen AT icn.siemens.de

> -----Original Message-----
> From: Randall R. Stewart
> [SMTP:randall AT stewart.chicago.il.us]
> Sent: Thursday, February 15, 2001 4:13 PM
> To: Hollaus Thomas
> Cc:
> SIGTRAN AT marvin.corpeast.baynetworks.com;
> Antonio Alonso Alarcon ECE/TL/NA TU-148 Tlf.3085; TUEXEN MICHAEL;
> 'Michael.Tuexen AT micmac.franken.de';
> Qiaobing Xie
> Subject: Re: AW: Number of streams in case of restart
>
> Thomas:
>
> Here is a quote from rfc2960 that deals
> with restart (its in5.2.4) :
>
> "
> A) In this case, the peer may have restarted. When the endpoint
> recognizes this potential 'restart', the existing session is
> treated the same as if it received an ABORT followed by a new
> COOKIE ECHO with the following exceptions:
>
> - Any SCTP DATA Chunks MAY be retained (this is an implementation
> specific option).
>
> - A notification of RESTART SHOULD be sent to the ULP instead of
> a "COMMUNICATION LOST" notification.
>
> All the congestion control parameters (e.g., cwnd, ssthresh)
> related to this peer MUST be reset to their initial values (see
> Section 6.2.1).
>
> After this the endpoint shall enter the ESTABLISHED state.
> "
>
> Note, I crafted this wording very very carefully to reflect the lines:
>
> "the existing session is treated the same as if it received an ABORT
> followed
> by a new COOKIE ECHO with the following exceptions:"
>
> The retention of data chunks is a OPTION only of the implementation. It
> is NOT required by the spec and in fact it is not even a SHOULD.
>
> The restart is in effect an ABORT followed by a valid cookie. In this
> scenario, all your streams are new. IF your implementation decides for
> some reason to re-queue data then it is UP to IT as to how to handle
> this situation when the stream numbers no longer match.. however if
> you HAD gotten a ABORT followed by a COOKIE.. what would have happened?
>
> What would have happened is ALL of the user datagrams would be passed
> back to the application, and then the new association would be
> setup....
>
>
>
>
> Hollaus Thomas wrote:
> >
> > Dear all,
> >
> > It's ok, but it is not clear how Z should handle chunks in its
> > transmission
> > queue with invalid stream nos (because A reduces MIB to a lower value than
> > Z's former OS).
> >
> > Variant 1:
> > Chunks with invalid stream nos will be discarded in transmission queue of
> > Z.
> > Problem: Z has to recalculate TSNs of all its chunks in the transmission
> > queue, otherwise it generates a gap.
> >
> > Variant 2:
> > Z neither does not discard chunks in its transmission queue nor
> > recalculate
> > anything. It simply transmit all as it is. A does recognize that chunks as
> > invalid, will send an ERROR chunk with invalid stream nos and discard that
> > chunks. After that all will be ok again. In the worst case some invalid
> > chunks will be sent but this variant is not complicated.
> >
> > I think it's not meaningful that the number of streams may be changed by
> > restart. Most applications have assignments of different tasks to its
> > streams. If the streams will be decreased by restart they cannot work
> > correctly and therefore will shutdown the association in most cases.
> >
>
> Since I consider a restart an ABORT followed by COOKIE I see no
> discrepancy here..
>
> > Another question arises what to do if a restart with more streams than Z
> > is
> > able to handle or invalid addresses will be received.
>
> This could not happen... remember you tell in your INIT-ACK how many
> streams you can handle in your MIS value. If the peer violates this
> by requesting more, he just does not have that many... same for>
> a regular INIT/INIT-ACK sequence...
>
> > Due to security reasons most of the checks should be done after receive of
> > COOKIE_ECHO (and not on INIT). If more streams than Z can handle will be
>
> No, you should be building the INIT-ACK/COOKIE as always new tags,
> setting
> your limits etc... It is just like a ordinary INIT processing with the
> exception that you fill in the tie-tags...
>
> > received Z would answer with error cause 'invalid mandatory parameter' in
> > normal case after received of INIT. On Restart Z may be answer with that
> > error after receive of COOKIE_ECHO, but this error is related to INIT and
> > therefore A will be a bit confused. Shouldn't we introduce a new error
> > cause
> > for that case?
>
> No this is the same as handling the normal INIT... no different. There
> is
> no confusion here. How would A be confused. It just restarted and sent
> an INIT. To it nothing exists previously...
>
> > The other case with invalid addresses is described in the backoff
> > document.
> > New error 'Restarting association adds an address, restart refused'. Is
> > there any draft for that error?
>
> There will be when we do the BIS. Not until.. Currently the
> BIS information is being folded into the bakeoff draft until such
> time as we are ready to start the BIS.
>
> >
> > Mit freundlichen Gruessen / Best regards
> > Thomas Hollaus
> >
> > SIEMENS AG Austria
> > Program and Systems Engineering
> > mailto:thomas.hollaus AT siemens.at
> > http://www.siemens.at/
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Michael Tüxen
> > > [mailto:Michael.Tuexen AT micmac.franken.de]
> > > Gesendet am: Mittwoch, 14. Februar 2001 18:54
> > > An: Qiaobing Xie
> > > Cc: Antonio Alonso Alarcon ECE/TL/NA TU-148 Tlf.3085;
> > > Michael.Tuexen AT ICN.SIEMENS.DE;
> > > SIGTRAN AT marvin.corpeast.baynetworks.com;
> > > sigtran AT marvin.corpeast.baynetworks.com;
> > > Randall R. Stewart
> > > Betreff: Re: Number of streams in case of restart
> > >
> > > Dear all,
> > > I can agree with that. But shouldn't we then change the description
> > > of the restart primitive. It should return the new values!
> > > Or should the user really use sctp_status after the restart primitive.
> > > Stating that would also be helpful. So is there something for the BIS
> > > draft?
> > > Best regards
> > >
> > > Qiaobing Xie wrote:
> > > >
> > > > I agree. The restart should be allowed by SCTP.
> > > >
> > > > However, the application at Z, after seeing the param changes in the
> > > > RESTART Notification, will ultimately make a decision on whether to
> > > > continue the communication with some re-arrangements on its
> > > stream usage
> > > > or to shutdown the restarted association. This decision is
> > > entirely up
> > > > to the application based on whether it considers the new
> > > stream numbers
> > > > are still work-able.
> > > >
> > > > -Q
> > > >
> > > > "Antonio Alonso Alarcon ECE/TL/NA TU-148 Tlf.3085" wrote:
> > > > >
> > > > > Hi !
> > > > >
> > > > > I think this is a valid "SCTP Re-start association" case.
> > > > > When node A fails, it sends a new INIT chunk which can
> > > > > carry different "OS", "MIS" and "IP address list" values.
> > > > >
> > > > > Due to security reasons, in last bakeoff was decided that
> > > > > the new "IP address list" must be the same list given in
> > > > > previous association or a subset (but no new IP addresses
> > > > > can be added). But nothing was said about changing the number
> > > > > of OS/MIS (and RCF does not say anything neither).
> > > > >
> > > > > I think the "RESTART notification" should give any
> > > > > info. about new "OS", "IS" and "remote IP addresses" values
> > > > > after the RESTART procedure (or the user should do what you
> > > > > say, invokink SCTP_STATUS to check if any of these values
> > > > > has changed after the RESTART)
> > > > >
> > > > > Regards / Antonio>
> > > > >
> > > > > > From: Tuexen Michael <Michael.Tuexen@icn.> siemens.de>
> > > > > > To:
> > > > > > sigtran AT marvin.corpeast.baynetworks.com
> > > > > > Subject: Number of streams in case of restart
> > > > > > Date: Tue, 13 Feb 2001 13:11:49 +0100
> > > > > > MIME-Version: 1.0
> > > > > > Content-Transfer-Encoding: quoted-printable
> > > > > > X-SMTP-HELO: gorilla.mchh.siemens.de
> > > > > > X-SMTP-MAIL-FROM:
> > > > > > Michael.Tuexen AT icn.siemens.de
> > > > > > X-SMTP-RCPT-TO:
> > > > > > sigtran AT standards.nortelnetworks.com
> > > > > > X-SMTP-PEER-INFO: [194.138.158.18]
> > > > > > X-Orig:
> > > > > > <lyndon_ong AT yahoo.com>
> > > > > >
> > > > > > Dear all,
> > > > > >
> > > > > > I need some lessons in SCTP restart behaviour.
> > > > > >
> > > > > > Consider the following case:
> > > > > >
> > > > > > Node A sends INIT with OS = 10, MIS=10
> > > > > > Node Z sends INIT-ACK with OS=10, MIS=10
> > > > > >
> > > > > > Finally the association will be up with 10 streams in
> > > both directions.
> > > > > >
> > > > > > Now node A fails and starts the restart procedure.
> > > > > > But Node A sends INIT with OS=10, MIS=5
> > > > > > Node Z can respond with OS = 5, MIS 10.
> > > > > >
> > > > > > The association can be established with 10 / 5 streams.
> > > > > >
> > > > > > Is this a valid restart szenario? Or is it invalid due to
> > > > > > the wrong numbers of streams?
> > > > > >
> > > > > > Using the API in RFC the user at Node Z has to ask for
> > > > > > the number of streams using the sctp_status primitive after
> > > > > > the restart notification.
> > > > > >
> > > > > > Best regards
> > > > > > Michael
> > > > > >
> > > > > > PS.: I'm sending this again, because sending to
> > > > > >
> > > > > > sigtran AT marvin.corpeast.baynetworks.com
> > > > > > does not work.
> > > > > >
> > > > > > Michael Tüxen Tel.: +49 89 722 47210
> > > > > > Siemens AG Fax: +49 89 722 48212
> > > > > > ICN WN CS SE 51 E-mail:
> > > > > > Michael.Tuexen AT icn.siemens.de
> > > > > >
> > > > >
> > > > > ///
> > > > > (@@)
> > > > > ___________o00_(____)_00o________________________
> > > > >
> > > > > Antonio Alonso Alarcón Ericsson R&D
> > > > > Phone: +34 91 339 3085
> > > > >
> > > > > ____________________Oooo.________________________
> > > > > .oooO ( )
> > > > > ( ) ) /
> > > > > \ ( (_/
> > > > > \_)
> > > > >
> > > > > file://home/emeaaal/public_html/atl-esc.gif
> > >
>
> --
> Randall R. Stewart
> randall AT stewart.chicago.il.us
> or
> rrs AT cisco.com
> 815-342-5222 (cell) 815-477-2127 (work)

---

• [SCTP-Discussion] FW: AW: Number of streams in case of restart, Tuexen Michael, 02/15/2001

---

Archive powered by MHonArc 2.6.19+.