Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-sctp-ndata-07.

From: Michael Tuexen <[email-masked]>
Date: Mon, 31 Oct 2016 09:05:36 +0100

> On 24 Sep 2016, at 11:22, G Fairhurst <[email-masked]> wrote:
> 
> With no WG Chair hat, I have the following editorial feedback that you may like to consider. These comments are on draft-ietf-tsvwg-sctp-ndata-07. I shall separately ask questions as the document shepherd.
Hi Gorry,

thank you very mich for your review. Please see my comments in-line.

Best regards
Michael
> 
> Gorry
> 
> ---
> 
> Editorial comments:
> —
> I see the document as having several parts, a para at the end of section 1 that explains these major parts would have been a welcome addition to the document.
OK. I added:
<t>This document specifies in <xref target='interleaving'/> the user
message interleaving by defining the I-DATA chunk, the procedures to use it
and its interactions with other SCTP extensions.
Multiple stream schedulers are defined in <xref target='scheduler'/>
followed by describing in <xref target='api'/> an extension to the
socket API for using what is specified in this document.</t>
> —
> Please expand “MTU” on first usage:
> /MTU sized message./
Done.
> —
> Replace /which/ by /that/
> /applications which might/
Done.
> —
> /might send very large messages over SCTP/
> - I’m curious whether the /very/ is really necessary (could we delete?), even a just a “large” message can benefit? (see next para)
Sure. Removed.
> —
> /are now sent over SCTP/
> - The word /now/ may be confusing, when the spec in this ID will define a part of SCTP. Can you refer to a spec - RFC4960? Or say “Prior to publication of this specification, SCTP…”
Changed to
are sent over SCTP as specified in <xref target='RFC4960'/>
> —
> /a form of
> sender side head of line blocking becomes created within the
> protocol/
> - maybe this could be clearer, and perhaps even include an example to be sure the reader understands the benefit,
> /can result in a form of
> sender side head of line blocking (e.g., when transmission of an urgent message is blocked from transmission because the sender has started transmission of another, possibly larger, message)./
Taken.
> —
> /an scheduler implies/
> to
> /a scheduler implies/
Done.
> —
> Please expand “SACK” on first usage:
> /SACK chunks/
Done.
> —
> / The MID is also used for ensuring ordered delivery, therefore replacing the stream sequence number. /
> - the word “replacing” is ambiguous with respect to whether the stream sequence number is still set, etc. can we say “omitting” or say something that these fields are no longer present and equivalent functions are provided by …?
OK. Changed to:
<t>In addition, the MID is also used for ensuring ordered delivery instead
of using the stream sequence number, which has been omitted from the I-DATA
chunk.</t>
> —
> /Therefore, the head of line
> blocking caused by the original design is avoided./
> - I’m not sure this explains how this mechanism does this - I think this sentence could be re-worded, or even just omitted.
Sentence removed.
> —
> /and no DATA chunks./
> - Does this mean
> /. DATA chunks are not permitted when this has been negotiated./
Correct. Changed to
If I-DATA support has been negotiated for an
association I-DATA chunks are used for all user-messages.
DATA chunks are not permitted when I-DATA support has been negotiated.
> —
> Can the figures be referenced in section 1 also be used to illustrate some of the scheduler descriptions in section 3 (e.g., by backwards reference) ?
Could be. But the figures (as indicated) only show one scheduler, the round robin one.
> —
> / this field is NOT touched/
> — is touched a term used elsewhere in SCTP? If this is not a widely-understood term please replace by “updated” or “read” or some similar combination of terms.
https://tools.ietf.org/html/rfc4960#section-3.3.1
says in the description of the Payload Protocol Identifier:
Note that this field is NOT touched by an SCTP implementation;
> —
> /a sender MAY fragment
> multiple user message, each of them on different streams./
> - insert /s/ after message.
Done.
> —
> /SCTP packet containing a I-DATA chunk/
> should be
> /SCTP packet containing an I-DATA chunk/
Done.
> —
> /then the receiver MUST use the FSN
> for reassembly of the message and not the TSN/
> - perhaps it may be clearer to explicitly say:
> /then a receiver that has negotiated use of I-Data for a stream MUST use the FSN
> for reassembly of the message and not the TSN/
I-DATA is not used on a per-stream basis, but on a per association basis.
We have stated that, if I-DATA support is negotiated, no DATA chunks are
used on the association. So I think the original text is clearer.
> —
> /An ordered or unordered fragmented message
> is thus identified by not having both bits set./
> - I can’t unravel this sentence.
> - Is this perhaps clearer written in this style:
> /A message may be identified as being … by seeing that both bits have been set./
Changed to
A message (either ordered or unordered) may be identified as being fragmented
by seeing that not both bits have been set.</t>
> —
> /MUST be reset to 0 correspondingly./
> - I’m not sure what “correspondingly” means here, could this be omitted?
Removed.
> —
> /it should be noted
> that the implementation of [RFC6525] needs to handle this./
> - understood, but this kind of suggests all RFC6525 implementations need to do this… is it true? is it all implementations of I-Data need this?
An implementation needs to support this when used in combination with I-DATA. This is what
the whole section is about.
> —
> / The streams schedulers/
> - please change to:
> / The stream schedulers/
Done.
> —
> Section 4.2 uses the term /and being deprecated/.
> - It is not evident from reading this what that means.
Changed to "and marked as deprecated."
See https://tools.ietf.org/html/rfc6458#section-5.3.2 and
https://tools.ietf.org/html/rfc6458#section-5.3.3.
> —
> /EOR/
> - Please expand when first mentioned.
Done.
> —-
> I think section 6 (security consideration) could usefully note that applications need to consent to the use of out-of-sequence delivery. This is accomplished by applications needing to enable the extension via the transport API.
OK. Added
<t>It should be noted that the application has to consent that it is willing
to do the more complex reassembly support required for user message
interleaving.</t>

---

From: "Gorry (erg)" <[email-masked]>
Date: Mon, 31 Oct 2016 08:17:29 +0000

That seems good to me

Gorry

> On 31 Oct 2016, at 08:05, Michael Tuexen <[email-masked]> wrote:
> 
>