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

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

Hi, Michael,

On Wed, Aug 9, 2017 at 5:17 PM, Michael Tuexen <
[e-mail]> wrote:

>
> > 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 <Michael.Tuexen@lurchi.
> franken.de> 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.
>

Upon reflection, you're right, of course. That should be clear enough.

Please feel free to submit an update that I can process.

And thanks for the quick response.

Spencer


> 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.
> >
> >
> >
>
>