SCTP Discussions

Text archives Help


RE: [SCTP-Discussion] Re: some questions to prototype 0.10.0


Chronological Thread 
  • From: Tuexen Michael <Michael.Tuexen AT icn.siemens.de>
  • To: "'discussion AT sctp.de'" <discussion AT sctp.de>
  • Subject: RE: [SCTP-Discussion] Re: some questions to prototype 0.10.0
  • Date: Tue Feb 13 16:24:01 2001
  • List-id: SCTP Discussions <discussion.sctp.de>

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: Andreas Jungmaier
> [SMTP:ajung AT exp-math.uni-essen.de]
> Sent: Tuesday, February 13, 2001 4:01 PM
> To:
> discussion AT sctp.de
> Subject: [SCTP-Discussion] Re: some questions to prototype 0.10.0
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> > 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?
>
> The idea is that even if we send SHUTDOWN requests, and do not get
> back a SHUTDOWN ACK by the peer, we should at least stop increasing
> an error counter. That is the case that the other side has a lot more
> to send, but we try to shut down....I will have to look where I got
> that from. Probably from the RFC.
>
> > 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?
>
> It is probably :-) set appropriately in mdi_receiveMessage(), which is
> called before that. Setting of tags logically belongs to the distribution
> layer rather than SCTP-control. Which has been the reason to put it there,
> if I remember right....
>
> >
> > 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?
>
> Which backoff document ?
[Tuexen Michael] See the second draft of the list 'Other
SCTP related drafts' at http://www.sctp.de
>
> This is a question that should probably be asked on the SIGTRAN mailing
> list.
[Tuexen Michael] I sent a mail to the list, but the server
seems to be down. They should use RSerPool ...
> > 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?
>
> Dito.
>
> > 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.
>
> Well, "Restart" is one of the cases that have not been tested very
> thoroughly,
> as you might have guessed already. Somewhere I put comments in the source
> code that data might be lost if a module is destroyed, but has not been
> retrieved by the upper layer...we are working on a change in the
> implementation
> where modules are destroyed only on explicit instruction of the upper
> layer, so that should fix this.
>
> Michael had a number of suggestions for changes before a 1.0.0 release
> which I am currently coding. We will have a more consistent API, as well
> as a few simple example programs, a documentation manual of the API as>
> PDF file, and some more goodies.
>
> In the meantime, I would be happy to get some more feedback, especially
> precise bug-reports :-)
>
> Best regards,
>
> - -
>
> Andreas Jungmaier
>
> -
> ----------------------------------------------------------------------------
> E-mail is insecure. It may be read by other people, modified in the
> course of transmission, or even faked (see http://www.stopcarnivore.org) !
> To protect your E-mail, use encryption programs, such as PGP or GPG,
> which can be obtained for free from http://www.gnupg.org !!!!
> -
> ----------------------------------------------------------------------------
> Andreas Jungmaier, Dipl.-Ing.
> University of Essen email:
> ajung AT exp-math.uni-essen.de
> Computer Networking Technology Group Tel. : +49 (0201) 183-7636
> -
> ----------------------------------------------------------------------------
> PGP Public Key and Fingerprint: see http://www.exp-math.uni-essen.de/~ajung
> -
> ----------------------------------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE6iUwYd2Uw+xBvGUIRAubkAJ0Ufhcte+Pfa3nq/IZ+huCd/je5XgCeOk8o
> hvTFYujWSoj7WfLRZFNb7MI=
> =/SqJ
> -----END PGP SIGNATURE-----
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion



  • RE: [SCTP-Discussion] Re: some questions to prototype 0.10.0, Tuexen Michael, 02/13/2001

Archive powered by MHonArc 2.6.19+.

Top of page