Chronological Thread 

< Chronological >      < Thread >

---

-----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 ?
This is a question that should probably be asked on the SIGTRAN mailing
list.

> 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-----

---

• [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+.