Chronological Thread 

< Chronological >      < Thread >

---

Dear all,

Some new questions about restart:

1. I've found the comments about checking the new remote addresses on
receiving of COOKIE_ECHO. Why should this done so late? Because it is
possible to check the new addresses and streams on receive of INIT.

2. How should the receiver of INIT react if it receives invalid stream nos
or addresses. I think it should answer with an ABORT with invalid mandatory
parameter in case of invalid streams and with the new operational error
'Restarting association adds an address, restart refused' as described in
the backoff document in case of invalid addresses. Are there any drafts
about the new operational error?
In addition the receiver should delete its association. Or is it better to
introduce a new operational error also for invalid streams in case of a
restart?



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: Meyknecht Bernward
> [mailto:Bernward.Meyknecht AT icn.siemens.de]
> Gesendet am: Montag, 12. Februar 2001 17:37
> An:
> 'discussion AT sctp.de'
> Betreff: AW: [SCTP-Discussion] some questions to prototype 0.10.0
>
>
> Hi,
>
> concerning point 2.:
>
> the corresp. code segment should be
> distribution.c, line 864,
> where the tag is saved.
>
> initChunk = ((SCTP_init_fixed *) & ((SCTP_init *)
> message->sctp_pdu)->init_fixed);
> /* make sure, if you send an ABORT later on (i.e. when peer
> requests 0 streams),
> * you pick the right tag */
> lastInitiateTag = ntohl(initChunk->init_tag);
> event_logi(VVERBOSE, "Got an INIT CHUNK with initiation-tag
> %u", lastInitiateTag);
>
> do well,
>
> Bernward
>
>
> > -----Urspr> üngliche Nachricht-----
> > Von: Tuexen Michael
> > [SMTP:Michael.Tuexen AT icn.siemens.de]
> > Gesendet am: Montag, 12. Februar 2001 17:03
> > An:
> > 'discussion AT sctp.de'
> > Betreff: RE: [SCTP-Discussion] some questions to prototype 0.10.0
> >
> > Dear all,
> > see my comments below.
> > Best regards
> > 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: Hollaus Thomas
> > > [SMTP:thomas.hollaus AT siemens.at]
> > > Sent: Monday, February 12, 2001 2:33 PM
> > > To:
> > > 'discussion AT sctp.de'
> > > Subject: [SCTP-Discussion] some questions to prototype 0.10.0
> > >
> > > Hi,
> > >
> > > I have some questions to prototype 0.10.0:
> > >
> > > 1. SCTP-control.c:
> > > TODO: check that in SHUTDOWN states we reset the
> retransmission counters,
> > > any time we get a valid datagram from our peer. This must
> also be done for
> > > SACKs, DATA, etc. we get from peer !
> > > -> I have not found anything about that in the RFC or
> backoff document.
> > > Where does that come from?
> > [Tuexen Michael] I do not know. Andreas do you know a reason?
> > >
> > > 2. SCTP-control.c procedure scr_init line 646:
> > > save a-sides init-tag from init-chunk to be used as a
> verification tag of
> > > the sctp-message carrying the initAck (required since
> peer may have changed
> > > the verification tag).
> > > mdi_writeLastInitiateTag(ch_initiateTag(initCID)); */
> > > -> Why is this under comments? Why is it not necessary to
> save the remote
> > > tag for responding? Is it stored in an other code fragment?
> > >
> > [Tuexen Michael] Andreas, could you answer this?
> >
> > > 3. Restart of peer:
> > > The backoff document says that it is allowed to restart
> with a subset of the
> > > original address list. But how new number of streams
> should be handled? Is
> > > it allowed to restart with less or more streams?
> > >
> > [Tuexen Michael] The number of streams should be the same
> > as before. That is as least what I think. But the RFC is
> > probably a bit vage on that.
> > > How restart should be handled in general? Should the own
> side (which
> > > receives the restart) discard all data in its queues and
> react like
> > > receiving a new association setup with all data lost of previous
> > > association?
> > [Tuexen Michael] The transmission queue has not
> > to be deleted. But that is implementation dependent.
> > The rest has to be reset.
> > > Currently (in prototype 0.10.0) a restart is implemented
> for flow control
> > > and receive control. But it arises the question if that
> makes sense: Because
> > > it could happen that the remote side (which restarts) has
> acked data chunks
> > > in sctp layer but the upper layer has not yet received
> the datagrams from
> > > sctp layer (e.g. due to crash). Flow control/Reliable
> transfer on the own
> > > side believes that the remote side has received the
> datagrams and does not
> > > repeat that chunks. Now the remote side has gaps and
> cannot detect them.
> > [Tuexen Michael] This will result in data loss. This
> > is indicated bt the restart indication.
> >
> >
> > > Mit freundlichen Gruessen / Best regards
> > > Thomas Hollaus
> > >
> > > SIEMENS AG Österreich
> > > Program and Systems Engineering
> > > mailto:thomas.hollaus AT siemens.at
> > > http://www.siemens.at/
> > > _______________________________________________
> > > discussion mailing list
> > > discussion AT sctp.de
> > > http://www.sctp.de/mailman/listinfo/discussion
> > _______________________________________________>
> > discussion mailing list
> > discussion AT sctp.de
> > http://www.sctp.de/mailman/listinfo/discussion
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion
>

---

• AW: [SCTP-Discussion] some questions to prototype 0.10.0, Meyknecht Bernward, 02/12/2001
  • <Possible follow-up(s)>
  • AW: [SCTP-Discussion] some questions to prototype 0.10.0, Hollaus Thomas, 02/13/2001

---

Archive powered by MHonArc 2.6.19+.