Subject: [tsvwg] draft-stewart-tsvwg-sctp-ndata-03.txt

From: "Karen E. Egede Nielsen" <[email-masked]>
Date: Mon, 4 Nov 2013 15:51:53 -0800

Hi,

Please accept the folowing comments to
draft-stewart-tsvwg-sctp-ndata-03.txt.

Please use as fit.

General comments:

-----------------------

The draft draft-stewart-tsvwg-sctp-ndata-03.txt, in my opinion, addresses
an important limitation of SCTP message fragmentation The

limitation is important to have removed in order to support large message
transfer by SCTP without detroying concurrent transmission of

data with real-time characteristics.

The advanced stream scheduling modes, suggested in the draft, also seems
very instrumental in order to instantiate different real time
characteristics on

different streams.

Title:  Given the scheduling aspects included in the draft, one should
consider to adjust the title so that it better accommodate for the
scheduling parts. Actually stream scheduling seems to be main topic of the
draft with the new (or extended) data chunk format just a mean to support
more flexible (interleaved) scheduling of fragments.

Something else:  The “N” as “New” in N-DATA seems not so future-proof.
Perhaps E for word “Extended” (E-DATA) would be a better naming ?

It should be clarified in the Introduction that the draft makes use of the
Supported Extension Parameter as defined in RFC5061.

Detailed Comments:

---------------------------

Section 1.1:

1.       It should be clarified that the draft defines a new data chunk
option as well as that it defines an advanced stream scheduler function and
that these are independent functions.

2.       It could be clarified that the intention is for the new data chunk
to be used for *all* data transmitted on a particular association (i.e.,
not only fragments).

3.       It could be clarified that the usage of the new data chunk will
differentiable on a per association basis and that an SCTP implementation
as such shall support coexistence of associations which use the existing
data chunk format and associations which use the new data chunk format.

Section 3.1:

1.       In the third paragraph that starts with “Sender side usage.. ”, it
should be clarified that the new data chunk is used for all data chunks and
not for only data chunks that need fragmentation.

2.       The situation, when the peer does not support N-DATA but the user
request it, should preferably be elaborated on in this section or somewhere
else in the draft. Presumably then in this situation the SCTP layer simply
uses the legacy data chunk with its in-build limitations. However this
should be described.

3.       Information should preferably be provided to UL about whether peer
supports usage of N-DATA. For a socket api compliant implementation such
information could possibly be provided in an extension of SCTP_STATUS ?

Section 4.1 – minor/editorial:

1.       The text could be clarified so that it more clearly refers to
“one-to-many” and to
“one-to-one” sockets. The text could also better describe the behaviour of
the socket option on each type.

2.       The second paragraph sentence: “An N-DATA chunk aware application
should also set the fragment interleave level to 2” – should refer to
appropriate option of RFC6458.

Section 4.1 – substance:

1.       I would like to press for that the ability to change the N-DATA
setting on current (established) associations is removed. It looks to open
up for a number of complexities both in SCTP layer as well as in O&M
layer;  E.g.,  if N-DATA feature is disabled, what about retransmissions
where original was send as N-DATA. When the O&M operation is made, then how
to control when it takes effect in the SCTP layer in respect to data
already in SND buffer. Further the disabling only effectively can control
the sending side. These details would have to be described in draft and,
secondly, implemented, both of which could be somewhat of a challenge. Are
there some important use-cases that demands for this “flexibility” ?

2.       I believe that one NEED to have the possibility, on a per
association basis, to read whether the peer supports N-DATA or not. This
regardless of whether it be an association belonging to a one-to-many
socket or a one-to-one socket. Support for read via socket api should be
described in the draft. This may be provided via an extension of
SCTP_STATUS (?). Optionally one may also prescribe for such information to
be returned as part of an extension of RFC3873, sctpAssocTable object.

3.       Situation with association restart on SCTP level should preferably
be described.

Section 4.1.2:

1.       Would it be reasonable to specify a subset of the listed
scheduling options as something that an implementation that support N-DATA
MUST support and others as MAY or optional.  Alternatively one may specify
that at least one of the options need to be supported ?

2.       The SCTP_SS_FAIR_BANDWIDTH could be demanding from an
implementation perspective.

3.       It should be clarified that these scheduling options are
applicable for sending normal DATA chunks also when peer does not support
usage of N-DATA.

Possible addition to the draft content: (?)

Possibly one could contemplate to include improvement of the receiver side
operation also. As follows:

·         The SCTP receive operation could be extended to allow for
specification of read stream scheduling  - possibly options – to start with
(RS: Read Scheduling):

o   SCTP_RS_FIRST_COME: The simple first-come, first-serve algorithm

is selected by using this value.  It just queues messages that are readable
in the order in which they have been received by the SCTP layer.

o   SCTP_RS_PRIORITY:  SCTP operates with a number of receive queues per
association according to a number of priorities set. For each priority
queue simple first-come, first-serve algorithm is used .I.e., for each
priority queue messages are queued as readable in the order in which they
have been received by the SCTP layer .The priority can be assigned on a per
stream basis. Value 0 is default priority, higher values are higher
priority (or lower), lower values are lower priority (or higher).

Select, poll (BSD) and epoll (Linux) mechanism must be extended to support
specification, and notification, of receiving readable event on a per
priority RCV queue basis.

Editorial:

Abstract: which which à which

Section 2: FSN's are unsigned number à FSN's are unsigned numbers

BR, Karen