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

Yutaka Takeda <yt0916@gmail.com> Fri, 08 February 2019 23:22 UTC

Return-Path: <yt0916@gmail.com>
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 61771129A87 for <tsvwg@ietfa.amsl.com>; Fri, 8 Feb 2019 15:22:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 5LCzVZtm4TRJ for <tsvwg@ietfa.amsl.com>; Fri, 8 Feb 2019 15:22:22 -0800 (PST)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEB0127AC2 for <tsvwg@ietf.org>; Fri, 8 Feb 2019 15:22:22 -0800 (PST)
Received: by mail-qt1-x834.google.com with SMTP id b8so5969482qtj.1 for <tsvwg@ietf.org>; Fri, 08 Feb 2019 15:22:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=pSN20D6pyLVbGBYB5LHSiZvoR5vB1FgApvJMbGaN/q0=; b=kpgc7LFazWM1T2nb1ww57tudqs8C89jJe8gO5angtthLCrfi3KmNFSmIVqPtAiQCZD 37n0tESPJdzYD3F8UqudJPoMB9fCI5CtRLmyAGB76u1DRBr0nrQ/JkpEBOBr23wNvsMN +Sp14KWbnW9GWBUJxQBOvbey83tF9S4exRYD9KTeWafS/VKrAg6wkGBfCmeab1ZHOW+w EyvLeon+N2AZFlUEfG8md+EiCKxOL4w4APoiuziRkq3lp4A9VHghBmE2lF7RUnmTXhyI YCrXowMMSsH2I9gozWPO6+5Vkj9UHdKj9iRLM93ZbRV/Qhf46gddrbjJeCJJ1FdEoTkP giRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pSN20D6pyLVbGBYB5LHSiZvoR5vB1FgApvJMbGaN/q0=; b=dwCqHccg/uxC4/HxAg2kz8kKWpy8B+M3o9dwnnmvf4vMburDm3vKEZK8dF3JEMdjni BxT2Rmx6t6gwOG6ZyCCswSAry7yazOMl4Uh0zenioIhiRjHnl8hwZoSQ3J4kUBf0oULa brHWbkdoXkDFfW7oIh7xWnlfRDmRCE+4M7w1c/81qh99qpAERY/W2VBW19/ci5aefDAD Omc1IiM0vreHmhJiqOKZ8IY92NVgzZR/jaVDc54YwmikxkH205+glNzD0v5lWsvCzZeE vVGMhNZa5aT+R2ccADABXkwABysj2iujcyuBkd3p33XR2rIiiAV/JoXFvkBhNUmYFOZF D05A==
X-Gm-Message-State: AHQUAuYSecfKUIusDpkUsJVOj5d7hY5smBOr0RQGadWQ6PKFLEZmsqDi ewl5y5Hy8D7KrgNw38t75MGm/jwRfoVu3pfe3FZcWg==
X-Google-Smtp-Source: AHgI3IYy+4zKCCb7TTuhLZATuxT0/boBr7gJvVCPhO5y1kKxoht3ESSaS5DT3FWE/wAc42iUDYkuAf8S6gHDVCTsxdI=
X-Received: by 2002:aed:3641:: with SMTP id e59mr18200509qtb.59.1549668140907; Fri, 08 Feb 2019 15:22:20 -0800 (PST)
MIME-Version: 1.0
From: Yutaka Takeda <yt0916@gmail.com>
Date: Fri, 08 Feb 2019 15:22:09 -0800
Message-ID: <CADozWMnCZMfgT9yHb0NyWEaWj7q0smi=0A4nduQKDUMZh-NTNQ@mail.gmail.com>
To: tsvwg@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000eff8705816a3b93"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/iBJH6mzPbObaKbpDSR0Dy06VeQ8>
Subject: [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:22:24 -0000

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