Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-03.txt

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Tue, 19 May 2015 10:12:11 +0200

Hi Michael,

Probably you have a version 04 soon in store. Anyway I hope that the
following comments may be useful..
We have discussed some in person or in written before I believe.

1. Section 2.1: "However, the lower
   16-bit of the MID can be used as the SSN if necessary."

This is not an option unless we make it negotiable if 16-bit or 32-bits are
used for SSN.

2. Section 2.1: References to 32-bit arithmetic of SSN/MID and FSN.

The TSN number is 32-bit only with 32-bit arithmetic. Consequently there
can be a most 2^31-1 outstanding messages
on an association period. Whether one apply 32-bit arithmetic or not to the
32-bit of the SSN/MIDs or FSN is not significant.

3.Section 2.2.2:  "Note that the usage of this chunk should also imply late
binding of
   the actual TSN to any chunk being sent."

Late binding would be a prerequisite for that this functions would work
properly (or efficiently) when combined with
stream scheduling. As discussed in an other email the late binding of TSNs
may deserve some considerations in connection with
stream reset functions of RFC6525 - thus enforcing binding
of TSNs to all messages on a stream when a stream reset is issued on the
stream. OR ?

4. Section 2.2.2: "This way other messages from
   other streams may be interleaved with the fragmented message."

I think it need to be made VERY CLEAR that the interleaving functions of
this document only support exactly this -
meaning only supports interleaving with messages from _OTHER_ streams.

We had some discussions about this in the fall. With the present text, and
with present RFC6458 interleave level 2, then it is NOT possible to
have messages  on the very same stream be interleaved with one another.

Having said that then I do persist to wonder about what exactly is meant by
the following sentence:

Section 2.2.2 " The sender MAY have one ordered and one unordered
fragmented message
   being produced within a single stream."

Could it be clarified what is meant with the word "produced" ?
Does it mean _have fragments outstanding belonging_ to - or ?

Further. Unless interleave level 2 function of RFC6458 is changed (or
equivalent function is changed) then
the receiver would only be able to receive fragments (partial delivery)
 from one of these messages at a time - and which ever starts to be
partial delivered to the receiver first would block the (partial) delivery
of the other message - and indeed bock delivery of any other message
from the same stream.

5. Section 2.3.1: Need to be changed to accommodate for 32-bit only SSNs.

BR, Karen

On 9 March 2015 at 22:54, <[email-masked]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Transport Area Working Group Working
> Group of the IETF.
>
>         Title           : Stream Schedulers and User Message Interleaving
> for the Stream Control Transmission Protocol
>         Authors         : Randall R. Stewart
>                           Michael Tuexen
>                           Salvatore Loreto
>                           Robin Seggelmann
>         Filename        : draft-ietf-tsvwg-sctp-ndata-03.txt
>         Pages           : 14
>         Date            : 2015-03-09
>
> Abstract:
>    The Stream Control Transmission Protocol (SCTP) is a message oriented
>    transport protocol supporting arbitrary large user messages.
>    However, the sender can not interleave different user messages which
>    causes head of line blocking at the sender side.  To overcome this
>    limitation, this document adds a new data chunk to SCTP.
>
>    Whenever an SCTP sender is allowed to send a user data, it can
>    possibly choose from multiple outgoing SCTP streams.  Multiple ways
>    for this selection, called stream schedulers, are defined.  Some of
>    them don't require the support of user message interleaving, some do.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>