Subject: [tsvwg] Comments to draft-ietf-tsvwg-sctp-ndata-05.txt

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Mon, 4 Apr 2016 14:39:18 +0200

Hi Michael, tsvwg

I support the progress of this document in the IETF process with the
following comments:
(The comments are not new but applied to version 04 as well, e.g. , see
email July 06, 2015,  copied in below.).

Section 1:

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

No this is not feasible unless it is made negotiable whether 16-bit or
32-bits are
used for SSN.

Section 1:

"Please note that the
      serial number arithmetic defined in [RFC1982] using SERIAL_BITS =
      32 applies.  Therefore the sender MUST NOT have more than 2**31 -
      1 ordered messages for each outgoing stream in flight and MUST NOT
      have more than 2**31 - 1 unordered messages for each outgoing
      stream in flight."

Hmm... from RFC4960 we have:

"An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more
   than 2**31 - 1 above the beginning TSN of its current send window.
   Doing so will cause problems in comparing TSNs."

This means that SCTP can never ever have more than 2**31 - 1 messages in
flight.
Perhaps the "MUST NOT" above technically is correct, but I would prefer that
it is explained that
by RFC4960 TSN arithmetic and the SHOULD NOT, having more than 2**31 - 1 in
flight SHOULD NOT happen anyway.

Section 2.3.2:

   "Since most schedulers require late TSN assignment, it should be noted
   that the implementation of [RFC6525] needs to handle this."

Not only do most schedulars require late TSN assignment, but any scheduler
supporting interleaving  indeed does this.
Perhaps this could be emphasized.

The pointer to that RFC6525 have an issue is now here. This is good. Given
that this is the first RFC which requires for late TSN assignment,
I wonder if one could not here in this RFC say how this issue is assumed to
be tackled by an RFC6525 implementation.  Even more so that I think that we
have general agreement on what the solution should be.  I.e., delay until
TSN has been assigned.

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
>
>
>> 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.
>>

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: 21. marts 2016 16:57
> To: [email-masked]
> Cc: [email-masked]
> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-05.txt
>
>
> 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 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-05.txt
> 	Pages           : 18
> 	Date            : 2016-03-21
>
> 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:
> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-05
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-05
>
>
> 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: Michael Tuexen <[email-masked]>
Date: Tue, 5 Apr 2016 08:39:12 -0300

> On 04 Apr 2016, at 09:39, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> Hi Michael, tsvwg
> 
I was thinking about using it in the API. We are reporting on the receiver
side the SSN which was received. My current thinking is that we don't
change that, just report the lower 16 bit of the MID. Do you agree, the
this is a way to go.

I agree that the above wording is bad and needs to be improved.

Best regards
Michael

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Tue, 5 Apr 2016 13:44:59 +0200

Hi Michael

> > 32-bits are used for SSN.
> I was thinking about using it in the API. We are reporting on the
receiver side
> the SSN which was received. My current thinking is that we don't change
> that, just report the lower 16 bit of the MID. Do you agree, the this is
a way
> to go.
[Karen Elisabeth Egede Nielsen] Yes I agree that this is viable. But as
you say the wording must be substantially improved. Possibly this
consideration even only belong to the API section and should not be in
this section at all as this section is about the wire format. I can live
with it being here if well explained.

BR, Karen

> > This means that SCTP can never ever have more than 2**31 - 1 messages
> > in flight.
> > Perhaps the "MUST NOT" above technically is correct, but I would
> > prefer that it is explained that by RFC4960 TSN arithmetic and the
> > SHOULD NOT, having more than 2**31 - 1 in flight SHOULD NOT happen
> > anyway.
> >
> > Section 2.3.2:
> >
> > Not only do most schedulars require late TSN assignment, but any
> > scheduler supporting interleaving  indeed does this.
> > The pointer to that RFC6525 have an issue is now here. This is good.
> > Given that this is the first RFC which requires for late TSN
> > assignment, I wonder if one could not here in this RFC say how this
> > issue is assumed to be tackled by an RFC6525 implementation.  Even
> > more so that I think that we have general agreement on what the
> > solution should be.  I.e., delay until TSN has been assigned.
> >
> > BR, Karen
> >
> >> submission until the htmlized version and diff are available at
> >> tools.ietf.org.
> >>

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 5 Apr 2016 09:04:32 -0300

> On 05 Apr 2016, at 08:44, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> Hi Michael
> 
>>> Section 1:
>>> 
>>> "However, the lower
I totally agree. 
Dealing with it in https://github.com/sctplab/sctp-idata/issues/3

Best regards
Michael