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

Paul Kyzivat <> Tue, 28 October 2014 22:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DA1591AD3A0 for <>; Tue, 28 Oct 2014 15:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zHGyXtB88Tmf for <>; Tue, 28 Oct 2014 15:14:35 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE7601AD3A2 for <>; Tue, 28 Oct 2014 15:14:22 -0700 (PDT)
Received: from ([]) by with comcast id 8mDt1p0055FMDhs01mELel; Tue, 28 Oct 2014 22:14:20 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id 8mEK1p00e3Ge9ey01mELp3; Tue, 28 Oct 2014 22:14:20 +0000
Message-ID: <>
Date: Tue, 28 Oct 2014 18:14:19 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1414534460; bh=9EsUru1XY99UOOjRgbgPH9p0Px4Izs+e9Nd9vKgphKA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HsLXcUdWDgDStiwBaJs97I+83yFVFCWo7AzvTllZ+kBrIKsiIuLRhqrGIyhCddvzt TiinQrKhABTA3tKfh+XRFhPJV//nuJ1buBZ8N+sCcBA0DT8M2ltdeJs4/vKuvyfbzf SR1aQq+YfFcxfwd1ZXn6PBLbeNgFdU9CPZ2TcGSy2d5bw3GmANXiFW56Udl0bNBEfj zg+GQGE9SeA9pzwHOnnVJ+kqzq1odKISaQjeGzvK9ZgcUR7NIPQmshwWMpDGv1JsHJ dEIJB7cmtEIOwZ4Zc70U4lHZ9opea9yalfDJ1lhYhqr4bBqUAH46GQ/Fr3rTfaxH1H rNO8fHAHvbRWw==
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: Tue, 28 Oct 2014 22:14:37 -0000

Mary pointed out an important typo in this message. Correction inline.

On 10/28/14 4:13 PM, Paul Kyzivat wrote:
> (This thread has gotten long, and its hard to figure where to jump in.
> I'm just replying to the last message I see, but am commenting on the
> thread in total.)
> Regarding data channels being webrtc-specific:
> I don't see it that way. Webrtc has opened up restricted communication
> among browsers. If you want to talk to a browser, you have few choices,
> and this is the one that is "general purpose". So any application that
> sometimes might need to run in a browser is a likely candidate for data
> channels. And then, when non-browser versions of that app are talking to
> one another, it will be most practical to use the same mechanism.
> That is why CLUE is using data channels - even if we think that *most*
> of the endpoints won't be in browsers.
> Regarding NDATA:
> ISTM that SCTP just screwed up in not including the NDATA features in
> the base protocol. Going forward, it always should be included in new
> implementations. Since data channels are being defined after NDATA, it
> is perfectly reasonable for data channels to require NDATA support.
> IIUC, while NDATA allows fragmentation to avoid head of line blocking,
> that doesn't mean the messages will be fragmented unnecessarily. If you
> are only using one channel I *think* it likely that even a large message
> won't be fragmented. So it will be harmless insurance.
> Christer said that since CLUE only needs one data channel there is no
> need for NDATA. Someone specifying BFCP over data channel might reach a
> similar conclusion for it. But there is nothing to prevent an
> application that implements both CLUE and BFCP. Independently they
> wouldn't need NDATA, but together they would.
> So I am in favor of making NDATA mandatory to implement, offer, and
> accept for data channels.
> But I would still like the data channel spec to acknowledge that, while
> webrtc is a *very* important client, that the protocol solely for
> webrtc. And with that in mind I would like to see "webrtc" removed from
> the name of the protocol. (E.g., in the SDP m-line.)

What I meant to say in the last paragraph is:

But I would still like the data channel spec to acknowledge that, while 
webrtc is a *very* important client, that the protocol *is not* solely 
for webrtc. And with that in mind I would like to see "webrtc" removed 
from the name of the protocol. (E.g., in the SDP m-line.)


> On 10/28/14 1:53 PM, Christer Holmberg wrote:
>> Hi,
>>      >>> I am not suggesting different flavors - I am suggesting to make
>>     the usage of
>>      >>> interleaving optional. Other SCTP features are also optional
>>     (including reliability, ordering etc).
>>      >>>
>>      >>> Where are these things optional? According to
>>      >>>
>>      >>> -6.1 an implementation MUST implement PR-SCTP and the support
>>     of the
>>      >>> FORWARD-TSN chunk will be negotiated similar to the NDATA
>>     chunk. I don't see a difference, especially not if we move to MUST
>>     support NDATA.
>>      >>
>>      >> For example, section 6.1 says:
>>      >>
>>      >>      "The partial reliability extension defined in [RFC3758]
>>     MUST be supported."
>>      >>
>>      >> However, in CLUE we say that a CLUE entity MUST NOT *use* the
>>     extension, as all CLUE messages are required to be sent reliably.
>>      >
>>      > That is OK. However, support for PR-SCTP MUST be there and it
>>     will be negotiated. You just never send a message with partial
>>     reliability. At least this is my understanding...
>>     So, can the same be done for interleaving? I.e. the support MUST be
>>     there, but e.g. CLUE entities can choose not to use it?
>>     Note that my issue is not about support, it's about usage :)
>> What resource is being conserved by not just requiring it?
>> I don’t know. The task is to figure out whether there are *technical*
>> reasons to mandate usage of certain SCTP features for CLUE.
>> Regards,
>> Christer
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list