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

[Paul Kyzivat <[e-mail]>]

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

	Thanks,
	Paul

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
>      >>>
>     https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section
>      >>> -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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>