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

Paul Kyzivat <> Tue, 28 October 2014 20:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 02D241ACF58 for <>; Tue, 28 Oct 2014 13:17:53 -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, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B8tIVi_jHovv for <>; Tue, 28 Oct 2014 13:17:51 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F11E1ACE15 for <>; Tue, 28 Oct 2014 13:13:03 -0700 (PDT)
Received: from ([]) by with comcast id 8kAb1p00557bBgG01kD36F; Tue, 28 Oct 2014 20:13:03 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id 8kD21p00K3Ge9ey01kD2Du; Tue, 28 Oct 2014 20:13:03 +0000
Message-ID: <>
Date: Tue, 28 Oct 2014 16:13:02 -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=1414527183; bh=cqsrqcX9uDrMJcuCU9f5H3XQgMHW7oRwqmqbhL1ugDI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TkexlvArZmK7DwKfeurYQsYFMJghVh/F1iSKVIll8fJ3cUzMS2gkX0R8UwnIsE1B5 w5auY0GzRD01ik7ayxmfAv1U1F8x0hogGiDG3REw4XgoS0yrSwUa7GzgH2XQGaGmDC zMQWy5QONx5I0kZiO9bBk7hfl42GLFifkJNnB6GLADQhYPQEFDzn9FdNZK7+DvIFwF 1ZBKkrDxyN/Lmlua3iWBa7nsK8wr96SCzDj69t7So9nAK5mn4jrLXzUghiZ2uZaSfU QOKBUcLiu3D2zimR9dtNhC1WSPzf2UFHhn37mRSv12sw5ywn/gHWDr94nliAZSxIem OQNS+daY1c+xQ==
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 20:17:53 -0000

(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.)


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