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

From: Michael Tuexen <[email-masked]>
Date: Mon, 6 Jul 2015 21:23:30 +0200

> On 19 May 2015, at 10:12, Karen Elisabeth Egede Nielsen <[email-masked]> wrote
> 
> 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.
Hi Karen,

thank you very much for the review. Please see my comments in-line.

Best regards
Michael
> 
> 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.
OK. Sentence removed.
> 
> 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.
Not sure. Need to think about it.
> 
> 
> 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 ?
I have been contemplating about this. I think I'll try to add an architectural diagram on
how the scheduler work. Let's discuss this in Prague.
> 
> 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.
I agree. Using a figure it might be easier to get this clear than just with text...
> 
> 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.
Correct.
> 
> 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.
Again: I hope a figure will make that easier to understand. Let's discuss this in Prague.
> 
> 5. Section 2.3.1: Need to be changed to accommodate for 32-bit only SSNs.
Done.
> 
> 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/
> 
>

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Mon, 13 Jul 2015 14:58:00 +0200

HI Michael,

Ok - I have no further comments the below. Let's see in Prague.

I read 04 -  I have one editorial thing only - but you probably thought
about that as well...

The term "User Message Based Round Robin Schedular" doesn't work so well
for
the message interleaving version - as it indeed are chunks that are  being
Round Robin Scheduled.
Perhaps one call is "Chunk based" or you simply use the term  "Round Robin
Scheduler" for section 3.1.2 and 3.2.1.

BR, Karen

>-----Original Message-----
>From: tsvwg [mailto:[email-masked]] On Behalf Of Michael Tuexen
>Sent: Monday, July 06, 2015 9:24 PM
>To: Karen Elisabeth Egede Nielsen
>Cc: [email-masked]
>Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-03.txt
>
>
>> This is not an option unless we make it negotiable if 16-bit or 32-bits
are
>used for SSN.
>> 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
>> 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 ?
>I have been contemplating about this. I think I'll try to add an
architectural
>diagram on how the scheduler work. Let's discuss this in Prague.
>>
>> 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.
>Correct.
>>
>> Having said that then I do persist to wonder about what exactly is
meant by
>the following sentence:
>> 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.
>Again: I hope a figure will make that easier to understand. Let's discuss
this in
>Prague.
>>         Title           : Stream Schedulers and User Message
Interleaving for the
>Stream Control Transmission Protocol
>> 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.