Subject: [tsvwg] AD Evaluation: draft-ietf-tsvwg-sctp-ndata-11.txt

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 18 Jul 2017 20:26:52 +0200

Sorry for not finishing this last week.

I really like this mechanism and the document describing it was mostly
clear to me. I did have some questions, but most are simple requests for
more clarity.

I suspect this will require a revised ID, so I'll mark it that way in the
Datatracker, but if I'm completely wrong, don't submit one just to make me
happy.

Michael and I talked briefly at the beginning of TSVWG this afternoon, and
as I told him, "I'm here all week", if chatting is faster than typing.

I'm a bit curious about this text,

   This document also defines several stream schedulers for general SCTP
   associations.  They can be used with and without user message
   interleaving being negotiated and possibly behave differently.

because I'm wondering, "possibly behave differently than what?" Could you
say a sentence or two more about what you mean here? The text in Section 3
says

   This section defines several stream schedulers.  The stream
   schedulers may behave differently depending on whether user message
   interleaving has been negotiated for the association or not.

and that's clearer to me, if I'm understanding correctly.

I need a bit more help on this text,

   Please note that the use of such a scheduler implies late
   TSN assignment but it can be used with an [RFC4960] compliant
   implementation that does not support user message interleaving.

I'm not quite sure what you mean by "can be used with/does not support user
message interleaving". I'm guessing that your point was, this is a new
sender-side behavior, so SCTPs that implement this specification know what
I-DATA is, and when they negotiate support for I-DATA, they will reassemble
fragments correctly, whether they would interleave user messages that they
send or not, but I'm guessing.

Also, could you provide a reference for "late TSN assignment"? This is the
first usage in the document.

You might consider putting this text

   The interleaving of user messages is required for WebRTC Datachannels
   as specified in [I-D.ietf-rtcweb-data-channel].

earlier in the document - perhaps in the Introduction? I wish I thought it
belonged in the Abstract, too, but I'm less sure about suggesting that.

You might consider adding explanatory text to

   If an SCTP implementation
   supports user message interleaving and the extension described in
   [RFC3758] or [RFC6525], it is REQUIRED to implement the corresponding
   changes specified in Section 2.3.

so,

   If an SCTP implementation
   supports user message interleaving and the partial reliability extension
   described in [RFC3758] or the stream reconfigurtion extension described
in
   RFC6525], it is REQUIRED to implement the corresponding
   changes specified in Section 2.3.

for those of us who don't remember the RFC numbers of extensions off the
tops of our heads.

I think I know what

      A message is considered in flight, if at least
      on of its I-DATA chunks is not acknowledged in a non-renegable
      way.

means, but is "non-renegable" a term of art in the SCTP community? I had
the same question about PPID, but I'm sure you would have the same answer
...

This is a nit, but

   The sender MUST NOT be fragmenting more than one user message in any
   given stream at any time.

would probably be clearer if it said "must not fragment".

This is a nit, but

   A message (either ordered or unordered) may be identified as
   being fragmented whose 'E' and 'B' bits are not set both.

should probably be be "not both set".

So, dumb question, but how close is the last sentence in

   If I-DATA support has been negotiated for an association, the
   reception of a DATA chunk is a violation of the above rules and
   therefore the receiver of the DATA chunk MUST abort the association
   by sending an ABORT chunk.  The ABORT chunk MAY include the 'Protocol
   Violation' error cause.  The same applies if I-DATA support has not
   be negotiated for an association and an I-DATA chunk is received.

to what an SCTP that doesn't support this extension would do, if it
received an I-DATA chunk? I was guessing that the last sentence isn't new
behavior, but wanted to ask because it's being specified here. Whether or
not it's different, it might be useful to tell the reader that.

I had the same question about the last sentence in section 2.3.1, "SCTP
Partial Reliability Extension", but I'm sure you would have the same answer.

In this text,

3.4.  Priority Based Scheduler (SCTP_SS_PRIO)

   Scheduling of user messages with strict priorities is used.  The
   priority is configurable per outgoing SCTP stream.  Streams having a
   higher priority will be scheduled first and when multiple streams
   have the same priority, the scheduling between them is implementation
   dependent.  When using user message interleaving, the sending of
   lower priority user messages will not block the sending of higher
   priority user messages.

I'm not sure I understand "will not block". If I'm in the process of
sending a lower priority user message and a higher priority user message is
being scheduled, wouldn't the higher priority user message have to wait?
I'm probably not understanding this.