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

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Fri, 08 February 2019 23:41 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08285130EB8 for <tsvwg@ietfa.amsl.com>; Fri, 8 Feb 2019 15:41:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEs700Yc0xTY for <tsvwg@ietfa.amsl.com>; Fri, 8 Feb 2019 15:41:01 -0800 (PST)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB516130EB3 for <tsvwg@ietf.org>; Fri, 8 Feb 2019 15:41:00 -0800 (PST)
Received: from [IPv6:2003:cd:6f38:4a00:99bc:fe22:995c:ea0a] (p200300CD6F384A0099BCFE22995CEA0A.dip0.t-ipconnect.de [IPv6:2003:cd:6f38:4a00:99bc:fe22:995c:ea0a]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 1CAF3721E281E; Sat, 9 Feb 2019 00:40:57 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <CADozWMnCZMfgT9yHb0NyWEaWj7q0smi=0A4nduQKDUMZh-NTNQ@mail.gmail.com>
Date: Sat, 09 Feb 2019 00:40:56 +0100
Cc: tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <305683D2-2FE7-496A-AE35-2F53242B029B@lurchi.franken.de>
References: <CADozWMnCZMfgT9yHb0NyWEaWj7q0smi=0A4nduQKDUMZh-NTNQ@mail.gmail.com>
To: Yutaka Takeda <yt0916@gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/9GIS2zRzJJtpW6ssahN31z5dxTo>
Subject: Re: [tsvwg] Question about RFC 4960 (SCTP) - initial stream sequence number
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Feb 2019 23:41:04 -0000

> On 9. Feb 2019, at 00:22, Yutaka Takeda <yt0916@gmail.com> 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
> 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