Subject: U-SCTP comments

From: [email-masked]
Date: Mon, 12 Mar 2001 23:09:42 +0200

Hi all!

	I have some comments about the version 01 of the unreliable
extension for SCTP. I hope they have not been discussed before in the
list...

	- Section 3.1.1: What happens if the "u-stream start" or "u-stream
end" fields of the Unreliable Streams parameter are bigger than or equal to
the "Number of Outbound Streams" field of the INIT/INIT ACK chunk? It would
be caused by an implementation error, but, should we discard the chunk in
which it comes (and so the whole datagram), or should we do something more
elaborated like sending an ERROR or ABORT chunk (maybe with the "Invalid
Stream Identifier" cause of error)?

	- Section 3.2.2: This is a little bit tricky. If the sender of a
P-DATA sets the "Checksum Coverage" field exactly to the value of Chunk
Length - 20, but the P-DATA contains some padding at the end, should those
bytes (that would be set in theory to 0) be included in the Adler-32
checksum? The same questions comes if for example there are 3 bytes of
padding at the end, and the Checksum Coverage is set to Chunk Length - 19,
for example, should we include also the other 2 bytes of padding in the
checksum?

	- Section 4.2, A3) C2): The draft says that the FORWARD TSN chunk
should be sent ONLY when a local advancement of the Peer.Cumulative.TSN is
done. What happens if that chunk is lost in the way to the peer? If we don't
have any other mechanism to send again that chunk, and if we don't make any
local advancement in a long time or ever, we could end having the peer
considering those chunks as lost, and never knowing that we have stopped
sending them. In that case, the peer will keep its cumulative TSN to the
previous TSN to the lost unreliable DATA chunk, and it will report any
successive DATA chunks with fragments inside the SACK chunks, so we won't
have to advance locally the TSN, nor sending the FORWARD TSN chunk. So any
ordered DATA chunk sent to the same stream won't ever be delivered to the
upper user of the peer endpoint (of course, only if the lost DATA chunk was
also ordered). In the worst case, we will full the peers buffer, affecting
also some other stream.

	It is stated in C2 that we shouldn't react in any way when receiving
SACK not acknowledging TSNs that are previous to the Peer.Cumulative.TSN.
Resending the FORWARD TSN every time we receive a such a SACK could be maybe
a lot, since this could make that actually we always send such a chunk lots
of times (if there are several SACK on the fly coming from the peer, and/or
several DATA chunks going to the peer).

	Maybe it could be a little bit messy to implement, maybe not, but
this could be solved having a variable that keeps the value of the next TSN
we will send to the peer (the TSN of the next DATA chunk that we will send
to the peer) at the moment of sending the FORWARD TSN. In that case, if we
receive the acknowledgement of that TSN but the peer is considering any
chunk previous to Peer.Cumulative.TSN as missing, we could send a new
FORWARD TSN, keeping again the value of the next TSN to send and so on.

	And now, some typos:

	- Section 3.2.2, Stream Identifier S: "Identifies the stream to
which the following the user data belongs." should be "Identifies the stream
to which the following user data belongs."

	- Section 4: "... we first defines the procedures for opening..."
should be "... we first define the procedures for opening..."

	- Section 4.2, A3) C2):"Note, an endpoint MUST NOT use the forward
TSN..." I guess should be "Note, an endpoint MUST NOT use the FORWARD
TSN..."

	- Section 4.4.3: "... the upper layer simply needs to examine the
the stream..." should be "... the upper layer simply needs to examine the
stream..."

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 12 Mar 2001 18:24:57 -0600

Ivan,

Please see my comments in-line...

-Qiaobing

> Stream Identifier" cause of error)?

My feeling is that we don't have to treat it as an error at this point.
For example, if the stream range is 0-19 and we get a "u-stream start =
5" and "u-stream end = 30", we can simply take it as meaning that stream
5-19 will be unreliable. The existing error reporting in RFC2960 will
kick in if the peer later really sends data to stream 20 and above.
 
> for example, should we include also the other 2 bytes of padding in the

Padding is never counted in the Chunk Length and is never covered by the
checksum. This is very clear in RFC2960 and U-SCTP makes no difference
here. We can further clarify this by adding a note.

> also ordered). In the worst case, we will full the peers buffer, affecting

This has been pointed out by John L. and will be fixed in the next
release, by the addition of the following (with some polish):

   The data sender MUST always send a F-TSN containing its latest
   "Peer.Cumulative.TSN" to the data receiver whenever the sender
   receives a SACK which is not out-of-order and carries a Cumulative
   TSN earlier than the current "Peer.Cumulative.TSN". 

> several DATA chunks going to the peer).

Since this scenario only happens when you lose the first F-TSN, I think
it shouldn't happen that often.

> FORWARD TSN, keeping again the value of the next TSN to send and so on.

There will be more clarifications in the next release in this section. I
think that will help.

> the stream..." should be "... the upper layer simply needs to examine the

Got them all. Thanks.