Subject: [tsvwg] Question about RFC 4960 (SCTP) - initial stream sequence number

From: Yutaka Takeda <[email-masked]>
Date: Fri, 8 Feb 2019 15:22:09 -0800

As I was reading RFC 4960 (also its errata-08), I was not able to find any
text which explained
how the initial Stream Sequence Number, or SSN, of DATA chunk for a
particular stream identifier,
or SI, is determined.

It is possible that a receiver of a stream can take the first DATA chunk
that is "due" by Cumulative TSN,
however, waiting for the chunk to be due (everything else before the chunk
was all received) could cause
a delay for delivering the already received chunk to the upper layer.

Here's an example on the receiver side queue:

TSN SI SSN BE status
--- -- --- -- -------
100  2 10  11 missing  <== Cumulative TSN
101  2 11  11 received (waiting for TSN:100)
102  2 12  11 received (waiting for TSN:101)
103  2 13  11 missing  (would wait for TSN:102)
104  1 10  11 received <== should it wait for TSN:103?

Initial TSN is 100 in the above example. For simplicity, both streams (SI=1
and 2) starts
with SSN=10.

My first question is if the chunk (TSN:104) has to wait for arrivals of TSN
100 and 103.
If yes, then as I mentioned, it means there's a head-of-line blocking
between the streams.
(SI=1 is blocked by SI=2 in the above case)

If no, then we could pass the chunk at TSN=104 to "stream level"
(reassembly queue, etc), but the
stream level would not know whether the SSN=10 is supposed to be the first
chunk to be delivered to the
upper layer (of course, to guarantee the ordered delivery).

To me, along with "unordered" delivery is implementation, it is natural to
pass received chunks to stream level
right away regardless of "ordered" or "unordered" and guarantee the
ordering at stream level (without being
blocked by other streams' retransmission), but doing so requires "initial
SSN" agreed by both ends.

I more than likely is missing something here.  It would be greatly
appreciated if you could give me any insight
into this problem.

Yutaka

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 9 Feb 2019 00:40:56 +0100

> On 9. Feb 2019, at 00:22, Yutaka Takeda <[email-masked]> wrote:
> 
> As I was reading RFC 4960 (also its errata-08), I was not able to find any text which explained
> how the initial Stream Sequence Number, or SSN, of DATA chunk for a particular stream identifier,
> or SI, is determined.
This is specified in https://tools.ietf.org/html/rfc4960#section-6.5

   The Stream Sequence Number in all the streams MUST start from 0 when
   the association is established.  Also, when the Stream Sequence
   Number reaches the value 65535 the next Stream Sequence Number MUST
   be set to 0.

Does that answer your question?

Best regards
Michael
> 
> It is possible that a receiver of a stream can take the first DATA chunk that is "due" by Cumulative TSN, 
> however, waiting for the chunk to be due (everything else before the chunk was all received) could cause
> Initial TSN is 100 in the above example. For simplicity, both streams (SI=1 and 2) starts
> with SSN=10.
> 
> My first question is if the chunk (TSN:104) has to wait for arrivals of TSN 100 and 103.
> If yes, then as I mentioned, it means there's a head-of-line blocking between the streams.
> If no, then we could pass the chunk at TSN=104 to "stream level" (reassembly queue, etc), but the
> stream level would not know whether the SSN=10 is supposed to be the first chunk to be delivered to the
> To me, along with "unordered" delivery is implementation, it is natural to pass received chunks to stream level
> right away regardless of "ordered" or "unordered" and guarantee the ordering at stream level (without being
> blocked by other streams' retransmission), but doing so requires "initial SSN" agreed by both ends.
> 
> I more than likely is missing something here.  It would be greatly appreciated if you could give me any insight
> into this problem.
> 
> Yutaka

---

From: Yutaka Takeda <[email-masked]>
Date: Fri, 8 Feb 2019 15:47:44 -0800

Oh -! how did I miss that one...
Thank you Michael, my problem solved!