Re: [rtcweb] Meaning of SHOULD support/use interleaving

Christer Holmberg <> Mon, 27 October 2014 20:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2381B1AD40B for <>; Mon, 27 Oct 2014 13:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MmFYHFgzHd_m for <>; Mon, 27 Oct 2014 13:10:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F15171AD40A for <>; Mon, 27 Oct 2014 13:10:48 -0700 (PDT)
X-AuditID: c1b4fb25-f791c6d00000617b-bc-544ea6c7e570
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 97.BC.24955.7C6AE445; Mon, 27 Oct 2014 21:10:47 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 21:10:46 +0100
From: Christer Holmberg <>
To: Harald Alvestrand <>, "" <>
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: <>
References: <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-GB
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==
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving
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


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 :)



Sent from my Windows Phone
From: Harald Alvestrand<>
Sent: ‎27/‎10/‎2014 22:00
To: Christer Holmberg<>;<>
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
>>>>>                 [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 so, 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 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 data 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 arguments
that bear upon their usage in WebRTC.

I'm not sure I have WG consensus (even rough consensus) on this point,
> 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 transport 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.