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