Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2381B1AD40B for ; Mon, 27 Oct 2014 13:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 MmFYHFgzHd_m for ; Mon, 27 Oct 2014 13:10:49 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15171AD40A for ; Mon, 27 Oct 2014 13:10:48 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-bc-544ea6c7e570 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 97.BC.24955.7C6AE445; Mon, 27 Oct 2014 21:10:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 21:10:46 +0100 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: Ac/x55WTmtr0wn1FRpKkoOi9WMJX3////5gA///tr8CAAFjuAP//7KkQgAAunYCAABOJKw== Date: Mon, 27 Oct 2014 20:10:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CEBED@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <544EA473.6040700@alvestrand.no> In-Reply-To: <544EA473.6040700@alvestrand.no> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4CEBEDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje7xZX4hBu+XCFgc6+tis1j7r53d gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4sbmTreC7a8Xl3xENjNutuhg5OSQETCTu HJ/JDGGLSVy4t56ti5GLQ0jgCKPElFU9jBDOEkaJe08b2LsYOTjYBCwkuv9pgzSICARL9D5/ zwhiCws4SJzdOYkdIu4o0fb2PBOEHSYxs7eHFcRmEVCV+Pt9OVgNr4CvxI6X91kh5l9hkvj9 /itYEaeArsS8Dx/BhjICXfT91BqwQcwC4hJNX1ayQlwqILFkz3moq0UlXj7+xwpRky/R/fEk 1AJBiZMzn7BMYBSehaR9FpKyWUjKIOIGEl/e34aytSWWLXzNDGHrS3S/P82ELL6AkX0Vo2hx anFSbrqRsV5qUWZycXF+nl5easkmRmD8HNzyW3UH4+U3jocYBTgYlXh4P9T4hgixJpYVV+Ye YpTmYFES5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkaRPA3ByUt8NwsxxZ2pq0k4 tirk0JGMLQtO3tE/UbXg08PZCuLXKvY7XI5yj94bmm/Z6/25f6r4qokx63pdJ0d8SX6mx5fS YW7JZHaPcdn3zpIzcndzsnrkhRsFDlUVWjRKr172fg3rjq8anqd3RtzsqXn6cmn/92qPJaca V3H87Qp+z5RSXqDEUpyRaKjFXFScCABI59PHgAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ETDY4-W7uahdOlKth9dMo--d2IA Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:10:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4CEBEDESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, We shall not add burden just because there are bad programmers out there - = they will anyway always manage to use our specs in a wrong way :) Regards, Christer Sent from my Windows Phone ________________________________ From: Harald Alvestrand Sent: =FD27/=FD10/=FD2014 22:00 To: Christer Holmberg; rtcweb@ietf.o= rg Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving On 10/27/2014 11:41 AM, Christer Holmberg wrote: > Hi, > >>>>> Within the CLUE WG, we had a discussion regarding the following state= ment in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: >>>>> >>>>> "The support for message interleaving as defined in >>>>> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." >>>>> >>>>> First, it is a little unclear what "the support SHOULD be used" means= . >>>> My understanding is that SCTP implementations supporting the extension= will use it. >>>> This is negotiated during the setup of the SCTP association. >>> If it's done on SCTP level, why do we need to talk about it in the data= channel draft? >>> >>> Is there a reason why it is important to use it for data channels? If s= o, does it apply to data channels in general? >> NDATA was added in order to avoid head-of-line blocking on the transport= (if I understand this correctly, until >> this was added, sending a huge message would block the delivery of small= messages on all channels until the huge message was fully delivered). >> >> Unlike Michael, I see no reason to make this a SHOULD; I think it should= be a MUST, and the older >> implementations in browsers should just be called out as non-conformant. >> >> That said, I think that data channels ought to interoperate successfully= with implementations that don't support the >> extension - but data channel implementations in WebRTC endpoints should = be under a "MUST implement, MUST offer" ruleset. > First, keep in mind that I am NOT talking about WebRTC endpoints (which i= s one reason we shouldn't call it webrtc data channel to begin with, but th= at's another story...), but ANY type of endpoint that wants to use a data c= hannel. I'm a bit self-centric on behalf of WebRTC, but I feel the other way - that it might have been a mistake to float the option of saying "other things can use these features", and that we should admit only arguments that bear upon their usage in WebRTC. I'm not sure I have WG consensus (even rough consensus) on this point, however. > > Second, I am not talking about MUST support, but MUST use/offer. > > Assume I have a CLUE endpoint, which will use a data channel ONLY to tran= sport CLUE messages. CLUE messages aren't that hugeto begin with, and there= will be no blocking of small messages on other channels - as there are no = other channels. > > So, why does the CLUE endpoint need to offer interleaving? Flipping the question around - if a programming mistake in the Javascript implementing a CLUE endpoint in a WebRTC browser happens to send a multimegabyte-sized object down the (out of order) datachannel, is it OK to have all the subsequent CLUE messages delivered 30 seconds late= ? -- Surveillance is pervasive. Go Dark. --_000_7594FB04B1934943A5C02806D1A2204B1D4CEBEDESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

We shall not add burden just because there are bad programmers out there - = they will anyway always manage to use our specs in a wrong way :)

Regards,

Christer

Sent from my Windows Phone
From: Harald Alvestrand
Sent: =FD27= /=FD10/=FD2014 22:00
To: Christer Holmberg; rtcweb@ietf.org
Subject: Re: [= rtcweb] Meaning of SHOULD support/use interleaving

On 10/27/2014 11:41 AM, Christer Holmberg wrote: > Hi,
>
>>>>> Within the CLUE WG, we had a discussion regarding the = following statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt= :
>>>>> 
>>>>> "The support for message interleaving as defined = in
>>>>>         &= nbsp;       [I-D.ietf-tsvwg-sctp-ndata] SHOUL= D be used."
>>>>> 
>>>>> First, it is a little unclear what "the support S= HOULD be used" means.
>>>> My understanding is that SCTP implementations supporting t= he extension will use it.
>>>> This is negotiated during the setup of the SCTP associatio= n.
>>> If it's done on SCTP level, why do we need to talk about it in= the data channel draft?
>>>
>>> Is there a reason why it is important to use it for data chann= els? If so, does it apply to data channels in general?
>> NDATA was added in order to avoid head-of-line blocking on the tra= nsport (if I understand this correctly, until
>> this was added, sending a huge message would block the delivery of= small messages on all channels until the huge message was fully delivered)= .
>>
>> Unlike Michael, I see no reason to make this a SHOULD; I think it = should be a MUST, and the older
>> implementations in browsers should just be called out as non-confo= rmant.
>>
>> That said, I think that data channels ought to interoperate succes= sfully with implementations that don't support the
>> extension - but data channel implementations in WebRTC endpoints s= hould be under a "MUST implement, MUST offer" ruleset.
> First, keep in mind that I am NOT talking about WebRTC endpoints (whic= h is one reason we shouldn't call it webrtc data channel to begin with, but= that's another story...), but ANY type of endpoint that wants to use a dat= a channel.

I'm a bit self-centric on behalf of WebRTC, but I feel the other way -
that it might have been a mistake to float the option of saying "other=
things can use these features", and that we should admit only argument= s
that bear upon their usage in WebRTC.

I'm not sure I have WG consensus (even rough consensus) on this point,
however.
>
> Second, I am not talking about MUST support, but MUST use/offer.
>
> Assume I have a CLUE endpoint, which will use a data channel ONLY to t= ransport CLUE messages. CLUE messages aren't that hugeto begin with, and th= ere will be no blocking of small messages on other channels - as there are = no other channels.
>
> So, why does the CLUE endpoint need to offer interleaving?

Flipping the question around - if a programming mistake in the
Javascript implementing a CLUE endpoint in a WebRTC browser happens to
send a multimegabyte-sized object down the (out of order) datachannel,
is it OK to have all the subsequent CLUE messages delivered 30 seconds late= ?



--
Surveillance is pervasive. Go Dark.


 --_000_7594FB04B1934943A5C02806D1A2204B1D4CEBEDESESSMB209erics_--