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

[Paul Kyzivat <[e-mail]>]

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

	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
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>