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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Michael,

This all looks lovely. I had one question (below), but I'll request Last
Call anytime you submit an update.

And thanks for your help.

Spencer

On Wed, Aug 9, 2017 at 7:35 AM, Michael Tuexen <
[e-mail]> wrote:

> > On 18. Jul 2017, at 20:26, Spencer Dawkins at IETF <
> [e-mail]> wrote:
> >
> > 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.
> Hi Spencer,
>
> thanks you very much for the review. See my comments in-line. The changes
> are in the GitRepo at
> https://github.com/sctplab/sctp-idata
> so submitting an updated version is pretty easy.
>
> Let me know if I addressed you issues.
>
> Best regards
> Michael
> >
> > 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.
> The point is that you can use one scheduler not matter if user message
> interleaving
> has been negotiated or not. But this scheduler can behave different in the
> following
> two cases:
> 1. User message interleaving has been negotiated.
> 2. User message interleaving has not been negotiated.
>
> I'll use the second text also in the first place. An example is given in
> the paragraph following
> the above sentence.
> >
> > 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.
> This document specifies two things:
> 1. Stream Schedulers (like the round robin one used in the example), which
> require late TSN
>    assignments.
> 2. User message interleaving requiring the I-DATA chunk (and
> I-FORWARD-TSN).
>
> You can implement Schedulers with implementing user message interleaving.
> FreeBSD had
> several schedulers way before implementing user message interleaving. You
> just need to
> do late TSN assignments. So an RFC 4960 based implementation can implement
> these schedulers
> as long as they use late TSN assignment.
> >
> > Also, could you provide a reference for "late TSN assignment"? This is
> the first usage in the document.
> Hmm. Not sure it is specified anywhere. It is a term we use. It describes
> when you assign the TSN
> to chunks. Conceptually you could do that as soon as the user provides a
> message. Split it up in
> chunks, assign TSNs and process them. That would be early assignment. Or
> you wait with splitting up
> as long as possible, just before you need to send the chunk. That is late
> assignment.
>
> I can add the following sentence to explain "late TSN assignment":
>
> Late TSN assignment means that the sender generates chunks from user
> messages and assigns
> the TSN as late as possible in the process of sending the user messages.
>
> >
> > 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.
> I have added
> The interleaving of user messages is required for WebRTC Datachannels.
> at the end of the first paragraph of the abstract to avoid using references
> in the abstract.
> >
> > 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.
> Fixed with using Partial Reliability extension and Stream Reconfiguration
> extension.
> >
> > 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
> ...
> TSN's which have not been acked via the cumack, but only via gap acks can
> be revoked or reneged
> by the the receiver. The term "reneged" is used in RFC 4960.
>
> I'm using this wording to cover the RFC 4960 case and also a potential
> extension
> https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath-14#section-4
> which is implemented in FreeBSD and also the userland stack used in web
> browsers.
>
> But I can add (i. e. acknowledged by the cummulative TSN ACK) at the end
> of the
> above sentence.
>
> The PPID is also well known, since the Payload Protocol Identifier is
> defined for
> DATA chunks in RFC 4960.
>

I didn't see this change in Github. If you were offering to make the change
if I thought it was helpful, I think it's helpful :-)



> >
> > 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".
> Fixed.
> >
> > 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".
> Fixed.
> >
> > 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.
> The suggested type is 64, which has the binary representation 01000000.
> According to https://tools.ietf.org/html/rfc4960#section-3.2 the required
> behaviour is:
> Stop processing of the packet, discard the chunk, report the chunk in an
> 'Unrecognized Chunk Type'
> error cause contained in an ERROR chunk.
> This is the handling of an unknown chunk having a type with upper bits 01
> required by RFC 4960.
>
> We are sending the ABORT, since the peer sends an I-DATA chunk and support
> for it
> has not been negotiated. That is a bug on the peer side. So we send an
> ABORT
> indicating a protocol violation.
> >
> > 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.
> The I-FORWARD-TSN chunk has 194 as a suggested type, which has the binary
> representation 11000010.
> According to https://tools.ietf.org/html/rfc4960#section-3.2 the required
> behaviour is:
> Continue processing of the packet, discard the chunk, report the chunk in
> an 'Unrecognized Chunk Type'
> error cause contained in an ERROR chunk.
> This is the handling of an unknown chunk having a type with upper bits 11
> required by RFC 4960.
>
> We are sending the ABORT, since the peer sends an I-FORWARD-TSN chunk and
> support fir it
> has not been negotiated. That is a bug on the peer side. So we send an
> ABORT
> indicating a protocol violation.
> >
> > 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.
> The point is that without the possibility of interleaving user messages,
> you have
> to finish the sending of the lower priority message before you can start
> sending
> higher priority message. If you can interleave messages, you don't have to
> finish
> the sending of the lower priority one.
>
> I think the following describes it better:
>
> When using user message interleaving, the sending of large lower priority
> user
> messages will not delay the sending of higher priority user messages.
>
>
>