Chronological Thread 

< Chronological >      < Thread >

---

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: Tuesday, February 13, 2001 11:59 AM
> To:
> 'discussion AT sctp.de'
> Subject: AW: [SCTP-Discussion] some questions to prototype 0.10.0
>
> 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.
[Tuexen Michael] Following the 4 way handshake principle you
should not do a lot after reception of INITs. It is delayed after
reception of the COOKIE_ECHO for security reasons.

> 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?
[Tuexen Michael] I will start a discussion on the IETF mailing list.


> 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
> >
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

---

• [SCTP-Discussion] some questions to prototype 0.10.0, Hollaus Thomas, 02/12/2001
  • [SCTP-Discussion] Re: some questions to prototype 0.10.0, Andreas Jungmaier, 02/13/2001
  • <Possible follow-up(s)>
  • RE: [SCTP-Discussion] some questions to prototype 0.10.0, Tuexen Michael, 02/12/2001
  • RE: [SCTP-Discussion] some questions to prototype 0.10.0, Tuexen Michael, 02/13/2001

---

Archive powered by MHonArc 2.6.19+.