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

[Harald Alvestrand <[e-mail]>]

On 10/28/2014 04:58 AM, Makaraju, Maridi Raju (Raju) wrote:
>
>  
>
>  
>
> From: Harald Alvestrand [mailto:[e-mail]]
> Sent: Monday, October 27, 2014 5:03 PM
>
> On 10/27/2014 01:31 PM, Makaraju, Maridi Raju (Raju) wrote:
>
>     +1 to make N-DATA optional.
>
>      
>
>     Data channel provides a robust generic peer to peer communication
>     channel. So, one can see that data channel may be used under
>     non-webrtc contexts (like as in CLUE) as a general transport or as
>     a replacement of native to SCTP to traverse firewalls. IMHO,
>     majority of these use cases:
>
>     a. May just involve a single data channel (with possible
>     multiplexing on top of it)
>
>     b. And may not use the DCEP either (both ends could assume same
>     data channel stream id, this is similar to SCTP PPIDs).
>
>     We already made DCEP(b) as optional.
>
>      
>
>     If an app is using just a single data channel then there is no
>     real benefit in using N-DATA. Then why not make it optional? Also,
>     as already pointed out, making it optional won’t break interop as
>     it is still negotiated during SCTP setup time anyway.
>
>
> Negotiation means that transport initiator gets to choose whether to
> use it or not.
> This means that a responder has no choice in the matter.
>
> In the situation where the responder knows better than the initiator
> what the usage is going to be, this is problematic.
>
> <Raju>
>
> IMHO, it is not just the responder knowing “better” which makes a
> scenario work, rather both have to agree on it. For example, if
> responder wants to have multiple data channels is no good if the
> originator does not want to support (CLUE use of data channels is an
> example of it). That’s why, in most cases I know it is the originator
> who offers capabilities and terminator gets to choose.
>
> </Raju>
>
>
>  
>
> I would like to point out that there will be some webrtc applications
> which might just use one webrtc data channel for simplicity (and may
> use some multiplexing of different types of msgs/objects on top of it)
> or one is just sufficient as the app does not send/recv huge chunks of
> data. So, N-DATA isn’t needed for such webrtc clients either. Then why
> add burden to such webrtc implementations!?
>
>
> You're confusing the webrtc application (what runs in the browser)
> with the webrtc implementation (the browser itself). Optional NDATA
> makes the browser *more* complex, since it has to expose API surface
> to let the application choose whether or not to offer NDATA, and it
> has to have code to decide whether or not to offer NDATA.
>
> <Raju>
>
> I am talking about 2 items:
>
> 1.       Making NDATA a MUST data channel draft? I could be wrong, but
> I thought this is the main discussion point in this thread! This is a
> burden on non-webrtc users of data channel. My understanding is data
> channels are meant to be used by non-webrtc as a general protocol.
> Please correct me if my understanding is not correct.
>

Your understanding may be right or wrong, but it's different from mine.

Data channels are created to be useful for WebRTC. That's their purpose
in being created, so WebRTC requirements take precedence over all other
requirements.

NDATA makes them more useful for WebRTC (or, as Martin put it, "without
NDATA, they're not fit for purpose").

Optional NDATA makes things more complex for WebRTC.

Therefore, seen from a WebRTC viewpoint, speaking in the RTCWEB WG, I
think NDATA should be mandatory.

> 2.       Making NDATA a MUST for webrtc clients? I am not just talking
> about browser, but non-browser based native/hybrid webrtc clients
> (e.g. a thin webrtc client on a cable set top box) as well. Browsers
> can implement it as a MUST clause, no one is stopping that. But why
> mandate a set top box (or an IoT device) implement NDATA when it just
> wants to use a single data channel only?!
>
> Let’s take an example: We keep NDATA a MUST. During SCTP setup, if
> NDATA is not supported at the peer then will the SCTP setup be
> abandoned? If the SCTP association is not abandoned then there is no
> point in making it a MUST where as in real practice it is not enforced
> as a MUST.
>

In general, when an application connects to something that does not
conform to the spec for the protocol he's using, "all bets are off".

Implementations are free to handle this situation whatever way they want.

Note: So far, I've seen *zero* evidence that the burden of implementing
NDATA is significantly higher than the total effort spent in writing
updates on this thread. For 90+% of all implementors, not implementing
NDATA is a larger effort than implementing it, because the libraries
they use will support it, so they have to take action to take it out.