> On 31. Aug 2017, at 15:46, Spencer Dawkins at IETF <spencerdawkins.ietf@xxxxxxxxx> wrote: > > Hi, Michael, > > On Thu, Aug 31, 2017 at 8:25 AM, Michael Tuexen <tuexen@xxxxxxxxxxxxxx> wrote: > > On 31. Aug 2017, at 14:50, Spencer Dawkins at IETF <spencerdawkins.ietf@xxxxxxxxx> wrote: > > > > Just interjecting ... > > > > On Thu, Aug 31, 2017 at 7:25 AM, Michael Tuexen <tuexen@xxxxxxxxxxxxxx> wrote: > > > > > On 31. Aug 2017, at 14:14, Benoit Claise <bclaise@xxxxxxxxx> wrote: > > > > > > Hi Michael, > > >>> On 30. Aug 2017, at 18:51, Benoit Claise <bclaise@xxxxxxxxx> wrote: > > >>> > > >>> Michael, > > >>> > > >>> I stumbled on the same point as Stefan. > > >> Hi Benoit, > > >> > > >> thanks for reviewing the document. See my comments in-line. > > >> > > >> Best regards > > >> Michael > > >>> First of, I had to review RFC4960 for TSN/SSN. I was not sure whether TSN was per stream or not > > >>> It would have helped me to repeat this information in the intro. > > >>> Ok, to be candid, I deduced this information from figure 1 and 2. > > >>>>>>> And the rest are only musings not needing any action if the authors don't want > > >>>>>>> to action on them: > > >>>>>>> > > >>>>>>> The introduction presents a good use case, quoting: "e.g., when the > > >>>>>>> transmission of an urgent > > >>>>>>> message is blocked from transmission because the sender has started > > >>>>>>> the transmission of another, possibly large, message". > > >>>>>>> > > >>>>>>> The later queueing example in figure 1 has three SIDs being queued > > >>>>>>> simultanseously. It is not clear which of those "has already started" and which > > >>>>>> There is actually one message queued for stream 0, three messages for stream 1, > > >>>>>> and one message for stream 2. > > >>>>>>> are the important ones being delayed. For a better understanding of the reader, > > >>>>>> The figure is about in which sequence they are put on the wire. So no > > >>>>>> transmission has startet. This examples also does not deal with the case > > >>>>>> of one stream having a higher priority than another. That would be an > > >>>>>> example using a priority scheduler. This examples illustrates the round > > >>>>>> robin scheduler. > > >>>>>> The point here is that a single scheduler (the round robin scheduler, for > > >>>>>> example) behaves differently when user message interleaving is used or not. > > >>>>>> That is an important point: You can even use the schedulers with regular > > >>>>>> DATA chunk, i.e. with user message interleaving being negotiated. > > >>> This was my source of confusion. > > >>> With figure 1 and figure 2, you want to show the effect of Round Robin Scheduler with and without User Message Interleaving, while we were expecting the figure 2 to be the solution from this spec. Hence Stefan and I were looking for this "urgent message" in figure 2. > > >> I don't know what you mean with "solution from this spec" means. This spec introduces > > >> stream schedulers and a protocol extension to allow interleaving of user messages. > > >> Using this to implement an "urgent" concept is only one possibility: usage of a > > >> strict priority scheduler (SCTP_SS_PRIO). So this "urgent" is misleading. It seems > > >> to ring the wrong bells. That is why I suggested to remove it... > > >>>>>>> it might be useful to revise the figure so that the head-of-line blocking > > >>>>>>> happens for SID 1 because transmission of 0 and 2 has already started (and > > >>>>>>> declare SID 1 to be the "important" message). The ASCII art would just have to > > >>>>>>> indent SID 1 content a bit (placing 0 and 2 earlier in time), and the resulting > > >>>>>>> serialisation would then put all the SID 1 messages at the very end, when 0 and > > >>>>>>> 2 have been completely submitted (right?). > > >>>>>> One could think about adding another example based on the priority scheduler > > >>>>>> and giving stream 1 a higher priority. But for illustrating the point of > > >>>>>> schedulers behaving differently depending on the negotiation of user message > > >>>>>> interleaving this seems not necessary. > > >>>>> That second example might indeed be useful. > > >>>>> > > >>>>> It's simply a bit strange that in the introduction you speak about an > > >>>>> "urgent" message (something deserving a higher-priority sending) and > > >>>>> that another transmission has already started - but then the example has > > >>>>> none of those two. > > >>> Exactly. > > >>> Please add this extra example. > > >>> This would also clarify from the introduction that when you write ... > > >>> > > >>> The sending of such large messages over > > >>> SCTP as specified in [RFC4960] can result in a form of sender side > > >>> head of line blocking (e.g., when the transmission of an urgent > > >>> message is blocked from transmission because the sender has started > > >>> the transmission of another, possibly large, message). > > >>> > > >>> .. the notion of transmission urgency is not within a stream but across streams, and that can be achieved with a priority scheduler. > > >> I would actually prefer to remove the word "urgent" from that sentence. This just rings the wrong bells. > > > That's a missed opportunity in mind, but your call. > > Hmm. Let me remove the word "urgent"... > > > > Yes, please! I wasn't wild about it, either. > It's done: > https://github.com/sctplab/sctp-idata/commit/cf7b331512cd85d6195eb88fa96360673293323f > > > > >>> The text might have to be rephrased to explain that this spec provides the ability to create stream scheduler with different relative stream treatments. > > >> What about: > > >> > > >> OLD TEXT > > >> This document also defines several stream schedulers for general SCTP > > >> associations. The stream schedulers may behave differently depending > > >> on whether user message interleaving has been negotiated for the > > >> association or not. > > >> > > >> NEW TEXT > > >> This document also defines several stream schedulers for general SCTP > > >> associations allowing different relative stream treatments. > > >> The stream schedulers may behave differently depending > > >> on whether user message interleaving has been negotiated for the > > >> association or not. > > >> > > >> Would that address this issue? > > > ok. > > Fixed. > > >> > > >>> And also that urgent message would be placed in this high priority stream scheduler (reliable, I guess, but that's orthogonal) stream. > > >> I really would like to get rid of this. I don't think giving the strict > > >> priority scheduler as specific role here is a good idea. > > >> > > >> The RR scheduler was chosen as the simplest scheduler to illustrate > > >> that scheduler can behave differently when using interleaving or not. > > >>>> What about removing the word "urgent" from that sentence. > > >>>>> In fact I wonder why you speak about urgent things in the introduction > > >>>>> at all. Neither the scheduler nor the interleaving are designed to help > > >>>>> urgent things to be sent earlier. > > >>>>> > > >>>>> All they do is make the transmission fairer so that *all* chunks get a > > >>>>> more even serialised distribution on the wire. > > >>>> That is not true in general. If you use the priority scheduler, one > > >>>> stream gets preferred treatment. It also makes sure that the time > > >>>> of a message spent in the stream queue is shorter. So these messages > > >>>> get sent earlier. > > >>>> In the case of the round robin scheduler, you are right that this is > > >>>> about getting fairer treatment. If you take the WFQ scheduler, the > > >>>> streams don't get the same treatment, but it depends on the weight > > >>>> given to the stream. > > >>>>> So, rather than saying that the spec helps urgent things to be sent > > >>>>> earlier, it should maybe rather state that the spec helps every message > > >>>>> getting an equal, and equally distributed, share of the medium. > > >>>> It is not meant that the spec does this. It was one example, what > > >>>> a particular stream scheduler does. But there are multiple schedulers > > >>>> defined in the document. > > >>>> > > >>>> The RR scheduler example is not intended to illustrate what you can do > > >>>> with all the schedulers, but that using message interleaving or not > > >>>> has an impact on the scheduler. That is meant by stating: > > >>>> > > >>>> This document also defines several stream schedulers for general SCTP associations. > > >>>> The stream schedulers may behave differently depending on whether user message > > >>>> interleaving has been negotiated for the association or not. > > >>>> > > >>>> This is followed by illustrating this using the RR scheduler. > > >>>> > > >>>> Best regards > > >>> Also, I don't see the value of the last sentence in this paragraph, especially with RFC2119 MAY. > > >>> > > >>> 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. An > > >>> implementation MAY implement any subset of them. > > >> During the review the question was brought up which scheduler have to be implemented > > >> by an implementation. This sentence was add to address it. > > >> If you want, I can remove it. > > > The point is that the MAY is that sentence doesn't mean anything. > > > Maybe you mean: > > > > > > An implementation MUST implement at least one stream scheduler. > > That would require an implementation to implement at least one of > > the ones being listed. You are right in the sense that an implementation > > MUST implement at least one stream scheduler, but the original text > > allows that one not to be specified in this document. > > > > Are you saying that an implementation MUST implement one of list defined > > by this document? > > > > I'm pretty sure (and this came up in my AD review) the problem is that the original specification DID define a stream scheduler, that's wasn't called a stream scheduler, but SCTP implementations did schedule streams. And that didn't matter until there was more than one way to schedule streams (as in this document). > The original specification did NOT specify a stream scheduler and left this completely implementation > specific. > Right now Linux is using (and only supporting a single scheduler) what we call in this document > SCTP_SS_FCFS. FreeBSD's default scheduler is what we call in this document SCTP_SS_RR and > Solaris uses one of these, forgot which one. Among these kernel implementations, only FreeBSD > supports multiple streams schedulers and its selection. Possibly other closed source SCTP > implementations might support other schedulers. Don't know. > > Thanks for getting that right for me ... > > Spencer > > > So you're working out better wording that says something like "in addition to the way the original specification scheduled streams, we're defining more of them". I think. > I think we wanted to say something like: > > Here is a list of schedulers. Your implementation might support some of them, but this is > left open. So you can't rely on it. > > The list of schedulers we specified includes the ones being used as default by FreeBSD, Linux and > Solaris and was extended by the ones supported by FreeBSD and the one explicitly required by > WebRTC, which is SCTP_SS_WFQ. > > What about this change: > > OLD TEXT: > An implementation MAY implement any subset of them. > > NEW TEXT: > An implementation MAY implement any subset of them. If the implementation > is used for WebRTC Datachannels as specified in [I-D.ietf-rtcweb-data-channel] > it MUST implement the Weighted Fair Queueing Scheduler defined in Section 3.6. > > That works for me, but I'll let Benoit reply. Benoit? > > Spencer > > Best regards > Michael > > > > ? > > > > Spencer > >
<<attachment: smime.p7s>>