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

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

Please see my comments inline.

From: Harald Alvestrand [mailto:[e-mail]]
Sent: Tuesday, October 28, 2014 8:27 AM

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.
<Raju2>
IMHO, I don't think that is how IETF worked; you produce something which is generally useful than very specific to one particular use case without giving up on too much for the original purpose. In fact, WebRTC is a huge beneficiary of it!! IMHO, making data channels transport a generic mechanism is part of that process.
</Raju2>

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.
<Raju2>
This is related to webrtc vs. non-webrtc use of data channels. To give data channels independence (sorry, I did not mean in a dramatic way :)) from webrtc, can we make data channel drafts generic and compliancy aspects of it into a webrtc specific section/draft; this (separate draft) is how it is done for RTP transport. Such webrtc compliance for data channels can be part of the same data channel draft but a new webrtc specific section or in a new/existing webrtc specific draft (webrtc/data-channel overview draft). Similarly CLUE specific compliance can be in a separate section of the data channel draft.
</Raju2>



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.
<Raju2>
This item is specific to data channel requirements for webrtc use. If a requirement is a MUST then how can it be implementation specific? Then why put a requirement as MUST but still allow implementations to have different behavior?
</Raju2>

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.
<Raju2>
The 90% can then always support NDATA... no issue with that. But why make it a burden for rest of the 10% (these are the ones who may be constrained by various resources)? IMHO, we don't add MORE work for an implementation just because it already has LOTs of work to do anyway! It should be other way around, since there is so much stuff mandatory already why not go easy on the stuff which may not be needed by some applications!!?
</Raju2>

BR
Raju