Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12
Benoit Claise <bclaise@cisco.com> Fri, 01 September 2017 06:59 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19906133280; Thu, 31 Aug 2017 23:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khhEJ17sxwvH; Thu, 31 Aug 2017 23:59:40 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133C7133174; Thu, 31 Aug 2017 23:59:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46152; q=dns/txt; s=iport; t=1504249179; x=1505458779; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=OCVcTD8UJ8w/FMbswvfqL5cF+zEIAAaPxleozhQ/ZNY=; b=CKzV3cIwVpm6tHWxhioTw52d0r7CZPeF9bXqQunngALteiitIlzRl6BG QxPB1flbuJOwLInzrsUA6eCNhOnTq5B9mafEMwa2uZcZzf+0rCjAzJzi5 o4CMNr2MQummtiYTVHHvHIlBf49TB/Qr83TiBzXcDZ2AvUIc/CMsW8WET Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BvAQDvBKlZ/xbLJq1dGQEBAQEBAQEBAQEBBwEBAQEBhD6BFY8LkHErd4dCkAAuhRkChFEVAQIBAQEBAQEBayiFGAEBAQECARoJTQkFCwsYIAEGAwICISURBgEMBgIBAReJfgMNCBCvXYInJ4cUDYQaAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDKoNQgWMrgXBYNYJXhTGCYQWKCJYrPIdbYYcfhHaCE4Vng1mHG4xOgQSIczUigQ0yIQgcFUmEXzkcgWk+NgWKWQEBAQ
X-IronPort-AV: E=Sophos;i="5.41,457,1498521600"; d="scan'208,217";a="654323011"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2017 06:59:33 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v816xXfG020836; Fri, 1 Sep 2017 06:59:33 GMT
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Michael Tuexen <tuexen@fh-muenster.de>
Cc: Stefan Winter <stefan.winter@restena.lu>, "ops-dir@ietf.org" <ops-dir@ietf.org>, draft-ietf-tsvwg-sctp-ndata.all@ietf.org, "tsvwg@ietf.org" <tsvwg@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, IESG IESG <iesg@ietf.org>
References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> <FDCFFA8C-8828-4578-A66E-A1AD7FF9BDC9@fh-muenster.de> <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> <F05D0F1F-47E2-4477-BFD9-F0119A4609FC@fh-muenster.de> <f4d121e4-44f5-e85d-98b1-bbea317a7539@cisco.com> <5CEB294C-AAC8-4F03-901D-487CD62BB491@fh-muenster.de> <41a1e8f1-2398-4d94-7021-638acdd58eb7@cisco.com> <1FFDADBA-4132-4D3B-B68C-A89A50AF1E24@fh-muenster.de> <CAKKJt-dM1q9NDe8r=q-aqdWW0i3i8mSYLCNssU4cvjo22GRRyw@mail.gmail.com> <BD327429-5C8F-4034-A9E7-834FDB1E7FB6@fh-muenster.de> <CAKKJt-fuJWEMd79Z2zRmg4GU8hpVcqSfN+Y6xLioMUmwu8d6fw@mail.gmail.com> <0E628ABF-6E0E-40A6-87EE-CA94A93FE0A5@fh-muenster.de> <CAKKJt-c5CnGnpP9Ky8j6=jvPpygLG+t2UZhF68+XP8p4x06veA@mail.gmail.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <78e79022-4f9b-c093-27fb-b6392d4cc689@cisco.com>
Date: Fri, 01 Sep 2017 08:59:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CAKKJt-c5CnGnpP9Ky8j6=jvPpygLG+t2UZhF68+XP8p4x06veA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------4BCF4298F57F46930484D486"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/FVNbH6KWLnRSkxN5dkdKtBXyT1Q>
Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Sep 2017 06:59:44 -0000
On 8/31/2017 11:01 PM, Spencer Dawkins at IETF wrote: > Hi, Michael, > > On Thu, Aug 31, 2017 at 2:56 PM, Michael Tuexen <tuexen@fh-muenster.de > <mailto:tuexen@fh-muenster.de>> wrote: > > > > On 31. Aug 2017, at 15:46, Spencer Dawkins at IETF > <spencerdawkins.ietf@gmail.com > <mailto:spencerdawkins.ietf@gmail.com>> wrote: > > > > Hi, Michael, > > > > On Thu, Aug 31, 2017 at 8:25 AM, Michael Tuexen > <tuexen@fh-muenster.de <mailto:tuexen@fh-muenster.de>> wrote: > > > On 31. Aug 2017, at 14:50, Spencer Dawkins at IETF > <spencerdawkins.ietf@gmail.com > <mailto:spencerdawkins.ietf@gmail.com>> wrote: > > > > > > Just interjecting ... > > > > > > On Thu, Aug 31, 2017 at 7:25 AM, Michael Tuexen > <tuexen@fh-muenster.de <mailto:tuexen@fh-muenster.de>> wrote: > > > > > > > On 31. Aug 2017, at 14:14, Benoit Claise <bclaise@cisco.com > <mailto:bclaise@cisco.com>> wrote: > > > > > > > > Hi Michael, > > > >>> On 30. Aug 2017, at 18:51, Benoit Claise > <bclaise@cisco.com <mailto:bclaise@cisco.com>> 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 > <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? > > > Since I'm not sure which timezone Benoit is in (except that I know > it's Yang Central Time), I'll respond by saying that I did talk with > Benoit on the call, after sending him this privately: > > > This is tripping over the same thing I was tripping over - SCTP > standards haven't had a stream scheduler, but SCTP implementations > scheduled streams. So Michael was thinking that you were asking > about forcing existing implementations to implement one of the new > ones. > > His response was to propose text basically saying "in addition to > what you're doing now, you MAY do one or more of the following". > > I'm sorry I garbled my point so badly. > > Benoit said on the call (if I understood him correctly) that my > explanation (filtered through your correction) worked for him. The > point I was trying to make earlier was that SCTP implementations > scheduled streams somehow, and that your document wasn't an effort to > tell them to stop doing what they were doing, but that implementers > now had more standardized options than they did before. > > I think your proposed text says that well. > > At this point, I think you're ready to submit a revised ID to reflect > the comments you've received. I'll review your changes, and that will > give Benoit a chance to interrupt if he needs to - no interrupt needed. I'll trust the venerable Spencer. Regards, Benoit > he's quite responsive, especially when he doesn't spend the evening on > a telechat. > > Thanks, and it's always a pleasure. > > Spencer > > > > > Spencer > > > > Best regards > > Michael > > > > > > ? > > > > > > Spencer > > > > > >
- [tsvwg] Opsdir last call review of draft-ietf-tsv… Stefan Winter
- Re: [tsvwg] Opsdir last call review of draft-ietf… Michael Tuexen
- Re: [tsvwg] [OPS-DIR] Opsdir last call review of … Stefan Winter
- Re: [tsvwg] [OPS-DIR] Opsdir last call review of … Michael Tuexen
- Re: [tsvwg] [OPS-DIR] Opsdir last call review of … Benoit Claise
- Re: [tsvwg] [OPS-DIR] Opsdir last call review of … Michael Tuexen
- Re: [tsvwg] [OPS-DIR] Opsdir last call review of … Benoit Claise
- Re: [tsvwg] [OPS-DIR] Opsdir last call review of … Michael Tuexen
- Re: [tsvwg] [OPS-DIR] Opsdir last call review of … Spencer Dawkins at IETF
- Re: [tsvwg] [OPS-DIR] Opsdir last call review of … Benoit Claise
- Re: [tsvwg] [OPS-DIR] Opsdir last call review of … Michael Tuexen
- Re: [tsvwg] [OPS-DIR] Opsdir last call review of … Michael Tuexen
- Re: [tsvwg] [OPS-DIR] Opsdir last call review of … Spencer Dawkins at IETF
- Re: [tsvwg] [OPS-DIR] Opsdir last call review of … Michael Tuexen
- Re: [tsvwg] [OPS-DIR] Opsdir last call review of … Spencer Dawkins at IETF
- Re: [tsvwg] [OPS-DIR] Opsdir last call review of … Benoit Claise