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

[Christian Groves <[e-mail]>]

+1 for removing webrtc from data channel and making it clearer that it 
can be used as a general mechanism. That's why I thought there should be 
a separate ALPN in draft-ietf-rtcweb-alpn-00 for data channel only usage 
rather than saying SRTP may be absent.

Regards, Christian

On 29/10/2014 9:14 AM, Paul Kyzivat wrote:
> 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
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>