Chronological Thread 

< Chronological >      < Thread >

---

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

---

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