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

[Michael Tuexen <[e-mail]>]

> On 10. Aug 2017, at 00:07, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> 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 :-)
I guess I wasn't clear enough in my e-mail:

I only added "(i. e. acknowledged by the cummulative TSN ACK)" at the end of
the sentences.

I have not changed anything related to the PPID. I thought that was clear enough.

But if you think some clarification might help, what about changing:

The Payload Protocol Identifier (PPID) and the FSN are stored at the
same location of the packet using the B bit to determine which value is
stored at the location.

to

The Payload Protocol Identifier (PPID) already defined for DATA chunks
in <xref target='RFC4960'/> and the new FSN are stored at the
same location of the packet using the B bit to determine which value is
stored at the location.

Best regards
Michael
> 
>  
> >
> > 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.
> 
> 
>