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

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Mon, 25 Aug 2014 23:26:10 +0200

Hi Michael,

Sorry for the late follow up.
Please find some feedback inline below.

Generally I should note that the section numbering in the more recent
versions of the draft does not correspond to the section numbering
of the version to which the comments were provided. Still I hope that we
can make sense of the below..

BR, Karen

> -----Original Message-----
> From: Michael Tuexen [mailto:[email-masked]]
> Sent: 4. juli 2014 22:42
> To: Karen E. Egede Nielsen
> Cc: Randall Stewart; [email-masked]; Salvatore Loreto
> Subject: Re: draft-stewart-tsvwg-sctp-ndata-03.txt
>
> On 05 Nov 2013, at 00:51, Karen E. Egede Nielsen
<[email-masked]>
> wrote:
>
> > Hi,
> >
> > Please accept the folowing comments to draft-stewart-tsvwg-sctp-ndata-
> 03.txt.
> > Please use as fit.
> Hi Karen,
>
> thank you very much for your comments. I'm sorry for not responding
> earlier...
> See my comments in-line.
>
> Best regards
> Michael
> >
> > 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.
> The is correct.
> >
> > 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 ?
> Possibly. But we are using N-DATA in several places... Will think about
it.

[Karen] A suggestion given at the tsvwg session at IETF 90 was I-data
chunk where I is for interleaving. A different alternative is the E-data
chunk where E is for extended.

> > It should be clarified in the Introduction that the draft makes use of
the
> Supported Extension Parameter as defined in RFC5061.
> Make sense. Done.
> >
> > 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.
> Correct. I agree.
> > 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).
> Done.
> > 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.
> Sure. Done.
> >
> > 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.
> Fixed.
> > 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.
> Fixed.
> > 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 ?
> I would prefer to signal it in the SCTP_ASSOC_CHANGE indicating
> SCTP_COMM_UP or SCTP_RESTART by using
> SCTP_SUPPORTS_INTERLEAVING similar to SCTP_ASSOC_SUPPORTS_PR,
> SCTP_ASSOC_SUPPORTS_AUTH, ...
> However, this goes into the socket API section.
> >

[Karen] Yes I agree that the realization of the function over the socket
api goes into the socket api section.
The requirement to provision information to ULP about what was negotiated
for the
association is part of the substance of the function and should go here.
Right ?

> > 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.
> Could you be more specific where information is missing?

[Karen] Right now  the text of section 4.1.2 says that the socket option
SCTP_NDATA_ENABLE
 applies to future associations. Yes I can interpret this also for a
one-to-one style socket but I would
prefer to have this written out. Like what happens for a one-to-one
socket; is this option rejected or ignored (?)
on already established associations.

I further think that one wants to cache (as for the number of streams)
both what was negotiated as well as what
was intended to be negotiated. If the SCTP_NDATA_ENABLE, when read, tells
what was intended to be negotiated, then we need somewhere else
(e.g. SCTP_STATUS) to read what got negotiated.

> > 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” ?
> This functionality isn't there. I agree completely with you. Isn't the
text in
> 4.1.1 on SCTP_NDATA_ENABLE clear on this?

[Karen]  The new text is much better.

Section 4.2.1 still has the following:

"and will also prevent current associations from
   producing N-DATA chunks for future large fragmented messages"

Do you really want to have this ? I would not...

> > 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
> Isn't the notification good enough? You can't query ASCONF support,
Stream
> Reset, and so on.
> This is currently only done via the notification. I'm open to discuss a
generic
> method...
> > 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.
> Let's talk about MIB stuff in general in a separate document. We are
lacking
> MIB support for all SCTP extensions. If there is a real need in this, we
should
> think about updating the MIB RFC. Years ago, when I implemented it for
> FreeBSD, I had a bunch of comments.
> > 3.       Situation with association restart on SCTP level should
preferably be
> described.
> You get a new notification...
[Karen] Fine :-) .. But what I want to know is the following:

Can usage of N-DATA be re-negotiated during restart of association.
Which setting of the local side dictates what should happen on a
one-to-one association during restart.
Will SCTP layer cache what originally was set in the SCTP_NDATA_ENABLE
option and use this to guide
re-negotiation during restart ?

> >
> > 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 ?
> I would just look which constants are defined... We can make a statement
> that not all implementation support all.
> > 2.       The SCTP_SS_FAIR_BANDWIDTH could be demanding from an
> implementation perspective.
> As will be the SCTP_SS_WEIGHTED_FAIR_QUEUEING...
> > 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.
> Yepp. I'll work on this while polishing/testing the implementation..
> >
> >
> > 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.
> As we discussed, I think this could go into a separate document...
> >
> >
> > Editorial:
> >
> > Abstract: which which à which
> > Section 2: FSN's are unsigned number à FSN's are unsigned numbers
> Fixed.
> >
> > BR, Karen